Entra Entitlement Management Zugriffspakete: gesteuerter Pilot

Was sind Entra Entitlement Management Zugriffspakete?

Entra Entitlement Management Zugriffspakete machen aus einer klar definierten geschäftlichen Aufgabe einen gesteuerten Zugriffsantrag. Ein sinnvolles erstes Paket beantwortet praktische Fragen: Welche Ressourcen benötigt diese Aufgabe, wer verantwortet die Entscheidung, wer darf Zugriff beantragen und wann soll die Zuweisung enden? Beginnen Sie mit einem Projekt, dessen Ressourcenverantwortliche diese Antworten erläutern und beim Testen helfen können.

Microsoft beschreibt ein Paket als Bündel von Ressourcenzugriffen, das durch Richtlinien gesteuert und in einem Katalog verwaltet wird. Unterstützte Ressourcen sind Gruppen, Unternehmensanwendungen und SharePoint Online-Websites. Richtlinien legen die Berechtigung zur Antragstellung, die Genehmigung und die Zuweisungsdauer fest. Kataloge bilden einen Rahmen für die Delegation. Pakete können Mitarbeitenden oder externen Benutzern dienen. Diese Konzepte stammen aus der Microsoft Learn-Übersicht zu Entitlement Management.

Ein fehlendes Paket ist eine Konfigurationsbeobachtung, die untersucht werden sollte. Es belegt nicht, dass Ihre Organisation über keine Zugriffsgovernance verfügt. Möglicherweise gibt es bereits einen dokumentierten Antragsdienst, Genehmigungen durch Ressourcenverantwortliche und zuverlässige Verfahren zum Entzug von Zugriff. Bewerten Sie diesen Prozess anhand des geschäftlichen Bedarfs, bevor Sie entscheiden, ob Entitlement Management ihn verbessern würde.

Funktionsweise: den gesteuerten Pilotversuch abgrenzen

Betrachten Sie ein Projektteam, das eine bestimmte Anwendungsrolle und Zugriff auf Projektdokumente benötigt. Dies ist ein beispielhaftes Planungsszenario, kein gemessener Befund in einem Mandanten. Halten Sie die vorgesehenen Benutzer, Ressourcen, Berechtigungsstufen, genehmigende Person und Endbedingung fest, bevor Sie den Assistenten öffnen. Lassen Sie jeden Ressourcenverantwortlichen bestätigen, dass der vorgeschlagene Zugriff für die Aufgabe ausreicht und nicht weiter reicht als nötig.

Begrenzen Sie den Pilotversuch so, dass Sie jede enthaltene Berechtigung erklären können. Bündeln Sie keinen sachlich unverbundenen Zugriff, nur weil die Ressourcen zur selben Abteilung gehören. Dokumentieren Sie die Person, die das Paket pflegt, und die für jede Ressource verantwortliche Person. Diese Zuständigkeiten können bei unterschiedlichen Personen liegen; die Übergabe ist wichtig, wenn sich eine Ressource ändert oder ein Projekt endet.

Die Übersicht stellt Pakete ausdrücklich neben andere Zuweisungsmechanismen. Sie eignen sich für zeitlich begrenzte Aufgaben, genehmigungspflichtigen Zugriff und Zusammenarbeit; sie ersetzen nicht jede bestehende Zuweisungsmethode. Vergleichen Sie Ihren Pilotversuch mit gewöhnlicher Gruppenmitgliedschaft und dem bestehenden Serviceantragsprozess. Wählen Sie den Mechanismus, mit dem der Verantwortliche den richtigen Zugriff genehmigen und dessen Entzug nachweisen kann. Microsoft Learn: Wann Zugriffspakete verwendet werden sollten.

Dynamische Mitgliedschaft und gesteuerter Zugriff beantworten ebenfalls unterschiedliche betriebliche Fragen. Eine attributbasierte Auswahl kann eine Benutzerpopulation bestimmen, während eine Paketrichtlinie regelt, wie diese Population eine bestimmte Zugriffsberechtigung erhält. Unser Artikel zur Abschaffung des memberOf-Operators behandelt dynamische Mitgliedschaft und Abhängigkeiten der automatischen Zuweisung in Entitlement Management. Prüfen Sie damit bestehende Zuweisungslogik, bevor Sie einen antragsbasierten Pilotversuch entwerfen. Gehen Sie dabei nicht davon aus, dass die Migration einer Gruppenregel Nachweise für Genehmigung oder Ablauf liefert.

