Azure App-Registrierungen: Sicherheitsrisiken

Azure App-Registrierungen gehören zu den Stellen im Tenant, an denen Berechtigungen am leichtesten unsichtbar werden. Eine App-Registrierung wirkt wie ein technisches Detail einer Integration, doch ihr Service Principal kann Microsoft-Graph-Anwendungsberechtigungen, aktive Anmeldeinformationen und tenant-weite Zugriffspfade besitzen, die nicht von einem angemeldeten Benutzer abhängen.

Was sind Azure App-Registrierungs-Risiken?

Azure App-Registrierungen sind die Identitätsobjekte hinter benutzerdefinierten Anwendungen, Automatisierungen, Integrationen und vielen SaaS-Verbindungen von Drittanbietern in Microsoft Entra ID. Sie können sich gegenüber Microsoft Graph, Azure-Ressourcen und anderen geschützten APIs authentifizieren.

Das Risiko entsteht, wenn diese Anwendungen mehr Berechtigungen behalten, als sie benötigen, Anmeldeinformationen länger als nötig aufbewahren oder lange nachdem der ursprüngliche Owner nicht mehr hinschaut im Tenant verbleiben. In diesem Zustand verhält sich die Anwendung wie eine dauerhaft privilegierte Identität – mit deutlich weniger alltäglicher menschlicher Sichtbarkeit als ein administratives Benutzerkonto.

Eine gute Überprüfung besteht nicht nur darin, eine einzelne gefährliche Berechtigung zu finden. Es geht darum nachzuweisen, welche Anwendungen aktiv sind, welche davon hochprivilegierten Anwendungszugriff besitzen, wer sie besitzt und wie ihre Anmeldeinformationen verwaltet werden.

So funktioniert es

App-Registrierungen authentifizieren sich in der Regel mit einem von zwei Anmeldeinformationstypen:

• Client Secrets
• Zertifikate

Die Anwendung handelt anschließend gemäß den Berechtigungen, die ihrem zugehörigen Service Principal gewährt wurden.

Zwei grundlegende Berechtigungsmodelle sind dabei relevant:

• delegierte Berechtigungen, bei denen die App im Kontext eines angemeldeten Benutzers agiert
• Anwendungsberechtigungen, bei denen die App als sie selbst agiert, ohne dass ein Benutzer anwesend ist

Die Microsoft-Graph-Dokumentation macht den Unterschied explizit deutlich: Anwendungsberechtigungen sind reine App-Berechtigungen, die ohne angemeldeten Benutzer genutzt werden. Eine Daemon-App oder ein Backend-Dienst kann sie verwenden, um APIs im eigenen Namen aufzurufen. Besitzt die App eine weitreichende Anwendungsberechtigung, wird der Explosionsradius durch diese Berechtigung und die Ressource bestimmt – nicht durch die aktuelle Sitzung eines interaktiven Benutzers.

Die risikoreichsten Fälle sind meist Anwendungsberechtigungen, die weitreichenden tenant-weiten Datenzugriff oder Verzeichnisänderungsrechte gewähren. Erlangt ein Angreifer die App-Anmeldeinformationen, erbt er jede API-Macht, die die App bereits besitzt.

Azure App-Registrierungen: Was sie hochriskant macht

Das gefährliche Muster ist meist eine Kombination, kein einzelnes Kästchen:

• weitreichende Anwendungsberechtigungen wie tenant-weiter Zugriff auf Postfächer, Dateien oder Verzeichnisse
• Anmeldeinformationen, die langlebig, schwach rotiert oder an mehreren Stellen kopiert sind
• kein klarer Owner für die App oder ihren Service Principal
• keine aktuelle Anmeldeaktivität, was darauf hindeutet, dass die App verwaist, aber weiterhin vertrauenswürdig ist
• Admin-Consent, der vor langer Zeit erteilt wurde, ohne wiederkehrende Überprüfung

Deshalb ist eine Berechtigungsprüfung ohne Owner-Prüfung unvollständig. Eine App mit moderaten Berechtigungen und ohne Owner kann dennoch zu einem ernsten Vorfall werden, wenn das Secret geleakt wird und niemand die Anmeldungen bemerkt.

