Lösungsansatz
Wenn auf einem Dateiserver nun sehr viele Dateien "herumliegen", die schon länger nicht mehr beschrieben wurden und vielleicht sogar aus Compliance-Gründen auch gar nicht mehr verändert werden sollten, dann könnte doch ein Prozess auf dem Server diese Dateien mit einem "Deny Write" für die normalen Benutzerkonten versehen. Wenn später ein Anwender eine Datei wirklich noch einmal ändern möchte, dann kann er diese einfach mit einem neuen Dateinamen, z.B. mit einer Versionsnummer, abspeichern: Aber damit wäre zuverlässig verhindert, dass ein Schadcode diese Dateien löscht oder verschlüsselt. Die Grundfunktion wäre also:
Die Analyse der Dateien hat aber auch gezeigt, dass ich noch einmal nachschauen muss, welchen Zeitstempel ich heranziehe Eine Datei auf einem NTFS-Dateisystem hat drei "Zeiten"
Feld | Beschreibung | Werte in der 100.000 Files-Auswertung |
---|---|---|
CreationTime |
Enthält das Datum, wann die Datei angelegt wurde. |
Maximum : 19.12.2015
22:20:24 |
LastWriteTimeUTC |
Enthält das Datum, wann das letzte Mal schreibend auf die Datei zugegriffen wurde |
Maximum : 22.02.2024
21:22:22 |
LastAccessTimeUTC |
Enthält den letzten lesenden Zugriff auf die Date |
Maximum : 19.12.2015
21:20:29 |
EEs ist schon irritierend, wenn Dateien angeblich so weit in die Zukunft oder in der Vergangenheit geändert sein sollen. Leider konnte ich nicht mehr nachvollziehen, warum das der Fall war. Anhand der gefundenen Werte muss man schon noch mal nachschauen, welche Information wie geändert wird. Denn per Software kann auch ein Client das Datum jederzeit ändern und zwar alle Daten. Das ist insbesondere wichtig, wenn eine Datei "kopiert" wird, z.B. wenn ein Consultant eine Datei auf dem Notebook erstellt und bearbeitet hat. Dann ist es schon interessant zu sehen, welche Felder beim COPY mitkommen. Zählt als "CreationDate" und "LastWriteDate" dann der Kopierprozess oder wird das originale Datum übernommen? Was passiert bei Änderungen von Berechtigungen oder beim Restore oder einem VSS-Restore ?
Vorgang | CreationTime | LastAccessTime | LastWriteTime | Bemerkung |
---|---|---|---|---|
Datei mit Notepad anlegen |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
Erwartetes Verhalten |
Datei mit Notepad schreiben |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
220.12.2015:21:05:37 |
LastWriteTime wird zuverlässig aktualisiert. |
Datei mit Notepad erneut lesen |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
20.12.2015:21:05:37 |
Seltsam. LastAccess ändert sich nicht. Ist aber wohl Default seit Win7SP1 durch ein Eintrag "NtfsDisableLastAccessUpdate" |
Datei mit "get-content" lesen |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
20.12.2015:21:05:37 |
Auch hier verändert sich nichts. |
Datei mit Notepad überschreiben (ohne vorher lesen) |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
20.12.2015:21:07:03 |
Das Überschreiben einer Datei ändert weder CreationTime noch LastAccessTime. Das kannte ich aber schon vorher. Siehe FileSystemTunnel |
Datei kopieren |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
20.12.2015:21:07:03 |
Die neue Datei hat zwar ein neues CreationTime und LastAccessTime aber der Werte von "LastWriteTime" wird von der Quelle übernommen. Das muss ich beachten. |
Attribute ändern |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
20.12.2015:21:07:03 |
Änderungen der Datei-Attribute (ReadOnly, Komprimiert, EFS) verändern nicht die Zeitstempel |
NTFS-Rechte anzeigen/ändern |
20.12.2015:20:59:01 |
20.12.2015:20:59:01 |
20.12.2015:21:07:03 |
Veränderungen an NTFS-Rechten verändern nicht die Zeitstempel. |
Die Testreihe zeigt, dass allein der Verlass auf Last AccessTime nicht ausreichend ist um z.B. frische Kopien korrekt zu behandeln. Das Skript muss auf jeden Fall auch das "CreationTime" und LastWriteTime mit einbeziehen. Beide Daten müssen "alt genug" sein, um die Datei nicht zu früh zu sperren.
- FileSystemTunnel
- File Times
https://msdn.microsoft.com/de-de/library/windows/desktop/ms724290(v=vs.85).aspx - NtfsDisableLastAccessUpdate
https://technet.microsoft.com/en-us/library/cc959914.aspx - Disable Last Access Time Stamps
(Standard 7 SP1)
https://msdn.microsoft.com/en-us/library/ff794679(v=winembedded.60).aspx