ESXi 6.5 Encryption - Video und Text

Verschlüsselung von virtuellen Maschinen

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Das Verschlüsseln erfolgt bei vSphere auf Hypervisor-Level und damit agnostisch für die VM.
Das Verschlüsseln erfolgt bei vSphere auf Hypervisor-Level und damit agnostisch für die VM. (Bild: Thomas Drilling)

„VMware vSphere“ ist seit Veröffentlichung der Version 6.5 vor ziemlich genau einem Jahr auch in der Lage, VMs „in Rest“ (auf dem Storage) und „in Flight“ (etwa beim Verschieben via „vMotion“) zu verschlüsseln. Dies geschieht unabhängig von der VM selbst und damit für diese und den Nutzer transparent.

Mit dem Zusammenwachsen von on premise betriebenen Datacenter samt Virtualisierung und Infrastruktur in der Private- oder Public Cloud wird es für viele Unternehmen immer wichtiger, VMs verschlüsselt abzulegen, insbesondere wenn sich VMs wie bei VMware nahtlos und transparent in die Cloud verschieben lassen. Im Gegensatz aber zu Gastsystem-zentrierten Lösungen wie „Bitlocker“&Co hatte VMware von Anfang an geplant den Ansatz, den Vorgang des Ver- und Entschlüsseln von VMs sowie das Schlüssel-Management für Nutzer einfach und transparent zu gestalten.

Wurde die im Folgenden beschriebene Konfiguration eines unterstützten KMS-Servers einmal erfolgreich abgeschlossen, muss sich der Nutzer um nichts mehr kümmern und kann VMs einfach durch Zuweisen einer Storage-Policy verschlüsseln. Er hat dann nichts mehr zu tun mit dem Verwalten von Schlüssel-Servern oder Schlüsseln, Verwalten von Verschlüsselungsrichtlinien und er benötigt auch keinen Konsolen-Zugriff auf VMs, um diese zu verschlüsseln. Er muss auch keine verschlüsselten VMNs manuell auf einen Datastore hochladen.

Das VM-Verschlüsselungs-Feature in „vSphere 6.5“ geht weit über die Standard-VM-Level-Sicherheit hinaus, da es die Verschlüsselung auf Hypervisor-Ebene durchführt. Dies macht die Verschlüsselung nicht nur agnostisch, sondern auch einfach per Storage-Policy steuerbar.

Damit sind für Anwender die Verschlüsselung des Storage Area Networks oder des unterliegenden Storage nicht mehr die einzigen Optionen. Wie bei jedem Verschlüsselungssystem zu erwarten gibt es zwar einen geringen Overhead für die VM-Verschlüsselung, in der Praxis ist davon jedoch nichts zu bemerken. Damit all das wie beschreiben funktioniert, müssen die involvierten Komponenten wie folgt zusammenspielen. Den kompletten Workflow demonstriert ergänzend dieses Video.

KMS

Das Einrichten des kryptographischen Backends ist einfach. Bei markiertem „vCenter“-Objekt fügt man im Tab „Konfigurieren“ im Abschnitt „Mehr / Schlüsselmanagementserver“ mit „KMS hinzufügen“ zuerst einen neuen KMS-Cluster/Server hinzu, der in der Umgebung vorhanden sein muss. Derzeit unterstützt VMware vSphere 6.5 zum Beispiel „IBM Security Key Lifecycle Manager“, „EMC Cloudlink“ und „HyTrust KeyControl“ sowie „Thales KMS“.

Einzelheiten verrät die VMware HCL. Das gewählte System muss lediglich mit dem KMIP-Standard 1.1 kompatibel sein, spricht beim eigentlichen Schlüssel-Management-Backend handelt es sich um ein externes-System, das Key-Management-Services für diverse KMIP-Clients bereit stellt, von denen etwa das vCenter einer ist.

