Audit des rôles personnalisés Entra ID : rôles admin sans assignation

Audit des rôles personnalisés Entra ID : que mesure-t-on ?

Un audit des rôles personnalisés Entra ID doit répondre à trois questions distinctes : quelles définitions de permissions existent, quels principaux les détiennent et si ces assignations répondent encore à un besoin métier. Microsoft représente une assignation comme un lien entre une définition, un principal et un périmètre. La seule présence d’une définition personnalisée ne démontre pas un accès privilégié. Microsoft Graph : unifiedRoleAssignment.

Les revues d’accès portent sur les assignations ; un audit des définitions examine séparément les permissions accordées par ces assignations. Une revue peut omettre les assignations qui ne relèvent pas des rôles, populations ou types d’assignation sélectionnés. Une revue correctement ciblée peut supprimer l’accès lorsque ses résultats sont appliqués. L’examen des assignations laisse aussi une question distincte : la définition sous-jacente doit-elle encore exister et ses permissions sont-elles adaptées ? Créer des revues d’accès aux rôles, terminer et appliquer les revues.

Ce guide distingue ces questions, fournit des requêtes Graph documentées et explique sept contrôles d’etc-collector. Il ne contient aucun résultat de tenant ni aucune opération Graph exécutée. L’objectif pratique est un dossier de preuves permettant à un administrateur de justifier les accès conservés, de supprimer les assignations inutiles et de retirer les définitions personnalisées réellement redondantes sans confondre ces actions.

Définitions, rôles activés et détenteurs

Dans Graph, isBuiltIn=false identifie une définition de rôle personnalisée. isEnabled indique si la définition est disponible pour une assignation ; cet attribut ne dit pas si quelqu’un détient actuellement le rôle. rolePermissions contient sa collection de permissions. Microsoft indique que resourceScopes ne doit pas être utilisé et que sa dépréciation est prévue ; rattachez plutôt le périmètre à l’assignation. Propriétés de unifiedRoleDefinition.

Les rôles d’annuaire Microsoft Entra régissent les ressources Entra ; le RBAC des ressources Azure régit des ressources telles que les machines virtuelles et le stockage. Leurs permissions ne sont pas interchangeables. Les rôles d’annuaire personnalisés peuvent mettre en œuvre une fonction métier plus restreinte qu’un rôle intégré ; « personnalisé » ne constitue donc pas en soi un verdict de sécurité. Vue d’ensemble du RBAC Microsoft Entra.

Pour cet audit, conservez trois catégories de constats : complexité des définitions, assignations nécessitant une justification et incertitude de collecte. Il s’agit d’une méthode de compte rendu recommandée. Elle évite de présenter une liste d’assignations vide comme une compromission active et d’utiliser un catalogue de rôles apparemment réduit à la place d’une analyse des permissions.

Fonctionnement : les permissions et le périmètre déterminent l’exposition

Un nom de permission suit une structure composée d’un espace de noms, d’une entité, d’un ensemble de propriétés et d’une action. Par exemple, microsoft.directory/applications/credentials/update est une permission d’annuaire, et non une permission applicative Graph nommée Application.ReadWrite.All ayant fait l’objet d’un consentement. La documentation Microsoft sur les permissions privilégiées explique cette structure et la manière dont de telles permissions peuvent rendre privilégié un rôle intégré ou personnalisé. Rôles et permissions privilégiés.

Le catalogue des permissions d’inscription d’applications décrit les mises à jour d’identifiants comme des modifications des certificats et secrets d’applications monolocataires et multilocataires. Sa variante applications.myOrganization restreint le sous-type d’application. Il distingue également applications/permissions/update, qui modifie la configuration des permissions, de l’octroi effectif d’un consentement. Préservez ces différences lors de la comparaison des définitions ; des noms d’action similaires ne sont pas interchangeables. Permissions personnalisées d’inscription d’applications.

Un chemin conditionnel d’abus des identifiants

Microsoft avertit qu’un administrateur capable d’ajouter des identifiants applicatifs peut se faire passer pour cette application, dont les permissions peuvent dépasser les siennes. Le raisonnement suivant est une inférence opérationnelle tirée de cet avertissement et du modèle de périmètre des rôles personnalisés : une assignation effective de mise à jour d’identifiants à l’échelle de l’annuaire peut exposer les inscriptions d’applications de cet annuaire ; une assignation limitée à une inscription restreint la cible en conséquence. Déléguer les permissions de gestion des applications.

