Unabhängig davon, welchen Schlüsselanbieter Sie verwenden, können Sie mit vSphere Virtual Machine Encryption verschlüsselte virtuelle Maschinen erstellen und vorhandene virtuelle Maschinen verschlüsseln. Da alle Dateien der virtuellen Maschine, die vertrauliche Informationen enthalten, verschlüsselt werden, ist die virtuelle Maschine geschützt. Nur Administratoren mit Berechtigungen zum Verschlüsseln können Verschlüsselungs- und Entschlüsselungsaufgaben durchführen.

Wichtig: ESXi Shell-Benutzer verfügen auch über Berechtigungen für kryptografische Vorgänge. Weitere Informationen finden Sie unter Voraussetzungen und erforderliche Berechtigungen für VM-Verschlüsselungsaufgaben.

Welcher Speicher wird von vSphere Virtual Machine Encryption unterstützt

vSphere Virtual Machine Encryption funktioniert mit allen unterstützten Speichertypen (NFS, iSCSI, Fibre Channel, direkt angeschlossener Speicher usw.), einschließlich VMware vSAN. Weitere Informationen zur Verwendung von Verschlüsselung auf einem vSAN-Cluster finden Sie in der Verwalten von VMware vSAN-Dokumentation.

vSphere Virtual Machine Encryption und vSAN verwenden dieselben Verschlüsselungsbibliotheken, aber unterschiedliche Profile. Bei der VM-Verschlüsselung handelt es sich um eine Verschlüsselung pro VM, während es sich bei vSAN um eine Verschlüsselung auf Datenspeicherebene handelt.

vSphere-Verschlüsselungsschlüssel und -Schlüsselanbieter

vSphere verwendet zwei Verschlüsselungsebenen in Form eines Schlüsselverschlüsselungsschlüssels (Key Encryption Key, KEK) und eines Datenverschlüsselungsschlüssels (Data Encryption Key, DEK). Kurz gesagt erzeugt ein ESXi-Host einen DEK, um virtuelle Maschinen und Festplatten zu verschlüsseln. Der KEK wird von einem Schlüsselserver bereitgestellt und zur Verschlüsselung (oder „Packung“) des DEK verwendet. Der KEK wird mithilfe des AES256-Algorithmus verschlüsselt und der DEK wird mithilfe des XTS-AES-256-Algorithmus verschlüsselt. Je nach Typ des Schlüsselanbieters werden verschiedene Methoden zum Erstellen und Verwalten des DEK und KEK verwendet.

Der Standardschlüsselanbieter funktioniert wie folgt.
  1. Der ESXi-Host generiert und verwendet interne Schlüssel zum Verschlüsseln von virtuellen Maschinen und Festplatten. Diese Schlüssel werden als DEKs verwendet.
  2. vCenter Server fordert Schlüssel aus dem Schlüsselserver (KMS) an. Diese Schlüssel werden als KEKs verwendet. vCenter Server speichert nur die ID jedes KEK, nicht jedoch den Schlüssel selbst.
  3. ESXi verwendet den KEK zum Verschlüsseln der internen Schlüssel und speichert den verschlüsselten internen Schlüssel auf der Festplatte. ESXi speichert den KEK nicht auf der Festplatte. Wenn ein Host neu gestartet wird, fordert vCenter Server den KEK mit der entsprechenden ID beim Schlüsselserver an und macht ihn für ESXi verfügbar. ESXi kann dann die internen Schlüssel nach Bedarf entschlüsseln.

