← Alle Funktionen

Wie Restow Ihre Daten verschlüsselt

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-29

Jeder Chunk, den Restow in den Speicher schreibt, wird mit AES-256-GCM verschlüsselt, bevor er den Server verlässt, mit einem getrennten Verschlüsselungsschlüssel je Organisation. Das ist eine strukturelle Eigenschaft des Chunk-Stores, keine Einstellung, die man erst aktivieren muss, und sie gilt in jeder Edition gleich.

Wer Ihre Daten tatsächlich lesen kann

Bei einer selbst gehosteten Installation (dem normalen Weg für Community oder Business) verlässt der Schlüssel Ihrer Organisation nie Ihre eigene Infrastruktur, und niemand außerhalb hält den Schlüssel. Bei einer Instanz, die ein Service Provider für Sie unter der Service-Provider-Edition betreibt, hält dieser Provider den Master-Schlüssel der Installation, um den Dienst zu betreiben (das lässt sich bei einem von jemand anderem betriebenen Dienst nicht vermeiden), und kann damit technisch die Daten jedes Mandanten entschlüsseln, auch vollständig außerhalb von Restow (etwa mit dem eigenständigen Offline-Restore-Werkzeug und dem Chunk-Store direkt, an der laufenden Anwendung vorbei). Lese- und Restore-Zugriffe innerhalb von Restow selbst laufen über geprüfte Pfade und landen in einem änderungserkennenden, hashverketteten Log: wer, wann, für wen, und von welcher IP. Aber dieses Log sieht keinen Zugriff, der außerhalb von Restow mit dem Master-Schlüssel direkt erfolgt. Wählen Sie einen Provider, dem Sie aus demselben Grund vertrauen, aus dem Sie jedem vertrauen würden, der einen Master-Schlüssel zu Ihren Daten hält, und lassen Sie Ihren Auftragsverarbeitungsvertrag (Art. 28 DSGVO) das ausdrücklich regeln.

Datenbankrollen

Seit 0.3.5 läuft die Anmeldung (Sitzungen, Passwörter, Passkeys und Zwei-Faktor-Geheimnisse) auf einer eigenen Datenbankrolle. Die Rolle der Anwendung beschränkt sich auf Mandantendaten unter PostgreSQL-Row-Level-Security und darf nur Jobs zur Warteschlange hinzufügen. Die Datenbankmigration legt die Anmelderolle an und hält sie aktuell; eine Änderung der .env-Datei ist nicht nötig, und DATABASE_AUTH_URL ist optional für Installationen, die ihre Datenbankrollen selbst verwalten.

Das ist eine Härtung, eine Ausnutzung ist nicht bekannt. Bis 0.3.4 konnte die Rolle der Anwendung auch die Tabellen außerhalb von Row-Level-Security lesen und schreiben, darunter die Anmeldetabellen, die Installationseinstellungen, die Lizenz und die Job-Warteschlange; ein Fehler in mandantenbezogenem Abfragecode hätte daher Daten über seinen Mandanten hinaus erreichen können. Die Änderung begrenzt, was ein solcher Fehler erreichen kann; sie heißt nicht, dass es keinen gibt.

Kein Nach-Hause-Telefonieren

Restow telefoniert nicht nach Hause: keine Telemetrie, kein zur Laufzeit kontaktierter Lizenzserver, keine Verbindung zurück zur IT Systeme Flores UG. Es verbindet sich nur mit dem, was Sie konfigurieren: Microsoft 365, Ihre IMAP-Server, Ihren gewählten Speicher und Ihren Mail-Transport. Dazu kommen, nur im öffentlichen Modus, Let's Encrypt für Ihr eigenes TLS-Zertifikat; nur wenn Sie die Update-Prüfung einschalten, die von Ihnen gewählte Update-Quelle; und nur wenn Sie den optionalen Updater aktivieren, die Registry, von der er Images bezieht (standardmäßig ghcr.io). Die Agents auf Ihren Servern und Clients sprechen nur mit Ihrem eigenen Restow. Ein Lizenzschlüssel wird offline gegen eine signierte Ed25519-Signatur geprüft, nicht durch Kontaktaufnahme mit einem Server. Seit 0.4.5 kann ein Schlüssel außerdem einen Update-Zeitraum tragen: Ob ein Release abgedeckt ist, wird aus dem Schlüssel und aus dem Release-Datum entschieden, das das Image des Releases trägt, nicht durch einen Aufruf bei einem Server, und die installierte Version arbeitet mit allen ihren Modulen weiter.

