Auditnachweis fuer Windows Dateizugriffe: SACLs, 4656/4663

Was ist ein Auditnachweis fuer Windows Dateizugriffe?

Ein Auditnachweis fuer Windows Dateizugriffe verbindet die wirksame Auditrichtlinie eines Servers, die Überwachungsregeln einer Datei und einen kontrollierten Zugriffsversuch mit den daraus entstehenden Security-Ereignissen. Eine Gruppenrichtlinieneinstellung allein kann diese Verbindung nicht belegen. Verwenden Sie vor einer Änderung der Produktionsrichtlinie Testdateien, um festzustellen, welche Identitäten und Dateirechte tatsächlich Nachweise auf einem Server innerhalb des vereinbarten Bereichs erzeugen.

Dieser Leitfaden trennt drei Fragen: Ist Audit File System auf diesem Server aktiviert, besitzt die Datei eine passende Systemzugriffssteuerungsliste (SACL) und beschreibt das aufgezeichnete Ereignis den getesteten Vorgang? Halten Sie die Antworten zusammen in einem Prüfprotokoll fest. Ein beruhigender Richtlinienwert ohne entsprechendes Ereignis lässt den Nachweis unvollständig.

Das folgende Verfahren wurde nicht in einer produktiven Domäne ausgeführt. Die Befehle verwenden dokumentierte Microsoft-Syntax; Pfade und Identitäten sind Beispiele, die durch genehmigte Testwerte zu ersetzen sind. Erwartete Beobachtungen sind Abnahmekriterien, keine berichteten Laborergebnisse.

Funktionsweise der Dateiüberwachung: Richtlinie, SACL und Zugriff

Microsofts Dokumentation zu Audit File System macht die Überwachung von einer passenden SACL abhängig: Das anfordernde Konto und der angeforderte Zugriff müssen mit ihren Einträgen übereinstimmen. Die Überwachung von Erfolg und Fehlschlag dient unterschiedlichen Ergebnissen. Die Aktivierung der Unterkategorie ohne geeignete Objektüberwachungsregeln belegt keine Abdeckung auf Dateiebene. Microsoft empfiehlt außerdem, die Auswertung der erfassten Ereignisse zu planen und übermäßige Überwachungsregeln zu entfernen.

Dateiberechtigungen und Überwachungsregeln erfüllen unterschiedliche Aufgaben. Prüfen Sie die diskretionäre Zugriffssteuerungsliste (DACL), um den vorgesehenen erlaubten oder verweigerten Zugriff festzustellen, und anschließend die SACL, um festzustellen, welche Versuche aufgezeichnet werden sollen. Das Hinzufügen einer Überwachungsregel ist kein Grund, ein ansonsten unzulässiges Dateirecht zu gewähren.

Legen Sie den Nachweisbereich vor dem Test fest. Welche Server und Dateirechte müssen nachgewiesen werden? Identifizieren Sie Host, synthetischen Pfad, Testidentität, Anwendung und Vorgang. Ein lokaler Lesezugriff auf einem Mitgliedsserver belegt diesen konkreten Fall; er belegt keine Abdeckung für jeden Server oder jede Anwendung. Halten Sie die Überwachung von Verzeichnisobjekten getrennt: Unser AD-Monitoring-Leitfaden zu Ereigniserfassung, Feldzuordnung und Validierung erläutert die umfassendere Pipeline zur Identitätsüberwachung einschließlich Verzeichnisereignissen. Hier ist das getestete Objekt eine Testdatei.

Eine Handle-Anforderung ist kein verwendetes Dateirecht

Diese Unterscheidungen stammen aus Microsofts 4656-Referenz und 4663-Referenz. Beide erfordern außerdem den relevanten SACL-Eintrag. Für dieses Protokoll sollte ein erlaubter Dateilesezugriff anhand eines passenden 4663 und eine verweigerte Handle-Anforderung anhand eines passenden Failure 4656 bewertet werden.

Überprüfung: Nachweise vor der Behebung aufbauen

Schritt 1: Die wirksame Richtlinie auf dem gewählten Server dokumentieren

