App-Berechtigungen und Admin Consent prüfen: Überprivilegierte Anwendungen erkennen

Wie lässt sich prüfen, ob eine Enterprise Application oder App Registration zu viele Rechte besitzt? Zuerst wird unterschieden, ob die Anwendung delegierte Berechtigungen im Kontext eines Benutzers oder Application Permissions ohne Benutzerkontext verwendet. Danach werden tatsächlicher Geschäftsprozess, benötigte API-Aktionen, erteilter Consent, Eigentümer, Anmeldeprotokolle und technische Credentials geprüft. Nicht benötigte Berechtigungen werden nach einem kontrollierten Test entzogen.

Eine Berechtigungsbezeichnung allein zeigt nicht das gesamte Risiko. Entscheidend sind Reichweite, Datentyp, Benutzerkontext, Mandantenscope, Credential-Sicherheit und die Frage, ob die Anwendung ihre Rechte automatisiert und dauerhaft nutzen kann.

Delegated Permissions und Application Permissions

Delegated Permissions

Die Anwendung handelt im Kontext eines angemeldeten Benutzers. Der effektive Zugriff ergibt sich aus den App-Berechtigungen und den Rechten des Benutzers. Ein Benutzer kann der App nicht automatisch mehr Zugriff verschaffen, als er selbst besitzt – dennoch können breit delegierte Scopes erhebliche Datenzugriffe erlauben.

Application Permissions

Die Anwendung handelt als eigene Identität ohne angemeldeten Benutzer. Sie authentifiziert sich beispielsweise mit Zertifikat, Secret, Managed Identity oder federierter Identität. Application Permissions erfordern in der Regel Administratorzustimmung und können tenantweit wirken.

Warum app-only besonders geprüft werden muss

Ein Dienst kann rund um die Uhr zugreifen, ohne dass ein Benutzer interaktiv bestätigt. Wird das Credential kompromittiert, kann ein Angreifer die erteilten App-Rechte nutzen. Deshalb gehören Application Permissions und Credentials in denselben Reviewprozess. Ergänzend lohnt sich ein Blick auf Secrets und Zertifikate von Entra-Anwendungen überwachen, weil Berechtigungen und Anmeldeinformationen zusammen bewertet werden müssen.

Permission Request und tatsächlicher Consent

Eine App Registration listet angeforderte Berechtigungen. Damit sind sie noch nicht automatisch im Tenant wirksam. Der Consent erzeugt den tenantbezogenen Berechtigungszustand am Service Principal.

Prüfen Sie beide Ebenen:

• Welche Berechtigungen fordert die Appdefinition an?
• Welche wurden im eigenen Tenant tatsächlich genehmigt?
• Für welche Ressource, etwa Microsoft Graph oder eine eigene API?
• Delegiert oder Application?
• Von wem und wann wurde Consent erteilt?
• Wird die Berechtigung im Code tatsächlich benötigt?

User Consent und Admin Consent

Ist im Tenant risikobasierter Step-up-Consent aktiviert, können Benutzer neu registrierten, unverifizierten Multi-Tenant-Apps in der Regel nicht mehr selbst weitreichende Berechtigungen erteilen. Solche Anforderungen gehören in den Admin-Prozess und sollten dort mit Hersteller-, Daten- und Berechtigungsprüfung behandelt werden.

Microsoft Entra erlaubt die Steuerung, wann Benutzer selbst Zustimmung erteilen dürfen. Eine restriktive Konfiguration kann User Consent auf Apps verifizierter Herausgeber und ausgewählte, risikoarme Berechtigungen begrenzen. Für blockierte Anforderungen kann ein Admin-Consent-Workflow eingerichtet werden.

Das Ziel ist nicht, jede App pauschal zu blockieren. Ein kontrollierter Prozess ermöglicht produktive SaaS-Nutzung, ohne dass einzelne Benutzer unbemerkt weitreichende Datenzugriffe freigeben.

Publisher Verification richtig einordnen

Publisher Verification zeigt, dass Microsoft die Identität eines Herausgebers anhand des vorgesehenen Programms verifiziert hat. Das ist ein Vertrauenssignal, aber keine vollständige Sicherheits- oder Datenschutzprüfung.

Trotz verifiziertem Publisher müssen geprüft werden:

• tatsächliche Berechtigungen,
• Vertrags- und Datenschutzlage,
• Datenverarbeitung und Hosting,
• Geschäftsbedarf,
• Hersteller-Sicherheitsinformationen,
• Incident- und Löschverfahren.

