PIM Entra ID : Gestion des Acces Privilegies Just-in-Time

Introduction

La gestion des identites privilegiees constitue le talon d'Achille de la plupart des organisations. Selon le rapport Verizon DBIR 2025, 74 % des breches impliquent un abus de privileges, et les comptes administratifs permanents representent la cible principale des attaquants. Microsoft Entra ID Privileged Identity Management (PIM) repond a cette problematique en introduisant un modele d'acces just-in-time (JIT) : les privileges ne sont actives que lorsque necessaire, pour une duree limitee, avec des controles d'approbation et d'audit. Les organisations deployant PIM constatent en moyenne une reduction de 64 % des incidents lies aux comptes privilegies selon les donnees Microsoft.

Ce guide technique detaille l'ensemble des fonctionnalites PIM : configuration des roles eligible versus actif, workflows d'approbation, integration MFA, PIM pour les groupes et les ressources Azure, campagnes d'Access Reviews automatisees, monitoring via KQL et Microsoft Sentinel, et les bonnes pratiques incluant la gestion des comptes break-glass. L'objectif est de fournir aux equipes IAM, SecOps et architectes cloud un reference operationnel pour implementer une strategie de moindre privilege robuste.

Pourquoi PIM : le probleme des privileges permanents

Le risque des Standing Privileges

Dans un environnement traditionnel, les administrateurs disposent de privileges permanents (standing privileges). Un compte Global Administrator est actif 24 heures sur 24, 7 jours sur 7, qu'il soit utilise ou non. Cette approche presente des risques majeurs :

• Surface d'attaque elargie : un compte compromis par phishing ou vol de credentials donne immediatement acces aux privileges les plus eleves.
• Lateral movement facilite : les attaquants utilisent les comptes privilegies permanents pour pivoter vers d'autres systemes, comme documente dans les techniques d'escalade de privileges AWS.
• Absence de tracabilite : sans activation explicite, il est difficile de distinguer une utilisation legitime d'un abus.
• Non-conformite reglementaire : les referentiels ISO 27001 (controle A.8.2) et NIS 2 exigent une gestion stricte des acces privilegies.
• Drift des permissions : les droits s'accumulent au fil du temps sans revue systematique, un phenomene appele privilege creep.

Le modele Zero Standing Privileges (ZSP)

PIM implemente le concept de Zero Standing Privileges : aucun utilisateur ne possede de privileges permanents en production. Les acces sont accordes a la demande (just-in-time), pour une duree limitee (time-bound), avec une justification obligatoire et, selon la criticite, une approbation manuelle. Ce modele reduit drastiquement la fenetre d'exposition :

Metrique	Sans PIM	Avec PIM
Duree d'exposition privileges	24/7 (8 760 h/an)	2-4 h/activation
Comptes Global Admin permanents	5-15	2 (break-glass)
Tracabilite des activations	Aucune	100 % audit trail
Incidents privileges (annuel)	Baseline	-64 %
Conformite ISO 27001 A.8.2	Partielle	Complete

PIM pour les roles Entra ID

Eligible vs Actif : comprendre la distinction

PIM introduit deux etats fondamentaux pour l'attribution des roles :

• Attribution eligible : l'utilisateur peut activer le role lorsqu'il en a besoin. Le role est inactif par defaut. L'activation requiert une justification, potentiellement une approbation et un renforcement MFA. La duree maximale d'activation est configurable (1 a 24 heures).
• Attribution active (permanente) : le role est immediatement actif, sans activation necessaire. Ce mode doit etre reserve exclusivement aux comptes de service et aux comptes break-glass. Meme les attributions actives peuvent etre limitees dans le temps.

Configuration des parametres de role

Chaque role dans PIM dispose de parametres configurables independamment. Pour le role Global Administrator, voici la configuration recommandee :

Onglet Activation

• Duree maximale d'activation : 2 heures (maximum recommande pour les roles critiques).
• Exiger une authentification multifacteur (MFA) : Oui, obligatoire. PIM force une reauthentification MFA meme si l'utilisateur a deja passe le MFA dans sa session courante.
• Exiger une justification : Oui. Le texte de justification est enregistre dans le journal d'audit et constitue une preuve pour les revues de conformite.
• Exiger des informations de ticket : Oui pour les roles critiques. Integrez avec ServiceNow, Jira ou un autre ITSM pour lier chaque activation a un ticket d'incident ou de changement.
• Exiger une approbation : Oui pour Global Admin, Privileged Role Administrator, Exchange Administrator. Definissez au minimum 2 approbateurs pour eviter un point de defaillance unique.

