Cloud IAM : Sécurisation des Identités et Accès AWS, Azure, GCP

1. Introduction : l'identité, plan de contrôle du cloud

Dans le cloud, l'identité est le nouveau périmètre de sécurité. Contrairement aux infrastructures on-premises protégées par des firewalls et des segments réseau, l'accès aux ressources cloud est contrôlé exclusivement par des politiques IAM (Identity and Access Management). Un utilisateur disposant des bonnes permissions peut accéder à n'importe quelle ressource depuis n'importe où dans le monde -- ce qui fait de la gestion des identités et des accès le domaine le plus critique de la sécurité cloud.

Les chiffres confirment cette réalité : selon le rapport Cloud Threat Landscape 2025 de CrowdStrike, 75 % des incidents de sécurité cloud impliquent un abus d'identité -- credentials compromises, rôles trop permissifs, service accounts mal sécurisés ou escalade de privilèges. Le rapport IBM X-Force 2025 ajoute que les organisations mettent en moyenne 230 jours pour détecter une compromission d'identité cloud, contre 180 jours pour les compromissions réseau traditionnelles.

Chaque fournisseur cloud -- AWS, Azure et GCP -- implémente son propre modèle IAM avec des concepts, une terminologie et des mécanismes distincts. Cette hétérogénéité complexifie la gouvernance des identités pour les organisations multi-cloud et crée des angles morts exploitables par les attaquants. Maîtriser les spécificités IAM de chaque CSP n'est plus optionnel : c'est un prérequis pour toute posture de sécurité cloud crédible.

Cet article propose un plongeon technique dans les modèles IAM d'AWS, Azure et GCP, documente les techniques d'attaque IAM les plus efficaces, et détaille les stratégies de durcissement -- du least privilege au Zero Standing Privileges. Chaque section intègre des exemples de configuration, des commandes d'audit et des liens vers nos articles spécialisés.

Point clé : L'IAM cloud n'est pas un sujet technique réservé aux ingénieurs DevOps. C'est un enjeu stratégique qui impacte directement le risque de fuite de données, la conformité réglementaire (NIS 2, DORA, RGPD) et la résilience de l'organisation.

2. Fondamentaux IAM cloud : concepts universels

2.1 Principals, Policies, Roles et Permissions

Malgré des implémentations différentes, les trois grands CSP partagent des concepts IAM fondamentaux :

Concept	AWS	Azure	GCP
Principal (qui)	IAM User, Role, Federated User	User, Group, Service Principal, Managed Identity	Google Account, Service Account, Google Group
Permission (quoi)	Actions (s3:GetObject, ec2:*)	Operations (Microsoft.Storage/read)	Permissions (storage.objects.get)
Policy (règle)	JSON Policy Document	Role Definition (JSON)	IAM Policy Binding
Role (ensemble)	IAM Role (assumable)	RBAC Role (assignable)	Predefined/Custom Role
Scope (où)	Resource ARN	Management Group / Subscription / RG / Resource	Organization / Folder / Project / Resource
Condition (quand)	Condition block (IpAddress, MFA, etc.)	Conditions (ABAC preview)	IAM Conditions (resource.type, etc.)

2.2 Le modèle d'évaluation des permissions

Comprendre comment chaque CSP évalue les permissions est essentiel pour anticiper les failles :

• AWS : évaluation en plusieurs passes -- SCP (Organizations) → Permission Boundaries → Policies basées sur l'identité → Policies basées sur la ressource → Session policies. Un deny explicite à n'importe quel niveau bloque l'accès. L'absence d'allow explicite est un deny implicite.
• Azure : évaluation RBAC avec héritage de scope (Management Group → Subscription → Resource Group → Resource). Les deny assignments priment sur les role assignments. Les Conditional Access policies d'Entra ID s'appliquent en amont de RBAC.
• GCP : évaluation basée sur la hiérarchie des ressources avec héritage descendant. Les Organization Policies définissent les contraintes structurelles. Les IAM Policy Bindings sont additives (union des permissions). Il n'existe pas de deny natif dans le modèle IAM GCP standard (sauf via les Deny Policies, GA depuis 2023).

3. AWS IAM : deep dive technique

3.1 Politiques JSON : anatomie et pièges

Les politiques IAM AWS sont des documents JSON structurés autour de quatre éléments clés : Effect (Allow/Deny), Action (les opérations API autorisées), Resource (les ARN ciblés) et Condition (les conditions contextuelles). La complexité réside dans les interactions entre ces éléments et les différentes couches de politiques.

