HVCI auf Windows: Speicherintegrität, Treiber und UEFI-Sperre

Was bedeutet HVCI auf Windows für die Speicherintegrität?

HVCI auf Windows schützt durch Speicherintegrität: Diese Windows-Schutzfunktion prüft die Integrität von Kernelcode in der isolierten Umgebung der virtualisierungsbasierten Sicherheit (VBS). Für ihre Bereitstellung sind drei getrennte Fragen zu beantworten: Welche Konfiguration ist vorgesehen, läuft die Speicherintegrität tatsächlich auf jedem Zielgerät, und bleibt eine Wiederherstellung nach Auswahl des UEFI-Sperrmodus möglich? Eine Domänen-GPO beantwortet allein nur einen Teil der ersten Frage. Microsoft-Anleitung zur Aktivierung

Für ein AD-Team ist das sinnvolle Ergebnis eine getestete Einführung mit Nachweisen pro Gerät. Beginnen Sie mit einer repräsentativen Gerätegruppe, klären Sie Treiberabhängigkeiten, messen Sie den Dienst nach dem Neustart und dokumentieren Sie die Entscheidung zur Sperre. Nehmen Sie auch Geräte, die nicht gemessen werden konnten, in den Bericht auf; ihr stillschweigendes Weglassen lässt Richtlinienabdeckung wie nachgewiesenen Schutz erscheinen.

Dieser Leitfaden verwendet Microsoft-Learn-Dokumentation, die am 3. Oktober 2026 geprüft wurde, sowie die beiden unten beschriebenen Collector-Prüfungen. Die Windows-Befehle sind Dokumentationsbeispiele oder ausdrücklich gekennzeichnete Anpassungen für reine Lesezugriffe; für diesen Artikel wurden sie nicht in einer Windows-Gerätelandschaft ausgeführt. Weder eine Flottenabdeckung noch ein erfolgreicher Kompatibilitätstest wird behauptet.

Unser Leitfaden zu Credential Guard nach einem Upgrade verwendet dieselbe WMI-Nachweismethode für einen anderen Dienst: die Isolation ausgewählter Geheimnisse. Speicherintegrität betrifft die Integrität von Kernelcode. Der Nachweis, dass ein Dienst läuft, belegt nicht, dass auch der andere läuft.

Wie sich Richtlinie, Laufzeit und UEFI-Sperre unterscheiden

Dieselbe Zahl hat je nach Einstellung unterschiedliche Bedeutungen. Microsofts Richtlinienreferenz zu VirtualizationBasedTechnology dokumentiert den Richtlinienmodus und seine Zuordnung zur Device-Guard-GPO. Die Aktivierungsseite dokumentiert getrennt davon die lokalen Werte Enabled und Locked.

Die lokalen Pfade in der Tabelle liegen unter HKLM\SYSTEM\CurrentControlSet\Control. Der Richtlinienwert liegt unter HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Schreiben Sie nicht Enabled=2, um den entsperrten Modus der Richtlinie nachzubilden. Interpretieren Sie eine WMI-Dienstkennung nicht als Registrierungsmodus. Bewahren Sie den vollständigen Pfad und den Wertnamen in den Nachweisen auf, damit ein anderer Administrator sie ohne Rekonstruktion der Erfassung interpretieren kann.

Ein nützlicher Änderungsnachweis führt Richtlinienabsicht, angewendete Richtlinie, lokale Einstellungen und Laufzeitbeobachtung als getrennte Felder. Gibt eine GPO einen Modus vor, während ein Endpunkt einen anderen zeigt, untersuchen Sie die angewendete Konfiguration, bevor Sie die Änderung als abgeschlossen betrachten. Stimmen die Einstellungen überein, aber die Laufzeit weicht ab, untersuchen Sie den Endpunkt, statt wiederholt dieselbe GPO zu bearbeiten.

Die UEFI-Sperre verändert auch die Entscheidung zur Wiederherstellung. Microsofts GPO-Verfahren bietet eine Bereitstellung ohne Sperre an und warnt, dass die Wahl des gesperrten Modus die Remote-Deaktivierung einschränkt. Klären Sie, wer das Firmwaremenü erreichen und den Rechner wiederherstellen kann, bevor diese Einschränkung Teil der Produktionsadministration wird. Microsoft-GPO-Anleitung

