Azure AD Premium P2 : PIM, Identity Protection et Access Reviews jamais activés

Azure AD Premium P2 : PIM, Identity Protection et Access Reviews jamais activés

Les fonctionnalités d'Azure AD Premium P2 — Privileged Identity Management (PIM), Identity Protection et Access Reviews — sont verrouillées derrière la licence premium de second niveau de Microsoft, mais l'attribution d'une licence P2 à un utilisateur ne signifie pas que l'une des trois est réellement configurée dans le tenant. Microsoft Entra ID P2 (le nom actuel d'Azure AD Premium P2) se situe au-dessus de P1 et est inclus dans Microsoft 365 E5, E7, et Enterprise Mobility + Security E5. En version autonome, elle est affichée à 10 $/utilisateur/mois (tarification Microsoft Entra). Sur le papier, c'est le niveau que tout tenant soucieux de sécurité devrait avoir. En pratique, de nombreux tenants l'ont attribuée à certains ou à tous leurs utilisateurs et n'utilisent presque rien de ce qu'elle propose réellement.

Cet écart compte parce que ces trois capacités ne sont pas de simples options cosmétiques. Ce sont précisément les éléments que Microsoft verrouille derrière le SKU P2 (Microsoft Entra ID Governance peut se substituer à certaines d'entre elles, mais P2 reste la voie la plus courante). Si vous payez la licence et qu'aucune des trois n'est configurée, vous payez pour une capacité que vous n'utilisez pas, alors que votre posture réelle d'accès privilégié et de risque reste identique à celle d'un tenant P1 — voir comment auditer la sécurité de Microsoft Entra ID pour la base complète dans laquelle s'inscrivent les contrôles de cet article.

Selon la référence de licence de Microsoft elle-même, trois capacités précises nécessitent P2 (ou Entra ID Governance) et sont tout simplement indisponibles — pas dégradées, indisponibles — en dessous : les politiques d'Accès Conditionnel basées sur le risque (risque de connexion et risque utilisateur), Privileged Identity Management pour les rôles Entra comme pour les rôles de ressources Azure, et la génération actuelle des Access Reviews (Licences Microsoft Entra — Microsoft Learn). Cet article détaille le fonctionnement de chacune, ce à quoi ressemble « configuré » sur le papier par rapport à la réalité du tenant, et comment détecter et combler l'écart.

Comment fonctionne réellement chaque fonctionnalité P2

Privileged Identity Management (PIM)

Le modèle de PIM oppose l'attribution de rôle « éligible » à l'attribution « active ». Un utilisateur rendu éligible à un rôle — Global Administrator, par exemple — ne détient aucun privilège permanent. Pour utiliser le rôle, il doit demander une activation, ce qui peut exiger le MFA, une justification ou l'approbation d'un approbateur désigné, et l'attribution active qui en résulte est limitée dans le temps et expire automatiquement (Microsoft Entra ID Governance — Qu'est-ce que PIM). C'est ce modèle juste-à-temps qui supprime l'accès admin permanent en tant que surface d'attaque — voir Accès Privilégié Azure : Trop d'Administrateurs Globaux pour ce que coûte réellement un accès permanent sans PIM.

PIM couvre également les rôles de ressources Azure (Owner, Contributor, etc. à n'importe quelle portée) et PIM pour les groupes, où l'éligibilité à l'appartenance ou à la propriété d'un groupe nécessite elle-même une licence P2 (ou Entra ID Governance) pour chaque membre, propriétaire, approbateur et réviseur éligible — pas seulement pour les administrateurs. Les scénarios d'exemple de Microsoft rendent le calcul de licence concret : un tenant avec 42 administrateurs gérés via PIM, plus 5 approbateurs et 6 réviseurs impliqués dans des revues de privilèges mensuelles, nécessite 53 licences, pas 42 (Licences Microsoft Entra — section PIM). Les équipes qui ne budgétisent le P2 que pour les comptes admin sous-licencient régulièrement ce point et se retrouvent avec des approbateurs ou des réviseurs silencieusement bloqués.

Identity Protection

Identity Protection évalue le risque des connexions et des utilisateurs grâce à des détections à la fois en temps réel et hors ligne (post-authentification) — identifiants divulgués, adresses IP anonymes, déplacements impossibles, propriétés de connexion inhabituelles et compromission confirmée par le renseignement sur les menaces, entre autres (Types et niveaux de détection de risque — Microsoft Learn). Les détections à faible risque expirent automatiquement après six mois ; les risques moyens et élevés persistent jusqu'à ce qu'un administrateur les corrige ou les ignore. Le score de risque ne devient exploitable que lorsqu'il est relié à une politique d'Accès Conditionnel basée sur le risque de connexion ou le risque utilisateur — sans cette politique, Identity Protection génère un rapport que personne ne regarde au lieu d'un contrôle automatisé, un des mêmes trous que ceux détaillés dans Failles d'Accès Conditionnel Azure : Contournement du MFA. Voir Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués pour savoir comment construire cette politique.

Access Reviews

Les Access Reviews permettent à des réviseurs désignés (un manager, un propriétaire de ressource, ou les utilisateurs eux-mêmes) de recertifier périodiquement l'appartenance à un groupe, l'accès aux applications, les attributions de rôles éligibles PIM et l'accès invité, plutôt que de compter sur le fait que quelqu'un se souvienne de retirer un accès devenu inutile. Le niveau de capacité « précédemment disponible en général dans Microsoft Entra ID P2 » est ce dont disposent la plupart des tenants P2 aujourd'hui (Licences Microsoft Entra — Access reviews). La licence suit la population revue, pas seulement le réviseur : la revue d'un groupe de 500 membres avec trois propriétaires de groupe comme réviseurs nécessite 503 licences dans l'exemple travaillé de Microsoft — les membres revus doivent eux aussi être couverts, pas seulement les personnes qui effectuent la revue.

Détection : utilisez-vous réellement ce que vous payez ?

L'attribution de licence et la configuration de la fonctionnalité sont deux questions différentes, et le centre d'administration Entra permet de confirmer facilement la première sans jamais vérifier la seconde. Voici quoi vérifier pour chacune.

Get-MgRoleManagementDirectoryRoleEligibilitySchedule (Microsoft Graph PowerShell SDK) renvoie chaque attribution éligible PIM dans le tenant, séparément de Get-MgRoleManagementDirectoryRoleAssignmentSchedule pour les attributions actives/permanentes — comparer les deux listes est le moyen le plus rapide de voir combien de rôles privilégiés passent réellement par PIM plutôt que de rester des octrois permanents (Référence Microsoft Graph PowerShell).

Remédiation : activer ce que vous possédez déjà

1. Migrer les attributions privilégiées permanentes vers PIM éligible. Dans ID Governance → Privileged Identity Management → Rôles Microsoft Entra, passez en revue chaque attribution active. Pour les rôles qui n'ont pas besoin d'accès permanent, retirez l'attribution permanente et créez-en une éligible avec une durée d'activation, une exigence MFA, et (pour Global Administrator et les rôles similairement sensibles) une approbation.
2. Activer l'Accès Conditionnel basé sur le risque. Créez une politique de risque de connexion (par exemple, exiger le MFA à risque moyen) et une politique de risque utilisateur (par exemple, exiger un changement de mot de passe sécurisé à risque élevé) sous Protection → Accès Conditionnel. Sans cette étape, Identity Protection reste un tableau de bord, pas un contrôle.
3. Activer les notifications pour les utilisateurs à risque. Configurez le résumé hebdomadaire et les alertes utilisateur-à-risque dans les paramètres d'Identity Protection afin que le risque ne soit pas quelque chose qu'un administrateur doit penser à vérifier.
4. Mettre en place des revues d'accès pour les périmètres à plus forte valeur en premier : les attributions de rôles éligibles PIM, les groupes imbriqués dans des rôles privilégiés et l'accès invité — voir Comptes Invités Azure : la Surface d'Attaque Oubliée pour comprendre pourquoi les comptes invités obsolètes sont généralement les pires contrevenants. Définissez une cadence récurrente (trimestrielle est un défaut raisonnable) et assignez des propriétaires de ressources ou des managers comme réviseurs plutôt qu'un seul administrateur central qui n'aura pas le contexte pour chaque groupe.
5. Revérifier le calcul de licence avant de monter en échelle. PIM pour les groupes et Access Reviews nécessitent tous deux une licence P2 (ou Governance) pour chaque membre, approbateur et réviseur éligible — pas seulement les administrateurs cibles. Sous-licencier ce point signifie que l'outil cesse silencieusement de couvrir des personnes qu'il devrait couvrir.
6. Vérifier par rapport à un référentiel. Les recommandations du CIS Microsoft 365 Foundations Benchmark pour PIM et les revues d'accès offrent un seuil concret et auditable — utile à la fois pour confirmer que vous avez comblé l'écart et pour justifier la dépense P2 auprès de qui l'a approuvée.

🚨 Danger : si une licence P2 (ou Governance) expire ou est retirée, PIM ne se contente pas d'arrêter d'appliquer les contrôles — Microsoft documente explicitement que les attributions de rôles Entra éligibles sont supprimées, que toute revue d'accès en cours sur des rôles Entra se termine, et que les paramètres de configuration PIM sont supprimés (Licences Microsoft Entra — expiration de licence PIM). Les attributions de rôles permanentes ne sont pas affectées par cela, ce qui explique précisément pourquoi s'appuyer sur PIM sans maintenir la couverture de licence à jour donne un faux sentiment de sécurité.

Comment EtcSec détecte cela

L'audit Azure d'EtcSec vérifie AZ_NO_P2_LICENSE (P2 présent dans le tenant mais ses fonctionnalités signature inutilisées), AZ_P2_NOT_FULLY_UTILIZED, PA_PIM_NOT_ENABLED et PA_PERMANENT_ADMIN_ASSIGNMENTS pour signaler les rôles privilégiés détenus hors PIM, RISK_NO_SIGNIN_RISK_POLICY pour repérer Identity Protection fonctionnant sans politique d'Accès Conditionnel qui l'applique, et AZ_ACCESS_REVIEWS_NOT_CONFIGURED pour signaler les tenants sans couverture de revue d'accès récurrente sur les rôles privilégiés ou l'accès invité.