Verwalten des Host-Überwachungsdiensts

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

Der Host-Überwachungsdienst (HGS) ist das Herzstück der geschützten Fabriclösung. Er muss sicherstellen, dass Hyper-V-Hosts im Fabric dem Hoster oder Unternehmen bekannt sind und vertrauenswürdige Software ausführen, und ist für die Verwaltung der Schlüssel verantwortlich, die zum Starten von abgeschirmten VMs verwendet werden. Wenn ein Mandant sich entscheidet, Ihnen zu vertrauen, um seine abgeschirmten VMs zu hosten, setzt er sein Vertrauen in Ihre Konfiguration und Verwaltung des Host-Überwachungsdiensts. Daher ist es sehr wichtig, bei der Verwaltung des Host-Überwachungsdiensts bewährte Methoden zu befolgen, um die Sicherheit, Verfügbarkeit und Zuverlässigkeit Ihres geschützten Fabrics zu gewährleisten. Die Anleitung in den folgenden Abschnitten behandelt die häufigsten operativen Probleme, mit denen Administratoren von HGS konfrontiert sind.

Einschränken des Administratorzugriffs auf HGS

Aufgrund des sicherheitsrelevanten Charakters des HGS sollten Sie unbedingt sicherstellen, dass die Administratoren äußerst vertrauenswürdige Mitglieder Ihrer Organisation und idealerweise keine Administratoren Ihrer Fabricressourcen sind. Darüber hinaus wird empfohlen, HGS nur über sichere Arbeitsstationen mit sicheren Kommunikationsprotokollen wie WinRM über HTTPS zu verwalten.

Aufgabentrennung

Beim Einrichten des HGS haben Sie die Möglichkeit, eine isolierte Active Directory-Gesamtstruktur nur für den HGS zu erstellen oder den HGS mit einer vorhandenen, vertrauenswürdigen Domäne zu verknüpfen. Diese Entscheidung sowie die Rollen, die Sie den Administratoren in Ihrer Organisation zuweisen, bestimmen die Vertrauensgrenze für HGS. Wer Zugriff auf den HGS hat, ob direkt als Administrator oder indirekt als Administrator einer anderen Komponente (z. B. Active Directory), die den HGS beeinflussen kann, hat die Kontrolle über Ihr geschütztes Fabric. HGS-Administratoren wählen aus, welche Hyper-V-Hosts autorisiert sind, um abgeschirmte VMs auszuführen, und verwalten Zertifikate, die zum Starten abgeschirmter VMs erforderlich sind. Ein Angreifer oder böswilliger Administrator, der Zugriff auf den HGS hat, kann diese Berechtigungen nutzen, um kompromittierte Hosts für die Ausführung abgeschirmter VMs zu autorisieren, einen Denial-of-Service-Angriff durch Entfernen von Schlüsselmaterial zu initiieren und vieles mehr.

Um dieses Risiko zu vermeiden, wird dringend empfohlen, die Überlappung zwischen den Administratoren Ihres HGS (einschließlich der Domäne, mit der der HGS verknüpft ist) und Hyper-V-Umgebungen zu begrenzen. Wenn sichergestellt ist, dass kein Administrator Zugriff auf beide Systeme hat, müsste ein Angreifer zwei verschiedene Konten von zwei Personen kompromittieren, um seine Mission zu erfüllen und die HGS-Richtlinien ändern zu können. Dies bedeutet auch, dass die Domänen- und Unternehmensadministratoren für die beiden Active Directory-Umgebungen nicht dieselbe Person sein sollten, und dass der HGS nicht dieselbe Active Directory-Gesamtstruktur wie Ihre Hyper-V-Hosts verwenden sollte. Jeder, der sich selbst Zugriff auf weitere Ressourcen gewähren kann, stellt ein Sicherheitsrisiko dar.

Verwenden von JEA (Just Enough Administration)

Der HGS verfügt über integrierte JEA-Rollen (Just Enough Administration), um seine sicherere Verwaltung zu ermöglichen. JEA hilft Ihnen dabei, indem es Ihnen ermöglicht, Verwaltungsaufgaben an Benutzer zu delegieren, die keine Administratoren sind. Das bedeutet, dass die Personen, die die HGS-Richtlinien verwalten, nicht unbedingt Administratoren des gesamten Computers oder der kompletten Domäne sein müssen. JEA beschränkt die Befehle, die ein Benutzer in einer PowerShell-Sitzung ausführen kann, und verwendet im Hintergrund ein temporäres lokales Konto (für jede Benutzersitzung eindeutig), um die Befehle auszuführen, die normalerweise eine Erhöhung von Rechten erfordern.

Der HGS wird mit zwei vorkonfigurierten JEA-Rollen ausgeliefert:

• HGS-Administratoren: Benutzer können alle HGS-Richtlinien verwalten, einschließlich der Autorisierung neuer Hosts zum Ausführen von abgeschirmten VMs.
• HGS-Prüfer: Benutzern erhalten nur das Recht, vorhandene Richtlinien zu überwachen. Sie können keine Änderungen an der HGS-Konfiguration vornehmen.

Um JEA zu verwenden, müssen Sie zunächst einen neuen Standardbenutzer erstellen und diesen entweder als Mitglied der Gruppe der HGS-Administratoren oder der Gruppe der HGS-Prüfer festlegen. Wenn Sie mit Install-HgsServer eine neue Gesamtstruktur für den HGS eingerichtet haben, werden diese Gruppen „servicename-Administratoren“ bzw. „servicename-Prüfer“ genannt, wobei servicename der Netzwerkname des HGS-Clusters ist. Wenn Sie den HGS mit einer vorhandenen Domäne verknüpft haben, sollten Sie auf die in Initialize-HgsServer angegebenen Gruppennamen verweisen.

Erstellen von Standardbenutzern für die Rollen „HGS-Administratoren“ und „HGS-Prüfer“

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

Überwachungsrichtlinien mit der Prüferrolle

Führen Sie auf einem Remotecomputer, der über eine Netzwerkverbindung zum HGS verfügt, die folgenden Befehle in PowerShell aus, um die JEA-Sitzung mit den Anmeldeinformationen des Prüfers zu starten. Sie sollten unbedingt beachten, dass das Prüferkonto, da es sich nur um einen Standardbenutzer handelt, nicht für reguläres Windows PowerShell-Remoting, Remotedesktopzugriff auf HGS usw. verwendet werden kann.

Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'

Anschließend können Sie überprüfen, welche Befehle in der Sitzung mit Get-Command zulässig sind, und alle zulässigen Befehle ausführen, um die Konfiguration zu überwachen. Im folgenden Beispiel wird überprüft, welche Richtlinien für den HGS aktiviert sind.

Get-Command

Get-HgsAttestationPolicy

Geben Sie den Befehl Exit-PSSession oder seinen Alias (exit) ein, wenn Sie mit der JEA-Sitzung fertig sind.

Hinzufügen einer neuen Richtlinie zum HGS mithilfe der Administratorrolle

Um eine Richtlinie tatsächlich zu ändern, müssen Sie eine Verbindung mit dem JEA-Endpunkt mit einer Identität herstellen, die zur Gruppe „hgsAdministrators“ gehört. Das folgende Beispiel verdeutlicht, wie Sie eine neue Codeintegritätsrichtlinie unter Verwendung von JEA in den HGS kopieren und dort registrieren können. Die Syntax kann sich von der Ihnen vertrauten Syntax unterscheiden. Damit soll einigen Einschränkungen in JEA Rechnung getragen werden, z. B. dem fehlenden Zugriff auf das gesamte Dateisystem.

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'

# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session

Überwachen des HGS

Ereignisquellen und Weiterleitung

Ereignisse aus HGS werden im Windows-Ereignisprotokoll unter zwei Quellen angezeigt:

• HostGuardianService-Attestation
• HostGuardianService-KeyProtection

Sie können diese Ereignisse anzeigen, indem Sie die Ereignisanzeige öffnen und zu „Microsoft-Windows-HostGuardianService-Attestation“ und „Microsoft-Windows-HostGuardianService-KeyProtection“ navigieren.

In einer großen Umgebung ist es häufig vorzuziehen, Ereignisse an eine zentrale Windows-Ereignissammlung weiterzuleiten, um die Analyse der Ereignisse zu vereinfachen. Weitere Informationen finden Sie in der Dokumentation zur Windows-Ereignisweiterleitung.

Verwenden von System Center Operations Manager

Sie können auch System Center 2016 – Operations Manager verwenden, um den HGS und Ihre überwachten Hosts zu überwachen. Das Management Pack für das geschützte Fabric verfügt über Ereignisüberwachungen, um auf häufige Fehlkonfigurationen zu überprüfen, die zu Ausfallzeiten im Rechenzentrum führen können, einschließlich Hosts, die den Nachweis nicht bestanden haben, und HGS-Server, die Fehler melden.

