Cloud IAM : Escalade de Privileges Multi-Cloud en 2026

En 2026, l'identité est le nouveau périmètre de sécurité. Les organisations qui ont migré vers des architectures multi-cloud AWS, GCP et Azure se retrouvent face à un défi de taille : chacun de ces environnements dispose de son propre système IAM (Identity and Access Management), avec ses mécanismes de délégation, ses pièges de configuration et ses chemins d'escalade de privilèges spécifiques. Les statistiques sont alarmantes — selon le rapport Verizon DBIR 2025, près de 74 % des compromissions cloud impliquent une exploitation de credentials ou une mauvaise configuration IAM. Dans un contexte où les applications cloud-native multiplient les comptes de service, les rôles temporaires et les fédérations d'identités, la surface d'attaque s'est considérablement élargie. Une seule permission mal accordée — comme iam:PassRole sur AWS ou roles/iam.serviceAccountTokenCreator sur GCP — peut suffire à un attaquant pour atteindre les droits administrateur de l'ensemble de votre infrastructure. Le cloud iam escalade privileges multi-cloud est devenu l'un des sujets les plus techniques et les plus urgents du paysage cybersécurité 2026. Cet article de référence couvre les techniques d'escalade les plus exploitées sur les trois clouds majeurs, les outils d'audit associés et les contre-mesures à déployer en priorité pour réduire votre exposition IAM.

Le contexte 2026 : pourquoi l'IAM multi-cloud est-il devenu le vecteur d'attaque prioritaire ?

L'évolution des architectures cloud vers des modèles multi-cloud et hybrides a fondamentalement changé la nature des attaques. Là où un attaquant cherchait autrefois à exploiter des vulnérabilités applicatives ou des failles réseau, il s'intéresse aujourd'hui en priorité aux identités cloud. Les raisons sont multiples : une identité compromise avec des permissions excessives offre un accès persistant, difficile à détecter, et souvent parfaitement légitime aux yeux des systèmes de journalisation.

Le framework MITRE ATT&CK Cloud Matrix — référence incontournable pour le mapping des tactiques cloud — liste l'escalade de privilèges (TA0004) comme l'une des tactiques les plus fréquemment observées dans les campagnes ciblant AWS, Azure et GCP. En 2026, trois tendances marquantes ressortent : la multiplication des comptes de service avec des permissions excessives héritées des phases de développement, la généralisation des fédérations d'identités entre Kubernetes et les clouds publics, et la complexité croissante des politiques IAM multi-couches qui génèrent des interactions inattendues entre permissions.

Les équipes qui réalisent des pentests cloud AWS, Azure et GCP constatent systématiquement les mêmes patterns : des rôles trop permissifs créés pour faciliter les déploiements DevOps, jamais révisés, et des chemins d'escalade qui auraient pu être détectés par un audit IAM élémentaire. La documentation officielle AWS souligne elle-même les risques (AWS IAM Security Best Practices), mais entre la théorie et la pratique opérationnelle, l'écart reste considérable dans la grande majorité des organisations.

AWS IAM : anatomie des chemins d'escalade de privilèges

AWS IAM est le système le plus mature des trois grands clouds, mais aussi celui qui présente le plus grand nombre de vecteurs d'escalade documentés. La richesse fonctionnelle du service IAM AWS — politiques inline, politiques gérées, conditions, limites de permissions (permissions boundaries), rôles de session et Service Control Policies — crée une complexité qui favorise les configurations incorrectes. Chaque couche supplémentaire de configuration représente une opportunité d'oubli ou d'interaction non anticipée.

AssumeRole et la chaîne de rôles cross-account

L'opération sts:AssumeRole est le mécanisme de délégation central d'AWS. Elle permet à une entité (utilisateur, rôle, service) d'obtenir des credentials temporaires associés à un autre rôle. Lorsqu'une trust policy est mal configurée — en autorisant par exemple l'ensemble d'un compte AWS (arn:aws:iam::*:root) ou en omettant des conditions restrictives sur sts:ExternalId — le rôle devient assumable par n'importe quelle identité disposant de la permission sts:AssumeRole.