Der Agent für Server und Clients

Der Agent, der Server und Clients sichert (siehe Server- und Client-Backup), verbindet sich nur ausgehend über HTTPS und öffnet keinen Port. Er ist nur anhängend: Er kann Backups hinzufügen, aber nie löschen oder überschreiben, und Aufbewahrung und Bereinigung laufen ausschließlich auf dem Restow-Server. Er hält nie die Zugangsdaten des Speicherziels, nur sein eigenes Agent-Geheimnis und das Passwort seines eigenen Repositorys. Zwei Grenzen benennen wir offen. Ein mTLS gibt es noch nicht: Jeder Agent authentifiziert sich mit einem Agent-Geheimnis über HTTPS, sodass ein gestohlenes Geheimnis (root auf dem Rechner) das Schreiben neuer Backups in das Repository dieses Rechners und dessen Lesen erlauben würde, aber kein Löschen. Und der Agent läuft als root, weil er jede gesicherte Datei lesen muss. Pre- und Post-Hooks laufen ebenfalls als root, deshalb entscheidet der Rechner, ob er sie ausführt: Auf einem neuen Rechner sind sie aus, nur root auf dem Rechner kann sie erlauben (nur benannte Skripte oder beliebige Befehle), und Restow kann diese Einstellung weder ändern noch einen Hook setzen, den der Rechner nicht ausführen würde. Wo beliebige Befehle erlaubt sind, kann jeder, der die Konfiguration dieses Rechners in Restow ändern kann, dort Befehle als root ausführen; behandeln Sie Administratorzugriff entsprechend.

Der Agent wird in einen Ordner installiert, den nur root ändern kann, und jedes Agent-Release signiert der Maintainer mit einem Ed25519-Schlüssel, der in den Agenten einkompiliert und in das Installationsskript geschrieben ist. Installer und Selbstaktualisierung des Agenten prüfen diese Signatur und den SHA-256 jeder Datei, bevor sie etwas ausführen, sodass eine kompromittierte Instanz einen installierten Agenten kein eigenes Programm ausführen lassen kann. Eine Grenze bleibt: Die Erstinstallation vertraut dem Installationsskript, das die Instanz ausliefert, wie jedes curl | sh. Vergleichen Sie den Fingerabdruck des Release-Schlüssels, den das Skript ausgibt, mit dem veröffentlichten, SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o (Ed25519, auch in den Release-Notes).

Signierte Releases

Jedes Release erscheint in zwei Builds: den vollständigen Images restow und restow-web und den Community-Images restow-community und restow-web-community. Jedes der vier Images wird für amd64 und arm64 gebaut, mit cosign signiert (keyless, über GitHub OIDC) und liefert eine SBOM im SPDX-Format mit, die auch als cosign-Attestation angehängt ist. Die Release-Dateien stehen in einer Prüfsummendatei, die ebenfalls signiert ist, und Agent-Releases tragen die eigene Signatur des Maintainers (siehe oben). Wie Sie das alles prüfen, beschreibt Releases prüfen in der Dokumentation.

Updates und Updater

Die Update-Prüfung ist aus, bis ein Administrator sie einschaltet. Danach liest sie nur die Release-Liste der Quelle, die der Betreiber gewählt hat (standardmäßig die öffentlichen GitHub-Releases, oder Ihr eigenes GitHub-, Forgejo- oder Gitea-Repository), einmal am Tag oder auf Anforderung, und keine Anfrage enthält Daten über Ihre Installation. Der optionale Updater ist ein Opt-in und ein eigenes Compose-Profil, das nichts tut, bis Sie es starten. Bevor er ein Image bezieht, prüft er dessen cosign-Signatur gegen die Identität des Release-Workflows und lehnt ein Image ab, das er nicht prüfen kann. Die Update-Quelle zu ändern und ein Update anzukündigen verlangt eine frische Anmeldung. Der Updater braucht den Docker-Socket, der gleichbedeutend mit root-Zugriff auf den Host ist: ein dokumentierter Kompromiss, beschrieben unter Updates in der Dokumentation, das Sie vor dem Aktivieren lesen sollten.

