Qu'est-ce que l'IAM ? Définition technique complète 2025

L'IAM (Identity and Access Management) est la discipline qui gère le cycle de vie des identités numériques (humaines et non-humaines) et leurs accès aux ressources d'une organisation, selon le framework AAA élargi en 5 piliers : Authentication (qui es-tu ?), Authorization (qu'as-tu le droit de faire ?), Accounting (qu'as-tu fait ?), Administration (comment gérer le cycle de vie ?), Audit (trace vérifiable des actions). Elle s'étend historiquement depuis les comptes locaux Unix des années 1970 jusqu'aux architectures Zero Trust modernes (NIST SP 800-207, 2020) où chaque requête est vérifiée indépendamment. En 2025, l'IAM se segmente en 5 domaines distincts avec leurs outils et équipes dédiés : Workforce Identity (employés internes, typiquement Okta ou Microsoft Entra ID), CIAM (Customer Identity and Access Management, utilisateurs finaux : Auth0, Okta Customer Identity, Azure AD B2C), PAM (Privileged Access Management, administrateurs : CyberArk, BeyondTrust, Delinea), IGA (Identity Governance and Administration, compliance et lifecycle : SailPoint, Saviynt, Omada), NHI (Non-Human Identity, workloads / services / machines : HashiCorp Vault, Akeyless, GitGuardian Aembit). Les NHI dépassent les humains en nombre dans les organisations cloud-native avec un ratio typique de 10-50 NHI pour 1 humain (GitGuardian Non-Human Identity Report 2024), et représentent 45 % des incidents cloud 2023-2024. Les modèles d'autorisation vont des plus simples (ACL, RBAC) aux plus expressifs (ABAC, PBAC, ReBAC) — le pattern 2025 standard combine RBAC comme fondation + ABAC en surcouche contextuelle, avec émergence de ReBAC (Google Zanzibar 2019, OpenFGA, SpiceDB) pour les graphes complexes. Les protocoles clés sont LDAP (annuaire), Kerberos (authentification), SAML 2.0 (federation SSO enterprise), OAuth 2.1 + OIDC 1.0 (authentification + authorization API / SaaS), SCIM (provisioning cycle de vie). Cet article détaille la définition AAA+, l'histoire de l'IAM depuis 1970, les 5 piliers, les types d'identités, les modèles d'autorisation avec exemples code, les protocoles et leurs cas d'usage, les 5 domaines IAM avec outils 2025, et la place centrale de l'IAM dans Zero Trust. Pour une entrée accessible cloud-focused, voir IAM expliqué simplement. Pour la fiche métier IAM engineer, Qu'est-ce qu'un ingénieur IAM.

1. Définition technique : framework AAA élargi

Le modèle historique de référence est AAA (Authentication, Authorization, Accounting) popularisé par les protocoles RADIUS (RFC 2865, 2000) et Diameter (RFC 6733, 2012). En 2025, les RSSI et architectes identity étendent à 5 piliers pour couvrir l'IAM de bout en bout :

Sans l'un des 5, l'IAM est incomplet. Un système qui authentifie bien mais n'audite pas produit des angles morts catastrophiques lors d'une investigation post-compromission.

2. Histoire rapide de l'IAM (1970 → 2025)

Évolution IAM 1970 → 2025
──────────────────────────────────────────────────────
1970s   Comptes locaux Unix (/etc/passwd, crypt(3))
1980s   NIS, LDAP (X.500)
1988    Kerberos v5 (MIT), puis Windows NT 4.0 Domain
1993    RADIUS (Livingston)
2000    Active Directory (Windows 2000)
2002    SAML 1.0 → 2005 SAML 2.0 (OASIS)
2007    OAuth 1.0 → 2012 OAuth 2.0 (RFC 6749)
2014    OIDC 1.0 (OpenID Foundation)
2015    SCIM 2.0 (RFC 7644)
2016    Azure AD (devenu Entra ID en 2023)
2019    Google Zanzibar (ReBAC paper)
2020    NIST SP 800-207 Zero Trust Architecture
2021    WebAuthn L2, FIDO2 Passwordless
2023    CISA Zero Trust Maturity Model 2.0
2024    OAuth 2.1 draft consolidé, passkeys adoption massive
2025    Non-Human Identity dédié (NHI), ReBAC mainstream

