Kurztest: GRAU Filelock bringt Volumes die WORM-Fähigkeit

Für eine gesetzes- und vorschriftenkonforme, revisionssichere Archivierung gibt es eine große Herausforderung: Die einmal geschriebenen Informationen müssen gegen eine spätere Modifizierung – oder gar „kreative“ Überarbeitung“ – zu 100 Prozent geschützt sein. Zudem sind Aufbewahrungsvorschriften einzuhalten. Was früher den eher teuren „Write Once, Read Many“-Systemen (WORM) vorbehalten war, das lässt sich von Administratoren mit der GRAU Filelock-Software auf NTFS-Datenträgern erzielen. Dabei wird auch das nachträgliche Archivieren von bestehenden Dateisystemen unterstützt. Zudem ist die Software nach  GDPdU/GoBs zertifiziert.

Rechtliche Vorgaben bestimmen bei verschiedensten Dokumentenarten, dass einmal gemachte Angaben nicht mehr geändert werden dürfen und zudem sind verschieden lange Aufbewahrungsfristen für relevante Informationen einzuhalten. Für diese Art von Daten eignen sich WORM-Systeme (Write Once Read Many), die eine Unveränderbarkeit von einmal geschriebenen Informationen garantieren: revisionssicheren Dokumente.

Im Windows-Umfeld – genauer auf der Basis des Dateisystems NTFS – gibt es mit der GRAU Filelock-Software eine günstige Option, um einzelnen Volumes mit einer WORM-Charakteristik auszustatten und zudem gleich definierte „Retention Policies“ – also Richtlinien für die nötige Aufbewahrungszeit – zum Einsatz zu bringen. Dabei können beliebige Applikationen über das CIFS (Common Internet File System) oder über FTP die Daten in die durch Filelock geschützten Volumes mit dem darin angelegten Dateisystem schreiben. Doch nachdem diese Informationen geschrieben und „geschützt“ (eigentlich eher abgeschlossen) sind, kann die Applikation keine Änderung mehr an den Inhalten ausführen.

Wahl bei der Schutzart

Dieser Schutzmechanismus von Filelock setzt entweder auf Verzeichnisebene an – dann sind alle darunter liegenden Informationen entsprechend geschützt. Die andere Option ist der Schutz auf Dateiebene – sprich es lassen sich einzelne Dateien gegen Änderungen schützen. Für die Applikation bleibt das aber transparent: Es sind vom Programmierer der Anwendung keine eigenen APIs zu berücksichtigen – die entsprechenden Vorkehrungen werden über das NTFS abgewickelt.

Mit den zu Filelock gehörenden Schutzrichtlinien lässt sich dann garantieren, dass Dateien nicht mehr geändert, umbenannt, verschoben oder überschrieben werden können. Damit bleiben die Daten so wie sie sind – für eine vorzugebende Zeit (sie kann auch als „unendlich“ – infinite – angegeben werden). Zudem schützt Filelock die Dateien auch im Bereich der Metadaten: Die Attribute der Dateien lassen sich danach auch nicht mehr modifizieren.
Wird für Dateien eine Aufbewahrungsfrist angegeben (nicht „unendlich“), dann kann sie der Administrator danach zwar löschen, doch ein modifizieren der Inhalte auf eine andere Art ist nach wie vor nicht möglich. Damit entspricht der Filelock-.Ansatz den einschlägigen Bestimmungen, die der Gesetzgeber fordert.

Aufgrund dieser Eigenschaften lässt sich mit geringem Aufwand eine Archivierung erzielen, die den Überwachungsvorschriften entspricht und die zudem die bestehende Server- und Speicherinfrastruktur (mit 32- oder 64-Bit-Architektur; allerdings darf kein Truecrypt installiert sein) nützen kann. Dabei lassen sich auch bestehende Dateisystem in ein WORM-Dateisystem überführen. Die WORM-Dateisysteme beziehen sich allerdings immer auf ein ganzes Volume – und das muss bestimmte Voraussetzungen erfüllen.

Nur für NTFS-Volumes

Unterstützt werden nur NTFS-Dateisysteme, die als primäre Partitionen einer Basisdisk (mit MBR – Master Boot Record – und GPT – GUID Partition Table) vorliegen. Der Einsatz mit einer dynamischen Festplatte ist zwar machbar, doch dann fällt der Modus „Enhanced Security Module“ (ESM) weg. Will man diesen Modus verwenden, ist auch nur eine primäre Partition pro Basisdisk erlaubt. Für die kommende Version (das ist Filelock Release 2.2.4)verspricht der Hersteller, dass ESM auch auf Disks mit mehreren Partitionen aktiviert wreden kann. Doch ansonsten unterstützt Filelock lokale Festplatten – entfernbare Laufwerke und „Removable Media“ werden nicht unterstützt.

Beim ESM handelt es sich um eine spezielle Schutzart. Wird dieser Modus auf ein Volume angewendet, kann das Betriebssystem dieses Volume zwar nach wie vor verwalten. Vor allem lässt sich ein derartig geschütztes Volume dann auch von einem Festplattenlaufwerk zu einem anderen verschieben – oder man kann es auch auf einen anderen Computer mounten (selbst wenn dort keine Filelock-Software installiert ist).

Mit ESM wird aber das Volume noch zusätzlich verschlüsselt. Damit ist danach kein Inhalt des ursprünglichen Volumes sichtbar, wenn Filelock nicht installiert ist. Dafür bekommt man in diesem Fall ein kleines FAT-basiertes Volume angezeigt, das sozusagen nur einen Warnhinweis enthält. Wirft der Administrator Filelock wieder vom System herunter (das kann er über die Systemsteuerung und den Punkt Software deinstallieren), dann hat er keinen Zugriff mehr auf die für den WORM-Zugriff vorgesehenen Dateien.

