GPU-Server verschlüsseln: LUKS2 und TPM2, selbstverschlüsselnde NVMe, Modelldateien

Was Festplatten­verschlüsselung auf einem GPU-Server schützt

Einen GPU-Server zu verschlüsseln heißt, seine NVMe-Laufwerke im Ruhezustand zu verschlüsseln, unter Linux meist mit LUKS2 und einem TPM2-Chip, der den Schlüssel beim Start freigibt, sodass die Daten auf einem Laufwerk oder Server, der Ihre Kontrolle verlässt, unlesbar sind. Ein KI-Server in einer Niederlassung, in einem Serverraum ohne Zutrittskontrolle oder in einem Colocation-Rack speichert feingetunte Modelle, Vektorindizes interner Dokumente und Protokolle von Fragen und Antworten. Die Verschlüsselung deckt den Diebstahl eines Laufwerks ab, den Diebstahl des Servers, wenn die Entsperrmethode dafür gewählt ist, ein defektes Laufwerk, das in die Garantie zurückgeht, und die Laufwerke bei der Außerbetriebnahme.

Auf dem laufenden System schützt sie nicht. Ist das Volume entsperrt, lesen Betriebssystem, Inferenz-Engine und jeder mit einer Shell die Daten im Klartext. Angriffe auf BMC, Inferenz-API, Container-Laufzeit oder Modelldateien behandelt unser Leitfaden zum Absichern eines GPU-Servers. Daten im GPU-Speicher während der Verarbeitung sind wieder ein eigenes Thema, das unser Artikel zu Confidential Computing mit H200 NVL und RTX PRO 6000 behandelt. Und wer die Platten des Servers verschlüsselt, verschlüsselt damit nicht seine Backups; unser Leitfaden zum Backup eines KI-Servers behandelt, wohin die Kopien gehen.

Die DSGVO nennt Verschlüsselung als Beispiel einer risikomindernden Maßnahme: Erwägungs­grund 83 spricht von Maßnahmen wie einer Verschlüsselung, und Erwägungs­grund 88 verlangt, dass Regeln zur Meldung von Verletzungen berücksichtigen, ob die Daten durch geeignete technische Schutzmaßnahmen geschützt waren. Ob Ihr Aufbau Ihre Pflichten erfüllt, bestätigt Ihr Datenschutz­beauftragter.

Was auf einem KI-Server zu verschlüsseln ist: Modelle, Indizes, Protokolle

Ein KI-Server speichert mehr sensible Daten, als seine Modelldateien vermuten lassen, und manche davon an Orten, die niemand geplant hat.

Unsere Einordnung; Inhalte von Vektorspeichern und Adaptern wie in unserem Leitfaden zum Backup eines KI-Servers beschrieben.

Ein praktischer Aufbau legt alles Sensible auf ein verschlüsseltes Daten-Volume (Modellspeicher für feingetunte Gewichte, Vektordatenbank, Logs, Traces) und entscheidet über das Betriebssystem-Volume getrennt, weil das Entsperren des Root-Volumes beim Start Unterstützung in der Initramfs braucht. Öffentliche Basisgewichte unverschlüsselt zu lassen hilft nur, wenn sie auf einem eigenen Volume liegen; bei unseren Referenz­konfigurationen mit zwei, vier oder acht NVMe-Laufwerken ist es die einfachere Regel, jedes Datenlaufwerk zu verschlüsseln. Betreibt der Server auch einen Trace-Speicher wie Langfuse oder das Abfrageprotokoll eines Gateways, liegen dort die meisten personenbezogenen Daten, nicht in den Modellen.

Entsperren beim Start: TPM2, PIN oder Netzwerk

Ein verschlüsselter Server braucht bei jedem Start seinen Schlüssel. Eine Person, die eine Passphrase eintippt, reicht für einen Server mit Konsole, nicht aber für einen Server, der nach einem Kernel-Update nachts neu startet. Drei automatische Methoden sind verbreitet, und sie schützen vor verschiedenen Dingen.

Unser Vergleich auf Basis des Handbuchs zu systemd-cryptenroll (systemd 262) und der RHEL-9-Dokumentation von Red Hat zur richtlinienbasierten Entschlüsselung, gelesen am 25. Oktober 2026.