Chaque évolution répond à un problème concret. Exemple : SAML 2.0 résout le SSO enterprise (une authentification pour N applications), OAuth 2.0 résout la délégation d'autorisation API sans partager de credentials, WebAuthn résout l'attaque phishing (clés privées bound au domaine, impossibles à exfiltrer par MITM).

3. Les 3 grands types d'identités

3.1 Workforce Identity (employés, prestataires)

• Population : employés CDI, CDD, alternants, stagiaires, prestataires internes, sous-traitants.
• Outils typiques 2025 : Microsoft Entra ID (anciennement Azure AD) 75 % marché France, Okta 15 %, Ping Identity 5 %, ForgeRock + autres 5 % (benchmarks Gartner IAM Magic Quadrant 2024).
• Protocoles dominants : SAML 2.0 (legacy enterprise apps), OIDC (SaaS modernes), SCIM (provisioning lifecycle), LDAP + Kerberos (on-prem hybride).
• Cycle de vie : onboarding automatisé via SCIM + role mining, offboarding sous 1-4h post-départ RH, access review 2x/an minimum.

3.2 Customer Identity (CIAM)

• Population : utilisateurs finaux externes (clients e-commerce, abonnés SaaS, patients, citoyens).
• Outils typiques 2025 : Auth0 (Okta), Okta Customer Identity, Microsoft Entra External ID (ex-Azure AD B2C), Ping Identity CIAM, ForgeRock Identity Cloud, Keycloak open-source.
• Contraintes spécifiques CIAM : scale (millions d'utilisateurs vs milliers en workforce), UX critique (abandon si friction), login social (Google, Apple, Facebook, LinkedIn), consent management RGPD, self-service (password reset, MFA enrollment), passwordless passkeys adoption.
• Protocoles : OIDC dominant, OAuth 2.1, SAML sur partenaires B2B, plus rare LDAP.

3.3 Non-Human Identity (NHI)

Explosion 2023-2025 avec la cloud-nativisation. Selon GitGuardian Non-Human Identity Report 2024 et CyberArk Identity Security Threat Landscape 2024 :

Types de NHI :

Pour l'architecture complète de gestion NHI, voir Secrets management dans le cloud.

4. Les 5 modèles d'autorisation

4.1 ACL (Access Control List)

Modèle le plus ancien et simple : liste explicite des principals autorisés par ressource.

# /etc/acl — exemple conceptuel
resource: /var/data/finance/
  user: alice        → read, write
  user: bob          → read
  group: accounting  → read

Forces : simplicité, traçabilité directe. Limites : scale mal (chaque ressource maintient sa liste), devient ingérable au-delà de ~500 ressources × 100 users.

4.2 RBAC (Role-Based Access Control)

Standardisé par NIST SP 800-162 et ISO/IEC 9075. Les permissions sont attribuées aux rôles, les utilisateurs héritent via leur appartenance.

# Exemple Python conceptuel — pattern RBAC
ROLES = {
    "analyst": {
        "permissions": ["read:transactions", "read:customers"]
    },
    "accountant": {
        "permissions": ["read:transactions", "write:transactions", "read:customers"]
    },
    "admin": {
        "permissions": ["read:*", "write:*", "delete:*"]
    },
}
 
def can(user, action: str, resource: str) -> bool:
    for role in user.roles:
        perms = ROLES.get(role, {}).get("permissions", [])
        for pattern in perms:
            if pattern == f"{action}:{resource}" or pattern == f"{action}:*":
                return True
    return False

Forces : auditable, simple pour 80 % des cas. Limites : role explosion — au-delà de ~500 rôles, la maintenance devient un enfer (un rôle par combinaison département × fonction × projet × environnement).

4.3 ABAC (Attribute-Based Access Control)

NIST SP 800-162 (2014). Les décisions se basent sur des attributs du sujet, de la ressource, de l'action et du contexte.

# Exemple ABAC — décision policy en Python
def can_access(subject, resource, action, context) -> bool:
    # Règle métier : un analyste junior ne peut lire que les transactions
    # de son département, en heures ouvrées, depuis un device compliant
    if (
        subject.role == "analyst_junior"
        and action == "read"
        and resource.type == "transaction"
        and resource.department == subject.department
        and 8 <= context.hour <= 20
        and context.device_compliant is True
    ):
        return True
 
    # Règle : admin peut tout faire si MFA + IP corporate
    if (
        "admin" in subject.roles
        and context.mfa_verified is True
        and context.ip_range == "corporate"
    ):
        return True
 
    return False

Forces : très expressif, décisions contextuelles. Limites : complexité de maintenance explose, debug difficile, performance (évaluation à chaque requête).

4.4 PBAC (Policy-Based Access Control)

Évolution ABAC avec policies as code externalisées. Standard pratique : OPA (Open Policy Agent) + Rego (CNCF graduated project).

# Exemple Rego OPA
package app.authz
 
default allow := false
 
allow if {
    input.subject.role == "analyst_junior"
    input.action == "read"
    input.resource.type == "transaction"
    input.resource.department == input.subject.department
    input.context.hour >= 8
    input.context.hour <= 20
    input.context.device_compliant == true
}
 
allow if {
    "admin" in input.subject.roles
    input.context.mfa_verified == true
    input.context.ip_range == "corporate"
}

Forces : policies versionnables Git, testables unitairement, déployables via CI/CD. Limites : courbe d'apprentissage Rego.

4.5 ReBAC (Relationship-Based Access Control)

Popularisé par le paper Google Zanzibar (2019) qui décrit le système d'autorisation derrière Google Drive / YouTube / Gmail. Modèle graphe où les permissions dérivent des relations entre objets.

Exemples d'implémentations 2024-2025 : OpenFGA (CNCF, 2022), Auth0 FGA, SpiceDB (AuthZed), Permify (Upstash).

# Exemple OpenFGA — modèle de base
type user
 
type document
  relations
    define owner: [user]
    define editor: [user] or owner
    define viewer: [user] or editor
 
type organization
  relations
    define member: [user]
    define admin: [user]
 
# Tuples (relations concrètes)
user:alice  owner   document:doc-123
user:bob    editor  document:doc-123
user:bob    member  organization:acme
user:alice  admin   organization:acme

Requête : « Alice peut-elle éditer doc-123 ? » → oui, car owner implique editor.

Forces : modélise les graphes complexes (Drive sharing, GitHub repos, SaaS multi-tenant). Limites : maturité écosystème < RBAC/ABAC, performance en graphe profond.

4.6 Comparaison synthétique

Pattern 2025 recommandé : RBAC fondation + ABAC/PBAC en surcouche contextuelle + ReBAC si produit avec graphes de sharing complexes.

5. Protocoles clés de l'IAM

5.1 LDAP (Lightweight Directory Access Protocol)

RFC 4510-4533. Annuaire hiérarchique. Usage 2025 : requêtes users/groups on-prem (ADDS, OpenLDAP, 389DS), authentification legacy, synchronisation vers cloud IdPs.

5.2 Kerberos

RFC 4120 (v5). Authentification à base de tickets avec KDC (Key Distribution Center). Dominant sur Active Directory. Attaques classiques : Kerberoasting (T1558.003 MITRE), AS-REP Roasting (T1558.004), Golden Ticket (T1558.001).

5.3 SAML 2.0

OASIS 2005. XML-based SSO enterprise. Assertion SAML contient identité + attributs, signée par IdP, consommée par SP (Service Provider). Toujours dominant en 2025 pour SaaS enterprise et legacy.

<!-- Exemple SAML Assertion simplifiée -->
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
           IssueInstant="2026-04-24T09:00:00Z" Version="2.0">
  <Issuer>https://idp.example.com</Issuer>
  <Subject>
    <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      alice@example.com
    </NameID>
  </Subject>
  <AttributeStatement>
    <Attribute Name="role">
      <AttributeValue>manager</AttributeValue>
    </Attribute>
    <Attribute Name="department">
      <AttributeValue>finance</AttributeValue>
    </Attribute>
  </AttributeStatement>
</Assertion>

5.4 OAuth 2.0 / OAuth 2.1

RFC 6749 (OAuth 2.0, 2012) + OAuth 2.1 draft consolidé. Protocole de délégation d'autorisation via access tokens. Scopes, refresh tokens, flows multiples (Authorization Code avec PKCE recommandé depuis 2019, Client Credentials pour M2M, Device Code pour IoT). Client Secret JWT + PAR recommandés pour production 2025.

5.5 OIDC (OpenID Connect 1.0)

OpenID Foundation 2014. Extension d'OAuth 2.0 ajoutant une couche d'authentification (ID Token JWT). L'ID Token contient identité + claims. Remplace progressivement SAML en 2025 sur SaaS modernes.

// Exemple ID Token JWT payload OIDC
{
  "iss": "https://idp.example.com",
  "sub": "user-abc123",
  "aud": "client-app-xyz",
  "exp": 1745481600,
  "iat": 1745478000,
  "email": "alice@example.com",
  "email_verified": true,
  "name": "Alice Dupont",
  "groups": ["analysts", "finance-read"]
}

5.6 SCIM (System for Cross-domain Identity Management)

RFC 7642-7644 (2015). API REST pour provisioning automatique des identités entre IdP et applications. Endpoint /Users et /Groups avec opérations CRUD. Essentiel pour cycle de vie automatisé.

POST /scim/v2/Users HTTP/1.1
Host: sp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.example
Content-Type: application/scim+json
 
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "alice@example.com",
  "name": { "familyName": "Dupont", "givenName": "Alice" },
  "emails": [{ "value": "alice@example.com", "primary": true }],
  "active": true,
  "groups": [
    { "value": "analysts" },
    { "value": "finance-read" }
  ]
}