La chaîne ainsi déduite nécessite une assignation effective ou une activation autorisée, un identifiant accepté pour l’application ciblée et des permissions applicatives effectives utiles. Elle n’accorde pas automatiquement Global Administrator. Elle ne démontre pas le contrôle de toutes les identités de charge de travail : une inscription d’application locale, une identité managée et un principal de service d’une application appartenant à une organisation externe sont des objets différents. Délégation de gestion des applications, RBAC et identités de charge de travail.

Un détecteur qui compte les définitions ne peut pas établir cette chaîne. PA_CUSTOM_ROLE_EXCESSIVE teste le nombre de rôles non intégrés, et non leurs actions ou les périmètres de leurs assignations (azure/privileged-access/roles/custom-role-excessive.go:24). Une seule définition puissante peut donc mériter une investigation même si ce contrôle de comptage ne signale rien.

Les rôles d’administrateur nommés restent des populations distinctes

Application Administrator concerne l’administration des applications ; Exchange Administrator et SharePoint Administrator régissent leurs services respectifs. Security Administrator gère la configuration de sécurité, tandis que Privileged Role Administrator gère les assignations de rôles et PIM. Dans la référence des rôles Microsoft, il s’agit de responsabilités distinctes, et non de cinq noms désignant le même privilège. Référence des rôles intégrés.

Nous recommandons de demander à chaque responsable de service d’expliquer les tâches nécessitant son rôle, le périmètre requis et la durée d’accès attendue. Gardez les détenteurs non humains visibles : notre article connexe sur les principaux de service avec rôles administratifs et privilèges permanents examine la responsabilité et le cycle de vie des détenteurs. Il complète l’inventaire des définitions sans le remplacer.

Mesure : requêtes Microsoft Graph documentées

Les requêtes ci-dessous sont reprises des exemples HTTP ou des syntaxes de requête Learn cités. Chacune dispose de son propre bloc de code. Il s’agit de documentation, et non d’instructions exécutées sur un tenant pour cet article. Lors d’un audit autorisé, consignez l’heure de collecte, les permissions, le statut de réponse et la pagination. Suivez chaque @odata.nextLink renvoyé ; classez une collecte échouée ou incomplète comme inconnue, et non comme zéro assignation.

1. Lister les définitions et classer les rôles personnalisés

L’exemple Learn du fournisseur d’annuaire liste les définitions de rôles :

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions

La même API documente le filtrage par égalité sur isBuiltIn. Pour la requête présentée, classez localement les définitions renvoyées à l’aide de isBuiltIn=false, conservez leurs identifiants et leur état d’activation, puis examinez les collections de permissions. RoleManagement.Read.Directory est une permission de lecture prise en charge ; les appels délégués exigent également un rôle d’opérateur approprié. Lister roleDefinitions.

Nous recommandons de conserver la définition brute à côté de votre interprétation. Un nom d’affichage tel que « Application Support » n’explique pas quelles actions d’écriture elle autorise. Inscrivez les actions exactes, le responsable métier et la justification dans le dossier d’audit afin qu’un futur évaluateur puisse comparer les permissions plutôt que les noms.

2. Distinguer les rôles intégrés activés

L’exemple documenté pour directoryRoles est le suivant :

GET https://graph.microsoft.com/v1.0/directoryRoles

Cette opération renvoie les rôles activés, et non l’ensemble des définitions intégrées disponibles. L’activation d’un rôle d’annuaire dans cette API n’est pas non plus une session d’activation PIM d’un utilisateur. Réconciliez roleTemplateId lorsque cela convient au lieu de considérer les identifiants d’instance et de définition comme interchangeables. Lister directoryRoles.

3. Collecter les assignations actives

Learn documente la syntaxe de requête du fournisseur d’annuaire :

GET /roleManagement/directory/roleAssignments

Utilisez la racine du service v1.0 pour ce chemin relatif. Learn fournit aussi cet exemple exact de filtrage et de développement :

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'&$expand=principal

Le GUID correspond à l’exemple Global Administrator de Microsoft, et non à une définition personnalisée découverte dans votre tenant. Pour une investigation par définition, remplacez-le par l’identifiant de définition vérifié. L’API de liste prend en charge $filter, $expand et $select, avec RoleManagement.Read.Directory parmi ses permissions de lecture. Lister unifiedRoleAssignments.

