Backup-Verschlüsselung: Schlüsselverwaltung richtig

Die meisten Backup-Setups in deutschen KMU sind 2026 verschlüsselt — das ist die gute Nachricht. Die schlechte Nachricht: Bei vielen ist die Schlüsselverwaltung so dünn, dass die Verschlüsselung im Ernstfall mehr Schaden als Schutz bringt. Drei Szenarien aus unserer Praxis:

• Der einzige Mitarbeiter, der das Restic-Repo-Passwort kannte, hat das Unternehmen verlassen. Niemand kommt mehr an die Off-Site-Backups.
• Die TrueNAS-Datasets sind verschlüsselt, der Key liegt als JSON-Datei auf demselben TrueNAS. Bei Ransomware-Befall ist Schlüssel und Daten gleichzeitig weg.
• Das PBS-Repo ist Client-Side verschlüsselt, der Key-File wurde nie woandershin kopiert. Server-Crash und Backup-Wiederherstellung scheitern.

Backup-Verschlüsselung ist Hygiene — aber nur, wenn die Schlüsselverwaltung mitgedacht wird. Dieser Artikel zeigt die Prinzipien und konkrete Umsetzung für die verbreiteten Tools.

Symmetrisch vs. asymmetrisch — was wo eingesetzt wird

Die wichtigste konzeptionelle Trennung:

Symmetrische Verschlüsselung (AES-256, ChaCha20) ist schnell und für große Datenmengen gemacht. Der gleiche Schlüssel verschlüsselt und entschlüsselt. Für die eigentlichen Backup-Daten ist AES-256 der Standard — schnell genug, dass die Festplatte das Bottleneck ist und nicht die CPU.

Asymmetrische Verschlüsselung (RSA, ECC) ist langsamer, hat aber den Vorteil, dass öffentlicher und privater Schlüssel getrennt sind. In der Backup-Praxis wird sie typischerweise für Key Wrapping verwendet: Der eigentliche Daten-Schlüssel (AES) wird mit einem RSA-Public-Key verschlüsselt und mit dem Backup abgelegt. Zum Wiederherstellen braucht es den passenden Private-Key.

In modernen Backup-Tools sieht das in der Regel so aus: Symmetrischer Master-Key pro Backup-Job, der wiederum mit einer Passphrase oder einem asymmetrischen Schlüssel “gewrappt” wird. Wer einen einzelnen Backup-Job entschlüsseln will, braucht beides.

Schlüssel-Tresor-Optionen — was wo passt

Wo lebt der Schlüssel, der zum Backup gehört? Hier eine Übersicht der gängigen Optionen mit Pro/Contra:

HashiCorp Vault. Enterprise-Standard für zentrales Secret Management. Audit-Logs, Rotation, Access Policies, Integration mit Identity-Providern. Erfordert Setup-Aufwand und mindestens drei Knoten für HA. Pro: voll-feature, gut auditierbar. Contra: Overhead für sehr kleine Umgebungen.

Bitwarden / Vaultwarden. Eigentlich ein Passwort-Manager, aber gut geeignet, um Backup-Keys (kurze Strings, Passphrases) zu speichern. Self-Hosted-Version (Vaultwarden) läuft auf jeder kleinen VM. Pro: niedrige Einstiegshürde, Team-Sharing. Contra: kein Auto-Rotation, schwächere Audit-Trails als Vault.

KeePassXC mit YubiKey. Verschlüsselte Datei-basierte Datenbank, geschützt durch Master-Passphrase + Hardware-Token. Für Ein-Personen-Workflows oder kleine Teams. Pro: keine Server-Infrastruktur, Offline-fähig. Contra: Sharing umständlich, Multi-User-Workflows fragil.

AWS KMS / Azure Key Vault. Wenn die Cloud-Infrastruktur sowieso bei einem Hyperscaler liegt, sind die nativen KMS-Dienste eine ernsthafte Option. Hardware-backed Keys (HSM), Audit-Logs, fein granulare IAM-Integration. Contra: Vendor-Lock-in, und Backup-Schlüssel beim gleichen Anbieter zu lagern, der auch die Cloud-Daten hostet, ist nicht für jedes Compliance-Modell passend.

