[English]Bei der Virtualisierung von Windows 11 oder Windows Server 2025 wird ein TMP-Plattformmodule (vTPM) benötigt. Bei der in Windows enthaltenen Virtualisierungsplattform Hyper-V lassen sich vTPN und weitere Optionen konfigurieren. Problem ist aber, wenn eine solche VM verschoben wird und die vTPM-Zertifikate brechen. Gerade ist mir ein entsprechender Artikel von Microsoft untergekommen, der sich mit dieser Frage beschäftigt.
Es ist bekannt, dass Gastbetriebssysteme wie Windows 11 oder Windows Server 2025 mit aktivierten Sicherheitsfunktionen (Secure Boot, Bitlocker) unter Hyper-V auf ein funktionierendes virtuelles, aber vertrauenswürdiges TMP-Plattformmodule (vTPM) angewiesen sind.
Hyper-V und vTPM für VMs
Unter Hyper-V ist es kein Problem, das vTPM für virtuelle Maschinen über die Konfigurierung bereitzustellen und dann das Gastbetriebssystem zu installieren. Problem bzw. Herausforderung von vTPMs ist, dass es auf Zertifikate auf dem lokalen Hyper-V-Server angewiesen ist.
Wenn ein vTPM auf einer virtuellen Maschine der Generation 2 aktiviert wird, generiert Hyper-V automatisch ein Paar selbstsignierter Zertifikate auf dem Host, auf dem sich die VM befindet. Diese Zertifikate sind speziell benannt:
- "Shielded VM Encryption Certificate (UntrustedGuardian)(ComputerName)"
- "Shielded VM Signing Certificate (UntrustedGuardian)(ComputerName)"
Diese Zertifikate werden in einem eindeutigen lokalen Zertifikatspeicher auf dem Hyper-V-Host namens "Shielded VM Local Certificates" gespeichert. Standardmäßig werden diese Zertifikate mit einer Gültigkeitsdauer von 10 Jahren bereitgestellt. Solange die virtuellen Maschinen (VMs) mit dem vTPM auf diesem Server ausgeführt werden, muss man sich keine Gedanken machen (dass eine VM länger als 10 Jahre läuft, dürfte eher selten sein).
vTPM für VMs bei Migration ein Problem
Soll aber eine VM auf einen anderen Hyper-V-Server verschoben werden, gibt es möglicherweise Probleme. Dann dann bricht das für vTPM beim Einrichten der VM verwendete Zertifikat und wird auf dem anderen Server ungültig. Der Administrator muss also Vorkehrungen treffen, um die Zertifikate mit zu migrieren.
Damit eine vTPM-aktivierte virtuelle Maschine erfolgreich live migriert und anschließend auf einem neuen Hyper-V-Host gestartet werden kann, müssen die "abgeschirmten lokalen VM-Zertifikate" (sowohl die Verschlüsselungs- als auch die Signierungszertifikate) vom Quellhost auf allen potenziellen Hyper-V-Zielhosts vorhanden und vertrauenswürdig sein.
Microsoft-Mitarbeiter Orin Thomas hat sich zum 7. Juli 2025 im Techcommunity-Beitrag Hyper-V Virtual TPMs, Certificates, VM Export and Migration über verschiedene Aspekte dieser Fragestellung ausgelassen. Im Artikel zeigt er, wie sich die mit vTPMs verknüpften Zertifikate verwalten lassen, so dass Administratoren die VMs mit z.B. Windows 11-VMs auf jeden vorbereiteten Hyper-V-Host exportieren oder verschieben können, den sie verwalten. Vielleicht sind die Ausführungen für den einen oder anderen Leser von Interesse.
MVP: 2013 – 2016
Vielleicht geht's auch so?:
1. BitLocker Recovery Key sichern.
2. vTPM deaktivieren.
3. Secure Boot deaktivieren.
4. VM herunterfahren, dann exportieren.
5. Auf Ziel-Host importieren.
6. TPM/Secure Boot wieder aktivieren.
7. Beim ersten Boot: BitLocker Recovery Key eingeben.
Kann es gerade wegen All-Inklusive Ferien nicht testen.
Naja, ich mache gerne eine Livemigration einer VM auf ein anderes Blech, wenn mal Wartungsarbeiten am Hostsystem (z.B. Updates einspielen) anstehen.
Das Schöne an der Livemigration ist, das die VM ohne Unterbrechung weiterläuft.
Und da ist der Hinweis bzgl. vTPM schon nützlich.
Kann man so versuchen, ist halt ein Wahnsinnsaufwand. Denk mal an eine VDI-Umgebung, auf der hunderte virtuelle Win 11 Desktops auf dutzenden Hyper-V-Hosts im Cluster laufen.
Wie siehts da bei Cluster aus in denen man eben mehr als 1 Host betreibt? Komme eher von vmware – daher ernst gemeinte Frage.
Auch in einem Hyper-V-Cluster müssen die Zertifikate, wie im verlinkten Beitrag von Orin Thomas oben im Artikel beschrieben, einmal (nach dem Setup des ersten vTPM) manuell von Host zu Host kopiert und importiert werden. Also "Shielded VM …"-Zertifikate von Host1 zu Host2,3,.. und umgekehrt. Diese Zertifikate werden im Hyper-V-Cluster nicht automatisch repliziert (um solche Dinge muss man sich in VMware dank vCenter nicht kümmern).
Ergänzung: Die vTPM werden mit den Zertifikaten vom Host signiert auf dem man die VM gerade erstellt. Daraus ergibt sich dann die Anforderung, dass jeder Host im Cluster die Zertifikate des anderen Host kennen muss. Das hätte M$ auch viel eleganter lösen können.
ggf. mach das aber auch der Virtual Machine Manager für Hyper-V?
Leider Nein.
Der VMM setzt einen Host Guardian Service voraus.
Das Migrieren der VMs innerhalb eines Clusters funktioniert über den VMM erst wenn die Zertifikate nach beschriebenem Weg verteilt wurden.
Das Migrieren von VMs zu einem anderen Cluster funktioniert erst mit eingerichtetem HGS.
Dafür braucht es den Host Guardian Service (HGS) (in einem dedizierten Cluster).
(Wenn man die Zertifikate nicht "händisch" exportieren / importieren will.)
Ich mag ja von gestern sein, aber ist nicht diese Form von Hardware-Gebundenheit (bzw. der Notwendigkeit, jene Gebundenheit quasi manuell aufzulösen) ein Widerspruch zur gesamten Thematik "Virtualisierung"? Der Witz an der Sache ist doch u. a., eine VM bei Bedarf schnell und unkompliziert auf anderer Hardware wieder zum Laufen zu bekommen.
Na ja, das sind halt nur meine laienhaften Gedanken. Ich persönlich habe auch immer mehr den Eindruck, dass TPM mehr Probleme schafft als es löst.
Was macht denn so eine VM, wenn ihr die Zertifikate fehlen? Startet das System gar nicht mehr?
Die lassen sich nicht auf einen anderen Host verschieben oder booten nicht.
Losgelöst von Windows 11 mit (v)TPM-Zwang oder auch Server 2025 mit gewissen (v)TPM-Benefits, ist eine "Guarded fabric" für Service Provider / Hoster bzw. deren Kunden evtl. interessant: https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms (und die folgenden Unterpunkte)
Bisher genügte es bei kleinen Kunden mit nur einem Hyper-V Host nur die VMs zu sichern und im Fehlerfall einfach die VMs per Backup-Software (z.B. Veem) auf neuem Blech wieder herzustellen.
Habt ihr Ideen wie man das in Zukunft macht?
Zusätzliches Backup vom Host?
Die Zertifikate welche im Artikel beschrieben sind mit dem privaten Schlüssel exportieren und diese an einem sicheren Ort aufbewahren (so wie man es mit Bitlocker-Schlüssel auch macht). Dann hat man diese zur Hand für den Import auf das neue Blech.
Google-Suche: hyper-v speicherort vtpm :
Die KI meint, zusammengefasst, das die Kombination von Zertifikat und VM-Konfigurationsdatei das vTPM ausmacht.
Habe diese Art von Wiederherstellung jedoch nicht getestet. Wir machen jede Nacht einen Backup der OS-Partition vom jedem Host im Cluster.
Windows Server 2025 verlangt noch kein vTPM, daher installiere ich es bewusst noch ohne. Gleiches gilt für alle Vorgänger-Server-OS Versionen.
Damit wären die wichtigen Serverdienste backuptechnisch mit Veeam oder ähnlichem abgedeckt.
Windows 11 verlangt dagegen vTPM – nutze ich hier aber nur in einer VM als Testclient, da wäre mir ein Verlust egal.
Aber… interessantes, wichtiges Thema!
Das sind alles unschöne Ideen.
Einfacher geht es mit richtigen HSMs, statt mit TPMs.
Der Vorteil von HSMs ist, dass man die HSMs clonen kann und so dasselbe Schlüsselmaterial auf jedem HSM bekommt.
Außerdem ist es sicherer, weil das
Schlüsselmaterial nicht aus dem RAM gedumpt und nicht aus dem HSM extrahiert werden kann.
https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-ms-host-guardian-service-guide.html
Die Jüngeren erinnern sich:
"highly isolated and restricted production environment" aber keine HSMs …
https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/