Festplattenverschlüsselung auf einer Maschine, die Ihnen nicht gehört

Jeder Anbieter, der Privatsphäre verkauft, behauptet, die Festplatten seien verschlüsselt. Das stimmt meist – und beantwortet meist eine Frage, die niemand gestellt hat. Verschlüsselung kennt drei Zustände, um die man sich sorgen muss, und ein Server verbringt sein gesamtes Arbeitsleben in genau dem einen, den volle Festplattenverschlüsselung nicht abdeckt. Hier verläuft die eigentliche Grenze, das liegt auf jeder ihrer beiden Seiten, und das entscheidet, welches der beiden unter denselben vier Worten verkauften Verfahren dasjenige ist, bei dem Sie selbst den Schlüssel besitzen.

Drei Zustände – und der eine, den niemand verschlüsselt

Daten befinden sich in einem von drei Zuständen, und für zwei davon hat die Branche eine überzeugende Lösung gefunden. Ruhend sind Daten, die auf einer Festplatte liegen, die gerade niemand liest: gelöst durch Festplattenverschlüsselung und durch darüberliegende Datenbank- oder Objektspeicherverschlüsselung. Unterwegs sind Daten, die ein Netzwerk durchqueren: gelöst durch TLS, so gründlich, dass ein fehlerhaft ausgestelltes Zertifikat heute Schlagzeilen macht. In Verwendung sind Daten, die im Arbeitsspeicher eines laufenden Prozesses liegen – und genau dorthin muss jedes Byte, das Ihr Server ausliefert, und sei es nur für einen Augenblick, damit es überhaupt ausgeliefert werden kann.

Der Ausdruck Verschlüsselung im Ruhezustand trifft es genau – und trifft es so genau, dass man leicht darüber hinwegliest. Er beschreibt den Zustand Ihrer Daten, während die Maschine aus ist. Ein Server ist eine Maschine, deren gesamte Aufgabe darin besteht, nicht aus zu sein. In den Monaten, die er im Betrieb verbringt, sind seine Volumes geöffnet, seine Datenbankdateien für jeden Prozess lesbar, der unter dem richtigen Benutzer läuft, und die Verschlüsselung tut nichts weiter, als auf einen Stromausfall zu warten.

Das Zweite, was sich hinter diesen vier Worten verbirgt, ist die Frage, wem der Schlüssel gehört. Unter ihnen werden zwei völlig verschiedene Verfahren verkauft. Ein Anbieter kann die Speicherschicht mit Schlüsseln verschlüsseln, die er selbst verwaltet: Das schützt seinen eigenen Ausmusterungsprozess und verringert sein eigenes Haftungsrisiko bei einem Datenabfluss, und es schützt Sie tatsächlich vor einem Laufwerk, das das Gebäude verlässt – aber die Partei, die den Schlüssel hält, ist genau die Partei, nach der Sie eigentlich gefragt hatten. Oder das Volume wird innerhalb Ihrer eigenen Maschine verschlüsselt, mit einem Schlüssel, der nirgendwo existiert außer in Ihrem Kopf und im Arbeitsspeicher eines laufenden Kernels. Nur das zweite Verfahren ändert, was ein Dritter erlangen kann, und nur das zweite ist gemeint, wenn im Rest dieses Leitfadens von Verschlüsselung die Rede ist.

Nichts davon spricht gegen das Verschlüsseln von Festplatten. Es spricht dafür, zu wissen, welches der acht unten stehenden Szenarien Sie abgedeckt haben und welches nicht. Eine Verschlüsselung, die eine einzige reale Sache verhindert, lohnt sich; eine Verschlüsselung, von der Sie glauben, sie verhindere acht, ist schlimmer als keine – weil dieser Glaube das Gespräch beendet.

Wo der Schlüssel liegt, während die Maschine läuft

Wenn Sie ein LUKS-Volume entsperren, ist die Passphrase, die Sie eingeben, nicht selbst der Schlüssel. Sie entschlüsselt einen Hauptschlüssel, der im Volume-Header gespeichert ist, und dieser Hauptschlüssel liegt dann im Arbeitsspeicher des Kernels, bis das Volume geschlossen wird oder die Maschine den Strom verliert. Jeder Lese- und jeder Schreibvorgang läuft durch ihn hindurch. Es gibt keine Konfiguration einer funktionierenden verschlüsselten Festplatte, bei der der Schlüssel während der Nutzung woanders liegt – das ist kein Implementierungsdetail, das sich beheben ließe, sondern die Bedeutung dessen, eine verschlüsselte Festplatte zu benutzen.

