Réagir à un secret compromis : révoquer, tourner, analyser

Dès qu'un secret est exposé, mot de passe, clé d'API ou jeton d'accès, considérez-le comme déjà utilisé par un attaquant. La bonne réaction n'est pas d'enquêter d'abord, mais de couper l'accès immédiatement : on révoque, puis on crée un nouveau secret, puis seulement on analyse ce qui a pu se passer. Cette page décrit la procédure d'incident en cinq temps, sans aucun prérequis technique, pour que vous sachiez quoi faire dans le bon ordre le jour où une clé fuite.

Ce que vous allez apprendre

Un secret est une information confidentielle qui prouve une identité ou déverrouille un accès : un mot de passe, une clé d'API (une chaîne de caractères qui autorise un programme à en appeler un autre), un jeton d'accès (un laissez-passer temporaire vers un service). Quand l'un d'eux échappe à votre contrôle, on parle de secret compromis ou de fuite de secret. Concrètement, vous saurez :

Reconnaître qu'un secret exposé est considéré comme déjà compromis, même sans preuve d'utilisation.
Dérouler la procédure d'incident en cinq temps : détecter, révoquer, tourner, analyser, prévenir.
Distinguer révoquer (couper l'accès) et tourner (remplacer par un nouveau secret), et comprendre pourquoi l'un ne remplace pas l'autre.
Éviter les pièges classiques, comme tourner un secret sans révoquer l'ancien.
Passer à l'action en reliant cette procédure à la détection de secrets et au modèle de menaces SOCLE des secrets.

Que faire quand un secret fuite

Le principe fondateur de toute réaction à une fuite tient en une phrase : un secret exposé est un secret compromis. Dès qu'une clé apparaît dans un dépôt public, un message de discussion, un journal de logs ou une capture d'écran, vous devez partir du principe qu'un attaquant l'a déjà copiée et s'en sert peut-être en ce moment même. Attendre d'avoir la preuve d'un abus, c'est laisser la porte ouverte pendant l'enquête.

Réagir à un secret compromis : détecter, révoquer, tourner, analyser, prévenir, dans cet ordre

Cette logique vient du fait que les robots d'exploration surveillent en permanence les dépôts publics. Une clé poussée par erreur sur un projet ouvert peut être récupérée en quelques secondes, bien avant que vous ne remarquiez votre erreur. On ne peut pas savoir si l'attaquant a été plus rapide que vous, alors on agit comme s'il l'avait été. C'est le réflexe qui sépare un incident maîtrisé d'une catastrophe.

La réponse s'organise en cinq temps, toujours dans cet ordre :

Détecter : repérer que le secret a fuité, où, et de quel secret il s'agit.
Révoquer : invalider immédiatement le secret exposé pour couper l'accès qu'il ouvrait.
Tourner : générer un nouveau secret et le distribuer aux systèmes qui en ont besoin, pour rétablir le service.
Analyser : enquêter sur la portée, où le secret a pu être utilisé, ce qui a pu être consulté ou modifié.
Prévenir : corriger la cause pour que la même fuite ne se reproduise pas.

Deux mots méritent une définition précise, car on les confond souvent. Révoquer un secret, c'est le déclarer invalide auprès du service qui le reconnaît : le service refuse désormais toute demande présentant cet ancien secret, comme une banque qui bloque une carte volée. Tourner un secret, aussi appelé rotation, c'est le remplacer par un nouveau : on crée une clé fraîche, on la met en place dans les systèmes légitimes, et l'ancienne cesse d'être utilisée. Révoquer regarde vers le passé, on ferme l'ancien accès ; tourner regarde vers le présent, on rétablit un accès sain.

Révoquer avant d'enquêter : pourquoi l'ordre compte

L'erreur la plus coûteuse consiste à vouloir comprendre avant d'agir. Face à une fuite, la tentation est forte d'ouvrir les journaux, de chercher qui a poussé la clé, d'évaluer les risques, puis de décider. Pendant toute cette réflexion, le secret exposé reste valide, et l'attaquant, lui, n'attend pas. L'enquête peut prendre des heures ; la copie d'une clé prend une seconde.

C'est pourquoi la révocation passe en premier, avant même l'analyse. Révoquer coupe net l'accès qu'ouvrait l'ancien secret. Même si un attaquant en possède une copie, elle ne lui sert plus à rien : le service la rejette. Vous transformez une porte grande ouverte en porte condamnée, et vous le faites en quelques minutes, sans savoir encore l'ampleur exacte de l'incident. L'analyse détaillée peut alors se dérouler tranquillement, car le danger immédiat est écarté.

Il faut bien comprendre que tourner seul ne suffit pas. Générer un nouveau secret pour vos systèmes ne rend pas l'ancien inoffensif. Si l'ancien reste valide en parallèle, l'attaquant continue de s'en servir pendant que vos équipes utilisent le nouveau, sans que rien n'alerte. Vous avez l'illusion d'avoir réglé le problème, alors que la fuite reste exploitable. La rotation ne protège que si l'ancien secret est explicitement révoqué, ou si le fait d'en créer un nouveau invalide automatiquement le précédent, ce qui dépend du service.

Analyser la portée

Une fois l'accès coupé et le service rétabli, vient le temps de l'analyse de portée : mesurer ce que l'attaquant a pu faire tant que le secret était valide. C'est une étape d'enquête, pas d'urgence, et c'est justement pour ça qu'elle vient après la révocation. On veut répondre à trois questions : à quoi ce secret donnait-il accès, a-t-il été utilisé par quelqu'un d'autre que vous, et si oui, qu'a-t-il consulté ou modifié.

La matière première de cette enquête, ce sont les journaux d'accès (les fichiers où un service enregistre chaque connexion et chaque action, avec l'heure et l'origine). En les relisant, on cherche des usages anormaux : des connexions depuis une adresse inconnue, à des heures inhabituelles, ou des actions que personne dans l'équipe ne reconnaît. Un service correctement configuré conserve aussi des journaux d'audit, plus détaillés, qui tracent les opérations sensibles comme la lecture de données ou la création de nouveaux comptes.

L'objectif de cette analyse est double. D'abord évaluer les dégâts : si l'attaquant a lu une base de clients, vous devez peut-être notifier ces personnes ou une autorité, selon la réglementation. Ensuite déterminer la fenêtre d'exposition : depuis combien de temps le secret circulait-il, ce qui vous dit sur quelle période chercher des traces. Un secret fuité il y a une heure et un secret exposé depuis six mois n'appellent pas la même enquête.

Prévenir la prochaine fois

Éteindre l'incident ne suffit pas : sans correction de la cause, la même fuite reviendra. La prévention repose sur quelques mesures qui réduisent à la fois la probabilité d'une fuite et son impact quand elle survient malgré tout.

La première est la détection de fuite : des outils qui scannent en continu le code, les dépôts et les journaux à la recherche de secrets exposés, pour vous prévenir en minutes plutôt qu'en semaines. Plus la détection est rapide, plus la fenêtre d'exposition est courte. La deuxième est la rotation automatique : faire changer les secrets régulièrement et sans intervention manuelle, de sorte qu'un secret volé cesse d'être valide de lui-même au bout d'un moment.

La troisième mesure est la durée de vie courte, souvent appelée TTL (Time To Live, la durée pendant laquelle un secret reste valide avant d'expirer). Un jeton qui n'est valable que quinze minutes ne vaut presque rien pour un attaquant : le temps qu'il l'exploite, il a déjà expiré. La quatrième est le moindre privilège : donner à chaque secret le strict minimum de droits nécessaires. Une clé qui ne peut que lire une seule ressource fait beaucoup moins de dégâts qu'une clé qui peut tout faire partout.

Le mettre en oeuvre

Cette page décrit la procédure et le raisonnement ; les guides pratiques montrent comment l'appliquer avec de vrais outils. Pour repérer les secrets qui fuitent avant qu'un attaquant ne les trouve, la détection de secrets explique comment scanner votre code et vos dépôts, et comment brancher cette vérification sur vos processus de développement.

Pour la partie rotation et durée de vie, le cycle de vie d'un secret détaille comment un secret naît, vit, tourne et expire, et comment automatiser ces étapes plutôt que de les faire à la main. Ces deux guides transforment les principes de cette page en gestes concrets et reproductibles.

Pièges courants

La procédure est simple à énoncer, mais quelques erreurs reviennent régulièrement et annulent une bonne partie de vos efforts. Les connaître à l'avance vous évite de croire l'incident réglé alors qu'il ne l'est qu'à moitié.

Le piège le plus fréquent est de tourner sans révoquer. On crée un nouveau secret, on le déploie, on souffle, et on oublie d'invalider l'ancien. Tant que l'ancien reste valide, l'attaquant garde son accès. La rotation vous a rassuré à tort : la porte d'origine est toujours ouverte, en parallèle de la nouvelle.

Le deuxième piège est d'oublier les copies. Un secret ne fuit jamais à un seul endroit. La clé poussée dans le code se retrouve aussi dans l'historique Git (la mémoire de toutes les versions passées d'un dépôt, où le secret reste lisible même après suppression du fichier), dans les journaux de logs, dans les images de conteneurs (des paquets figés qui embarquent une application et ses fichiers) et parfois dans des sauvegardes. Supprimer la ligne visible ne retire pas le secret de tous ces endroits. La seule protection fiable reste la révocation : une clé invalidée ne sert plus, où qu'elle traîne encore.

Le troisième piège est de retarder la révocation par peur de casser un service en production. C'est un mauvais calcul : un service momentanément interrompu est moins grave qu'un accès laissé ouvert à un intrus. La bonne approche est de préparer la rotation pour rétablir vite, pas de repousser la coupure.

À retenir

Un secret exposé est un secret compromis : agissez comme s'il était déjà utilisé, sans attendre la preuve d'un abus.
Révoquer d'abord, enquêter ensuite : couper l'accès de l'ancien secret est prioritaire sur l'analyse, car l'attaquant n'attend pas.
Tourner ne remplace pas révoquer : créer un nouveau secret rétablit le service mais ne ferme pas l'ancien accès s'il reste valide.
Analyser la portée après coup : les journaux d'accès et d'audit disent ce que l'attaquant a pu voir ou modifier pendant l'exposition.
Chercher toutes les copies : historique Git, journaux, images de conteneurs, une même clé fuite à plusieurs endroits à la fois.
Prévenir en réduisant l'impact : détection rapide, rotation automatique, durée de vie courte et moindre privilège limitent les dégâts d'une future fuite.
Ancrez la procédure au socle : la détection et la procédure de révocation répondent à l'exigence SOCLE-SEC-GEN-6, la rotation à SOCLE-SEC-GEN-4, détaillées dans le modèle de menaces SOCLE des secrets.

Prochaines étapes

Détecter les secrets exposés Scanner code et dépôts pour repérer une fuite avant un attaquant.

Cycle de vie d'un secret Naissance, rotation, expiration : automatiser plutôt que gérer à la main.

Secrets dans le code et Git Nettoyer un secret poussé dans un dépôt et son historique.

Modèle de menaces SOCLE des secrets Les attaques visant les secrets et les contrôles qui les couvrent.