Lizenzierung und administrative Voraussetzungen prüfen

Die Lizenzanforderungen in der Learn-Übersicht nennen Microsoft Entra ID Governance oder Microsoft Entra Suite für Benutzer der Organisation und erklären, dass einige Funktionen mit Microsoft Entra ID P2 genutzt werden können. Behandeln Sie dies als funktionsbezogene Lizenzprüfung und nicht als allgemeine Aufforderung, ein bestimmtes Abonnement zu erwerben.

Die Tabelle zu den Grundlagen der Governance-Lizenzierung führt Self-Service-Anträge von Benutzern, Gruppen, Anwendungen, SharePoint-Websites, Vorgesetzte oder bestimmte Personen als Genehmigende sowie den Ablauf von Zuweisungen sowohl unter P2 als auch unter Governance und Suite auf. Richtlinien zur automatischen Zuweisung und Sponsoren aus Benutzerprofilen als Genehmigende erfordern laut dieser Tabelle Governance oder Suite. Governance-Produkte setzen zudem bestimmte Abonnements voraus; für die Governance von Gästen gelten gesonderte Abrechnungsaspekte. Prüfen Sie die vorgesehenen Funktionen und die berechtigte Benutzerpopulation anhand der aktuellen Learn-Dokumentation, bevor Sie den Pilotversuch aktivieren. Leiten Sie eine Nutzungsberechtigung nicht allein daraus ab, dass irgendwo im Mandanten eine Lizenz vorhanden ist.

Konzentrieren Sie den ersten Test auf menschliche Benutzer und gewöhnliche Projektressourcen. Wenn Sie später erweiterte Funktionen hinzufügen, prüfen Sie Lizenzierung und delegierte Berechtigungen erneut, statt die Annahmen des Pilotversuchs zu übernehmen. Dokumentieren Sie die Lizenzentscheidung zusammen mit dem Paketentwurf, damit der nächste Verantwortliche nachvollziehen kann, welche Entscheidungen bewusst getroffen wurden.

Erkennung: feststellen, ob Pakete fehlen

Prüfen Sie im Microsoft Entra admin center ID Governance > Entitlement management > Access package, den im Erstellungsleitfaden dokumentierten Pfad. Bestätigen Sie das Verzeichnis und Ihre Sichtbarkeit, bevor Sie eine leere Ansicht interpretieren. Halten Sie Beobachtungsdatum, beobachtende Person und Umfang zusammen mit dem Inventar fest.

Für ein API-Inventar dokumentiert Microsoft unter List accessPackages folgende Anfrage:

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

Die API liefert Pakete aus allen Katalogen zurück, die der Aufrufer lesen darf. Die Berechtigungstabelle führt EntitlementManagement.Read.All als OAuth-Berechtigung mit den geringsten Privilegien für delegierten und Anwendungszugriff auf; delegierte Aufrufer benötigen außerdem eine unterstützte Rolle. Für Aufrufer mit reinem Anwendungszugriff unterstützt Microsoft auch die Zuweisung einer geeigneten Rolle anstelle dieser Anwendungsberechtigung; Catalog reader ist eine weniger privilegierte Option. Katalogbezogener Zugriff kann einschränken, was der Aufrufer sieht. Eine erfolgreiche leere Antwort stützt daher nur dann die Aussage, dass im gesamten Mandanten keine Pakete existieren, wenn der Erfassungsumfang die Kataloge des Mandanten abdeckt. Schließen Sie die Aufzählung einschließlich aller zurückgegebenen Fortsetzungslinks ab, bevor Sie ein Inventar als vollständig dokumentieren.

Die Graph-Dokumentation zur accessPackage-Ressource beschreibt den Katalog des Pakets, seine Zuweisungsrichtlinien und die Beziehungen zu Ressourcenrollen. Das Auflisten von Paketobjekten prüft deren Existenz; um zu beurteilen, ob ein Paket den vorgesehenen Zugriff abbildet, müssen diese Beziehungen gesondert untersucht werden.

