CISSP Domaine 5 — Identity and Access Management : SSO, MFA et fédération pas-à-pas

Article principal de la série : Décrocher la certification CISSP 2026. Ce tutoriel approfondit le domaine 5 du CBK 2024 — 13 % de l’examen. L’IAM est devenu le nouveau périmètre de la cybersécurité moderne. Au programme : cycle de vie de l’identité, facteurs d’authentification, MFA et passkeys, fédération (SAML, OIDC), modèles d’accès (DAC/MAC/RBAC/ABAC), PAM et accès Just-In-Time.

Prérequis

• Domaines 1 à 4 maîtrisés
• Familiarité avec un annuaire d’entreprise (AD, LDAP) appréciée
• Temps estimé : 20 à 25 heures sur deux à trois semaines

Étape 1 — Internaliser la chaîne IAAA

L’IAM repose sur la séquence Identification, Authentication, Authorization, Accountability — IAAA, qu’on peut voir comme l’AAA étendu avec l’identification explicite. Chaque maillon a sa contre-mesure dédiée et l’examen aime tester la frontière entre eux.

Erreur classique : confondre authentification et autorisation. L’authentification est binaire (oui/non), l’autorisation est conditionnelle (oui sur cette ressource, dans ce contexte, à cette heure). Le contrôle d’accès est l’application de la décision d’autorisation au moment de la requête sur la ressource.

Étape 2 — Les facteurs d’authentification

Cinq familles à connaître. Something you know (mot de passe, code PIN). Something you have (téléphone, clé physique, badge). Something you are (biométrie : empreinte, iris, faciale, voix). Something you do (frappe au clavier, signature). Somewhere you are (géolocalisation, IP, segment réseau).

La MFA exige au moins deux facteurs de familles différentes. Mot de passe plus question secrète n’est PAS de la MFA — ce sont deux fois la même famille. Mot de passe plus OTP envoyé sur téléphone est de la MFA (savoir plus avoir). Mot de passe plus empreinte digitale est de la MFA (savoir plus être).

Sur la biométrie, deux indicateurs à connaître : FRR (False Rejection Rate, taux de rejet d’un utilisateur légitime, qui pénalise l’expérience), et FAR (False Acceptance Rate, taux d’acceptation d’un imposteur, qui pénalise la sécurité). Le point d’intersection des deux courbes est le Crossover Error Rate (CER ou EER) — plus il est bas, meilleure est la techno biométrique. La biométrie haut de gamme (iris, palm vein) atteint des CER inférieurs à 0,01 %.

Étape 3 — FIDO2, WebAuthn et passkeys

FIDO2 (Fast Identity Online Alliance) est le standard moderne d’authentification sans mot de passe. Il se compose de WebAuthn (W3C, intégré navigateurs depuis 2019) côté serveur et CTAP2 (Client to Authenticator Protocol) côté authentificateur.

Les passkeys sont l’évolution grand public de FIDO2 lancée en 2022 par Apple, Google et Microsoft : la clé privée est synchronisée entre les appareils de l’utilisateur via un compte cloud (iCloud Keychain, Google Password Manager, Microsoft Authenticator). Avantages : résistance native au phishing (la clé est liée à l’origine), pas de mot de passe à retenir ni à compromettre, expérience utilisateur simplifiée.

Trois types d’authentificateurs FIDO2 cohabitent : platform authenticators (TPM, Secure Enclave, intégré à l’OS), roaming authenticators (YubiKey, Google Titan, clé portable), multi-device passkeys (synchronisés). À l’examen, FIDO2 est la bonne réponse moderne pour remplacer le mot de passe.

Étape 4 — Single Sign-On et fédération

Le SSO permet à un utilisateur de s’authentifier une fois et d’accéder à plusieurs applications sans réauthentification. Deux familles : SSO intra-domaine (Kerberos, ticket granting tickets en Active Directory) et SSO fédéré (entre organisations ou applications cloud).

Trois protocoles fédérés à maîtriser. SAML 2.0 (OASIS, 2005) utilise des assertions XML signées. Les rôles sont Identity Provider (IdP), Service Provider (SP) et utilisateur. Le flux principal est le SP-initiated : l’utilisateur arrive sur SP, est redirigé vers IdP pour authentification, revient sur SP avec une assertion signée. SAML reste dominant pour les applications d’entreprise B2B et les ERP historiques.

