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), décrit le cycle de vie des clés tel que le présente le NIST, compare six modèles de déploiement, recense les standards qui comptent (PKCS#11, KMIP, FIPS 140-3) et se termine par une grille d'évaluation en 15 critères.
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.
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.
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.
| 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). 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.
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.
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 les régions de déploiement, les certifications 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 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: 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.