Zum Einstieg installieren und konfigurieren Sie SCOM 2016, und laden Sie das Management Pack für das geschützte Fabric herunter. Das mitgelieferte Management-Pack-Handbuch erklärt, wie das Management-Pack konfiguriert wird und wie der Umfang seiner Monitore zu verstehen ist.

Sichern und Wiederherstellen des HGS

Planen der Notfallwiederherstellung

Bei der Erstellung Ihrer Notfallwiederherstellungspläne ist es wichtig, die besonderen Anforderungen des Host-Überwachungsdiensts in Ihrem bewachten Fabric zu berücksichtigen. Sollten Sie einige oder alle Ihrer HGS-Knoten verlieren, treten möglicherweise sofortige Verfügbarkeitsprobleme auf, die Benutzer daran hindern, ihre abgeschirmten VMs zu starten. In einem Szenario, in dem der gesamte HGS-Cluster verloren geht, müssen Sie über vollständige Sicherungen der HGS-Konfiguration verfügen, um Ihren HGS-Cluster wiederherzustellen und den normalen Betrieb fortzusetzen. In diesem Abschnitt werden die Schritte erläutert, die zur Vorbereitung eines solchen Szenarios erforderlich sind.

Zunächst ist es wichtig zu verstehen, welche Komponenten beim HGS gesichert werden müssen. HGS speichert verschiedene Informationen, mit denen ermittelt werden kann, welche Hosts zum Ausführen von abgeschirmten VMs autorisiert sind. Dies schließt Folgendes mit ein:

1. Active Directory-Sicherheitsbezeichner für die Gruppen, die vertrauenswürdige Hosts enthalten (bei Verwendung des Active Directory-Nachweises);
2. Eindeutige TPM-Bezeichner für jeden Host in Ihrer Umgebung;
3. TPM-Richtlinien für jede eindeutige Konfiguration des Hosts; und
4. Codeintegritätsrichtlinien, die bestimmen, welche Software auf Ihren Hosts ausgeführt werden darf.

Diese Nachweisartefakte erfordern eine Abstimmung mit den Administratoren Ihres Hostingfabrics, um sie zu erhalten, was es möglicherweise schwierig macht, diese Informationen nach einem Notfall wieder zu beschaffen.

Darüber hinaus benötigt der HGS Zugriff auf zwei oder mehr Zertifikate, die zum Verschlüsseln und Signieren der zum Starten einer abgeschirmten VM erforderlichen Informationen (Schlüsselschutzvorrichtung) verwendet werden. Diese Zertifikate sind bekannt (sie werden von den Besitzern abgeschirmter VMs verwendet, um Ihr Fabric für die Ausführung der VMs zu autorisieren) und müssen nach einem Notfall wiederhergestellt werden, um eine nahtlose Wiederherstellung zu ermöglichen. Sollten Sie den HGS nach einem Notfall nicht mit denselben Zertifikaten wiederherstellen, muss jede VM aktualisiert werden, um Ihre neuen Schlüssel zum Entschlüsseln der Informationen zu autorisieren. Aus Sicherheitsgründen kann nur der VM-Besitzer die VM-Konfiguration aktualisieren, um diese neuen Schlüssel zu autorisieren. Wenn Sie Ihre Schlüssel nach einem Notfall nicht wiederherstellen können, müssen daher alle VM-Besitzer Maßnahmen ergreifen muss, um ihre VMs wieder zum Laufen zu bringen.

Einstellen auf das Schlimmste

Um auf einen vollständigen Verlust des HGS vorbereitet zu sein, müssen Sie zwei Schritte ausführen:

1. Sichern der HGS-Nachweisrichtlinien
2. Sichern der HGS-Schlüssel

Anleitungen zum Ausführen dieser beiden Schritte finden Sie im Abschnitt Sichern des HGS.

Zusätzlich ist es empfehlenswert (aber nicht zwingend erforderlich), dass Sie die Liste der Benutzer sichern, die für die Verwaltung des HGS in der Active Directory-Domäne oder in Active Directory selbst autorisiert sind.

Sicherungen sollten regelmäßig durchgeführt werden, um zu gewährleisten, dass die Informationen auf dem neuesten Stand sind und sicher gespeichert werden, um Manipulationen oder Diebstahl zu verhindern.

Es wird nicht empfohlen, ein komplettes Systemimage eines HGS-Knotens zu sichern oder dessen Wiederherstellung zu versuchen. Wenn Sie Ihren gesamten Cluster verloren haben, empfiehlt es sich, einen brandneuen HGS-Knoten einzurichten und nur den HGS-Status und nicht das gesamte Serverbetriebssystem wiederherzustellen.

Wiederherstellen nach dem Verlust eines Knotens

Wenn Sie einen oder mehrere Knoten (aber nicht alle Knoten) in Ihrem HGS-Cluster verlieren, können Sie einfach Knoten zu Ihrem Cluster hinzufügen. Befolgen Sie dazu die Anleitung im Bereitstellungshandbuch. Die Nachweisrichtlinien werden automatisch synchronisiert, ebenso wie alle Zertifikate, die dem HGS als PFX-Dateien mit begleitenden Kennwörtern bereitgestellt wurden. Für Zertifikate, die dem HGS mithilfe eines Fingerabdrucks hinzugefügt werden (in der Regel nicht exportierbare und hardwaregestützte Zertifikate), müssen Sie sicherstellen, dass jeder neue Knoten Zugriff auf den privaten Schlüssel jedes Zertifikats hat.

Wiederherstellen nach dem Verlust des gesamten Clusters

Wenn Ihr gesamter HGS-Cluster ausfällt und Sie ihn nicht wieder online schalten können, müssen Sie den HGS aus einer Sicherung wiederherstellen. Zum Wiederherstellen des HGS aus einer Sicherung müssen Sie zunächst einen neuen HGS-Cluster gemäß den Anleitungen im Bereitstellungshandbuch einrichten. Es wird dringend empfohlen, ist aber nicht zwingend erforderlich, beim Einrichten der HGS-Wiederherstellungsumgebung denselben Clusternamen zu verwenden, um die Namensauflösung von Hosts zu unterstützen. Die Verwendung desselben Namens vermeidet die Neukonfiguration von Hosts mit neuen Nachweis- und Schlüsselschutz-URLs. Wenn Sie Objekte in der Active Directory-Domäne, die den HGS unterstützt, wiederhergestellt haben, wird empfohlen, die Objekte zu entfernen, die den HGS-Cluster, die Computer, das Dienstkonto und die JEA-Gruppen darstellen, bevor Sie den HGS-Server initialisieren.

Nachdem Sie Ihren ersten HGS-Knoten eingerichtet haben (d. h. nachdem er installiert und initialisiert wurde), befolgen Sie die Verfahren unter Wiederherstellen des HGS aus einer Sicherung, um die Nachweisrichtlinien und öffentlichen Teile der Schlüsselschutzzertifikate wiederherzustellen. Sie müssen die privaten Schlüssel für Ihre Zertifikate gemäß den Anweisungen Ihres Zertifikatsanbieters manuell wiederherstellen (z. B. das Zertifikat in Windows importieren oder den Zugriff auf HSM-gestützte Zertifikate konfigurieren). Nachdem der erste Knoten eingerichtet wurde, können Sie weitere Knoten im Cluster installieren, bis Sie die gewünschte Kapazität und Resilienz erreicht haben.

Sichern des HGS

Der HGS-Administrator sollte für die regelmäßige Sicherung des HGS verantwortlich sein. Eine vollständige Sicherung enthält vertrauliches Schlüsselmaterial, das entsprechend gesichert werden muss. Sollte eine nicht vertrauenswürdige Entität Zugriff auf diese Schlüssel erhalten, könnte sie dieses Material zum Einrichten einer böswilligen HGS-Umgebung verwenden, um abgeschirmte VMs zu kompromittieren.

Sichern der Nachweisrichtlinien Führen Sie zum Sichern der HGS-Nachweisrichtlinien den folgenden Befehl auf jedem funktionierenden HGS-Serverknoten aus. Sie werden aufgefordert, ein Kennwort bereitzustellen. Dieses Kennwort wird verwendet, um alle Zertifikate zu verschlüsseln, die mit einer PFX-Datei (anstelle eines Zertifikatfingerabdrucks) zum HGS hinzugefügt werden.

Export-HgsServerState -Path C:\temp\HGSBackup.xml

Hinweis

Wenn Sie einen Admin-basierten Nachweis verwenden, müssen Sie die Mitgliedschaft in den Sicherheitsgruppen, die vom HGS zum Autorisieren von überwachten Hosts verwendet werden, separat sichern. Der HGS sichert nur die SID der Sicherheitsgruppen, nicht die Mitgliedschaft in diesen Gruppen. Für den Fall, dass diese Gruppen während eines Notfalls verloren gehen, müssen Sie die Gruppen neu erstellen und ihnen jeden überwachten Host erneut hinzufügen.

