OAuth2 App Governance in Entra ID

OAuth2-App-Sicherheit ist das neue Schlachtfeld für Microsoft 365 Administratoren. Während einige MVPs und ISVs vor einer apokalyptischen Welle von Malware-Apps warnen, zeigt die Realität, dass oft nicht böswillige Absicht, sondern schlichtes administratives Desinteresse das größte Risiko darstellt. Du benötigst keine teuren Drittanbieter-Tools, um die Kontrolle zu behalten, aber ein tiefes Verständnis dafür, was in Deinem Tenant „lebt“, ist unverzichtbar.

Die Anatomie des Risikos: Permissions & Service Principals

Das Kernproblem liegt in der Intransparenz von Entra ID. Es fehlt eine native Inventarisierung, die kritische Berechtigungen wie Mail.Read, Files.Read.All oder Sites.Manage.All prominent hervorhebt. Diese Berechtigungen sind die Kronjuwelen für Angreifer, um Daten unbemerkt zu exfiltrieren – wie der „Midnight Blizzard“-Angriff im März 2024 schmerzlich demonstrierte.

Jede Multi-Tenant-App, die in Deinen Tenant integriert wird, erzeugt einen Service Principal. Dieser fungiert als lokale Repräsentanz der App und definiert, was die App in Deiner Umgebung darf. Das Risiko: Einmal genehmigt (Consent), bleibt der Zugriff bestehen, bis er explizit entzogen wird.

Jagd auf „Traitorware“ und Schatten-IT

Studien von Huntress Labs (Matt Kiely) zeigen, dass etwa 10 % aller Tenants sogenannte „Traitorware“-Apps beherbergen. Dies sind Apps, die legitim erscheinen, aber im Hintergrund weitreichende Berechtigungen sammeln. Ein einfaches PowerShell-Skript auf Basis des Microsoft Graph SDK kann hier als hocheffizienter „Jäger“ dienen.

Dein Skript sollte gezielt nach folgenden Mustern suchen:

• Namensgebung: Apps mit „Test“, „Demo“ oder reinen Sonderzeichen im Namen.
• User-Bezug: Apps, die nach Benutzern benannt sind (oft ein Zeichen für manuelle, unsichere Registrierungen).
• Suspicious Reply URLs: Umleitungs-URLs, die auf bekannte Phishing-Kampagnen (wie ProofPoint MACT 1445) hindeuten.
• Credentials: Abgelaufene oder zu lang gültige Client Secrets und Zertifikate.

Analyse-Skript: Service Principals identifizieren

Um die Herkunft einer App zu bestimmen, hilft das Cmdlet Find-MgTenantRelationshipTenantInformationByTenantId. Damit löst Du die kryptische AppOwnerTenantId in einen lesbaren Namen auf.

# Abrufen aller Service Principals inkl. SignIn-Aktivität
$ServicePrincipals = Get-MgServicePrincipal -All -Property "displayName", "appId", "signInAudience", "appOwnerTenantId", "signInActivity"

foreach ($sp in $ServicePrincipals) {
    # Besitzer-Tenant auflösen
    $OwnerInfo = Find-MgTenantRelationshipTenantInformationByTenantId -TenantId $sp.AppOwnerTenantId
    
    # Ausgabe der Identität
    [PSCustomObject]@{
        DisplayName = $sp.DisplayName
        Owner       = $OwnerInfo.DisplayName
        LastSignIn  = $sp.SignInActivity.LastSuccessfulSignInDateTime
        IsVerified  = $sp.VerifiedPublisher.DisplayName -ne $null
    }
}

Inaktive Apps aufspüren

Viele Service Principals sind „Leichen“ aus alten Testphasen oder umgezogenen Microsoft-Diensten (z. B. alte Secure Score Apps). Zur Identifikation inaktiver Apps hast Du zwei Wege:

1. Entra ID Sign-in Logs: Bietet 30 Tage Historie, erfordert aber Entra P1 Lizenzen und ist rechenintensiv.
2. servicePrincipalSignInActivity Objekt: Dieses Graph-Objekt liefert den Zeitstempel der letzten erfolgreichen Anmeldung direkt mit. Dies ist der schnellste Weg, um Apps zu finden, die seit Monaten nicht mehr aktiv waren.

Governance-Strategie: Dokumentieren und Markieren

Ein technischer Scan ist nur die halbe Miete. Du musst das Wissen im Team sichern. Microsoft bietet die Möglichkeit, administrative Notizen (Notes) an Service Principals zu heften.

Verwende diese Felder konsequent, um festzuhalten:

• Wer hat die App angefordert?
• Welchem Business-Zweck dient sie?
• Wann wurde der letzte Review durchgeführt?

Fazit und Sicherheitsbewertung

Die Verwaltung von OAuth2-Anwendungen ist keine einmalige Aufgabe, sondern ein kontinuierlicher Prozess. Das größte Risiko ist nicht die technisch hochgerüstete Malware, sondern die schleichende Akkumulation von Berechtigungen („Permission Creep“) und das Vergessen von Apps, die einst für legitime Zwecke erstellt wurden.

Die Identifikation von Apps aus fremden Tenants wie PRDTRS01 oder trustportal zeigt, dass selbst Microsoft nicht immer sauber aufräumt. Hier musst Du als Administrator die „Stadtreinigung“ übernehmen. Ein monatlicher automatisierter Report, idealerweise als Azure Automation Runbook, der Dir eine CSV-Liste aller Apps mit Mail.Read oder AppRoleAssignment.ReadWrite.All und deren letztem Login sendet, ist effektiver als jedes teure Sicherheits-Dashboard.

Schutzmaßnahmen wie RBAC for Applications für Mailbox-Zugriffe sollten Standard sein. Behandle App-Identitäten mit der gleichen Strenge wie privilegierte Benutzerkonten. Nur so verhinderst Du, dass eine vergessene „Test“-App zum Einfallstor für den nächsten großen Exfiltrations-Angriff wird.

This post is also available in: Deutsch