9 300 clés AWS actives exposées en ligne : l'alerte de Truffle Security

Plus de 9 300 clés d'accès AWS actives, dont 768 avec des droits d'administrateur complets, ont été retrouvées en accès libre sur Internet par les chercheurs de Truffle Security. Dépôts Git, jeux de données Hugging Face, images Docker, logs d'intégration continue : les secrets techniques traînent partout, et 88 % des clés analysées fonctionnent encore. Pour toute organisation qui héberge des données personnelles dans le cloud, chaque clé oubliée est une porte d'entrée potentielle vers une violation de données au sens de l'article 33 du RGPD.

Ce qui s'est passé

Truffle Security a scanné le web public à la recherche de secrets exposés et a recensé 64 024 paires de clés AWS uniques, réparties sur 431 875 signalements publics. Sur les 10 616 paires jugées complètes et revérifiées, 88 % s'authentifient toujours auprès des services AWS concernés. Hugging Face est la source la plus importante, avec 8 482 clés actives retrouvées dans 3 394 jeux de données publics, dont 18 % disposaient de privilèges root.

L'âge médian des clés vivantes est d'environ cinq ans, la plus ancienne dépassant les dix-sept ans. Seules 13,7 % des clés exposées ont depuis été renouvelées : dans l'immense majorité des cas, personne n'a détecté la fuite ni révoqué l'accès. Seulement 9,5 % des comptes concernés disposaient d'une alerte de budget capable de signaler une activité anormale, comme un cryptominage lancé par un attaquant après vol de la clé.

Pourquoi c'est important pour les DPO et les RSSI

Une clé AWS n'est pas qu'un identifiant technique : elle donne accès à des bases de données, des buckets de stockage ou des services applicatifs qui, très souvent, traitent des données à caractère personnel. Une prise de contrôle de compte cloud peut donc déclencher une obligation de notification à la CNIL sous 72 heures au titre de l'article 32 du RGPD, qui impose des mesures techniques et organisationnelles proportionnées au risque, dont la gestion rigoureuse des accès et des secrets fait partie intégrante.

Ce type d'incident illustre aussi un point que Leto rappelle régulièrement : la majorité des violations de données ne viennent pas d'une faille sophistiquée, mais d'une négligence de configuration. Notre guide sur la violation de données et les obligations RGPD associées détaille précisément ce qui qualifie juridiquement un incident comme celui-ci, et les délais à respecter une fois la fuite détectée.

Le cas rejoint d'ailleurs un précédent déjà documenté par Leto : la fuite Klue, où un identifiant hérité d'une intégration dépréciée avait permis à un attaquant de siphonner des tokens OAuth reliant plusieurs CRM Salesforce. Même mécanisme de fond : un secret technique oublié, jamais révoqué, devenu une porte dérobée des années plus tard.

Ce que ça change pour les organisations — actions concrètes

Truffle Security recommande une série de mesures directement transposables dans un plan d'action DPO/RSSI :

• Supprimer systématiquement les clés d'accès root sur tous les comptes AWS, y compris personnels — un cas sur six des clés exposées disposait de ce niveau de privilège.
• Trier les clés IAM par ancienneté (commande aws iam list-access-keys) et appliquer une politique d'âge maximal avec rotation automatique.
• Configurer une alerte de budget, même minime, pour détecter rapidement un usage frauduleux type cryptominage.
• Considérer tout secret exposé publiquement — même un instant — comme définitivement compromis : 43 % des clés retrouvées par les chercheurs apparaissaient à plusieurs reprises dans différents dépôts ou images.
• Surveiller les alertes automatiques d'AWS (politique AWSCompromisedKeyQuarantine), qui signalent qu'une clé a été détectée comme publique.

Si un incident de ce type touche votre organisation, la marche à suivre en matière de conformité reste la même que pour toute violation de données : qualifier le risque pour les personnes concernées, notifier la CNIL si nécessaire, et documenter chaque étape. Notre guide pratique « fuite de données personnelles : les démarches à suivre en 72h » détaille ce processus pas à pas.

Ce que Leto pense de cette décision

Cette étude confirme ce que nous observons dans nos audits : la gestion des secrets techniques reste le maillon faible de la sécurité du cloud, loin devant les attaques sophistiquées. Un DPO qui n'intègre pas la revue des accès IAM et la rotation des clés dans son plan de conformité article 32 laisse un angle mort majeur dans sa cartographie des risques. La bonne nouvelle, c'est que corriger ce point ne coûte rien : une politique de rotation et une alerte budgétaire suffisent à éliminer l'essentiel du risque. Ne pas le faire, en revanche, revient à parier que personne ne trouvera la clé avant un attaquant — un pari que 90 % des comptes exposés dans cette étude ont visiblement perdu.

Sources : Infosecurity Magazine, « Researchers Uncover Thousands of Leaked AWS Keys »