Entra ID benutzerdefinierte Rollen Audit: Ohne Zuweisung

Entra ID benutzerdefinierte Rollen Audit: Was wird gemessen?

Ein entra id benutzerdefinierte rollen audit sollte drei getrennte Fragen beantworten: Welche Berechtigungsdefinitionen existieren, welche Principals besitzen sie und erfüllen diese Zuweisungen noch einen geschäftlichen Zweck? Microsoft modelliert eine Zuweisung als Verbindung zwischen einer Definition, einem Principal und einem Geltungsbereich. Eine benutzerdefinierte Definition allein belegt keinen privilegierten Zugriff. Microsoft Graph: unifiedRoleAssignment.

Zugriffsüberprüfungen befassen sich mit Zuweisungen; ein Definitionsaudit untersucht separat die Berechtigungen, die diese Zuweisungen gewähren. Eine Überprüfung kann Zuweisungen außerhalb der ausgewählten Rollen, Populationen oder Zuweisungstypen übersehen. Eine passend ausgerichtete Überprüfung kann Zugriff entfernen, wenn ihre Ergebnisse angewendet werden. Auch nach der Überprüfung der Zuweisungen bleibt eine eigene Frage: Sollte die zugrunde liegende Definition weiterhin existieren, und sind ihre Berechtigungen angemessen? Zugriffsüberprüfungen für Rollen erstellen, Überprüfungen abschließen und anwenden.

Dieser Leitfaden trennt diese Fragen, liefert dokumentierte Graph-Anfragen und erläutert sieben Prüfungen von etc-collector. Er enthält weder Mandantenergebnisse noch ausgeführte Graph-Operationen. Das praktische Ziel ist eine Belegsammlung, mit der Administratoren beibehaltenen Zugriff begründen, unnötige Zuweisungen entfernen und tatsächlich redundante benutzerdefinierte Definitionen stilllegen können, ohne diese Maßnahmen zu verwechseln.

Definitionen, aktivierte Rollen und Rolleninhaber

In Graph kennzeichnet isBuiltIn=false eine benutzerdefinierte Rollendefinition. isEnabled beschreibt, ob die Definition für Zuweisungen verfügbar ist; es sagt nicht aus, ob sie derzeit jemand besitzt. rolePermissions enthält ihre Berechtigungssammlung. Microsoft kennzeichnet resourceScopes als nicht zu verwenden und zur künftigen Entfernung vorgesehen; ordnen Sie den Geltungsbereich stattdessen der Zuweisung zu. Eigenschaften von unifiedRoleDefinition.

Microsoft-Entra-Verzeichnisrollen steuern Entra-Ressourcen; Azure-Ressourcen-RBAC steuert Ressourcen wie virtuelle Maschinen und Speicher. Die Berechtigungen sind nicht austauschbar. Benutzerdefinierte Verzeichnisrollen können eine enger begrenzte Aufgabe als eine integrierte Rolle abbilden; „benutzerdefiniert“ ist daher für sich genommen kein Sicherheitsurteil. Überblick über Microsoft Entra RBAC.

Führen Sie für dieses Audit drei Befundkategorien: Definitionskomplexität, begründungsbedürftige Zuweisungen und Unsicherheit bei der Datenerfassung. Dies ist eine empfohlene Berichtsmethode. Sie verhindert, dass eine leere Zuweisungsliste als aktive Kompromittierung dargestellt wird oder ein scheinbar kleiner Rollenkatalog die Berechtigungsanalyse ersetzt.

Funktionsweise: Berechtigungen und Geltungsbereich bestimmen die Exposition

Ein Berechtigungsname besteht aus Namespace, Entität, Eigenschaftssatz und Aktion. Beispielsweise ist microsoft.directory/applications/credentials/update eine Verzeichnisberechtigung und keine durch Zustimmung erteilte Graph-Anwendungsberechtigung namens Application.ReadWrite.All. Microsofts Dokumentation zu privilegierten Berechtigungen erläutert deren Struktur und wie solche Berechtigungen eine integrierte oder benutzerdefinierte Rolle privilegiert machen können. Privilegierte Rollen und Berechtigungen.

