Unveränderbare Backups

Ransomware und ein gestohlenes Administratorkonto wollen dasselbe: auch die Sicherungen sollen weg sein. Seit 0.4.0 kann Restow die Backup-Daten eines Repositorys unveränderbar machen, sodass sie niemand, Restow eingeschlossen, vor ihrem Datum ändern oder löschen kann. Jedes Repository hat seine eigene Einstellung, und sie ist aus, bis eine Administration sie einschaltet. Beim Update wird nichts gesperrt.

Zwei Mechanismen

	S3 Object Lock	Löschverzögerung
Für	Ein S3-kompatibles Repository, dessen Bucket mit Object Lock angelegt wurde	Ein Verzeichnis-Repository: das Docker-Volume oder eine NFS-Freigabe
Wer das Löschen verweigert	Der Speicherdienst selbst	Restows eigener Code
Einstellung	Compliance-Modus oder Governance-Modus, 1 bis 3650 Tage	1 bis 3650 Tage
Unveränderbar	Ja. Compliance: Niemand kann die Sperre verkürzen oder aufheben, auch nicht der Inhaber des Buckets. Governance: Ein Konto mit `s3:BypassGovernanceRetention` kann sie aufheben	Nein. Wer Zugriff auf den Server oder die Freigabe hat, kann die Dateien trotzdem löschen, und die Oberfläche sagt das
Schützt vor	Einem Angreifer auf dem Restow-Server, jemandem mit dem Speicherschlüssel von Restow, einem gestohlenen Administratorkonto, einer verkürzten Aufbewahrungsrichtlinie	Missbrauch von Restow selbst: einem gestohlenen Administratorkonto, einer verkürzten Aufbewahrungsrichtlinie

Für echte Unveränderbarkeit im eigenen Haus nutzen Sie einen S3-Dienst mit Object Lock auf einem getrennten Rechner (Ceph RGW oder ein anderer S3-Server, der Object Lock umsetzt) als Repository oder als Kopie. Auch ein NAS, dessen Snapshots der Restow-Host nicht löschen kann, hilft; Restow kann das aber nicht prüfen und zeigt es nie als unveränderbar an.

S3 Object Lock einschalten

Legen Sie den Bucket mit Object Lock an. Object Lock braucht Versionierung und lässt sich nur beim Anlegen eines Buckets einschalten: Es lässt sich einem bestehenden Bucket nicht nachträglich hinzufügen. Fügen Sie den neuen Bucket als Repository hinzu, oder als Kopie neben Ihrem bisherigen primären Repository (siehe Backups und Zeitpläne).

Geben Sie dem Zugriffsschlüssel die richtigen Berechtigungen. Neben dem Lesen und Schreiben von Objekten braucht ein unveränderbares Repository am Bucket:

Der Schlüssel braucht	Wofür
`s3:GetBucketObjectLockConfiguration`	Object Lock erkennen, wenn Sie das Repository testen und die Einstellung einschalten
`s3:PutObjectRetention`, `s3:GetObjectRetention`	die Verlängerung, die Prüfung und die Markierung an Sicherungsständen
`s3:ListBucketVersions`, `s3:DeleteObjectVersion`	ein Objekt endgültig löschen, sobald seine Sperre abgelaufen ist

Der Schlüssel darf nicht s3:BypassGovernanceRetention, s3:PutBucketObjectLockConfiguration oder s3:PutBucketVersioning haben. Sonst kann, wer den Schlüssel hat, den Schutz schwächen.

Testen Sie das Repository. Ein erfolgreicher Test zeigt Object Lock aktiv (WORM). Ein Schlüssel, der die Object-Lock-Konfiguration des Buckets nicht lesen darf, zeigt „Object-Lock-Status unbekannt“.
Öffnen Sie unter Mandanten-Einstellungen → Repositories die Karte des Repositorys und wählen Sie im Teil Unveränderbare Backups Unveränderbarkeit ändern. Wählen Sie Object Lock, Compliance-Modus (empfohlen) oder Object Lock, Governance-Modus, geben Sie die Zahl der Tage ein (1 bis 3650) und speichern Sie.

