Sicherheitsmodell

Diese Seite beschreibt, was die Backups eines Endpoints schützt und wo der Schutz endet. Sie folgt dem Aufbau von Agent und Server. Lesen Sie sie, bevor Sie den Agent breit ausrollen, besonders den Abschnitt über Root-Rechte.

Nur ausgehend

Der Agent öffnet keinen Port, auf dem er lauscht. Er verbindet sich ausgehend per HTTPS mit Ihrer Restow-Instanz und mit nichts sonst. Die Instanz verbindet sich nie mit dem Endpoint. Aufgaben wie „Jetzt sichern“, „Wiederherstellung“ oder „Agent deinstallieren“ reisen in der Antwort auf den regelmäßigen Kontakt des Agents mit der Instanz.

Append-only, von der Instanz erzwungen

Der Agent schreibt in ein restic-Repository, das Ihre Instanz bereitstellt. Die Instanz entscheidet, was der Agent darf, nicht der Agent und nicht restic:

Der Agent authentifiziert sich mit seinem eigenen Secret. Der Repository-Endpunkt verweigert jedes Löschen und jedes Überschreiben, außer bei Lock-Dateien.
Der Agent ruft selbst auch nie forget, prune oder eine andere Löschoperation auf.
Aufbewahrung, Prune und Integritätsprüfungen laufen nur auf dem Restow-Server.
Die Integrationstests lassen den echten Agent gegen den Append-only-REST-Server von restic laufen und stellen sicher, dass restic forget --prune mit den Zugangsdaten des Agents fehlschlägt und die Snapshots unverändert bleiben.

Weitere Schutzmaßnahmen des Repository-Endpunkts:

Objektnamen müssen ein SHA-256 in Hex sein, sodass kein Pfad das Repository verlassen kann. Der Server prüft beim Hochladen, dass der Inhalt zum Namen passt, und speichert nichts, wenn er nicht passt.
Bodys über 128 MiB werden abgelehnt. Anfragen sind je Endpoint begrenzt, falsche Zugangsdaten je Adresse.
Jeder Versuch eines Agents, etwas Verbotenes zu tun, wird im Audit-Log protokolliert (endpoint.repository.denied, höchstens ein Eintrag je Endpoint und Art alle 10 Minuten). Ein Rechner, der versucht, seine Backups zu löschen, ist ein Fall für einen Administrator.
Ein gesperrter Endpoint wird abgewiesen und sichert nicht mehr. Ein Mandant, der gesperrt ist, wird ebenfalls abgewiesen.

Der Agent hält nie Zugangsdaten des Speicherziels

Der Agent kennt sein eigenes Agent-Secret und das Repository-Passwort seines eigenen Repositorys. Er erhält nie die Zugangsdaten des Speicherziels, etwa S3-Schlüssel oder Mount-Pfade. Er hat keinen Zugriff auf andere Endpoints oder auf das Speicherziel selbst.

Ein Repository und ein Passwort pro Endpoint

Der Server erzeugt das Repository-Passwort, speichert es mit dem Mandantenschlüssel verschlüsselt und gibt es beim Enrollment an den Agent. Weil der Server es behält, kann ein Administrator auch dann wiederherstellen, wenn der Endpoint nicht mehr existiert. Siehe Restore.

Wie der Server das Repository erreicht

Aufbewahrung, Repository-Prüfungen, Restore-Tests, Durchsuchen, Downloads und das Anlegen des Repositorys brauchen mehr als Append-only-Zugriff. Sie laufen als restic-Prozesse auf dem Server, über einen Listener auf 127.0.0.1, der genau eine Operation lang lebt. Seine Zugangsdaten sind für diesen einen Listener zufällig und gehen über die Umgebung an restic. Es gibt keinen öffentlich erreichbaren Wartungszugang und kein gespeichertes Wartungs-Passwort. Diese restic-Prozesse erhalten nur PATH, TMPDIR und die RESTIC_*-Variablen, nicht die Umgebung des Servers, sie sehen also weder die Datenbank-URL noch den Master-Key.