Auf eigener Hardware sitzt dieser Speicher in einem Gehäuse in einem Raum, den Sie kontrollieren, und der Angriff darauf ist exotisch: physische Anwesenheit und die Sekunden an Restladung, die Speicherchips nach dem Abschalten noch halten. Auf einem virtuellen Server unterscheidet sich die Lage nicht graduell, sondern grundsätzlich. Der Arbeitsspeicher Ihres Kernels ist ein Bereich des Arbeitsspeichers des Hosts. Der Hypervisor kann ihn per Definition adressieren, denn genau durch diese Adressierung hat er ihn Ihnen überhaupt erst zugewiesen. Drei ganz gewöhnliche Vorgänge lesen ihn aus:

• Eine Live-Migration. Beim Verschieben einer laufenden virtuellen Maschine zwischen physischen Hosts wird ihr Speicher im laufenden Betrieb mitkopiert. Das ist ein Feature – so wird ein Host gewartet, ohne Sie neu zu starten – und Ihr Hauptschlüssel befindet sich in den kopierten Seiten.
• Ein Snapshot, der den Arbeitsspeicher einschließt. Ein reiner Festplatten-Snapshot eines selbst verschlüsselten Volumes enthält nur Chiffretext und sonst nichts. Ein Snapshot, der die Maschine exakt dort fortsetzen lässt, wo sie stand, enthält auch den Schlüssel – denn der Schlüssel gehört zu dem, was „exakt dort, wo sie stand“ ausmacht.
• Ein Speicherauszug. Der Arbeitsspeicher Ihres Gasts liegt im Adressraum eines Prozesses auf dem Host. Diesen Prozessspeicher auszulesen ist ein routinemäßiger Debugging-Vorgang, und das dafür nötige Werkzeug liegt dem Virtualisierungsstack ohnehin bei, statt eingeschmuggelt werden zu müssen.

Nichts davon behauptet, dass Ihr Anbieter etwas davon tut. Es behauptet, dass diese Vorgänge keine Mitwirkung Ihrerseits erfordern, keine für Sie sichtbare Spur hinterlassen und sich nicht von gewöhnlicher Plattformwartung unterscheiden lassen. Das ist die einzige Eigenschaft, die es wert ist, in ein Bedrohungsmodell aufzunehmen: nicht, was jemand tut, sondern wozu er in der Lage ist, ohne dass Sie es bemerken. Dieselbe Überlegung, eine Schicht weiter außen, ist der Grund, warum die Registry und der Proxy vor Ihnen auf dieselbe Liste gehören wie der Host.

Das Neustart-Problem – und die Abkürzung, die es zunichtemacht

Ein verschlüsseltes Root-Volume muss entsperrt werden, bevor das System weit genug hochfährt, um eine SSH-Verbindung anzunehmen. Auf einem Laptop tippen Sie die Passphrase an der Tastatur ein. Bei einer Maschine zweitausend Kilometer entfernt, in einem Gebäude, das Sie nie betreten haben, gibt es in dem Moment, in dem sie gebraucht wird, keine Tastatur, die Sie erreichen können. Jede praktikable Antwort darauf ist ein Kompromiss – und eine der vier unten ist gar kein Kompromiss, sondern nur der Anschein, einen eingegangen zu sein.

Vier Wege, ein verschlüsseltes Root-Volume auf einer entfernten Maschine zu entsperren

Methode	Unbeaufsichtigter Neustart	Hält eine gestohlene Festplatte auf	Was es Sie kostet
SSH ins Boot-Image	Nein	Ja	Ein minimaler SSH-Server im initramfs erlaubt es Ihnen, sich zu verbinden und die Passphrase einzugeben. Die Maschine bleibt so lange unten, bis ein Mensch wach und erreichbar ist. Das ist die ehrliche Option, und die Kosten sind real: Ein Neustart um vier Uhr morgens ist ein Ausfall, bis ihn jemand bemerkt.
Netzwerkgebundener Schlüssel	Ja	Teilweise	Die Maschine holt sich ihren Entsperrschlüssel beim Booten von einem Server, den Sie anderswo betreiben, und Sie können sich weigern, einer Maschine, die sich bewegt hat oder die Sie nicht selbst neu gestartet haben, einen Schlüssel auszuliefern. Der Schlüsselserver muss dabei erreichbar bleiben, und er muss irgendwo stehen, wo dieselbe Anordnung ihn nicht erreicht – sonst haben Sie den Schlüssel lediglich auf zwei Türen mit demselben Schloss verteilt.
Schlüsseldatei im Boot-Image	Ja	Nein	Der Schlüssel liegt im initramfs, das initramfs liegt auf einer unverschlüsselten Boot-Partition, und die Boot-Partition liegt auf genau der Festplatte, die Sie eigentlich schützen wollten. Wer die Festplatte mitnimmt, nimmt den Schlüssel gleich mit. Diese Konfiguration ist verbreitet, sie bootet tadellos, und sie schützt vor rein gar nichts.
An ein TPM gebunden	Ja	Teilweise	Auf eigener Hardware gibt ein echter Sicherheitschip den Schlüssel nur an eine Boot-Kette frei, die nicht verändert wurde. Auf einem virtuellen Server wird dieser Chip vom Host emuliert, sodass die Bindung des Schlüssels an ihn den Schlüssel genau der Partei aushändigt, vor der Sie ihn eigentlich versiegeln wollten.

