Entra ID Audit Log: Was du wirklich brauchst

Definition

Entra ID Audit Logs sind Änderungsprotokolle aus Microsoft Entra ID, die administrative und directory-relevante events wie role-Änderungen, Policy-Updates oder application-Konfigurationen im tenant dokumentieren.

Sie sind nicht dasselbe wie Sign-in logs und ersetzen kein SIEM oder Incident-Management, sondern liefern die beweisfähige Grundlage zum Review von Changes und Admin-Activity.

Einleitung

Wenn in deinem Microsoft 365 tenant etwas „plötzlich anders“ ist, brauchst du eine belastbare Antwort auf die Frage: Wer hat was wann geändert? Genau dafür ist der Entra ID Audit Log da.

Der praktische Nutzen entsteht, wenn du Audit logs nicht nur im Portal „sehen“ kannst, sondern sie exportierst, auswertest und für monitoring und alerts nutzt. Dann werden investigations schneller, Risiken sinken und Compliance-Reports werden einfacher.

Welche Log-Typen du auseinanderhalten musst

In Entra ID gibt es mehrere Log-Streams, die in reports zusammengehören, aber unterschiedliche Fragen beantworten. Für saubere insights musst du sie trennen, sonst bleiben Lücken in der Analyse.

• Entra ID Audit Logs: Änderungen im directory und an admin-nahen Objekten (Users, Gruppen, roles, Apps, Richtlinien, access-bezogene Konfiguration).
• Sign-in logs: Anmeldeevents (Erfolg/Fehlschlag, device, location, MFA, Conditional Access decision) für Risiko- und Zugriffsanalysen.
• Provisioning logs: provisioning- und Sync-Aktivitäten, z. B. bei Benutzerbereitstellung in Apps oder Directory-Workflows.

Für viele Unternehmen ist der Audit Log der schnellste Hebel gegen „unkontrollierte Änderungen“: Er macht Changes sichtbar, die sonst in Admin-Routinen untergehen.

Zugriff und Sichtbarkeit: Portal reicht nur für den ersten Blick

Im Microsoft Entra Admin Center (azure portal/Entra portal) lassen sich Audit logs filtern, einzelne activity-Details öffnen und exportieren. Das ist gut für ad-hoc review, aber schwach für operational monitoring und Langzeitanalysen.

Wenn mehrere administrators, SecOps und Betriebsteams zusammenarbeiten, brauchst du zentrale Sichtbarkeit: wer darf welche logs sehen, wer bestätigt Reviews, und wie werden findings dokumentiert. Ohne Rollen- und Rechtekonzept wird das schnell entweder zu offen (zu viel access) oder zu blind (niemand sieht die kritischen events).

Ingestion: Event Hub, API und Diagnostic settings

Damit Audit logs wirklich nutzbar werden, müssen sie aus dem Portal heraus in eine Plattform, die Suchen, Korrelation und retention sauber kann. Typische Optionen sind Diagnostic settings, Azure Event Hubs und API-Zugriffe.

• Azure Monitor / Diagnostic settings: Weiterleitung an Log Analytics, Azure Storage oder Event Hub für stabile Ingestion.
• Azure Event Hubs: Streaming-Feed, ideal für SIEM-Integration und near-real-time monitoring.
• Microsoft Graph API: Abfrage und Automatisierung, z. B. für eigene Kontroll-Workflows oder Bulk-Reviews (statt manueller Portal-Klicks).

Der häufigste Fallstrick: Log-Ingestion wird „irgendwie“ aktiviert, aber ohne Zielbild. Dann steigen storage-Kosten, während der Nutzen ausbleibt, weil niemand die richtigen queries und alerts gebaut hat.

Speichern und Abfragen: Log Analytics, KQL und Storage

Für die tägliche Arbeit ist ein Log Analytics Workspace oft die beste Balance aus Kosten, Geschwindigkeit und Auswertbarkeit. Mit Kusto Query Language (KQL) kannst du wiederholbare Abfragen erstellen, Trends erkennen und Reports automatisieren.

