Inventaire crypto et crypto-agilité : vous ne migrez pas ce que vous ne savez pas avoir

Chaque conversation sur la migration post-quantique se heurte à une question sans réponse : où exactement l’organisation utilise-t-elle la cryptographie. La plupart des dirigeants ne savent pas comment réagir, et ceux qui réagissent rapidement se trompent souvent.

Ce manque de connaissances est le plus grand obstacle au projet. Vous ne pouvez pas migrer, prioriser ou estimer des délais sur une carte vierge. Avant de choisir ML-KEM, ML-DSA ou tout autre algorithme, vous devez voir la configuration du terrain.

Cet article aborde les deux capacités qui sous-tendent toute transition cryptographique sérieuse : l’inventaire, qui montre ce que vous possédez, et la crypto-agilité, qui vous permet de modifier les algorithmes sans réécrire l’ensemble du système. Sans eux, la migration post-quantique devient un projet éternel et coûteux.

Pourquoi l'inventaire passe avant tout

Le chiffrement se propage silencieusement dans toute une organisation. Il se trouve dans le trafic réseau, dans les certificats, dans les signatures logicielles, dans les jetons, dans les bases de données, dans les intégrations avec des tiers, dans les appareils, dans les bibliothèques intégrées dans des dépendances que personne n'a consciemment choisies.

Cette diffusion crée des angles morts dangereux. Un certificat oublié, une ancienne bibliothèque intégrée à trois niveaux de la chaîne de dépendance, un service hérité auquel personne ne veut toucher : n'importe lequel d'entre eux pourrait être exactement le point qui utilise RSA ou ECC de manière critique. Vous ne migrez pas ce que vous ne savez pas avoir, et ce que vous ne savez pas que vous avez est ce qui fait le plus mal.

L’inventaire est également ce qui rend possible la priorisation. Sans savoir où se trouve le chiffrement et quelles données il protège, vous ne pouvez pas savoir quoi migrer en premier. Avec la carte, la conversation passe de « nous devons faire quelque chose à propos du quantique » à « ces vingt flux protègent les données à long terme et s'appuient sur des algorithmes vulnérables, commençons par eux ».

Et il y a l’aspect conformité. Démontrer à un régulateur, un auditeur ou un client que vous savez où vous utilisez le cryptage et que vous avez un plan est très différent d'admettre que vous n'en avez aucune idée. En vertu de la LGPD, connaître et protéger le cheminement des données personnelles fait partie de l'obligation et non un supplément.

Que cartographier spécifiquement

Un inventaire cryptographique utile va au-delà de la liste des certificats. Il répond aux questions opérationnelles.

Cartographiez les actifs cryptographiques : clés, certificats, secrets, leurs emplacements, propriétaires et dates d'expiration. Cartographiez les algorithmes utilisés, en distinguant ce qui est vulnérable à l'informatique quantique, comme RSA et ECC, de ce qui est plus résilient, comme la cryptographie symétrique forte. Cartographiez les bibliothèques et les versions utilisées par chaque application, y compris celles intégrées aux dépendances, car c'est là que réside la majeure partie du chiffrement que personne n'a consciemment choisi.

Cartographiez les protocoles de vos connexions, internes et externes, car c'est dans leur échange de clés que se concentre le risque de capture précoce. Et cartographier les données que chaque utilisation du chiffrement protège, avec une attention particulière à la validité de la confidentialité : les données qui doivent rester secrètes pendant de nombreuses années sont les plus exposées au « récolter maintenant, décrypter plus tard », la capture des données chiffrées aujourd'hui pour un décryptage futur avec l'informatique quantique.

Enfin, cartographiez les fournisseurs. Une grande partie de votre chiffrement s'effectue au sein de fournisseurs de cloud, de SaaS et de partenaires. Savoir lesquels d’entre eux ont un plan de transition post-quantique fait partie de votre inventaire, car leur risque est le vôtre.

Comment mener l'enquête sans planter

