Backup verschlüsseln: Schlüsselverwaltung, an der Restores scheitern

Die Verschlüsselung selbst ist bei allen gängigen Backup-Werkzeugen erledigt, bevor man darüber nachgedacht hat: ein Schalter, ein Passwort, fertig. Der schwierige Teil kommt danach und wird fast nie behandelt.

Ein verschlüsseltes Backup ohne verfügbaren Schlüssel ist gleichwertig zu keinem Backup. Und dieser Fall tritt in der Praxis häufiger ein als ein Plattendefekt – weil der Schlüssel typischerweise genau auf dem System liegt, das ausgefallen ist.

Dieser Artikel behandelt deshalb überwiegend Schlüsselverwaltung.

Wann verschlüsseln?

Kurze Antwort: sobald die Daten deinen Einflussbereich verlassen. Genauer:

Ziel	Verschlüsseln?
Cloud-Speicher, Objektspeicher	immer
Fremdgehosteter Server	immer
Wechselplatte, die transportiert wird	immer
Backup-Server im eigenen Rack	empfehlenswert
Lokale Platte im selben Gerät	optional

Der Grund für „immer“ bei fremden Zielen ist nicht Misstrauen gegenüber einem konkreten Anbieter. Es ist die Tatsache, dass du dort keine Kontrolle über Zugriffe, Ausmusterung von Datenträgern und Rechteverwaltung hast. Clientseitige Verschlüsselung macht diese Fragen für deine Daten gegenstandslos.

Bei der Wechselplatte ist die Sache noch einfacher: Sie wird irgendwann verloren.

Drei Arten, die verwechselt werden

Transportverschlüsselung schützt die Übertragung. TLS, SSH. Sie schützt nicht die gespeicherten Daten.

Verschlüsselung beim Anbieter („Encryption at Rest“) bedeutet, dass der Anbieter die Daten verschlüsselt speichert – mit seinem Schlüssel. Gegen einen gestohlenen Datenträger hilft das. Gegen Zugriff durch den Anbieter oder durch jemanden mit Kontozugang nicht.

Clientseitige Verschlüsselung verschlüsselt vor der Übertragung, mit deinem Schlüssel. Nur diese Variante bedeutet, dass ausschließlich du die Daten lesen kannst.

Wenn ein Anbieter mit „verschlüsselter Speicherung“ wirbt, ist meist die zweite Variante gemeint. Für ein Backup ist die dritte die relevante.

Wie die Werkzeuge es lösen

restic

Verschlüsselt immer, ohne Möglichkeit, es abzuschalten. Das Repository wird mit einem Master-Schlüssel verschlüsselt, der wiederum mit deinem Passwort geschützt ist.

Praktische Folge: Es lassen sich mehrere Passwörter für dasselbe Repository anlegen.

# zweiten Zugang anlegen - z. B. fuer eine Vertretung
restic key add

# vorhandene Zugaenge auflisten
restic key list

Das ist der eleganteste Weg, das Vertretungsproblem zu lösen: Ein zweiter Zugang mit eigenem Passwort, hinterlegt an einem anderen Ort, ohne dass jemand dein Passwort kennen muss.

Das Passwort gehört in eine Datei mit chmod 600 und wird über RESTIC_PASSWORD_FILE übergeben – nicht als Kommandozeilenargument, denn Argumente sind für jeden sichtbar, der ps ausführen darf.

BorgBackup

Borg kennt mehrere Modi. Die praktisch relevante Unterscheidung:

Modus	Wo liegt der Schlüssel
repokey	im Repository, geschützt durch die Passphrase
keyfile	lokal auf dem Client, zusätzlich Passphrase

repokey ist bequemer, weil der Schlüssel mit dem Repository reist. Bei keyfile ist der Schlüssel nur lokal vorhanden – geht der Client verloren, ist das Repository ohne gesicherten Schlüssel unbrauchbar.

Borg bringt für beide Fälle eine Exportfunktion mit, inklusive einer druckbaren Variante:

borg key export /pfad/zum/repo schluessel-sicherung.txt
borg key export --paper /pfad/zum/repo   # zum Ausdrucken

Die Papiervariante ist bewusst so gestaltet, dass sie sich wieder eintippen lässt. Das klingt altmodisch und ist genau deshalb die Verwahrungsform, die einen kompletten Systemausfall überlebt.

Proxmox Backup Server

PBS verschlüsselt clientseitig auf dem PVE-Host. Der Schlüssel entsteht beim Einrichten des Speichers und liegt anschließend auf dem Host.

Die Oberfläche bietet an, eine Sicherung des Schlüssels herunterzuladen – einschließlich einer druckbaren Variante. Diesen Schritt jetzt ausführen, nicht später. Wer ihn überspringt, hat den Schlüssel ausschließlich auf dem Host, dessen Ausfall der ganze Zweck der Übung war.

