Entra Service Principal Anmeldeanomalie-Erkennung: Workload-Identity blinde Flecken

Entra Service Principal Anmeldeanomalie-Erkennung: Workload-Identity definiert

Entra Service Principal Anmeldeanomalie-Erkennung, also Workload-Identity-Monitoring, das erfasst, wie sich Maschinenkonten normalerweise authentifizieren, ist die eine Kontrolle, die die meisten Tenants nie konfigurieren. Jede andere Identitätskontrolle in einem reifen Tenant — MFA-Einführungskampagnen, phishing-resistente Authentifizierungsmethoden, risikobasierter Conditional Access — ist um einen Menschen herum aufgebaut, der an der Tastatur sitzt. Service Principals haben keinen Menschen, und die Kontrollen erreichen sie schlicht nicht.

Microsoft ist explizit, warum diese Identitäten anders sind. Eine Workload-Identity ist eine Identität, die es einer Anwendung oder einem Service Principal erlaubt, auf Ressourcen zuzugreifen, und Microsofts eigene Dokumentation listet drei Eigenschaften auf, die sie von einem Benutzerkonto unterscheiden: Workload-Identitäten „können keine Multi-Faktor-Authentifizierung durchführen“, „haben oft keinen formalen Lifecycle-Prozess“ und „müssen ihre Zugangsdaten oder Secrets irgendwo speichern“.

Liest man diese drei zusammen, wird die Exposition offensichtlich. Die Zugangsdaten sind eine Zeichenkette, die in einer Pipeline-Variable, einem Key Vault, einer appsettings-Datei oder einer Container-Image-Ebene liegt. Es gibt keinen zweiten Faktor dahinter, keinen Lifecycle, der sie am letzten Arbeitstag eines ausscheidenden Mitarbeiters ablaufen lässt, und — weil eine Service-Principal-Anmeldung keinen Benutzer involviert — nichts, was einem nutzerzentrierten Alerting-Stack ungewöhnlich erscheint. Sobald diese Zeichenkette leakt, authentifiziert sich der Angreifer exakt so, wie es die Anwendung tut, und die Anmeldung gelingt beim ersten Versuch.

Warum Ihre MFA- und Conditional-Access-Abdeckung Nicht Greift

Conditional Access ist die Kontrolle, von der Administratoren annehmen, dass sie alles abdeckt. Das tut sie nicht — Workload-Identitäten sind einer von mehreren Orten, an denen ihre Abdeckung leise endet, neben den Scope- und Ausnahmefehlern, die in Entra ID Conditional-Access-Lücken: Welche Fehlkonfigurationen echte Exposition hinterlassen katalogisiert sind. Microsofts Dokumentation stellt fest, dass Conditional-Access-Richtlinien „historisch nur für Nutzer galten, wenn sie auf Apps und Dienste zugreifen“, und dass die Unterstützung für Service Principals eine separate Fähigkeit namens Conditional Access für Workload-Identitäten ist.

Diese separate Fähigkeit bringt Einschränkungen mit sich, die darüber entscheiden, ob Ihre Richtlinie überhaupt etwas bewirkt:

Die Gruppenzuweisungsregel verdient Betonung, weil sie stillschweigend versagt. Ein Administrator, der Service Principals in eine Sicherheitsgruppe einordnet, die bereits von einer Conditional-Access-Richtlinie anvisiert wird, sieht eine Richtlinie, die im Portal korrekt zugeordnet aussieht, aber für diese Service Principals überhaupt nichts durchsetzt. Nichts meldet einen Fehler. Nichts warnt. Die Richtlinie wird für sie einfach nicht ausgewertet.

Die unterstützten Bedingungen sind bewusst eng gefasst: Blockieren von Service Principals „außerhalb bekannter öffentlicher IP-Bereiche“, Blockieren „basierend auf einem von Microsoft Entra ID Protection erkannten Risiko“, sowie Authentifizierungskontexte. Standort und Risiko — nicht Gerät, nicht MFA, nicht Compliance.

Es gibt zudem eine Asymmetrie zwischen dem Erkennen von Risiko und dem Blockieren, die man leicht falsch herum verstehen kann. ID Protection „erkennt Risiken bei Single-Tenant-, Nicht-Microsoft-SaaS- und Multi-Tenant-Apps“, während die Conditional-Access-Durchsetzung nur Single-Tenant-Service-Principals erreicht. Managed Identities liegen außerhalb beider. Bei einer Multi-Tenant-SaaS-Anwendung in Ihrem Tenant kann Ihnen also mitgeteilt werden, dass sie kompromittiert ist, Sie können sie aber nicht mit einer Workload-Identity-Richtlinie blockieren — was Erkennung und Reaktion, nicht Prävention, zur operativen Kontrolle macht.

