1 — Identity & Access Controls (AZ-500)

Sécuriser l'accès aux ressources Azure via RBAC, rôles personnalisés, accès privilégié juste-à-temps (PIM), MFA et Conditional Access, selon les principes Zero Trust et le moindre privilège.

A. Azure RBAC — angle sécurité

Bases du modèle (héritage de scope, role assignment = principal + role definition + scope) → AZ-104. Ici on cible la séparation des devoirs et le qui peut élever.

Les 5 rôles fondamentaux + rôles sécurité clés :

Points de décision :

• Qui peut assigner un rôle ? Seulement Owner, RBAC Administrator, User Access Administrator (et rôles dédiés type Reservations Admin). Contributor ne peut pas.
• RBAC Administrator vs User Access Administrator : RBAC Admin = juste les role assignments (plus restreint) ; UAA = tout Microsoft.Authorization. Choisir RBAC Admin si on veut déléguer l'attribution sans donner la gestion des policies/deny assignments.
• 🚨 Les classic administrators (Co-Administrator / Service Administrator) sont retirés : depuis déc. 2025 Azure a auto-attribué Owner aux comptes restants, retraite complète en mai 2026. Sur l'exam, traiter comme obsolète → tout passe par RBAC.
• 🚨 Key Vault : avec le modèle Access Policy (legacy), tout porteur de Microsoft.KeyVault/vaults/write (Contributor, KV Contributor) peut se créer une access policy et accéder aux secrets. → Basculer sur le modèle de permissions RBAC pour séparer plan de gestion et plan de données.

📌 Elevate access : un Global Administrator Entra peut s'élever pour gérer toutes les souscriptions (User Access Administrator à la racine /) — utile pour découvrir/nettoyer les assignations orphelines, à révoquer après usage.

Azure built-in roles · rôles Privileged · Security

B. Rôles personnalisés (Azure RBAC) vs rôles personnalisés Entra

Deux systèmes distincts à ne pas confondre — c'est un piège classique AZ-500.

B.1 — Azure custom roles (plan de gestion des ressources Azure)

Structure JSON :

{
  "Name": "Custom VM Operator",
  "Description": "Monitor + start/restart VMs",
  "Actions": ["*/read", "Microsoft.Compute/virtualMachines/start/action",
              "Microsoft.Compute/virtualMachines/restart/action"],
  "NotActions": ["*/write"],
  "DataActions": ["Microsoft.Storage/.../blobs/read"],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/xxxxxxxx-..."]
}

• 1 seul management group autorisé dans AssignableScopes ; racine / non supportée.
• Limite : 5000 custom roles / tenant (2000 pour 21Vianet).
• ABAC conditions (Condition + ConditionVersion 2.0) : raffine les permissions ; aujourd'hui sur Storage Blob Data Owner/Contributor/Reader notamment.
• 🚨 Un custom role doit contenir exactement un objet permission lors de la création (l'API n'en accepte qu'un).

B.2 — Microsoft Entra custom roles (gestion du répertoire)

• Prérequis : Entra ID P1/P2 + rôle Privileged Role Administrator pour créer/assigner.
• Permissions au format microsoft.directory/... (ex. microsoft.directory/applications/credentials/update), choisies dans une liste préfixée.
• Création-assignation = 2 étapes : unifiedRoleDefinition puis unifiedRoleAssignment.
• Scopes : tenant-wide (/), administrative unit, ou objet unique (app registration, enterprise app, groupe). Scope sur conteneur = porte sur les objets contenus, pas le conteneur lui-même.
• 🚨 microsoft.directory/applications/create (ne décompte pas du quota 250 du créateur, pas owner) vs createAsOwner (créateur = owner, décompte). Le create prime si les deux sont assignés → à manier avec prudence.

Azure custom roles · Entra custom role

C. PIM — Privileged Identity Management pour ressources Azure

Élimine l'accès permanent (standing access) : on rend les rôles éligibles, activés juste-à-temps (JIT). Nécessite Entra ID P2 / Governance.

Eligible vs Active :

🚨 Une assignation ne peut pas durer < 5 min, ni être retirée < 5 min après création.

Role settings (PIM policies) — par rôle ET par ressource :

🚨 Pas d'héritage des settings : un réglage au niveau Souscription n'est PAS hérité au niveau Resource Group. Configurer à chaque scope.

📌 Activation : portail Entra (My roles > Azure resources) OU directement depuis le blade Subscriptions (« View eligible subscriptions ») / Access control (IAM) (« View my access »). Aussi via ARM API (roleAssignmentScheduleRequests, requestType = SelfActivate).

Access reviews PIM : revues récurrentes (weekly→annually) des assignations Owner/UAA. Scope par type (eligible only / active only / all), reviewers (selected / self / manager + fallback), Upon completion → Auto apply retire les utilisateurs refusés. Créer une review Azure resource = être Owner ou UAA sur la ressource.

Alertes PIM : détectent l'activité suspecte (ex. trop d'Owners, assignation hors PIM, rôles activés trop souvent) avec remédiation guidée.

