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 unter Verwalten von VMware vSAN.
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 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.
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.
Was wird 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.
Was wird nicht verschlüsselt?
- Protokolldateien
- Protokolldateien werden nicht verschlüsselt, da sie keine vertraulichen Daten enthalten.
Wer darf kryptografische Vorgänge durchführen?
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 können kryptografische Vorgänge durchgeführt werden?
Der vSphere Client unterstützt viele der kryptografischen Vorgänge. Für andere Aufgaben können Sie die vSphere API verwenden.
| Schnittstelle | Vorgänge | Informationen |
|---|---|---|
| vSphere Client | Erstellen einer verschlüsselten virtuellen Maschine Verschlüsseln und Entschlüsseln virtueller Maschinen |
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 |
Neuverschlüsselung virtueller Maschinen
Sie können eine virtuelle Maschine mit neuen Schlüsseln neu verschlüsseln, z. B. für den Fall, dass ein Schlüssel abläuft oder manipuliert wird. Die folgenden Optionen sind verfügbar.
- Eine tiefe Neuverschlüsselung, bei der sowohl der Festplattenverschlüsselungsschlüssel (DEK, Disk Encryption Key) als auch der Schlüsselverschlüsselungsschlüssel (KEK, Key Encryption Key) ersetzt wird
- Eine flache Neuverschlüsselung, bei der nur der KEK ersetzt wird
Sie müssen die Neuverschlüsselung einer virtuellen Maschine mithilfe der API durchführen. Weitere Informationen hierzu finden Sie unter Programmierhandbuch zum vSphere Web Services SDK.
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.
