Disk-Krypto und Backups: VeraCrypt, LUKS und eine Belastbare 3-2-1-Strategie

Eine verschluesselte Maschine zu verlieren ist aergerlich. Das verschluesselte Backup der verschluesselten Maschine zu verlieren beendet das Projekt. Der Unterschied zwischen beiden Szenarien ist meist eine zweispaltige Tabelle: wo der Schluessel heute liegt und wer schon einmal eine Wiederherstellung daraus probiert hat. Bei Basilisk OffSec laufen quartalsweise Wipe-and-Restore-Uebungen auf unseren Research-Workstations, und fast jede Iteration deckt ein vergessenes Detail auf: LUKS-Header ohne Backup, Passphrase-Drift zwischen Tresoren, ein Restic-Snapshot, der auf einen laengst rotierten Bucket zeigt. Disk-Verschluesselung und Backup sind keine getrennten Themen; sie sind dasselbe Zahnrad, das sich in entgegengesetzte Richtungen dreht.

Unter Linux bleibt LUKS2 mit Argon2id 2026 die Standardwahl. Nutzen Sie `cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 /dev/nvme0n1p3` fuer aggressive KDF-Kosten auf moderner Hardware, und ueberspringen Sie nie `cryptsetup luksHeaderBackup` in eine 16-MiB-Datei auf einem getrennten physischen Medium. Diese Datei trennt eine nutzbare verschluesselte Platte von einem Zufallsziegel, falls Sektor null der Partition korrumpiert. Wir kombinieren das mit per `systemd-cryptenroll` versiegeltem TPM2 fuer passwortlosen Boot auf vertrauenswuerdigen Stationen, behalten aber einen Recovery-Slot mit 6-Wort-Diceware-Passphrase. Mehr zu dieser Schichtverteidigung in Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen.

VeraCrypt kommt ins Spiel, wenn wir portable Container oder plausible Deniability brauchen. Eine 50-GiB-`.hc`-Datei mit verstecktem Volume ist nach wie vor der unauffaelligste Weg, Engagement-Evidenz durch einen Flughafen zu tragen, solange Sie verstehen, dass plausible Deniability nur funktioniert, wenn die Gegenseite die Praemisse akzeptiert. Fuer ganze Disks unter Windows bevorzugen wir BitLocker mit TPM plus PIN und VeraCrypt nur fuer Sekundaerpartitionen oder USB-Sticks, die zwischen Linux und Windows geteilt werden. Wir dokumentieren jeden Trade-off im Rahmen unseres persoenlichen OPSEC-Prozesses, verbunden in OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell und in der OS-Auswahl in Tails, Whonix oder Qubes OS: Welches fuer Welches OPSEC-Szenario.

Die klassische 3-2-1-Strategie lautet drei Kopien, zwei verschiedene Medien, eine offsite. 2026 fahren wir ein 3-2-1-1-0: die vierte Kopie ist immutable (S3 Object Lock oder Backblaze B2 mit Hold), und die Null bedeutet null Fehler in der letzten Verifikation. Unsere Pipeline nutzt Restic mit AES-256-verschluesseltem Repo, taegliche Snapshots auf ein Synology-NAS im Rack, woechentliche Replikation auf eine USB-HDD in einem Off-Site-Tresor und monatliche Replikation auf Backblaze B2 mit sieben Jahren Retention und Object Lock Governance. Der Restic-Schluessel wird mit 256 Bit Entropie generiert, per SLIP39 in 3 von 5 Shards geteilt und auf physischen Tresor, Hardware-Wallet und vertrauenswuerdigen Anwalt verteilt, ein Prozess aehnlich dem in Private Krypto: Hardware Wallets, Passphrase und Zwangsresistentes Backup.

Verschluesseln reicht nicht: ein nicht getestetes Backup existiert nicht. Jeden ersten Freitag im Monat reissen wir eine Research-VM ab, bauen sie aus dem aktuellsten Restic-Snapshot neu und stoppen die Zeit bis zur Einsatzbereitschaft. RTO-Ziel: 90 Minuten fuer eine Pentest-Workstation mit Custom-Tooling. Zur Integritaetspruefung laufen `restic check --read-data-subset=10%` woechentlich und ein voller `restic check --read-data` quartalsweise. Logs gehen in unser internes Elastic und werden mit einfachen Sigma-Regeln korreliert, eine Idee, die wir in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel vertiefen. Schlaegt eine Pruefung fehl, oeffnen wir ein Incident-Ticket wie bei einem produktiven IOC.

Achten Sie auf die Anti-Pattern, die uns in Beratungen staendig begegnen: LUKS-Header-Backup innerhalb derselben verschluesselten Disk; Restic-Schluessel im Klartext unter `~/.config`; Time-Machine-Snapshot auf ein NAS ohne At-Rest-Verschluesselung; Replikation auf privates Google Drive, die als Offsite gilt. Jedes davon war bereits ein echter Postmortem bei einem Kunden. Faustregel: koennen Sie nicht am Whiteboard die komplette Schluesselkette vom Plaintext bis zum kaeltesten Medium zeichnen und benennen, wer physischen Zugriff auf jedes Glied hat, dann leckt Ihr Threat Model.

Zum Schluss etwas Konkretes: blocken Sie dieses Wochenende zwei Stunden, fahren Sie `cryptsetup luksHeaderBackup` gegen jede verschluesselte Platte, die Sie betreuen, generieren Sie eine frische Diceware-Passphrase und legen Sie den Header auf einem verschluesselten USB-Stick an einer anderen Adresse ab. Spielen Sie danach Ihr juengstes Backup testweise in eine Wegwerf-VM zurueck und messen Sie die Dauer. Wenn Sie nicht wiederherstellen konnten oder es laenger als zwei Stunden dauerte, haben Sie kein Backup, sondern Hoffnung. Krypto- und Backup-Hygiene ist genau die stille Arbeit, die entscheidet, ob ein Incident als witzige Anekdote in der Retro endet oder als arbeitsgerichtliches Verfahren.