Microsoft-365-App-Berechtigungen prüfen: Wer darf auf welche Unternehmensdaten zugreifen?

Anwendungen, die mit Microsoft 365 verbunden sind, sollten nicht allein nach Name oder Hersteller bewertet werden. Entscheidend ist, welchen geschäftlichen Zweck sie erfüllen, auf welche Daten sie zugreifen, ob sie im Namen eines Benutzers oder selbstständig handeln und wer intern für ihren Einsatz verantwortlich ist.

Für eine belastbare Prüfung braucht es deshalb mehr als eine Liste aus dem Microsoft-Entra-Portal. Das praktische Ergebnis sollte ein App-Register sein, das technische Berechtigungen mit fachlicher Verantwortung und einem nächsten Prüftermin verbindet. Unklare Anwendungen werden dabei nicht vorschnell gelöscht. Zuerst werden Zweck, Abhängigkeiten und Auswirkungen einer Änderung geklärt.

Warum alte Zustimmungen relevant bleiben

Im Unternehmensalltag werden Testwerkzeuge, Fachanwendungen, Automatisierungen oder externe Dienste mit Microsoft 365 verbunden. Die erteilte Zustimmung kann bestehen bleiben, obwohl ein Projekt beendet wurde, sich der Arbeitsablauf geändert hat oder die ursprünglich verantwortliche Person nicht mehr zuständig ist.

Eine technisch vorhandene Anwendung ist daher nicht automatisch weiterhin erforderlich. Umgekehrt beweist ein unbekannter Name nicht, dass die Anwendung entbehrlich ist. Auch ein bekannter Hersteller beantwortet nicht die Frage, ob gerade diese Anwendung alle angeforderten Rechte benötigt.

Wichtig ist zudem die Abgrenzung von menschlichen Anmeldungen: App-Autorisierungen regeln, welche Funktionen und Daten eine Anwendung verwenden darf. Manche Zugriffe erfolgen im Kontext eines angemeldeten Benutzers, andere ohne eine aktuelle Benutzeranmeldung.

Drei Ansichten mit unterschiedlichen Prüffragen

Bei der ersten Bestandsaufnahme schauen wir nicht nur in eine Anwendungsliste. Drei Bereiche müssen getrennt betrachtet werden.

Enterprise Applications

Unter den Enterprise Applications wird die im eigenen Tenant vorhandene Anwendungsinstanz verwaltet, technisch häufig als Service Principal bezeichnet. Diese Sicht ist für die Zugriffsprüfung besonders wichtig: Hier lässt sich untersuchen, welche Anwendung in der Organisation verwendet wird und welche Zustimmungen für sie bestehen.

Die Ansicht beantwortet jedoch nicht automatisch, warum die Anwendung benötigt wird, welcher interne Prozess von ihr abhängt oder wer die fachliche Verantwortung trägt.

App Registrations

App Registrations enthalten die Definition einer registrierten Anwendung. Sie sind nicht mit der im Tenant verwendeten Enterprise Application gleichzusetzen. Eine selbst entwickelte oder für mehrere Tenants vorgesehene Anwendung kann hier definiert sein, während ihre konkrete Instanz unter Enterprise Applications erscheint.

Eine typische Fehlannahme lautet: Wenn eine Anwendung nicht unter App Registrations erscheint, könne sie keinen Zugriff besitzen. Für eine Inventur reicht diese Ansicht deshalb nicht aus.

Erteilte Einwilligungen

Die Zustimmung zeigt, welche Berechtigungen einer Anwendung tatsächlich gewährt wurden. Dabei sind Einwilligungen einzelner Benutzer und administrativ erteilte Zustimmungen zu unterscheiden. Eine frühere Administratorfreigabe belegt lediglich, dass eine Entscheidung getroffen wurde. Sie sagt nicht, ob Zweck und Umfang heute noch angemessen sind.

Da Microsoft Verwaltungsoberflächen und Bezeichnungen ändern kann, sollten konkrete Navigationswege vor einer Prüfung mit der aktuellen Dokumentation abgeglichen werden.

Delegiert bedeutet nicht automatisch unkritisch

Delegierte Berechtigungen werden verwendet, wenn die Anwendung im Kontext eines angemeldeten Benutzers handelt. Der tatsächlich mögliche Zugriff hängt sowohl von der gewährten App-Berechtigung als auch von den Rechten des Benutzers ab. Delegiert bedeutet daher weder automatisch harmlos noch zwingend auf persönliche Daten begrenzt.