Wo Service-Principal-Anmeldungen Tatsächlich Leben

Der zweite Grund, warum diese Anmeldungen unbeobachtet bleiben, ist, dass die meisten Hunting-Abfragen sie nie berühren. Microsoft Entra protokolliert vier Arten von Anmeldeprotokollen: interaktive Benutzeranmeldungen, nicht-interaktive Benutzeranmeldungen, Service-Principal-Anmeldungen und Managed-Identity-Anmeldungen. Ein SOC, das seine Erkennungen auf Benutzeranmeldungen aufgebaut hat, schaut nicht auf eine gefilterte Teilmenge einer Tabelle — es schaut auf einen völlig anderen Stream.

Der Service-Principal-Stream ist ein eigenständiges Ding. Microsoft beschreibt es unverblümt: „Anders als interaktive und nicht-interaktive Benutzeranmeldungen involvieren Service-Principal-Anmeldungen keinen Benutzer. Stattdessen handelt es sich um Anmeldungen durch ein beliebiges Nicht-Benutzerkonto, etwa Apps oder Service Principals ... Bei diesen Anmeldungen stellt die App oder der Service Principal seine eigenen Zugangsdaten bereit, etwa ein Zertifikat oder App-Secret, um sich zu authentifizieren oder auf Ressourcen zuzugreifen.“

Werden diese über Diagnoseeinstellungen in einen Log-Analytics-Workspace exportiert, landen sie in der Tabelle AADServicePrincipalSignInLogs — nicht in SigninLogs. Haben Sie diese Log-Kategorie nie aktiviert, liefern die Abfragen im nächsten Abschnitt null Zeilen, und null Zeilen sehen exakt wie eine saubere Umgebung aus.

Die Aufbewahrung ist die andere Hälfte der Voraussetzung. Microsofts Referenz zur Datenaufbewahrung gibt Anmeldeprotokollen sieben Tage bei Microsoft Entra ID Free und 30 Tage bei P1 oder P2. Eine verhaltensbasierte Erkennung braucht eine Baseline plus ein aktuelles Zeitfenster innerhalb dieses Budgets — Sie können kein 90-Tage-Profil aus einem 30-Tage-Log erstellen. Wie der Export konfiguriert wird, behandelt Entra ID Protokollierung: Aufbewahrung, Diagnoseeinstellungen, SIEM-Export-Lücken; betrachten Sie das als harte Voraussetzung für alles Folgende.

Diese Spalten tragen das Signal:

Die Angriffskette Nach Einem Geleakten Secret

Schritt 1 — Das Credential entkommt

Das Secret verlässt die Umgebung: in ein öffentliches Repository committet, aus einem Build-Log erfasst, von einer kompromittierten Entwickler-Workstation abgezogen oder gekauft. Microsofts Leaked Credentials-Erkennung für Workload-Identitäten existiert genau deshalb, weil das Routine ist — sie prüft Zugangsdaten, die „von GitHub, dem Dark Web, Paste-Sites oder anderen Quellen“ stammen, gegen gültige Zugangsdaten im Tenant. Derselbe Dienst deckt auch Benutzerkonten ab, wo das wiederkehrende Versagen eher in der Reaktion als in der Erkennung liegt — siehe Entra ID Risikoschutz: Geleakte Anmeldedaten, riskante Nutzer nicht behoben.

Schritt 2 — Eine Authentifizierung, die völlig legitim wirkt

Der Angreifer führt einen OAuth-Client-Credentials-Flow mit dem gestohlenen Secret durch. Keine MFA ist möglich, also fehlt auch keine. Ist keine Workload-Identity-Richtlinie direkt zugewiesen, spiegelt ConditionalAccessStatus eine Anmeldung wider, die nichts ausgewertet hat. Das Ergebnis ist eine erfolgreiche Anmeldung, die Byte für Byte dieselbe Operation ist, die die echte Anwendung tausendmal am Tag ausführt. Nur der umgebende Kontext unterscheidet sich.

Schritt 3 — Persistenz durch Hinzufügen eines Credentials

