Auf den ersten Blick präsentiert sich Windows Server 2022 als sorgsam modellgepflegtes Update seines direkten Vorfahren, Windows Server 2019. Microsoft setzt klar auf Evolution statt Revolution. Dennoch offenbart ein zweiter Blick spannende neue Funktionen, besonders im Bereich der Informationssicherheit. Mit dem Secure-Core-Server gibt Microsoft seinem neuen Betriebssystem insgesamt sechs Komponenten mit, die mit wenig Aufwand die Sicherheit des Systems erhöhen. Ob und welche dieser Funktionen eine Instanz von Windows Server 2022 unterstützt, hängt davon ab, ob es sich um eine physische oder virtuelle Maschine handelt. Und auch die unterliegende Hardware samt Firmware sowie im Falle einer VM der Hypervisor müssen mitspielen.

Bevor wir uns den Details und technischen Voraussetzungen des Secured-Core-Servers widmen, möchten wir einem Missverständnis vorbeugen. Auch in Verbindung mit früheren Ausgaben von Windows Server hatte Microsoft bereits den Begriff "Core" verwendet, meinte damit aber eine Installation, die ohne grafische Benutzeroberfläche auskommt. Bereits seit Windows Server 2008 R2 durften Sie im Rahmen des Setups zwischen einer solchen Core-Installation und einer vollständigen Installation mit Desktop-Darstellung wählen.

Der Begriff des Secured-Core-Servers und dessen Funktionen sind völlig unabhängig von dieser Unterscheidung. Sie können sämtliche der neuen Sicherheitsfunktionen auch in Verbindung mit einer Installation samt grafischer Benutzeroberfläche verwenden, und das in allen Editionen. Sowohl Windows Server 2022 Standard als auch Datacenter und die Datacenter-Azure-Edition unterstützen Secured-Core-Server, sofern die Hardware und die Virtualisierung hierfür gerüstet sind.

Die Sicherheit beginnt bereits mit dem BIOS, besser gesagt, mit einem modernen Unified Extensible Firmware Interface (UEFI), das den Standard "Secure Boot" unterstützt. Dabei handelt es sich keineswegs um eine Erfindung von Microsoft, sondern um einen Bestandteil der UEFI-Spezifikation, auf den sich zahlreiche Hardwarehersteller (Original Equipment Manufacturer, OEM) geeinigt haben.

Secure Boot setzt schon an, bevor ein Betriebssystem startet, und soll die Unverfälschtheit der Firmware verifizieren, um Rootkits auszusperren. Dazu prüft das UEFI die Signaturen seines Boot-Codes und der Firmware-Treiber. Schlägt diese Prüfung fehl, löst die Firmware einen vom OEM definierten Prozess aus, um wieder einen vertrauenswürdigen Zustand herzustellen [1]. Analog dazu verifiziert die Firmware auch den Boot-Manager des Betriebssystems. Nur wenn dieser ebenfalls eine gültige Signatur vorweisen kann, übergibt ihm die Firmware zum weiteren Start die Kontrolle. Und auch die übrigen Bestandteile des Betriebssystems, wie Kernel und Gerätetreiber, müssen entsprechend mittels Signaturen beweisen, dass sie nicht manipuliert wurden. Stimmt eine der Signaturen nicht mit denen in der Datenbank des UEFI überein, startet das System nicht.

Unter der Haube nutzt Secure Boot dazu asymmetrische Verschlüsselung, ähnlich einer Public Key Infrastructure (PKI). Vergleichbar mit einer Certification Authority (CA) bilden Hersteller von UEFI-Firmwares den Vertrauensanker (Root-of-Trust). Sie besitzen die sogenannten Platform Keys (PK), mit denen sie die Echtheit und Unverfälschtheit ihrer Firmware belegen. Hersteller wie Microsoft signieren ihre Betriebssysteme und Treiber mithilfe von Key Exchange Keys (KEK), die ein OEM ab Werk in seiner Firmware hinterlegt und diese anschließend für Schreibzugriffe sperrt. Spätere Updates der KEK-Datenbank sind zwar möglich, setzen aber voraus, dass sie mit dem PK signiert sind. Microsoft verfügt über einen KEK, mit dem es neue Versionen von Windows sowie andere Softwarebestandteile und Treiber signieren oder bereits bestehende Signaturen wieder sperren kann. Dieses Verfahren wird auch als "Static Root of Trust for Measurement" (SRTM) bezeichnet.