Onglet Attribution

• Autoriser les attributions eligibles permanentes : Non. Forcez une date d'expiration (6 mois recommande) pour obliger une revue periodique.
• Expiration des attributions actives : maximale de 90 jours, sauf pour les comptes break-glass.
• Exiger une justification lors de l'attribution : Oui. L'administrateur qui attribue un role eligible doit egalement justifier sa decision.

Onglet Notification

• Notifications aux approbateurs : activees. Les approbateurs recoivent un e-mail lorsqu'une demande d'activation est en attente.
• Notifications aux administrateurs : activees. Chaque activation reussie genere une notification aux Global Administrators.
• Notifications a l'utilisateur active : activees. L'utilisateur recoit une confirmation de son activation avec la duree restante.
• Destinataires additionnels : ajoutez l'adresse du SOC ou de la boite aux lettres de securite pour une visibilite centralisee.

Workflow d'approbation

Le workflow d'approbation PIM fonctionne comme suit : l'utilisateur soumet une demande d'activation avec justification et numero de ticket. Les approbateurs designes recoivent une notification par e-mail et dans le portail Entra. Ils peuvent approuver ou refuser la demande, avec un commentaire obligatoire en cas de refus. Si aucun approbateur ne repond dans le delai configure (par defaut 24 heures), la demande est automatiquement refusee.

Pour les roles moins critiques comme User Administrator ou Helpdesk Administrator, l'auto-activation sans approbation est acceptable, a condition que le MFA et la justification restent obligatoires. Cela permet aux equipes support d'intervenir rapidement sans attendre une validation manuelle, un principe similaire aux mecanismes d'activation decrits dans la gestion des applications enregistrees Azure AD.

Configuration via PowerShell et Microsoft Graph

Bien que le portail Entra ID offre une interface graphique pour configurer PIM, l'automatisation via Microsoft Graph API est recommandee pour les deployments a grande echelle. Voici un exemple de configuration du role Global Administrator en mode eligible avec approbation :

# Connexion a Microsoft Graph avec les permissions PIM
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory","RoleEligibilitySchedule.ReadWrite.Directory"

# Recuperer l'ID du role Global Administrator
$roleDefinition = Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Global Administrator'"

# Creer une attribution eligible pour un utilisateur
$params = @{
    action = "adminAssign"
    justification = "Attribution eligible PIM - projet securisation Q1 2026"
    roleDefinitionId = $roleDefinition.Id
    directoryScopeId = "/"
    principalId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"  # ObjectId utilisateur
    scheduleInfo = @{
        startDateTime = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
        expiration = @{
            type = "afterDuration"
            duration = "P180D"  # 180 jours = 6 mois
        }
    }
}

New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params

# Configurer les parametres du role (activation settings)
$policyParams = @{
    rules = @(
        @{
            "@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicyApprovalRule"
            id = "Approval_EndUser_Assignment"
            target = @{ caller = "EndUser"; operations = @("All"); level = "Assignment" }
            setting = @{
                isApprovalRequired = $true
                approvalStages = @(
                    @{
                        approvalStageTimeOutInDays = 1
                        isApproverJustificationRequired = $true
                        primaryApprovers = @(
                            @{
                                "@odata.type" = "#microsoft.graph.groupMembers"
                                groupId = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"  # Groupe approbateurs
                            }
                        )
                    }
                )
            }
        },
        @{
            "@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicyAuthenticationContextRule"
            id = "AuthenticationContext_EndUser_Assignment"
            target = @{ caller = "EndUser"; operations = @("All"); level = "Assignment" }
            claimValue = "c1"  # Authentication context pour MFA renforce
            isEnabled = $true
        }
    )
}

Roles critiques et classification

Tous les roles Entra ID ne necessitent pas le meme niveau de controle. Classifiez vos roles en trois niveaux de criticite pour adapter les parametres PIM :

