Une clé AWS exposée reste un accès tant qu’elle n’est pas supprimée

Une clé cloud exposée n’est pas un événement passé. C’est une connexion active jusqu’à preuve du contraire, rotation, suppression et vérification de ce qu’elle pouvait atteindre. C’est la leçon utile de l’étude publiée par Truffle Security en août 2026: le danger n’est pas seulement que des secrets fuient, mais que des organisations les laissent fonctionner pendant des années.

Truffle Security indique avoir collecté 431 875 découvertes vérifiées de secrets AWS, réduites à 64 024 access keys uniques dans 50 654 comptes, puis revérifié 10 616 paires complètes apparues publiquement entre août 2022 et août 2026. Résultat: 88% s’authentifiaient encore. Sur 9 308 clés actives, 817 étaient liées à des entreprises et 768 donnaient le contrôle complet d’un compte AWS: 526 clés root et 242 utilisateurs IAM avec AdministratorAccess.

BleepingComputer, The Register, TNW et d’autres médias ont repris l’affaire. Dans The Register, Corey Quinn a déplacé le débat vers AWSCompromisedKeyQuarantineV3. AWS présente cette politique comme une manière de limiter certains dégâts liés à la fraude sans affecter les ressources existantes. Le problème: la quarantaine n’est pas une remédiation. Elle peut réduire des abus évidents tout en laissant un risque sérieux.

C’est une histoire de cybersécurité sans panique parce que la réponse est concrète. Les clés root ne devraient presque jamais exister. Les clés IAM de longue durée doivent avoir un propriétaire, une durée de vie et une rotation. Un secret dans Git history, une image Docker, un log CI, un notebook ou un dataset doit être considéré comme publié. Une politique de quarantaine lance l’incident; elle ne le ferme pas.

Ce qui a été trouvé

Le grand nombre de 431 875 inclut beaucoup de répétitions: forks, miroirs, logs, images, datasets. Le chiffre le plus utile est le jeu dédupliqué et la part encore valide. Truffle Security signale 64 024 access keys uniques, puis 10 616 paires complètes revérifiées le 10 août 2026. 9 308 fonctionnaient toujours.

La partie entreprise est plus petite mais plus grave. 817 clés actives étaient liées à des organisations, et 768 donnaient un contrôle administratif complet. Certaines étaient des root keys, d’autres des utilisateurs IAM avec AdministratorAccess. Truffle Security mentionne aussi 130 clés root actives dans des comptes de gestion d’organisation. Ce n’est pas un simple secret de développeur oublié; c’est parfois la clé maîtresse du parc cloud.

L’âge aggrave le constat. L’âge médian d’une clé exposée encore active est donné à 1 831 jours. Beaucoup étaient publiques depuis des années. Truffle Security indique aussi que seulement 13,7% des clés, lorsqu’il était possible d’énumérer les access keys, avaient une clé plus récente à côté. Cela ressemble moins à une rotation qu’à un abandon.

Hugging Face apparaît comme grande source de clés exposées dans des datasets publics. Il ne faut pas le présenter comme une nouvelle intrusion chez Hugging Face. Le bon angle est que les datasets, notebooks et dépôts de modèles héritent du vieux problème des dépôts logiciels: des artefacts publics contiennent parfois des credentials.

Pourquoi root est différent

Une clé IAM peut être dangereuse. Une root access key est pire. Le root user représente le compte AWS lui-même. La documentation AWS recommande de protéger ces identifiants, d’éviter l’usage quotidien de root et de préférer IAM Identity Center, des rôles et des credentials temporaires.

La différence est le périmètre. Une identité IAM peut être limitée par permissions, conditions, boundaries et politiques d’organisation. Root se situe au-dessus d’une grande partie de cette structure. Une clé root exposée touche facturation, paramètres de compte, chemins de récupération et parfois le compte de gestion de l’organisation.

Les clés root survivent aussi aux propriétaires. Des ingénieurs partent, des comptes personnels deviennent professionnels, une vieille automatisation continue d’utiliser la seule clé qui marchait. Personne ne veut la supprimer par peur de casser la production. Cette peur explique justement le risque.

Un programme cloud sérieux doit savoir si des root access keys existent, qui les a approuvées et quand elles seront supprimées. Sans réponse, il n’y a pas de contrôle.

Supprimer une ligne ne suffit pas

La règle de base du secret scanning reste mal comprise: lorsqu’un credential atteint un artefact public, il faut le considérer copié. Le supprimer du dernier commit ne nettoie pas l’historique Git. Fermer un dépôt n’efface pas forks, mirrors, caches, couches Docker, logs CI, notebooks, index ni datasets.

Une clé AWS exposée doit donc être traitée comme un mot de passe publié. Il faut la faire tourner ou la supprimer, enquêter sur son usage, vérifier les charges qui en dépendent et inspecter l’activité. Si elle est root ou AdministratorAccess, il faut ajouter CloudTrail, facturation, inventaire de secrets et recherche de persistance.

