DC Security Log Aufbewahrung: Lesbare Historie prüfen

Was umfasst die Prüfung der DC Security Log Aufbewahrung?

Eine Prüfung der DC Security Log Aufbewahrung stellt fest, welche Security-Ereignisse ein Ermittler auf jedem Domänencontroller, in dessen Archiven und am zentralen Protokollierungsziel noch lesen kann. Das nützliche Ergebnis ist ein datierter Nachweis, der sich auf eine genehmigte organisatorische Richtlinie bezieht. Eine konfigurierte maximale Dateigröße, ein altes Ereignis oder eine funktionierende Weiterleitungsverbindung ist jeweils nur ein Teil dieses Nachweises.

Drei Fragen benötigen getrennte Antworten: Wurden die erforderlichen Ereignisse erzeugt, sind sie lokal noch lesbar, und hat das vorgesehene zentrale System sie empfangen und aufbewahrt? Beginnen Sie mit den Prüfungen der wirksamen Auditrichtlinie zur Ereigniserzeugung. Dieser Leitfaden untersucht Auditeinstellungen mit auditpol; diese Prüfung behandelt die lesbare Historie, das Kanalverhalten, Archive und den Nachweis einer zentralen Kopie.

Dieses Verfahren umfasst Active-Directory-Domänencontroller und ihre Windows-Security-Kanäle. Es bewertet nicht die Aufbewahrung von Microsoft-Entra-Auditprotokollen. Die folgenden Befehle sind dokumentationsbasierte Beispiele für autorisierte Windows-Administratoren; sie wurden für diesen Artikel nicht in einer Kundendomäne ausgeführt. Die Dokumentation und das Verhalten des Collectors wurden am 4. Oktober 2026 geprüft.

Wie Kanalkapazität und Aufbewahrungsmodus funktionieren

Microsoft dokumentiert über wevtutil drei relevante Verhaltensweisen: Bei deaktivierter Aufbewahrung überschreiben neue Datensätze die ältesten, sobald die Kapazität erreicht ist; bei aktivierter Aufbewahrung und deaktivierter automatischer Sicherung bleiben vorhandene Datensätze erhalten, während eingehende Datensätze bei vollem Protokoll verworfen werden. Die automatische Sicherung setzt aktivierte Aufbewahrung voraus und sichert das Protokoll, sobald es seine maximale Größe erreicht. Die Einstellung /ms steuert einen Grenzwert in Bytes, keine garantierte Anzahl von Tagen. Siehe die Befehlsreferenz zu wevtutil.

Betrachten Sie jeden Domänencontroller einzeln. Die Historie eines wenig ausgelasteten Servers kann keinen stärker ausgelasteten Controller repräsentieren, und ein Konfigurationsexport ersetzt keinen erfolgreichen Lesezugriff auf Ereignisse. Bewahren Sie die wirksamen Einstellungen zusammen mit den Beobachtungen auf, statt die Prüfung allein anhand von Einstellungen abzuschließen.

Definieren Sie die Richtlinie, bevor Sie ein Urteil vergeben. Bitten Sie den verantwortlichen Eigentümer, die Ereignismengen, den erforderlichen Zeitraum, lokale und zentrale Zuständigkeiten, Zugriffsanforderungen und das akzeptable Wiederherstellungsverhalten festzulegen. Dokumentieren Sie Richtlinienversion und Genehmigung. Der Leitfaden zur Compliance-Zuordnung verbindet benannte Kontrollen mit Nachweisen aus dem Produktivbetrieb; wenden Sie diesen Ansatz auf die tatsächliche Aufbewahrungsrichtlinie an, statt eine universelle gesetzliche Dauer zu erfinden.

Erkennung: Für jeden DC einen datierten Nachweis erfassen

Schritt 1: Die wirksame Konfiguration des Security-Kanals lesen

Führen Sie diese Befehle mit autorisiertem Zugriff lokal auf jedem identifizierten DC aus. Ihre Syntax ist in Learn dokumentiert; Security ist der für dieses Verfahren ausgewählte Kanal.

