Qu'est-ce que la gestion des clés cryptographiques ? Un guide complet

La gestion des clés cryptographiques est la discipline qui consiste à contrôler les clés cryptographiques tout au long de leur cycle de vie : depuis leur création jusqu'à leur destruction. Elle englobe les politiques, les procédures et les technologies qui régissent la manière dont les clés sont générées, distribuées, stockées, utilisées, renouvelées, révoquées et retirées. Lorsqu'elle est correctement mise en œuvre, elle garantit que les protections cryptographiques sur lesquelles repose une organisation restent efficaces, conformes et résilientes. Lorsqu'elle est négligée, elle crée des vulnérabilités invisibles pouvant entraîner des failles catastrophiques.

Ce guide présente tout ce que les responsables de la sécurité informatique, les RSSI et les architectes de sécurité doivent savoir sur la gestion des clés cryptographiques à l'échelle de l'entreprise.

Pourquoi l'automatisation est-elle importante pour la gestion des clés cryptographiques ?

L'automatisation est le levier qui permet de mettre en œuvre à grande échelle toutes les autres bonnes pratiques clés en matière de gestion.

Évoluer au rythme de la croissance.
Alors que les exigences en matière de cryptographie ne cessent de s'étendre avec l'apparition de nouvelles réglementations, applications et types d'appareils, la gestion manuelle des clés ne parvient plus à suivre le rythme. L'automatisation permet aux entreprises de faire évoluer leur infrastructure cryptographique sans augmenter proportionnellement leurs effectifs ni leurs risques.

Automatisation du cycle de vie.
La rotation, le renouvellement et la révocation des clés doivent être automatisés afin d'éliminer les processus manuels et de réduire la fenêtre de vulnérabilité. Le cycle de vie des clés doit être automatisé pour garantir leur rotation régulière.

Réduire l'intervention humaine.
Chaque fois qu'une personne manipule directement une clé cryptographique, le risque d'erreur, de vol ou d'utilisation abusive augmente. La violation de données subie par Postbank, au cours de laquelle un seul employé malveillant a dérobé des clés principales, illustre pourquoi il est essentiel de réduire au minimum le contact humain avec les clés. L'automatisation évite au personnel d'avoir à manipuler directement les clés.

Prévention des erreurs de configuration.
Les systèmes automatisés garantissent une configuration cohérente sur l'ensemble des appareils et applications utilisant des clés, éliminant ainsi les écarts de configuration que les processus manuels entraînent inévitablement.

Cryptographie post-quantique.
À mesure que la transition vers la cryptographie résistante au quantique (PQC) s'amorce, il faudra remplacer l'ensemble des clés et mettre en place l'infrastructure nécessaire pour prendre en charge les tailles et les formats de clés requis par les nouveaux algorithmes.

Chacun de ces points est abordé plus en détail dans la suite de cet article.

S'adapter à la croissance : pourquoi la gestion des clés cryptographiques est essentielle

L’ampleur du défi aggrave encore le risque. Les organisations géraient en moyenne plus de 11 000 clés et certificats, mais une grande partie d’entre elles ignorent le nombre exact de clés utilisées dans leurs environnements, ou pire encore, ne savent pas où ces clés sont stockées. Compte tenu de la croissance rapide de l’adoption de la cryptographie depuis lors, ces chiffres sous-estiment probablement l’ampleur actuelle du défi. La plupart des organisations ne disposent ni des outils, ni des compétences, ni du budget nécessaires pour gérer efficacement leurs clés cryptographiques. Les violations de sécurité touchent rarement les actifs faisant l’objet d’une surveillance constante ; ce sont les clés non gérées et oubliées qui conduisent le plus souvent à des compromissions.

La leçon à retenir est simple : chaque clé doit être identifiée, gérée, surveillée et contrôlée.

Types et exemples de clés cryptographiques:les organisations doivent gérer une grande variété de clés cryptographiques, chacune présentant des exigences spécifiques en matière de cycle de vie et des considérations de sécurité différentes. La compréhension de ces catégories constitue la première étape vers une gestion complète des clés.

ClésPKI (les ancrages de confiance)