Reliez les assignations aux définitions à l’aide de roleDefinitionId et conservez principalId et directoryScopeId. Les principaux pris en charge comprennent les utilisateurs, les groupes auxquels un rôle peut être assigné et les principaux de service. Un principal de groupe développé reste un objet groupe ; il ne constitue pas un décompte des personnes recevant l’accès par leur appartenance. Champs et relations des assignations.

4. Collecter séparément l’éligibilité PIM

L’exemple documenté pour l’éligibilité est le suivant :

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleInstances

L’API renvoie les instances d’éligibilité et prend en charge la sélection, le filtrage et le développement. Sa permission de lecture de moindre privilège est RoleEligibilitySchedule.Read.Directory ; l’accès délégué exige également un rôle d’opérateur. Lister roleEligibilityScheduleInstances.

Nous recommandons de conserver séparément les enregistrements actifs et éligibles avant de produire une vue combinée. Faites correspondre le principal, la définition, le périmètre et les dates pertinentes. Une liste active vide ne permet pas de déterminer si quelqu’un reste éligible, et une réponse d’éligibilité ne permet pas d’établir l’utilisation historique. Consignez exactement la question à laquelle répond chaque jeu de données.

5. Identifier les assignations privilégiées sans masquer la version de l’API

La page Learn sur les rôles privilégiés propose cet exemple facultatif :

GET https://graph.microsoft.com/beta/roleManagement/directory/roleAssignments?$expand=roleDefinition&$filter=roleDefinition/isPrivileged eq true

Il s’agit explicitement d’une requête beta. Ne la réécrivez pas silencieusement en v1.0 et ne laissez pas entendre que isPrivileged est une propriété documentée par la ressource de définition v1.0 utilisée ci-dessus. La page décrit aussi l’étiquette PRIVILEGED dans le centre d’administration. Identification des rôles privilégiés.

Détection : compter les assignations, les principaux distincts et les inconnues

Nous recommandons de produire la fiche suivante pour chaque rôle. Ce sont des champs de compte rendu d’audit, et non des limites Microsoft supplémentaires :

Pour un rôle activé sans assignation collectée, réconciliez d’abord les identifiants et confirmez que les deux chemins de collecte ont réussi. Demandez ensuite à son responsable si la définition a un usage prévu. Décrivez-le comme « activé sans assignation active ou éligible collectée », et non comme « jamais utilisé ». Le prédicat UNUSED du collecteur vérifie les correspondances dans les données d’entrée actuelles, et non l’historique d’activité (azure/privileged-access/roles/unused-admin-role.go:36).

Pour les nombres de détenteurs, précisez si votre chiffre désigne des enregistrements d’assignation ou des principaux distincts. Le détecteur partagé TOO_MANY compare les identifiants de rôle et compte les entrées d’assignation correspondantes ; il ne déduplique pas les personnes, ne filtre pas le type de principal et ne restreint pas le périmètre (azure/privileged-access/roles/too-many-privileged-roles.go:43). Traitez son résultat comme un signal de triage nécessitant cette fiche.

Transformer un signal en décision vérifiable

Nous recommandons d’attribuer à chaque constat une décision explicite : conserver avec justification, investiguer les preuves incomplètes, supprimer une assignation, restreindre une assignation ou retirer une définition personnalisée. Consignez la personne responsable de la décision et les preuves qu’elle a examinées. Conservez le résultat du détecteur à côté de cette décision afin qu’une exception opérationnelle reste distinguable d’une erreur de mesure.

Pour un constat de comptage des définitions, demandez une comparaison des permissions avant de recommander une consolidation. Pour un constat UNUSED, demandez les enregistrements de collecte actifs et éligibles avant de recommander un retrait. Pour un constat TOO_MANY, demandez quels principaux et périmètres ont produit le décompte avant de recommander une population plus réduite. Ces questions suivent les trois prédicats décrits ci-dessus ; aucune n’exige d’inventer un résultat d’exploitation.

Nous recommandons de documenter la règle de comptage dans l’export lui-même. Si un principal apparaît à plusieurs périmètres, expliquez si le rapport compte ces assignations séparément. Si un groupe apparaît, qualifiez son assignation d’octroi à un groupe et réservez un champ distinct aux preuves d’appartenance. Si l’éligibilité n’a pas pu être collectée, marquez la conclusion d’absence comme provisoire. Le rapport devient ainsi utilisable par un évaluateur qui n’a pas effectué la collecte.

