Access Reviews in Microsoft Entra ID: Zugriffe regelmäßig bestätigen oder automatisch entziehen

Wie lassen sich Gruppen-, App- und Gastzugriffe regelmäßig prüfen, ohne versehentlich noch benötigte Berechtigungen zu entfernen? Microsoft Entra Access Reviews können wiederkehrende Prüfungen für unterstützte Gruppen, Enterprise Applications, Access Packages und privilegierte Zugriffe durchführen. Ein sicherer Start verwendet klar benannte Reviewer, einen begrenzten Scope, Empfehlungen nur als Entscheidungshilfe und zunächst keinen automatischen Entzug. Auto-Apply wird erst nach einem erfolgreichen Pilot und dokumentiertem Rückfallweg aktiviert.

Access Reviews lösen ein organisatorisches Problem: Berechtigungen werden häufig beim Eintritt oder Projektstart vergeben, aber bei Rollenwechsel oder Projektende nicht zuverlässig entfernt. Eine Reviewkampagne macht den Ressourcenowner für die weitere Notwendigkeit verantwortlich.

Was Access Reviews prüfen können

Für viele produktive Szenarien rund um Gruppen, Anwendungen und Gastzugriffe wird heute Microsoft Entra ID Governance beziehungsweise Entra Suite benötigt. Einzelne ältere P2-nahe Überschneidungen ändern nichts daran, dass die konkrete Lizenzzuordnung vor einem breiten Rollout tenantbezogen geprüft werden sollte.

Je nach Microsoft-Entra-Funktion, Lizenz und Zielobjekt können Reviews unter anderem betreffen:

• Mitglieder von Gruppen,
• Benutzerzuweisungen zu Enterprise Applications,
• Gastbenutzer in Microsoft-365-Gruppen,
• Zuweisungen aus Entitlement Management,
• Microsoft-Entra- oder Azure-Rollen in PIM-Szenarien.

Nicht jede effektive Berechtigung wird automatisch sichtbar. Direkte SharePoint-Freigaben, verschachtelte Gruppen, lokale Anwendungskonten oder Berechtigungen außerhalb Entra können separate Prüfungen benötigen.

Reviewziel vor Technik definieren

Ein Review benötigt eine klare Frage. Beispiele:

• Benötigt diese Person weiterhin Mitgliedschaft in der Finanzgruppe?
• Darf dieser Gast weiterhin auf das Projektteam zugreifen?
• Ist die Zuweisung zur Enterprise Application noch erforderlich?
• Benötigt der Administrator weiterhin die PIM-Berechtigung?

Unklare Fragen führen zu pauschalem „Genehmigen“, weil Reviewer das Risiko nicht verstehen.

Geeigneten Reviewer wählen

Gruppenowner

Kennt häufig den Ressourcenzweck, aber nicht immer die aktuelle Rolle jedes Mitglieds.

Manager

Kennt die Aufgaben des Mitarbeiters, aber nicht zwingend die technische Bedeutung einer Gruppe oder App.

Benutzer selbst

Kann eigenen Bedarf bestätigen, besitzt aber einen Interessenkonflikt und kennt nicht immer Compliance-Anforderungen.

Application-/Ressourcenowner

Versteht den Zugriff, benötigt jedoch verlässliche Informationen zu Person und Projekt.

Mehrstufige Reviews

Bei kritischen Ressourcen können mehrere Stufen sinnvoll sein, etwa Manager plus App-Owner. Die Konfiguration und Lizenzunterstützung muss geprüft werden.

Die Reviewerwahl sollte zum Reviewziel passen. Für Gäste ist der interne Sponsor oder Gruppenowner oft geeigneter als der Gast selbst.

Einmalig oder wiederkehrend

Wichtig für die Auswertung: Jede Review-Instanz arbeitet mit einem Snapshot zum Startzeitpunkt. Änderungen an Mitgliedschaften oder App-Zuweisungen, die erst nach Beginn erfolgen, tauchen deshalb erst in einer späteren Instanz oder in einer separaten Nachprüfung auf.

Einmaliger Review

Geeignet für eine erste Bereinigung, Auditfeststellung oder Projektabschluss.

Wiederkehrender Review

Geeignet für dauerhafte Governance. Microsoft unterstützt je nach Reviewtyp periodische Intervalle wie monatlich, quartalsweise oder jährlich.

Die Frequenz richtet sich nach Risiko:

• hochprivilegierte Rollen: häufiger,
• geschäftskritische App: regelmäßig,
• kurzlebiges Projekt: zum Projektende,
• stabile Basisgruppe: seltener.

Empfehlungen richtig verwenden

Microsoft Entra kann Empfehlungen anhand von Sign-in-Aktivität oder anderen unterstützten Signalen anzeigen. Bei Inaktivitätsbewertungen kann beispielsweise ein Benutzer ohne Anmeldung im betrachteten Zeitraum als Deny empfohlen werden.