Der Berechtigungskatalog für Anwendungsregistrierungen beschreibt Aktualisierungen von Anmeldeinformationen als Änderungen an Zertifikaten und Geheimnissen von Einzelmandanten- und Mehrmandantenanwendungen. Seine Variante applications.myOrganization schränkt den Anwendungsuntertyp ein. Er unterscheidet außerdem applications/permissions/update, das die Berechtigungskonfiguration ändert, von der tatsächlichen Erteilung einer Zustimmung. Bewahren Sie diese Unterschiede beim Vergleich von Definitionen; ähnlich aussehende Aktionsnamen sind nicht austauschbar. Benutzerdefinierte Berechtigungen für Anwendungsregistrierungen.

Ein bedingter Missbrauchspfad über Anmeldeinformationen

Microsoft warnt, dass ein Administrator, der Anmeldeinformationen zu Anwendungen hinzufügen kann, als diese Anwendung auftreten kann, deren Berechtigungen seine eigenen übersteigen können. Folgendes ist eine operative Schlussfolgerung aus dieser Warnung und dem Geltungsbereichsmodell benutzerdefinierter Rollen: Eine wirksame Zuweisung zum Aktualisieren von Anmeldeinformationen auf Verzeichnisebene kann Anwendungsregistrierungen in diesem Verzeichnis exponieren; eine auf eine einzelne Registrierung begrenzte Zuweisung schränkt das Ziel entsprechend ein. Berechtigungen zur Anwendungsverwaltung delegieren.

Die abgeleitete Kette benötigt eine wirksame Zuweisung oder zulässige Aktivierung, für die Zielanwendung akzeptierte Anmeldeinformationen und nutzbare effektive Anwendungsberechtigungen. Sie gewährt nicht automatisch Global Administrator. Sie belegt keine Kontrolle über jede Workload-Identität: Eine lokale Anwendungsregistrierung, eine verwaltete Identität und ein Service Principal einer extern verwalteten Anwendung sind unterschiedliche Objekte. Delegierung der Anwendungsverwaltung, RBAC und Workload-Identitäten.

Ein Detektor für die Anzahl von Definitionen kann diese Kette nicht nachweisen. PA_CUSTOM_ROLE_EXCESSIVE prüft die Anzahl nicht integrierter Rollen, nicht deren Aktionen oder Zuweisungsgeltungsbereiche (azure/privileged-access/roles/custom-role-excessive.go:24). Eine einzelne mächtige Definition kann deshalb eine Untersuchung verdienen, selbst wenn diese Anzahlprüfung keinen Befund liefert.

Benannte Administratorrollen bleiben getrennte Populationen

Application Administrator betrifft die Anwendungsverwaltung; Exchange Administrator und SharePoint Administrator steuern die jeweiligen Dienste. Security Administrator verwaltet die Sicherheitskonfiguration, während Privileged Role Administrator Rollenzuweisungen und PIM verwaltet. Microsofts Rollenreferenz beschreibt unterschiedliche Verantwortlichkeiten, keine fünf Namen für dasselbe Privileg. Referenz der integrierten Rollen.

Es empfiehlt sich, jeden Dienstverantwortlichen nach den Aufgaben zu fragen, die seine Rolle erfordern, nach dem notwendigen Geltungsbereich und dem erwarteten Zugriffszeitraum. Halten Sie nicht menschliche Rolleninhaber sichtbar: Unser verwandter Artikel über Service Principals mit Administratorrollen und dauerhaften Privilegien untersucht Verantwortlichkeit und Lebenszyklus der Rolleninhaber. Das ergänzt eine Definitionsinventur; es ersetzt sie nicht.

Messung: Dokumentierte Microsoft-Graph-Anfragen