Le scénario d'attaque le plus courant dans les environnements AWS Organizations est la chaîne de rôles inter-comptes (cross-account role chaining). Un attaquant compromet un compte de développement peu protégé, identifie un rôle qui trust ce compte et dispose de permissions élevées sur le compte de production, puis l'assume pour pivoter vers l'environnement sensible. L'opération sts:GetCallerIdentity est systématiquement utilisée en première étape pour l'énumération de l'identité courante :

# Étape 1 : identifier l'identité courante et le compte AWS
aws sts get-caller-identity

# Étape 2 : énumérer les rôles et leurs trust policies
aws iam list-roles --query "Roles[*].[RoleName,Arn]" --output table

# Étape 3 : inspecter la trust policy d'un rôle suspect
aws iam get-role --role-name CrossAccountDeployRole   --query "Role.AssumeRolePolicyDocument"

# Étape 4 : assumer le rôle cross-account
aws sts assume-role   --role-arn arn:aws:iam::PROD_ACCOUNT_ID:role/CrossAccountAdminRole   --role-session-name pentest-escalation-session

# Étape 5 : avec Pacu, automatiser la détection des rôles assumables
pacu --module iam__enum_assume_role

iam:PassRole — la permission la plus dangereuse d'AWS

La permission iam:PassRole est régulièrement sous-estimée dans les politiques IAM. Elle permet à une entité de "passer" un rôle IAM à un service AWS lors de la création d'une ressource. En apparence anodine, elle devient critique dès lors qu'elle est combinée avec la capacité de créer certains types de ressources AWS qui s'exécutent ensuite avec les permissions du rôle passé.

Le scénario d'escalade classique : un attaquant dispose des permissions iam:PassRole et lambda:CreateFunction + lambda:InvokeFunction. Il crée une fonction Lambda en lui passant un rôle IAM disposant d'AdministratorAccess, puis invoque cette fonction qui s'exécute avec les permissions administrateur. Le même vecteur s'applique avec EC2 (ec2:RunInstances), Glue (glue:CreateJob), ECS (ecs:RegisterTaskDefinition), SageMaker (sagemaker:CreateTrainingJob) et de nombreux autres services AWS.

# Identifier les politiques attachées à l'identité cible
aws iam list-attached-user-policies --user-name victim
aws iam get-policy-version   --policy-arn arn:aws:iam::123456789012:policy/DevDeployPolicy   --version-id v1

# Vérifier les rôles disponibles pour PassRole
aws iam list-roles --query "Roles[?contains(RoleName, 'Admin') || contains(RoleName, 'admin')]"

# Avec Pacu : scanner automatiquement tous les chemins d'escalade
pacu --module iam__enum_permissions
pacu --module iam__privesc_scan

import boto3

# Simuler les permissions PassRole via boto3 IAM Policy Simulator
iam = boto3.client('iam')

response = iam.simulate_principal_policy(
    PolicySourceArn='arn:aws:iam::123456789012:user/victim',
    ActionNames=['iam:PassRole', 'lambda:CreateFunction', 'lambda:InvokeFunction'],
    ResourceArns=['arn:aws:iam::123456789012:role/AdminRole']
)
for result in response['EvaluationResults']:
    print(f"{result['EvalActionName']}: {result['EvalDecision']}")

# Créer la Lambda d'escalade avec le rôle admin
lambda_client = boto3.client('lambda')
# NB : en contexte d'audit autorisé uniquement
response = lambda_client.create_function(
    FunctionName='escalation-test',
    Runtime='python3.12',
    Role='arn:aws:iam::123456789012:role/AdminRole',
    Handler='index.handler',
    Code={'ZipFile': b'...' }  # code qui exfiltre les credentials admin
)