Choisissez les preuves de clôture lors de l’ouverture du constat. Une tâche de retrait de définition doit se terminer par l’absence de la définition approuvée dans un nouvel inventaire. Une tâche de suppression d’assignation doit se terminer par l’absence de cet octroi précis dans le jeu de données pertinent. Une exception conservée doit se terminer par un usage documenté et une date de revue future. Ce sont des critères d’acceptation recommandés pour l’audit, et non des affirmations sur une fonctionnalité d’application automatique.

Microsoft recommande moins de cinq Global Administrators et moins de dix assignations de rôles privilégiés dans l’ensemble de l’organisation. Il s’agit de recommandations de gouvernance, et non de plafonds d’assignation imposés. La page citée ne fixe pas de plafond de deux à quatre détenteurs par rôle Application, Exchange, Security, SharePoint ou Privileged Role Administrator. Les seuils par rôle du collecteur sont des valeurs par défaut du produit. Bonnes pratiques des rôles Microsoft Entra.

Remédiation : retirer les définitions redondantes et gouverner les accès restants (Remediation)

1. Décider quels rôles personnalisés conserver

Nous recommandons d’examiner chaque définition avec le responsable du service : quelle opération exacte la nécessite, quel périmètre plus restreint convient et qui répond des modifications futures ? Consolidez les définitions redondantes uniquement après avoir comparé leurs actions et leurs assignations prévues. Conservez les rôles personnalisés utiles lorsqu’ils mettent en œuvre les permissions requises plus précisément qu’un rôle intégré. Sélection de rôles de moindre privilège.

Traitez cela comme un dossier de décision, et non comme une démarche visant une taille arbitraire du catalogue. Pour une définition apparemment vide, capturez les inventaires actifs et éligibles, confirmez la qualité de collecte et examinez les dépendances prévues avant d’approuver son retrait. Lorsque l’accès reste nécessaire, privilégiez la réduction des actions inutiles de gestion des identifiants et des périmètres applicatifs trop larges. Permissions personnalisées d’inscription.

2. Supprimer les assignations inutiles, puis les définitions personnalisées approuvées

Nous recommandons de séparer ces deux décisions de changement. La suppression d’une assignation concerne l’accès d’un détenteur ; le retrait d’une définition concerne le catalogue de rôles. L’API de suppression Microsoft prend en charge les définitions personnalisées, interdit la suppression des rôles intégrés et documente cette syntaxe :

DELETE /roleManagement/directory/roleDefinitions/{id}

Il s’agit d’une opération d’écriture citée, non exécutée ici. Remplacez {id} uniquement par l’identifiant de définition personnalisée approuvé. Learn indique RoleManagement.ReadWrite.Directory comme permission API de moindre privilège et Privileged Role Administrator comme rôle d’opérateur délégué pris en charge de moindre privilège. Une suppression réussie renvoie 204 No Content. Supprimer unifiedRoleDefinition.

Pour un rôle intégré signalé par UNUSED, documentez pourquoi il n’a aucun détenteur et si l’instance activée reste pertinente. N’appliquez pas une procédure de suppression de définition personnalisée à chaque résultat UNUSED. Nous recommandons de vérifier les inventaires des définitions et assignations après modification avant de clôturer le changement.

3. Définir des populations justifiées et migrer les accès humains adaptés vers PIM

Nous recommandons un budget d’accès par rôle fondé sur les tâches nécessaires et la couverture opérationnelle, avec des exceptions explicites. Évaluez les assignations privilégiées agrégées de l’organisation au regard des recommandations Microsoft au lieu de considérer les seuils du collecteur comme des quotas Microsoft obligatoires.

PIM prend en charge l’activation limitée dans le temps et soumise à approbation pour les rôles Entra intégrés et personnalisés. Son plan de déploiement recommande de tester un pilote, de configurer les paramètres de chaque rôle et de préserver l’accès d’urgence. Les principaux de service ne peuvent pas recevoir d’assignations éligibles ; ils peuvent recevoir des assignations actives limitées dans le temps. Le plan Microsoft recommande deux comptes d’urgence exclusivement cloud avec des assignations Global Administrator permanentes. Planifier un déploiement PIM.

Pour les assignations humaines adaptées, nous recommandons de tester l’approbation, la MFA, la justification et la durée par rapport au modèle opérationnel prévu avant le déploiement. Notre article sur les contrôles d’approbation, de MFA, de justification et de durée d’activation PIM traite de cette revue de configuration distincte.