Niveau	Roles	Duree max	Approbation	MFA
Critique	Global Admin, Privileged Role Admin, Security Admin	2h	Oui (2 approbateurs)	FIDO2 / Passkey
Eleve	Exchange Admin, SharePoint Admin, Teams Admin, Intune Admin	4h	Oui (1 approbateur)	Authenticator
Standard	User Admin, Helpdesk Admin, License Admin, Reports Reader	8h	Non (self-service)	Authenticator

PIM pour les groupes

Groupes assignables a des roles

Depuis 2024, PIM s'etend aux groupes de securite et aux groupes Microsoft 365 marques comme role-assignable. Cette fonctionnalite permet d'appliquer le modele JIT a l'appartenance aux groupes, ce qui offre des possibilites majeures :

• Acces conditionnel granulaire : un utilisateur active son appartenance a un groupe qui lui donne acces a une application specifique via Conditional Access, plutot qu'un role global.
• Delegation securisee : les proprietaires de groupes PIM peuvent gerer les membres eligibles de leur groupe sans necessiter le role Privileged Role Administrator.
• Scenarios multi-tenant : dans les architectures B2B, PIM pour les groupes permet de gerer l'acces des invites de maniere temporaire et tracee, reduisant les risques documentes dans les attaques sur les Identity Providers.

Configuration PIM pour un groupe

Pour activer PIM sur un groupe, celui-ci doit etre cree avec la propriete isAssignableToRole = true. Cette propriete est immutable apres creation. Voici la procedure :

# Creer un groupe role-assignable pour PIM
$groupParams = @{
    displayName = "PIM-Eligible-SharePoint-Admins"
    description = "Groupe PIM eligible pour le role SharePoint Administrator"
    mailEnabled = $false
    mailNickname = "pim-sp-admins"
    securityEnabled = $true
    isAssignableToRole = $true  # OBLIGATOIRE pour PIM
    "owners@odata.bind" = @(
        "https://graph.microsoft.com/v1.0/users/$ownerObjectId"
    )
}
New-MgGroup -BodyParameter $groupParams