CreateLoginProfile et UpdateLoginProfile : créer des credentials détournés

Les permissions iam:CreateLoginProfile et iam:UpdateLoginProfile permettent respectivement de créer un mot de passe console pour un utilisateur IAM qui n'en a pas, et de modifier le mot de passe d'un utilisateur existant. Si un attaquant dispose de ces permissions sur un compte à hauts privilèges — typiquement un compte de service CI/CD qui n'est jamais censé se connecter à la console — il peut créer des credentials persistants sans déclencher d'alerte.

# Lister les utilisateurs sans mot de passe console (candidats à CreateLoginProfile)
aws iam list-users --query "Users[*].[UserName,PasswordLastUsed]" --output table

# Créer un profil de connexion console pour un utilisateur sans mot de passe
aws iam create-login-profile   --user-name privileged-ci-account   --password "P@ssw0rd!Temp2026"   --no-password-reset-required

# Modifier le mot de passe d'un utilisateur existant à hauts privilèges
aws iam update-login-profile   --user-name admin-backup-account   --password "NewP@ss!2026"

Bypass des conditions IAM : aws:RequestedRegion et aws:SourceIp

Les conditions IAM sont censées restreindre l'utilisation de permissions à des contextes précis. Cependant, une condition mal rédigée peut être contournée de façon triviale. Deux cas reviennent régulièrement dans les audits. Premièrement, une politique qui utilise aws:RequestedRegion comme seule restriction laisse des angles morts critiques : les actions globales comme iam:*, sts:*, organizations:* ne sont pas soumises à la condition de région et s'exécutent dans us-east-1 quel que soit le contexte. Deuxièmement, une condition aws:SourceIp qui restreint à une IP interne peut être contournée si l'attaquant compromet un service qui s'exécute depuis cet IP — rebond via un Lambda, un ECS task ou une instance EC2 interne. La politique semble restrictive mais le pivot réseau la neutralise.

GCP IAM : escalade depuis Kubernetes jusqu'aux droits administrateur

La documentation officielle GCP sur IAM (Google Cloud IAM Documentation) décrit un système de permissions granulaires. En pratique, les rôles primitifs (roles/owner, roles/editor) sont encore largement utilisés dans de nombreuses organisations, créant des surfaces d'attaque importantes. GCP présente des vecteurs d'escalade spécifiques, notamment autour des fédérations d'identités et des comptes de service Kubernetes.

Workload Identity Federation — de l'impersonation de pod à l'escalade GCP

La fonctionnalité Workload Identity de GKE permet à des pods Kubernetes d'agir en tant que comptes de service GCP sans avoir à gérer des clés JSON. Ce mécanisme est excellent en théorie, mais sa configuration requiert une précision absolue sur les contraintes d'audience et de namespace et service account Kubernetes. Un binding Workload Identity trop large — par exemple, autorisant n'importe quel service account Kubernetes du cluster plutôt qu'un service account spécifique d'un namespace spécifique — permet à un attaquant qui a compromis n'importe quel pod du cluster de s'authentifier en tant que compte de service GCP et d'en hériter les permissions.

# Lister les permissions d'un service account GCP
gcloud projects get-iam-policy PROJECT_ID   --flatten="bindings[].members"   --filter="bindings.members:serviceAccount:myapp@PROJECT_ID.iam.gserviceaccount.com"   --format="table(bindings.role)"

# Vérifier les bindings Workload Identity sur un service account
gcloud iam service-accounts get-iam-policy   TARGET_SA@PROJECT_ID.iam.gserviceaccount.com

# Depuis un pod compromis : obtenir un token pour le SA GCP lié
curl -H "Metadata-Flavor: Google"   "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