Führen Sie Folgendes auf dem Server aus, der die Testdateien hostet, mit einem Konto, das die Auditrichtlinie prüfen darf. Microsoft dokumentiert die Auswahl von Kategorien und Unterkategorien sowie die CSV-Berichtsoption in auditpol get:

auditpol /get /subcategory:* /r

Bewahren Sie die vollständige Ausgabe mit Servername, Erfassungszeitpunkt und ausführender Person auf. Suchen Sie File System und dokumentieren Sie dessen Einstellungen für Erfolg und Fehlschlag. Bei einem Protokoll, das sowohl erlaubte als auch verweigerte Zugriffe abdeckt, stellen Sie beide Einstellungen fest, bevor Sie beide Arten von Nachweisen erwarten. Ist ein Modus deaktiviert, dokumentieren Sie diese Beobachtung und ihre Folge, statt den gesamten Server als überprüft zu kennzeichnen.

Bewahren Sie die GPO-Sicht als separates Artefakt auf. Sie dokumentiert die deklarierte Konfiguration; die lokale Abfrage dokumentiert die vom Host zurückgegebene Systemauditrichtlinie. Falls eine benutzerspezifische Richtlinie die Testidentität beeinflussen könnte, prüfen Sie auch diese mit dem dokumentierten Selektor /user. Dokumentieren Sie jeden Berechtigungsfehler als unvollständige Messung, nicht als leere oder deaktivierte Richtlinie.

Schritt 2: Die SACLs der tatsächlich verwendeten Testdateien prüfen

Bereiten Sie über die genehmigte Testeinrichtung zwei synthetische Dateien vor, beispielsweise C:\AuditProof\allow.txt und C:\AuditProof\deny.txt. Sorgen Sie dafür, dass die Testidentität das gewählte Recht auf der ersten Datei besitzt und auf der zweiten nicht. Prüfen Sie beide DACLs, bevor Sie fortfahren; nehmen Sie nicht an, dass ein Dateiname einen Zugriff erlaubt oder verweigert.

Microsoft dokumentiert -Audit in Get-Acl als Abruf von SACL-Daten. Diese Befehle passen die dokumentierten Parameter an die Beispielpfade an. Führen Sie jede Zeile einzeln in Windows PowerShell oder PowerShell unter Windows aus:

$allowAcl = Get-Acl -LiteralPath 'C:\AuditProof\allow.txt' -Audit
$allowAcl.Audit
$allowAcl.Sddl

$denyAcl = Get-Acl -LiteralPath 'C:\AuditProof\deny.txt' -Audit
$denyAcl.Audit
$denyAcl.Sddl

Bewahren Sie die zurückgegebenen Überwachungseinträge und den Sicherheitsdeskriptor für jede Datei auf oder den genauen Fehler, falls die Prüfung fehlschlägt. Prüfen Sie Identität, überwachte Rechte, Flags für Erfolg und Fehlschlag sowie Vererbungsbereich. Die Anzahl von Einträgen reicht nicht aus: Der relevante Eintrag muss diese Identität und diesen Vorgang auf diesem Objekt abdecken. Eine geerbte Regel sollte auf der tatsächlich verwendeten Datei bewertet werden, nicht allein aus einem übergeordneten Ordner abgeleitet werden.

Die Entscheidung ist hier konkret: Welche SACL deckt die erforderliche Identität, Ergebnisse und Rechte ohne übermäßiges Rauschen oder sensible Inhalte ab? Geben Sie die gewählten Rechte an und begründen Sie, warum sie für den Nachweis ausreichen. Erweitern Sie den Bereich nicht nur, um mehr Ereignisse zu erhalten.

Schritt 3: Die erlaubten und verweigerten Fälle getrennt ausführen

Führen Sie mit der gewählten Testanwendung unter der gewöhnlichen Testidentität den gewählten Vorgang auf allow.txt aus. Versuchen Sie anschließend denselben Vorgang auf deny.txt. Dokumentieren Sie für jeden Fall Start- und Endzeit, Anwendung, Identität, Ziel und beobachtetes Ergebnis. Verwenden Sie den prüfenden Administrator nicht als Identität für den Zugriffstest; das Protokoll muss die zu prüfenden Berechtigungen tatsächlich ausüben.

