Sicherheit – Handbuch

24.1 Transport: TLS und Pinning#

Jede Verbindung zwischen Agent und bkp_target ist TLS-verschlüsselt. Der Agent prüft den Server gegen genau das mit --tls-ca angegebene Zertifikat (Pinning), nicht gegen Zertifizierungsstellen des Systems. Weicht das Zertifikat ab, bricht der Agent ab (Statuscode -8, Kapitel 26). Das schützt vor einem untergeschobenen Server, verlangt aber, dass target.crt sicher zu den Clients kommt.

24.2 Anmeldung: API-Keys und ACL#

Ein API-Key ist ein zufälliger 256-Bit-Wert, den der Server nur als SHA-256-Hash im Speicher hält.
Jeder Key ist an ein oder mehrere Verzeichnisse gebunden. Ein Agent kann nur dort schreiben und lesen.
Key-Dateien auf den Clients nur für den ausführenden Benutzer lesbar machen (chmod 600).
Ein Key pro Client; einen Key entziehen heißt seine Zeile aus der ACL streichen und den Server neu starten.

24.3 Updates: Ed25519-Signatur#

Ein Update ist Code, der als root/SYSTEM läuft. Deshalb gilt:

Das Manifest ist mit Ed25519 signiert (die Signatur erfasst ein festes Präfix plus die exakten Manifest-Bytes). Der Updater vertraut nur den eingebauten oder konfigurierten öffentlichen Schlüsseln.
TLS mit Zertifikats- und Hostprüfung ist Pflicht (kein HTTP, auch nicht über Weiterleitungen). Es schützt aber nur die Übertragung; den Inhalt schützt die Signatur. Pakete sind über SHA-256 und Größe aus dem signierten Manifest gebunden.
Das Manifest hat ein Ablaufdatum und eine steigende Nummer: ein alter, gültig signierter Stand („Replay“) wird abgelehnt, ein abgelaufenes Manifest ebenso.
Pakete werden streng entpackt: nur normale Dateien und Verzeichnisse, keine ..- oder absoluten Pfade, keine Links oder Geräte, Größenbegrenzungen; PACKAGE.json muss die Dateien und die im Manifest zugesagte Version exakt bestätigen.
blocked_versions sperrt eine Version; ein Downgrade gibt es nur mit --allow-downgrade --to <version>.
Der Updater installiert nur mit allow_package_install = yes Pakete nach; die Namen stammen aus dem signierten Manifest und werden streng geprüft.

24.4 Daten im Ruhezustand#

Ohne Verschlüsselung liegen die Daten nur komprimiert im Store: Wer Zugriff auf /srv/backups hat, kann sie lesen. Mit encryption= und key= im Sink (Kapitel 6) verschlüsselt der Agent jeden Chunk, bevor er die Maschine verlässt; der Server sieht dann nur Struktur und Größen, nie Inhalte, und braucht den Schlüssel nie. Die Verschlüsselung ist authentifiziert: verfälschte Daten werden beim Lesen erkannt und nie unbemerkt zurückgeschrieben.

Ohne Verschlüsselung das Speicherverzeichnis durch Dateirechte, ein verschlüsseltes Dateisystem (zum Beispiel LUKS) oder ein verschlüsseltes Volume schützen.
Gemeinsame Stores: Wer in einen Store schreiben darf, kann über die Deduplizierung erkennen, ob ein bestimmter Chunk dort schon liegt, und mit dem passenden Schlüssel alle Runs darin lesen. Rechner, die einander nicht vertrauen, bekommen deshalb eigene Verzeichnisse (ACL) bzw. eigene Stores und Schlüssel. Für gemeinsame Stores sha256 oder blake3 als ID-Hash wählen, nie xxh3-128 (Kapitel 3).
WORM-Sperren (--worm, Kapitel 10) schützen Runs vor dem Löschen durch Wartungsbefehle. Gegen einen Angreifer mit root-Rechten auf dem Server hilft auf einem lokalen Dateisystem nur eine zweite Kopie an einem anderen Ort (mirror, Archiv).

24.5 Checkliste#

Server-Schlüssel target.key und ACL nur für root bzw. das Dienstkonto aegisgrid lesbar.
Pro Client ein eigener Key mit möglichst enger Verzeichnisbindung.
Verschlüsselungs-Schlüssel gesichert an einem zweiten Ort; ohne ihn sind die Daten verloren.
release.key offline, Sicherungskopie an einem zweiten Ort.
Zugang zu bkp_restore, target.crt, API-Key und Verschlüsselungs-Schlüssel auch außerhalb des gesicherten Systems verfügbar.
Regelmäßiger Restore-Test, regelmäßiger scrub und eine zweite Kopie (Sink oder Spiegel).