Nicht alles, was in den Amtszimmern im Hinblick auf IT-Themen besprochen und beschlossen wird, lässt sich in der Praxis wie gewünscht sinnvoll umsetzen. Die meisten Administratoren wissen davon ein Liedchen zu singen: Ein gutes Beispiel für "theoretisch gut, praktisch schwierig umzusetzen" stellen die Anforderungen an Unternehmen im Hinblick auf das dauerhafte, unveränderliche Speichern von Daten dar. Das trifft Firmen an verschiedenen Stellen: So sind Daten wirksam gegen Cyberattacken und Industriespionage ebenso zu schützen wie Belege in der Buchhaltung, für die digital wie analog eine Aufbewahrungsfrist von zehn Jahren gilt.

Mit dem bloßen Speichern der Daten ist es dabei oft nicht getan, denn der Gesetzgeber schreibt beispielsweise für Belege vor, dass diese im Nachhinein nicht mehr verändert werden dürfen und dass genau das in irgendeiner Form technisch sichergestellt ist. Schnell hat sich hierfür die Abkürzung WORM etabliert: "Write Once, Read Many" sorgt dafür, dass ein einmal geschriebener Datensatz unveränderlich ist und bloß noch in genau der Form lesbar ist, in der er einst seinen Weg auf einen Datenträger fand. Das technisch umzusetzen ist aber alles andere als trivial.

Die meisten Admins beschäftigen sich nur deshalb mit WORM-Speicher, weil der Gesetzgeber sie dazu zwingt. Da stellt sich freilich die Frage, welche Anforderungen WORM notwendig machen und wie genau die rechtlichen Formulierungen dazu lauten. Intuitiv würde der IT-Verantwortliche wahrscheinlich annehmen, dass beispielsweise das Bundesfinanzministerium (BMF) sehr konkrete Vorgaben hinsichtlich der Speicherung von Daten macht – schon um die Unternehmen nicht dem Gutdünken der Steuerbehörden vor Ort auszusetzen.

Das Gegenteil ist aber der Fall. Mit dem Schreiben vom 28. November 2019 erfolgte durch das BMF die letzte Anpassung der "Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff" (GoBD) [1], in denen unter Punkt 3.2.5 ("Unveränderbarkeit") die grundsätzlichen Anforderungen definiert sind. Hier erfolgt auch der Rückgriff auf spezifische Gesetze, etwa die Abgabenordnung oder das Handelsgesetzbuch. Konkrete Vorgaben aber fehlen – lediglich muss der ausführende Betrieb sicherstellen, dass einmal in der Belegführung hinterlegte Daten weitgehend unverändert bleiben und jedenfalls keine Änderungen stattfinden, die den ursprünglichen Inhalt der Buchung nicht mehr nachvollziehbar machen.

Groteskerweise gilt die GoBD, die erstmals Ende 2014 in Kraft trat, in dieser Hinsicht bereits als Meilenstein. Denn vorher waren die einzigen üblicherweise von den Behörden akzeptierten Speichermedien für digitale Belege echte Read-Only-Medien, also gebrannte CDs oder DVDs. Was nicht zuletzt daran lag, dass die GDPdU, der Vorgänger der GoBD, beinahe steinzeitliche Vorschriften zum Thema enthielt. Wer sich mit dem Thema seinerzeit ausführlich befasst hat, weiß aber, dass sich auch mit CDs oder DVDs aus Sicht eines Unternehmens die rechtssichere Aufbewahrung kaum garantieren ließ. Denn dass sich eine vor zehn Jahren selbst gebrannte CD oder DVD in einem zeitgenössischen Laufwerk noch problemlos lesen lässt, ist schließlich keineswegs sicher. Auch deshalb liefen in Unternehmen und Buchhaltungskanzleien zumindest bis 2014 die Drucker heiß, um auf Nummer sicher zu gehen und stets auch Papierbelege zu haben.

Andere Gesetzestexte bieten kaum mehr Erleuchtung. Die DSGVO etwa schreibt eine Sicherung der Daten nach den technischen Standards der Gegenwart zwar vor, bleibt dabei aber ausgesprochen vage. Dasselbe gilt für die NIS2-Verordnung, die auch nur die Aufforderung zum sicheren, irreversiblen Speichern von Daten enthält, vor allem zum Schutz vor korrumpierenden Zugriff durch Angreifer, konkrete technische Details aber schuldig bleibt. Eine konkrete Liste vorgefertigter Ansätze zum dauerhaften, irreversiblen Speichern von Daten gibt es weder seitens der Bundesbehörden noch ihrer untergeordneten Stellen für irgendeines der Themengebiete – also weder für das Sichern von Daten gegen Angriffe noch für die Speicherung von Belegen in der Buchhaltung.

