Microsofts Security Response Center hat bereits vor über 15 Jahren die "10 Immutable Laws of Security" (inzwischen überarbeitet) [1] veröffentlicht. Das dritte Gesetz lautet: "Wenn ein Angreifer physischen Zugriff auf deinen Computer hat, ist es nicht mehr dein Computer". Damals hat Microsoft selbst noch keinen Typ-1-Hypervisor hergestellt, und auch der Branchenprimus VMware stand erst am Anfang seiner Erfolgsgeschichte. Heutzutage liegen die "Kronjuwelen" der Unternehmens-IT meist nicht auf physischen Servern, sondern in virtuellen Maschinen. Somit müssen das dritte Gesetz und die daraus resultierenden Schutzmaßnahmen auf die virtuelle "Hardware" angewandt werden. Dies gilt unabhängig vom eingesetzten Hypervisor, doch Hyper-V ist dank seiner Windows-DNA im besonderen Maße gefährdet und verdient daher entsprechende Beachtung.

Wie könnte ein Angreifer das Betriebssystem einer virtuellen Maschine und die darin ausgeführten Anwendungen und Dienste potenziell anzugreifen? In der physischen Welt rangieren die möglichen Angriffe von der Zerstörung der Hardware (gerne mittels Vorschlaghammer) über deren Entwendung aus dem Gebäude bis hin zur Installation eines Keyloggers zum Abgreifen der Passwörter. Die meisten denkbaren Angriffe auf physische Server und Clients haben auch in der virtuellen Welt ihre Entsprechungen.

Ein Angreifer, der Zugriff auf den Host erlangt hat, könnte eine VM herunterfahren oder durch abnormales Beenden von Prozessen hart ausschalten. Das stellt an sich keine Gefahr für die Sicherheit Ihrer Unternehmensdaten dar. Wird jedoch das richtige System im richtigen Moment ausgeschaltet, kann dies die Geschäftsprozesse durcheinander bringen, den Versand zeitkritischer Nachrichten blockieren und zumindest für einen Imageschaden sorgen. Doch auch eine Datenkorruption ist denkbar, beispielsweise bei einem Datenbankserver, der in diesem Moment eine umfangreiche Datenreorganisation durchführt.

In der virtuellen Welt lässt sich eine empfindliche Störung der Infrastruktur oft schon durch eine manipulierte Uhrzeit auf den Hosts erreichen. Viele virtuelle Maschinen in Unternehmen und Organisationen sind so konfiguriert, dass sie die Uhrzeit mit dem Hypervisor synchronisieren. Ändert sich die Hostzeit, folgen auch die VMs; die Kerberos-Authentifizierung und andere von der Uhrzeit abhängige Vorgänge funktionieren nicht mehr und Chaos ist vorprogrammiert.

Mit etwas mehr Berechtigungen ausgestattet, kann es das Ziel des Angreifers sein, virtuelle Maschinen in Ihrer Umgebung zu zerstören. Was in der physischen Welt den erwähnten Vorschlaghammer und körperlichen Zutritt zur Hardware erfordert, gelingt im virtualisierten Rechenzentrum mit ein paar Befehlen und ist aus großer Entfernung durchführbar. In die gleiche Richtung gehen moderne Ransomware- und Killware-Angriffe auf virtualisierte Infrastrukturen. Bei diesen sind üblicherweise nicht nur die laufenden VMs das Ziel, sondern auch Sicherungen dieser VMs, sofern sie über das Netz erreichbar sind.

Doch nicht jeder Angriff resultiert gleich im Verlust von Daten oder Funktionalität. Oft ist nicht das Stören Ihres Geschäftsbetriebs, sondern das Entwenden der Informationen das Ziel des Angriffs. Auch hier bieten virtuelle Maschinen deutlich bequemere Möglichkeiten als physische Server; mit Zugriff auf die Storage-Volumes können sie kopiert werden, ohne dass Sie im ersten Moment etwas davon merken.

