Archivierung und Journaling

Mail erfassen, bevor jemand sie anfassen kann

Exchange-Online-Journaling (der primäre Weg)

Eine Journal-Regel, im Exchange-Online-Admin-Center von der Administration des Kunden eingerichtet, weist Exchange an, eine Kopie passender Mail (einen Journal-Report) an eine von Restow kontrollierte Adresse zu senden, bevor das Postfach der Empfängerin oder des Empfängers gelesen, geändert oder daraus gelöscht werden kann. Die Regel lässt sich auf alle im Mandanten oder auf ausgewählte Empfänger oder Gruppen beschränken, genauso, wie Restows eigene Schutzregeln funktionieren.

Jeder Mandant hat eine eigene Journal-Adresse, journal+<token>@<Journal-Host>, mit einem zufälligen Token je Mandant, sodass ein Report nicht durch Erraten der Adresse im falschen Mandanten landen kann. Die Einrichtung steht unter Exchange-Journaling.
Exchange verlangt eine konfigurierte Adresse für unzustellbare Journal-Reports, bevor Journaling überhaupt funktioniert. Eine Administration wird das einmalig beim Aktivieren des Journalings einrichten.
Ein Journal-Report ist ein Umschlag um die ursprüngliche Nachricht: Restow soll den Umschlag parsen (Absender, Empfänger, Message-ID, einschließlich der BCC-Empfänger, die nur im Umschlag sichtbar sind, nie in der Nachricht selbst) und das Original byte-genau (message/rfc822) zusammen mit dem Umschlag als strukturierte Daten speichern.
Ein nicht parsbarer Report (fehlender Anhang, missgebildeter Umschlag) soll trotzdem archiviert und als unvollständig markiert werden. Restow ist darauf ausgelegt, nichts still zu verwerfen, was es nicht vollständig verstehen kann.

Graph-Sync (eine Ergänzung, kein Ersatz)

Journaling sieht Mail erst ab dem Moment, in dem die Regel aktiv ist. Ein Graph-basierter Sync ergänzt, was vorher schon im Postfach lag, sowie Kalender- und Kontakteinträge, die Journaling überhaupt nicht abdeckt. Auf diesem Weg Erfasstes wird als „nachträglich erfasst“ markiert: Der unten beschriebene Hash-Ketten-Schutz beginnt erst, sobald Restow das Element tatsächlich hat, sodass ein spät erfasstes Element nicht beanspruchen kann, im Moment seines Eintreffens erfasst worden zu sein.

IMAP-Archivierung: was sie erfassen soll und was sie nicht garantieren kann

Für Mail-Anbieter ohne Journaling-Äquivalent plant Restow einen fortlaufenden IMAP-Sync (IDLE, wo der Server es unterstützt, sonst Polling) als bestmögliche Näherung:

Was erfasst werden soll: Alles, was beim nächsten Sync noch im Postfach liegt.
Was nicht garantiert werden kann: Vollständigkeit. Eine Nachricht, die zwischen Eingang und dem nächsten Sync gelesen, verschoben oder von einer Mail-Regel gelöscht wird, wird nie gesehen, anders als beim Journaling, das erfasst, bevor irgendetwas davon möglich ist. Restow dokumentiert das ausdrücklich als Näherung, nie als gleichwertig zum Journaling.
Wo der Anbieter es unterstützt, empfiehlt Restow zusätzlich eine serverseitige Kopierregel (eine Sieve-Regel oder eine BCC-Regel an die Journal-Adresse), damit eine Kopie unabhängig vom Zustand des Postfachs im Archiv ankommt. Die Oberfläche soll je IMAP-Konto anzeigen, welcher Erfassungsweg tatsächlich aktiv ist.

Aus Dateien importierte Mail

Mail aus einem Altpostfach, das es nicht mehr gibt (EML, MSG, MBOX, ZIP oder ein MailStore-Export), lässt sich in Restow importieren und optional gleichzeitig archivieren, mit dem Erfassungsweg file_import (Mail-Dateien importieren und exportieren). Wie beim Graph-Sync wird sie nachträglich erfasst: Die Aufbewahrungsfrist beginnt mit dem Import, nicht mit dem Datum der Mail. Eine alte Mail, die heute importiert wird, ist also ab heute unveränderbar und wird ab heute gezählt. Das eigene Sendedatum der Mail bleibt erhalten und wird in Suche und Anzeige bevorzugt. Eine Nachricht, die für dasselbe Postfach bereits archiviert ist, wird nicht doppelt archiviert.

Unveränderbarkeit: Prüfkette und WORM