Erkennung: Nachweise auf dem Zielgerät erfassen

Verwenden Sie auf dem Zielgerät eine PowerShell-Sitzung mit erhöhten Rechten. Microsoft stellt diesen Befehl in seiner Win32_DeviceGuard-Referenz bereit:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Die folgende Anpassung für reine Lesezugriffe wählt die für diese Untersuchung erforderlichen Felder aus:

$state = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$state | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus

Interpretieren Sie die Dienstarrays anhand der enthaltenen Werte. Ein Ergebnis mit sowohl 1 als auch 2 umfasst die Speicherintegrität; 1 kennzeichnet Credential Guard. VirtualizationBasedSecurityStatus=2 beschreibt laufendes VBS, während der Wert 2 in SecurityServicesRunning laufende Speicherintegrität kennzeichnet. Microsoft-Definitionen der WMI-Eigenschaften

Behandeln Sie die Erfassung als Beobachtung mit Host, Zeitpunkt und Startkontext. Bewahren Sie die vollständigen Arrays auf, auch wenn das Dashboard später einen booleschen Wert anzeigt. Unterscheiden Sie eine erfolgreiche Abfrage ohne Speicherintegrität von einer fehlgeschlagenen Abfrage. Authentifizierungsfehler, nicht erreichbare Geräte und fehlende Ausgaben gehören in eine Kategorie „unbekannt“ mit einer Folgemaßnahme.

Richtlinie und lokale Sperreinstellungen vergleichen

Diese PowerShell-Anpassung für reine Lesezugriffe liest die benannten Einstellungen; fehlende Pfade oder Werte sollten als nicht vorhanden erfasst und nicht stillschweigend durch null ersetzt werden:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name HypervisorEnforcedCodeIntegrity
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity' -Name Enabled, Locked
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' -Name EnableVirtualizationBasedSecurity, RequirePlatformSecurityFeatures, Locked

Vergleichen Sie diese Beobachtungen mit dem freigegebenen Modus und einem Bericht über die resultierende Richtlinie für diesen Host. Eine aus einer unbeteiligten GPO exportierte Einstellung reicht nicht als Nachweis, dass das Ziel sie erhalten hat. Erfassen Sie widersprüchliche Konfigurationen und Erfassungsfehler, statt sie in eine einfache Bewertung „geschützt/ungeschützt“ umzuwandeln.

Die oben dokumentierten Eigenschaften von Win32_DeviceGuard stellen keine Eigenschaft Locked bereit. Lesen Sie die benannten Registrierungsmarker getrennt aus. Sie beschreiben die Sperrkonfiguration und sollten nicht als unabhängige Firmwareattestierung dargestellt werden. Ein CIM-Ergebnis mit laufender Speicherintegrität beweist ebenfalls nicht, dass die UEFI-Sperre durchgesetzt wird. Microsoft-Referenz zur Konfiguration und Validierung

Treiberkompatibilität: einen Piloten mit realen Arbeitsabläufen planen

Microsofts Anleitung zur Treiberkompatibilität kombiniert Code-Integrity-Prüfungen in Driver Verifier, Funktionstests mit aktivierter Speicherintegrität und den Windows HLK HyperVisor Code Integrity Readiness Test. Sie unterscheidet die Signierungsbereitschaft von gründlichen Funktionstests. Ein Treiber, der bei einem Start geladen wird, hat damit nicht zwangsläufig jeden relevanten Laufzeitpfad durchlaufen.

Für einen Treiberverantwortlichen oder ein Entwicklungsteam lautet der dokumentierte Verifier-Befehl:

verifier.exe /flags 0x02000000 /driver <driver.sys>

Ersetzen Sie den Platzhalter durch den ausgewählten Treiber in einer Testumgebung mit gesicherter Wiederherstellung. Driver Verifier ist ein Testwerkzeug, kein Befehl zur wahllosen Verteilung auf Produktionsendpunkte. Dokumentieren Sie den ausgewählten Treiber, die Testbedingungen, die Befunde und den Wiederherstellungsweg. Stimmen Sie Fehler mit dem Treiberanbieter ab, statt eine dauerhafte Deaktivierung als einzige Lösung zu behandeln.