• Clé de signature de l'autorité de certification racine.
  Signe les certificats des autorités de certification intermédiaires. Ces clés sont généralement conservées hors ligne dans un module HSM isolé physiquement (air-gapped) et ne sont utilisées que lors des cérémonies de changement de clés programmées.
• Émission de la clé de signature de l'autorité de certification (intermédiaire).
  Signe en masse les certificats d'entités finales et les listes CRL. Ces clés se trouvent en ligne, dans un module HSM connecté au réseau et situé en aval de l'autorité de certification émettrice (ADCS, EJBCA, Keyfactor Command).
• Clé de signature du répondeur OCSP.
  Signe les réponses relatives à l'état des certificats. Ces clés se trouvent sur l'hôte du répondeur et sont généralement stockées dans un module de sécurité matériel (HSM).
• Identifiants d'inscription.
  Mots de passe de vérification SCEP, clés de compte ACME, identifiants EST. Ils sont conservés par les terminaux inscrits : appareils gérés par MDM/UEM, équipements réseau, serveurs Web et équilibreurs de charge exécutant des clients ACME.

Clés d'identité et clés hardware(identités des appareils)

• IDevID.
  Identifiant permanent gravé lors de la fabrication. Il se trouve dans l'élément sécurisé de l'appareil ou dans le TPM : cartes réseau, IoT et équipements réseau.
• LDevID.
  Identités émises localement et attribuées lors de l'intégration. Elles sont stockées dans le même TPM/élément sécurisé, dont la portée est limitée à votre domaine.
• Clés TPM (EK, AK, SRK).
  Clés d'attestation, de validation et de stockage racine. Elles sont intégrées ou générées au sein du TPM sur chaque ordinateur portable et serveur géré ; elles permettent l'attestation de la plate-forme et le chiffrement du disque.
• Démarrage sécurisé et clés de signature du micrologiciel.
  Vérification que seul le code autorisé est chargé au démarrage. Les clés de signature sont détenues par le fabricant d'équipement d'origine (OEM) ou le fournisseur de la plateforme ; les clés de vérification sont intégrées au micrologiciel UEFI.
• Clés de signature de code.
  Signer software les pilotes. Elles se trouvent dans une hardware ou un HSM (hardware est désormais requise pour la signature de code de confiance publique, conformément aux recommandations du CA/Browser Forum relatives à la signature de code), généralement au sein du pipeline de compilation/déploiement ou d'un service de signature dédié.

Secrets liés au protocole et à l'application

• Clés SSH.
  Asymétriques et réputées pour leur prolifération (pas de date d'expiration, pas d'inventaire centralisé). On les trouve partout : dans le fichier `authorized_keys` des serveurs, sur les environnements CI/CD, sur les ordinateurs portables des développeurs, dans les comptes de service.
• Clés pré-partagées (PSK).
  Secrets symétriques à longue durée de vie. On les retrouve dans les concentrateurs VPN et les tunnels IPsec, le Wi-Fi (WPA2-PSK) et IoT .
• Clés de chiffrement des tickets de session (STEK).
  Elles chiffrent les tickets TLS ; si elles ne sont pas renouvelées, elles compromettent discrètement la confidentialité persistante que l'échange de clés éphémères est censé garantir. On les trouve dans TLS : équilibreurs de charge, proxys inversés, périphérie CDN, serveurs web.
• Clésstatiquesd'accord de cléetde transport de clé.
  Les équivalents non éphémères des clés éphémères d'établissement de clé. On les retrouve dans TLS hérités, dans S/MIME et dans certaines IoT .

Types de clés post-quantiques

• Paires de clés ML-KEM (FIPS 203).
  Remplacent l'établissement classique des clés. Premières applications : TLS hybride X25519MLKEM768), VPN et SSH.
• Clés de signature ML-DSA (FIPS 204) et SLH-DSA (FIPS 205).
  Elles remplacent les signatures RSA et ECC. Elles sont utilisées pour la signature de code et de micrologiciels, les futures hiérarchies d'autorités de certification (CA) et la signature de documents.
• Paires hybrides.
  Une clé classique et une clé PQ par canal pendant la migration. Elles apparaissent partout où les clés classiques sont déjà présentes, ce qui explique précisément la croissance du parc et justifie le recours à la « crypto-agilité ».