Geheimnisse

Geheimnis	Wo es liegt	Wie
Enrollment-Token	Im Befehl, den Sie kopieren	24 Stunden gültig, einmal verwendbar. Restow speichert nur einen SHA-256-Hash. Der Agent liest es aus der Umgebung, nie aus einem Flag oder einer URL, und entfernt es sofort aus der Umgebung.
Agent-Secret	`/etc/restow-agent/state.json` auf dem Endpoint	Auf dem Server nur als SHA-256-Hash gespeichert.
Repository-Passwort	`/etc/restow-agent/state.json` auf dem Endpoint	Auf dem Server mit dem Mandantenschlüssel verschlüsselt.

Ruhend auf dem Endpoint. /etc/restow-agent/state.json enthält Agent-Secret und Repository-Passwort im Klartext. Die Datei hat Modus 0600 in einem Ordner mit Modus 0700, Besitzer root. Der Agent korrigiert zu offene Berechtigungen und verweigert eine Datei, die jemand anderem gehört. Sonst wird nichts Geheimes gespeichert. status.json ist für alle lesbar und enthält keine Geheimnisse.
In Benutzung. restic erhält Repository-Passwort und REST-Zugangsdaten nur über Umgebungsvariablen, nie in einer Kommandozeile. Kindprozesse (restic und Hooks) erben nur eine kurze Liste von Variablen.
In Logs. Alles, was der Agent protokolliert, das an den Server gesendete Log-Ende und Fehlermeldungen laufen durch eine Schwärzung. Sie maskiert die genauen Geheimnis-Werte, Tokens, Authorization-Header, Zugangsdaten in URLs und NAME=wert-Paare, deren Name auf ein Geheimnis hindeutet. Ein Hook, der ein eigenes Geheimnis ausgibt, wird nicht erfasst, siehe Profile, Zeitplan und Hooks.
Auf dem Server. Keines dieser Geheimnisse erscheint in Logs oder Audit-Details, und Fehlermeldungen von restic werden geschwärzt.

Integrität dessen, was installiert wird

Die Installationsskripte und das Selbst-Update prüfen SHA-256-Prüfsummen. Diese Prüfsummen stammen von derselben Instanz wie die Binärdateien. Sie schützen vor beschädigten oder abgeschnittenen Downloads. Sie schützen nicht vor einer kompromittierten Instanz: Wer die Instanz kontrolliert, kontrolliert, was die Agents herunterladen.

Agent-Updates sind nicht signiert. Signierte Agent-Releases sind ein späterer Schritt.
Der Agent prüft alle 6 Stunden auf eine neuere Version. Er lädt sie vom selben Host wie Ihre Instanz, prüft, dass das SHA-256 zur Ankündigung passt, startet sie, um zu sehen, dass sie die angekündigte Version meldet, und ersetzt erst dann die aktuelle Binärdatei. Die alte bleibt als restow-agent.prev erhalten. Updates werden nur angewendet, solange kein Lauf aktiv ist.
restic ist auf Version 0.19.1 festgelegt, mit Prüfsummen, die gegen die GPG-signierte SHA256SUMS des offiziellen Releases geprüft wurden.

Der Agent läuft als root, ohne Einschränkung

Der Agent muss jede Datei lesen, die er sichert, und Restores überall hin schreiben. Hooks sind beliebige Befehle, die ein Administrator in Restow festlegt. Wer die Konfiguration eines Endpoints in Restow ändern kann, kann deshalb Befehle als root auf diesem Rechner ausführen. Behandeln Sie den Administrator-Zugang zu Restow entsprechend und halten Sie die Zahl der Administratoren klein.

Der Dienst läuft mit niedriger CPU- und I/O-Priorität und wird von systemd oder launchd neu gestartet, wenn er stoppt.

Wer was darf