Les développeurs retiennent parfois: “j’ai retiré la ligne”. La bonne conclusion est: “la ligne a révélé un credential à remplacer”. C’est la différence entre nettoyer un fichier et fermer un accès.

Les images Docker et les datasets ML compliquent tout. Une clé peut rester dans une couche ancienne, une sortie de notebook, un log de debug, un corpus ou une archive ZIP. La gestion des secrets doit donc dépasser le dépôt principal.

Ce que signifie la quarantaine AWS

AWSCompromisedKeyQuarantineV3 est une politique gérée par AWS. La documentation dit qu’elle s’applique à des credentials IAM compromis ou exposés publiquement, afin de refuser certaines actions et limiter les dégâts liés à la fraude sans impacter les ressources existantes.

Cette dernière phrase est essentielle. C’est une réduction de risque, pas une correction complète. Une clé en quarantaine reste un signal d’incident. Elle ne prouve pas que le compte est sûr. Si la politique évite de casser les ressources existantes, certaines interactions existantes peuvent continuer.

La critique de Corey Quinn porte sur ce risque résiduel: bases de données, sessions d’administration, AssumeRole, perturbation de journaux, messagerie, lecture de secrets, sauvegardes et changements d’infrastructure. Il n’est pas nécessaire de donner un mode d’emploi offensif pour comprendre le point défensif: quarantine is a temporary guardrail, not incident closure.

Le compromis est réel. Désactiver automatiquement toute clé publique peut casser la production d’un client. La laisser s’authentifier évite l’outage mais conserve l’exposition. Les organisations doivent donc avoir leur propre playbook de rotation rapide.

À vérifier maintenant

Commencez par root. Dans chaque compte AWS, vérifiez l’existence de root access keys. S’il y en a, identifiez le motif, le propriétaire, le dernier usage et la date de suppression. Pour la plupart des entreprises, l’état cible est aucune clé root. Le root user doit être protégé par MFA et réservé aux rares tâches nécessaires.

Inventoriez les IAM access keys. Classez par âge, dernier usage, propriétaire, workload et niveau de permission. Les clés avec AdministratorAccess, permissions larges, pas de propriétaire, pas d’usage récent ou pas de date de rotation sont prioritaires.

Cherchez les attachements AWSCompromisedKeyQuarantine. Si AWS a appliqué la quarantaine, traitez cela comme un signal d’incident. Localisez le credential, faites-le tourner, supprimez l’ancien, vérifiez CloudTrail, facturation, anomalies de budget et chemins d’AssumeRole.

Scannez plus que le code. Incluez historique Git, forks, registres publics, images de conteneur, logs de build, variables CI, notebooks, bundles de support, datasets publics et dépôts de modèles. Les secrets vivent maintenant dans des artefacts de données autant que dans du code.

Remplacez les credentials statiques. Pour CI/CD, utilisez OIDC federation et des rôles de courte durée. Pour les humains, IAM Identity Center ou accès fédéré. Pour les workloads, des rôles d’instance, tâche, pod ou service. Les clés statiques legacy doivent rester des exceptions avec propriétaire, expiration et surveillance.

Corriger sans casser la production

La peur de l’outage explique beaucoup de clés encore valides. Supprimer une clé inconnue peut casser build, backup, pipeline ou vieux service. La solution n’est pas de la garder; c’est de tourner avec preuves.

Identifiez d’abord le principal et les services utilisés. CloudTrail, données last accessed, logs applicatifs et anomalies de coûts aident. Puis trouvez le propriétaire, créez une voie de remplacement plus limitée, déployez avec monitoring et supprimez l’ancienne clé. Si la suppression doit attendre, l’exception doit avoir une date, un responsable et des contrôles compensatoires.

Pour root et AdministratorAccess, supposez un usage possible par un tiers. Revoyez activité API, accès aux secrets, AssumeRole, changements IAM, politiques de buckets, backups et dépenses inhabituelles. Activez budget alerts et détection d’anomalies.

L’objectif est de pratiquer la rotation avant l’urgence. Une équipe qui sait remplacer un credential répond en heures. Une équipe sans propriétaires négocie des semaines avec une clé compromise.

Conclusion calme

L’étude ne signifie pas que chaque compte AWS est compromis. Elle ne dit pas non plus que la quarantaine AWS est inutile ou qu’il faut supprimer des clés au hasard. La panique casse la production; le déni crée des incidents.

La réponse proportionnée: traiter tout credential public comme compromis, supprimer les root keys, remplacer les clés IAM longues par rôles et fédération, scanner les vrais artefacts modernes, réagir aux quarantaines, pratiquer la rotation et garder les alertes de budget.

Le plus gênant est que l’accès cloud échoue silencieusement. Une clé fuit, un scanner alerte, le fournisseur limite certaines actions, quelqu’un supprime une ligne, puis tout continue. Mais le credential s’authentifie encore. C’est cela qu’il faut corriger: ownership, inventory, credentials courts et discipline opérationnelle.