Anleitung: Virtuelle Maschinen in vSphere 6.5 verschlüsseln

Von diesem Schutz profitieren sämtliche Dateien einer virtuellen Maschine einschließlich der virtuellen Laufwerke (VMDK), vmx-Konfigurations­dateien, Snapshot- und vmx-Swap-Files. Neben der Verschlüs­selung auf der Platte unterstützt VMware auch jene von VMs bei der Migration (Encrypted vMotion oder "Encryption in flight"), das Verschlüsseln von CoreDumps (Encryted Core Dumps) und verschlüsselte Backups.

Das Feature leidet aktuell aber noch unter einigen Einschränkungen. So werden das Pausieren und Fortsetzen verschlüsselter virtueller Maschinen, Snapshots verschlüsselter VMs, vSphere-Replikation und das Content-Library-Feature nicht unterstützt.

KMS-Infrastruktur als Voraussetzung

Die Verschlüsselung in vSphere 6.5 lässt sich nur nutzen, wenn in der eigenen Umgebung ein Key-Management-Server (KMS) existiert. Momentan unterstützt VMware unter anderem IBM Security Key Lifecycle Manager, EMC Cloudlink, HyTrust KeyControl oder Thales KMS.

Einzelheiten finden sich in VMwares HCL. Das gewählte System muss lediglich mit dem KMIP-Standard 1.1 kompatibel sein. KMS ist also ein externes-System, das diverse KMIP-Clients bereitstellt, von denen vCenter nur eines ist.

Key-Management in vCenter

vCenter speichert nur die KMS-Credentials, jedoch nicht die Schlüssel selbst, sondern nur deren ID. Außerdem kümmert es sich um das Anfordern/Empfangen von Schlüssel­verschlüs­selungs-Keys, sowie das Weiterleiten dieser Schlüssel auf die ESXi-Hosts.

Der KMS-Client in vCenter verwaltet zudem sämtliche Berechtigungen, so dass die Administrator-Rolle ab vSphere 6.5 zusätzlich über krypto­graphische Privilegien verfügt.

Sollen in der Praxis nicht alle Admini­stratoren diese Berechtigung besitzen, dann kann man die mit der Version 6.5 neu eingeführte Rolle No Cryptogaphy Administrator verwenden. Außerdem zeichnet vCenter für Auditing-Zwecke Events bei der Kommunikation mit dem KMS auf.

Schlüssel-Rolle

VMwares Verschlüsselungs­technologie unterscheidet zwei Arten von 256-Bit-AES-Keys, die in den Verschlüs­selungs­prozess involviert sind: Data Encryption Keys (DEK) und Key Encryption-Keys (KEK).

DEKs werden von ESXi selbst generiert, ausschließlich im RAM  abgelegt und für kryptografische Funktionen auf den Hosts benutzt. KEKs dagegen werden vom KMS-Server generiert und zum Ver- und Entschlüsseln der DEKs über vCenter auf die ESXi-Server verteilt.

Die verschlüsselten DEKs werden dann im vmx-File der jeweiligen virtuellen Maschine gespeichert und nicht auf lokalen Datenträgern eines ESXi-Hosts. Im Detail sieht der Prozess beispielsweise beim Einschalten einer verschlüsselten VM so aus:

1. Initiiert ein Nutzer eine Verschlüsselungs­operation,  fordert vCenter einen neuen KEK vom KMS-Server an. Der KEK wird vom KMS geliefert, aber nicht auf dem vCenter-Server gespeichert. Das vCenter merkt sich nur dessen ID für die Zuordnung.
2. vCenter leitet den Key zu den beteiligten ESXi-Hosts weiter. Ist der Host Mitglied eines Clusters, sendet vCenter den KEK auch an alle anderen Hosts im Cluster.
3. Anschließend liest jeder ESXi-Host im Cluster den verschlüsselten DEK aus dem vmx-File aus, entschlüsselt ihn mit dem KEK und kann mit diesem die virtuelle Maschine (VMDK) einschalten.

KMS einrichten

Das Konfigurieren der Verbindung zum KMS ist schnell erledigt. Hierzu klickt man bei markiertem vCenter-Objekt im Tab Konfigurieren im Abschnitt Mehr => Schlüssel­management­server auf KMS hinzufügen.

Das Konfigurieren der Verbindung vom vCenter-Server zum KMS erfordert einen Namen nebst Alias sowie die IP des KMS-Clusters oder -Servers, die Portnummer 5696 (Default) und einen optionalen Anmeldenamen.