// Politique IAM AWS avec conditions granulaires
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3AccessFromVPCEndpoint",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::production-data-*",
        "arn:aws:s3:::production-data-*/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-1234567890abcdef0"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "IpAddress": {
          "aws:SourceIp": ["10.0.0.0/8", "172.16.0.0/12"]
        }
      }
    }
  ]
}

3.2 Service Control Policies (SCP) et Permission Boundaries

Les SCP fonctionnent comme des garde-fous organisationnels : elles définissent les permissions maximales possibles pour tous les comptes membres d'une Organisation AWS. Une SCP ne peut pas accorder des permissions -- elle ne peut que les restreindre. C'est un mécanisme de sécurité critique pour empêcher les dérives IAM à l'échelle de l'organisation.

Les Permission Boundaries s'appliquent au niveau des utilisateurs et rôles IAM individuels. Elles définissent le périmètre maximal de permissions qu'un principal peut recevoir. Même si une politique IAM accorde *:*, les permissions effectives sont limitées à l'intersection avec le Permission Boundary. C'est l'outil clé pour la délégation sécurisée : permettre à une équipe DevOps de créer des rôles IAM tout en garantissant qu'ils ne pourront jamais s'attribuer plus de permissions que prévu.

// Permission Boundary : limiter les permissions délégables
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowedServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*",
        "cloudwatch:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyIAMChanges",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

3.3 IRSA : IAM Roles for Service Accounts (EKS)

IRSA (IAM Roles for Service Accounts) est le mécanisme recommandé pour accorder des permissions AWS aux pods Kubernetes sur EKS. Plutôt que d'utiliser le rôle IAM de l'instance node (partagé par tous les pods), IRSA permet d'associer un rôle IAM spécifique à un Kubernetes Service Account via une fédération OIDC. Chaque pod obtient des credentials temporaires limités à son service account.

# Configuration IRSA pour un pod applicatif
# 1. Créer le rôle IAM avec trust policy OIDC
aws iam create-role --role-name my-app-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789:oidc-provider/oidc.eks.eu-west-1.amazonaws.com/id/ABCDEF"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.eu-west-1.amazonaws.com/id/ABCDEF:sub": "system:serviceaccount:production:my-app-sa"
        }
      }
    }]
  }'

# 2. Annoter le ServiceAccount Kubernetes
kubectl annotate serviceaccount my-app-sa \
  -n production \
  eks.amazonaws.com/role-arn=arn:aws:iam::123456789:role/my-app-role

Sans IRSA, tous les pods sur un node partagent le rôle IAM de l'instance -- ce qui signifie qu'un pod compromis peut accéder aux permissions de tous les autres pods du même node. C'est un vecteur d'escalade de privilèges documenté dans notre article sur les attaques Kubernetes RBAC.

4. Azure RBAC et Entra ID

4.1 Le modèle RBAC Azure

Azure combine deux systèmes de gestion des accès : Entra ID (anciennement Azure AD) pour l'authentification et les rôles d'annuaire, et Azure RBAC pour les permissions sur les ressources Azure. Cette séparation est source de confusion : un utilisateur peut être Global Administrator dans Entra ID sans avoir aucun accès aux ressources Azure (subscriptions, VMs, storage), et inversement.

Les rôles RBAC Azure sont définis par des Role Definitions qui listent les actions autorisées (Actions), les actions interdites (NotActions), les actions de données (DataActions) et les actions de données interdites (NotDataActions). Ces rôles sont assignés à des scopes spécifiques dans la hiérarchie Azure :

// Rôle custom Azure RBAC - Opérateur de stockage restreint
{
  "Name": "Storage Blob Operator - Restricted",
  "Description": "Peut lire et écrire des blobs dans les conteneurs autorisés",
  "Actions": [
    "Microsoft.Storage/storageAccounts/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/read"
  ],
  "NotActions": [],
  "DataActions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write"
  ],
  "NotDataActions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete"
  ],
  "AssignableScopes": [
    "/subscriptions/xxxx/resourceGroups/production-rg"
  ]
}

4.2 Conditional Access et PIM (Privileged Identity Management)

