IAM expliqué simplement : identités, rôles et permissions cloud

IAM (Identity and Access Management) est la discipline qui répond à trois questions fondamentales de sécurité cloud : qui peut faire quoi, sur quelles ressources et dans quelles conditions. C'est la colonne vertébrale de tout déploiement cloud moderne : une faille IAM conduit quasi systématiquement à une compromission massive, comme l'ont démontré les incidents Capital One 2019 (SSRF + IMDSv1 + rôle IAM trop permissif), Uber 2022 (compromission MFA + pivot via identité), MGM Resorts 2023 (social engineering + Okta + identités cloud), Snowflake 2024 (clients sans MFA). Cet article explique les concepts IAM universels, compare les modèles AWS / Azure / GCP / Kubernetes avec des exemples concrets, détaille les principes d'authentification vs autorisation, introduit le CIEM (Cloud Infrastructure Entitlement Management) et liste les pièges courants à éviter en 2026.

Qu'est-ce que l'IAM exactement

L'IAM couvre l'ensemble des mécanismes techniques et organisationnels qui gèrent les identités numériques et leurs droits d'accès aux ressources.

Définition opérationnelle en 3 volets

1. Volet humain : gestion des comptes utilisateurs, cycles de vie (création, modification, suppression), authentification forte (MFA), SSO via IdP centralisé.
2. Volet machines : service accounts, workload identities, secrets/clés, credentials éphémères, authentification mTLS, OIDC tokens entre systèmes.
3. Volet gouvernance : revue périodique des droits, séparation des privilèges, logs d'audit, alerting sur anomalies, compliance NIS 2 / DORA / ISO 27001.

Tous les cloud providers (AWS, Azure, GCP, Oracle Cloud, Alibaba Cloud) et toutes les plateformes modernes (Kubernetes, Snowflake, Databricks, Salesforce) reposent sur une implémentation d'IAM, avec des terminologies et des mécanismes qui divergent mais des concepts de fond identiques.

Les 4 concepts fondamentaux

Tout système IAM, quel que soit le cloud, repose sur quatre briques élémentaires.

