9 300 clés AWS valides après 4 ans d'exposition : le secrets sprawl qui ronge votre cloud

9 300 clés d'accès AWS exposées publiquement entre 2022 et 2026. Toutes encore actives et valides en août 2026. Cette statistique devrait vous glacer le sang — et pourtant, elle ne surprend personne dans la communauté sécurité. C'est le secret de polichinelle du cloud : les secrets ne meurent jamais, ils s'accumulent.

Le constat : 9 300 clés AWS valides, 4 ans d'exposition

Les chercheurs en sécurité ont documenté cette semaine un fait éloquent : plus de 9 300 clés d'accès Amazon Web Services (AWS), exposées publiquement quelque part entre août 2022 et août 2026, sont encore actives et utilisables. Quatre ans d'exposition. Aucun changement de clé. Aucune révocation. Aucune alerte, ou des alertes ignorées.

Pour comprendre l'ampleur du problème, il faut d'abord comprendre ce qu'est une clé d'accès AWS. Il s'agit d'une paire composée d'un Access Key ID (commence par AKIA pour les clés longue durée) et d'un Secret Access Key. Ces deux éléments forment des identifiants qui permettent d'interagir programmatiquement avec n'importe quel service AWS pour lequel le compte IAM associé dispose de permissions. Un attaquant disposant d'une clé avec des droits étendus peut lire vos données S3, créer des instances EC2, exfiltrer vos secrets Secrets Manager, déployer du code Lambda, ou pire encore : créer de nouveaux utilisateurs IAM avec des droits admin pour s'assurer un accès persistant même après révocation de la clé initiale.

La question n'est donc pas "combien de clés sont exposées" — elle est "que font les attaquants avec ces 9 300 clés actives en ce moment ?" La réponse est probablement : du cryptomining discret, de l'exfiltration de données, de la construction de botnet, et de la revente sur des marketplaces de credentials. Les clés AWS à permissions élevées se vendent entre 200 et 5 000 euros sur les forums de la dark web, selon le niveau d'accès associé.

Ce qui rend ce chiffre particulièrement révélateur, c'est la durée. 4 ans. Dans la grande majorité des entreprises, les pratiques de rotation des secrets cloud ne sont soit pas implémentées, soit implementées sur le papier mais pas en pratique. Les clés "temporaires" créées pour un projet deviennent permanentes. Les clés de test créées par un développeur restent actives après son départ. Les clés hardcodées dans des scripts déposés sur GitHub en 2022 sont toujours là, en 2026.

Comment vos secrets finissent sur internet : 5 vecteurs principaux

Comprendre pourquoi les secrets s'exposent est aussi important que de savoir quoi faire une fois qu'ils le sont. En 4 ans de pratique de l'audit cloud, j'ai observé les mêmes vecteurs revenir systématiquement.

1. Les dépôts Git publics (et privés mal configurés)

Le vecteur classique. Un développeur commit un fichier .env contenant des clés AWS, ou hardcode les credentials directement dans le code. Le dépôt est public, ou devient public par erreur lors d'un changement de paramètres. GitHub Secret Scanning détecte ces patterns et envoie des alertes — mais les alertes sont souvent ignorées ou traitées trop tard. Des outils comme TruffleHog, gitleaks et GitGuardian scannent en permanence l'intégralité des dépôts GitHub publics à la recherche de patterns de secrets. Il suffit de quelques secondes entre un push et la détection par un attaquant automatisé.

2. Les fichiers de configuration dans des buckets S3 publics

Ironie suprême : des clés AWS stockées dans des fichiers de configuration hébergés sur... S3, dans un bucket mal configuré en accès public. Ce scénario est plus fréquent qu'on ne le croit, notamment dans les environnements où la gestion des buckets S3 est décentralisée et sans politique de blocage de l'accès public au niveau compte (block public access).

3. Les logs applicatifs et systèmes

Les clés AWS peuvent apparaître dans des logs applicatifs quand une application enregistre ses variables d'environnement en cas d'erreur (stack traces, debug logs) ou quand une commande AWS CLI est exécutée avec les credentials dans l'argument de ligne de commande. Ces logs, s'ils sont centralisés dans un SIEM ou un système de log management avec des droits d'accès insuffisamment stricts, deviennent un vecteur d'exfiltration de credentials.

4. Les CI/CD pipelines et les variables d'environnement

Les pipelines CI/CD sont devenus l'un des vecteurs les plus actifs d'exposition de secrets. Des variables d'environnement mal protégées dans GitHub Actions, GitLab CI, CircleCI ou Jenkins peuvent être exposées via des logs de build, des artefacts, ou des pull requests malveillantes qui exécutent du code dans le contexte du pipeline. L'attaque SolarWinds de 2020 avait déjà illustré comment compromettre un pipeline CI/CD permettait d'atteindre des secrets et des accès cloud critiques. En 2026, cette menace est encore plus répandue.