Lesen Sie bei einem Lesetest die erlaubte Testdatei tatsächlich, statt sie lediglich in einem Dateiauswahldialog auszuwählen. Dokumentieren Sie beim verweigerten Fall die Ablehnung durch die Anwendung und prüfen Sie die zugehörigen Nachweise der Handle-Anforderung. Erfolgt die Ablehnung, bevor die vorgesehene Datei erreicht wird, belegt der Fall die Überwachung dieser Datei noch nicht. Halten Sie ein solches Ergebnis im Protokoll sichtbar und untersuchen Sie den Zugriffspfad.

Erwarten Sie keine feste Anzahl von Ereignissen. Prüfen Sie während des dokumentierten Zeitfensters das Security-Protokoll des Hosts in Event Viewer und filtern Sie nach 4656 und 4663. Vergleichen Sie Konto-, Objekt- und Zugriffsfelder mit dem Testblatt, bevor Sie ein Ereignis einem Fall zuordnen.

Schritt 4: Das Ereignis aufbewahren und die Entscheidung erläutern

Bewahren Sie für jedes relevante Ereignis das ursprüngliche Ereignis-XML am genehmigten Nachweisort auf. Microsoft dokumentiert Identität und Anmelde-ID des Subjekts, Objekttyp und -name, Prozessinformationen, Handle-ID und Zugriffsfelder. In 4663 beschreibt die Zugriffsliste verwendete Rechte; in 4656 beschreibt sie angeforderte Rechte. Für einen Dateilesezugriff ist das dokumentierte Recht ReadData gleich 0x1; unterscheiden Sie dies bei der Interpretation von Objekt und Vorgang von Verzeichnisauflistung oder reinem Metadatenzugriff.

Verwenden Sie, wenn verfügbar, die Handle-ID zur Korrelation zusammen mit Host, Zeitpunkt, Subjekt, Prozess und Objekt. Microsoft weist darauf hin, dass das Handle-Feld 0x0 sein kann; es darf nicht der alleinige Verknüpfungsschlüssel sein. Schreiben Sie auf, ob jedes aufbewahrte Ereignis den erlaubten Vorgang oder die verweigerte Anforderung stützt und was unbewiesen bleibt.

Wenn die Monitoring-Vereinbarung eine zentrale Erfassung umfasst, suchen Sie dort dasselbe Ereignis und vergleichen Sie seine wesentlichen Felder. Ein lokales Ereignis und ein zentral nutzbarer Datensatz sind separate Nachweise. Dieser Vergleich ist ein vorgeschlagener Validierungsschritt, keine Behauptung, dass ein bestimmter Collector diese Felder bewahrt.

Behebung: Die nachgewiesene Lücke schließen und erneut testen (Remediation)

Schritt 5: Die Richtlinie oder SACL ändern, die die Überprüfung nicht bestanden hat

Fehlt bei File System die Überwachung von Erfolg oder Fehlschlag, korrigieren Sie die anwendbare Richtlinie für den gewählten Server. Die Dokumentation zu auditpol set unterstützt die Angabe einer Unterkategorie nach Name oder GUID und die Aktivierung jedes Ergebnisses. In einem genehmigten Pilotversuch mit englischem Unterkategorienamen lautet der entsprechende Befehl:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Behandeln Sie dies als lokale Pilotänderung und bewahren Sie die vorherigen Einstellungen für ein Rollback auf. Korrigieren Sie bei einer verwalteten Bereitstellung die anwendbare Richtlinie über den GPO-Änderungsprozess des Teams und überprüfen Sie den resultierenden Hostzustand erneut. Eine erfolgreiche Befehlsantwort allein schließt die Nachweislücke zum Dateizugriff nicht.

Verwenden Sie auf lokalisierten Systemen den tatsächlichen Namen oder die GUID aus Microsofts dokumentiertem auditpol list-Befehl:

auditpol /list /subcategory:* /r

