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.
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 verschlüsselt den DEK mit dem AES256-Algorithmus und der DEK verschlüsselt die VMDK mit dem XTS-AES-256-Algorithmus (Schlüsselgröße 512 Bit). Je nach Typ des Schlüsselanbieters werden verschiedene Methoden zum Erstellen und Verwalten des DEK und KEK verwendet.
- Der ESXi-Host generiert und verwendet interne Schlüssel zum Verschlüsseln von virtuellen Maschinen und Festplatten. Diese Schlüssel werden als DEKs verwendet.
- 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.
- 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.
- 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.
- Der vCenter Server des vertrauenswürdigen Clusters fügt dem vertrauenswürdigen Schlüsselanbieter die Konfigurationsspezifikation der virtuellen Maschine hinzu.
- Die Anforderung zum Erstellen der virtuellen Maschine wird an den ESXi-Host gesendet.
- Wenn dem ESXi-Host noch kein Bestätigungstoken zur Verfügung steht, wird ein Token beim Bestätigungsdienst angefordert.
- 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.
- Der ESXi-Host erzeugt einen DEK, um die Festplatten der virtuellen Maschine zu verschlüsseln.
- 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.
- Die virtuelle Maschine wird verschlüsselt und in den Speicher geschrieben.
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.
- 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.)
- Die ESXi-Hosts erzeugen bei Bedarf einen DEK.
- 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.
- 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
- 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.
- 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.
- 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.
Welche Komponenten werden von vSphere Virtual Machine Encryption nicht verschlüsselt
- Protokolldateien
- Protokolldateien werden nicht verschlüsselt, da sie keine vertraulichen Daten enthalten.
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.
| 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 |
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.