TPM2 allein hält den Schlüssel im TPM-Chip des Servers. Ein ausgebautes Laufwerk ist nutzlos, aber ein gestohlener Server startet und entsperrt sich selbst, und seine Daten sind dann so sicher wie sein Login und seine Dienste. Eine PIN schließt diese Lücke: --tpm2-with-pin=yes verlangt sie zusätzlich zur PCR-Bindung, und die PIN lässt sich über die Remote-Konsole des BMC eingeben, wenn niemand vor Ort ist. Das Handbuch warnt, dass falsche PIN-Eingaben die Sperre des TPM auslösen können. Netzgebundene Festplatten­verschlüsselung (NBDE) mit Clevis und einem Tang-Server, die Red Hat für RHEL 9 dokumentiert, entsperrt das Volume nur, solange der Server den Tang-Server in Ihrem Netz erreicht. Ein Server, der aus der Niederlassung getragen wird, findet ihn nicht mehr und bleibt gesperrt. Tang wird aus dem Paket tang installiert und hört in der Minimalinstallation von Red Hat auf Port 80.

Für einen Server in einem abgeschlossenen Rechenzentrum reicht meist TPM2 mit PCR 7. Für einen Server in einem Büro oder einer Niederlassung, wie in unserem Leitfaden zum GPU-Server im Büro, passt eine PIN oder Tang zum Risiko.

LUKS2 mit TPM2 über systemd-cryptenroll

systemd-cryptenroll fügt einem bestehenden LUKS2-Volume Entsperrmethoden hinzu; es unterstützt nur LUKS2-Volumes, weil es seine Metadaten im JSON-Token-Bereich von LUKS2 ablegt. Die Schritte für ein Daten-Volume auf einem NVMe-Laufwerk:

1. Legen Sie das Volume mit cryptsetup luksFormat --type luks2 und dem Gerät an, mit einer Passphrase. Das Handbuch von cryptsetup überlässt Cipher, Schlüssellänge und Schlüsselableitung den einkompilierten Standardwerten, die cryptsetup --help anzeigt; LUKS2 unterstützt das speicherintensive Argon2.
2. Hinterlegen Sie zuerst einen Recovery-Schlüssel mit systemd-cryptenroll --recovery-key und dem Gerät. Der Befehl erzeugt einen Schlüssel mit hoher Entropie, der sich eintippen oder als QR-Code scannen lässt. Bewahren Sie ihn außerhalb des Servers auf (siehe Recovery-Schlüssel unten).
3. Binden Sie das TPM mit --tpm2-device=auto --tpm2-pcrs=7 und dem Gerät ein. Ohne --tpm2-pcrs bindet der Schlüssel laut Handbuch an gar keine PCRs, das TPM gibt ihn also jedem Start beliebiger Software frei. Ergänzen Sie --tpm2-with-pin=yes für eine PIN.
4. Tragen Sie in /etc/crypttab eine Zeile mit der Option tpm2-device=auto ein; die Beispielzeile im Handbuch nennt den Volume-Namen, das Gerät per UUID, none für die Schlüsseldatei und tpm2-device=auto. Das Volume entsperrt sich dann beim Start über das TPM, das den im LUKS2-Token-Header gespeicherten Schlüssel entschlüsselt.
5. Entfernen Sie die anfängliche Passphrase, wenn die Richtlinie es verlangt, mit --wipe-slot und der Slot-Nummer; das Werkzeug verweigert das Löschen aller Slots. Lassen Sie mindestens den Recovery-Schlüssel eingetragen.

Die crypttab-Option tpm2-device= kam mit systemd 248, und die Optionen no-read-workqueue und no-write-workqueue aus derselben Version brauchen Kernel 5.9 oder neuer. Für das Root-Volume muss die Initramfs das Entsperren übernehmen. Die Dokumentation von Red Hat löst das für Clevis mit dem Paket clevis-dracut und einer neu erzeugten Initramfs (dracut -fv --regenerate-all mit --hostonly-cmdline) und bindet ein Volume mit clevis luks bind -d plus Gerät und Tang-URL an Tang. Prüfen Sie auf anderen Distributionen, ob die Initramfs TPM2-Entsperrung unterstützt, bevor Sie das Root-Volume verschlüsseln.

Wir liefern die KI-Server, auf denen das läuft; senden Sie uns Ihre Anforderungen an die Verschlüsselung mit der Anfrage, etwa ein TPM-2.0-Modul und selbstverschlüsselnde NVMe-Laufwerke, und unser Team nimmt sie in die Konfiguration auf.

Secure Boot, Firmware-Updates und die Wahl der PCRs

Das TPM gibt den Schlüssel nur frei, wenn die PCRs, Register, die festhalten, was gestartet wurde, die Werte vom Zeitpunkt der Einbindung haben. Die Wahl der PCRs entscheidet, wann das Entsperren scheitert. Das Handbuch zu systemd-cryptenroll führt sie auf:

Handbuch zu systemd-cryptenroll, systemd 262, gelesen am 25. Oktober 2026.

Das Handbuch hält es für meist nicht ratsam, an PCRs wie 0 und 2 zu binden, weil sie sich mit Firmware-Updates ändern, und ein GPU-Server kann im Lauf seines Lebens mehrere BIOS- und BMC-Firmware-Updates erhalten. PCR 7 ist die Wahl, die wir hier beschreiben: Er bleibt über Kernel- und Treiber-Updates stabil und ändert sich, wenn jemand Secure Boot abschaltet, um eigene Software zu starten. Für PCR 11, der sich mit jedem Kernel ändert, bietet das Handbuch signierte PCR-Richtlinien (--tpm2-public-key), bei denen eine Signatur auf die erwarteten Werte an die Stelle der Werte selbst tritt; das passt zu Teams, die signierte Unified Kernel Images bauen.

Secure Boot ist auf einem GPU-Server aus einem zweiten Grund wichtig: Der NVIDIA-Treiber ist ein Kernelmodul außerhalb des Kernelbaums, das signiert sein muss, oft mit einem Machine Owner Key, wie unser Leitfaden zu NVIDIA-Treiber und Secure Boot unter Linux erklärt. Schlüssel einzutragen und Secure-Boot-Einstellungen zu ändern kann PCR 7 verändern; erledigen Sie das also, bevor Sie das TPM einbinden, oder halten Sie den Recovery-Schlüssel bereit. Prüfen Sie vor jedem Firmware-Update, dass der Recovery-Schlüssel griffbereit ist; verweigert das TPM nach dem Update, entsperren Sie damit und binden das TPM neu ein. Red Hat warnt für Clevis ebenso: PCR-Werte können sich ändern, und das Volume entsperrt sich dann nicht mehr, halten Sie also eine starke Passphrase für das manuelle Entsperren bereit.

Selbstverschlüsselnde NVMe-Laufwerke (Opal)

Selbstverschlüsselnde NVMe-Laufwerke verschlüsseln jeden Block in Hardware, und Laufwerke mit dem Standard TCG Opal lassen sich vom Host sperren und entsperren. cryptsetup kann sie verwalten: --hw-opal formatiert LUKS2 mit dm-crypt-Verschlüsselung über der Hardwareverschlüsselung, sodass beide Schichten greifen, während --hw-opal-only allein die Verschlüsselung des Laufwerks nutzt und LUKS2 nur den Entsperrschlüssel des Locking Range verwaltet. Die Opal-Unterstützung verlangt Kernel 6.4 oder neuer.

Das Handbuch enthält zwei Warnungen. Mit --hw-opal-only entsperrt die Opal-Administrator-PIN des Laufwerks alle eingerichteten Locking Ranges ohne Entschlüsselung eines LUKS-Keyslots; diese PIN wird damit so sensibel wie die Schlüssel. Und manche Laufwerke brauchen einen PSID-Reset, der alle Daten löscht, bevor sie das LUKS-Opal-Format annehmen. Die PSID steht auf dem Laufwerk; das Handbuch zum Löschen warnt, dass sie jedem mit Zugriff erlaubt, die Daten zu zerstören, und bittet darum, dass sie nicht durch durchsichtige Verpackung beim Transport oder online gestellte Fotos des Laufwerks bekannt wird.

Hardwareverschlüsselung kostet keine CPU-Zeit, ihre Qualität hängt aber von einer Firmware ab, die Sie nicht prüfen können. Softwareverschlüsselung mit dm-crypt ist offen und prüfbar. Mit --hw-opal gestapelt, bleibt bei einer Schwäche der einen Schicht die andere bestehen. Ob ein Laufwerk Opal unterstützt, steht in seinem Datenblatt; fragen Sie im Angebot danach, wenn Sie es brauchen.

Recovery-Schlüssel, Header-Backups und Hinterlegung

Ein verlorener Schlüssel bedeutet verlorene Daten; die Schlüsselverwaltung kommt deshalb vor der Verschlüsselung. Drei Dinge gehören in einen Passwort-Tresor des Unternehmens oder in einen versiegelten Umschlag im Safe, außerhalb des Servers:

• Der Recovery-Schlüssel aus systemd-cryptenroll --recovery-key, einer pro Volume, beschriftet mit der Seriennummer des Servers und der UUID des Volumes.
• Das LUKS-Header-Backup, erstellt mit cryptsetup luksHeaderBackup und --header-backup-file. Das Handbuch warnt, dass bei einem beschädigten Header alle Daten dauerhaft verloren sind, wenn es kein Header-Backup gibt. Es warnt auch, dass das Backup zusammen mit einer zum Zeitpunkt des Backups gültigen Passphrase die Daten entschlüsselt, selbst wenn die Passphrase später geändert oder entfernt wurde; das Backup ist also so sensibel wie der Schlüssel.
• Bei Opal-Laufwerken die Administrator-PIN, mit derselben Sorgfalt.