Conditional Access est le moteur de décision Zero Trust de Microsoft Entra ID. Chaque authentification est évaluée en fonction de signaux contextuels : identité de l'utilisateur, appareil utilisé, localisation, niveau de risque détecté par Identity Protection, application ciblée. Les contrôles d'accès granulaires incluent le MFA, la conformité de l'appareil, les restrictions de session et le blocage pur et simple. Pour un guide approfondi, consultez notre article dédié sur la sécurisation d'Entra ID.

Privileged Identity Management (PIM) est la réponse de Microsoft au problème des accès privilégiés permanents. PIM transforme les attributions de rôles permanentes en attributions just-in-time (JIT) : un administrateur n'active son rôle Global Administrator que lorsqu'il en a besoin, pour une durée limitée (typiquement 1 à 8 heures), avec une justification et une approbation optionnelle. Les détails de configuration PIM sont couverts dans notre article sur les accès privilégiés JIT avec PIM.

4.3 Managed Identities

Les Managed Identities Azure éliminent le besoin de stocker des credentials dans le code ou la configuration. Azure crée et gère automatiquement un service principal dans Entra ID, et injecte les tokens d'authentification dans les ressources Azure de manière transparente. Deux types existent :

• System-assigned : liée au cycle de vie de la ressource (VM, App Service, Function). Si la ressource est supprimée, l'identité est automatiquement supprimée.
• User-assigned : créée indépendamment et assignable à plusieurs ressources. Permet la réutilisation et la gestion centralisée.

Les Managed Identities doivent toujours être préférées aux service principals avec credentials (client secrets), dont l'expiration et la rotation constituent un risque opérationnel et sécuritaire. Un client secret exposé offre un accès persistent au service principal et à toutes ses permissions -- un vecteur documenté dans notre article sur les applications enregistrées Azure AD.

5. GCP IAM : hiérarchie et service accounts

5.1 La hiérarchie des ressources GCP

Le modèle IAM GCP est fondamentalement basé sur une hiérarchie des ressources : Organization → Folders → Projects → Resources. Les permissions IAM sont héritées du haut vers le bas, ce qui signifie qu'une permission accordée au niveau Organisation se propage automatiquement à tous les dossiers, projets et ressources en dessous. Cette hérédité est puissante pour la gouvernance mais dangereuse si mal utilisée : un rôle Editor accordé au niveau Organisation donne des permissions d'écriture sur l'intégralité de l'infrastructure GCP.

5.2 Service Accounts : la surface d'attaque critique

Les Service Accounts GCP sont des identités non humaines utilisées par les applications, VMs et services pour s'authentifier auprès des API Google Cloud. Chaque service account est un principal IAM à part entière qui peut recevoir des rôles et des permissions. Le problème : les clés de service accounts sont des fichiers JSON téléchargeables qui offrent un accès persistent -- l'équivalent GCP des clés d'accès IAM AWS.

# Lister les service accounts et leurs clés
gcloud iam service-accounts list --project=my-project

# Lister les clés d'un service account (les clés externes sont à risque)
gcloud iam service-accounts keys list \
  --iam-account=my-sa@my-project.iam.gserviceaccount.com

# Bonne pratique : utiliser Workload Identity au lieu de clés
# Pour GKE :
gcloud container clusters update my-cluster \
  --workload-pool=my-project.svc.id.goog

# Créer le binding entre le KSA et le GSA
gcloud iam service-accounts add-iam-policy-binding \
  my-gsa@my-project.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:my-project.svc.id.goog[namespace/ksa-name]"

5.3 Workload Identity Federation

Workload Identity Federation permet aux workloads externes (AWS, Azure, CI/CD pipelines, Kubernetes on-prem) de s'authentifier auprès de GCP sans utiliser de clés de service account. Le workload échange un token de son identity provider (ex: OIDC token GitHub Actions, Azure AD token, AWS STS token) contre un token d'accès GCP de courte durée. C'est l'équivalent GCP d'IRSA pour AWS et des Managed Identities pour Azure. Pour les techniques d'exploitation GCP, consultez notre article sur GCP Offensive Security.

# Workload Identity Federation - GitHub Actions vers GCP
# 1. Créer un Workload Identity Pool
gcloud iam workload-identity-pools create "github-pool" \
  --project="my-project" \
  --location="global" \
  --display-name="GitHub Actions Pool"

# 2. Créer un provider OIDC pour GitHub
gcloud iam workload-identity-pools providers create-oidc "github-provider" \
  --project="my-project" \
  --location="global" \
  --workload-identity-pool="github-pool" \
  --display-name="GitHub Provider" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --issuer-uri="https://token.actions.githubusercontent.com"

