Les erreurs de configuration IAM AWS figurent parmi les vecteurs d'attaque les plus exploités dans les environnements cloud. Contrairement à une vulnérabilité logicielle classique, ces failles ne nécessitent aucun exploit sophistiqué : un attaquant qui obtient des credentials même limités peut, en quelques appels API bien choisis, remonter jusqu'au contrôle total du compte. Ce chemin d'escalade de privilèges est documenté, reproductible, et pourtant encore trop rarement anticipé.
Les trois erreurs IAM les plus dangereuses en AWS
Politiques avec wildcard sur iam:*
Accorder iam:* à un utilisateur ou un rôle, c'est lui donner les clés du royaume IAM. Avec cette permission, n'importe quelle entité peut créer un nouvel utilisateur, lui attacher une politique AdministratorAccess, puis opérer sous cette nouvelle identité. C'est une escalade en deux appels API : iam:CreateUser suivi de iam:AttachUserPolicy. Ce type de permission apparaît souvent dans des environnements de développement copiés en production, ou dans des politiques écrites rapidement sous contrainte de temps.
Rôles assumables sans condition restrictive
Un rôle IAM avec une trust policy trop permissive — typiquement "Principal": {"AWS": "*"} ou sans condition sur l'IP source, le MFA ou l'organisation AWS — peut être assumé par n'importe quelle entité authentifiée, parfois même depuis un compte externe. Dans un scénario type, un attaquant compromet une Lambda avec des droits restreints, découvre qu'un rôle hautement privilégié est assumable sans condition depuis n'importe quelle ressource du même compte, et l'assume immédiatement via sts:AssumeRole. Le saut de privilèges est instantané.
Clés d'accès root non rotées (ou simplement existantes)
AWS déconseille fortement la création de clés d'accès programmatiques pour le compte root, mais ces clés existent dans de nombreux environnements, souvent créées lors des premières configurations et jamais supprimées. Une clé root active n'est soumise à aucune politique IAM restrictive : elle dispose par définition de tous les droits sur le compte, y compris la désactivation du MFA et la suppression des guardrails Organizations. Si cette clé fuite — via un dépôt Git public, un fichier de configuration mal versionné, ou un incident chez un prestataire — la compromission est totale et immédiate.
Le chemin d'escalade typique jusqu'au contrôle total
Un chemin d'escalade réaliste commence rarement avec des droits élevés. L'attaquant dispose au départ de credentials faibles : un utilisateur de développement avec des droits ReadOnly sur S3 et quelques actions EC2. La première phase est l'énumération : quelles politiques lui sont attachées, quels rôles existent dans le compte, lesquels sont assumables. C'est ici qu'intervient l'outil PMapper.
PMapper (Principal Mapper) construit un graphe orienté de toutes les entités IAM du compte et des chemins de transition entre elles. Il détecte automatiquement les chemins où une entité A peut atteindre les droits d'une entité B, directement ou via plusieurs intermédiaires. Une entité avec iam:PassRole et ec2:RunInstances peut, par exemple, lancer une instance avec un rôle admin attaché et exécuter des commandes via SSM. PMapper calcule ce chemin sans que l'opérateur ait besoin de le construire manuellement.
Une fois le chemin identifié, l'exploitation elle-même est menée avec Pacu, le framework offensif AWS open source. Pacu propose des modules dédiés à l'escalade de privilèges IAM : iam__privesc_scan énumère les techniques applicables à l'identité courante, iam__backdoor_users_keys crée des backdoors persistantes, et plusieurs modules couvrent des vecteurs comme la création de politiques inline ou la manipulation de groupes IAM. L'ensemble forme une chaîne d'attaque cohérente, du reconnaissance à la persistance.
Pourquoi ces erreurs persistent malgré leur notoriété
La plupart des équipes cloud connaissent ces risques théoriquement. Le problème est opérationnel. Les politiques permissives naissent souvent d'une urgence : un service ne fonctionnait pas, on a élargi les droits pour débloquer, et personne n'est revenu corriger ensuite. Les rôles assumables sans condition viennent parfois de templates Infrastructure-as-Code copiés depuis des exemples publics sans lecture attentive de la section Trust Policy. Quant aux clés root, leur existence est parfois ignorée des équipes actuelles, héritées d'une configuration initiale par un prestataire extérieur.
La difficulté est aussi la visibilité : sans outil de cartographie, identifier qu'un chemin d'escalade existe entre deux entités IAM dans un compte avec plusieurs centaines de rôles relève de l'exercice manuel fastidieux. C'est précisément ce gap que des environnements d'entraînement pratiques permettent de combler — explorer les labs dédiés à la sécurité cloud AWS est un moyen concret de former les équipes à détecter et corriger ces chemins avant qu'un attaquant ne les emprunte.
Mesures de remédiation concrètes
Auditer et restreindre les politiques IAM existantes
Commencer par un export complet des politiques via aws iam get-account-authorization-details et analyser les occurrences de wildcards sur des actions sensibles (iam:*, sts:*, s3:*). AWS Access Analyzer identifie les accès externes non intentionnels. PMapper, lancé régulièrement, détecte les nouveaux chemins d'escalade introduits par chaque modification de politique.
Durcir les trust policies des rôles
Chaque rôle doit avoir une condition explicite dans sa trust policy : restriction à un ARN source précis, condition aws:PrincipalOrgID pour les environnements Organizations, ou exigence de MFA pour les rôles critiques. Un rôle qui n'a pas besoin d'être assumé depuis un compte externe ne doit jamais l'autoriser.
Supprimer les clés root et activer les guardrails organisationnels
Les clés d'accès root doivent être supprimées, pas seulement désactivées. AWS CloudTrail doit être activé sur toutes les régions avec une alerte sur tout usage du root. Dans un contexte multi-comptes, les Service Control Policies (SCP) peuvent bloquer explicitement toute action effectuée avec des credentials root sur les comptes membres.
Intégrer l'audit IAM dans une démarche continue
Un audit IAM ponctuel a une valeur limitée : les configurations dérivent à chaque déploiement, chaque ajout de service, chaque rotation d'équipe. La posture de sécurité IAM doit être traitée comme du code — versionnée, testée, revue. Des outils comme aws-nuke en environnement de test, des pipelines d'analyse statique des templates CloudFormation ou Terraform, et des exercices réguliers de simulation d'escalade permettent de maintenir un niveau de contrôle réel. Pour les équipes qui souhaitent évaluer leur exposition actuelle aux risques IAM cloud, une analyse structurée des permissions existantes est le point de départ le plus utile.
Questions fréquentes
Qu'est-ce qu'une escalade de privilèges IAM en AWS ?
C'est le fait pour un attaquant de partir d'un accès limité et d'obtenir, via des enchaînements d'appels API autorisés par des permissions mal configurées, des droits plus élevés — jusqu'au contrôle total du compte dans les cas les plus graves. Aucun exploit système n'est nécessaire : seule la logique IAM est utilisée.
PMapper et Pacu s'utilisent-ils uniquement en Red Team ?
Non. PMapper est aussi utilisé en mode défensif par les équipes sécurité et les Cloud Security Architects pour cartographier les risques IAM existants sans rien exploiter. Pacu peut être utilisé dans des environnements de lab ou lors de pentests mandatés pour valider des chemins identifiés par PMapper. Les deux outils sont complémentaires dans une démarche d'audit structurée.
Comment savoir si mon compte AWS possède des clés root actives ?
AWS fournit un rapport de credential (aws iam generate-credential-report) qui liste toutes les entités IAM, y compris le compte root, avec l'état de leurs clés d'accès et la date de dernière utilisation. Un accès root avec une clé active et une date d'utilisation récente est un signal d'alerte immédiat.
Les wildcards IAM sont-ils toujours dangereux ?
Un wildcard sur des actions non sensibles (lecture seule sur des services sans impact latéral) présente un risque limité. Le danger vient des wildcards sur les namespaces IAM, STS, Organizations ou sur des services permettant l'exécution de code (Lambda, EC2, ECS), qui ouvrent des chemins d'escalade. La règle du moindre privilège reste le seul principe fiable.