Revisionssichere Nachweise: XGS-Logs und Microsoft 365 Audit Log korreliert auswerten

Audit-Log-Korrelation zwischen Firewall und M365, revisionssichere Protokollierung — dahinter steht immer dieselbe Prüferfrage: »Wer hat wann was gemacht — und wie belegen Sie das?« Die Kurzantwort vorab: Die Antwort liegt fast nie in einem einzigen System. Der Firewall-Log kennt die Verbindung, aber nicht die Aktion; das M365-Audit-Log kennt die Aktion, aber nicht den Netzweg; Entra kennt die Anmeldung samt MFA-Beweis, aber weder Weg noch Tat. Erst die Korrelation der drei Quellen — verbunden über Benutzer, IP-Adresse und Zeit — macht aus verstreuten Einträgen einen belastbaren Nachweis. Dieser Artikel liefert das Handwerk dazu: was Auditoren wirklich sehen wollen, die Quellen-Landkarte, das Zeitsynchronisations-Fundament, konkrete Korrelations-Szenarien mit Beispielabfragen, die Aufbewahrungsgrenzen des Unified Audit Log samt Erweiterungen — und die Berichtsformate, mit denen aus einer Abfrage ein Dokument wird, das Prüfungen standhält. Die Zutaten stehen in den meisten Umgebungen bereit; was fehlt, ist die Verkettung.

Was Auditoren wirklich sehen wollen

Wer für Prüfungen baut, sollte die Abnehmerseite kennen — und Auditoren (ob ISO-Prüfer, Versicherungs-Auditor, Wirtschaftsprüfer oder die eigene Revision) wollen erstaunlich einheitliche Dinge. Erstens konkrete Antworten auf konkrete Fragen: Wer hat diese Firewall-Regel geändert? Wer hat auf dieses Postfach zugegriffen? Wann bekam dieses Konto seine Berechtigungen, und wer hat das genehmigt? War der VPN-Zugriff am Feiertag legitim? Zweitens die Kette statt des Fragments: Nicht »hier ist ein Log-Eintrag«, sondern der nachvollziehbare Weg von der Person über den Zugang zur Aktion — mit benannten Originalquellen. Drittens Konsistenz: Zeitstempel, die zusammenpassen, Benutzernamen, die sich über Systeme hinweg zuordnen lassen, keine Lücken im relevanten Zeitraum. Und viertens — gern unterschätzt — den Prozess dahinter: Wer darf solche Auswertungen fahren, wie wird der Zugriff auf die Logs selbst protokolliert, wie werden Nachweise abgelegt? Was Auditoren dagegen nicht wollen: eine Festplatte voller Rohlogs mit dem Angebot, selbst zu suchen. Die Fähigkeit, aus einer Frage binnen Minuten einen dokumentierten Beleg zu machen, ist das eigentliche Prüfungsergebnis — alles Weitere in diesem Artikel dient genau ihr.

Die Nachweisquellen: XGS, Entra, Purview Audit

Die Landkarte in der Skizze sortiert die drei Quellen nach ihren Ebenen. Ebene Netz — die Sophos XGS: Verbindungsprotokolle (wer sprach wann mit welchem Ziel), VPN-Logs mit Adresszuweisungen und Sitzungen, das Admin-Audit-Protokoll mit jeder Regel- und Konfigurationsänderung, dazu Web-Filter-Ereignisse in der Tiefe, die [LINK: C2] und die Betriebsvereinbarung erlauben. Ebene Identität — Entra ID: die Sign-in-Logs mit jedem Anmeldeversuch samt MFA-Ergebnis, Gerätestatus und Conditional-Access-Entscheidung, dazu die Verzeichnis-Audit-Logs mit Kontoanlagen, Rollen- und Gruppenänderungen; wer die Firewall-Verwaltung per Entra-SSO angebunden hat, bekommt hier gratis auch die WebAdmin- und VPN-Anmeldungen mit MFA-Beweis. Ebene Aktion — das Unified Audit Log in Purview: Postfachzugriffe und Mail-Regeln, SharePoint- und OneDrive-Zugriffe, Downloads und Freigaben, Teams-Ereignisse, Mandanten-Administration. Das Landkarten-Prinzip für die Praxis: Fast jede ernsthafte Audit-Frage braucht mindestens zwei Ebenen — die Regeländerung will Netz plus Identität, der Postfachzugriff Aktion plus Netz, der Datenabfluss alle drei. Genau diese Mehrebenen-Natur macht die Korrelation zum Pflichtprogramm statt zur Kür.