Statt sich auf ein Secret zu verlassen, das rotiert werden könnte, fügt ein Angreifer mit ausreichenden Rechten der Anwendung oder dem Service-Principal-Objekt sein eigenes Credential hinzu. Die Identität hat nun zwei gültige Zugangsdaten, und das Widerrufen des geleakten ändert nichts. Dieser Schritt hinterlässt zwei Spuren: eine Verzeichnisänderung im Audit-Log, und — bei jeder nachfolgenden Anmeldung — eine ServicePrincipalCredentialKeyId, die für diese AppId noch nie aufgetaucht ist.

Schritt 4 — Handeln über Graph

Die Anwendungsberechtigungen des Service Principal sind nun der Explosionsradius, und Anwendungsberechtigungen sind durch keine Nutzerrechte begrenzt. Tenant-weite Grants wie Directory.ReadWrite.All oder RoleManagement.ReadWrite.Directory machen aus einem geleakten Secret die volle Verzeichniskontrolle; siehe Entra App-Registrierung Gefährliche Graph-API-Berechtigungen dazu, wie diese Grants inventarisiert und reduziert werden. Microsofts Suspicious API Traffic-Erkennung zielt auf genau diese Phase und löst aus, „wenn abnormaler GraphAPI-Traffic oder eine Verzeichnisaufzählung eines Service Principal beobachtet wird“.

Erkennung

Verhaltensbasierte Erkennung stützt sich hier auf eine Eigenschaft, die dem Verteidiger zugutekommt: Workloads sind langweilig konsistent. Ein nächtlicher Sync-Job läuft zur gleichen Stunde, von derselben Egress-IP, gegen dieselbe Ressource, mit demselben Credential. Menschen sind unberechenbar; Automatisierung ist es nicht. Diese Konsistenz macht Abweichungen aussagekräftig — und deshalb müssen die entsprechenden Erkennungen für Benutzerkonten, etwa unmögliche Reisen und AiTM-Token-Replay, deutlich mehr Rauschen tolerieren als die folgenden Abfragen.

Volumenspitze gegenüber einer Baseline pro Identität

// Workload identity volume spike: last 24h vs the preceding daily baseline
let Recent = 1d;
let Lookback = 30d;
let MinRecent = 20;       // suppress low-volume identities
let MinBaselineDays = 7;  // suppress identities we have not observed long enough
let Baseline =
    AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(Lookback) .. ago(Recent))
    | where ResultType == "0"
    | summarize Total = count(), Days = dcount(startofday(TimeGenerated)) by AppId
    | where Days >= MinBaselineDays and Total > 0
    | extend BaselineDaily = todouble(Total) / todouble(Days);
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(Recent)
| where ResultType == "0"
| summarize RecentCount = count(), Name = take_any(ServicePrincipalName) by AppId
| where RecentCount >= MinRecent
| join kind=inner (Baseline) on AppId
| extend SpikeRatio = round(RecentCount / BaselineDaily, 1)
| where SpikeRatio >= 5
| project Name, AppId, RecentCount, BaselineDaily = round(BaselineDaily, 1), SpikeRatio
| order by SpikeRatio desc

Erstmals gesehenes Land oder autonomes System

// A workload identity authenticating from a country or ASN it has never used
let Recent = 1d;
let Lookback = 30d;
let Known =
    AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(Lookback) .. ago(Recent))
    | where ResultType == "0"
    | extend Country = tostring(parse_json(tostring(LocationDetails)).countryOrRegion)
    | where isnotempty(Country)
    | summarize KnownCountries = make_set(Country),
                KnownASNs = make_set(AutonomousSystemNumber) by AppId;
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(Recent)
| where ResultType == "0"
| extend Country = tostring(parse_json(tostring(LocationDetails)).countryOrRegion)
| where isnotempty(Country)
| join kind=inner (Known) on AppId
| where array_length(KnownCountries) > 0
| where not(set_has_element(KnownCountries, Country))
     or not(set_has_element(KnownASNs, AutonomousSystemNumber))
| project TimeGenerated, ServicePrincipalName, AppId, Country,
          ASN = AutonomousSystemNumber, IPAddress, ResourceDisplayName,
          NewCountry = not(set_has_element(KnownCountries, Country))
| order by TimeGenerated desc

Ein Credential, das noch nie zuvor verwendet wurde

