Le chiffrement des secrets : enveloppe, HSM et KMS

Chiffrer un secret, c'est le transformer en une suite de caractères illisibles pour quiconque ne possède pas la clé. Un mot de passe, un jeton d'accès ou une clé d'API doit être chiffré à deux moments : quand il dort sur un disque (au repos) et quand il circule sur le réseau (en transit). Le point délicat est ailleurs : où ranger la clé qui déverrouille tout ? La réponse professionnelle s'appelle le chiffrement en enveloppe, appuyé sur un coffre matériel qui ne laisse jamais sortir sa clé maître. Cette page définit chaque terme sans supposer de prérequis, pour comprendre comment on protège vraiment un secret.

Ce que vous allez apprendre

Le chiffrement paraît magique de loin, mais il repose sur quelques idées simples que tout le monde peut saisir. Concrètement, vous saurez :

• Distinguer le chiffrement au repos (sur le stockage) du chiffrement en transit (sur le réseau).
• Expliquer le chiffrement en enveloppe, avec sa clé de données et sa clé maître, et pourquoi cette double couche est plus sûre.
• Comprendre le rôle du HSM et du KMS, ces gardiens de la clé maître qui ne la laissent jamais sortir.
• Repérer l'intérêt de l'encryption as a service, qui évite de confier la clé aux applications.
• Éviter les erreurs classiques comme ranger la clé à côté de la donnée qu'elle protège.
• Relier ce sujet au cycle de vie d'un secret et aux menaces qui pèsent sur les secrets, qui montrent quand et pourquoi ce chiffrement compte.

Pourquoi chiffrer les secrets

Un secret est une donnée qui donne un accès ou un pouvoir : mot de passe, jeton d'authentification, clé privée, chaîne de connexion à une base de données. Si un attaquant met la main dessus, il obtient les mêmes droits que vous. Le chiffrement est la barrière qui rend ce vol inutile : même volé, un secret chiffré reste une suite de caractères sans valeur tant que l'attaquant n'a pas la clé qui va avec.

Un secret est vulnérable à deux endroits différents, et il faut le protéger aux deux. Le premier, c'est au repos : quand le secret est stocké quelque part, sur un disque dur, dans une base de données, dans un fichier de configuration ou sur une sauvegarde. Le chiffrement au repos garantit que quelqu'un qui vole le disque ou copie le fichier n'y lit rien d'exploitable. Sans lui, une sauvegarde égarée ou un disque mis au rebut devient une fuite de secrets.

Le second endroit, c'est en transit : quand le secret voyage sur le réseau, entre votre navigateur et un site, entre une application et sa base de données, entre deux services. Le chiffrement en transit empêche un espion placé sur le trajet de lire ce qui passe. L'outil standard s'appelle TLS (Transport Layer Security), le protocole qui met en place un tunnel chiffré entre deux machines. C'est lui qui transforme http en https et affiche le cadenas dans votre navigateur.

Ces deux protections sont complémentaires, jamais interchangeables. Un secret chiffré sur le disque mais envoyé en clair sur le réseau reste interceptable. Un secret protégé par TLS pendant son voyage mais stocké en clair à l'arrivée reste volable sur le serveur. Un secret bien protégé l'est des deux côtés, du stockage jusqu'au réseau.

Le chiffrement ne remplace pas le contrôle d'accès

Chiffrer une donnée la rend illisible sans la clé, mais ne décide pas qui a le droit d'obtenir cette clé. Le chiffrement protège la confidentialité du contenu ; le contrôle des droits reste un sujet à part, traité par le principe de moindre privilège.

Le chiffrement en enveloppe

Une fois qu'on veut chiffrer, une question embarrassante surgit : il faut une clé pour chiffrer, mais alors où ranger cette clé ? Si on la pose à côté de la donnée chiffrée, l'attaquant qui vole l'une vole l'autre, et le chiffrement n'a servi à rien. Le chiffrement en enveloppe (en anglais envelope encryption) résout ce casse-tête en empilant deux niveaux de clés.

