Gestion des clés de chiffrement en entreprise : cycle de vie selon NIST SP 800-57, KMS, HSM, KMaaS et MPC comparés, et une grille d'évaluation en 15 points.
La gestion des clés de chiffrement en entreprise (enterprise key management) désigne la gestion centralisée des clés cryptographiques utilisées par les applications, les clouds et les services SaaS d'une organisation. Elle couvre la manière dont les clés sont générées, stockées, utilisées, renouvelées, révoquées et détruites, sous une seule politique et avec une seule piste d'audit. Un système de gestion des clés d'entreprise (EKMS) est le logiciel, et souvent le matériel, qui applique cette politique.
La plupart des organisations ne manquent pas de chiffrement. Ce qui leur manque, c'est le contrôle des clés qui se trouvent derrière. Les clés sont dispersées entre des services KMS cloud, des HSM, des « clés gérées par le client » dans les SaaS et des secrets applicatifs, chacun avec sa propre console, ses propres administrateurs et ses propres journaux. Lorsqu'un régulateur demande qui peut déchiffrer un jeu de données donné, la réponse est difficile à reconstituer.
Ce guide s'adresse aux architectes sécurité et aux RSSI qui doivent choisir comment gérer leurs clés en 2026. Il définit les termes (KMS, HSM, gestion des clés en tant que service, MPC), présente les composants d'un système de gestion des clés, décrit le cycle de vie des clés tel que le présente le NIST, compare KMaaS, HSM et KMS cloud, recense les standards qui comptent (PKCS#11, KMIP, FIPS 140-3) et se termine par une grille d'évaluation en 15 critères, un plan de déploiement et une FAQ.
Les clés résident généralement dans des services KMS cloud, des plateformes SaaS, des bases de données avec chiffrement transparent (TDE), des HSM sur site et des logiciels de coffre-fort (vault). Chacun constitue un magasin de clés distinct, avec son propre calendrier de rotation, son propre modèle d'accès et son propre format de journalisation. Les conséquences :
Le contrôle central de la gestion des clés est le suivant : la partie qui stocke vos données ne devrait pas être aussi la seule à contrôler la clé qui les déchiffre. Lorsqu'un fournisseur cloud ou SaaS génère et détient la clé dans son propre KMS, ses opérateurs, ses obligations légales et ses incidents font tous partie de votre modèle de menace. La gestion externe des clés, souvent appelée hold your own key (HYOK), place la clé hors du contrôle du fournisseur. Notre guide hold your own key (HYOK) présente ces modèles en détail.
Les régulateurs du secteur financier et des infrastructures critiques demandent de plus en plus aux entreprises de montrer comment les clés cryptographiques sont gouvernées, et pas seulement que les données sont chiffrées. Pour le détail, consultez nos guides sur les exigences de chiffrement de DORA, les exigences de chiffrement de NIS2 et la communication FINMA 05/2026 pour les banques suisses. Le fil conducteur : un cycle de vie des clés documenté, des accès restreints et journalisés, et la capacité de changer d'algorithme au fil de la migration vers la cryptographie post-quantique.
Un système de gestion des clés (KMS) génère les clés, les stocke ou en délègue le stockage à un HSM, contrôle qui peut les utiliser, exécute les opérations cryptographiques via une API et journalise chaque action. La publication NIST SP 800-130, A Framework for Designing Cryptographic Key Management Systems, décrit ce que la spécification d'un tel système doit couvrir : politique de sécurité, rôles, types de clés et métadonnées, fonctions de gestion, protection et reprise. Concrètement, la plupart des systèmes de gestion des clés d'entreprise reposent sur les huit mêmes briques.
| Composant | Rôle | Points à vérifier |
|---|---|---|
| Magasin de clés et racine de confiance | Détient le matériel de clé, ou la clé maîtresse qui le protège | HSM, fragments MPC, HSM cloud ou logiciel ; qui peut y accéder |
| Moteur de cycle de vie | Crée, active, renouvelle, suspend, révoque et détruit les clés | États explicites, cryptopériodes, versions |
| Politique et contrôle d'accès | Décide quel utilisateur, service ou workload peut utiliser quelle clé, pour quelle opération | RBAC, règles par attributs, double contrôle des actions destructrices |
| API cryptographique | Expose chiffrement, déchiffrement, encapsulation, signature et vérification | REST, PKCS#11, KMIP, latence par appel |
| Intégrations | Relie le KMS aux clouds, SaaS, bases de données, hyperviseurs et coffres-forts | Connecteurs natifs utilisables dès aujourd'hui |
| Audit et rapports | Enregistre chaque opération sur les clés et chaque action d'administration | Inviolabilité, export SIEM, durée de conservation |
| Disponibilité et reprise | Garde les clés utilisables en cas de panne d'un nœud, d'un site ou d'une région | Clustering, sauvegardes, restauration testée |
| Administration | Console, tenants, unités organisationnelles, automatisation | SSO et MFA pour les administrateurs, API, infrastructure as code |
La plupart des systèmes reposent aussi sur le chiffrement par enveloppe : les données sont chiffrées avec une clé de chiffrement de données (DEK), elle-même encapsulée par une clé de chiffrement de clés (KEK) conservée dans le KMS ou le HSM. Qui contrôle la KEK contrôle toutes les DEK qui en dépendent ; c'est pourquoi la gestion externe des clés porte d'abord sur la KEK.
La référence sur laquelle s'appuient la plupart des auditeurs et des référentiels est la publication spéciale NIST 800-57 Part 1 Revision 5, Recommendation for Key Management: Part 1 – General (mai 2020). Elle donne des orientations générales sur les types de clés, la protection requise pour chacun et les fonctions de gestion des clés qui s'y rapportent.
SP 800-57 divise le cycle de vie de la gestion des clés en quatre phases et place chaque clé dans l'un de six états :
| Phase | Ce qui se passe | États de la clé |
|---|---|---|
| Pré-opérationnelle | Matériel de clé pas encore disponible pour un usage normal ; clé générée ou en attente d'activation | Pré-activation |
| Opérationnelle | Clé disponible et en usage normal | Active, Suspendue |
| Post-opérationnelle | Plus en usage normal, mais encore accessible pour traiter des données déjà protégées (p. ex. déchiffrer, vérifier) ; peut être archivée | Désactivée, Compromise |
| Détruite | Clé plus disponible ; les métadonnées peuvent être conservées | Détruite |
Deux détails comptent pour la conception : une clé suspendue peut traiter des données (par exemple déchiffrer) mais pas appliquer une nouvelle protection, et après destruction, les métadonnées de la clé (nom, type, cryptopériode, période d'utilisation) peuvent être conservées comme preuve.
Au quotidien, un système de gestion des clés d'entreprise exécute ces opérations :
Le NIST définit la cryptopériode comme la durée pendant laquelle une clé donnée est autorisée à être utilisée. Une cryptopériode adaptée limite la quantité de données exposées en cas de compromission d'une clé, la quantité de matériel disponible pour la cryptanalyse et le temps dont dispose un attaquant pour contourner les contrôles qui protègent la clé. Si une clé est compromise, sa cryptopériode n'est plus valable.
SP 800-57 énumère les facteurs qui doivent déterminer la durée d'une cryptopériode, notamment la robustesse de l'algorithme et la longueur de clé, la manière dont le mécanisme est implémenté (par exemple un module matériel par opposition à un logiciel sur un PC), l'environnement d'exploitation, la rotation du personnel, le volume de données, la durée de vie sécuritaire des données et la méthode de renouvellement des clés. La publication propose aussi des cryptopériodes indicatives par type de clé ; utilisez ces valeurs tirées de la publication elle-même plutôt que des règles empiriques.
Ce que cela implique pour un système de gestion des clés d'entreprise : il doit modéliser les états explicitement (pas seulement « activé/désactivé »), appliquer des cryptopériodes par type de clé, garder les clés utilisables pour le déchiffrement une fois qu'elles ne servent plus au chiffrement, et conserver les preuves de destruction.
En résumé, KMS ou HSM, c'est politique et cycle de vie d'un côté, stockage et exécution sécurisés de l'autre. La plupart des entreprises ont besoin des deux fonctions ; la question est de savoir qui exploite chacune, et où se situe la confiance.
Les trois options que les acheteurs comparent le plus souvent répondent à des questions différentes. Un HSM répond à « où la clé est-elle protégée physiquement ? ». Un KMS cloud répond à « comment chiffrer dans ce cloud avec peu d'effort ? ». La gestion des clés en tant que service répond à « comment appliquer une seule politique de clés à plusieurs clouds et SaaS sans exploiter la plateforme moi-même ? ».
| HSM sur site ou cloud | KMS du fournisseur cloud | KMaaS indépendant | |
|---|---|---|---|
| Rôle principal | Stockage matériel des clés et opérations cryptographiques | Chiffrement des services de ce fournisseur | Cycle de vie, politique et audit sur plusieurs fournisseurs |
| Périmètre | Applications qui l'appellent (PKCS#11, JCE, CNG) | Un seul cloud | Plusieurs clouds, SaaS, bases de données, sur site |
| Clé détenue par | Vous, sur du matériel hébergé par vous ou par le fournisseur | Le fournisseur, selon votre politique IAM | Le KMaaS, hors du fournisseur qui stocke les données |
| Exploitation | Votre équipe (ou le fournisseur pour le matériel) | Le fournisseur | L'éditeur ; vous gardez la politique |
| Séparation d'avec le détenteur des données | Oui, si sur site | Non | Oui |
| Principaux postes de coût | Matériel, paires HA, spécialistes, renouvellement | Par clé et par requête | Abonnement, clés, intégrations |
| Adapté quand | Une exigence impose un périmètre matériel validé, ou des applications ont besoin d'un HSM local | Données et workloads restent dans un cloud et la garde par le fournisseur est acceptable | Les clés doivent rester hors des clouds et SaaS qui détiennent les données, avec une seule piste d'audit |
Ces modèles se combinent. Un KMaaS peut utiliser des HSM ou le MPC comme magasin de clés, et alimenter les KMS cloud ou répondre à leurs requêtes via des interfaces BYOK et HYOK. Une architecture cible fréquente en 2026 : KMS natif du cloud pour les workloads peu sensibles, KMS externe ou KMaaS pour les données réglementées, avec une garde HSM ou MPC en dessous.
Pour une vue du marché fournisseur par fournisseur, consultez notre guide d'achat KMS. Pour des comparatifs directs, voyez DuoKey vs Thales CipherTrust et DuoKey vs Entrust.
Le niveau de contrôle que vous gardez sur une clé cloud ou SaaS se range en trois niveaux :
Un système de gestion des clés d'entreprise doit couvrir les trois, car vous utiliserez les trois : clés gérées par le fournisseur pour les données peu sensibles, BYOK là où le fournisseur ne propose que l'import, HYOK pour les données qui doivent rester hors de portée du fournisseur.
| Modèle | Qui assure la garde | Qui peut techniquement accéder aux clés | Coût d'exploitation | Disponibilité | Preuves de conformité |
|---|---|---|---|---|---|
| HSM sur site | Vous | Vos administrateurs HSM | Élevé : matériel, centre de données, personnel spécialisé, cycles de renouvellement | Vous concevez la haute disponibilité (clusters, sites) | Preuves matérielles solides ; journaux de cycle de vie et d'accès à construire vous-même |
| HSM cloud | Vous, sur le matériel du fournisseur | Vos utilisateurs de partition ; le fournisseur exploite le matériel | Moyen à élevé : tarification par HSM, vous gérez le clustering et les opérations sur les clés | SLA du fournisseur plus votre conception de cluster | Preuves matérielles disponibles ; le fournisseur fait partie de la chaîne de confiance |
| KMS du fournisseur cloud | Le fournisseur, selon vos politiques | Service géré par le fournisseur ; vous contrôlez la politique IAM | Faible : tarification par clé et par requête | SLA du fournisseur, élevé | Bons journaux natifs, mais par cloud ; le fournisseur détient la clé |
| KMS externe / indépendant (exploité en interne) | Vous | Vos opérateurs KMS | Moyen à élevé : vous exploitez le logiciel, la haute disponibilité et les sauvegardes | Vous concevez la haute disponibilité | Cycle de vie et piste d'audit uniques pour tous les clouds, si les intégrations existent |
| KMaaS (indépendant) | Vous (politique), le fournisseur exploite le service | Selon la conception : les opérateurs du fournisseur peuvent ou non atteindre le matériel de clé | Faible à moyen : abonnement | SLA du fournisseur | Audit central sur les clouds et les SaaS ; vérifiez ce que le fournisseur peut voir |
| KMS basé sur le MPC | Partagée entre des fragments indépendants | Aucun opérateur ni hôte ne détient à lui seul une clé complète | Faible à moyen en tant que service | La conception à seuil tolère la perte de certains nœuds | Audit central ; la preuve de garde repose sur la séparation des parts |
Lisez ce tableau à travers la question que posent les régulateurs : qui pourrait déchiffrer vos données à votre insu ? Avec le KMS d'un fournisseur cloud, la réponse inclut le fournisseur ; avec le MPC, un attaquant ou un initié doit compromettre plusieurs fragments indépendants, et non un seul.
Exemple de clés externes dans un cloud : un magasin de clés externe AWS KMS (XKS) s'appuie sur un gestionnaire de clés externe que vous possédez hors d'AWS ; AWS KMS ne communique avec lui que via un proxy de magasin de clés externe, « cannot create, view, manage, or delete your keys », et utilise un double chiffrement afin que ni AWS KMS ni le détenteur de la clé externe ne puissent déchiffrer seuls. AWS est aussi clair sur la contrepartie : vous assumez la responsabilité de la disponibilité, de la durabilité et de la latence des opérations sur les clés.
Un KMS d'entreprise ne vaut que par les systèmes auxquels il peut se connecter. Trois familles d'interfaces couvrent l'essentiel du parc.
PKCS#11 (Cryptoki) est l'API de niveau C qu'utilisent les applications, les bases de données, les serveurs web et les logiciels de coffre-fort pour communiquer avec un HSM ou un jeton de type HSM. Elle est maintenue par OASIS ; la version actuelle, PKCS #11 Specification Version 3.2, est devenue un standard OASIS le 3 juin 2026. Lorsqu'un produit annonce une « intégration HSM », il s'agit généralement de PKCS#11.
Le Key Management Interoperability Protocol est un protocole réseau entre les serveurs de gestion des clés et leurs clients (baies de stockage, bases de données, systèmes de sauvegarde, hyperviseurs). KMIP Specification Version 2.1 est un standard OASIS depuis le 14 décembre 2020. C'est dans KMIP que les opérations de cycle de vie des clés (create, register, locate, activate, revoke, destroy) sont standardisées entre fournisseurs. VMware vCenter, par exemple, utilise un fournisseur de clés KMIP pour le chiffrement des VM et de vSAN.
Les hyperscalers, les éditeurs SaaS et les bases de données exposent leurs propres mécanismes de clés externes : AWS XKS, Microsoft 365 Double Key Encryption et Customer Key, Snowflake Tri-Secret Secure, Oracle TDE, SQL Server EKM. Ces interfaces sont propriétaires ; le test pratique pour un KMS d'entreprise est donc la liste des intégrations qu'il propose déjà.
FIPS 140-3, Security Requirements for Cryptographic Modules (publiée le 22 mars 2019), définit quatre niveaux de sécurité qualitatifs croissants pour les modules cryptographiques et s'aligne sur ISO/IEC 19790:2012. Les modules sont validés dans le cadre du Cryptographic Module Validation Program (CMVP), géré conjointement par le NIST et le Centre canadien pour la cybersécurité ; des laboratoires accrédités testent le module, puis le CMVP examine et valide le résultat.
Trois points pratiques pour les acheteurs :
Dans un HSM, la clé complète existe à l'intérieur d'un seul périmètre résistant à l'effraction. Ce périmètre est solide, mais il constitue un point de confiance unique : quiconque contrôle l'équipement, ses administrateurs ou les identifiants de sa partition contrôle la clé.
Le calcul multipartite supprime ce point unique. Chaque clé est divisée en parts détenues par des nœuds indépendants. La signature ou le déchiffrement sont calculés conjointement à partir des parts, et la clé complète n'est jamais reconstituée. Dans un schéma à seuil, un nombre défini de parts doit coopérer pour toute opération, ce qui apporte deux propriétés à la fois :
MPC et HSM ne s'excluent pas : les parts peuvent elles-mêmes être protégées par des HSM, et les HSM restent la bonne réponse lorsqu'une exigence impose un périmètre matériel validé. Pour une comparaison détaillée de l'architecture de sécurité, des performances et des coûts, consultez MPC ou HSM pour la gestion des clés.
| # | Critère | Question à poser |
|---|---|---|
| 1 | Modèle de garde | Qui peut techniquement utiliser ou exporter une clé complète : vous, le fournisseur, le fournisseur cloud ? |
| 2 | Séparation d'avec les détenteurs des données | La clé est-elle détenue hors du fournisseur qui stocke les données (HYOK) ? |
| 3 | Intégrations | Quels clouds, plateformes SaaS et bases de données sont pris en charge aujourd'hui, et non sur la feuille de route ? |
| 4 | Interfaces standard | Bibliothèque PKCS#11 ? Version du serveur KMIP ? |
| 5 | Modèle de cycle de vie | Les états de SP 800-57 (pré-activation, active, suspendue, désactivée, compromise, détruite) sont-ils représentés ? Les cryptopériodes sont-elles appliquées ? |
| 6 | Rotation sans interruption | Les clés peuvent-elles être renouvelées pendant que les anciennes versions déchiffrent encore les données existantes ? |
| 7 | Audit | Chaque opération est-elle journalisée de manière centralisée, inviolable et exportable vers votre SIEM ? |
| 8 | Contrôle d'accès | RBAC uniquement, ou aussi des politiques fondées sur les attributs (ABAC) ? Double contrôle pour les actions destructrices ? |
| 9 | Multi-tenant | Les unités métier, filiales ou clients sont-ils isolés par tenant ? |
| 10 | Haute disponibilité | Que se passe-t-il si un nœud, une région ou le fournisseur est indisponible ? Quel est le SLA documenté ? |
| 11 | Latence | Quelle est la latence ajoutée par opération, pour les services qui l'appellent de manière synchrone ? |
| 12 | Préparation post-quantique | Peut-il gérer des clés ML-KEM et ML-DSA et des modes hybrides, et changer d'algorithme par politique ? |
| 13 | Assurance matérielle | Quels backends détiennent les clés, et lesquels disposent d'un certificat FIPS 140-3 en cours de validité ? |
| 14 | Sortie et portabilité | Pouvez-vous exporter, ré-encapsuler ou migrer les clés si vous changez de fournisseur ? |
| 15 | Modèle tarifaire | Par clé, par opération, par intégration ou forfaitaire ? Comment le coût évolue-t-il avec la prolifération des clés ? |
Le critère 12 mérite une attention particulière en 2026. L'encapsulation de clés post-quantique modifie la taille et le traitement des clés ; notre guide de gestion des clés ML-KEM explique ce qui change en pratique. Pour transformer ces critères en appel d'offres, utilisez notre modèle d'appel d'offres KMS.
La gestion des clés d'entreprise se déploie rarement d'un seul coup. Les organisations qui vont au bout procèdent en général système par système.
DuoKey repose sur une idée : aucun fournisseur cloud, aucun opérateur et aucun hôte compromis ne devrait détenir une clé complète.
Pour tout ce qui n'est pas mentionné ici, comme des certifications particulières ou les tarifs, contactez directement DuoKey.
Q: Qu'est-ce que la gestion des clés de chiffrement en entreprise ?
La gestion des clés de chiffrement en entreprise est la gestion centralisée des clés cryptographiques utilisées par les applications, les clouds et les services SaaS d'une organisation. Elle couvre la génération, le stockage, l'utilisation, la rotation, la révocation et la destruction des clés sous une seule politique et une seule piste d'audit, au lieu d'une console distincte par fournisseur.
Q: Qu'est-ce qu'un système de gestion des clés (KMS) ?
Un système de gestion des clés est le logiciel, souvent adossé à du matériel, qui génère les clés, les stocke ou en délègue le stockage à un HSM, contrôle qui peut les utiliser, exécute les opérations cryptographiques via une API et journalise chaque action. Les KMS cloud sont des systèmes de gestion des clés limités à un seul cloud ; un KMS d'entreprise couvre l'ensemble du parc.
Q: Qu'est-ce que la gestion des clés en tant que service (KMaaS) ?
La gestion des clés en tant que service est un système de gestion des clés fourni sous forme de service managé : le fournisseur assure la disponibilité, la montée en charge et les correctifs, et vous gardez le contrôle de la politique des clés. Le KMS d'un fournisseur cloud en est une forme ; un KMaaS indépendant fonctionne en dehors du fournisseur cloud ou SaaS dont il protège les données, ce qui maintient la clé séparée des données.
Q: KMS ou HSM : quelle est la différence ?
Un KMS gère le cycle de vie et la politique d'accès des clés à travers les systèmes et les expose via des API. Un HSM est un équipement résistant à l'effraction qui stocke les clés et exécute les opérations cryptographiques à l'intérieur d'un périmètre matériel. De nombreux déploiements KMS utilisent un HSM comme backend de stockage : les deux sont complémentaires.
Q: Quelle est la différence entre BYOK et HYOK ?
Avec le BYOK, vous créez la clé dans votre propre KMS ou HSM et l'importez dans le KMS du fournisseur, qui en détient donc une copie pendant son utilisation. Avec le HYOK, la clé reste dans votre KMS externe et le fournisseur doit l'appeler à chaque opération : révoquer l'accès dans votre KMS arrête le déchiffrement.
Q: Qu'est-ce que la gestion des clés par MPC ?
La gestion des clés par MPC divise chaque clé en parts détenues par des nœuds indépendants et calcule les opérations cryptographiques conjointement, de sorte que la clé complète n'est jamais assemblée en un seul endroit. Compromettre un nœud, un opérateur ou un compte cloud ne donne à un attaquant qu'une part, pas une clé utilisable.
Q: Que dit le NIST sur le cycle de vie des clés ?
NIST SP 800-57 Part 1 Rev. 5 divise le cycle de vie en phases pré-opérationnelle, opérationnelle, post-opérationnelle et de destruction, les clés se trouvant dans les états pré-activation, active, suspendue, désactivée, compromise ou détruite. Elle définit aussi les cryptopériodes, c'est-à-dire la durée pendant laquelle une clé est autorisée à être utilisée, ainsi que les facteurs qui doivent les déterminer.
Q: FIPS 140-2 est-il encore valable en 2026 ?
Le CMVP indique que les validations FIPS 140-2 passent sur la liste Historical après le 21 septembre 2026 ; ensuite, les agences ne peuvent continuer à utiliser ces modules que dans des systèmes existants. Les nouveaux achats doivent exiger des certificats FIPS 140-3.
Q: Que sont PKCS#11 et KMIP ?
PKCS#11 est l'API maintenue par OASIS qu'utilisent les applications pour communiquer avec les HSM et les jetons de type HSM ; la version 3.2 est devenue un standard OASIS en juin 2026. KMIP est le protocole OASIS entre les serveurs de clés et leurs clients, comme le stockage et les bases de données ; la version 2.1 est un standard OASIS depuis décembre 2020.
Q: Ai-je encore besoin d'un HSM si j'utilise un KMS basé sur le MPC ?
Pas toujours. Le MPC supprime le point de confiance unique que représente un HSM, mais certaines exigences imposent un périmètre matériel validé. De nombreuses organisations combinent les deux : le MPC pour une garde distribuée et des coffres adossés à des HSM là où une validation matérielle est requise.
La gestion des clés de chiffrement en entreprise, c'est un cycle de vie, un modèle d'accès et une piste d'audit uniques pour tous les magasins de clés que vous possédez déjà, sans qu'aucun fournisseur, opérateur ou hôte ne puisse déchiffrer seul vos données.
Écrit par
DuoKey Team
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