Der vertrauenswürdige vSphere Trust Authority-Schlüsselanbieter funktioniert folgendermaßen.

  1. Der vCenter Server des vertrauenswürdigen Clusters überprüft, ob der ESXi-Host, auf dem die verschlüsselte virtuelle Maschine erstellt werden soll, auf den standardmäßigen vertrauenswürdigen Schlüsselanbieter zugreifen kann.
  2. Der vCenter Server des vertrauenswürdigen Clusters fügt dem vertrauenswürdigen Schlüsselanbieter die Konfigurationsspezifikation der virtuellen Maschine hinzu.
  3. Die Anforderung zum Erstellen der virtuellen Maschine wird an den ESXi-Host gesendet.
  4. Wenn dem ESXi-Host noch kein Bestätigungstoken zur Verfügung steht, wird ein Token beim Bestätigungsdienst angefordert.
  5. Der Schlüsselanbieterdienst validiert das Bestätigungstoken und erstellt einen KEK, der an den ESXi-Host gesendet werden soll. Der KEK wird mit dem auf dem Schlüsselanbieter konfigurierten primären Schlüssel verschlüsselt. Sowohl der verschlüsselte KEK-Text als auch der KEK-Klartext werden an den vertrauenswürdigen Host zurückgegeben.
  6. Der ESXi-Host erzeugt einen DEK, um die Festplatten der virtuellen Maschine zu verschlüsseln.
  7. Der KEK wird zum Verschlüsseln des vom ESXi-Host generierten DEK verwendet und der Verschlüsselungstext des Schlüsselanbieters wird mit den verschlüsselten Daten gespeichert.
  8. Die virtuelle Maschine wird verschlüsselt und in den Speicher geschrieben.
Hinweis:

Die ESXi-Hosts in vSphere-Clustern enthalten den KEK für verschlüsselte virtuelle Maschinen im Hostarbeitsspeicher, um Verfügbarkeitsfunktionen wie Hochverfügbarkeit, vMotion, DRS usw. zu ermöglichen. Wenn eine virtuelle Maschine gelöscht oder die Registrierung einer virtuellen Maschine aufgehoben wird, löschen die ESXi-Hosts im Cluster den KEK aus ihrem Arbeitsspeicher. Somit kann der ESXi-Host den KEK nicht mehr verwenden. Dieses Verhalten ist für Standardschlüsselanbieter und vertrauenswürdige Schlüsselanbieter identisch.

Der vSphere Native Key Provider funktioniert folgendermaßen.

  1. Wenn Sie den Schlüsselanbieter erstellen, generiert vCenter Server einen primären Schlüssel und über gibt ihn an die ESXi-Hosts im Cluster weiter. (Es ist kein externer Schlüsselserver beteiligt.)
  2. Die ESXi-Hosts erzeugen bei Bedarf einen DEK.
  3. Wenn Sie eine Verschlüsselungsaktivität durchführen, werden die Daten mit dem DEK verschlüsselt.

    Verschlüsselte DEKs werden neben den verschlüsselten Daten gespeichert.

  4. Wenn Sie Daten entschlüsseln, wird der primäre Schlüssel verwendet, um den DEK und dann die Daten zu entschlüsseln.

Welche Komponenten werden von vSphere Virtual Machine Encryption verschlüsselt

vSphere Virtual Machine Encryption unterstützt die Verschlüsselung von Dateien der virtuellen Maschine, von virtuellen Festplattendateien und von Core-Dump-Dateien.
Dateien der virtuellen Maschine
Die meisten Dateien der virtuellen Maschine werden verschlüsselt, insbesondere Gastdaten, die nicht in der VMDK-Datei gespeichert werden. Zu diesen Dateien gehören unter anderen die NVRAM-, VSWP- und VMSN-Dateien. Der Schlüssel vom Schlüsselanbieter entsperrt ein verschlüsseltes Paket in der VMX-Datei, die interne Schlüssel und andere Geheimschlüssel enthält. Der Schlüsselabruf funktioniert je nach Schlüsselanbieter wie folgt:
  • Standardschlüsselanbieter: vCenter Server verwaltet die Schlüssel vom Schlüsselserver und ESXi-Hosts können nicht direkt auf den Schlüsselanbieter zugreifen. Die Hosts warten, bis vCenter Server die Schlüssel überträgt.
  • Vertrauenswürdiger Schlüsselanbieter und vSphere Native Key Provider: Die ESXi-Hosts greifen direkt auf die Schlüsselanbieter zu und rufen die angeforderten Schlüssel entweder direkt vom vSphere Trust Authority-Dienst oder vom vSphere Native Key Provider ab.
