Activation PIM Entra : Approbation, MFA, Justification

Entra PIM Activation Approbation MFA Justification Mauvaise Configuration Expliquée

Activer Microsoft Entra Privileged Identity Management (PIM) est la partie facile. L'Entra PIM activation approbation MFA justification mauvaise configuration est ce qui se passe ensuite : PIM est déployé, les rôles sont éligibles plutôt que permanents, mais l'étape d'activation elle-même reste grande ouverte — aucune approbation requise, aucun MFA à l'activation, aucune justification enregistrée, et une fenêtre d'activation de 8 heures ou plus. Le résultat ressemble à un accès juste-à-temps sur un tableau de bord, mais se comporte comme un accès admin permanent en pratique : quiconque est éligible à un rôle l'obtient dès qu'il clique sur « Activer », sans second facteur, sans piste de responsabilité, et avec une fenêtre assez longue pour dépasser la plupart des cycles de détection.

C'est un mode de défaillance distinct de « PIM n'est pas du tout activé ». Un tenant peut réussir ce premier contrôle et rester exposé, car la valeur de sécurité de PIM provient presque entièrement de la façon dont l'activation est configurée, et non du simple fait que des assignations éligibles existent. Chacun des quatre contrôles d'activation — approbation, MFA, justification et durée — est optionnel par rôle dans Microsoft Entra, et aucun n'est requis par défaut.

⚠️

⚠️ Avertissement : les paramètres de rôle PIM sont propres à chaque rôle et indépendants. Corriger Administrateur Global ne corrige pas Administrateur de Rôle Privilégié, Administrateur de Sécurité, ni aucun rôle d'annuaire personnalisé — chacun doit être vérifié et configuré séparément.

Comment Fonctionnent les Contrôles d'Activation PIM

Microsoft Entra expose les paramètres de rôle PIM — appelés en interne policies — via le centre d'administration Microsoft Entra (ID Governance > Privileged Identity Management > Rôles Microsoft Entra > Rôles > [rôle] > Paramètres de rôle) ou via la ressource Microsoft Graph unifiedRoleManagementPolicy. Chaque policy est composée de règles indépendantes, et quatre d'entre elles définissent ce qui se passe au moment de l'activation (Configurer les paramètres de rôle Microsoft Entra dans PIM, Mettre à jour les règles dans PIM avec Microsoft Graph) :

Contrôle	Paramètre UI	ID de règle Graph	Ce qu'il fait
Approbation	Require approval to activate	`Approval_EndUser_Assignment` (`isApprovalRequired`)	Envoie la demande d'activation à un ou plusieurs approbateurs nommés avant que le rôle ne devienne actif
MFA	On activation, require multifactor authentication	`Enablement_EndUser_Assignment` (`enabledRules: MultiFactorAuthentication`)	Force un défi MFA au moment de l'activation
Justification	Require justification on activation	`Enablement_EndUser_Assignment` (`enabledRules: Justification`)	Force une justification métier en texte libre, enregistrée avec l'activation
Durée	Activation maximum duration	`Expiration_EndUser_Assignment` (`maximumDuration`, ISO 8601, ex. `PT8H`)	Plafonne la durée pendant laquelle le rôle activé reste actif, de 1 à 24 heures

Les quatre sont configurés par rôle et aucun n'est mutuellement exclusif — un rôle bien durci a généralement l'approbation et le MFA et la justification et une durée courte, pas un seul de ces éléments.

Pourquoi « PIM Activé » Ne Signifie Pas « Activation Protégée »

Une vérification connexe, plus basique, consiste à savoir si PIM est configuré pour les rôles privilégiés — c'est un écart distinct et plus sévère, que nous couvrons dans Accès Privilégié Azure : Trop d'Admins Globaux. Cet article part du principe que ce contrôle est déjà validé : PIM est actif, les rôles sont éligibles, et le tenant paraît conforme au premier regard. L'écart traité ici est un niveau plus profond — c'est ce qui se passe à l'intérieur de PIM une fois que quelqu'un active un rôle.

Les quatre valeurs par défaut comptent car aucune d'elles ne penche vers la sécurité par défaut :