Das Einschalten fragt den Bucket nach seiner Object-Lock-Konfiguration und lehnt einen Bucket ohne sie ab („Dieser Bucket erzwingt kein Object Lock, daher lassen sich seine Backups nicht unveränderbar machen“). Dasselbe passiert, wenn der Schlüssel die Konfiguration nicht lesen darf.

Geben Sie dem Schlüssel von Restow im Governance-Modus kein s3:BypassGovernanceRetention: Restow sendet den Governance-Umgehungs-Header nie, aber jedes Konto mit dieser Berechtigung kann die Sperre aufheben. Der Compliance-Modus hat keine solche Hintertür.

Den Zeitraum wählen

Ein Sicherungsstand bleibt mindestens so viele Tage gesperrt, wie Sie eingeben, gerechnet ab seiner Erstellung. Wählen Sie einen Zeitraum, der mindestens so lang ist, wie Sie brauchen, um einen Angriff zu bemerken und sich für eine Wiederherstellung davor zu entscheiden. Ein längerer Zeitraum hält Daten länger im Bucket, nachdem sie nicht mehr gebraucht werden, und diesen Speicher bezahlen Sie: siehe Löschen unter einer Sperre. Im Compliance-Modus kann niemand vor dem Datum löschen, Sie eingeschlossen. Beginnen Sie deshalb mit einem kurzen Zeitraum an einem Test-Repository.

Die Einstellung gilt für das, was ab jetzt geschrieben wird. Bereits gespeicherte Daten behalten ihre Sperre oder bleiben ungesperrt. Die tägliche Verlängerung (unten) sperrt auch ältere Daten, die neue Sicherungsstände noch verwenden. Eine geänderte Einstellung erreicht die api sofort und einen Worker innerhalb seiner Speicher-Cache-Zeit (einige Minuten); in der Zwischenzeit geschriebene Objekte tragen die alte Einstellung, und die Prüfung findet sie.

Wie die Sperre gesetzt wird

Jedes gesperrte Objekt wird mit einem Sperrdatum von Zeitraum plus 7 Tagen geschrieben.
Der tägliche Aufbewahrungslauf verlängert die Sperren der Objekte, die noch verwendet werden. Durch Deduplizierung kann ein Backup von heute auf einem Pack ruhen, das vor Monaten geschrieben wurde und dessen eigene Sperre längst abgelaufen ist. Sobald die letzte vollständige Verlängerung 6 Tage alt ist, setzt der tägliche Aufbewahrungslauf die Sperre jedes Packs, jedes umhüllten Schlüssels und jedes gesperrten restic-Objekts, das noch verwendet wird, auf Zeitraum plus 7 Tage ab jetzt. Zwischen zwei Verlängerungen ist jedes verwendete Objekt daher mindestens für den Zeitraum ab jetzt gesperrt, sodass ein Sicherungsstand, der jetzt entsteht, für seinen ganzen Zeitraum gedeckt ist, samt allem, was er wiederverwendet.
Eine Verlängerung kostet eine PutObjectRetention-Anfrage je Objekt alle 6 Tage. Sie läuft mit 32 Anfragen gleichzeitig (IMMUTABILITY_RENEWAL_CONCURRENCY, höchstens 256). Eine Verlängerung, die unterbrochen wurde oder bei der einzelne Objekte scheiterten, setzt dort fort, wo sie stehen blieb, und gilt ab ihrem ursprünglichen Beginn als vollständig.
Objekte, deren Löschung der Speicher schon abgelehnt hat, bleiben von der Verlängerung ausgenommen, damit sie ablaufen können.
Fällt die Verlängerung um mehr als die 7 Tage Puffer zurück, warnt die Karte des Repositorys: Daten, die neue Sicherungsstände wiederverwenden, sind dann möglicherweise kürzer als der Zeitraum gesperrt.
Die Verlängerung läuft im Aufbewahrungslauf des Mandanten. Ein Mandant, dessen Aufbewahrungszeitplan gelöscht wurde, wird nicht verlängert, und sein Repository sagt das.

Verzeichnisse: eine Löschverzögerung, keine Unveränderbarkeit

