Geschütztes Fabric und abgeschirmte virtuelle Computer: Planungshandbuch für Hoster

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

In diesem Thema werden Planungsentscheidungen behandelt, die getroffen werden müssen, damit abgeschirmte virtuelle Computer in Ihrem Fabric ausgeführt werden können. Unabhängig davon, ob Sie ein vorhandenes Hyper-V-Fabric aktualisieren oder ein neues Fabric erstellen, umfasst die Ausführung abgeschirmter virtueller Computer zwei Hauptkomponenten:

• Der Host-Überwachungsdienst (Host Guardian Service, HGS) bietet Nachweis- und Schlüsselschutzdienste, damit Sie sicherstellen können, dass abgeschirmte virtuelle Computer nur auf genehmigten und fehlerfreien Hyper-V-Hosts ausgeführt werden. 
• Genehmigte und fehlerfreie Hyper-V-Hosts, auf denen abgeschirmte virtuelle Computer (sowie reguläre virtuelle Computer) ausgeführt werden können, werden als überwachte Hosts bezeichnet.

Entscheidung Nr. 1: Vertrauensstufe im Fabric

Wie Sie den Host-Überwachungsdienst und die überwachten Hyper-V-Hosts implementieren, hängt hauptsächlich von der Vertrauensstufe ab, die Sie in Ihrem Fabric erreichen möchten. Die Vertrauensstufe wird durch den Nachweismodus bestimmt. Es gibt zwei Optionen, die sich gegenseitig ausschließen:

1. TPM-basierter Nachweis

   Wenn Sie virtuelle Computer vor böswilligen Administratoren oder einem kompromittierten Fabric schützen möchten, verwenden Sie den TPM-basierten Nachweis. Diese Option eignet sich sowohl für Hostingszenarien mit mehreren Mandanten als auch für wertvolle Ressourcen in Unternehmensumgebungen wie etwa Domänencontroller oder Inhaltsserver wie SQL oder SharePoint. HVCI-Richtlinien (hypervisor-protected code integrity, Hypervisor-geschützte Codeintegrität) werden gemessen, und ihre Gültigkeit wird durch den Host-Überwachungsdienst erzwungen, bevor die Ausführung abgeschirmter virtueller Computer auf dem Host zugelassen wird.

2. Hostschlüsselnachweis

   Wenn Ihre Anforderungen in erster Linie compliancebasiert sind und erfordern, dass virtuelle Computer sowohl im Ruhezustand als auch während des Betriebs verschlüsselt werden, verwenden Sie den Hostschlüsselnachweis. Diese Option eignet sich gut für universelle Rechenzentren, in denen Administratoren von Hyper-V-Host und Fabric Zugriff auf die Gastbetriebssysteme virtueller Computer haben dürfen, um sich um die alltägliche Wartung und den Betrieb zu kümmern.

   In diesem Modus ist der Fabricadministrator allein für die Sicherstellung der Integrität der Hyper-V-Hosts verantwortlich. Da der Host-Überwachungsdienst an der Entscheidung, was ausgeführt werden darf, nicht beteiligt ist, funktionieren Schadsoftware und Debugger wie vorgesehen.

   Debugger, die direkt an einen Prozess angefügt werden (z. B. „WinDbg.exe“), werden allerdings für abgeschirmte virtuelle Computer blockiert, da der Workerprozess des virtuellen Computers (VMWP.exe) ein schwach geschützter Prozess (Protected Process Light, PPL) ist. Alternative Debuggingtechniken (etwa von „LiveKd.exe“) werden nicht blockiert. Im Gegensatz zu abgeschirmten virtuellen Computern wird der Workerprozess für virtuelle Computer mit Verschlüsselungsunterstützung nicht als schwach geschützter Prozess ausgeführt, sodass herkömmliche Debugger wie „WinDbg.exe“ weiterhin normal funktionieren.

   Ein ähnlicher Nachweismodus mit einem (Active Directory-basierten) Nachweis, dem Administratoren vertrauen, ist ab Windows Server 2019 veraltet.

Die verwendete Vertrauensstufe bestimmt die Hardwareanforderungen für Ihre Hyper-V-Hosts sowie die Richtlinien, die Sie auf das Fabric anwenden. Bei Bedarf können Sie Ihr geschütztes Fabric unter Verwendung vorhandener Hardware und eines Nachweises, dem Administratoren vertrauen, bereitstellen und später in einen TPM-basierten Nachweis konvertieren, wenn die Hardware aufgerüstet wurde und Sie die Fabricsicherheit erhöhen müssen.

Entscheidung Nr. 2: Bereits vorhandenes Hyper-V-Fabric oder neues separates Hyper-V-Fabric