Sichern von Zertifikaten

Der Befehl Export-HgsServerState sichert zum Zeitpunkt seiner Ausführung alle PFX-basierten Zertifikate, die dem HGS hinzugefügt wurden. Wenn Sie Zertifikate mithilfe eines Fingerabdrucks zum HGS hinzugefügt haben (typisch für nicht exportierbare und hardwaregestützte Zertifikate), müssen Sie die privaten Schlüssel für Ihre Zertifikate manuell sichern. Um zu ermitteln, welche Zertifikate beim HGS registriert sind und manuell gesichert werden müssen, führen Sie den folgenden PowerShell-Befehl auf jedem aktiven HGS-Serverknoten aus.

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

Für jedes der aufgeführten Zertifikate müssen Sie den privaten Schlüssel manuell sichern. Wenn Sie ein softwarebasiertes Zertifikat verwenden, das nicht exportierbar ist, sollten Sie sich an Ihre Zertifizierungsstelle wenden, um sicherzustellen, dass sie über eine Sicherung Ihres Zertifikats verfügt und/oder es bei Bedarf erneut ausstellen kann. Für in Hardwaresicherheitsmodulen erstellte und gespeicherte Zertifikate finden Sie in der Dokumentation für Ihr Gerät eine Anleitung zur Planung der Notfallwiederherstellung.

Sie sollten die Zertifikatsicherungen zusammen mit den Sicherungen Ihrer Nachweisrichtlinien an einem geschützten Speicherort speichern, damit beide Teile zusammen wiederhergestellt werden können.

Zusätzliche Konfiguration, die gesichert werden muss

Der gesicherte HGS-Serverstatus enthält nicht den Namen Ihres HGS-Clusters, keine Informationen aus Active Directory und keine SSL-Zertifikate, die zum Sichern der Kommunikation mit den HGS-APIs verwendet werden. Diese Einstellungen sind wichtig für die Konsistenz, aber nicht zwingend erforderlich, um Ihren HGS-Cluster nach einem Notfall wieder online zu schalten.

Um den Namen des HGS-Diensts zu erfassen, führen Sie Get-HgsServer aus, und notieren Sie sich den Flatnamen in den Nachweis- und Schlüsselschutz-URLs. Wenn die Nachweis-URL beispielsweise „https://hgs.contoso.com/Attestation“ lautet, ist „hgs“ der Name des HGS-Diensts.

Die vom HGS verwendete Active Directory-Domäne sollte wie jede andere Active Directory-Domäne verwaltet werden. Beim Wiederherstellen des HGS nach einem Notfall müssen Sie nicht unbedingt genau die Objekte neu erstellen, die in der aktuellen Domäne vorhanden sind. Es erleichtert jedoch die Wiederherstellung, wenn Sie Active Directory sichern und eine Liste der JEA-Benutzer führen, die zum Verwalten des Systems autorisiert sind, sowie der Mitgliedschaften in allen Sicherheitsgruppen, die vom Admin-basierten Nachweis verwendet werden, um überwachte Hosts zu autorisieren.

Führen Sie den folgenden Befehl in PowerShell aus, um den Fingerabdruck der für den HGS konfigurierten SSL-Zertifikate zu identifizieren. Anschließend können Sie diese SSL-Zertifikate gemäß den Anweisungen Ihres Zertifikatanbieters sichern.

Get-WebBinding -Protocol https | Select-Object certificateHash

Wiederherstellung des HGS aus einer Sicherung

In den folgenden Schritten wird beschrieben, wie Sie HGS-Einstellungen aus einer Sicherung wiederherstellen. Die Schritte sind sowohl für Situationen relevant, in denen Sie versuchen, an Ihren bereits ausgeführten HGS-Instanzen vorgenommene Änderungen rückgängig zu machen, als auch in Situationen, in denen Sie nach einem vollständigen Verlust des vorherigen Clusters einen brandneuen HGS-Cluster erstellen.

Einrichten eines Ersatz-HGS-Clusters

Bevor Sie den HGS wiederherstellen können, benötigen Sie einen initialisierten HGS-Cluster, in dem Sie die Konfiguration wiederherstellen können. Wenn Sie lediglich Einstellungen importieren, die in einen vorhandenen (ausgeführten) Cluster versehentlich gelöscht wurden, können Sie diesen Schritt überspringen. Wenn Sie die Wiederherstellung nach einem vollständigen Verlust des HGS durchführen, müssen Sie mindestens einen HGS-Knoten gemäß den Anweisungen im Bereitstellungshandbuch installieren und initialisieren.

Insbesondere müssen Sie diese Schritte ausführen:

1. Einrichten der HGS-Domäne oder Verknüpfen des HGS mit einer vorhandenen Domäne
2. Initialisieren Sie den HGS-Server mit Ihren vorhandenen Schlüsseln oder einem Satz temporärer Schlüssel. Sie können die temporären Schlüssel entfernen, nachdem Sie Ihre tatsächlichen Schlüssel aus den HGS-Sicherungsdateien importiert haben.
3. Importieren von HGS-Einstellungen aus Ihrer Sicherung, um die vertrauenswürdigen Hostgruppen, Codeintegritätsrichtlinien, TPM-Baselines und TPM-Bezeichner wiederherzustellen

Tipp

Der neue HGS-Cluster muss nicht dieselben Zertifikate, Dienstnamen oder Domänen wie die HGS-Instanz verwenden, aus der die Sicherungsdatei exportiert wurde.

Importieren von Einstellungen aus einer Sicherung

Führen Sie den folgenden Befehl auf einem initialisierten HGS-Serverknoten aus, um Nachweisrichtlinien, PFX-basierte Zertifikate und die öffentlichen Schlüssel von Nicht-PFX-Zertifikaten auf Ihrem HGS-Knoten aus einer Sicherungsdatei wiederherzustellen. Sie werden aufgefordert, das Kennwort einzugeben, das Sie beim Erstellen der Sicherung angegeben haben.

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

Wenn Sie nur Admin-basierte Nachweisrichtlinien oder TPM-basierte Nachweisrichtlinien importieren möchten, können Sie dazu die Flags -ImportActiveDirectoryModeState oder -ImportTpmModeState für Import-HgsServerState angeben.

Stellen Sie sicher, dass das neueste kumulative Update für Windows Server 2016 installiert ist, bevor Sie Import-HgsServerState ausführen. Andernfalls kann es zu einem Importfehler kommen.

Hinweis

Wenn Sie Richtlinien auf einem vorhandenen HGS-Knoten wiederherstellen, auf dem bereits eine oder mehrere dieser Richtlinien installiert sind, zeigt der Importbefehl für jede duplizierte Richtlinie einen Fehler an. Dies ist ein erwartetes Verhalten und kann in den meisten Fällen problemlos ignoriert werden.

Erneutes Installieren privater Schlüssel für Zertifikate

Wurden Zertifikate, die auf dem HGS, von dem die Sicherung erstellt wurde, verwendet wurden, unter Verwendung von Fingerabdrücken hinzugefügt, wird nur der öffentliche Schlüssel dieser Zertifikate in die Sicherungsdatei aufgenommen. Dies bedeutet, dass Sie die privaten Schlüssel für jedes dieser Zertifikate manuell installieren und/oder Zugriff darauf gewähren müssen, bevor der HGS Anforderungen von Hyper-V-Hosts verarbeiten kann. Die zum Ausführen dieses Schritts erforderlichen Aktionen variieren je nachdem, wie Ihr Zertifikat ursprünglich ausgestellt wurde. Bei softwaregestützten Zertifikaten, die von einer Zertifizierungsstelle ausgestellt wurden, müssen Sie sich an Ihre Zertifizierungsstelle wenden, um den privaten Schlüssel abzurufen und gemäß deren Anweisungen auf jedem HGS-Knoten zu installieren. Wenn Sie hardwaregestützte Zertifikate verwenden, müssen Sie die Dokumentation des Herstellers Ihres Hardwaresicherheitsmoduls konsultieren, und die erforderlichen Treiber auf jedem HGS-Knoten installieren, um eine Verbindung zum HSM herzustellen und jedem Computer Zugriff auf den privaten Schlüssel zu gewähren.

Zur Erinnerung: Zertifikate, die dem HGS mithilfe von Fingerabdrücken hinzugefügt werden, erfordern eine manuelle Replikation der privaten Schlüssel auf jeden Knoten. Sie müssen diesen Schritt auf jedem zusätzlichen Knoten wiederholen, den Sie dem wiederhergestellten HGS-Cluster hinzufügen.

Überprüfen importierter Nachweisrichtlinien

Nachdem Sie Ihre Einstellungen aus einer Sicherung importiert haben, empfiehlt es sich, alle importierten Richtlinien mithilfe von Get-HgsAttestationPolicy genau zu überprüfen, um sicherzustellen, dass nur die vertrauenswürdigen Hosts, denen Sie die Ausführung abgeschirmter VMs erlauben, den Nachweis erfolgreich erbringen können. Wenn Sie Richtlinien finden, die ihrem Sicherheitsstatus nicht mehr entsprechen, können Sie diese deaktivieren oder entfernen.

