Rotation des secrets : pourquoi, quand et comment le faire sans casser votre système

Vos secrets sont stockés en toute sécurité dans un coffre. Votre pipeline les injecte au moment du déploiement. Tout semble solide. Mais il y a un problème auquel vous n'avez peut-être pas pensé : utiliser le même secret pendant des mois ou des années, c'est une bombe à retardement.

Imaginez qu'un développeur inclue accidentellement une clé API dans une capture d'écran lors d'une présentation. Ou qu'un fichier de log vieux de six mois contienne encore un mot de passe de base de données, et qu'une personne non autorisée le trouve. Plus un secret vit longtemps, plus le risque qu'il fuite sans que vous le sachiez est élevé. La rotation est votre filet de sécurité : si un secret fuit, sa durée de vie utile a déjà expiré avant que la fuite puisse être exploitée.

Pourquoi faire tourner les secrets ?

La raison la plus fondamentale est de réduire votre fenêtre de vulnérabilité. Si une clé API est valide un an et fuit au troisième mois, un attaquant dispose de neuf mois d'accès. Mais si vous faites tourner cette clé chaque semaine, la fenêtre de dégât maximale est de sept jours.

La rotation est également importante pour la conformité. Des normes comme PCI DSS et SOC 2 exigent une rotation périodique des secrets. Mais même sans pression réglementaire, la rotation est un mécanisme de défense pratique. Elle limite le rayon d'explosion, vous oblige à vérifier que votre pipeline de gestion des secrets fonctionne réellement, et crée une mémoire musculaire opérationnelle pour gérer les changements d'identifiants dans des conditions calmes plutôt que pendant un incident.

Quand faut-il faire tourner les secrets ?

Il y a trois scénarios principaux qui déclenchent une rotation.

Rotation planifiée. C'est le cycle de routine prévisible. Tous les 30, 60 ou 90 jours, selon la sensibilité du secret. Un mot de passe de base de données pour un système de production peut tourner tous les 30 jours. Une clé API interne moins critique peut tourner tous les 90 jours. Le calendrier doit correspondre au profil de risque de ce que le secret protège.

Rotation déclenchée par un incident. Quelque chose s'est produit. Peut-être avez-vous repéré un accès suspect dans les journaux d'audit. Peut-être qu'un secret est apparu dans un dépôt GitHub public. Peut-être que l'ordinateur portable d'un employé a été compromis. Dans ces cas, vous faites tourner immédiatement. N'attendez pas la prochaine fenêtre planifiée. La rapidité prime sur le protocole.

Changements de personnel. Lorsqu'une personne qui avait accès aux secrets quitte l'équipe, change de rôle ou est licenciée, faites tourner tous les secrets auxquels elle a pu avoir accès. Il ne s'agit pas de confiance. Il s'agit d'éliminer la possibilité que des identifiants qu'elle a mémorisés, sauvegardés localement ou notés quelque part soient encore valides après que son accès aurait dû prendre fin.

Comment faire tourner les secrets sans casser les applications

Voici la partie difficile. Si vous faites tourner un mot de passe de base de données et que tous vos services perdent soudainement la connexion, vous avez aggravé la situation. L'objectif est de faire tourner sans temps d'arrêt. La stratégie la plus fiable est la rotation double secret, également appelée rotation avec période de transition.

Rotation double secret

L'idée est simple : votre application accepte deux secrets valides en même temps pendant la transition. Voici le processus étape par étape :

Le diagramme de séquence suivant illustre le processus de rotation double secret entre un coffre, un service de configuration et plusieurs instances d'application :

Voici comment implémenter cela avec HashiCorp Vault et un fichier de configuration JSON :

# Étape 1 : Générer une nouvelle version du secret (garder l'ancien)
vault kv put secret/db-password \
  old_password="$(vault kv get -field=password secret/db-password)" \
  new_password="$(openssl rand -base64 32)"

# Étape 2 : Mettre à jour la configuration de l'application avec les deux secrets
cat > /etc/myapp/config.json <<EOF
{
  "db": {
    "old_password": "$(vault kv get -field=old_password secret/db-password)",
    "new_password": "$(vault kv get -field=new_password secret/db-password)"
  }
}
EOF

# Étape 3 : Recharger l'application pour prendre en compte la nouvelle configuration
systemctl reload myapp

# Étape 4 : Après que toutes les instances utilisent le nouveau secret, supprimer l'ancien
vault kv patch secret/db-password old_password=""