Lediglich das Institut der Wirtschaftsprüfer hat mit seinem Prüfungsstandard 860 (IDW PS 860) eine Vorgabe geschaffen, mit der Unternehmen ihre Prozesse auch außerhalb einer konkreten Steuer- oder Wirtschaftsprüfung im Hinblick auf ihre Kompatibilität mit der GoBD abklopfen können. Statt selbst feste Vorgaben zu machen, ließ das Bundesfinanzministerium seinerzeit verlauten, es setze auf die "Anbieter am Markt", um gesetzeskonforme Lösungen anzubieten.

Administratoren, die die Schaffung eines rechtskonformen Speichers als Aufgabe vor der Brust haben, bleibt damit nur sorgfältige Recherche und ein möglichst enges Entlanghangeln an den spärlichen Vorschriften, die etwa die GoBD macht. Die GoBD gibt zwar keine konkrete Technik vor, beschreibt aber immerhin, dass Unternehmen neben dem Betrieb der Technik auch die Pflege einer umfassenden Betriebs- und Zugriffsdokumentation trifft. Dazu gehört beispielsweise ein Verfahrensverzeichnis, das festlegt, wer auf Daten wie zugreifen kann oder darf und das turnusgemäß auch tut. Das Problem des irreversiblen Speicherns von Daten löst das aber nicht. Auch in einem Verfahrensverzeichnis samt Zugriffsdokumentation wäre es schließlich ein Leichtes, Einträge zu fälschen und die Daten im Hintergrund doch zu verändern. Ohne einen technischen Baustein ist WORM-Speicher nicht sinnvoll zu realisieren.

Um Verwirrung rund um den Begriff des WORM-Speichers zu vermeiden, steht zunächst dessen genaue Definition auf dem Plan. Denn zwar bedeutet WORM immer dasselbe, doch haben sich am Markt verschiedene Ansätze etabliert, die zum selben Ziel führen und aus heutiger Sicht den Anforderungen etwa der GoBD durchaus standhalten.

So lassen sich die WORM-Ansätze der Gegenwart in drei Kategorien unterteilen: Als Erstes zu nennen sind als Hardware-WORM bezeichnete Medien, die bauartbedingt nur einen einzelnen Schreibzugriff zulassen. Das sind etwa Rohlinge für CDs oder DVDs oder Bänder für Bandlaufwerke, die nur einmal beschreibbar sind. Ansätze wie diese bilden aus Sicht des Administrators die sicherste technische Basis für WORM-Speicher, wenn gewährleistet werden kann, dass der Zugriff in zehn Jahren ab dem Zeitpunkt des Schreibens möglich ist. Auch hier sind Zugriffs- und Verfahrensprotokolle notwendig, um auszuschließen, dass bestehende Datenträger durch veränderte ausgetauscht werden. Wer WORM-Laufwerke mit den Daten aus seiner Buchhaltung etwa im Schließfach bei der Bank lagert, wird dem Finanzamt auf Anfrage belegen müssen, wer zu welchem Zeitpunkt auf das Schließfach zugegriffen hat und was sich dabei am Inhalt verändert hat.

Die zweite Kategorie bildet Software-WORM, das auf Hardware von der Stange setzt und WORM als Anwendung integriert. Beispielhaft wäre die WriteOnce-Funktionalität von Synology (Bild 1) oder vergleichbare Features in NAS-Geräten aller etablierten Hersteller. Derartige Anwendungen gestatten also einmal den schreibenden Zugriff, erlauben danach aber nur noch Lesezugriff, selbst für den Administrator des jeweiligen Geräts.

Diese Ansätze galten eine Weile als die weichsten, doch bei entsprechender Dokumentation per Zugriffs- und Verfahrensverzeichnis sehen die meisten Experten Software-WORM heute auf einer Ebene mit Hardware-WORM. Es entsteht hier allerdings die Herausforderung, dass es für Software-WORM zumindest hierzulande kaum technische Vorgaben oder gar Standards gibt, an die Anbieter sich halten könnten. Obendrein gibt das Finanzamt insbesondere für Software-WORM vor, dass ihm auf Anfrage Zugriff zu den betroffenen Systemen zu gewähren ist – eine Neuerung im Rahmen der GoBD.