5. Les postes développeurs compromis et le vol de fichiers .aws/credentials

Le fichier ~/.aws/credentials stocké sur les postes de développeurs est une mine d'or pour les infostealers. Des malwares comme RedLine, Vidar ou MetaStealer ciblent spécifiquement ce fichier lors de l'infection d'un poste. Une fois exfiltré, le fichier peut contenir plusieurs profils AWS (prod, staging, dev) avec des clés longue durée pour plusieurs environnements. Dans ce scénario, la compromission d'un seul poste développeur peut exposer l'intégralité des environnements cloud de l'organisation.

Le mythe de la rotation automatique des clés AWS

AWS propose des mécanismes pour éviter les clés longue durée : les rôles IAM avec credentials temporaires (STS AssumeRole), les Instance Profiles pour EC2, les IRSA (IAM Roles for Service Accounts) pour Kubernetes, les Lambda execution roles. Ces mécanismes génèrent des credentials éphémères avec une durée de vie de quelques heures. Un attaquant qui vole des credentials temporaires se retrouve avec une fenêtre d'exploitation extrêmement courte.

La réalité terrain est que ces mécanismes sont sous-utilisés. Pourquoi ? Parce qu'ils nécessitent une refactorisation du code existant, une formation des développeurs, et une architecture IAM plus complexe. Il est beaucoup plus simple de créer une clé longue durée dans la console AWS, de la copier dans un fichier .env, et de passer à autre chose. Le résultat : des organisations qui utilisent AWS depuis 5, 6, 7 ans accumulent des clés IAM longue durée créées lors de projets pilotes, de PoC, de tests d'intégration, et qui n'ont jamais été révoquées.

AWS publie régulièrement des recommandations pour éliminer les clés d'accès longue durée. AWS IAM Access Analyzer peut identifier les clés non utilisées depuis plus de 90 jours. AWS Trusted Advisor signale les clés vieilles de plus de 90 jours. Ces outils existent. Ils sont souvent activés. Et pourtant, les 9 300 clés exposées depuis 2022 et toujours actives en 2026 prouvent qu'entre l'outil et l'action, il manque quelque chose : le processus.

Secrets sprawl en entreprise : l'inventaire impossible (ou presque)

Le vrai problème derrière les 9 300 clés AWS, c'est ce qu'on appelle le secrets sprawl — la prolifération incontrôlée de secrets (clés API, mots de passe, certificats, tokens) à travers les environnements d'une organisation. Ce phénomène touche toutes les entreprises ayant dépassé un certain seuil de maturité dans leur adoption du cloud.

Voici un inventaire réaliste de là où se cachent les secrets dans une entreprise de taille intermédiaire (200-2000 employés) :

