Exploiter les clés : rotation, KMS et secrets

Exploiter les clés : rotation, KMS et secrets

Une clé cryptographique n’est pas un simple secret à cacher dans un coffre. C’est un actif de production avec un cycle de vie, des dépendances applicatives, des sauvegardes, des droits d’usage et une capacité de destruction qui doivent être conçus avant le premier chiffrement. Le compromis central est brutal : plus la clé est protégée et isolée, plus son exploitation devient coûteuse, lente et dépendante de l’infrastructure. Pour les clés qui protègent des données métier ou des identités, ce coût est justifié. Pour un jeton de test éphémère, non.

Explication de la marmotte

Les clés numériques ressemblent aux clés d’un immeuble : certaines ouvrent une boîte aux lettres, d’autres une porte technique, d’autres encore presque tout le bâtiment. Les ranger, les remplacer et savoir quoi faire après un vol évite qu’un incident banal devienne une catastrophe durable. Le vrai sujet est de garder le contrôle sans empêcher les occupants légitimes de travailler.

→ Lire l’explication complète de la marmotte

Poser les prérequis avant de créer une clé

Un système de gestion de clés, ou Key Management Service (KMS), ne remplace pas une architecture de sécurité. Il fournit des opérations cryptographiques, une journalisation et des contrôles d’accès autour de clés maîtresses. Il faut donc disposer avant son adoption d’une identité de charge de travail non partagée, d’une journalisation centralisée, d’une horloge synchronisée et d’un modèle d’autorisation capable de distinguer lecture de données, chiffrement, déchiffrement, administration et audit.

Le KMS doit être accessible depuis les environnements qui chiffrent ou déchiffrent. Cette dépendance devient vite structurante. Une application incapable de joindre son KMS ne peut souvent plus démarrer, traiter une requête ou restaurer une sauvegarde. Il faut définir explicitement si l’indisponibilité du KMS bloque le trafic, si une clé de données déjà obtenue reste utilisable temporairement, et combien de temps. Un cache local de clés peut absorber une panne courte, mais agrandit la fenêtre d’exposition après compromission ou révocation.

Les bibliothèques cryptographiques doivent supporter des primitives modernes et des formats stables. Pour chiffrer des données applicatives, utiliser un chiffrement authentifié tel qu’Advanced Encryption Standard Galois/Counter Mode (AES-GCM) ou ChaCha20-Poly1305. Un chiffrement sans authentification laisse l’attaquant modifier les données sans connaître la clé. Le chiffrement ne remplace ni le contrôle d’accès, ni la validation métier, ni l’intégrité d’une base de données. La frontière entre ces garanties est détaillée dans chiffrer et authentifier avec une seule primitive.

Enfin, inventorier les consommateurs avant toute migration. Une clé de base de données, une clé de signature, une clé de chiffrement de sauvegarde et un mot de passe d’API n’ont ni le même usage, ni la même rotation, ni la même procédure de reprise. Les classer dans le même coffre sans métadonnées revient à préparer un incident où personne ne sait ce qui peut être coupé.

Séparer clés de données, clés maîtresses et secrets applicatifs

L’architecture recommandée pour les données volumineuses est l’envelope encryption, ou chiffrement par enveloppe. Une clé de données, souvent appelée Data Encryption Key (DEK), chiffre un objet, un fichier ou un petit lot homogène. Cette DEK est ensuite chiffrée par une clé de chiffrement de clé, ou Key Encryption Key (KEK), conservée dans le KMS ou dans un Hardware Security Module (HSM), module cryptographique matériel.

Cette séparation est le bon compromis dans presque tous les cas. Le KMS protège les clés les plus sensibles et contrôle leur utilisation, tandis que le chiffrement des données reste local et performant. Demander au KMS de chiffrer chaque bloc d’un fichier ou chaque ligne d’une table transforme rapidement la latence réseau et les quotas de service en problème de production. Le matériel cryptographique est précieux, pas magique, et surtout pas gratuit en temps de réponse.