Empfehlungen sind keine vollständige fachliche Entscheidung:

• eine selten genutzte Notfallanwendung kann trotzdem erforderlich sein,
• Service- oder nicht interaktive Nutzung erscheint anders,
• Anmeldeprotokolle besitzen Aufbewahrungs- und Lizenzgrenzen,
• ein Benutzer kann über eine andere Identität zugreifen,
• saisonale Prozesse erzeugen lange Inaktivität.

Reviewer sollten Empfehlung, Ressourcenzweck und Sponsorinformation gemeinsam bewerten.

Entscheidungen und Begründungen

Typische Entscheidungen:

• Approve,
• Deny,
• Don’t know oder keine Antwort, abhängig von Konfiguration.

Für kritische Ressourcen sollte eine Begründung verlangt oder organisatorisch erwartet werden. Approve – arbeitet noch hier ist zu schwach, wenn die Frage den Zugriff auf eine konkrete Anwendung betrifft.

Besser:

• „Weiterhin Projektleiter bis 31.12.; Zugriff auf Projektgruppe erforderlich.“
• „Rollenwechsel abgeschlossen; Finanz-App wird nicht mehr benötigt.“
• „Externer Vertrag verlängert; Sponsor bestätigt Zugriff bis Reviewdatum.“

Umgang mit nicht beantworteten Reviews

Vor Start muss festgelegt werden, was am Ende mit offenen Entscheidungen geschieht:

• Zugriff beibehalten,
• Zugriff entziehen,
• Systemempfehlung übernehmen,
• an einen Fallback-Reviewer eskalieren.

Ein automatischer Entzug bei fehlender Antwort kann sicher wirken, aber Geschäftsprozesse unterbrechen, wenn Reviewer abwesend oder falsch zugeordnet sind. Ein automatisches Beibehalten macht den Review dagegen wirkungslos. Die Entscheidung muss risikobasiert und getestet sein.

Auto-Apply vorsichtig einführen

Wenn Auto-Apply aktiviert ist, kann Microsoft Entra Entscheidungen nach Abschluss auf die Ressource anwenden. Bei Deny wird beispielsweise eine direkte Gruppenmitgliedschaft oder App-Zuweisung entfernt.

Pilot ohne Auto-Apply

1. kleine, gut verstandene Gruppe wählen,
2. Review durchführen,
3. Entscheidungen manuell analysieren,
4. Auswirkungen simulieren,
5. falsche Reviewer oder Empfehlungen korrigieren,
6. Entzug kontrolliert anwenden,
7. Supportfälle beobachten.

Erst danach wird Auto-Apply für geeignete Ressourcen erwogen.

Verschachtelte Gruppen

Wenn Zugriff über eine verschachtelte Gruppe entsteht, kann der Review der Zielressource nicht zwingend die Mitgliedschaft in der Quellgruppe entfernen. Microsoft weist auf Einschränkungen bei indirekten Mitgliedschaften hin. Effektiver Zugriff muss daher nach dem Review getestet werden. Für Reviewer kann die Zielressource verschachtelte Mitglieder zwar sichtbar machen, ein Deny entfernt aber nicht automatisch die Mitgliedschaft in der verschachtelten Quellgruppe.

Gastzugriffe prüfen

Gerade bei Gastzugriffen sollten auch Betriebs- und Vertragsparameter sichtbar bleiben. Je nach Tenant und Vereinbarung können Access Reviews, Entitlement Management und Gastgovernance zusätzliche MAU-basierte Kosten auslösen, obwohl der eigentliche Review technisch unspektakulär wirkt.

Für Gäste können Reviews alle Gastmitglieder bestimmter Gruppen oder andere definierte Scopes betrachten. Optionen können auch die spätere Blockierung oder Entfernung von Gastobjekten unterstützen, abhängig von Konfiguration.

Der Review sollte unterscheiden:

• Gast benötigt Ressource weiterhin,
• Gast verliert Ressourcenzugriff, bleibt aber für andere Projekte,
• Gast besitzt gar keinen Ressourcenbedarf mehr und kann aus dem Tenant entfernt werden.

Das Gastobjekt darf nicht automatisch gelöscht werden, wenn es noch andere Gruppen, Apps oder direkte Freigaben verwendet.

Enterprise Applications

Vor einem App-Review muss die Anwendung sauber in Entra integriert und der Zugriff über nachvollziehbare Zuweisungen abgebildet sein. Wenn Assignment required deaktiviert ist oder die App eigene lokale Autorisierung verwendet, erfasst der Review möglicherweise nicht den vollständigen Zugriff.

Prüfen Sie:

• direkte Benutzer- und Gruppenzuweisungen,
• App Roles,
• nested groups,
• lokale Konten im SaaS-System,
• Provisioning-Status,
• tatsächliche Sign-ins,
• Owner und Fachverantwortliche.

