Réagir à un secret compromis : révoquer, renouveler, 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 : on révoque, on crée un nouveau secret, puis seulement on analyse ce qui a pu se passer. Cette leçon décrit cette procédure en cinq temps, pour que vous sachiez quoi faire, dans le bon ordre, le jour où une clé fuite.

Trois faits la rendent concrète. gitleaks 8.30.1 retrouve un jeton GitHub dans l'historique alors que le fichier a été supprimé. GitHub fournit une API de révocation publique, utilisable par quiconque trouve un jeton. Et chez AWS, désactiver une clé d'accès ne coupe pas les sessions temporaires déjà obtenues avec elle : elles restent valides jusqu'à leur expiration.

Ce que vous allez apprendre

Un secret est une information confidentielle qui prouve une identité ou déverrouille un accès. 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 compromis, même sans preuve d'utilisation
• Dérouler la procédure en cinq temps : détecter, révoquer, renouveler, analyser, prévenir
• Distinguer révoquer (couper l'accès) et renouveler (remplacer le secret)
• Couper aussi ce que le secret a déjà ouvert : sessions, baux, jetons dérivés
• Éviter les pièges classiques, comme renouveler un secret sans révoquer l'ancien
• Répondre à l'exigence SOCLE-SEC-GEN-6 : détection de fuite et procédure de réponse

Que faire quand un secret fuite

Le principe fondateur 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 ou une capture d'écran, partez du principe qu'un attaquant l'a copiée. Attendre la preuve d'un abus, c'est laisser la porte ouverte pendant l'enquête.

Cette logique vient du fait que des robots parcourent en permanence les dépôts publics à la recherche de clés. 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 procédure en cinq temps

La réponse s'organise en cinq temps, dans l'ordre du schéma. La révocation, en rouge, passe en deuxième, avant toute analyse ; la boucle en pointillés rappelle que la prévention a pour premier effet de raccourcir la prochaine détection.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

1. Détecter : repérer la fuite, où, et de quel secret il s'agit.
2. Révoquer : invalider immédiatement le secret exposé.
3. Renouveler : générer un nouveau secret et le distribuer aux systèmes légitimes.
4. Analyser : mesurer la portée, ce qui a pu être lu ou modifié.
5. Prévenir : corriger la cause pour que la fuite ne se reproduise pas.

L'OWASP décrit la même séquence dans sa Secrets Management Cheat Sheet : révoquer immédiatement, renouveler, supprimer les copies jusque dans l'historique Git et les journaux, puis journaliser les accès pour l'enquête.

Révoquer et renouveler : deux gestes différents

Deux mots méritent une définition précise, car on les confond. 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 qui le présente, comme une banque qui bloque une carte volée. Renouveler (faire une rotation), c'est le remplacer par un nouveau, mis en place dans les systèmes légitimes.

Révoquer regarde vers le passé, on ferme l'ancien accès ; renouveler regarde vers le présent, on rétablit un accès sain. Certains services font les deux d'un coup, la création d'une nouvelle clé invalidant l'ancienne ; beaucoup ne le font pas, et c'est ce qu'il faut vérifier chez chaque fournisseur.

Détecter : la fuite survit au fichier

La détection repose sur des outils qui cherchent des formats de secrets connus et des chaînes à forte entropie. Le piège est de ne scanner que les fichiers présents : un secret supprimé au commit suivant reste dans l'historique, donc dans chaque clone du dépôt.

Mesuré avec gitleaks 8.30.1 sur un dépôt où un jeton ghp_ a été commité dans deploy.env puis supprimé : le mode dir ne trouve rien, le mode git trouve le jeton dans le premier commit et sort en code 1, ce qui suffit à faire échouer un job de CI.

$ gitleaks dir . --no-banner
INF no leaks found

$ gitleaks git . --no-banner --redact -v
RuleID:      github-pat
File:        deploy.env
Commit:      d400395794befbc7039f5fdad842ea1aa9f0f197
...
WRN leaks found: 1
$ echo $?
1

Le commit et le fichier donnés par gitleaks sont le point de départ de l'enquête : ils datent l'exposition. La leçon sur Gitleaks montre comment brancher ce scan en pré-commit et en CI pour raccourcir la fenêtre.

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é, puis de décider. Pendant ce temps, le secret exposé reste valide, et l'attaquant n'attend pas : l'enquête prend des heures, la copie d'une clé une seconde.

C'est pourquoi la révocation passe en premier. Même si un attaquant possède une copie, elle ne lui sert plus : le service la rejette. L'analyse se déroule ensuite sans urgence, le danger immédiat étant écarté. Le prix est une coupure possible du service légitime, le temps de déployer le nouveau secret : c'est un prix acceptable face à un accès laissé ouvert.

Ce que la révocation doit aussi couper

Révoquer la clé ne suffit pas toujours : il faut couper ce qu'elle a déjà ouvert. Le cas le plus traître est celui d'AWS : la documentation IAM précise que des identifiants temporaires restent valides jusqu'à leur expiration, jusqu'à 36 heures, même après désactivation de la clé qui les a obtenus. Il faut alors retirer les permissions de l'utilisateur ou du rôle.

Service	Révoquer le secret	Couper aussi
GitHub (jeton ghp_, github_pat_)	Supprimer le jeton, ou l'API publique POST /credentials/revoke	Ce que le jeton a pu créer pendant l'exposition : clés de déploiement, webhooks, autres jetons
AWS (clé AKIA...)	aws iam update-access-key --status Inactive, puis delete-access-key	Sessions temporaires déjà émises : politique de refus, ou révocation des sessions du rôle
Vault / OpenBao	vault token revoke ou vault lease revoke	Tous les baux d'un chemin : vault lease revoke -prefix

Glissez pour voir

L'API de révocation de GitHub a une particularité : elle s'appelle sans authentification, et une requête authentifiée reçoit même un refus 403. Elle accepte jusqu'à 1000 jetons par appel (classiques, fins, OAuth, d'applications GitHub), et le propriétaire du jeton est notifié. Quiconque trouve un jeton fuité peut donc le neutraliser sans en être le propriétaire.