Der Zugriff auf das KMS-System erfolgt über IP. vCenter selbst speichert lediglich die KMS-Credentials und kümmert sich im Rahmen der Schlüsselverwaltung beziehungsweise der Verschlüsselung um das Empfangen von Schlüsselverschlüsselungs-Keys vom KMS, das Verteilen von Datenverschlüsslungs-Keys auf die ESXi-Hosts sowie deren Identifikation anhand von UUIDs.

Ergänzendes zum Thema
 
Kurz zusammengefasst

Der KMS-Client im vCenter verwaltet sämtliche Berechtigungen. Dazu hat per Default die Rolle „vCenter Administrator“ kryptographische Privilegien. Damit in der Praxis nicht alle Administratoren die Berechtigung haben, kryptographische Operationen auszuführen, hat VMware mit der Version 6.5 zudem eine neue Rolle „No Cryptogaphy Administrator“ eingeführt.

Ferner zeichnet das vCenter für Auditing-Zwecke Events bei der Kommunikation mit dem KMS auf. Ist das vCenter nicht verfügbar, funktioniert auch die Ver- und Entschlüsselung von virtuellen Maschinen nicht.

Beim Konfigurieren der Verbindung vom vCenter zum KMS braucht man Name nebst Alias sowie die IP eines KMS-Cluster oder KMS-Servers, die Port-Nummer 5696 (Default), sowie gegebenenfalls (optionale) einen Anmeldenamen.

Die Verbindung zum KMS-System muss lediglich 1 mal im vCenter konfiguriert werden.
Die Verbindung zum KMS-System muss lediglich 1 mal im vCenter konfiguriert werden. (Bild: Thomas Drilling)

Zudem muss der Admin dem KMS vertrauen, das Heißt: Es gibt immer eine gesicherte Verbindung zwischen KMS und vCenter. Im Web-Client erscheint hierzu ein Fenster, in dem der Nutzer die Verbindung als vertraut einrichtet. Der Verbindungszustand des KMS-Servers sollte anschließend „Normal“ sein und der Zertifikatsstatus gültig:

Funktioniert der KMS, bzw. dessen Verbindung mit dem vCenter, kann der Anwender die VM-Verschlüsselung konfigurieren.

Das Zusammenspiel der Schlüssel

Bei VMware sind zwei Arten von Schlüsseln in den Verschlüsselungsprozess involviert: Data Encryption Keys (DEK) und Key Encryption-Keys (KEK). Alles sind XTS-AES-256-Schlüssel. Erstere werden von ESXi selbst generiert, ausschließlich im RAM gespeichert und für kryptografische Funktionen auf den Hosts verwendet.

Die KEKs hingegen werden vom KMS-Server generiert und zum Ver- und Entschlüsseln der DEKs auf die ESXi-Server übertragen. Erst die verschlüsselten DEKs werden dann im vmx-File der jeweiligen virtuellen Maschine gespeichert und niemals auf den Datenträgern eines ESXi-Host abgelegt. Die Zwischenschlüssel zum Ver- und Entschlüsseln der VMs befinden sich also sozusagen immer in einer sicheren Verschlüsselungs-Enklave. Im Detail sieht der Prozess so aus:

  • 1. Stößt ein Nutzer eine Verschlüsselungsoperation an, etwa das Einschalten einer verschlüsselten VM, fordert vCenter zunächst einen neuen KEK vom KMS-Server an. Der KEK selbst wird unter keinen Umständen vom, bzw. auf dem vCenter gespeichert. Dieser kennt und speichert nur die zugehörige ID.
  • 2. vCenter speichert zunächst die Key-ID und leitet den Key selbst direkt zum ESXI-Host weiter. Gehört der ESXi-Host zu einen Cluster, sendet der vCenter-Server den KEK auch an alle anderen Hosts im Cluster.
  • 3. Nun liest jeder ESXi-Host im Cluster den verschlüsselten DEK aus dem vmx-File aus, entschlüsselt diesen mit dem KEK und kann mit diesem die virtuelle Maschine (VMDK) entschlüsseln und einschalten.

