Identité cloud : sécurité IAM et accès

L'identité cloud désigne l'ensemble des mécanismes de sécurité IAM qui gouvernent l'authentification et l'accès aux ressources hébergées dans des environnements cloud (AWS, Azure, GCP). Contrairement aux annuaires Active Directory on-premises, l'identité cloud repose sur des protocoles fédérés : OAuth 2.0, OpenID Connect (OIDC) et SAML 2.0 assurent la délégation de confiance entre fournisseurs d'identité (IdP) et fournisseurs de services. Les entités concernées ne sont pas uniquement des utilisateurs humains. Les workload identities, service accounts et managed identities constituent des surfaces d'attaque critiques, souvent sous-surveillées. Le modèle RBAC (Role-Based Access Control) structure les permissions via des rôles assignés à des principals. AWS IAM utilise des policies JSON évaluées à chaque appel API. Azure Entra ID repose sur des objets service principal et app registration. GCP Cloud IAM associe des bindings IAM à des ressources hiérarchiques. Une mauvaise configuration, comme un rôle trop permissif ou un token à longue durée de vie, peut compromettre l'intégralité d'un tenant cloud. La gestion du cycle de vie des identités (provisioning, deprovisioning, rotation des secrets) est donc un pilier fondamental de la posture de sécurité cloud.

La détection des abus d'identité cloud s'appuie sur l'analyse des journaux d'activité natifs de chaque plateforme. Sur AWS, CloudTrail enregistre chaque appel API avec le principal appelant, la région, l'adresse IP source et le user agent. Les événements ConsoleLogin, AssumeRole et GetSessionToken sont particulièrement sensibles. Une séquence AssumeRole vers un rôle cross-account inhabituel est un indicateur fort de mouvement latéral. Sur Azure, les logs Microsoft Entra ID (anciennement Azure AD) exposent les SignInLogs et les AuditLogs. Les connexions depuis des pays non autorisés, les authentifications sans MFA sur des comptes privilégiés, et les créations soudaines de service principals constituent des signaux à alerter. Sur GCP, les Cloud Audit Logs (Data Access et Admin Activity) tracent les modifications de bindings IAM. L'activation de l'API iam.serviceAccounts.getAccessToken par un principal non attendu est un signal critique. Les outils SIEM comme Microsoft Sentinel, Splunk ou Chronicle permettent de corréler ces événements. Des règles de détection basées sur des anomalies comportementales (heure d'accès, volume d'appels API, nouveaux scopes demandés) complètent l'approche signature. L'outil open source Cartography permet de visualiser le graphe des relations IAM pour identifier les chemins d'escalade de privilèges.

Côté Red Team, l'exploitation de l'identité cloud cible prioritairement les credentials exposés et les permissions mal configurées. Les metadata services des instances (IMDS sur AWS, http://169.254.169.254) permettent de récupérer des tokens temporaires associés au rôle IAM attaché. L'outil Pacu (framework offensif AWS) automatise l'énumération des permissions disponibles et les tentatives d'escalade via des actions comme iam:PassRole ou iam:CreatePolicyVersion. Sur Azure, l'outil AzureHound mappe le graphe des objets Entra ID et identifie les chemins d'escalade vers le Global Administrator. La technique du token hijacking consiste à extraire un access token OAuth depuis la mémoire d'un processus ou depuis un fichier de configuration mal protégé. Les contre-mesures prioritaires sont : activer le MFA sur tous les comptes humains sans exception, appliquer le principe du moindre privilège via des conditions IAM (restriction par IP, par heure), activer le session token binding, et surveiller toute création ou modification de rôle via des alertes en temps réel. La rotation automatique des secrets via AWS Secrets Manager ou Azure Key Vault réduit la fenêtre d'exploitation en cas de fuite. L'activation du Privileged Identity Management (PIM) sur Azure impose une élévation just-in-time pour les rôles critiques.