wevtutil gl Security
Get-WinEvent -ListLog Security
Get-WinEvent -ListLog Security | Format-List -Property *

Die Get-WinEvent-Referenz dokumentiert -ListLog, Konfigurationseigenschaften, die Ereignisreihenfolge, -MaxEvents, -Oldest und das Lesen gespeicherter Protokolle über -Path. Erfassen Sie LogMode, MaximumSizeInBytes, FileSize, RecordCount, IsLogFull und LogFilePath, soweit zurückgegeben. Bewahren Sie die unveränderte Ausgabe, die Hostidentität, den Erfassungszeitpunkt mit Zeitzone, den ausführenden Administrator und das Befehlsergebnis auf.

Schließen Sie einen DC nicht stillschweigend aus, weil ein Lesezugriff fehlschlägt. Bewahren Sie den Fehler auf und kennzeichnen Sie seine Nachweise bis zur Untersuchung als nicht verfügbar. Ein Berechtigungsfehler, ein leeres Ergebnis und ein erfolgreich gelesenes Protokoll sind unterschiedliche Ergebnisse. Das Prüfregister sollte alle drei für seinen Verantwortlichen sichtbar machen.

Schritt 2: Beide Enden der verfügbaren Ereignisfolge lesen

Get-WinEvent -LogName Security -MaxEvents 1 -Oldest |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName
Get-WinEvent -LogName Security -MaxEvents 1 |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName

Standardmäßig stehen die neuesten Ereignisse zuerst; -Oldest kehrt die Reihenfolge um. Bewahren Sie die zurückgegebenen Zeitstempel und Identitäten auf, ohne anzunehmen, dass sie eine lückenlose Abdeckung belegen. Gleichen Sie die Darstellung der Zeitzonen ab, bevor Sie Quellen vergleichen. Diese begrenzten Lesezugriffe identifizieren die Enden der verfügbaren Folge, statt über alle Datensätze hinweg die kleinsten und größten Zeitstempel zu berechnen.

Halten Sie für die Prüfung die beobachtete Zeitspanne und deren Grenzen fest. Liegt der erste lesbare Datensatz nach dem laut Richtlinie erforderlichen Anfangszeitpunkt, untersuchen Sie, ob ein Archiv oder eine genehmigte zentrale Kopie die fehlende Historie bereitstellt. Liegt er davor, prüfen Sie weiterhin die erforderlichen Ereignismengen und bekannten Unterbrechungen. Ein früher Zeitstempel allein belegt keine Vollständigkeit.

Schritt 3: Nachweise und Entscheidung dokumentieren

Verwenden Sie eine Zeile pro DC und anschließend verknüpfte Zeilen für Archive und zentrale Ziele. Vermeiden Sie eine einzige domänenweite Bestanden/Nicht-bestanden-Zelle, die einen nicht zugänglichen Server verbirgt. Das folgende Nachweisregister ist ein Vorschlag, keine gemessene Ausgabe:

Der Prüfer sollte zwischen einem nachgewiesenen Defizit und einer unbeantworteten Frage unterscheiden. Ein unlesbares Archiv ist eine Nachweislücke, auch wenn die Datei vorhanden ist. Eine zentrale Abfrage, die einen DC auslässt, ist ein unvollständiger Test, selbst wenn das Ziel viele Datensätze anderer Server liefert. Bewahren Sie diese Unterscheidungen im Behebungsticket.

Archive und die zentrale Kopie überprüfen

Eine Archivinventur sollte zu tatsächlichen Lesezugriffen führen. Passen Sie diese dokumentierte -Path-Syntax an jeden genehmigten Speicherort für Security-Archive an; der folgende Pfad ist ein Beispiel, keine gefundene Datei.

Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1 -Oldest
Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1