Ist die Richtlinie aktiviert, die SACL passt jedoch nicht, korrigieren Sie den Überwachungseintrag für die gewählte Testidentität, das Recht und das Ergebnis über den genehmigten Ablauf zur Objektsicherheit. Bewahren Sie die DACL und die ursprüngliche SACL für die Prüfung auf. Wiederholen Sie die Prüfung, bevor Sie den Zugriff wiederholen; eine Änderung der Erlauben-/Verweigern-Berechtigungen würde den Test selbst verändern.

Schritt 6: Richtlinienabweichungen klären, ohne Erfolg zu erklären

Wenn ältere GPO-Einstellungen korrekt erscheinen, das Hostverhalten aber abweicht, prüfen Sie die anwendbare erweiterte Richtlinie und die Sicherheitsoption zum Überschreiben durch Unterkategorien. Microsoft dokumentiert SCENoApplyLegacyAuditPolicy als Verhinderung der Anwendung von Richtlinien auf Kategorieebene. Unser Auditrichtlinien-Leitfaden zu wirksamen Einstellungen und Konflikten zwischen älteren und erweiterten Richtlinien liefert den umfassenderen Konfigurationskontext.

Die offene Entscheidung betrifft die Frage, welche Nachweise aufbewahrt werden sollen, wenn das erwartete Ereignis trotz beruhigender älterer Konfiguration fehlt. Halten Sie lokale Richtlinienausgabe, tatsächliche SACL, Testergebnis, Suchzeitfenster und Erfassungsort zusammen. Weisen Sie die Abweichung einem Verantwortlichen zu. Wiederholen Sie nach der gezielten Änderung denselben Vorgang und die Nachweisprüfung; ersetzen Sie einen ungeklärten Fall nicht durch einen breiteren, einfacheren Test.

Wie EtcSec dies erkennt

Bei Collector-Commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d liest HDS_5_4_LOG_ACCESS_TO_HEALTH_DATA die GPOPolicies und ihre älteren Werte EventAudit.AuditObjectAccess. Der SMB-Provider befüllt dieses Feld aus [Event Audit] in GptTmpl.inf. Er erfasst erweitertes audit.csv separat, doch dieses Detect() verwendet es nicht.

Die implementierte Bedingung akzeptiert jede erfasste nicht-null GPO mit nicht-null EventAudit und AuditObjectAccess >= 3. Existiert eine solche GPO, ist Count 0. Andernfalls ist Count 1, wenn die GPO-Richtliniensammlung nicht leer ist; eine leere Sammlung ergibt ebenfalls Count 0. Obwohl der Kommentar beschreibt, dass genau 3 erforderlich sei, lautet die ausführbare Bedingung >= 3.

Folglich kann eine GPO außerhalb des Bereichs des getesteten Servers den Befund unterdrücken. Diese Kontrolle beobachtet weder wirksame Richtlinien pro Server noch SACLs, Dateipfade, Zugriffsversuche, die Klassifizierung von Gesundheitsdaten oder Security-Ereignisse. Weder ein Befund noch Count 0 belegt das Ergebnis dieses Validierungsprotokolls. Verwenden Sie das Signal, um Nachweise für den festgelegten Bereich anzufordern und seine Grenzen zu dokumentieren.

Die Prüfung mit einem bereichsbezogenen Urteil abschließen

Dokumentieren Sie für jeden Server, jedes Objekt, jede Identität und jedes Recht ein Urteil: nachgewiesen, fehlgeschlagen oder unvollständig. Fügen Sie Richtlinien-/SACL-Artefakte, das tatsächliche Anwendungsergebnis, relevante Ereignisse, einen etwaigen Vergleich mit der zentralen Erfassung, die Behebungsentscheidung und das Ergebnis des erneuten Tests bei. Geben Sie Ausschlüsse ausdrücklich an, damit ein Prüfer einen bestandenen Testdateifall von einer nie getesteten Abdeckung unterscheiden kann.

Technische Quellen und Collector-Implementierung wurden am 4. Oktober 2026 geprüft. Die Beispiele bleiben ein Verfahren, das mit genehmigten Testdaten auszuführen ist, ohne Inhalte von Gesundheitsdaten zu erfassen.