Définir une stratégie d’accès privilégié pour les utilisateurs administratifs

• 10 minutes

Qu’est-ce que Privileged Identity Management (PIM) ?

PIM est un service dans Microsoft Entra ID qui permet de gérer l’accès aux ressources privilégiées. PIM vous permet de gérer, contrôler et surveiller l’accès aux ressources importantes dans votre organisation. Ces ressources incluent celles qui existent dans Microsoft Entra ID, dans Azure et dans d’autres services Microsoft Online, comme Microsoft 365 ou Microsoft Intune.

Que fait PIM ?

PIM fournit une activation de rôle basée sur le temps et l’approbation pour accéder aux ressources. Cela permet d’atténuer les risques d’autorisations d’accès excessives, inutiles ou inutilisées sur les ressources qui vous intéressent. Les principales fonctionnalités de PMI sont les suivantes :

• Fournir un accès privilégié juste-à-temps à Microsoft Entra ID et aux ressources Azure
• Affecter un accès aux ressources limité dans le temps à l’aide de dates de début et de fin
• Exiger une approbation pour activer les rôles privilégiés
• Appliquer l’authentification multifacteur Azure pour activer des rôles
• Utiliser la justification pour comprendre le motif d’activation des utilisateurs
• Recevoir des notifications lors de l’activation de rôles privilégiés
• Effectuer des révisions d’accès pour vérifier que les utilisateurs ont toujours besoin de leurs rôles
• Télécharger l’historique des audits (internes ou externes)

Avant de déployer PIM dans votre organisation, suivez les instructions et comprenez les concepts de cette section. Cela vous aidera à créer un plan adapté aux exigences de votre organisation en matière d’identité privilégiée.

Identifier les participants

La section suivante vous aide à identifier toutes les parties prenantes impliquées dans le projet. Vous regardez qui a besoin d’approuver, de réviser ou de rester informé. Elle inclut des tableaux distincts pour le déploiement de PIM pour les rôles Microsoft Entra et pour les rôles Azure. Ajoutez des participants au tableau suivant en fonction de votre organisation.

SO = approbation sur ce projet

R = Réviser ce projet et fournir une entrée

I = Se tenir informé de ce projet

Parties prenantes : Privileged Identity Management pour les rôles Microsoft Entra

Nom	Rôle	Action
Nom et e-mail	Architecte d’identité ou Administrateur général Azure - Représentant de l’équipe de gestion des identités chargé de définir l’alignement de ce changement avec l’infrastructure de gestion des identités de base de votre organisation.	SO/R/I
Nom et e-mail	Directeur du service ou Propriétaire du service - Représentant des propriétaires dans le service informatique d’un service ou d’un groupe de services. Ils sont essentiels à la prise de décisions et au déploiement de PIM pour leur équipe.	SO/R/I
Nom et e-mail	Propriétaire de la sécurité - Représentant de l’équipe de sécurité qui peut confirmer que le plan répond aux exigences de sécurité de votre organisation.	SO/R
Nom et e-mail	Responsable du support informatique/support technique - Représentant de l’organisation du support informatique qui peut fournir des commentaires sur la prise en charge de ce changement du point de vue du support technique.	R/I
Nom et e-mail des utilisateurs pilotes	Utilisateurs de rôle privilégié - Groupe d’utilisateurs pour qui la gestion des identités privilégiées est implémentée. Ils devront savoir comment activer leurs rôles une fois Privileged Identity Management implémenté.	I

Participants : Privileged Identity Management pour les rôles Azure

Nom	Rôle	Action
Nom et e-mail	Propriétaire d’abonnement/de ressource - Représentant des propriétaires dans le service informatique de chaque abonnement ou ressource pour lesquels vous voulez déployer PIM.	SO/R/I
Nom et e-mail	Propriétaire de la sécurité - Représentant de l’équipe de sécurité pouvant confirmer que le plan répond aux exigences de sécurité de votre organisation.	SO/R
Nom et e-mail	Responsable du support informatique/support technique - Représentant de l’organisation du support informatique qui peut fournir des commentaires sur la prise en charge de ce changement du point de vue du support technique.	R/I
Nom et e-mail des utilisateurs pilotes	Utilisateurs de rôle Azure - Groupe d’utilisateurs pour qui la gestion des identités privilégiées est implémentée. Ils devront savoir comment activer leurs rôles une fois Privileged Identity Management implémenté.	I

Commencer à utiliser Privileged Identity Management

