Packages d'accès Entra Entitlement Management : pilote gouverné

Que sont les packages d'accès Entra Entitlement Management ?

Les packages d'accès Entra Entitlement Management transforment une tâche métier définie en une demande d'accès gouvernée. Un premier package utile répond à des questions pratiques : de quelles ressources cette tâche a-t-elle besoin, qui décide, qui peut demander l'accès et quand l'affectation doit-elle prendre fin ? Commencez par un projet dont les propriétaires de ressources peuvent expliquer ces réponses et participer à leur vérification.

Microsoft décrit un package comme un ensemble d'accès aux ressources régi par des stratégies, au sein d'un catalogue. Les groupes, les applications d'entreprise et les sites SharePoint Online sont des ressources prises en charge. Les stratégies définissent l'éligibilité, l'approbation et la durée d'affectation. Les catalogues délimitent la délégation. Les packages peuvent servir les employés ou les utilisateurs externes. Ces concepts proviennent de la présentation d'Entitlement Management sur Microsoft Learn.

L'absence de package est une observation de configuration à examiner. Elle ne démontre pas que votre organisation n'a aucune gouvernance des accès. Vous disposez peut-être déjà d'un service de demande documenté, d'une approbation par les propriétaires de ressources et de procédures de retrait fiables. Évaluez ce processus au regard du besoin métier avant de décider si Entitlement Management l'améliorerait.

Fonctionnement : délimiter le pilote gouverné

Prenons une équipe projet qui a besoin d'un rôle applicatif précis et d'un accès aux documents du projet. Il s'agit d'un scénario illustratif de planification, pas d'un constat mesuré dans un tenant. Consignez les utilisateurs prévus, les ressources, les niveaux d'autorisation, l'approbateur et la condition de fin avant d'ouvrir l'assistant. Demandez à chaque propriétaire de ressource de confirmer que l'accès proposé suffit à la tâche et ne dépasse pas le nécessaire.

Gardez un périmètre assez restreint pour pouvoir expliquer chaque autorisation incluse. Évitez de regrouper des accès sans rapport simplement parce que les ressources appartiennent au même service. Consignez la personne responsable de la maintenance du package et celle responsable de chaque ressource. Ces responsabilités peuvent relever de personnes différentes ; leur coordination compte lorsqu'une ressource change ou qu'un projet se termine.

La présentation situe explicitement les packages aux côtés d'autres mécanismes d'affectation. Ils conviennent aux tâches limitées dans le temps, aux accès soumis à approbation et aux scénarios de collaboration ; ils ne remplacent pas toutes les méthodes d'affectation existantes. Comparez votre pilote à l'appartenance ordinaire aux groupes et au processus existant de demande de service. Choisissez le mécanisme qui permet au propriétaire d'approuver le bon accès et d'en démontrer le retrait. Microsoft Learn : quand utiliser les packages d'accès.

L'appartenance dynamique et l'accès gouverné répondent aussi à des questions opérationnelles différentes. La sélection fondée sur les attributs peut identifier une population, tandis qu'une stratégie de package définit comment cette population reçoit un droit particulier. Notre article sur le retrait de l'opérateur memberOf traite de l'appartenance dynamique et des dépendances de l'affectation automatique d'Entitlement Management. Utilisez-le pour examiner la logique d'affectation existante avant de concevoir un pilote fondé sur les demandes, sans supposer qu'une migration de règle de groupe apporte des preuves d'approbation ou d'expiration.

Vérifier les licences et les prérequis administratifs

Les exigences de licence de la présentation Learn citent Microsoft Entra ID Governance ou Microsoft Entra Suite pour les utilisateurs de l'organisation et précisent que certaines capacités peuvent fonctionner avec Microsoft Entra ID P2. Traitez cela comme une vérification des licences propre à chaque fonctionnalité, plutôt que comme une instruction universelle d'achat d'un abonnement particulier.

Le tableau des principes de licence de Governance répertorie les demandes en libre-service des utilisateurs, les groupes, les applications, les sites SharePoint, les responsables hiérarchiques ou approbateurs désignés et l'expiration des affectations sous P2 ainsi que Governance et Suite. Dans ce tableau, les stratégies d'affectation automatique et les sponsors issus des profils utilisateur comme approbateurs nécessitent Governance ou Suite. Les produits Governance ont aussi des abonnements prérequis ; la gouvernance des invités relève de considérations de facturation distinctes. Vérifiez les capacités prévues et la population éligible dans la documentation Learn actuelle avant d'activer le pilote. Ne déduisez pas un droit d'utilisation de la simple présence d'une licence quelque part dans le tenant.