5.7 WebAuthn / FIDO2

W3C WebAuthn L3 (2024) + FIDO Alliance FIDO2/CTAP2. Authentification passwordless avec clés cryptographiques liées au domaine — résistante au phishing. Passkeys (clés synchronisées iCloud/Google) en adoption massive 2024-2025.

6. Les 5 domaines IAM 2025

La discipline se segmente en 2025 par population et contraintes :

Segmentation IAM 2025 — outils dominants par domaine
─────────────────────────────────────────────────────
 
Workforce Identity (employés, prestataires)
  ├─ Microsoft Entra ID   ~75 % France
  ├─ Okta Workforce       ~15 %
  ├─ Ping Identity        ~5 %
  └─ ForgeRock / autres   ~5 %
 
CIAM (clients, utilisateurs finaux)
  ├─ Auth0 (Okta)
  ├─ Okta Customer Identity
  ├─ Microsoft Entra External ID
  ├─ Ping Identity CIAM
  ├─ ForgeRock Identity Cloud
  └─ Keycloak (OSS)
 
PAM (administrateurs, accès privilégiés)
  ├─ CyberArk               ~40 % part marché enterprise
  ├─ BeyondTrust            ~20 %
  ├─ Delinea (ex-Thycotic)  ~15 %
  ├─ HashiCorp Boundary
  └─ Teleport
 