Chaque objet chiffré doit conserver avec son contenu chiffré au minimum : l’identifiant de l’algorithme, l’identifiant de la KEK, la version de clé, la DEK chiffrée, le vecteur d’initialisation et les données authentifiées associées. Ces données associées lient le chiffrement à son contexte, par exemple l’identifiant du locataire, le type d’objet et son chemin logique. Elles empêchent de déplacer un contenu chiffré d’un compte à un autre sans provoquer d’échec de déchiffrement.

Avec AES-GCM, un vecteur d’initialisation ne doit jamais être réutilisé avec la même DEK. La réutilisation d’un couple clé et vecteur peut divulguer des relations entre messages et permettre des falsifications. Un générateur aléatoire fiable convient si le volume reste dans les limites documentées de l’algorithme. Pour des débits élevés, préférer un compteur persistant ou une DEK par objet. Le compteur doit survivre à une restauration et être partagé entre nœuds actifs, sinon l’architecture actif-actif fabrique des collisions avec beaucoup d’enthousiasme.

Choisir le bon emplacement de stockage

Un gestionnaire de secrets stocke des valeurs récupérables : mots de passe, jetons, certificats, chaînes de connexion et parfois clés privées. Il répond au besoin de distribution contrôlée de secrets aux applications. Il ne devient pas un KMS parce qu’on y dépose une clé AES dans un champ texte. Si le secret sort en clair vers chaque charge de travail, l’application porte toute la responsabilité de sa protection en mémoire, dans ses journaux et dans ses dumps de diagnostic.

Le KMS convient aux clés de chiffrement et de signature dont l’usage doit être autorisé, journalisé et limité. Les KMS managés utilisent généralement des HSM en arrière-plan, mais cette présence ne signifie pas que les équipes contrôlent le matériel, les domaines d’administration ou la procédure de récupération. Un HSM dédié devient pertinent lorsqu’une exigence impose une frontière matérielle maîtrisée, une certification donnée, la conservation locale des clés ou la séparation forte entre opérateurs.

Un Trusted Platform Module (TPM) ancre des secrets sur une machine et peut conditionner leur usage à l’état de démarrage. Il protège bien une clé de nœud, moins une clé partagée par un cluster. Une enclave matérielle protège certaines opérations dans une zone isolée du processeur, mais ne corrige ni un contrôle d’accès trop large ni une application qui expose le texte en clair avant l’appel. Les cartes à puce sont adaptées à l’authentification humaine ou à la signature individuelle, pas au chiffrement transactionnel d’un service à forte charge.

Le fichier local reste acceptable pour une clé de développement sans données réelles, ou pour une clé de démarrage protégée par le système d’exploitation dans un environnement très contraint. En production, un fichier de clé déployé avec l’application est une dette de sécurité : les sauvegardes, images de conteneur, volumes persistants et outils de support finissent par le recopier. Les principes de gouvernance cryptographique et d’inventaire doivent couvrir ces copies, y compris celles que personne ne pense posséder.

Tourner sans perdre la capacité de lire

La rotation n’est pas la révocation. Tourner une clé signifie créer une nouvelle version pour les nouveaux chiffrement ou signatures, tout en maintenant les anciennes versions disponibles pour relire l’historique. Révoquer une clé signifie interdire son usage parce que son intégrité, sa confidentialité ou son autorisation d’emploi n’est plus crédible. Une rotation planifiée préserve la continuité. Une révocation peut imposer un arrêt, un rechiffrement d’urgence ou la perte définitive de données si aucune solution n’existe.

La rotation d’une KEK est simple quand les DEK sont conservées chiffrées : il suffit de déchiffrer chaque DEK avec l’ancienne KEK puis de la rechiffrer avec la nouvelle. Les données métier ne changent pas. Cette opération de rewrapping est nettement moins coûteuse qu’un rechiffrement complet et limite les risques de corruption. En revanche, la compromission d’une DEK impose de rechiffrer toutes les données protégées par cette DEK, car leur contenu peut déjà avoir été lu.