Die ausgeklügelten, langfristig angelegten Angriffsszenarien wie das Modifizieren der Hardware oder das Einschleifen eines Keyloggers in die Tastatur haben gleichfalls ihre Entsprechungen im Virtuellen – schließlich handelt es sich sowohl beim "BIOS" als auch bei der "Tastatur" lediglich um Dateien und Programme auf dem Hyper-V-Host, die mit genügend Sachverstand und bösem Willen verändert werden könnten. Die funktionsbedingt erforderliche Kommunikation zwischen dem Hypervisor und den VMs lässt sich ebenfalls missbrauchen, um an das Betriebssystem der VM zu gelangen.

Wo Netzwerksegmentierung das Ausbreiten innerhalb der Umgebung erschwert, kann beispielsweise PowerShell Direct [2] eine willkommene Abkürzung sein, laufen doch VMs aus unterschiedlichen Netzsegmenten häufig auf den gleichen Hosts. Die virtuelle ACPI-Schnittstelle (Advanced Configuration and Power Interface) kann der einfachste Weg sein, um das Betriebssystem innerhalb der VM herunterzufahren. Die Data-Exchange-API ist zudem ein robustes und zuverlässiges Vehikel zum Exfiltrieren von Daten aus einer VM.

Virtualisierung eröffnet weitere Angriffsvektoren, die mit physischen Maschinen so nicht möglich sind. Nutzen Sie zum Beispiel in Ihrer Virtualisierung die Shared-Nothing-Livemigration, werden sowohl der Inhalt der virtuellen Festplatten als auch der des Arbeitsspeichers über das Netzwerk übertragen. Hat der Angreifer eine Möglichkeit gefunden, den Netzverkehr abzuhören, könnte ihm eine gesamte VM einfach dadurch zufliegen, dass sie auf einen anderen Host verschoben wird.

Doch auch innerhalb eines Hosts gibt es immer wieder Möglichkeiten, durch gemeinsam genutzte Ressourcen wie Arbeitsspeicher, Peripherie oder GPU-Speicher aus einer kompromittierten VM heraus die anderen VMs auszuhorchen oder deren Betrieb zu stören.

Virtualisierung birgt außerdem noch eine weitere Gefährdung. Über Jahrzehnte haben die Hersteller von Betriebssystemen und Sicherheitsprodukten zusammen mit den Hardwareproduzenten eine Reihe von Technologien entwickelt, um Computersysteme sicherer zu machen, indem die Hardware Funktionen wie TPM, kryptografische Koprozessoren oder UEFI-Zertifikate bereitstellt, die die Software zur Sicherstellung der Integrität und Vertraulichkeit der verarbeiteten Daten benutzen kann. Virtuelle Hardware kann nur einen Teil dieser Technologien abbilden, und nicht selten ist deren Einsatz mit zusätzlichem Aufwand und funktionalen Einschränkungen verbunden. Das führt dazu, dass in virtualisierten Umgebungen oft wichtige Sicherheitsfeatures inaktiv bleiben, die sich auf physischer Hardware mit einer einfachen Einstellung umsetzen lassen.

Der wichtigste und zugleich erste Schritt zum Schutz virtueller Workloads ist, wenig überraschend, der Schutz der darunterliegenden Virtualisierungsplattform. Das dritte Gesetz gilt schließlich auch für die Hypervisor-Hosts. Im Zentrum der Absicherung virtueller Maschinen sollte stets die Sicherheit des Workloads selbst stehen. Sorgen Sie dafür, dass die Software auf dem aktuellen Stand ist, schränken Sie mittels der lokalen Firewall den Netzwerkverkehr ein und halten Sie die allgemeinen Hygieneregeln bezüglich Admin-Accounts oder nicht benötigter Dienste ein. Um die "Hülle" Ihrer Hyper-V-VMs so sicher wie möglich zu gestalten und von den erweiterten Sicherheitsfeatures moderner Betriebssysteme zu profitieren, stehen Ihnen einige Möglichkeiten zur Verfügung.