Ausführen einer Diagnose zum Überprüfen des Systemstatus

Nach Abschluss der Einrichtung und Wiederherstellung des Zustands Ihres HGS-Knotens sollten Sie mit dem HGS-Diagnosetool den Systemsstatus überprüfen. Führen Sie hierzu den folgenden Befehl auf dem HGS-Knoten aus, auf dem Sie die Konfiguration wiederhergestellt haben:

Get-HgsTrace -RunDiagnostics

Wenn das „Gesamtergebnis“ nicht „Bestanden“ lautet, sind zusätzliche Schritte erforderlich, um die Konfiguration des Systems abzuschließen. Überprüfen Sie die Meldungen, die in den Untertests gemeldet wurden, bei denen ein Fehler aufgetreten ist, um weitere Informationen zu finden.

Patchen des HGS

Es ist wichtig, dass Sie die Knoten Ihres Host-Überwachungsdiensts auf dem neuesten Stand halten, indem Sie das neueste kumulative Update immer sofort nach dessen Veröffentlichung installieren. Wenn Sie einen brandneuen HGS-Knoten einrichten, wird dringend empfohlen, vor dem Installieren oder Konfigurieren der HGS-Rolle alle verfügbaren Updates zu installieren. Dadurch wird sichergestellt, dass alle neuen oder geänderten Funktionen sofort wirksam werden.

Beim Patchen Ihres geschützten Fabrics wird dringend empfohlen, zunächst alle Hyper-V-Hosts zu aktualisieren, bevor Sie den HGS aktualisieren. Dadurch soll sichergestellt werden, dass alle Änderungen an den Nachweisrichtlinien für den HGS vorgenommen werden, nachdem die Hyper-V-Hosts aktualisiert wurden, um die für sie erforderlichen Informationen bereitzustellen. Wenn ein Update das Verhalten von Richtlinien ändert, werden diese nicht automatisch aktiviert, um eine Unterbrechung Ihres Fabrics zu vermeiden. Für solche Updates müssen Sie die Anweisungen im folgenden Abschnitt befolgen, um die neuen oder geänderten Nachweisrichtlinien zu aktivieren. Wir empfehlen Ihnen, die Versionshinweise für Windows Server und alle kumulativen Updates, die Sie installieren, zu lesen, um zu überprüfen, ob die Richtlinienupdates erforderlich sind.

Aktualisierungen, die Richtlinienaktivierung erfordern

Wenn durch ein Update für den HGS das Verhalten einer Nachweisrichtlinie festgelegt oder wesentlich geändert wird, ist ein zusätzlicher Schritt erforderlich, um die geänderte Richtlinie zu aktivieren. Richtlinienänderungen werden erst nach dem Exportieren und Importieren des HGS-Status vorgenommen. Sie sollten die neuen oder geänderten Richtlinien erst aktivieren, nachdem Sie das kumulative Update auf allen Hosts und allen HGS-Knoten in Ihrer Umgebung installiert haben. Nachdem alle Computer aktualisiert wurden, führen Sie die folgenden Befehle auf einem beliebigen HGS-Knoten aus, um den Upgradevorgang auszulösen:

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password

Wenn eine neue Richtlinie eingeführt wurde, wird sie standardmäßig deaktiviert. Um die neue Richtlinie zu aktivieren, suchen Sie sie zuerst in der Liste der Microsoft-Richtlinien (mit dem Präfix „HGS_“), und aktivieren Sie sie dann mit den folgenden Befehlen:

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Verwalten von Nachweisrichtlinien

Der HGS verwaltet mehrere Nachweisrichtlinien, die die Mindestanforderungen definieren, die ein Host erfüllen muss, um als „fehlerfrei“ zu gelten und die Ausführung abgeschirmter VMs zuzulassen. Einige dieser Richtlinien werden von Microsoft definiert, andere werden von Ihnen hinzugefügt, um die zulässigen Codeintegritätsrichtlinien, TPM-Baselines und Hosts in Ihrer Umgebung zu definieren. Die regelmäßige Wartung dieser Richtlinien ist erforderlich, um sicherzustellen, dass Hosts weiterhin ordnungsgemäß nachweisen können, während Sie sie aktualisieren und ersetzen, und um sicherzustellen, dass nicht vertrauenswürdige Hosts oder Konfigurationen am erfolgreichen Nachweis gehindert werden.

Für den Admin-basierten Nachweis gibt es nur eine Richtlinie, die bestimmt, ob ein Host fehlerfrei ist: Die Mitgliedschaft in einer bekannten, vertrauenswürdigen Sicherheitsgruppe. Der TPM-Nachweis ist komplizierter und umfasst verschiedene Richtlinien, um den Code und die Konfiguration eines Systems zu messen, bevor ermittelt wird, ob es fehlerfrei ist.

Ein einzelner HGS kann gleichzeitig mit Active Directory- und TPM-Richtlinien konfiguriert werden, aber der Dienst überprüft nur die Richtlinien für den aktuellen Modus, für den er konfiguriert ist, wenn ein Host versucht, einen Nachweis zu erbringen. Führen Sie Get-HgsServer aus, um den Modus ihres HGS-Servers zu überprüfen.

Standardrichtlinien

Für den TPM-basierten Nachweis gibt es mehrere integrierte Richtlinien, die für den HGS konfiguriert sind. Einige dieser Richtlinien sind „gesperrt“, was bedeutet, dass sie aus Sicherheitsgründen nicht deaktiviert werden können. In der folgenden Tabelle wird der Zweck der einzelnen Standardrichtlinien erläutert.

Richtlinienname	Zweck
Hgs_SecureBootEnabled	Erfordert, dass für Hosts der sichere Start aktiviert ist. Dies ist zum Messen der Startbinärdateien und anderer UEFI-gesperrter Einstellungen erforderlich.
Hgs_UefiDebugDisabled	Stellt sicher, dass für Hosts kein Kerneldebugger aktiviert ist. Debugger im Benutzermodus werden mit Codeintegritätsrichtlinien blockiert.
Hgs_SecureBootSettings	Negative Richtlinie, um sicherzustellen, dass Hosts mindestens eine (vom Administrator definierten) TPM-Baseline erfüllen.
Hgs_CiPolicy	Negative Richtlinie, um sicherzustellen, dass Hosts eine der vom Administrator definierten CI-Richtlinien verwenden.
Hgs_HypervisorEnforcedCiPolicy	Erfordert, dass die Codeintegritätsrichtlinie vom Hypervisor erzwungen wird. Wenn Sie diese Richtlinie deaktivieren, wird der Schutz vor Angriffen im Kernelmodus auf Codeintegritätsrichtlinien geschwächt.
Hgs_FullBoot	Stellt sicher, dass der Host nicht aus dem Standby oder Ruhezustand fortgesetzt wurde. Hosts müssen ordnungsgemäß neu gestartet oder heruntergefahren werden, um diese Richtlinie zu bestehen.
Hgs_VsmIdkPresent	Erfordert, dass auf dem Host virtualisierungsbasierte Sicherheit ausgeführt wird. Der IDK stellt den Schlüssel dar, der zum Verschlüsseln von Informationen erforderlich ist, die an den sicheren Speicherplatz des Hosts zurückgesendet werden.
Hgs_PageFileEncryptionEnabled	Erfordert die Verschlüsselung von Pagedateien auf dem Host. Das Deaktivieren dieser Richtlinie kann zu einer Offenlegung von Informationen führen, wenn eine unverschlüsselte Pagedatei auf Mandantengeheimnisse überprüft wird.
Hgs_BitLockerEnabled	Erfordert, dass BitLocker auf dem Hyper-V-Host aktiviert ist. Diese Richtlinie ist aus Leistungsgründen standardmäßig deaktiviert und sollte nicht aktiviert werden. Diese Richtlinie hat keinen Einfluss auf die Verschlüsselung der abgeschirmten VMs selbst.
Hgs_IommuEnabled	Erfordert, dass auf dem Host ein IOMMU-Gerät verwendet wird, um Direct Memory Access (DMA)-Angriffe zu verhindern. Das Deaktivieren dieser Richtlinie und die Verwendung von Hosts ohne aktiviertes IOMMU kann Mandanten-VM-Geheimnisse für direkte Speicherangriffe verfügbar machen.
Hgs_NoHibernation	Erfordert, dass der Ruhezustand auf dem Hyper-V-Host deaktiviert ist. Wird diese Richtlinie deaktiviert, können Hosts Arbeitsspeicher einer abgeschirmten VM in einer unverschlüsselten Ruhezustanddatei speichern.
Hgs_NoDumps	Erfordert, dass Speicherabbilder auf dem Hyper-V-Host deaktiviert sind. Wenn Sie diese Richtlinie deaktivieren, wird empfohlen, die Abbildverschlüsselung zu konfigurieren, um zu verhindern, dass Arbeitsspeicher einer abgeschirmten VM in unverschlüsselten Absturzabbilddateien gespeichert wird.
Hgs_DumpEncryption	Erfordert, dass Speicherabbilder, wenn sie auf dem Hyper-V-Host aktiviert sind, mit einem Verschlüsselungsschlüssel verschlüsselt werden, der vom HGS als vertrauenswürdig eingestuft wird. Diese Richtlinie gilt nicht, wenn auf dem Host keine Abbilder aktiviert sind. Wenn sowohl diese Richtlinie als auch Hgs_NoDumps deaktiviert sind, kann Arbeitsspeicher einer abgeschirmten VM in einer unverschlüsselten Abbilddatei gespeichert werden.
Hgs_DumpEncryptionKey	Negative Richtlinie, um sicherzustellen, dass Hosts, die so konfiguriert sind, dass sie Speicherabbilder zulassen, einen vom Administrator definierten Verschlüsselungsschlüssel für Speicherabbilddateien verwenden, der dem HGS bekannt ist. Diese Richtlinie gilt nicht, wenn Hgs_DumpEncryption deaktiviert ist.

