Was die Verschlüsselung einer gemieteten Festplatte tatsächlich bringt
Ein Server hat zwei Zustände, und die Festplattenverschlüsselung hat nur zu einem davon etwas zu sagen. Ausgeschaltet ist das Volume Chiffretext: Der Speicher enthält Bytes, die ohne den Schlüssel nicht von Rauschen zu unterscheiden sind. Laufend ist das Volume gemountet, was bedeutet, dass der Master-Key abgeleitet, in den Kernel-Speicher geladen und dort belassen wurde, solange die Maschine läuft. Jede Datei, die das Betriebssystem lesen kann, kann es lesen, weil dieser Schlüssel resident ist. Die Verschlüsselung hat nicht aufgehört zu funktionieren — sie tut lediglich genau das, wozu sie aufgefordert wurde.
Das ist eine engere Garantie, als das Marketing suggeriert, und sie lohnt sich trotzdem, weil die Ereignisse, die sie abdeckt, genau die sind, die tatsächlich passieren. Eine Platte wird ausgemustert und weiterverkauft. Eine defekte NVMe geht mit Ihren Daten darauf im RMA-Verfahren an den Hersteller zurück. Ein Node wird heruntergefahren und seine Platten werden abgezogen. Ein Backup-Archiv verlässt das Gebäude auf einem Medium, das niemand verschlüsselt hat. Jemand mit physischem Zugang zu einem Rack nimmt versehentlich das Falsche mit. Das ist unspektakulär, und es macht die überwältigende Mehrheit realer Vorfälle aus — weit häufiger als die Razzia an einer laufenden Maschine, die jeder vor Augen hat.
| Szenario | Maschinenzustand | Hilft LUKS? | Was ist exponiert |
|---|---|---|---|
| Platte ausgemustert, weiterverkauft oder per RMA zurückgegeben | Aus | Ja, vollständig | Chiffretext und der LUKS-Header |
| Node heruntergefahren, Platten abgezogen | Aus | Ja | Chiffretext, Partitionslayout, Klartext-/boot |
| Backup-Archiv extern kopiert | k. A. | Nur wenn das Archiv selbst verschlüsselt ist | Was auch immer das Archiv enthält, im Klartext |
| Live-Sicherung einer laufenden Instanz | Laufend | Praktisch nein | Alles — der Schlüssel liegt im RAM |
| Kompromittierung des laufenden Systems | Laufend | Nein | Alles, was das gemountete Volume preisgibt |
Der Hypervisor sitzt in Ihrem Bedrohungsmodell, und Verschlüsselung entfernt ihn nicht
Auf einem VPS ist Ihr Kernel ein Gast. Wer auch immer den Hypervisor betreibt, hält den Speicher dieses Gastes so in der Hand, wie Sie den Inhalt einer Datei halten, und dazwischen liegt kein kryptografischer Schritt. virsh dump schreibt das RAM einer laufenden Domain als Routinevorgang in eine Datei; Live-Migration kopiert genau diesen Speicher konstruktionsbedingt über das Netzwerk, weil genau das Migration bedeutet. Ein LUKS-Master-Key, der im Gast-Speicher liegt, ist in all dem enthalten.
Der ehrliche Satz lautet also: Full-Disk-Encryption auf einem VPS schützt Ihre Daten vor jedem außer der Partei, die den Hypervisor betreibt — und auch vor dieser Partei, aber nur solange die Maschine aus ist. Jeder Hoster, der behauptet, die Verschlüsselung Ihrer Gast-Platte mache Ihre Daten für ihn auf einer laufenden Instanz unlesbar, beschreibt eine Maschine, die nicht existiert. Wir schreiben das lieber so hin, als Sie etwas Bequemeres vermuten zu lassen.
Wenn der Anbieter tatsächlich Teil Ihres Bedrohungsmodells ist, lautet die Antwort nicht: eine stärkere Chiffre. Sie lautet: den Hypervisor entfernen. Ein Dedicated Server lässt Ihren Kernel auf dem Blech laufen, sodass das Auslesen seines Speichers bedeutet, die Maschine physisch in der Hand zu haben und einen DMA- oder Cold-Boot-artigen Angriff gegen das RAM zu fahren — langsam, laut und einen Zugriffslevel voraussetzend, den eine routinemäßige Anfrage nicht verschafft. Der VPS-versus-Dedicated-Guide beschreibt, wo sich dieser Wechsel auch aus anderen Gründen lohnt. Confidential-Computing-Erweiterungen wie AMD SEV-SNP und Intel TDX zielen genau auf diese Lücke, sind auf gemieteten VPS heute aber keine Massenware und verlagern das Vertrauen zum CPU-Hersteller, statt es zu beseitigen.
Drei Arten, es zu betreiben, und was jede davon kostet
In der Praxis gibt es drei Ausprägungen, und sie tauschen Sicherheit gegen den Schmerz Ihrer Reboots. Ein verschlüsseltes Root, über die Konsole entsperrt, ist die stärkste und die lästigste: Ohne einen Menschen übersteht nichts einen Reboot. Ein verschlüsseltes Root mit einem SSH-Server im initramfs bietet dieselbe Sicherheit mit einem Remote-Unlock und ist das, was die meisten Leute bauen sollten. Ein verschlüsseltes Datenvolume auf einem Klartext-Root ist die bequeme Option und diejenige, die leise enttäuscht.
Sie enttäuscht, weil ein Klartext-Root Ihre Geheimnisse sammelt, ob Sie das wollten oder nicht. Das systemd-Journal schreibt dorthin. Ebenso die Shell-History, der Paketcache, Core-Dumps, /tmp, Dockers Standard-Datenroot und — der Fall, der fast jeden erwischt — Swap, wohin der Speicher eines Prozesses wandert, wenn die Box unter Druck steht. /var/lib/mysql zu verschlüsseln, während Swap direkt daneben unverschlüsselt liegt, ist keine teilweise Verteidigung, sondern eine vollständige Verteidigung mit einem Loch in der Mitte.
| Setup | Unlock | Übersteht einen unbeaufsichtigten Reboot | Ehrliches Urteil |
|---|---|---|---|
| Verschlüsseltes Root, Konsolen-Unlock | KVM-over-VNC oder IPMI | Nein — bleibt unten, bis ein Mensch entsperrt | Am stärksten; passt für eine Maschine, die Sie selten rebooten |
| Verschlüsseltes Root, dropbear im initramfs | SSH zum Unlock-Port | Nein — aber Sie können von überall entsperren | Der sinnvolle Standard |
| Verschlüsseltes Datenvolume, Klartext-Root | Skript oder manuell nach dem Boot | Ja | Schwach, sofern Swap, Logs und Temp nicht behandelt werden |
| Verschlüsseltes Root, Key-File auf Klartext-/boot | Automatisch | Ja | Schützt nur gegen eine weiterverkaufte Platte und sonst nichts |
Ein verschlüsseltes Root installieren, Schritt für Schritt
1. Einen Installer booten, kein Template. Ein vorgefertigtes Image kann Ihnen kein verschlüsseltes Root liefern, weil die Platte geschrieben wurde, bevor Sie als Kunde existierten. Jeder BitVPS-Plan unterstützt Rebuild-from-ISO, den Upload einer eigenen ISO und Netboot, und jeder Plan enthält eine KVM-over-VNC-Notfallkonsole — das ist der Teil, der zählt, denn Sie müssen einen Installer beobachten, der Fragen stellen wird. Dedicated Server bieten dieselbe Möglichkeit über einen VPN-gesicherten IPMI-Endpunkt mit ISO-Mount und BIOS-Zugriff.
2. Mit einem kleinen Klartext-Boot-Bereich partitionieren. Eine kleine Partition für /boot oder die EFI-System-Partition, alles andere in einen einzigen LUKS-Container. Bootloader und initramfs müssen lesbar sein, bevor irgendein Schlüssel existiert, also bleibt diese Partition für jeden lesbar, der die Platte abzieht. Planen Sie darum herum, statt so zu tun, als wäre das anders.
3. Den Container erstellen. cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/vda2. LUKS2 mit argon2id ist der eigentliche Punkt: argon2id ist memory-hard, spezifiziert in RFC 9106, und es macht einen Offline-Guessing-Angriff in Hardware teuer statt nur in Software langsam — der Unterschied zwischen einer GPU-Farm, die sich durch Ihre Passphrase frisst, und einer GPU-Farm, für die sich das nicht lohnt. Halten Sie die Speicherkosten innerhalb dessen, was die Maschine beim frühen Boot allokieren kann; auf einer 4 GB Instanz wird ein Wert, der auf Ihrem 64 GB Laptop abgestimmt wurde, das Entsperren schlicht scheitern lassen.
4. Öffnen und installieren. cryptsetup open /dev/vda2 cryptroot, dann LVM oder ein Dateisystem direkt auf /dev/mapper/cryptroot, dann den Distributions-Installer damit gegen /boot auf der Klartext-Partition laufen lassen. Debian, Ubuntu, Alpine, Arch, Rocky, Fedora und FreeBSD kommen alle damit klar; die dm-crypt-Seiten des Arch-Wikis sind die vollständigste Referenz, unabhängig davon, welche Distribution Sie tatsächlich einsetzen.
5. Einen SSH-Server ins initramfs einbauen. Installieren Sie dropbear-initramfs, legen Sie Ihren Public Key in /etc/dropbear/initramfs/authorized_keys ab und fügen Sie der Kernel-Command-Line einen ip=-Parameter hinzu, damit das Interface hochkommt, bevor die Passphrase abgefragt wird. Lassen Sie diesen Parameter weg, haben Sie eine Maschine gebaut, die zu einem Prompt bootet, den niemand erreichen kann.
6. Neu bauen und rebooten. update-initramfs -u backt den Server, Ihren Schlüssel und die Netzwerkeinstellungen in das Image, das der Bootloader lädt. Dann bei geöffneter Konsole rebooten, denn der erste Versuch ist derjenige, der schiefgeht.
7. Entsperren und die Übergabe bestätigen. Per SSH zum Unlock-Port verbinden und cryptroot-unlock ausführen. Das initramfs präsentiert einen anderen Host-Key als das installierte System, sodass Ihr Client bei der ersten Verbindung lautstark warnt — das ist korrektes Verhalten und ein nützliches Signal, kein Hindernis: Pinnen Sie diesen Fingerabdruck als eigenen known_hosts-Eintrag, statt die Host-Key-Prüfung abzuschalten. Dass die Session abbricht, ist Ihr Zeichen, dass das echte System übernommen hat.
Remote-Unlock, und die 04:00-Uhr-Frage, die niemand zuerst stellt
Betreiben Sie den initramfs-SSH-Server auf einem eigenen Port — 2222 ist üblich —, damit die beiden Host-Keys nie im selben known_hosts-Eintrag kollidieren. Bevorzugen Sie ein statisches ip= gegenüber DHCP: Das initramfs ist eine minimale Umgebung, und ein fehlschlagender DHCP-Roundtrip lässt Sie mit einer Maschine zurück, die läuft, unerreichbar ist und an einem Prompt hängt. Wenn Sie sich auf IPv6 verlassen, prüfen Sie, ob Ihr initramfs es tatsächlich konfiguriert; mehrere Distributionen bringen an dieser Stelle noch immer nur v4 hoch.
Behalten Sie die Konsole als Fallback, auch nachdem der SSH-Unlock funktioniert. Der Fehler, auf den Sie irgendwann stoßen werden, ist kein kryptografischer, sondern ein Kernel-Update, das das initramfs ohne Ihren Schlüssel neu gebaut hat, oder ein Netzwerkparameter, der sich unter Ihnen geändert hat — und in diesem Moment ist der einzige Weg hinein die KVM-over-VNC-Konsole, die zum Plan gehört. Beide zu haben ist keine Redundanz, es ist der Unterschied zwischen einer Unannehmlichkeit und einem Neuaufbau.
Dann die betriebliche Frage, die Sie klären sollten, bevor Sie irgendetwas davon bauen: Ein verschlüsseltes Root bedeutet, dass ein unbeaufsichtigter Reboot Ihren Dienst so lange offline lässt, bis ein Mensch entsperrt. Node-Wartung, ein Kernel-Panic, ein Stromereignis — die Maschine kommt zu einem Prompt zurück, nicht zu Ihrer Anwendung. Wenn das für den Workload nicht akzeptabel ist, übertünchen Sie es nicht mit einem Key-File auf der Klartext-Boot-Partition. Das ist ein Schloss mit dem Schlüssel, der an die Tür geklebt ist, und es schützt nur gegen eine weiterverkaufte Platte und sonst nichts. Wählen Sie es bewusst, wenn Sie wollen, aber halten Sie in Ihrem eigenen Runbook fest, dass Sie sich dafür entschieden haben.
Alles, was rund um das verschlüsselte Volume durchsickert
Selten geht beim Volume selbst etwas schief. Schief geht es beim Material, das es nie hineingeschafft hat.
| Leck | Warum es passiert | Fix |
|---|---|---|
| Swap | Prozessspeicher — einschließlich Schlüssel — fließt unter Druck auf die Platte | Swap innerhalb des Containers, oder ein Swap-Device mit Zufallsschlüssel, oder gar keins |
| Hibernation-Image | Ein vollständiger RAM-Dump, der konstruktionsbedingt auf die Platte geschrieben wird | Auf einem Server deaktivieren; hat dort nichts verloren |
| Klartext-/boot und initramfs | Muss lesbar sein, bevor irgendein Schlüssel existiert | Akzeptieren, und jede Änderung als Kompromittierung behandeln — verifizieren oder, wo verfügbar, Secure Boot nutzen |
| Journal vor dem Mount geschrieben | Frühe Boot-Logs landen auf der Klartext-Partition | Prüfen, wo Ihr Journal tatsächlich liegt, bevor das Volume öffnet |
| Docker-Datenroot | Standardmäßig /var/lib/docker, außerhalb eines angeflanschten Datenvolumes | Nach innen verschieben, oder stattdessen das Root verschlüsseln |
| Externes Monitoring und Logging | Agenten senden Dateiinhalte im Klartext an Dritte | Prüfen, was der Agent sendet, bevor Sie dem Volume vertrauen |
Eine Eigenschaft, über die Klarheit herrschen sollte, weil sie regelmäßig übertrieben verkauft wird: Ein LUKS-Header kündigt sich selbst an. Jeder, der die Platte abzieht, sieht, dass ein verschlüsselter Container vorhanden ist, welche Chiffre er benutzt, die KDF-Parameter und wie viele Key-Slots belegt sind. LUKS gibt Ihnen Vertraulichkeit, keine plausible Abstreitbarkeit, und ein Plan, der darauf setzt, dass niemand den Container bemerkt, ist auf Sand gebaut.
Passphrasen, Key-Files und getrennte Header
Die Passphrase ist das gesamte System. Argon2id macht jeden Versuch teuer, aber teuer multipliziert mit einem kleinen Keyspace ist immer noch billig: Fünf oder sechs Wörter aus einer Diceware-Liste schlagen ein elfstelliges Passwort mit Ersetzungen darin, und zwar nicht knapp. Stimmen Sie die Kosten mit --iter-time auf die Maschine ab, die das Volume tatsächlich entsperren wird, nicht auf die, an der Sie gerade tippen, und verwenden Sie niemals eine Passphrase wieder, die auch nur in der Nähe eines KYC-Accounts war.
Ein Key-File erspart das Tippen und verlagert das Problem: cryptsetup luksAddKey fügt einen in einen freien Slot ein, und die einzige Version, die etwas taugt, ist die, die niemals auf dem Server liegt — aufbewahrt auf Ihrer eigenen Maschine oder einem Hardware-Token und über die SSH-Session an den Unlock übergeben. Ein getrennter Header (--header) geht noch weiter: Das Datengerät wird von Zufallsbytes ununterscheidbar, weil die Metadaten woanders liegen. Die Kehrseite ist gnadenlos. Geht der Header verloren, ist das Volume unwiederbringlich weg, ohne jede Möglichkeit — nehmen Sie cryptsetup luksHeaderBackup also ernst und bewahren Sie dieses Backup irgendwo selbst verschlüsselt auf. Die vorgelagerte cryptsetup-FAQ und die dm-crypt-Dokumentation des Kernels sind die beiden Referenzen, die sich zu lesen lohnen, bevor Sie sich auf ein Layout festlegen.
Und eine Regel ohne Ausnahmen: Die Passphrase gehört in kein Support-Ticket. Nicht in unseres, in niemandes. Nichts, was wir tun, erfordert sie, keine Operation, die wir für Sie durchführen können, braucht sie, und ein Ticket ist ein schriftlicher Eintrag in einer Datenbank. Fragt ein Hoster Sie jemals danach, ist das das Ende des Gesprächs.
Was eine abgezogene Platte tatsächlich preisgibt
Nehmen wir den ausgeschalteten Fall konkret, denn Vagheit hilft hier niemandem. Ein Ermittler mit einem Image Ihrer Platte hat: den Chiffretext, den LUKS-Header mit seiner Chiffre, den KDF-Parametern und der Slot-Anzahl, die Partitionstabelle, die Größen von allem, und die gesamte Klartext-Boot-Partition — Ihren Kernel, Ihr initramfs und die Änderungszeitstempel jeder Datei darin. Letzteres ist aufschlussreicher, als man denkt. Paket-Installationszeiten skizzieren eine Zeitlinie, und ein initramfs, das einen dropbear-Schlüssel enthält, sagt etwas darüber aus, wie die Maschine administriert wurde.
Was er nicht hat, ist der Inhalt. Gegen einen modernen LUKS2-Container mit argon2id und einer echten Passphrase ist der Offline-Angriff keine Frage des längeren Wartens — er steht schlicht nicht zur Debatte. Das ist das gesamte Wertversprechen, und es ist ein gutes.
Der laufende Fall ist das Gegenteil und lässt sich kurz fassen: alles. Nicht, weil die Verschlüsselung versagt hat, sondern weil der Schlüssel resident ist — genau die Bedingung, unter der ein gemountetes Dateisystem überhaupt funktioniert.
Snapshots liegen dazwischen und überraschen Leute. Unsere stündlichen Snapshots mit 7-day-Retention arbeiten auf Blockebene, ein verschlüsseltes Volume wird also als Chiffretext gesichert — gut, und der Haken dabei trifft ebenso zu: Auch dieser Snapshot ist ohne die Passphrase für niemanden lesbar, Sie eingeschlossen. Verlieren Sie den Schlüssel, sind die Snapshots genauso unwiederbringlich wie das Original. Planen Sie einen Restore-Pfad, der die Passphrase einschließt, sonst haben Sie sieben Tage sehr zuverlässiges Rauschen gebaut. Was wir außerhalb des Volumes über Sie speichern, steht in der Privacy Policy, und wir veröffentlichen wöchentlich einen PGP-signierten Warrant Canary als stehenden Beleg statt als Versprechen.
Die Teile, die über den Ausgang entscheiden, sind nicht kryptografisch
Niemand hat Daten verloren, weil AES-256-XTS versagt hat. Sie verlieren sie, weil die Passphrase von einem Exchange-Account wiederverwendet wurde, bei dem der Reisepass hinterlegt war, weil das Key-File auf der Klartext-Boot-Partition liegen gelassen wurde, damit Reboots ruhig verlaufen, weil das Off-Site-Backup ein einfaches Tarball war, weil die Passphrase in der Shell-History des Laptops steht, oder weil ein Monitoring-Agent die ganze Zeit Dateiinhalte an ein SaaS gesendet hat.
Und der leise: Ein Server, der nie aus ist, verbringt sein ganzes Leben in dem Zustand, in dem nichts davon hilft. Eine Instanz mit 400 Tagen Uptime war 400 Tage lang entschlüsselt. Wenn die Daten wirklich kalt sind — ein Archiv, ein Key-Backup, Unterlagen, die Sie zweimal im Jahr konsultieren —, bewahren Sie sie in einem Container auf, den Sie bei Bedarf öffnen und nach Gebrauch mit cryptsetup close wieder schließen. Zehn Sekunden Tippen verwandeln eine dauerhafte Exponierung in eine momentane, und diese Umwandlung ist mehr wert als jeder Parameter, den Sie an luksFormat übergeben können.
Wenden Sie dieselbe Logik gleich auch auf die Jurisdiktion an. Verschlüsselung entscheidet, was lesbar ist; wo die Maschine steht, entscheidet, wer fragen darf, und durch welche Allianzen die Anfrage reist. Die beiden sind keine Ersatzstücke füreinander, und wer das richtig macht, behandelt sie als eine einzige Entscheidung.
Was wir bereitstellen, und was wir nicht können
Jeder Plan ab dem $8.50 Starter liefert das, was ein verschlüsseltes Root tatsächlich braucht: KVM-Virtualisierung mit vollem Root, die Möglichkeit, eigene ISOs zu booten und Netboot zu nutzen, Rebuild-from-ISO aus dem Panel, das Laden von Kernel-Modulen und eine KVM-over-VNC-Notfallkonsole für den Moment, in dem das initramfs nicht zurückkommt. Dedicated-Tiers ergänzen einen VPN-gesicherten IPMI-Endpunkt mit Konsole, Power-Cycle, ISO-Mount und BIOS-Zugriff. An der Verschlüsselung ist nichts ein Produkt, das wir Ihnen verkaufen — es ist etwas, das Sie bauen, und unser Job ist es, nicht im Weg zu stehen.
Was wir nicht können, ist nützlicher festzuhalten. Auf einem laufenden VPS kann der Hypervisor den Gast-Speicher lesen; das ist die Architektur, keine Policy-Einstellung, und keine Verschlüsselung, die Sie innerhalb des Gastes installieren, ändert daran etwas. Was wir dagegen bieten, ist keine Mathematik, sondern Haltung und Beleg: kein Netflow, kein PCAP, kein NIC-Mirroring, Panel-Session-IPs nach 24 Stunden gelöscht, kein KYC bei der Anmeldung, sodass der Account kein Hebel ist, ausschließlich Krypto-Zahlung, sodass auch die Abrechnungsspur keiner ist, und ein wöchentlicher PGP-signierter Canary, den Sie selbst prüfen können. Nur Dedicated Hardware entfernt den Hypervisor aus dem Bild, und nur das Herunterfahren entfernt das RAM daraus.
Wenn sich das für bestimmte Bedrohungsmodelle wie ein Argument gegen unseren eigenen VPS liest, dann ist es das auch. Wir verkaufen Ihnen lieber zweimal das Richtige als einmal das Falsche. Deployen Sie eine Instanz mit einer ISO und probieren Sie die Installation einen Monat lang auf einem Starter aus; stellt sich Blech als die Antwort heraus, starten die Dedicated-Tiers bei $39.50 und brauchen zwei bis vier Stunden für die Bereitstellung statt 41 Sekunden.
