Architecture Technologique en Pratique  ›  Sécurité & Identité  ›  Chapitre 19

IAM — Gestion des Identités
& Accès

L'identité est le nouveau périmètre de sécurité. Dans un monde où les applications sont dans le nuage et les utilisateurs travaillent de partout, l'architecture IAM est le fondement de la posture de sécurité de l'organisation.

IAM — Identity & Access
Management

Identity is the new security perimeter. In a world where applications are in the cloud and users work from anywhere, IAM architecture is the foundation of an organization's security posture.

IAM — Gestión de Identidades
y Accesos

La identidad es el nuevo perímetro de seguridad. En un mundo donde las aplicaciones están en la nube y los usuarios trabajan desde cualquier lugar, la arquitectura IAM es el fundamento de la postura de seguridad de la organización.

Maturité : Production Sécurité & Identité Chapitre 19 Mise à jour : Mai 2026

Définition & Positionnement

La gestion des identités et des accès (IAM) est l'infrastructure qui établit, maintient et vérifie les identités numériques dans une organisation, et qui détermine ce que chaque identité est autorisée à faire. Pendant des décennies, l'IAM consistait à gérer une liste d'utilisateurs dans un annuaire et à configurer des permissions sur des partages réseau. Ce modèle est structurellement insuffisant dans un contexte d'architectures cloud, de mobilité généralisée et d'accès multi-partenaires.

L'IAM repose sur quatre piliers fondamentaux : l'authentification (qui êtes-vous ?), l'autorisation (qu'avez-vous le droit de faire ?), l'administration (cycle de vie des identités et des droits) et l'audit (traçabilité des événements). Ces quatre fonctions sont interdépendantes — une faiblesse dans l'une compromet les trois autres.