Skizze 1: Netz, Identität, Aktion — jede Quelle weiß etwas, keine weiß alles; ernsthafte Fragen brauchen mindestens zwei Ebenen.

Zeitstempel und Zeitsynchronisation als Fundament

Bevor irgendeine Korrelation trägt, muss eine Banalität stimmen, die keine ist: Alle Quellen müssen dieselbe Zeit sprechen. Die Baustellen: Die XGS gehört fest auf NTP (der externe Zeitgeber, den auch die Domänencontroller-Hierarchie nutzt), die Windows-Welt synchronisiert über den PDC-Emulator nach außen, und die Microsoft-Cloud stempelt ohnehin zuverlässig — aber in UTC, während die Firewall je nach Einstellung lokale Zeit schreibt. Daraus folgen die zwei Arbeitsregeln der Korrelation: Erstens wird für jede Auswertung auf UTC normiert — wer Log-Zeilen mit gemischten Zeitzonen nebeneinanderlegt, produziert Phantom-Differenzen von ein oder zwei Stunden, die je nach Jahreszeit auch noch wechseln (die Sommerzeit-Umstellung ist der Klassiker unter den Korrelations-Unfällen). Zweitens wird die Zeitquelle überwacht wie ein Dienst: Ein NTP-Ausfall fällt im Betrieb nicht auf — die Uhren laufen ja weiter, nur eben auseinander; ein Monitoring-Check auf die Zeitabweichung der Kernsysteme kostet nichts und bewacht das Fundament. Warum das keine Pedanterie ist, rechnet der Faktenkasten vor: Schon wenige Minuten Drift können eine Kausalkette umkehren — und eine umgekehrte Kette ist vor dem Prüfer schlimmer als gar keine.

Korrelations-Szenarien mit Beispielabfragen

Jetzt das Handwerk an den drei häufigsten Szenarien — die Nachweiskette der Skizze führt das dritte im Detail vor. Szenario eins, die Regeländerung: »Wer hat die DNAT-Regel am 3. Juni geändert?« Der Weg: XGS-Admin-Audit liefert Konto und Zeitstempel der Änderung; die Entra-Sign-in-Logs liefern zur selben Zeit die Anmeldung dieses Admins am WebAdmin — mit MFA-Ergebnis und Gerät, sofern die Verwaltung per Entra-SSO angebunden ist. Ergebnis: Person, Zeitpunkt, Authentifizierungsbeweis. Szenario zwei, der Postfachzugriff: Das Unified Audit Log liefert die Zugriffs-Ereignisse samt Client-IP; ist es eine interne oder VPN-Adresse, sagt der XGS-VPN-Log, welchem Benutzer sie gehörte, und Entra ergänzt Gerät und Anmeldekontext. Szenario drei, der Datenabfluss-Verdacht: UAL-Download-Ereignisse, XGS-Verbindungen, Entra-Anmeldung — die volle Drei-Ebenen-Kette. Zur Werkzeugfrage: Mit Sentinel ([LINK: B8]) sind das Abfragen über die vorhandenen Tabellen, verbunden über Benutzer, IP und Zeitfenster — wobei die dort beschriebene Namensnormalisierung (DOMAIN\benutzer gegen UPN) die halbe Miete ist. Ohne SIEM geht es auch: Audit-Suche im Purview-Portal beziehungsweise per PowerShell, Entra-Portal-Filter, XGS-Log-Export — und die Verknüpfung von Hand; mühsamer, aber für Einzelfragen völlig tragfähig. Der Hinweis-Kasten gibt Startpunkte für beide Wege.

Skizze 2: Identität, Netz, Aktion im Zeitverlauf — verbunden über Benutzer, IP und Zeitfenster; darunter die drei Voraussetzungen, ohne die die Kette reißt.

Aufbewahrung: Unified Audit Log — Grenzen und Erweiterungen