Ein Dateisystem kann Restows eigenen Prozessen nichts verweigern, und keine der verfügbaren Möglichkeiten hält gegen die Leute, gegen die man sie verkaufen würde: chattr +i kann root auf dem Host und jeder Prozess aufheben, der den Docker-Socket erreicht, und dazu gehört der Mounter. Ein wirklich gehärtetes Repository braucht einen getrennten Rechner, auf dem Restow sich nicht anmelden kann.

Für ein Verzeichnis-Repository (das Docker-Volume, eine NFS-Freigabe) bietet Restow deshalb nur eine Löschverzögerung: Restows eigener Code weigert sich, eine gesperrte Datei zu löschen oder zu überschreiben, bis der Zeitraum seit dem Schreiben verstrichen ist. Ein später gesenkter Zeitraum verkürzt nie, was vorher geschrieben wurde. Die Verzögerung schützt vor Missbrauch von Restow, zum Beispiel einem gestohlenen Administratorkonto oder einer verkürzten Aufbewahrungsrichtlinie, in der Restow Sicherungsstände löschen würde. Sie schützt nicht vor jemandem mit Zugriff auf den Server, den Mounter oder die Freigabe, der die Dateien direkt löschen kann. Die Oberfläche sagt deutlich, dass das keine Unveränderbarkeit ist („Löschverzögerung, 30 Tage (nicht unveränderbar)“). Ein Verzeichnis-Repository können nur Provider-Administrationen ändern.

Was gesperrt ist und was nicht

Gesperrt (bei eingeschalteter Unveränderbarkeit)	Nicht gesperrt
Chunk-Store (Microsoft-365-Postfächer, OneDrives und SharePoint-Websites, IMAP-Konten, Proxmox-VE-VM-Disks): Packs, abgeschlossene Manifeste und umhüllte Schlüssel	Prüfpunkte (das unfertige Manifest einer laufenden Sicherung)
Jedes restic-Repository (Rechner, Freigaben, Proxmox-VE-Container): die Objekte `data/`, `snapshots/`, `keys/` und `config` sowie das versiegelte Repository-Passwort daneben	Staging (Mail-Datei-Uploads), Exporte, Downloads und Testobjekte
	die restic-Dateien in `locks/` und `index/`

Warum die restic-Ordner locks/ und index/ offen bleiben: restic schreibt und löscht Sperrdateien bei jedem Lauf, und jedes Prune schreibt den Index neu. restic bricht ein Prune endgültig ab, wenn es eine alte Indexdatei nicht entfernen kann (getestet mit restic 0.19.1). Indexdateien listen nur auf, was die Packs enthalten, sodass restic repair index sie aus den gesperrten Packs wieder aufbaut.

Archivdatensätze behalten ihre eigene Aufbewahrung (siehe Archivierung). Der Nachrichteninhalt des Archivs liegt in denselben Packs wie Backup-Daten; bei eingeschalteter Unveränderbarkeit sind diese Packs daher wie jedes andere Pack gesperrt, für den Zeitraum der Repository-Einstellung und verlängert, solange sie verwendet werden. Dieser Zeitraum ist nicht die Aufbewahrung des Archivs von 8 Jahren.

Löschen unter einer Sperre

Auf einem unveränderbaren S3-Repository löscht Restow ein Objekt, indem es jede seiner Versionen löscht (ein Löschmarker allein gibt nichts frei und versteckt das Objekt nur), nachdem es die Sperre jeder Version geprüft hat. Solange eine Version gesperrt ist, löscht es nichts. Jeder Aufrufer behandelt das als „noch nicht“, nie als Fehler:

Die Aufbewahrung lässt einen Sicherungsstand, dessen Manifest noch gesperrt ist, unangetastet: Er bleibt sichtbar und wiederherstellbar, bis die Sperre abgelaufen ist. Bei restic-Repositories nimmt sie Snapshots, deren Snapshot-Datei gesperrt ist, aus restic forget heraus.
Die Speicherbereinigung (die wöchentliche Speicherprüfung) packt wie bisher um, behält aber ein überholtes oder verwaistes Pack, das der Speicher noch sperrt, und löscht es in einem späteren Lauf.
restic prune bekommt für ein gesperrtes Pack eine Ablehnung, meldet eine Warnung und macht weiter. Das Pack wird von da an nicht mehr referenziert, und das nächste Prune nach dem Ende der Sperre entfernt es.
Eine abgelehnte Löschung wird je Repository festgehalten und auf seiner Karte gezeigt („N Löschungen warten auf das Ende der Sperre“).