Jedes archivierte Element soll eine verkettete Prüfsumme erhalten: chain_hash = SHA-256(vorheriger_chain_hash || item_hash || received_at). Ein täglicher Anker hält Datum, aktuellen Kettenwert und Elementanzahl fest; der Anker soll dem Betreiber per E-Mail zugestellt und optional an einen externen RFC-3161-Zeitstempeldienst (zum Beispiel freetsa.org) gesendet werden, damit der Zeitstempel des Ankers selbst unabhängig überprüfbar ist. Wer Schreibzugriff auf die Datenbank hat, könnte die Kette selbst neu berechnen. Die Kette allein beweist also nichts. Ein archiviertes Element zu ändern oder zu löschen, soll erkennbar werden, sobald die Kette gegen die täglichen, außerhalb von Restow gehaltenen Anker (die E-Mail-Kopie oder der externe Zeitstempel) geprüft wird; erst dieser Abgleich mit den Ankern, nicht die Kette für sich genommen, macht eine Manipulation erkennbar.

Was das nicht nur erkennbar, sondern auf Speicherebene verhindert, ist die Objektsperre (WORM):

Das Standard-Speicherziel für das Archiv soll S3-kompatibler Objektspeicher mit Object Lock im COMPLIANCE-Modus sein: Jedes Archivobjekt wird mit einem Retain-until-Datum geschrieben, das dem Ende seiner Aufbewahrungsfrist entspricht, und Legal Hold soll zusätzlich zum eigenen Legal Hold von Restow die objektbezogene Sperre des Speichers nutzen.
Ein Dateisystem-Ziel (ein lokaler Pfad, eine NFS- oder SMB-Freigabe) hat keine Hardware-WORM. Ein solches für das Archiv zu nutzen, soll einen expliziten, auditierten Opt-out durch eine Provider-Administration erfordern („nur Unveränderbarkeit auf Anwendungsebene“), und sowohl die Oberfläche als auch jeder ab diesem Zeitpunkt erzeugte Nachweisbericht sollen das dann genau so benennen: „Speicherziel ohne Hardware-WORM“. Unveränderbarkeit auf Anwendungsebene bedeutet genau das: kein Code-Pfad, um ein archiviertes Element vor Fristablauf zu ändern oder zu löschen, plus die Prüfkette, um eine Manipulation zu erkennen, sollte jemand Restow ganz umgehen. Das ist ein echter Schutz, aber nicht dieselbe Garantie, die eine speicherseitig erzwungene Schreibsperre gibt.

Ob das Gesetz tatsächlich WORM im Speziellen verlangt oder auch andere Maßnahmen akzeptiert, steht unter Vorschriften.

Aufbewahrung und Legal Hold

Eine Aufbewahrungsrichtlinie je Mandant, mit einem vorgeschlagenen Standard von 10 Jahren und wählbar 6, 8, 10 Jahren oder unbegrenzt, passend zu den deutschen handels- und steuerrechtlichen Aufbewahrungsfristen (siehe Vorschriften), geplant optional auch als eigene Richtlinie je Postfach-Gruppe.
Die gesetzliche Berechnung nach § 147 Abs. 4 AO (und § 257 Abs. 5 HGB) beginnt die Aufbewahrungsfrist mit dem Ende des Kalenderjahres, in dem ein Beleg empfangen oder versendet wurde, nicht mit dem genauen Erfassungsdatum. Das gilt breit, für alles, was § 147 Abs. 1 AO erfasst, nicht nur für Buchungsbelege. Die Aufbewahrungsrichtlinie von Restow soll diesen Start zum Kalenderjahresende ebenso anbieten wie einen einfacheren Start zum Erfassungsdatum bei gleicher Jahreszahl; ein Start zum Erfassungsdatum beendet die Aufbewahrung früher als die gesetzliche Berechnung, um bis zu etwa ein Jahr. Die Option zum Kalenderjahresende ist diejenige, die der gesetzlichen Mindestfrist entspricht.
Legal Hold soll sich auf Ebene eines Mandanten, eines Postfachs oder eines gespeicherten Suchergebnisses anlegen lassen, mit erforderlicher Begründung, wer ihn angelegt hat und wann. Ein Hold soll die Löschung vollständig blockieren und selbst auditiert werden wie jede andere Aktion, die archivierte Daten berührt.
Ein täglicher Löschlauf soll nur Objekte entfernen, die sowohl abgelaufen als auch nicht gehalten sind, und das Gelöschte (Anzahl, betroffener Zeitraum und die Hashes der gelöschten Objekte) in dieselbe Prüfkette schreiben, die auch für die Integrität genutzt wird, sodass selbst rechtmäßige Löschung nach Fristablauf nachvollziehbar bleibt.
Die Aufbewahrung endet nicht zwangsläufig starr nach 6/8/10 Jahren: Nach § 147 Abs. 3 AO muss ein Beleg länger aufbewahrt werden, solange er für eine noch nicht bestandskräftige Steuerfestsetzung von Bedeutung ist. Ein Löschlauf, der immer nach der festen Frist löscht, ohne das zu prüfen, könnte zu früh löschen. Diese Prüfung vorzunehmen oder eine Richtlinie von Hand zu verlängern, ist die eigene Entscheidung Ihrer Organisation, nichts, was Restow automatisiert.