Die schönste Abfrage nützt nichts, wenn die Quelle das Ereignis schon vergessen hat — und die Vergesslichkeit ist höchst ungleich verteilt, wie der Balkenvergleich zeigt. Die lokale XGS rotiert nach Tagen und zählt als Quelle nicht; ihre Wahrheit lebt am Syslog-Ziel mit dem konfigurierten [LINK: C2]-Korridor. Entra hält 30 Tage — die kürzeste Frist im Bunde, deren Abhilfe (Export nach Log Analytics) der Warn-Kasten beschrieben hat. Und das Unified Audit Log staffelt nach Lizenz: Der Faktenkasten liefert die zitierfähigen Zahlen. Für die Praxis ergeben sich daraus zwei Gestaltungsaufgaben. Erstens die Lückenschluss-Frage: Die relevanten Quellen so verlängern, dass der typische Prüfungshorizont (Jahresaudit! Vorfallsaufklärung nach Monaten!) abgedeckt ist — per Audit-Premium-Lizenz, per Export in eigene Speicher oder per Sentinel-Archivierung. Zweitens die DSGVO-Klammer: Länger ist nicht automatisch besser — die Differenzierung aus dem Datenschutz-Artikel gilt auch hier: Admin- und Audit-Daten, die Handlungen der IT und Konfigurationsänderungen dokumentieren, dürfen und sollen länger leben als benutzerbezogene Verkehrsdaten; wer pauschal alles auf zehn Jahre stellt, tauscht die Audit-Lücke gegen ein Datenschutz-Problem. Die Tabelle fasst Fristen und Verlängerungswege zusammen.

Skizze 3: Vom Tage-Gedächtnis der lokalen Box bis zum Zehn-Jahres-Add-on — und die 30-Tage-Falle von Entra als schwächstes Glied.

Berichtsformate für Prüfungen

Der letzte Schritt trennt die gut vorbereitete Umgebung von der wirklich audit-fähigen: das Format, in dem Nachweise beim Prüfer ankommen. Rohlogs sind keins — die belastbare Form ist das Nachweisdokument je Frage, und es hat einen festen Aufbau: die Frage im Wortlaut; die verwendeten Quellen mit ihrer Rolle in der Kette; die Abfragen selbst (das KQL-Statement, der PowerShell-Befehl, die Portal-Filter) — der Prüfer will sehen, wie das Ergebnis entstand, nicht nur dass es existiert; das Ergebnis als Export oder Bildschirmfoto mit sichtbaren Zeitstempeln und vermerkter Zeitzone; und die Metadaten der Erstellung: wer hat wann abgefragt, abgelegt wo. Für die Ablage gilt Unveränderbarkeits-Logik: ein geschützter Bereich mit Versionierung und Aufbewahrungsrichtlinie — die Nachweise über die Nachweise. Und zum Wort »gerichtsfest« gehört Ehrlichkeit: Eine Zauberformel gibt es nicht — was zählt, ist die Kombination aus synchronisierten Zeitquellen, dokumentiertem Abfrageweg, unveränderter Ablage und geregeltem Auswertungsprozess (Zugriffskonzept samt Anlass-Regeln liefern die Datenschutz-Artikel). Diese Kombination überzeugt Prüfer aller Couleur — vom ISO-Auditor bis zum Versicherer, im Ernstfall auch die Instanz mit der Robe.

FAQ — häufige Fragen zu Audit-Korrelation und Nachweisen

Wie lange speichert Microsoft 365 Audit-Ereignisse?

Gestaffelt nach Lizenz: Mit Audit Standard — enthalten in den gängigen Business- und E3-Plänen — hält das Unified Audit Log Ereignisse 180 Tage vor (von Microsoft seinerzeit von 90 Tagen angehoben). Mit Audit Premium — in E5 beziehungsweise als Add-on — wird daraus ein Jahr, ergänzt um zusätzliche Ereignistypen und differenzierbare Aufbewahrungsrichtlinien; das Langzeit-Add-on dehnt ausgewählte Protokolle auf bis zu zehn Jahre. Drei Randnotizen: Die Fristen gelten nur fürs UAL — Entra-Logs folgen eigenen, kürzeren Regeln (30 Tage mit P1/P2) und brauchen den Export. Die Werte sind Microsoft-Stellschrauben — vor einer Prüfung in die aktuelle Doku schauen. Und die Speicherfrist beantwortet nur die halbe Frage: Ob sie reicht, entscheidet der Prüfungshorizont — ob sie zulässig ist, die DSGVO-Differenzierung nach Datenarten.

Wie verknüpfe ich Firewall- und M365-Ereignisse?