Confirmez les licences avant d’adopter le plan : l’utilisation des rôles personnalisés exige P1 pour les utilisateurs assignés, tandis que PIM exige P2 ou Governance. Les revues d’accès des principaux de service nécessitent Workload ID Premium en plus de P2 ou Governance. Licences des rôles personnalisés, Licences PIM et recommandations sur les rôles, Prérequis des revues PIM.

4. Revoir les accès et appliquer les décisions

Dans PIM, sélectionnez les rôles Entra et les populations concernés, choisissez les assignations actives, éligibles ou les deux, puis configurez les évaluateurs responsables et le traitement des absences de réponse. Une revue capture un instantané au démarrage ; les groupes auxquels un rôle peut être assigné apparaissent sans développement de leurs membres. Créer des revues d’accès aux rôles.

Nous recommandons de conserver le périmètre de revue avec les résultats afin que « revue terminée » ne puisse pas être confondu avec « tous les accès administratifs revus ». Documentez séparément les preuves d’appartenance lorsqu’un rôle est assigné à un groupe. Donnez aux responsables des charges de travail une tâche de revue adaptée à l’identité de service au lieu de supposer que les contrôles d’activation humains la couvrent.

Les accès refusés sont supprimés lorsque les résultats de revue sont appliqués, manuellement ou par l’application automatique configurée. Le simple enregistrement d’un refus n’est pas l’étape finale de révocation. Terminer les revues d’accès aux rôles.

5. Vérifier le résultat avec les mêmes mesures

Nous recommandons de répéter les lectures documentées après les changements, en comparant les identifiants de définition, les actions de permission, les périmètres et les assignations actives et éligibles. Vérifiez le changement précis approuvé : un détenteur retiré, une permission restreinte ou une définition retirée. Conservez les exceptions et les inconnues au lieu de déclarer l’audit réussi parce qu’un décompte a diminué.

Comment EtcSec détecte cette situation

Les sept identifiants suivants existent dans le catalogue. Leurs implémentations ont été lues dans etc-collector au commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Les chemins ci-dessous sont relatifs à public/internal/audit/detectors/.

CUSTOM utilise azure/privileged-access/roles/custom-role-excessive.go:24 ; UNUSED utilise azure/privileged-access/roles/unused-admin-role.go:36. Les cinq contrôles TOO_MANY utilisent tous la méthode partagée Detect() dans azure/privileged-access/roles/too-many-privileged-roles.go:43. Leurs constructeurs individuels too-many-*-admins.go fixent les seuils à la ligne 17 et les sévérités à la ligne 19. Chaque implémentation renvoie un constat même avec Count=0 ; une détection positive exige Count>0. Au-dessus du seuil, CUSTOM et TOO_MANY renvoient le nombre total correspondant, et non seulement l’excédent.

Les cinq entrées TOO_MANY sont Info avec un poids de 0 dans le catalogue, bien que leurs constructeurs émettent High, ou Critical pour Privileged Role Administrator. Cet écart est conservé explicitement. Ne relevez pas silencieusement le score du catalogue et ne présentez pas les sévérités d’exécution comme les valeurs du catalogue.

Les limites de collecte influencent l’interprétation

Le fournisseur examiné combine les assignations actives avec l’éligibilité collectée à l’aide du principal, du rôle et du périmètre (public/internal/providers/azure/client.go:1597, :1626, :1784). Son inventaire de rôles combine les instances intégrées activées avec les définitions personnalisées, en mappant les identifiants de définition personnalisée sur RoleTemplateID et en fixant leur attribut interne IsEnabled=true sans copier la valeur d’activation de Graph (client.go:1500).

Les lectures des définitions personnalisées sont effectuées au mieux ; les chemins de rôles et d’éligibilité examinés n’implémentent pas de boucles nextLink. Les erreurs HTTP ou d’analyse de l’éligibilité peuvent renvoyer une map vide (client.go:404). Par conséquent, une collecte d’éligibilité manquante peut produire un résultat UNUSED apparent ou sous-estimer les populations TOO_MANY. Ce sont des observations statiques du code, et non des défaillances de tenant reproduites.

Clôturez l’audit avec des preuves distinctes de la nécessité des définitions, de la justification des détenteurs et de la révocation effective. Un résultat sous les seuils est utile, mais la décision dont il faut répondre est de savoir si chaque permission et assignation conservée a encore un usage documenté.