// Sign-in using a credential key this workload identity has never presented
let Recent = 1d;
let Lookback = 30d;
let KnownKeys =
    AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(Lookback) .. ago(Recent))
    | where ResultType == "0" and isnotempty(ServicePrincipalCredentialKeyId)
    | summarize KnownKeyIds = make_set(ServicePrincipalCredentialKeyId) by AppId;
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(Recent)
| where ResultType == "0" and isnotempty(ServicePrincipalCredentialKeyId)
| join kind=inner (KnownKeys) on AppId
| where not(set_has_element(KnownKeyIds, ServicePrincipalCredentialKeyId))
| project TimeGenerated, ServicePrincipalName, AppId,
          ServicePrincipalCredentialKeyId, ClientCredentialType,
          IPAddress, ResourceDisplayName
| order by TimeGenerated desc

Kombinieren Sie diese letzte Abfrage mit dem Audit-Log-Eintrag, der das Hinzufügen des Credentials zum Anwendungs- oder Service-Principal-Objekt festhält. Ein neuer Credential-Key ohne entsprechenden, genehmigten Change Request ist das aussagekräftigste Signal in diesem Artikel.

Zwei Einschränkungen verdienen Ehrlichkeit. Erstens: Eine kürzere Baseline als die ideale ist unvermeidlich, wenn das Log selbst nach 7 bis 30 Tagen abläuft — haben Sie nicht in einen Workspace mit längerer Aufbewahrung exportiert, ist Ihre Baseline durch Ihre Lizenz gedeckelt. Zweitens: Eine legitime Deployment-Änderung (eine neue Region, ein migrierter Build-Agent, eine geplante Rotation) erzeugt exakt dieselbe Signatur wie eine Kompromittierung. Microsoft räumt denselben Effekt in seiner eigenen Erkennung ein: „Anmeldungen, die nach einer autorisierten Konfigurationsänderung ausgelöst werden, können diese Erkennung auslösen.“ Diese Abfragen erzeugen Untersuchungswarteschlangen, keine Urteile.

Microsofts eigene Suspicious Sign-ins-Erkennung für Workload-Identitäten lohnt es sich, zusätzlich zu aktivieren. Sie „erlernt die Baseline des Anmeldeverhaltens für Workload-Identitäten in Ihrem Tenant“, benötigt dafür „zwischen 2 und 60 Tagen“ und löst aus bei unbekannter „IP-Adresse/ASN, Zielressource, User-Agent, Wechsel zwischen Hosting-/Nicht-Hosting-IP, IP-Land, Credential-Typ“ — dieselbe Merkmalsmenge, Microsoft-seitig korreliert. Kunden ohne Workload Identities Premium „erhalten weiterhin alle Erkennungen mit eingeschränkten Berichtsdetails“.

Behebung

1. Exportieren Sie den Stream und erweitern Sie das Fenster. Leiten Sie Service-Principal-Anmeldeprotokolle in einen Workspace, dessen Aufbewahrung über die Standardwerte von 7 oder 30 Tagen hinausgeht, damit überhaupt eine Baseline möglich ist. Siehe Entra ID Protokollierung: Aufbewahrung, Diagnoseeinstellungen, SIEM-Export-Lücken.

2. Entfernen Sie das Secret, statt es zu bewachen. Läuft die Workload auf Azure, verwenden Sie Managed Identities, damit die Plattform die Zugangsdaten verwaltet. Läuft sie außerhalb von Azure — GitHub Actions, Kubernetes, GCP, AWS — verwenden Sie Workload Identity Federation, die ein Token eines externen Identity Providers gegen ein Access Token tauscht. Microsofts Begründung ist direkt: gespeicherte Zugangsdaten „stellen ein Sicherheitsrisiko dar und müssen sicher gespeichert und regelmäßig rotiert werden“, während Federation „das Risiko eliminiert, dass Secrets geleakt werden oder Zertifikate ablaufen“. Ein Credential, das nicht existiert, kann nicht geleakt werden.

3. Legen Sie eine Workload-Identity-Conditional-Access-Richtlinie an — korrekt. Erstellen Sie eine standortbasierte Richtlinie unter Benutzer oder Workload-Identitäten → Workload-Identitäten, zielen Sie auf Alle Ressourcen, schließen Sie Jeden Standort ein und schließen Sie die benannten Standorte aus, von denen aus Ihre Workload legitim läuft. Denken Sie an die drei Fallen: Es erfordert Workload Identities Premium, es muss dem Service Principal direkt zugewiesen werden statt über eine Gruppe, und Zugriff blockieren ist die einzige Grant-Kontrolle. Speichern Sie sie zuerst im Nur-Bericht-Modus und lesen Sie die Ergebnisse in der Ansicht Service Principal-Anmeldungen, bevor Sie durchsetzen.