Details zur Einrichtung: Proxmox Backup Server einrichten.

Das eigentliche Problem: Verwahrung

Hier scheitern Restores. Die Regel dazu ist kurz:

Der Schlüssel darf nicht ausschließlich an einem Ort liegen, der vom selben Ereignis betroffen sein kann wie die Daten.

Daraus folgt eine unbequeme Konsequenz: Der Passwortmanager auf dem Server, der ausgefallen ist, zählt nicht. Die Notiz auf dem verschlüsselten Notebook, das gestohlen wurde, zählt nicht. Die Kopie im Backup zählt erst recht nicht – man bräuchte den Schlüssel, um an den Schlüssel zu kommen.

Ein Verfahren, das funktioniert

Drei Kopien an drei unabhängigen Orten:

1. Betriebskopie – auf dem System, das die Sicherung ausführt. chmod 600, Eigentümer root. Diese Kopie ist für den laufenden Betrieb, nicht für den Notfall.
2. Kopie im Passwortmanager, der außerhalb der gesicherten Umgebung erreichbar ist – also nicht auf dem eigenen Server, sondern beim Anbieter oder auf einem Gerät, das unabhängig vom Rechenzentrum ist.
3. Ausdruck an einem physisch getrennten Ort – Bankschließfach, Safe, ein anderes Gebäude. Borg und PBS liefern die Papiervariante mit; bei restic ist es das Passwort selbst.

Für Betriebe kommt ein vierter Punkt dazu: eine zweite Person hat Zugang. Sonst ist die Datensicherung von der Verfügbarkeit eines einzelnen Menschen abhängig, was in einem ernsten Fall regelmäßig zusammenfällt.

Was gegen den Ausdruck spricht – und warum er trotzdem richtig ist

Ein Ausdruck ist kopierbar, verlierbar und altert. Alles richtig. Er hat trotzdem eine Eigenschaft, die keine digitale Verwahrung bietet: Er ist nicht von einem System abhängig, das ausfallen kann. Genau darum geht es. In einem verschlossenen Umschlag mit Datum, an einem Ort mit Zugangskontrolle, ist er die belastbarste Rückfallebene.

Wenn der Schlüssel gewechselt wird

Ein Schlüsselwechsel ist selten nötig, aber wenn, dann meist unter Druck – etwa nach einem Verdacht auf Kompromittierung. Zwei Dinge sind dabei zu beachten:

Alte Sicherungsstände bleiben mit dem alten Schlüssel verschlüsselt. Solange sie existieren, brauchst du auch den alten Schlüssel. Beide aufbewahren, bis der letzte alte Stand entfernt ist.

Der Wechsel gehört dokumentiert. Datum, Grund, wo die neue Kopie liegt, ob die alte noch benötigt wird. Ohne diese Notiz weiß in zwei Jahren niemand mehr, welcher der drei Umschläge der aktuelle ist.

Was Verschlüsselung nicht leistet

Zur Abgrenzung, weil das regelmäßig verwechselt wird:

• Sie schützt nicht gegen Löschung. Ein Angreifer, der dein Repository löscht, braucht dafür keinen Schlüssel. Dagegen hilft Unveränderlichkeit: Ransomware-sichere Backups.
• Sie schützt nicht gegen fehlerhafte Sicherungen. Verschlüsselter Müll bleibt Müll.
• Sie ersetzt keine Zugangskontrolle am Backup-System.

Checkliste

• Alle Ziele außerhalb der eigenen Kontrolle sind clientseitig verschlüsselt
• Der Schlüssel existiert an mindestens drei unabhängigen Orten
• Mindestens eine Kopie ist nicht von der eigenen Infrastruktur abhängig
• Mindestens eine Kopie ist physisch getrennt verwahrt
• Passwörter stehen in Dateien mit chmod 600, nicht in Kommandozeilen
• Eine zweite Person kann im Ernstfall entschlüsseln
• Ein Restore wurde mit der Notfallkopie des Schlüssels durchgeführt – nicht mit der Betriebskopie
• Schlüsselwechsel sind dokumentiert
• Alte Schlüssel bleiben verfügbar, solange alte Stände existieren

Der vorletzte Punkt der Liste ist der wichtigste und der am seltensten erfüllte. Ein Restore mit der Betriebskopie beweist nur, dass das System funktioniert – nicht, dass deine Notfallverwahrung taugt. Wie das getestet wird: Restore testen.

Weiter im Cluster

• 3-2-1-Backup-Strategie
• restic, Borg oder PBS? – Verschlüsselung im Vergleich
• Offsite-Backup – wo Verschlüsselung Pflicht wird
• Ransomware-sichere Backups – die andere Hälfte des Schutzes
• Restore testen
• Typische Backup-Fehler