Tags: vSphere, Storage, Verschlüsselung
VMware vSphere kann seit der Version 6.5 virtuelle Maschinen auf dem Datenspeicher ("Encyption at rest") und beim Verschieben mit vMotion verschlüsseln. Die Besonderheit dieses Features besteht darin, dass es auf Hypervisor-Ebene arbeitet und damit unabhängig vom Gastbetriebssystem ist.
Die Verschlüsselung durch den Hypervisor hat den Vorteil, dass die Keys nicht über den Speicher der VM angreifbar sind. Bei jeder I/O-Operation zwischen VM und virtuellem Platten-Controller kodiert ein Kernelmodul den Datenstrom und sendet ihn bereits verschlüsselt zur Speicherschicht.
Verschlüsselung aller VM-Dateien
Von diesem Schutz profitieren sämtliche Dateien einer virtuellen Maschine einschließlich der virtuellen Laufwerke (VMDK), vmx-Konfigurationsdateien, Snapshot- und vmx-Swap-Files. Neben der Verschlüsselung 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üsselverschlüsselungs-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 kryptographische Privilegien verfügt.
Sollen in der Praxis nicht alle Administratoren 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üsselungstechnologie unterscheidet zwei Arten von 256-Bit-AES-Keys, die in den Verschlüsselungsprozess 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:
- Initiiert ein Nutzer eine Verschlüsselungsoperation, 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.
- 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.
- 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üsselmanagementserver 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 Vertrauenswürdigkeit des Zertifikats bestätigt.
Der Verbindungszustand 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 Voraussetzungen 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 Speicherrichtlinie 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 Speicherrichtlinie 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 unverschlü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 unverschlü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:
- Im ersten Schritt wird der verschlüsselte Core-Dump in einen digitalen Briefumschlag verpackt.
- Danach wird dieser Umschlag mit einem internen Schlüssel verschlüsselt
- 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
- Neu in VMware vSphere 7 Update 2: Integrierter KMS, ESXi Suspend-to-Memory, vSAN-Zugriff für normale vSphere-Cluster, Load-Balancer für Kubernetes
- Neu in vSphere 6.5: Verschlüsselte VMs, erweitertes HA, VMFS6
- VMware vSphere 7 Update 3: Neue Features in vSAN 7.2
- Neu in vSphere 7 Update 3: NSX-Integration, NVMe über TCP, Update für DRS, Precision Time
- Leistung von vSphere-Speicher überprüfen mit VMware Storage Performance Tester
Weitere Links