Erstellen Sie für das Bereitstellungsteam eine Matrix aus Gerätemodellen, Firmwareversionen, Windows-Builds, Treiberpaketen und Geschäftsabläufen. Nehmen Sie die Kombinationen auf, die tatsächlich in der Zielgruppe vorhanden sind. Wählen Sie Pilotgeräte mit aussagekräftigen Unterschieden; eine bequem verfügbare Gruppe identischer Laptops kann andere Hardwarefamilien ungetestet lassen.

Testen Sie die Arbeit, die diese Geräte leisten müssen: Start, Peripheriegeräte, erforderliche Anwendungen und deren treiberabhängige Vorgänge. Definieren Sie die erwarteten Ergebnisse vor Beginn und ordnen Sie Fehler einem benannten Paket und Verantwortlichen zu. Dies sind Empfehlungen für die Einführung, keine Behauptung, dass eine bestimmte Anwendung oder ein Gerät in Ihrer Umgebung inkompatibel ist.

Geben Sie für jede Ausnahme einen Grund, die betroffene Gerätegruppe, einen Verantwortlichen, die geplante Behebung und einen Überprüfungstermin an. Trennen Sie einen nachgewiesenen Kompatibilitätsfehler von der Annahme, dass eine alte Ausnahme weiterhin benötigt wird. Fordern Sie vom Anbieter ein aktualisiertes Paket oder unterstützende Testnachweise an und wiederholen Sie dann den relevanten Arbeitsablauf mit aktiver Speicherintegrität. Das Ausnahmeinventar bildet die Grenze der nächsten Einführungswelle.

Behebung: GPO stufenweise einführen und Ergebnis nach Neustart belegen (Remediation)

1. Gerätegruppe und Wiederherstellungsplan freigeben

Benennen Sie Verantwortliche für Hardwareprüfung, Treibertests, GPO-Änderungen und Wiederherstellung. Dokumentieren Sie den vorgesehenen Sperrmodus, den Pilotumfang und die Ausschlüsse, bevor Sie die Richtlinie bearbeiten. Legen Sie eine Abnahmeregel fest, die sowohl eine Laufzeitbeobachtung als auch bestandene erforderliche Arbeitsabläufe verlangt; das bloße Erstellen einer GPO sollte die Aufgabe nicht abschließen.

Ordnen Sie diese Entscheidung für Administrationsarbeitsplätze in die umfassendere Architektur unseres ANSSI-Leitfadens für Active Directory ein: Administrationswege, dedizierte Nutzung und Vertrauensgrenzen. Das Härten einer einzelnen Windows-Funktion belegt weder eine tragfähige Administrationsarchitektur noch ANSSI-Konformität.

2. Eine unterstützte Konfiguration mit begrenztem Geltungsbereich anwenden

Folgen Sie Microsofts GPO-Verfahren unter Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Aktivieren Sie die Richtlinie und wählen Sie unter Virtualization Based Protection of Code Integrity die vorgesehene Option. Verknüpfen und filtern Sie die GPO für die freigegebene Pilotgruppe; prüfen Sie die auf dem Ziel angewendete Richtlinie, bevor Sie den Umfang erweitern. Microsoft-Bereitstellungsverfahren

Der dokumentierte Befehl zur Richtlinienaktualisierung, ausgeführt in einem Command Prompt mit erhöhten Rechten, lautet:

gpupdate /force

Planen Sie einen Neustart für die Nachweiserfassung im Piloten. Wiederholen Sie nach dem Start die CIM-Beobachtung und den Vergleich der lokalen Einstellungen. Dokumentieren Sie die beobachteten Arrays und den Modus zusammen mit dem Änderungsantrag. Leiten Sie aus einem erfolgreichen Rechner kein Ergebnis für die gesamte Flotte ab; jedes nicht gemessene Ziel behält seinen eigenen ungeklärten Zustand.

3. Wiederherstellung vor Auswahl der UEFI-Sperre dokumentieren

Bei Instabilität nach der Aktivierung beginnt Microsofts Fehlerbehebungsverfahren damit, die aktivierenden Richtlinien zu deaktivieren. Anschließend wird in Windows Recovery Environment (Windows RE) der Wert Enabled des Szenarios auf 0 gesetzt und neu gestartet. Der dokumentierte Befehl lautet:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f