OAuth 2.1 (Internet-Draft IETF, version draft-15 publiée en 2026, consolide RFC 6749 et la Security Best Current Practice RFC 9700) est un protocole d’autorisation, pas d’authentification — il délègue l’accès à une ressource sans partager les credentials. Quatre rôles : resource owner, client, authorization server, resource server. Les flows examinables sont Authorization Code avec PKCE (recommandé pour SPA et mobile), Client Credentials (machine-to-machine), Device Code (TV, IoT). Les flows implicit et password sont dépréciés.

OpenID Connect (OIDC) construit l’authentification au-dessus d’OAuth 2.0 en ajoutant un ID Token JWT signé contenant l’identité de l’utilisateur. C’est le standard moderne pour l’authentification SaaS (Google, Microsoft Entra ID, Auth0, Keycloak).

Étape 5 — Modèles d’autorisation

Cinq modèles examinables et leurs frontières.

Le piège classique oppose DAC et MAC. DAC = discretionary, c’est-à-dire que le propriétaire de la ressource a la discrétion sur les permissions. MAC = mandatory, c’est-à-dire que le système impose la politique sans laisser de marge au propriétaire — typique des environnements classifiés gouvernementaux. RBAC est un compromis pragmatique : les rôles centralisent les permissions et facilitent l’administration en entreprise.

ABAC est la tendance moderne pour le Zero Trust : la décision combine l’identité (sujet), la ressource (objet) et le contexte (heure, lieu, posture du device, niveau de risque calculé). Un même utilisateur peut accéder à un document depuis son poste corporate mais être refusé depuis un café public, même avec les bons credentials.

Étape 6 — Privileged Access Management (PAM)

Les comptes à privilèges (administrateurs domaine, root, comptes de service) concentrent le risque. Le PAM gère leur cycle de vie avec quatre fonctions clés : coffre-fort (rotation automatique des mots de passe, jamais affichés en clair à l’utilisateur), session brokering (l’utilisateur ne connaît jamais le mot de passe, il lance une session via le PAM qui s’injecte), enregistrement (vidéo et journal de la session privilégiée, support du forensic), workflow d’approbation (demande d’accès validée par un superviseur).

Le Just-In-Time (JIT) access est une évolution moderne : aucun compte n’a de privilège permanent ; les rôles administratifs sont accordés pour une durée limitée (typiquement 1 à 4 heures) après justification et approbation. Combiné au PAM, le JIT réduit drastiquement la surface d’attaque liée aux comptes compromis. Azure PIM, CyberArk JIT et HashiCorp Boundary sont des références examinables.

Étape 7 — Cycle de vie de l’identité (JML)

Le processus Joiner-Mover-Leaver structure la gestion des identités en entreprise. Au joining, le compte est provisionné selon le rôle métier ; au moving (changement de poste), les permissions sont mises à jour avec révocation des accès obsolètes (point critique souvent oublié) ; au leaving, le compte est désactivé immédiatement, ses sessions sont terminées, son contenu boîte mail archivé.

Le risque principal est le privilege creep — l’accumulation d’accès au fil des mouvements internes. La parade est l’access review périodique (trimestrielle pour les comptes sensibles, annuelle pour les autres) où le manager certifie les accès de son équipe. Les outils Identity Governance and Administration (IGA — SailPoint, Saviynt, One Identity) automatisent ces campagnes de certification.

Étape 8 — Annuaires et synchronisation

Les annuaires d’entreprise classiques utilisent LDAP (RFC 4511). Active Directory ajoute Kerberos, GPO et schéma Microsoft. Entra ID (anciennement Azure AD, rebranding annoncé par Microsoft le 11 juillet 2023 et déployé jusqu’à fin 2023) est l’IdP cloud Microsoft, qui supporte SAML, OIDC, SCIM (provisioning automatisé), et intègre les passkeys depuis 2023.

Le standard SCIM (System for Cross-domain Identity Management, RFC 7644) automatise la création, modification et suppression de comptes entre un IdP et des SP cloud. Sans SCIM, les comptes sont gérés manuellement dans chaque application — source classique de comptes orphelins et de privilege creep.

Étape 9 — Kerberos et authentification interne

Kerberos (RFC 4120) reste le protocole d’authentification interne dominant des annuaires d’entreprise Microsoft. Le flux à comprendre comporte trois acteurs : le client, le KDC (Key Distribution Center, composé de l’AS Authentication Server et du TGS Ticket Granting Server) et le serveur de ressource. L’authentification initiale produit un TGT (Ticket Granting Ticket) signé par le KDC, puis chaque accès produit un Service Ticket dérivé du TGT.

