Sentinel Audit: Auditdaten in Microsoft Sentinel sauber nutzen
Ein funktionierendes SIEM ist nur so gut wie sein Betrieb. Sentinel Audit hilft dir, Änderungen, Abfrage-Aktivitäten und die „Gesundheit“ deiner Analysen im Log Analytics Workspace nachvollziehbar zu machen.
- SentinelAudit und SentinelHealth liefern die Basis für Nachweise, Troubleshooting und Kostenkontrolle.
- Office 365 Audit-Daten werden über Data Connectors eingebunden und machen User- und Admin-Aktivitäten aus Microsoft 365 sichtbar.
- Workbooks, Analytics Rules und Playbooks machen Ergebnisse messbar und automatisieren Reaktionen.
- Saubere Aufbewahrung, Zugriffskontrolle und Datenschutzregeln entscheiden, ob Auditdaten compliance-tauglich sind.
Der praktische Nutzen: weniger Blindflug im Betrieb, schnellere Fehleranalyse, weniger teure Fehlalarme und belastbare Dokumentation.
Du sorgst dafür, dass M365 läuft. Wir sorgen dafür, dass niemand unbemerkt eindringt, heimlich mitliest und Schaden anrichtet.
Definition
Sentinel Audit bezeichnet das Prüfen und Nachvollziehen von Aktivitäten, Änderungen und Abfrage-Nutzung in Microsoft Sentinel innerhalb eines Log Analytics Workspace. Es ist kein allgemeines IT-Monitoring, sondern ein Audit- und Betriebsnachweis für Sentinel-Konfiguration, Analytics Rules und Datenerfassung.
Einleitung
Microsoft Sentinel sammelt Logs, aber Auditdaten zeigen dir, ob du Sentinel wirklich kontrollierst: Wer hat eine Rule geändert, welche Queries run, und ob wichtige Connectoren noch sauber collect. Das spart Zeit im Incident-Fall, reduziert Betriebsaufwand und schafft klare Nachweise für Audit und interne Compliance.
Welche Audit-Daten du in Sentinel wirklich brauchst
Zwei Strukturen sind zentral: SentinelAudit und SentinelHealth. SentinelAudit (bzw. _SentinelAudit()) bildet Activity und Änderungen rund um Sentinel-Konfigurationen ab; SentinelHealth (bzw. _SentinelHealth()) zeigt den Zustand und die Ausführung von Analytics Rules und zugehörigen Runs.
Der Nutzen ist direkt messbar: Du siehst within Minuten, warum eine Detection nicht mehr feuert (z. B. Rule deaktiviert, Fehler beim Run, fehlende Daten), statt stundenlang im Dunkeln zu suchen und teure Fehlalarme zu jagen.
Prerequisites: Workspace, Rollen, Logs
Voraussetzung ist ein korrekt angebundener Log Analytics Workspace (analytics workspace) in Azure (sentinel azure) sowie Rechte für Monitoring und Audit. Außerdem müssen die relevanten Data connectors aktiv sein, sonst bleiben Workbooks leer und Analytics rules liefern Schein-Sicherheit.
- Rollen/Access: Mindestens Leserechte auf dem Sentinel workspace und Log Analytics (für view und query), plus passende Rechte zum Configure von Rules und Connectoren.
- Logs: AzureActivity table für Änderungen in Azure, plus SentinelAudit/SentinelHealth (je nach Umgebung als Functions oder Tabellen verfügbar).
- Baseline: Klare Retention-Regeln und ein definierter Scope, welche audit log-Events wirklich gebraucht werden.
Schritt-für-Schritt: Aktivitäten und Abfragen auditieren
Das Ziel ist eine wiederholbare Routine: erst „Was ist passiert?“, dann „Wer hat es changed?“, dann „Wirkt es noch?“. Dafür nutzt du Kusto Query Language (KQL), also die query language in Log Analytics.
1) Änderungen an Sentinel-Konfiguration prüfen
Öffne Logs im Workspace und starte mit SentinelAudit bzw. _SentinelAudit(). Filtere nach Zeitraum, Operation und „created/updated“-ähnlichen Events. So bekommst du eine Liste von activities (wer, was, wann).
2) Regel-Gesundheit und Ausführung nachvollziehen
Nutze SentinelHealth bzw. _SentinelHealth(), um zu sehen, ob eine analytics rule erfolgreich run konnte, ob Fehler auftraten und ob sich Laufzeiten verändert haben. Das ersetzt viel manuelles Troubleshooting.
3) Query-Nutzung und teure Abfragen finden
Wenn du wissen willst, welche Queries regelmäßig laufen und ob sie Kosten treiben, prüfe LAQueryLogs table (laquerylogs). Das hilft, Workbooks und sample queries zu optimieren und unnötige Abfragen zu reduzieren.
Office 365 Audit-Daten in Sentinel integrieren (Office, Teams, Entra ID)
Für Microsoft Sentinel werden Office 365 audit logs über den Office 365 connector (office connector) angebunden. Voraussetzung ist, dass das Office 365 audit log im Tenant aktiviert ist, sonst kommen audit events nur lückenhaft an.
- In Sentinel: Content Hub öffnen, passenden Data connector auswählen und sentinel connect (connect) durchführen. Häufig lautet die UI-Aktion „click add“.
- In Microsoft 365: Sicherstellen, dass Unified Audit Logging aktiv ist und die gewünschten Workloads (z. B. Exchange, SharePoint, Teams) Events liefern.
- Ergänzen: Entra ID (Azure AD) Sign-ins/Directory-Logs und AzureActivity, damit Änderungen und Zugriffsketten im gleichen Workspace korrelieren.
Alerts für Sentinel-Aktivitäten: Rules, Incidents, Playbooks
Auditdaten bringen nur Nutzen, wenn sie in Alerts übersetzt werden. Lege analytics rules gezielt auf „kritische Sentinel-eigene“ Ereignisse (z. B. Rule deaktiviert, Connector-Fehler, auffällige Admin-Aktivität). Damit entstehen Incidents, die du priorisieren und messen kannst.
Playbooks (Automatisierung) setzen dort an, wo Zeit teuer ist: z. B. Ticket erstellen, Teams-Notification, Kontextdaten anreichern oder ein standardisiertes Approval im Change-Management anstoßen.
Überwachung mit Workbooks: sichtbar für IT und Management
Azure Workbooks sind die schnellste Art, Audit logs in ein Dashboard zu bringen, das nicht nur für Analysten taugt. Nutze ein Workspace audit workbook, um Health, Connector-Status und Rule-Ausführung in einer Ansicht zu monitor.
Mini-Story aus der Praxis: Eine Organisation sah plötzlich weniger Incidents und dachte, das Team sei „besser geworden“. Das Workbook zeigte aber: Ein Connector hatte keine events mehr geliefert, eine Rule war zwar vorhanden, aber lief nicht mehr sauber. Nach Fix und Retuning war die Erkennung wieder stabil.
Best Practices: Compliance, Aufbewahrung, Datenschutz
Sentinel audit ist auch ein Compliance-Thema: Audit-Daten enthalten häufig personenbezogene Informationen (User, IPs, Dateien/Ordner wie SharePoint folder, Device-Namen). Definiere daher klare Regeln, bevor du „alles“ ingest.
- Aufbewahrung: Retention nach Zweck (Security-Nachweis vs. Betrieb), nicht nach Bauchgefühl; ältere Daten ggf. archivieren statt dauerhaft im schnellen Storage zu halten.
- Datenschutz: Zugriff in Azure RBAC strikt begrenzen, Workbooks nicht unkontrolliert share; Logging-Scopes minimieren.
- Messbarkeit: KPIs festlegen (z. B. Rule-Run-Fehler, Connector-Ausfälle, Zeit bis Alert), damit „lohnt sich das?“ beantwortbar wird.
Wann externe Unterstützung sinnvoll wird
Externe Hilfe lohnt sich, wenn Auditierung zwar gewünscht ist, aber im Alltag liegen bleibt: zu viele Datenquellen, zu wenig Zeit für Tuning, oder unklare Verantwortung für Rules, Workbooks und Playbooks. Typische Trigger sind wiederkehrende False Positives, fehlende Logs „irgendwo“ im Pipeline-Teil, oder Prüfungen, bei denen Nachweise schnell benötigt werden.
Fazit
Sentinel Audit macht Microsoft Sentinel steuerbar: Du bekommst Nachvollziehbarkeit über Änderungen, Qualität der Datenerfassung und die tatsächliche Ausführung von Analytics Rules. Mit sauberer Integration von Office 365 Audit-Daten, passenden Alerts und Workbooks wird aus Log-Sammlung ein messbarer Betriebsprozess. Entscheidend sind klare Prerequisites, konsequentes Tuning und Regeln für Aufbewahrung und Datenschutz.
Häufige Fragen
Lohnt sich Sentinel Audit wirklich oder ist das nur Zusatzaufwand?
Es lohnt sich, sobald Sentinel produktiv betrieben wird. Auditdaten sparen Zeit bei Störungen, reduzieren Blindflug („warum kommen keine Alerts?“) und machen Änderungen nachvollziehbar. Zusätzlich lassen sich teure oder unnötige Abfragen über LAQueryLogs erkennen und optimieren.
Welche Voraussetzungen sind die häufigsten Stolpersteine?
Unvollständige Data connectors, fehlendes Office 365 Unified Audit Logging im Tenant und zu breite Berechtigungen. Häufig ist der Connector zwar „connected“, aber die Quelle liefert nicht die erwarteten audit events oder nur teilweise workloads.
Wie lange dauert es, bis man Ergebnisse sieht?
Erste Sichtbarkeit ist meist innerhalb weniger Stunden möglich (Workbooks, erste Queries). Stabiler Nutzen entsteht, wenn Rules und Workbooks 2–4 Wochen im Betrieb nachjustiert werden und Zuständigkeiten für Changes klar sind.
Was ist mit Datenschutz und Compliance?
Audit logs enthalten oft personenbezogene Daten. Best Practice ist: Scope minimieren, Zugriff strikt rollenbasiert steuern, Aufbewahrung zweckgebunden definieren und Reports so bauen, dass sie für Management nutzbar sind, ohne unnötige Detaildaten zu verbreiten.