L'approbation est désactivée par défaut. Tout utilisateur éligible peut s'auto-activer immédiatement, sans qu'une seconde personne intervienne.
Le MFA à l'activation a un angle mort documenté. La documentation de Microsoft indique elle-même que « les utilisateurs peuvent ne pas être invités à effectuer une authentification multifacteur s'ils se sont authentifiés avec des identifiants forts ou ont fourni une authentification multifacteur plus tôt dans la session » — une session ayant déjà satisfait le MFA à la connexion peut donc activer un rôle privilégié sans aucun défi supplémentaire. C'est le même angle mort de réauthentification couvert dans Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas.
La justification est désactivée par défaut, donc les activations ne portent aucune raison métier enregistrée — ce qui affaiblit à la fois la revue en temps réel et l'audit a posteriori.
La durée maximale d'activation est de 8 heures par défaut et peut être réglée jusqu'à 24 heures — assez longtemps pour qu'une session ou un jeton détourné reste exploitable pendant toute une journée de travail.

🚨 Danger : comme le paramètre MFA à l'activation ne force pas de réauthentification lorsque le MFA a déjà été satisfait dans la session, un attaquant ayant volé un jeton de session valide peut activer un rôle privilégié sans jamais toucher à un second facteur. La mitigation documentée par Microsoft pour cet écart spécifique est le contexte d'authentification Conditional Access combiné à une fréquence de connexion réglée sur « À chaque fois » — pas la simple case à cocher MFA à l'activation.

Détection

Ce qu'il faut vérifier par rôle

Récupérez la policy d'activation actuelle pour chaque rôle d'annuaire Microsoft Entra et comparez-la aux quatre contrôles ci-dessus. Manuellement, cela signifie ouvrir Paramètres de rôle pour chaque rôle dans le centre d'administration. À grande échelle, interrogez-la via Graph :

GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'&$expand=rules

Ou avec Microsoft Graph PowerShell :

# Nécessite RoleManagement.Read.Directory ou RoleManagement.ReadWrite.Directory
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$policies = Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/' and scopeType eq 'DirectoryRole'"
foreach ($p in $policies) {
    Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $p.PolicyId |
        Where-Object { $_.Id -in @('Approval_EndUser_Assignment','Enablement_EndUser_Assignment','Expiration_EndUser_Assignment') }
}

Pour chaque rôle, signalez-le si : isApprovalRequired est false, enabledRules de la règle d'enablement n'inclut pas MultiFactorAuthentication, enabledRules n'inclut pas Justification, ou maximumDuration de la règle d'expiration dépasse votre seuil de policy (généralement 1 à 4 heures pour les rôles Tier-0). Priorisez Administrateur Global, Administrateur de Rôle Privilégié, Administrateur de Sécurité, Administrateur d'Accès Conditionnel, et tout rôle personnalisé disposant de droits d'écriture à l'échelle de l'annuaire — ce sont les rôles où l'écart a le rayon d'impact le plus élevé.

Ce qu'il faut surveiller dans le journal d'audit

Microsoft Entra conserve l'historique des policies PIM et des activations dans le volet Audit des ressources (ID Governance > Privileged Identity Management > Rôles Microsoft Entra > Audit des ressources), retenu 30 jours par défaut (Afficher le rapport de journal d'audit pour les rôles Microsoft Entra dans PIM) — si cette fenêtre par défaut pose problème pour vos délais d'investigation, voir Journalisation Entra ID : Rétention, Diagnostic Settings, SIEM Export pour router ces journaux vers un stockage à plus long terme. Deux types d'activité comptent le plus :

Activité	Pourquoi c'est important
`Update role setting in PIM`	Quelqu'un a modifié la policy d'activation d'un rôle — y compris en désactivant l'approbation, le MFA ou la justification, ou en allongeant la fenêtre d'activation. C'est en soi une cible de choix pour un attaquant qui a déjà un certain privilège et veut desserrer la porte avant d'activer davantage.
Demandes d'activation de rôle sans piste de justification/approbation	Les activations terminées sans approbateur enregistré et sans texte de justification sont exactement celles qu'une policy durcie aurait bloquées ou ralenties.

ℹ️

ℹ️ Note : un événement Update role setting in PIM n'est pas en soi une preuve d'attaque — des admins légitimes reconfigurent aussi les policies PIM. Traitez-le comme un signal qui mérite la même revue que tout autre changement de rôle privilégié : qui l'a fait, sur quel rôle, et si cela a affaibli ou renforcé le contrôle.