Dans le cadre du processus de planification, vous devez préparer Privileged Identity Management en suivant notre article « Commencer à utiliser Privileged Identity Management ». L’activation de PIM vous donne accès à certaines fonctionnalités qui sont spécifiquement conçues pour faciliter votre déploiement.

Si votre objectif est de déployer Privileged Identity Management pour les ressources Azure, consultez notre article «  Découvrir des ressources Azure à gérer dans Privileged Identity Management ». Seuls les propriétaires d’abonnements et de groupes d’administration peuvent placer ces ressources sous la gestion de Privileged Identity Management. Une fois sous gestion, la fonctionnalité PIM est accessible aux propriétaires à tous les niveaux, y compris le groupe d’administration, l’abonnement, le groupe de ressources et la ressource. Si vous êtes Administrateur général et que vous essayez de déployer PIM pour vos ressources Azure, vous pouvez élever l’accès afin de gérer tous les abonnements Azure pour vous accorder l’accès à toutes les ressources Azure dans l’annuaire pour la découverte. Toutefois, il est conseillé d’obtenir l’approbation de chacun des propriétaires d’abonnements avant de gérer leurs ressources avec PIM.

Appliquer le principe des privilèges minimum

Il est important de vérifier que vous avez appliqué le principe du privilège minimum dans votre organisation, à la fois pour vos rôles Microsoft Entra et pour vos rôles Azure.

Planifier la délégation du privilège minimum

Pour les rôles Microsoft Entra, il est courant pour les organisations d’attribuer le rôle Administrateur général à un certain nombre d’administrateurs alors que la plupart d’entre eux n’ont besoin que d’un ou deux rôles d’administrateur spécifiques et moins puissants. Avec un grand nombre d’administrateurs généraux ou d’autres rôles à privilèges élevés, il est difficile de suivre de suffisamment près les attributions de rôles privilégiés.

Suivez ces étapes pour implémenter le principe du privilège minimum pour vos rôles Microsoft Entra.

1. Appréhendez la granularité des rôles en lisant et en comprenant bien les rôles d’administrateur Microsoft Entra disponibles. Vous et votre équipe devez également faire référence aux rôles d’administrateur par tâche d’identité dans Microsoft Entra ID, qui explique le rôle le moins privilégié pour des tâches spécifiques.

2. Listez les utilisateurs avec des rôles privilégiés dans votre organisation. Vous pouvez utiliser la découverte et les Insights PIM (version préliminaire) pour réduire votre exposition.

   

3. Pour tous les administrateurs généraux dans votre organisation, découvrez pourquoi ils ont besoin du rôle. Ensuite, supprimez-les du rôle Administrateur général, et attribuez-leur des rôles intégrés ou des rôles personnalisés avec un moindre privilège dans Microsoft Entra ID. Pour information, Microsoft ne compte actuellement qu’une dizaine d’administrateurs ayant le rôle Administrateur général.

4. Pour tous les autres rôles Microsoft Entra, passez en revue la liste des attributions, identifiez les administrateurs qui n’ont plus besoin du rôle et supprimez-les de leurs attributions.

Pour automatiser les deux dernières étapes, vous pouvez utiliser des révisions d’accès dans PIM. En suivant les étapes de « Démarrer une révision d’accès des rôles Microsoft Entra dans Privileged Identity Management », vous pouvez configurer une révision d’accès pour chaque rôle Microsoft Entra ID qui a un ou plusieurs membres.

Définissez les réviseurs sur Membres (auto) . Tous les utilisateurs du rôle recevront un e-mail leur demandant de confirmer qu’ils ont besoin de l’accès. Par ailleurs, activez l’option Exiger la raison lors de l’approbation dans les paramètres avancés afin que les utilisateurs puissent indiquer pourquoi ils ont besoin du rôle. En fonction de ces informations, vous pourrez supprimer des utilisateurs des rôles inutiles ou les déléguer à des rôles d’administrateur plus granulaires.

Les révisions d’accès s’appuient sur les e-mails pour demander aux utilisateurs de revoir leur accès aux rôles. Si vous avez des comptes privilégiés sans e-mail associé, veillez à renseigner le champ d’e-mail secondaire pour ces comptes.

Planifier la délégation du rôle de ressource Azure

Pour les abonnements et les ressources Azure, vous pouvez configurer un processus de révision d’accès similaire pour passer en revue les rôles dans chaque abonnement ou ressource. L’objectif de ce processus consiste à réduire les attributions de rôles Propriétaire et Administrateur de l’accès utilisateur attachées à chaque abonnement ou ressource et à supprimer les attributions inutiles. Toutefois, les organisations délèguent souvent de telles tâches au propriétaire de chaque abonnement ou ressource, car il a une meilleure compréhension des rôles spécifiques (en particulier, des rôles personnalisés).