Autorisieren neuer überwachter Hosts

Um einen neuen Host zu autorisieren, ein geschützter Host zu werden (z. B. erfolgreich Nachweise zu erbringen), muss der HGS dem Host und (wenn er für die Verwendung des TPM-basierten Nachweises konfiguriert ist) der darauf ausgeführten Software vertrauen. Die Schritte zum Autorisieren eines neuen Hosts unterscheiden sich je nach dem Nachweismodus, der für den HGS derzeit konfiguriert ist. Um den Nachweismodus für Ihr geschütztes Fabric zu überprüfen, führen Sie Get-HgsServer auf einem beliebigen HGS-Knoten aus.

Softwarekonfiguration

Stellen Sie sicher, dass auf dem neuen Hyper-V-Host Windows Server 2016 Datacenter Edition installiert ist. Windows Server 2016 Standard kann keine abgeschirmten VMs in einem geschützten Fabric ausführen. Der Host kann mit Desktopdarstellung oder Server Core installiert sein.

Auf einem Server mit Desktopdarstellung und Server Core müssen Sie die Serverrollen „Hyper-V“ und „Hyper-V-Unterstützung für die Host-Überwachung“ installieren:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Admin-basierter Nachweis

Wenn Sie bei Verwendung des Admin-basierten Nachweises einen neuen Host im HGS registrieren möchten, müssen Sie den Host zunächst einer Sicherheitsgruppe in der Domäne hinzufügen, mit der er verknüpft ist. In der Regel verfügt jede Domäne über eine Sicherheitsgruppe für überwachte Hosts. Wenn Sie diese Gruppe bereits beim HGS registriert haben, müssen Sie den Host nur neu starten, um seine Gruppenmitgliedschaft zu aktualisieren.

Sie können überprüfen, welche Sicherheitsgruppen von HGS als vertrauenswürdig eingestuft werden, indem Sie den folgenden Befehl ausführen:

Get-HgsAttestationHostGroup

Um eine neue Sicherheitsgruppe beim HGS zu registrieren, erfassen Sie zunächst die Sicherheits-ID (SID) der Gruppe in der Domäne des Hosts, und registrieren Sie die SID beim HGS.

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

Anweisungen zum Einrichten der Vertrauensstellung zwischen der Hostdomäne und dem HGS finden Sie im Bereitstellungshandbuch.

TPM-basierter Nachweis

Wenn der HGS im TPM-Modus konfiguriert ist, müssen Hosts alle gesperrten Richtlinien und „aktivierten“ Richtlinien mit dem Präfix „Hgs_“ sowie mindestens eine TPM-Baseline, einen TPM-Bezeichner und eine Codeintegritätsrichtlinie bestehen. Jedes Mal, wenn Sie einen neuen Host hinzufügen, müssen Sie den neuen TPM-Bezeichner beim HGS registrieren. Solange auf dem Host dieselbe Software ausgeführt (und dieselbe Codeintegritätsrichtlinie gilt) sowie die gleiche TPM-Baseline wie auf einem anderen Host in Ihrer Umgebung ausgeführt wird, müssen Sie keine neuen CI-Richtlinien oder Baselines hinzufügen.

Hinzufügen des TPM-Bezeichners für einen neuen Host Führen Sie auf dem neuen Host den folgenden Befehl aus, um den TPM-Bezeichner zu erfassen. Stellen Sie sicher, dass Sie für den Host einen eindeutigen Namen angeben, der Ihnen hilft, ihn im HGS nachzuschlagen. Sie benötigen diese Informationen, wenn Sie den Host außer Betrieb setzen oder verhindern möchten, dass darauf abgeschirmte VMs im HGS ausgeführt werden.

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

Kopieren Sie diese Datei auf Ihren HGS-Server, und führen Sie dann den folgenden Befehl aus, um den Host beim HGS zu registrieren.

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

Hinzufügen einer neuen TPM-Baseline Wenn auf dem neuen Host eine neue Hardware- oder Firmwarekonfiguration für Ihre Umgebung ausgeführt wird, müssen Sie möglicherweise eine neue TPM-Baseline erstellen. Führen Sie zu diesem Zweck den folgenden Befehl auf dem Host aus.

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

Hinweis

Wenn Sie eine Fehlermeldung erhalten, die besagt, dass ihr Host die Überprüfung nicht bestanden hat und keinen erfolgreichen Nachweis erbringen kann, seien Sie unbesorgt. Dies ist eine Voraussetzungsprüfung, um sicherzustellen, dass Ihr Host abgeschirmte VMs ausführen kann, und bedeutet wahrscheinlich, dass noch keine Codeintegritätsrichtlinie oder andere erforderliche Einstellungen angewendet wurden. Lesen Sie die Fehlermeldung, nehmen Sie alle darin vorgeschlagenen Änderungen vor, und versuchen Sie es dann erneut. Alternativ können Sie die Überprüfung zu diesem Zeitpunkt überspringen, indem Sie dem Befehl das Flag -SkipValidation hinzufügen.

Kopieren Sie die TPM-Baseline auf Ihren HGS-Server, und registrieren Sie sie dann mit dem folgenden Befehl. Wir empfehlen Ihnen, eine Namenskonvention zu verwenden, die Ihnen hilft, die Hardware- und Firmwarekonfiguration dieser Hyper-V-Hostklasse zu verstehen.

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

Hinzufügen einer neuen Codeintegritätsrichtlinie Wenn Sie die Codeintegritätsrichtlinie, die auf Ihren Hyper-V-Hosts ausgeführt wird, geändert haben, müssen Sie die neue Richtlinie beim HGS registrieren, bevor diese Hosts erfolgreich den Nachweis erbringen können. Erfassen Sie auf einem Referenzhost, der als Masterimage für die vertrauenswürdigen Hyper-V-Computer in Ihrer Umgebung dient, mithilfe des Befehls New-CIPolicy eine neue CI-Richtlinie. Es wird empfohlen, die FilePublisher-Ebene und das Hash-Fallback für Hyper-V-Host-CI-Richtlinien zu verwenden. Sie sollten zunächst eine CI-Richtlinie im Überwachungsmodus erstellen, um sicherzustellen, dass alles wie erwartet funktioniert. Nachdem Sie eine Beispielworkload auf dem System überprüft haben, können Sie die Richtlinie erzwingen und die erzwungene Version in den HGS kopieren. Eine vollständige Liste der Konfigurationsoptionen für Codeintegritätsrichtlinien finden Sie in der Device Guard-Dokumentation.

# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete

# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

Nachdem Sie Ihre Richtlinie erstellt, getestet und erzwungen haben, kopieren Sie die Binärdatei (.p7b) auf Ihren HGS-Server, und registrieren Sie die Richtlinie.

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'

Hinzufügen eines Speicherabbild-Verschlüsselungsschlüssels

Wenn die Richtlinie Hgs_NoDumps deaktiviert und die Richtlinie Hgs_DumpEncryption aktiviert ist, dürfen überwachte Hosts Speicherabbilder (z. B. Absturzabbilder) aktivieren, solange diese Abbilder verschlüsselt sind. Überwachte Hosts bestehen den Nachweis nur, wenn Speicherabbilder deaktiviert sind oder wenn sie sie mit einem Schlüssel verschlüsseln, der dem HGS bekannt ist. Standardmäßig sind keine Abbildverschlüsselungsschlüssel für den HGS konfiguriert.