Der Workflow zum Verschlüsseln des I/Os beim einschließlich Schlüsselmanagement.
Der Workflow zum Verschlüsseln des I/Os beim einschließlich Schlüsselmanagement. (Bild: Thomas Drilling)

Storage Policy

Die Benutzung der Verschlüsselung ist - sind alle Voraussetzungen erfüllt (KSM-Cluster vorhanden, alle Hosts im Cluster auf Version 6.5) - tatsächlich überaus einfach, da VMware dazu eine eigene Storage-Policy „Encryption“ bereit stellt, die widerum als E/A-Filter implementiert ist (siehe: Abbildung). Dazu wirft man vorab einen Blick „in“ die Verschlüsselungs-Richtlinie im Policy-Editor. Administratoren können aber auch jederzeit eine eigene Storage-Policy für Encryption erstellen, wie die Abbildung zeigt:

So sieht einer Speicherrichtlinie zur Verschlüsselung aus.
So sieht einer Speicherrichtlinie zur Verschlüsselung aus. (Bild: Thomas Drilling)

Beim Erstellen einer neuen verschlüsselten VM genügt es dann, im Schritt 2c des Assistenten bei der Auswahl des Datastores die entsprechende Speicherrichtlinie auszuwählen. Im Schritt 2f des Assistenten beim Anpassen der virtuellen Hardware hängt der neuen Disk dann bereits die gewählte Storage-Policy an.

BU: Das Verschlüsseln einer neuen VM nutzt ebenfalls eine Speicherrichtlinie direkt im Create-VM-Assistenten.
BU: Das Verschlüsseln einer neuen VM nutzt ebenfalls eine Speicherrichtlinie direkt im Create-VM-Assistenten. (Bild: Thomas Drilling)

Zum Verschlüsseln einer bisher unverschlüsselten VM gehen Admins hingegen wie folgt vor: Bevor sich das Gerät verschlüsseln lässt, muss es ausgeschaltet sein. Dann öffnet der Admin im Kontextmenü der zu verschlüsselnden VM das Kontextmenü „VM-Richtlinie / VM-Speicherrichtlinie bearbeiten“, wählt bei „VM-Speicherrichtlinie“ die „Encryption-Policy“ und ordnet dann den Objekten „VM-Home“ und der jeweiligen virtuellen Festplatte ebenfalls die „Encryption-Policy“ zu.

Das Verschlüsseln der VM geschieht einfach durch Zuweisen einer Storge-Policy
Das Verschlüsseln der VM geschieht einfach durch Zuweisen einer Storge-Policy (Bild: Thomas Drilling)

Das Deaktivieren der VM-Verschlüsselung ist ebenso einfach wie das Ändern einer vorhandenen Speicher-Richtlinie auf die Standard-Datenspeicherrichtlinie. Auch dazu muss die VM ausgeschaltet sein.

Zu beachten ist allerdings, dass das Exportieren verschlüsselter VMs in das OVF-Format nicht unterstützt wird. Außerdem funktioniert das Verschlüsseln einer bestehenden VM „intern“ etwas anders, als das Neuerstellen einer verschlüsselten VM.

Beim Verschlüsseln einer bestehenden unverschlüsselten VM erstellt das System zunächst ein Duplikat der zu verschlüsselnden Disk mit angehängtem I/O-Filter für „Encrytion“. Danach werden die Daten von der unverschlüsselten auf die verschlüsselte Disk kopiert. Erst dann wird die neue verschlüsselte Disk an die VM angehängt und die „Alte“ gelöscht. Das Ganze funktioniert dabei immer nur für eine Disk zur gleichen Zeit. Außerdem muss der Datastore die Kapazität zum temporären Aufnehmen der duplizierten Disk verfügen.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44897965 / Verschlüsselung)