Wenn Sie über ein vorhandenes Fabric (Hyper-V oder anderer Art) verfügen, ist es sehr wahrscheinlich, dass Sie es verwenden können, um abgeschirmte virtuelle Computer gemeinsam mit regulären virtuellen Computern auszuführen. Einige Kunden entscheiden sich dafür, abgeschirmte virtuelle Computer in ihre bereits vorhandenen Tools und Fabrics zu integrieren. Andere trennen das Fabric dagegen aus geschäftlichen Gründen.

Planung für Host-Überwachungsdienstadministratoren für den Host-Überwachungsdienst

Stellen Sie den Host-Überwachungsdienst (Host Guardian Service, HGS) in einer hochsicheren Umgebung bereit. Dabei kann es sich um einen dedizierten physischen Server, um einen abgeschirmten virtuellen Computer, um einen virtuellen Computer auf einem isolierten Hyper-V-Host (getrennt von dem Fabric, das geschützt wird) oder um eine Umgebung handeln, die durch die Verwendung eines anderen Azure-Abonnements logisch getrennt ist.

Bereich	Details
Installationsanforderungen	Ein einzelner Server (Cluster mit drei Knoten für Hochverfügbarkeit empfohlen) Für Fallback sind mindestens zwei Host-Überwachungsdienstserver erforderlich. Server können entweder virtuell oder physisch sein. (Physischer Server mit TPM 2.0 empfohlen; TPM 1.2 wird aber auch unterstützt.) Server Core-Installation von Windows Server 2016 oder einer höheren Version Netzwerk-Sichtverbindung mit dem Fabric, um HTTP- oder Fallbackkonfiguration zu ermöglichen Für die Zugriffsüberprüfung wird ein HTTPS-Zertifikat empfohlen.
Festlegen der Größe	Jeder mittelgroße Knoten (acht Kerne, 4 GB) des Host-Überwachungsdienstservers bietet genügend Kapazität für 1.000 Hyper-V-Hosts.
Verwaltung	Legen Sie bestimmte Personen für die Verwaltung des Host-Überwachungsdiensts fest. Hierbei sollte es sich nicht um Fabricadministratoren handeln. Host-Überwachungsdienstcluster sind hinsichtlich administrativer Isolation, physischer Bereitstellung und allgemeiner Sicherheitsanfälligkeit mit einer Zertifizierungsstelle (Certificate Authority, CA) vergleichbar.
Active Directory des Host-Überwachungsdiensts	Standardmäßig installiert der Host-Überwachungsdienst ein eigenes internes Active Directory für die Verwaltung. Hierbei handelt es sich um eine eigenständige, selbstverwaltete Gesamtstruktur sowie um die empfohlene Konfiguration, um den Host-Überwachungsdienst von Ihrem Fabric zu isolieren. Wenn Sie für die Isolation bereits über eine Active Directory-Gesamtstruktur mit umfassenden Berechtigungen verfügen, können Sie anstelle der Standardgesamtstruktur des Host-Überwachungsdiensts auch diese Gesamtstruktur verwenden. Wichtig: Der Host-Überwachungsdienst darf keiner Domäne in der gleichen Gesamtstruktur angehören wie die Hyper-V-Hosts oder Ihre Fabric-Verwaltungstools. Andernfalls könnte ein Fabricadministrator die Kontrolle über den Host-Überwachungsdienst erlangen.
Notfallwiederherstellung	Drei Optionen stehen zur Verfügung: Installieren Sie in jedem Rechenzentrum einen separaten Host-Überwachungsdienstcluster, und autorisieren Sie die Ausführung abgeschirmter virtueller Computer im primären Rechenzentrum sowie in Ausweichrechenzentren. Dadurch wird vermieden, dass der Cluster über ein WAN ausgedehnt werden muss, und Sie können virtuelle Computer so isolieren, dass sie nur am vorgesehenen angegebenen Standort ausgeführt werden. Installieren Sie den Host-Überwachungsdienst in einem Stretched Cluster zwischen (mindestens) zwei Rechenzentren. Das sorgt zwar für Resilienz im Falle eines WAN-Ausfalls, geht aber an die Grenzen des Failoverclusterings. Sie können Workloads nicht an einem einzelnen Standort isolieren. Ein virtueller Computer, der für die Ausführung an einem Standort autorisiert ist, kann auch an jedem anderen Standort ausgeführt werden. Registrieren Sie Ihren Hyper-V-Host bei einem anderen Host-Überwachungsdienst als Failover. Außerdem empfiehlt es sich, jeden Host-Überwachungsdienst durch Exportieren seiner Konfiguration zu sichern, um ihn jederzeit lokal wiederherstellen zu können. Weitere Informationen finden Sie unter Export-HgsServerState bzw. unter Import-HgsServerState.
Schlüssel für den Host-Überwachungsdienst	Ein Host-Überwachungsdienst verwendet zwei asymmetrische Schlüsselpaare (einen Verschlüsselungsschlüssel und einen Signaturschlüssel), die jeweils durch ein SSL-Zertifikat dargestellt werden. Es gibt zwei Optionen, um diese Schlüssel zu generieren: Interne Zertifizierungsstelle: Sie können diese Schlüssel mithilfe Ihrer internen PKI-Infrastruktur generieren. Diese Vorgehensweise bietet sich für eine Rechenzentrumsumgebung an. Öffentlich vertrauenswürdige Zertifizierungsstellen: Verwenden Sie eine Gruppe von Schlüsseln, die von einer öffentlich vertrauenswürdigen Zertifizierungsstelle abgerufen wurden. Dies ist die empfohlene Option für Hoster. Hinweis: Die Verwendung selbstsignierter Zertifikate ist zwar möglich, wird aber außerhalb von Proof-of-Concept-Labs nicht empfohlen. Neben Schlüsseln für den Host-Überwachungsdienst kann ein Hoster auch eigene Schlüssel verwenden. Bei diesem Modell stellen Mandanten ihre eigenen Schlüssel bereit, sodass einige (oder alle) Mandanten über einen eigenen spezifischen Schlüssel für den Host-Überwachungsdienst verfügen können. Diese Option eignet sich für Hoster, die einen Out-of-Band-Prozess bereitstellen, über den Mandanten ihre Schlüssel hochladen können.
Schlüsselspeicher für den Host-Überwachungsdienst	Um höchstmögliche Sicherheit zu gewährleisten, sollten Schlüssel für den Host-Überwachungsdienst ausschließlich in einem Hardwaresicherheitsmodul (HSM) erstellt und gespeichert werden. Wenn Sie keine HSMs verwenden, wird dringend empfohlen, BitLocker auf den Host-Überwachungsdienstservern zu verwenden.