Secrets au porteur(gérés comme des clés, mais qui ne sont pas des clés)

• Clés API, PAT,chaînesde connexion.
  Elles ont une durée de vie longue et sont validées par une comparaison avec une valeur stockée (idéalement hachée). Elles se trouvent dans des gestionnaires de secrets (Vault, AWS/GCP Secrets Manager), dans les environnements CI/CD, dans la configuration des applications, dans les fichiers .env et, trop souvent, dans le code source.
• Secrets et jetons OAuth (accès, actualisation, session).
  Les secretssont définis dans la configuration de l'application ; les jetons sont émis par le fournisseur d'identité (IdP) et conservés par les applications et les sessions de navigateur. Leur durée de vie est généralement courte.

Le cycle de vie des clés cryptographiques

Chaque clé cryptographique passe par une série d'étapes, de sa création à sa destruction. Il est essentiel de gérer efficacement chacune de ces étapes pour garantir la sécurité.

1. Génération :les clés doivent être générées à l'aide de générateurs de nombres aléatoires cryptographiquement sûrs. Une entropie insuffisante lors de la génération peut compromettre l'ensemble de la chaîne de sécurité.
2. Distribution :les clés doivent être transmises en toute sécurité aux parties et aux systèmes autorisés. Les clés privées ne doivent en aucun cas être exposées pendant leur transfert, et l'intégrité des clés publiques doit pouvoir être garantie.
3. Stockage :les clés au repos doivent être protégées à l'aide de modules hardware (HSM), de coffres à clés ou de protections équivalentes empêchant tout accès non autorisé.
4. Utilisation :les clés doivent être utilisées dans le cadre d'opérations cryptographiques soumises à des contrôles d'accès stricts, afin de garantir que seuls les processus et les utilisateurs autorisés puissent les invoquer.
5. Rotation :les clés doivent être remplacées selon un calendrier préétabli ou en fonction d'événements spécifiques. La rotation répond à plusieurs objectifs : elle minimise le risque d'utiliser une clé compromise, elle garantit la conformité aux normes cryptographiques et aux bonnes pratiques en vigueur, et elle réduit l'intervention humaine sur les clés sensibles. La rotation des clés est souvent évitée car elle peut s'avérer fastidieuse, ce qui explique précisément pourquoi l'automatisation est essentielle.
6. Révocation :les clés compromises ou obsolètes doivent être invalidées sans délai afin d'empêcher toute utilisation abusive ultérieure.
7. Destruction :les clés retirées doivent être définitivement effacées afin qu'elles ne puissent être ni récupérées ni réutilisées.

Ces étapes sont fixes et, en principe, chacune d'entre elles pourrait être effectuée manuellement. Cependant, l'automatisation garantit que chaque étape est exécutée en temps voulu, de manière efficace et en toute sécurité, ce qui est essentiel lors du traitement de matériel cryptographique.

Réduire les interventions humaines et prévenir les erreurs de configuration

Les conséquences d’une mauvaise gestion des clés peuvent s’avérer extrêmement coûteuses. L’un des exemples les plus frappants est celui de Postbank (la division bancaire de la Poste sud-africaine), qui a découvert qu’un employé malveillant avait dérobé les clés principales à 36 chiffres protégeant ses systèmes. Cette faille a donné lieu à 25 000 transactions frauduleuses d’une valeur totale de 3,2 millions de dollars, et le coût du remplacement de toutes les cartes de crédit et de retrait concernées s’est élevé à 58 millions de dollars.

Ce cas illustre une réalité plus générale : une seule clé compromise peut entraîner des pertes qui dépassent de loin le coût d’une infrastructure de gestion des clés adéquate. Il met également en évidence la cause profonde du problème. Une personne a pu consulter une clé principale en clair et agir de son propre chef, sans que personne d’autre ne soit mis au courant et, jusqu’à ce que la fraude soit découverte, sans qu’on puisse lui attribuer la responsabilité de cet acte. Les deux mesures de protection qui auraient permis d’éviter cela font l’objet de cette section : aucune clé ne doit appartenir à personne en particulier, et aucune clé ne doit pouvoir être utilisée par une seule personne agissant à l’insu de tous.