IGA (gouvernance + lifecycle + compliance)
  ├─ SailPoint IdentityNow  ~35 % marché
  ├─ Saviynt                ~15 %
  ├─ Omada Identity
  └─ One Identity Manager
 
NHI (workloads, services, machines)
  ├─ HashiCorp Vault + Boundary
  ├─ Akeyless
  ├─ GitGuardian Aembit
  ├─ Workload Identity federation (AWS/GCP/Azure)
  └─ SPIRE / SPIFFE (CNCF)

6.1 PAM — enjeu critique à part

Les comptes privilégiés (admin domaine, root, cloud admin) sont le trophée final des attaquants. Un programme PAM mature 2025 couvre :

1. Vault centralisé des credentials privilégiés.
2. Session recording (ttyrec, Teleport session, CyberArk PSM).
3. Just-in-Time (JIT) elevation — admin Entra ID / Azure PIM, AWS SSO permission sets temporaires.
4. Approval workflows pour actions hautement privilégiées.
5. Break glass accounts stockés offline avec processus strict.
6. Rotation automatique des credentials utilisés.

6.2 IGA — gouvernance et compliance

IGA répond à trois questions :

• Qui a accès à quoi ? (access certification)
• Qui devrait avoir accès ? (role mining + birthright)
• Qui a fait quoi ? (audit trail, SoD Segregation of Duties)

Exigé par SOX, PCI-DSS, NIS 2, DORA, ISO 27001:2022 (A.8.2 Privileged access rights, A.8.3 Information access restriction).

7. IAM et Zero Trust — architecture 2025

Le Zero Trust selon NIST SP 800-207 (2020) et CISA Zero Trust Maturity Model 2.0 (2023) place l'identité au cœur :

