Der Admin-Consent-Workflow sichert App-Berechtigungen im Tenant ab

Auch 2026 reißen die Fälle von Consent-Phishing nicht ab. In vielen Tenants, die ich mir genauer ansehe, finde ich fragwürdige App-Integrationen. Typisch ist ein Benutzer, der einer App aus Neugier Zugriff auf E-Mails oder Kalender gewährt hat – und schon hat ein Angreifer sensible Daten in der Hand. Denn bis heute dürfen Nutzer bestimmten Drittanbieter-Apps standardmäßig selbst Berechtigungen einräumen. Die meisten Unternehmen unterschätzen diese Lücke und vertrauen darauf, dass ihre Benutzer schon wissen, was sie tun. Wie falsch diese Annahme ist, haben die Vorfälle rund um Midnight Blizzard erneut gezeigt (siehe Blogbeitrag).

Eine eingeschränkte Benutzereinwilligung stoppt den Wildwuchs im Tenant

Mehr Sicherheit beginnt oft mit einer einfachen Konfigurationsänderung. Im Entra Admin Center unter Enterprise-Anwendungen → Consent und Berechtigungen → Benutzereinwilligungseinstellungen wähle ich inzwischen fast immer „Nur verifizierte Herausgeber und Berechtigungen mit geringem Risiko erlauben“ oder gleich „Keine Benutzereinwilligung zulassen“. So wächst die App-Landschaft nicht mehr unkontrolliert, und riskante oder unbekannte Apps gelangen gar nicht erst in den Tenant. Die Einstellung gilt zentral für den gesamten Tenant, Ausnahmen sind nur selten nötig. Die einzelnen Optionen beschreibt Microsoft in der Dokumentation.

Praxistipp: Wer den User Consent bereits eingeschränkt hat, sollte das Application- und Service-Principal-Inventar trotzdem regelmäßig nach alten, zu weit gefassten oder nicht mehr genutzten Einwilligungen durchsuchen. Vor allem Tenants mit langer Cloud-Historie schleppen hier oft eine Menge Altlasten mit sich.

Der Admin-Consent-Workflow schafft einen kontrollierten Weg für Ausnahmen

Ganz ohne Spielraum kommt allerdings kaum ein Unternehmen aus. Manche legitime App benötigt zusätzliche Rechte, etwa für Teams-Integrationen oder Automatisierungen in M365. Für solche Fälle ist der Admin-Consent-Workflow gedacht. Er liegt ebenfalls unter Enterprise-Anwendungen → Consent und Berechtigungen und lässt sich mit wenigen Klicks aktivieren. Stößt ein Benutzer danach auf eine App, die mehr Rechte verlangt, kann er bei festgelegten Prüfern (Reviewern) einen Einwilligungsantrag stellen. Die Reviewer erhalten eine Benachrichtigung, sehen sich den Antrag mit allen Details im Portal an und entscheiden, ob sie ihn genehmigen oder ablehnen. Wie die Einrichtung im Einzelnen funktioniert, erklärt Microsoft in der Anleitung Admin-Consent-Workflow konfigurieren.

Damit der Workflow im Alltag tatsächlich greift, sollte man:

• die Reviewer-Gruppe(n) mit Bedacht zusammenstellen (z. B. Security Admins und Application Owner),
• die Benachrichtigungen regelmäßig prüfen,
• klare Kriterien für Genehmigungen kommunizieren,
• jede Entscheidung dokumentieren (z. B. im Ticketsystem).

Den Ablauf des Prozesses zeigt die folgende Übersicht:

flowchart TD
  Benutzer["Benutzer entdeckt App"] --> Antrag["Antrag auf Admin-Consent"]
  Antrag --> Reviewer["Reviewer prüfen Antrag"]
  Reviewer --> Entscheidung["Genehmigung oder Ablehnung"]
  Entscheidung --> Admin["Admin erteilt Consent (bei Genehmigung)"]
  Entscheidung --> KeineConsent["Kein Consent (bei Ablehnung)"]

Abbildung: Ablauf des Admin-Consent-Workflows mit Prüfung durch die Reviewer

In der Praxis sehe ich häufig, dass der Prozess zwar technisch eingeschaltet ist, sich aber niemand um die Reviewer-Gruppe kümmert oder auf die Benachrichtigungen reagiert. Dann verpufft der Schutz. Wer den Workflow dagegen konsequent umsetzt, behält den Überblick und kann jede Einwilligung nachvollziehbar dokumentieren.

Bereits erteilte Einwilligungen verdienen einen zweiten Blick

Anschließend lohnt es sich, die bereits vergebenen Rechte unter die Lupe zu nehmen. Im Entra Admin Center unter Enterprise-Anwendungen → Berechtigungen lässt sich auflisten, welche Apps Nutzer- oder Admin-Einwilligungen erhalten haben. Dort kann man bestehende Grants auch gezielt entziehen. Besonders heikel ist die Kombination aus weitreichenden Rechten („Mail.ReadWrite“, „User.Read.All“) und nicht verifizierten Herausgebern.

Seit Midnight Blizzard vorgeführt hat, wie sich kompromittierte OAuth-Apps für Angriffe nutzen lassen, hat dieser Punkt noch mehr Gewicht bekommen. Wie man auffällige App-Berechtigungen erkennt und bewertet, beschreibe ich ausführlicher in der Blogreihe zu App Governance. Wer Microsoft Defender for Cloud Apps oder die App-Governance-Funktionen lizenziert hat, sollte die App-Governance-Warnungen unbedingt aktivieren und regelmäßig abarbeiten. Sie melden riskante oder ungewöhnliche App-Aktivitäten, die mit Bordmitteln kaum auffallen würden.

Die Freigabe von App-Rechten bleibt ein fortlaufender Prozess

Den Admin-Consent-Workflow sehe ich nicht als Häkchen, das man einmal setzt und dann vergisst. Er ist eine dauerhafte Aufgabe. Technisch ist er in wenigen Minuten aktiviert, wirklich sicher wird der Tenant aber erst, wenn die Reviewer ihre Verantwortung ernst nehmen und App-Governance fest zu den Standardprozessen gehört. Bei den heutigen Angriffsmethoden ist die restriktivste Einstellung oft die beste. Deshalb gehört die Prüfung von App-Einwilligungen künftig in jeder Cloud-Sicherheitsstrategie zum Pflichtprogramm.