Ein Access Review prüft Benutzerzugriff, nicht die API-Permissions der Anwendung. Dafür ist ein separater App-Consent-Review nötig, siehe App-Berechtigungen und Admin Consent.

Privilegierte Rollen

PIM und Access Reviews können privilegierte Zuweisungen kontrollieren. Der Reviewer muss verstehen, welche Aufgaben die Rolle erlaubt und ob eine kleinere Rolle ausreicht.

Fragen:

• Wurde die Rolle in der letzten Periode aktiviert?
• Ist Nichtnutzung ein Beweis für Entbehrlichkeit oder nur für seltene Notfälle?
• Muss die Zuweisung aktiv oder nur eligible sein?
• Ist der Scope korrekt?
• Gibt es Vertretung und Enddatum?

Typische Fehlerbilder

Reviewer kennt die Gruppe nicht

Ursache ist oft fehlendes Ownership. Stoppen oder korrigieren Sie den Review, benennen Sie einen fachlichen Owner und stellen Sie Beschreibung sowie Ressourcenzweck bereit.

Alle Zugriffe werden pauschal genehmigt

Der Review ist zu groß, zu unverständlich oder ohne Konsequenz. Kleinere Scopes, Risikokategorien, Begründungen und Ownertraining verbessern die Qualität.

Zugriff wurde entzogen, Benutzer hat ihn weiterhin

Mögliche Ursachen:

• verschachtelte Gruppe,
• zweite direkte Zuweisung,
• lokales App-Konto,
• bestehende Sitzung oder Token,
• SharePoint-Direktfreigabe,
• andere Gruppe mit gleicher App Role.

Prüfen Sie effektiven Zugriff end-to-end.

Zugriff wurde fälschlich entzogen

Rückfall:

1. fachlichen Bedarf bestätigen,
2. vorherige Zuweisung aus Review/Audit ermitteln,
3. Mitgliedschaft oder App-Zuweisung kontrolliert wiederherstellen,
4. Benutzeranmeldung testen,
5. Ursache korrigieren – Reviewer, Fallback oder Scope,
6. Ausnahme mit Ablaufdatum dokumentieren.

Review umfasst ausgeschiedene Mitarbeiter, die bereits deaktiviert sind

Das kann ein Hinweis sein, dass JML-Prozesse nicht vollständig entziehen. Access Reviews sollten nicht dauerhaft den fehlenden Leaver-Prozess ersetzen.

Reviewdesign

Für jeden Review dokumentieren:

• Name und Ressource,
• Ziel und Risikoklasse,
• Scope,
• Reviewer und Fallback,
• Start, Dauer und Wiederholung,
• Empfehlungskonfiguration,
• Umgang mit Nichtantwort,
• Auto-Apply,
• Gastentfernung,
• Benachrichtigungen,
• Audit- und Rückfallverfahren,
• Owner des Reviewprogramms.

Testkatalog

1. aktiver Benutzer mit klarem Bedarf,
2. inaktiver Benutzer ohne Bedarf,
3. Benutzer mit indirekter Mitgliedschaft,
4. Gast mit mehreren Ressourcen,
5. Reviewer ist abwesend,
6. Reviewer wählt Deny, Auto-Apply aus,
7. manueller Entzug und Wiederherstellung,
8. Auto-Apply in Pilotgruppe,
9. App-Zugriff trotz entfernter Zuweisung,
10. Review endet mit offenen Entscheidungen,
11. wiederkehrende nächste Instanz,
12. Auditexport und Abschlussbericht.

Betriebskennzahlen

• Reviewabschlussquote,
• unbeantwortete Entscheidungen,
• Anteil pauschaler Genehmigungen,
• entzogene Zugriffe,
• nachträglich wiederhergestellte Zugriffe,
• Ressourcen ohne Owner,
• Gäste ohne Sponsor,
• indirekte Zugriffe, die Review nicht entfernen konnte,
• überfällige oder deaktivierte Reviewserien.

Eine hohe Entzugszahl ist nicht automatisch ein Erfolg. Wichtiger sind richtige Entscheidungen und ein sinkender Bestand veralteter Zugriffe.

Besonders eng verknüpft sind Access Reviews mit Gastkonten und externen Identitäten in Microsoft Entra ID sowie mit dem Benutzerlebenszyklus in Microsoft Entra ID.

So werden historisch gewachsene Zugriffe regelmäßig bereinigt

Access Reviews sind wirksam, wenn die richtige Person eine verständliche Zugriffsfrage beantwortet und die Entscheidung technisch überprüft wird. Pilotierung ohne Auto-Apply, klare Regeln für Nichtantworten, Berücksichtigung indirekter Zugriffe und ein getesteter Rückfall verhindern unnötige Ausfälle. Wiederkehrende Reviews ergänzen Joiner-Mover-Leaver-Prozesse und machen bestehende Berechtigungen zu einer regelmäßig bestätigten Entscheidung.