L'architecte technologique distingue trois disciplines complémentaires souvent confondues sous le terme générique IAM : l'IAM proprement dit (moteur d'identité — annuaires, protocoles, autorisation), l'IGA (Identity Governance and Administration — gouvernance et administration des identités) et le PAM (Privileged Access Management — gestion des accès privilégiés). En pratique : un utilisateur s'authentifie via IAM, ses accès sont gouvernés par IGA, et les administrateurs accèdent aux systèmes critiques via PAM.

Registre ARB (Architecture Review Board) : Les décisions d'architecture IAM — choix du fournisseur d'identité, politique de fédération, exigences MFA (Multi-Factor Authentication), standards d'accès privilégié — sont des décisions ARB de Niveau 2. La question centrale : « Qui peut accéder à quoi, et comment le prouve-t-on ? »

Vue Architecturale

L'architecture IAM s'organise en couches fonctionnelles superposées, chacune s'appuyant sur la précédente :

IGA
Revues d'accès Provisionnement RH (SCIM) SoD (séparation des rôles) Cycle de vie
PAM
Coffre-fort de secrets Accès JIT (juste à temps) Enregistrement sessions Comptes admin
MFA / AuthN
FIDO2 / Passkeys Authenticator App (TOTP) Certificats (CBA) Accès conditionnel
Fédération
SAML 2.0 OIDC / OAuth 2.0 JWT SCIM 2.0 Kerberos
Annuaire / IdP
Active Directory Entra ID Okta LDAP v3 Keycloak (OSS)

Types d'identités : L'architecte distingue les identités humaines (employés, partenaires, clients) des identités non-humaines (comptes de service, machines, workloads cloud). Ces dernières sont souvent les plus vulnérables — gérées manuellement, avec des secrets statiques, sans rotation. Les identités de workloads (AWS IAM Roles, Azure Managed Identity) éliminent les secrets statiques en fournissant des identités éphémères gérées par la plateforme.

Trois scénarios hybrides AD/Entra ID :

ScénarioAD on-premEntra IDCas d'usage typique
Cloud uniquementNonOuiNouvelles organisations, startups
Hybride avec synchronisationOuiOui (AD Connect)Migration progressive, M365
Hybride avec fédérationOuiOui (ADFS / PTA)Contrôle on-prem strict des authentifications

Cas d'Usage Architecturaux

Cas 1
Migration vers l'identité fédérée (SSO d'entreprise)
Une organisation avec 40 applications SaaS gère 40 silos d'identités. L'architecte définit un IdP (Identity Provider) central (Entra ID ou Okta) avec fédération SAML/OIDC vers chaque application. Résultat : expérience SSO (Single Sign-On) unifiée, politique MFA centrale, auditabilité globale. Décision ARB : aucune nouvelle application ne peut créer un silo d'identité — toute intégration doit passer par l'IdP approuvé.
Cas 2
Implémentation Zero Trust — identité comme contrôle primaire
Dans une architecture Zero Trust (Ch. 16), l'IAM est le fondement. Chaque accès — interne ou externe — passe par l'IdP avec vérification de l'appareil, du contexte et de l'identité. Le VPN traditionnel est remplacé par ZTNA (Zero Trust Network Access), où chaque ressource est protégée individuellement. Le MFA résistant au phishing (FIDO2) est obligatoire pour tous les accès.
Cas 3
Gouvernance des accès pour la conformité réglementaire
SOX exige des revues périodiques des accès aux systèmes financiers. PCI DSS 4.0 impose le MFA résistant au phishing pour l'accès à l'environnement de données de carte. HIPAA mandate l'authentification forte pour les données de santé. L'IGA (Identity Governance and Administration) — SailPoint, Saviynt — automatise les revues d'accès et génère les rapports d'audit. L'architecte définit la politique : fréquence des revues, propriétaires des certifications, seuils de révocation automatique.
Cas 4
Identités non-humaines dans les architectures cloud-natives
Les microservices et les pipelines CI/CD (Continuous Integration / Continuous Delivery) génèrent des centaines d'identités non-humaines. L'usage de secrets statiques (mots de passe de base de données dans le code) est une dette de sécurité critique. L'architecte standardise : AWS IAM Roles / Azure Managed Identity pour les workloads cloud, HashiCorp Vault pour les secrets applicatifs, rotation automatique des credentials. Règle ARB : aucun secret statique dans les dépôts de code.

Forces & Limites

Forces
  • Périmètre de sécurité universel — applicable on-prem, cloud et hybride
  • FIDO2/WebAuthn : résistance native au phishing, meilleur taux de succès (93 % vs 63 % pour les méthodes traditionnelles)
  • Centralisation des politiques d'accès — cohérence et auditabilité
  • Intégration native aux cadres réglementaires (SOX, HIPAA, PCI DSS)
  • SSO améliore l'expérience utilisateur et réduit la fatigue des mots de passe
  • PAM réduit la surface d'attaque sur les comptes les plus ciblés
Limites & Risques
  • Point de défaillance unique : l'IdP indisponible bloque l'accès à toutes les applications fédérées
  • Complexité d'intégration — les applications legacy non compatibles SAML/OIDC nécessitent des passerelles
  • L'IGA est souvent sous-gouverné : revues d'accès non réalisées = droits accumulés (permission creep)
  • Migration de l'existant coûteuse — chaque intégration SAML/OIDC est un projet
  • La gestion des identités non-humaines est souvent négligée et mal inventoriée
  • MFA SMS/OTP insuffisant — phishable, cible des attaques SIM swap

Décisions Architecturales (ADR Simplifié)