Eine unverifizierte App ist nicht automatisch schädlich; bei einem internen Entwickler kann sie erwartbar sein. Sie benötigt aber eine besonders klare Eigentümer- und Herkunftsprüfung.

Admin-Consent-Workflow aufbauen

Reviewer in einem Admin-Consent-Workflow erhalten durch ihre Rolle nicht automatisch die technischen Rechte zum Genehmigen. Sie prüfen und empfehlen, die tatsächliche Freigabe muss anschließend ein ausreichend privilegierter Administrator durchführen. Gerade bei Microsoft-Graph-Application-Permissions kann dafür im Einzelfall Global Administrator nötig sein.

Ein vollständiger Workflow umfasst:

1. Benutzer stellt Anfrage mit fachlicher Begründung.
2. Reviewer prüft Hersteller, App, Permissions und Zielgruppe.
3. Fachverantwortlicher bestätigt Bedarf.
4. Datenschutz/Security werden bei relevanten Rechten beteiligt.
5. Technischer Test erfolgt in kontrollierter Umgebung oder Pilotgruppe.
6. Berechtigter Administrator erteilt oder verweigert Consent.
7. Benutzer- und Gruppenzuweisungen werden gesetzt.
8. Review- und Ablaufdatum werden dokumentiert.

Nicht jeder Reviewer darf jede Berechtigung genehmigen. Microsoft-Rollen unterscheiden sich; besonders Microsoft-Graph-Application-Permissions können höhere Administratorrechte erfordern. Die aktuellen Rollenvoraussetzungen müssen geprüft werden.

Berechtigungen fachlich bewerten

Für jede Permission werden folgende Fragen beantwortet:

• Welche API-Operation benötigt der Prozess?
• Reicht eine spezifischere Permission?
• Muss die App tenantweit oder nur für bestimmte Objekte zugreifen?
• Kann delegierter Zugriff statt Application Permission verwendet werden?
• Gibt es Application Access Policies, Resource-Specific Consent oder andere Eingrenzungen für das Zielsystem?
• Welche Daten können gelesen, verändert oder gelöscht werden?
• Werden privilegierte Verzeichnisobjekte oder Mailboxen erreicht?
• Wie wird Missbrauch erkannt?

Beispiel

Eine Anwendung soll Kalendertermine eines Funktionspostfachs lesen. Eine breite Graph-Application-Permission kann technisch funktionieren, aber mehr Postfächer erreichen als nötig. Je nach Workload sollte geprüft werden, ob der Zugriff auf konkrete Ressourcen begrenzt werden kann.

Bestandsaufnahme vorhandener Consents

Erfassen Sie pro Service Principal:

• App- und Service-Principal-ID,
• Hersteller und verifizierter Publisher,
• Eigentümer,
• delegierte Grants,
• App Role Assignments/Application Permissions,
• Zielressourcen,
• Benutzer-/Gruppenzuweisungen,
• Sign-in-Aktivität,
• Credentials und Ablaufdaten,
• letzter fachlicher Review.

Microsoft Graph und Portalansichten können unterschiedliche Teilinformationen liefern. Für große Tenants ist ein automatisierter Export sinnvoll.

Risikokategorien

Hohes Risiko

• Verzeichnis-, Rollen- oder Authentifizierungsverwaltung,
• tenantweiter Mail-, Datei- oder Chat-Zugriff,
• Schreib- oder Löschrechte auf viele Objekte,
• Application Permissions mit langlebigem Secret,
• App ohne Eigentümer,
• unbekannter Publisher und fehlender Vertrag.

Mittleres Risiko

• breite Leserechte mit klarer Anwendung,
• delegierte Rechte für große Nutzergruppen,
• externe SaaS-App mit gut dokumentiertem Zweck,
• selten überprüfter Consent.

Niedrigeres Risiko

• minimale Sign-in- und Profildaten,
• enge Zielgruppe,
• verifizierter und vertraglich geprüfter Anbieter,
• keine App Credentials im Kundentenant,
• regelmäßige Reviews.

Die Kategorie muss tenant- und prozessbezogen bewertet werden.

Typische Fehlerbilder

Benutzer sieht „Need admin approval“

Die angeforderte Berechtigung ist für User Consent nicht zulässig oder die Tenant-Policy blockiert die App. Der Benutzer sollte eine Consent-Anfrage stellen, nicht nach einem Administrator suchen, der spontan global zustimmt.

Admin Consent wurde erteilt, App funktioniert trotzdem nicht

Mögliche Ursachen:

