Des clés AWS exposées par centaines viennent de donner à des attaquants un contrôle total sur des comptes cloud d’entreprise. La recherche publiée cette semaine montre que ces identifiants ne proviennent pas d’une faille AWS, mais de dépôts Git, de fichiers de configuration et d’artefacts de build laissés accessibles. Pour une PME-ETI, une seule clé AWS exposée suffit à transformer un incident mineur en compromission complète de l’infrastructure.
Pourquoi une clé AWS exposée vaut plus qu’un mot de passe volé
Un identifiant utilisateur classique se heurte au MFA, à la géolocalisation, à la détection de connexion anormale. Une clé d’accès programmatique, elle, contourne tout cela par conception : elle est faite pour être utilisée par des scripts, sans interaction humaine. C’est précisément ce qui la rend redoutable.
- Pas de MFA : les clés d’accès (AKIA…) s’authentifient seules auprès de l’API AWS.
- Durée de vie infinie : sans rotation explicite, une clé reste valide des années.
- Permissions surdimensionnées : la majorité des clés de service héritent de politiques bien plus larges que nécessaire.
- Visibilité faible : sans CloudTrail exploité, une utilisation illégitime passe inaperçue.
Les chercheurs ont constaté que beaucoup des comptes touchés permettaient la création d’utilisateurs IAM, le démarrage d’instances EC2 et la lecture de buckets S3 entiers. Autrement dit : persistance, minage et exfiltration, avec un seul secret.
Où fuient réellement les clés AWS en PME-ETI
Le dépôt de code
C’est la source historique et elle reste la première. Un commit de dépannage, un fichier .env ajouté « temporairement », un notebook de test : l’historique Git conserve le secret même après suppression du fichier. Nous avions déjà détaillé ce mécanisme dans notre article sur les secrets exposés sur GitHub.
Les artefacts de build et les images
Une image Docker construite avec un ARG contenant une clé conserve celle-ci dans les couches intermédiaires. Idem pour les archives de déploiement et les logs de pipeline CI/CD verbeux.
Les postes de développement et les SaaS tiers
Le fichier ~/.aws/credentials est un fichier texte. Un infostealer sur un poste développeur le récupère en quelques secondes, au même titre que les cookies de session. Les intégrations SaaS qui demandent une clé AWS « pour la sauvegarde » élargissent encore la surface.
Sécuriser vos comptes cloud contre les clés AWS exposées
La réponse n’est pas de mieux cacher les clés, mais d’arrêter d’en produire. Voici l’ordre de priorité que nous recommandons à nos clients PME-ETI.
- Inventorier : listez toutes les clés d’accès actives et leur date de dernière utilisation (
aws iam get-credential-report). Toute clé inutilisée depuis 90 jours est un passif, pas un actif. - Supprimer les clés longue durée : remplacez-les par des rôles IAM pour les charges de travail internes et par OIDC pour les pipelines GitHub Actions ou GitLab CI. Aucun secret n’est alors stocké.
- Appliquer le moindre privilège : une clé de sauvegarde n’a pas besoin de
iam:CreateUser. Utilisez IAM Access Analyzer pour réduire les politiques trop larges. - Activer les garde-fous natifs : GuardDuty pour les usages anormaux, CloudTrail vers un stockage immuable, et des SCP pour interdire les régions non utilisées — un point de contrôle classique du cryptominage.
- Scanner en continu : activez la détection de secrets côté dépôt et bloquez le commit, pas seulement la fusion.
Détecter l’usage d’une clé AWS exposée
Trois signaux méritent une alerte immédiate dans votre SIEM :
- Appel d’API depuis une adresse IP ou un pays jamais observé pour ce principal.
GetCallerIdentitysuivi d’énumération (ListBuckets,ListUsers,DescribeInstances) en quelques secondes : la signature d’un outil automatisé.- Création d’une nouvelle clé d’accès ou d’un utilisateur IAM en dehors de la fenêtre de changement.
Ce type de corrélation est exactement ce qu’un SOC agentique traite bien : le volume d’événements CloudTrail dépasse la capacité d’analyse manuelle, mais les schémas d’abus sont stables et reconnaissables.
Que faire dans l’heure si une clé a fuité
Désactivez la clé avant de la supprimer — la désactivation conserve les traces pour l’investigation. Puis passez en revue CloudTrail sur les 90 derniers jours pour ce principal, et vérifiez systématiquement les créations d’utilisateurs IAM, les politiques attachées, les rôles assumables et les nouvelles paires de clés EC2. Une révocation sans chasse à la persistance ne ferme que la première porte, exactement comme dans le cas des passkeys enrôlées par un attaquant après un reset.
La leçon des clés AWS exposées est simple : dans le cloud, le secret statique est le maillon faible structurel. Migrer vers des identités éphémères n’est pas un projet de confort, c’est la seule mesure qui supprime la classe de vulnérabilité au lieu de la réduire.