Secrets : rotation et fuites

Prérequis : cours 4.1 (secrets en 600) et 5.3 (contrat secrets) ; mots de passe et hash.

Pourquoi

Un secret a un cycle de vie : création, usage, rotation, révocation. La plupart gèrent les deux premiers et découvrent les deux derniers le jour de la fuite. Ce cours, c'est les deux derniers.

Concepts

• Inventaire vivant : secret | où il vit | qui y accède | comment le changer | dernière rotation. Sans ça, changer un mot de passe = expédition (« et si tel script l'utilisait ? »). Avec = 10 minutes.
• Rotation : générer le nouveau → déployer partout → vérifier → révoquer l'ancien → confirmer dans les logs. Déclencheurs : départ, suspicion, fuite, calendrier (1×/an les critiques). SESSION_SECRET : rotation = déconnexion générale, zéro perte — prévoir le message.
• Garde-fous anti-fuite : gitleaks (scanner qui bloque tout commit contenant un secret), .gitignore (.env dedans, toujours), hook pre-commit (vérification locale avant chaque commit). Et git filter-repo pour purger l'historique — en sachant que face aux copies/forks, c'est cosmétique.

Exemple : protocole de fuite

1. Révoquer d'abord : le commit restera public pour toujours.
2. Chercher les autres occurrences (.env.bak, screenshots, tickets avec le secret collé !).
3. Purger si utile, puis activer les 3 garde-fous s'ils manquaient.

Cas réel

Clé API collée dans un ticket « pour débugger », 6 mois ouverte, aspirée par un scraper : 400 € de data + rotation d'urgence un dimanche. Depuis : aucun secret hors coffre, même « juste pour débugger ».

Pièges

• « Je supprime le commit » : l'historique est indélébile (forks, caches, archives).
• Rotation partielle (nouveau déployé mais ancien pas révoqué) : deux secrets valides = deux fois le risque.
• Secret dans les logs « pour débugger » : les logs partent en backup — compromis d'avance.

À retenir

Inventaire vivant, rotation procédurée, fuite = révoquer d'abord, gitleaks en CI.