Responsabilité des clés.
La responsabilitédes clés et des certificats est souvent répartie au sein d’une organisation, la direction émettant des hypothèses quant aux politiques applicables. Le problème profond ne réside pas dans le fait que cette responsabilité soit répartie, mais qu’elle soit souvent mal définie. Les clés s’accumulent sans propriétaire désigné, et une clé sans propriétaire est une clé que personne ne renouvelle, ne surveille ni ne révoque lorsque la personne qui l’a créée quitte l’entreprise. Chaque clé et chaque certificat doivent être associés à un propriétaire spécifique et responsable, qu’il s’agisse d’une personne ou d’une équipe désignée plutôt que d’une boîte aux lettres partagée, et être répertoriés dans l’inventaire avec leur finalité, leur emplacement et leur durée de validité cryptographique. Il convient de distinguer la propriété (la responsabilité du cycle de vie de la clé et de la politique qui la régit) de la garde (le contrôle opérationnel du matériel de chiffrement lui-même) ; le propriétaire définit les règles, tandis que le dépositaire et le module HSM les appliquent. La propriété doit également être transférée sans heurts lors des changements de poste et des départs, car c’est précisément lors de ces moments de transition que les clés se retrouvent orphelines. Une approche fragmentée de la gestion des clés n’est plus acceptable : si vous ne pouvez pas désigner la personne responsable d’une clé, vous ne pouvez tenir personne pour responsable de celle-ci.

Contrôles d’accès.
Aucune personne ne devrait pouvoir générer, distribuer et utiliser des clés sans surveillance. Ce principe, appelé « séparation des contrôles », est mis en œuvre grâce à plusieurs mécanismes qui se recoupent. La séparation des tâches répartit le cycle de vie entre des rôles distincts (responsable de la cryptographie, dépositaire de clés, opérateur, auditeur) afin qu’aucun rôle ne couvre à la fois la génération, l’utilisation et l’audit. Le double contrôle et la répartition des connaissances exigent que deux personnes autorisées ou plus agissent conjointement pour les opérations sensibles, de sorte qu’aucun individu ne puisse activer ou exporter seul une clé protégée. Le quorum « M sur N » étend ce principe aux opérations les plus critiques, telles que les cérémonies de clés racines et l’autorisation des HSM, où un seuil minimum de dépositaires doit se réunir physiquement. Le principe du « privilège minimal » limite chaque rôle aux seules clés et opérations dont il a réellement besoin. Ensemble, ces contrôles garantissent que la défaillance d’une seule personne, qu’elle soit malveillante ou simplement négligente, ne suffit pas à compromettre une clé.

Supprimer l’intervention humaine du processus.
Le contrôle d’accès le plus efficace est celui qui élimine totalement toute manipulation humaine directe. Les clés générées et utilisées au sein d’un HSM ne sont jamais exportées en clair ; ainsi, les opérateurs autorisent les opérations sans jamais voir le matériel de clé, ce qui correspond exactement au type d’exposition qui a causé la perte de la Postbank. L’automatisation de l’enregistrement et de la rotation via des protocoles tels que ACME et EST élimine les points de contact manuels où les erreurs et les vols ont tendance à se produire. Toute action humaine restante doit être consignée dans une piste d’audit inviolable et attribuable à une personne spécifique, bouclant ainsi le cercle entre accès et responsabilité : une personne peut agir sur une clé, mais jamais de manière anonyme et jamais seule.

Cryptographie post-quantique

L'informatique quantique représente le prochain défi majeur pour la gestion des clés cryptographiques. Si la cryptographie post-quantique (PQC) et l'agilité cryptographique ont déjà été abordées en détail dans d'autres publications, leurs implications en matière de gestion des clés méritent une attention particulière.

La menace quantique qui pèse sur les clés.
Les ordinateurs quantiques finiront par venir à bout d’algorithmes asymétriques largement utilisés, tels que DH, RSA et ECC, rendant ainsi vulnérables les clés qui en dépendent. Cela signifie que chaque clé RSA et ECC figurant dans l’inventaire d’une organisation dispose d’une durée de fiabilité limitée.

