Shielded VMs

Die grundlegende Idee hinter den „Shielded VMs” lautet: Administratoren des physischen Virtualisierungs-Hosts bekommen keinen Zugriff auf die „geschützten VMs“. Dazu setzt Microsoft einiges an bestehender Technik ein: Bitlocker-Verschlüsselung, „Secure Boot“ und das „Virtual TPM“ (Trusted Platform module) werden kombiniert und zudem kommt mit dem „Host Guardian Service“ eine neues Feature mit ins Spiel. Ist eine Shielded VM erst einmal konfiguriert, lässt sie sich nur auf vorbestimmten Hosts einsetzen. Die VM selbst ist verschlüsselt, ebenso der Netzwerkverkehr – etwa bei der Live Migration. Allerdings sind auch Nachteile zu verzeichnen: Auf eine Shielded VM kann man nicht mehr über den Hyper-V Manager zugreifen, die virtuelle Disk dieser VM lässt sich nicht mehr außerhalb der VM mounten – und es ist eine geringere Performance zu verzeichnen: Microsoft spricht von 10 % weniger – wegen des massiven Einsatzes der Verschlüsselung.

In mittleren und größeren Unternehmen sind im IT-Bereich mehrere Administratoren im Einsatz. Üblicherweise teilen sie sich bestimmte Aufgabenbereiche: Einige sind für Virtualisierung zuständig, andere für den Speicher und wieder andere für das Netzwerk. Spezielle Aufgaben wie das Sichern der Umgebung werden unter Umständen auch einem Backup-Administrator zugeordnet.

In den meisten Fällen bekommen diese verschiedenen Administratoren den Zugriff auf die einzelnen Objekte einer virtuellen Maschine (VM) eingeräumt. Viele Organisationen – und dazu gehören auch Hosting Provider – stehen dabei vor der Herausforderung, dass einzelne VMs vor dem Zugriff durch Administratoren geschützt sein müssen – und genau das lässt sich mit den Shielded VMs erreichen.

Für den Schutz der VMs vor Administratoren gibt es heutzutage mehrere Gründe, zum Beispiel:

• Phishing Attacken,
• gestohlene Administrator-Anmeldeinformationen oder
• Angriffe von Insidern.

Eine Shielded VM bietet Schutz für die Daten der VM sowie für ihren Status. Dabei kann kein Unbefugter die VM inspizieren, sie stehlen oder Änderungen an ihr ausführen, selbst wenn er Administrator-Privilegien besitzt. Die Shielded VMs setzen allerdings voraus, dass es sich um VMs der zweiten Generation beim Hyper-V handelt. Denn nur sie bieten die nötigen Schutzvoraussetzungen. Dazu gehören „Secure Boot“, UEFI-Firmware und die Unterstützung von „Virtual TPM 2.0“ (Virtual Trusted Platform Module 2.0).

Dabei muss des Hostsystem für den Hyper-V als Betriebssystem den Windows Server 2016 verwenden, doch als Gastbetriebssysteme in der Shielded VM können Windows Server 2012 (oder neuere Versionen) zum Einsatz kommen. Zudem soll mit der Vorstellung des „echten“ Release von Windows Server 2016 auch recht schnell Linux als Gastbetriebssystem in einer Shielded VM unterstützt werden.

Eine Instanz des neu hinzugekommenen Host Guardian Service (HGS) muss in der Umgebung zum Einsatz kommen. Dieser Dienst nimmt die Schlüssel auf, die nötig sind, um Shielded VMs auf autorisierten Hyper-V-Hostsystemen laufen zu lassen, wenn sie ihren „gesunden“ (also nicht kompromittierten) Zustand nachweisen können.

Die Vorteile

Eine Shielded VM hat die folgenden Vorteile:

• Die zur VM gehörigen Festplatten sind über Bitlocker verschlüsselt (die Schlüssel dazu werden über das vTPM der VM geschützt).
• Es kommt ein gehärteter „VM Worker Process“ (VMWP) zum Einsatz, der unterbindet, dass die VM untersucht oder geändert wird.
• Wenn es zu einer Live Migration der Shielded VM kommt, wird der Netzwerkverkehr automatisch verschlüsselt. Auch die Laufzeit-Zustandsdatei, die gesicherten Zustände, die Checkpoints und sogar die Hyper-V-Replica-Dateien werden verschlüsselt.
• Zudem gibt es keinen Zugriff über die Konsole, zusätzlich dazu werden auch die Powershell-Direct-Zugriffe unterbunden. Aber auch andere Komponenten, wie etwa die Guest File Copy Integration oder Dienste, die unter Umständen den Zugriff über einen Pfad für einen Benutzer oder Prozess mit administrativen Berechtigungen auf die VM erlauben, werden geblockt.

