# Proxmox VM Security: UEFI, Secure Boot & vTPM Deep Dive

TL;DR / Management Summary Moderne Betriebssysteme (wie Windows 11) fordern hardwarebasierte Sicherheits-Features. In Proxmox emulieren wir diese durch OVMF (UEFI) und virtuelle TPM (vTPM) 2.0 Chips. Ein Senior Admin nutzt diese Technologien, um die Vertrauenskette (Chain of Trust) vom Bootloader bis zur Applikation zu schließen und ermöglicht so den Einsatz von BitLocker innerhalb der VM, um Daten auch bei Diebstahl der physischen Host-SSD (Artikel 711) zu schützen.

# 1. Das UEFI-Fundament (OVMF)

Vom BIOS zur Firmware.

Jede VM, die Secure Boot oder TPM nutzen soll, muss mit UEFI gebootet werden.

  1. BIOS: Wählen Sie OVMF (UEFI) in den VM-Hardware-Optionen.
  2. EFI Disk: Fügen Sie ein dediziertes Laufwerk hinzu, um den permanenten UEFI-Variablen-Speicher (NVRAM) zu sichern.
  3. Machine: Nutzen Sie den Typ q35, da er ein moderneres Bus-Layout für Sicherheitskomponenten bietet.

# 2. vTPM 2.0: Der virtuelle Sicherheitschip

Schlüssel sicher verwahren.

Ein virtuelles TPM (Trusted Platform Module) erlaubt der VM das Speichern von kryptografischen Schlüsseln.

# 3. Deep Dive: Secure Boot konfigurieren

Nur signierten Code erlauben.

Secure Boot verhindert, dass unbefugte Software (z.B. Boot-Rootkits) vor dem Betriebssystem lädt.

  1. Starten Sie die VM und drücken Sie sofort ESC, um in das UEFI-Menü zu gelangen.
  2. Navigieren Sie zu Device Manager -> Secure Boot Configuration.
  3. Attempt Secure Boot: Auf Enabled stellen.
  4. Enroll Keys: Falls Sie Linux nutzen, müssen Sie die Microsoft-Keys (für Shim) laden.

# 4. Day-2 Operations: Backup von TPM-Daten

Vorsicht bei Migrationen.

Die Daten im vTPM sind an die VM-ID gebunden.

# 5. Troubleshooting & “War Stories”

Wenn der Bootvorgang bei 0% abbricht.

# Top 3 Fehlerbilder

  1. Symptom: Windows 11 meldet beim Setup “Dieser PC erfüllt die Mindestanforderungen nicht”.

    • Ursache: UEFI oder TPM fehlt in der Hardware-Konfiguration.
    • Lösung: Hardware-Liste prüfen (Artikel 669).

  2. Symptom: Linux VM bootet nur in den Grub Rescue Modus.

    • Ursache: Kernel-Update wurde nicht signiert, während Secure Boot aktiv war.
    • Fix: Secure Boot temporär im UEFI-Menü deaktivieren und Kernel-Signatur prüfen.

  3. Symptom: BitLocker verlangt nach jedem Proxmox-Update den Wiederherstellungs-Key.

    • Ursache: Ein Update des OVMF-Pakets am Host hat die “Messwerte” des virtuellen Mainboards geändert (PCR-Mismatch).

# “War Story”: Der “Auto-Update” Lockout

Ein Administrator aktivierte BitLocker auf 50 Windows-VMs mit vTPM. Er vergaß, die Recovery Keys im Active Directory zu sichern. Das Ereignis: Er migrierte die VMs auf einen neuen Proxmox-Cluster mit einer anderen CPU-Generation (Intel v3 auf Intel v4). Das Ergebnis: Das vTPM verweigerte die Freigabe des Keys, da es eine “Manipulation der Hardware-Umgebung” erkannte. Alle 50 Server verlangten beim Booten den Recovery-Key. Lehre: vTPM ist ein mächtiges Schutzschild, aber es reagiert allergisch auf Infrastruktur-Änderungen. Sichern Sie immer die Recovery-Keys extern (Artikel 431)!

# 6. Monitoring & Reporting

Security-Compliance.

# vTPM Check (Shell)

Prüfen Sie, welche VMs einen aktiven TPM-Status haben:

grep -r "tpmstate" /etc/pve/qemu-server/*.conf

# 7. Fazit & Empfehlung

Secure Boot und vTPM sind heute der Standard für geschäftliche Desktops und Server.

# Anhang: Cheatsheet (VM Security Settings)

Feature Proxmox Hardware Setting Nutzen
UEFI BIOS: OVMF (UEFI) GPT Boot, Secure Boot
vTPM TPM State: v2.0 BitLocker, Windows 11
CPU Härtung Type: host + AES-NI Verschlüsselungs-Speed
Isolation Machine: q35 Modernes PC-Layout

# Referenzen