08 - Rotation des secrets : comment ne rien casser

Ce que tu vas apprendre

• Pourquoi et quand faire tourner tes secrets
• La stratégie dual-key pour une rotation sans downtime
• Une checklist de ce qu'il faut faire tourner maintenant

Prerequisites

Avoir lu au moins l'article sur les solutions de gestion des secrets.

Pourquoi faire tourner ses secrets

Un secret qui ne change jamais est un secret qui attend d'etre compromis. Plus une clé API vit longtemps, plus elle a de chances de fuiter : un backup oublie, un ancien laptop non efface, un message Slack qui traine.

Il y a quatre raisons de faire une rotation :

Un secret a ete expose. Quelqu'un l'a colle dans un canal Slack. Il est apparu dans des logs. Il a ete committe dans git. Dans ce cas, la rotation n'est pas optionnelle : c'est une urgence.

Un membre de l'équipe part. Il a eu acces au .env, aux variables CI/CD, peut-etre au vault. Tu ne sais pas ce qu'il a copie sur sa machine perso. Tous les secrets auxquels il avait acces doivent etre renouveles.

La compliance l'exige. PCI-DSS demande une rotation tous les 90 jours pour certains types de credentials. SOC 2 aussi. Meme si tu n'es pas concerne directement, c'est une bonne hygiene.

Ca fait trop longtemps. Si ta clé API Anthropic sur paltemps.fr est la meme depuis 6 mois, il est temps de la changer. Pas parce qu'elle a fuite, mais parce que tu ne sais pas si elle a fuite.

Le problème : le downtime

La rotation naive, c'est : générer une nouvelle clé, remplacer l'ancienne partout, relancer les services. En theorie, ca marche. En pratique, il y a toujours un moment ou l'ancienne clé est invalide et l'application n'a pas encore la nouvelle. Résultat : des erreurs 401, des emails qui ne partent plus, des appels API qui echouent.

Sur un seul serveur, la fenêtre est courte (quelques secondes). Avec plusieurs serveurs ou services, ca peut durer des minutes. Et si tu oublies un service, il plante jusqu'a ce que quelqu'un s'en rende compte.

La stratégie dual-key

La solution propre, c'est la rotation en 5 étapes sans jamais invalider l'ancienne clé avant d'avoir confirme que la nouvelle fonctionne :

Étape 1 : généré la nouvelle clé.

Va dans le dashboard du fournisseur (Anthropic, OpenAI, ton provider SMTP) et généré une nouvelle clé API. Ne revoque pas l'ancienne. A ce stade, les deux clés sont valides.

Étape 2 : deploie l'app avec la nouvelle clé.

Mets à jour ton .env, ta variable CI/CD, ou ton vault avec la nouvelle valeur. Redeploy.

bash# Si tu utilises SOPS
sops .env.enc
# Change la valeur de ANTHROPIC_API_KEY
git add .env.enc && git commit -m "rotate ANTHROPIC_KEY"
git push origin main
# Le pipeline deploie automatiquement

Étape 3 : vérifié que tout fonctionne.

Teste les fonctionnalités qui utilisent cette clé. Fais un appel API, envoie un email de test, vérifié les logs. Si quelque chose ne marche pas, tu peux revenir a l'ancienne clé sans panique (elle est encore valide).

Étape 4 : revoque l'ancienne clé.

Une fois que tu es sur que la nouvelle clé fonctionne en production, va revoquer l'ancienne dans le dashboard du fournisseur.

Étape 5 : documente.

Note la date de rotation, qui l'a faite, et pourquoi. Un simple commentaire dans le commit suffit pour les petites équipes. Pour les grosses, un registre dans le vault (Google Secret Manager et AWS gardent automatiquement l'historique des versions).

Rotation selon le type de secret

Tous les secrets n'ont pas la meme fréquence de rotation ideale.

Cles API de services externes (Anthropic, OpenAI, Unsplash, Pexels) : tous les 90 jours, ou immédiatement si exposees. La plupart des fournisseurs permettent d'avoir 2 clés actives simultanément, ce qui facilite la dual-key.