Die obige Anfrage ist eine dokumentierte Prüfmethode, keine für diesen Artikel gegen einen Kundenmandanten ausgeführte Abfrage. Bewahren Sie den tatsächlichen Status, den Erfassungsumfang und die Antwort Ihres autorisierten Audits auf. Ein Authentifizierungsfehler, Autorisierungsfehler, unterbrochener Lauf oder ungeprüfter Umfang gehört als Einschränkung der Erfassung in die Nachweise. Keiner dieser Fälle rechtfertigt die Aussage „keine Pakete konfiguriert“.

Behebung: das Paket erstellen und seinen Lebenszyklus nachweisen (Remediation)

1. Katalog und Ressourcenrollen auswählen

Folgen Sie dem Learn-Erstellungsablauf: Wählen Sie New access package, geben Sie unter Basics den Namen und die Beschreibung ein und wählen Sie den Katalog. Identity Governance Administrator, catalog owner oder access package manager können innerhalb ihres autorisierten Umfangs Pakete erstellen. Access package managers verwenden Ressourcen, die bereits im Katalog enthalten sind; sie können ihm keine Ressourcen hinzufügen. Wählen Sie unter Resource roles die vorgesehenen Ressourcen und Rollen.

Wählen Sie den Katalog bewusst und nennen Sie dessen verantwortlichen Eigentümer in Ihrer Pilotdokumentation. Verwenden Sie eine Beschreibung, anhand derer Antragsteller die geschäftliche Aufgabe erkennen können. Lassen Sie die Ressourcenverantwortlichen die ausgewählten Rollen prüfen, bevor Sie fortfahren. Eine Gruppeneigentümerrolle unterscheidet sich wesentlich von einer Mitgliedschaft, und eine Anwendungsadministratorrolle kann für gewöhnliche Projektarbeit unnötig sein. Prüfen Sie die tatsächliche Berechtigung und nicht nur den Anzeigenamen der Ressource.

2. Antragsteller und Genehmigende festlegen

Konfigurieren Sie unter Requests die berechtigten Benutzer und Genehmigungseinstellungen der ersten Richtlinie. Verlangen Sie für den Pilotversuch eine Genehmigung, wählen Sie die dafür bestimmte Person aus und verlangen Sie eine Antragsbegründung. Wenn Sie die Vorgesetztenoption verwenden, konfigurieren Sie eine Ersatzperson für fehlende Vorgesetzteninformationen. Wählen Sie unter Who can request access die Option Self für diesen von Benutzern beantragten Pilotzugriff. Diese Steuerelemente sind in den Genehmigungseinstellungen des Erstellungsleitfadens dokumentiert.

Bevorzugen Sie eine klar definierte Pilotpopulation gegenüber einem breiten Antragstellerkreis. Fragen Sie die genehmigende Person, welche Informationen sie für eine Entscheidung benötigt und ob sie einen unangebrachten Antrag erkennen kann. Testen Sie mit einem berechtigten Benutzer und einem Benutzer außerhalb des vorgesehenen Kreises. Halten Sie die erwarteten Entscheidungen vor dem Test fest, damit Sie einen Richtlinienfehler von einer missverstandenen Anforderung unterscheiden können.

Prüfen Sie bei externer Zusammenarbeit außerdem Conditional Access für Gäste und Einstellungen für externe Zusammenarbeit. Dieser Artikel behandelt den Schutz von Gastanmeldungen, Einladungen, Sichtbarkeit und Lebenszykluskontrollen. Nutzen Sie ihn, um die umgebenden Kontrollen für die externe Population einzuordnen; eine Paketgenehmigung allein dokumentiert diese umfassendere Prüfung nicht.

3. Ablauf vor dem Erstellen des Pakets konfigurieren

Wählen Sie unter Lifecycle einen Zuweisungsablauf nach Datum oder Dauer und entscheiden Sie, ob Verlängerungen zulässig sind und eine Genehmigung erfordern. Prüfen Sie die Konfiguration unter Review + create und wählen Sie anschließend Create, um das Paket und die erste Richtlinie zu erstellen. Dies sind die dokumentierten Erstellungsschritte.