Remédiation

💡

💡 Gain Rapide : commencez par Administrateur Global et Administrateur de Rôle Privilégié — les deux rôles avec le plus grand rayon d'impact — puis étendez à tous les autres rôles éligibles.

Recensez la policy actuelle de chaque rôle avec la requête Graph ou PowerShell ci-dessus, pour disposer d'une base avant/après plutôt que d'une simple estimation par rôle.
Exigez l'approbation à l'activation pour les rôles Tier-0, avec au moins deux approbateurs nommés configurés explicitement. Ne laissez pas la liste d'approbateurs vide : la documentation de Microsoft avertit qu'un tenant peut se retrouver verrouillé si tous les Administrateurs de Rôle Privilégié/Administrateurs Globaux n'ont que des assignations éligibles (pas actives), que l'approbation est requise, et qu'aucun approbateur n'est configuré — mettez en place des comptes d'accès d'urgence correctement surveillés, en assignation active et permanente, avant d'activer ce paramètre.
Exigez le MFA à l'activation, et là où le rôle le justifie, ajoutez un contexte d'authentification Conditional Access (voir Failles Accès Conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition) avec la fréquence de connexion réglée sur « À chaque fois » — c'est ce paramètre qui force réellement la réauthentification à l'activation, au lieu d'accepter silencieusement une preuve MFA obtenue plus tôt dans la session.
Exigez la justification à l'activation (et envisagez d'exiger aussi une référence de ticket) afin que chaque activation porte une raison métier enregistrée et vérifiable.
Réduisez la durée maximale d'activation. Le défaut de 8 heures et le plafond de 24 heures existent tous deux pour le confort, pas pour la sécurité — la plupart des tâches opérationnelles tiennent en 1 à 4 heures. Réglez-le via maximumDuration de la règle d'expiration au format ISO 8601 (PT2H pour deux heures, PT4H pour quatre heures).
Appliquez la même policy à tous les rôles équivalents, pas seulement à celui que vous avez testé. Les paramètres de rôle sont indépendants, donc un script qui ne corrige qu'Administrateur Global laisse Administrateur de Rôle Privilégié, Administrateur de Sécurité et les rôles d'annuaire personnalisés inchangés.
Relancez la requête Graph d'énumération après le changement et confirmez isApprovalRequired: true, que enabledRules inclut MultiFactorAuthentication et Justification, et que maximumDuration reflète votre nouveau plafond — puis répétez ce contrôle sur un calendrier, car un futur événement Update role setting in PIM peut silencieusement tout annuler.

Comment EtcSec Détecte Cela

L'audit Azure d'EtcSec vérifie la policy d'activation PIM à chaque scan, indépendamment du fait que PIM lui-même soit activé.

PA_PIM_NO_APPROVAL_REQUIRED signale les assignations de rôle éligibles où l'activation ne requiert pas d'approbation.

PA_PIM_NO_MFA_ON_ACTIVATION signale les rôles dont la policy d'activation ne requiert pas d'authentification multifacteur.

PA_PIM_NO_JUSTIFICATION signale les rôles dont l'activation ne requiert pas de justification métier.

PA_PIM_LONG_ACTIVATION signale les rôles configurés avec une durée maximale d'activation assez longue pour prolonger significativement l'exposition après une activation compromise.

ℹ️

ℹ️ Note : EtcSec vérifie automatiquement cette vulnérabilité à chaque audit Azure. Lancez un audit gratuit pour vérifier votre environnement.

Contrôles Connexes

Le durcissement de l'activation PIM est une couche du contrôle d'accès privilégié. Passez-le en revue avec Accès Privilégié Azure : Trop d'Admins Globaux pour savoir si PIM est déployé et si le nombre d'admins permanents est maîtrisé, Comptes d'Accès d'Urgence Break Glass Entra ID : Absents, Non Surveillés, Non Exclus avant d'exiger l'approbation sur les rôles Tier-0, Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas pour l'angle mort de réauthentification que le MFA à l'activation seul ne referme pas, et Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique pour la checklist complète de revue d'identité dans laquelle ce sujet s'inscrit.