L'idée est d'emboîter deux clés comme une lettre dans une enveloppe. La clé de données (souvent notée DEK, pour Data Encryption Key) est la clé qui chiffre réellement le secret, ou plus souvent un gros volume de données. La clé maître (souvent notée KEK, pour Key Encryption Key) ne chiffre pas les données elles-mêmes : elle chiffre uniquement la clé de données. On stocke ensuite le secret chiffré et sa clé de données chiffrée côte à côte, sans risque, car la clé de données est elle-même inutilisable sans la clé maître.

Pourquoi ne pas chiffrer tout directement avec la clé maître, ce qui serait plus simple ? Pour plusieurs raisons pratiques. D'abord, la clé maître est précieuse et bien gardée : on veut la faire travailler le moins possible et l'exposer le moins souvent. Ensuite, on peut générer une clé de données différente pour chaque fichier, chaque base ou chaque secret, ce qui limite les dégâts si l'une fuite. Enfin, pour changer la clé maître (une opération de sécurité recommandée), il suffit de re-chiffrer les petites clés de données, pas des téraoctets de secrets. La double enveloppe apporte de la souplesse sans sacrifier la sécurité.

Reste le coeur du problème : où vit la clé maître ? La bonne réponse est un composant conçu pour ne jamais la laisser sortir. Un HSM (Hardware Security Module, module matériel de sécurité) est un boîtier physique durci qui génère et conserve les clés dans son enceinte. On lui envoie une clé de données à déchiffrer, il la déchiffre à l'intérieur et renvoie le résultat, mais la clé maître ne quitte jamais le boîtier. Même l'administrateur ne peut pas l'extraire. Un KMS (Key Management Service, service de gestion de clés) est le service, souvent proposé par un hébergeur ou un logiciel, qui pilote tout cela : il crée les clés, gère leurs autorisations, s'adosse à un HSM et offre une interface propre pour chiffrer et déchiffrer sans jamais manipuler la clé maître soi-même.

La règle d'or

Ne jamais ranger la clé à côté de la donnée qu'elle protège. Une clé stockée dans le même dépôt, la même base ou le même fichier que le secret chiffré annule le bénéfice du chiffrement. La clé de données peut voyager avec la donnée à condition d'être elle-même chiffrée par une clé maître gardée ailleurs, hors de portée de l'attaquant.

L'encryption as a service

Le chiffrement en enveloppe règle le rangement de la clé maître, mais un risque subsiste dans les applications. Traditionnellement, pour chiffrer une donnée, un programme doit récupérer une clé en mémoire, l'utiliser, puis espérer bien l'effacer. Pendant ce temps, la clé traîne dans le processus, vulnérable à une fuite de mémoire, à un journal trop bavard ou à un vidage de crash. Multipliez par des dizaines d'applications et vous avez autant d'endroits où une clé peut échapper.

L'encryption as a service (chiffrement en tant que service) renverse la logique : au lieu de donner la clé à l'application, on lui retire la clé et on lui offre un service qui chiffre et déchiffre pour elle. L'application envoie une donnée à un service central en lui disant « chiffre-moi ça » ou « déchiffre-moi ça », et récupère le résultat. La clé reste chez le service, jamais dans l'application. Le programme fait son travail sans jamais voir, stocker ni manipuler la moindre clé.

Ce modèle apporte trois bénéfices concrets. D'abord, la surface d'exposition rétrécit : la clé vit à un seul endroit protégé plutôt que dupliquée dans chaque application. Ensuite, la rotation des clés (les remplacer régulièrement) devient centralisée et transparente, sans toucher au code des applications. Enfin, on peut journaliser chaque opération de chiffrement au même endroit, ce qui donne une trace précieuse en cas d'incident. Le service HashiCorp Vault propose exactement ce mécanisme sous le nom de moteur transit : les applications lui délèguent le chiffrement sans jamais détenir la clé.

Le mettre en oeuvre