Wahl je Postfach: nur Backup, oder Backup und Archiv

Nicht jedes Postfach braucht dieselbe Behandlung. Ein geteiltes Postfach wie bestellung@ oder noreply@ mag es wert sein, gesichert zu werden (damit es sich erholen lässt, wenn etwas kaputtgeht), ohne dieselbe dauerhafte, unveränderbare Archivierung zu brauchen, die normale Mitarbeiterkorrespondenz aus Beweisgründen erhält. Restow soll es erlauben, je Postfach, über denselben Regelmechanismus, den der Backup-Umfang bereits nutzt (alle, eine Gruppe, eine Ausschlussliste, Einzelentscheidungen), zu wählen, ob ein Objekt nur gesichert oder gesichert und archiviert wird, dargestellt als getrennte Spalten Backup und Archiv nebeneinander unter Geschützte Objekte.

Sobald die Archivierung verfügbar ist, ist der geplante Standard, dass jedes Postfach archiviert wird; eines auszuschließen ist eine bewusste, ausdrückliche, auditierte Entscheidung, kein stiller Standard. Ein Journal-Report, der Empfänger außerhalb des Archiv-Umfangs nennt, soll für diese einfach nicht gespeichert werden, es sei denn, ein anderer Empfänger derselben Nachricht liegt im Umfang: Dann wird die Nachricht einmal archiviert, für die im Umfang liegenden Empfänger. Jede Änderung dessen, was im oder außerhalb des Umfangs liegt, soll auditiert werden und im Nachweisbericht erscheinen, und die Dokumentation soll erklären, wie sich die zugrunde liegende Exchange-Journal-Regel selbst eingrenzen lässt (nach Empfänger oder Gruppe). Ein Postfach mit tatsächlich geschäftsrelevanter Korrespondenz vom Archiv auszuschließen, bleibt die eigene Entscheidung Ihrer Organisation nach GoBD, nicht etwas, das Restow für Sie entscheidet.

Suche, Export und Nachweis

Volltextsuche (verfügbar in 0.1.0) über Betreff, Body und Anhangsinhalt (PDF, DOCX, XLSX, TXT), Absender, Empfänger, Datum, Postfach und Größe.
Rollen (in Entwicklung): Eine Mandanten-Administration soll mandantenweit suchen können (selbst auditiert); ein Endnutzer soll ausschließlich im eigenen Postfach suchen können; eine Provider-Administration soll eine explizite, vom Mandanten erteilte Vier-Augen-Freigabe brauchen, bevor sie überhaupt im Archiv eines Kunden suchen kann.
Export (teilweise verfügbar): Archivierte Mail lässt sich bereits als EML-Dateien in einer ZIP-Datei mit der ursprünglichen Ordnerstruktur, einer MANIFEST.csv und einer SHA256SUMS-Datei oder als MBOX exportieren; siehe Mail-Dateien importieren und exportieren. Der Export zur Weitergabe an eine Prüferin oder einen Prüfer, der zusätzlich eine CHAIN.txt der relevanten Kettenwerte enthält und mit jedem Mail-Programm ohne laufendes Restow lesbar ist, ist noch in Entwicklung.
Nachweisbericht (PDF, in Entwicklung): Mandant, abgedeckter Zeitraum, Elementanzahl, Speicherziel, dessen Objektsperren-Status, Ergebnis der Kettenprüfung, geltende Aufbewahrungsrichtlinie, Löschlauf-Protokolle und eine Signatur über den Bericht selbst.

Weiterlesen

Archivierung: die administrationsseitige Zusammenfassung und der aktuelle Stand.
Vorschriften: welche Anforderungen dieses Design adressiert, und ob WORM-Speicher tatsächlich erforderlich ist.
GoBD und Nachweise: die deutschrechtlichen Details hinter „unveränderbar“ und „zeitgerecht“.
Backup vs. Archiv: warum das überhaupt getrennte Systeme sind.