Um einen Abbildverschlüsselungsschlüssel zum HGS hinzuzufügen, verwenden Sie das Cmdlet Add-HgsAttestationDumpPolicy, um dem HGS den Hash Ihres Abbildverschlüsselungsschlüssels bereitzustellen. Wenn Sie eine TPM-Baseline auf einem mit der Abbildverschlüsselung konfigurierten Hyper-V-Host erfassen, ist der Hash im tcglog enthalten und kann für das Cmdlet Add-HgsAttestationDumpPolicy bereitgestellt werden.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

Alternativ können Sie die Zeichenfolgendarstellung des Hashs direkt für das Cmdlet bereitstellen.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

Stellen Sie sicher, dass Sie jeden eindeutigen Abbildverschlüsselungsschlüssel zum HGS hinzufügen, wenn Sie sich für die Verwendung verschiedener Schlüssel in Ihrem geschützten Fabric entscheiden. Hosts, die Speicherabbilder mit einem Schlüssel verschlüsseln, der dem HGS nicht bekannt ist, bestehen den Nachweis nicht.

Weitere Informationen zum Konfigurieren der Abbildverschlüsselung auf Hosts finden Sie in der Hyper-V-Dokumentation.

Überprüfen, ob das System den Nachweis bestanden hat

Nachdem Sie die erforderlichen Informationen beim HGS registriert haben, sollten Sie überprüfen, ob der Host den Nachweis besteht. Führen Sie auf dem neu hinzugefügten Hyper-V-Host Set-HgsClientConfiguration aus, und geben Sie die richtigen URLs für Ihren HGS-Cluster an. Diese URLs können abgerufen werden, indem Sie auf einem beliebigen HGS-Knoten Get-HgsServer ausführen.

Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'

Wenn der resultierende Status nicht „IsHostGuarded: True“ lautet, müssen Sie Probleme mit der Konfiguration beheben. Führen Sie auf dem Host, auf dem der Nachweis fehlgeschlagen ist, den folgenden Befehl aus, um einen detaillierten Bericht über Probleme zu erhalten, der Ihnen beim Beheben des fehlerhaften Nachweises helfen kann.

Get-HgsTrace -RunDiagnostics -Detailed

Wichtig

Wenn Sie Windows Server 2019 oder Windows 10, Version 1809, mit Codeintegritätsrichtlinien verwenden, gibt Get-HgsTrace möglicherweise einen Fehler für die Diagnose Aktive Codeintegritätsrichtlinie zurück. Sie können dieses Ergebnis ruhig ignorieren, wenn es sich um den einzigen Fehler in der Diagnose handelt.

Überprüfen von Nachweisrichtlinien

Führen Sie die folgenden Befehle auf jedem HGS-Knoten aus, um den aktuellen Status der auf dem HGS konfigurierten Richtlinien zu überprüfen:

# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy

Wenn Sie feststellen, dass eine Richtlinie aktiviert ist, die Ihre Sicherheitsanforderung nicht mehr erfüllt (z. B. eine alte Codeintegritätsrichtlinie, die jetzt als unsicher eingestuft wird), können Sie sie deaktivieren, indem Sie den Namen der Richtlinie im folgenden Befehl ersetzen:

Disable-HgsAttestationPolicy -Name 'PolicyName'

Ebenso können Sie Enable-HgsAttestationPolicy verwenden, um eine Richtlinie wieder zu aktivieren.

Wenn Sie eine Richtlinie nicht mehr benötigen und sie von allen HGS-Knoten entfernen möchten, führen Sie Remove-HgsAttestationPolicy -Name 'PolicyName' aus, um die Richtlinie endgültig zu löschen.

Ändern der Nachweismodi

Wenn Sie Ihr geschütztes Fabric unter Verwendung des Admin-basierten Nachweises gestartet haben, sollten Sie auf den deutlich stärkeren TPM-Nachweismodus upgraden, sobald Sie über genügend TPM 2.0-kompatible Hosts in Ihrer Umgebung verfügen. Wenn Sie zum Wechseln bereit sind, können Sie alle Nachweisartefakte (CI-Richtlinien, TPM-Baselines und TPM-Bezeichner) im HGS vorab laden, während Sie den HGS weiterhin mit Admin-basiertem Nachweis ausführen. Befolgen Sie dazu einfach die Anweisungen im Abschnitt Autorisieren eines neuen überwachten Hosts.

Nachdem Sie alle Ihre Richtlinien zum HGS hinzugefügt haben, besteht der nächste Schritt darin, einen synthetischen Nachweisversuch auf Ihren Hosts auszuführen, um zu ermitteln, ob sie den Nachweis im TPM-Modus bestehen würden. Dies wirkt sich nicht auf den aktuellen Betriebszustand des HGS aus. Die folgenden Befehle müssen auf einem Computer ausgeführt werden, der Zugriff auf alle Hosts in der Umgebung und mindestens einen HGS-Knoten hat. Wenn dies durch Ihre Firewall oder andere Sicherheitsrichtlinien verhindert wird, können Sie diesen Schritt überspringen. Wenn möglich, sollten Sie den synthetischen Nachweis auszuführen, um einen guten Hinweis darauf zu erhalten, ob ein Wechsel in den TPM-Modus zu Ausfallzeiten für Ihre VMs führt.

# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'

# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode

Überprüfen Sie nach Abschluss der Diagnose die ausgegebenen Informationen, um festzustellen, ob irgendwelche Hosts den Nachweis im TPM-Modus nicht bestanden hätten. Führen Sie die Diagnose erneut aus, bis Sie von jedem Host ein „Bestanden“ erhalten, und fahren Sie dann damit fort, den HGS in den TPM-Modus zu wechseln.

Der Wechsel in den TPM-Modus dauert nur eine Sekunde. Führen Sie den folgenden Befehl auf einem beliebigen HGS-Knoten aus, um den Nachweismodus zu aktualisieren.

Set-HgsServer -TrustTpm

Wenn Probleme auftreten und sie zurück in den Active Directory-Modus wechseln müssen, können Sie dies tun, indem Sie Set-HgsServer -TrustActiveDirectory ausführen.

Nachdem Sie bestätigt haben, dass alles wie erwartet funktioniert, sollten Sie alle vertrauenswürdigen Active Directory-Hostgruppen aus dem HGS entfernen und die Vertrauensstellung zwischen dem HGS und den Fabricdomänen entfernen. Wenn Sie die Active Directory-Vertrauensstellung beibehalten, riskieren Sie, dass jemand die Vertrauensstellung erneut aktiviert und den HGS in den Active Directory-Modus wechselt, sodass nicht vertrauenswürdiger Code ungeprüft auf Ihren überwachten Hosts ausgeführt werden kann.

Schlüsselverwaltung

Die geschützte Fabriclösung verwendet mehrere öffentliche/private Schlüsselpaare, um die Integrität verschiedener Komponenten in der Lösung zu überprüfen und Mandantengeheimnisse zu verschlüsseln. Für den Host-Überwachungsdienst sind mindestens zwei Zertifikate (mit öffentlichen und privaten Schlüsseln) konfiguriert, die zum Signieren und Verschlüsseln der Schlüssel zum Starten abgeschirmter VMs verwendet werden. Diese Schlüssel müssen sorgfältig verwaltet werden. Wenn der private Schlüssel von einem Angreifer abgerufen wird, kann er die Abschirmung aller VMs aufheben, die in Ihrem Fabric ausgeführt werden, oder einen betrügerischen HGS-Cluster einrichten, der schwächere Nachweisrichtlinien verwendet, um die von Ihnen eingerichteten Schutzmaßnahmen zu umgehen. Wenn Sie die privaten Schlüssel während eines Notfalls verlieren und in keiner Sicherung finden, müssen Sie ein neues Schlüsselpaar einrichten und die Schlüssel erneut an jede VM vergeben lassen, um Ihre neuen Zertifikate zu autorisieren.

In diesem Abschnitt werden allgemeine Themen zur Schlüsselverwaltung behandelt, mit denen Sie Ihre Schlüssel so konfigurieren können, dass sie funktionsfähig und sicher sind.

Hinzufügen neuer Schlüssel

Der HGS muss zwar mit einem Schlüsselsatz initialisiert werden, Sie können dem HGS aber später mehr als einen Verschlüsselungs- und Signaturschlüssel hinzufügen. Die beiden häufigsten Gründe, warum Sie dem HGS neue Schlüssel hinzufügen möchten, sind:

1. Zur Unterstützung von „Bring Your Own Key“-Szenarien, in denen Mandanten ihre privaten Schlüssel in Ihr Hardwaresicherheitsmodul kopieren und nur die eigenen Schlüssel autorisieren, ihre abgeschirmten VMs zu starten.
2. Als Ersatz der vorhandenen Schlüssel für den HGS, indem Sie zuerst die neuen Schlüssel hinzufügen und beide Schlüsselsätze beibehalten, bis jede VM-Konfiguration auf die neuen Schlüssel aktualisiert wurde.

Der Prozess zum Hinzufügen neuer Schlüssel unterscheidet sich je nach dem Typ des verwendeten Zertifikats.