Die dritte Zeile verdient einen längeren Blick. Hier landen Sie, wenn die Vorgabe lautete die Festplatten müssen verschlüsselt sein und niemand gefragt hat, wofür. Das Audit besteht die Prüfung. Das Blockgerät ist tatsächlich verschlüsselt. Der Schlüssel reist auf demselben Stück Metall mit, in einer Datei, die eine Recovery-Shell in etwa vier Sekunden ausliest.

Das ist auch der klarste praktische Unterschied zwischen einer gemieteten virtuellen Maschine und einer eigenen. Bei dedizierter Hardware gibt Ihnen die Out-of-Band-Management-Schnittstelle eine Konsole, die einen Neustart übersteht, sodass aus der ersten Zeile kein Ausfall mehr wird, sondern eine zweiminütige Unterbrechung – und das emulierte-Chip-Problem der vierten Zeile verschwindet, weil der Chip auf eine Platine gelötet ist, statt von genau der Partei in Software geschrieben zu werden, vor der Sie sich schützen wollen.

Was volle Festplattenverschlüsselung tatsächlich bringt

Dieselbe Frage, achtmal gestellt. Die Spalte, auf die es ankommt, ist die letzte, denn in jeder Zeile, in der Verschlüsselung nicht hilft, hilft etwas anderes – und genau dieses Andere zu benennen ist der eigentliche Wert der Übung.

Acht Szenarien, und ob volle Festplattenverschlüsselung das Ergebnis ändert

Szenario	Verschlüsselung hilft	Was tatsächlich entscheidet
Ein Laufwerk wird ausgemustert, weiterverkauft oder per Garantie zurückgegeben	Ja	Nichts anderes deckt das ab. Laufwerke verlassen Rechenzentren laufend, Datenlöschung ist ein Prozess, und Prozesse versagen lautlos. Genau für dieses Szenario wurde volle Festplattenverschlüsselung erfunden, und dagegen wirkt sie exakt wie versprochen.
Die Maschine wird abgeschaltet und die Festplatte ausgebaut	Ja	Derselbe Schutz mit derselben Grenze, und diese Grenze ist das Wort aus. Eine Maschine, die im laufenden Betrieb mitgenommen wird, ist eine Maschine, die entsperrt mitgenommen wird – mit offenen Volumes und residentem Schlüssel.
Eine Sicherungskopie liegt anderswo	Teilweise	Verschlüsselung auf dem Quell-Volume nützt einer Kopie der Daten nichts. Entscheidend ist, ob die Sicherung vor dem Verlassen der Maschine verschlüsselt wurde, mit einem Schlüssel, der nicht auf der gesicherten Maschine selbst liegt.
Die Plattform erstellt einen Snapshot	Teilweise	Ein reiner Festplatten-Snapshot eines selbst verschlüsselten Volumes ist Chiffretext und ohne Ihre Passphrase für niemanden zu gebrauchen. Ein Snapshot, der den Speicherzustand erfasst, erfasst den Schlüssel gleich mit. Beides nennt sich Snapshot.
Jemand bekommt eine Shell auf der laufenden Maschine	Nein	Das Volume ist bereits geöffnet, und ein Eindringling liest Dateien, keine Blöcke. Patches, minimale Rechtevergabe und Zugangsdaten, die nicht dienstübergreifend wiederverwendet werden, entscheiden diese Zeile – Verschlüsselung trägt dazu nichts bei.
Der Host-Betreiber, oder wer auch immer dessen Zugriff besitzt	Nein	Nur eine Verschlüsselung, deren Schlüssel die Maschine überhaupt nie erreicht. Speicherverschlüsselung auf Hardware-Ebene ist die einzige Ausnahme, und sie ist überall standardmäßig deaktiviert, wie der nächste Abschnitt zeigt.
Eine Anordnung wird dem Anbieter zugestellt	Teilweise	Der Rechtsraum entscheidet, wer fragen darf und mit welcher Begründung; die Verschlüsselung entscheidet, was eine Antwort überhaupt enthalten könnte. Unsere eigene veröffentlichte Position besteht aus zwei getrennten Sätzen, und beide zählen: Wir besitzen keine Kundenschlüssel und können sie nicht herausgeben, und ein unverschlüsseltes Volume auf einem virtuellen Server erfordert weiterhin eine Anordnung, die genau diesen Dienst benennt.
Sie müssen einen Vorfall melden	Teilweise	Sitzen Ihre Nutzer in der EU, nennt Artikel 32 der DSGVO Verschlüsselung ausdrücklich unter den erwarteten Maßnahmen, und Artikel 34 hebt die Pflicht auf, die betroffenen Personen zu benachrichtigen – niemals die Aufsichtsbehörde –, sofern die Daten unkenntlich gemacht wurden. Ob das zutrifft, hängt einzig davon ab, wo sich der Schlüssel befand, als die Daten die Maschine verließen.