Quand adopter
Fédération centralisée (SAML / OIDC)
Dès que l'organisation compte plus de 5 applications distinctes avec gestion d'identités. La fragmentation en silos est le risque à adresser en priorité. Critère de sélection : SAML 2.0 pour les applications d'entreprise établies (legacy SaaS, on-prem), OIDC/OAuth 2.0 pour les applications modernes et les APIs. Ne jamais créer une nouvelle application sans intégration IdP — c'est une décision ARB systématique.
Quand adopter
FIDO2 / Passkeys en priorité sur TOTP
NIST SP 800-63-4 (juillet 2025) rend le MFA résistant au phishing obligatoire à AAL2. PCI DSS 4.0 exige le MFA phishing-résistant pour l'accès aux données de carte. Les passkeys syncables qualifient désormais comme AAL2. TOTP (Google Authenticator) reste acceptable pour AAL1 mais est phishable. Priorité de déploiement : administrateurs d'abord, puis accès aux données sensibles, puis population générale.
Quand éviter / arbitrer
PAM as-a-Service vs. On-premises
Le PAM cloud (CyberArk Cloud, BeyondTrust) réduit l'overhead opérationnel. Le PAM on-prem maintient la souveraineté des secrets pour les secteurs réglementés (défense, finance, santé). Impact sur l'exploitabilité : le PAM ajoute une friction opérationnelle réelle — les administrateurs doivent "vérifier" leurs accès avant chaque session. Cette friction est intentionnelle et nécessaire ; mal communiquée, elle génère du shadow IT (accès directs en contournant le PAM).

Écosystème & Intégrations

ABB-SEC-IAM-001
Fournisseur d'identité d'entreprise (IdP)
Source centrale d'identité — authentification, SSO, MFA, fédération. Disponibilité critique (99,99 % minimum).
Microsoft Entra ID Okta Workforce Ping Identity Google Cloud Identity Keycloak (OSS)
ABB-SEC-IAM-002
Gestion des Accès Privilégiés (PAM)
Coffre-fort de secrets, accès JIT (Just-in-Time), enregistrement des sessions d'administration. Protège les comptes les plus ciblés.
CyberArk PAM Delinea Secret Server BeyondTrust HashiCorp Vault (OSS)
ABB-SEC-IAM-003
Identity Governance & Administration (IGA)
Cycle de vie, revues d'accès périodiques, SoD (Separation of Duties — séparation des rôles), provisionnement RH automatisé via SCIM.
SailPoint IdentityNow Saviynt Entra ID Governance One Identity

Standards applicables

NIST SP 800-63-4 (juil. 2025)Digital Identity Guidelines — nouveau référentiel IAL/AAL/FAL
SAML 2.0 (OASIS)Fédération pour applications d'entreprise
OIDC / OAuth 2.0Identité et autorisation pour applications modernes
FIDO2 / WebAuthnAuthentification sans mot de passe, résistante au phishing
SCIM 2.0 (RFC 7643)Provisionnement automatique des identités
Kerberos (RFC 4120)Authentification réseau (Active Directory)
LDAP v3 (RFC 4511)Accès aux annuaires d'entreprise
ISO/IEC 24760Framework de gestion de l'identité

État de l'Art & Tendances (2025–2026)

87%
des entreprises déploient ou pilotent FIDO2/passkeys (HID/FIDO Alliance, 2025)
48%
des 100 premiers sites mondiaux supportent les passkeys — plus du double vs 2022
93%
taux de succès des passkeys vs 63% pour les méthodes d'authentification traditionnelles

NIST SP 800-63-4 finalisé (juillet 2025) : La mise à jour la plus significative depuis 2017. Le framework passe d'une approche par liste de contrôle à un modèle de gestion du risque d'identité numérique (DIRM). AAL2 doit désormais obligatoirement offrir une option MFA résistante au phishing. Les passkeys syncables qualifient comme AAL2. Le SMS OTP n'est plus une option acceptable pour les niveaux d'assurance élevés.

Microsoft Entra Agent ID (novembre 2025, GA) : Extension majeure de la plateforme Entra pour les identités d'agents IA. La gestion des identités s'étend au-delà des humains et des workloads techniques vers les agents autonomes opérant dans les environnements d'entreprise, avec OAuth 2.0, MCP et A2A comme protocoles. Signal fort : l'IAM doit désormais intégrer la gouvernance des identités d'agents dans son périmètre.