Option 1: Hinzufügen eines in einem HSM gespeicherten Zertifikats

Unser empfohlener Ansatz zum Absichern von HGS-Schlüsseln ist die Verwendung von Zertifikaten, die in einem Hardwaresicherheitsmodul (HSM) erstellt wurden. HSM stellen sicher, dass die Verwendung Ihrer Schlüssel an den physischen Zugriff auf ein sicherheitsrelevantes Gerät in Ihrem Rechenzentrum gebunden ist. Jedes HSM ist anders und verfügt über ein eigenes Verfahren zum Erstellen und Registrieren von Zertifikaten beim HGS. Die folgenden Schritte dienen als grobe Anleitungen für die Verwendung von HSM-gesicherten Zertifikaten. Genaue Schritte und Funktionen finden Sie in der Dokumentation Ihres HSM-Herstellers.

1. Installieren Sie die HSM-Software auf jedem HGS-Knoten in Ihrem Cluster. Je nachdem, ob Sie über ein Netzwerk oder ein lokales HSM-Gerät verfügen, müssen Sie das HSM möglicherweise so konfigurieren, dass es Ihrem Computer Zugriff auf den Schlüsselspeicher gewährt.

2. Erstellen von zwei Zertifikaten im HSM mit 2048-Bit-RSA-Schlüsseln für Verschlüsselung und Signatur

   1. Erstellen eines Verschlüsselungszertifikats mit der Schlüsselverwendungseigenschaft Datenverschlüsselung in Ihrem HSM
   2. Erstellen eines Signaturzertifikats mit der Schlüsselverwendungseigenschaft Digitale Signatur in Ihrem HSM

3. Installieren Sie die Zertifikate gemäß den Anleitungen Ihres HSM-Herstellers im lokalen Zertifikatspeicher jedes HGS-Knotens.