Als weiteren Vertrauensanker nutzt der Secure-Core-Server ein aktives Trusted Platform Module (TPM) in der Version 2.0. Beim TPM handelt es sich um einen Chip, der kryptografische Schlüssel sowie Hash-Werte erzeugt, speichert und den Zugriff darauf steuert. Microsoft verwendet ein TPM für biometrische Anmeldungen mittels Windows Hello auf Clientcomputern sowie auch für die Laufwerksverschlüsselung Bitlocker.

Im Rahmen eines "Measured Boot" generiert und speichert das TPM Hash-Werte aller am Startvorgang des Systems beteiligten Komponenten [2]. Die Überprüfung dieser Hashes durch einen vertrauenswürdigen Server (Remote Attestation) ist allerdings nicht allein mit Bordmitteln möglich, sondern erfordert Intune, Microsoft Endpoint Configuration Manager oder Software von Drittanbietern. Doch auch ohne zusätzliche Anwendungen und Dienste hilft ein TPM, die Sicherheit zu erhöhen, denn es bildet die Basis für eine weitere Komponente des Secured-Core-Servers, die Systemüberwachung.

Die Systemüberwachung (System Guard) ist ein Bestandteil von Microsoft Defender und folgt dem Prinzip "Assume breach", nimmt also an, dass ein System und seine Bestandteile grundsätzlich nicht vertrauenswürdig und potenziell bereits kompromittiert sind. Entsprechend vertraut die Systemüberwachung nicht darauf, dass Secure Boot die Integrität des UEFI zweifelsfrei bewiesen hat, sondern setzt auf das zusätzliche Verfahren "Secure Launch" sowie eine Absicherung des System Management Modes (SMM) der CPU [3].

Den Secure Launch bezeichnet Microsoft auch als "Dynamic Root of Trust for Measurement" (DRTM), denn anders als Secure Boot setzt dieses Verfahren nicht auf statische Listen vertrauenswürdiger und widerrufener Signaturen. Stattdessen berechnet Defender System Guard mithilfe des TPM selbst Prüfsummen über die Firmware, die weitere Hardwarekonfiguration sowie Bestandteile des Betriebssystems und vergleicht diese mit früheren Zuständen, um Abweichungen zu erkennen. Zusätzlich sichert die Systemüberwachung den SMM des Prozessors ab. Da Code in diesem Modus mit den höchsten Berechtigungen läuft, nutzt die Systemüberwachung in der Hardware moderner Prozessoren realisierte Sicherheitsfunktionen und etabliert einen Schutz für Zugriffe auf sensible Bereiche des Hauptspeichers.

Der DMA-Schutz beim Starten (Boot DMA Protection) setzt auf dem Kernel-DMA-Schutz auf, den Microsoft mit der Version 1803 von Windows 10 erstmals eingeführt hatte [4]. Diese Sicherheitsfunktion schützt das System vor sogenannten "Drive-by"-Attacken mittels hot-plug-fähiger Peripheriegeräte. Dieser Angriffsvektor zielt darauf ab, per Direct Memory Access (DMA) sensible Daten aus den Hauptspeicher auszulesen oder am Sperrbildschirm vorbei Malware direkt in ein System einzuschleusen.

Die Boot DMA Protection schützt externe und interne PCI-/PCIe-Schnittstellen eines Systems vor solchen Versuchen bereits während der Startphase und zur Laufzeit. Voraussetzung dafür ist allerdings, dass die Gerätetreiber der externen Geräte die sogenannte DMA-Neuzuordnung (DMA-Remapping) unterstützen.

Virtualisierungsbasierte Sicherheit (Virtualization-based Security, VBS) nutzt Funktionen von Microsofts Hypervisor Hyper-V, um sensible Informationen, wie etwa die Hash-Werte von Passwörtern, in einem besonders gesicherten Speicherbereich abzulegen. Selbst privilegierte Systemprozesse können nicht ohne Weiteres auf diesen isolierten Speicherbereich zugreifen. VBS erfordert ein UEFI ab Version 2.6 mit Unterstützung für eine Speicherattributtabelle (Memory Attributes Table, MAT). Die sorgt für eine saubere Trennung der Laufzeitspeicherbereiche von Code und Daten.

VBS bildet die Basis für die sechste und letzte Komponente des Secured-Core-Servers, die Hypervisor Enforced Code Integrity (HVCI). Diese Funktion wacht über die Ausführung von Code im Kernel-Mode und lässt diesen nur zu, wenn er als legitim verifiziert werden kann. Dies betrifft Gerätetreiber sowie Software, die die Funktion Control Flow Guard (CFG) nutzt, und zudem auch Zertifikate. Möchten Sie Windows Server 2022 direkt auf einer physischen Hardware installieren, so können Sie im besten Fall alle sechs Funktionen des Secured-Core-Servers verwenden – sofern Hardware, Firmware und Gerätetreiber dies unterstützen.

