Nachdem Sie einen Schlüsselanbieter eingerichtet haben, können Benutzer mit den erforderlichen Berechtigungen verschlüsselte virtuelle Maschinen und Festplatten erstellen. Diese Benutzer können auch vorhandene virtuelle Maschinen verschlüsseln und verschlüsselte virtuelle Maschinen entschlüsseln sowie virtuellen Maschinen vTPMs (Virtual Trusted Platform Modules) hinzufügen.
Je nach Typ des Schlüsselanbieters kann der Prozessablauf einen Schlüsselserver, den vCenter Server und den ESXi-Host beinhalten.
Prozessablauf bei der Verschlüsselung des Standardschlüsselanbieters
- Wenn eine Benutzer eine Verschlüsselungsaufgabe durchführt, z. B. die Erstellung einer verschlüsselten virtuellen Maschine, fordert der vCenter Server einen neuen Schlüssel vom Standardschlüsselserver an. Dieser Schlüssel wird als KEK verwendet.
- Der vCenter Server speichert diese Schlüssel-ID und gibt den Schlüssel an den ESXi-Host weiter. Wenn der ESXi-Host zu einem Cluster gehört, sendet der vCenter Server den KEK an jeden Host im Cluster.
Der Schlüssel selbst wird nicht im vCenter Server-System gespeichert. Nur die Schlüssel-ID ist bekannt.
- Der ESXi-Host generiert interne Schlüssel (DEKs) für die virtuelle Maschine und deren Festplatten. Es legt die internen Schlüssel nur im Arbeitsspeicher ab und verwendet die KEKs zum Verschlüsseln der internen Schlüssel.
Nicht verschlüsselte interne Schlüssel werden niemals auf der Festplatte gespeichert. Es werden nur verschlüsselte Daten gespeichert. Da die KEKs vom Schlüsselserver stammen, verwendet der Host weiterhin dieselben KEKs.
- Der ESXi-Host verschlüsselt die virtuelle Maschine mit dem verschlüsselten internen Schlüssel.
Jeder Host, der über den KEK verfügt und auf die verschlüsselte Schlüsseldatei zugreifen kann, kann Vorgänge auf der verschlüsselten virtuellen Maschine oder Festplatte ausführen.
Prozessablauf bei der Verschlüsselung des vertrauenswürdigen Schlüsselanbieters
Der Prozessablauf bei der vSphere Trust Authority-Verschlüsselung umfasst die vSphere Trust Authority-Dienste, die vertrauenswürdigen Schlüsselanbieter sowie den vCenter Server und die ESXi-Hosts.
Das Verschlüsseln einer virtuellen Maschine mit einem vertrauenswürdigen Schlüsselanbieter entspricht der Benutzererfahrung bei der VM-Verschlüsselung bei Verwendung eines Standardschlüsselanbieters. Die VM-Verschlüsselung unter vSphere Trust Authority verlässt sich weiterhin entweder auf die Speicherrichtlinien für die Verschlüsselung von virtuellen Maschinen oder auf das Vorhandensein eines vTPM-Geräts, um zu entscheiden, wann eine virtuelle Maschine verschlüsselt werden soll. Sie verwenden weiterhin einen standardmäßig konfigurierten Schlüsselanbieter (in vSphere 6.5 und 6.7 als KMS-Cluster bezeichnet), wenn Sie eine virtuelle Maschine über den vSphere Client verschlüsseln. Darüber hinaus können Sie die APIs immer noch auf ähnliche Weise verwenden, um den Schlüsselanbieter manuell anzugeben. Die vorhandenen Kryptografierechte, die für vSphere 6.5 hinzugefügt wurden, gelten nach wie vor in vSphere 7.0 und höher für vSphere Trust Authority.
Der Verschlüsselungsprozess für den vertrauenswürdigen Schlüsselanbieter weist einige wichtige Unterschiede zum Standardschlüsselanbieter auf:
-
Trust Authority-Administratoren geben Informationen nicht direkt an, wenn sie einen Schlüsselserver für eine vCenter Server-Instanz einrichten, und sie legen auch die Vertrauensstellung des Schlüsselservers nicht fest. Stattdessen veröffentlicht vSphere Trust Authority vertrauenswürdige Schlüsselanbieter, die von den vertrauenswürdigen Hosts verwendet werden können.
- vCenter Server überträgt Schlüssel nicht mehr an ESXi-Hosts und kann stattdessen jeden vertrauenswürdigen Schlüsselanbieter als einzelnen Schlüssel der obersten Ebene verarbeiten.
- Nur vertrauenswürdige Hosts können Verschlüsselungsvorgänge von Trust Authority-Hosts anfordern.
Prozessablauf bei der vSphere Native Key Provider-Verschlüsselung
vSphere Native Key Provider ist in vSphere 7.0 Update 2 und höher enthalten. Wenn Sie einen vSphere Native Key Provider konfigurieren, überträgt vCenter Server einen primären Schlüssel an alle ESXi-Hosts im Cluster. Ebenso wird die Änderung an die Hosts im Cluster übertragen, wenn Sie einen vSphere Native Key Provider aktualisieren oder löschen. Der Prozessablauf bei der Verschlüsselung ähnelt der Funktionsweise eines vertrauenswürdigen Schlüsselanbieters. Der Unterschied besteht darin, dass vSphere Native Key Provider die Schlüssel generiert und sie mit dem Primärschlüssel umhüllt und dann zur Verschlüsselung zurückgibt.
Benutzerdefinierte Attribute für Schlüsselserver
Das KMIP-Protokoll (Key Management Interoperability Protocol) bietet Unterstützung beim Hinzufügen benutzerdefinierter Attribute, die für anbieterspezifische Zwecke bestimmt sind. Mit benutzerdefinierten Attributen können Sie die in Ihrem Schlüsselserver gespeicherten Schlüssel genauer angeben. vCenter Server fügt die folgenden benutzerdefinierten Attribute für VM- und Hostschlüssel hinzu.
| Benutzerdefiniertes Attribut | Wert |
|---|---|
x-Vendor |
VMware, Inc. |
x-Product |
VMware vSphere |
x-Product_Version |
vCenter Server-Version |
x-Component |
Virtuelle Maschine |
x-Name |
Name der virtuellen Maschine (aus ConfigInfo oder ConfigSpec erfasst) |
x-Identifier |
Instanz-UUID der virtuellen Maschine (aus ConfigInfo oder ConfigSpec erfasst) |
| Benutzerdefiniertes Attribut | Wert |
|---|---|
x-Vendor |
VMware, Inc. |
x-Product |
VMware vSphere |
x-Product_Version |
vCenter Server-Version |
x-Component |
ESXi-Server |
x-Name |
Hostname |
x-Identifier |
Hardware-UUID des Hosts |
vCenter Server fügt die Attribute x-Vendor, x-Product und x-Product_Version hinzu, wenn der Schlüsselserver einen Schlüssel erstellt. Wenn der Schlüssel zum Verschlüsseln einer virtuellen Maschine oder eines Hosts verwendet wird, legt vCenter Server die Attribute x-Component, x-Identifier und x-Name fest. Unter Umständen können Sie diese benutzerdefinierten Attribute auf der Schlüsselserver-Benutzeroberfläche anzeigen. Erkundigen Sie sich bei Ihrem Schlüsselserveranbieter.
Sowohl der Host- als auch der VM-Schlüssel enthalten die sechs benutzerdefinierten Attribute. x-Vendor, x-Product und x-Product_Version sind möglicherweise für beide Schlüssel identisch. Diese Attribute werden beim Erzeugen des Schlüssels festgelegt. Je nachdem, ob der Schlüssel für eine virtuelle Maschine oder einen Host verwendet wird, werden unter Umständen die Attribute x-Component, x-Identifier und x-Name angehängt.
Verschlüsselungsschlüsselfehler
Wenn beim Senden von Schlüsseln vom Schlüsselserver an einen ESXi-Host ein Fehler auftritt, erzeugt vCenter Server eine Meldung im Ereignisprotokoll für die folgenden Ereignisse:
- Das Hinzufügen von Schlüsseln zum ESXi-Host ist aufgrund von Problemen bei der Hostverbindung oder -unterstützung fehlgeschlagen.
- Das Abrufen von Schlüsseln aus dem Schlüsselserver ist aufgrund eines fehlenden Schlüssels im Schlüsselserver fehlgeschlagen.
- Das Abrufen von Schlüsseln aus dem Schlüsselserver ist aufgrund der Schlüsselserververbindung fehlgeschlagen.
Entschlüsseln verschlüsselter virtueller Maschinen
Wenn Sie später eine verschlüsselte virtuelle Maschine entschlüsseln möchten, ändern Sie deren Speicherrichtlinie. Sie können die Speicherrichtlinie für die virtuelle Maschine und alle Festplatten ändern. Wenn Sie individuelle Komponenten entschlüsseln möchten, entschlüsseln Sie zunächst ausgewählte Festplatten und anschließend die virtuelle Maschine, indem Sie die Speicherrichtlinie für VM-Home ändern. Beide Schlüssel sind für die Entschlüsselung jeder Komponente notwendig. Weitere Informationen hierzu finden Sie unter Entschlüsseln einer verschlüsselten virtuellen Maschine oder virtuellen Festplatte.