Über die drei Verbindungsstücke Benutzer, IP-Adresse und Zeitfenster — und mit einer Vorarbeit, die wichtiger ist als jedes Werkzeug. Die Vorarbeit: Namensnormalisierung. Die Firewall schreibt Benutzer gern als DOMAIN\name, Entra und M365 als UPN (name@firma.de) — wer korrelieren will, braucht die Übersetzung, entweder fest in der Abfrage oder als Normalisierung beim Datenimport ins SIEM. Dann der Weg mit Sentinel: Die relevanten Tabellen (Firewall-Events, SigninLogs, OfficeActivity) liegen nebeneinander, die Verknüpfung ist ein Join über den normalisierten Benutzer oder die Client-IP, eingegrenzt auf das Zeitfenster — die Beispielabfragen im Hinweis-Kasten liefern die Gerüste. Der Weg ohne SIEM: je Quelle filtern und exportieren (Purview-Audit-Suche, Entra-Portal, XGS-Log-Viewer), dann die Verknüpfung von Hand oder in der Tabellenkalkulation — für Einzelfragen völlig tragfähig, für regelmäßige Auswertungen mühsam. In beiden Welten gelten dieselben Disziplinen: Zeitstempel vor dem Vergleich auf UTC normieren und die Kette an ihren Übergabepunkten prüfen — passt die IP aus dem UAL-Ereignis wirklich zur VPN-Zuweisung? Ein Übungslauf mit der eigenen gestrigen Anmeldung deckt die Stolpersteine auf, bevor es ernst wird.

Reichen die Standard-Aufbewahrungszeiten für Audits?

Für das UAL oft ja, für Entra klar nein — und die ehrliche Antwort hängt am Prüfungshorizont. Die Rechnung: Jahresaudits fragen routinemäßig nach Ereignissen, die bis zu zwölf Monate zurückliegen; Vorfallsaufklärungen beginnen erfahrungsgemäß Wochen bis Monate nach dem eigentlichen Geschehen; Versicherungs- und Vertragsprüfungen orientieren sich an Vertragsjahren. Daran gemessen: Die 180 UAL-Tage des Audit Standard decken viele, aber nicht alle dieser Fenster — für den vollen Jahreshorizont braucht es Audit Premium oder den Export in eigene Ablagen. Die 30 Entra-Tage decken praktisch nichts davon — der Export nach Log Analytics ist deshalb keine Kür, sondern die Pflichtübung dieses Themas. Die Firewall-Seite richtet sich nach dem selbst gesetzten Korridor am Syslog-Ziel, wobei für die Audit-tauglichen Admin- und Konfigurationsprotokolle bewusst längere Fristen gelten dürfen als für benutzerbezogene Verkehrsdaten — die Datenschutz-Differenzierung aus dem C2-Artikel löst genau diese Spannung. Die Methode für die eigene Antwort: die drei bis fünf wahrscheinlichsten Prüfungsfragen aufschreiben, je Frage die beteiligten Quellen aus der Landkarte notieren — und prüfen, ob jede Quelle den nötigen Rückblick hat. Wo nicht, ist die Lücke benannt und der Verlängerungsweg steht in der Tabelle.

Welche Rolle spielt Zeitsynchronisation?

Die der Beweisgrundlage — ohne synchrone Uhren ist jede Korrelation nur eine Behauptung. Der Mechanismus: Nachweisketten leben von Reihenfolge und Nähe der Ereignisse (Anmeldung, dann Tunnel, dann Zugriff — binnen Sekunden); driftet eine Quelle, verschieben sich ihre Stempel gegen die anderen, und schon wenige Minuten können eine Kausalkette auf dem Papier umkehren — der Faktenkasten rechnet das Vier-Minuten-Beispiel durch, an dessen Ende ein Zugriff vor dem zugehörigen Tunnel steht und der Prüfer die ganze Kette verwerfen muss. Die Umsetzung in drei Punkten: die XGS fest auf NTP gegen dieselbe externe Quelle wie die Windows-Hierarchie (die Cloud stempelt ohnehin zuverlässig in UTC); ausgewertet und dokumentiert wird grundsätzlich in UTC — die Sommerzeit-Umstellung ist der klassische Stolperdraht handgemachter Korrelationen; und die Zeitabweichung der Kernsysteme gehört ins Monitoring, denn NTP-Ausfälle sind lautlos. Kurz: Wer bei der Zeit spart, spart an der Stelle, die alles andere entwertet.

Brauche ich dafür zwingend ein SIEM?