5 piliers CISA Zero Trust Maturity Model 2.0
─────────────────────────────────────────────
 
1. Identity       ─► IAM + MFA + identity threat detection
2. Devices        ─► MDM + device posture + compliance
3. Networks       ─► ZTNA + micro-segmentation + NDR
4. Applications   ─► ZTNA pour apps + WAF + runtime protection
5. Data           ─► DLP + encryption + classification

L'identité conditionne les 4 autres piliers : sans authentification forte + autorisation contextuelle + session continue + governance, les contrôles réseau, device et data deviennent aveugles.

7.1 Conditional Access — pattern dominant 2025

Microsoft Entra Conditional Access, Okta Adaptive Access, Ping Risk Signal : policies qui évaluent à chaque requête :

7.2 ITDR — Identity Threat Detection and Response

Catégorie émergente 2023-2025 (Gartner). Détection spécialisée des attaques identity : token theft, session hijack, credential stuffing, MFA fatigue, AS-REP Roasting, Kerberoasting, golden ticket. Solutions : CrowdStrike Identity Protection, Microsoft Defender for Identity, Silverfort, Semperis.

8. Mapping IAM vs métiers cyber adjacents

Pour comprendre la place de l'IAM dans le paysage cyber et le positionnement des rôles :

9. Les 6 anti-patterns IAM à éviter en 2025

Retour d'expérience audits IAM 2024-2025 :

1. MFA partiel — 80-90 % des users MFA, le reste (comptes de service, admin break-glass) restent en password seul. Les attaquants ciblent exactement ces 10-20 %.
2. SSO sans Conditional Access — SSO baisse la friction mais sans signaux contextuels, un token compromis reste valide 8-24h.
3. Role explosion non-maîtrisée — 2 000+ rôles actifs AD dans une ETI 5 000 personnes = impossibilité d'auditer. Role mining + consolidation minimum 1x/an.
4. NHI traités comme humains — rotation manuelle annuelle de secrets partagés entre équipes. Anti-pattern catastrophique : passage obligatoire à Workload Identity federation.
5. PAM partiel — admin AD Tier 0 vaulté chez CyberArk, mais admins AWS root + comptes break-glass restent en fichier Excel. Couverture PAM à 100 % ou proche.
6. Offboarding manuel — désactivation compte à J+7 ou J+30 post-départ RH. Cible : J+0 automatique via SCIM, vérification sous 1h maximum.

Points clés à retenir

• Définition : IAM = framework AAA+ (Authentication, Authorization, Accounting, Administration, Audit) qui gère cycle de vie identités humaines et non-humaines + accès aux ressources.
• 5 domaines : Workforce (Entra/Okta), CIAM (Auth0/B2C), PAM (CyberArk/BeyondTrust), IGA (SailPoint/Saviynt), NHI (Vault/Akeyless/SPIRE).
• 3 types d'identités : humaines workforce, humaines CIAM, non-humaines (NHI). NHI > humains en cloud-native (ratio 10-50/1) et 45 % des incidents cloud 2023-2024.
• 5 modèles d'autorisation : ACL, RBAC (fondation), ABAC (contextuel), PBAC (OPA/Rego policies as code), ReBAC (Zanzibar/OpenFGA pour graphes).
• Protocoles clés : LDAP + Kerberos (on-prem), SAML 2.0 (enterprise legacy), OAuth 2.1 + OIDC 1.0 (SaaS modern), SCIM (provisioning), WebAuthn/FIDO2 (passwordless phishing-resistant).
• WebAuthn tue le phishing : -99,9 % compromission vs password+TOTP. Adoption 2024 : 73 % Fortune 500.
• Zero Trust (NIST SP 800-207, CISA ZTMM 2.0) : 5 piliers — Identity + Devices + Networks + Applications + Data. IAM conditionne les 4 autres.
• 99 % des attaques bloquées par MFA (Microsoft Digital Defense 2024) mais 34 % comptes enterprise sans MFA (Okta 2024) — plus haut ROI sécurité documenté.

Pour l'entrée accessible cloud-focused AWS/Azure/GCP, voir IAM expliqué simplement. Pour le pendant NHI / secrets, Secrets management dans le cloud. Pour le volet détection identité, Détection d'intrusion : les bases. Pour les trajectoires métier, Ingénieur IAM et Spécialiste Active Directory Security.