Full-Disk-Verschlüsselung auf einem VPS

Full-Disk-Verschlüsselung beantwortet genau eine Frage: Was bekommt ein Angreifer in die Hand, wenn er Ihren Speicher besitzt und die Maschine ausgeschaltet ist? Jede andere Frage, die Sie haben könnten — was der Anbieter sehen kann, was passiert, wenn ein laufender Server beschlagnahmt wird, ob Ihre Backups sicher sind — hat eine andere Antwort, und wer sie alle in einen Topf wirft, endet mit einer Verschlüsselung, die gar nichts schützt.

Diese Unterscheidung verdient es, unverblümt ausgesprochen zu werden, denn „LUKS-verschlüsselt" steht auf jeder Privacy-Hosting-Seite dieser Branche, unsere eingeschlossen. Es ist eine echte Schutzmaßnahme, kostet im Betrieb fast nichts und ist zugleich die im Hosting am meisten überstrapazierte Schutzmaßnahme. Dieser Leitfaden behandelt, was Verschlüsselung ruhender Daten auf einem gemieteten Server tatsächlich verhindert, die drei Konstellationen, die sich lohnen, samt den Befehlen für jede, die zwei Einstellungen, die auf einem kleinen VPS wirklich zählen, sowie die Handvoll Fehler, die aus der ganzen Übung Dekoration macht.

Wovor Verschlüsselung ruhender Daten tatsächlich schützt

Verschlüsselung ruhender Daten bedeutet, dass die Bytes auf dem Speichermedium Chiffretext sind, solange das Volume geschlossen ist. Das ist eine eng gefasste Aussage, und ihr Wert hängt von einer einzigen Variable ab: wo sich der Schlüssel befindet, wenn der Angreifer eintrifft.

Lesen Sie das als Definition, nicht als Enttäuschung. Die Klasse von Risiken durch ein entwendetes Laufwerk auszuschließen, ist eine Stunde Arbeit wert — gerade weil es die Klasse ist, gegen die Sie sonst kein Mittel haben, und die eintritt, ohne dass irgendjemand Sie gezielt ins Visier nimmt: Hardware fällt aus und wird zurückgeschickt, Arrays werden ausgemustert, Volumes werden dem nächsten Mieter neu zugewiesen. Verschlüsselung macht all das zu einem Nicht-Ereignis.

Warum ein VPS kein Laptop ist

Bei einem Laptop liegt das Design auf der Hand. Sie tippen beim Start eine Passphrase ein, der Schlüssel existiert nur im RAM, solange die Maschine wach ist, und mit dem Herunterfahren ist die Geschichte zu Ende. Bei einem Server sitzt niemand an der Konsole. Irgendetwas muss den Schlüssel bei jedem Start liefern, und jeder Kandidat für dieses „Irgendetwas" tauscht Verfügbarkeit gegen Schutz:

• Ein Mensch tippt ihn ein. Die stärkste Variante, weil der Schlüssel niemals auf der Maschine ruht — aber der Server kommt nach einem Neustart nicht ohne Sie zurück, und Sie brauchen einen Weg hinein, bevor das Betriebssystem überhaupt existiert.
• Die Maschine hält ihn selbst. Bequem, und in den meisten selbstgebauten Setups selbstzerstörerisch: Eine Schlüsseldatei auf derselben virtuellen Festplatte bedeutet, dass jeder, der die Festplatte hat, auch den Schlüssel hat.
• Eine andere Maschine gibt ihn heraus. Netzwerkgebundene Entsperrung, meist Clevis mit einem Tang-Server. Der Server entsperrt sich nur, solange er einen Host erreichen kann, den Sie kontrollieren — eine echt nützliche Eigenschaft, und eine Verlagerung von Vertrauen, keine Beseitigung.

Es gibt einen zweiten Unterschied, den die meisten Leitfäden übergehen. Auf einem VPS liegen /boot und das initramfs im Klartext, sie befinden sich auf Speicher, den letztlich der Anbieter kontrolliert, und es gibt keine Boot-Kette, die Sie überprüfen können — kein TPM, das Ihnen gehört, kein Measured Boot, nichts zu bezeugen. Ein Anbieter, der Ihre Passphrase haben wollte, könnte das initramfs verändern und sie beim nächsten Entsperren mitschneiden. Das ist keine Beschreibung dessen, was wir tun; es ist eine Beschreibung dessen, was die Architektur zulässt, und das ist die einzige ehrliche Art, über einen gemieteten Computer nachzudenken. Unser Vergleich zwischen VPS und dediziertem Server geht dieselbe Vertrauensgrenze von der Hardware-Seite aus durch, und unsere ehrliche Antwort zur Offshore-Anonymität wendet dieselbe Disziplin auf das Marketing dazu an.

Die drei Konstellationen, die sich lohnen

Es gibt nicht das eine richtige Setup — es gibt dasjenige, dessen Fehlermodus Sie ertragen können. Diese drei decken im Grunde jeden realen Fall ab.

Beginnen Sie mit der ersten, sofern Sie keinen besonderen Grund dagegen haben. Sie liefert den Großteil des Schutzes bei einem Bruchteil des Betriebsrisikos und besitzt die eine Eigenschaft, die den beiden anderen fehlt: Nichts daran kann verhindern, dass der Server wieder online geht. Konstellation drei ist die einzige, bei der die Passphrase eine Tatsache ist, an die der Anbieter nicht herankommt, statt ein Versprechen, das der Anbieter gibt — weshalb unsere dedizierten Server LUKS bei der Installation einrichten, mit einer Passphrase, die wir nie zu Gesicht bekommen.

Ein Datenvolume auf einem laufenden VPS verschlüsseln

Das ist die Konstellation, zu der Sie zuerst greifen sollten. Nichts wird neu installiert, am Bootvorgang ändert sich nichts, und wenn Ihnen ein Fehler unterläuft, ist das schlimmste Ergebnis eine Container-Datei, die Sie wegwerfen. Fünfzehn Minuten auf einem laufenden Debian- oder Ubuntu-Server.

• Das Werkzeug installieren. apt install cryptsetup. Wenn Ihr Plan Ihnen ein zweites Block-Gerät gegeben hat, verwenden Sie es direkt und überspringen Sie den nächsten Schritt.
• Einen Container anlegen. Auf einem VPS mit nur einer Festplatte ist eine Datei der praktische Weg: fallocate -l 40G /var/lib/vault.img. Sie verhält sich wie eine Festplatte und kann später vergrößert werden.
• Als LUKS2 formatieren. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Übernehmen Sie die Standardwerte für die Chiffre; der Abschnitt weiter unten behandelt den einen Parameter, an dem es sich auf einem kleinen Server lohnt zu drehen.
• Öffnen und ein Dateisystem anlegen. cryptsetup open /var/lib/vault.img vault liefert Ihnen /dev/mapper/vault; dann mkfs.ext4 /dev/mapper/vault und mount /dev/mapper/vault /srv/vault.
• Die Daten, die zählen, verschieben und dann Dienste darauf zeigen lassen. Ein Bind-Mount oder ein rsync bei gestopptem Dienst ist meist sauberer als Symlinks — Datenbanken mögen es besonders wenig, wenn man sie herumverfolgt.
• Den LUKS-Header sichern. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, dann diese Datei vom Server wegbewegen. Ein paar beschädigte Kilobyte am Anfang des Containers zerstören jedes Byte dahinter, dauerhaft, und das ist die einzige Versicherung, die es dafür gibt.
• Schließen und beweisen, dass Sie wieder hineinkommen. umount /srv/vault && cryptsetup close vault, dann öffnen Sie ihn erneut anhand Ihrer Notizen statt aus dem Gedächtnis. Tun Sie das, bevor irgendetwas Wertvolles darin liegt.

Nach einem Neustart bleibt der Tresor verschlossen, bis Sie sich anmelden und ihn öffnen. Das ist keine Einschränkung, die man wegkonstruieren sollte — das ist der ganze Sinn der Sache. Ein Volume, das sich selbst öffnet, ist ein Volume, dessen Schlüssel auf der Maschine liegt.

Vollständige Root-Verschlüsselung mit Fernentsperrung über SSH

Wenn die Anforderung lautet, dass nichts Lesbares eine Beschlagnahmung im ausgeschalteten Zustand übersteht — Logs, Shell-Verlauf, Paketlisten, die Form dessen, was Sie betreiben —, muss auch das Root-Dateisystem in den Container. Das Problem wird dann, eine Passphrase in eine Maschine zu bekommen, die noch nicht gebootet hat, und die Antwort ist ein winziger SSH-Server, der im initramfs lebt.

• Von Anfang an verschlüsselt installieren. Booten Sie den Distributions-Installer über den Upload einer benutzerdefinierten ISO und wählen Sie geführte Partitionierung mit verschlüsseltem LVM. Ein laufendes Root-Dateisystem nachträglich zu konvertieren ist möglich, aber das Risiko nicht wert.
• Den Pre-Boot-SSH-Server hinzufügen. apt install dropbear-initramfs, dann Ihren öffentlichen Schlüssel in /etc/dropbear/initramfs/authorized_keys eintragen. Das ist ein eigener Schlüsselsatz, getrennt von Ihrem normalen SSH — verwenden Sie einen dedizierten Schlüssel.
• Absichern. Setzen Sie in /etc/dropbear/initramfs/dropbear.conf DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": keine Passwort-Logins, keine Portweiterleitung, ein eigener Port, und ein Idle-Timeout, damit eine hängende Sitzung den Bootvorgang nicht offenhält.
• Dem initramfs ein Netzwerk geben. Fügen Sie einen statischen ip=-Parameter zu GRUB_CMDLINE_LINUX in /etc/default/grub hinzu — die Form lautet ip=address::gateway:netmask::interface:off. Sich an dieser Stelle auf DHCP zu verlassen ist der Weg, auf dem Menschen ausgesperrt enden.
• Neu bauen und neu starten. update-initramfs -u && update-grub, dann neu starten und mit ssh -p 2222 root@your-server verbinden und cryptroot-unlock ausführen. Ihr Client wird vor einem unbekannten Host-Schlüssel warnen: Das initramfs hat seinen eigenen, das ist zu erwarten, und es lohnt sich, ihn in einem separaten known_hosts-Eintrag zu pinnen.
• Den Fehlerpfad testen, bevor Sie sich darauf verlassen. Installieren Sie ein Kernel-Update, starten Sie neu, entsperren Sie erneut. Kernel-Upgrades erzeugen das initramfs neu, und genau dann zeigt sich eine Fehlkonfiguration.

Die zwei Einstellungen, die zählen, und die Falle beim kleinen VPS

LUKS2 verwendet standardmäßig AES-XTS mit einem 512-Bit-Schlüssel und Argon2id-Schlüsselableitung. Beides ist richtig. Die Chiffre von Hand nachzujustieren ist ein Weg, gleichzeitig langsamer und schwächer zu werden, und das Internet ist voller kopierter Befehlszeilen, die genau das tun. Zwei Dinge verdienen jedoch Ihre Aufmerksamkeit.

Performance ist kein Thema — bis sie es ist

Prüfen Sie Hardwarebeschleunigung mit grep -m1 -o aes /proc/cpuinfo und messen Sie mit cryptsetup benchmark. Auf jeder CPU mit AES-NI — und das ist jeder Node, den wir betreiben — bewegt AES-XTS mehrere Gigabyte pro Sekunde und Kern, komfortabel über dem, was eine einzelne virtuelle Festplatte liefert, sodass die spürbaren Kosten bei starker I/O-Last wenige Prozent CPU und ein kleiner Latenzanstieg sind. Ohne AES-NI kehrt sich das Bild um, und Verschlüsselung wird zum Flaschenhals; das ist der einzige Fall, in dem eine andere Chiffre eine echte Entscheidung ist und kein Cargo-Kult.

Der Argon2id-Speicher ist es, der zubeißt

Argon2id ist bewusst speicherhungrig, und cryptsetup kalibriert ihn beim Formatieren anhand des RAM der Maschine, auf der Sie gerade formatieren. Formatieren Sie ein Volume auf einer 32-GB-Workstation und verschieben Sie es auf einen 1-GB-VPS, kann das Entsperren komplett fehlschlagen, weil der von der Schlüsselableitung verlangte Speicher schlicht nicht vorhanden ist — noch schlimmer innerhalb eines initramfs, wo weit weniger verfügbar ist als in einem laufenden System. Pinnen Sie ihn auf kleinen Instanzen fest: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb deckelt ihn bei 256 MB. Weniger ist eine echte Verringerung der Widerstandsfähigkeit gegen Offline-Brute-Force, gleichen Sie das also mit einer längeren Passphrase aus.

Ein optionales Flag verdient eine bewusste Entscheidung statt Copy-Paste: --allow-discards reicht TRIM an das darunterliegende Gerät durch, was gut für SSD-Verschleiß und die Dauerleistung ist, aber auch offenbart, wie viel des Volumes in Benutzung ist und ungefähr wo. Standardmäßig ist es aus. Schalten Sie es ein, im Wissen, was es preisgibt.

Swap, Logs, Snapshots — die Teile, die man vergisst

Ein verschlüsselter Tresor, um den herum Klartext sickert, ist der häufigste Fehler von allen, und er bleibt unsichtbar, bis jemand genau hinsieht.

• Swap. Alles im Arbeitsspeicher kann auf die Festplatte ausgelagert werden, einschließlich des Materials, das Sie sorgfältig in den Tresor gelegt haben. Deaktivieren Sie Swap entweder ganz, oder geben Sie ihm bei jedem Start einen zufälligen Schlüssel mit einer /etc/crypttab-Zeile wie swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Alles, was dorthin schreibt, wo Sie nicht hingesehen haben. /var/log, /tmp, das Datenverzeichnis der Datenbank, /var/lib/docker, Shell-Verlauf, systemd-Journale. /srv/vault zu verschlüsseln, während PostgreSQL nach /var/lib/postgresql schreibt, erreicht genau gar nichts. Erst aufzählen, dann verschlüsseln.
• Snapshots. Ein Snapshot eines verschlüsselten Volumes auf Blockebene ist Chiffretext und daher unbedenklich. Ein Snapshot, der den Speicherzustand erfasst, ist ein völlig anderes Objekt und kann den Schlüssel enthalten. Wissen Sie, welche Art Ihr Anbieter-Panel erstellt, bevor Sie es verwenden.
• Backups. Das Ziel ist der falsche Ort, um das zu lösen. Werkzeuge wie restic und BorgBackup verschlüsseln an der Quelle mit einem Schlüssel, den das Ziel nie zu sehen bekommt — weshalb ein Backup-Server eine gewöhnliche Maschine in einer anderen Jurisdiktion sein kann statt einer vertrauenswürdigen.
• Der Klartext, den Sie bereits irgendwohin geschickt haben. Verschlüsselung ruhender Daten wirkt nicht rückwirkend. Alles, was bereits kopiert, gemailt oder anderswohin synchronisiert wurde, liegt außerhalb der Grenze, die Sie jetzt ziehen.

Wo der Schlüssel lebt, ist das ganze Design

Jede Konstellation oben ist im Grunde eine Aussage über die Verwahrung des Schlüssels. Es gibt vier Optionen, und sie sind nicht gleichwertig:

• In Ihrem Kopf, bei jedem Start eingetippt. Maximaler Schutz, maximale Betriebsreibung. Die Maschine kann ohne Sie schlicht nicht gelesen werden.
• In einer Datei auf der verschlüsselten Maschine. Schützt gegen einen naiven Weiterverkauf der Festplatte und gegen nichts sonst. Liegt diese Datei auf dem Klartext-/boot, schützt sie vor gar nichts — der mit Abstand häufigste Fehler bei selbstgehosteter Verschlüsselung.
• Auf einer Maschine, die Sie kontrollieren, über das Netzwerk geholt. Clevis, gebunden an einen Tang-Server: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. Der Server startet unbeaufsichtigt, solange er sein Zuhause erreichen kann, und verweigert die Entsperrung überall sonst. Ausgezeichnet für Flotten ohne Konsole, und es macht den Tang-Host zu dem Ding, das verteidigt werden muss.
• In einem TPM. Sinnvoll auf Hardware, die Ihnen gehört. Auf einem VPS wird das virtuelle TPM vom selben Hypervisor bereitgestellt, den Sie eigentlich ausschließen wollen — es löst also Bequemlichkeit, nicht Vertrauen.

Ein Test klärt die meisten Designs: Wenn die Maschine ohne Sie einen Login-Prompt erreichen kann, liegt der Schlüssel auf der Maschine. Das kann ein durchaus vernünftiger Kompromiss sein — viele Workloads wollen unbeaufsichtigte Neustarts mehr als Widerstandsfähigkeit gegen einen entschlossenen Angreifer. Treffen Sie die Wahl bewusst, und beschreiben Sie das Ergebnis nicht als etwas, das es nicht ist.

Was Ihr Anbieter sehen kann, und wo die Jurisdiktion übernimmt

Auf einem VPS sitzt ein Hypervisor unter Ihnen. Wir lesen den Arbeitsspeicher des Gasts nicht, und wir führen weder Traffic-, Verbindungs- noch DNS-Logs, keine Konsolen-Spur — aber das sind Richtlinien, und die ehrliche Einordnung ist, dass ein VPS Sie bittet, sich darauf zu verlassen. Bei Bare Metal gibt es keinen Hypervisor zwischen Ihnen und dem Silizium: Full-Disk-Verschlüsselung, bei der Installation eingerichtet mit einer Passphrase, die wir nie erhalten, ist eine physische Eigenschaft der Maschine statt einer Zusicherung von uns. Dieser Unterschied, nicht die Wahl der Chiffre, ist es, zwischen dem Sie wirklich wählen.

