Identity & Zero Trust sur Azure : ce qu’on peut faire sans licence P2
Le Projet 2 de mon lab Azure portait sur le domaine le plus lourd de l’AZ-500 : la gestion des identités et des accès. Environ 30% des questions de l’examen gravitent autour d’Entra ID, du RBAC, de PIM et du Conditional Access. Difficile de faire l’impasse.
Ce que je n’avais pas anticipé : une bonne partie de ces fonctionnalités est verrouillée derrière des licences que Microsoft refuse d’accorder aux comptes personnels. Cet article raconte ce que j’ai réussi à faire, ce que j’ai compris sans pouvoir le tester, et pourquoi la contrainte de licence est en soi une leçon utile.
Les configs et commandes détaillées sont sur GitHub.
L’identité comme nouveau périmètre
Dans un réseau traditionnel, le périmètre de sécurité c’est le firewall. Tout ce qui est derrière est “de confiance”, tout ce qui vient de l’extérieur est suspect. Zero Trust casse cette logique : plus de périmètre réseau par défaut, chaque accès est vérifié indépendamment de l’origine.
Concrètement dans Azure, ça signifie que l’identité devient le point de contrôle central. Un NSG mal configuré est un problème. Un compte compromis avec des droits Owner sur l’abonnement, c’est une catastrophe. D’où l’intérêt de vraiment comprendre Entra ID avant de toucher à Defender ou Key Vault.
Venant de douze ans en BI bancaire où on gérait des droits d’accès sur des bases de données Oracle et des espaces Power BI, j’avais une intuition de la gestion des accès. Mais le modèle Entra ID est structurellement différent, et ça valait la peine de tout reprendre depuis le début.
Ce qu’Entra ID est vraiment
Premier point à clarifier : Entra ID (anciennement Azure Active Directory) n’est pas un simple annuaire. C’est le service d’identité cloud de Microsoft, qui gère les utilisateurs, les groupes, les applications et les appareils d’un tenant. Le tenant, c’est le niveau d’isolation le plus haut : une entreprise = un tenant, ou plusieurs dans le cas de grandes structures avec filiales.
La distinction qui surprend quand on arrive sur Azure : les rôles Entra ID et les rôles Azure RBAC sont deux systèmes complètement séparés. Être Global Administrator dans Entra ID ne donne aucun droit sur les ressources Azure (VMs, storage, réseaux). Et inversement, un Owner sur un abonnement Azure n’a pas forcément des droits d’administration sur l’annuaire. C’est un piège classique aux examens, et ça crée de vraies confusions en production.
Les protocoles d’authentification, aussi. Entra ID utilise OIDC pour l’authentification et OAuth2 pour l’autorisation. Kerberos reste présent dans les environnements hybrides avec Active Directory on-premise, mais il n’entre pas en jeu pour les authentifications cloud natives. La distinction OIDC / OAuth2 / Kerberos revient régulièrement dans les questions AZ-500.
RBAC en pratique
Pour toucher quelque chose de concret, j’ai créé un utilisateur de test dans le tenant et lui ai assigné le rôle Lecteur sur le resource group Projet-Azure-1. L’objectif était de valider la mécanique : quelle est la différence entre assigner un rôle au niveau de l’abonnement vs au niveau d’un resource group vs au niveau d’une ressource individuelle ?
La réponse est dans le concept de scope. Un rôle s’hérite vers le bas : un Lecteur assigné à l’abonnement peut lire toutes les ressources de tous les resource groups. Assigné uniquement sur Projet-Azure-1, il ne voit que ce resource group. C’est le principe du moindre privilège appliqué concrètement.
La vérification via “Vérifier l’accès” dans le portail IAM confirme visuellement les permissions d’un utilisateur sur une ressource donnée. Pratique pour auditer sans avoir à se connecter avec le compte de l’utilisateur.
Les identités managées méritent une mention à part. Quand la VM du Projet 1 avait besoin d’interagir avec d’autres services Azure, l’alternative à stocker des credentials dans le code c’est d’utiliser une identité managée : Azure assigne automatiquement une identité à la ressource et gère le cycle de vie des tokens. Dans IAM, elle apparaît comme n’importe quel autre principal avec un rôle assigné.
Le mur de la licence
PIM — Privileged Identity Management — répond au problème des privilèges permanents. Plutôt qu’assigner un rôle Owner en permanence à un compte, PIM permet de le rendre “eligible” : l’utilisateur demande l’élévation pour une durée limitée, avec une justification, éventuellement soumise à approbation. Concept JIT, zéro standing privileges. Beaucoup d’organisations devraient l’avoir sur leurs comptes à privilèges élevés. Beaucoup ne l’ont pas.
Conditional Access fonctionne sur une logique SI/ALORS : si un utilisateur se connecte depuis un appareil non reconnu ET hors du réseau de l’entreprise, alors forcer le MFA. Ou bloquer. Les politiques peuvent cibler des applications spécifiques, des groupes d’utilisateurs, des niveaux de risque détectés par Identity Protection.
Les deux nécessitent une licence Entra ID P2 (ou M365 E5 qui l’inclut). Avec un compte Azure PAYG personnel, le trial P2 est refusé. Le Microsoft 365 Developer Program, qui aurait fourni un tenant E5 complet, refuse les comptes personnels depuis que Microsoft a durci ses critères en 2023. J’ai tenté avec un compte Outlook neuf : même résultat.
Je ne vais pas prétendre que j’ai pratiqué PIM et Conditional Access. J’ai vu les interfaces, compris les concepts, documenté le blocage. Sur le terrain, cette contrainte de licence arrive aussi en PME : “on ne peut pas activer PIM parce qu’on n’a pas P2” est une vraie conversation, pas juste un cas de lab.
Ce que les journaux racontent
Ce qui était accessible sans licence supplémentaire : les journaux de connexion et les journaux d’audit Entra ID, dans Surveillance et Intégrité.
Les journaux de connexion enregistrent chaque tentative d’authentification : qui, quand, depuis quelle IP et quel agent utilisateur, résultat, niveau de risque, et l’état du Conditional Access au moment de la connexion. Sur mon tenant, toutes les lignes affichent “Conditional Access : non appliqué” faute de politiques actives. Ça donne quand même une idée de ce qu’un analyste SOC surveille. Les patterns d’attaque se lisent directement dans les logs. Une tentative de Password Spraying se voit à l’œil nu : même IP, codes d’erreur d’authentification, comptes différents, intervalles de quelques secondes.
Les journaux d’audit, c’est autre chose. Là où les journaux de connexion tracent les authentifications, les journaux d’audit tracent les actions d’administration : création d’un utilisateur, modification d’un rôle, changement d’une politique. En remontant au 30 avril, j’ai retrouvé l’événement “Add user” correspondant à la création du compte de test, avec toutes les propriétés renseignées au moment de la création. C’est la piste d’audit de l’annuaire, l’équivalent du changelog d’une base de données, mais pour les identités.
La suite
Le Projet 3 porte sur Defender for Cloud et Microsoft Sentinel. La question de la licence ne disparaît pas, mais Sentinel a ses propres mécanismes, à explorer.
Pour PIM et Conditional Access en pratique, il faudra soit un tenant organisationnel, soit une opportunité en stage ou en poste. Les concepts sont là.
Ce que j’en retiens
Le domaine Identity & Access se structure bien une fois qu’on a compris les deux ou trois distinctions fondamentales : Entra ID vs RBAC Azure, OIDC vs OAuth2 vs Kerberos, rôle eligible vs rôle active. Le reste découle de là. Ce n’est pas le domaine le plus difficile techniquement, c’est surtout celui où les confusions de vocabulaire coûtent cher.
La contrainte de licence est frustrante mais réaliste. Savoir expliquer pourquoi ces fonctionnalités manquent dans une organisation et ce que ça implique pour la posture de sécurité, c’est une compétence utile. Peut-être plus utile que de les avoir configurées en lab sans comprendre le contexte.
Ce qui m’a pris le plus de temps sur ce projet, c’est de trouver où chercher l’information dans le portail. Azure réorganise régulièrement ses menus. Les journaux de connexion se trouvent à deux endroits différents selon qu’on arrive par le menu Utilisateurs ou par Surveillance et Intégrité. Pas un problème technique, juste une question d’habitude.
Configurations et commandes disponibles sur GitHub. Projet suivant : Defender for Cloud + Microsoft Sentinel.