Damit das realisiert werden kann, muss zunächst sicher sein, dass der Hyper-V-Host nicht kompromittiert wurde, ehe die für den Zugriff auf die Shielded VM nötigen Schlüssel vom HGS freigegeben wurden. Der „saubere Zustand“ des Host-Systems wird von einem Prozess namens „Attestation“ bestimmt. Das kann auf zwei Arten erfolgen: Eine TPM-basierte „Attestation“ oder aber eine Active Directory-basierte „Attestation“.

Die bevorzugte und stärkste Methodik ist die TPM-basierte. Sie benötigt TPM 2.0 (frühere TPMs werden nicht unterstützt) beim Hyper-V-Hosts. Mit Hilfe des „Secure Boot“ und des TPM werden der Boot-Pfad und die Code-Integrität des Servers sichergestellt. Das garantiert, dass sich keine Malware, keine Rootkits oder nicht zulässige Software auf dem Server befinden. Die die Sicherheit des Systems kompromittieren könnten. Das TPM wird zudem verwendet, um die Kommunikation zum und vom HGS Attestation-Dienst abzusichern.

Wenn ein Host-System nicht über TPM 2.0 verfügt, kann man alternativ das AD-basierte Attestation-Modell einsetzen. Jedoch wird dabei nur geprüft, ob der Host ein Teil einer vordefinierten AD-Gruppe ist. Diese Alternative bietet nicht dieselben Schutz- und Sicherheitsfunktionalitäten wie das TPM-basierte Modell. Ein cleverer Hacker könnte es wohl beim AD-basierten Verfahren mit einem gewissen Aufwand schaffen, auf die VMs zuzugreifen.

Ausgabe des Zertifikats

Wenn ein Host nun diese Attestation-Phase erfolgreich absolviert hat, bekommt er vom Attestation-Dienst des HGS ein entsprechendes Zertifikat, das den Host autorisiert, um an die Schlüssel des „Key Protection Service“ (KPS) zu kommen. Dabei läuft der KPS ebenfalls auf dem HGS. Während der Übertragung sind die Schlüssel selbst ebenfalls verschlüsselt und sie lassen sich nur mit einem geschützten Objekt (es ist neu bei Windows 10 und beim Windows Server 2016, Microsoft bezeichnet es als „Enclave“) entschlüsseln.

Die Schlüssel können dann verwendet werden, um das vTPM zu entschlüsseln, über das dann die VM auf ihren via Bitlocker geschützten Speicher und Startbereich zugreifen kann. Damit ist sichergestellt, dass nur ein Host-System, das autorisiert und „sauber“ ist, die benötigten Schlüssel bekommt und den VMs (und nicht den Administratoren; denn die VHD liegt immer noch verschlüsselt auf der Festplatte) den Zugriff auf den verschlüsselten Storage gewährt.

An diesem Punkt könnte man argumentieren, dass man als Administrator auf dem Hyper-V-Host doch die Möglichkeit hat, die für den Zugriff auf die VM notwendigen Schlüssel aus dem Arbeitsspeicher des Hosts auszulesen und somit alle Sicherheitsvorkehrungen aushebeln kann. Doch ein weiteres neues Feature bei Windows 10 und Windows Server 2016 hilft hier. Das ist die geschützte „Enclave“ – sie wird als Virtual Secure Mode (VSM) bezeichnet und besteht aus einer Anzahl von Komponenten.

Beim VSM handelt es sich um eine sichere Ausführungsumgebung, bei der alle Schlüssel und sonstigen schützenswerte Objekte verwaltet werden. Zudem werden alle kritischen sicherheitsrelevanten Prozesse als „Trustlets“ (kleine vertrauenswürdige Prozesse) in einer sicheren virtualisierten Partition ausgeführt werden. Dabei handelt es sich nicht um eine VM des Hyper-V – man sollte sich das eher wie ein kleiner virtueller Safe vorstellen, der über Virtualisierungs-basierte Technologien (wie SLAT und IOMMU) geschützt wird. Damit ist es nicht möglich, zum Beispiel den Arbeitsspeicher auszulesen oder einen DMA-Angriff zu starten.

Das Windows-Betriebssystem – auch nicht der Betriebssystemkern – hat keinen Zugriff auf den VSM. Nur spezielle „White-gelistete“ Prozesse (die Trustlets), die von Microsoft signiert worden sind, dürfen die Brücke zum VSM überschreiten. Generell ist es so geregelt, dass es keinen Weg gibt, auf den Arbeitsspeicher mit den Schlüsseln zuzugreifen, selbst wenn man kompletten Kernel-Zugriff bekommt. Mit einem Debugger könnte man zum Beispiel nicht an diese Informationen gelangen, denn das würde im Zuge des Attestation-Prozesses bemerkt und der „Gesundheits-Check“ würde fehlschlagen – Resultat: Die Schlüssel würden nicht an den Host übermittelt. (rhh)