Chapitre 13.2 — Vaults, rotation & chiffrement

⏱️ TL;DR — Une fois les secrets hors du code (chapitre 13.1), où les mettre ? Pour un petit projet, des variables d’environnement injectées au déploiement suffisent souvent. Pour du sérieux, un vault (gestionnaire de secrets — HashiCorp Vault, secrets managers cloud, secrets vault Symfony) : stockage chiffré, accès contrôlé et audité, distribution aux services. On applique le moindre privilège (chaque service ne lit que ses secrets) et « un secret par usage » (pas une clé fourre-tout partagée). On fait tourner les secrets régulièrement (rotation) — et impérativement après une fuite ou un départ. Enfin, on chiffre au repos les données sensibles qui le méritent (AES-GCM), la vraie difficulté étant… la gestion de la clé de chiffrement (qui revient au même problème : la protéger).

🎯 Objectifs

Choisir où stocker les secrets (env vs vault) selon le contexte.
Comprendre ce qu’apporte un vault (chiffrement, accès contrôlé, audit).
Appliquer moindre privilège et « un secret par usage ».
Mettre en place la rotation des secrets ; chiffrer au repos les données sensibles.

Où stocker les secrets

Selon la taille et les enjeux du projet :

Variables d’environnement (injectées au déploiement) : simple et suffisant pour beaucoup de projets. Les secrets sont fournis par la plateforme (PaaS) ou le système de déploiement (Partie 14, Serveur Linux), lus par l’appli via l’environnement. Attention : ne pas les logger, ne pas les exposer via une page de debug, ne pas les mettre dans un fichier versionné.
Vault / gestionnaire de secrets : pour des besoins plus exigeants (nombreux services, rotation, audit, secrets partagés). Exemples : HashiCorp Vault, les secrets managers cloud, le secrets vault de Symfony (Partie 9). Ils apportent :
- Stockage chiffré des secrets (pas en clair sur disque).
- Contrôle d’accès fin : quel service/identité peut lire quel secret.
- Audit : qui a accédé à quel secret, quand.
- Distribution et parfois génération dynamique (secrets à durée de vie courte).

Le choix dépend du contexte ; l’important est que les secrets soient chiffrés au repos, accessibles seulement à qui en a besoin, et jamais en clair dans le code ou les logs.

Moindre privilège et « un secret par usage »

Deux principes (Partie 1) appliqués aux secrets :

Moindre privilège : chaque service/identité ne peut lire que les secrets dont il a besoin, pas tous. Si un service est compromis, l’attaquant n’obtient que ses secrets, pas le trousseau complet. Un vault permet ce cloisonnement (politiques d’accès).
Un secret par usage : ne pas réutiliser le même secret partout (une clé unique pour la CI, la prod, un partenaire…). Un secret dédié par usage limite l’impact d’une fuite (on révoque ce secret sans tout casser) et facilite la rotation ciblée. Rappel de la Partie 4 : une clé de déploiement distincte de ta clé personnelle, une clé d’API par intégration.

La rotation : changer les secrets régulièrement

Un secret n’est pas éternel. La rotation consiste à le remplacer périodiquement par un nouveau, pour limiter la fenêtre pendant laquelle un secret (peut-être fuité à ton insu) reste exploitable.

Rotation périodique : changer les secrets à intervalle régulier (selon la sensibilité). Les secrets dynamiques (générés par un vault avec une courte durée de vie) automatisent cela.
Rotation événementielle — impérative : après une fuite (chapitre 13.1), après le départ d’une personne qui y avait accès, après une compromission suspectée. Là, la rotation n’est pas optionnelle : c’est la réponse.
Rotation sans coupure : prévoir le mécanisme (accepter temporairement l’ancien et le nouveau secret le temps de propager) pour ne pas casser le service.

💡 Réflexe — Conçois tes secrets pour être remplaçables facilement dès le départ : centralisés (env/vault, pas éparpillés en dur), un par usage, et changeables sans redéploiement lourd. Un secret « impossible à changer sans tout casser » est un piège : le jour d’une fuite, tu voudras le rotationner en urgence, et la difficulté de rotation deviendra elle-même un risque. La capacité à rotationner vite est une propriété de sécurité.

Chiffrer au repos les données sensibles

Certaines données (pas des secrets d’accès, mais des données personnelles ou confidentielles : un numéro sensible, des données de santé) méritent d’être chiffrées au repos — c’est-à-dire stockées chiffrées en base/sur disque, pour qu’une fuite de la base (vol de dump, sauvegarde égarée) ne les livre pas en clair.

Rappels de la Partie 3 :

On chiffre (réversible) quand on doit relire la donnée en clair plus tard ; on hache (irréversible) quand on veut juste vérifier une correspondance (mots de passe → jamais chiffrés, toujours hachés).
Le chiffrement au repos est typiquement symétrique (AES-GCM, mode authentifié qui garantit aussi l’intégrité).
Ne réimplémente pas la crypto : utilise les bibliothèques standard (Partie 3), ou le chiffrement transparent de la base / du disque quand il convient.

Le point décisif, comme toujours : la clé de chiffrement. Chiffrer des données avec une clé stockée à côté (dans le code, dans la même base, en clair) ne protège rien — c’est reculer le problème d’un cran. La clé doit être gérée comme un secret (vault, env, moindre privilège, rotation) — on boucle sur la gestion des secrets.


Chiffrer des donnees au repos protege SI la cle est bien geree.
Cle dans le code / a cote des donnees / en clair = protection nulle.
-> la cle de chiffrement est un SECRET (vault, moindre privilege, rotation).