Schließlich implementiert die dritte Kategorie "Systemisches WORM" die WORM-Funktionalität über bestimmte Controller für den Speicherzugriff oder über deren Firmware. Das bringt gegenüber Hardware-WORM den Vorteil mit sich, dass die Speicherhardware selbst – etwa die Flash-Chips bei Flash-Laufwerken – die gleichen wie bei entsprechenden Laufwerken ohne WORM-Funktionalität sein können. Das erlaubt viel höhere Laufwerksgrößen als etwa bei CDs oder DVDs, ohne dass die Kosten für entsprechende Hardware vollständig aus dem Ruder laufen. Typische Beispiele für Geräte mit systemischem WORM ist Content-Addressed Storage (CAS), wie er etwa bei EMCs früherer Produktreihe Centera zum Einsatz kam.

Schauen wir uns den aktuellen WORM-Markt an, zeigt sich schnell, dass vor allem Software-WORM mittlerweile den Ton angibt und beispielsweise der Verkauf spezieller WORM-Appliances weitgehend zum Erliegen gekommen ist. Auch wenn NAS-Systeme WORM-Features bieten, sind diese stets ausschließlich in der Software implementiert. Und natürlich hat das vor allem der Markt geregelt: Hardware-WORM ist unhandlich und üblicherweise stark beschränkt im Hinblick auf die Datenkapazität. Systemische WORM-Laufwerke waren ebenfalls stets deutlich teurer als schnöde Festplatten oder Flash-Laufwerke von der Stange. Praktisch alle relevanten WORM-Ansätze der Gegenwart verkaufen insofern Software, die auf Standardhardware zugreift und die WORM-Funktionalität intern erzwingt.

Nun, da die rechtlichen und theoretischen Grundlagen klar sind, lassen sich die am Markt verfügbaren Produkte sinnvoll in bestimmte Einsatzszenarien einsortieren. Eine zentrale Frage dabei ist stets jene nach der Menge der Daten, die im WORM-Speicher landen sollen. Im einfachsten Fall benötigen Unternehmen WORM-Speicher vor allem für die Aufbewahrung von Belegen aus der Buchhaltung. Selbst wenn diese viele große Scans enthalten, sind Datenmengen im TByte-Bereich hier sehr selten. Der aktuell einfachste Ansatz für diese Use Cases ist die Verwendung eines handelsüblichen NAS-Speichers.

Synology, QNAP und auch andere Anbieter wissen, dass auch in kleinere Unternehmen mittlerweile Bedarf an WORM-Funktionalität besteht und haben entsprechende Features in die Firmware ihrer Geräte integriert. Dabei handelt es sich samt und sonders um Software-WORM, doch das Prinzip funktioniert zuverlässig. Markiert der Administrator ein Laufwerk als WORM-Speicher, schützt die Firmware der Geräte das betroffene Laufwerk nach dem ersten Schreiben von Daten zuverlässig und lässt keine Veränderung mehr zu. Ergänzt um Compliance-Dokumente wie das beschriebene Verfahrensverzeichnis und eine Zugriffsdokumentation erfüllt der Ansatz nach gängiger Auslegung die Anforderungen der GobD.

Synology macht vor, wie es gehen kann. Die Voraussetzung ist ein Gerät des Herstellers, das die Funktion "Immutable Snapshots" beherrscht. Denn diese stellt über Btrfs-Immutable-Snapshots als WORM-Funktionalität ("WriteOnce" in der Synology-Terminologie) bereit. Eine Liste aller Modelle, die das Feature unterstützen, liefert [2]. In der Praxis müssen Sie darauf achten, dass Sie beim Anlegen eines Volumes im DiskStation Manager als Dateisystem "Btrfs" auswählen, weil eben nur dann die benötigte Funktionalität zur Verfügung steht.

Sind die Voreinstellungen korrekt, zeigt der DiskStation Manager die Option für WriteOnce von alleine an. Hier haben Sie dann noch die Wahl zwischen dem Compliance-Modus und dem Enterprise-Modus. Letzterer ermöglicht es Administratoren zusätzlich, die Daten zu löschen, Ersterer weist jeden schreibenden Zugriffsversuch auf die Daten des Volumes strikt zurück. Die Dauer, bis die Sperre greift sowie ihre Länge legen Sie dann noch über separate Optionen fest (Bild 2). Es ist dabei sinnvoll, die hinterlegten Daten nicht bereits unmittelbar nach dem Schreiben zu schützen, ansonsten müssten Sie fälschlich hinterlegte Daten zehn Jahre lang mitschleifen, was zumindest unnötig Speicherplatz verbraucht. Hier lässt Synology Ihnen aber per komfortablem GUI viel Spielraum für eigene Präferenzen.