Entra ID Governance 2025 : Révocation d'accès post-approbation, gestion par Unités Administratives, Group Source of Authority (conversion des groupes AD legacy en groupes dynamiques Entra ID), intégration de vérification d'identité biométrique (Face Check) dans Entitlement Management. L'IGA cloud rattrape et dépasse les capacités des solutions on-prem legacy.

Identité comme fondation Zero Trust : La convergence IAM/ZTNA (Zero Trust Network Access) s'accélère. Les plateformes SASE (Secure Access Service Edge) intègrent le moteur d'identité directement dans la pile réseau — l'accès conditionnel évalue simultanément l'identité, la posture de l'appareil et le contexte réseau. Le VPN traditionnel disparaît au profit de l'accès par ressource individuelle, orchestré par l'IdP.

Signal d'alerte : PCI DSS 4.0 (échéances 2025–2026) exige le MFA résistant au phishing pour tout accès à l'environnement de données de carte. Les organisations qui n'ont pas amorcé la migration vers FIDO2 sont en retard réglementaire.

Definition & Positioning

Identity and Access Management (IAM) is the infrastructure that establishes, maintains, and verifies digital identities within an organization, and determines what each identity is authorized to do. For decades, IAM meant managing a list of users in a directory and configuring permissions on network shares. This model is structurally insufficient in cloud architectures, with generalized mobility and multi-partner access.

IAM rests on four fundamental pillars: authentication (who are you?), authorization (what are you allowed to do?), administration (identity and entitlement lifecycle), and audit (event traceability). These four functions are interdependent — a weakness in one compromises the other three.

The technology architect distinguishes three complementary disciplines often conflated under the generic IAM label: IAM proper (identity engine — directories, protocols, authorization), IGA (Identity Governance and Administration — lifecycle governance, access reviews, compliance), and PAM (Privileged Access Management — protection of high-privilege accounts). In practice: a user authenticates via IAM, their access is governed by IGA, and administrators reach critical systems via PAM.

ARB register: IAM architecture decisions — identity provider choice, federation policy, MFA requirements, privileged access standards — are Level 2 ARB decisions. Central question: "Who can access what, and how is it proven?"

Architectural View

IAM architecture organizes into layered functional tiers, each built on the one below. The same diagram applies: IGA at the top (governance), PAM (privileged access), MFA/AuthN (authentication), Federation protocols (SAML/OIDC), and the Identity Provider / directory at the foundation.

Hybrid AD/Entra ID scenarios: Cloud-only (Entra ID alone, for new organizations), Hybrid with sync (AD + Entra ID via AD Connect, for M365 migrations), Hybrid with federation (AD + ADFS/PTA, for strict on-premises authentication control).

Non-human identities — service accounts, machines, cloud workloads — are often the most vulnerable. AWS IAM Roles, Azure Managed Identity, and GCP Workload Identity Federation eliminate static secrets by providing ephemeral identities managed by the cloud platform.

Architectural Use Cases

Use case 1
Federated identity migration (Enterprise SSO)
An organization with 40 SaaS apps manages 40 identity silos. The architect defines a central IdP (Entra ID or Okta) with SAML/OIDC federation to each application. Result: unified SSO, central MFA policy, global auditability. ARB decision: no new application may create an identity silo — every integration must use the approved IdP.
Use case 2
Zero Trust implementation — identity as primary control
In Zero Trust architecture (Ch. 16), IAM is the foundation. Every access — internal or external — passes through the IdP with device, context, and identity verification. Traditional VPN is replaced by ZTNA. Phishing-resistant MFA (FIDO2) is mandatory for all access.
Use case 3
Access governance for regulatory compliance
SOX requires periodic access reviews for financial systems. PCI DSS 4.0 mandates phishing-resistant MFA for cardholder data environment access. IGA (SailPoint, Saviynt) automates access reviews and generates audit reports. The architect defines policy: review frequency, certification owners, automatic revocation thresholds.