Concentrez votre premier test sur des utilisateurs humains et des ressources de projet ordinaires. Si vous ajoutez ensuite des fonctionnalités avancées, réexaminez les licences et les autorisations déléguées au lieu de reprendre les hypothèses du pilote. Consignez la décision relative aux licences avec la conception du package pour que le prochain responsable comprenne les choix délibérés.

Détection : établir si les packages sont absents

Dans le Microsoft Entra admin center, examinez ID Governance > Entitlement management > Access package, le chemin documenté dans le guide de création. Confirmez l'annuaire et votre visibilité avant d'interpréter une vue vide. Enregistrez la date d'observation, l'observateur et le périmètre avec l'inventaire.

Pour un inventaire par API, Microsoft documente la requête suivante dans List accessPackages :

GET https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages

L'API renvoie les packages que l'appelant peut lire dans les catalogues. Le tableau des autorisations indique EntitlementManagement.Read.All comme autorisation OAuth de moindre privilège pour les accès délégués et applicatifs ; les appelants délégués ont aussi besoin d'un rôle pris en charge. Pour les appelants utilisant uniquement une application, Microsoft prend également en charge l'affectation d'un rôle approprié à la place de cette autorisation applicative ; Catalog reader constitue une option moins privilégiée. Un accès limité à certains catalogues peut restreindre la visibilité de l'appelant. Une réponse vide réussie ne permet donc de conclure à une absence à l'échelle du tenant que si le périmètre de collecte couvre ses catalogues. Terminez l'énumération, y compris tout lien de continuation renvoyé, avant de consigner un inventaire comme complet.

La documentation de la ressource Graph accessPackage décrit le catalogue du package, ses stratégies d'affectation et ses relations avec les rôles de ressources. Lister les objets package vérifie leur existence ; examiner séparément ces relations est nécessaire pour évaluer si un package représente l'accès prévu.

La requête ci-dessus est une méthode d'inspection documentée, pas une requête exécutée dans un tenant client pour cet article. Conservez le statut réel, le périmètre de collecte et la réponse de votre audit autorisé. Une erreur d'authentification, une erreur d'autorisation, une exécution interrompue ou un périmètre non vérifié doivent figurer dans les preuves comme limites de collecte. Aucune ne permet d'écrire « aucun package configuré ».

Remédiation : créer le package et prouver son cycle de vie (Remediation)

1. Sélectionner le catalogue et les rôles de ressources

Suivez le processus de création Learn : sélectionnez New access package, saisissez son nom et sa description dans Basics, puis choisissez son catalogue. Identity Governance Administrator, catalog owner ou access package manager peuvent créer des packages dans leur périmètre autorisé. Les access package managers utilisent les ressources déjà présentes dans le catalogue ; ils ne peuvent pas y ajouter de ressources. Dans Resource roles, sélectionnez les ressources et les rôles prévus.

Choisissez le catalogue délibérément et nommez son propriétaire responsable dans le dossier du pilote. Utilisez une description qui permet au demandeur de reconnaître la tâche métier. Faites vérifier les rôles sélectionnés par les propriétaires de ressources avant de continuer. Le rôle de propriétaire d'un groupe diffère sensiblement de l'appartenance au groupe, et un rôle d'administrateur d'application peut être inutile pour un travail de projet ordinaire. Examinez l'autorisation réelle, pas seulement le nom d'affichage de la ressource.

2. Définir les demandeurs et les approbateurs

Dans Requests, configurez les utilisateurs éligibles et les paramètres d'approbation de la stratégie initiale. Exigez une approbation pour le pilote, choisissez l'approbateur désigné et exigez une justification de la demande. Si vous utilisez l'option du responsable hiérarchique, configurez une solution de repli lorsque cette information manque. Dans Who can request access, sélectionnez Self pour ce pilote où les utilisateurs demandent eux-mêmes l'accès. Ces contrôles sont documentés dans les paramètres d'approbation du guide de création.