Seit 0.3.6 zeigt eine Änderung, die erst nach einem Neustart wirkt, unter Installation, Updates den Hinweis „Neustart erforderlich“ mit dem Grund und dem Befehl zum Kopieren, und Provider-Administratoren sehen einen Hinweis über jeder Seite. Läuft der Updater, bekommt der Inhaber des Provider-Teams außerdem die Schaltfläche „Jetzt neu starten“. Sie läuft über den Updater und startet nur die API, den Worker oder den Scheduler neu, keinen anderen Dienst. Sie läuft nie, während ein Update angekündigt ist oder läuft, sie fragt vorher nach einer Bestätigung, und das Audit-Log hält fest, wer sie ausgelöst hat. Nichts startet ohne einen Klick neu. Die Schaltfläche braucht den Updater von 0.3.6; ein älterer Updater zeigt stattdessen den Befehl. Noch zeichnet nichts eine Neustart-Anforderung auf: Hinweis und Schaltfläche sind für Updates da, die sie brauchen.

Seit 0.4.2 lässt sich ein Update außerdem für ein gewähltes Datum und eine Uhrzeit planen, bis zu 30 Tage im Voraus, in der Zeitzone der Installation. Vorher wird nichts angehalten: Der Server bestätigt den Plan den Countdown vor der gewählten Zeit genau so, als hätte ein Administrator ihn dann bestätigt, mit denselben Prüfungen, und alle angemeldeten Personen sehen ab einem Tag vorher einen Hinweis. Läuft der Server mit dem neuen Release, installieren es auch Proxmox-VE-Knoten und Agenten, nur im Leerlauf, über denselben signierten Download wie ihre eigene Selbstaktualisierung (der Agent prüft die signierte SHA256SUMS mit dem eingebauten Schlüssel, dann jede Datei mit ihrem signierten Hash), und neue Läufe warten, bis sie es getan haben, höchstens 15 Minuten. restow-agent update tut es von Hand auf einem Rechner, wie restow-pve update auf einem Knoten; läuft gerade eine Sicherung, lehnt er ab.

Seit 0.3.6 aktualisiert der erneut ausgeführte Installer (install.sh) auf einer bestehenden Installation außerdem eine alte docker-compose.yml auf das Release, das in der .env steht. Er prüft die Datei gegen die signierte SHA256SUMS des Releases, behält die alte Datei als docker-compose.yml.bak-<timestamp> und lässt die .env unverändert.

Unveränderbare Backups und Ransomware-Erkennung

Verschlüsselung schützt, was ein Angreifer lesen kann; sie hindert nicht am Löschen. Seit 0.4.0 tun das zwei weitere Schichten. Jedes Repository lässt sich unveränderbar machen: Bei S3 mit Object Lock lehnt der Speicher selbst ab, gesperrte Backup-Daten vor ihrem Datum zu löschen oder zu überschreiben, wer auch fragt; ein Verzeichnis bekommt nur eine Löschverzögerung, die Restow selbst einhält und die keine Unveränderbarkeit ist. Sie ist aus, bis ein Administrator sie einschaltet, und ein Senken braucht den Provider-Inhaber mit jüngerer Anmeldung. Was gesperrt ist und was nicht, und wovor es nicht schützt, steht auf der Speicherseite. Die Ransomware-Erkennung beurteilt jeden neuen Sicherungsstand, markiert die verdächtigen, meldet einmal je Angriff und hält die Aufbewahrung des Objekts an, bis ein Administrator den Befund klärt. Sie ist ein Frühwarnsystem, kein Virenscanner, und nur mit simulierten Angriffen getestet; siehe Ransomware-Erkennung.

S3-Endpunkte über HTTPS

Seit 0.4.0 wird ein neuer oder geänderter S3-Endpunkt über reines http:// abgelehnt, auch für Provider-Administratoren und den Installations-Standard, außer zur Maschine selbst. Früher gespeicherte Endpunkte funktionieren weiter und sagen in Rot, dass sie auf HTTPS umziehen sollten.

Der Mounter und Freigaben

Das Backup von Freigaben (siehe Dateifreigaben) läuft in kurzlebigen Runner-Containern, die der Mounter startet, und der Mounter hält den Docker-Socket, also root-gleichen Zugriff auf den Host. Neue Installationen starten ihn standardmäßig; install.sh --no-mounter lässt ihn aus, und die Sicherheitshinweise zum Mounter sollten Sie vorher lesen (englisch). Ein Runner hat nur ein internes Netz zur API, bindet die Freigabe nur lesend ein und schreibt mit einem Zugangsdatum, das für einen Lauf gilt und nur anhängend ist. Mandanten-Administratoren können Freigaben selbst hinzufügen; eine Freigabe an einer privaten oder Loopback-Adresse braucht die Freigabe durch einen Provider-Administrator oder den Installationsschalter „Mandanten dürfen Freigaben in privaten Netzen hinzufügen“.

