Des chercheurs ont découvert des milliers de clés d’accès AWS divulguées qui fonctionnent toujours, dont des centaines offrant un accès administratif complet à des comptes d’entreprise.
Truffle Security est parvenue à cette conclusion après avoir analysé 431 875 éléments publics contenant 64 024 clés d’accès AWS uniques. Sur les 10 616 paires de clés complètes que les chercheurs ont vérifiées à nouveau, 9 308 s’authentifiaient toujours auprès d’AWS. Bien que le nombre de clés actives soit faible comparé aux chiffres initiaux, le risque réside dans ce qu’une seule clé active exposée peut permettre si elle est exploitée.
La recherche ne démontre pas que des attaquants ont utilisé les identifiants, mais elle montre pourquoi l’exposition n’est pas la fin de l’histoire. Une clé divulguée peut rester valide à mesure que ses copies se propagent dans différents pipelines, transformant une ancienne erreur de développeur en un risque de sécurité cloud durable.
Des milliers de clés AWS exposées fonctionnent toujours
Les chercheurs ont analysé 431 875 éléments exposés publiquement provenant de dépôts Git, de l’historique Git, d’images Docker, de registres de paquets, de journaux CI et de jeux de données publics.
L’analyse a permis d’identifier 64 024 clés d’accès AWS uniques. Les chercheurs ont revérifié 10 616 paires de clés complètes le 10 août 2026 et ont constaté que 88 % s’authentifiaient toujours auprès d’AWS.
La découverte la plus préoccupante concernait ce à quoi certaines de ces clés pouvaient donner accès.
Parmi les identifiants actifs, 817 étaient liés à des entreprises, dont 526 clés d’accès root et 242 identifiants IAM associés à la politique « Administrator Access » d’AWS. Cela signifie que 768 clés liées à des entreprises offraient un contrôle administratif complet sur leurs comptes AWS.
Pour les 2 903 clés actives dont les chercheurs ont pu récupérer la date de création, l’ancienneté médiane était d’environ cinq ans, tandis que la plus ancienne avait 17,4 ans.
Pourquoi des clés AWS divulguées peuvent rester valides pendant des années
Les clés d’accès AWS n’expirent pas automatiquement du simple fait d’avoir été exposées publiquement. Elles peuvent rester valides jusqu’à ce que quelqu’un les révoque explicitement.
Cela révèle une défaillance dans la gestion du cycle de vie des identifiants. Une entreprise peut supprimer un secret d’un dépôt, passer à une autre clé ou mettre une application hors service, mais aucune de ces actions ne révoque nécessairement la clé sous-jacente.
La découverte par Truffle Security d’identifiants actifs associés à la politique AWSCompromisedKeyQuarantine est particulièrement révélatrice. AWS avait identifié certains identifiants comme compromis, mais les clés existaient toujours et pouvaient encore être utilisées pour s’authentifier.
Il existe également un problème de visibilité et de politique interne. Les organisations peuvent accumuler d’anciens utilisateurs IAM au fil du temps. Mais si plus personne n’est responsable d’un identifiant, il se peut que personne ne vérifie s’il est toujours actif ni s’il a encore besoin des autorisations qui lui avaient été accordées à l’origine.
Cela aide à comprendre comment un secret vieux de cinq ans peut rester techniquement valide, même après la transformation complète du système qui l’a créé.
La leçon dépasse le cadre d’AWS
Bien que l’étude se soit concentrée sur les clés d’accès AWS, sa leçon sur la gestion des identifiants s’applique plus largement. La même erreur peut se produire avec tout type d’identifiant, des clés d’API et des identifiants de base de données aux jetons utilisés par les plateformes SaaS.
Ce risque devient plus difficile à contenir à mesure qu’une part croissante de l’infrastructure d’une organisation migre vers le cloud. Hugging Face a été la principale source unique de l’étude, avec 8 482 clés AWS actives uniques trouvées dans 3 394 jeux de données publics.
Le même problème prend encore plus d’ampleur à mesure que les agents d’IA et les intégrations reçoivent des identités de service, des identifiants utilisés par les serveurs et clients MCP et des autorisations leur permettant d’accéder à des ressources cloud, à des bases de données et à d’autres services.
Les identifiants à longue durée de vie devraient être remplacés, chaque fois que possible, par des identifiants temporaires ou par un accès fondé sur les rôles.
Les clés exposées doivent être immédiatement révoquées ou renouvelées, plutôt que simplement supprimées du code source. Les organisations devraient également analyser l’historique Git et les artefacts publics, appliquer des politiques claires en matière d’identifiants et utiliser des alertes de journalisation et de facturation pour détecter toute activité suspecte.
L’objectif devrait être simple : si un identifiant fuit aujourd’hui, il ne devrait pas encore pouvoir ouvrir la même porte dans cinq ans.
En savoir plus : une attaque AWS pilotée par l’IA montre comment des identifiants exposés peuvent donner un accès administratif complet en moins de 10 minutes, ce qui rappelle pourquoi les équipes de sécurité doivent révoquer les clés divulguées avant que les attaquants ne puissent étendre leurs accès.