Die folgenden Anfragen stammen aus den zitierten HTTP-Beispielen oder der Anfragesyntax in Learn. Jede steht in einem eigenen Codeblock. Sie sind Dokumentation und wurden für diesen Artikel nicht gegen einen Mandanten ausgeführt. Erfassen Sie bei einem autorisierten Audit Zeitpunkt, Berechtigungen, Antwortstatus und Paginierung. Folgen Sie jedem zurückgegebenen @odata.nextLink; klassifizieren Sie fehlgeschlagene oder unvollständige Erfassung als unbekannt und nicht als null Zuweisungen.

1. Definitionen auflisten und benutzerdefinierte Rollen klassifizieren

Das Learn-Beispiel für den Verzeichnisprovider listet Rollendefinitionen auf:

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

Dieselbe API dokumentiert Gleichheitsfilter auf isBuiltIn. Klassifizieren Sie für die gezeigte Anfrage die zurückgegebenen Definitionen lokal anhand von isBuiltIn=false, bewahren Sie ihre IDs und den Aktivierungsstatus auf und untersuchen Sie die Berechtigungssammlungen. RoleManagement.Read.Directory ist eine unterstützte Leseberechtigung; delegierte Aufrufe benötigen außerdem eine geeignete Operatorrolle. roleDefinitions auflisten.

Es empfiehlt sich, die unverarbeitete Definition neben Ihrer Interpretation aufzubewahren. Ein Anzeigename wie „Application Support“ erklärt nicht, welche Schreibaktionen erlaubt sind. Nehmen Sie die exakten Aktionen, den geschäftlichen Verantwortlichen und die Begründung in den Auditdatensatz auf, damit spätere Prüfer Berechtigungen statt Namen vergleichen können.

2. Aktivierte integrierte Rollen unterscheiden

Das dokumentierte directoryRoles-Beispiel lautet:

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

Diese Operation liefert aktivierte Rollen, nicht sämtliche verfügbaren integrierten Definitionen. Die Verzeichnisrollenaktivierung in dieser API ist außerdem keine PIM-Aktivierungssitzung eines Benutzers. Gleichen Sie gegebenenfalls roleTemplateId ab, statt Instanz-IDs und Definitions-IDs als austauschbar zu behandeln. directoryRoles auflisten.

3. Aktive Zuweisungen erfassen

Learn dokumentiert die Anfragesyntax für den Verzeichnisprovider:

GET /roleManagement/directory/roleAssignments

Verwenden Sie für diesen relativen Pfad den v1.0-Dienststamm. Learn liefert auch dieses exakte Beispiel mit Filter und Erweiterung:

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

Die GUID stammt aus Microsofts Beispiel für Global Administrator und ist keine in Ihrem Mandanten ermittelte benutzerdefinierte Definition. Ersetzen Sie sie bei einer Untersuchung je Definition durch die verifizierte Definitions-ID. Die Listen-API unterstützt $filter, $expand und $select; RoleManagement.Read.Directory zählt zu ihren Leseberechtigungen. unifiedRoleAssignments auflisten.

Verknüpfen Sie Zuweisungen über roleDefinitionId mit Definitionen und bewahren Sie principalId und directoryScopeId auf. Unterstützte Principals sind Benutzer, Gruppen mit zuweisbaren Rollen und Service Principals. Ein erweiterter Gruppen-Principal bleibt ein Gruppenobjekt; er ist keine Anzahl der Personen, die über Mitgliedschaft Zugriff erhalten. Zuweisungsfelder und Beziehungen.

4. PIM-Berechtigung zur Aktivierung separat erfassen

Das dokumentierte Beispiel für die Berechtigung zur Aktivierung lautet:

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

Die API liefert Instanzen der Aktivierungsberechtigung und unterstützt Auswahl, Filterung und Erweiterung. Ihre Leseberechtigung mit den geringsten Privilegien ist RoleEligibilitySchedule.Read.Directory; delegierter Zugriff erfordert außerdem eine Operatorrolle. roleEligibilityScheduleInstances auflisten.