Datenbank-Dumps, Updates und Datei-Restore

Vor einem Update hält der Updater einen Dump der Datenbank vor. Der Reiter Updates listet diese Dumps, und der Provider-Inhaber kann einen herunterladen, über einen Einmal-Link, nach jüngerer Anmeldung und mit Audit-Eintrag, oder löschen. Ein Dump enthält die ganze Datenbank, verschlüsselte Geheimnisse eingeschlossen: Bewahren Sie einen heruntergeladenen Dump so sorgfältig auf wie den Hauptschlüssel. Wird ein Update bestätigt, zählt sein Dialog, was in jedem Mandanten noch läuft, und fragt, ob die Läufe sauber angehalten werden („Sauber anhalten“), ob auf sie gewartet wird („Warten, bis sie fertig sind“) oder nicht („Nicht warten“); ab der Bestätigung bis zum Ende des Updates startet kein neuer Lauf. Seit 0.4.2 kann ein Administrator außerdem eine laufende Sicherung in der Weboberfläche stoppen (Proxmox-VE-Gäste, Rechner und Läufe von Dateifreigaben); jedes Stoppen fragt vorher nach und wird im Audit-Log festgehalten, und der Lauf endet als „Abgebrochen“.

Restore-Operatoren, die Backups sehen und wiederherstellen, ohne sie zu verwalten, können jetzt auch Server & Clients, Datei-Restore öffnen: Sie durchsuchen Sicherungsstände, laden Dateien als ZIP herunter und stellen Dateien auf einem Rechner wieder her, und bei Proxmox VE durchsuchen und laden sie Dateien von Container- und VM-Sicherungsständen herunter. Einstellungen, Tokens, Jobs, Sichern, die Wiederherstellung eines ganzen Gasts und das Repository-Passwort bleiben bei den Administratoren. Jedes Lesen, Herunterladen und Wiederherstellen steht mit dem Operator als Akteur im Audit-Log. Ein vorbereiteter Download von Proxmox-VE-Dateien lässt sich einmal innerhalb von zehn Minuten von dem Administrator starten, der ihn vorbereitet hat, und die Dateien einer VM liest der Server in einem eingeschränkten Kindprozess, ohne etwas einzubinden.

Der Betreiberhinweis

Der Setup-Assistent fragt zuerst nach einem einmaligen Setup-Token, das nur lesen kann, wer Zugriff auf das Log (oder die Konfiguration) des Servers hat. Danach zeigt er einen Betreiberhinweis, der vor allem anderen bestätigt werden muss: Hardware und Speicher (Redundanz, Unveränderbarkeit bzw. WORM), die Verwahrung der Schlüssel, Netzwerk- und Zugriffssicherheit sowie Restore-Tests liegen in der Verantwortung des Betreibers, und das Archiv ist für den GoBD-konformen Einsatz ausgelegt. Daten sind nur unveränderbar, wenn der Speicher sie unveränderbar macht: Ohne Object Lock am Speicherort kann jeder, der ihn erreicht, die Backups ändern oder löschen. Seit 0.4.0 kann Restow Backup-Daten auf S3 mit Object Lock sperren, und ein Verzeichnis bekommt nur eine Löschverzögerung (siehe oben). Die Bestätigung (Textfassung, Zeitpunkt, Client-Adresse) wird gespeichert und in das Audit-Log geschrieben, und der Server schließt die Einrichtung ohne sie nicht ab. Siehe Betreiberhinweis in der Dokumentation.

Der Rest des Bildes

Verschlüsselung ist ein Teil der Souveränitätsgeschichte; wo die verschlüsselten Bytes physisch liegen, ist der andere: siehe Speicher und Ihre Daten sind Ihre Daten für das Gesamtbild.

Häufig gefragt

Wie Mandantentrennung funktioniert →

Mehr in Wissen: das Backup-Glossar (Verschlüsselung gespeicherter Daten, Key Encryption Key) →

Ransomware-Erkennung: wie jeder Sicherungsstand beurteilt wird →

Mehr in Wissen: unveränderliche Backups, WORM, Air Gap und Ransomware →

Mehr in Wissen: DSGVO und Backups (Löschung, Verschlüsselung, Auftragsverarbeiter) →