Configurer des vérifications de séparation des tâches pour un package d’accès dans la gestion des droits d’utilisation
Dans la gestion des droits d’utilisation, vous pouvez configurer plusieurs stratégies, avec des paramètres différents pour chaque communauté d’utilisateurs qui aura besoin d’un accès par le biais d’un package d’accès. Par exemple, les employés peuvent avoir besoin seulement de l’approbation du responsable pour accéder à certaines applications, mais des invités provenant d’autres organisations peuvent nécessiter l’approbation d’un sponsor et d'un responsable du département de l’équipe des ressources. Dans une stratégie pour les utilisateurs qui se trouvent déjà dans l’annuaire, vous pouvez spécifier un groupe d’utilisateurs particulier qui peut demander l’accès. Cependant, vous pouvez avoir comme exigence d'éviter qu'un utilisateur n'obtienne un accès excessif. Pour répondre à cette exigence, vous voulez limiter davantage les personnes autorisées à demander un accès en fonction de l’accès qu'a déjà le demandeur.
Avec les paramètres de séparation des tâches d’un package d’accès, vous pouvez configurer qu’un utilisateur qui est membre d’un groupe ou qui a déjà une attribution à un package d’accès ne peut pas demander un package d’accès supplémentaire.
Scénarios de séparation des vérifications des tâches
Par exemple, vous disposez d’un package d’accès, campagne marketing, que les personnes de votre organisation et d’autres organisations peuvent demander à accéder à pour travailler avec le service marketing de votre organisation pendant que cette campagne se poursuivra. Étant donné que les employés du service marketing doivent avoir déjà accès à ce matériel de campagne marketing, vous ne souhaitez pas que les employés du service marketing demandent l’accès à ce package d’accès. Vous pourriez aussi avoir déjà un groupe dynamique, Employés du service marketing, qui contient tous les employés du marketing. Vous pouvez indiquer que le package d’accès est incompatible avec l’appartenance de ce groupe dynamique. Ensuite, si un employé du service marketing recherche un package d’accès à demander, il ne peut pas demander l’accès au package d’accès à la campagne marketing.
De même, vous pourriez avoir une application avec deux rôles d’application, Ventes Ouest et Ventes Est, représentant les secteurs commerciaux, et vous voulez vous assurer qu’un utilisateur ne peut avoir qu’un seul secteur commercial à la fois. Si vous avez deux packages d’accès, un package d’accès Secteur Ouest donnant le rôle Ventes Ouest et un autre package d’accès, Secteur Est donnant le rôle Ventes Est, vous pouvez configurer :
- que le package d’accès Secteur ouest a le package d’accès Secteur est comme étant incompatible et
- que le package d’accès Secteur est a le package d’accès Secteur ouest comme étant incompatible.
Si vous avez utilisé Microsoft Identity Manager ou d’autres systèmes de gestion des identités locaux pour automatiser l’accès aux applications locales, vous pouvez également intégrer ces systèmes à la gestion des droits d’utilisation. Si vous contrôlez l’accès aux applications intégrées à Microsoft Entra via la gestion des droits d’utilisation et que vous voulez empêcher les utilisateurs d’avoir un accès incompatible, vous pouvez configurer le fait qu’un package d’accès est incompatible avec un groupe. Il peut s’agir d’un groupe que votre système de gestion des identités local envoie à Microsoft Entra ID via Microsoft Entra Connect. Cette vérification garantit qu’un utilisateur ne peut pas demander un package d’accès si ce package d’accès donne à cet utilisateur un accès incompatible avec l’accès de l’utilisateur aux applications locales.
Prérequis
Pour utiliser la gestion des droits d’utilisation et affecter des utilisateurs aux packages d’accès, vous devez disposer d’une des licences suivantes :
- Microsoft Entra ID P2 ou gouvernance de Microsoft Entra ID
- Licence Enterprise Mobility + Security (EMS) E5
Configurer un autre package d’accès ou une appartenance à un groupe comme incompatible pour demander l’accès à un package d’accès
Conseil
Les étapes décrites dans cet article pourraient varier légèrement en fonction du portail de départ.
Rôle prérequis : administrateur général, administrateur de la gouvernance des identités, propriétaire de catalogue ou gestionnaire de package d'accès
Procédez comme suit pour modifier la liste des groupes incompatibles ou d’autres packages d’accès pour un package d’accès existant :
Connectez-vous au centre d’administration de Microsoft Entra en tant qu’Administrateur de la gouvernance des identités.
Accédez à Gouvernance des identités>Gestion des droits d’utilisation>Packages d’accès.
Dans la page Packages d’accès, ouvrez le package d'accès que les utilisateurs vont demander.
Dans le menu de gauche, sélectionnez Séparation des tâches.
Si vous souhaitez empêcher les utilisateurs qui ont déjà une autre affectation de package d’accès à demander ce package d’accès, sélectionnez Ajouter un package d’accès et sélectionnez le package d’accès que l’utilisateur est déjà affecté.
Si vous souhaitez empêcher les utilisateurs qui ont une appartenance à un groupe existante de demander ce package d’accès, sélectionnez Ajouter un groupe, puis sélectionnez le groupe auquel l’utilisateur se trouvait déjà.
Configurer des packages d’accès incompatibles par programmation par Graph
Vous pouvez configurer les groupes et autres packages d’accès qui sont incompatibles avec le package d’accès à l’aide de Microsoft Graph. Un utilisateur doté d’un rôle approprié avec une application disposant de l’autorisation déléguée EntitlementManagement.ReadWrite.All, ou une application disposant de cette autorisation d’application EntitlementManagement.ReadWrite.All, peut appeler l’API pour ajouter, supprimer et répertorier les groupes et les packages d’accès incompatibles d’un package d’accès.
Configurer des packages d’accès incompatibles via Microsoft PowerShell
Vous pouvez également configurer les groupes et autres packages d’accès incompatibles avec un package d’accès dans PowerShell avec les applets de commande du module Microsoft Graph PowerShell cmdlets for Identity Governance version 1.16.0 ou ultérieure.
Ce script ci-dessous illustre l’utilisation du v1.0 profil de Graph pour créer une relation indiquant qu’un autre package d’accès est incompatible.
Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"
$apid = "00001111-aaaa-2222-bbbb-3333cccc4444"
$otherapid = "11112222-bbbb-3333-cccc-4444dddd5555"
$params = @{
"@odata.id" = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages/" + $otherapid
}
New-MgEntitlementManagementAccessPackageIncompatibleAccessPackageByRef -AccessPackageId $apid -BodyParameter $params
Afficher les autres packages d’accès configurés comme incompatibles avec celui-ci
Rôle prérequis : administrateur général, administrateur de la gouvernance des identités, propriétaire de catalogue ou gestionnaire de package d'accès
Procédez comme suit pour afficher la liste des autres packages d’accès qui ont indiqué qu’ils ne sont pas compatibles avec un package d’accès existant :
Connectez-vous au centre d’administration de Microsoft Entra en tant qu’Administrateur de la gouvernance des identités.
Accédez à Gouvernance des identités>Gestion des droits d’utilisation>Packages d’accès.
Dans la page Packages d’accès, ouvrez le package d’accès.
Dans le menu de gauche, sélectionnez Séparation des tâches.
Sélectionnez Incompatible avec.
Identification des utilisateurs qui ont déjà un accès incompatible à un autre package d’accès (préversion)
Si vous avez configuré des paramètres d’accès incompatibles sur un package d’accès auquel des utilisateurs sont déjà affectés, vous pouvez télécharger la liste des utilisateurs qui disposent de cet accès supplémentaire. Les utilisateurs qui ont également une affectation au package d’accès incompatible ne pourront pas demander à nouveau l’accès.
Rôle prérequis : administrateur général, administrateur de la gouvernance des identités, propriétaire de catalogue ou gestionnaire de package d'accès
Suivez ces étapes pour afficher la liste des utilisateurs qui ont des affectations à deux packages d’accès.
Connectez-vous au centre d’administration de Microsoft Entra en tant qu’Administrateur de la gouvernance des identités.
Accédez à Gouvernance des identités>Gestion des droits d’utilisation>Packages d’accès.
Sur la page Packages d’accès, ouvrez le package d’accès dans lequel vous avez configuré un autre package d'accès comme incompatible.
Dans le menu de gauche, sélectionnez Séparation des tâches.
Dans la table, s’il existe une valeur différente de zéro dans la colonne Accès supplémentaire pour le deuxième package d’accès, cela indique qu’il existe un ou plusieurs utilisateurs avec des affectations.
Sélectionnez ce nombre pour afficher la liste des affectations incompatibles.
Si vous le souhaitez, vous pouvez sélectionner le bouton Télécharger pour enregistrer cette liste d’affectations sous forme de fichier CSV.
Identification des utilisateurs qui auront un accès incompatible à un autre package d’accès
Si vous configurez des paramètres d’accès incompatibles sur un package d’accès auquel des utilisateurs sont déjà affectés, tous les utilisateurs qui ont également une affectation aux groupes ou au package d’accès incompatibles ne pourront pas redemander l’accès.
Rôle prérequis : administrateur général, administrateur de la gouvernance des identités, propriétaire de catalogue ou gestionnaire de package d'accès
Suivez ces étapes pour afficher la liste des utilisateurs qui ont des affectations à deux packages d’accès.
Connectez-vous au centre d’administration de Microsoft Entra en tant qu’Administrateur de la gouvernance des identités.
Accédez à Gouvernance des identités>Gestion des droits d’utilisation>Packages d’accès.
Ouvrez le package d’accès dans lequel vous allez configurer des affectations incompatibles.
Dans le menu de gauche, sélectionnez Affectations.
Dans le champ État, vérifiez que l’état Remis est sélectionné.
Sélectionnez le bouton Télécharger et enregistrez le fichier CSV résultant en tant que premier fichier avec une liste d’affectations.
Dans la barre de navigation, sélectionnez Gouvernance des identités.
Dans le menu de gauche, sélectionnez Packages d’accès, puis ouvrez le package d’accès que vous prévoyez d’indiquer comme incompatible.
Dans le menu de gauche, sélectionnez Affectations.
Dans le champ État, vérifiez que l’état Remis est sélectionné.
Sélectionnez le bouton Télécharger et enregistrez le fichier CSV résultant en tant que deuxième fichier avec une liste d’affectations.
Utilisez un tableur comme Excel pour ouvrir les deux fichiers.
Les utilisateurs listés dans les deux fichiers ont des affectations incompatibles déjà existantes.
Identification des utilisateurs qui ont déjà un accès incompatible programmatiquement
Vous pouvez récupérer des affectations à un package d’accès à l’aide de Microsoft Graph, qui sont limitées uniquement aux utilisateurs qui ont également une affectation à un autre package d’accès. Un utilisateur doté d’un rôle administratif avec une application disposant de l’autorisation déléguée EntitlementManagement.Read.All ou EntitlementManagement.ReadWrite.All peut appeler l’API pour lister des accès supplémentaires.
Identification des utilisateurs qui ont déjà un accès incompatible à l’aide de PowerShell
Vous pouvez également interroger les utilisateurs qui ont des affectations à un package d'accès avec l'applet de commande Get-MgEntitlementManagementAssignment à partir des applets de commande Microsoft Graph PowerShell pour le module Identity Governance version 2.1.0 ou ultérieure.
Par exemple, si vous avez deux packages d’accès, l’un avec l’ID 29be137f-b006-426c-b46a-0df3d4e25ccd et l’autre avec l’ID cce10272-68d8-4482-8ba3-a5965c86cfe5, vous pouvez récupérer les utilisateurs qui ont des affectations au premier package d’accès, puis les comparer aux utilisateurs qui ont des affectations au deuxième package d’accès. Vous pouvez également signaler les utilisateurs qui ont des affectations remises aux deux, à l’aide d’un script PowerShell similaire à ce qui suit :
$c = Connect-MgGraph -Scopes "EntitlementManagement.Read.All"
$ap_w_id = "29be137f-b006-426c-b46a-0df3d4e25ccd"
$ap_e_id = "cce10272-68d8-4482-8ba3-a5965c86cfe5"
$apa_w_filter = "accessPackage/id eq '" + $ap_w_id + "' and state eq 'Delivered'"
$apa_e_filter = "accessPackage/id eq '" + $ap_e_id + "' and state eq 'Delivered'"
$apa_w = @(Get-MgEntitlementManagementAssignment -Filter $apa_w_filter -ExpandProperty target -All)
$apa_e = @(Get-MgEntitlementManagementAssignment -Filter $apa_e_filter -ExpandProperty target -All)
$htt = @{}; foreach ($e in $apa_e) { if ($null -ne $e.Target -and $null -ne $e.Target.Id) {$htt[$e.Target.Id] = $e} }
foreach ($w in $apa_w) { if ($null -ne $w.Target -and $null -ne $w.Target.Id -and $htt.ContainsKey($w.Target.Id)) { write-output $w.Target.Email } }
Configuration de plusieurs packages d’accès pour les scénarios de remplacement
Si un package d’accès a été configuré comme incompatible, un utilisateur qui a une affectation à ce package d’accès incompatible ne peut pas demander le package d’accès et l’administrateur ne peut pas non plus créer de nouvelle affectation qui serait incompatible.
Par exemple, si le package d’accès Environnement de production a marqué le package Environnement de développement comme incompatible et qu’un utilisateur a une affectation au package d’accès Environnement de développement, le gestionnaire de package d’accès pour Environnement de production ne peut pas créer d’affectation pour cet utilisateur au package d’accès Environnement de production. Pour continuer avec cette affectation, l’affectation existante de l’utilisateur au package d’accès Environnement de développement doit d’abord être supprimée.
Dans une situation exceptionnelle où les règles de séparation des tâches auraient besoin d’être remplacées, la configuration d’un package d’accès supplémentaire pour capturer les utilisateurs avec des droits d’accès qui se chevauchent éclairerait les approbateurs, les réviseurs et les auditeurs sur la nature exceptionnelle de ces affectations.
Par exemple, dans un scénario où certains utilisateurs auraient besoin d’accéder simultanément aux environnements de production et de développement, vous pourriez créer un nouveau package d’accès Environnements de production et de développement. Ce package d’accès pourrait avoir comme rôles de ressource certains des rôles de ressource du package d’accès Environnement de production et certains des rôles de ressource du package d’accès Environnement de développement.
Si la motivation de l’accès incompatible est que les rôles d’une ressource sont particulièrement problématiques, cette ressource peut être omise du package d’accès combiné et demander une affectation d’administrateur explicite d’un utilisateur au rôle de ressource. S’il s’agit d’une application tierce ou de votre propre application, vous pouvez assurer la supervision en surveillant ces attributions de rôles à l’aide du workbook Activité d’attribution de rôle d’application décrit dans la section suivante.
Selon vos procédures de gouvernance, ce package d’accès combiné pourrait avoir comme stratégie :
- Une stratégie d’affectations directes afin que seul un gestionnaire de package d’accès interagisse avec le package d’accès, ou
- Une stratégie où les utilisateurs peuvent demander l’accès afin que l’utilisateur puisse demander l’accès, avec éventuellement une étape d’approbation supplémentaire
Cette stratégie pourrait avoir comme paramètres de cycle de vie un nombre de jours d’expiration nettement inférieur à une stratégie sur d’autres packages d’accès, ou exiger des révisions d’accès plus fréquentes avec une supervision régulière afin que les utilisateurs ne conservent pas l’accès plus longtemps que nécessaire.
Surveiller et signaler les affectations d’accès
Vous pouvez utiliser les classeurs Azure Monitor pour obtenir des informations sur la façon dont les utilisateurs reçoivent leur accès.
Configurez Microsoft Entra ID pour envoyer des événements d’audit à Azure Monitor.
Le classeur nommé Activité du package d’accès affiche chaque événement lié à un package d’accès particulier.
Pour voir si des modifications ont été apportées aux attributions de rôle d’application pour une application qui n’ont pas été créées en raison des affectations de package d’accès, vous pouvez sélectionner le classeur nommé Activité d’attribution de rôle d’application. Si vous choisissez d’omettre l’activité de droit, seules les modifications apportées aux rôles d’application qui n’ont pas été effectuées par la gestion des droits d’utilisation s’affichent. Par exemple, vous verriez une ligne si un administrateur général a directement affecté un utilisateur à un rôle d’application.
