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

Ein gestohlener Laptop im Zug, eine beschlagnahmte Festplatte, eine Ransomware, die um 03:12 Uhr alle Netzlaufwerke verschluesselt: drei Szenarien, dieselbe Frage. Kommt jemand an deine Daten, und kommst du selbst nach einem Totalverlust wieder an sie heran? Disk-Krypto und eine belastbare 3-2-1-Backup-Strategie sind die zwei Seiten derselben Medaille: Vertraulichkeit gegen Diebstahl, Verfuegbarkeit gegen Verlust. Dieser Beitrag zeigt konkret, wie du mit LUKS und VeraCrypt verschluesselst, wie du Schluessel wirklich verwaltest und wie du Backups so baust, dass weder ein Dieb noch eine Ransomware noch deine eigene Fehlbedienung dich ruiniert.

Das Bedrohungsmodell zuerst

Verschluesselung ohne Bedrohungsmodell ist Kryptotheater. Full-Disk-Encryption schuetzt Daten at rest: geklaute oder beschlagnahmte Hardware im ausgeschalteten Zustand. Sie schuetzt nicht das laufende System, in dem der Schluessel im RAM liegt, nicht gegen Malware mit Root, nicht gegen einen Cold-Boot-Angriff bei entsperrtem Geraet und nicht gegen Coercion, wenn dich jemand zur Passphrase zwingt. Definiere also klar, gegen wen du dich verteidigst, so wie wir es in OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell herleiten. Aus dem Modell folgt die Wahl: reicht Standard-LUKS, brauchst du versteckte Volumes, brauchst du eine strikte Trennung wie in Tails, Whonix oder Qubes OS: Welches fuer Welches OPSEC-Szenario. Ein haeufiger Denkfehler ist, Vertraulichkeit und Verfuegbarkeit zu verwechseln: Verschluesselung allein rettet keine Daten, die durch eine defekte Platte, einen versehentlichen Loeschbefehl oder eine Ransomware verloren gehen. Umgekehrt schuetzt ein perfektes Backup ohne Verschluesselung nicht davor, dass ein Dieb die Kopie liest. Erst beide Achsen zusammen ergeben eine ehrliche Verteidigung. Notiere pro Szenario, welches der beiden Ziele bedroht ist, und dimensioniere die Massnahme entsprechend, statt reflexhaft ueberall dieselbe Loesung anzuwenden.

LUKS auf Linux richtig aufsetzen

Unter Linux ist LUKS2 der Standard. Beim Anlegen zaehlt die Key-Derivation: cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id /dev/nvme0n1p3. Argon2id ist speicher-hart und bremst Brute-Force massiv aus, anders als das aeltere PBKDF2. Pruefe mit cryptsetup luksDump, dass tatsaechlich argon2id und ein vernuenftiger Memory-Cost aktiv sind. LUKS bietet acht Keyslots: nutze einen fuer die Passphrase, einen fuer ein Keyfile im Safe, einen als Notfall-Recovery, den du offline verwahrst. Rotiere kompromittierte Slots mit luksKillSlot. Fuer Server kombiniere LUKS mit Boot-Hygiene und Least Privilege wie in Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen, sonst schuetzt die verschluesselte Platte ein loechriges laufendes System. Achte darauf, dass die /boot-Partition und der Initramfs Teil deiner Integritaetsbetrachtung sind, denn ein manipulierter Bootloader kann die Passphrase abgreifen (Evil-Maid-Angriff); Secure Boot mit selbst signierten Keys oder ein separat verwahrter Boot-Stick schliessen diese Luecke. Teste nach jeder Aenderung, dass das System noch bootet und entsperrt, bevor du den einzigen funktionierenden Keyslot loeschst. Ein falsch gesetzter Cipher oder ein vergessener zweiter Slot verwandelt Hardening schnell in einen selbstgebauten Denial-of-Service gegen dich selbst.

VeraCrypt, versteckte Volumes und plausible Deniability

VeraCrypt glaenzt plattformuebergreifend (Windows, macOS, Linux) und mit Containern statt ganzer Partitionen. Ein .hc-Container ist eine Datei, die als verschluesseltes Volume gemountet wird, ideal fuer transportable, sensible Datensaetze. Die Killer-Funktion ist das versteckte Volume: innerhalb eines aeusseren Volumes liegt ein zweites, dessen Existenz sich kryptografisch nicht beweisen laesst. Unter Coercion gibst du die Passphrase des aeusseren Volumes preis, das plausible Koederdaten enthaelt, waehrend das versteckte Volume unsichtbar bleibt. Das ist maechtig, aber fehleranfaellig: schreibst du zu viel ins aeussere Volume, ueberschreibst du das versteckte. VeraCrypt ist ausserdem bewusst langsam bei der Ableitung (hohe Iterationszahl), was Brute-Force teuer macht. Waehle eine lange, hochentropische Passphrase, denn keine Iterationszahl rettet ein schwaches Passwort.