Wenn Sie den vSphere Client zum Erstellen einer verschlüsselten virtuellen Maschine verwenden, können Sie virtuelle Festplatten getrennt von VM-Dateien verschlüsseln und entschlüsseln. Alle virtuellen Festplatten sind standardmäßig verschlüsselt. Für andere Verschlüsselungsaufgaben wie das Verschlüsseln einer vorhandenen virtuellen Maschine können Sie virtuelle Festplatten getrennt von Dateien der virtuellen Maschine verschlüsseln und entschlüsseln.
Hinweis: Eine verschlüsselte virtuelle Festplatte kann nicht einer unverschlüsselten virtuellen Maschine zugeordnet werden.
Virtuelle Festplattendateien
Daten in einer Datei einer verschlüsselten virtuellen Festplatte (VMDK-Datei) werden nie in Klartext in den Speicher oder auf eine physische Festplatte geschrieben und nie in Klartext über das Netzwerk übertragen. Die VMDK-Deskriptordatei besteht zum größten Teil aus Klartext, enthält jedoch eine Schlüssel-ID für den KEK und den internen Schlüssel (DEK) im verschlüsselten Paket.
Sie können den vSphere Client oder die vSphere-API verwenden, um einen flachen Neuverschlüsselungsvorgang mit einem neuen KEK durchzuführen, oder mithilfe der vSphere-API einen tiefen Neuverschlüsselungsvorgang mit einem neuen internen Schlüssel durchzuführen.
Core-Dumps
Core-Dumps auf einem ESXi-Host, auf dem der Verschlüsselungsmodus aktiviert ist, werden immer verschlüsselt. Weitere Informationen hierzu finden Sie unter vSphere VM-Verschlüsselung und Core-Dumps. Core-Dumps auf dem vCenter Server-System werden nicht verschlüsselt. Schützen Sie den Zugriff auf das vCenter Server-System.
Auslagerungsdatei der virtuellen Maschine
Die Auslagerungsdatei der virtuellen Maschine wird jedes Mal verschlüsselt, wenn Sie ein vTPM zu einer virtuellen Maschine hinzufügen. In Umgebungen mit wenig RAM kann es zu verschlüsselungsbezogenen Auslagerungen mit Auswirkungen auf die Leistung kommen.
vTPMs
Wenn Sie ein vTPM konfigurieren, werden die Dateien der virtuellen Maschine verschlüsselt, die Festplatten hingegen nicht. Sie haben die Möglichkeit, Verschlüsselung für die virtuelle Maschine und die zugehörigen Festplatten explizit hinzuzufügen. Weitere Informationen finden Sie unter Sichern von virtuellen Maschinen mit Virtual Trusted Platform Module.
Hinweis: Informationen zu Einschränkungen bezüglich Geräten und Funktionen, mit denen vSphere Virtual Machine Encryption interagieren kann, finden Sie unter Interoperabilität bei der Verschlüsselung von virtuellen Maschinen.

Welche Komponenten werden von vSphere Virtual Machine Encryption nicht verschlüsselt

Einige der Dateien, die einer virtuellen Maschine zugeordnet sind, werden nicht oder teilweise verschlüsselt.
Protokolldateien
Protokolldateien werden nicht verschlüsselt, da sie keine vertraulichen Daten enthalten.
Konfigurationsdateien der virtuellen Maschine
Die meisten Informationen zur Konfiguration der virtuellen Maschine (gespeichert in den VMX- und VMSD-Dateien) werden nicht verschlüsselt.
Deskriptordatei der virtuellen Festplatte
Zur Unterstützung der Festplattenverwaltung ohne Schlüssel werden die meisten Deskriptordateien der virtuellen Festplatte nicht verschlüsselt.

Erforderliche Rechte für die Durchführung von Kryptografievorgängen

Nur Benutzer die über Berechtigungen für Kryptografische Vorgänge verfügen, können kryptografische Vorgänge durchführen. Die Berechtigungen sind fein unterteilt. Die standardmäßige Systemrolle „Administrator“ umfasst alle Berechtigungen für Kryptografische Vorgänge. Die Rolle, „Kein Kryptografie-Administrator“ unterstützt alle Administratorberechtigungen mit Ausnahme der Berechtigungen für Kryptografievorgänge.

Zusätzlich zur Verwendung der Cryptographer.*-Berechtigungen kann vSphere Native Key Provider die Berechtigung Cryptographer.ReadKeyServersInfo verwenden, die spezifisch für vSphere Native Key Providers ist.

Weitere Informationen hierzu finden Sie unter Rechte für Verschlüsselungsvorgänge.