Strengths & Limits

Strengths
  • Universal security perimeter — applicable on-prem, cloud, and hybrid
  • FIDO2/WebAuthn: native phishing resistance, 93% login success rate vs. 63% for traditional methods
  • Centralized access policies — consistency and auditability
  • Native integration with regulatory frameworks (SOX, HIPAA, PCI DSS)
  • SSO improves user experience and reduces password fatigue
Limits & Risks
  • Single point of failure: IdP unavailability blocks all federated applications
  • Legacy application integration complexity — SAML/OIDC gateways required
  • IGA is often under-governed: skipped access reviews = accumulated permissions (permission creep)
  • SMS/OTP MFA is phishable — insufficient for high-assurance scenarios
  • Non-human identity inventory is often incomplete and poorly managed

Current State & Trends (2025–2026)

87%
of enterprises deploying or piloting FIDO2/passkeys (HID/FIDO Alliance, 2025)
48%
of the world's top 100 websites support passkeys — more than double vs. 2022
93%
passkey login success rate vs. 63% for traditional authentication methods

NIST SP 800-63-4 finalized (July 2025): Most significant update since 2017. The framework moves from checklist compliance to a Digital Identity Risk Management (DIRM) model. AAL2 must now mandatorily offer a phishing-resistant MFA option. Syncable passkeys qualify as AAL2. SMS OTP is no longer acceptable for high-assurance levels.

Microsoft Entra Agent ID (November 2025, GA): Major platform extension for AI agent identities, using OAuth 2.0, MCP, and A2A protocols. IAM scope must now include AI agent identity governance — a new category of non-human identity with autonomous behaviors.

Identity as Zero Trust foundation: IAM/ZTNA convergence is accelerating. SASE platforms integrate the identity engine directly into the network stack. Traditional VPN gives way to per-resource access orchestrated by the IdP.

Definición & Posicionamiento

La gestión de identidades y accesos (IAM) es la infraestructura que establece, mantiene y verifica las identidades digitales en una organización, y determina lo que cada identidad está autorizada a hacer. En arquitecturas cloud, con movilidad generalizada y acceso multi-socio, el modelo tradicional basado en directorios locales es estructuralmente insuficiente.

La IAM descansa en cuatro pilares: autenticación (¿quién eres?), autorización (¿qué tienes derecho a hacer?), administración (ciclo de vida de identidades y derechos) y auditoría (trazabilidad). El arquitecto distingue IAM propiamente dicha, IGA (Identity Governance and Administration — gobernanza y administración de identidades) y PAM (Privileged Access Management — gestión de accesos privilegiados).

Registro ARB (Architecture Review Board): Las decisiones de arquitectura IAM — elección del proveedor de identidad, política de federación, requisitos MFA (Multi-Factor Authentication), estándares de acceso privilegiado — son decisiones ARB de Nivel 2.

Vista Arquitectónica

La arquitectura IAM se organiza en capas funcionales: IGA (Identity Governance and Administration) en la cima, PAM (Privileged Access Management), MFA (Multi-Factor Authentication) / AuthN (autenticación), protocolos de federación (SAML/OIDC), y el IdP (Identity Provider) / directorio en la base.

Escenarios híbridos AD/Entra ID: Solo cloud (Entra ID solo, para nuevas organizaciones), Híbrido con sincronización (AD + Entra ID vía AD Connect), Híbrido con federación (AD + ADFS/PTA, para control estricto on-premises).

Fortalezas & Límites

Fortalezas
  • Perímetro de seguridad universal — aplicable en on-prem, cloud e híbrido
  • FIDO2/WebAuthn: resistencia nativa al phishing, 93% tasa de éxito
  • Políticas de acceso centralizadas — coherencia y trazabilidad
  • Integración con marcos regulatorios (SOX, HIPAA, PCI DSS)