Es empfiehlt sich, aktive und aktivierbare Datensätze vor dem Erstellen einer kombinierten Ansicht getrennt zu halten. Gleichen Sie Principal, Definition, Geltungsbereich und relevante Daten ab. Eine leere Liste aktiver Zuweisungen klärt nicht, ob jemand weiterhin zur Aktivierung berechtigt ist; eine Antwort zu Aktivierungsberechtigungen belegt keine historische Nutzung. Dokumentieren Sie genau, welche Frage jeder Datensatz beantwortet.

5. Privilegierte Zuweisungen identifizieren und die API-Version sichtbar halten

Die Learn-Seite zu privilegierten Rollen zeigt dieses optionale Beispiel:

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

Dies ist ausdrücklich eine beta-Anfrage. Schreiben Sie sie nicht stillschweigend auf v1.0 um und suggerieren Sie nicht, dass isPrivileged eine dokumentierte Eigenschaft der oben verwendeten v1.0-Definitionsressource sei. Die Seite beschreibt außerdem die Kennzeichnung PRIVILEGED im Admin Center. Privilegierte Rollen identifizieren.

Erkennung: Zuweisungen, eindeutige Principals und Unbekanntes zählen

Es empfiehlt sich, das folgende Arbeitsblatt je Rolle zu erstellen. Es handelt sich um Berichtsfelder für das Audit, nicht um zusätzliche Microsoft-Grenzwerte:

Gleichen Sie bei einer aktivierten Rolle ohne erfasste Zuweisungen zunächst die IDs ab und bestätigen Sie, dass beide Erfassungspfade erfolgreich waren. Fragen Sie dann den Verantwortlichen, ob die Definition einen geplanten Zweck hat. Beschreiben Sie sie als „aktiviert, ohne erfasste aktive oder aktivierbare Zuweisung“, nicht als „nie verwendet“. Das UNUSED-Prädikat des Collectors prüft die Zugehörigkeit zu den aktuellen Eingabedaten, nicht den Aktivitätsverlauf (azure/privileged-access/roles/unused-admin-role.go:36).

Geben Sie bei der Anzahl von Rolleninhabern an, ob Sie Zuweisungsdatensätze oder eindeutige Principals zählen. Der gemeinsame TOO_MANY-Detektor vergleicht Rollen-IDs und zählt passende Zuweisungseinträge; er dedupliziert keine Personen, filtert keinen Principal-Typ und beschränkt keinen Geltungsbereich (azure/privileged-access/roles/too-many-privileged-roles.go:43). Behandeln Sie sein Ergebnis als Triage-Signal, das dieses Arbeitsblatt benötigt.

Ein Signal in eine überprüfbare Entscheidung überführen

Es empfiehlt sich, jedem Befund eine explizite Entscheidung zuzuordnen: mit Begründung beibehalten, unvollständige Belege untersuchen, eine Zuweisung entfernen, eine Zuweisung einschränken oder eine benutzerdefinierte Definition stilllegen. Dokumentieren Sie die entscheidungsverantwortliche Person und die geprüften Belege. Bewahren Sie das Detektorergebnis neben dieser Entscheidung auf, damit eine operative Ausnahme von einem Messfehler unterscheidbar bleibt.

Fordern Sie bei einem Befund zur Definitionsanzahl einen Berechtigungsvergleich an, bevor Sie eine Konsolidierung empfehlen. Fordern Sie bei einem UNUSED-Befund die Datensätze aktiver und aktivierbarer Zuweisungen an, bevor Sie die Stilllegung empfehlen. Fragen Sie bei einem TOO_MANY-Befund, welche Principals und Geltungsbereiche die Anzahl ergeben haben, bevor Sie eine kleinere Population empfehlen. Diese Fragen folgen den drei oben beschriebenen Prädikaten; keine erfordert ein erfundenes Ausnutzungsergebnis.