Starten Sie mit der frischen Installation eines physischen Systems, auf dem bislang noch kein Secured-Core-Server lief, sollten Sie zunächst sicherstellen, dass Ihre Hardware über ein modernes UEFI verfügt und dieses auch verwendet. Aktuelle Systeme, die für den Einsatz von Windows Server 2022 zertifiziert sind, bringen die nötigen Voraussetzungen mit. Und auch beim Einsatz von Hardware, die bereits drei bis fünf Jahre alt ist, stehen die Chancen gut.Sofern sich in den Einstellungen der Firmware zwecks Rückwärtskompatibilität zu älteren Betriebssystemen die Option eines Legacy-BIOS-Modus findet, darf diese nicht aktiv sein. Die weiteren Schritte zur Aktivierung hardwaregestützter Virtualisierung unterscheiden sich abhängig vom Prozessorhersteller, der übrigen Serverhardware sowie der Version des UEFI.

Die Hardwarevirtualisierung heißt je nach Fabrikat des Prozessors "Intel VT-d/VT-x" oder "AMD IOMMU", kann sich davon abweichend je nach Hersteller und Version des UEFI jedoch auch unter anderen Begriffen oder in einem Submenü verstecken. Halten Sie Ausschau nach Menübereichen, wie etwa "Advanced", "Processor Configuration", "CPU Configuration", "System Configuration", "Chipset", "Security" oder "Northbridge". Intel nennt die Hardwarevirtualisierung schlicht "Intel Virtualization Technology", "VT-x" oder auf älteren Systemen vielleicht "Vanderpool" nach dem ursprünglichen internen Codenamen aus der Entwicklung dieser Technologie. AMD bezeichnet das Ganze neben "AMD-V" auch als "Secure Virtual Machine" (SVM).

Die Konfiguration von Secure Boot und TPM finden Sie in Bereichen mit Titeln wie "Advanced", "Security" oder "Trusted Computing". Als alternative Bezeichnungen für das TPM sind auch "Security Device", "Security Device Support", "AMD fTPM", "AMD PSP fTPM", oder "Intel Platform Trust Technology" (PTT) gebräuchlich. Im Zweifelsfall hilft die Dokumentation des Server- oder Mainboard-Herstellers.

Die Systemüberwachung sowie der DMA-Schutz beim Starten sind Instanzen von Windows Server 2022 vorbehalten, die Sie direkt auf einem physischen System installieren. Die übrigen vier Komponenten können Sie auch in virtuellen Maschinen verwenden, wenn der unterliegende Hypervisor die nötigen Funktionen an VMs durchreicht. In Microsoft Hyper-V erstellen Sie dazu eine VM der zweiten Generation und aktivieren in deren Eigenschaften im Bereich "Sicherheit" die Optionen "Sicheren Start aktivieren" sowie "Trusted Platform Module". Die Voraussetzungen für VBS und HVCI erfüllt Hyper-V ohne weiteres Zutun.

Bei der Virtualisierung mittels VMware vSphere/ESXi aktivieren Sie VBS beim Anlegen einer neuen VM im sechsten Dialogschritt, der die Familie und Version des Gastbetriebssystems bestimmt. Setzen Sie dort die Checkbox "Virtualisierungsbasierte Sicherheit für Windows aktivieren" [5]. Im folgenden Dialog legen Sie die Hardwareausstattung Ihrer VM fest. Mittels "Neues Gerät hinzufügen" ergänzen Sie ein virtuelles TPM. Das funktioniert allerdings nur, wenn Sie in Ihrer vSphere-Umgebung zuvor bereits einen Schlüsselanbieter konfiguriert haben [6].

Was für VMs in Ihrem lokalen Rechenzentrum funktioniert, gelingt ebenso in der Cloud. Microsoft unterstützt die Komponenten des Secured-Core-Servers sowohl in der hauseigenen Azure-Cloud als auch in Azure Stack HCI. Im Rahmen dieser hyperkonvergenten Infrastruktur bietet Microsoft in Kooperation mit OEMs zertifizierte Hardware an, die Sie in Ihrem eigenen Rechenzentrum betreiben und trotzdem gemeinsamen mit Ihren Ressourcen in der Cloud einheitlich über das Azure-Portal verwalten.