Halten Sie die Version der virtuellen Hardware aktuell. Wenn Sie VMs aus fremden Quellen importieren oder innerhalb Ihrer Umgebung von älteren auf neuere Hosts migrieren, bleibt die Konfiguration der VM auf dem ursprünglichen Stand und unterstützt möglicherweise nicht alle Sicherheitsfeatures, die der neue Hyper-V-Host zur Verfügung stellen kann. Das Upgrade der Konfiguration lässt sich nicht rückgängig machen, Sie werden die VM daher nicht mehr auf ältere Hosts verschieben können. Die Liste der unterstützten Versionen finden Sie unter [3], im gleichen Artikel sind auch die Features aufgeführt, die von jedem Konfigurationsupgrade freigeschaltet werden. Beim Anlegen einer neuen VM mit den grafischen Tools verwendet ein Hyper-V-Host standardmäßig die höchste von ihm unterstützte Version, mittels PowerShell hingegen können Sie auch frühere Konfigurationsversionen erzeugen, indem Sie New-VM mit dem Parameter "-Version" verwenden.

Nicht minder wichtig ist es, die Hyper-V Integration Components (ICs) innerhalb der VM stets aktuell zu halten, denn darüber läuft die Kommunikation zwischen dem Host und der VM. Auf modernen Windows-Betriebssystemen sorgt Windows Update dafür, dass die ICs aktuell bleiben. Alle derzeit unterstützten Linux- und BSD-Distributionen und -Versionen bringen Hyper-V Integration Components mit und sorgen im Rahmen des integrierten Package-Managements für deren Aktualisierung. Andere Betriebssysteme einschließlich älterer Windows-Versionen, sofern Sie in Ihrer Virtualisierung solche betreiben, müssen Sie explizit aktuell halten, was nicht immer möglich sein wird.

Für Betriebssysteme, die auf der Supportliste für Ihre Hyper-V-Version stehen und UEFI unterstützen [4], sollten Sie unbedingt VMs der Generation 2 verwenden, um die neusten Sicherheitsfeatures Ihres Betriebssystems nutzen zu können – allen voran SecureBoot und vTPM [5]. Die gewählte Generation bestimmt auch das Format der Systemfestplatte (IDE-Boot mit BIOS-Partitionstabelle oder SCSI-Boot mit GPT), daher ist ein nachträgliches Generationsupgrade nicht vorgesehen. Wünschen Sie dennoch eine andere Generation, müssen Sie ein geeignetes und von Microsoft unterstütztes Konvertierungstool bemühen – oder die VM neu aufbauen, was oft schneller geht und ein stabileres Ergebnis liefert.

Schalten Sie die nicht benötigten Integrationsdienste ab. Falls Sie den KVP-Datenaustausch (Key-Value Pair) nicht verwenden, können Sie den Dienst getrost hostseitig deaktivieren. Das gleiche gilt für den Dienst "Gastschnittstelle" zum Kopieren von Dateien zwischen Host und Gast, der auf modernen Hyper-V-Versionen standardmäßig ausgeschaltet ist. Ob Sie den Dienst zum Herunterfahren des Gasts und den VSS-Anbieter (Volume Shadow Copy Service) aktiviert lassen oder deaktivieren, hängt im Wesentlichen davon ab, wie Sie Ihre Umgebung verwalten und ob Sie die Dienste tatsächlich benötigen. Einige Organisationen verwenden zum Herunterfahren stets explizite Befehle auf Betriebssystemebene, unabhängig davon, ob die jeweilige Maschine physisch oder virtuell ist.

Die Hyper-V-Gemeinde ist seit jeher uneins darüber, ob die Zeitsynchronisierung mit dem Host sinnvoll ist oder nicht. Es gibt einen Artikel von Ben Armstrong aus frühen Hyper-V-Zeiten, der darauf hindeutet, dass die Hostzeit zunächst nur zur Startzeit der VM zum Einsatz kommt und später im Betrieb ignoriert wird, sofern die VM über eine andere valide Zeitquelle verfügt. Die Erfahrung zeigt jedoch, dass spontane Änderungen der Hostzeit sich sehr wohl in die laufenden VMs übertragen. Es empfiehlt sich daher, die Hostzeit-Synchronisation generell zu deaktivieren, vor allem bei virtualisierten Domaincontrollern. Falls Sie die Hostzeit bei Linux- und BSD-VMs abschalten, müssen Sie mittels Monitoring und anderer Maßnahmen sicherstellen, dass beim Starten eine korrekte Uhrzeit eingestellt wird. Der NTP-Daemon auf diesen Betriebssystemen verträgt nämlich keine zu großen Abweichungen von der eingestellten externen Zeitquelle und korrigiert die Zeit nicht selbsttätig, wenn sie zu weit vor oder hinter der NTP-Zeit liegt.