Eine zweite praktische Unterscheidung ist ebenfalls wichtig: Manche Apps sind riskant, weil sie schreiben oder administrieren können, andere sind riskant, weil sie unbemerkt große Mengen an Tenant-Daten lesen können. Beide Fälle verdienen eine Überprüfung, selbst wenn das Portal sie als unterschiedliche Berechtigungssets kennzeichnet.

Berechtigungsfakten, die das Risiko verändern

Behandeln Sie nicht jede Graph-Berechtigung als austauschbar. Microsoft dokumentiert, dass Anwendungsberechtigungen ohne angemeldeten Benutzer funktionieren können und dass manche Berechtigungen organisationsweiten Zugriff auf die zugehörigen Daten erlauben. Eine weitreichende Datei-, Mail-, Verzeichnis- oder Application-Management-Berechtigung kann beispielsweise schädlicher sein als eine delegierte Berechtigung, die nur innerhalb einer eingeschränkten Benutzersitzung wirkt.

Application-Management-Berechtigungen verdienen besondere Aufmerksamkeit. Die Berechtigungsreferenz von Microsoft Graph warnt, dass Berechtigungen, die Anmeldeinformationen verwalten können, einer Anwendung erlauben, als andere Entitäten zu agieren und deren gewährte Rechte zu nutzen. Das ist eine andere Risikoklasse als eine App, die nur ihr eigenes Profil liest.

Auch Admin-Consent gehört zur Kontrollgrenze. Anwendungsberechtigungen können ausschließlich von einem Administrator zugestimmt werden, niemals von einem Endbenutzer. Speziell für Microsoft-Graph-Anwendungsberechtigungen dokumentiert Microsoft, dass nur Privileged Role Administrator und Global Administrator zustimmen können; Application Administrator und Cloud Application Administrator können Anwendungsberechtigungen außerhalb von Microsoft Graph zustimmen. Fehlt im Tenant eine wiederkehrende Überprüfung admin-genehmigter Anwendungen, kann das effektive Zugriffsmodell über Jahre hinweg abdriften, nachdem das ursprüngliche Projekt längst beendet ist.

Die Angriffskette

Schritt 1 – App-Registrierungen und ihre Berechtigungen erfassen

Connect-MgGraph -Scopes 'Application.Read.All'

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"
  $appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

  [PSCustomObject]@{
    AppName      = $app.DisplayName
    AppId        = $app.AppId
    Created      = $app.CreatedDateTime
    SecretExpiry = ($app.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime
    Permissions  = ($appRoles | ForEach-Object { "$($_.ResourceDisplayName):$($_.AppRoleId)" }) -join ', '
  }
} | Where-Object { $_.Permissions -ne '' }

Schritt 2 – Die sensibelsten Kombinationen priorisieren

Konzentrieren Sie sich zunächst auf Anwendungen, die weitreichende Tenant-Berechtigungen mit veralteten Anmeldeinformationen oder unklarer Ownership kombinieren. Service Principals, die direkt Entra-Admin-Rollen besitzen, sind ein separater und oft schlimmerer Fall, der in Entra Service Principal: Überprivilegierte Admin-Rolle erkennen und beheben behandelt wird.

Eine sinnvolle Priorisierungsreihenfolge:

1. Anwendungen mit Anwendungsberechtigungen für Microsoft-Graph- oder Exchange-Workloads
2. Anwendungen mit App-Management- oder Directory-Management-Berechtigungen
3. Service Principals mit aktiven Anmeldeinformationen, aber ohne Nachweis aktueller Anmeldungen
4. Apps mit mehreren aktiven Secrets oder Zertifikaten, für die kein Owner eine Erklärung liefern kann
5. Apps mit Admin-Consent, aber ohne aktuellen Business Owner

Schritt 3 – Die Anmeldeinformationen erlangen