Pour un secret dynamique, la révocation est la plus nette. Mesuré sur Vault 2.1.1 avec PostgreSQL 17 : vault lease revoke -prefix database/creds/app supprime tous les utilisateurs créés par le rôle, et la base n'en compte plus aucun. La leçon sur le cycle de vie détaille cette mesure.

Renouveler n'est pas révoquer

Créer un nouveau secret rétablit votre service, mais ne ferme pas forcément l'ancien accès. Vérifiez toujours que le secret compromis est invalidé, en tentant de l'utiliser et en constatant l'échec. Deux clés valides en même temps, ce sont deux portes ouvertes.

Analyser la portée

Une fois l'accès coupé et le service rétabli, vient 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 pour cela qu'elle vient après la révocation. Elle répond à trois questions : à quoi le secret donnait-il accès, a-t-il été utilisé par quelqu'un d'autre, et si oui, pour faire quoi.

La matière première est faite de journaux d'accès (chaque connexion et chaque action, avec l'heure et l'origine) et de journaux d'audit, plus détaillés, qui tracent les opérations sensibles. On y cherche des usages anormaux : adresse inconnue, horaire inhabituel, action que personne ne reconnaît. Chez AWS, CloudTrail et aws iam get-access-key-last-used disent si et quand la clé a servi.

L'objectif est double. D'abord évaluer les dégâts : si l'attaquant a lu une base de clients, il faut peut-être notifier ces personnes ou une autorité, selon la réglementation. Ensuite déterminer la fenêtre d'exposition, du commit fautif identifié par gitleaks jusqu'à la révocation : un secret fuité depuis 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 quatre 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 : des outils qui scannent le code, les dépôts et les journaux en continu, pour prévenir en minutes plutôt qu'en semaines. La deuxième est la rotation automatique : un secret volé cesse d'être valide de lui-même au bout d'un moment. La troisième est la durée de vie courte, le TTL (Time To Live) : un jeton valable quinze minutes ne vaut presque rien une heure après le vol.

La quatrième est le moindre privilège : une clé qui ne peut lire qu'une ressource fait beaucoup moins de dégâts qu'une clé qui peut tout faire. Ces quatre mesures transforment une catastrophe potentielle en simple incident : vous ne pourrez jamais empêcher toute fuite, mais vous pouvez faire qu'elle coûte peu.

Le mettre en oeuvre

Cette leçon décrit la procédure et son raisonnement ; d'autres montrent les outils. Pour repérer les secrets qui fuient, la détection de secrets compare gitleaks, TruffleHog et Trivy, et explique comment brancher le scan sur vos processus de développement.

Pour la révocation et la rotation, la leçon sur le cycle de vie montre comment automatiser ces étapes. Et une procédure qui n'a jamais été jouée n'existe pas : l'exigence SOCLE-SEC-ROT-3 demande le compte rendu d'un test de rotation et de révocation d'urgence, à faire à froid, avant l'incident.

Pièges courants

La procédure est simple à énoncer, mais quatre erreurs reviennent et annulent une partie de l'effort. Les connaître évite de croire l'incident réglé alors qu'il ne l'est qu'à moitié, ce qui est le pire état : plus personne ne surveille, et l'attaquant garde son accès.

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

Le deuxième est d'oublier les copies. La clé poussée dans le code se retrouve dans l'historique Git, les journaux, les images de conteneurs et parfois les sauvegardes. Supprimer la ligne visible ne la retire de nulle part, comme gitleaks le montre. La seule protection fiable reste la révocation : une clé invalidée ne sert plus, où qu'elle traîne.

Le troisième est d'oublier ce que la clé a ouvert. Une clé AWS désactivée laisse vivre les sessions temporaires déjà émises, un jeton peut avoir autorisé une application tierce. Révoquer le secret sans couper ses descendants laisse une porte entrouverte pendant des heures.

Le dernier est de retarder la révocation par peur de casser la production. C'est un mauvais calcul : un service interrompu quelques minutes est moins grave qu'un accès laissé à 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é.
• Révoquer d'abord, enquêter ensuite : l'attaquant n'attend pas la fin de l'analyse.
• Renouveler ne remplace pas révoquer : vérifiez que l'ancien secret échoue.
• Couper les descendants : chez AWS, les sessions temporaires survivent à la désactivation de la clé ; GitHub offre POST /credentials/revoke sans authentification.
• La fuite survit au fichier : gitleaks 8.30.1 la retrouve en mode git, pas en mode dir, et le commit date l'exposition.
• Analyser après coup : journaux d'accès et d'audit, fenêtre d'exposition du commit à la révocation.
• Prévenir en réduisant l'impact : détection rapide, rotation automatique, TTL court, moindre privilège.
• La preuve attendue par SOCLE-SEC-GEN-6 est un dispositif de détection de fuite de secrets et sa procédure de réponse ; le modèle de menaces des secrets détaille les attaques couvertes.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →