LUKS2-Backup-Volumes: Schlüsselwechsel und lesende Wiederherstellung

Die Backup-Dateien sind gespeichert, und das empfangende Konto ist bereits isoliert. Ob sich die Daten auf ausgemusterten Datenträgern oder in Offline-Kopien dennoch direkt lesen lassen, ist jedoch eine eigene Sicherheitsfrage. Volume-Verschlüsselung schützt Daten, solange das Volume nicht entsperrt ist; sie ersetzt keine Zugriffskontrolle im laufenden Betrieb. Ein Passphrasenwechsel kann alte Passphrasen ungültig machen, aber keinen bereits erfolgten Datenabfluss rückgängig machen. Dieser Artikel übt den Schlüsselwechsel und die Wiederherstellung mit LUKS2 in einem separaten Dateicontainer. Bestehende Datenlaufwerke bleiben unberührt.

1. Zuerst den Schutzumfang der Verschlüsselung festlegen

Dedicated Server von OnuCloud sind standardmäßig mit zwei direkt angebundenen 1TB NVMe-Laufwerken ausgestattet, ohne Hardware-RAID. Volume-Verschlüsselung, Datenträgerredundanz und externe Backups lösen unterschiedliche Probleme: Verschlüsselung schränkt das Offline-Auslesen ein, Redundanz fängt Geräteausfälle ab, und externe Backups stellen unabhängige Kopien bereit. Beide Laufwerke zu verschlüsseln erzeugt nicht automatisch ein wiederherstellbares Backup.

Das folgende Beispiel verwendet Ubuntu Server 24.04 LTS. Benötigt werden Administratorrechte, cryptsetup, e2fsprogs und etwa 256 MiB tatsächlich verfügbarer Speicherplatz. Installieren Sie zunächst die benötigten Werkzeuge über die Paketverwaltung der Distribution und öffnen Sie anschließend eine dedizierte Administrator-Shell. Führen Sie alle weiteren Befehle in derselben Shell aus, damit die gesetzten Variablen erhalten bleiben.

Ein entsperrtes Volume bleibt für Prozesse mit den entsprechenden Berechtigungen lesbar. Volume-Verschlüsselung verhindert weder den Missbrauch von Administratorrechten noch sorgt sie automatisch dafür, dass eine Kopie einer laufend beschriebenen Datenbank anwendungskonsistent ist.

Vor dem produktiven Einsatz muss geklärt sein, wer die Passphrasen verwahrt, wer Header-Backups lesen darf und wie Zugänge bei personellen Änderungen entzogen werden. Schreiben Sie Passphrasen weder in Befehlsargumente noch in Skripte oder den Text von Support-Tickets.

2. Ein Übungsvolume ohne Zugriff auf echte Datenträger anlegen

mktemp erstellt ein separates Arbeitsverzeichnis. Sämtliche Formatierungsbefehle richten sich ausschließlich an die darin neu angelegte Datei. Prüfen Sie vor der Ausführung, dass der Mapping-Name backup-drill noch nicht verwendet wird. Falls er bereits existiert, brechen Sie ab und klären Sie die Ursache; schließen Sie kein unbekanntes Mapping. Das Beispiel fragt die Passphrasen interaktiv ab und legt die anfängliche Passphrase in Slot 0 ab.

umask 077
work=$(mktemp -d /var/tmp/luks-drill.XXXXXX)
image="$work/backup.img"
mountpoint="$work/mnt"
mkdir "$mountpoint"
truncate -s 256M "$image"
cryptsetup luksFormat --type luks2 --key-slot 0 "$image"
cryptsetup open "$image" backup-drill
mkfs.ext4 /dev/mapper/backup-drill
mount /dev/mapper/backup-drill "$mountpoint"
printf 'backup-recovery-check\n' > "$mountpoint/probe.txt"
(
  cd "$mountpoint"
  sha256sum probe.txt
) > "$work/expected.sha256"
sync
umount "$mountpoint"
cryptsetup close backup-drill

Führen Sie den nächsten Befehl erst aus, wenn der vorherige erfolgreich abgeschlossen wurde. Insbesondere dürfen Sie nach einem fehlgeschlagenen Entsperren nicht mit der Formatierung fortfahren. Ersetzen Sie den Dateipfad auch niemals durch einen ungeprüften NVMe-Gerätenamen. Die nominelle Größe einer Sparse-Datei entspricht nicht ihrem tatsächlichen Platzbedarf. Prüfen Sie deshalb auch während der Übung, ob auf dem zugrunde liegenden Dateisystem genügend Speicherplatz verfügbar ist.

Die Prüfsummenliste liegt außerhalb des Containers, damit sie bei der Wiederherstellung als unabhängige Referenz dienen kann. Auch im Produktivbetrieb muss diese Liste aus einer vertrauenswürdigen Quelle stammen. Können Daten und Prüfsummenliste gemeinsam manipuliert werden, belegen übereinstimmende Hashwerte allein keine vertrauenswürdige Herkunft.

3. Zuerst den neuen Slot prüfen, dann die alte Passphrase entfernen

Führen Sie zunächst cryptsetup luksDump "$image" aus. Vergewissern Sie sich, dass der Typ LUKS2 ist, Slot 0 aktiviert und Slot 1 frei ist. Bei einem echten Volume kann die Slot-Belegung anders aussehen; übernehmen Sie die Nummern daher nicht ungeprüft. Beim folgenden Hinzufügen einer neuen Passphrase geben Sie zuerst die alte Passphrase zur Autorisierung ein und legen anschließend nach Aufforderung die neue fest.

cryptsetup luksAddKey --key-slot 1 "$image"
cryptsetup open --test-passphrase --key-slot 1 "$image"
cryptsetup luksDump "$image"

Geben Sie beim zweiten Befehl die neue Passphrase ein. Die Prüfung gilt nur dann als erfolgreich, wenn der Exit-Code 0 lautet. --test-passphrase prüft lediglich das Entsperren und erstellt kein Mapping; der Einhängezustand des Dateisystems bleibt daher unverändert. Das Hinzufügen eines Slots ersetzt weder den Volume-Schlüssel noch verschlüsselt es sämtliche Daten neu.

Entfernen Sie Slot 0 erst, nachdem sichergestellt ist, dass die neue Passphrase von den berechtigten Personen sicher verwahrt wird. Autorisieren Sie das Entfernen in dieser Übung mit der neuen, beibehaltenen Passphrase:

cryptsetup luksKillSlot "$image" 0
cryptsetup open --test-passphrase "$image"

Geben Sie beim letzten Befehl zunächst die alte Passphrase ein; der Versuch muss fehlschlagen. Führen Sie den Befehl anschließend erneut aus und geben Sie die neue Passphrase ein; dieser Versuch muss erfolgreich sein. Verdecken Sie Fehler nicht durch automatische Wiederholungen und erklären Sie den Wechsel nicht allein anhand der Slot-Liste für abgeschlossen. Der Prüfnachweis sollte die Änderungen an der Slot-Belegung und die Ergebnisse beider Tests enthalten, nicht aber die Passphrasen selbst.

4. Auch Header-Backups sind sensibles Zugangsmaterial

Der LUKS-Header enthält wesentliche Metadaten für das Entsperren. Ist der Datenbereich noch vorhanden, der Header aber beschädigt, kann ein Header-Backup die Voraussetzung für eine Wiederherstellung sein. Es ist keine Datenkopie und darf erst recht nicht zusammen mit dem einzigen Datenvolume verloren gehen. Exportieren Sie nach dem erfolgreichen Wechsel den aktuellen Header:

cryptsetup luksHeaderBackup "$image" \
  --header-backup-file "$work/header-current.bin"
chmod 600 "$work/header-current.bin"
cryptsetup luksDump "$image" > "$work/luks-layout.txt"

Verzeichnis- und Dateiberechtigungen beschränken lediglich den lokalen Zugriff. Produktive Header-Backups gehören an einen kontrollierten, separaten Aufbewahrungsort. Dokumentieren Sie das zugehörige Volume, den jeweiligen Wechselvorgang und die berechtigten Personen und stellen Sie eine eindeutige Zuordnung zu den Datenkopien her. Versenden Sie Header-Dateien nicht wie gewöhnliche Diagnoseanhänge.

Besondere Aufmerksamkeit erfordern ältere Versionen: Ein alter Header kann bereits entfernte Slots enthalten. Wird er wiederhergestellt, kann damit auch die alte Passphrase erneut gültig werden. Das Entfernen eines alten Slots auf dem aktuellen Volume bedeutet deshalb nicht, dass sämtliche Zugriffsmöglichkeiten über historische Unterlagen ebenfalls entzogen wurden. Betrifft die Bedrohung einen offengelegten Volume-Schlüssel, reicht ein bloßer Passphrasenwechsel nicht aus. In diesem Fall muss eine Neuverschlüsselung oder Migration gesondert geplant werden.

5. Die lesende Wiederherstellung bis zum Dateiinhalt prüfen

Das Übungsvolume wurde sauber ausgehängt. Sie können nun erneut ein schreibgeschütztes Mapping anlegen und das ext4-Dateisystem schreibgeschützt sowie ohne Journal-Wiedergabe einhängen. Diese beiden Schutzebenen begrenzen das Verhalten des Blockgeräts und des Dateisystems jeweils separat.

cryptsetup open --readonly --key-slot 1 "$image" backup-drill
mount -t ext4 -o ro,noload /dev/mapper/backup-drill "$mountpoint"
findmnt -no SOURCE,FSTYPE,OPTIONS "$mountpoint"
(
  cd "$mountpoint"
  sha256sum -c "$work/expected.sha256"
)
touch "$mountpoint/should-not-exist"

Nach Eingabe der neuen Passphrase müssen die Mount-Optionen ro enthalten, die Prüfsummenprüfung muss erfolgreich sein und der abschließende Schreibversuch muss fehlschlagen. Gelingt das Schreiben dennoch, brechen Sie die Abnahme sofort ab und prüfen Sie das tatsächliche Mount-Ziel. Behandeln Sie dies nicht als nebensächliche Abweichung. noload ist nicht dazu geeignet, einen unsauberen Dateisystemzustand zu kaschieren. Bei einer nicht ordnungsgemäß ausgehängten Kopie sollten Sie zunächst das Original sichern und mögliche Reparaturen an einer Arbeitskopie beurteilen.

Hängen Sie zum Abschluss zuerst das Verzeichnis aus und schließen Sie danach das Mapping. Vergewissern Sie sich, dass weder Mounts noch Mappings zurückgeblieben sind, bevor Sie das Übungsverzeichnis bereinigen. Produktive Unterlagen werden dagegen nach den festgelegten Aufbewahrungsregeln verwaltet und nicht im Rahmen der temporären Bereinigung entfernt.

Die abschließende Dokumentation muss vier Fragen beantworten: Kann die neue Passphrase das Volume eigenständig entsperren? Ist die alte Passphrase ungültig? Wird das Header-Backup kontrolliert aufbewahrt? Stimmen die wiederhergestellten Dateien mit der vertrauenswürdigen Prüfsummenliste überein? Erst wenn alle vier Prüfungen bestanden sind, liegt eine nachvollziehbare Übung zum Schlüsselwechsel und zur Wiederherstellung vor.

Häufig gestellte Fragen