La rotation d’un secret doit prévoir la nouvelle valeur, la période de coexistence et le retrait de l’ancienne clé avant de modifier la production.
Les mots de passe, certificats et jetons expirent ou doivent être remplacés après un incident. Une rotation improvisée peut couper une intégration ou laisser l’ancienne valeur active trop longtemps. La procédure doit être écrite et testée avec un secret sans impact.
Inventorier les usages
Identifiez les applications, tâches, webhooks et fournisseurs qui utilisent la clé. Notez le propriétaire, la date d’expiration et la procédure de remplacement. Un secret copié dans un script ou un environnement secondaire est facile à oublier.
Préparer deux valeurs
Lorsque le fournisseur le permet, créez une nouvelle clé avant de révoquer l’ancienne. Déployez la configuration qui accepte la nouvelle valeur, vérifiez un appel contrôlé, puis retirez l’ancienne. La durée de coexistence doit être courte et surveillée.
Ne placez pas les secrets dans les logs, les tickets ou les fichiers de configuration versionnés. Les règles de configuration doivent distinguer les valeurs et leurs noms logiques.
Prévoir l’échec
Un appel avec la nouvelle clé peut échouer à cause d’un format, d’un droit ou d’une horloge. Gardez une procédure de retour avec la valeur précédente uniquement pendant la fenêtre prévue. Après révocation, ne restaurez pas un secret compromis.
Vérifier les effets
Testez les lectures, écritures, tâches différées et webhooks. Surveillez les erreurs d’authentification et l’âge de la dernière opération réussie. Le suivi des erreurs doit identifier le service sans révéler la valeur.
Une rotation correcte se termine par la révocation, la mise à jour de l’inventaire et la preuve que l’ancienne valeur n’est plus utilisée.
Sources : OWASP, gestion des secrets, NIST, identités machine.