Schluesselverwaltung, die haelt

Der Schluessel ist der eigentliche Angriffspunkt, nicht der Algorithmus. Eine Passphrase mit sechs zufaelligen Diceware-Woertern schlaegt jedes clevere, aber kurze Passwort. Trenne Wissen und Besitz: Passphrase im Kopf plus Keyfile auf einem YubiKey oder einem Offline-Stick. Fuer unbeaufsichtigtes Entsperren von Servern bindet man den Schluessel an ein TPM mit PCR-Policy, sodass die Platte nur bootet, wenn die Firmware-Messkette unveraendert ist; Clevis und systemd-cryptenrol automatisieren das. Verwahre einen Recovery-Key physisch getrennt und offline. Die gleiche Coercion-resistente Denke, inklusive Duress-Mechanismen, vertiefen wir in Private Krypto: Hardware Wallets, Passphrase und Zwangsresistentes Backup. Merke: ein verlorener Schluessel ohne Recovery bedeutet garantierten Datenverlust, ein geleakter Schluessel bedeutet garantierte Kompromittierung.

Die 3-2-1-Regel und ihre Erweiterung

Die 3-2-1-Regel ist der Kern jeder belastbaren Strategie: drei Kopien deiner Daten, auf zwei verschiedenen Medientypen, davon eine ausser Haus. Konkret: die Live-Daten, ein lokales Backup auf einer anderen Platte oder einem NAS, und eine geografisch getrennte Kopie in einem verschluesselten Cloud- oder Offsite-Ziel. Die moderne Erweiterung heisst 3-2-1-1-0: die zusaetzliche Eins steht fuer ein offline oder unveraenderliches (immutable) Exemplar, die Null fuer null Fehler in verifizierten Wiederherstellungen. Genau diese eine Offline-Kopie ist der Unterschied zwischen ueberleben und untergehen, wenn Ransomware jedes erreichbare Laufwerk verschluesselt. Ein Backup, das die Ransomware mitverschluesseln kann, ist kein Backup, sondern eine zweite Geisel. Denke die drei Kopien zudem als Schutz gegen unterschiedliche Fehlerklassen: die lokale Kopie deckt schnelle Wiederherstellung bei versehentlichem Loeschen, der andere Medientyp deckt einen Controller- oder Firmware-Defekt, der die ganze Platten-Charge betrifft, und die Offsite-Kopie deckt Feuer, Diebstahl und Beschlagnahme des Standorts. Wer alle drei Kopien am selben Ort und auf demselben Medientyp haelt, hat streng genommen nur eine Kopie mit drei Namen.

Backups verschluesseln mit restic und borg

Backup-Software muss clientseitig verschluesseln, bevor die Daten das Geraet verlassen. restic und BorgBackup tun genau das: Deduplizierung plus Verschluesselung, sodass das Ziel (S3, ein fremder Server, eine externe Platte) nur Chiffrat sieht. Mit restic legst du ein Repo mit restic init an, sicherst mit restic backup /daten und prunest mit einer Retention-Policy wie --keep-daily 7 --keep-weekly 4 --keep-monthly 12. Der Repo-Schluessel wird nie zum Provider hochgeladen, das ist entscheidend, wenn das Offsite-Ziel nicht vertrauenswuerdig ist. Borg bietet Aehnliches mit borg init --encryption=repokey-blake2. Beide erlauben, das Backup-Ziel als potenziell feindlich zu behandeln, was der einzig gesunde Standard fuer Offsite-Kopien ist.

Unveraenderliche und offline Backups gegen Ransomware

Die entscheidende Frage bei Ransomware lautet: kann der kompromittierte Host seine eigenen Backups zerstoeren? Wenn ja, hast du keine. Mach mindestens eine Kopie unveraenderlich oder physisch offline. In der Cloud setzt du S3 Object Lock im Compliance-Modus oder Backblaze-B2-Immutability, sodass selbst gestohlene Credentials Objekte nicht vor Ablauf der Aufbewahrungsfrist loeschen koennen. Lokal rotierst du zwei externe Platten, von denen immer eine im Schrank liegt und physisch getrennt ist. Ergaenze append-only Repos (restic ueber einen rest-server mit --append-only), damit ein kompromittierter Client zwar schreiben, aber nicht loeschen kann. Ungewoehnliche Massenloeschungen oder Verschluesselungswellen erkennst du frueh mit Detektion im Stil von Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel.