Comprendre ces concepts est une chose, les appliquer en est une autre, et vous n'avez pas à tout construire vous-même. La brique la plus répandue dans l'écosystème est un coffre à secrets couplé à un service de chiffrement. Le guide HashiCorp Vault montre comment déléguer le chiffrement et le déchiffrement à un service central via son moteur transit, exactement selon le modèle d'encryption as a service décrit plus haut : vos applications ne détiennent jamais la clé.

Pour le stockage des secrets eux-mêmes, la centralisation dans un coffre est le premier réflexe à adopter avant même de parler d'algorithmes. La page d'ensemble sur la gestion des secrets présente les outils disponibles et comment choisir. Un coffre applique le chiffrement en enveloppe pour vous, gère les autorisations et trace les accès, ce qui vous évite de réinventer une mécanique fragile à la main.

Pièges courants

Le chiffrement donne un sentiment de sécurité qui peut être trompeur. Quelques erreurs reviennent sans cesse et vident la protection de sa substance sans qu'on s'en aperçoive.

Le piège numéro un est de stocker la clé avec les données qu'elle protège. Une clé écrite dans un fichier de configuration versionné à côté de la base chiffrée, une clé glissée dans une variable d'environnement lisible par tous, une clé commitée par mégarde dans un dépôt Git : dans tous ces cas, l'attaquant qui obtient les données obtient aussi la clé, et le chiffrement devient décoratif. La clé doit toujours vivre ailleurs, dans un coffre ou un service dédié, hors de portée de qui accède aux données.

Le deuxième piège est de ne jamais changer la clé. Une clé qui chiffre les mêmes données pendant des années finit par fuiter, par une sauvegarde égarée, un départ d'employé ou une faille oubliée. La rotation des clés consiste à les remplacer périodiquement et à re-chiffrer ce qu'elles protégeaient. Le chiffrement en enveloppe rend cette opération abordable, puisqu'on ne re-chiffre que les petites clés de données. Ne pas tourner ses clés, c'est laisser une porte dont on a distribué la serrure trop longtemps.

Le troisième piège est de confondre chiffrement et gestion des accès. Chiffrer garantit qu'un secret volé reste illisible, mais ne dit rien sur qui a le droit de demander son déchiffrement. Un service qui déchiffre pour n'importe quel appelant sans vérifier son identité protège mal, aussi solide soit son chiffrement. Les deux couches, chiffrement et contrôle des droits, doivent tenir ensemble.

À retenir

1. Deux moments à protéger : un secret se chiffre au repos (sur le stockage) et en transit (sur le réseau, via TLS), jamais l'un sans l'autre.

2. Le vrai problème, c'est la clé : chiffrer est facile, ranger la clé en sécurité est la vraie difficulté.

3. Chiffrement en enveloppe : une clé de données (DEK) chiffre le secret, une clé maître (KEK) chiffre la clé de données, ce qui apporte souplesse et sécurité.

4. La clé maître ne sort jamais : un HSM (boîtier matériel) ou un KMS (service de gestion) génère et garde la clé maître sans jamais la laisser s'échapper.

5. Encryption as a service : déléguer le chiffrement à un service central évite de confier la clé aux applications, qui ne la détiennent jamais.

6. Jamais la clé à côté de la donnée : une clé stockée avec ce qu'elle protège annule tout le bénéfice, et une clé jamais tournée finit par fuiter.

7. Passez à la pratique : le socle exige de ne jamais laisser un secret en clair et de le confier à un coffre sûr (SOCLE-SEC-GEN-2) ; le modèle des menaces sur les secrets montre quelles attaques ce chiffrement bloque.

Prochaines étapes

Le cycle de vie d'un secret De la création à la révocation, les étapes qu'un secret traverse et les risques à chaque phase.

HashiCorp Vault Déléguer le chiffrement à un service central avec le moteur transit, sans jamais détenir la clé.

Gérer ses secrets Choisir et mettre en place un coffre pour centraliser et protéger ses secrets.

Les menaces sur les secrets Les attaques qui visent les secrets et les contrôles du socle qui les couvrent.

×

📖 Voir la documentation →