Migration vers la cryptographie post-quantique (PQC).
La mise en place et le déploiement d’une cryptographie résistante à l’ère quantique constituent un défi considérable sur les plans scientifique, technologique, logistique et infrastructurel. Chaque étape doit être menée avec la plus grande prudence, car les conséquences d’une erreur peuvent être dévastatrices. La migration peut s’effectuer selon différentes stratégies, chacune d’entre elles nécessitant plusieurs étapes. Pour plus d’informations sur ce sujet, consultez la rubrique « Migration post-quantique ».

Élaboration d'une politique de gestion des clés cryptographiques

Maintenant que nous savons pourquoi la gestion des clés est un aspect essentiel pour garantir la sécurité des actifs cryptographiques d’une organisation, nous allons aborder la manière de la mettre en œuvre dans la pratique. Une gestion efficace des clés nécessite une gouvernance formelle. Les éléments suivants constituent les fondements d’une politique solide, fournissant les paramètres nécessaires à la mise en place et à la configuration de la gestion des clés cryptographiques.

Responsabilité en matière de clés et d'auditabilité.
La responsabilitédes clés et des certificats est souvent répartie au sein d'une organisation, les dirigeants se contentant de supposer quelles politiques s'appliquent. Une approche fragmentée de la gestion des clés n'est plus acceptable.

Contrôles d'accès et séparation des tâches.
Aucune personne ne devrait pouvoir générer, distribuer et utiliser des clés sans surveillance. Une séparation formelle des rôles réduit le risque lié aux menaces internes.

Répartir les décisions en fonction de l’objectif de chaque clé.
La politique doit trouver le juste équilibre entre confidentialité, intégrité et disponibilité, tout en gérant les tensions inhérentes à ces trois aspects. Elle doit ensuite tenir compte de l’objectif de chaque clé. Par exemple, il convient de sauvegarder les clés de confidentialité afin de ne jamais perdre les données, de ne jamais confier les clés de signature à un dépositaire afin de ne jamais compromettre l’intégrité, et d’assurer la disponibilité des deux types de clés grâce à la redondance (réplication HSM, quorum M-sur-N, chevauchement des renouvellements) plutôt qu’à des copies supplémentaires.

Applicationdes normes.
La politique doit recenser les clés qui ne respectent pas les normes en vigueur et les réglementations gouvernementales (telles que les directives NIST SP 800-57 ou les exigences PCI DSS), et doit également définir des délais de mise en conformité.

Exigences en matière d'audit et de conformité.
L'utilisation des clés et les métadonnées associées, notamment les dates de création, de validité et d'expiration, doivent être documentées afin de garantir la conformité réglementaire, notamment aux normes telles que NIST SP 800-57, PCI DSS, HIPAA et RGPD, selon le cas.

Centre d'excellence en cryptographie.
Certaines organisations centralisent la gouvernance des clés en mettant en place un centre d'excellence en cryptographie: il s'agit d'une équipe centrale, généralement placée sous la responsabilité d'un cadre dirigeant, chargée d'élaborer et de faire respecter les politiques et procédures cryptographiques à l'échelle de l'organisation. Cette équipe s'attache à déterminer quatre éléments : quelles sont les clés existantes et où elles se trouvent, comment elles sont utilisées par les systèmes et les applications, quelles clés ne répondent pas aux normes en vigueur, et comment appliquer les meilleures pratiques à l'ensemble des clés.

Alors que la législation continue d’encourager l’adoption de la cryptographie, le nombre de clés nécessaires pour assurer la sécurité des produits et des applications augmente rapidement. L’investissement dans la gestion des clés est, comme le souligne Chris Hickman, directeur de la sécurité Keyfactor, « une goutte d’eau dans l’océan par rapport au coût commercial, en termes d’image de marque et financier d’une violation ou d’une compromission ».

Mécanismes, artefacts et dispositifs destinés à protéger et à gérer le matériel de chiffrement

Une gestion efficace des clés repose sur un ensemble de hardware spécialisé, de contrôles d’accès et de registres opérationnels, dont la plupart restent invisibles jusqu’à ce qu’un dysfonctionnement survienne ou qu’un auditeur demande à les consulter. Les sections ci-dessous expliquent le rôle de chaque couche et, tout aussi important, présentent les éléments qui prouvent son bon fonctionnement, car en matière de gestion des clés, la différence entre « sécurisé » et « conforme » se résume généralement à ce que vous êtes en mesure de fournir sur demande.