Client Secrets werden häufig über Code-Repositories, Deployment-Pipelines, lokale Konfigurationsdateien oder kopierte Betriebsnotizen offengelegt. Das Problem ist nicht, dass Secrets theoretisch leaken können. Das Problem ist, dass viele Tenants für hochwertige Apps immer noch auf langlebige Secrets setzen.

Schritt 4 – Sich als App authentifizieren und den Scope nutzen

import msal

app = msal.ConfidentialClientApplication(
    client_id='APP_CLIENT_ID',
    client_credential='STOLEN_SECRET',
    authority='https://login.microsoftonline.com/TENANT_ID'
)
result = app.acquire_token_for_client(scopes=['https://graph.microsoft.com/.default'])
token = result['access_token']

Ab diesem Punkt wird der Angriffspfad durch die der App bereits gewährten Berechtigungen bestimmt – nicht durch einen neuen Admin-Exploit.

Erkennung

Entra-Audit- und Anmeldesignale

Microsoft dokumentiert Service-Principal-Anmeldeprotokolle getrennt von interaktiven und nicht-interaktiven Benutzeranmeldungen. Diese Protokolle sind wichtig, weil bei einer reinen App-Authentifizierung kein menschlicher Benutzer beteiligt ist. Microsoft dokumentiert außerdem, dass diese Ereignisse aggregiert werden: Anmeldungen werden in einer einzigen Zeile zusammengefasst, wenn Service-Principal-Name oder -ID, Status, IP-Adresse und Ressourcenname oder -ID übereinstimmen – erweitern Sie also eine Zeile, bevor Sie schlussfolgern, dass sich eine App nur einmal angemeldet hat. Managed-Identity-Anmeldungen erscheinen nicht in diesem Protokoll; sie haben ihr eigenes. Für Erkennungsmuster, die speziell auf diesem Protokoll basieren, siehe Entra Service Principal Anmeldeanomalie-Erkennung: Workload-Identity blinde Flecken.

Praktische Prüffragen

• welche Apps Anwendungsberechtigungen mit tenant-weiter Reichweite besitzen
• welche Apps mehrere aktive Secrets oder alte, nie entfernte Secrets haben
• welche Apps keine aktuelle Anmeldung aufweisen, aber weiterhin privilegierten Zugriff behalten
• welche Apps keinen aktiven Owner oder Business-Sponsor haben
• welche Apps Anwendungen, Service Principals, Anmeldeinformationen, Grants oder Rollenzuweisungen verwalten können

SIEM-Erkennungsabfrage (Elastic KQL)

data_stream.dataset: "azure.auditlogs"
    and azure.auditlogs.operation_name: "Add service principal credentials"
    and event.outcome: "success"

Verwenden Sie den Aktivitätsnamen exakt so, wie Microsoft ihn in der Audit-Activity-Referenz veröffentlicht. Eine Anmeldeinformation, die am Application-Objekt hinzugefügt wird, wird unter einer anderen Aktivität protokolliert, Update application - Certificates and secrets management. Eine Regel, die nur die Service-Principal-Aktivität überwacht, übersieht daher die Hälfte der Fälle. Dieses Ereignis wird deutlich nützlicher, wenn Sie es mit dem App-Owner, dem bisherigen Credential-Inventar und dem Berechtigungslevel des betroffenen Service Principal anreichern.

Erkennungslogik, die Fehlalarme reduziert

Ein neues Secret an einer Test-App mit geringen Berechtigungen ist nicht dasselbe wie ein neues Secret an einer App mit Graph-Anwendungsberechtigungen und ohne Owner. Priorisieren Sie, indem Sie Audit-Aktivität mit dem App-Inventar verknüpfen:

• aktuelle App-Berechtigungen und Consent-Status
• ob die App Anwendungsberechtigungen oder delegierte Berechtigungen nutzt
• Anzahl der Anmeldeinformationen und Ablaufdaten
• Zeitpunkt der letzten Service-Principal-Anmeldung
• Anzahl der Owner und ob diese noch aktive Mitarbeiter sind
• ob sich die Quell-IP oder der Workload gegenüber der historischen Baseline verändert hat

Behebung

