Une clé d'accès avec des permissions de production vient d'être trouvée dans un dépôt public. Que faites-vous ?

Révoquez d'abord, enquêtez ensuite. Désactivez ou supprimez la clé immédiatement au lieu d'attendre de confirmer un usage abusif, puis émettez des identifiants de remplacement pour que les services se rétablissent. Ensuite, sortez le journal d'audit de tous les appels faits avec cette clé depuis l'exposition, en cherchant des adresses inconnues, de nouvelles identités ou des accès aux données. Traitez ça comme un incident, impliquez la sécurité, et enchaînez en supprimant le besoin même de clés statiques.

Désactiver la clé d'abord. Les gens hésitent parce qu'ils ont peur de casser quelque chose, mais la clé est publique et l'exposition se mesure en secondes ; les scanners automatiques trouvent ces choses plus vite que nous. Donc désactiver plutôt que supprimer dans un premier temps, puisque ça stoppe le risque tout en gardant l'identité pour l'enquête, puis fournir des identifiants de remplacement à ce qui en avait légitimement besoin. Ensuite le rayon d'impact. Je sors de la piste d'audit tous les appels faits avec cette clé depuis le commit, et ce qui m'intéresse c'est tout ce qui vient d'une adresse inconnue, et surtout la persistance : nouveaux utilisateurs ou rôles, nouvelles clés, politiques de confiance modifiées, parce qu'un attaquant malin utilise la clé fuitée une fois pour se créer un accès plus discret. Je vérifie aussi les lectures de données et les motifs d'exfiltration. C'est géré comme un incident de sécurité avec l'équipe sécurité impliquée, pas en douce par celui qui l'a remarqué. Après, deux suivis. Pourquoi cette identité avait-elle des clés longue durée tout court, alors que ça devrait être un rôle, et pourquoi notre analyse de secrets ne l'a-t-elle pas attrapée avant le push ? Les deux valent bien plus que la rotation elle-même.