Ganz ähnlich liegen die Dinge bei Geräten von Qnap, sofern Sie das Qnap-Betriebssystem QuTS Hero einsetzen und so in den Genuss einer eingebauten WORM-Funktion kommen (Bild 3). Deren Einrichtung unterscheidet sich zwar von der bei Synology, im Prinzip tun beide Features aber dasselbe. Auch bei Qnap sind im Anschluss die Daten dauerhaft vor Zugriff geschützt. Quasi als Dritter im Bunde der verbreiteten SAN-Hersteller bietet Asustor ebenfalls ein WORM-Feature, wenn auch nur für die höherpreisigen Geräte. Wer ein NAS anschaffen möchte und dabei die Nutzung von WORM in Betracht zieht, informiert sich im Idealfall vorher, ob das ins Auge gefasste Gerät WORM bietet. Grundsätzlich sind NAS-Appliances aber ein sinnvoller Weg, um WORM im kleineren Maßstab umzusetzen. Denn je nach benötigter Speichergröße kommen Sie für deutlich unter 1000 Euro an eine rechtskonforme Speicherumgebung.

Vorsicht ist hingegen bei manchen Open-Source-NAS-Implementierungen geboten. Zwar wäre es etwa auch bei TrueNAS problemlos möglich, echte WORM-Funktionalität zu implementieren. Ausnahmsweise patzt TrueNAS als Vertreter der Open-Source-Kategorie hier aber im Vergleich mit der proprietären Konkurrenz.

Denn auch TrueNAS bietet zwar ein WORM-Feature für geteilte SMB-Laufwerke. Hier bezieht sich der Schreibschutz aber vor allem auf den Zugriff per Netz. Das primäre Ziel besteht also darin zu verhindern, dass beispielsweise ein mit Viren befallener Windows-Rechner ein geteiltes Netzlaufwerk infiziert und sich so beliebig im Netz verbreitet. Der Administrator der TrueNAS-Instanz hat hingegen vollen lesenden und schreibenden Zugriff auf den Share, auch im Nachhinein. Mit echtem WORM-Speicher hat dieser Ansatz also nichts zu tun.

Noch eine Warnung ist an dieser Stelle fällig: Zwar dienen NAS-Laufwerke üblicherweise als Backupziel. Wenn das Device wie in diesem Fall aber selbst Nutzdaten enthält, ist eine zusätzliche Backup- strategie für das NAS selbst notwendig. Denkbar wäre etwa, die Daten des NAS mittels entsprechender Software verschlüsselt in die Cloud zu spiegeln oder zusätzlich zum NAS ein weiteres NAS anzuschaffen, das dann klassisch das Sicherungsziel darstellt.

Wer nicht nur Belegdaten oder kleinere Datenmengen im WORM-Speicher unterbringen muss, stößt mit einem klassischen NAS bald an Kapazitätsgrenzen. Hier empfiehlt es sich, den eigentlichen Speicher und die WORM-Funktionalität voneinander zu trennen und die letztere durch eine separate Software bereitzustellen, die prinzipiell jeden Speicher als Ziel verwenden kann. Eine einheitliche, in der Branche allgemein anerkannte Anwendung gibt es dabei allerdings nicht und obendrein ist der Markt sehr unübersichtlich. Viele gängige Backupprodukte wie Veeam bringen WORM-Support mit und auch Open-Source-Applikationen wie Bareos sind hier relevant. So kommt in der gerade erst angekündigten Bareos-Version 24 ein neuer Zugriffsmechanismus für Tapes zum Einsatz, der es ermöglicht, diese als WORM-Speicher zu verwenden. Überhaupt werden Admins, die WORM-Speicher recherchieren, sich früher oder später mit Bandlaufwerken befassen wollen. Denn diese kommen vielen zwar vor wie Relikte aus grauer Vorzeit, de facto hat aber auch die Entwicklung dieser Technologie in den vergangenen Jahren erhebliche Fortschritte gemacht. So bieten Tapes gerade für WORM-Backups heute oft das mit Abstand beste Preis-Leistungs-Verhältnis.