Schneller Erfolg: Erfassen Sie jede Anwendung mit weitreichenden Anwendungsberechtigungen in einem Inventar und lassen Sie den Owner bestätigen, dass Berechtigung und Anmeldeinformation weiterhin benötigt werden.

1. Ungenutzte Anwendungen entfernen oder deaktivieren

Beginnen Sie beim Alter, verwechseln Sie Alter aber nicht mit Nichtnutzung. Die folgende Abfrage listet Anwendungen auf, die vor mehr als 90 Tagen registriert wurden – in einem reifen Tenant sind das die meisten. Sie liefert eine Liste von Prüfkandidaten, keine Liste ungenutzter Anwendungen.

$cutoff = (Get-Date).AddDays(-90)
Get-MgApplication -All | Where-Object { $_.CreatedDateTime -lt $cutoff } |
  Select-Object DisplayName, AppId, CreatedDateTime

Das Signal für Nichtnutzung ist die Authentifizierung, nicht das Erstellungsdatum: Prüfen Sie die Service-Principal-Anmeldeprotokolle für die App oder den Bericht „Service principal sign-in activity usage and insights“, der zum Zeitpunkt dieses Artikels noch in der Vorschau ist. Kombinieren Sie Aktivitäts-, Ownership- und Abhängigkeitsprüfung. Kann niemand erklären, warum die App noch existiert, sollte sie keinen dauerhaften Zugriff behalten.

2. Anmeldeinformationen rotieren und reduzieren

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $app.PasswordCredentials |
    Where-Object { $_.EndDateTime -lt (Get-Date).AddDays(30) } |
    Select-Object @{n='AppName';e={$app.DisplayName}}, DisplayName, EndDateTime
}

Rotieren Sie alte Secrets, entfernen Sie ersetzte Secrets und vermeiden Sie es, mehrere gültige Anmeldeinformationen ohne Grund aktiv zu lassen. Wurde eine Anmeldeinformation in Code, Pipelines oder Dokumentation kopiert, betrachten Sie die Rotation nur als einen Schritt. Auch der alte Speicherort muss bereinigt werden.

3. Stärkeres Credential-Management bevorzugen

Microsoft veröffentlicht hierzu eine explizite Präferenzreihenfolge, und sie beginnt nicht mit Zertifikaten. Verwenden Sie eine Managed Identity, wann immer der Workload auf Azure läuft: Microsoft bezeichnet sie als die sicherste Option und empfiehlt sie ausdrücklich. Läuft der Workload anderswo auf einer Plattform, die automatisiertes Credential-Management bietet, verwenden Sie stattdessen Workload Identity Federation. Nur wenn beides nicht möglich ist, sollten Sie auf Zertifikat-Anmeldeinformationen zurückgreifen – in einem Key Vault gespeichert und von einer vertrauenswürdigen CA ausgestellt, statt selbstsigniert.

Die Empfehlung von Microsoft zu Secrets ist unmissverständlich: „Don't use password credentials, also known as secrets.“ Secrets sind bequem, und genau deshalb landen sie kopiert in Entwickler- und Betriebs-Tooling. Application-Management-Richtlinien können außerdem die Lebensdauer von Secrets begrenzen oder ihre Nutzung ganz blockieren.

4. Berechtigungsumfang reduzieren

Prüfen Sie, ob die App überhaupt Anwendungsberechtigungen benötigt. Wo möglich:

• ersetzen Sie weitreichende Schreibberechtigungen durch engere Lese- oder skopierte Berechtigungen
• bevorzugen Sie delegierte Berechtigungen, wenn ein echter Benutzerkontext existiert
• entfernen Sie Admin-Consent, der durch den Workload nicht mehr gerechtfertigt ist
• vermeiden Sie App-Management-Berechtigungen, außer der Workload verwaltet tatsächlich Apps
• dokumentieren Sie, warum jede verbleibende Anwendungsberechtigung erforderlich ist

5. Festlegen, wer Apps erstellen und Zustimmung erteilen darf

