En bref

  • Truffle Security a recensé plus de 9 300 clés d'accès AWS exposées publiquement et toujours actives, dont 768 accordant un accès administrateur complet à des comptes d'entreprises réelles.
  • Parmi ces 768 clés critiques, 526 sont des root keys — le niveau d'accès le plus élevé dans AWS — et 130 contrôlent des organization management accounts exposant potentiellement l'intégralité du portefeuille cloud d'une organisation.
  • Auditer immédiatement les dépôts de code, fichiers de configuration et images Docker à la recherche de credentials AWS exposés, puis révoquer et remplacer sans délai toute clé identifiée.

9 300 clés AWS actives exposées : quatre ans d'observation par Truffle Security

Truffle Security, société spécialisée dans la détection de secrets exposés, a publié les résultats d'une étude longitudinale couvrant quatre années — d'août 2022 à août 2026. Le constat est alarmant : plus de 9 300 clés d'accès AWS (Amazon Web Services) exposées publiquement au cours de cette période demeurent actives et valides au moment de la publication. Ces credentials, accessibles à quiconque sait où chercher — dépôts GitHub publics, fichiers de configuration, pages de documentation, images Docker publiques — offrent une porte d'entrée directe dans des infrastructures cloud d'entreprises réelles. L'étude a été relayée cette semaine par BleepingComputer et Cybernews, qui soulignent tous deux l'ampleur inédite du problème.

Sur ces 9 300 clés actives, Truffle Security en a identifié 817 directement liées à des comptes d'entreprises. C'est sur ce sous-ensemble corporate que les chiffres atteignent un niveau critique : 768 de ces clés accordent un accès administrateur complet au compte AWS concerné. Cette catégorie se divise en deux types : 526 sont des clés racine (root keys), le niveau d'accès le plus élevé possible dans AWS, non soumis à aucune restriction de politique IAM ; les 242 restantes sont des clés IAM bénéficiant de la politique AdministratorAccess, équivalant à un accès illimité à l'ensemble des services et ressources du compte. Dans les deux cas, un attaquant en possession de l'une de ces clés dispose du contrôle total sur l'environnement AWS visé.

La dimension la plus préoccupante de cette étude concerne les 130 root keys identifiées sur des organization management accounts. Dans une hiérarchie AWS Organizations, le compte de gestion dispose d'un contrôle total sur tous les comptes membres de l'organisation. La compromission d'une seule root key de management account expose potentiellement l'intégralité du portefeuille cloud d'une entreprise : tous ses comptes enfants, toutes ses ressources de production, toutes ses données stockées sur S3, toutes ses instances EC2 et tous ses services managés. Un seul secret mal gardé peut suffire à compromettre une infrastructure cloud entière représentant des années d'investissement.

Truffle Security souligne que 86 % des clés identifiées n'ont pas de clé de remplacement plus récente associée au même compte, signifiant qu'elles n'ont jamais été révoquées ni remplacées malgré leur exposition publique. Cette statistique illustre un problème systémique profond : la rotation des secrets est une pratique déficiente dans la grande majorité des organisations touchées. AWS recommande depuis des années la rotation régulière des clés d'accès et, idéalement, l'abandon des clés long terme au profit de rôles IAM avec des credentials temporaires générés par AWS STS (Security Token Service) — une recommandation clairement documentée dans le AWS Well-Architected Framework.

Les vecteurs d'exposition documentés par l'étude sont multiples et récurrents. Les dépôts GitHub publics contenant des fichiers .env accidentellement committés restent le principal canal. Viennent ensuite les fichiers de configuration (aws/credentials, .boto, terraform.tfvars) inclus dans des archives ou des images Docker publiées sur Docker Hub, les réponses de support technique contenant des credentials copiés-collés, les documentations techniques publiées sur des wikis publics, et les logs d'application qui journalisent accidentellement des variables d'environnement contenant des secrets.

L'impact financier est directement mesurable : parmi les comptes analysés dans l'étude, les dépenses AWS agrégées pour le seul mois de juillet 2026 atteignaient 420 631 dollars. Les activités malveillantes typiquement observées sur des comptes AWS compromis comprennent le déploiement d'instances EC2 à haute performance pour le minage de cryptomonnaies (cryptojacking), la création d'infrastructures de spam et de phishing utilisant Amazon SES, le stockage de contenus illicites sur S3, ou la revente de capacité de calcul sur des marchés souterrains. Amazon Web Services dispose de mécanismes de détection automatique, mais la fenêtre d'exploitation peut se mesurer en heures avant qu'un compte ne soit suspendu.