Der einzige Dienst, den Sie nicht hostseitig abstellen können, ist PowerShell Direct. Hier muss der Administrator seine Windows-VM selbst vor dem äußeren Einfluss schützen, indem er den PowerShell-Direct-Dienst (vmicvmsession) auf "deaktiviert" stellt.

Eine kleine Maßnahme, die einige seltene und sehr spezifische Angriffsszenarien abwendet, im Betrieb aber meist nicht stört, besteht darin, in der Konfiguration der VMs keine optischen Laufwerke zu registrieren. Muss ein ISO-Image einmal eingebunden werden, lässt es sich entweder in die VM kopieren und dort bereitstellen, oder Sie ändern kurz die Konfiguration der VM und löschen das DVD-Laufwerk nach getaner Arbeit. Beide Konfigurationsanpassungen sind im laufenden Betrieb möglich.

Wie bereits erwähnt, eröffnen virtualisierungstypische Vorgänge wie Livemigration oder Zustandsspeicherung von virtuellen Maschinen zusätzliche Möglichkeiten, Daten der VM abzugreifen. In beiden Fällen wird der Zustand des aktiven Arbeitsspeichers übertragen beziehungsweise auf der Festplatte gespeichert, was unter Umständen den Zugriff auf verwendete Anmeldedaten und andere Geheimnisse erlaubt. Um solchen Angriffen einen Riegel vorzuschieben, unterstützt Hyper-V bereits seit einigen Versionen die Verschlüsselung dieser Daten – sowohl bei der Zustandsspeicherung als auch bei Livemigrationen.

In VMs der ersten Generation muss dafür ein dediziertes Schlüsselspeicher-Laufwerk hinzugefügt werden. Diese 42 MByte große IDE-Festplatte ist im Betriebssystem sichtbar, jedoch nicht formatiert oder partitioniert. Neben der Zustandsspeicherung bietet dieses Laufwerk eine Möglichkeit, BitLocker-Schlüssel abzulegen und die Festplatten der VM zu verschlüsseln. Die zweite Generation der Hyper-V-VMs baut diese Technologie weiter aus und erlaubt die Nutzung eines virtuellen TPM-Chips. Mit diesem ist weiterhin die Verschlüsselung des gespeicherten Zustandes und des Livemigration-Datenverkehrs möglich. Doch auch für alle anderen Funktionen innerhalb des Betriebssystems, die einen TPM-Chip erfordern, ist diese zusätzliche virtuelle Hardware geeignet. Auf diese Weise gelingt beispielsweise auch eine Windows-11-Installation, die einen TPM-Chip zwingend voraussetzt.

Technologisch betrachtet weist vTPM keine Abhängigkeit zu dem eventuell im Hyper-V-Host verbauten realen TPM-Modul auf. Die abgesicherte und authentifizierte Speicherung der Verschlüsselungsschlüssel ist vollständig in Software realisiert und auch auf Hosts ohne einen eigenen TPM-Chip problemlos möglich. Dennoch ist vTPM zunächst einmal an den Host gebunden – es ist nicht Teil der VM, und die gespeicherten Daten sind mit Schlüsseln verschlüsselt, die durch DPAPI auf dem Host geschützt sind. Dies hat zur Folge, dass Maschinen mit aktiviertem Schlüsselspeicher-Laufwerk oder vTPM nicht auf einen anderen Host umziehen können, sei es per Live- oder Quick-Migration. Im ausgeschalteten Zustand können Sie die VM zwar auf einen anderen Host bewegen, doch sie wird dort nicht starten können, weil der entsprechende Key Protector fehlt. Dafür müssen Sie zwei Zertifikate inklusive privater Schlüssel vom Quellhost exportieren und auf dem Zielhost importieren. Diese finden Sie im Zertifikatsspeicher "Lokale Zertifikate für abgeschirmte VMs".

