Anleitung: Virtuelle Maschinen in vSphere 6.5 verschlüsseln

    Kostenloses E-Book: Installation, Upgrade und Patchen von VMware vSphere mit Image Builder, VUM, Auto Deploy, Host Profiles. 112 Seiten. Download »

    (Anzeige)

    Laufwerke und VMs verschlüsselnVMware vSphere kann seit der Version 6.5 virtu­elle Maschinen auf dem Daten­speicher ("Encyp­tion at rest") und beim Ver­schieben mit vMotion ver­schlüsseln. Die Beson­derheit dieses Features besteht darin, dass es auf Hypervisor-Ebene arbeitet und damit unab­hängig vom Gast­betriebs­system ist.

    Die Verschlüs­selung 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 Kernel­modul 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-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.

    Ablauf der VM-Verschlüsselung unter vSphere

    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.

    KMS-Server für VM-Verschlüsselung in vSphere hinzufügen

    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.

    Zertifikat des KMS-Servers als vertrauenswürdig akzeptieren

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

    Statusanzeige für denKMS-Server nach dem erfolgreichen Hinzufügen zu vCenter.

    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 Storage-Policy Encryption ist als E/A-Filter implementiert.

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

    Die Eigenschaften der Storage-Policy für die Verschlüsselung lassen sich im Editor anzeigen.

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

    Eigene Storage-Policy für die Verschlüsselung anlegen

    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.

    Laufwerke einer neuen VM gleich beim Anlegen verschlüsseln

    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.

    Speicherrichtlinie zur Verschlüsselung einer bestehenden VM zuordnen.

    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.

    Durch Entfernen der Storage-Policy lässt sich die Verschlüsselung aufheben.

    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.

    Kennwort zur Verschlüsselung eines Core-Dumps im vSphere Web-Client eingeben.

    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.

    Keine Kommentare