Fabricadministratorplanung für überwachte Hosts

Bereich	Details
Hardware	Hostschlüsselnachweis: Sie können beliebige vorhandene Hardware als überwachten Host verwenden. Es gibt allerdings ein paar Ausnahmen. Unter Compatible hardware with Windows Server Virtualization-based protection of Code Integrity (Hardware, die mit dem virtualisierungsbasierten Schutz der Codeintegrität von Windows Server 2016 kompatibel ist) können Sie überprüfen, ob Ihr Host neue Sicherheitsmechanismen verwenden kann, die ab Windows Server 2016 zur Verfügung stehen. TPM-basierter Nachweis: Sie können beliebige Hardware mit der zusätzlichen Hardwarenachweisqualifikation verwenden, solange sie entsprechend konfiguriert ist. Informationen zur spezifischen Konfiguration finden Sie unter Compatible hardware with Windows Server Virtualization-based protection of Code Integrity (Hardware, die mit dem virtualisierungsbasierten Schutz der Codeintegrität von Windows Server 2016 kompatibel ist). Dies schließt TPM 2.0 sowie UEFI ab Version 2.3.1c ein.
OS	Es empfiehlt sich, die Server Core-Option für das Hyper-V-Hostbetriebssystem zu verwenden.
Folgen für die Leistung	Basierend auf Leistungstests ist mit einer Dichtedifferenz von etwa fünf Prozent zwischen der Ausführung abgeschirmter virtueller Computer und nicht abgeschirmter virtueller Computer zu rechnen. Wenn ein bestimmter Hyper-V-Host also 20 nicht abgeschirmte virtuelle Computer ausführen kann, können Sie davon ausgehen, dass darauf 19 abgeschirmte virtuelle Computer ausgeführt werden können. Überprüfen Sie die Dimensionierung mit Ihren typischen Workloads. Beispielsweise kann es einige Ausreißer mit intensiven schreiborientierten E/A-Workloads geben, die sich stärker auf die Dichtedifferenz auswirken.
Überlegungen zu Filialen	Ab der Windows Server-Version 1709 können Sie eine Fallback-URL für einen virtualisierten Host-Überwachungsdienstserver angeben, der lokal als abgeschirmter virtueller Computer in der Filiale ausgeführt wird. Diese Fallback-URL kann verwendet werden, wenn die Verbindung der Filiale mit den Host-Überwachungsdienstservern im Rechenzentrum unterbrochen wird. In älteren Versionen von Windows Server muss ein Hyper-V-Host, der in einer Filiale ausgeführt wird, über eine Verbindung mit dem Host-Überwachungsdienst verfügen, um abgeschirmte virtuelle Computer einschalten oder eine Livemigration für sie durchführen zu können. Weitere Informationen finden Sie unter Überlegungen zu Filialen.