Den höchsten Schutz gegen Angriffe aus der Infrastruktur, beispielsweise durch einen allzu neugierigen Hyper-V-Administrator, bieten abgeschirmte VMs (Shielded VMs). Diese müssen der Generation 2 angehören und haben alle auf vTPM basierten Features zwangsweise aktiviert. Zusätzlich sind keine Konsolen- oder PowerShell-Direct-Verbindungen zu abgeschirmten VMs möglich, sodass der Hyper-V-Administrator die VM zwar verwalten, aber keinen Einblick in die Daten und Prozesse dort nehmen kann. Abgeschirmte VMs erfordern eine Datacenter-Lizenz und unterliegen der gleichen Einschränkung bezüglich des Hostwechsels wie die normalen Maschinen mit aktiviertem vTPM.

Einerseits gehört die Fähigkeit zum Umzug oder Failover auf einen anderen Host zu den wichtigsten Merkmalen der Virtualisierung, andererseits können lokal auf dem Host gespeicherte Schlüssel in letzter Konsequenz dem Zugriff der Administratoren nicht entzogen werden. Microsoft hat deshalb für die VM-Verschlüsselung den ultimativen Schutz konzipiert: die Guarded Fabric. Das Feature wird oft in einem Atemzug mit abgeschirmten VMs genannt. Jedoch ist, wie wir gesehen haben, eine abgeschirmte VM auch auf einem alleinstehenden Host möglich. Sie genießt allerdings nicht den vollständigen Schutz gegen Angreifer, die sich hohe Privilegien auf dem Host verschafft haben.

Guarded Fabric behebt dieses Manko und sorgt gleichzeitig dafür, dass abgeschirmte VMs innerhalb der geschützten Infrastruktur bewegt werden können. Die Voraussetzungen dafür erscheinen vielen IT-Verantwortlichen auf den ersten Blick als Overkill, bei näherem Hinsehen offenbart sich allerdings eine gut durchdachte Sicherheitsarchitektur:

- Ein Cluster aus mindestens drei Hardwareknoten, die den sogenannten "Host Guardian Service" (HGS) ausführen. Es wird empfohlen, die dort verbauten TPM-Module zu nutzen, dies ist jedoch keine zwingende Voraussetzung.

- Eine Active-Directory-Domäne für HGS, die nicht dem gleichen Forest wie die Domäne(n) der geschützten Hyper-V-Hosts angehört.

- Eine Vertrauensstellung zwischen der HGS-Domäne und den Hyper-V-Domänen. Die HGS-Domäne muss den Hostdomänen vertrauen, denn die Hosts authentifizieren sich mit ihren Maschinenidentitäten gegenüber dem HGS. Daher sind bestehende Admin- oder Bastion-Forests für HGS ungeeignet, denn dort ist die Vertrauensstellung in die andere Richtung gegeben.

In einer "Guarded Fabric" können neben abgeschirmten auch herkömmliche VMs laufen – mit oder ohne vTPM. Für Maschinen mit vTPM verwaltet der HGS die Schlüssel und reicht sie erst an einen anfordernden Host aus, wenn dessen tadelloser Zustand feststeht. Dafür sind im HGS für jeden Host eine Hardware-Baseline und eine Code-Integrity-Richtlinie hinterlegt. Sie kennen Code Integrity vielleicht als "Windows Defender Application Control".

Das Einrichten und der Betrieb von HGS-Clustern und Guarded Fabrics erfordern gute Planung und viel Arbeit, was Microsoft im Detail unter [7] dokumentiert hat. Nur mit dieser Technologie lässt sich jedoch die ultimative Separation der Verantwortlichkeiten erzwingen, die Sie für eine sichere Private Cloud voraussetzen müssen.

Der Schutz virtualisierter Workloads ist stets eine Kombination aus Infrastrukturabsicherung, Betriebssystemhärtung innerhalb der VMs sowie Maßnahmen, die für die VM-Hüllen spezifisch sind. Hyper-V bietet hier praktischerweise eine Fülle an Möglichkeiten – von der Deaktivierung nicht benötigter Host-Gast-Integrationen bis hin zu abgeschirmten VMs und Guarded Fabrics. Für alle fortgeschrittenen Schutzfunktionen sind jedoch Kenntnisse in Windows-Kryptographie und PowerShell von großem Vorteil.