Rotation des secrets et identités de service : un runbook de production, pas une tâche isolée

La rotation d’un secret applicatif paraît simple tant qu’elle est traitée comme une opération ponctuelle : générer une nouvelle valeur, la déposer dans un coffre, redémarrer le service. En production, le problème est rarement la génération du secret. Le risque se trouve dans les dépendances non inventoriées, les caches, les jobs planifiés, les connecteurs SaaS, les identités CI, les certificats oubliés, et les applications qui ne savent pas relire leur configuration sans redéploiement.

Le cas d’usage traité ici est celui d’une plateforme où plusieurs applications consomment des secrets, certificats ou identités de service : accès base de données, API internes, service principal cloud, webhook tiers, stockage, bus de messages ou backend Terraform. L’objectif n’est pas seulement de faire tourner une valeur avant expiration. Il faut construire un runbook qui prouve qui consomme quoi, comment la nouvelle valeur est propagée, quels signaux confirment le succès, et comment revenir en arrière sans ouvrir trop largement les accès.

Commencer par l’inventaire des consommateurs réels

Un secret n’appartient pas seulement à une application. Il appartient à un chemin d’exécution. Le même identifiant peut être utilisé par un worker, une API, un job de nuit, un pipeline CI et un script de maintenance. Tant que ces consommateurs ne sont pas listés, la rotation reste un pari.

Secret ou credential
Nom fonctionnel
Emplacement source: Key Vault, variable CI, coffre SaaS, fichier chiffré
Identité propriétaire
Date d'expiration ou politique de rotation

Consommateurs
Service applicatif
Job planifié
Pipeline CI/CD
Script d'exploitation
Intégration externe

Preuves attendues
Log d'authentification réussi
Métrique d'erreur stable
Test applicatif ciblé
Ancienne valeur non utilisée après bascule

La question utile n’est pas “où est stocké le secret ?”. C’est “quels processus échouent si cette valeur change maintenant ?”. Cette nuance évite de limiter le runbook au coffre de secrets alors que l’incident peut apparaître côté worker, scheduler ou pipeline.

Séparer rotation, déploiement et révocation

Une rotation saine se déroule en trois temps. D’abord, la nouvelle valeur est créée et rendue disponible. Ensuite, les consommateurs basculent vers cette valeur. Enfin seulement, l’ancienne valeur est révoquée. Mélanger ces étapes augmente le risque de panne immédiate et rend le diagnostic plus difficile.

Phase 1 - Préparer
Créer le nouveau secret ou certificat
Le déposer dans l'emplacement cible
Vérifier les permissions de lecture
Ne pas révoquer l'ancienne valeur

Phase 2 - Basculer
Redéployer ou recharger les consommateurs
Valider les appels réels
Surveiller erreurs d'authentification et latence
Confirmer que le chemin critique utilise la nouvelle valeur

Phase 3 - Révoquer
Confirmer absence d'usage de l'ancienne valeur
Supprimer ou désactiver l'ancienne valeur
Garder les preuves dans le ticket de changement
Mettre à jour la date de prochaine rotation

Cette séparation donne aussi un rollback praticable. Si la bascule échoue, l’ancienne valeur existe encore. Si la révocation échoue, les consommateurs fonctionnent déjà avec la nouvelle valeur.

Vérifier les permissions avant la fenêtre de changement

Beaucoup de rotations échouent pour une raison banale : le service qui doit lire la nouvelle valeur n’a pas les droits sur le coffre, ou le pipeline qui doit l’injecter utilise une identité différente de celle testée manuellement. La pré-vérification doit donc porter sur l’identité qui exécutera réellement le changement.

# Exemple Azure Key Vault: vérifier la présence et la date d'expiration
az keyvault secret show --vault-name kv-prod-app --name api-backend-client-secret --query '{name:name, enabled:attributes.enabled, expires:attributes.expires, updated:attributes.updated}'

# Vérifier depuis l'identité d'exécution réelle du pipeline ou du workload.
# Le test manuel depuis un compte admin ne prouve pas le chemin de production.

L’étape critique consiste à documenter l’identité utilisée pour le test. Un succès depuis un poste d’administration ne prouve pas que le runner CI, le pod applicatif ou le service managé pourra lire la nouvelle version.