Schéma d'une décision IAM type

    [Identité]        Alice / role-lambda-reader
        +
    [Action]          s3:GetObject
        +                                 ---> Décision : ALLOW / DENY
    [Ressource]       arn:aws:s3:::logs/*
        +
    [Conditions]      SourceIp = 10.0.0.0/8
                      MFA = true
                      CurrentTime < 2026-12-31

Un système IAM mature ajoute un 5e élément : les conditions (contexte). Contraintes d'IP source, présence de MFA, heure, tags de ressource, source de la requête (AWS service name, identity federation). Les conditions permettent l'ABAC (Attribute-Based Access Control) en complément du RBAC (Role-Based) traditionnel.

IAM AWS — modèle et spécificités

AWS IAM est le modèle historique de référence, créé en 2011. Son vocabulaire est largement repris par les autres clouds.

Briques AWS IAM

• IAM Users : identités humaines persistantes, console + clés d'accès programmatique.
• IAM Groups : regroupement de Users avec policies partagées.
• IAM Roles : identités assumables par services AWS (EC2, Lambda), par humains via federation (SAML, OIDC), par principaux cross-account. Toujours produit des credentials temporaires via STS.
• IAM Identity Center (ex AWS SSO) : gouvernance SSO centralisée multi-compte avec permissions sets.
• Service-linked roles : rôles gérés par les services AWS pour leurs propres opérations.
• Permission boundaries : plafond maximum de permissions, même si la policy le dépasse.

Exemple d'Identity Policy (attachée à une identité)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadLogsBucketOnly",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::company-logs",
        "arn:aws:s3:::company-logs/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-3"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Exemple de Trust Policy (attachée à un Role, définit qui peut l'assumer)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

Ce pattern (OIDC federation depuis GitHub Actions) est le standard 2026 pour éviter les access keys long-terme dans les pipelines CI/CD.

Outils IAM AWS essentiels

• IAM Access Analyzer : détecte les ressources exposées hors compte, les policies public, les unused access keys.
• IAM Identity Center : remplace IAM Users pour les accès humains multi-compte.
• IAM Roles Anywhere : pour workloads on-premise authentifiés via certificats X.509.
• Service Control Policies (SCP) dans AWS Organizations : plafonds au niveau organisationnel.

IAM Azure — modèle et spécificités

Azure sépare nettement authentification et autorisation.

Architecture Azure

• Microsoft Entra ID (ex Azure Active Directory) : service d'identité, gère les utilisateurs humains, les applications, les service principals. Authentification via SAML, OIDC, OAuth 2.0.
• Azure RBAC : autorisation sur les ressources Azure. Assignation de rôles (built-in ou custom) à des identités Entra ID sur des scopes (management group, subscription, resource group, resource).
• Managed Identities : identités Azure pour workloads, gérées automatiquement, sans secrets à manipuler. Système-assigned (liée au cycle de vie de la ressource) ou user-assigned (réutilisable).
• Service Principals : identité applicative explicite dans Entra ID, historique, remplacée progressivement par Managed Identities.
• Privileged Identity Management (PIM) : élévation just-in-time pour les rôles privilégiés, avec approbation et durée limitée.
• Conditional Access : politiques de contrôle basées sur contexte (device, localisation, risque).

Rôles built-in les plus utilisés

Exemple de Role Assignment via Azure CLI

# Assignation d'un rôle Reader sur un resource group précis
az role assignment create \
  --assignee "alice@example.com" \
  --role "Reader" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod"
 
# Création d'une Managed Identity système-assignée sur une VM
az vm identity assign --name myVM --resource-group myRG
 
# Utilisation côté workload : le SDK Azure récupère automatiquement le token
# via l'endpoint IMDS Azure (http://169.254.169.254/metadata/identity/oauth2/token)

IAM GCP — modèle et spécificités

GCP organise l'IAM autour de la hiérarchie Organization → Folder → Project → Resource.

Briques GCP IAM

• Members (principals) : Google accounts, service accounts, Google groups, Google Workspace / Cloud Identity domains, allAuthenticatedUsers, allUsers.
• Roles : primitive roles (Owner, Editor, Viewer — dépréciés, à éviter), predefined roles (centaines, par service), custom roles.
• Policy bindings : attribution member → role au niveau d'une ressource.
• Service accounts : identités pour workloads. Impersonation possible via iam.serviceAccounts.getAccessToken.
• Workload Identity Federation : remplace les service account keys, authentification depuis AWS, Azure, OIDC providers (GitHub Actions, GitLab).
• Organization Policies : contraintes au niveau org (location restrictions, allowed services, etc.).
• IAM Conditions : ABAC via attributs de ressource (tags, timestamp, requester IP).
• IAM Recommender : suggestions de downgrade basées sur l'usage réel 90 jours.

Exemple de IAM binding GCP via gcloud

# Attribution du rôle Storage Object Viewer sur un bucket
gcloud storage buckets add-iam-policy-binding gs://company-logs \
  --member="serviceAccount:log-reader@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"
 
# Avec condition IAM : accès uniquement pendant les heures ouvrées
gcloud projects add-iam-policy-binding my-project \
  --member="user:alice@example.com" \
  --role="roles/compute.viewer" \
  --condition='expression=request.time.getHours("Europe/Paris") >= 8 && request.time.getHours("Europe/Paris") < 20,title=business-hours-only'
 
# Workload Identity Federation pour GitHub Actions
gcloud iam workload-identity-pools create "github-pool" \
  --project="my-project" \
  --location="global"

Hiérarchie et héritage

Les policies s'héritent de haut en bas (Organization → Folder → Project → Resource). Un rôle Viewer sur le project donne également Viewer sur toutes les ressources enfants. Important : les policies sont union (pas d'intersection) — ajouter un binding ne retire jamais les droits existants. Depuis 2022, les Deny policies GCP permettent de bloquer explicitement des actions, complément nécessaire à l'héritage Allow-only historique.

IAM Kubernetes en résumé

Kubernetes utilise son propre modèle IAM distinct du cloud sous-jacent.

• ServiceAccount : identité d'un pod ou workload.
• Role / ClusterRole : regroupement de permissions (verbs + resources).
• RoleBinding / ClusterRoleBinding : lien entre ServiceAccount et Role.

Couvert en détail dans l'article Sécurité Kubernetes pour développeurs. Point critique : un cluster Kubernetes hébergé sur AWS EKS, Azure AKS ou GCP GKE combine deux IAM distincts — celui du cloud (accès au cluster et aux nodes) et celui de Kubernetes (accès aux ressources dans le cluster). Les deux doivent être cohérents.

Principes universels : least privilege, zero trust, séparation

Au-delà des spécificités de chaque cloud, cinq principes universels structurent une stratégie IAM saine.

1. Moindre privilège (Principle of Least Privilege)

Ne donner que les permissions strictement nécessaires, pour la durée strictement nécessaire, sur les ressources strictement concernées. Corrolaire : les permissions doivent être scoped (par ressource), time-bound (éphémères), audités (logs).

2. Zero Standing Privileges (ZSP)

Personne ne détient en permanence des privilèges élevés. L'élévation est just-in-time, sur demande, avec approbation et durée limitée. Implémentations : Azure PIM, AWS SSO permission sets avec session duration courte, Teleport, StrongDM, JIT access dans les outils CIEM.

3. Séparation des privilèges

L'administrateur IAM n'est pas l'administrateur des ressources. Deux personnes minimum pour des actions critiques (break-glass). Matérialisé par des rôles distincts : user-access-administrator vs contributor.

4. Identités machines courtes et federated

Bannir les access keys / service account keys long-terme. Utiliser :

• AWS STS + IAM Roles Anywhere ou OIDC federation (GitHub Actions, GitLab).
• Azure Managed Identities ou Workload Identity Federation.
• GCP Workload Identity Federation.

5. MFA obligatoire sur les identités humaines

Pas de compte console humain sans MFA. Enforcement via SCP AWS Organizations, Conditional Access Azure, Organization Policy GCP. 83 % des incidents cloud origine identité concernent des comptes sans MFA effective (Verizon DBIR 2024).

Authentification vs autorisation

Les deux faces de l'IAM sont à séparer conceptuellement et techniquement.

Authentification (AuthN)

Répond à : qui es-tu ? Mécanismes :

• Mot de passe + MFA : humains, IdP centralisé (Okta, Entra ID, Google Workspace, Keycloak).
• Certificats X.509 : machines, mTLS.
• OIDC / OAuth 2.0 tokens : SSO moderne, federation.
• SAML : SSO historique, encore majoritaire en entreprise.
• Clés d'accès / access keys : legacy, remplacées progressivement par la federation.
• Tokens JWT : transport standard des claims entre systèmes.

Autorisation (AuthZ)

Répond à : que peux-tu faire ? Mécanismes :

• RBAC (Role-Based) : permissions groupées en rôles, rôles attribués aux identités. Dominant en 2026.
• ABAC (Attribute-Based) : décision basée sur attributs dynamiques (tags, IP, heure, contexte). Complément d'ABAC via IAM Conditions AWS/GCP, Conditional Access Azure.
• PBAC (Policy-Based) : policies déclaratives via OPA, Cedar. Extension pour contextes multi-systèmes.
• ReBAC (Relationship-Based) : permissions basées sur relations (Zanzibar de Google, SpiceDB, OpenFGA). Émergent pour SaaS multi-tenant.

Protocoles de référence en 2026

Identity Providers (IdP) majeurs

Okta, Microsoft Entra ID, Google Workspace, Ping Identity, OneLogin, Auth0 (Okta), JumpCloud, Keycloak (open-source), Authentik (open-source). Pour les consommateurs finaux : Google Sign-In, Apple Sign-In, GitHub OAuth, etc.

CIEM — la gouvernance IAM moderne

CIEM (Cloud Infrastructure Entitlement Management) est la catégorie d'outils qui gouverne les permissions cloud à grande échelle. Apparue vers 2019-2020, standardisée depuis 2022-2023.

Problème résolu

Un compte AWS mature compte 500 à 10 000 identités avec potentiellement des millions de permissions effectives via l'effet combinatoire identités × rôles × ressources × conditions. Impossible à auditer manuellement.

Fonctions d'un CIEM

Leaders CIEM 2026

Observation typique sur un compte cloud non gouverné

Microsoft Permissions Management 2023 rapporte que plus de 95 % des permissions attribuées dans le cloud public sont inutilisées dans les 90 jours sur les comptes non gouvernés. Un compte mature avec CIEM actif ramène ce chiffre à 30-50 % par right-sizing continu.

Pièges courants à éviter

Utiliser le compte root pour le travail quotidien. Le root AWS / Global Administrator Entra ID / Organization Admin GCP doit être MFA obligatoire et utilisé uniquement en break-glass. Opérations courantes via IAM Identity Center / PIM / federation.

Access keys long-terme qui traînent dans le code. Premier vecteur de compromission via GitHub leaks : plus de 12 millions de secrets exposés publiquement en 2023 selon GitGuardian. Remplacer par STS / Managed Identities / Workload Identity Federation.

Wildcards dans les policies copiés depuis un tutoriel. "Action": "*", "Resource": "*" équivaut à admin. Toujours scope par service et par ressource spécifique.

Trust policies cross-account sans conditions. Autoriser sts:AssumeRole depuis n'importe quel principal externe est un vecteur utilisé par plusieurs ransomwares pour pivot cloud. Ajouter ExternalId condition + restriction aux principals de son organisation.

Pas de MFA sur les comptes privilégiés. 83 % des incidents cloud origine identité concernent des comptes sans MFA effective. Enforcement via SCP / Conditional Access / Organization Policy, pas sur base volontaire.

Groupes de permissions « just in case ». Groupe « developers » avec 50 permissions dont 10 seulement utilisées. Effectuer un right-sizing CIEM trimestriel.

Ne pas monitorer les changements IAM. Un attaquant qui compromet une identité modifie les policies pour persister. CloudTrail / Azure Activity Log / GCP Admin Audit Logs doivent être surveillés avec alerting sur modifications IAM.

Confondre authentification et autorisation. Un SSO (AuthN) ne garantit pas les permissions correctes (AuthZ). Les deux doivent être conçus séparément.

Mélanger identités humaines et identités machines. Un service account qui porte parfois des actions utilisateurs brouille l'audit. Séparer strictement, nommer explicitement (sa-lambda-reader-prod vs user-alice).

Points clés à retenir

• IAM = qui peut faire quoi, sur quelles ressources, dans quelles conditions.
• 4 briques fondamentales : identité (principal), ressource, action, policy — universellement présentes dans AWS, Azure, GCP, Kubernetes.
• AWS IAM : Users, Roles, Groups, STS, Identity Center, Access Analyzer, SCP.
• Azure IAM : Entra ID (AuthN) + RBAC Azure (AuthZ), Managed Identities, PIM, Conditional Access.
• GCP IAM : Members, Roles, Policy bindings, hiérarchie Org/Folder/Project, Workload Identity Federation, Deny policies.
• 5 principes universels : least privilege, zero standing privileges, séparation des privilèges, identités machines éphémères, MFA humains.
• OIDC federation standard obligatoire en 2026 pour pipelines CI/CD (GitHub Actions, GitLab) — plus d'access keys long-terme.
• CIEM (Wiz, Orca, Microsoft Entra Permissions Management, Sonrai, SailPoint) gouverne 95 % d'over-permissioning des comptes cloud matures.
• Incidents cloud 2023-2024 : 50 %+ origine identité (Capital One, Uber, MGM, Snowflake). L'IAM est le périmètre de défense prioritaire devant le réseau et l'applicatif.
• 5 pièges à éliminer en priorité : root quotidien, access keys long-terme, wildcards policies, trust cross-account sans condition, MFA absente sur privilégiés.

Pour aller plus loin

• Roadmap Cloud Security 2026 — parcours d'apprentissage complet incluant IAM comme fondation.
• Sécurité Kubernetes pour développeurs — zoom sur l'IAM Kubernetes et RBAC interne cluster.
• OPA Open Policy Agent : définition, Rego et cas d'usage 2026 — moteur de policy-as-code pour autorisation multi-système.
• Outils DevSecOps à connaître en 2026 — stack incluant CIEM et CNAPP.
• Roadmap DevSecOps 2026 — parcours général qui couvre l'IAM dans son contexte SDLC.
• Devenir DevSecOps sans expérience — pillar catégorie, point d'entrée global.