Wie Restow Ihre Daten verschlüsselt
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.
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.
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, sodass jeder, der die Konfiguration eines Rechners in Restow ändern kann, auf diesem Rechner Befehle als root ausführen kann. Behandeln Sie Administratorzugriff entsprechend. Das Installationsskript und Agent-Updates prüfen SHA-256-Prüfsummen, die von Ihrem eigenen Restow stammen. Das schützt vor beschädigten Downloads, nicht vor einer kompromittierten Instanz; Agent-Updates sind noch nicht signiert.
Signierte Releases
Jedes Release-Image 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. 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. Er 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.
Der Betreiberhinweis
Der Setup-Assistent beginnt mit einem 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. Die Bestätigung (Textfassung, Zeitpunkt, Client-Adresse) wird gespeichert und in das Audit-Log geschrieben, und der Server verweigert die späteren Setup-Schritte, solange sie fehlt. 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 werden meine Daten bei Restow verschlüsselt?
Jeder Chunk wird mit AES-256-GCM verschlüsselt, bevor er den Server verlässt, mit einem getrennten Schlüssel je Organisation (Mandant). Verschlüsselung ist nicht optional oder von der Edition abhängig: sie gilt identisch in Community, Business und Service Provider.
Kann der Betreiber meiner Restow-Instanz meine Daten lesen?
Bei einer selbst gehosteten Installation (der normale Weg für Community oder Business) hält niemand außerhalb Ihrer Organisation den Schlüssel. Bei einer von einem Service Provider betriebenen Instanz hält der Provider den Master-Schlüssel der Installation und kann damit technisch Mandantendaten entschlüsseln, auch außerhalb der laufenden Restow-Anwendung, etwa mit dem eigenständigen Offline-Restore-Werkzeug. Lese- und Restore-Zugriffe innerhalb von Restow selbst laufen über protokollierte, geprüfte Pfade (wer, wann, für wen, von welcher IP) in einem änderungserkennenden, hashverketteten Log; ein Zugriff außerhalb von Restow mit dem Master-Schlüssel direkt erscheint dort nicht. Wählen Sie einen Provider, dem Sie vertrauen, und regeln Sie das ausdrücklich in Ihrem Auftragsverarbeitungsvertrag (Art. 28 DSGVO).
Sendet Restow Telemetrie oder telefoniert nach Hause?
Nein. Keine Telemetrie, kein zur Laufzeit kontaktierter Lizenzserver, keine Verbindung zur IT Systeme Flores UG. Es verbindet sich nur mit dem, was Sie konfigurieren: Microsoft 365, Ihre IMAP-Server, Ihr Speicher und Ihr 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.
Was kann der Agent auf einem Rechner, und was nicht?
Der Agent 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 er hält nie Zugangsdaten zum Speicher. Ein mTLS gibt es noch nicht, jeder Agent authentifiziert sich also mit einem Agent-Geheimnis über HTTPS. Der Agent läuft als root, und Pre- und Post-Hooks laufen ebenfalls als root; wer die Konfiguration eines Rechners in Restow ändern kann, kann daher auf diesem Rechner Befehle als root ausführen.
Kann ich prüfen, dass ein Release wirklich vom Restow-Projekt stammt?
Ja. Jedes Release-Image wird mit cosign signiert (keyless, über GitHub OIDC), liefert eine SBOM mit und wird für amd64 und arm64 gebaut. Die Release-Dateien sind durch eine signierte Prüfsummenliste abgedeckt. Die Dokumentation zeigt den Prüfbefehl. Agent-Updates dagegen werden gegen eine SHA-256-Prüfsumme Ihres eigenen Restow geprüft, sind aber noch nicht signiert.