Leiten Sie die Endbedingung aus dem geschäftlichen Zeitplan der Aufgabe ab. Verwenden Sie für den Pilotversuch eine Testzuweisung, deren geplanter Ablauf innerhalb Ihres Prüfzeitraums liegt. Stimmen Sie diesen Zeitpunkt mit dem Ressourcenverantwortlichen ab. Dokumentieren Sie, wie berechtigte Verlängerungen behandelt werden und wer darüber entscheidet. Lassen Sie eine Zuweisung nicht allein deshalb dauerhaft bestehen, weil das Testen des Ablaufs mehr Abstimmung erfordert.

4. Bereitgestellten Zugriff und anschließend abgelaufenen Zugriff prüfen

Microsofts Leitfaden zur Zuweisungsverwaltung dokumentiert Assignments, die Details einzelner Zuweisungen und die Statusfilter Delivering und Expired. Bereitstellungsfehler lassen sich über den entsprechenden Eintrag unter Requests untersuchen. Sammeln Sie anhand dieser Ansichten Nachweise für den tatsächlichen Zustand der Testzuweisung.

Stellen Sie den Pilotantrag über den konfigurierten Genehmigungsweg. Dokumentieren Sie Antragsteller, ausgewählte Richtlinie, Entscheidung, Zuweisungskennung und vorgesehenen Endzeitpunkt. Prüfen Sie, ob der Testbenutzer die vorgesehene Ressourcenrolle erhält und die erlaubte Aufgabe ausführen kann. Testen Sie außerdem eine aussagekräftige Aktion, die der Benutzer nicht ausführen dürfen sollte. Eine erfolgreiche Anmeldung allein sagt wenig darüber aus, ob die zugewiesene Rolle angemessen ist.

Erfassen Sie nach dem geplanten Ablauf die abgelaufene Zuweisung und prüfen Sie den Ressourcenzugriff erneut. Vergleichen Sie Mitgliedschaft, Anwendungszuweisung und die Fähigkeit des Benutzers, die Aufgabe auszuführen, mit den früheren Nachweisen. Falls Zugriff bestehen bleibt, untersuchen Sie andere Zuweisungen, bevor Sie behaupten, das Paket habe versagt oder der Ablauf habe jeden effektiven Zugriff entfernt. Derselbe Benutzer kann eine separate Zugriffsberechtigung haben, die Ihr Pilotversuch nie entziehen sollte.

Bewahren Sie beide Beobachtungen in der Pilotdokumentation auf. „Paket erstellt“ ist ein Einrichtungsmeilenstein; „genehmigter Zugriff bereitgestellt, anschließend Zuweisung abgelaufen und vorgesehener Ressourcenzugriff entzogen“ ist das Prüfergebnis, das Sie nachweisen möchten. Dieser Artikel behauptet nicht, dass ein solcher Test bereits in einem Mandanten erfolgreich war.

Wie EtcSec dies erkennt

Der Detektor AZ_ENTITLEMENT_MANAGEMENT von EtcSecs etc-collector bewertet anhand von AzureAccessPackagesProbed und AzureAccessPackagesCount, ob bei der Erfassung Pakete gefunden wurden. Das untersuchte Detect() hat folgende Zweige:

Das Count: 1 des Befunds bezeichnet die Anzahl der Befunde auf Mandantenebene, nicht die Anzahl betroffener Benutzer oder fehlender Richtlinien. Ein nil-Ergebnis bestätigt weder Ressourcenauswahl, Genehmigende, Antragstellerkreis, Lizenzierung, Ablauf noch Zugriffsentzug. Der Detektor prüft die Existenz und nicht die Qualität der Richtlinien. Ein Befund fehlender Pakete beweist ebenfalls nicht, dass jeder alternative Governance-Prozess fehlt.

Leiten Sie aus dem Ergebnis die passende Untersuchung ab: Erfassungsabdeckung bei Info, eine geschäftliche und lizenzbezogene Bewertung bei Medium sowie eine separate Lebenszyklusprüfung, wenn bereits Pakete existieren. Bewahren Sie die Nachweise für Bereitstellung und Ablauf des Pilotversuchs zusammen mit dem Audit auf, damit die nächste Prüfung zwischen einem beseitigten Existenzbefund und nachgewiesener Zugriffsgovernance unterscheiden kann.