Sie können zusätzliche benutzerdefinierte Rollen erstellen, um beispielsweise zuzulassen, dass eine Gruppe von Benutzern virtuelle Maschinen verschlüsselt, zugleich aber zu verhindern, dass diese Benutzer virtuelle Maschinen entschlüsseln.

Wie führen Sie kryptografische Vorgänge durch

Der vSphere Client unterstützt viele der kryptografischen Vorgänge. Für andere Aufgaben können Sie PowerCLI oder die vSphere API verwenden.

Tabelle 1. Schnittstellen für das Durchführen von kryptografischen Vorgängen
Schnittstelle Vorgänge Informationen
vSphere Client Erstellen einer verschlüsselten virtuellen Maschine

Verschlüsseln und Entschlüsseln virtueller Maschinen

Durchführen einer flachen Neuverschlüsselung einer virtuellen Maschine (Verwendung eines anderen KEK)

Dieses Handbuch
PowerCLI Erstellen einer verschlüsselten virtuellen Maschine

Verschlüsseln und Entschlüsseln virtueller Maschinen

Konfigurieren von vSphere Trust Authority

Referenz zu VMware PowerCLI-Cmdlets
vSphere Web Services SDK Erstellen einer verschlüsselten virtuellen Maschine

Verschlüsseln und Entschlüsseln virtueller Maschinen

Durchführen einer tiefen Neuverschlüsselung einer virtuellen Maschine (Verwendung eines anderen DEK)

Durchführen einer flachen Neuverschlüsselung einer virtuellen Maschine (Verwendung eines anderen KEK)

Programmierhandbuch zum vSphere Web Services SDK

vSphere Web Services-API-Referenz

crypto-util Entschlüsseln verschlüsselter Core-Dumps

Prüfen, ob Dateien verschlüsselt sind

Führen Sie andere Verwaltungsaufgaben direkt auf dem ESXi-Host durch.

Befehlszeilenhilfe

vSphere VM-Verschlüsselung und Core-Dumps

Vorgehensweise zum Neuverschlüsseln (erneute Schlüsselerstellung) einer verschlüsselten virtuellen Maschine

Sie können eine virtuelle Maschine mit neuen Schlüsseln neu verschlüsseln (auch als „rekey“ bezeichnet), z. B. für den Fall, dass ein Schlüssel abläuft oder manipuliert wird. Die folgenden Optionen für die erneute Schlüsselerstellung sind verfügbar.

  • Eine flache Neuverschlüsselung, bei der nur der Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) ersetzt wird
  • Eine tiefe Neuverschlüsselung, bei der sowohl der Festplattenverschlüsselungsschlüssel (DEK, Disk Encryption Key) als auch der KEK ersetzt wird

Bei einer tiefen Neuverschlüsselung muss die virtuelle Maschine ausgeschaltet sein und darf keine Snapshots enthalten. Sie können eine flache Neuverschlüsselung bei eingeschalteter virtueller Maschine durchführen, sofern auf der virtuellen Maschine Snapshots vorhanden sind. Die flache Neuverschlüsselung einer verschlüsselten virtuellen Maschine mit Snapshots ist nur in einem einzelnen Snapshot-Zweig (Festplattenkette) zulässig. Mehrere Snapshot-Zweige werden nicht unterstützt. Darüber hinaus wird eine flache Neuverschlüsselung auf einem verknüpften Klon einer virtuellen Maschine oder Festplatte nicht unterstützt. Wenn die flache Neuverschlüsselung fehlschlägt, bevor alle Verknüpfungen in der Kette mit dem neuen KEK aktualisiert werden, können Sie weiterhin auf die verschlüsselte virtuelle Maschine zugreifen, vorausgesetzt, Sie verfügen über die alten und neuen KEKs. Es erweist sich jedoch am sinnvollsten, die flache Neuverschlüsselung vor dem Durchführen von Snapshot-Vorgängen erneut auszuführen.

Sie können die erneute Schlüsselerstellung für eine virtuelle Maschine mithilfe von vSphere Client, der CLI oder der API durchführen. Weitere Informationen finden Sie unter Erneute Schlüsselerstellung einer verschlüsselten virtuellen Maschine mithilfe des vSphere Client, Erneute Schlüsselerstellung einer verschlüsselten virtuellen Maschine mithilfe der CLI und Programmierhandbuch zum vSphere Web Services SDK.