Microsoft stellt Tenant-Einstellungen und delegierte Rollen bereit, um zu steuern, wer Anwendungen registrieren und wer Apps zustimmen darf. Deaktivieren Sie die breite Benutzer-App-Registrierung und Benutzer-Consent dort, wo das Business sie nicht benötigt, und weisen Sie stattdessen explizite Rollen für die Teams zu, die sie brauchen.

Das ist nicht nur Governance. Es verhindert, dass der Tenant nach der Bereinigung dasselbe Problem erneut einführt. Kann jeder Apps erstellen und weitreichende Berechtigungen ohne Prüfpfad anfordern, kehrt die privilegierte App-Wildwuchs-Problematik zurück.

Vor dem Abschluss validieren

Eine App-Registrierungs-Überprüfung ist nicht abgeschlossen, nur weil das Portal aufgeräumter aussieht. Validieren Sie das Ergebnis anhand des tatsächlichen Tenant-Verhaltens.

• exportieren Sie die verbleibenden hochriskanten Apps, ihre Owner, ihre aktiven Anmeldeinformationen und ihre effektiven Berechtigungen
• bestätigen Sie, dass alte Secrets entfernt und nicht nur ersetzt wurden, während die vorherige Anmeldeinformation aktiv blieb
• prüfen Sie, ob die App nach Berechtigungsreduzierung oder Credential-Rotation weiterhin funktioniert
• bestätigen Sie, dass verwaiste Anwendungen tatsächlich deaktiviert oder gelöscht wurden, statt als undokumentierte Ausnahme bestehen zu bleiben
• prüfen Sie die Service-Principal-Anmeldeprotokolle nach der Änderung, um sicherzustellen, dass keine unerwarteten Quell-IPs oder Ressourcen verbleiben
• überprüfen Sie erneut die admin-genehmigten Berechtigungen und bestätigen Sie, dass die Liste mit dem App-Inventar übereinstimmt

Überprüfen Sie außerdem den umgebenden Governance-Pfad: Wer kann Apps erstellen, wer kann Admin-Consent erteilen, und wer muss privilegierten App-Zugriff genehmigen? Ohne diese Kontrolle kehrt dasselbe Muster im nächsten Projektzyklus zurück.

Wie EtcSec das erkennt

EtcSec macht App-Registrierungs-Findings nutzbar, indem es Berechtigung, Alter der Anmeldeinformationen, Ownership-Lücken und Aktivitätssignale kombiniert. Ein Tenant scheitert meist nicht, weil er viele Anwendungen hat. Er scheitert, weil eine kleine Zahl von Anwendungen weitreichende Berechtigungen, schwache Credential-Hygiene und keinen klaren Prüfpfad besitzt.

Das Erkennungsmodell ist expositionsbasiert: weitreichende Anwendungsberechtigungen, gültig bleibende Anmeldeinformationen, unklare Ownership und Service-Principal-Aktivität, die nicht zum dokumentierten Anwendungsfall passt. Jedes dieser Elemente wird auf eine dedizierte Prüfung abgebildet: gefährliche Mail-, Datei-, Verzeichnis- und Rollenberechtigungen, die einer App gewährt wurden; Anwendungen mit mehreren aktiven Secrets oder ohne Credential-Rotation; Anwendungen und Service Principals ohne Owner; tenant-weite Consent-Grants; und Service Principals, die weiterhin veraltete Anmeldeinformationen besitzen. Der Wert liegt in der Verknüpfung, nicht in einem einzelnen Flag.

Weiterführende Artikel

• Azure Tenant-Härtung: Unsichere Defaults
• Azure Privilegierter Zugriff: Zu Viele Globale Admins
• Entra ID bedingter Zugriff Luecken: welche Fehlkonfigurationen reale Angriffsflaechen lassen
• Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant
• Azure Identity Protection: Geleakte Zugangsdaten Blockieren

Primärquellen

• Microsoft Graph permissions overview
• Microsoft Graph permissions reference
• Permissions and consent in the Microsoft identity platform
• Service principal sign-in logs in Microsoft Entra ID
• Security best practices for application properties
• Delegate application management administrator permissions
• Microsoft Entra audit log activity reference