• falscher Tenant,
• falsche API oder Permission,
• App fordert Token für falsche Ressource an,
• Benutzer-/Gruppenzuweisung fehlt,
• Credential oder Redirect URI fehlerhaft,
• Application Code verwendet delegated statt app-only oder umgekehrt,
• Consent ist nicht für die erwartete App-/Service-Principal-Instanz vorhanden.

Permission entfernt, Anwendung funktioniert weiter

Bestehende Tokens können bis zu ihrem Ablauf weiterwirken. Außerdem kann ein anderer Grant oder eine andere App-Instanz vorhanden sein. Prüfen Sie Tokenlebenszyklus, Service Principal, Consentobjekte und tatsächliche API-Aufrufe.

App ist ungenutzt, aber niemand traut sich zu löschen

Nutzen Sie einen gestuften Prozess:

1. Owner ermitteln,
2. Sign-ins und Abhängigkeiten prüfen,
3. neue Anmeldungen oder Zuweisungen blockieren,
4. Beobachtungszeitraum,
5. Consent widerrufen,
6. Credentials deaktivieren,
7. erst danach löschen.

Sicherer Entzug von Berechtigungen

Vorbereitung

• aktuelle Grants exportieren,
• Abhängigkeiten und Testfälle dokumentieren,
• Owner und Fachbereich informieren,
• Rollback-Verfahren festlegen,
• Testzeitfenster vereinbaren.

Entzug

Entfernen Sie die konkrete nicht benötigte Berechtigung oder widerrufen Sie Consent. Bei app-only Zugriff kann zusätzlich das Credential rotiert oder deaktiviert werden.

Test

• erwartete Funktion ohne die Permission,
• Fehlerprotokoll der Anwendung,
• Tokenneuausstellung,
• Zugriffsversuch auf nicht mehr erlaubte Ressource,
• weiterhin benötigte Funktionen.

Rollback

Microsoft dokumentiert Möglichkeiten, widerrufene Berechtigungen erneut zu erteilen. Eine Wiederherstellung kann über erneuten Admin Consent oder gezielte Graph-/PowerShell-Operationen erfolgen. Deshalb muss der vorherige Zustand dokumentiert sein.

Admin Consent für eigene APIs

Bei eigenen APIs definieren Entwickler Scopes oder App Roles. Prüfen Sie:

• verständliche Namen und Beschreibungen,
• minimale Rechte,
• wer Zustimmung erteilen darf,
• Preauthorization nur für bekannte Clients,
• Trennung von Lesen, Schreiben und Administration,
• Claims und serverseitige Autorisierung.

Consent allein ersetzt keine Autorisierungsprüfung in der API. Die API muss Tokenziel, Tenant, Client, Scopes oder Rollen validieren.

Betrieb und regelmäßige Reviews

Ein Review sollte mindestens quartals- oder risikobasiert prüfen:

• neue Consents,
• neue Application Permissions,
• Apps ohne Sign-in-Aktivität,
• Apps ohne Owner,
• unverifizierte Publisher,
• auslaufende oder ungenutzte Credentials,
• Benutzerzuweisungen,
• Hersteller- oder Vertragsänderungen,
• dokumentierten Zweck.

Access Reviews können Benutzerzugriffe auf Enterprise Applications prüfen. Sie ersetzen nicht den Permission-Review der Anwendung selbst.

Testkatalog

1. Benutzer mit zulässigem User Consent.
2. Benutzer mit blockierter Permission und Admin-Consent-Anfrage.
3. Reviewer lehnt Anfrage ab.
4. Reviewer genehmigt kontrollierte App.
5. delegated Token enthält erwarteten Scope.
6. app-only Token enthält erwartete App Role.
7. Zugriff außerhalb der benötigten Ressource scheitert.
8. Consent wird widerrufen und Token erneuert.
9. Rollback erteilt Permission erneut.
10. App ohne Owner wird erkannt und blockiert.

Wer Objektmodell und Berechtigungszustand auseinanderhalten will, sollte zusätzlich Enterprise Applications und App Registrations unterscheiden lesen. Für die laufende Benutzerzugriffsprüfung ergänzt Access Reviews in Microsoft Entra ID das Consent-Thema.

So wird aus App Consent ein kontrollierter Freigabeprozess

Ein sicherer Consent-Prozess verbindet technische Permission-Analyse mit fachlichem Bedarf, Eigentum und wiederkehrender Prüfung. Delegated und Application Permissions werden getrennt bewertet, Publisher Verification nur als Signal genutzt und Berechtigungsentzug mit realen Tests abgesichert. Dadurch bleiben Anwendungen nutzbar, ohne dass tenantweite Rechte unbemerkt wachsen.