Si vous avez le rôle Administrateur général et que vous tentez de déployer PIM pour les rôles Azure dans votre organisation, vous pouvez élever l’accès afin de gérer tous les abonnements Azure pour accéder à chaque abonnement. Vous pouvez ensuite rechercher le propriétaire de chaque abonnement et travailler avec lui pour supprimer les affectations inutiles et réduire l’affectation de rôle Propriétaire.

Les utilisateurs avec le rôle Propriétaire pour un abonnement Azure peuvent également utiliser des révisions d’accès pour les ressources Azure afin d’auditer et de supprimer des attributions de rôles non nécessaires, comme dans le processus décrit précédemment pour les rôles Microsoft Entra.

Identifier les attributions de rôle qui doivent être protégées par Privileged Identity Management

Après le nettoyage des attributions de rôle privilégié dans votre organisation, vous devez choisir les rôles à protéger avec Privileged Identity Management.

Si un rôle est protégé par PIM, les utilisateurs éligibles qui lui sont affectés doivent s’élever pour utiliser les privilèges octroyés par le rôle. Le processus d’élévation peut également inclure l’obtention de l’approbation, l’utilisation de l’authentification multifacteur Azure et l’indication d’un motif d’activation. PIM permet également de suivre les élévations via des notifications ainsi que les journaux des événements d’audit PIM et Microsoft Entra.

Le choix des rôles à protéger avec PIM peut être difficile et sera différent pour chaque organisation. Cette section contient nos meilleures pratiques pour les rôles Microsoft Entra et Azure.

Rôles Microsoft Entra

Il est important de donner la priorité à la protection des rôles Microsoft Entra qui ont le plus d’autorisations. Selon les modèles d’utilisation parmi tous les clients PIM, les 10 rôles principaux Microsoft Entra gérés par PIM sont :

• Administrateur général

• Security Administrator

• Administrateur d'utilisateurs

• Administrateur Exchange

• Administrateur SharePoint

• Administrateur Intune

• Lecteur de sécurité

• Administrateur de services

• Administrateur de facturation

• Administrateur Skype Entreprise

  Conseil

  Microsoft recommande de gérer tous les rôles Administrateur général et Administrateur de la sécurité à l’aide de Privileged Identity Management dans un premier temps, car il s’agit des utilisateurs qui peuvent être les plus nuisibles quand ils sont compromis.

Il est important de prendre en compte les données et les autorisations les plus sensibles pour votre organisation. Par exemple, certaines organisations souhaitent protéger leurs rôles Administrateur Power BI ou Administrateur Teams avec PIM, car ils peuvent accéder aux données et modifier les workflows de base.

Si des rôles sont attribués à des utilisateurs invités, ils sont vulnérables aux attaques.

Les rôles de lecteur comme Lecteur de répertoire, Lecteur du Centre de messages et Lecteur de sécurité sont parfois considérés comme étant moins importants que d’autres rôles parce qu’ils n’ont pas d’autorisation d’écriture. Cependant, certains de nos clients protègent également ces rôles, car les attaquants ayant accès à ces comptes pourraient être en mesure de lire des données sensibles, telles que des données personnelles. Prenez ce risque en considération quand vous décidez si les rôles de lecteur de votre organisation doivent être gérés à l’aide de Privileged Identity Management.

Rôles Azure

Quand vous choisissez les attributions de rôle qui doivent être managées à l’aide de Privileged Identity Management pour les ressources Azure, vous devez tout d’abord identifier les abonnements/ressources qui sont essentiels pour votre organisation. Des exemples de ces abonnements/ressources sont :

• Ressources qui hébergent les données les plus sensibles.
• Ressources desquelles dépendent les applications orientées client de base.

Si vous êtes un administrateur général qui éprouve des difficultés à décider quels abonnements et quelles ressources sont les plus importants, nous vous conseillons de contacter les propriétaires d’abonnements de votre organisation pour dresser la liste des ressources gérées par chaque abonnement. Ensuite, collaborez avec les propriétaires d’abonnements pour regrouper les ressources en fonction du niveau de gravité (bas, moyen, élevé) en cas de compromission. Classez par ordre de priorité la gestion des ressources avec Privileged Identity Management en fonction de ce niveau de gravité.

PIM pour les ressources Azure prend en charge les comptes de service associés à un délai. Vous devez traiter les comptes de service exactement comme un compte d’utilisateur normal.