Dokumentieren Sie fehlgeschlagene neben erfolgreichen Lesezugriffen. Durchsuchen Sie anschließend die Archive nach den in der Richtlinie erforderlichen Ereignismengen und Zeiträumen. Eine lesbare Stichprobe an den Grenzen belegt nur, dass diese Datensätze geöffnet werden können; die Prüfung benötigt weiterhin eine ausdrückliche Suche, welche die relevanten Untersuchungsfragen abdeckt.

Wählen Sie für WEC oder ein anderes Protokollierungsziel bekannte Quellereignisse aus und suchen Sie die entsprechenden zentralen Datensätze. Bewahren Sie Quellcomputer, Kanal, Anbieter, Ereigniskennung, Zeitstempel und relevante Ereignisdaten für den Vergleich auf. Dokumentieren Sie jede Transformation in der Aufnahmepipeline, statt anzunehmen, dass eine vom Ziel vergebene Datensatznummer der Nummer des Quelldatensatzes entspricht.

Trennen Sie Empfang und Durchsuchbarkeit. Das Nachweispaket sollte das zentrale Aufnahmeziel und die vom Ermittler verwendete Abfrage einschließlich Filtern, Zeitraum und Ergebnis enthalten. Ein Datensatz, der in einem Eingangsprotokoll sichtbar, über den genehmigten Suchweg aber nicht verfügbar ist, hinterlässt eine praktische Untersuchungslücke. Umgekehrt bestätigt eine erfolgreiche zentrale Stichprobe nicht sämtliche Datensätze oder jeden DC.

Behebung: Genehmigte Richtlinie erfüllen und Wiederherstellung testen (Remediation)

Schritt 1: Die konkrete Lücke beheben

Leiten Sie die Änderung aus den Nachweisen ab: lokale Kapazität, Umgang mit vollen Protokollen, Archivzugriff, Abonnementumfang, zentraler Speicher oder Suchpipeline. Benennen Sie einen Verantwortlichen und einen Prüfschritt. Entscheidungen zu Größe und Modus benötigen das erwartete Ereignisaufkommen und Unterbrechungsszenario dieser Umgebung; dieser Artikel schreibt weder einen universellen Byte-Grenzwert noch eine Aufbewahrungsdauer vor.

Bewahren Sie vor einer Kanaländerung die aktuelle Konfiguration und erforderlichen Nachweise auf. Wenden Sie die genehmigte Konfiguration über den verwalteten Prozess des Teams an und wiederholen Sie anschließend die Konfigurations- und Ereignisabfragen. Dokumentieren Sie die beabsichtigte Einstellung und das beobachtete Ergebnis. Leeren Sie kein Security-Protokoll, um ein früheres Aufbewahrungsproblem verschwinden zu lassen, und behandeln Sie eine höhere Kapazität nicht als Beweis dafür, dass bereits verlorene Historie wiederhergestellt wurde.

Schritt 2: Dokumentierte WEF-Zustelleinstellungen prüfen

Microsofts WEF-Leitfaden zur Angriffserkennung erklärt, dass WEF vorhandene Kanalereignisse liest; es aktiviert weder ihre Erzeugung noch ändert es die Größe des Quellprotokolls. Das lokale Protokoll puffert Ereignisse bei Verbindungsunterbrechungen. Überschreiben kann Ereignisse verlieren lassen, ohne WEC eine Lücke zu melden. Der Leitfaden dokumentiert außerdem Lesezeichen, Heartbeats, die Option zum Lesen vorhandener Ereignisse und benutzerdefinierte Zustelleinstellungen.

Dies sind Microsofts Beispielparameter, die in einer Shell mit erhöhten Rechten für ein genehmigtes Testabonnement auf WEC zu prüfen sind; sie sind keine Dimensionierungsempfehlungen für den Produktivbetrieb:

Wecutil ss "testSubscription" /cf:Events
Wecutil ss "SubscriptionNameGoesHere" /cm:Custom
Wecutil ss "SubscriptionNameGoesHere" /dmi:1
Wecutil ss "SubscriptionNameGoesHere" /dmlt:10