Anwendungsberechtigungen, in Microsoft-Dokumentationen als Application Permissions bezeichnet, ermöglichen den Zugriff ohne aktuell angemeldeten Benutzer. Das kann für Hintergrundprozesse und Integrationen erforderlich sein. Weil die Anwendung selbstständig arbeiten kann, benötigen solche Rechte eine besonders nachvollziehbare Begründung.

Für beide Arten helfen dieselben konkreten Fragen:

• Muss die Anwendung nur während einer Benutzeraktion arbeiten?
• Ist ein selbstständiger Hintergrundzugriff erforderlich?
• Genügt Lesen, oder muss die Anwendung Daten ändern?
• Muss der Zugriff für den gesamten Tenant gelten?
• Sind Postfächer, Dateien oder Verzeichnisinformationen betroffen?
• Ist dokumentiert, warum jede relevante Berechtigung benötigt wird?

Der Name einer Berechtigung genügt nicht für die abschließende Bewertung. Zusätzlich sind Geschäftszweck, Datenarten, Benutzerkreis und technische Arbeitsweise der Anwendung zu betrachten. Bei Unklarheiten gehört auch die Dokumentation des Herstellers in die Prüfung.

Das App-Register verbindet Technik und Verantwortung

Eine Anwendungsliste wird erst dann zu einem brauchbaren Berechtigungsregister, wenn sie die fachlichen Informationen ergänzt. Folgende Struktur lässt sich in eine Tabellenkalkulation oder ein vorhandenes Dokumentationssystem übernehmen:

Fehlen Zweck oder verantwortliche Person, sollte der Status zunächst in Klärung lauten. Das macht die Informationslücke sichtbar, ohne einen möglicherweise benötigten Ablauf unvorbereitet abzuschalten.

Entscheidungshilfe: behalten, einschränken oder abschalten?

Je größer Reichweite und Veränderungsmöglichkeit sind, desto belastbarer sollte die Begründung sein. Besondere Aufmerksamkeit verdienen anwendungsweite Berechtigungen, tenantweite Zustimmungen sowie Schreibzugriffe auf Postfächer, Dateien oder Verzeichnisinformationen. Das ist keine Verbotsliste: Manche Integrationen benötigen solche Rechte für ihren vorgesehenen Zweck. Diese Notwendigkeit muss jedoch nachvollziehbar dokumentiert sein.

Zugriffe kontrolliert zurücknehmen

Das Löschen einer Anwendung sollte nicht der erste Prüfschritt sein. Ein abgestuftes Vorgehen reduziert das Risiko, benötigte Prozesse unkontrolliert zu unterbrechen:

1. Anwendung zuordnen: Name, Hersteller, Geschäftszweck und interne Verantwortung klären.
2. Berechtigungen erfassen: Delegierte und anwendungsweite Rechte getrennt dokumentieren.
3. Abhängigkeiten bestimmen: Betroffene Personen, Prozesse und Daten identifizieren.
4. Notwendigkeit bewerten: Für die Anwendung und jede relevante Berechtigung eine fachliche Begründung prüfen.
5. Änderung vorbereiten: Erwartete Auswirkungen und eine Rückfallmöglichkeit festhalten.
6. Kontrolliert testen: Wenn möglich, die Änderung begrenzt erproben statt sofort zu löschen.
7. Bei Unklarheit deaktivieren: Die Anwendung bleibt für die weitere Untersuchung erhalten, ohne unverändert weitergenutzt zu werden.
8. Zustimmung widerrufen: Nicht mehr benötigte Einwilligungen zurücknehmen und Zeitpunkt sowie Entscheidung dokumentieren.
9. Anwendung entfernen: Erst nach Klärung verbleibender Abhängigkeiten löschen.

Das Entziehen einer einzelnen Berechtigung versetzt nicht jede Anwendung automatisch in einen sicheren und zugleich funktionsfähigen Zustand. Ob eine Integration mit geringerem Umfang weiterarbeitet, muss anhand ihrer technischen Ausgestaltung und des vorgesehenen Arbeitsablaufs geprüft werden.

Ein schlanker Freigabeprozess für neue Anwendungen

Neue Einwilligungsanfragen sollten vor der Zustimmung mindestens folgende Angaben enthalten:

• Name und Hersteller der Anwendung
• konkreter geschäftlicher Zweck
• intern verantwortliche Person
• betroffener Benutzerkreis und betroffene Daten
• angeforderte Berechtigungen und Berechtigungsart
• Begründung für Schreibrechte oder tenantweiten Zugriff
• vorgesehene Nutzungsdauer
• Termin oder Anlass für die nächste Prüfung