La réaction de nombreuses équipes face à cette liste est le découragement : elle semble trop grande. La solution n’est pas d’essayer de tout inventorier parfaitement en une seule fois.

Combinez les polices. Les outils de découverte automatisés analysent le réseau, le code et les certificats et trouvent une grande partie de ce qui est caché. Mais ils ne remplacent pas les connaissances des utilisateurs : les architectes et les équipes produit connaissent les dépendances et les contextes qu'aucune analyse ne capture. Utilisez les deux fronts.

Commencez par ce qui compte. Au lieu d’effectuer un inventaire universel avant de prendre toute mesure, donnez la priorité aux systèmes qui touchent à des données à longue validité et à forte exposition. Inventoriez-les d’abord, commencez à agir en conséquence et élargissez l’enquête par vagues. Un inventaire partiel et exploitable vaut plus qu’un inventaire complet et retardé.

Et traitez l’inventaire comme vivant. Ce n’est pas un document que vous écrivez une seule fois et que vous classez. Les systèmes changent, les certificats naissent et meurent, les dépendances augmentent en version. Un inventaire qui n’est pas mis à jour vieillit rapidement et redevient une carte vierge. Intégrez la découverte cryptographique dans vos processus de changement et de déploiement.

Crypto-agilité : échanger sans réécrire

L'inventaire répond « ce que j'ai ». La crypto-agilité répond « à quelle vitesse puis-je trader ». Les deux se complètent.

La crypto-agilité est la capacité de modifier l’algorithme cryptographique d’un système sans le réécrire complètement. C'est une propriété architecturale. Les systèmes qui ont lié un algorithme spécifique au code, diffusant des appels directs à un chiffre partout dans le monde, paient cher au changement : chaque changement devient un projet de plusieurs mois, avec des risques à chaque étape.

La différence réside dans le couplage. Lorsque le chiffrement est isolé derrière une couche bien définie, une limite claire que le reste du système utilise sans connaître les détails internes, le fait de basculer l'algorithme en dessous de cette limite est un changement contenu. Le reste du système ne le remarque même pas.

Cela est particulièrement important aujourd’hui, car la cryptographie post-quantique va évoluer. Les paramètres seront ajustés, de nouveaux algorithmes pourront émerger, les recommandations changeront. Sans crypto-agilité, vous répétez l’intégralité du projet de migration à chaque mouvement. Avec lui, le prochain échange est incrémental. La migration post-quantique est la première preuve majeure de cette capacité, et non la dernière.

Développer la capacité d'échange

La crypto-agilité ne peut pas être achetée toute faite, elle est construite avec des décisions de conception conscientes.

Centralisez l’accès au chiffrement. Au lieu que chaque partie du système appelle directement un chiffre spécifique, faites-les passer par un point commun qui décide quel algorithme utiliser. Changer l’algorithme, c’est changer cette décision centrale, et non rechercher les appels disséminés dans le code.

Externaliser la configuration des algorithmes. Le chiffre à utiliser, avec quels paramètres, doit être une configuration et non une constante intégrée dans le code. Cela vous permet d'ajuster, et même de revenir en arrière, sans tout réécrire ni redéployer, ce qui est vital lorsqu'une mise à niveau post-quantique provoque des problèmes de production et que vous avez besoin d'un retour en arrière.

Concevoir pour fonctionner avec plusieurs algorithmes en même temps. Pendant la transition, les clients et les serveurs seront à des étapes différentes, et l'approche hybride combine des algorithmes classiques et post-quantiques. Votre système doit négocier et prendre en charge plusieurs algorithmes en parallèle sans rompre les connexions légitimes. Quiconque a supposé un seul algorithme dans la conception en souffre précisément ici.

Et s'adapte aux nouvelles tailles. Les clés et signatures post-quantiques sont plus grandes. Les structures, les champs et les limites qui ont pris de petites dimensions doivent être dégagés. Construire ce slack évite désormais de refaire le travail plus tard.