# 3. Autoriser le workflow GitHub à impersonner un service account
gcloud iam service-accounts add-iam-policy-binding \
  deploy-sa@my-project.iam.gserviceaccount.com \
  --project="my-project" \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/123456/locations/global/workloadIdentityPools/github-pool/attribute.repository/my-org/my-repo"

# 4. Dans le workflow GitHub Actions :
# - uses: google-github-actions/auth@v2
#   with:
#     workload_identity_provider: 'projects/123456/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
#     service_account: 'deploy-sa@my-project.iam.gserviceaccount.com'

5.4 IAM Conditions et Organisation Policies

GCP offre des IAM Conditions pour restreindre les permissions en fonction de critères contextuels (heure, attributs de la ressource, adresse IP). Les Organization Policies permettent de définir des contraintes à l'échelle de l'organisation, similaires aux SCP d'AWS :

# IAM Condition : autoriser l'accès uniquement pendant les heures ouvrées
gcloud projects add-iam-policy-binding my-project \
  --member="user:admin@example.com" \
  --role="roles/compute.admin" \
  --condition='expression=request.time.getHours("Europe/Paris") >= 8 && request.time.getHours("Europe/Paris") <= 18,title=heures-ouvrees,description=Accès limité aux heures de bureau'

# Organization Policy : interdire les clés de service account
gcloud resource-manager org-policies enable-enforce \
  constraints/iam.disableServiceAccountKeyCreation \
  --organization=123456789

# Organization Policy : restreindre les domaines autorisés
gcloud resource-manager org-policies set-policy policy.yaml \
  --organization=123456789

# policy.yaml :
# constraint: constraints/iam.allowedPolicyMemberDomains
# listPolicy:
#   allowedValues:
#     - "C0xxxxxxx"  # Customer ID de votre organisation Google Workspace

# Organization Policy : restreindre les régions de déploiement
gcloud resource-manager org-policies set-policy region-policy.yaml \
  --organization=123456789
# constraint: constraints/gcp.resourceLocations
# listPolicy:
#   allowedValues:
#     - "europe-west1"
#     - "europe-west9"  # Paris

6. Comparaison multi-cloud : matrice de correspondance IAM

Pour les organisations multi-cloud, comprendre les équivalences entre les systèmes IAM des trois providers majeurs est essentiel. Le tableau ci-dessous présente les correspondances fonctionnelles :

Cette correspondance n'est pas parfaite : chaque provider a des spécificités qui ne trouvent pas d'équivalent direct. Par exemple, le concept de Resource-based Policies d'AWS (politiques attachées aux ressources comme les buckets S3 ou les clés KMS) n'a pas d'équivalent exact dans Azure ou GCP. Inversement, les Deny Assignments Azure et les IAM Deny Policies GCP sont des ajouts récents qui n'ont pas encore de maturité comparable aux SCP d'AWS. Pour une analyse approfondie des architectures multi-cloud, consultez notre article sur la sécurité multi-cloud.

7. Hardening IAM : bonnes pratiques universelles

7.1 Principe du moindre privilège en pratique

Le principe du moindre privilège (PoLP) est le fondement de toute stratégie IAM, mais son application pratique reste le défi principal. Voici les techniques concrètes pour implémenter le PoLP sur les trois clouds :

# === AWS : Utiliser IAM Access Analyzer pour identifier les permissions inutilisées ===
# Générer une politique basée sur l'activité réelle (last accessed)
aws accessanalyzer generate-policy \
  --policy-generation-details '{"principalArn":"arn:aws:iam::123456789:role/my-app-role"}' \
  --cloud-trail-details '{"trails":[{"cloudTrailArn":"arn:aws:cloudtrail:eu-west-1:123456789:trail/main","regions":["eu-west-1"],"allRegions":false}],"accessRole":"arn:aws:iam::123456789:role/AccessAnalyzerRole","startTime":"2025-01-01T00:00:00Z","endTime":"2025-03-01T00:00:00Z"}'

# Vérifier les permissions inutilisées (last accessed)
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::123456789:role/my-app-role