Ein handhabbarer Ablauf besteht aus fachlich begründetem Antrag, technischer Prüfung, Klärung weniger weitreichender Alternativen, eindeutiger Entscheidung, dokumentierter Zustimmung und Eintrag in das App-Register.

Ein mögliches, bewusst einfaches Konfigurationsprinzip lautet: Benutzereinwilligungen werden nur in dem für die Organisation vertretbaren Umfang zugelassen; darüber hinausgehende Anfragen durchlaufen einen dokumentierten administrativen Freigabeprozess. Welche Microsoft-Einstellung dazu passt, hängt von den Arbeitsabläufen, den benötigten Anwendungen und der administrativen Organisation ab. Eine pauschale Einstellung ist nicht für jedes Unternehmen geeignet.

Die CISA-Sicherheitsbaseline kann hierfür als Referenz dienen. Sie wurde für US-Bundesbehörden entwickelt und ist keine unverändert zu übernehmende Vorgabe für deutsche KMU.

Änderungen über Auditprotokolle nachvollziehen

Microsoft stellt Auditereignisse für das Erteilen und Entziehen von App-Berechtigungen bereit. Bei der Kontrolle sind insbesondere folgende Fragen relevant:

• Wer hat eine Zustimmung erteilt oder entzogen?
• Wann wurde die Änderung vorgenommen?
• Welche Anwendung war betroffen?
• Gehört die Änderung zu einem dokumentierten Antrag oder einer Freigabe?
• Wurde das App-Register anschließend aktualisiert?

Statt für alle Anwendungen einen unbegründeten identischen Prüfzyklus festzulegen, können konkrete Anlässe verwendet werden: das Ende eines Tests oder Projekts, ein Wechsel der verantwortlichen Person, das Ende einer Dienstleisterbeziehung, ein geänderter Einsatzzweck, zusätzliche Berechtigungsanforderungen oder die Aufgabe eines angebundenen Prozesses. Ergänzend erhält jede Anwendung einen passenden Termin im Register.

Kompakte Prüfliste

Inventur

• [ ] Enterprise Applications erfasst
• [ ] App Registrations nicht mit Anwendungsinstanzen verwechselt
• [ ] Benutzer- und Administratorzustimmungen geprüft
• [ ] delegierte und anwendungsweite Rechte getrennt dokumentiert
• [ ] Geschäftszweck und interne Verantwortung festgehalten
• [ ] betroffene Daten und Benutzerkreise erfasst
• [ ] Status und nächster Prüftermin eingetragen

Bewertung und Rücknahme

• [ ] Jede Berechtigung ist für den dokumentierten Zweck erforderlich
• [ ] ein geringerer Umfang wurde geprüft
• [ ] Schreibrechte und tenantweiter Zugriff sind begründet
• [ ] Hintergrundzugriff ohne angemeldeten Benutzer ist erforderlich
• [ ] Auswirkungen einer Änderung wurden geklärt
• [ ] Verantwortliche wurden einbezogen
• [ ] die Änderung wurde kontrolliert getestet
• [ ] nicht benötigte Zustimmungen wurden widerrufen
• [ ] Entfernung erfolgt erst nach Prüfung der Abhängigkeiten
• [ ] Entscheidung und Änderung sind dokumentiert

Grenzen der Prüfung

Der Beitrag ersetzt weder die Einzelprüfung einer Anwendung noch die Herstellerdokumentation. Aus dem Namen einer Berechtigung lässt sich nicht die vollständige Datenverarbeitung ableiten. Eine Freigabe benötigt daher eine technische und eine fachliche Bewertung.

Behandelt wird ausschließlich die App-Autorisierung in Microsoft 365 beziehungsweise Microsoft Entra. Gastzugriffe, Freigabelinks, Mehrfaktor-Authentifizierung, Passkeys, Offboarding und lokale Administratorrechte sind nicht Gegenstand dieser Prüfung.

Eine sinnvolle Bestandsaufnahme betrachtet Anwendungen und Berechtigungen im Zusammenhang mit Identitäten, Gruppen, E-Mail, Dateien, Teams, Freigaben und Richtlinien. Wenn Sie diese Einordnung im Rahmen Ihrer Microsoft-365-Umgebung gemeinsam vornehmen möchten, ist die Leistung Cloud Native und Microsoft 365 von netzmal der passende Kontaktanlass.