„Wir können im Zweifel nachvollziehen, wer was gemacht hat." Diesen Satz höre ich in fast jedem Erstgespräch — und in etwa der Hälfte der Fälle stimmt er nicht. Nicht, weil Microsoft nichts protokolliert. Sondern weil die Aufbewahrungsfrist kürzer ist als der Zeitraum, über den man Auskunft geben müsste, weil die interessantesten Ereignisse eine Lizenz voraussetzen, die man nicht hat — oder weil schlicht nie jemand hineingeschaut hat und der erste Blick mitten im Vorfall stattfindet.
Das Microsoft 365 Audit Log ist die einzige Quelle, aus der Du im Ernstfall belegen kannst, was in Deinem Tenant passiert ist: Wer hat auf welches Postfach zugegriffen, wer hat eine Weiterleitungsregel angelegt, wer hat eine Datei heruntergeladen, wer hat eine Rolle vergeben. Ohne diese Belege ist jede Aussage gegenüber Aufsicht, Versicherung oder Geschäftsführung eine Vermutung. Dieser Guide zeigt Dir, was das Log tatsächlich erfasst, wie lange es das behält, wie Du gezielt suchst — und an welchen drei Stellen die Standardkonfiguration im Ernstfall nicht trägt.
Eine Klarstellung vorweg, weil hier zwei Dinge regelmäßig durcheinandergehen: Wer nach einem Entra ID Sicherheitsaudit sucht, meint meistens eine Prüfung der Konfiguration — eine Standortbestimmung, wie sicher der Tenant aufgestellt ist. Darum geht es hier nicht. Hier geht es um das Protokoll: die fortlaufende Aufzeichnung dessen, was Benutzer und Administratoren tatsächlich getan haben. Beides ist wichtig, beides heißt im Deutschen „Audit", und beides braucht unterschiedliche Werkzeuge.
Alles Wichtige auf einen Blick
Was das Unified Audit Log erfasst — und was woanders liegt
Das Unified Audit Log ist der gemeinsame Sammelpunkt für Aktivitäten aus praktisch allen Diensten Deines Tenants. Konkret findest Du dort unter anderem Postfachzugriffe und Änderungen an Postfachregeln aus Exchange Online, Datei- und Ordneroperationen aus SharePoint und OneDrive, Freigaben an Externe, Aktivitäten in Teams, Verwaltungsvorgänge aus dem Admin Center und Änderungen an Richtlinien in Purview. Für die meisten Organisationen ist die Protokollierung inzwischen standardmäßig aktiviert — verlassen sollte man sich darauf trotzdem nicht, sondern es einmal aktiv prüfen. Die offizielle Übersicht dazu steht in der Microsoft-Learn-Dokumentation zum Durchsuchen des Überwachungsprotokolls.
Interessanter als die Liste der Dienste ist die Frage, welche Aktivitäten überhaupt protokolliert werden — denn hier verläuft eine Lizenzgrenze, die im Ernstfall den Unterschied macht. Bestimmte forensisch besonders wertvolle Ereignisse stehen nur mit Audit (Premium) zur Verfügung, das an höherwertige Lizenzen wie Office 365 E5 gekoppelt ist. Das prominenteste Beispiel ist MailItemsAccessed: Es protokolliert, auf welche einzelnen Mail-Elemente zugegriffen wurde. Nach einer Kontoübernahme ist genau das die Information, die darüber entscheidet, ob Du sagen kannst „es wurden diese zwölf Nachrichten gelesen" oder nur „wir wissen nicht, was der Angreifer gesehen hat". Diese Unterscheidung ist keine akademische: Von ihr hängt ab, ob eine Meldung an die Aufsichtsbehörde und an Betroffene fällig wird und wie sie ausfällt.
Und dann ist da der Punkt, der in den meisten Anleitungen fehlt und den ich für den häufigsten blinden Fleck überhaupt halte: Die Anmeldeprotokolle von Microsoft Entra ID sind nicht Teil des Unified Audit Log. Sie liegen im Entra Admin Center, sie haben ein eigenes Schema, und vor allem haben sie eine eigene, deutlich kürzere Aufbewahrungsfrist. Wer wissen will, von welcher IP-Adresse und mit welchem Gerät sich ein kompromittiertes Konto angemeldet hat, findet das dort — und nur dort. Wer die Anmeldeprotokolle nicht in ein längerfristiges Ziel exportiert, verliert genau die Spur, die eine Untersuchung trägt. Der Export dieser Protokolle in ein SIEM oder einen Log-Analytics-Arbeitsbereich ist deshalb kein Reifegrad-Luxus, sondern die Voraussetzung dafür, dass eine Untersuchung überhaupt bis zum Anfang zurückreichen kann. Wie Du diese Aggregation strategisch aufsetzt, habe ich unter SIEM und SOAR im Microsoft 365-Security-Stack beschrieben.
Aufbewahrung: die Zahl, die über Deine Beweisfähigkeit entscheidet
Die Aufbewahrungsfrist ist die wichtigste Zahl in diesem ganzen Thema, und fast niemand kennt seine eigene. Mit Audit (Standard) liegen die Einträge rund 180 Tage vor — Microsoft hat diesen Wert von ursprünglich 90 Tagen angehoben. Mit Audit (Premium) verlängert sich die Standardaufbewahrung auf ein Jahr, und über ein zusätzliches Add-on lassen sich Protokolle bis zu zehn Jahre vorhalten. Premium erlaubt darüber hinaus Aufbewahrungsrichtlinien für Überwachungsprotokolle: Du kannst je Dienst, je Aktivitätstyp und je Benutzergruppe unterschiedliche Fristen festlegen, statt alles über einen Kamm zu scheren. Die Details stehen in der Microsoft-Dokumentation zu Aufbewahrungsrichtlinien für Überwachungsprotokolle.
Warum das praktisch zählt, zeigt eine Zahl aus der Vorfallpraxis: Die Zeitspanne zwischen dem ersten unbemerkten Zugriff eines Angreifers und seiner Entdeckung wird branchenübergreifend in Monaten gemessen, nicht in Tagen. Wenn eine Kompromittierung nach sieben Monaten auffällt und Dein Protokoll sechs Monate zurückreicht, ist der Beginn des Vorfalls nicht mehr rekonstruierbar. Du kannst dann weder sagen, wann der Zugriff begann, noch was am Anfang passiert ist — und stehst gegenüber Aufsicht und Versicherung mit leeren Händen da. Die unbequeme Konsequenz: Deine Aufbewahrungsfrist sollte sich nicht daran orientieren, was die Lizenz mitbringt, sondern daran, wie lange ein Angreifer in Deiner Branche typischerweise unentdeckt bleibt.
Drei Fragen, die Du dazu beantworten können solltest — und die ich in Workshops regelmäßig stelle, ohne eine belastbare Antwort zu bekommen: Wie lange werden Deine Unified-Audit-Log-Einträge tatsächlich vorgehalten? Wie lange die Anmeldeprotokolle in Entra? Und gibt es irgendwo eine Kopie, die länger lebt als beide? Wer bei einer der drei Fragen zögert, hat kein Protokollierungsproblem, sondern ein Nachweisproblem.
Das Audit Log durchsuchen: Portal, PowerShell und API
Für die Suche gibt es drei Wege, und die Wahl hängt weniger vom Geschmack ab als vom Umfang der Frage.
Der Weg über das Microsoft Purview Portal ist der Einstieg: Zeitraum wählen, Aktivitäten filtern, Benutzer eingrenzen, Suche starten. Für gezielte Einzelfragen — „was hat dieser eine Benutzer am Dienstag gemacht" — ist das schnell und ausreichend. Bei größeren Zeiträumen läuft die Suche als Auftrag im Hintergrund, und das Ergebnis lässt sich als CSV-Datei exportieren. Genau hier endet die Bequemlichkeit: Der Export ist in der Zeilenzahl begrenzt, und die eigentlich interessanten Details stecken in einer JSON-Spalte, die sich in einer Tabellenkalkulation nur mühsam auswerten lässt.
Der Weg über Exchange Online PowerShell ist der, den ich in echten Untersuchungen fast immer nehme. Das Cmdlet Search-UnifiedAuditLog liefert dieselben Daten, aber skriptbar, filterbar und in beliebiger Menge. Für wiederkehrende Auswertungen — etwa „zeige mir alle neu angelegten Postfachweiterleitungen der letzten 30 Tage" oder „alle Rollenzuweisungen an privilegierte Gruppen" — ist das der einzig praktikable Weg. Wichtig dabei: Die Ergebnisse kommen seitenweise, und wer die Paginierung nicht sauber behandelt, bekommt unvollständige Antworten, ohne dass eine Fehlermeldung darauf hinweist. Das ist ein Fehler, der stillschweigend falsche Sicherheit erzeugt — die Abfrage läuft ja durch.
Der Weg über die Office 365 Management Activity API ist die Grundlage für alles Automatisierte. Ein SIEM zieht die Daten darüber ab, ebenso jede eigene Auswertung, die kontinuierlich laufen soll. Wer Protokolle länger aufbewahren will, als die Lizenz vorsieht, exportiert über diesen Weg in ein eigenes Ziel — und löst damit gleichzeitig das Aufbewahrungsproblem aus dem vorherigen Abschnitt.
Für die Praxis eine Empfehlung zur Reihenfolge: Fang nicht mit dem Werkzeug an, sondern mit der Frage. Definiere zuerst die fünf bis zehn Fragen, die Du im Ernstfall beantworten musst — Wer hat auf welche Daten zugegriffen? Wurden Weiterleitungen eingerichtet? Wurden Berechtigungen erweitert? Wurden Dateien nach außen geteilt? Wurden Anmeldemethoden hinzugefügt? Und prüfe dann für jede einzelne, ob Dein Tenant sie heute beantworten könnte. Diese Übung dauert einen halben Tag und ist die ehrlichste Standortbestimmung, die ich kenne.
Von der Nachschau zur Alarmierung
Ein Audit Log, in das nur nach einem Vorfall geschaut wird, ist ein Archiv, kein Sicherheitswerkzeug. Der Unterschied zwischen beidem liegt darin, ob bestimmte Ereignisse von sich aus jemanden erreichen.
Microsoft bietet dafür Warnungsrichtlinien, die auf Aktivitäten im Audit Log reagieren und bei Auffälligkeiten benachrichtigen. Einige davon sind vorkonfiguriert, weitere lassen sich ergänzen. Meine Empfehlung für den Anfang sind vier Auslöser, die sich in der Praxis als besonders aussagekräftig erwiesen haben: das Anlegen einer Postfachweiterleitung nach extern, die Zuweisung einer privilegierten Rolle, das Hinzufügen einer neuen Anmeldemethode zu einem Konto und ein ungewöhnlich großes Download-Volumen aus SharePoint oder OneDrive. Jeder dieser vier Punkte ist ein verlässlicher Frühindikator für eine Kontoübernahme, und keiner davon erzeugt im Normalbetrieb nennenswertes Rauschen.
Wer bereits mit Defender arbeitet, verbindet die Protokolle sinnvollerweise mit der Erkennung — wie das praktisch aussieht, steht unter Defender XDR Monitoring mit Warnungsrichtlinien. Und ein Hinweis, der zu oft untergeht: Auch die Zugriffe der Administratoren auf das Audit Log selbst werden protokolliert. Das ist kein Misstrauen, sondern die Eigenschaft, die ein Protokoll überhaupt erst gerichtsverwertbar macht. Wer privilegierte Zugriffe zusätzlich zeitlich begrenzen will, findet den passenden Ansatz unter Privileged Identity Management.
Compliance und Haftung: Wer wann nach Deinen Logs fragt
Protokollierung wirkt technisch, ist aber zuallererst ein Haftungsthema. Drei Regelwerke fragen sehr konkret danach.
Die DSGVO verlangt in Artikel 5 Absatz 2 die Rechenschaftspflicht: Du musst die Einhaltung der Grundsätze nicht nur gewährleisten, sondern nachweisen können. Artikel 33 setzt eine Frist von 72 Stunden für die Meldung einer Verletzung des Schutzes personenbezogener Daten. Diese Frist ist nur einzuhalten, wenn Du innerhalb weniger Stunden feststellen kannst, welche Daten betroffen waren — und genau das entscheidet sich am Umfang Deiner Protokollierung, nicht an der Geschwindigkeit Deiner Juristen. Wie Du Deinen Tenant insgesamt DSGVO-konform einrichtest, habe ich separat beschrieben.
ISO 27001:2022 adressiert das Thema in A.8.15 (Protokollierung) und A.8.16 (Überwachungsaktivitäten). Ein Auditor fragt hier nicht, ob Protokollierung aktiv ist — das setzt er voraus. Er fragt nach der Aufbewahrungsfrist, nach dem Schutz der Protokolle vor Veränderung und danach, wer sie regelmäßig auswertet. Die dritte Frage ist die, an der die meisten Organisationen scheitern.
NIS2 verlangt von betroffenen Unternehmen Verfahren zur Behandlung von Sicherheitsvorfällen, und die Meldefristen sind noch enger als bei der DSGVO — eine Frühwarnung ist binnen 24 Stunden fällig. Da die Geschäftsleitung für die Umsetzung persönlich verantwortlich ist, wird die Frage nach der Protokollierung damit zu einer Frage an die Geschäftsführung, nicht an die IT.
Es gibt außerdem eine Grenze, die in die andere Richtung wirkt und die man kennen sollte: Protokollierung darf nicht zur Leistungs- und Verhaltenskontrolle werden. In Deutschland ist bei einer Auswertung, die Rückschlüsse auf einzelne Beschäftigte zulässt, der Betriebsrat einzubeziehen. Ein sauber dokumentierter Auswertungszweck, ein definierter Kreis von Berechtigten und ein Vier-Augen-Prinzip bei personenbezogenen Auswertungen lösen das in der Praxis — aber sie müssen vorher vereinbart sein, nicht im Vorfall improvisiert werden.
Häufige Fragen
Was bedeutet Audit-Log in Microsoft 365?
Das Audit-Log — offiziell Unified Audit Log — ist die dienstübergreifende Aufzeichnung von Benutzer- und Administratoraktivitäten in Microsoft 365. Es hält fest, wer wann welche Aktion in Exchange Online, SharePoint, OneDrive, Teams, Microsoft Entra und Purview ausgeführt hat.
Wie lange werden Audit-Logs in Microsoft 365 aufbewahrt?
Mit Audit (Standard) rund 180 Tage, mit Audit (Premium) ein Jahr; über ein Add-on sind bis zu zehn Jahre möglich. Wichtig: Die Anmeldeprotokolle in Microsoft Entra haben eine eigene, kürzere Frist — 7 Tage in der Free-Lizenz, 30 Tage mit P1 oder P2.
Wie aktiviere ich das Unified Audit Log?
Für die meisten Tenants ist die Protokollierung standardmäßig aktiv. Prüfen lässt sich das im Microsoft Purview Portal unter Audit; fehlt die Suchfunktion, muss die Protokollierung dort erst eingeschaltet werden. Verlasse Dich nicht auf die Annahme — prüfe es einmal aktiv.
Wie sehe ich Audit-Logs in Office 365 ein?
Über drei Wege: das Microsoft Purview Portal für gezielte Einzelfragen, Search-UnifiedAuditLog in der Exchange Online PowerShell für skriptbare Auswertungen, und die Office 365 Management Activity API für alles Automatisierte, etwa die Anbindung an ein SIEM.
Was ist der Unterschied zwischen Audit-Log und Anmeldeprotokoll?
Das Unified Audit Log erfasst Aktivitäten in den Diensten. Die Anmeldeprotokolle in Microsoft Entra erfassen Anmeldevorgänge — mit IP-Adresse, Gerät und Risikobewertung. Es sind getrennte Quellen mit getrennten Aufbewahrungsfristen, und für eine Untersuchung brauchst Du beide.
Dürfen Audit-Logs zur Mitarbeiterüberwachung genutzt werden?
Nein, nicht als Leistungs- und Verhaltenskontrolle. In Deutschland ist bei Auswertungen, die Rückschlüsse auf einzelne Beschäftigte zulassen, der Betriebsrat einzubeziehen. Ein dokumentierter Auswertungszweck, ein definierter Berechtigtenkreis und ein Vier-Augen-Prinzip lösen das — vorher vereinbart, nicht im Vorfall improvisiert.
Audit-Log-Self-Check
Jedes „Nein" ist eine Lücke, die genau dann sichtbar wird, wenn Du sie am wenigsten gebrauchen kannst:
Wo Du mehrfach zögerst, lohnt eine strukturierte Bestandsaufnahme statt punktueller Nachbesserung. Weitere Härtungsmaßnahmen findest Du unter Microsoft 365 Security und Empfehlungen, und Deinen Fortschritt machst Du über den Microsoft Secure Score messbar.
Bereit, Deine Nachweisfähigkeit auf den Prüfstand zu stellen?
Ich bin Aaron Siller, Microsoft MVP für Security und Gründer von siller.consulting. In meiner Beratungspraxis sehe ich regelmäßig Tenants, in denen die Protokollierung technisch einwandfrei läuft — und trotzdem niemand die Fragen beantworten könnte, die im Ernstfall gestellt werden. Der Unterschied liegt selten an der Technik. Er liegt an Aufbewahrungsfristen, die niemand überprüft hat, und an Auswertungen, die nie jemand gefahren ist.
In einem persönlichen Workshop gehen wir Deinen Tenant gemeinsam durch: tatsächliche Protokolltiefe, reale Aufbewahrungsfristen über beide Log-Quellen, die Fragen, die Du im Vorfall beantworten musst — und ob Dein heutiges Setup sie beantworten kann. Kein Folienvortrag, sondern Hands-on an Deiner echten Umgebung.
Oder starte direkt mit unserem Microsoft 365 Hardening Check: Wir prüfen strukturiert, wie belastbar Deine Protokollierung heute ist — und Du weißt anschließend, welche Lücken Dich im Ernstfall wirklich treffen würden.
