Entra ID Protokollierung: Aufbewahrung, Diagnoseeinstellungen, SIEM-Export-Lücken

Entra ID Protokollierung Aufbewahrung, Diagnoseeinstellungen, SIEM-Export: Was fehlt

Entra ID Protokollierungsaufbewahrung, Diagnoseeinstellungen, SIEM-Export — drei getrennte Kontrollen, und standardmäßig tut keine davon das, was die meisten Teams annehmen. Anmelde- und Überwachungsprotokolle laufen nach Tagen ab, nicht nach Monaten. Ohne eine explizite Diagnoseeinstellung wird nichts irgendwohin weitergeleitet. Und solange niemand einen Event Hub oder einen Log Analytics-Arbeitsbereich eingerichtet hat, sieht Microsoft Sentinel oder ein SIEM eines Drittanbieters kein einziges Entra ID-Ereignis.

Das ist eine Konfigurationslücke, keine Angriffstechnik — aber es ist eine der folgenreichsten Lücken im gesamten Azure-Katalog, weil sie darüber entscheidet, ob jede andere Erkennung in diesem Blog überhaupt nutzbar ist. Eine Conditional-Access-Richtlinie, die Legacy-Authentifizierung blockiert ist im Nachhinein wertlos zu untersuchen, wenn die Anmeldung, die sie ausgelöst hat, bereits aus dem Protokoll gefallen ist. Eine Identity-Protection-Risikoerkennung bedeutet für ein SOC nichts, das keine Pipeline hat, die sie in sein SIEM einspeist.

Vier verwandte Findings gehören zu diesem Cluster:

• AZ_AUDIT_LOG_RETENTION_SHORT — Überwachungsprotokolle werden kürzer aufbewahrt, als die Lizenz des Tenants erlaubt (oder als ein Incident-Response-Zeitfenster erfordert).
• AZ_SIGN_IN_LOGS_NOT_RETAINED — Anmeldeprotokolle laufen im Standard-Free-Tier-Fenster und verschwinden, bevor die meisten Breach-Erkennungszeitachsen überhaupt beginnen.
• AZ_DIAGNOSTIC_SETTINGS_MISSING — es existiert keine Diagnoseeinstellung, um Protokolle überhaupt irgendwohin zu leiten, sodass das Standard-Aufbewahrungsfenster die einzige Aufbewahrung ist, die existiert.
• AZ_NO_SIEM_EXPORT — Protokolle erreichen möglicherweise einen Log Analytics-Arbeitsbereich, verlassen ihn aber nie in Richtung eines überwachten SIEM, sodass niemand darauf reagiert.

Wie die Lücken tatsächlich entstehen

Aufbewahrung ist eine Lizenzobergrenze, keine Richtlinie, die man selbst festlegt

Laut Microsofts Dokumentation zur Aufbewahrung von Microsoft Entra-Daten sieht das eingebaute Aufbewahrungsfenster für Überwachungs- und Anmeldeprotokolle so aus:

Zwei Details machen es schlimmer, als es aussieht:

1. Aufbewahrungsänderungen wirken nicht rückwirkend. Microsofts Dokumentation stellt klar: Wer von Free auf P1/P2 upgraded, gewinnt nur zurück, was noch innerhalb des kostenlosen 7-Tage-Fensters liegt — bereits abgelaufene Daten sind verloren, sofern sie nicht zuvor archiviert wurden.
2. Microsoft Graph-Aktivitätsprotokolle sind unter Entra ID Free überhaupt nicht verfügbar und werden auch unter P1/P2 standardmäßig nicht aufbewahrt — Microsofts eigene Aufbewahrungstabelle listet sie als von Anfang an auf die Integration mit Speicher- oder Analysewerkzeugen angewiesen; es gibt kein Standard-Fallback-Fenster wie bei Überwachungs- und Anmeldeprotokollen.

Wird ein Vorfall neun Tage später entdeckt — ein durchaus üblicher Zeitrahmen bei credential-basierten Kompromittierungen —, hat ein P1/P2-Tenant ohne konfigurierten Export die Anmeldenachweise für die ersten zwei Tage des Eindringens bereits verloren, und ein Free-Tenant fast alles.

Diagnoseeinstellungen sind Opt-in, pro Protokollkategorie, pro Ziel

Um Protokolle aus dem Standard-Aufbewahrungsfenster von Entra ID herauszuleiten, braucht es eine Diagnoseeinstellung, konfiguriert unter Entra Admin Center → Überwachung und Integrität → Diagnoseeinstellungen durch eine Person mit der Rolle Sicherheitsadministrator (Konfigurieren von Microsoft Entra-Diagnoseeinstellungen). Das geschieht nicht automatisch und deckt nicht "alles" ab, sofern nicht jede relevante Protokollkategorie explizit ausgewählt wird.

Microsoft dokumentiert die streambaren Protokollkategorien, die jeweils einzeln ausgewählt werden müssen (Protokolle, die aus Microsoft Entra ID gestreamt werden können) — die sicherheitsrelevanten davon umfassen:

AuditLogs                          SignInLogs
NonInteractiveUserSignInLogs       ServicePrincipalSignInLogs
ManagedIdentitySignInLogs          ProvisioningLogs
ADFSSignInLogs                     RiskyUsers
UserRiskEvents                     RiskyServicePrincipals
ServicePrincipalRiskEvents         RiskyAgents / AgentRiskEvents
NetworkAccessTrafficLogs           MicrosoftGraphActivityLogs
EnrichedOffice365AuditLogs         CustomSecurityAttributeAuditLogs

Ein Tenant kann eine Diagnoseeinstellung haben, die nur AuditLogs weiterleitet, während SignInLogs, RiskyUsers und UserRiskEvents — die Kategorien, die tatsächlich Authentifizierungs- und Risikotelemetrie tragen — ungeroutet bleiben und der oben genannten 7/30-Tage-Obergrenze unterliegen. Das ist ein sehr häufiger halbkonfigurierter Zustand: Jemand hat Logging einmal für ein Compliance-Häkchen aktiviert, ein oder zwei Kategorien ausgewählt und nie wieder überprüft. Dieselbe Lücke untergräbt direkt auch Untersuchungen von privilegierten Rollenaktivitäten, die über Azure PIM nachverfolgt werden — ein Aktivierungsverlauf ist nur so beständig wie das Überwachungsprotokoll, in das er geschrieben wird.

Das Ziel selbst muss bereits existieren, bevor die Diagnoseeinstellung darauf zeigen kann: ein Log Analytics-Arbeitsbereich, ein Event Hub oder ein Speicherkonto. Protokolle können bis zu drei Tage brauchen, um nach dem Speichern einer Einstellung zu erscheinen — das ist relevant, wenn man einen Fix validiert.

Ein Log Analytics-Arbeitsbereich ist kein SIEM

Hier weicht AZ_NO_SIEM_EXPORT von AZ_DIAGNOSTIC_SETTINGS_MISSING ab: Ein Tenant kann vollständig konfigurierte Diagnoseeinstellungen haben, die jede Kategorie in einen Log Analytics-Arbeitsbereich schreiben, und trotzdem null Erkennungsabdeckung — weil niemand Analyseregeln gegen diesen Arbeitsbereich laufen lässt oder der Arbeitsbereich nie mit Microsoft Sentinel verbunden oder per Event Hub an ein SIEM eines Drittanbieters (Splunk, Elastic, QRadar) exportiert wurde.

Microsofts eigene Integrationsdokumentation weist darauf hin, dass die Verbindung von Entra-Protokollen mit Azure Monitor-Protokollen automatisch den Microsoft Entra-Datenconnector in Microsoft Sentinel aktiviert (Integration von Microsoft Entra-Protokollen mit Azure Monitor-Protokollen) — aber nur, wenn Sentinel überhaupt auf demselben Arbeitsbereich bereitgestellt ist. Ein Arbeitsbereich ohne Sentinel (oder eine gleichwertige SIEM-Aufnahme) obendrauf ist ein reines Schreibarchiv: Daten werden aufbewahrt, aber niemand und nichts schaut sie sich an.

Erkennung

Prüfe jede der vier Lücken unabhängig — ein Tenant hat häufig einige, aber nicht alle behoben.

1. Bestätige, was tatsächlich konfiguriert ist, nicht was du annimmst. Gehe im Entra Admin Center zu Überwachung und Integrität → Diagnoseeinstellungen und prüfe jede vorhandene Einstellung: welche Protokollkategorien ausgewählt sind und auf welches Ziel sie zeigen. Ist die Liste leer, gilt sofort AZ_DIAGNOSTIC_SETTINGS_MISSING — der Tenant läuft nur mit Standardaufbewahrung.

2. Prüfe die lizenzbedingte Aufbewahrungsobergrenze gegen deine tatsächlichen Incident-Response-Anforderungen. Ein 7-Tage-Fenster bei Entra ID Free, oder selbst das 30-Tage-Fenster bei P1/P2, ist kurz im Vergleich zu typischen Verweildauer-Statistiken bei identitätsbasierten Angriffen — wenn nichts es verlängert, markiere AZ_AUDIT_LOG_RETENTION_SHORT / AZ_SIGN_IN_LOGS_NOT_RETAINED.

3. Verifiziere, dass Daten tatsächlich in Log Analytics ankommen, nicht nur, dass eine Einstellung existiert. Führe in Sentinel oder einem verbundenen Arbeitsbereich aus:

SigninLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

AuditLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

Beachte, dass die Tabellennamen in Log Analytics SigninLogs (kleines "i") verwenden, abweichend vom Namen der Diagnoseeinstellungs-Kategorie SignInLogs — eine häufige Quelle für "warum ist meine Abfrage leer"-Verwirrung. Ist LastEvent veraltet oder existiert die Tabelle nicht, ist die Diagnoseeinstellung entweder nicht gespeichert, deckt diese Kategorie nicht ab oder zeigt auf einen anderen Arbeitsbereich als den, den du abfragst.