# Utiliser ce token pour appeler l'API GCP
TOKEN=$(curl -s -H "Metadata-Flavor: Google"   "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"   | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

curl -H "Authorization: Bearer $TOKEN"   "https://cloudresourcemanager.googleapis.com/v1/projects/PROJECT_ID:getIamPolicy"

Ce vecteur est directement lié aux erreurs de configuration RBAC Kubernetes. Notre guide sur les erreurs critiques de configuration RBAC Kubernetes couvre les contre-mesures au niveau du cluster qui limitent la portée d'une compromission de pod vers GCP.

roles/editor et les permissions implicites non documentées

Le rôle roles/editor sur GCP est plus dangereux qu'il n'y paraît. Au-delà des permissions explicites documentées, il inclut des centaines de permissions sur la quasi-totalité des services GCP — notamment iam.serviceAccounts.actAs qui permet d'usurper l'identité de n'importe quel compte de service du projet. Un utilisateur disposant de roles/editor peut donc créer une Cloud Function, lui assigner un compte de service admin, et l'exécuter pour escalader ses privilèges vers AdministratorAccess.

La technique d'énumération via ScoutSuite ou Pacu-GCP révèle régulièrement des utilisateurs humains avec roles/editor créés lors des phases de développement et jamais révisés. Pour un audit IAM approfondi de votre configuration cloud, notre équipe propose un audit de sécurité cloud couvrant les trois environnements majeurs.

IAM conditions Resource Manager : un faux sentiment de sécurité

GCP Resource Manager permet d'appliquer des conditions IAM basées sur l'heure, l'adresse IP ou l'identité de la ressource cible. Ces conditions sont appliquées au niveau des bindings IAM, mais elles ne s'appliquent pas uniformément à toutes les APIs. En particulier, les conditions basées sur resource.name peuvent être contournées si l'attaquant a accès à des ressources qui héritent des permissions par la hiérarchie organisation-dossier-projet de GCP. Un binding conditionnel restreint à un projet peut être court-circuité via un actif héritant de permissions au niveau organisation.

Azure IAM : PIM, Managed Identity et la double gouvernance

Azure présente une complexité particulière avec ses deux systèmes de contrôle d'accès distincts : Azure Active Directory (maintenant Microsoft Entra ID) pour la gouvernance des identités au niveau du tenant, et Azure RBAC pour le contrôle d'accès aux ressources Azure. Cette dualité crée des chemins d'escalade que les équipes de sécurité ne maîtrisent pas toujours et que les outils d'audit standard manquent parfois.

Managed Identity (MSI) — le token silencieux de la VM Azure

Les Managed Identities Azure (System-assigned ou User-assigned) permettent aux VMs et autres ressources Azure de s'authentifier auprès des services Azure sans credentials stockés. L'accès aux tokens MSI se fait via l'Azure Instance Metadata Service (IMDS), accessible depuis la VM sans authentification préalable — uniquement depuis l'intérieur de la machine.

Le scénario d'exploitation est direct : un attaquant qui a compromis une VM Azure (via une vulnérabilité applicative, une exécution de commandes RCE, un accès SSH obtenu via credential stuffing) peut immédiatement obtenir le token MSI de la VM et l'utiliser pour appeler l'API Azure Resource Manager avec les permissions du rôle attribué à la VM — souvent Contributor voire Owner sur une subscription entière. L'audit des permissions Managed Identity est étroitement lié à la surveillance de l'API Microsoft Graph ; consultez notre guide sur l'audit et monitoring de l'API Microsoft Graph pour les contrôles complémentaires.

# Obtenir le token MSI depuis une VM Azure compromise
curl -s -H "Metadata: true"   "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

# Extraire le token et l'utiliser pour les appels ARM
TOKEN=$(curl -s -H "Metadata: true"   "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"   | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

# Lister les subscriptions accessibles avec ce token
curl -s -H "Authorization: Bearer $TOKEN"   "https://management.azure.com/subscriptions?api-version=2020-01-01" | python3 -m json.tool

# Énumérer les attributions de rôles sur la subscription découverte
curl -s -H "Authorization: Bearer $TOKEN"   "https://management.azure.com/subscriptions/SUB_ID/providers/Microsoft.Authorization/roleAssignments?api-version=2022-04-01"

# Récupérer un token pour Microsoft Graph (Entra ID)
curl -s -H "Metadata: true"   "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://graph.microsoft.com/"

Privileged Identity Management (PIM) : activation sans friction, risque maximal

Azure PIM est conçu pour réduire la surface d'attaque en rendant les rôles élevés "éligibles" plutôt que permanents. Un utilisateur éligible doit activer son rôle pour une durée limitée, potentiellement avec approbation et MFA. C'est une excellente approche — à condition d'être correctement configurée.

Les abus PIM documentés en 2026 suivent plusieurs patterns récurrents : activation sans approbation requise (configuration permissive laissée par défaut après migration), activation sans MFA supplémentaire pour les rôles Owner ou Global Administrator, et durées d'activation excessivement longues — jusqu'à 24 heures — permettant à un attaquant de maintenir ses privilèges bien après la compromission initiale. Un attaquant qui compromet un compte éligible au rôle Global Administrator peut l'activer silencieusement pendant la nuit, créer de nouvelles backdoors administrateur (applications Entra ID, utilisateurs admin alternatifs), puis désactiver le rôle pour brouiller les pistes. Les journaux PIM existent mais ne sont pas toujours intégrés dans les workflows SOC.

Azure AD vs Azure RBAC : deux modèles, des chemins d'escalade multiples

La distinction entre les rôles Azure AD (Entra ID) et les rôles Azure RBAC est source de confusion et d'erreurs de configuration fréquentes. Les rôles Entra ID — Global Administrator, Application Administrator, Cloud Application Administrator, User Administrator — opèrent au niveau du tenant et contrôlent les objets d'annuaire et les applications. Les rôles Azure RBAC — Owner, Contributor, User Access Administrator, Reader — opèrent au niveau des ressources Azure (subscriptions, resource groups, ressources individuelles).

Les chemins d'escalade les plus critiques exploitent les interactions entre ces deux systèmes. Un utilisateur avec le rôle Entra ID "Application Administrator" peut modifier les credentials d'applications Entra ID qui disposent de rôles Owner sur des subscriptions Azure — transformation d'un accès annuaire en accès infrastructure complet. Un utilisateur avec le rôle RBAC "User Access Administrator" peut s'attribuer directement le rôle Owner sur la subscription. Ces interactions peuvent être cartographiées avec AzureHound et visualisées dans BloodHound. Pour les environnements hybrides qui combinent Active Directory on-premise et Azure AD, notre service de pentest Active Directory couvre également les vecteurs Azure AD Connect et Entra ID.

Comment un attaquant enchaîne-t-il les vecteurs multi-cloud ?

Dans les environnements réels, les compromissions IAM les plus impactantes ne reposent pas sur un seul vecteur mais sur une chaîne d'escalade traversant plusieurs services et parfois plusieurs clouds. Voici un scénario type observé lors de pentests cloud en 2026.

Phase 1 — Accès initial : L'attaquant compromet un pipeline CI/CD (GitHub Actions, GitLab CI) et exfiltre des credentials AWS à longue durée de vie stockés en tant que secrets de repository. Ces credentials appartiennent à un compte IAM avec des permissions apparemment limitées (s3:GetObject, ec2:DescribeInstances, cloudwatch:PutMetricData).

Phase 2 — Reconnaissance IAM : Via sts:GetCallerIdentity et l'énumération des politiques attachées, l'attaquant découvre que le compte dispose également de iam:PassRole sur un rôle Glue et de la permission glue:CreateJob. Ce chemin PassRole-Glue n'a pas été détecté lors de la dernière revue IAM car le rôle Glue n'était pas encore attaché à un rôle admin au moment de l'audit.

Phase 3 — Escalade AWS : L'attaquant crée un job Glue malveillant qui s'exécute avec un rôle AdministratorAccess, extrait des secrets depuis AWS Secrets Manager (connexions DB, clés API tiers), et crée un nouvel utilisateur IAM avec des credentials permanents pour maintenir l'accès après rotation des secrets CI/CD.

Phase 4 — Pivot multi-cloud : Parmi les secrets extraits, l'attaquant trouve un fichier JSON de compte de service GCP utilisé par une application AWS pour écrire dans des buckets Google Cloud Storage. Ce compte de service GCP dispose de roles/editor sur le projet principal. Via la permission actAs implicite dans roles/editor, l'attaquant peut créer une Cloud Function avec un compte de service admin GCP et escalader dans l'environnement GCP.

Ce type de chaîne illustre pourquoi l'audit IAM ne peut pas se limiter à un seul cloud et pourquoi les secrets cross-cloud doivent être gérés avec la même rigueur que les credentials de production. Les environnements cloud contenant des workloads containerisés ajoutent une couche supplémentaire de complexité — consultez notre guide sur les container escapes Docker et containerd en 2026 pour comprendre comment une compromission conteneur peut conduire à des accès IAM non autorisés.

Les outils d'audit IAM indispensables en 2026

La détection manuelle des chemins d'escalade IAM est pratiquement impossible dans des environnements cloud complexes disposant de centaines de rôles et de politiques. Plusieurs outils open source permettent d'automatiser l'énumération et l'identification des vecteurs d'escalade.

Pacu — le framework d'exploitation AWS

Pacu, développé par RhinoSecurity Labs, est le framework d'exploitation AWS de référence pour les tests de pénétration autorisés. Son module iam__privesc_scan est particulièrement puissant : il analyse les permissions actuelles de l'identité et identifie automatiquement tous les chemins d'escalade possibles en fonction des politiques IAM attachées, en tenant compte des permissions borders et des SCPs Organizations. Pacu intègre plus de 40 modules couvrant IAM, EC2, Lambda, S3, et les services de données.

# Installation de Pacu
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu && pip3 install -r requirements.txt

# Démarrer une session et configurer les credentials AWS
python3 pacu.py

# Dans Pacu : énumérer toutes les permissions de l'identité courante
run iam__enum_permissions

# Scanner l'ensemble des chemins d'escalade de privilèges
run iam__privesc_scan

# Énumérer les rôles assumables depuis l'identité courante
run iam__enum_assume_role

# Lister les clés d'accès actives sur tous les utilisateurs
run iam__enum_users_roles_policies_groups

ScoutSuite — l'audit multi-cloud open source

ScoutSuite de NCC Group est l'outil d'audit multi-cloud open source le plus complet du marché. Il supporte AWS, GCP, Azure, Alibaba Cloud et Oracle Cloud, et génère des rapports HTML interactifs détaillant les mauvaises configurations IAM, réseau, stockage et logging. Pour les équipes qui gèrent des environnements multi-cloud, c'est l'outil de référence pour un premier état des lieux de posture de sécurité. ScoutSuite classe automatiquement les findings par sévérité et les associe aux benchmarks CIS et MITRE ATT&CK.

# Installation ScoutSuite
pip install scoutsuite

# Audit AWS avec profil dédié
scout aws --profile audit-readonly-profile --report-dir ./scout-report

# Audit GCP avec les credentials application default
gcloud auth application-default login
scout gcp --user-account --project-id PROJECT_ID

# Audit Azure avec les credentials CLI
az login
scout azure --cli --subscription-ids SUB_ID_1 SUB_ID_2

CloudFox — énumération des chemins d'escalade AWS

CloudFox est spécialisé dans l'identification des chemins d'escalade et des secrets accessibles dans les environnements AWS. Son approche se distingue par sa capacité à identifier les ressources "attaquables" depuis une identité donnée — ressources S3 accessibles, endpoints Lambda exposés, ECS tasks exploitables, paramètres SSM Parameter Store lisibles. CloudFox produit des sorties directement exploitables dans BloodHound pour la visualisation des chemins d'attaque, ce qui le rend particulièrement adapté aux red teams.

# Installation CloudFox (via release binaire GitHub)
wget https://github.com/BishopFox/cloudfox/releases/latest/download/cloudfox-linux-amd64.zip
unzip cloudfox-linux-amd64.zip

# Tous les contrôles depuis l'identité courante
./cloudfox aws --profile target-profile all-checks -o ./cloudfox-output

# Identifier les rôles assumables et leurs trust policies
./cloudfox aws --profile target-profile role-trusts

# Inventaire des secrets accessibles (Secrets Manager + SSM)
./cloudfox aws --profile target-profile secrets

# Cartographier les chemins d'escalade via les permissions
./cloudfox aws --profile target-profile permissions

Prowler — conformité CIS AWS, GCP et Azure

Prowler est l'outil de référence pour l'audit de conformité cloud selon les benchmarks CIS, NIST 800-53, PCI-DSS et SOC2. Il couvre AWS, GCP et Azure et propose plus de 500 contrôles de sécurité automatisés. Dans le contexte IAM, Prowler identifie les utilisateurs sans MFA, les access keys anciennes non rotées, les rôles avec des trust policies trop larges, les comptes root AWS utilisés récemment, et les politiques avec des wildcards dangereux. C'est l'outil complémentaire idéal à ScoutSuite pour une couverture exhaustive.

# Installation Prowler
pip install prowler

# Audit IAM complet sur AWS
prowler aws --services iam --output-formats html json csv

# Contrôles CIS AWS Level 1 et Level 2
prowler aws --compliance cis_level1_aws cis_level2_aws

# Audit GCP avec focus IAM
prowler gcp --project-id PROJECT_ID --services iam

# Rapport de conformité Azure
prowler azure --subscription-ids SUB_ID --services iam entra

Tableau comparatif des vecteurs d'escalade multi-cloud

Comment détecter et corriger les failles IAM sur AWS, GCP et Azure ?

La détection des escalades de privilèges IAM repose sur un triptyque : logging exhaustif et centralisé, alertes temps réel sur les actions sensibles, et revues périodiques des permissions effectives. Voici les mesures prioritaires par cloud.

AWS : Activer AWS CloudTrail dans toutes les régions avec validation d'intégrité des logs et livraison vers un bucket S3 de sécurité dans un compte dédié (impossible à modifier depuis le compte compromis). Configurer des métriques CloudWatch et des alertes sur les événements IAM les plus sensibles : CreateLoginProfile, UpdateLoginProfile, AttachUserPolicy, PutUserPolicy, AssumeRole cross-account, et toute création de clé d'accès. Utiliser AWS IAM Access Analyzer pour identifier automatiquement les ressources partagées hors du périmètre de confiance. Déployer des Service Control Policies (SCPs) via AWS Organizations pour créer des guardrails impossibles à contourner même depuis un compte root compromis — par exemple, interdire la désactivation de CloudTrail ou la création d'utilisateurs IAM avec des politiques administrateur.

GCP : Activer Cloud Audit Logs pour tous les services IAM et les APIs critiques. Configurer des alertes sur les modifications de bindings IAM (SetIamPolicy), les créations de comptes de service, les générénations de clés de compte de service, et les actions actAs. Utiliser Policy Analyzer et IAM Recommender pour identifier les accès excessifs et les permissions non utilisées depuis plus de 90 jours. Supprimer ou restreindre les rôles primitifs (owner, editor, viewer) au profit de rôles prédéfinis granulaires. Appliquer des conditions de binding IAM temporelles pour les accès sensibles.

Azure : Activer Microsoft Defender for Cloud avec les plans Defender for Identity et Defender for DevOps. Configurer des règles Microsoft Sentinel sur les activations PIM sans approbation, les modifications d'attributions de rôles RBAC, les accès inhabituels via l'IMDS depuis des VMs, et les créations d'applications Entra ID avec des permissions élevées. Auditer mensuellement les attributions de rôles privilegiés avec az role assignment list --all et identifier les Managed Identities disposant de rôles Contributor ou Owner sur des scopes larges. Exiger une approbation d'un second administrateur et un MFA renforcé pour toutes les activations PIM de rôles Global Administrator, Privileged Role Administrator et Owner de subscription.

La conformité NIS 2 impose des exigences explicites sur la gestion des accès privilégiés — notre guide NIS 2 et l'offre de RSSI externalisé couvrent les obligations de gouvernance IAM dans ce cadre réglementaire. Les référentiels de la CISA Cloud Security Best Practices fournissent des guidelines directement applicables à la sécurisation IAM multi-cloud, notamment autour du principe de moindre privilège et de la détection des comportements anormaux.

Questions fréquentes

Quelle est la différence entre l'escalade de privilèges verticale et horizontale en IAM cloud ?

L'escalade verticale consiste à obtenir des permissions plus élevées que celles initialement attribuées — par exemple, passer d'un rôle ReadOnly à AdministratorAccess via PassRole sur AWS. L'escalade horizontale consiste à accéder aux ressources d'une autre identité de même niveau — usurper le rôle d'un développeur tiers pour accéder à ses S3 buckets. Les deux types sont référencés dans MITRE ATT&CK Cloud sous TA0004 et nécessitent des stratégies de détection distinctes.

Comment auditer les permissions IAM dans un environnement multi-cloud sans outil commercial coûteux ?

La combinaison Prowler (conformité CIS multi-cloud), ScoutSuite (audit de configuration), CloudFox (chemins d'escalade AWS) et AzureHound (graphe d'attaque Azure) couvre l'essentiel des besoins sans budget logiciel supplémentaire. Pour GCP, gcloud projects get-iam-policy avec --flatten et --format permet une analyse fine des bindings effectifs. Ces outils complètent efficacement un audit de sécurité professionnel sur les configurations les plus complexes.

Quel est le risque concret d'une mauvaise configuration Workload Identity GCP sur un cluster de production ?

Un binding Workload Identity trop large permet à n'importe quel pod du cluster — y compris ceux créés par des développeurs sans autorisation spéciale — de s'authentifier en tant que compte de service GCP et d'accéder à des ressources sensibles : bases de données Cloud SQL, buckets GCS, secrets Secret Manager. En cas de compromission d'un pod via une vulnérabilité applicative (RCE, injection de commandes), l'attaquant hérite directement des permissions GCP du service account, potentiellement à l'échelle du projet entier.

Les Managed Identities Azure sont-elles plus sécurisées que des Service Principals avec client secret ?

Les Managed Identities éliminent le risque de fuite de credentials statiques et automatisent la rotation des tokens. Elles restent vulnérables à une exploitation via le metadata endpoint depuis la ressource compromise. La vraie amélioration de sécurité vient de la combinaison Managed Identity avec le principe de moindre privilège sur le rôle assigné, un monitoring des accès IMDS anormaux, et une détection des anomalies comportementales via Defender for Identity.

Comment le framework MITRE ATT&CK Cloud aide-t-il à structurer un programme de détection des escalades IAM ?

MITRE ATT&CK Cloud fournit un référentiel commun pour mapper les techniques d'escalade — T1098 Account Manipulation, T1548 Abuse Elevation Control Mechanism — à des sources de logs et des règles de détection. Chaque technique inclut des indicateurs de compromission, des sources de données recommandées (CloudTrail, GCP Audit Logs, Azure Activity Log) et des exemples de procédures concrètes, permettant aux équipes SOC de prioriser leurs règles de détection en fonction des vecteurs les plus exploités dans leur environnement.