# === Azure : Utiliser Entra ID Access Reviews ===
# Créer une Access Review pour les rôles privilégiés
az rest --method POST \
  --url "https://graph.microsoft.com/v1.0/identityGovernance/accessReviews/definitions" \
  --body '{
    "displayName": "Revue trimestrielle - Global Administrators",
    "scope": {
      "query": "/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq '\''62e90394-69f5-4237-9190-012177145e10'\''",
      "queryType": "MicrosoftGraph"
    },
    "reviewers": [{"query": "/users/security-manager@contoso.com","queryType":"MicrosoftGraph"}],
    "settings": {
      "mailNotificationsEnabled": true,
      "autoApplyDecisionsEnabled": true,
      "defaultDecision": "Deny",
      "recurrence": {"pattern":{"type":"absoluteMonthly","interval":3}}
    }
  }'

# === GCP : Utiliser Policy Analyzer et Recommender ===
# Analyser les permissions effectivement utilisées
gcloud policy-intelligence query-activity \
  --project=my-project \
  --activity-type=serviceAccountLastAuthentication

# Obtenir les recommandations de réduction de permissions
gcloud recommender recommendations list \
  --project=my-project \
  --location=global \
  --recommender=google.iam.policy.Recommender

7.2 Gestion des credentials et rotation

La gestion des credentials est le talon d'Achille de la sécurité IAM. Les access keys, client secrets et service account keys sont des vecteurs de compromission persistants qui survivent au-delà de la session de l'utilisateur. Les bonnes pratiques universelles :

• Privilégier les identités fédérées : SSO via SAML/OIDC plutôt que des utilisateurs IAM locaux
• Utiliser les identités machine natives : IRSA (AWS), Managed Identities (Azure), Workload Identity (GCP) plutôt que des clés statiques
• Rotation automatique : max 90 jours pour les clés d'accès, 180 jours pour les client secrets avec alerte 30 jours avant expiration
• Détection des credentials exposés : GitHub secret scanning, AWS Secrets Manager rotation, Azure Key Vault avec expiration automatique
• MFA obligatoire : pour tous les comptes humains, avec phishing-resistant (FIDO2/passkeys) pour les comptes privilégiés

7.3 Monitoring et détection des anomalies IAM

Le monitoring IAM doit détecter trois catégories de menaces : les accès non autorisés (credentials volés ou fédération compromise), l'escalade de privilèges (modification de politiques ou de rôles) et les mouvements latéraux (utilisation de permissions cross-account ou cross-project). Les événements critiques à surveiller :

# === AWS CloudTrail - Événements IAM critiques ===
# Détection : création d'un utilisateur IAM avec des clés d'accès
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --start-time "2025-03-01T00:00:00Z" \
  --end-time "2025-03-08T00:00:00Z"

# Événements critiques à alerter :
# - CreateUser, CreateAccessKey, AttachUserPolicy (création de persistence)
# - AssumeRole avec source inhabituelle (mouvement latéral)
# - PutRolePolicy, CreatePolicyVersion (escalade de privilèges)
# - ConsoleLogin sans MFA depuis une IP inconnue
# - DeactivateMFADevice (désactivation de MFA)

# === Azure - Entra ID Audit & Sign-in Logs ===
# Requête KQL dans Log Analytics / Sentinel
# SigninLogs
# | where ResultType == 0  // connexions réussies
# | where RiskLevelAggregated in ("high", "medium")
# | where AppDisplayName in ("Azure Portal", "Microsoft Graph")
# | project TimeGenerated, UserPrincipalName, IPAddress, Location, RiskDetail
# | sort by TimeGenerated desc

# === GCP - Cloud Audit Logs ===
# Détection : modifications IAM suspectes
gcloud logging read \
  'protoPayload.methodName="google.iam.admin.v1.SetIamPolicy" OR
   protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey" OR
   protoPayload.methodName="SetIamPolicy"' \
  --project=my-project \
  --freshness=24h \
  --format=json

8. Scénarios d'attaque IAM et remédiation

8.1 Scénario 1 : Escalade de privilèges via politique IAM permissive

L'attaque la plus classique consiste à exploiter une politique IAM qui accorde iam:* ou des permissions de type *:*. Un attaquant disposant d'un accès limité peut créer de nouveaux rôles, s'attribuer des permissions administratives, ou modifier les politiques existantes pour élever ses privilèges :

# Attaque : un développeur dispose de iam:CreatePolicyVersion
# Il peut modifier une politique existante pour s'octroyer admin
aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789:policy/dev-policy \
  --policy-document '{
    "Version":"2012-10-17",
    "Statement":[{
      "Effect":"Allow",
      "Action":"*",
      "Resource":"*"
    }]
  }' \
  --set-as-default