4. Bestätige die SIEM-Seite, nicht nur die Pipeline. Wenn Microsoft Sentinel das Ziel ist, prüfe unter Datenconnectors → Microsoft Entra ID, ob die Verbindung besteht und sowohl SignInLogs als auch AuditLogs aktiviert sind — das ist ein separater Schalter, getrennt von der Entra-seitigen Diagnoseeinstellung, und beide müssen auf denselben Arbeitsbereich zeigen. Bei einem SIEM eines Drittanbieters bestätige, dass der Event Hub tatsächlich eine aktive Consumer-Gruppe hat, die daraus liest — nicht nur, dass die Diagnoseeinstellung einen Event Hub als Ziel aufführt.

5. Für die programmatische Beweiserhebung stellt das Microsoft Graph PowerShell SDK die zugrunde liegenden Daten direkt bereit, unabhängig von jeder SIEM-Pipeline — nützlich, um zu bestätigen, was Entra ID selbst aktuell vorhält:

# Bestätigen, wie weit die Anmeldedaten aktuell zurückreichen
Get-MgAuditLogSignIn -Top 1 -Sort "createdDateTime asc"

# Dieselbe Prüfung für Verzeichnis-Überwachungsereignisse
Get-MgAuditLogDirectoryAudit -Top 1 -Sort "activityDateTime asc"

Behebung

1. Zuerst das Ziel bereitstellen. Erstelle (oder identifiziere) einen Log Analytics-Arbeitsbereich und, falls zusätzlich eine langfristige Kaltspeicherung nötig ist, ein separates Speicherkonto — Diagnoseeinstellungen benötigen ein bereits existierendes Ziel, bevor sie darauf zeigen können.
2. Erstelle die Diagnoseeinstellung mit jeder sicherheitsrelevanten Kategorie, nicht nur AuditLogs. Mindestens: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, RiskyUsers, UserRiskEvents. Füge ADFSSignInLogs und ProvisioningLogs hinzu, falls diese in deiner Umgebung relevant sind.
3. Verbinde den Arbeitsbereich mit Microsoft Sentinel (oder der Event-Hub-Consumer-Gruppe deines SIEM) und bestätige, dass der Microsoft Entra ID-Datenconnector sowohl SignInLogs als auch AuditLogs als verbunden zeigt — ein Arbeitsbereich, der Daten empfängt, ohne dass ein SIEM sie liest, schließt AZ_DIAGNOSTIC_SETTINGS_MISSING, lässt aber AZ_NO_SIEM_EXPORT offen.
4. Verlängere die Aufbewahrung über die Lizenzobergrenze hinaus, indem du die eigene Aufbewahrungsrichtlinie des Log Analytics-Arbeitsbereichs oder Speicherkontos unabhängig vom 7/30-Tage-Standard von Entra ID konfigurierst — das Aufbewahrungsfenster von Entra ID spielt keine Rolle mehr, sobald die Daten in Azure Monitor liegen. Organisationen mit Microsoft 365 E5 / Purview Suite-Lizenzierung können die Aufbewahrung alternativ über Microsoft Purview Audit (Premium) verlängern.
5. Führe die obigen Erkennungsabfragen erneut aus, nachdem die Einstellung gespeichert wurde — gib bis zu drei Tage Zeit, bis Daten erscheinen, bevor du von einem Fehlschlag ausgehst — und bestätige, dass LastEvent in SigninLogs / AuditLogs aktuell ist, nicht nur, dass die Abfrage irgendwelche Zeilen zurückgibt.
6. Dokumentiere, wer die Re-Validierung verantwortet. Diagnoseeinstellungen driften lautlos: eine Arbeitsbereichs-Migration, ein Sentinel-Onboarding, bei dem das erneute Verbinden des Connectors vergessen wurde, oder eine abgelaufene Purview-Lizenz können die Pipeline still zum Stillstand bringen, ohne dass im Entra Admin Center ein Fehler sichtbar wird.

Wie EtcSec das erkennt

EtcSec prüft AZ_AUDIT_LOG_RETENTION_SHORT, AZ_SIGN_IN_LOGS_NOT_RETAINED, AZ_DIAGNOSTIC_SETTINGS_MISSING und AZ_NO_SIEM_EXPORT bei jedem Azure/Entra ID-Audit — und bestätigt nicht nur, dass eine Diagnoseeinstellung existiert, sondern welche Protokollkategorien sie tatsächlich weiterleitet und ob das Ziel von deinem SOC überwacht wird. Das ist eine begleitende Prüfung zum breiteren Bild der Tenant-Härtung, das in Microsoft Entra ID-Sicherheit auditieren und der Azure-Tenant-Härtung-Baseline behandelt wird.