⚠️ Piège — Le faux sentiment de sécurité du « on chiffre la base ». Si la clé de chiffrement est accessible en même temps que les données (dans le même dump, dans le code, dans une variable exposée), un attaquant qui obtient la base obtient aussi la clé → le chiffrement ne sert à rien. Le chiffrement au repos n’a de valeur que si la clé est séparée et protégée (vault, hors du dump, accès restreint). Sans gestion de clé rigoureuse, « chiffré au repos » est une case cochée sans protection réelle.

🎯 Côté attaquant — Quand un attaquant obtient une base « chiffrée », sa première question est : « où est la clé ? ». Trop souvent, elle est à portée — dans le code (qu’il a peut-être aussi), dans une variable d’environnement qu’il peut lire, dans la même sauvegarde. Il cible aussi les secrets long-lived jamais rotationnés (une clé valide depuis des années, peut-être fuitée entre-temps) et les secrets partagés (compromettre un endroit donne accès à tout). D’où : clés bien gérées, secrets par usage, et rotation — surtout des secrets anciens et partagés.

🧭 Sur FormaCampus — FormaCampus stocke ses secrets dans un gestionnaire de secrets (vault Symfony côté API + secrets manager de la plateforme), avec accès cloisonné (chaque service ne lit que ses secrets — moindre privilège) et audit des accès. Chaque intégration a sa clé dédiée (un secret par usage), et une clé de déploiement distincte des clés humaines (Partie 4). Les secrets font l’objet d’une rotation périodique, et immédiate en cas de fuite ou de départ. Les rares données chiffrées au repos (un identifiant sensible) le sont en AES-GCM, la clé vivant dans le vault (jamais à côté des données ni dans le code) et étant elle-même rotationnable. La capacité à rotationner vite a été conçue dès le départ.

✏️ Exercices

Exercice 1 — Un secret par usage. Une équipe utilise la même clé d’API pour la CI, la préproduction et la production, et pour deux partenaires. Quels problèmes, et que proposer ?

✅ Solution

Problèmes : (1) impact d’une fuite maximal — si cette clé unique fuite (par la CI, la préprod, un partenaire), tous les usages sont compromis d’un coup ; (2) rotation impossible sans tout casser — la changer coupe simultanément CI, préprod, prod et les deux partenaires ; (3) traçabilité nulle — impossible de savoir quel usage est à l’origine d’un incident ; (4) moindre privilège violé — chaque usage a accès à ce que devrait avoir chaque autre. Proposition : un secret par usage — une clé pour la CI, une pour la préprod, une pour la prod, une par partenaire. Ainsi, une fuite est cloisonnée (on révoque ce secret sans toucher aux autres), la rotation est ciblée, et la traçabilité est possible. Idéalement, gérer le tout dans un vault avec accès cloisonné.

Exercice 2 — La clé à côté. Un dev chiffre une colonne sensible en base (AES) mais stocke la clé de chiffrement dans une constante du code, committée. Qu’est-ce qui ne va pas ?

✅ Solution

Le chiffrement ne protège rien ici, pour deux raisons : (1) la clé est dans le code committé — donc dans Git (compromise en principe, chapitre 13.1) et lisible par quiconque a le dépôt ; (2) plus fondamentalement, la clé est accessible en même temps que les données : un attaquant qui obtient la base (dump, sauvegarde) obtient aussi la clé (via le code), et déchiffre tout. « Chiffré au repos » n’a de valeur que si la clé est séparée et protégée. Correctif : sortir la clé du code, la stocker dans un vault / variable d’environnement, avec accès restreint (moindre privilège) et hors des sauvegardes de données, et la rendre rotationnable. La clé de chiffrement est un secret à gérer comme tel — sinon on a coché la case « chiffrement » sans aucune protection réelle.

🧠 Quiz de révision

1. Qu’apporte un vault par rapport à de simples variables d’environnement ?

Un vault apporte : stockage chiffré des secrets, contrôle d’accès fin (qui lit quoi), audit des accès, distribution aux services et parfois génération dynamique (secrets à courte durée de vie). Utile pour de nombreux services, la rotation et la traçabilité. Les variables d’environnement suffisent pour des projets plus simples.

2. Que signifie « un secret par usage » et pourquoi ?

Ne pas réutiliser le même secret pour plusieurs usages (CI, prod, partenaires) : chaque usage a son secret dédié. Cela cloisonne l’impact d’une fuite (on révoque ce secret sans tout casser), permet une rotation ciblée et la traçabilité. Une clé fourre-tout partagée maximise les dégâts d’une fuite.

3. Quand la rotation d’un secret est-elle impérative ?

Après une fuite, après le départ d’une personne qui y avait accès, et après une compromission suspectée. Là, la rotation n’est pas optionnelle : c’est la réponse. On fait aussi une rotation périodique pour limiter la fenêtre d’exploitation d’un secret éventuellement fuité à son insu.

4. De quoi dépend l’efficacité du chiffrement au repos ?

De la gestion de la clé de chiffrement. Chiffrer des données avec une clé stockée à côté (dans le code, la même base, en clair) ne protège rien : qui obtient les données obtient la clé. La clé doit être séparée et protégée (vault, moindre privilège, hors des dumps, rotationnable) — c’est un secret à part entière.

5. Pourquoi concevoir ses secrets pour être facilement remplaçables ?

Parce que le jour d’une fuite, il faudra les rotationner en urgence : un secret « impossible à changer sans tout casser » devient lui-même un risque. Centraliser (env/vault), un par usage, et permettre le changement sans redéploiement lourd font de la capacité à rotationner vite une propriété de sécurité.

Chapitre suivant : PII, logs & minimisation — protéger les données personnelles des utilisateurs : en collecter le moins possible, ne pas les fuiter (notamment dans les logs), en lien avec le RGPD.