Secured Core in Windows Server 2022: HVCI, DMA-Schutz, System Guard und VBS konfigurieren

Diese Anforderungen sollten alle modernen Server erfüllen, insbesondere wenn sie für Azure Stack HCI oder Windows Server zertifiziert wurden. Die Hardware fungiert als Root-of-Trust, wobei das TPM die Schlüssel speichert, die für die Verifizierung aller Komponenten während des System­starts erforderlich sind.

Während der frühen Startphase stellt die Secure-Boot-Routine der Firmware sicher, dass ein legitimer Boot-Loader zum Zug kommt und nicht etwa ein Rootkit oder Bootkit.

System Guard überwacht den Boot-Vorgang

Windows verlässt sich aber nicht auf die UEFI-Integrität, sondern bringt das System mit Hilfe von System Guard (bestehend aus Secure Launch und System Management Mode (SMM) Protection) in einen vertrauens­würdigen Zustand.

Ein weiterer Mechanismus ist Kernel DMA Protection, der verhindern soll, dass Angreifer mittels externer PCI-Geräte Zugriff auf den Arbeits­speicher des Rechners erhalten und auf diese Weise Passwörter auslesen oder Malware einschleusen.

Geräte, deren Treiber nicht mit DMA-Remapping kompatibel sind, werden standardmäßig am direkten Speicherzugriff so lange gehindert, bis ein autorisierter Benutzer am System angemeldet ist.

HVCI als VBS-Feature

Schließlich baut Secured Core auf Virtualization based Security (VBS), für die der Hypervisor kritische Funktionen vom Rest des Betriebs­systems isoliert und sie somit vor Infizierung mit Schad­programmen schützt.

VBS führt einen separaten und sicheren Kernel auf einem höheren Trust-Level aus als den eigentlichen Systemkern von Windows. Dieser sowie Prozesse im User-Mode können nicht auf die geschützten Funktionen und Daten direkt zugreifen.

Ein VBS-Feature ist Hypervisor-protected Code Integrity (HVCI), das über Kernel-Code wacht und seine Ausführung nur zulässt, wenn er als legitim verifiziert wurde. Dies soll das Einschleusen von Malware verhindern, die im Kontext des Kernels Zugriff auf den gesamten Speicher hätte. HVCI setzt kompatible Treiber voraus, und deren Eignung lässt sich mit dem DGReadiness-Tool prüfen.

Secured Core konfigurieren

Einige Komponenten müssen einfach nur im System vorhanden sein, wie das erwähnte TPM 2.0, die UEFI-Firmware oder ein moderner Prozessor. Funktionen wie Secure Boot sind auf den meisten Rechnern standard­mäßig bereits aktiviert, ebenso wie die CPU-Extensionen für die Virtualisierung.

Wenn man auf die Schnelle herausfinden möchte, ob Secure Boot aktiviert ist, dann ruft man in einer PowerShell-Sitzung mit erhöhten Rechten

Confirm-SecureBootUEFI

auf. Auskunft über die Virtualisierungs­erweiterungen erhält man etwa im Task-Manager unter Leistung oder über msinfo32.exe.

Um den Status aller Komponenten von Secured Core auf einen Blick zu erfassen, bietet sich das Windows Admin Center (WAC) an. Die Security-Erweiterung bietet dafür eine eigene Registerkarte.

Abhängig davon, welche Features aktiviert sind, wird man sie erst freischalten müssen. Für HVCI kann man das über die App Einstellungen unter Gerätesicherheit erledigen, Secure Boot konfiguriert man ohnehin in den UEFI-Einstellungen. Auch das WAC erlaubt die Statusänderung der VBS-basierten Funktionen.

VBS über Gruppenrichtlinien steuern

Nachdem Secured Core nicht bloß ein Konzept für Windows Server, sondern auch für das Client-OS ist, wird man bevorzugt zu Gruppen­richtlinien greifen, um die betreffenden Sicherheits­funktionen zentral zu verwalten.

Die wesentliche Einstellung dafür findet sich unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => System => Device Guard und heißt Virtualisierungs­basierte Sicherheit aktivieren.

Wenn man sie aktiviert, dann lassen sich über Pull-down-Menüs vier Funktionen konfigurieren. Die erste davon betrifft Secure Boot, das man auf kompatiblen PCs um DMA-Protection ergänzen kann.

Über ein weiteres Menü passt man HVCI an, wofür vier Optionen zur Auswahl stehen. Deaktiviert schaltet die Code-Integrität ab, auch wenn diese interaktiv über die App Einstellungen aktiviert wurde. Dagegen belässt Nicht konfiguriert den aktuellen Zustand.

Mit UEFI-Sperre aktiviert führt dazu, dass die Einstellung dauerhaft in der Firmware gespeichert wird und nicht durch Zurücksetzen der Gruppen­richtlinie entfernt werden kann. Vielmehr muss sie physisch an jedem PC entfernt werden. Ohne Sperre aktiviert hingegen erlaubt das Ändern der Einstellung via GPO.

Mit dem Aktivieren von Sicherer Start­konfiguration schaltet man die betreffende Funktion von System Guard frei.

Über eine weitere Gruppen­richtlinie kann man den DMA-Schutz anpassen. Standard­mäßig blockiert er beispiels­weise das Anschließen von Thunderbolt-Geräten, die nicht mit DMA-Remapping kompatibel sind, wenn kein User angemeldet oder der Bildschirm gesperrt ist.

Unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => System => Kernel-DMA-Schutz kann man diese Vorgabe so ändern, dass diese Geräte generell gesperrt oder freigegeben werden.

Secured Core in einer VM

Wendet man die beschriebenen Einstellungen auf eine virtuelle Maschine an, dann zeigt sich, dass man dort VBS allgemein und HVCI im Besonderen nutzen kann. Voraussetzung dafür ist jedoch, dass man für die VM verschachtelte Virtualisierung aktiviert hat, weil andernfalls der Hypervisor im Gast-OS nicht zur Verfügung steht.

Nicht nutzbar hingegen sind System Guard und Boot-DMA-Protection. Das WAC weist beide als Not supported aus. Für Secure Boot benötigt man UEFI, das nur in einer VM der Generation 2 zur Verfügung steht.

Die Sicherheitseinstellungen einer VM kann man in PowerShell mit

Get-VMSecurity -VMName "Name-der-VM"

abrufen. Es zeigt auch einen Parameter mit dem Namen Virtualization­Based­Security­OptOut an, den man mit Set-VMSecurity bei Kompatibilitäts­problemen auf $true setzen kann. Diese treten etwa beim Anschließen eines virtuellen Fibre-Channel-Adapters auf.