2 — IAM (Azure RBAC & Entra ID Roles)

Deux systèmes de permissions distincts à NE PAS confondre :

Piège AZ-104 : être Global Admin sur Entra ID ne donne pas automatiquement les droits sur les ressources Azure. Il faut explicitement activer Access management for Azure resources dans Entra (donne User Access Admin sur la racine MG Tenant Root pour pouvoir ensuite s'attribuer/attribuer des rôles).

Concepts RBAC (communs aux deux systèmes)

Un role assignment = triplet :

• Security Principal : user, security group, service principal (app), managed identity
• Role Definition : built-in ou custom (= ensemble de permissions)
• Scope : sur quoi s'applique le rôle

Principe du moindre privilège : donner uniquement les permissions nécessaires.

Azure RBAC

Built-in roles fondamentaux

→ + des centaines de rôles spécifiques (ex Virtual Machine Contributor, Storage Blob Data Reader).

Rôles RBAC dédiés gouvernance (least-privilege)

🚨 Piège exam : "principle of least privilege" + "create/assign Azure Policy" → Resource Policy Contributor (pas Contributor plein, pas Automation Contributor, pas Policy Insights Data Writer qui ne fait que de l'écriture de compliance data).

Classic subscription admin roles (legacy, encore en exam) : Account Admin (gère le billing, 1 par sub), Service Admin et Co-Administrator — équivalents historiques d'Owner. À éviter, MS recommande RBAC moderne. Pour AZ-104 : savoir qu'ils existent et qu'ils sont distincts des rôles RBAC modernes (gérés dans Subscription > Properties / Classic administrators).

Hiérarchie & héritage des scopes

Management Group
   └─ Subscription
        └─ Resource Group
             └─ Resource

Un rôle donné à un niveau est hérité à tous les niveaux inférieurs. → Donner Owner sur la Sub = Owner sur tout dedans (mauvaise pratique, scope au plus bas possible).

Custom Roles — structure JSON

{
  "Name": "Koalification Team",
  "Description": "...",
  "Actions": [ "Microsoft.Compute/virtualMachines/*", "Microsoft.Support/*/read" ],
  "NotActions": [ "Microsoft.Compute/virtualMachines/delete" ],
  "DataActions": [ "Microsoft.Storage/.../blobs/read" ],
  "NotDataActions": [],
  "AssignableScopes": [ "/subscriptions/<sub-id>" ]
}

⚠️ NotActions n'est pas une deny rule — c'est juste une exclusion de l'allow. Si un autre role assignment couvre l'action, elle sera quand même autorisée.

Deny assignments

• "Anti-règle" RBAC qui bloque explicitement une action, même si un autre allow l'autorise. Deny > Allow toujours.
• **Tu ne peux PAS en créer toi-même (de deny assignment) (ni portail ni CLI). Azure les crée automatiquement dans 2 contextes :
  • Azure Blueprints (déprécié 11 juil 2026 mais encore en exam) : verrouille les ressources déployées par le blueprint (déployé des mm ressources et mm rbac en masse).
  • Managed Apps (apps Marketplace) : l'éditeur empêche le user d'aller bidouiller les ressources internes.
• Exemple : tu déploies une Managed App AKS depuis Marketplace. Azure crée un RG mc_aks_managed_xxx avec VMSS/NSG/LB → une deny assignment est ajoutée auto sur ce RG. Résultat : tu ne peux PAS modifier le NSG ou supprimer la VM, même si tu es Owner de la sub. Tu dois passer par les paramètres exposés par l'éditeur.
• Visualiser : Resource > IAM > Deny assignments (onglet à côté de Role assignments). Lecture seule.

Entra ID Roles

Permissions sur l'annuaire : créer un user, reset password, gérer apps, lire audit logs, etc.

Built-in roles courants

• Global Administrator : full Entra (à limiter au max).
• User Administrator : créer/modifier/supprimer users + reset password + gérer tous les groupes.
• Helpdesk Administrator : reset password (users non-admins).
• Privileged Role Administrator : assigner des rôles Entra (y compris à soi-même).
• Application Administrator / Cloud App Administrator : gérer les apps.
• Authentication Administrator : gérer méthodes MFA des users.
• Cloud Device Administrator : enable/disable/delete devices Entra + read BitLocker keys. ❌ Ne gère PAS : groupes (≠ User Admin), users, autres propriétés device.

Particularités vs Azure RBAC

• Scope possible : Tenant, AU, ou Application (pas de RG/Resource).
• Pour assigner un rôle Entra à un groupe : groupe créé avec l'option Microsoft Entra roles can be assigned to the group activée → uniquement à la création, irréversible. P1 requis.
• Custom roles → P1 requis, permissions limitées à un sous-ensemble (toutes les actions Entra ne sont pas customisables).

Custom Security Attributes

Métadonnées clé-valeur custom (Project=Confidential, Department=Finance) attachables aux users, groupes, service principals (Enterprise apps). Utilisés pour ABAC (conditions dans role assignments RBAC), filtrage, audit.

• Sur quoi : Users / Groups / Service Principals. ❌ Pas sur devices, ❌ pas sur resources Azure (≠ Tags Azure).
• Licence : Entra ID P1 ou P2 requis.
• Structure : Attribute Set (namespace) > Attribute (clé) > Allowed values (optionnel : liste fermée).

Rôles dédiés (séparés de Global Admin pour least privilege)

🚨 Piège exam : Global Admin n'a PAS l'accès par défaut aux Custom Security Attributes — il doit explicitement s'auto-assigner un des rôles ci-dessus pour pouvoir lire/modifier. Conception "by design" pour limiter l'exposition par défaut.

"Qui peut assigner une security attribute à un user/groupe ?" → Attribute Assignment Administrator (pas User Admin, pas Global Admin par défaut).

DEMO — Custom Security Attribute

1. Self-assign le rôle : Entra > Roles and administrators > Attribute Definition Administrator > Add assignments → s'ajouter (Global Admin nécessaire pour ce step).
2. Créer un Attribute Set : Entra > Protect & secure > Custom security attributes > Add attribute set (ex HR).
3. Créer une Attribute dans le set (ex Project, type String, multi-value Yes/No, allowed values prédéfinies optionnelles).
4. Assigner à un user : Users > [user] > Custom security attributes > Add assignment → choisir set/attribute/value.
5. Utilisation ABAC : dans un role assignment Azure RBAC → onglet Conditions → expression @Principal[Microsoft.Directory/CustomSecurityAttributes/HR.Project] StringEquals 'Confidential'.

DEMO — chemins portail & commandes

Assigner un rôle Azure RBAC

1. Resource (ou RG / Sub / MG) > Access control (IAM) > Add > Add role assignment
2. Choisir le rôle (ex Virtual Machine Contributor) → Next
3. Members → User / Group / Service Principal / Managed Identity → Select
4. Review + assign

Pour vérifier les rôles d'un user : IAM > Check access > sélectionner l'identité.

Créer un Azure RBAC Custom Role (Cloud Shell)

# 1. Activer Cloud Shell (nécessite un Storage)
mkdir roles && cd roles
code koalificationteam.json   # coller le JSON, mettre l'ID de la sub dans AssignableScopes

# 2. Créer le rôle
New-AzRoleDefinition -InputFile ./koalificationteam.json

# 3. L'assigner via le portail
# Sub > Access control (IAM) > Add role assignment > Type: Custom roles

Alternative CLI : az role definition create --role-definition ./koalificationteam.json

Assigner un rôle Entra ID

Méthode 1 — direct sur le rôle :

• Entra > Roles and administrators > [Rôle, ex Helpdesk Administrator] > Add assignments
• Scope : Directory (Tenant) ou Administrative Unit

Méthode 2 — via groupe (P1) :

• Entra > Groups > New group
• ⚠️ Cocher Microsoft Entra roles can be assigned to the group → uniquement à la création, on ne peut pas l'activer après.
• Puis assigner les rôles Entra au groupe.

Créer un Entra ID Custom Role

1. Entra > Roles and administrators > New custom role
2. Définir nom + permissions (uniquement des actions liées à Entra, ex microsoft.directory/users/standard/read)
3. Le rôle créé apparaît dans la liste → ouvrir → Assignments > Add assignment
4. Choisir scope : Directory / AU / Application

Pour plus de contrôle : utiliser PowerShell ou MS Graph API (interface portail = sous-ensemble des permissions disponibles).

À retenir pour l'exam

• Azure RBAC ≠ Azure Policy (RBAC = qui peut faire quoi / Policy = standards et conformité).
• Owner = Contributor + gestion des accès.
• Le scope le plus bas gagne en clarté mais l'héritage est cumulatif (un user peut avoir plusieurs rôles, l'union des permissions s'applique).
• Deny > Allow (mais deny assignments sont rares, Azure-only).
• P1 obligatoire pour : Entra Custom Roles + groupes assignables aux rôles Entra.

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

Scenario 1 : Gaming studio AAA — 400 devs, 80 ingés DevOps

Contexte business : studio jeu vidéo en production, 6 environnements (dev/staging/prod × EU/US). Les devs ont besoin d'autonomie sur leurs VMs Linux de build, mais ne doivent pas pouvoir purger les Storage de save games joueurs ni toucher au réseau. Choix techniques : Custom Role RBAC + scope Resource Group + rôle dédié Resource Policy Contributor pour l'équipe FinOps/Gouvernance. Architecture / pattern :

• Hiérarchie : MG Studio-Root → MG Prod & NonProd → Subs par jeu → RG par feature
• Custom role Dev-VM-Operator = Microsoft.Compute/virtualMachines/* + NotActions: delete — assigné au RG de build uniquement
• FinOps team = Cost Management Contributor + Resource Policy Contributor au scope MG Studio-Root (pas Owner)
• Service Principals CI/CD scopés au RG cible, jamais à la sub Pièges à éviter :
• Donner Contributor sur la sub à toute l'équipe dev pour "aller vite" → un dev peut effacer la VM de prod par mégarde (héritage descendant)
• Croire que NotActions: delete empêche la suppression : un autre role assignment Owner ailleurs annulera la restriction (NotActions ≠ deny)
• Oublier le champ AssignableScopes dans le JSON → impossible de créer le rôle (/subscriptions/<id> minimum)

Scenario 2 : Banque de détail — gouvernance Tenant Root + auditabilité

Contexte business : banque réglementée (PCI-DSS, ACPR). L'équipe sécurité doit prouver à l'auditeur que personne n'a Owner permanent sur le MG racine, et que toute action privilégiée est traçable. Choix techniques : séparation stricte Entra Roles vs Azure RBAC + Privileged Role Administrator pour la délégation + break-glass dans une AU Restricted. Architecture / pattern :

• Activation explicite Access management for Azure resources (Entra > Properties) uniquement pour le bootstrap, puis désactivation
• User Access Administrator au MG Root assigné à un groupe (pas un user) → permet rotation sans casser RBAC
• 2 comptes break-glass cloud-only en AU Restricted Management → même un Global Admin compromis ne peut pas les toucher
• Privileged Role Administrator séparé de Global Admin (≠ même personne) → l'un fait, l'autre vérifie Pièges à éviter :
• Penser que Global Admin Entra = Owner Azure : NON, il faut explicitement activer la elevation Access management for Azure resources (toggle dans Entra Properties)
• Vouloir créer une deny assignment manuellement pour bloquer un Owner — impossible, seuls Blueprints et Managed Apps en créent
• Mélanger Classic admins (Account/Service/Co-Admin) avec RBAC moderne → les Co-Admins ont Owner implicite, audit difficile

Scenario 3 : SaaS B2B healthcare — Managed App publiée sur Marketplace

Contexte business : éditeur SaaS publie une solution AKS pré-packagée sur Azure Marketplace pour des cliniques. Le client déploie l'app dans sa sub mais ne doit PAS pouvoir bidouiller le NSG ni les secrets internes (sinon support cassé). Choix techniques : Managed Application (déclenche deny assignments automatiques) + Custom Security Attributes pour le tagging des tenants clients + ABAC conditions sur le RBAC. Architecture / pattern :

• Publication Managed App → Azure crée un RG mc_* côté client avec deny assignment auto (le client Owner ne peut PAS modifier les NSG / VMSS internes)
• Custom Security Attribute Tier=Premium|Standard assigné aux Service Principals des tenants clients
• Role assignment côté ressource publique avec condition ABAC : @Principal[...Tier] StringEquals 'Premium'
• Rôle Attribute Assignment Administrator au sales-ops (pas Global Admin) Pièges à éviter :
• Croire qu'un Owner de sub peut overrider le deny assignment Managed App → non, deny > allow toujours, par design
• Assigner Attribute Definition Administrator à tous les admins → fuite du schéma de tiering aux concurrents qui invitent un guest
• Oublier que Global Admin n'a PAS accès par défaut aux Custom Security Attributes → self-assignment requis, sinon il ne voit même pas l'attribut

Scenario 4 : E-commerce mid-market — délégation helpdesk par région

Contexte business : marchand en ligne avec 6 BU (FR, BE, NL, DE, ES, IT). Chaque BU a son propre helpdesk niveau 1 qui doit reset les mots de passe et ajouter des users, sans voir les autres pays ni toucher aux admins. Choix techniques : Entra Built-in Roles scopés sur AU + groupes assignables aux rôles + jamais de custom Entra role (pas nécessaire). Architecture / pattern :

• AU Helpdesk-FR, Helpdesk-DE, etc. → contient les users de chaque pays (via dynamic AU sur user.country)
• Groupe Security Helpdesk-Operators-FR créé avec Microsoft Entra roles can be assigned to the group = Yes (irréversible !)
• Rôle Helpdesk Administrator assigné au groupe au scope AU Helpdesk-FR
• Idem chaque pays → ajouter/retirer un membre du groupe = rotation sans toucher au role assignment Pièges à éviter :
• Oublier de cocher Microsoft Entra roles can be assigned to the group à la création → impossible de le faire après, il faut recréer le groupe
• Donner User Administrator au lieu de Helpdesk Administrator → permet la gestion de tous les groupes, dépasse le besoin
• Croire que Cloud Device Administrator gère les groupes — non, il ne touche que les devices (piège exam fréquent)