Oberhalb der Festplatte: Was einen feindlichen Host übersteht

Alles bisher Gesagte betrifft eine Schicht, die beim Blockgerät endet. Drei Dinge liegen darüber, und zusammen sind sie die einzigen Antworten auf die fünfte, sechste und siebte Zeile jener Tabelle.

Oberhalb der Anwendung verschlüsseln, nicht darunter

Feldbasierte Verschlüsselung bedeutet, dass die Anwendung einen Wert verschlüsselt, bevor er die Datenbank erreicht, und ihn erst nach dem Auslesen wieder entschlüsselt. Ein Dump der Datenbank liefert Chiffretext, ganz gleich, wer ihn gezogen hat und auf welchem Weg. Das kostet Sie die Möglichkeit, die verschlüsselten Spalten zu durchsuchen oder zu indizieren, weshalb sie sich nur für die wenigen Felder eignet, die es wert sind – Nachrichtentexte, hochgeladene Dokumente, Tokens Dritter – und nicht für alles. Das Ende dieses Wegs ist Ende-zu-Ende-Verschlüsselung: Der Schlüssel gehört dem Nutzer, der Server sieht nie den Klartext, und ein feindlicher Host erhält nichts, weil es dort nichts zu erhalten gibt. Das ist die einzige Architektur auf dieser Seite, der es wirklich gleichgültig ist, wer die Hardware betreibt, und sie ist eine Produktentscheidung, lange bevor sie eine Infrastrukturentscheidung ist.

Sicherungen sind eine eigene Entscheidung, keine Konsequenz

Der häufigste Weg, auf dem Daten eine verschlüsselte Maschine verlassen, ist eine Sicherung. Ein in einen Objektspeicher geschobener Snapshot, ein zu einem zweiten Anbieter synchronisierter Datenbank-Dump, ein auf eine Workstation heruntergeladenes Archiv – keines davon erbt irgendetwas von dem Volume, aus dem es stammt. Verschlüsseln Sie in dem Moment, in dem die Daten in die Sicherung geschrieben werden, mit einem Schlüssel, den die Maschine selbst nicht erreichen kann, damit ein kompromittierter Server nicht seine eigene Geschichte entschlüsseln kann. Stellen Sie dann eine Sicherung testweise auf einer anderen Maschine wieder her, bevor Sie es wirklich brauchen: eine verschlüsselte Sicherung, die sich nicht öffnen lässt, ist eine ungewöhnlich saubere Methode, alles auf einen Schlag zu verlieren. Eine Kopie in einem anderen Land ist zugleich eine Kopie unter einem anderen Regelwerk – ein zweiter Rechtsraum, den Sie unbemerkt gewählt haben.

Speicherverschlüsselung – und warum Sie sie vermutlich nicht haben

Für den Zustand, den niemand verschlüsselt, gibt es tatsächlich eine Hardware-Antwort. Confidential-Computing-Erweiterungen – AMDs SEV-SNP, Intels TDX – verschlüsseln den Arbeitsspeicher und den Registerzustand eines Gasts mit einem Schlüssel, den ein eigener Sicherheitsprozessor hält statt der Hypervisor, sodass ein Host, der den Speicher ausliest, nur Chiffretext bekommt. Das ist real und bereits verfügbar. Es ist aber auch eng begrenzt: SEV-SNP setzt EPYC-Silizium der dritten Generation oder neuer voraus, der Host muss eigens dafür konfiguriert werden, und der Gast muss bestätigen, dass er es tatsächlich erhalten hat. Fast kein Allzweck-VPS bietet das an, und keiner bietet es stillschweigend an. Gehen Sie davon aus, dass Sie es nicht haben, sofern ein Anbieter Ihnen nicht schriftlich das Gegenteil bestätigt und Ihnen erklären kann, wie Sie die Attestierung selbst überprüfen.