Hardware-Token / Smartcards. Für hochsensible Master-Keys gibt es dedizierte Lösungen (YubiKey HSM, Nitrokey HSM, Smartcards). Schlüsselmaterial verlässt das Gerät nie. Pro: höchste Sicherheit. Contra: physisches Handling, Verfügbarkeit bei Wartung.

Pragmatische Empfehlung für KMU 2026: Vaultwarden für Backup-Repo-Passphrases, KeePassXC + YubiKey für Master-Keys. Für größere Umgebungen oder regulierte Branchen: HashiCorp Vault.

3-2-1 für Schlüssel — auch Schlüssel brauchen Backups

Die 3-2-1-Regel ist für Daten Standard. Für Schlüssel wird sie oft vergessen. Mindestanforderung:

• Zwei Kopien des Master-Keys, idealerweise drei
• Räumlich getrennt (nicht alles im gleichen Tresor)
• Verschlüsselt (Klartext-Key auf einem USB-Stick ist keine Lösung)

Konkretes Setup, das sich in der Praxis bewährt:

1. Master-Key im primären Schlüssel-Tresor (z.B. Vaultwarden), Zugriff für IT-Leitung
2. Verschlüsseltes Backup des gesamten Tresors monatlich auf separates Medium
3. Notfall-Schlüssel im Bankschließfach — ausgedruckt auf Papier, in versiegeltem Umschlag

Letzteres klingt altmodisch, ist aber die einzige Variante, die einen kompletten IT-Ausfall (alle Systeme verschlüsselt durch Ransomware, alle Konten gesperrt) überlebt. Wir haben Kunden, die genau dieses Setup bei einem Ransomware-Befall gerettet hat — der Geschäftsführer hat das Schließfach geöffnet, den Schlüssel rausgeholt und damit das Off-Site-Backup entschlüsselt.

Rotation: jährlich, aber sinnvoll

Backup-Master-Keys sollten rotiert werden. Wie oft, hängt vom Risikoprofil ab — eine sinnvolle Faustregel für KMU: einmal jährlich, plus bei jedem Verdacht auf Kompromittierung oder Personalwechsel mit Schlüsselzugriff.

Rotation bedeutet nicht: alte Backups neu verschlüsseln. Das wäre meist unverhältnismäßig aufwändig. Stattdessen:

• Neuer Master-Key wird angelegt und in Tresor abgelegt
• Ab Stichtag werden neue Backups mit dem neuen Key verschlüsselt
• Alte Backups bleiben mit altem Key zugänglich — der alte Key bleibt im Tresor, getrennt markiert (“ARCHIV — bis Datum X”)
• Nach Ablauf der Aufbewahrungsfrist für die alten Backups wird auch der alte Key gelöscht

Wer das Re-Encryption-Modell trotzdem fahren will (z.B. weil ein alter Schlüssel kompromittiert wurde): einmaliger Aufwand einplanen, mit den Tool-spezifischen Mechanismen (siehe unten).

Recovery-Szenarien durchspielen

Ein Schlüsselverwaltungs-Konzept ist nur so gut wie der durchgespielte Notfall. Drei Szenarien, die in jeder KMU-Umgebung mindestens einmal jährlich getestet werden sollten:

Szenario 1: IT-Verantwortlicher steht morgen nicht zur Verfügung. Kann ein anderer Mitarbeiter / die Geschäftsführung an die Backup-Schlüssel? Wenn die Antwort “nein” ist, gibt es ein Bus-Faktor-Problem.

Szenario 2: Komplettes Rechenzentrum nicht erreichbar. Sind Schlüssel auch von einem alternativen Standort aus zugänglich? Im Idealfall: vom Laptop des Geschäftsführers zu Hause, plus Bankschließfach.

Szenario 3: Ransomware hat alle Online-Systeme verschlüsselt. Liegt mindestens eine Schlüssel-Kopie offline (Papier, kalter Speicher)? Wenn nur Online-Tresore existieren, ist das Konzept nicht ransomware-fest.

Konkrete Tools: PBS, Restic, TrueNAS

Proxmox Backup Server (PBS) — Client-Side Encryption. PBS unterstützt Client-Side Encryption mit einem 256-bit AES-Key pro Datastore. Der Key wird auf dem PBS-Client erzeugt und liegt dort, das PBS-Server-System sieht nur verschlüsselte Chunks. Praxis:

proxmox-backup-client key create /etc/pve/priv/pbs-encryption.key

Diese Datei muss ausserhalb des Backup-Targets sicher abgelegt werden. Ohne sie ist das Backup unwiederherstellbar — auch nicht durch Proxmox Server GmbH. Wir empfehlen: Key-File in Vaultwarden hochladen + Bankschließfach-Kopie ausdrucken (Hex- oder Base64-Dump).

Restic — Repo-Passphrase. Restic verschlüsselt jedes Repository mit einer Passphrase. Aus der Passphrase wird ein Master-Key abgeleitet, der wiederum die Daten-Keys verschlüsselt. Restic unterstützt mehrere Passphrases pro Repo (restic key add) — das ist sehr praktisch für Team-Setups:

restic -r s3:s3.example.com/bucket key add

Jedes Team-Mitglied oder jeder Service-Account bekommt eigene Passphrase. Wenn ein Mitarbeiter ausscheidet, wird seine Passphrase mit restic key remove widerrufen — ohne dass das Repo komplett neu verschlüsselt werden muss. Siehe auch Restic: verschlüsselte Backups und Restic REST-Server für zentralisiertes Backup.

TrueNAS — Dataset-Encryption. TrueNAS verschlüsselt ZFS-Datasets entweder mit Passphrase oder mit Key-File. Der entscheidende Punkt: Der Schlüssel darf nicht auf demselben TrueNAS liegen, das er verschlüsselt. Empfehlung:

• Dataset-Schlüssel als JSON-File exportieren (zfs key export)
• JSON-Datei in externen Tresor (Vaultwarden, KeePass) hochladen
• TrueNAS auf Unlock-on-Boot konfigurieren nur, wenn die Boot-Konsole physisch gesichert ist; sonst manueller Unlock nach Reboot

Für Replikation zwischen TrueNAS-Systemen lässt sich der Schlüssel mit übertragen (zfs send -w) — damit bleibt der Zielpool ebenfalls verschlüsselt, ohne dass die Daten zwischendurch entschlüsselt werden. Siehe TrueNAS-Replikation mit ZFS-Encryption-Keys.

GoBD und DSGVO: Aufbewahrungsfristen für Schlüssel

Ein Punkt, der bei Audits regelmäßig auftaucht: Schlüssel müssen mindestens so lange aufbewahrt werden wie die verschlüsselten Daten. Wenn das Finanzamt nach acht Jahren Buchhaltungsdaten verlangt und das Backup ist da, aber der Schlüssel ist drei Jahre vorher gelöscht worden — formal sind die Daten nicht mehr lesbar und das ist ein GoBD-Problem.

Konkrete Empfehlungen:

• Schlüssel-Aufbewahrungsplan dokumentieren (welcher Schlüssel, welche Aufbewahrungsfrist, wann gelöscht)
• Im Tresor alte Schlüssel klar markieren (“ARCHIV — Aufbewahrung bis 31.12.2034”)
• Bei DSGVO-Lösch-Anforderungen (“Recht auf Vergessen”): wenn die Daten in verschlüsselten Backups liegen und der Schlüssel pseudonym wäre, ist das ein Sonderfall, der mit dem Datenschutzbeauftragten zu klären ist

Fazit

Verschlüsselte Backups sind 2026 Standard und richtig — aber sie sind nur so robust wie das Schlüsselmanagement. Drei Mindestanforderungen aus unserer Sicht:

1. Mindestens zwei Kopien jedes Master-Keys, davon eine offline (Papier, Bankschließfach)
2. Tresor außerhalb der Backup-Infrastruktur (Vaultwarden, KeePass, Vault — nicht auf dem TrueNAS, das verschlüsselt wird)
3. Recovery-Test mindestens einmal jährlich, mit echtem Wiederherstellungsversuch ohne den Hauptverantwortlichen

Wer das hat, übersteht nicht nur Ransomware und Hardware-Ausfälle, sondern auch Personalwechsel und langfristige Compliance-Prüfungen. DATAZONE hilft beim Aufbau des passenden Schlüssel-Konzepts für PBS, Restic und TrueNAS-Umgebungen — pragmatisch und für KMU-Realitäten dimensioniert.