Une migration sûre fonctionne en double lecture : écrire exclusivement avec la nouvelle version, lire avec la version indiquée dans les métadonnées, puis retraiter progressivement les objets anciens. Ne jamais supposer qu’une rotation automatique du fournisseur rechiffre les données existantes. Elle change souvent seulement la clé qui protège les nouvelles DEK ou les nouvelles versions de ressources managées.

La désactivation d’une ancienne clé doit être précédée d’une recherche mesurable des références restantes. Il faut compter les objets par version, simuler une lecture de sauvegarde et attendre la fin des délais de rétention applicatifs avant destruction. Détruire une clé sans effacer ses copies de sauvegarde ne la détruit pas réellement. Inversement, supprimer la dernière clé capable de déchiffrer une sauvegarde transforme cette sauvegarde en archive décorative.

Préparer compromission, sauvegarde et reprise

Une compromission de clé n’est pas toujours détectable. Les journaux du KMS indiquent qu’une opération a eu lieu, pas que l’appelant était légitime au sens métier. Une identité de charge de travail volée utilisera la clé avec des autorisations parfaitement valides. Il faut donc corréler les opérations cryptographiques avec le contexte applicatif : volume inhabituel de déchiffrements, accès depuis un environnement inattendu, changement de politique, export de secret ou échec répété d’authentification.

Le runbook d’incident doit distinguer quatre cas : exposition d’une DEK, exposition d’une KEK, compromission d’une identité autorisée et perte d’accès au KMS. Dans le premier cas, rechiffrer les données concernées. Dans le second, geler les nouveaux usages, créer une KEK de remplacement, rewrapper les DEK et évaluer les journaux historiques. Dans le troisième, révoquer l’identité avant de tourner les clés : tourner sans couper l’attaquant lui donne simplement accès aux nouvelles versions. Dans le dernier, activer les procédures de reprise du KMS et vérifier les dépendances applicatives avant toute restauration.

Les sauvegardes de clés privées, notamment de clés de signature ou de clés gérées dans un HSM, exigent une cérémonie documentée : chiffrement sous une clé distincte, contrôle à plusieurs personnes, stockage séparé et test de restauration. L’escrow, ou dépôt de clé permettant à un tiers de récupérer une clé, n’est pas une sauvegarde. Il introduit un détenteur supplémentaire, donc une surface d’attaque et une obligation de gouvernance. Il ne doit jamais servir de raccourci pour contourner la séparation des privilèges.

La supervision doit couvrir l’expiration des certificats, l’échec des opérations KMS, les changements de politiques, les suppressions de versions, la saturation de quotas et la dérive des droits. Les clés de signature méritent une attention spécifique : leur rotation impose de publier la nouvelle clé publique avant de signer avec la nouvelle clé privée, puis de maintenir l’ancienne clé publique pendant la durée de validité des signatures. Les mécanismes et limites sont développés dans signer comme preuve publique.

HSM et KMS

répondent à deux questions différentes : où les clés sont-elles physiquement protégées, et qui orchestre leur cycle de vie.

HSM (Hardware Security Module). C’est la brique matérielle (ou virtuelle certifiée), la racine de confiance. Les clés privées ou secrètes n’en sortent jamais en clair : toutes les opérations cryptographiques (chiffrement, signature, wrap/unwrap) s’exécutent dans son enceinte. Certifié FIPS 140-2/3 ou Critères Communs, il protège contre l’extraction physique et logique. C’est un composant d’exécution, pas un outil de gestion de flotte de clés : pas de rotation orchestrée nativement, pas de versioning avancé, pas de politique d’accès granulaire par défaut. Exemples : Thales Trustway/Proteccio, Utimaco, SafeNet Luna.

KMS (Key Management Service/System). C’est la couche d’orchestration du cycle de vie : génération, rotation, versioning, contrôle d’accès (IAM), journalisation et audit, distribution des clés aux applications via API. Un KMS peut être purement logiciel (moins robuste) ou, cas le plus solide, adossé à un ou plusieurs HSM en interne pour la partie stockage et exécution sensible. AWS KMS, Azure Key Vault (palier Premium adossé à un HSM), GCP Cloud KMS ou HashiCorp Vault (avec plugin HSM) appartiennent tous à cette catégorie : l’API abstrait le HSM sous-jacent.