Legen Sie fest, wer sie nach welchem Verfahren abrufen darf, und testen Sie einmal im Jahr eine Wiederherstellung an einem Ersatz-Volume. Hat eine einzige Person die einzige Kopie, hängen die Daten an dieser Person.

Defekte Laufwerke, Garantierückgaben und Außerbetriebnahme

Ein ausgefallenes Laufwerk lässt sich oft nicht mehr löschen, und genau in diesem Fall zahlt sich die Verschlüsselung am meisten aus. Ein verschlüsseltes Laufwerk, das in die Garantie zurückgeht, enthält nur Chiffretext: Der im TPM versiegelte Schlüssel bleibt im Chip des Servers, und weder Recovery-Schlüssel noch Passphrase liegen auf dem Laufwerk. Der LUKS-Header auf dem Laufwerk enthält allerdings die Keyslots, sodass eine schwache Passphrase offline angegriffen werden könnte; ein erzeugter Recovery-Schlüssel und eine starke Passphrase schließen diesen Weg.

Reagiert das Laufwerk noch, entfernen Sie die Schlüssel, bevor es das Haus verlässt. cryptsetup erase entfernt alle Keyslots und den Volume-Schlüssel. Das Handbuch nennt den Vorgang unumkehrbar und die Daten dauerhaft unwiederbringlich, sofern kein Header-Backup existiert; vernichten Sie also auch alle Header-Backups dieses Volumes. Das Löschen überschreibt den Datenbereich nicht, was ohne Schlüssel auch nicht nötig ist. Bei Opal-Laufwerken löscht der Werksreset mit der PSID alle Daten auf dem Laufwerk. Bei der Außerbetriebnahme schließt die NVMe-Bereinigung mit Crypto Erase und einem Zertifikat pro Laufwerk den Vorgang ab, wie unser Leitfaden zur Lebensdauer von GPU-Servern beschreibt.

Leistung: Modelle laden und Vektorspeicher

dm-crypt entschlüsselt auf der CPU, und ein GPU-Server liest seine größten Dateien, die Modellgewichte, beim Start einer Engine. Ein Modell wie gpt-oss-120b mit 60,8 GiB Gewichten wird einmal pro Start gelesen; danach hält der Page Cache von Linux die Datei, und die GPUs arbeiten aus ihrem eigenen Speicher. Die Inferenzgeschwindigkeit bleibt unberührt. Vektordatenbanken und Logs lesen und schreiben im Betrieb kleinere, verteilte Blöcke auf dem verschlüsselten Volume.

Eine veröffentlichte Messung des dm-crypt-Durchsatzes auf aktuellen EPYC-Prozessoren mit NVMe-Laufwerken für PCIe 5.0 haben wir nicht gefunden. cryptsetup benchmark misst die Cipher auf Ihren Prozessoren im Speicher; das ergibt die Obergrenze, die Sie mit der Nenngeschwindigkeit Ihrer Laufwerke vergleichen. Testen Sie die Optionen no-read-workqueue und no-write-workqueue mit Ihrer Last, wenn das Volume langsamer ist als erwartet. Die Option discard reicht TRIM an die SSD durch und verbessert laut crypttab-Handbuch die Leistung auf SSDs, hat aber Folgen für die Sicherheit, weil sie verrät, welche Blöcke belegt sind. Unser Leitfaden zu NVMe für LLM-Server nennt Ladezeiten von NVMe, einem NAS und aus dem Page Cache.

Was wir liefern

Sie können diese Server bei uns kaufen: Unser Team legt die Konfiguration nach Ihrer Last und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server auf Bestellung mit zwei, vier oder acht Karten der RTX PRO 6000 Server Edition oder H200 NVL, zwei AMD-EPYC-Prozessoren und NVMe-Speicher, mit Out-of-Band-Verwaltung über den BMC, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer EU-Rechnung und mit Herstellergarantie auf jede Komponente, abgewickelt über uns; Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Auf Wunsch kommt der Server mit Betriebssystem, NVIDIA-Treiber, CUDA und einer Container-Laufzeit. Nennen Sie uns den Standort des Servers und wer ihn entsperren darf, und wir nehmen TPM-Modul und Laufwerke auf, die Ihr Verschlüsselungskonzept braucht.

FAQ