Installation von Filelock

Um für den Test der Filelock-Software (als Testversion erreichte uns die Version 2.2.3) genügend Volumes zu haben, wurde in einem bestehenden Arbeitsplatzrechner (i5-basierter Arbeitsplatzrechner mit Windows 7, 64 Bit, SSD-Laufwerk und eine SATA-Festplatte mit 1 TByte) eine weitere SATA-Festplatte installiert (mit 1 TByte, darin wurden zwei Partitionen angelegt).

Die Installation wird ohne Probleme mit Hilfe eines Installations-Assistenten erledigt. Am Ende des Installationsvorgangs wurde allerdings der ESM-Modus nicht aktiviert – denn dann wäre auch eine Verschlüsselung der Inhalte auf dem WORM-Volume gegeben. Diese Aktion würde einen Neustart nach der Installation mit sich bringen.

Die Konfiguration der WORM-Volumes

Nachdem Filelock installiert ist, kann der Administrator ein passendes NTFS-Volume zu einem WORM-Volume konvertieren. Dazu muss er lediglich im Windows Explorer auf die Eigenschaften des Volumes gehen und dort zum neu hinzugekommenen Reiter Filelock. Hier ist dann die WORM-Fähigkeit zu aktivieren (Enable WORM Mode) und dann eventuelle die besonders sichere Version (den ESM) anzugeben.  Als weitere Option kann der Administrator noch die Art der Policy-Ebene einstellen: Entweder auf Root-Ebene des Volumes oder aber auf der ersten Ebene der Verzeichnisstruktur (1st directory-level).

Danach fragt ein Dialog noch ab, ob diese Konvertierung stattfinden soll (dazu muss der Systembetreuer noch das Wort WORM für das Volume eintippen) und dann wird das komplette Volume als WORM geführt – und diese Aktion lässt sich nicht mehr rückgängig machen. Bei ESM wird dann auch der Inhalt verschlüsselt – das kann je nach Umfang der dort liegenden Daten eine Weile dauern. Als nächste Aufgabe muss man dann noch die Papierkorb-Funktionalität auf dem neu erzeugten WORM-Volume ausschalten.

Danach ist das Volume an sich vorbereitet, doch dann gilt es noch, die zugehörigen Policies zu definieren. Dazu ist über den Windows Explorer wieder zum gewünschten Verzeichnis auf dem WORM-Volume zu gehen und dann über die Eigenschaften und dem Reiter Filelock die Policy für diesen Ordner anzugeben.

Bei der „Directory Level Retention Policy“ muss der Systembetreuer eine Zeitspanne für die Aufbewahrungsdauer angeben (in Tagen oder auch unbegrenzt mit der Checkbox infinite). Das gilt dann für alle Dateien unterhalb des angegebenen Verzeichnisses. Mit dem Wert für das Autocommit Delay wird eine Zeitspanne vorgegeben, nach der die eigentliche WORM-Aktion auf das Objekt ausgeführt wird – standardmäßig sind dort 5 Sekunden eingetragen. Wer diese Art der Policy-Vergabe wählt, der muss wenig Aufwand betreiben, weil die an der „obersten Stelle“ gemachten Einstellungen sich nach unten im Verzeichnisbaum vererben.

Mehr Aufwand aber auch eine feingliedrigere Einstellung bietet dagegen die Variante „Single File Retention Policy (Snaplock Interface)". Hier lassen sich die Parameter (Minimum Retention, Default Retention Maximum Retention und Autocommit Delay) vorgeben. Zudem bietet diese Art der Policy auch eine Kompatibilität zu Applikationen, die das Snaplock-Interface verwenden und die Daten auf ein teures System wie einen Netapp-Filer (oder ähnliche) weg schreiben.

Replikation und Backup

Bei Filelock gibt es die Möglichkeit, identische Replikate eines WORM-Volumes anzulegen. Dabei können die Ziel-WORM-Volumes auf demselben Server liegen oder auch auf einem Standby-Server. Über die WORM zu WORM Replikation lassen sich hochausfallsichere Konfigurationen aufbauen. Mit der Sicherung von WORM-Volumes gibt es eine weitere Absicherung gegen Ausfälle. Dazu muss der Administrator aber von betreffenden WORM-Volume ein „Full Image Backup“ anlegen – sprich das Volume komplett duplizieren. Nur so ist sichergestellt, dass die Daten genau so wiederhergestellt werden können, wie sie zum Zeitpunkt der Sicherung vorlagen.

Benutzerkonten und Berechtigungen

Die Aktionen auf den WORM-Volumes dürfen nur von einem lokalen Administrator und von Domänenadmins ausgeführt werden. Beim Standard-Domänenadmin-Konto sind dann auch noch die Richtlinien (bei der Benutzerkontenkontrolle) anzupassen (Deaktivieren der Richtlinien „Admin Approval Mode for the Built-In Administrator Account“ und „Run all administrators in Admin Approval Mode“).

Generell empfiehlt es sich in einer Domäne, mit speziellen Sicherheitsgruppen zu arbeiten und dann einzelne Benutzerkonten zu Mitgliedern in diesen Gruppen zu machen. Damit kann man die feste Zuordnung der erlaubten Aktionen bei Filelock mit einzelnen Konten so konfigurieren, dass auch dann mit den WORM-Volumes gearbeitet werden kann, selbst wenn das Benutzerkonto gelöscht wurde – etwa weil eine Administrator aus dem Unternehmen ausgeschieden ist.

Rainer Huttenloher

Kontakt:
Weitere Infos auf der Website von Graudata.

Eine Testversion der Software (zeitlimitiert aber ansonsten voll funktional) lässt sich von der Website zu Filelock herunterladen.