# Remédiation : Permission Boundary qui bloque les actions IAM dangereuses
# + SCP au niveau de l'OU qui interdit iam:CreatePolicyVersion
# sauf pour le rôle d'administration centralisé

8.2 Scénario 2 : Persistance via fédération SAML/OIDC

Un attaquant ayant compromis un compte administratif cloud peut créer un Identity Provider (IdP) fédéré qui pointe vers son propre fournisseur SAML. Cela lui permet de s'authentifier à tout moment avec des rôles arbitraires, même après la rotation des credentials compromis initialement. Cette technique de persistance est particulièrement dangereuse car elle survit aux resets de mots de passe et à la révocation des clés :

# Attaque : création d'un IdP SAML malveillant dans AWS
aws iam create-saml-provider \
  --saml-metadata-document file://evil-metadata.xml \
  --name "BackdoorIdP"

aws iam create-role \
  --role-name "BackdoorRole" \
  --assume-role-policy-document '{
    "Version":"2012-10-17",
    "Statement":[{
      "Effect":"Allow",
      "Principal":{"Federated":"arn:aws:iam::123456789:saml-provider/BackdoorIdP"},
      "Action":"sts:AssumeRoleWithSAML",
      "Condition":{"StringEquals":{"SAML:aud":"https://signin.aws.amazon.com/saml"}}
    }]
  }'

# Remédiation :
# 1. Auditer régulièrement les IdP configurés
aws iam list-saml-providers
aws iam list-open-id-connect-providers

# 2. SCP pour bloquer la création d'IdP non autorisés
# 3. Alerte CloudTrail sur CreateSAMLProvider / CreateOpenIDConnectProvider
# 4. Revue mensuelle des trust relationships de tous les rôles

8.3 Scénario 3 : Mouvement latéral cross-cloud

Dans les environnements multi-cloud, un attaquant qui compromet un environment AWS peut pivoter vers Azure ou GCP via des fédérations inter-cloud mal configurées. Par exemple, un Workload Identity Federation GCP qui accepte des tokens OIDC d'AWS sans restriction sur le rôle source permet à tout rôle AWS d'accéder aux ressources GCP. La remédiation consiste à restreindre les conditions de fédération au strict minimum (rôle source spécifique, account ID, claims OIDC). Consultez notre article sur les erreurs de configuration cloud pour d'autres scénarios d'attaque.

9. Conclusion : vers une posture IAM mature

La sécurité IAM dans le cloud est un processus continu, pas un projet ponctuel. L'identité est le plan de contrôle du cloud, et chaque permission excessive, chaque credential non roté, chaque fédération mal configurée est un vecteur d'attaque potentiel. Les organisations matures adoptent une approche holistique qui combine :

• Moindre privilège systématique : utiliser les outils d'analyse natifs (IAM Access Analyzer, Policy Analyzer, Entra Access Reviews) pour réduire continuellement les permissions
• Identités fédérées et machine-native : éliminer les credentials statiques au profit de SSO, IRSA, Managed Identities et Workload Identity
• Accès Just-in-Time : PIM (Azure), IAM Identity Center (AWS), PAM (GCP) pour les accès privilégiés temporaires
• Contraintes organisationnelles : SCP, Azure Policy, Organization Policies pour définir des garde-fous infranchissables
• Monitoring continu : alertes sur les événements IAM critiques via CloudTrail, Audit Logs et Entra ID Sign-in Logs
• Tests offensifs réguliers : simuler les scénarios d'escalade de privilèges et de mouvement latéral pour valider les contrôles

La complexité multi-cloud ajoute une dimension supplémentaire : chaque provider a ses spécificités, ses pièges et ses angles morts. La standardisation de la posture IAM à travers les clouds passe par des outils CSPM qui normalisent les contrôles et offrent une visibilité unifiée. Combinée avec une gouvernance des identités rigoureuse et des tests de sécurité réguliers, une stratégie IAM mature réduit considérablement le risque de compromission cloud.

En résumé : Dans le cloud, l'identité est tout. Une politique IAM trop permissive est l'équivalent d'un mot de passe admin sur un post-it. Appliquez le moindre privilège, éliminez les credentials statiques, monitorez chaque action IAM, et testez régulièrement votre posture -- c'est la seule approche qui résiste aux attaquants modernes.