Préférez une population pilote clairement définie à un large périmètre de demande. Demandez à l'approbateur quelles informations lui sont nécessaires pour décider et s'il peut reconnaître une demande inappropriée. Testez avec un utilisateur éligible et un utilisateur hors périmètre. Consignez les décisions attendues avant le test pour distinguer un défaut de stratégie d'une exigence mal comprise.

Pour la collaboration externe, examinez aussi l'accès conditionnel des invités et les paramètres de collaboration externe. Cet article traite de la protection des connexions des invités, des invitations, de la visibilité et des contrôles du cycle de vie. Utilisez-le pour cadrer les contrôles qui entourent la population externe ; l'approbation du package ne documente pas à elle seule cet examen plus large.

3. Configurer l'expiration avant de créer le package

Dans Lifecycle, sélectionnez une expiration d'affectation par date ou durée et décidez si les prolongations sont autorisées et soumises à approbation. Vérifiez la configuration dans Review + create, puis sélectionnez Create pour créer le package et sa stratégie initiale. Ce sont les étapes de création documentées.

Choisissez la condition de fin selon le calendrier métier de la tâche. Pour le pilote, utilisez une affectation de test qui peut atteindre son expiration programmée pendant votre fenêtre de vérification. Convenez de ce calendrier avec le propriétaire de ressource. Documentez le traitement des prolongations légitimes et la personne qui en décidera. Évitez de laisser une affectation permanente simplement parce que tester l'expiration exige davantage de coordination.

4. Vérifier l'accès fourni, puis l'accès après expiration

Le guide de gestion des affectations de Microsoft documente Assignments, les détails de chaque affectation et les filtres de statut Delivering et Expired. Les erreurs de fourniture peuvent être examinées via l'entrée correspondante dans Requests. Utilisez ces vues pour recueillir des preuves de l'état réel de l'affectation de test.

Soumettez la demande du pilote par son circuit d'approbation configuré. Consignez le demandeur, la stratégie sélectionnée, la décision, l'identifiant d'affectation et l'heure de fin prévue. Vérifiez que l'utilisateur de test reçoit le rôle de ressource prévu et peut réaliser la tâche autorisée. Testez aussi une opération pertinente qu'il ne devrait pas pouvoir effectuer. Une connexion réussie renseigne peu, à elle seule, sur le caractère approprié du rôle affecté.

Après l'expiration programmée, capturez l'affectation expirée et vérifiez à nouveau l'accès aux ressources. Comparez l'appartenance aux groupes, l'affectation applicative et la capacité de l'utilisateur à réaliser la tâche avec les preuves précédentes. Si l'accès demeure, examinez les autres droits accordés avant d'affirmer que le package a échoué ou que l'expiration a supprimé tout accès effectif. Le même utilisateur peut disposer d'un droit distinct que votre pilote n'avait jamais vocation à retirer.

Conservez les deux observations dans le dossier du pilote. « Package créé » est une étape de configuration ; « accès approuvé fourni, puis affectation expirée et accès prévu aux ressources retiré » est le résultat de vérification que vous cherchez à établir. Cet article ne prétend pas qu'un tel test a déjà réussi dans un tenant.

Comment EtcSec détecte cette configuration

Le détecteur AZ_ENTITLEMENT_MANAGEMENT d'etc-collector d'EtcSec évalue l'existence des packages collectés à travers AzureAccessPackagesProbed et AzureAccessPackagesCount. La méthode Detect() examinée comporte les branches suivantes :

Le Count: 1 du constat représente le nombre de constats au niveau du tenant, pas le nombre d'utilisateurs concernés ni de stratégies manquantes. Un résultat nil ne valide ni la sélection des ressources, ni les approbateurs, ni le périmètre des demandes, ni les licences, ni l'expiration, ni le retrait. Le détecteur vérifie l'existence, pas la qualité des stratégies. Un constat d'absence ne prouve pas non plus que tous les processus alternatifs de gouvernance sont manquants.

Utilisez le résultat pour ouvrir l'investigation appropriée : couverture de collecte pour Info, évaluation métier et des licences pour Medium, et examen séparé du cycle de vie lorsque des packages existent déjà. Conservez les preuves de fourniture et d'expiration du pilote avec l'audit pour que l'examen suivant puisse distinguer la disparition d'un constat d'existence d'une gouvernance des accès démontrée.