Límites & Riesgos
  • Punto único de fallo: IdP no disponible bloquea todas las aplicaciones federadas
  • IGA frecuentemente sub-gobernada: revisiones omitidas = acumulación de permisos
  • SMS/OTP es phishable — insuficiente para alta garantía
  • Inventario de identidades no humanas frecuentemente incompleto

Estado del Arte & Tendencias (2025–2026)

87%
de empresas desplegando o pilotando FIDO2/passkeys (HID/FIDO Alliance, 2025)
48%
de los 100 principales sitios mundiales soportan passkeys — más del doble vs. 2022
93%
tasa de éxito de passkeys vs. 63% para métodos de autenticación tradicionales

NIST SP 800-63-4 (julio 2025): AAL2 debe ofrecer obligatoriamente una opción MFA resistente al phishing. Los passkeys syncables califican como AAL2. SMS OTP ya no es aceptable para niveles de alta garantía.

Microsoft Entra Agent ID (noviembre 2025, GA): Extensión para identidades de agentes IA con OAuth 2.0, MCP y A2A. La gobernanza de identidades de agentes autónomos se convierte en nuevo dominio IAM.

Convergencia IAM/ZTNA (Zero Trust Network Access): Las plataformas SASE (Secure Access Service Edge) integran el motor de identidad directamente en la pila de red. El VPN tradicional da paso al acceso por recurso individual orquestado por el IdP (Identity Provider).

Approfondir le sujet

Ce concept est traité dans le Chapitre 19 de L'Architecture Technologique en Pratique de Rolando del Cid, M. Sc. — avec les protocoles de fédération, l'architecture AD/Entra ID, les patterns PAM et IGA, et les décisions ARB détaillées.

Découvrir le livre →

Go Deeper

Chapter 19 of Technology Architecture in Practice by Rolando del Cid, M. Sc. covers federation protocols, AD/Entra ID architecture, PAM and IGA patterns, and ARB decisions — with the detail required for senior architect practice.

Discover the book →

Profundizar el tema

El Capítulo 19 de Arquitectura Tecnológica en Práctica de Rolando del Cid, M. Sc. cubre los protocolos de federación, la arquitectura AD/Entra ID, los patrones PAM e IGA, y las decisiones ARB detalladas.

Descubrir el libro →

Sources & Références

Sources & References

Fuentes y Referencias

#SourceTypeURL / RéférenceConsulté
1NIST — National Institute of Standards and Technology📄 StandardNIST SP 800-63-4 — Digital Identity Guidelines (Final, juil. 2025)05/2026
2Microsoft Learn📘 OfficielleMicrosoft Entra — Releases and Announcements 2025–202605/2026
3Microsoft Learn📘 OfficielleMicrosoft Entra ID Governance — Overview05/2026
4Microsoft Learn📘 OfficielleMicrosoft Entra Ignite 2025 — Key Announcements (Agent ID GA)05/2026
5FIDO Alliance📄 StandardFIDO2 / WebAuthn — Specification Overview05/2026
6HID / FIDO Alliance📊 RapportFIDO Passkey Index — Enterprise Adoption Report (oct. 2025)05/2026
7Dark Reading📰 ArticleNew Study: Enterprise Passkey Adoption Tops 85% (oct. 2025)05/2026
8OASIS Open📄 StandardSAML 2.0 — Security Assertion Markup Language05/2026
9OpenID Foundation📄 StandardOpenID Connect Core 1.005/2026
10IETF📄 StandardRFC 4511 — LDAP v3 Protocol05/2026
11Microsoft Tech Community📰 ArticleNew Governance Tools for Hybrid Access — Group SOA & Face Check (août 2025)05/2026
12Rolando del Cid, M. Sc.📖 LivreL'Architecture Technologique en Pratique — Chapitre 19 : IAM05/2026