Pour les abonnements/ressources qui ne sont pas aussi critiques, vous n’avez pas besoin de configurer PIM pour tous les rôles. Toutefois, vous devez toujours protéger les rôles Propriétaire et Administrateur de l’accès utilisateur avec PIM.

Décider s’il faut utiliser un groupe pour attribuer des rôles

L’attribution d’un rôle à un groupe plutôt qu’à des utilisateurs individuels est une décision stratégique. Lors de la planification, envisagez d’attribuer un rôle à un groupe pour gérer les attributions de rôles dans les cas suivants :

• De nombreux utilisateurs sont affectés à un rôle.
• Vous voulez déléguer l’attribution du rôle.

De nombreux utilisateurs sont affectés à un rôle

Le suivi des personnes qui sont affectées à un rôle et la gestion de leurs affectations en fonction du moment où elles en ont besoin peut prendre du temps lorsqu’ils sont effectués manuellement. Pour affecter un groupe à un rôle, vous devez d’abord créer un groupe assignable à un rôle puis rendre le groupe éligible à un rôle. Cette action soumet tous les membres du groupe au même processus d’activation que les utilisateurs individuels qui sont éligibles pour s’élever dans ce rôle. Les membres du groupe activent leurs affectations au groupe individuellement à l’aide de la requête d’activation et du processus d’approbation Privileged Identity Management. Le groupe n’est pas activé, seulement l’appartenance au groupe de l’utilisateur.

Vous voulez déléguer l’attribution du rôle

Un propriétaire de groupe peut gérer l’appartenance à un groupe. Pour les groupes auxquels un rôle Microsoft Entra ID peut être attribué, seuls l’administrateur de rôle privilégié, l’administrateur général et les propriétaires de groupes peuvent gérer l’appartenance à un groupe. Quand un administrateur ajoute de nouveaux membres au groupe, le membre obtient l’accès aux rôles attribués au groupe, que l’attribution soit éligible ou active. Utilisez les propriétaires de groupe pour déléguer la gestion de l’appartenance à un groupe pour un rôle attribué afin de réduire l’étendue des privilèges requis.

Identifier les affectations de rôles qui doivent être permanentes ou éligibles

Une fois que vous avez dressé la liste des rôles gérés par PIM, vous devez choisir les utilisateurs qui ont le rôle éligible et ceux qui ont le rôle actif en permanence. Les rôles actifs en permanence sont les rôles normaux attribués via des ressources Microsoft Entra ID et Azure, tandis que les rôles éligibles peuvent être attribués seulement dans PIM.

Microsoft vous recommande de ne pas avoir d’attributions actives en permanence pour les rôles Microsoft Entra et les rôles Azure autres que les deux comptes d’accès d’urgence recommandés, qui doivent avoir le rôle permanent Administrateur général.

Même si nous recommandons de n’avoir aucun administrateur permanent, il est parfois difficile pour les organisations d’atteindre immédiatement cet objectif. Voici quelques points à prendre en compte lorsque vous prenez cette décision :

• Fréquence d’élévation : si l’utilisateur n’a besoin de l’affectation de rôle privilégié qu’une seule fois, l’affectation ne doit pas être permanente. En revanche, si l’utilisateur a besoin du rôle pour ses tâches quotidiennes et si l’utilisation de PIM réduit considérablement sa productivité, le rôle permanent peut être envisagé.

• Cas spécifiques à votre organisation : si la personne qui reçoit le rôle éligible fait partie d’une équipe distante ou est un cadre de haut rang au point que la communication et l’application du processus d’élévation s’avèrent difficiles, le rôle permanent peut être envisagé.

  Conseil

  Microsoft vous recommande de configurer des révisions d’accès récurrentes pour les utilisateurs qui ont des attributions de rôle permanentes.

Composer vos paramètres Privileged Identity Management

Avant d’implémenter votre solution PIM, une bonne pratique est de définir vos paramètres PIM pour chaque rôle privilégié utilisé par votre organisation. Cette section contient des exemples de paramètres Privileged Identity Management pour des rôles particuliers (ils sont indiqués uniquement pour référence et peuvent être différents pour votre organisation). Chacun de ces paramètres est expliqué en détail avec des recommandations de Microsoft après les tableaux.

Paramètres Privileged Identity Management pour les rôles Microsoft Entra

Paramètre	Administrateur général	Administrateur Exchange	Administrateur du support technique
Exiger l’authentification multifacteur ; vérification en deux étapes	Oui	Oui	Non
Notification	Oui	Oui	Non
Ticket d’incident	Oui	No	Oui
Exiger une approbation	Oui	No	Non
Approbateur	Autres administrateurs généraux	None	None
Durée d’activation	1 heure	2 heures	8 heures
Administrateur permanent	Comptes d’accès d’urgence	None	None

Paramètres Privileged Identity Management pour les rôles Azure

Paramètre	Propriétaire d’abonnements critiques	Administrateur de l’accès utilisateur d’abonnements moins critiques	Contributeur de machine virtuelle
Exiger l’authentification multifacteur ; vérification en deux étapes	Oui	Oui	Non
Notification	Oui	Oui	Oui
Exiger une approbation	Oui	No	Non
Approbateur	Autres propriétaires de l’abonnement	None	None
Durée d’activation	1 heure	1 heure	3 heures
Administrateur actif	None	None	None
Expiration active	n/a	n/a	n/a

Le tableau suivant décrit chacun des paramètres.

Paramètre	Description
Rôle	Nom du rôle pour lequel vous définissez les paramètres.
Exiger l’authentification multifacteur ; vérification en deux étapes	Si l’utilisateur éligible doit effectuer une authentification multifacteur ; vérification en deux étapes avant d’activer le rôle.
	Microsoft vous recommande d’appliquer l’authentification multifacteur ; vérification en deux étapes pour tous les rôles d’administrateur, en particulier si les rôles ont des utilisateurs invités.
Notification	Si la valeur est true, les rôles Administrateur général, Administrateur de rôle privilégié et Administrateur de la sécurité de l’organisation reçoivent une notification par e-mail quand un utilisateur éligible active le rôle.
	Certaines organisations n’ont pas d’adresse de messagerie liée à leurs comptes d’administrateur. Pour recevoir ces notifications par e-mail, définissez une adresse e-mail alternative afin que les administrateurs puissent recevoir ces e-mails.
Ticket d’incident	Indique si l’utilisateur éligible doit enregistrer un numéro de ticket d’incident lors de l’activation de son rôle. Ce paramètre permet à une organisation d’identifier chaque activation avec un numéro d’incident interne pour atténuer les activations indésirables.
	Microsoft recommande de tirer parti des numéros de ticket d’incident pour lier PIM à votre système interne. Cette méthode peut être utile pour les approbateurs qui ont besoin de contexte pour l’activation.
Exiger une approbation	Indique si l’utilisateur éligible doit obtenir une approbation pour activer le rôle.
	Microsoft recommande de configurer l’approbation pour les rôles avec le plus d’autorisations. En fonction des modèles d’utilisation de tous les clients PIM, les rôles Administrateur général, Administrateur des utilisateurs, Administrateur Exchange, Administrateur de la sécurité et Administrateur des mots de passe sont les rôles les plus courants pour lesquels une approbation est nécessaire.
Approbateur	Si l’approbation est nécessaire pour activer le rôle éligible, liste les personnes qui doivent approuver la requête. Par défaut, PIM définit comme approbateur tous les utilisateurs qui sont des administrateurs de rôles privilégiés, qu’ils soient permanents ou éligibles.
	Si un utilisateur est éligible à la fois pour un rôle Microsoft Entra et pour un approbateur du rôle, il ne sera pas en mesure de s’approuver lui-même.
	Microsoft recommande de choisir comme approbateurs les utilisateurs qui sont les plus compétents quant au rôle et ses utilisateurs fréquents plutôt qu’un administrateur général.
Durée d’activation	Durée pendant laquelle un utilisateur est activé dans le rôle avant l’expiration.
Administrateur permanent	Liste des utilisateurs qui seront un administrateur permanent pour le rôle (activation jamais nécessaire).
	Microsoft recommande de n’avoir aucun administrateur permanent pour tous les rôles à l’exception des administrateurs généraux.
Administrateur actif	Pour les ressources Azure, un administrateur actif correspond à la liste des utilisateurs qui n’ont jamais besoin d’activation pour utiliser le rôle. Cette liste n’est pas considérée comme un administrateur permanent comme dans les rôles Microsoft Entra, car vous pouvez définir une date/heure d’expiration à laquelle l’utilisateur perdra ce rôle.
Expiration active	Les attributions de rôles actives pour les rôles Azure expirent après la durée configurée. Vous pouvez choisir entre 15 jours, 1 mois, 3 mois, 6 mois, 1 an, ou un rôle actif en permanence.
Expiration éligible	Les attributions de rôles éligibles pour les rôles Azure expirent après cette durée. Vous pouvez choisir entre 15 jours, 1 mois, 3 mois, 6 mois, 1 an, ou un rôle actif en permanence.