PIM overview · Role settings · Assign · Access reviews · Alerts

D. MFA pour l'accès aux ressources Azure

3 façons d'activer la MFA — par ordre de maturité :

• Méthodes : Microsoft Authenticator (push/code), Windows Hello for Business, Passkey FIDO2, certificate-based auth, OATH tokens, SMS/voix (à éviter). Phishing-resistant = FIDO2 / WHfB / CBA.
• 🚨 Security Defaults ⇄ Conditional Access mutuellement exclusifs : impossible d'activer SD si une seule politique CA existe (même en Off/Report-only), et vice versa.
• 🚨 Legacy authentication (IMAP/POP3/SMTP, Office 2010) ne supporte pas la MFA → un attaquant la contourne. SD et CA bloquent ces protocoles.
• Registration : portail myprofile / combined registration (MFA + SSPR). Sécuriser l'enrôlement lui-même via une CA sur l'action Register security information.

Security defaults · MFA best practices identity

E. Conditional Access pour les ressources cloud Azure

Moteur de politique Zero Trust : Signaux → Conditions → Décision (Grant / Session).

Anatomie d'une politique :

Points de décision clés :

• Require MFA vs Require authentication strength : authentication strength = plus fin (impose Phishing-resistant MFA / Passwordless MFA). 🚨 Mais incompatible avec External Authentication Methods (EAM) → dans ce cas, garder le grant « Require multifactor authentication ».
• Risk-based (lien Entra ID Protection, P2) : sign-in risk = probabilité que cette connexion ne soit pas du propriétaire ; user risk = compte probablement compromis. Politique type : sign-in risk High+Medium → Require MFA ; user risk High → block / change password. ID Protection envoie les signaux de risque, CA applique la décision.
• Named locations : marquer les plages VPN/bureau comme trusted améliore le calcul de risque et réduit les faux positifs.

🚨 Pièges majeurs :

• Toujours exclure les comptes break-glass / emergency access de chaque politique → sinon lockout total du tenant.
• Les service principals / managed identities ne sont pas bloqués par une CA ciblant des utilisateurs → utiliser CA for workload identities pour les couvrir.
• Toujours déployer en Report-only d'abord : évalue l'impact dans les sign-in logs avant de passer On.

CA overview · Risk-based sign-in · Report-only · Emergency access accounts

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : Finance — Accès administrateur sans privilèges permanents

Contexte business : une banque est auditée (PCI-DSS / ISO 27001). 14 comptes sont Owner en permanence sur la prod. Objectif : plus aucun droit admin permanent.

Choix architectural : on rend les droits Owner « temporaires à la demande » via PIM (activation avec approbation + MFA).

Architecture / pattern :

• Repérer les Owners permanents (PIM Discovery) → les passer en éligibles (droits dormants).
• Sur Owner : activation 1 h max, MFA obligatoire, 2 approbateurs, justification écrite.
• Revues d'accès trimestrielles (retrait auto des droits inutiles).
• Comptes de secours (break-glass) hors PIM, surveillés séparément.

Trade-offs assumés :

• Gain : un compte volé n'a des droits que 1 h max ; tout est tracé et conforme.
• Perte : chaque intervention demande activation + approbation ; il faut un approbateur dispo 24/7 ; licence P2 par admin.

Pièges à éviter :

• Les réglages PIM d'une souscription ne descendent pas automatiquement sur ses RG.
• Mettre le compte break-glass sous PIM → blocage total si l'approbateur est absent.
• Un seul approbateur → goulot et risque de complicité.

📐 Réf. CAF/WAF — MCSB PA-2 (Avoid standing access) : utiliser un mécanisme JIT (PIM) pour attribuer l'accès privilégié temporairement plutôt que des privilèges permanents ; PIM génère aussi des alertes de sécurité. Lien

Scénario 2 : Santé — Conditional Access conforme HIPAA pour la gestion Azure

Contexte business : un hôpital héberge des données patients dans Azure. L'accès au portail/ARM doit exiger une MFA résistante au phishing, un appareil géré, et refuser les connexions anormales.

Choix architectural : un socle de règles Conditional Access (Zero Trust) ciblant la gestion Azure, complété par le risque de connexion (ID Protection).

Architecture / pattern :

• Admins → MFA anti-phishing + appareil conforme (Intune).
• Tout le monde → MFA exigée sur les ressources.
• Blocage de l'authentification legacy (sans MFA possible).
• Risque élevé (P2) : forcer MFA, voire bloquer.
• Sites/VPN connus marqués « de confiance » ; break-glass et identités applicatives exclus.
• Tester en Report-only avant d'activer pour de vrai.