Die Folge für Sie: Speicherplatz kommt spät zurück. Gelöschte Daten geben ihren Platz erst frei, nachdem ihre Sperre abgelaufen ist, bis zu Zeitraum plus 7 Tage später. Eine Freigabe, deren Repository noch gesperrt ist, lässt sich vorher nicht endgültig löschen. Ein Sicherungsstand, den die Aufbewahrung sonst entfernt hätte, kann noch eine Weile sichtbar bleiben. Planen Sie die Größe des Buckets damit ein.

Was Sie sehen und wie geprüft wird

Prüfung. Der tägliche Aufbewahrungslauf und Jetzt prüfen auf der Karte des Repositorys fragen den Speicher nach der Sperre einer kleinen Stichprobe zuletzt geschriebener Objekte, die noch verwendet werden (das braucht s3:GetObjectRetention). Jedes muss über „jetzt“ hinaus gesperrt sein, im Compliance-Modus, wenn Compliance eingestellt ist. Jetzt prüfen verlängert nichts. Jede Prüfung wird im Audit-Log festgehalten (storage.target.immutability_verified).
Karte des Repositorys. Der Teil Unveränderbare Backups nennt die Einstellung in Worten (zum Beispiel „Unveränderbar: Object Lock, Compliance-Modus, 30 Tage“), wann die Sperren zuletzt verlängert und wann der Speicher zuletzt gefragt wurde, und zeigt Warnungen zuerst: Objekte, die ohne Sperre gefunden wurden, Objekte, die nur im Governance-Modus gesperrt sind, obwohl Compliance eingestellt ist, eine Verlängerung, die überfällig ist oder fehlschlug. Sie zählt auch die Löschungen, die auf ihre Sperre warten.
Dashboard. Die Kachel Speicher zählt die Repositories des Mandanten mit Object Lock oder Löschverzögerung („Unveränderbar: 2 Repositories mit Object Lock“) und warnt, wenn eines Aufmerksamkeit braucht.
Provider-Ansicht. Sie zählt die Kunden mit unveränderbaren Backups und meldet eine immutability_warning, wenn ein Repository Objekte ohne Sperre oder eine Verlängerung im Rückstand hat.
Markierung an Sicherungsständen. Die Leiste der Sicherungsstände im Restore-Explorer und die Sicherungsstände eines Rechners zeigen, was der Speicher für den Sicherungsstand meldet. „Unveränderbar bis <Datum>“ ist nur bei einer Compliance-Sperre grün, die der Speicher selbst gemeldet hat. Eine Governance-Sperre erscheint als „Gesperrt bis <Datum> (Governance)“ und die Löschverzögerung eines Verzeichnisses als „Löschen verzögert bis <Datum>“, beides neutral, weil ein Konto mit der Umgehungsberechtigung die eine aufheben kann und bei der anderen nur Restows Zusage gilt. „Nicht gesperrt“ heißt: Der Sicherungsstand entstand vor dem Einschalten der Unveränderbarkeit, oder seine Sperre ist abgelaufen.

Wer es ändern darf

Den Schutz erhöhen (mehr Tage, von aus auf an, von Governance auf Compliance) darf, wer das Repository konfigurieren darf.
Ihn senken (weniger Tage, ein schwächerer Modus, aus) ist dem Provider-Inhaber mit einer Anmeldung aus den letzten 10 Minuten vorbehalten. Es gilt nur für Daten, die ab dann geschrieben werden: S3 behält jede bereits gesetzte Sperre, und eine Löschverzögerung folgt dem gespeicherten Verlauf der Einstellung.
Jede Änderung steht im Audit-Log (storage.target.immutability_changed, mit alter und neuer Einstellung und ob sie den Schutz gesenkt hat). Siehe Audit-Log.

Der Dialog sagt, wovor die Einstellung schützt und wovor nicht, und warnt vor einer Senkung.

Wovor es schützt, und wovor nicht