Chercher les usages résiduels dans les logs

Avant de révoquer l’ancienne valeur, il faut chercher des signes d’usage résiduel. Selon les plateformes, ce signal peut venir des logs d’authentification, des logs applicatifs, des erreurs 401/403, des métriques de connexion base de données ou des événements du coffre.

let RotationStart = datetime(2026-06-04T08:00:00Z);
AppServiceHTTPLogs
| where TimeGenerated > RotationStart
| where ScStatus in (401, 403, 500)
| summarize errors=count() by bin(TimeGenerated, 5m), CsHost, CsUriStem, ScStatus
| order by TimeGenerated desc

Cette requête n’est pas une preuve universelle, mais elle illustre le réflexe attendu : relier la rotation à un signal temporel exploitable. Le runbook doit dire où chercher, quelle fenêtre observer et quel seuil déclenche un arrêt de la révocation.

Prévoir les caches et les processus longs

Un service peut avoir relu le secret, mais garder une connexion ouverte avec l’ancienne valeur. Un worker peut ne recharger sa configuration qu’au démarrage. Un job mensuel peut être absent de tous les tests immédiats. C’est pourquoi le runbook doit distinguer validation immédiate et validation différée.

Consommateurs à risque différé
Workers et files de messages
Connexions persistantes base de données
Jobs batch peu fréquents
Runners CI utilisés seulement à la demande
Intégrations externes qui cachent les credentials

Preuves complémentaires
Redémarrage contrôlé si nécessaire
Test synthétique après redéploiement
Surveillance 24h sur erreurs d'authentification
Ticket de suivi pour jobs non rejouables immédiatement

Sans cette lecture, l’équipe peut conclure trop vite que la rotation est réussie. Le vrai incident arrive parfois au prochain traitement batch, quand l’ancienne valeur a déjà été supprimée.

Rendre le rollback précis

Le rollback ne doit pas être “remettre comme avant” sans détail. Il doit préciser quelle valeur peut être réactivée, qui a le droit de le faire, combien de temps l’exception reste ouverte, et quel signal permet de reprendre la rotation. Sinon, le retour arrière devient une ouverture durable.

Rollback borné
Réactiver l'ancienne version si elle n'a pas été supprimée
Rebasculer uniquement les consommateurs en échec
Garder la nouvelle valeur disponible pour analyse
Ajouter une expiration courte à l'exception
Rejouer le test applicatif et le contrôle de logs
Planifier une nouvelle fenêtre de rotation

Le rollback est aussi une information de sécurité. Une ancienne valeur réactivée doit avoir une durée de vie explicite et un propriétaire. Elle ne doit pas rester comme dette silencieuse après stabilisation.

Automatiser sans perdre la preuve humaine

L’automatisation est utile pour générer, déposer et propager les secrets. Elle ne doit pas supprimer la preuve opérationnelle. Un pipeline de rotation doit produire un journal lisible : valeurs jamais affichées, versions concernées, consommateurs redéployés, tests exécutés, erreurs observées et décision de révocation.

Contrat d'automatisation
Aucune valeur secrète dans les logs
Identité d'exécution dédiée
Version nouvelle et version précédente tracées par identifiant
Tests post-bascule obligatoires
Révocation séparée de la création
Approbation humaine avant suppression définitive si chemin critique

Cette trace évite deux extrêmes : une rotation manuelle fragile et une rotation automatique opaque. L’exploitation a besoin d’un mécanisme reproductible, mais aussi d’éléments lisibles pendant un incident.

Conclusion

La rotation des secrets et identités de service devient fiable quand elle est traitée comme un runbook de production. Il faut inventorier les consommateurs, séparer préparation, bascule et révocation, tester avec les identités réelles, observer les erreurs après changement, et prévoir un rollback borné.

Le bon indicateur n’est pas seulement “le secret a été changé”. C’est “les consommateurs critiques utilisent la nouvelle valeur, l’ancienne n’est plus nécessaire, et l’équipe sait quoi faire si un chemin oublié échoue”. À ce niveau, la rotation cesse d’être une tâche sécurité isolée et devient une pratique d’exploitation maîtrisée.