Deshalb sind Verschlüsselung und Jurisdiktion zwei Hälften einer Antwort. Verschlüsselung entscheidet, was eine Kopie Ihrer Festplatte wert ist; die Jurisdiktion entscheidet, wer die Maschine zur Herausgabe zwingen kann, über welches Verfahren und wie schnell. Wir betreiben Server in sieben — Island, der Schweiz, Panama, Rumänien, Moldau, den Niederlanden und Russland —, und die Überlegungen zur Wahl zwischen ihnen stehen in unserem Jurisdiktions-Leitfaden, oder in kürzerer Form über den Jurisdiktions-Selektor und die Standorte-Seite.

Der Teil, den Verschlüsselung nicht berühren kann, ist die Zwangsoffenlegung, denn sie zielt auf Sie, nicht auf die Hardware. Das Vereinigte Königreich, Frankreich und Australien gehören zu den Ländern, deren Recht eine Person zwingen kann, einen Entschlüsselungsschlüssel herauszugeben, oder eine Strafe für die Weigerung vorsieht. Diese Gefährdung folgt dem Ort, an dem Sie sich befinden, nicht dem Ort des Servers, und keine Konfiguration auf der Maschine ändert das. Sich ohne Identitätsdokumente anzumelden begrenzt von vornherein, wie viel Papierspur überhaupt entsteht — der praktische, unglamouröse Grund, warum No-KYC-Hosting und Verschlüsselung im selben Gespräch landen — aber es ist kein Schutz vor einem Gericht, das Ihren Namen bereits kennt.

Neun Fehler, die Verschlüsselung zur Dekoration machen

• Automatisches Entsperren aus einer Schlüsseldatei auf derselben Festplatte. Die Mehrheit der „verschlüsselten" Server, und das Äquivalent dazu, den Schlüssel im Schloss stecken zu lassen.
• Ein Volume verschlüsseln, das die sensiblen Daten nie erreichen. Der Tresor ist leer, und die Datenbank ist nicht darin.
• Den LUKS-Header nie sichern. Ein beschädigter Sektor am Anfang des Containers, und jedes Byte dahinter ist für immer verloren.
• Den Entsperrpfad nie testen. Dann erzeugt ein Kernel-Upgrade das initramfs neu, und der nächste Neustart wird zu einer Rettungsaktion.
• Auf einer großen Maschine formatieren und auf einer kleinen entsperren. Argon2id verlangt Speicher, den der VPS nicht bereitstellen kann, und das Volume öffnet sich nicht.
• Eine Passphrase wie ein Login-Passwort wählen. Nichts begrenzt die Rate eines Offline-Angriffs außer der Schlüsselableitungsfunktion. Länge ist es, was Zeit erkauft.
• Klartext in Verschlüsselung migrieren und annehmen, das Original sei weg. Auf virtualisiertem Speicher löscht Überschreiben nicht zuverlässig.
• Die Passphrase über denselben Kanal senden, über den die Maschine administriert wird. Server-OpSec behandelt das dadurch entstehende Korrelationsproblem.
• Die Verschlüsselung des Anbieters mit der eigenen verwechseln. „Die gesamte Infrastruktur ist im Ruhezustand verschlüsselt" — unsere eingeschlossen — schützt die Infrastruktur. Nur ein Schlüssel, den Sie selbst halten, schützt Sie vor der Infrastruktur.

Lohnt sich das also auf einem VPS?

Ja, mit kalibrierten Erwartungen. Für eine Stunde Arbeit und keine messbaren laufenden Kosten entfernt ein verschlüsseltes Datenvolume eine ganze Klasse von Risiken, gegen die Sie sonst kein Mittel haben — und entfernt sie dauerhaft: ausgemusterte Hardware, neu zugewiesener Speicher, eine ausgeschaltete Maschine in fremder Obhut. Tun Sie das auf jedem Server, der irgendetwas Wichtiges enthält, gleich nach der Checkliste für die erste Stunde.

Was es nicht tut, ist einen gemieteten Computer zu Ihrem Computer zu machen. Wenn Ihr Bedrohungsmodell den Anbieter selbst als Angreifer einschließt, behebt keine Chiffre das — die Antwort ist dedizierte Hardware, bei der der Schlüssel über IPMI eingegeben wird und nie durch einen Hypervisor läuft, eine bewusst gewählte Jurisdiktion, und die Disziplin, auf keinen Server zu legen, was dort nicht sein muss. Die Schutzmaßnahme dem tatsächlichen Bedrohungsmodell anzupassen, ist der Unterschied zwischen Privatsphäre und ihrem bloßen Anschein.