Es empfiehlt sich, die Zählregel im Export selbst zu dokumentieren. Erscheint ein Principal in mehreren Geltungsbereichen, erläutern Sie, ob der Bericht diese Zuweisungen separat zählt. Erscheint eine Gruppe, kennzeichnen Sie ihre Zuweisung als Gruppenvergabe und reservieren Sie ein eigenes Feld für Mitgliedschaftsbelege. Konnten Aktivierungsberechtigungen nicht erfasst werden, kennzeichnen Sie die Schlussfolgerung über fehlende Zuweisungen als vorläufig. So wird der Bericht auch für Prüfer nutzbar, die die Erfassung nicht durchgeführt haben.

Legen Sie bereits beim Öffnen eines Befunds die Abschlussbelege fest. Eine Aufgabe zur Stilllegung einer Definition sollte damit enden, dass die genehmigte Definition in einer neuen Inventur fehlt. Eine Aufgabe zum Entfernen einer Zuweisung sollte damit enden, dass genau diese Vergabe im relevanten Datensatz fehlt. Eine beibehaltene Ausnahme sollte einen dokumentierten Zweck und einen zukünftigen Überprüfungstermin aufweisen. Dies sind empfohlene Akzeptanzkriterien für das Audit, keine Aussagen über eine automatische Durchsetzungsfunktion.

Microsoft empfiehlt weniger als fünf Global Administrators und weniger als zehn privilegierte Rollenzuweisungen in der gesamten Organisation. Das sind Governance-Empfehlungen, keine erzwungenen Zuweisungsobergrenzen. Die zitierte Seite belegt keine Obergrenze von zwei bis vier Inhabern je Rolle Application, Exchange, Security, SharePoint oder Privileged Role Administrator. Die Schwellenwerte des Collectors je Rolle sind Produktstandardwerte. Bewährte Verfahren für Microsoft-Entra-Rollen.

Abhilfemaßnahmen: Redundante Definitionen stilllegen und verbleibenden Zugriff steuern (Remediation)

1. Entscheiden, welche benutzerdefinierten Rollen bleiben sollen

Es empfiehlt sich, jede Definition mit dem Dienstverantwortlichen zu prüfen: Welche exakte Operation benötigt sie, welcher engere Geltungsbereich funktioniert und wer verantwortet zukünftige Änderungen? Konsolidieren Sie redundante Definitionen erst nach einem Vergleich ihrer Aktionen und vorgesehenen Zuweisungen. Behalten Sie nützliche benutzerdefinierte Rollen bei, wenn sie den benötigten Berechtigungssatz präziser abbilden als eine integrierte Rolle. Rollenauswahl nach dem Prinzip der geringsten Privilegien.

Behandeln Sie dies als Entscheidungsdokumentation und nicht als Versuch, eine willkürliche Kataloggröße zu erreichen. Erfassen Sie für eine scheinbar leere Definition die Inventare aktiver und aktivierbarer Zuweisungen, bestätigen Sie die Erfassungsqualität und untersuchen Sie geplante Abhängigkeiten, bevor Sie die Stilllegung genehmigen. Wo Zugriff notwendig bleibt, priorisieren Sie den Abbau unnötiger Aktionen zur Verwaltung von Anmeldeinformationen und zu weit gefasster Anwendungsgeltungsbereiche. Benutzerdefinierte Registrierungsberechtigungen.

2. Unnötige Zuweisungen entfernen, dann genehmigte benutzerdefinierte Definitionen löschen

Es empfiehlt sich, die beiden Änderungsentscheidungen zu trennen. Das Entfernen einer Zuweisung betrifft den Zugriff eines Rolleninhabers; die Stilllegung einer Definition betrifft den Rollenkatalog. Microsofts Lösch-API unterstützt benutzerdefinierte Definitionen, verbietet das Löschen integrierter Rollen und dokumentiert diese Syntax:

DELETE /roleManagement/directory/roleDefinitions/{id}