4. Inventarisieren und rotieren Sie Zugangsdaten. Microsofts Behebungsanleitung für eine kompromittierte Workload-Identity besteht darin, jedes Credential sowohl am Service-Principal- als auch am Anwendungsobjekt zu inventarisieren, ein neues hinzuzufügen (x509-Zertifikate bevorzugt), die kompromittierten Zugangsdaten zu entfernen — „wenn Sie glauben, dass das Konto gefährdet ist, empfehlen wir, alle vorhandenen Zugangsdaten zu entfernen“ — und alle Key-Vault-Secrets zu rotieren, die diese Identität erreichen konnte. Rotationshygiene im Allgemeinen behandelt Entra App-Registrierung Zugangsdaten-Rotation Secrets.

5. Verkleinern Sie den Explosionsradius, bevor Sie ihn brauchen. Der Schaden, den ein geleaktes Secret anrichten kann, ist durch die ihm gewährten Anwendungsberechtigungen begrenzt. Entfernen Sie tenant-weite Graph-Grants, die nicht wirklich benötigt werden, und überprüfen Sie Service Principals mit Verzeichnisrollen erneut — die statische Seite dieses Problems behandelt Entra Service Principal Admin-Rolle Überprivilegiert.

6. Verifizieren. Führen Sie die drei Abfragen erneut aus. Ein korrekt instrumentierter Tenant liefert Zeilen für Ihre bekannten Deployment-Ereignisse und nichts sonst; ein Tenant, der buchstäblich nichts liefert, hat ein Protokollierungsproblem, kein sauberes Zeugnis. Wo diese Prüfung in einer vollständigen Tenant-Überprüfung einzuordnen ist, beschreibt Wie man Microsoft Entra ID Security auditiert (Azure AD): Praktischer Leitfaden.

Wie EtcSec Das Erkennt

Die etc-collector-Audit-Engine liefert zwei Detektoren, die genau diese Telemetrie abdecken, beide eingestuft als Hoch:

• RISK_SP_SIGNIN_SPIKE — kennzeichnet einen Service Principal, der sich in den letzten 24 Stunden weit häufiger angemeldet hat als in den vorangegangenen Tagen des erfassten Zeitfensters. Die Gruppierung erfolgt pro appId nur über Maschinen-Anmeldeereignistypen, sodass eine interaktive Benutzeranmeldung, die zufällig eine appId trägt, die gemessene Rate einer Anwendung nicht verwässern kann.
• RISK_UNUSUAL_GEO_ADMIN — kennzeichnet ein privilegiertes Konto, das sich erfolgreich aus einem Land angemeldet hat, das es zuvor im erfassten Zeitfenster nicht genutzt hatte. Dies ist das menschliche Gegenstück derselben Telemetrie: dieselbe „erstmals gesehene Geografie“-Logik, angewendet auf Admins statt auf Workloads.

Beide sind um die oben beschriebenen Leitplanken herum gebaut, statt um ein reines Verhältnis: Eine Identität mit zu wenig Baseline-Historie bleibt still, eine Identität mit zu wenigen aktuellen Anmeldungen bleibt still, eine leere Menge bekannter Länder bleibt still, und Anmeldungen ohne aufgelöstes Land werden ignoriert statt als neues Land gezählt. Die Erfolgsfilterung unterscheidet sich zwischen beiden: RISK_UNUSUAL_GEO_ADMIN zählt auf beiden Seiten der Aufteilung nur erfolgreiche Anmeldungen, sodass es sich nicht mit RISK_FAILED_SIGNIN_BURST überschneidet, das bereits Muster fehlgeschlagener Versuche abdeckt; RISK_SP_SIGNIN_SPIKE misst seine Rate über jede Maschinenanmeldung im Zeitfenster, erfolgreich oder fehlgeschlagen.

Das aktuelle Zeitfenster ist am jüngsten erfassten Ereignis verankert statt an der Wanduhrzeit, sodass das erneute Abspielen eines Audits Stunden später dieselben Tage vergleicht.