Comment préparer votre entreprise à la transition post-quantique

La cryptographie post-quantique (PQC) est conçue pour protéger les données et les systèmes d’authentification contre de futurs ordinateurs quantiques capables de casser des méthodes cryptographiques largement utilisées aujourd’hui. Pour les DSI, RSSI et CTO, l’état de préparation d’un fournisseur cloud en matière de PQC ne garantit pas l’état de préparation de chaque application, client, clé et dépendance matérielle exécutés chez ce fournisseur.

Les fournisseurs contrôlent certains composants. Les clients et d’autres fournisseurs en contrôlent d’autres, tandis que les organismes de normalisation influencent la trajectoire de migration. L’état de préparation de l’entreprise dépend donc de sa capacité à savoir qui contrôle chaque dépendance cryptographique et à quel moment elle peut évoluer.

L’objectif pratique est l’agilité cryptographique : la capacité à faire évoluer les méthodes cryptographiques au rythme des standards et des capacités des fournisseurs, sans devoir mener une migration perturbatrice à chaque fois.

L’état de préparation à la cryptographie post-quantique dépend de la propriété

Un fournisseur cloud peut mettre à jour l’infrastructure sous son contrôle, mais les dépendances gérées par le client nécessitent toujours des changements. Les applications, les actifs cryptographiques, les logiciels clients, les configurations de service et les pratiques de cycle de vie des clés peuvent tous se situer du côté client de cette frontière.

Un client incompatible, par exemple, ne peut pas utiliser une nouvelle option cryptographique tant qu’il n’a pas été mis à jour. Une équipe doit identifier une dépendance cryptographique avant de pouvoir déterminer si sa migration relève de l’entreprise, de son fournisseur cloud ou d’un autre fournisseur.

Cela fait de l’agilité cryptographique une exigence d’architecture. Si une dépendance cryptographique est intégrée dans un client incompatible, un composant logiciel legacy ou un cycle de vie matériel, changer d’algorithme exige aussi de modifier cette dépendance.

La cryptographie post-quantique suit différentes trajectoires de migration

La confidentialité crée une première trajectoire de migration. Store Now, Decrypt Later décrit une attaque dans laquelle des informations chiffrées sont capturées aujourd’hui pour être déchiffrées une fois que des systèmes quantiques suffisamment puissants seront disponibles. Le risque est déjà réel pour les informations qui doivent rester confidentielles pendant de nombreuses années.

L’authenticité crée une autre trajectoire. Les identifiants falsifiés et les signatures logicielles posent un problème de migration différent de celui du trafic chiffré capturé. Les certificats, les identités et les autres mécanismes de confiance doivent eux aussi évoluer.

Le matériel et les logiciels legacy introduisent des contraintes supplémentaires, car leur remplacement peut dépendre de cycles de mise à niveau et de renouvellement. L’état de préparation à la migration et le retrait des anciennes technologies cryptographiques peuvent donc suivre des calendriers différents.

Certaines dépendances échappent au contrôle du client

Les entreprises dépendent de l’infrastructure des fournisseurs et de standards externes pour certaines parties de la migration qu’elles ne peuvent pas modifier directement. D’autres dépendances restent sous le contrôle de l’entreprise.

Pour la planification de l’entreprise, cela crée trois groupes de propriété : l’infrastructure contrôlée par le fournisseur, les mécanismes dépendants des standards et les systèmes contrôlés par le client. Les données confidentielles à longue durée de vie doivent être examinées au regard de leur exposition à Store Now, Decrypt Later. Les dépendances liées aux signatures, aux certificats et aux identités nécessitent leur propre planification de migration. Le matériel et les logiciels legacy doivent ensuite être rattachés à la trajectoire qu’ils contraignent.

Le levier pratique est une cartographie de la propriété. Elle doit identifier les dépendances que l’entreprise peut modifier directement, celles qui nécessitent des capacités du fournisseur, et celles régies par des standards ou d’autres fournisseurs. Cette cartographie donne aux équipes d’ingénierie une base pour tester les clients et applications contrôlés par le client à mesure que les capacités externes requises deviennent disponibles.

Points clés à retenir pour les décideurs

Cartographier la propriété cryptographique : L’état de préparation du fournisseur cloud ne rend pas les applications, clients, clés et matériels du client résistants au quantique. Les dirigeants doivent identifier qui contrôle chaque dépendance et où la migration dépend des fournisseurs, des standards ou d’autres prestataires.
Planifier des trajectoires de migration distinctes : La confidentialité, l’authentification, le matériel et les logiciels legacy sont confrontés à des risques et à des calendriers post-quantiques différents. Donnez la priorité aux données sensibles à longue durée de vie tout en planifiant séparément les certificats, les signatures, les identités et les cycles de renouvellement technologique plus lents.
Construire l’agilité cryptographique autour des dépendances externes : Certains changements cryptographiques dépendent des fournisseurs cloud, des organismes de normalisation et des fournisseurs. Les dirigeants doivent développer l’agilité cryptographique et tester les systèmes contrôlés par le client à mesure que les capacités externes deviennent disponibles.