Erstellen Sie das gerätespezifische Wiederherstellungshandbuch anhand dieses Verfahrens. Validieren Sie den Zugang zu Windows RE und zur Registrierung der betroffenen Installation, benennen Sie die ausführende Person und testen Sie, wie die aktivierende Richtlinie zurückgenommen wird. Gehen Sie nicht davon aus, dass eine gewöhnliche Remote-Änderung der Registrierung einen Rechner wiederherstellen kann, der nicht mehr startet.

Bei UEFI-Sperre verlangt Microsoft zusätzlich die Deaktivierung von Secure Boot, um diese Wiederherstellungsschritte abzuschließen. Damit wird der Firmwarezugang Teil des Plans. Wählen Sie die Sperre nur, wenn der physische Wiederherstellungsweg, die autorisierte ausführende Person und das Rücksetzverfahren dokumentiert sind. Nehmen Sie die Wiederherstellung der freigegebenen Firmwarekonfiguration und die erneute Validierung in das Handbuch auf. Microsoft-Anleitung zur Wiederherstellung

4. Mit aufbewahrten Nachweisen erweitern

Prüfen Sie die Pilotbeobachtungen und Fehler vor der nächsten Welle. Bewahren Sie Ausnahmen und unbekannte Geräte im selben Inventar wie erfolgreiche Messungen auf. Prüfen Sie nach relevanten Treiber- oder Plattformänderungen erneut. Ein nützlicher Abschlussnachweis enthält die freigegebene Richtlinie, den Zielumfang, den Startkontext, den Nachweis laufender Dienste, das Ergebnis der Funktionstests und den Wiederherstellungsverantwortlichen.

Wie EtcSec dies erkennt

EtcSecs etc-collector stellt für dieses Thema zwei Prüfungen der GPO-Konfiguration bereit. Das folgende Verhalten stammt aus den tatsächlichen Verzweigungen von Detect(), nicht aus einem Endpunkttest:

gpoSetsAtLeast und gpoMaxValue durchlaufen die erfassten GPOs, überspringen fehlende Richtlinien-/Einstellungsobjekte und ignorieren nicht gesetzte Werte. Das Maximum beginnt bei -1. Der Registry.pol-Parser ordnet einen DWORD namens HypervisorEnforcedCodeIntegrity in einem Schlüssel, der deviceguard enthält, dem Feld HVCIEnabled zu. Er erfasst nicht die getrennten Messwerte Enabled und Locked des Laufzeitszenarios.

Das Maximum ist ein numerisches Aggregat, keine Sicherheitsrangfolge und keine Berechnung des GPO-Vorrangs. Hat eine Richtlinie 1 und eine andere 2, beträgt das Maximum 2 und die Low-Prüfung löst aus. Werte über 2 gelangen ebenfalls in dieselbe Befundverzweigung, weil der Code keine Enum-Validierung enthält. Sie sind keine dokumentierten gültigen Sperrmodi und sollten als unerwartete Daten untersucht werden.

Count 1 ist die Befundanzahl des Detektors, keine Anzahl exponierter Endpunkte. Keine der beiden Prüfungen berechnet pro Gerät das Resultant Set of Policy (RSoP), wertet GPO-Verknüpfungen/Filterung aus oder fragt die WMI-Laufzeit ab. Eine positive Einstellung an irgendeiner Stelle kann die OFF-Prüfung unterdrücken, selbst wenn die Zielabdeckung unvollständig ist. Ein fehlender GPO-Wert kann mit einer Aktivierung über einen anderen Mechanismus zusammenfallen; er belegt nicht, dass die Speicherintegrität zur Laufzeit deaktiviert ist.

Verwenden Sie diese Prüfungen als Ausgangspunkt für die Richtlinienuntersuchung und ergänzen Sie unabhängige Gerätenachweise. Die Detektornamen und Kommentare belegen für sich allein weder ANSSI-Konformität noch tatsächliche Firmwaresperre, Treiberkompatibilität oder erfolgreichen Schutz der gesamten Flotte. Diese Schlussfolgerungen benötigen eigene Nachweise und eine eigene Prüfung.

Quellen

• Microsoft Learn: Speicherintegrität aktivieren, GPO, Registrierung, WMI und Wiederherstellung
• Microsoft Learn: Treiberkompatibilität mit Speicherintegrität und VBS
• Microsoft Learn: VirtualizationBasedTechnology-Richtlinienwerte und GPO-Zuordnung