Es schützt vor einem Angreifer auf dem Restow-Server, jemandem, der den Speicherschlüssel von Restow hat, einem gestohlenen Administratorkonto und einer absichtlich verkürzten Aufbewahrungsrichtlinie: Keiner von ihnen kann gesperrte Daten vor ihrem Datum löschen oder überschreiben.

Es schützt nicht vor:

Wer Restow kontrolliert, kann neue Sperren und die Verlängerung anhalten. Was gesperrt ist, bleibt bis zu seinem Datum gesperrt (mindestens der Zeitraum nach der letzten Verlängerung vor dem Angriff), Backups danach sind aber nicht geschützt. Die Prüfung und die Warnungen der Karte zeigen Ihnen, dass etwas nicht stimmt.
Eine Governance-Sperre hebt jedes Konto mit s3:BypassGovernanceRetention auf. Geben Sie dem Schlüssel von Restow eine IAM-Richtlinie ohne diese Berechtigung, oder nutzen Sie den Compliance-Modus.
Löschmarker und neuere Versionen können gesperrte Daten verstecken: Wer den Schlüssel von Restow hat, kann weiterhin Löschmarker oder Müllversionen darüberlegen. Die gesperrten Versionen bleiben. Entfernen Sie die neueren Versionen oder Marker (zum Beispiel mit aws s3api list-object-versions und aws s3api delete-object --version-id), dann liest restow-restore den Bucket wie gewohnt.
Der Master-Key liegt nicht im Bucket. Bewahren Sie eine Kopie von ihm, oder der exportierten Mandantenschlüssel, getrennt vom Server auf, sonst lassen sich gesperrte Daten nicht öffnen. Siehe Restow selbst sichern.
Die Löschverzögerung eines Verzeichnisses schützt nur vor Missbrauch von Restow, siehe oben.
Es ist kein Hardware-WORM und keine rechtliche Garantie. Es ist ein technischer Schutz der Backups. Die Aufbewahrung des Archivs und was sie für das Aufzeichnungsrecht bedeutet, ist ein eigenes Thema: siehe Archivierung und Journaling und GoBD und Nachweise.

Unveränderbare Daten ergänzen die Ransomware-Erkennung, die verdächtige Sicherungsstände markiert und Restows eigene Aufbewahrung anhält: Die Unveränderbarkeit verhindert, dass der Verlauf gelöscht wird, die Erkennung sagt Ihnen, wann Sie nachsehen sollten.

S3-Endpunkte brauchen HTTPS

Ein S3-Repository sendet seine Zugriffsschlüssel (als Signaturen) und jedes Pack an den Speicherdienst. Seit 0.4.0 wird deshalb ein neuer oder geänderter Endpunkt über unverschlüsseltes http:// mit dem Grund endpoint_insecure abgelehnt, außer zum Rechner selbst (localhost, 127.0.0.1, [::1]). Früher gespeicherte Endpunkte laufen weiter, zeigen aber in Rot, dass sie auf HTTPS umziehen sollten, und Testumgebungen können mit S3_ALLOW_INSECURE=true ausnehmen. Die Einzelheiten stehen unter Backups und Zeitpläne.

Grenzen in 0.4.7

Das Standard-Repository der Installation lässt sich nicht unveränderbar machen. Geben Sie dem Mandanten ein eigenes Repository oder eine unveränderbare Kopie.
restic-Indexdateien sind nicht gesperrt (siehe oben).
Der Platz gelöschter Daten kommt erst zurück, wenn ihre Sperre abgelaufen ist, und eine Freigabe, deren Repository noch gesperrt ist, lässt sich vorher nicht endgültig löschen.
Ein Mandant, dessen Aufbewahrungszeitplan gelöscht wurde, wird nicht verlängert.
Nur gegen einen nachgebauten S3-Dienst getestet. Unveränderbare Backups wurden gegen einen nachgebauten S3-Dienst mit Object Lock getestet, nicht gegen einen echten S3-Dienst. Ob Ihr Anbieter die Aufbewahrungs-Header so umsetzt, wie Restow es erwartet, sagt Ihnen die Prüfung: Schalten Sie es zuerst an einem Test-Repository ein und nutzen Sie Jetzt prüfen.
Die bekannten Probleme von 0.4.0 gelten insgesamt, siehe die Roadmap.