Restore-Tests, sonst hast du kein Backup

Ein Backup, das nie wiederhergestellt wurde, ist eine Hoffnung, kein Backup. Plane regelmaessige Restore-Drills: stelle eine zufaellige Datei, dann einen ganzen Ordner, dann ein komplettes System in einer VM wieder her und vergleiche Hashes. Mit restic pruefst du die Repo-Integritaet via restic check --read-data-subset=10% und uebst die echte Wiederherstellung mit restic restore latest --target /restore-test. Dokumentiere die Wiederherstellungszeit (RTO) und den maximal tolerierbaren Datenverlust (RPO), damit im Ernstfall niemand raten muss. Die Null in 3-2-1-1-0 steht genau dafuer: null Fehler in einer verifizierten Wiederherstellung. Ohne diesen Test entdeckst du das kaputte Backup ausgerechnet in der Nacht, in der du es brauchst.

Haeufige Fehler

Fuenf Fallen sehen wir immer wieder. Erstens: schwache Passphrase auf starker Krypto, was den ganzen Aufwand zunichtemacht. Zweitens: der Schluessel liegt neben den Daten, etwa das Keyfile auf derselben unverschluesselten Partition. Drittens: Backups im selben Vertrauensbereich, sodass ein Angreifer mit Zugriff sie gleich mitloescht. Viertens: nie getestete Restores, die im Ernstfall an einem vergessenen Passwort oder einem korrupten Repo scheitern. Fuenftens: unbedachtes Fuellen des aeusseren VeraCrypt-Volumes, das das versteckte ueberschreibt. Jede dieser Fallen verwandelt eine scheinbar sichere Strategie in eine Illusion. Die gute Nachricht: alle fuenf lassen sich mit Disziplin statt mit teurer Technik vermeiden.

Praktische Checkliste

Erstens: LUKS2 mit argon2id, per luksDump verifiziert. Zweitens: Passphrase aus mindestens sechs Diceware-Woertern, getrennt von einem Keyfile im Besitz. Drittens: sensible Transportdaten in VeraCrypt-Containern, bei Coercion-Risiko mit verstecktem Volume. Viertens: 3-2-1 einhalten, erweitert zu 3-2-1-1-0 mit einer offline oder unveraenderlichen Kopie. Fuenftens: Backups clientseitig mit restic oder borg verschluesseln, Ziel als feindlich behandeln. Sechstens: Object Lock oder append-only gegen Ransomware. Siebtens: Retention-Policy setzen und prunen. Achtens: monatlicher Restore-Drill mit Hash-Vergleich, RTO und RPO dokumentiert. Neuntens: Recovery-Key offline und physisch getrennt verwahren. Wer diese neun Punkte lebt, ueberlebt Diebstahl, Beschlagnahme und Ransomware gleichermassen.

FAQ

Reicht Full-Disk-Encryption allein? Nein. Sie schuetzt nur Daten at rest. Ein laufendes, entsperrtes System, Malware mit Root oder ein aufgeklappter Laptop mit Schluessel im RAM sind davon nicht gedeckt. Kombiniere Disk-Krypto mit System-Hardening, kurzer Auto-Lock-Zeit und verschluesselten, getrennten Backups.

Cloud-Backup oder eigene Offsite-Kopie? Beides ist legitim, solange clientseitig verschluesselt wird und der Schluessel nie den Provider erreicht. Die Cloud gibt dir einfache Geo-Trennung und Immutability via Object Lock; eine rotierte externe Platte im anderen Gebaeude gibt dir volle Kontrolle. Ideal ist die Kombination aus beidem.

Fazit

Disk-Krypto und Backups loesen zwei verschiedene, gleich wichtige Probleme: Niemand liest deine Daten, und du verlierst sie nie. LUKS2 mit argon2id und VeraCrypt mit versteckten Volumes decken die Vertraulichkeit, eine ehrlich gelebte 3-2-1-1-0-Strategie mit clientseitiger Verschluesselung und mindestens einer unveraenderlichen Offline-Kopie deckt die Verfuegbarkeit. Praktischer Takeaway: verschluessle heute die erste Platte, richte heute das erste restic-Repo mit Offsite-Ziel ein, und mach diese Woche den ersten echten Restore-Test. Sicherheit, die du nie geprobt hast, ist nur ein Geruecht ueber deine eigene Widerstandsfaehigkeit.