# Étape 5 : Mettre à jour la configuration pour n'utiliser que le nouveau secret
cat > /etc/myapp/config.json <<EOF
{
  "db": {
    "password": "$(vault kv get -field=new_password secret/db-password)"
  }
}
EOF
systemctl reload myapp
sequenceDiagram participant Vault participant Config participant ServiceA participant ServiceB Note over Vault,ServiceB: Étape 1 : Générer un nouveau secret Vault->>Vault: Générer un nouveau secret (garder l'ancien) Note over Vault,ServiceB: Étape 2 : Déployer le nouveau secret sur tous les services Vault->>Config: Fournir l'ancien + le nouveau secret Config->>ServiceA: Mettre à jour la config (les deux secrets valides) Config->>ServiceB: Mettre à jour la config (les deux secrets valides) Note over Vault,ServiceB: Étape 3 : Vérifier que tous les services utilisent le nouveau secret ServiceA->>Vault: Se connecter avec le nouveau secret ServiceB->>Vault: Se connecter avec le nouveau secret Note over Vault,ServiceB: Étape 4 : Désactiver l'ancien secret Vault->>Config: Marquer l'ancien secret comme invalide Config->>ServiceA: Supprimer l'ancien secret de la config Config->>ServiceB: Supprimer l'ancien secret de la config Note over Vault,ServiceB: Étape 5 : Supprimer l'ancien secret du coffre Vault->>Vault: Supprimer l'ancien secret
  1. Générez un nouveau secret dans votre coffre ou magasin de secrets. Ne supprimez pas l'ancien.
  2. Mettez à jour la configuration de votre application pour qu'elle sache que l'ancien et le nouveau secret sont valides.
  3. Déployez la configuration mise à jour. Toutes les instances en cours d'exécution acceptent désormais les deux secrets.
  4. Attendez que chaque instance ait pris la nouvelle configuration et utilise le nouveau secret.
  5. Supprimez l'ancien secret de la configuration et déployez à nouveau.

Pendant ce processus, votre application ne perd jamais la connectivité. Si une instance n'a pas encore reçu la nouvelle configuration, elle fonctionne toujours avec l'ancien secret. Une fois qu'elle a pris la mise à jour, elle peut utiliser l'un ou l'autre. Après la suppression de l'ancien secret, seul le nouveau fonctionne.

Cette approche fonctionne bien pour les secrets consommés directement par les applications : mots de passe de base de données, clés API, jetons de service à service. La condition clé est que votre code applicatif ou votre middleware prenne en charge plusieurs identifiants valides simultanément. La plupart des pilotes de base de données modernes et des clients HTTP peuvent gérer cela.

Coordonner la rotation entre plusieurs services

Lorsqu'un seul secret est partagé entre de nombreux services, la rotation devient plus complexe. Imaginez un mot de passe de base de données utilisé par dix microservices. Vous ne pouvez pas le faire tourner un service à la fois sans coordination. Si le service A passe au nouveau mot de passe pendant que le service B utilise encore l'ancien, et que la base de données n'accepte que le nouveau mot de passe, le service B se casse.

Une solution consiste à utiliser un service mesh ou un proxy sidecar qui gère les connexions à la base de données de manière centralisée. Le sidecar gère l'authentification auprès de la base de données. Vos services se connectent au sidecar, pas directement à la base de données. Lorsque vous faites tourner le mot de passe de la base de données, vous mettez à jour uniquement la configuration du sidecar. Les services ne savent même pas qu'une rotation a eu lieu.

Une autre approche consiste à utiliser un système de secrets dynamiques, que nous aborderons brièvement. Mais pour les secrets statiques partagés entre de nombreux consommateurs, un service mesh ou un pooler de connexions dédié est le modèle le plus pratique.

Quoi d'autre compte dans la rotation

La rotation ne consiste pas seulement à changer une valeur. C'est un processus qui nécessite des pratiques de support.

Journalisation d'audit. Chaque rotation doit être enregistrée. Qui l'a déclenchée, quand, quel secret a été tourné, et quel a été le résultat. C'est essentiel pour l'investigation d'incidents et les audits de conformité.

Test en staging d'abord. Ne faites jamais tourner un secret de production sans vérifier le processus dans un environnement de staging. Le staging doit refléter les modèles de consommation de secrets de la production. Si la rotation casse quelque chose, vous voulez que cela casse en staging, pas en production.

Ayez un plan de rollback. Parfois, une rotation cause des problèmes inattendus. Peut-être que le nouveau secret ne se propage pas correctement. Peut-être qu'un service ne parvient pas à prendre le changement de configuration. Votre procédure de rotation doit inclure un moyen de revenir rapidement à l'ancien secret. Cela signifie garder l'ancien secret valide jusqu'à ce que vous soyez sûr que le nouveau fonctionne partout.

Checklist pratique pour la rotation des secrets

  • Identifier les secrets qui nécessitent une rotation et leur niveau de risque
  • Définir des calendriers de rotation basés sur le risque (30/60/90 jours)
  • Implémenter le support du double secret dans le code applicatif ou le middleware
  • Tester la procédure de rotation dans l'environnement de staging
  • Documenter les étapes de rollback avant de faire tourner les secrets de production
  • Journaliser chaque rotation avec horodatage, opérateur et résultat
  • Automatiser les rotations planifiées lorsque c'est possible
  • Établir un processus de réponse aux incidents pour les rotations d'urgence

Ce qu'il faut retenir

Un secret qui ne change jamais est une vulnérabilité qui attend d'être exploitée. La rotation limite la fenêtre de dégât, satisfait aux exigences de conformité et vous oblige à maintenir vos pratiques de gestion des secrets affûtées. Le modèle du double secret vous offre un moyen sûr de faire tourner sans temps d'arrêt. Mais la rotation n'est qu'une partie du tableau. La question suivante est de savoir si vous pouvez aller au-delà des secrets statiques, vers des secrets qui expirent automatiquement après une seule utilisation. C'est là que les secrets dynamiques entrent en jeu.