• Variables d'environnement dans les déploiements Kubernetes, ECS, Lambda — souvent passées directement au lieu d'utiliser des références à AWS Secrets Manager
• Fichiers de configuration dans des dépôts Git (application.properties, config.yaml, .env, appsettings.json)
• Coffres-forts de mots de passe individuels (LastPass, 1Password, Bitwarden) utilisés par des développeurs pour leurs clés de dev/staging
• Variables de pipeline CI/CD (GitHub Actions secrets, GitLab CI variables, Jenkins credentials store)
• Fichiers locaux sur les postes développeurs (~/.aws/credentials, ~/.kube/config avec tokens d'authentification)
• Scripts d'administration (PowerShell, Bash, Terraform) avec credentials hardcodés
• Bases de données de configuration (tables SQL, documents NoSQL contenant des API keys)
• Systèmes de ticketing (JIRA, ServiceNow) où des tickets d'incident contiennent parfois des clés en clair
• Logs et monitoring (traces applicatives, dashboards Datadog/Grafana avec des tokens)

Faire l'inventaire exhaustif de tout cela dans une organisation de plusieurs centaines de personnes est une tâche herculéenne. Des outils comme GitGuardian, Vault par HashiCorp, AWS Secrets Manager, ou Doppler peuvent aider — mais aucun ne couvre l'intégralité du périmètre sans une discipline organisationnelle forte.

Ce que font les attaquants avec une clé AWS active

Imaginons qu'un attaquant mette la main sur l'une de ces 9 300 clés AWS encore actives. Que se passe-t-il dans les premières minutes ?

T+0 : Validation de la clé via aws sts get-caller-identity. Cette commande retourne l'identité du compte sans déclencher d'alarme CloudTrail particulière (c'est une API de lecture basique). L'attaquant sait maintenant à quel compte AWS il a accès et quel utilisateur IAM est associé.

T+1 à T+5 min : Énumération des permissions via aws iam list-attached-user-policies, aws iam simulate-principal-policy, et des outils automatisés comme Pacu ou Prowler. L'attaquant cartographie rapidement ce qu'il peut faire : lire des buckets S3 ? Lancer des instances EC2 ? Appeler des services sensibles ?

T+5 à T+20 min : Selon les permissions disponibles, l'attaquant déploie ses actions : lancement d'instances EC2 pour du cryptomining (souvent dans des régions peu surveillées comme ap-southeast-1), exfiltration de buckets S3 contenant des données clients, extraction de secrets depuis AWS Secrets Manager ou Parameter Store, lecture des variables d'environnement Lambda (qui peuvent contenir d'autres credentials), ou — dans le pire cas — création d'un utilisateur IAM admin pour assurer la persistance.

T+20 min et après : Si l'organisation n'a pas de monitoring CloudTrail avec alertes en temps réel sur des actions critiques, l'attaquant opère en toute discrétion. Dans les petites structures sans SOC dédié, la compromission peut rester non détectée pendant des semaines ou des mois — jusqu'à l'arrivée d'une facture AWS anormale ou d'une notification d'un tiers.

Corriger le problème : les outils et méthodes qui marchent vraiment

Il n'existe pas de solution magique au secrets sprawl, mais il existe une progression logique pour réduire drastiquement l'exposition.

Étape 1 : Inventaire et découverte

Commencer par scanner vos dépôts Git (internes et externes) avec TruffleHog ou GitGuardian. Scanner vos buckets S3 et vos pipelines CI/CD. AWS IAM Access Analyzer peut identifier les permissions non utilisées et les clés longue durée dormantes. Un premier audit de 2 à 4 heures sur un compte AWS peut révéler un inventaire effrayant — mais c'est le point de départ indispensable.

Étape 2 : Élimination des clés longue durée

Pour chaque workload qui utilise des clés IAM longue durée, migrer vers des credentials temporaires :

• EC2, ECS, Lambda : utiliser des rôles d'exécution (Instance Profile, Task Role, Execution Role)
• GitHub Actions : utiliser OIDC pour assumer un rôle IAM sans clé statique
• Applications on-premise accédant à AWS : AWS IAM Roles Anywhere avec des certificats X.509
• Développeurs : utiliser AWS IAM Identity Center (SSO) avec des sessions temporaires via aws sso login

Étape 3 : Centralisation des secrets restants

Les secrets qui ne peuvent pas être remplacés par des credentials temporaires (clés d'API tierces, certificats, tokens Stripe, etc.) doivent être centralisés dans un coffre-fort : AWS Secrets Manager, HashiCorp Vault, ou Azure Key Vault. L'objectif est que le code ne contienne jamais de secret en dur — uniquement une référence à un secret centralisé.

Étape 4 : Monitoring et détection

Activer AWS CloudTrail sur tous les comptes et régions. Configurer des alertes Amazon GuardDuty — notamment la détection "UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B" et les alertes sur des API calls depuis des régions inhabituelles. Intégrer les événements CloudTrail dans votre SIEM pour des règles de détection personnalisées : premier usage d'une clé, usage depuis une IP non connue, création d'utilisateurs IAM en dehors des processus normaux.

Étape 5 : Processus organisationnels

Les outils seuls ne suffisent pas. Il faut des processus : revue trimestrielle des clés IAM avec suppression systématique des clés non utilisées depuis 90 jours, processus de départ des employés incluant la révocation des clés IAM personnelles, politique de "zéro secret dans le code" vérifiée lors des code reviews, et formation des développeurs aux bonnes pratiques IAM.

Conclusion : le secrets sprawl est un problème de gouvernance, pas de technologie

La statistique des 9 300 clés AWS toujours actives après 4 ans d'exposition ne devrait pas être une surprise — elle devrait être un signal d'alarme pour toute organisation qui utilise le cloud sans avoir mis en place une politique de gestion des secrets robuste. Les attaquants scannent GitHub, Pastebin, les buckets S3 publics et les résultats de moteurs de recherche à la recherche de ces clés en permanence. Le délai entre l'exposition et l'exploitation est souvent inférieur à quelques heures.

La bonne question n'est pas "avons-nous des secrets exposés ?" — la plupart des organisations en ont. La bonne question est "combien de temps faudra-t-il pour que quelqu'un les exploite, et serons-nous capables de le détecter avant que les dégâts soient irréversibles ?"

La réponse à cette question commence par un inventaire honnête et un audit ciblé. Pas dans 6 mois. Maintenant.