Dies ist eine zitierte Schreiboperation, hier nicht ausgeführt. Ersetzen Sie {id} nur durch die genehmigte ID der benutzerdefinierten Definition. Learn nennt RoleManagement.ReadWrite.Directory als API-Berechtigung mit den geringsten Privilegien und Privileged Role Administrator als unterstützte delegierte Operatorrolle mit den geringsten Privilegien. Ein erfolgreiches Löschen liefert 204 No Content. unifiedRoleDefinition löschen.

Dokumentieren Sie bei einer von UNUSED gemeldeten integrierten Rolle, warum keine Inhaber vorhanden sind und ob die aktivierte Instanz noch relevant ist. Wenden Sie ein Löschverfahren für benutzerdefinierte Definitionen nicht auf jedes UNUSED-Ergebnis an. Es empfiehlt sich, die Inventare der Definitionen und Zuweisungen nach der Änderung zu prüfen, bevor Sie die Änderung abschließen.

3. Begründete Populationen festlegen und geeigneten menschlichen Zugriff zu PIM migrieren

Es empfiehlt sich, für jede Rolle ein Zugriffsbudget anhand der erforderlichen Aufgaben und der betrieblichen Abdeckung mit expliziten Ausnahmen festzulegen. Bewerten Sie die gesamten privilegierten Zuweisungen der Organisation anhand von Microsofts Leitlinien, statt die Collector-Schwellenwerte als verpflichtende Microsoft-Quoten zu behandeln.

PIM unterstützt zeitbasierte und genehmigungsbasierte Aktivierung für integrierte und benutzerdefinierte Entra-Rollen. Der Bereitstellungsplan empfiehlt einen Pilotversuch, die Konfiguration der Einstellungen je Rolle und die Bewahrung von Notfallzugriff. Service Principals können keine aktivierbaren Zuweisungen erhalten; zeitlich begrenzte aktive Zuweisungen sind möglich. Microsofts Plan empfiehlt zwei ausschließlich cloudbasierte Notfallkonten mit dauerhaften Zuweisungen der Rolle Global Administrator. PIM-Bereitstellung planen.

Für geeignete menschliche Zuweisungen empfiehlt es sich, Genehmigung, MFA, Begründung und Dauer vor dem Rollout gegen das vorgesehene Betriebsmodell zu testen. Unser Artikel über Kontrollen für PIM-Aktivierungsgenehmigung, MFA, Begründung und Dauer behandelt diese separate Konfigurationsprüfung.

Bestätigen Sie vor Einführung des Plans die Lizenzierung: Die Verwendung benutzerdefinierter Rollen erfordert P1 für zugewiesene Benutzer, PIM erfordert P2 oder Governance. Zugriffsüberprüfungen für Service Principals benötigen Workload ID Premium zusätzlich zu P2 oder Governance. Lizenzierung benutzerdefinierter Rollen, PIM-Lizenzierung und Rollenleitlinien, Voraussetzungen für PIM-Überprüfungen.

4. Zugriff überprüfen und Entscheidungen anwenden

Wählen Sie in PIM die relevanten Entra-Rollen und Populationen aus, entscheiden Sie sich für aktive Zuweisungen, aktivierbare Zuweisungen oder beide und konfigurieren Sie verantwortliche Prüfer und die Behandlung ausbleibender Antworten. Eine Überprüfung erfasst zu Beginn eine Momentaufnahme; Gruppen mit zuweisbaren Rollen erscheinen ohne Auflösung ihrer Mitglieder. Zugriffsüberprüfungen für Rollen erstellen.

Es empfiehlt sich, den Überprüfungsumfang neben den Ergebnissen aufzubewahren, damit „Überprüfung abgeschlossen“ nicht mit „sämtlicher administrativer Zugriff überprüft“ verwechselt wird. Dokumentieren Sie separate Mitgliedschaftsbelege, wenn eine Rolle einer Gruppe zugewiesen ist. Geben Sie Workload-Verantwortlichen eine für die Dienstidentität geeignete Überprüfungsaufgabe, statt anzunehmen, dass menschliche Aktivierungskontrollen sie abdecken.