Ein Aufbau, der ehrlich zu seinen Grenzen ist

Nichts davon läuft auf lassen Sie es einfach hinaus. Es läuft auf eine Konfiguration hinaus, deren Grenzen Sie laut aussprechen können, ohne zu zögern.

1. Schreiben Sie das eine Szenario auf, gegen das Sie sich absichern (5 Min.). Ein ausgemustertes Laufwerk, eine im Betrieb beschlagnahmte Maschine, ein feindlicher Host, ein Gerichtsbeschluss, ein meldepflichtiger Vorfall. Sie haben unterschiedliche Antworten, und ein Aufbau, der auf alle fünf zielt, erreicht zuverlässig keine davon.
2. Legen Sie die Verschlüsselung dorthin, wo Ihr Schlüssel ist (Entscheidung). Hält der Anbieter den Schlüssel, haben Sie sich Schutz gegen ein Laufwerk erkauft, das das Gebäude verlässt, und nichts darüber hinaus. Wollen Sie mehr, muss das Volume von innerhalb des Gasts entsperrt werden, von Ihnen, mit etwas, das die Plattform nie zu Gesicht bekommt.
3. Verschlüsseln Sie das Datenvolume statt der Root-Partition (Einrichtung). Ein verschlüsseltes Root-Volume bedeutet, dass jeder Neustart auf Sie wartet. Ein separates verschlüsseltes Volume für das Datenbankverzeichnis, die Uploads und die Geheimnisse lässt die Maschine von selbst wieder hochfahren, während der sensible Teil geschlossen bleibt, bis Sie ihn öffnen. Das ist der Kompromiss, den die meisten kleinen Plattformen eingehen sollten, und den fast niemand aufschreibt.
4. Lassen Sie die Schlüsseldatei nie auf der unverschlüsselten Boot-Partition liegen (Regel). Bootet die Maschine unbeaufsichtigt, ohne Schlüsselserver und ohne Konsole, liegt der Schlüssel auf der Festplatte; eine dritte Möglichkeit gibt es nicht. Das ist ein vertretbarer Kompromiss, wenn ein gestohlenes Laufwerk wirklich Ihr gesamtes Bedrohungsmodell ist – und Selbsttäuschung in jedem anderen Fall.
5. Verschlüsseln Sie Sicherungen im Moment des Schreibens, mit einem Schlüssel, der anderswo aufbewahrt wird (Einrichtung). Stellen Sie danach eine davon auf einer anderen Maschine wieder her, an einem Tag, an dem gerade nichts brennt.
6. Formulieren Sie in einem Satz, was Sie abgedeckt haben (5 Min.). Etwa so: Ein Angreifer, der diese Festplatte aus dem Rack zieht, bekommt nichts, und jeder mit Root-Rechten auf der laufenden Maschine oder ihrem Host bekommt alles. Wenn Ihnen dieser Satz unangenehm ist, ihn aufzuschreiben, dann deshalb, weil er wahr ist.

Zwei dieser sechs sind Entscheidungen, vier sind Konfiguration. Die Entscheidungen brauchen einen Nachmittag, die Konfiguration eine Stunde – und die Stunde ist ohne den Nachmittag nichts wert. Wer die Reihenfolge umdreht, landet in der dritten Zeile der ersten Tabelle: mit einer Maschine, die jedes Audit besteht und vor niemandem schützt.

Gegen welches Szenario Sie sich absichern, ist zuerst eine Frage der Bedrohungsmodellierung und erst danach eine Frage der Verschlüsselung, und die Ein-Stunden-Version dieser Übung liefert den Satz aus Schritt sechs fast wie nebenbei. Stellt sich am Ende ein Gerichtsbeschluss statt eines gestohlenen Laufwerks als die eigentliche Frage heraus, entscheidet nicht Ihre Festplatte über den Ausgang – sondern welches Recht Ihren Anbieter erreicht, und wie Sie das prüfen, bevor Sie sich darauf verlassen.

Geschrieben von den Ingenieuren, die die Plattform betreiben, und zuletzt überprüft heute. Wenn hier etwas falsch ist oder veraltet, sagen Sie es über das Kundenpanel — von dort stammt etwa die Hälfte davon.