4. Wenn Ihr HSM differenzierte Berechtigungen verwendet, um bestimmten Anwendungen oder Benutzern die Berechtigung zur Verwendung des privaten Schlüssels zu erteilen, müssen Sie Ihrem gruppenverwalteten HGS-Dienstkonto Zugriff auf das Zertifikat gewähren. Zum Ermitteln des Namens des HGS-gMSA-Kontos führen Sie (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName aus.

5. Fügen Sie die Signatur- und Verschlüsselungszertifikate zum HGS hinzu, indem Sie in den folgenden Befehlen die Fingerabdrücke durch die Fingerabdrücke Ihrer Zertifikate ersetzen:

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"
   

Option 2: Hinzufügen von nicht exportierbaren Softwarezertifikaten

Wenn Sie über ein softwaregestütztes Zertifikat verfügen, das von ihrer Firma oder einer öffentlichen Zertifizierungsstelle ausgestellt wurde und über einen nicht exportierbaren privaten Schlüssel verfügt, müssen Sie Ihr Zertifikat mithilfe des Fingerabdrucks zum HGS hinzufügen.

1. Installieren Sie das Zertifikat gemäß den Anweisungen Ihrer Zertifizierungsstelle auf Ihrem Computer.

2. Gewähren Sie dem gruppenverwalteten HGS-Dienstkonto Lesezugriff auf den privaten Schlüssel des Zertifikats. Zum Ermitteln des Namens des HGS-gMSA-Kontos führen Sie (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName aus.

3. Registrieren Sie das Zertifikat mit dem folgenden Befehl beim HGS, und ersetzen Sie den Fingerabdruck Ihres Zertifikats (zum Signieren von Zertifikaten ändern Sie Verschlüsselung in Signatur):

   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
   

Wichtig

Sie müssen den privaten Schlüssel manuell installieren und Lesezugriff auf das gMSA-Konto auf jedem HGS-Knoten gewähren. Der HGS kann private Schlüssel für Zertifikate, die durch Fingerabdruck registriert sind, nicht automatisch replizieren.

Option 3: Hinzufügen von Zertifikaten, die in PFX-Dateien gespeichert sind

Wenn Sie über ein softwaregestütztes Zertifikat mit einem exportierbaren privaten Schlüssel verfügen, der im PFX-Dateiformat gespeichert und mit einem Kennwort geschützt werden kann, kann der HGS Ihre Zertifikate automatisch für Sie verwalten. Zertifikate, die mit PFX-Dateien hinzugefügt wurden, werden automatisch auf jeden Knoten Ihres HGS-Clusters repliziert, und der HGS sichert den Zugriff auf die privaten Schlüssel. Um ein neues Zertifikat mithilfe einer PFX-Datei hinzuzufügen, führen Sie die folgenden Befehle auf einem beliebigen HGS-Knoten aus (zum Signieren von Zertifikaten ändern Sie Verschlüsselung in Signatur):

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword

Identifizieren und Ändern der primären Zertifikate Der HGS kann zwar mehrere Signatur- und Verschlüsselungszertifikate unterstützen, verwendet jedoch ein Paar als „primäre“ Zertifikate. Dies sind die Zertifikate, die verwendet werden, wenn jemand die Schutzmetadaten für diesen HGS-Cluster herunterlädt. Führen Sie den folgenden Befehl aus, um zu überprüfen, welche Zertifikate derzeit als primäre Zertifikate gekennzeichnet sind:

Get-HgsKeyProtectionCertificate -IsPrimary $true

Um ein neues primäres Verschlüsselungs- oder Signaturzertifikat festzulegen, suchen Sie den Fingerabdruck des gewünschten Zertifikats, und kennzeichnen Sie es mit den folgenden Befehlen als primär:

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary

Erneuern oder Ersetzen von Schlüsseln

Wenn Sie die vom HGS verwendeten Zertifikate erstellen, wird den Zertifikaten gemäß der Richtlinie Ihrer Zertifizierungsstelle und Ihren Anforderungsinformationen ein Ablaufdatum zugewiesen. Normalerweise müssen Zertifikate in Szenarien, in denen die Gültigkeit des Zertifikats wichtig ist, wie z. B. das Schützen der HTTP-Kommunikation, vor ihrem Ablauf erneuert werden, um eine Dienstunterbrechung oder besorgniserregende Fehlermeldung zu vermeiden. Der HGS verwendet keine Zertifikate in diesem Sinne. Der HGS verwendet Zertifikate einfach als bequeme Möglichkeit, ein asymmetrisches Schlüsselpaar zu erstellen und zu speichern. Ein abgelaufenes Verschlüsselungs- oder Signaturzertifikat im HGS weist nicht auf eine Schwäche oder den Verlust des Schutzes für abgeschirmte VMs hin. Darüber hinaus werden Zertifikatsperrprüfungen nicht vom HGS durchgeführt. Wenn ein HGS-Zertifikat oder das Zertifikat der ausstellenden Behörde gesperrt wird, wirkt sich dies nicht auf die Verwendung des Zertifikats durch den HGS aus.

Sie müssen sich um ein HGS-Zertifikat nur dann kümmern, wenn Sie Grund zu der Annahme haben, dass der private Schlüssel gestohlen wurde. In diesem Fall ist die Integrität Ihrer abgeschirmten VMs gefährdet, da der Besitz des privaten Teils des HGS-Verschlüsselungs- und Signaturschlüsselpaars ausreicht, um den Abschirmungsschutz auf einer VM zu entfernen oder einen gefälschten HGS-Server mit schwächeren Nachweisrichtlinien einzurichten.

Wenn Sie sich in dieser Situation befinden oder durch Compliancestandards verpflichtet sind, Zertifikatschlüssel regelmäßig zu aktualisieren, Schauen Sie sich die folgenden Schritten an, in denen der Prozess zum Ändern der Schlüssel auf einem HGS-Server beschrieben wird. Beachten Sie, dass die folgende Anleitung ein wichtiges Unterfangen darstellt, das zu einer Unterbrechung des Diensts für jede vom HGS-Cluster bereitgestellte VM führt. Eine ordnungsgemäße Planung für das Ändern von HGS-Schlüsseln ist erforderlich, um Dienstunterbrechungen zu minimieren und die Sicherheit von Mandanten-VMs zu gewährleisten.

Führen Sie die folgenden Schritte auf einem HGS-Knoten aus, um ein neues Paar von Verschlüsselungs- und Signaturzertifikaten zu registrieren. Ausführliche Informationen zu den verschiedenen Möglichkeiten zum Hinzufügen neuer Schlüssel zum HGS finden Sie im Abschnitt zum Hinzufügen neuer Schlüssel.

1. Erstellen Sie ein neues Paar von Verschlüsselungs- und Signaturzertifikaten für Ihren HGS-Server. Im Idealfall werden diese in einem Hardwaresicherheitsmodul erstellt.

2. Registrieren der neuen Verschlüsselungs- und Signaturzertifikate mit Add-HgsKeyProtectionCertificate

   Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
   Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>
   

3. Wenn Sie Fingerabdrücke verwendet haben, müssen Sie zu jedem Knoten im Cluster wechseln, um den privaten Schlüssel zu installieren und dem HGS-gMSA Zugriff auf den Schlüssel zu gewähren.

4. Festlegen der neuen Zertifikate als Standardzertifikate im HGS

   Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary
   Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary
   

An diesem Punkt werden von geschützten Daten, die mit vom HGS-Knoten abgerufenen Metadaten erstellt wurden, die neuen Zertifikate verwendet, aber vorhandene VMs funktionieren weiterhin, da die älteren Zertifikate noch vorhanden sind.

Um sicherzustellen, dass alle vorhandenen VMs mit den neuen Schlüsseln funktionieren, müssen Sie die Schlüsselschutzvorrichtung auf jeder VM aktualisieren.

Dies ist eine Aktion, die erfordert, dass der VM-Besitzer (Person oder Entität mit „Besitzer“-Schutzschlüssel) einbezogen werden muss. Führen Sie für jede abgeschirmte VM die folgenden Schritte aus:

1. Fahren Sie die VM herunter. Die VM kann erst wieder aktiviert werden, wenn die verbleibenden Schritte abgeschlossen sind, andernfalls müssen Sie den Prozess erneut starten.

2. Speichern Sie die aktuelle Schlüsselschutzvorrichtung in einer Datei: Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'

3. Übertragen des KP an den VM-Besitzer

4. Lassen Sie den Besitzer die aktualisierten Schutzinformationen vom HGS herunterladen und in sein lokales System importieren.

5. Lesen Sie den aktuellen KP in den Arbeitsspeicher, gewähren Sie dem neuen Schutz Zugriff auf die KP, und speichern Sie sie in einer neuen Datei, indem Sie die folgenden Befehle ausführen:

   $kpraw = Get-Content -Path .\VM001.kp
   $kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
   $newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
   $updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian
   $updatedKP.RawData | Out-File .\updatedVM001.kp
   

6. Kopieren Sie den aktualisierten KP zurück in das Hostingfabric.

7. Wenden Sie den KP auf die ursprüngliche VM an:

   $updatedKP = Get-Content -Path .\updatedVM001.kp
   Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP
   

8. Starten Sie schließlich die VM, und stellen Sie sicher, dass sie erfolgreich ausgeführt wird.

   Hinweis

   Wenn der VM-Besitzer eine falsche Schlüsselschutzvorrichtung auf dem virtuellen Computer festlegt und Ihr Fabric nicht autorisiert, die VM auszuführen, können Sie die abgeschirmte VM nicht starten. Führen Sie Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector aus, um zur letzten als fehlerfrei bekannten Schlüsselschutzvorrichtung zurückzukehren.

   Nachdem alle VMs aktualisiert wurden, um die neuen Schutzschlüssel zu autorisieren, können Sie die alten Schlüssel deaktivieren und entfernen.

9. Abrufen der Fingerabdrücke der alten Zertifikate aus Get-HgsKeyProtectionCertificate -IsPrimary $false

10. Deaktivieren Sie jedes Zertifikat, indem Sie die folgenden Befehle ausführen:

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
    Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false
    

11. Nachdem Sie sichergestellt haben, dass VMs mit deaktivierten Zertifikaten weiterhin starten können, entfernen Sie die Zertifikate aus dem HGS, indem Sie die folgenden Befehle ausführen:

    Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
    Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`
    

Wichtig

VM-Sicherungen enthalten Informationen zu alten Schlüsselschutzvorrichtungen, mit denen die alten Zertifikate zum Starten der VM verwendet werden können. Wenn Sie wissen, dass Ihr privater Schlüssel kompromittiert wurde, sollten Sie davon ausgehen, dass auch die VM-Sicherungen kompromittiert sein können, und entsprechende Maßnahmen ergreifen. Durch das Zerstören der VM-Konfiguration aus den Sicherungen (.vmcx) werden die Schlüsselschutzvorrichtungen entfernt. Dadurch wird es notwendig, beim nächsten Starten des virtuellen Computers das BitLocker-Wiederherstellungskennwort verwenden zu müssen.

Schlüsselreplikation zwischen Knoten

Jeder Knoten im HGS-Cluster muss mit denselben Verschlüsselungs-, Signatur- und (sofern konfiguriert) SSL-Zertifikaten konfiguriert werden. Dies ist erforderlich, um sicherzustellen, dass die Anforderungen von Hyper-V-Hosts, die einen beliebigen Knoten im Cluster erreichen möchten, erfolgreich verarbeitet werden können.

Wenn Sie den HGS-Server mit PFX-basierten Zertifikaten initialisiert haben, repliziert der HGS automatisch sowohl den öffentlichen als auch den privaten Schlüssel dieser Zertifikate auf jeden Knoten im Cluster. Sie müssen die Schlüssel nur auf einem Knoten hinzufügen.

Wenn Sie den HGS-Server mit Zertifikatverweisen oder Fingerabdrücken initialisiert haben, repliziert der HGS nur den öffentlichen Schlüssel im Zertifikat auf jeden Knoten. Darüber hinaus kann der HGS in diesem Szenario sich selbst keinen Zugriff auf den privaten Schlüssel auf irgendeinem Knoten gewähren. Daher liegt es in Ihrer Verantwortung, für Folgendes zu sorgen:

1. Installieren des privaten Schlüssels auf jedem HGS-Knoten
2. Gewähren Sie dem gruppenverwalteten HGS-Dienstkonto (gMSA) Zugriff auf den privaten Schlüssel auf jedem Knoten. Diese Aufgaben verursachen zusätzlichen Arbeitsaufwand, sind jedoch für HSM-gestützte Schlüssel und Zertifikate mit nicht exportierbaren privaten Schlüsseln erforderlich.

SSL-Zertifikate werden nie in irgendeiner Form repliziert. Es liegt in Ihrer Verantwortung, jeden HGS-Server mit demselben SSL-Zertifikat zu initialisieren und jeden Server zu aktualisieren, wenn Sie das SSL-Zertifikat erneuern oder ersetzen. Es wird empfohlen, zum Ersetzen des SSL-Zertifikats das Cmdlets Set-HgsServer zu verwenden.

Aufheben der Konfiguration des HGS

Wenn Sie einen HGS-Server außer Betrieb nehmen oder erheblich neu konfigurieren müssen, verwenden Sie dazu die Cmdlets Clear-HgsServer oder Uninstall-HgsServer.

Löschen der HGS-Konfiguration

Um einen Knoten aus dem HGS-Cluster zu entfernen, verwenden Sie das Cmdlet Clear-HgsServer. Dieses Cmdlet nimmt die folgenden Änderungen auf dem Server vor, auf dem es ausgeführt wird:

• Hebt die Registrierung der Nachweis- und Schlüsselschutzdienste auf.
• Entfernt den JEA-Verwaltungsendpunkt „microsoft.windows.hgs“.
• Entfernt den lokalen Computer aus dem HGS-Failovercluster.

Wenn der Server der letzte HGS-Knoten im Cluster ist, werden auch der Cluster und die zugehörige Ressource des verteilten Netzwerknamens (Distributed Network Name, DNN) zerstört.

# Removes the local computer from the HGS cluster
Clear-HgsServer

Nach Abschluss des Löschvorgangs kann der HGS-Server mit Initialize-HgsServer neu initialisiert werden. Wenn Sie Install-HgsServer zum Einrichten einer Active Directory Domain Services-Domäne verwendet haben, bleibt diese Domäne nach dem Löschvorgang konfiguriert und betriebsbereit.

Deinstallieren des HGS

Wenn Sie einen Knoten aus dem HGS-Cluster entfernen und den darauf ausgeführten Active Directory-Domäne-Controller herabstufen möchten, verwenden Sie das Cmdlet Uninstall-HgsServer. Dieses Cmdlet nimmt die folgenden Änderungen auf dem Server vor, auf dem es ausgeführt wird:

• Hebt die Registrierung der Nachweis- und Schlüsselschutzdienste auf.
• Entfernt den JEA-Verwaltungsendpunkt „microsoft.windows.hgs“.
• Entfernt den lokalen Computer aus dem HGS-Failovercluster.
• Stuft den Active Directory-Domäne-Controller herunter, falls konfiguriert.

Wenn der Server der letzte HGS-Knoten im Cluster ist, werden auch die Domäne, der Failovercluster und die Ressource des verteilten Netzwerknamens (DNN) des Clusters zerstört.

# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart

Nach Abschluss des Deinstallationsvorgangs und Neustart des Computers können Sie ADDC und den HGS mithilfe von Install-HgsServer neu installieren oder den Computer mit einer Domäne verknüpfen und den HGS-Server in dieser Domäne mit Initialize-HgsServer initialisieren.

Wenn Sie den Computer nicht mehr als HGS-Knoten verwenden möchten, können Sie die Rolle aus Windows entfernen.

Uninstall-WindowsFeature HostGuardianServiceRole