Trois attaques classiques à connaître. Le Pass-the-Ticket réutilise un TGT volé sur la mémoire d’un poste compromis. Le Golden Ticket forge un TGT arbitraire après vol du hash du compte krbtgt — il faut alors faire tourner deux fois la clé krbtgt pour invalider tous les Golden Tickets résiduels. Kerberoasting demande un Service Ticket pour un Service Principal Name puis casse hors-ligne le mot de passe du compte de service. Les parades modernes sont les comptes de service managés (gMSA) avec mot de passe long et rotation automatique tous les 30 jours.

Étape 10 — Niveaux d’assurance NIST SP 800-63

NIST SP 800-63-4 (publié en version finale en juillet 2025, après un second public draft en août 2024) définit trois niveaux d’assurance indépendants à connaître. IAL (Identity Assurance Level) mesure la rigueur de la preuve d’identité initiale, de IAL1 (auto-déclarée) à IAL3 (vérification en personne ou équivalente supervisée). AAL (Authenticator Assurance Level) mesure la rigueur du processus d’authentification courante, de AAL1 (un facteur) à AAL3 (cryptographique matériel résistant au phishing, comme FIDO2 avec attestation). FAL (Federation Assurance Level) mesure la robustesse de l’assertion fédérée, de FAL1 à FAL3 (assertion chiffrée plus holder-of-key).

Le triplet IAL/AAL/FAL est cité comme exigence par les autorités fédérales US pour les services en ligne. Un service de banque en ligne grand public vise IAL2/AAL2/FAL2 ; un service de signature de contrats commerciaux engageant vise IAL2/AAL3/FAL3. L’examen aime poser une question sur la sélection du niveau adapté à un cas d’usage.

Étape 11 — Identité machine et secrets en CI/CD

L’identité ne concerne plus seulement les humains. Les conteneurs, fonctions, microservices et pipelines CI/CD ont besoin d’une identité forte pour s’authentifier mutuellement. Le standard moderne est SPIFFE (Secure Production Identity Framework For Everyone) avec son implémentation de référence SPIRE. Chaque charge de travail reçoit un SVID (SPIFFE Verifiable Identity Document) sous forme de certificat X.509 court ou de JWT, automatiquement renouvelé toutes les heures.

Pour les secrets de pipeline (clés API, tokens, certificats), trois bonnes pratiques examinables. Premièrement, ne jamais stocker un secret en clair dans le dépôt Git — utiliser un coffre comme HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou Doppler. Deuxièmement, préférer les identités fédérées workload-to-cloud (OIDC trust entre GitHub Actions et AWS IAM, par exemple) qui suppriment les clés à long terme. Troisièmement, surveiller les fuites de secrets dans les commits publics avec des scanners (TruffleHog, gitleaks) intégrés en pre-commit hook et en CI.

Erreurs fréquentes

Tutoriels frères

• Retour au guide principal : Décrocher la certification CISSP 2026
• Précédent : Domaine 4 — Communication and Network Security
• Suite : Domaine 6 — Security Assessment and Testing

Ressources et références

• W3C — Web Authentication API (WebAuthn)
• FIDO Alliance — Specifications
• RFC 6749 — OAuth 2.0
• OpenID Connect Core 1.0
• OASIS — SAML 2.0
• RFC 7644 — SCIM
• NIST SP 800-63-4 — Digital Identity Guidelines

Foire aux questions

Les passkeys remplacent-elles les mots de passe ?

Pour les services compatibles, oui. La migration est en cours chez les grands acteurs (Google, Apple, Microsoft, GitHub). Les mots de passe restent utilisés en fallback et pour les services non encore migrés. Sur le long terme, l’authentification phishing-resistant FIDO2 est le standard cible.

SAML peut-il être encore utilisé en 2026 ?

Oui, c’est même la norme pour beaucoup d’applications d’entreprise. Pour les nouvelles intégrations cloud-native, préférer OIDC quand le SP le supporte — il est plus simple et mieux adapté aux flux mobile et SPA.

Quelle longueur de mot de passe demander en 2026 ?

NIST SP 800-63B v4 (publié août 2024) recommande 8 caractères minimum, longueur souhaitable 15 caractères ou plus. Les exigences de complexité arbitraires (1 majuscule, 1 chiffre, 1 spécial) sont déconseillées car elles dégradent l’entropie réelle des mots de passe choisis. Privilégier la passphrase ou le gestionnaire de mots de passe.

Le PAM est-il obligatoire pour les PME ?

Aucune obligation réglementaire générale, mais c’est la bonne pratique reconnue dès que l’organisation gère des comptes administrateurs domaine, des secrets infrastructure ou des accès tiers. Des solutions open-source (Teleport, HashiCorp Boundary) rendent le PAM accessible aux structures modestes.