Abgelehnter Zugriff wird entfernt, wenn die Überprüfungsergebnisse manuell oder durch konfigurierte automatische Anwendung umgesetzt werden. Die bloße Erfassung einer Ablehnung ist nicht der abschließende Entzugsschritt. Zugriffsüberprüfungen für Rollen abschließen.

5. Das Ergebnis mit denselben Messgrößen überprüfen

Es empfiehlt sich, die dokumentierten Leseoperationen nach Änderungen zu wiederholen und Definitions-IDs, Berechtigungsaktionen, Geltungsbereiche sowie aktive und aktivierbare Zuweisungen zu vergleichen. Prüfen Sie die konkrete genehmigte Änderung: einen entfernten Rolleninhaber, eine eingeschränkte Berechtigung oder eine stillgelegte Definition. Bewahren Sie Ausnahmen und unbekannte Werte auf, statt das Audit allein wegen einer gesunkenen Anzahl als erfolgreich zu erklären.

Wie EtcSec dies erkennt

Die folgenden sieben IDs existieren im Katalog. Ihre Implementierungen wurden in etc-collector beim Commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c gelesen. Die folgenden Pfade sind relativ zu public/internal/audit/detectors/.

CUSTOM verwendet azure/privileged-access/roles/custom-role-excessive.go:24; UNUSED verwendet azure/privileged-access/roles/unused-admin-role.go:36. Alle fünf TOO_MANY-Prüfungen verwenden das gemeinsame Detect() in azure/privileged-access/roles/too-many-privileged-roles.go:43. Ihre jeweiligen too-many-*-admins.go-Konstruktoren legen Schwellenwerte in Zeile 17 und Schweregrade in Zeile 19 fest. Jede Implementierung liefert einen Befund auch bei Count=0; positive Erkennung erfordert Count>0. Oberhalb des Schwellenwerts liefern CUSTOM und TOO_MANY die gesamte passende Anzahl, nicht nur den Überschuss.

Die fünf TOO_MANY-Einträge sind Info mit Gewicht 0 im Katalog, obwohl ihre Konstruktoren High beziehungsweise Critical für Privileged Role Administrator ausgeben. Diese Abweichung wird ausdrücklich beibehalten. Erhöhen Sie nicht stillschweigend den Katalogscore und beschreiben Sie Laufzeitschweregrade nicht als Katalogwerte.

Erfassungsgrenzen beeinflussen die Interpretation

Der geprüfte Provider kombiniert aktive Zuweisungen mit erfassten Aktivierungsberechtigungen anhand von Principal, Rolle und Geltungsbereich (public/internal/providers/azure/client.go:1597, :1626, :1784). Sein Rolleninventar kombiniert aktivierte integrierte Instanzen mit benutzerdefinierten Definitionen, ordnet deren Definitions-IDs RoleTemplateID zu und setzt ihren internen Wert IsEnabled=true, ohne den Aktivierungswert von Graph zu übernehmen (client.go:1500).

Leseoperationen für benutzerdefinierte Definitionen erfolgen nach dem Best-Effort-Prinzip; die geprüften Rollen- und Aktivierungsberechtigungspfade implementieren keine nextLink-Schleifen. HTTP- oder Parsingfehler bei Aktivierungsberechtigungen können eine leere Map liefern (client.go:404). Deshalb kann eine fehlende Erfassung von Aktivierungsberechtigungen ein scheinbares UNUSED-Ergebnis erzeugen oder TOO_MANY-Populationen zu niedrig zählen. Dies sind statische Codebeobachtungen, keine reproduzierten Mandantenfehler.

Schließen Sie das Audit mit getrennten Belegen für die Notwendigkeit der Definition, die Begründung der Rolleninhaber und den wirksamen Entzug ab. Ein unauffälliges Schwellenwertergebnis ist nützlich; die verantwortliche Entscheidung lautet jedoch, ob jede beibehaltene Berechtigung und Zuweisung weiterhin einen dokumentierten Zweck hat.