Möchten Sie einen Secured-Core-Server in Azure installieren, gilt es zu beachten, dass Sie diese Entscheidung bereits beim Erstellen einer VM treffen müssen. Für bereits bestehende VMs ist dies nachträglich nicht mehr möglich, sodass nur eine Neuinstallation bleibt. Die nötigen Einstellungen finden Sie bereits auf der ersten Seite des Assistenten für neue virtuelle Computer. Wählen im Dropdown-Feld für den Sicherheitstyp anstelle von "Standard" die "VMs mit vertrauenswürdigem Start". Wie auf einem lokalen Hyper-V-Host handelt es sich dabei um eine VM der zweiten Generation [7]. Unterhalb des Dropdown-Felds erscheint daraufhin ein Link, mit dem Sie die Sicherheitsfunktionen der VM konfigurieren. Die beiden Optionen "Sicherer Start" sowie "vTPM" sind bereits standardmäßig aktiv.

Damit haben Sie auf den Ebenen der Hardware und Virtualisierung alle Voraussetzungen für den Secured-Core-Server geschaffen. Alles Weitere erledigen Sie anschließend auf der Ebene des Betriebssystems.

Microsoft bewirbt das webbasierte Windows Admin Center (WAC) schon seit Längerem als moderne Alternative zum betagten Server-Manager. Falls Sie sich noch nicht damit beschäftigt haben sollten, ist nun ein günstiger Zeitpunkt hierfür gekommen. Mittels WAC verschaffen Sie sich einen Überblick über den Status aller Komponenten des Secured-Core-Servers und aktivieren die noch nicht konfigurierten Funktionen.

Microsoft bietet das WAC kostenlos zum Download an [8]. Laden Sie die aktuelle Version herunter und installieren Sie sie auf einem Windows-Server. Dabei muss es sich nicht zwingend um die Maschinen handeln, die Sie als Secured-Core-Server konfigurieren möchten. Für den produktiven Betrieb sollten Sie bereits vor der Installation über eine AD-integrierte oder externe PKI ein SSL-Zertifikat auf den vollqualifizierten DNS-Namen Ihres WAC-Servers ausstellen.

Das Setup ist mit wenigen Schritten erledigt. WAC möchte Diagnosedaten zu seiner Verwendung an Microsoft schicken. Hier haben Sie nur die Wahl zwischen den zwingend benötigten Daten oder zusätzlich optionalen Daten. Weiterhin dürfen Sie entscheiden, ob WAC Microsofts Updatedienst für Aktualisierungen nutzen soll. Der Assistent sieht für das Webfrontend als Standard den TCP-Port 443 vor. An dieser Stelle können Sie auch den Fingerabdruck Ihres eigenen Zertifikats angeben, falls vorhanden. Alternativ erzeugt das Setup ein selbstsigniertes Zertifikat, das allerdings nur 60 Tage gültig ist.

Im letzten Dialogschritt weist Ihnen der Assistent den Weg. Klicken Sie auf den URL der Form "https://<FQDN des Servers>:<Port>" oder übertragen Sie diesen in Ihren Browser. Das WAC fordert Sie nun zur Anmeldung auf. Der Server, auf dem das WAC installiert ist, fungiert als Gateway, um die Verbindung zu weiteren Systemen aufzunehmen und diese zu verwalten. Mittels des Dropdown-Menüs "Alle Verbindungen" in der Kopfzeile des Fensters nehmen Sie zusätzliche Server, Clientcomputer sowie auch Cluster auf. Navigieren Sie in den Bereich "Alle Verbindungen / Server-Manager" und richten Sie über die Schaltfläche "+ Hinzufügen" Verbindungen zu Ihren Instanzen von Windows Server 2022 ein.

Klicken Sie nun auf eine der Serververbindungen, fordert das WAC Sie zu einer erneuten Authentifizierung auf. Möchten Sie diese künftig vermeiden, richten Sie die eingeschränkte Kerberos-Delegierung vom WAC an den jeweiligen Zielserver ein. Das gelingt per PowerShell auf einem Domaincontroller oder einem Server mit installierten AD-Snap-ins [9]. In der Detailansicht des jeweiligen Servers wählen Sie nun aus der vertikalen Navigation den Punkt "Sicherheit". Im Hauptbereich der Seite rufen Sie dann die Registerkarte "Secured-Core" auf, um den Status der sechs Sicherheitsfunktionen anzuzeigen.