Azure Blob Storage eignet sich zusätzlich für günstige Archivierung und evidence-Aufbewahrung, wenn du Logs länger halten musst als die Standard-retention im Portal. In der Praxis kombinieren viele beides: Log Analytics für investigations und monitoring, Storage als Langzeitablage.

Messbarer Nutzen: Statt bei jedem incident manuell nachzuschauen, hast du gespeicherte queries, die in Minuten zeigen, ob role-Changes, app-Änderungen oder risky activities im Zeitraum passiert sind.

Monitoring, Alerts, Dashboards: Aus Logs werden Entscheidungen

Logs ohne reaction-Prozess sind nur Daten. Mit Azure Monitor alerts, Workbooks und einem SIEM wie Microsoft Sentinel machst du daraus Steuerung: Alerts für critical events, Dashboards für management und einheitliche Operational-Reports.

• Alerts auf role-Änderungen und PIM-Aktivierungen: reduziert das Risiko „stiller“ Privilegien-Eskalation.
• Alerts auf Änderungen an Conditional Access policies und MFA-Einstellungen: verhindert, dass protection unbemerkt geschwächt wird.
• Dashboards/Workbooks für Review & Reporting: spart Zeit, weil weniger manuelles Zusammenklicken im Portal nötig ist.

Microsoft Sentinel bringt dabei zusätzlich Automatisierung: Fälle werden korreliert, enrichment passiert automatisch, und Standardreaktionen können vorbereitet werden. Das senkt Betriebskosten und verkürzt Untersuchungen, statt dass jedes Team bei jedem event bei null startet.

Retention, Compliance und Beweismittel: Was du vor dem Audit klären musst

Für compliance zählt nicht, dass Logs „irgendwo“ existieren, sondern dass retention, Zugriff und Nachvollziehbarkeit definiert sind. Spätestens bei audits oder internen Prüfungen brauchst du klare Antworten: Wie lange werden logs gehalten, wer kann sie verändern, und wie werden Reports erzeugt?

Als Beweismittel taugen Audit logs nur, wenn sie vollständig gesichert wurden, bevor ein incident auffällt. Deshalb gehört die Retention-Entscheidung an den Anfang, nicht ans Ende.

Mini-Use-Case: Der „plötzliche“ Policy-Bruch

Ein Team stellt fest, dass legacy authentication wieder funktioniert und Zugriffe ohne MFA möglich sind. Im Audit Log sieht man die changes an Conditional Access, inklusive admin account, Zeitpunkt und betroffener policy. Über Log Analytics und KQL wird geprüft, ob weitere related events (App-Änderungen, role-Updates) im Zeitraum passiert sind. Das spart Stunden in der investigation und verhindert повторte issues durch klare Ursache.

Best Practices und häufige Fallstricke

Am meisten Nutzen entsteht durch klare Priorisierung: Nicht alles ist kritisch, aber kritische events müssen automatisch sichtbar werden.

• Best Practice: Definiere „critical events“ (roles, Conditional Access, Apps) und baue dafür Alerts plus Review-Prozess.
• Best Practice: Nutze KQL-Queries als Standardprüfungen (wiederholbar statt ad-hoc), inklusive Reporting für management.
• Fallstrick: Nur Portal-Review ohne Export/Retention; im Ernstfall fehlen Daten und die Reaktionszeit explodiert.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung wird sinnvoll, wenn Audit logs zwar vorhanden sind, du aber keinen stabilen Betrieb hinbekommst: regelmäßiges monitoring, saubere alerts, dokumentierte Reviews und SIEM-Integration ohne Dauerprojekt.

Typische Trigger sind: zu wenig Zeit im IT-Team, unklare Verantwortlichkeiten zwischen admin und SecOps, oder der Wunsch nach messbarer Entlastung durch Automatisierung (z. B. Sentinel-Playbooks) statt mehr manueller Arbeit.