Trade-offs assumés :

• Gain : accès adapté au contexte, anomalies géographiques bloquées, legacy auth éliminée.
• Perte : nécessite Intune + P1/P2 ; gérer les exclusions est délicat ; faux positifs possibles pour le personnel en déplacement.

Pièges à éviter :

• Ne pas exclure le break-glass → blocage total.
• Une règle sur les utilisateurs ne couvre pas les identités applicatives (règle workload identities à part).
• Activer sans avoir testé en Report-only.
• Authentication strength est incompatible avec les EAM (fournisseurs externes).

📐 Réf. CAF/WAF — MCSB IM-7 (Restrict resource access based on conditions) : déployer Entra Conditional Access pour un contrôle granulaire et adaptatif (MFA admin, blocage legacy auth, devices conformes, locations de confiance, blocage des sign-ins risqués). Lien

Scénario 3 : SaaS / startup — Délégation au moindre privilège sans rôles built-in trop larges

Contexte business : un éditeur SaaS donne Contributor sur toute la souscription à ses équipes DevOps « pour aller vite ». Une erreur peut tout casser. Objectif : ne donner que le strict nécessaire.

Choix architectural : Reader par défaut + rôles ciblés/custom limités au resource group, et déléguer l'attribution via RBAC Administrator (pas User Access Administrator).

Architecture / pattern :

• Reader par défaut partout (on voit, on ne modifie pas).
• Rôles précis (VM Contributor, Storage Account Contributor) au lieu de Contributor global.
• Custom role minimal limité au RG du produit, pas à la souscription.
• Un lead peut attribuer des rôles via RBAC Administrator (attribution seule).
• Key Vault passé en mode RBAC (fin des access policies).

Trade-offs assumés :

• Gain : une erreur reste limitée au RG ; séparation claire des responsabilités.
• Perte : créer/maintenir des custom roles demande du travail (max 5000/tenant) et de connaître les opérations des resource providers.

Pièges à éviter :

• Confondre custom role Azure et custom role Entra (formats/licences différents).
• Mettre toute la souscription dans AssignableScopes au lieu du seul RG.
• Donner User Access Administrator quand RBAC Administrator suffit (UAA peut se promouvoir Owner).
• Laisser Key Vault en Access Policy (Contributor donne alors accès aux secrets).

📐 Réf. CAF/WAF — MCSB AM-4 (Limit access to asset management) : Reader par défaut, rôles Contributor spécifiques au service, custom roles à permissions minimales, scoping au RG/ressource pour réduire le blast radius, et PIM pour les rôles élevés. Lien

DEMO — chemins portail

1. Créer un Azure custom role (portail, Start from JSON)

1. Access control (IAM) du scope (souscription/RG) → Add → Add custom role.
2. Onglet Basics → Baseline permissions = Start from JSON, charger le fichier (avec Actions, NotActions, AssignableScopes).
3. Onglet Permissions → ajouter/exclure (les exclusions deviennent NotActions/NotDataActions).
4. Onglet Assignable scopes → ajouter le RG/souscription (1 seul mgmt group max).
5. Onglet JSON → éditer/valider → Review + create. CLI : az role definition create --role-definition @role.json

2. Rendre un rôle Owner éligible via PIM

1. Entra admin center → ID Governance > Privileged Identity Management > Azure resources → sélectionner la souscription.
2. Roles > Add assignments → rôle Owner → sélectionner le membre.
3. Onglet Settings → Assignment type = Eligible → définir l'expiration → Assign.
4. (Auth requise : être Owner ou User Access Administrator sur la ressource.)

3. Configurer les role settings PIM (MFA + approbation)

1. PIM > Azure resources > la ressource > Settings.
2. Sélectionner le rôle (ex. Owner) → Edit.
3. Activation : max duration 1 h, cocher Require MFA, Require justification, Require approval (ajouter ≥ 1 approbateur).
4. Assignment : Expire eligible assignment after → durée voulue → Update.

4. Créer une politique Conditional Access « Require MFA » en Report-only

1. Entra admin center → Entra ID > Conditional Access > New policy (nom explicite).
2. Users : Include = All users ; Exclude = comptes break-glass.
3. Target resources : Microsoft Azure Management (ou All resources).
4. Grant : Grant access → Require multifactor authentication.
5. Enable policy = Report-only → Create. Vérifier les Sign-in logs (onglet Conditional Access) puis basculer On.

5. Lancer une access review PIM sur Owner/UAA

1. PIM > Azure resources > la souscription > Access reviews > New.
2. Nom, Start date, Frequency = Quarterly, durée.
3. Users scope → Review role membership : Owner + User Access Administrator ; assignment type = all active and eligible.
4. Reviewers = Selected users (ou Manager + fallback).
5. Upon completion : Auto apply results = Enable, If reviewers don't respond = Remove access → Start.