Den sicheren Start sowie das TPM können Sie an dieser Stelle nicht beeinflussen. Gibt das WAC für die beiden Funktionen "Nicht unterstützt" an, so bedeutet dies, dass Ihr System entweder nicht über die passende Hardware verfügt oder die Funktionen lediglich im UEFI oder den Eigenschaften der VM nicht eingeschaltet sind. Sobald Sie Secure Boot und TPM in der Firmware eines physischen Systems oder den Eigenschaften einer VM aktivieren, wechselt der Status im WAC zu "Ein". Die beiden Funktionen sind automatisch aktiv, weitere Optionen zur Konfiguration bieten sich nicht.

Sofern die Maschine die Voraussetzungen erfüllt, zeigt das WAC für die weiteren Funktionen den Status "Nicht konfiguriert" an. Setzen Sie jeweils die Checkbox in der ersten Spalte und klicken Sie auf die Schaltfläche "Aktivieren". Der Status der Komponenten wechselt damit auf "Aktiviert, wird aber nicht ausgeführt" und das WAC fordert einen Neustart für den Server an, den Sie direkt aus der Oberfläche heraus sofort auslösen oder aber einen passenden Zeitpunkt dafür einplanen. Der Status der Funktionen wechselt anschließend auf "Ein".

Virtuelle Instanzen von Windows Server 2022 müssen auf den DMA-Schutz beim Starten sowie die Systemüberwachung verzichten und haben mit vier von sechs Secure-Core-Funktionen ihren höchsten Schutzlevel erreicht (Bild 1). Physische Maschinen kommen auch in den Genuss der übrigen zwei Optionen, wenn alle Gerätetreiber mitspielen.

Alternativ zum WAC können Sie Gruppenrichtlinien verwenden, um die Funktionen des Secured-Core-Servers zu steuern. Die Optionen dazu finden Sie im Gruppenrichtlinienverwaltungs-Editor unter "Computerkonfiguration / Richtlinien / Administrative Vorlagen… / System / Device Guard" und dort innerhalb der Einstellung "Virtualisierungsbasierte Sicherheit aktivieren".

Aktivieren Sie diese Einstellung, regeln im Bereich der Optionen vier Dropdown-Felder die Details (Bild 2). Die erste Option der Plattform-Sicherheitsstufe aktiviert Secure Boot mit oder ohne DMA-Schutz. Dieg "Nicht konfiguriert" besagt, dass die Gruppenrichtlinie den auf einer Zielmaschine bereits vorhandenen Status von HVCI belässt. "Ohne Sperre aktiviert" entspricht dem Zustand, den Sie auch mittels WAC aktivieren konnten. HVCI wird in diesem Fall aktiviert und kann auch mittels Gruppenrichtlinie wieder deaktiviert werden. Die Option "Mit UEFI-Sperre aktiviert" verknüpft den Status von HVCI mit dem lokalen UEFI des Ziels, soweit kompatibel. In diesem Fall kann die Funktion aus der Ferne nicht mehr deaktiviert werden, weder per WAC noch per Gruppenrichtlinie.

Die Checkbox zur Speicherattributtabelle sorgt dafür, dass VBS und HVCI nur auf Systemen mit kompatiblem UEFI zum Einsatz kommen. Microsoft warnt andernfalls vor Abstürzen, Datenverlust oder Inkompatibilitäten beim Betrieb physischer Erweiterungskarten. Der Credential Guard zählt nicht zu den sechs Kernfunktionen des Secured-Core-Servers, nutzt aber VBS als Basis, um Anmeldeinformationen zu schützen. Die Optionen sind identisch zu denen der HVCI. Auch Credential Guard lässt sich an ein lokales UEFI anbinden. Zu guter Letzt regelt die Option der sicheren Startkonfiguration, ob die Systemüberwachung aktiv werden soll oder nicht.

Unter "Computerkonfiguration / Richtinien / Administrative Vorlagen… / System / Kernel-DMA-Schutz" finden Sie eine weitere Einstellung mit der etwas holprigen Übersetzung "Aufzählungsrichtlinie für externe Geräte, die nicht Kernel-DMA-Schutz kompatibel sind". Diese regelt, ob das Zielsystem Geräte, deren Treiber keine DMA-Neuzuordnung unterstützen, generell blockiert oder zulässt. Die dritte Option gibt als Standard vor, dass solche Geräte nur funktionieren, solange ein Benutzer angemeldet und der Bildschirm nicht gesperrt ist.

Der Secured-Core-Server nutzt sämtliche Sicherheitsfunktionen moderner Hardware und Virtualisierungsinfrastrukturen. Sofern UEFI und Gerätetreiber hierfür geeignet sind, gelingt die Inbetriebnahme mit wenigen Handgriffen. Der Secured-Core-Server reduziert die Angriffsfläche von Windows Server 2022 ohne weitere Kosten und mit geringst-möglichem Aufwand.