Der Folge-Dialog weist darauf hin, dass man dem KMS vertrauen muss, weil die Kommunikation immer über eine gesicherte Verbindung läuft. Der Web Client präsentiert dann einen Dialog, in dem man die Vertrauens­würdigkeit des Zertifikats bestätigt.

Der Verbindungs­zustand des KMS-Servers ist anschließend  Normal, sein der Zertifikatsstatus gültig.

Erst wenn die Verbindung zum KMS funktioniert, lässt sich die VM-Verschlüsselung konfigurieren.

Storage Policy

Das Verwenden der VM-Verschlüsselung ist, sofern alle Voraus­setzungen erfüllt sind (KMS-Cluster vorhanden, alle Hosts im Cluster auf Version 6.5), weil VMware dazu eine eigene Storage-Policy Encryption bereitstellt. Diese ist als E/A-Filter implementiert ist, wie die Abbildung zeigt.

Die zugehörige Speicher­richtlinie für die Verschlüsselung lässt sich im Policy-Editor verifizieren.

Der Nutzer kann aber auch seine eigene Storage-Policy für Encryption erstellen.

Verschlüsselung anwenden

Bei der Verschlüsselung muss man zwischen dem Ver-/Entschlüsseln einer bestehenden VM und dem Neuerstellen einer verschlüsselten VM unterscheiden. Im zweiten Fall muss der Nutzer im Assistenten für neue VMs bei der Auswahl des Datastores unter 2c nur die entsprechende Speicher­richtlinie wählen.

Im Schritt 2f beim Anpassen der virtuellen Hardware hängt dem neu zu erstellenden Datenträger dann die gewählte Storage-Policy bereits an.

Vorhandene VM kodieren

Das Verschlüsseln einer bestehenden VM funktioniert etwas anders. Hierbei erstellt das System zunächst ein Duplikat der zu verschlüsselnden Disk mit angehängtem I/O-Filter für Encrytion und kopiert danach die Daten von der unver­schlüsselten auf die verschlüsselte Disk. Deshalb nimmt der Vorgang unter Kürzlich bearbeitete Aufgaben etwas Zeit in Anspruch.

Erst dann wird die neue verschlüsselte Disk an die VM angehängt und das ursprüngliche Laufwerk  gelöscht. Das Ganze funktioniert immer nur für eine Disk zur gleichen Zeit. Der Datastore muss zudem über genügend Kapazität zum temporären Aufnehmen der duplizierten Disk verfügen.

Der Workflow zum Verschlüsseln einer bisher unver­schlüsselten VM ist indes noch einfacher als bei einer neuen VM. Dazu muss der Nutzer die betreffenden VMs zunächst ausschalten.

Dann öffnet er im Kontextmenü einer zu verschlüsselnden VM VM-Richtlinie / VM-Speicherrichtlinie bearbeiten, wählt bei VM-Speicherrichtlinie die Encryption-Policy und weist den Objekten VM-Home und der jeweiligen virtuellen Festplatte ebenfalls die Encryption-Policy zu.

Genauso einfach gelingt das Deaktivieren der VM-Verschlüsselung. Auch dazu muss man die VM ausschalten. Das Exportieren verschlüsselter VMs in das OVF-Format wird übrigens nicht unterstützt.

Verschlüsselte Core-Dumps

Ein Core-Dump ist ein auf Platte geschriebener Speicherzustand zum Zeitpunkt eines Systemabsturzes. Er wird vom VMware Technical Support Personal beim Debuggen von Abstürzen mit einem Purple Screen Of Death (PSOD) verwendet.

Core-Dumps enthalten daher im Zweifel auch sensitive Daten wie die Schlüssel für die VM-Encryption. Sie werden normalerweise unter /var/core auf dem jeweiligen ESXI-Host abgelegt. Daher ist es wichtig, auch Core Dumps zu schützen, auch wenn diese "nur" vom VMware-Support angefordert werden.

Sobald also die Verschlüsselung unter vSphere 6.5 eingerichtet ist, werden Core-Dumps automatisch verschlüsselt, um die Kundendaten zu schützen. Und das geschieht wie folgt:

1. Im ersten Schritt wird der verschlüsselte Core-Dump in einen digitalen Briefumschlag verpackt.
2. Danach wird dieser Umschlag mit einem internen Schlüssel verschlüsselt
3. Der interne Schlüssel wiederum ist durch den Host-Key geschützt.

Zum Öffnen des Umschlags wird dann der Host-Key benötigt, der nur auf dem betreffenden Host verfügbar ist.

Beim Exportieren von System-Logs über den Web-Client kann der Nutzer daher ein Passwort einrichten, bevor er sein Log-Bundle exportiert und an VMware weitergibt.