Mots de passe applicatifs (admin password, DB password) : tous les 180 jours. Plus frequent si l'équipe change souvent.

Credentials SMTP : tous les 180 jours. Si tu utilises un service comme SendGrid ou Mailgun, ils offrent la possibilité de générer de nouvelles clés sans revoquer les anciennes immédiatement.

Certificats TLS : avant l'expiration. Let's Encrypt renouvelle automatiquement tous les 60 jours si tu utilises Caddy ou certbot. Pas besoin d'y penser. On en parle dans la serie sur le chiffrement TLS.

Tokens d'acces CI/CD (GitLab Runner registration token, deploy tokens) : a chaque changement d'équipe ou tous les 6 mois.

Ce que tu dois faire tourner maintenant

Arrete de lire une seconde et reponds a ces questions :

• Est-ce qu'un de tes secrets a ete partage par Slack ou email ? Si oui, régénéré-le.
• Est-ce qu'un ancien collegue avait acces a tes secrets ? Si oui, régénéré-les tous.
• Est-ce qu'un de tes secrets a plus d'un an ? Si oui, planifie une rotation cette semaine.
• Est-ce qu'un de tes secrets est dans un historique git ? Si oui, régénéré-le (supprimer le commit ne suffit pas, les anciens commits sont accessibles avec git reflog).

C'est la réalité : la plupart des devs que je connais (moi y compris) ont au moins un secret qui traine quelque part ou il ne devrait pas. La rotation, c'est le filet de sécurité.

Rotation automatique avec les vaults cloud

Si tu utilises Google Secret Manager ou AWS Secrets Manager, la rotation automatique est intégrée.

Chez AWS, tu attaches une Lambda qui généré la nouvelle valeur et met à jour le secret :

bashaws secretsmanager rotate-secret \
  --secret-id "paltemps/DB_PASSWORD" \
  --rotation-lambda-arn "arn:aws:lambda:eu-west-3:123:function:rotate-db" \
  --rotation-rules '{"AutomaticallyAfterDays": 30}'

Chez Google, c'est un système de notifications Pub/Sub qui déclenché une Cloud Function.

HashiCorp Vault va encore plus loin avec les secrets dynamiques : pas besoin de rotation puisque chaque credential est temporaire et expire automatiquement.

Pour les clés API de services externes (Anthropic, OpenAI), l'automatisation complète n'est pas toujours possible : il faut appeler l'API du fournisseur pour régénérer la clé, et tous ne proposent pas cette fonctionnalité par API. Dans ce cas, la rotation reste manuelle mais planifiee.

Checklist de rotation

Quand tu fais une rotation, suis cette liste dans l'ordre :

[ ] Identifier le secret a faire tourner et tous les services qui l'utilisent
[ ] Generer la nouvelle valeur (dashboard fournisseur ou commande)
[ ] Mettre a jour le secret (vault, variable CI/CD, SOPS)
[ ] Deployer les services concernes
[ ] Tester que tout fonctionne avec la nouvelle valeur
[ ] Revoquer l'ancienne valeur chez le fournisseur
[ ] Verifier que rien ne plante apres la revocation
[ ] Documenter la rotation (date, raison, qui)

Tu peux copier cette checklist dans un fichier ROTATION.md dans ton projet, ou dans un issue template GitLab/GitHub si tu veux tracker les rotations.

Mettre en place un rappel

La rotation, c'est comme les backups : tout le monde sait qu'il faut le faire, personne ne le fait régulièrement. Mets un rappel dans ton calendrier. Tous les 90 jours pour les clés API, tous les 180 jours pour les mots de passe.

Pas besoin d'un outil sophistique. Un event Google Calendar recurrent fait le travail.

Navigation : Precedent : 07 - Secrets dans CI/CD | Suivant : 09 - Glossaire

Sources

• OWASP Key Management Cheat Sheet par OWASP
• AWS Secrets Manager rotation par AWS
• NIST SP 800-57: Key Management par NIST

Retrouve d'autres articles techniques sur paltemps.fr.