/cf:Events wählt das Ereignisformat; /cm:Custom wählt die benutzerdefinierte Zustellung; /dmi legt die maximale Anzahl von Ereignissen pro Zustellung fest, während /dmlt die maximale Zustelllatenz in Millisekunden festlegt. Ersetzen Sie die Beispielnamen erst nach Prüfung des vorgesehenen Abonnements. Das Lesen vorhandener Ereignisse kann verfügbare Historie erfassen; es kann überschriebene oder nie erzeugte Ereignisse nicht wiederherstellen.

Schritt 3: Eine genehmigte Unterbrechung validieren

Planen Sie mit dem Monitoring-Verantwortlichen einen kontrollierten Test mit definiertem Umfang, einer Abbruchbedingung und einem Wiederherstellungsverfahren. Wählen Sie harmlose Aktivitäten aus, die bereits von den erforderlichen Auditeinstellungen und dem Abonnement abgedeckt sind. Dokumentieren Sie die entsprechenden Quellereignisse vor, während und nach der Unterbrechung. Legen Sie im Voraus fest, welche Datensätze zentral durchsuchbar sein sollten und wann das Team sie bewerten wird.

Stellen Sie die Erfassung wieder her und überprüfen Sie diese Datensätze anschließend über den genehmigten zentralen Suchweg. Bewahren Sie Quellnachweise, Unterbrechungsablauf, Abonnementeinstellungen, zentrale Ergebnisse und Fehler auf. Untersuchen Sie Abweichungen, auch wenn die Verbindung wiederhergestellt ist. Melden Sie jedes fehlende Intervall ausdrücklich und klären Sie, ob verbliebene Archive oder eine andere genehmigte Kopie es abdecken können.

Schritt 4: Die Nachweisprüfung abschließen

Der Abschluss sollte genau benennen, was bewertet wurde: die DC-Population, erforderliche Ereignisse, Richtlinienzeitraum, lokal verfügbare Historie, Archive, zentrales Ziel und Suchweg. Fügen Sie offene Ausnahmen mit Verantwortlichem und Prüftermin bei. Umfasste der Test nur einen Controller oder ausgewählte Ereignisse, geben Sie diesen Umfang an und planen Sie die verbleibenden Prüfungen.

Halten Sie die Nachweise datiert. Wiederholen Sie die Prüfung nach Änderungen an der DC-Population, Protokollierungskonfiguration, den Archiven oder der zentralen Erfassung. Die sinnvolle Wartungsaufgabe besteht darin, die zugrunde liegenden Belege zu erneuern und Abweichungen zu untersuchen, statt das vorherige Urteil in einen neuen Bericht zu kopieren.

Wie EtcSec dies erkennt

In etc-collector beim Commit 9f698083354a1cb7f625df5cb490a515823c3257 erzeugt AUDIT_LOG_RETENTION_SHORT einen einzelnen Info-Befund mit konstantem Count=1. Seine Methode Detect() liest keine DetectorData-Felder und gibt die Erinnerung auch ohne DC-Daten zurück. Sie misst weder die Protokollkapazität noch die lesbare Aufbewahrung und kann eine konforme Umgebung nicht von einer mangelhaften unterscheiden oder nach der Behebung automatisch grün werden.

Der untersuchte AD-Erfassungspfad ruft Verzeichnisobjekte und GPO-Daten über LDAP ab; dieser Detektor ruft keinen Ereignisprotokollanbieter auf und liest keinen lokalen Security-Kanal. Nutzen Sie die Erinnerung, um die oben beschriebenen Nachweise pro DC anzufordern, nicht als Beweis eines Aufbewahrungsdefizits.

Dokumentieren Sie die manuelle Prüfung und die genehmigte Entscheidung zusammen mit der Erinnerung. Halten Sie die Belege zur lesbaren Historie und die zentralen Suchergebnisse für den Verantwortlichen verfügbar, der den Abschluss akzeptiert.