Best practices · 5 MIN DE LECTURE

Cryptographie post-quantique : préparer les équipes réseau

L’édition spéciale Cisco de Post-Quantum Cryptography for Dummies se présente comme un point de départ pour les équipes informatiques confrontées à la complexité de l’informatique quantique. Pour les exploitants réseau, l’étape suivante consiste à transformer cette sensibilisation en un plan couvrant les actifs, les configurations, les canaux d’administration, la conformité et le cycle de vie.

Cryptographie post-quantique : préparer les équipes réseau

Passer de la sensibilisation à la préparation opérationnelle

L’article de Cisco revient sur les raisons qui ont conduit à la publication de Post-Quantum Cryptography for Dummies—Cisco Special Edition. Cette ressource doit servir de point de départ aux équipes informatiques qui souhaitent comprendre la cryptographie post-quantique, ou PQC, et aborder les difficultés liées à l’informatique quantique.

Pour les équipes réseau, ce point de départ doit déboucher sur une question concrète : comment faire évoluer la cryptographie d’une infrastructure multiconstructeur sans perdre en visibilité, en accessibilité ou en maîtrise opérationnelle ?

La préparation à la PQC ne concerne pas uniquement les développeurs d’applications et les architectes de sécurité. L’infrastructure réseau s’appuie elle aussi sur la cryptographie pour les accès administratifs, les communications entre équipements, l’automatisation, les identifiants et d’autres processus de gestion. Une transition future devra donc prendre en compte le trafic de production, mais aussi les canaux utilisés pour exploiter le réseau.

Commencer par l’inventaire de l’infrastructure

Aucune équipe ne peut planifier des évolutions cryptographiques autour d’actifs qu’elle ne connaît pas. La première étape consiste à établir une vue fiable des éléments suivants :

  • Équipements réseau, pare-feu, appliances et systèmes d’administration

  • Constructeurs, modèles, versions logicielles et état du cycle de vie

  • Configurations de référence et dépendances entre actifs

  • Chemins d’administration et d’automatisation utilisés pour gérer les équipements

  • Propriétaires et responsabilités opérationnelles de chaque système

Cet inventaire constitue la base des futures évaluations des constructeurs et des décisions de mise à niveau. Il aide également à distinguer les équipements susceptibles d’être mis à jour de ceux qui devront, à terme, être remplacés.

Ne pas oublier le plan d’administration

Une migration cryptographique peut échouer si elle se concentre exclusivement sur les services visibles par les utilisateurs. Les équipes réseau doivent aussi documenter la manière dont les administrateurs, les scripts et les outils opérationnels accèdent à l’infrastructure.

Il convient notamment d’examiner :

  • Les sessions d’administration interactives

  • Les tâches automatisées de configuration et de provisionnement

  • Les processus de sauvegarde et de restauration des configurations

  • Le stockage et la distribution des identifiants

  • Les connexions de supervision et de découverte des actifs

  • Les communications entre équipements réseau et appliances de sécurité

L’objectif n’est pas de modifier immédiatement les protocoles à partir d’un premier document de sensibilisation. Il s’agit d’identifier les dépendances afin que les futurs changements puissent être testés sans interrompre de façon imprévue les accès ou les automatisations.

Construire un processus de mise à niveau maîtrisé

La PQC étant un domaine en évolution, mieux vaut ne pas traiter la préparation comme un projet de remplacement unique. Une démarche progressive est plus facile à maîtriser :

  1. Découvrir : établir un inventaire actualisé des actifs et des configurations.

  2. Classer : regrouper les actifs par fonction, criticité, constructeur, cycle de vie et méthode d’administration.

  3. Suivre : surveiller les recommandations des constructeurs et les informations de sécurité pertinentes pour chaque actif.

  4. Tester : valider les changements dans un périmètre limité, y compris les accès d’administration et le retour arrière.

  5. Documenter : consigner les configurations approuvées, les exceptions et les preuves nécessaires aux audits.

  6. Déployer progressivement : recourir à une automatisation contrôlée et vérifier chaque étape avant d’élargir le périmètre.

  7. Réévaluer : actualiser le plan à mesure que les produits, les recommandations et les exigences de l’organisation évoluent.

L’historique des configurations est particulièrement important. Une modification cryptographique peut affecter la compatibilité entre plusieurs systèmes. Les équipes ont donc besoin d’un enregistrement fiable des changements et d’un moyen concret de revenir à une configuration connue.

Rattacher la préparation PQC à la gouvernance

Le chantier PQC ne doit pas être isolé des programmes existants de sécurité et de conformité. Les inventaires, normes de configuration, validations de changement, exceptions et décisions liées au cycle de vie peuvent tous intégrer le corpus de preuves de l’organisation.

Les équipes peuvent commencer par définir :

  • Le responsable de la transition cryptographique de l’infrastructure réseau

  • La manière dont les recommandations des constructeurs seront examinées et consignées

  • Les actifs prioritaires selon leur rôle et leur cycle de vie

  • Les preuves de test et de retour arrière exigées avant un déploiement

  • Le traitement des exceptions et des équipements non pris en charge

Une vaste réflexion technologique devient ainsi un processus opérationnel reproductible.

Comment ConnectMyAssets aide

ConnectMyAssets fournit une base on-premise et indépendante des constructeurs pour gérer les informations d’infrastructure nécessaires à la préparation d’une transition cryptographique.

  • La CMDB dynamique centralise les actifs multiconstructeurs, leurs versions logicielles et leurs configurations.

  • Le module Backup & History conserve les versions de configuration et permet un retour arrière en un clic lorsqu’un changement testé doit être annulé.

  • Le Compliance Engine aide à évaluer les configurations au regard des exigences internes et de référentiels tels que NIS2, ISO 27001, PCI, CISA et NIST.

  • Le suivi de fin de vie met en évidence les actifs dont le cycle de vie risque de limiter les futures possibilités de mise à niveau.

  • Le suivi des CVE par actif relie les vulnérabilités aux équipements concernés.

  • Les fonctions Automation & ZTP facilitent un déploiement contrôlé et reproductible après validation des changements.

  • Le Credential Vault et le SSH Bastion contribuent à encadrer les accès administratifs pendant les opérations de migration.

Il ne s’agit pas de prédire les fonctions PQC que chaque constructeur proposera. L’objectif est de fournir aux équipes réseau un inventaire fiable, un historique des configurations, un processus de conformité et une méthode de déploiement afin qu’elles puissent agir lorsque des recommandations validées et des mises à niveau prises en charge seront disponibles.

Faire de cette ressource un point de départ

Cisco présente sa publication sur la PQC comme un point de départ, et c’est ainsi que les équipes réseau devraient l’utiliser. La sensibilisation doit être suivie d’un travail de découverte des actifs, de cartographie des dépendances, de planification du cycle de vie, de test, de retour arrière et de gouvernance.

Les organisations les mieux préparées aux futures évolutions cryptographiques seront celles qui savent déjà précisément ce qu’elles exploitent, comment elles l’administrent et comment le faire évoluer sans risque.

Source : Cisco

Partager cet articleLinkedIn ↗Email ↗

Pour aller plus loin.

Tous les articles
Best practices

Sous-réseaux dupliqués : une panne cachée dans vagrant-libvirt

Un environnement vagrant-libvirt peut échouer de manière inattendue lorsqu'un réseau virtuel existant utilise le même sous-réseau IP qu'un réseau de gestion demandé, même si les réseaux ont des noms différents. L'incident est un rappel utile que l'automatisation doit valider l'espace d'adressage, pas simplement les noms d'objets, avant de créer l'infrastructure de laboratoire.

Lire l’article