Cette étude s'inscrit dans une tendance documentée de longue date. GitGuardian a rapporté dans son rapport 2025 que plus de 12,8 millions de secrets étaient exposés dans les seuls dépôts GitHub publics, avec un taux de révocation inférieur à 1 % dans les 24 heures suivant l'exposition. AWS a renforcé ses contrôles en 2024 avec un programme de détection automatique de secrets en partenariat avec GitHub, permettant la notification automatique des propriétaires de compte lorsqu'une clé est détectée dans un dépôt public. Mais ces protections ne couvrent pas tous les vecteurs identifiés par Truffle Security, notamment les images Docker publiques, les wikis d'entreprise et les archives de code tierces.

La démocratisation des outils de développement assistés par IA ajoute une dimension supplémentaire au problème. Des assistants comme GitHub Copilot peuvent suggérer des extraits de code incluant des patterns de configuration qui encouragent l'usage de variables hardcodées. Les développeurs travaillant sous pression sont susceptibles d'accepter ces suggestions sans vérifier systématiquement qu'aucun secret n'est inclus dans le code généré. La sensibilisation reste l'un des maillons les plus faibles de la chaîne de sécurité des credentials cloud, et cette étude de Truffle Security en fournit une démonstration quantifiée saisissante.

Pourquoi une clé AWS admin exposée est un scénario de compromission immédiate

L'exposition de clés AWS administrateur représente l'un des scénarios de compromission cloud les plus dévastateurs et les plus simples à exploiter. Contrairement à une vulnérabilité applicative qui requiert un exploit complexe, une clé AWS valide suffit à un attaquant pour prendre le contrôle total d'une infrastructure cloud en quelques minutes. Qualys a documenté en juillet 2026 le concept de « sub-10-minute cloud takeover » : avec une clé AdministratorAccess, un attaquant peut en moins de dix minutes créer de nouveaux utilisateurs IAM avec des droits complets (pour maintenir l'accès même après révocation de la clé originale), désactiver AWS CloudTrail, exfiltrer l'intégralité des buckets S3, déployer des instances pour le minage, et pivoter vers d'autres comptes AWS liés via des rôles cross-account.

Des groupes cybercriminels comme Scattered Spider et TeamTNT ont développé des outils sophistiqués pour scanner en temps réel les dépôts GitHub, les pâtes publiques et les résultats de moteurs de recherche spécialisés comme Shodan et Censys, à la recherche de secrets exposés. La fenêtre entre l'exposition accidentelle d'une clé et sa première utilisation malveillante se mesure désormais en minutes. Cette automatisation rend illusoire l'idée qu'une clé exposée brièvement puis révoquée n'a pas été compromise — elle doit être considérée comme compromise dès sa première exposition publique.

La dimension réglementaire est également significative pour les organisations européennes. Le RGPD impose des mesures techniques et organisationnelles pour protéger les données personnelles ; une compromission d'infrastructure cloud résultant de l'exposition de clés AWS constitue très probablement une violation de données notifiable auprès des autorités compétentes dans les 72 heures. NIS2, en vigueur depuis octobre 2024 pour les entités essentielles et importantes en Europe, impose des obligations similaires avec des sanctions potentiellement substantielles. Les organisations dont des clés AWS sont exposées mais n'ont pas encore subi d'incident vivent dans un état de vulnérabilité réglementaire latente.

Pour les CISO et les équipes cloud security, cette étude soulève une question fondamentale de gouvernance des secrets. La gestion des secrets (secrets management) est un domaine mature avec des solutions éprouvées — AWS Secrets Manager, HashiCorp Vault, Doppler — mais leur adoption reste partielle, notamment dans les équipes gérant des projets legacy ou sous contrainte de délais. L'audit régulier des secrets exposés via des outils comme truffleHog, Gitleaks ou les alertes GitHub Secret Scanning, associé à l'interdiction des clés d'accès long terme au profit de rôles IAM temporaires, doit être intégré aux processus DevSecOps comme une priorité absolue et non négociable.

Ce qu'il faut retenir

  • 768 clés AWS corporate avec accès administrateur complet sont actuellement actives et exposées en ligne, dont 526 root keys qu'aucune politique IAM ne peut restreindre.
  • 130 de ces root keys contrôlent des organization management accounts, exposant potentiellement l'ensemble du portefeuille cloud d'organisations entières via un seul credential.
  • Auditer sans attendre les dépôts de code (y compris l'historique git), les images Docker et les fichiers de configuration à la recherche de credentials AWS ; activer GitHub Secret Scanning et AWS GuardDuty ; migrer vers des rôles IAM temporaires via AWS STS.

Comment détecter si des clés AWS de mon organisation sont exposées en ligne ?

Activez GitHub Secret Scanning (partenariat AWS/GitHub pour la notification automatique), utilisez truffleHog ou Gitleaks sur l'historique complet de vos dépôts, configurez AWS Config et AWS GuardDuty pour détecter les usages anormaux, et vérifiez régulièrement AWS IAM Access Analyzer pour identifier les politiques trop permissives. La règle fondamentale reste de ne jamais créer de root key AWS et d'utiliser AWS IAM Identity Center avec des credentials temporaires à la place de clés d'accès long terme.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact