Révoquer et renouveler les secrets exposés

Une fois la fuite d’un identifiant confirmée, la rapidité compte, mais l’ordre des actions aussi. Désactiver brutalement une clé peut interrompre la production si vous ne comprenez pas d’abord ce qui en dépend.

L’objectif est de couper l’accès à l’attaquant tout en maintenant les charges de travail légitimes, idéalement au moyen d’une séquence unique et répétée à l’avance.

La première action à effectuer pour une clé d’accès divulguée est de la désactiver, et non de la supprimer. Définir son état sur Inactive l’empêche immédiatement de fonctionner.

La conserver (inactive) pour le moment permet de la corréler aux éléments d’investigation dans CloudTrail. Vous ne la supprimez qu’une fois l’enquête terminée.

Pour les utilisations légitimes, la rotation consiste à émettre une nouvelle clé d’accès, à mettre à jour chaque emplacement utilisant l’ancienne, puis à désactiver la clé compromise.

Procéder dans cet ordre évite une interruption : le nouvel identifiant est actif avant la désactivation de l’ancien. Vérifiez toujours d’abord que l’application fonctionne avec la nouvelle clé.

La désactivation d’une clé à long terme ne met pas fin aux identifiants temporaires qu’elle a éventuellement déjà produits. Pour les rôles, utilisez la fonctionnalité IAM de révocation des sessions, qui associe une stratégie de refus fondée sur une heure limite d’émission des jetons.

Cette opération invalide toutes les sessions actives antérieures à ce moment et ferme ainsi la porte aux identifiants déjà détenus par l’attaquant.

Avant d’effectuer la rotation, déterminez où se trouve le secret. CloudTrail indique quels services et quelles adresses IP ont utilisé la clé.

Un secret inscrit en dur à de nombreux endroits montre précisément pourquoi cette pratique est dangereuse. Cartographier chaque consommateur garantit que la rotation ne laissera pas un système oublié en panne ni une copie du secret encore active.

AWS Secrets Manager stocke des secrets tels que des mots de passe de bases de données et des clés d’API, et peut les renouveler automatiquement selon une planification au moyen d’une fonction Lambda.

La rotation automatique signifie qu’un secret divulgué reste utile peu de temps et que les applications récupèrent la valeur actuelle lors de leur exécution au lieu de conserver une copie obsolète inscrite en dur.

Un identifiant divulgué en déverrouille souvent d’autres. Si un attaquant a utilisé une clé pour lire une base de données, les mots de passe de cette base peuvent également être compromis.

Renouvelez aussi les secrets en aval. Réfléchissez à toute la chaîne : chaque secret auquel l’attaquant a pu accéder doit être considéré comme exposé et remplacé.

Si AWS détecte une exposition, le service peut associer AWSCompromisedKeyQuarantineV2 à l’utilisateur, ce qui refuse les actions à haut risque tout en vous permettant de poursuivre l’enquête.

Ne la détachez pas simplement pour passer à autre chose. Considérez-la comme un signal indiquant que les mesures correctives réelles — désactivation, rotation et examen — doivent encore être effectuées par vos soins.

La rotation empêche les abus futurs, mais n’annule pas les dommages passés. Utilisez CloudTrail pour répertorier chaque action effectuée par l’identifiant compromis.

Annulez les modifications malveillantes : supprimez les utilisateurs IAM indésirables, retirez les clés de porte dérobée et démanteler les ressources créées par l’attaquant. Le confinement et le nettoyage sont deux étapes distinctes et nécessaires.

Après la récupération, réduisez les risques futurs. Remplacez les clés à long terme par des identifiants temporaires fondés sur des rôles, activez la rotation automatique des secrets et ajoutez la recherche de secrets à votre chaîne d’intégration et de déploiement continus.

La correction la plus solide est architecturale : s’il n’existe aucun secret statique susceptible d’être divulgué, l’attaquant n’a rien à trouver.

La remédiation n’est pas terminée tant qu’elle n’est pas consignée. Documentez les identifiants renouvelés, les actions de l’attaquant et les éléments restaurés.

Informez les parties prenantes indiquées dans votre guide d’intervention et, si des données réglementées ont été exposées, respectez vos obligations de notification de violation. Un compte rendu clair transforme l’incident en leçon et répond aux audits ultérieurs.

Choisissez la première action appropriée.

Pour remédier à la fuite d’un identifiant, désactivez la clé d’accès (en la conservant à des fins d’analyse judiciaire), effectuez une rotation vers une nouvelle clé sans interruption de service et révoquez les sessions de rôle actives afin d’invalider les identifiants temporaires déjà délivrés. Recensez d’abord chaque consommateur, renouvelez les secrets en aval auxquels l’attaquant a pu accéder et annulez les modifications malveillantes à partir de CloudTrail. Utilisez Secrets Manager pour automatiser la rotation et adoptez des identifiants temporaires fondés sur les rôles afin d’éviter les récidives.