Nein — aber die ehrliche Antwort hat zwei Hälften. Ohne SIEM funktioniert die Nachweisführung für Einzelfragen ordentlich: Die Purview-Audit-Suche (Portal oder PowerShell) deckt die M365-Aktionen ab, die Entra-Portale filtern Anmeldungen und Verzeichnisänderungen, der XGS-Log-Viewer beziehungsweise das Syslog-Ziel liefert die Netzseite — je Quelle exportieren, von Hand über Benutzer, IP und Zeit verknüpfen, fertig ist der Nachweis; Voraussetzung bleibt auch hier, dass die Aufbewahrung stimmt (insbesondere der Entra-Export, der auch ohne SIEM in ein Storage-Konto laufen kann). Die zweite Hälfte: Ein SIEM wie Sentinel verwandelt diese Handarbeit in Minutenarbeit — die Quellen liegen als Tabellen nebeneinander, die Korrelation ist eine gespeicherte Abfrage, die Namensnormalisierung passiert einmal statt bei jeder Auswertung, und die Archivierung löst die Fristenfrage gleich mit. Die pragmatische Staffelung: Wer Prüfungen nur gelegentlich bedient, kommt mit der Handarbeit plus diszipliniertem Export aus; wer regelmäßig Nachweise liefern muss, unter NIS2 fällt oder ohnehin über die Sentinel-Anbindung aus dem Cluster nachdenkt, bekommt die Audit-Fähigkeit dort als Nebenprodukt der Sicherheitsüberwachung — zwei Anforderungen, eine Architektur. Zwingend ist das SIEM also nicht. Es ist nur der Unterschied zwischen können und mühelos können.

Wie exportiere ich Nachweise gerichtsfest?

Mit der ehrlichen Vorbemerkung, dass »gerichtsfest« kein Stempel ist, den ein Export-Button verleiht — belastbar wird ein Nachweis durch die Kombination von vier Eigenschaften, und die sind alle herstellbar. Erstens Integrität der Quelle: synchronisierte Zeit (siehe oben), lückenlose Aufbewahrung im relevanten Zeitraum, und Systeme, in denen Protokolle nicht nachträglich editierbar sind — was für UAL, Entra-Logs und ein sauber betriebenes Syslog-Ziel gilt. Zweitens Nachvollziehbarkeit des Weges: Das Nachweisdokument enthält die Abfrage selbst (KQL, PowerShell-Befehl, Portal-Filter), die Quellen mit Zeitzone und den Erstellungsvermerk — wer, wann, woraus; ein Ergebnis ohne dokumentierten Entstehungsweg ist nur ein Bildschirmfoto. Drittens Unveränderbarkeit der Ablage: Export in einen geschützten Bereich mit Versionierung und Aufbewahrungsrichtlinie, wo es darauf ankommt mit vermerkter Prüfsumme. Viertens der Prozess: ein geregeltes Zugriffskonzept, das belegt, dass nur Befugte auswerten — die Kontrolle der Kontrolle. Und für den echten Rechtsstreit gilt der Schlusssatz aller Compliance-Artikel dieses Clusters: Dann gehören Fachanwalt und gegebenenfalls Forensiker früh an den Tisch — die hier beschriebene Disziplin sorgt dafür, dass sie etwas Brauchbares vorfinden.

Fazit: Die Kette ist der Nachweis — und sie will vorher gebaut sein

Die Prüferfrage »Wer hat wann was gemacht?« beantwortet kein einzelnes System — sie beantwortet eine Architektur: Firewall-Logs am Syslog-Ziel mit sauberem Korridor, Entra-Logs per Export vor der 30-Tage-Amnesie gerettet, das Unified Audit Log mit lizenzgerechter Aufbewahrung, alle Uhren synchron und alle Auswertungen in UTC, Benutzernamen normalisierbar — und darüber das Handwerk der Korrelation, das aus drei Ebenen eine Kette macht, plus das Nachweisdokument, das Weg und Ergebnis prüffest verpackt. Nichts davon ist exotisch, das meiste steht in den Bestandslizenzen bereit, und die aufwendigste Zutat ist die Disziplin, es vor der Prüfung zu bauen statt während ihr. Der Lohn ist konkret: Auditfragen in Minuten statt Wochen, Versicherungsprüfungen ohne Aufschlag, Vorfallsaufklärung mit Substanz — und das gute Gefühl, dass die Antwort auf »Können Sie das belegen?« schlicht »Ja, Moment« lautet.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Die technische Log-Pipeline in Richtung Sentinel samt Kostenlogik und Namensnormalisierung liefert [LINK: B8]. Personenbezug, Fristen-Korridor und Löschkonzept — die DSGVO-Klammer dieser Aufbewahrungsfragen — stehen in [LINK: C2]. Und wie diese Nachweisketten in ISO-27001- und TISAX-Audits einzahlen, zeigt [LINK: C8].