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)

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) directement (ni portail ni CLI). Azure les crée automatiquement dans 3 contextes :
  • Deployment Stacks (via deny settings) — le moyen moderne (remplaçant de Blueprints). À la création du stack tu choisis denySettings (denyDelete ou denyWriteAndDelete) → Azure crée une deny assignment possédée par le stack pour protéger les ressources managées.
  • Azure Blueprints (🚨 déprécié le 11 juillet 2026 → migrer vers Template Specs + Deployment Stacks ; encore en exam) : verrouille les ressources déployées par le blueprint (déploie les mêmes ressources + 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/modif/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 (❌ 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'.

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

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

Contexte business : studio en prod, 6 environnements (dev/staging/prod × EU/US). Les devs veulent gérer librement leurs VMs de build, mais ne doivent ni effacer les Storage de saves joueurs ni toucher au réseau. Choix architectural : on crée un Custom Role RBAC taillé sur mesure, posé au niveau du Resource Group (le plus bas), et un rôle dédié Resource Policy Contributor pour l'équipe FinOps. Architecture / pattern :

• Hiérarchie : MG Studio-Root → MG Prod & NonProd → 1 Sub par jeu → 1 RG par feature.
• Custom role Dev-VM-Operator = tout sur les VMs sauf delete (NotActions), posé seulement sur le RG de build.
• FinOps = Cost Management Contributor + Resource Policy Contributor au MG Studio-Root (et non Owner).
• Les Service Principals CI/CD sont scopés au RG cible, jamais à toute la Sub. Trade-offs assumés :
• Gain : chaque équipe est autonome sans pouvoir casser la prod ou le réseau.
• Perte : plus de rôles à concevoir et maintenir qu'un simple Contributor. Pièges à éviter :
• Donner Contributor sur la Sub à toute l'équipe → un dev peut effacer une VM de prod (l'héritage descend).
• Croire que NotActions: delete interdit la suppression : un autre rôle Owner ailleurs l'annule (NotActions n'est pas un deny).
• Oublier AssignableScopes dans le JSON → impossible de créer le rôle (/subscriptions/<id> minimum).

📐 Réf. CAF — Just-enough-access (JEA) & subscription democratization : scoper les custom roles au plus bas (RG) pour que l'équipe app gère ses workloads dans les guardrails de la plateforme est le pattern CAF Landing zone identity & access management. Lien

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

Contexte business : banque réglementée (PCI-DSS, ACPR). La sécurité doit prouver à l'auditeur que personne n'est Owner permanent du MG racine et que toute action sensible est tracée. Choix architectural : on sépare nettement les rôles Entra et les rôles Azure RBAC, on délègue via Privileged Role Administrator, et on protège les comptes break-glass dans une AU Restricted. Architecture / pattern :

• On active Access management for Azure resources (Entra > Properties) juste le temps du bootstrap, puis on le coupe.
• User Access Administrator sur le MG Root est posé sur un groupe (pas un user) → on peut tourner les gens sans casser le RBAC.
• 2 comptes break-glass cloud-only en AU Restricted → même un Global Admin compromis ne peut pas y toucher.
• Privileged Role Administrator confié à une autre personne que le Global Admin → l'un agit, l'autre vérifie. Trade-offs assumés :
• Gain : aucun accès permanent excessif, séparation des pouvoirs prouvable en audit.
• Perte : plus d'étapes pour obtenir un accès (friction volontaire). Pièges à éviter :
• Croire que Global Admin Entra = Owner Azure : non, il faut activer l'élévation Access management for Azure resources dans Entra Properties.
• Vouloir créer une deny assignment à la main pour bloquer un Owner → impossible : seuls Deployment Stacks, Blueprints et Managed Apps en créent.
• Mélanger les Classic admins (Account/Service/Co-Admin) avec le RBAC moderne → les Co-Admins ont Owner implicite, audit illisible.

📐 Réf. CAF — Enterprise access model & Landing zone IAM : séparer les rôles privilégiés, assigner User Access Administrator à un groupe (rotation), utiliser PIM (JIT) et protéger les break-glass via Restricted Management AU sont les recommandations CAF/WAF de gouvernance du control plane. Lien

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

Contexte business : un éditeur publie une solution AKS pré-packagée sur le Marketplace. Le client la déploie chez lui mais ne doit PAS pouvoir modifier le NSG ni les secrets internes (sinon le support casse). Choix architectural : on la livre en Managed Application (qui crée automatiquement des deny assignments), on étiquette les tenants clients avec des Custom Security Attributes, et on filtre l'accès via des conditions ABAC. Architecture / pattern :

• La Managed App crée un RG mc_* chez le client avec deny assignment auto → même Owner, il ne peut pas toucher aux NSG/VMSS internes.
• Custom Security Attribute Tier=Premium|Standard posé sur les Service Principals des clients.
• Sur la ressource partagée, le rôle est donné avec une condition ABAC : @Principal[...Tier] StringEquals 'Premium'.
• Rôle Attribute Assignment Administrator confié au sales-ops (pas Global Admin). Trade-offs assumés :
• Gain : le producteur garde la main sur l'interne, l'accès suit le tier commercial automatiquement.
• Perte : modèle ABAC + attributs custom plus complexe à mettre en place et à comprendre. Pièges à éviter :
• Croire qu'un Owner peut contourner le deny assignment → non, deny l'emporte toujours, par design.
• Donner Attribute Definition Administrator à tous les admins → un guest peut lire le schéma de tiering (fuite concurrentielle).
• Oublier que Global Admin n'a PAS accès par défaut aux Custom Security Attributes → il faut se l'attribuer, sinon il ne voit même pas l'attribut.

📐 Réf. — Azure Managed Applications & ABAC : les deny assignments auto sur le RG managé (mc_*) et les conditions ABAC sur les attributs custom suivent le modèle producteur/consommateur documenté. Managed Apps · ABAC

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).