Clés AWS divulguées : 768 donnaient un contrôle total de comptes d’entreprise

La publication d’une clé dans un dépôt ne prouve pas, à elle seule, qu’elle représente toujours une menace. Le risque devient critique lorsque l’identifiant est encore accepté par AWS, n’a pas été révoqué et conserve des permissions importantes. Dans cette enquête, ces trois conditions se retrouvaient fréquemment réunies.

768 clés permettaient de contrôler entièrement un compte d’entreprise

Parmi les clés actives attribuées à des comptes professionnels, 817 étaient liées à des entreprises. Cet ensemble comprenait :

• 526 clés de comptes root AWS ;
• 242 clés d’utilisateurs IAM associés à la politique AdministratorAccess ;
• 768 clés au total offrant un contrôle administratif complet d’un compte AWS d’entreprise.

Le compte root représente le niveau de privilège le plus élevé pour un client AWS. De son côté, une identité IAM dotée de AdministratorAccess peut intervenir sur l’ensemble des services AWS avec des permissions très larges. Une clé valide à l’un de ces niveaux peut donc faciliter une prise de contrôle, l’accès à des données, la création de ressources non autorisées ou une exploitation abusive de la facturation cloud.

Le problème dépasse ainsi la simple hygiène du code source. Supprimer une clé d’un fichier ou réécrire l’historique Git ne suffit pas : une copie peut déjà circuler. Pour fermer l’accès, il faut révoquer ou faire tourner la clé.

Hugging Face, principale source individuelle

Hugging Face représentait 8 482 expositions de clés AWS, soit la plus grande source individuelle identifiée dans le rapport. Truffle Security indique que 17,9 % de ces identifiants AWS étaient des clés root.

Ce résultat s’inscrit dans une analyse plus vaste des données publiques de la plateforme. L’entreprise affirme avoir examiné 7,6 pétaoctets de jeux de données publics sur Hugging Face et y avoir trouvé des identifiants actifs dans des milliers de jeux de données. Les secrets peuvent donc survivre en dehors des dépôts logiciels classiques et se retrouver intégrés à des données diffusées publiquement.

Pour les équipes de sécurité, le message est clair : analyser uniquement les dépôts actuels ne suffit pas. Les historiques Git, artefacts de compilation, images de conteneurs, registres, jeux de données publiés et sorties de pipelines CI peuvent tous conserver une clé après que les développeurs pensent l’avoir supprimée.

Des identifiants souvent très anciens et rarement renouvelés

L’âge médian des identifiants examinés était d’environ 1 831 jours, soit près de cinq ans. La clé la plus ancienne avait 17,4 ans. Seuls 13,7 % des éléments analysés disposaient d’une clé plus récente associée au même utilisateur, ce qui suggère que la plupart n’avaient pas été renouvelés dans le cadre d’une rotation normale.

Des clés qui restent actives pendant des années laissent davantage de temps à un usage abusif et rendent plus difficile l’identification de leur propriétaire. Elles peuvent aussi survivre aux changements d’équipe, aux migrations applicatives, au nettoyage d’un dépôt ou à une redistribution des responsabilités opérationnelles.

L’ancienneté doit donc être considérée comme un signal de risque. Une clé exposée depuis plusieurs années ne doit pas être présumée obsolète : il faut vérifier sa validité, la révoquer et rechercher d’éventuels abus, sauf preuve qu’elle n’est plus utilisable.

Les alertes budgétaires restent rares

Truffle Security a pu consulter les informations de 2 754 comptes, mais seuls 262 avaient activé des alertes de budget AWS.

Ces alertes ne remplacent ni la révocation des identifiants ni la détection des intrusions. Elles peuvent toutefois signaler rapidement la création de ressources coûteuses avec une clé compromise, notamment dans le cadre d’une cryptomonnaie minée à grande échelle ou d’un autre abus du cloud.

Sans notification adressée à une personne capable d’intervenir, une hausse inhabituelle des dépenses peut se poursuivre après la compromission d’un compte.

Les notifications AWS ne règlent pas tout

Le rapport décrit les mécanismes AWS capables de détecter des clés divulguées, d’avertir les clients concernés et d’appliquer des restrictions ou des mesures de mise en quarantaine. Toutefois, le nombre de clés encore valides lors des tests laisse penser que la détection ou la notification n’a pas systématiquement été suivie d’une révocation et d’une rotation rapides par les clients.

La détection n’est que la première étape. Une réponse complète doit permettre de retrouver le propriétaire de la clé, d’évaluer ses permissions, de rechercher des signes d’utilisation abusive et de l’invalider.

Truffle Security présente sa validation comme une opération en lecture seule : les chercheurs ont vérifié l’authentification ainsi que certaines informations de compte et de permissions, sans modifier les ressources des clients. Cette description provient de Truffle Security et n’est pas étayée indépendamment dans tous ses détails par l’ensemble des sources disponibles.

Que faire après une fuite de clé AWS ?

1. Révoquer ou renouveler immédiatement la clé

Désactivez ou supprimez tout identifiant publié par erreur, puis créez-en un nouveau uniquement si l’accès reste nécessaire. Retirer le secret d’un dépôt, supprimer un fichier ou réécrire l’historique Git n’invalide pas les copies déjà récupérées.

2. Supprimer les clés du compte root

Les clés d’accès du compte root ne doivent pas servir aux accès programmatiques courants. Supprimez-les et migrez les traitements vers des identités contrôlées, dotées de permissions strictement nécessaires.

3. Vérifier les permissions et le propriétaire

Identifiez le compte, l’utilisateur, le service et les ressources auxquels la clé était rattachée. Traitez en priorité les clés root, celles associées à AdministratorAccess, celles donnant accès à des données sensibles ou celles autorisant la création d’infrastructures.

4. Rechercher les abus avant et après la révocation

Examinez les journaux d’authentification, les traces CloudTrail, les modifications IAM, les ressources nouvellement créées et la facturation. Révoquer une clé empêche son utilisation future, mais ne permet pas de savoir si elle a déjà été exploitée.

5. Remplacer les clés permanentes par des identités temporaires

Lorsque c’est possible, privilégiez les rôles IAM de courte durée et les identités de workload plutôt que des clés d’accès permanentes. Des permissions limitées réduisent les conséquences d’une fuite.

6. Activer les alertes budgétaires et organiser la réponse

Configurez les alertes AWS Budgets et la détection des anomalies de coûts. Faites parvenir les notifications à des contacts capables d’agir rapidement. Le suivi financier constitue un filet de sécurité, pas un substitut à l’analyse des secrets, à la rotation des clés et à la revue des accès.

La leçon dépasse AWS

Le point le plus important de l’enquête n’est pas seulement le nombre de secrets trouvés. C’est leur combinaison : exposition publique, validité persistante, privilèges élevés, ancienneté extrême et surveillance limitée.

Les espaces de données publics peuvent conserver des identifiants longtemps après que l’organisation a oublié où ils étaient utilisés. De son côté, une clé copiée reste exploitable jusqu’à sa révocation explicite.

La règle la plus sûre pour les équipes cloud est donc simple : considérer toute clé AWS exposée comme compromise, vérifier ce qu’elle permet d’atteindre, la révoquer ou la renouveler immédiatement, puis remplacer les accès permanents par des identités temporaires et limitées au strict nécessaire.