Stockage et ressources de calcul sécurisés :

• HSM.
  Modèles connectés au réseau (Luna, nShield, CloudHSM), PCIe et portables/USB. Certifiés FIPS 140-2/3, dotés d'une protection contre les altérations. C'est là que sont générées et utilisées les clés non exportables.
• TPM, éléments sécurisés, TEE.
  Équivalents côté appareil pour l'identité et les clés hardware.
• Cloud KMS et magasins de clés externes.
  Services de gestion des clés, ainsi que les intégrations BYOK/HYOK et avec des gestionnaires de clés externes (EKM) lorsque vous souhaitez conserver la clé en dehors de l'environnement du fournisseur de cloud.
• Gestionnairesde secrets.
  Vault, gestionnaires de secrets dans le cloud, pour les secrets au porteur et les données à faible niveau de sécurité qui ne justifient pas l'utilisation d'un emplacement HSM.

Contrôle des accès et de la répartition :

• Quorum M sur N / Partage de secrets de Shamir.
  Pour les opérations sur la racine et l'autorisation HSM.
• Contrôle double et partage des connaissances.
  Aucune personne ne peut à elle seule générer, exporter ou activer une clé protégée.
• Séparation des fonctions par rôle.
  Responsable de la cryptographie, dépositaire des clés, opérateur et auditeur constituent des rôles distincts.

Interfaces et protocoles:

• KMIP.
  Interopérabilité de la gestion des clés entre le gestionnaire de clés et les modules HSM / clients.
• PKCS#11.
  L'interface de jeton à laquelle les applications font appel.
• Inscription etparcours :
  ACME, EST, SCEP, CMP.
• Révocation et statut :
  OCSP, CRL, ainsi que l'agrafage.

Identification et inventaire des clés cryptographiques

Avant qu'une organisation puisse gérer ses clés, il est recommandé de commencer par les recenser toutes. Deux approches complémentaires permettent d'y parvenir.

La découverte statique (SBOM/CBOM)consiste à analyser software et les nomenclatures cryptographiques afin de répertorier les composants cryptographiques intégrés dans les applications et les systèmes. Les réglementations européennes, telles que la loi sur la cybersécurité (CSA), exigeant de plus en plus des fournisseurs qu’ils fournissent des SBOM et des CBOM, cette approche est désormais considérée comme une bonne pratique de référence.

La découverte dynamique (basée sur le réseau)utilise des techniques telles que TLS et l'analyse des protocoles pour identifier les clés cryptographiques et les algorithmes activement utilisés sur le réseau. Cette approche met en évidence des risques que les inventaires statiques ne détectent pas : clés inactives, connexions non autorisées, software avec des terminaux inattendus, algorithmes faibles négociés lors TLS , et clés codées en dur intégrées dans des applications qui « contactent leur serveur d'origine » vers des serveurs externes.

Une grande entreprise pourrait constater que la majeure partie de son trafic réseau utilise TLS standard et correctement configurées, mais qu'un faible pourcentage de ce trafic mérite une analyse plus approfondie, susceptible de révéler des terminaux inattendus, des configurations vulnérables ou des comportements anormaux qui resteraient invisibles sans analyse dynamique.

La combinaison de ces deux approches de découverte offre la visibilité globale nécessaire à une gestion efficace des clés.

Gestion de la posture cryptographique

La gestion de la posture cryptographique consiste à évaluer et à améliorer en permanence le niveau global de préparation cryptographique d'une organisation. Elle intègre l'inventaire, la gestion des politiques et la gestion du cycle de vie au sein d'une boucle d'amélioration continue.

Visibilité sur l'ensemble du parc informatique. La gestion de la posture de sécurité de
offre une vue d'ensemble unifiée des actifs cryptographiques existants, de leur emplacement de déploiement et de leur configuration. La posture cryptographique est essentielle non seulement pour comprendre le fonctionnement interne des systèmes, mais aussi pour être bien préparé.