# Attribuer le role SharePoint Admin a ce groupe (attribution active)
New-MgRoleManagementDirectoryRoleAssignment `
    -RoleDefinitionId $sharepointAdminRoleId `
    -PrincipalId $groupObjectId `
    -DirectoryScopeId "/"

# Les membres du groupe seront ensuite ajoutes en mode eligible via PIM
# L'activation de l'appartenance au groupe = activation du role SharePoint Admin

PIM pour les ressources Azure

Scopes et hierarchie Azure RBAC

PIM pour les ressources Azure applique le modele JIT aux roles Azure RBAC (Owner, Contributor, Reader, roles custom) a differents niveaux de la hierarchie : Management Group, Subscription, Resource Group, ou Ressource individuelle. Cette granularite permet d'implementer le principe de moindre privilege avec precision :

• Owner eligible sur une Subscription : active uniquement pour les operations critiques (modification des policies, suppression de ressources).
• Contributor eligible sur un Resource Group : active par les developpeurs pour deployer du code en production.
• Key Vault Administrator eligible : active uniquement pour la rotation des secrets, selon les principes decrits dans la gestion des credentials Kerberos en Active Directory.

Discovery et onboarding des ressources

La premiere etape du deployment PIM pour les ressources Azure consiste a effectuer un inventaire (discovery) des attributions RBAC existantes. Le portail PIM affiche automatiquement toutes les souscriptions auxquelles vous avez acces. Pour chaque souscription, vous pouvez visualiser les attributions permanentes actuelles et les convertir en attributions eligibles.

// KQL - Identifier toutes les attributions Owner permanentes sur les souscriptions
AzureActivity
| where OperationNameValue == "Microsoft.Authorization/roleAssignments/write"
| where Authorization_d.action == "Microsoft.Authorization/roleAssignments/write"
| extend RoleDefinitionName = tostring(Properties_d.roleDefinitionName)
| where RoleDefinitionName == "Owner"
| summarize Count=count() by Caller, SubscriptionId
| order by Count desc

Access Reviews : campagnes automatisees

Principe des Access Reviews

Les Access Reviews (revues d'acces) sont le complement indispensable de PIM. Elles permettent de verifier periodiquement que les attributions eligibles sont toujours justifiees. Sans revue reguliere, les attributions eligibles s'accumulent et recreent progressivement une surface d'attaque elargie.

PIM integre nativement les Access Reviews avec deux modes principaux :

• Self-review : l'utilisateur lui-meme confirme ou renonce a son attribution eligible. Ce mode convient pour les roles Standard ou l'utilisateur est le mieux place pour savoir s'il utilise encore le role.
• Manager review : le manager hierarchique de l'utilisateur valide ou revoque l'attribution. Ce mode est recommande pour les roles Eleves et Critiques.
• Group owner review : pour PIM pour les groupes, le proprietaire du groupe valide les membres eligibles.
• Designated reviewers : une equipe specifique (SOC, equipe IAM) revoit l'ensemble des attributions critiques.

Configuration d'une campagne d'Access Review

Creez des campagnes recurrentes pour automatiser le processus de revue. Voici les parametres recommandes par niveau de criticite :

Parametre	Roles Critiques	Roles Eleves	Roles Standard
Frequence	Mensuelle	Trimestrielle	Semestrielle
Reviewers	SOC + Manager	Manager	Self-review
Duree de la revue	7 jours	14 jours	21 jours
Action si pas de reponse	Revoquer	Revoquer	Conserver
Auto-apply results	Oui	Oui	Oui

Monitoring et alertes

Alertes PIM integrees

PIM dispose d'un systeme d'alertes integre qui detecte les configurations a risque et les comportements anormaux. Les alertes les plus importantes a surveiller :

• Roles being assigned outside of PIM : detecte les attributions de roles effectuees directement via l'interface IAM sans passer par PIM, ce qui contourne les controles.
• Too many permanent admins : alerte lorsque le nombre d'attributions permanentes depasse le seuil configure (recommandation : maximum 5).
• Roles don't require MFA : identifie les roles dont la configuration PIM n'exige pas le MFA a l'activation.
• Admins aren't using their privileged roles : signale les attributions eligibles non utilisees depuis un nombre configurable de jours.
• Potential stale accounts with privileged roles : identifie les comptes qui n'ont pas change leur mot de passe depuis une periode prolongee.

Requetes KQL pour Microsoft Sentinel

L'integration PIM avec Microsoft Sentinel permet de creer des regles analytiques avancees. Voici les requetes KQL essentielles pour le monitoring PIM :

// 1. Activations PIM en dehors des heures ouvrees (potentiel indicateur de compromission)
AuditLogs
| where OperationName == "Add member to role completed (PIM activation)"
| where TimeGenerated !between (datetime(06:00) .. datetime(20:00))
| extend ActivatedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend RoleName = tostring(TargetResources[0].displayName)
| project TimeGenerated, ActivatedBy, RoleName, Result
| order by TimeGenerated desc

// 2. Activations refusees (tentatives suspectes)
AuditLogs
| where OperationName == "Add member to role request denied (PIM activation)"
| extend RequestedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend RoleName = tostring(TargetResources[0].displayName)
| summarize DeniedCount=count() by RequestedBy, RoleName
| where DeniedCount > 3
| order by DeniedCount desc

// 3. Attributions permanentes hors PIM (contournement des controles)
AuditLogs
| where OperationName has "Add member to role"
| where OperationName !has "PIM"
| extend AddedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| extend RoleName = tostring(parse_json(tostring(TargetResources[0].modifiedProperties[1])).newValue)
| project TimeGenerated, AddedBy, TargetUser, RoleName

// 4. Volume d'activations par role (baseline comportementale)
AuditLogs
| where OperationName == "Add member to role completed (PIM activation)"
| extend RoleName = tostring(TargetResources[0].displayName)
| summarize ActivationCount=count() by RoleName, bin(TimeGenerated, 1d)
| render timechart

Workbooks Azure Monitor

Microsoft fournit un workbook PIM preconfigure dans Azure Monitor qui offre une vue consolidee des metriques cles : nombre d'activations par jour, ratio eligible/permanent, activations en attente d'approbation, et tendances sur 30/60/90 jours. Personnalisez ce workbook en ajoutant :

• Un widget montrant les activations par localisation geographique (detecte les activations depuis des pays inhabituels).
• Un graphique de correlation entre les activations PIM et les alertes Microsoft Defender for Identity.
• Un tableau des comptes eligibles n'ayant pas active leur role depuis plus de 60 jours.
• Un indicateur du nombre de comptes break-glass et la date de leur dernier test.

Bonnes pratiques et comptes break-glass

Les comptes break-glass : la securite de dernier recours

Les comptes break-glass (ou emergency access accounts) sont des comptes Global Administrator avec des attributions permanentes, exclus de PIM, des politiques Conditional Access et du MFA. Ils constituent le dernier recours en cas de panne majeure du systeme d'authentification (panne MFA, blocage PIM, compromission des comptes d'approbation).

// Alerte Sentinel : connexion reussie avec un compte break-glass
SigninLogs
| where UserPrincipalName in ("breakglass1@contoso.onmicrosoft.com", "breakglass2@contoso.onmicrosoft.com")
| where ResultType == 0  // Connexion reussie
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, DeviceDetail
// Severite : HAUTE - Declencher une notification immediate au RSSI

Checklist de deploiement PIM

Suivez cette checklist exhaustive pour un deploiement PIM reussi :

• Phase 1 - Preparation : inventorier tous les comptes privilegies permanents, classifier les roles par criticite, creer les comptes break-glass, valider les licences Entra ID P2.
• Phase 2 - Configuration : configurer les parametres PIM par role (activation, attribution, notification), definir les approbateurs, integrer avec l'ITSM, configurer les Conditional Access Policies associees.
• Phase 3 - Migration : convertir les attributions permanentes en attributions eligibles en commencant par les roles Standard, puis Eleves, puis Critiques. Communiquer proactivement avec les utilisateurs impactes.
• Phase 4 - Access Reviews : creer les campagnes recurrentes, configurer les decision helpers, definir les actions par defaut en cas de non-reponse.
• Phase 5 - Monitoring : deployer les requetes KQL dans Sentinel, creer les workbooks de suivi, configurer les alertes PIM integrees, tester les comptes break-glass.
• Phase 6 - Amelioration continue : revoir trimestriellement les metriques PIM, ajuster les durees d'activation selon l'usage reel, etendre PIM aux ressources Azure et aux groupes.

Integration avec le Zero Trust

PIM s'integre dans une architecture Zero Trust en tant que composant central du pilier Identity. Combinez PIM avec :

• Conditional Access : creez des politiques qui exigent un appareil conforme (Intune) et une localisation reseau connue pour les activations de roles critiques.
• Continuous Access Evaluation (CAE) : revoque les tokens en quasi-temps reel si les conditions changent pendant une session PIM active.
• Microsoft Defender for Identity : correle les activations PIM avec les alertes de comportement suspect dans Active Directory on-premises.
• Entra ID Protection : bloque les activations PIM si le risque utilisateur est eleve (sign-in risk ou user risk).

Conclusion

Privileged Identity Management dans Entra ID transforme fondamentalement la gestion des acces privilegies en remplacant le modele statique des permissions permanentes par un modele dynamique just-in-time. Les benefices sont quantifiables : reduction de 64 % des incidents lies aux comptes privilegies, conformite facilitee avec ISO 27001 et NIS 2, et tracabilite complete de chaque elevation de privilege.

La cle du succes reside dans une approche progressive : commencez par les roles les plus critiques (Global Administrator), etendez ensuite aux roles administratifs courants, puis deployez PIM pour les groupes et les ressources Azure. Combinez systematiquement PIM avec des Access Reviews automatisees pour eviter l'accumulation de privileges inutiles au fil du temps.

N'oubliez pas les comptes break-glass : ils constituent votre filet de securite en cas de defaillance du systeme PIM lui-meme. Testez-les regulierement, surveillez-les en permanence, et documentez leur procedure d'utilisation dans votre plan de continuite.

En combinant PIM avec Conditional Access, Continuous Access Evaluation et Microsoft Defender for Identity, vous construisez une architecture Zero Trust robuste ou chaque privilege est justifie, approuve, limite dans le temps et audite. C'est la fondation d'une posture de securite mature face aux menaces actuelles.

Articles complementaires