Für jede relevante Anwendung braucht Ihre IT drei Antworten: Wofür wird sie genutzt? Auf welche Daten und Funktionen darf sie zugreifen? Wer kann Änderungen an diesem Zugriff fachlich freigeben? Fehlt eine Antwort, ist die Anwendung noch nicht ausreichend eingeordnet.
Die vier Prüfschritte
1. Bestand erfassen. App Registrations, Enterprise Applications und weitere Dienstidentitäten zusammenführen.
2. Erteilte Rechte prüfen. Anzeigenamen und angeforderte Berechtigungen allein reichen nicht.
3. Zweck und Verantwortliche klären. Nur mit dem fachlichen Bedarf lassen sich Rechte bewerten.
4. Änderungen testen. Nach einer Anpassung müssen die benötigte Funktion und die Zugriffsgrenze stimmen.
Dieser Artikel behandelt Anwendungszugriffe auf Microsoft 365 und Entra ID. Eine vollständige Prüfung von Code, Architektur oder Lieferanten ersetzt er nicht.
App Registrations zeigen nicht alle Anwendungszugriffe
Die Registrierung einer Anwendung kann beim Anbieter liegen, während sie in Ihrem Mandanten Rechte besitzt. Bei Ihnen erscheint dann die Enterprise Application, also der lokale Dienstprinzipal. Nehmen Sie deshalb neben Ihren eigenen App Registrations auch Unternehmensanwendungen und weitere Dienstidentitäten in den Bestand auf.
| Begriff | Bedeutung für Ihre Prüfung |
|---|---|
| App Registration | Beschreibt die Anwendung in ihrem Heimatmandanten, einschließlich ihrer Authentifizierungseinstellungen. |
| Enterprise Application | Lokale Instanz der Anwendung im Mandanten, auch Dienstprinzipal genannt. Hier sind erteilte Rechte und Zuweisungen zu prüfen. |
| Managed Identity | Weitere Dienstidentität, die bei der Prüfung von Anwendungszugriffen gesondert zu betrachten ist. |
Führen Sie eigene App Registrations und relevante Enterprise Applications zusammen. Verwenden Sie dafür App- und Dienstprinzipal-IDs statt Anzeigenamen. Ordnen Sie jeder Identität einen Geschäftszweck zu und kennzeichnen Sie ungeprüfte Teile des Bestands. Microsoft Learn, Anwendungen und Dienstprinzipale, abgerufen am 18.09.2026.
Welche Rechte wurden wirklich erteilt?
Prüfen Sie die Rechte der Unternehmensanwendung in Ihrem Mandanten: delegierte Berechtigungen, Anwendungsberechtigungen und weitere Rollenzuweisungen. Microsoft Learn, Anwendungsberechtigungen verwalten, abgerufen am 18.09.2026. Die in der App Registration angeforderten Berechtigungen allein zeigen nicht, welche Zugriffe genehmigt wurden.
Welche Anwendungsrechte sollten Sie zuerst prüfen?
Beginnen Sie bei Anwendungen, die ohne angemeldeten Benutzer auf sensible Daten zugreifen, Identitäten oder Berechtigungen ändern können oder keinen benannten Verantwortlichen haben. Ein weitreichendes Recht belegt keinen Missbrauch. Es verdient aber eine genauere Prüfung.
| Anlass | Mögliche Wirkung | Zu klären |
|---|---|---|
AppRoleAssignment.ReadWrite.All | Kann zusätzliche Anwendungsrechte vergeben | Ist diese Fähigkeit erforderlich und ausdrücklich genehmigt? |
Application.ReadWrite.All | Kann unter anderem Zugangsdaten anderer Anwendungen verwalten | Welche anderen Identitäten und Rechte werden dadurch erreichbar? |
Mail.ReadWrite als Anwendungsberechtigung | Erlaubt weitreichende Verarbeitung von Nachrichten ohne angemeldeten Benutzer | Welche Postfächer braucht die Anwendung, und ist eine Einschränkung wirksam? |
| Schreibrechte auf Benutzer oder Gruppen | Können Identitäts- und Zugriffsprozesse beeinflussen | Welche konkreten Objekte und Vorgänge benötigt die Anwendung? |
| Kein dokumentierter Verantwortlicher | Eine fachliche Entscheidung über benötigte Rechte ist nicht nachvollziehbar | Wer übernimmt die Klärung, und bis wann? |
Microsoft warnt bei den beiden zuerst genannten Rechten vor einer möglichen Ausweitung von Berechtigungen. Wichtig bei Mail.ReadWrite: das Recht erlaubt nicht automatisch das Versenden von E-Mails. Microsoft Graph, Berechtigungsreferenz, abgerufen am 18.09.2026.
Ein Recht ist noch kein Befund über die Nutzung
Der Berechtigungsname zeigt, was technisch möglich sein kann. Bewerten Sie auch Geschäftszweck, Ressourcengrenzen, weitere Rechte und die Anmeldung der Anwendung.
Führt Group.ReadWrite.All automatisch zu Global-Administrator-Rechten?
Nein. Um Mitglieder zu rollenzuweisbaren Gruppen hinzuzufügen, sind weitere Berechtigungen nötig. Group.ReadWrite.All allein reicht dafür nicht. Unterscheiden Sie im Bericht zwischen einem vorhandenen Recht, einem möglichen Weg zu weiteren Rechten und einem anhand der Konfiguration nachgewiesenen Weg. Keiner dieser Befunde belegt für sich genommen einen Angriff. Microsoft Graph, Gruppenmitglieder hinzufügen, abgerufen am 18.09.2026.
Warum Benutzer-MFA App-only-Zugriffe nicht absichert
Eine Anwendung kann im Namen eines Benutzers oder mit eigener Identität handeln. Im ersten Fall nutzt sie delegierte Rechte. Bei App-only-Zugriffen meldet sie sich ohne Benutzer an und nutzt eigene Berechtigungen. Eine MFA-Anforderung für Benutzer schützt diesen Zugriff nicht automatisch. Beide Zugriffsarten können bei derselben Anwendung vorkommen.
| Zugriffsart | Was geprüft werden muss |
|---|---|
| Delegiert | Die Anwendung handelt im Namen eines Benutzers. App-Berechtigung und Berechtigungen des Benutzers wirken zusammen. |
| Anwendungsberechtigung | Die Anwendung handelt als eigene Identität ohne angemeldeten Benutzer. Entscheidend sind ihre eigenen Rechte. |
Für App-only-Zugriffe meldet sich der Dienst selbst an, etwa mit einem Secret, Zertifikat oder föderierten Identitätsnachweis. Die Zustimmung zu seinen Rechten ersetzt die Anmeldung nicht. Auch wenn im Kundenmandanten kein Secret sichtbar ist, kann der Anbieter eigene Zugangsdaten verwenden. Microsoft Learn, Berechtigungen und Einwilligung und Client-Credentials-Flow, abgerufen am 18.09.2026.
Das geänderte Kennwort eines früheren Administrators entzieht einer Anwendung keine eigenständig erteilten Rechte. Prüfen Sie App-Rechte und Anmeldedaten getrennt.
Gibt es Conditional Access und Protokolle für solche Dienste?
Für Workloadidentitäten gibt es eigene Richtlinien. Prüfen Sie, welche Dienstprinzipale Ihre Richtlinien erfassen. Conditional Access für Workloadidentitäten unterstützt bestimmte eigene Single-Tenant-Dienstprinzipale. Microsoft-Apps, SaaS-Anwendungen von Drittanbietern (einschließlich Multi-Tenant-Apps) und Managed Identities sind von diesen Richtlinien nicht abgedeckt. Workloadidentitäten können keine Benutzer-MFA durchführen.
Anmeldungen ohne Benutzer sind nicht grundsätzlich unsichtbar: Für Dienstprinzipale gibt es eigene Protokolle. Prüfen Sie, welche davon verfügbar sind. Microsoft Learn, Conditional Access für Workloadidentitäten und Dienstprinzipal-Anmeldungen, abgerufen am 18.09.2026.
Klären Sie, welche Protokolle Ihre IT auswertet, wie weit sie zurückreichen und wer Auffälligkeiten bearbeitet. Eine fehlende Anmeldung im betrachteten Zeitraum allein ist kein Grund, eine Anwendung zu löschen.
Was gehört in einen App-Steckbrief?
Ein App-Steckbrief verbindet technische Befunde mit dem Geschäftszweck. Erfassen Sie Herkunft, Fachverantwortliche, App- und Dienstprinzipal-ID, erteilte Rechte, Anmeldeverfahren, betroffene Ressourcen und deren Begrenzungen. Halten Sie auch Nutzung oder verfügbare Protokolle, Abhängigkeiten und den nächsten Prüftermin fest.
Fiktives Muster, kein Kundenbefund
| Feld | Ausgefülltes Muster |
|---|---|
| Geschäftszweck | Anbindung eines CRM für die Vertriebsarbeit |
| Herkunft | Anwendung eines externen Anbieters, lokaler Dienstprinzipal im eigenen Mandanten |
| Befund | Mail.ReadWrite als Anwendungsberechtigung ist dokumentiert. Die wirksame Postfachbegrenzung wurde noch nicht vollständig geprüft. |
| Fachlich benötigter Umfang | Muss durch den Verantwortlichen für das CRM verbindlich festgelegt werden |
| Verantwortlichkeit | Im Steckbrief ist niemand benannt. Ob es im Unternehmen eine verantwortliche Person gibt, ist noch zu klären. |
| Noch anzufordernde Belege | Erteilte Rechte, Exchange-seitige Autorisierung, freigegebene Zielpostfächer, technische Funktionsanforderungen des Anbieters |
| Bewertung | Weitreichendes Recht belegt. Die Übereinstimmung mit dem benötigten Zugriff ist noch nicht beurteilbar. |
| Entscheidung | Verantwortlichen benennen und benötigte Funktionen festlegen, Einschränkung mit Anbieter und Betrieb planen |
| Nachprüfung | Nach freigegebener Umsetzung Geschäftsfunktion und Zugriffsgrenze gezielt prüfen |
Das erteilte Recht Mail.ReadWrite zeigt nicht, welche Postfächer die App liest oder ob ihr Zugriff wirksam begrenzt ist. Prüfen Sie die Grenze in Exchange und klären Sie, welche Postfächer das CRM benötigt.
So lässt sich der Befund formulieren:
Die Anwendung hat ein weitreichendes Recht auf Postfächer. Ob ihr Zugriff wirksam begrenzt ist, wurde noch nicht geprüft. Die Aussage, dass sie auf jedes Postfach zugreifen kann, ist damit nicht belegt. Offen sind der fachlich benötigte Umfang und die verantwortliche Person.
Warum begrenzt eine Benutzerzuweisung App-only-Zugriffe nicht?
Zugewiesene Benutzer zeigen nicht, welche Postfächer eine App mit eigener Identität lesen oder verändern darf. Benutzerzuweisungen, API-Anwendungsrechte und Exchange-seitige Begrenzungen sind getrennt zu prüfen. Lassen Sie sich die wirksame Grenze des Datenzugriffs zeigen. Microsoft Learn, erteilte Berechtigungen und RBAC für Anwendungen in Exchange Online, abgerufen am 18.09.2026.
Rechte begrenzen, ohne den Betrieb zu unterbrechen
Entfernen Sie Rechte nicht allein aufgrund einer Portalliste. Klären Sie zuerst Zweck, Abhängigkeiten und benötigte Funktionen. Legen Sie für jede Änderung fest, wer sie freigibt, wie sie zurückgenommen wird und wie Sie Funktion und Zugriffsgrenze testen.
Die Abnahme muss beides zeigen: Die Anwendung funktioniert weiterhin, und Zugriffe außerhalb des freigegebenen Bereichs scheitern.
| Befund | Empfohlene Maßnahme | Abnahmefrage |
|---|---|---|
| Geschäftszweck unklar | Fachverantwortlichen, Vertragsbezug und technische Abhängigkeiten klären | Kann jemand den weiteren Betrieb begründen und freigeben? |
| Rechte umfangreicher als erforderlich | Benötigte Funktionen und minimal geeignete Berechtigungen bestimmen | Funktioniert die Anwendung mit dem freigegebenen Umfang? |
| Ressourcengrenze fehlt | Einen vom jeweiligen Dienst unterstützten Begrenzungsmechanismus prüfen | Ist Zugriff außerhalb des freigegebenen Bereichs wirksam ausgeschlossen? |
| Unsichere oder auslaufende Zugangsdaten | Authentifizierungsverfahren und geregelten Wechsel planen | Ist der Wechsel getestet und verantwortlich zugeordnet? |
| Stilllegung vorgesehen | Abhängigkeiten bestätigen, Änderung und Rückfallweg festlegen | Sind verbleibende Rechte und Zugänge nachvollziehbar behandelt? |
Wie lässt sich der Zugriff auf Exchange-Postfächer begrenzen?
Bei Exchange-Zugriffen müssen Sie neben den Entra-Berechtigungen auch die Autorisierung in Exchange prüfen. Mit RBAC for Applications lassen sich unterstützte Rechte auf bestimmte Ressourcen begrenzen. Microsoft führt es als Nachfolger der Application Access Policies. Eine neue begrenzte Zuweisung hebt einen bereits erteilten unbeschränkten Zugriff nicht auf.
Testen Sie nach der Änderung, ob die Anwendung weiter funktioniert und Zugriffe außerhalb des erlaubten Bereichs scheitern. Test-ServicePrincipalAuthorization prüft nur die RBAC-Seite; separat in Entra ID erteilte Rechte berücksichtigt es nicht. Microsoft Learn, Exchange Application RBAC, abgerufen am 18.09.2026.
Zugangsdaten verbessern und Rechte getrennt prüfen
Prüfen Sie, ob eine Managed Identity oder eine geeignete föderierte Identität möglich ist. Falls nicht, empfiehlt Microsoft Zertifikate statt Client Secrets. Microsoft Learn, Sicherheitsempfehlungen für App-Registrierungen, abgerufen am 18.09.2026. Private Schlüssel müssen geschützt und Zertifikate rechtzeitig erneuert werden. Ein Zertifikat verringert nicht automatisch die erteilten API-Rechte. Anmeldung und Berechtigungsumfang sind getrennt zu prüfen.
Neue Zustimmungen begrenzen, bestehende Rechte prüfen
Legen Sie fest, welche Berechtigungen Benutzer selbst genehmigen dürfen und wann Fachbereich und IT entscheiden. Microsoft Learn, Benutzerzustimmung konfigurieren, abgerufen am 18.09.2026. Halten Sie bei jeder Freigabe Zweck, Rechte, verantwortliche Person und nächsten Prüftermin fest. Neue Zustimmungsregeln entfernen bereits erteilte Rechte nicht.
Welche Nachweise braucht die IT-Leitung?
Eine Exportliste allein hilft bei der Entscheidung wenig. Fassen Sie für jede relevante Anwendung Identität, Zweck, Verantwortliche, erteilte Rechte, Anmeldeverfahren und Ressourcengrenzen zusammen. Ergänzen Sie Nutzung oder Protokollstand, offene Punkte und die nächste Entscheidung.
| Nachweis | Mindestinhalt für die Entscheidung |
|---|---|
| Identität | Mandant, App-ID, lokale Dienstprinzipal-ID und Herkunft |
| Berechtigungen | Ziel-API, Berechtigungsart, tatsächlich erteilte Rechte und relevante weitere Rollenzuweisungen |
| Reichweite | Betroffene Ressourcen, dokumentierte Grenzen und offene Punkte |
| Verantwortlichkeit | Fachverantwortliche, technischer Betrieb und eingetragene App-Owner getrennt benannt |
| Authentifizierung | Verfahren, Laufzeiten und Zuständigkeit für Änderungen; keine Geheimnisse im Bericht |
| Nutzung | Ausgewertete Protokollquelle, Zeitraum und Ergebnis, Beobachtungslücken vermerkt |
| Entscheidung | Beibehalten, reduzieren, weiter untersuchen oder stilllegen, mit Begründung und Verantwortlichem |
| Prüfnachweis | Test-ID, Methode, Prüfdatum, Belegreferenz und Ergebnis der Nachprüfung |
Trennen Sie Beleg und Bewertung. Ein weitreichendes Recht kann eindeutig nachgewiesen sein und gerade deshalb Handlungsbedarf auslösen. Ein fehlender Beleg bestätigt dagegen keinen Angriff. Wie weit Entra-Protokolle zurückreichen, hängt unter anderem von Lizenz und Datenart ab. Prüfen Sie den Zeitraum, bevor Sie eine vollständige Historie der Zustimmungen zusagen. Microsoft Learn, Datenaufbewahrung, abgerufen am 18.09.2026.
Ein Termin allein prüft keine Rechte. Beim Review muss jemand entscheiden, welche Berechtigungen weiterhin benötigt werden, und die Entfernung überflüssiger Rechte kontrollieren.
Wann sollten Sie erneut prüfen?
Prüfen Sie bei neuen Rechten, einem Betreiberwechsel, geändertem Zweck, auffälliger Aktivität oder geplanter Stilllegung erneut. Legen Sie zusätzlich einen regelmäßigen Termin passend zum Risiko fest. Auch App-Owner brauchen Kontrolle: Sie können Anwendungen weitreichend verwalten. Microsoft empfiehlt, ihre Zahl zu begrenzen und die Zuweisungen regelmäßig zu prüfen. Microsoft Learn, Sicherheitsleitlinien für App Registrations, abgerufen am 18.09.2026.
Wann hilft eine externe Bestandsaufnahme?
Externe Unterstützung kann helfen, wenn viele App Registrations und Enterprise Applications über Jahre gewachsen sind, Verantwortliche fehlen oder die Reichweite erteilter Rechte unklar ist. Gibt es bereits ein gepflegtes App-Register mit aktuellen Rechten, Verantwortlichen und Prüfungen, kann Ihre IT den Bestand selbst bewerten.
Die hochzwei Nachweisakte prüft unter anderem App-Registrierungen, erteilte Zustimmungen, Graph-Berechtigungen, Owner und Laufzeiten von Zugangsdaten. Ergebnisse werden mit Test-ID, Methode und Prüfdatum dokumentiert. Umfang, Ablauf und Preise stehen auf der Produktseite.
Die Nachweisakte ist weder Audit noch Penetrationstest und vergibt kein Zertifikat. Sie ersetzt auch keine laufende Erkennung und Bearbeitung von Sicherheitsvorfällen. Wie die Ergebnisse in einen Fragebogen einfließen, steht in den Artikeln zum Cyberversicherungs-Fragebogen und zum Lieferantenfragebogen.
Häufige Fragen
Was ist der Unterschied zwischen App Registration und Enterprise Application?
Die App Registration beschreibt die Anwendung in ihrem Heimatmandanten. Die Enterprise Application ist der Dienstprinzipal in Ihrem Mandanten. Bei einer Anbieter-App kann die Registrierung außerhalb Ihrer Umgebung liegen. Prüfen Sie deshalb beide Objekte.
Reicht MFA aus, um Anwendungszugriffe abzusichern?
Nein. Eine App kann ohne angemeldeten Benutzer mit eigener Identität auf Daten zugreifen. Prüfen Sie ihr Anmeldeverfahren, ihre erteilten Rechte und die verfügbaren Schutzmaßnahmen gesondert.
Ist eine Anwendung mit weitreichenden Rechten bereits kompromittiert?
Nein. Ein Recht beschreibt zunächst eine technische Möglichkeit. Ob die Anwendung missbraucht oder übernommen wurde, erfordert eine eigene Untersuchung.
Müssen wir jede alte App Registration sofort löschen?
Nein. Ein alter Eintrag kann noch zu einem produktiven Prozess gehören. Prüfen Sie Nutzung, erteilte Rechte und Verantwortlichkeit. Planen Sie eine Stilllegung mit Abhängigkeiten, Rückfallweg und Kontrolle der verbleibenden Rechte.
Reicht ein Zertifikat statt eines Client Secrets?
Nicht allein. Ein Zertifikat kann die Anmeldung besser absichern; der private Schlüssel muss geschützt werden. Die erteilten Rechte bleiben davon unberührt. Prüfen Sie deshalb auch den Berechtigungsumfang.
Was liefert die Prüfung für einen Kunden- oder Versicherungsfragebogen?
Die Prüfung dokumentiert erteilte App-Rechte und untersuchte Zugriffsgrenzen. Ob das die konkrete Frage beantwortet, hängt vom gefragten Umfang ab. Nennen Sie im Antwortentwurf auch ungeprüfte oder offene Punkte.
Über den Autor
Manuel Fetscher ist Geschäftsführer der hochzwei tech GmbH. Dieser Beitrag behandelt Anwendungsidentitäten in Entra ID, ihre Berechtigungen und die Kontrolle von Zugriffen auf Microsoft 365.
Technische Aussagen stützen sich auf die jeweils verlinkte Microsoft-Dokumentation, abgerufen am 18.09.2026. Priorisierung, Entscheidungstabellen und Prüfaufträge sind redaktionelle Empfehlungen von hochzwei. Der App-Steckbrief ist ein konstruiertes Beispiel und enthält keine gemessenen Kundenwerte und keine Aussage über Häufigkeiten. Der Artikel behandelt Zugriffe auf Microsoft 365 und Entra ID. Für die vollständige Sicherheitsprüfung einer selbst entwickelten Anwendung sind weitere Prüfungen nötig.