Données en transit et données au repos.
Chaque domaine nécessite des outils et des approches spécifiques. Les outils basés sur le réseau, tels que TLS , traitent les données en transit, tandis que software et l'analyse SBOM/CBOM concernent la cryptographie intégrée et les données au repos. Une stratégie complète de gestion de la posture de sécurité couvre ces deux aspects.

Conformité réglementaire.
Les réglementations européennes, notamment la CSA, exigent de plus en plus des organisations qu’elles démontrent leur niveau de sécurité cryptographique. Sans une gestion adéquate de ce niveau de sécurité, il devient nettement plus difficile d’atteindre et de maintenir la conformité.

Reconnaissance par les analystes.
Les analystes du secteur recommandent désormais la gestion de la posture cryptographique comme bonne pratique, ce qui montre que le marché a atteint un stade de maturité tel que l'évaluation cryptographique continue est désormais considérée comme une nécessité et non plus comme une option.

Se préparer à la cryptographie post-quantique

L'inventaire : une condition préalable.
Les organisations ne peuvent pas se préparer à la transition quantique sans savoir au préalable de quels actifs cryptographiques elles disposent et où ceux-ci sont déployés. Les pratiques de recensement et d'inventaire décrites plus haut dans ce guide revêtent une importance encore plus cruciale dans le contexte de la migration vers la cryptographie post-quantique (PQC). Il est essentiel de dresser un inventaire complet des actifs cryptographiques, tant pour se prémunir aujourd’hui contre les attaques actuelles que pour assurer la transition future vers des algorithmes résistants à l’informatique quantique.

C'est parti.
La transition vers la cryptographie post-quantique nécessite une planification dès aujourd'hui, avant même que les ordinateurs quantiques ne soient opérationnels. Les organisations devraient commencer à tester des algorithmes post-quantiques, à évaluer la vulnérabilité de leurs stocks de clés face à la cryptographie quantique et à mettre en place des architectures « crypto-agiles » qui permettront de remplacer rapidement les algorithmes lorsque les normes seront finalisées.

Comment Keyfactor vous aider

La plateforme Keyfactorrépond aux défis liés à la gestion des clés cryptographiques présentés dans ce guide grâce à une suite intégrée de solutions.

• Détection et inventaire des actifs cryptographiques automatise la découverte de tous les actifs cryptographiques au sein de l'entreprise, remplaçant les audits manuels par une visibilité en continu.
• PKI moderne assure la confiance et délivre des identités à grande échelle, servant ainsi de fondement aux architectures « zero-trust ».
• Automatisation du cycle de vie des certificats gère l'intégralité du cycle de vie des clés et des certificats, de leur émission à leur révocation en passant par leur rotation, éliminant ainsi les processus manuels.
• La gestion de la posture cryptographiqueoffre une vue d'ensemble des risques cryptographiques, des lacunes en matière de conformité et du niveau de préparation à l'ère quantique au sein de l'organisation.
• Bouncy Castle  et PQC Lab permettent aux organisations de tester et de se préparer dès aujourd’hui aux algorithmes post-quantiques, en jetant les bases d’une cryptographie agile, indispensables à la transition quantique.

Keyfactor la détection, la gestion du cycle de vie et la gestion de la conformité au sein d'une plateforme unique, remplaçant ainsi les processus manuels et fragmentés par une gestion automatisée et vérifiable des clés.

Principaux enseignements

• La gestion des clés cryptographiques est la discipline qui consiste à contrôler les clés tout au long de leur cycle de vie, depuis leur génération jusqu'à leur destruction.
• Une seule clé compromise peut coûter des dizaines de millions de dollars à une entreprise, comme l'a démontré la violation de données subie par Postbank.
• La plupart des organisations gèrent des dizaines de milliers de clés, mais ne savent pas exactement où elles se trouvent toutes.
• Une gestion efficace des clés nécessite l'inventaire des clés, l'automatisation de leur cycle de vie, une gouvernance formelle et une gestion continue de la posture de sécurité.
• Pour se préparer à la cryptographie post-quantique, il faut tout d'abord connaître son parc cryptographique actuel.
• Une approche basée sur une plateforme centralisée remplace les processus fragmentés et manuels par une gestion des clés automatisée et vérifiable.