Darüber hinaus finden sich diverse Hardware-Appliances und Anwendungen, die WORM-Kompatibilität etwa durch die Einbindung in ECM- oder Dokumentenmanagement-Systeme versprechen. Hier müssen Administratoren besonders gut hinsehen, was sie bekommen: Manche Anbieter etwa versehen ihre Produkte frech mit offenkundig in Photoshop selbst gebastelten Zertifizierungsstempeln, die "revisionssicher nach GoBD" versprechen und darauf hinweisen, das jeweilige Gerät erfülle "alle rechtlichen Anforderungen". Gar von "zertifizierten Lösungen" ist im Text dann die Rede; schaut der IT-Verantwortliche jedoch genauer hin, entpuppt sich die "Zertifizierung" ebenfalls als Marketinggag. Zertifiziert sind solche Systeme dann nämlich nicht nach GoBD, für die es, wie erwähnt, gar kein amtliches Prüfverfahren gibt, sondern für die Verwendung mit bestimmten Anwendungen wie ECM oder DMS.

Es soll an dieser Stelle keinesfalls der Eindruck entstehen, sämtliche Angebote für WORM seien ein Fall für "Nepper, Schlepper, Bauernfänger". Dass sich in der Branche diverse Glücksritter tummeln, die auf den schnellen Euro mit wuchtigem Marketing aus sind, ist aber leider eine Tatsache. Im Zweifelsfall tun Unternehmen gut daran, sich für größere WORM-Speicher die Konzepte mehrerer Anbieter vorstellen zu lassen und eine Abwägung zu treffen.

Wer einen nahtlos skalierbaren Speicher mit WORM-Funktionalität braucht, wird zudem möglicherweise beim Objektspeicher Ceph auf Open-Source-Basis fündig. Teil von Ceph ist das RADOS Object Gateway, das den Zugriff auf den Objektspeicher mittels Amazons S3-Protokoll ermöglicht (Bild 4). Das sieht seit langer Zeit eine "Object Lock"-Funktion vor, die nach dem Schreiben eines Objekts den weiteren schreibenden Zugriff darauf unterbindet – sogar für einen Administrator der Umgebung.

Intern sichert es die Integrität der Daten zudem über Prüfsummen ab, sodass auch ein Verändern der Objekte direkt im Speicher (statt durch S3 hindurch) nicht zum gewünschten Ergebnis führt, sondern höchstens zu unbrauchbarem Datensalat. Weil dieser dem Steuerpflichtigen oder dem Unternehmen, das seine Daten gegen Angriffe schützen will, nichts nutzt, besteht a priori kein Anreiz für Manipulationsversuche. Hersteller IBM weist explizit darauf hin, dass ein "richtig konfiguriertes Ceph mit S3" sogar den Anforderungen der amerikanischen SEC und FINRA genügt und obendrein konform mit der Regelung 1.31(c)-(d) der "Commodity Futures Trading Commission" (CFTC) ist, also einer Behörde der US-amerikanischen Börsenaufsicht.

Entsprechend hat ein deutsches Finanzamt an dieser Stelle eher wenige Optionen, eine auf Ceph und dessen S3-Schnittstelle basierende Infrastruktur kategorisch abzulehnen. Allein holt Ceph die Kohlen dann aber nicht aus dem Feuer, denn zusätzlich ist ein Backup- oder ECM/DMS-Werkzeug erforderlich, das S3 als Backend-Speicher verwendet und die Lock-Tage entsprechend setzen kann. Hier ist im Zweifelsfall also einiges an Eigenleistung nötig. Im Gegenzug erhält der Admin einen auf offenen Standards basierenden Speicher, der nahezu beliebig in die Breite skaliert und mit einer Vielzahl von Anwendungen kompatibel ist. Denn praktisch jede gängige Software für Backups der Gegenwart hat S3-Unterstützung im Gepäck. Hingewiesen sei an dieser Stelle einmal mehr darauf, dass auch ein Konstrukt auf S3-Basis eine eigene Backupvorrichtung braucht.

WORM-Speicher ist gerade für kleinere Datenmengen im Betrieb über NAS-Appliances heute leicht und rechtssicher zu erreichen und das sogar für relativ wenig Geld. Wer größere Mengen an Daten rechtskonform speichern muss, greift wahlweise auf ein Gespann aus generischem Speicher und entsprechender Software zurück oder baut sich auf Open-Source-Basis eine nahtlos in die Breite skalierbare Umgebung. Wichtig ist bei allen Ansätzen, dass es mit der technischen Umsetzung allein nicht getan ist. Sowohl die GoBD als auch die DSGVO und NIS2 setzen zusätzlich Compliance in Form verschiedener Dokumente voraus, die zusammen mit der technischen Infrastruktur zu entwickeln und zu pflegen sind.