Le rapport entre les deux : le HSM est un moyen d’exécution, le KMS une couche de service qui peut s’appuyer sur un ou plusieurs HSM. Un KMS sans HSM en dessous n’offre que des garanties logicielles. Un HSM sans KMS par-dessus fonctionne, mais le cycle de vie des clés se gère alors à la main.

🐝 Ce qui arrive si on s’en passe

Sans cycle de vie des clés, la porte reste ouverte et personne ne compte ce qui entre. Une clé unique et sans version chiffre tout : la moindre fuite oblige à rechiffrer l’intégralité du parc, sans moyen de délimiter la période exposée. Faute de métadonnées stockées avec l’objet (identifiant d’algorithme, version, données authentifiées associées), un contenu chiffré redevient déchiffrable après avoir été recopié d’un locataire vers un autre, et un changement de bibliothèque rend l’historique illisible. Sans journalisation corrélée des opérations, un déchiffrement massif par une identité volée passe pour du trafic normal : aucune alerte, aucune borne temporelle pour la notification. Sans test de restauration, la suppression d’une version laisse des sauvegardes que plus aucune clé n’ouvre, et la reprise se découvre le jour de l’incident.

🦫 Explication de la marmotte 🍫

Une clé cryptographique est une information secrète utilisée pour protéger ou vérifier des données. Avant de l’utiliser, il faut décider qui peut demander son emploi, où elle sera conservée, comment ses utilisations seront enregistrées et comment récupérer le service après une panne.

Pour chiffrer un document, l’application crée généralement une petite clé propre à ce document. Cette clé chiffre le contenu. Elle est ensuite protégée par une autre clé, plus importante, conservée dans un service spécialisé ou dans un matériel conçu pour empêcher son extraction. L’application stocke le document chiffré avec les informations nécessaires pour retrouver la bonne clé et vérifier que le contenu n’a pas été modifié.

Quand une clé doit être remplacée, les nouveaux documents utilisent la nouvelle version. Les anciens restent lisibles grâce à l’ancienne version pendant une période contrôlée. Pour certaines clés, il suffit de protéger à nouveau les petites clés sans rechiffrer tous les documents. Si une petite clé est volée, les documents concernés doivent être chiffrés de nouveau.

Si une clé importante ou une identité autorisée est compromise, il faut d’abord empêcher l’accès suspect, puis remplacer les clés et traiter les données exposées. Les sauvegardes doivent être testées : une sauvegarde inutilisable ne protège rien. Enfin, supprimer une clé rend les données impossibles à lire si aucune autre copie légitime ne subsiste.

À lire aussi

• Que protège réellement le chiffrement au reposLe chiffrement au repos protège les données volées hors de leur système d’exécution, mais ne remplace ni le contrôle d’accès ni la gestion des clés.
• Envelope encryptionPoint d'ancrage editorial pour expliquer le chiffrement par enveloppe et son role dans les architectures modernes.
• Chiffrement au niveau champ dans une base de donnéesMettre en œuvre un chiffrement au niveau champ pour protéger des colonnes sensibles, avec ses compromis de recherche, performance et exploitation.
• Protéger les données au repos : disque, base, sauvegardeCouvrir le stockage chiffré depuis le disque jusqu’au champ applicatif, en incluant bases de données, archives, sauvegardes, recherche et enveloppe de chiffrement.

Pages voisines

La citent

• Choisir, combiner et migrer les algorithmes symétriques
• Créer, vérifier et utiliser les clés dès le départ
• KEK vs DEK
• Protéger une information en environnement hostile
• Rotation des cles
• Tester, auditer, répondre et migrer
• Transformer mots de passe et secrets applicatifs en clés

Exploiter les clés : rotation, KMS et secrets

Elle cite

• Gouverner la cryptographie: inventaire, agilité et conformité
• Chiffrer et authentifier en une seule construction
• HSM cloud ou on-premise pour les clés critiques
• Signer numériquement : preuve publique, politiques de vérification
• Attestation distante TPM et démarrage mesuré