Alle Endpoint-Funktionen in der Weboberfläche und der API verlangen einen Mandanten-Administrator oder einen Provider-Administrator. Die Rollen des Provider-Teams sind so aufgeteilt:

Provider-Rolle	Darf
Nur lesen	Liste, Details, Läufe und Wiederherstellungspunkte sehen.
Techniker	Jetzt sichern, Restore, Restore-Test, gesicherte Dateien durchsuchen und herunterladen.
Administrator	Installationsbefehle erstellen und widerrufen, Konfiguration und Hooks ändern, Endpoints sperren und deinstallieren, das Repository-Passwort anzeigen.

Die Rollen selbst beschreibt Team und Rollen.

Was ein kompromittierter Endpoint kann und nicht kann

Der Endpoint hält Passwort und Zugangsdaten seines eigenen Repositorys, weil er schreiben und für Restores lesen muss. Wer root auf dem Endpoint hat, kann deshalb:

neue Backups hinzufügen, auch Müll (Restore-Tests und Repository-Prüfungen bewerten das, die Aufbewahrung räumt auf),
sein eigenes Repository lesen und damit entschlüsseln,
kein Backup löschen oder überschreiben und keine neue Repository-Konfiguration schreiben. Das erzwingt die Instanz,
nicht auf andere Endpoints, andere Mandanten oder das Speicherziel zugreifen.

Ein gestohlenes Agent-Secret ergibt dasselbe: neue Backups in das Repository dieses Endpoints schreiben und es lesen, aber nichts löschen. Um es abzuschneiden, sperren Sie den Endpoint in Restow.

Audit-Log

Jedes Lesen gesicherter Dateien und jede Änderung wird im Audit-Log protokolliert, in jeder Edition. Das Ansehen des Logs (Suche, Details, Kettenprüfung) gehört zu Business und Service Provider und ist in Entwicklung, siehe Audit-Log.

Aktion	Wird protokolliert, wenn
`endpoint.token.created`, `endpoint.token.revoked`	Ein Installationsbefehl erstellt oder widerrufen wird.
`endpoint.enrolled`	Ein Rechner sich anmeldet (Hostname, System, Architektur, Profil, Token-ID, nie ein Geheimnis).
`endpoint.config.changed`	Einstellungen sich ändern. Bei Hooks ein Fingerabdruck, nicht der Text.
`endpoint.backup.requested`, `endpoint.restore_test.requested`	Jemand ein Backup oder einen Restore-Test startet.
`endpoint.snapshot.browsed`, `endpoint.snapshot.downloaded`	Gesicherte Dateien durchsucht oder heruntergeladen werden.
`endpoint.restore.requested`, `endpoint.restore.finished`	Ein Restore auf den Rechner angefordert wird und wenn er endet.
`endpoint.repository.password.revealed`	Jemand das Repository-Passwort anzeigt.
`endpoint.uninstall.requested`, `endpoint.revoked`	Eine Deinstallation angefordert oder ein Endpoint gesperrt wird.
`endpoint.repository.denied`	Ein Agent etwas versucht, das die Append-only-Regeln verbieten.

Bekannte Grenzen

Noch kein mTLS. Version 1 authentifiziert jeden Agent mit einem eigenen Secret über HTTPS. Ein gestohlenes Secret (root auf dem Endpoint) erlaubt, neue Backups in das Repository dieses Endpoints zu schreiben und es zu lesen. Es erlaubt nicht, etwas zu löschen. mTLS je Agent ist für ein späteres Release geplant.
Prüfsummen von derselben Instanz. Siehe oben: Eine kompromittierte Instanz kann einen anderen Agent ausliefern, und Agent-Updates sind nicht signiert.
Root und Hooks. Der Agent und seine Hooks laufen als root.
Das Repository-Passwort entschlüsselt das gesamte Backup eines Endpoints. Wer es besitzt und das Speicherziel lesen kann, kann jede gesicherte Datei lesen.