IAM AWS : contrôle d'accès et privilege escalation

IAM AWS (Identity and Access Management) est le service natif d'Amazon Web Services qui contrôle l'accès aux ressources cloud. IAM repose sur quatre entités fondamentales : les utilisateurs, les groupes, les rôles et les politiques. Une politique IAM est un document JSON qui définit des permissions via des directives Allow ou Deny appliquées à des actions précises sur des ressources ARN. Les rôles IAM permettent à des services AWS, des comptes tiers ou des identités fédérées d'assumer temporairement des permissions via AWS STS (Security Token Service). Le mécanisme AssumeRole génère des credentials éphémères valables de 15 minutes à 12 heures. La complexité de IAM AWS réside dans l'évaluation des politiques : une permission effective résulte de la combinaison des politiques basées sur l'identité, sur la ressource, les permission boundaries, les Service Control Policies (SCP) dans AWS Organizations et les session policies. Une mauvaise compréhension de cette logique d'évaluation produit systématiquement des misconfigurations. Ces écarts de configuration constituent les vecteurs d'attaque les plus courants dans les environnements cloud AWS, rendant la maîtrise d'IAM indispensable pour tout praticien en sécurité offensive ou défensive.

La détection des abus IAM AWS repose principalement sur AWS CloudTrail, qui journalise chaque appel d'API effectué dans un compte. Les événements critiques à surveiller incluent AssumeRole, CreateAccessKey, AttachUserPolicy, PutUserPolicy, AddUserToGroup et CreateLoginProfile. Un appel AssumeRole vers un rôle inter-comptes depuis une identité inhabituelle constitue un signal fort de compromission. Les accès depuis des adresses IP inconnues, des régions non utilisées ou en dehors des horaires habituels doivent déclencher des alertes. AWS GuardDuty analyse en continu CloudTrail et détecte automatiquement des comportements suspects : exfiltration de credentials via les métadonnées EC2 (chemin IMDSv1 169.254.169.254), énumération IAM agressive ou utilisation de credentials compromis signalés sur le dark web. Dans un SIEM, il faut corréler les événements GetCallerIdentity (reconnaissance initiale), ListUsers, ListRoles et ListAttachedUserPolicies qui signalent une phase d'énumération. AWS Access Analyzer identifie les ressources exposées publiquement ou partagées avec des comptes externes. Les logs VPC Flow peuvent compléter la détection en corrélant des flux réseaux anormaux avec des appels d'API suspects réalisés depuis des instances EC2 ou Lambda.

En pentest AWS, l'escalade de privilèges via IAM AWS emprunte des chemins bien documentés. La technique iam:PassRole combinée à des permissions de création de ressources (ec2:RunInstances, lambda:CreateFunction) permet d'attacher un rôle privilégié à une nouvelle ressource et d'en récupérer les credentials. La permission iam:CreatePolicyVersion autorise la mise à jour d'une politique existante pour s'octroyer des droits AdministratorAccess. L'outil Pacu (framework offensif AWS) automatise l'énumération et l'exploitation de ces vecteurs. PMapper modélise le graphe des relations IAM pour identifier les chemins d'escalade les plus courts entre une identité compromise et les droits administrateur. Côté durcissement, l'application du principe de moindre privilège reste la mesure fondamentale : utiliser des politiques basées sur les conditions (aws:SourceIp, aws:RequestedRegion, aws:MultiFactorAuthPresent) restreint fortement la surface d'attaque. Les permission boundaries limitent le périmètre maximal qu'un utilisateur peut accorder à d'autres identités. IMDSv2 doit être imposé sur toutes les instances EC2 pour bloquer le vol de credentials via SSRF. Une rotation régulière des access keys, la suppression des utilisateurs IAM au profit de rôles et l'activation du MFA sur le compte root sont des prérequis non négociables.