Établir et maintenir un inventaire cryptographique pour la migration post-quantique

Objectif

État au 25 octobre 2026. Établir un inventaire étayé par des preuves, qui facilite les décisions de migration et reste utile après les changements de déploiement. Vérifier de nouveau la FAQ de migration régulièrement actualisée du NIST et le schéma CycloneDX choisi pour les échanges. Cette procédure propose un registre opérationnel plutôt que d'affirmer qu'un outil d'analyse peut découvrir toutes les dépendances cryptographiques.

Le NIST décrit un inventaire couvrant les systèmes, les applications, les services, les appareils et les flux de données. CycloneDX fournit un modèle pour les algorithmes, les clés, les certificats et leurs relations avec les composants logiciels. Ces relations techniques sont des éléments utiles ; il reste à consigner les responsabilités et les décisions de migration.

Prérequis

Choisir un service au périmètre délimité et un responsable désigné. Obtenir son architecture, ses inventaires logiciels et matériels, ses registres de certificats, sa configuration et des observations autorisées en cours d'exécution. Inclure les fournisseurs lorsqu'une dépendance est gérée à l'extérieur. Consigner explicitement les inconnues au lieu de supposer qu'une absence de résultat signifie une absence de cryptographie.

Étapes

1. Cartographier les flux de données et les frontières de confiance du service. Créer des entrées distinctes pour les connexions dont la terminaison est externe, les connexions internes, les données stockées et la vérification de signatures. Identifier les données qui doivent rester confidentielles sur une longue durée et les signatures qui doivent rester vérifiables.
2. Consigner la finalité cryptographique, l'algorithme exact ou le jeu de paramètres, la taille de clé lorsqu'elle s'applique, le protocole et le groupe négocié. Distinguer une capacité implémentée, un paramètre activé et une utilisation observée. Éviter un unique champ oui/non indiquant le caractère post-quantique d'un service entier.
3. Joindre le contexte d'implémentation : versions des bibliothèques et des environnements d'exécution, identifiant du paquet ou de l'image, fournisseur cryptographique, emplacement de la configuration, chaîne de certificats et algorithme de clé publique. Consigner le modèle matériel et les dépendances au micrologiciel lorsqu'un HSM ou une appliance limite les possibilités de mise à niveau. Stocker les identifiants des clés et les métadonnées relatives à leur garde, jamais les clés privées, les secrets partagés ou les éléments de récupération.
4. Ajouter les preuves et les responsabilités. Pour chaque entrée, conserver la méthode de collecte, l'heure d'observation, l'environnement, l'équipe responsable et la référence de la source. Préciser si la preuve provient de l'examen du code source, de la configuration, de la documentation d'un fournisseur ou d'une connexion observée. Traiter les divergences comme des tâches à résoudre, pas comme des valeurs à fusionner silencieusement.
5. Exporter les éléments techniques et leurs relations sous forme de CBOM CycloneDX en utilisant un schéma pris en charge par les outils destinataires. Valider l'export selon ce schéma. Le relier à l'inventaire logiciel et tenir un registre complémentaire pour les responsables métier, les besoins de conservation, les contraintes des fournisseurs, les exceptions et l'action de migration proposée.
6. Actualiser le registre lorsque les logiciels, les micrologiciels, les certificats, la politique ou les chemins de terminaison changent. Examiner les différences lors de l'approbation du déploiement. Attribuer à chaque dépendance non résolue un responsable et une prochaine échéance de réexamen ; conserver les preuves expliquant une décision de migration antérieure.

Résultat attendu

Le responsable peut relier les données protégées à un protocole, à une implémentation et à une partie responsable, distinguer les observations confirmées des hypothèses et identifier la prochaine tâche concrète de migration. Une nouvelle version produit des changements d'inventaire qui peuvent être examinés.

Limites et base de vérification

Aucun outil de découverte ni aucun parc n'a été testé pour cet article. Une validation de schéma réussie établit la structure du document, pas son exhaustivité ni sa correction cryptographique. Les observations réseau ne permettent pas d'établir tous les comportements de signature hors ligne ou de stockage. Restreindre l'accès à l'inventaire, car ses métadonnées décrivent une infrastructure sensible même s'il ne contient aucun élément secret.