Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Assume Role AWS

cloud

Définition

AWS Assume Role est le mécanisme permettant à une entité AWS (utilisateur IAM, service AWS, ou compte AWS) d'obtenir temporairement les permissions d'un rôle IAM différent via AWS STS (Security Token Service). Cette opération génère des credentials temporaires (AccessKeyId, SecretAccessKey, SessionToken) avec une durée de vie configurable (15 min à 12h), remplaçant l'utilisation de credentials permanents pour les accès cross-account ou les escalades de privilege contrôlées. L'opération AssumeRole est au cœur du modèle de sécurité AWS : elle permet de réaliser l'accès cross-account (un compte AWS opérationnel accède aux ressources d'un compte AWS de données via un rôle), les workflows DevOps (une pipeline CI/CD assume un rôle de déploiement avec des permissions limitées), et les accès fedérés (des utilisateurs authentifiés via un IdP externe assument des rôles AWS via AssumeRoleWithWebIdentity ou AssumeRoleWithSAML). La Trust Policy (politique de confiance) d'un rôle IAM définit qui peut l'assumer (le Principal) et sous quelles conditions (Condition). Elle est distincte de la Permission Policy qui définit ce que le rôle peut faire. Une Trust Policy typique pour du cross-account spécifie le Principal comme arn:aws:iam::ACCOUNT_ID:root et peut imposer des conditions comme aws:MultiFactorAuthPresent: true (exiger MFA pour assumer le rôle) ou sts:ExternalId (protection contre la confused deputy attack). L'External ID dans les Trust Policies protège contre la confused deputy attack dans les accès cross-account via des tiers : un client partage un External ID secret avec son fournisseur de services, qui doit le présenter lors de l'AssumeRole. Sans External ID, si le rôle du fournisseur est compromis, l'attaquant peut assumer n'importe quel rôle client. L'External ID garantit que seul le fournisseur légitime (qui connaît l'External ID) peut assumer le rôle. AWS CloudTrail enregistre chaque AssumeRole avec l'identité du demandeur, le rôle assumé, les credentials temporaires générés, et la session name. L'analyse de ces événements AssumeRole est fondamentale pour détecter les escalades de privilege non autorisées et les mouvements latéraux cross-account.

Cross-account avec Assume Role

Architecture multi-compte recommandée : dans le compte cible, créez un rôle IAM avec une Trust Policy autorisant arn:aws:iam::SOURCE_ACCOUNT_ID:role/deployment-role à l'assumer. Dans le compte source, accordez au rôle de déploiement la permission sts:AssumeRole sur le rôle cible. Pour assumer le rôle : aws sts assume-role --role-arn arn:aws:iam::TARGET:role/role-name --role-session-name my-session. Exportez AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN dans l'environnement.

Détection des AssumeRole anormaux

Dans CloudTrail, surveillez : AssumeRole depuis des IPs inconnues ou des régions non utilisées habituellement, AssumeRole pour des rôles à hautes permissions (OrganizationsAdmin, SecurityAudit) hors des fenêtres de maintenance, et des AssumeRole en cascade (Compte A assume rôle B qui assume rôle C). Ces patterns peuvent indiquer une compromission de credentials ou un mouvement latéral. Configurez des alertes CloudWatch Events sur ces patterns dans votre SIEM.

Permission Boundary et restriction des rôles assumés

Utilisez les IAM Permission Boundaries pour limiter les permissions maximales qu'un rôle peut obtenir, même si la Permission Policy est trop permissive. Un rôle avec une Permission Boundary policies:AdministratorAccess et une Permission Policy restrictive ne pourra jamais dépasser les limites de la boundary. Les Permission Boundaries sont particulièrement utiles pour les pipelines CI/CD qui créent eux-mêmes des rôles IAM : la boundary empêche la pipeline de créer un rôle plus permissif qu'elle-même.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis