Configurer les paramètres des rôles Azure AD dans Privileged Identity Management
Dans Privileged Identity Management (PIM) au sein de Azure Active Directory (Azure AD), faisant partie de Microsoft Entra, paramètres de rôle définissant les propriétés d’attribution de rôle : exigences d’authentification multi-facteur et d’approbation, durée maximale d’assignation, paramètres de notifications et plus. Les étapes suivantes permettent de configurer les paramètres de rôle et de définir le flux d’approbation afin de spécifier qui peut approuver ou refuser les requêtes d’élévation des privilèges.
Vous devez avoir le rôle Administrateur général ou Administrateur de rôle privilégié pour gérer les paramètres de rôle PIM pour le rôle Azure AD. Les paramètres de rôle sont définis par rôle : toutes les attributions du même rôle suivent les mêmes paramètres de rôle. Les paramètres d’un rôle sont indépendants des paramètres d’un autre rôle.
Les paramètres de rôle PIM sont également appelés « stratégies PIM ».
Ouvrir les paramètres de rôle
Suivez ces étapes pour ouvrir les paramètres d’un rôle Azure AD.
Sélectionnez Azure AD Privileged Identity Management -> Rôles Azure AD -> Rôles. Cette page affiche la liste des rôles Azure AD disponibles dans le tenant (abonné/locataire), y compris les rôles intégrés et personnalisés.
Sélectionnez le rôle dont vous souhaitez configurer les paramètres.
Sélectionnez Paramètres du rôle. Dans la page Paramètres du rôle, vous pouvez afficher les paramètres de rôle PIM actuels pour le rôle sélectionné.
Sélectionnez Modifier pour mettre à jour les paramètres de rôle.
Une fois que vous avez terminé, sélectionnez Mettre à jour.
Paramètres de rôle
Durée maximum d’activation
Utilisez le curseur Durée maximale d’activation pour définir la durée maximale, en heures, pendant laquelle une demande d’activation pour une attribution de rôle reste active avant d’expirer. Cette valeur peut être comprise entre 1 et 24 heures.
Lors de l’activation, exiger l’authentification multifacteur
Vous pouvez exiger des utilisateurs éligibles à un rôle qu'ils s'authentifient à l'aide d'Azure AD Multi-Factor Authentication pour effectuer l'activation. L’authentification multifacteur permet de protéger l’accès aux données et aux applications, en offrant une couche de sécurité supplémentaire grâce à l’utilisation d’une seconde méthode d’authentification.
Notes
S’il s’est déjà authentifié à l’aide d’informations d’identification fortes ou d’une authentification multifacteur plus tôt au cours de la session, l’utilisateur ne devrait pas être invité à s’authentifier une nouvelle fois via une authentification multifacteur. Si votre objectif est de vous assurer que les utilisateurs fournissent une authentification lors de l’activation, vous pouvez utiliser le paramètre Lors de l’activation, exiger le contexte d’authentification d’accès conditionnel Azure AD avec Points forts d’authentification pour exiger que les utilisateurs s’authentifient pendant l’activation à l’aide de méthodes différentes de celle qu’ils ont utilisée pour se connecter à l’ordinateur. Par exemple, si les utilisateurs se connectent à l’ordinateur à l’aide de Windows Hello Entreprise, vous pouvez utiliser « Lors de l’activation, exiger le contexte d’authentification d’accès conditionnel Azure AD » et « Points forts d’authentification » pour exiger que les utilisateurs se connectent sans mot de passe avec Microsoft Authenticator lorsqu’ils activent le rôle. Dans cet exemple, une fois que l’utilisateur a procédé à une connexion sans mot de passe avec Microsoft Authenticator, il pourra effectuer sa prochaine activation dans cette session sans authentification supplémentaire, car la connexion sans mot de passe avec Microsoft Authenticator sera déjà incluse dans son jeton.
Il est recommandé d’activer l’authentification multifacteur Azure AD pour tous les utilisateurs. Pour plus d’informations, consultez Planifier un déploiement de l’authentification multifacteur Azure Active Directory.
Lors de l’activation, exiger le contexte d’authentification d’accès conditionnel Azure AD (préversion publique)
Vous pouvez exiger que les utilisateurs éligibles à un rôle respectent les exigences de stratégie d’accès conditionnel (utiliser une méthode d’authentification spécifique appliquée via la fonctionnalité Points forts d’authentification, élever le rôle depuis un appareil conforme à Intune, se conformer aux conditions d’utilisation, et bien plus encore).
Pour appliquer cette exigence, procédez comme suit :
Créez un contexte d’authentification par accès conditionnel.
Configurez la stratégie d’accès conditionnel qui applique les exigences pour ce contexte d’authentification.
Notes
L’étendue de la stratégie d’accès conditionnel doit inclure tous les utilisateurs ou éligibles pour un rôle. Ne créez pas de stratégie d’accès conditionnel limitée au contexte d’authentification et au rôle d’annuaire en même temps, car pendant l’activation, l’utilisateur n’a pas encore de rôle et la stratégie d’accès conditionnel ne s’applique pas. Consultez la remarque à la fin de cette section concernant une situation dans laquelle vous pouvez avoir besoin de deux stratégies d’accès conditionnel, l’une limitée au contexte d’authentification et l’autre au rôle.
Configurez le contexte d’authentification dans les paramètres PIM pour le rôle.
Notes
Si les paramètres PIM (Privileged Identity Management) sont configurés avec l’option « Lors de l’activation, exiger le contexte d’authentification d’accès conditionnel Azure AD », les stratégies d’accès conditionnel définissent les conditions qu’un utilisateur doit remplir pour répondre aux exigences d’accès. Cela signifie que les responsables de la sécurité qui disposent d’autorisations pour gérer les stratégies d’accès conditionnel, tels que les administrateurs de l’accès conditionnel ou les administrateurs de sécurité, peuvent modifier les exigences, les supprimer ou empêcher les utilisateurs éligibles d’activer le rôle. Les responsables de la sécurité qui peuvent gérer les stratégies d’accès conditionnel doivent être considérés comme hautement privilégiés et donc être protégés en conséquence.
Notes
Nous vous recommandons de créer et d’activer une stratégie d’accès conditionnel pour le contexte d’authentification avant que le contexte d’authentification ne soit configuré dans les paramètres PIM. En tant que mécanisme de protection de secours et dans le cas où il n’y a pas de stratégies d’accès conditionnel dans le client qui cible le contexte d’authentification configuré dans les paramètres PIM, lors de l’activation du rôle PIM, l’authentification multifacteur Azure AD est requise, car le paramètre Lors de l’activation, exiger l’authentification multifacteur est défini. Ce mécanisme de protection de secours est conçu pour vous protéger uniquement dans le cas d’un scénario où les paramètres PIM ont été mis à jour avant la création de la stratégie d’accès conditionnel, à la suite d’une erreur de configuration. Ce mécanisme de protection de secours ne sera pas déclenché si la stratégie d’accès conditionnel est désactivée, en mode rapport uniquement, ou si un utilisateur éligible est exclu de la stratégie.
Notes
Le paramètre « Lors de l’activation, exiger le contexte d’authentification d’accès conditionnel Azure AD » définit le contexte d’authentification, conditions que l’utilisateur doit satisfaire lorsqu’il active le rôle. Une fois le rôle activé, cela n’empêche pas les utilisateurs d’utiliser une autre session de navigation, appareil, emplacement, etc. pour utiliser des autorisations. Par exemple, les utilisateurs peuvent utiliser un appareil conforme à Intune pour activer le rôle, puis, une fois le rôle activé, se connecter au même compte d’utilisateur à partir d’un autre appareil qui n’est pas conforme à Intune, et y utiliser le rôle précédemment activé. Pour vous protéger contre cette situation, créez deux stratégies d’accès conditionnel :
- Première stratégie d’accès conditionnel ciblant le contexte d’authentification. Il doit avoir « Tous les utilisateurs » ou les utilisateurs éligibles dans son étendue. Cette stratégie spécifie les exigences que l’utilisateur doit respecter pour activer le rôle.
- Deuxième stratégie d’accès conditionnel ciblant les rôles d’annuaire. Cette stratégie spécifie les exigences que les utilisateurs doivent respecter pour se connecter avec le rôle d’annuaire activé.
Les deux stratégies peuvent appliquer des exigences identiques ou différentes en fonction de vos besoins.
Une autre option consiste à étendre les stratégies d’accès conditionnel qui appliquent directement certaines exigences aux utilisateurs éligibles. Par exemple, vous pouvez exiger que les utilisateurs éligibles à certains rôles utilisent toujours des appareils conformes à Intune.
Pour en savoir plus sur le contexte d’authentification de l’accès conditionnel, consultez Accès conditionnel : applications cloud, actions et contexte d’authentification.
Demander une justification lors de l’activation
Vous pouvez exiger que les utilisateurs saisissent une justification métier lorsqu’ils activent l’affectation éligible.
Exiger des informations sur le ticket lors de l’activation
Vous pouvez exiger que les utilisateurs entrent un ticket de support lorsqu’ils activent l’affectation éligible. Il s’agit d’un champ uniquement informatif. La corrélation avec les informations dans un système de gestion de tickets n’est pas appliquée.
Demander une approbation pour activation
Vous pouvez exiger une approbation pour l’activation de l’affectation éligible. L’approbateur n’a pas besoin d’avoir de rôles. Lorsque vous utilisez cette option, vous devez sélectionner au moins un approbateur (nous vous recommandons de sélectionner au moins deux approbateurs). Il n’existe aucun approbateur par défaut.
Si vous souhaitez en savoir plus sur les approbations, veuillez consulter la rubrique Approuver ou rejeter des requêtes de rôles Azure AD dans Privileged Identity Management.
Durée de l’attribution
Vous pouvez choisir entre deux options de durée d’attribution pour chaque type d’attribution (éligible et actif) lorsque vous configurez les paramètres d’un rôle. Ces options deviennent la durée maximale par défaut lorsqu’un utilisateur est attribué au rôle dans Privileged Identity Management.
Vous pouvez choisir l’une de ces options de durée d’attribution éligible :
| Paramètre | Description |
|---|---|
| Autoriser une attribution éligible permanente | Les administrateurs de ressources peuvent accorder une attribution éligible permanente. |
| Faire expirer les attributions éligibles après | Les administrateurs de ressources peuvent exiger que toutes les attributions éligibles aient une date de début et une date de fin spécifiées. |
Vous pouvez choisir l’une de ces options de durée d’attribution active :
| Paramètre | Description |
|---|---|
| Autoriser une attribution active permanente | Les administrateurs de ressources peuvent accorder une attribution active permanente. |
| Faire expirer les attributions actives après | Les administrateurs de ressources peuvent exiger que toutes les attributions actives aient une date de début et une date de fin spécifiées. |
Notes
Toutes les attributions qui ont une date de fin spécifiée peuvent être renouvelées par les Administrateurs généraux et les Administrateurs de rôle privilégié. De plus, les utilisateurs peuvent lancer des demandes en libre-service afin d’étendre ou renouveler des attributions de rôles.
Exiger Azure Multi-Factor Authentication lors de l’attribution active
Vous pouvez exiger que l’administrateur fournisse une authentification multifacteur lorsqu’il crée une affectation active (par opposition à éligible). Privileged Identity Management ne peut pas appliquer l’authentification multifacteur lorsque l’utilisateur utilise son attribution de rôle, car il est déjà actif dans le rôle depuis l’attribution.
L’administrateur peut ne pas être invité à effectuer l’authentification multifacteur s’il s’est authentifié avec des informations d’identification fortes ou s’il a fourni une authentification multifacteur plus tôt dans cette session.
Demander une justification lors de l’affectation active
Vous pouvez exiger que les utilisateurs entrent une justification métier lorsqu’ils créent une affectation active (par opposition à éligible).
Sous l’onglet Notifications dans la page des paramètres de rôle, l’option Privileged Identity Management permet de contrôler précisément qui reçoit telle notification.
- Désactivation d’un e-mail Vous pouvez désactiver certains e-mails en décochant la case du destinataire par défaut et en supprimant les éventuels autres destinataires.
- Limiter les e-mails à des adresses e-mail spécifiées Vous pouvez désactiver les e-mails envoyés aux destinataires par défaut en décochant la case du destinataire par défaut. Vous pouvez ensuite ajouter d’autres adresses e-mail en tant que destinataires. Si vous souhaitez ajouter plusieurs adresses e-mail, séparez-les par un point-virgule (;).
- Envoyer des e-mails à la fois aux destinataires par défaut et à plus de destinataires Vous pouvez envoyer des e-mails à la fois à des destinataires par défaut et à d’autres destinataires en cochant la case du destinataire par défaut et en ajoutant les adresses e-mail des autres destinataires.
- E-mails critiques uniquement Pour chaque type d’e-mail, vous pouvez cocher la case pour recevoir uniquement les e-mails critiques. Cela signifie que Privileged Identity Management continuera d’envoyer des e-mails aux destinataires spécifiés uniquement lorsqu’une action immédiate est requise. Par exemple, les e-mails qui demandent à l’utilisateur d’étendre son attribution de rôle ne seront pas déclenchés, tandis que ceux qui demandent à des administrateurs d’approuver une requête d’extension seront déclenchés.
Gérer les paramètres de rôle via Microsoft Graph
Pour gérer les paramètres des rôles Azure AD via Microsoft Graph, utilisez le type de ressource UnifiedRoleManagementPolicy et les méthodes associées.
Dans Microsoft Graph, les paramètres de rôle sont appelés règles et sont affectés aux rôles Azure AD par le biais de stratégies de conteneur. Chaque rôle Azure AD se voit recevoir un objet de stratégie spécifique. Vous pouvez récupérer toutes les stratégies qui sont étendues aux rôles Azure AD et pour chaque stratégie, récupérer la collection de règles associée par le biais d’un paramètre de requête $expand. La syntaxe de la requête est la suivante :
GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'&$expand=rules
Les règles sont regroupées en conteneurs. Les conteneurs sont ensuite divisés en définitions de règles identifiées par des ID uniques pour faciliter la gestion. Par exemple, un conteneur unifiedRoleManagementPolicyEnablementRule expose trois définitions de règle identifiées par les ID uniques suivants.
Enablement_Admin_Eligibility- Règles qui s’appliquent aux administrateurs pour effectuer des opérations sur les éligibilités aux rôles. Par exemple, si la justification est requise et s’applique à toutes les opérations (par exemple, renouvellement, activation ou désactivation) ou uniquement à des opérations spécifiques.Enablement_Admin_Assignment- Règles qui s’appliquent aux administrateurs pour effectuer des opérations sur les attributions de rôles. Par exemple, si la justification est requise et s’applique à toutes les opérations (par exemple, renouvellement, désactivation ou extension) ou uniquement à des opérations spécifiques.Enablement_EndUser_Assignment- Règles qui s’appliquent aux principaux pour activer leurs affectations. Par exemple, si l’authentification multifacteur est requise.
Pour mettre à jour ces définitions de règles, utilisez l’API de règles de mise à jour. Par exemple, la requête suivante spécifie une collection enabledRules vide, ce qui désactive les règles activées pour une stratégie, comme l’authentification multifacteur, les informations de ticket et la justification.
PATCH https://graph.microsoft.com/v1.0/policies/roleManagementPolicies/DirectoryRole_cab01047-8ad9-4792-8e42-569340767f1b_70c808b5-0d35-4863-a0ba-07888e99d448/rules/Enablement_EndUser_Assignment
{
"@odata.type": "#microsoft.graph.unifiedRoleManagementPolicyEnablementRule",
"id": "Enablement_EndUser_Assignment",
"enabledRules": [],
"target": {
"caller": "EndUser",
"operations": [
"all"
],
"level": "Assignment",
"inheritableSettings": [],
"enforcedSettings": []
}
}
Vous pouvez récupérer la collection de règles appliquées à tous les rôles Azure AD ou à un rôle Azure AD spécifique via le type de ressource unifiedroleManagementPolicyAssignment et les méthodes associées. Par exemple, la requête suivante utilise le paramètre de requête $expand pour récupérer les règles appliquées à un rôle Azure AD identifié par roleDefinitionId ou templateId62e90394-69f5-4237-9190-012177145e10.
GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicyAssignments?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole' and roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'&$expand=policy($expand=rules)
Pour plus d’informations sur la gestion des paramètres de rôle via PIM, consultez Paramètres de rôle et PIM. Pour obtenir des exemples de règles de mise à jour, consultez Utiliser les API PIM dans Microsoft Graph pour mettre à jour les règles Azure AD.