In vSphere 7.0 Update 2 und höher können Sie den integrierten vSphere Native Key Provider verwenden, um Verschlüsselungstechnologien wie virtuelle TPMs (vTPM) zu aktivieren.

vSphere Native Key Provider ist in allen vSphere Editionen enthalten und benötigt keinen externen Schlüsselserver – in der Branche auch als Schlüsselmanagementserver (Key Management Server oder KMS) bezeichnet. Sie können auch vSphere Native Key Provider für vSphere Virtual Machine Encryption verwenden. Dazu müssen Sie jedoch die VMware vSphere® Enterprise Plus Edition™ erwerben.

Was ist vSphere Native Key Provider?

Bei einem Standardschlüsselanbieter oder vertrauenswürdigen Schlüsselanbieter müssen Sie einen externen Schlüsselserver konfigurieren. In einer Standardschlüsselanbieter-Konfiguration ruft vCenter Server Schlüssel vom externen Schlüsselserver ab und verteilt sie an die ESXi-Hosts. In der Konfiguration eines vertrauenswürdigen Schlüsselanbieters (vSphere Trust Authority) rufen die vertrauenswürdigen ESXi-Hosts die Schlüssel direkt ab.

Mit vSphere Native Key Provider benötigen Sie keinen externen Schlüsselserver mehr. vCenter Server generiert einen primären Schlüssel, den so genannten Key Derivation Key (KDK), und leitet ihn an alle ESXi-Hosts im Cluster weiter. Daraufhin generieren die ESXi-Hosts Datenverschlüsselungsschlüssel (auch wenn sie nicht mit vCenter Server verbunden sind), um Sicherheitsfunktionalität wie vTPMs zu aktivieren. Die vTPM-Funktionalität ist in allen vSphere Editionen enthalten. Um einen vSphere Native Key Provider für vSphere Virtual Machine Encryption zu verwenden, müssen Sie die vSphere Enterprise Plus Edition erwerben. vSphere Native Key Provider kann mit einer vorhandenen Schlüsselserverinfrastruktur koexistieren.

vSphere Native Key Provider:

  • Aktiviert die Verwendung von vTPMs, vSphere Virtual Machine Encryption und die vSAN-Verschlüsselung ruhender Daten, wenn Sie keinen externen Schlüsselserver benötigen oder möchten.
  • Funktioniert nur mit VMware-Infrastrukturprodukten.
  • Bietet keine externe Interoperabilität, KMIP-Unterstützung, Hardware-Sicherheitsmodule oder andere Funktionen, die ein herkömmlicher, externer Schlüsselserver von Drittanbietern für die Interoperabilität oder die Einhaltung behördlicher Auflagen anbieten kann. Wenn Ihre Organisation diese Funktionalität für Nicht-VMware-Produkte und -Komponenten benötigt, installieren Sie den herkömmlichen Schlüsselserver eines Drittanbieters.
  • Hilft bei der Abwicklung der Anforderungen von Organisationen, die einen externen Schlüsselserver entweder nicht verwenden können oder nicht verwenden möchten.
  • Verbessert die Methoden der Datenbereinigung und der Systemwiederverwendung, indem die frühere Verwendung von Verschlüsselungstechnologien auf schwer zu bereinigenden Medien wie Flash und SSD aktiviert wird.
  • Stellt einen Übergangspfad zwischen Schlüsselanbietern bereit. vSphere Native Key Provider ist mit dem VMware-Standardschlüsselanbieter und dem vertrauenswürdigen vSphere Trust Authority-Schlüsselanbieter kompatibel.
  • Funktioniert mit mehreren vCenter Server-Systemen, die eine Konfiguration im erweiterten verknüpften Modus oder eine vCenter Server-Hochverfügbarkeitskonfiguration verwenden.
  • Kann verwendet werden, um vTPM in allen Editionen von vSphere zu aktivieren und virtuelle Maschinen mit dem Kauf der vSphere Enterprise Plus Edition zu verschlüsseln, die vSphere Virtual Machine Encryption enthält. vSphere Virtual Machine Encryption funktioniert mit vSphere Native Key Provider wie bei VMware und vertrauenswürdigen Schlüsselanbietern.
  • Kann verwendet werden, um vSAN-Verschlüsselung ruhender Daten mithilfe einer entsprechenden vSAN-Lizenz zu aktivieren.
  • Kann ein Trusted Platform Module (TPM) 2.0 verwenden, um die Sicherheit zu erhöhen, wenn eins auf einem ESXi-Host installiert ist. Sie können vSphere Native Key Provider auch so konfigurieren, dass er nur für Hosts verfügbar ist, auf denen ein TPM 2.0 installiert ist. Wenn Sie ein TPM verwenden, muss es sich um TPM 2.0 handeln. vSphere Native Key Provider unterstützt TPM 1.2 nicht.
Hinweis: Ein ESXi-Host benötigt kein TPM 2.0 zur Verwendung eines vSphere Native Key Providers. Ein TPM 2.0 bietet jedoch erweiterte Sicherheit.

Wie bei allen Sicherheitslösungen sollten Sie das Systemdesign, Implementierungsüberlegungen und Konflikte bei der Verwendung des nativen Schlüsselanbieters berücksichtigen. Beispielsweise vermeidet ESXi-Schlüsselpersistenz die Abhängigkeit von einem Schlüsselserver, der immer verfügbar ist. Da die Schlüsselpersistenz jedoch die kryptografischen Informationen des nativen Schlüsselanbieters auf den Clusterhosts speichert, sind Sie weiterhin gefährdet, wenn böswillige Akteure die ESXi-Hosts selbst stehlen. Da die Umgebungen unterschiedlich sind, sollten Sie Ihre Sicherheitskontrollen entsprechend den gesetzlichen und sicherheitstechnischen Anforderungen, den betrieblichen Anforderungen und der Risikotoleranz Ihres Unternehmens bewerten und implementieren.

Weitere Informationen zum vSphere Native Key Provider finden Sie unter https://core.vmware.com/native-key-provider.

vSphere Native Key Provider – Anforderungen

Um vSphere Native Key Provider zu verwenden, müssen Sie Folgendes ausführen:

  • Stellen Sie sicher, dass sowohl das vCenter Server-System als auch ESXi-Hosts vSphere 7.0 Update 2 oder höher ausführen.
  • Konfigurieren Sie die ESXi-Hosts in einem Cluster.
  • Obwohl dies nicht erforderlich ist, wird empfohlen, möglichst identische ESXi-Hosts zu verwenden, einschließlich TPMs. Clusterverwaltung und Funktionsaktivierung werden durch identische Clusterhosts stark vereinfacht.
  • Konfigurieren Sie die dateibasierte vCenter Server-Sicherung und -Wiederherstellung und speichern Sie die Backups auf sichere Weise, da sie den KDK (Key Derivation Key) enthalten. Weitere Informationen finden Sie im Thema zur vCenter Server-Sicherung und -Wiederherstellung in der Installation und Einrichtung von vCenter Server-Dokumentation.

Um vSphere Virtual Machine Encryption oder vSAN-Verschlüsselung mit vSphere Native Key Provider durchführen zu können, müssen Sie diejenigen Editionen dieser Produkte erwerben, die die entsprechende Lizenz enthalten.

vSphere Native Key Provider und erweiterter verknüpfter Modus

Sie können einen einzelnen vSphere Native Key Provider konfigurieren, der über vCenter Server-Systeme hinweg gemeinsam nutzbar ist, die in einer Konfiguration des erweiterten verknüpften Modus konfiguriert sind. Die allgemeinen Schritte in diesem Szenario:

  1. Erstellen des vSphere Native Key Providers auf einem der vCenter Server-Systeme
  2. Sichern des nativen Schlüsselanbieters auf dem vCenter Server, auf dem er erstellt wurde
  3. Exportieren des nativen Schlüsselanbieters
  4. Wiederherstellen des nativen Schlüsselanbieters auf den anderen vCenter Server-Systemen in der Konfiguration mit erweitertem verknüpftem Modus (siehe Wiederherstellen eines vSphere Native Key Providers mithilfe des vSphere Client)

vSphere Native Key Provider – Rechte

Wie bei Standardschlüsselanbietern und vertrauenswürdigen Schlüsselanbietern verwendet vSphere Native Key Provider den Cryptographer.*-Berechtigungen Darüber hinaus verwendet vSphere Native Key Provider zum Auflisten der vSphere Native Key Provider das Recht Cryptographer.ReadKeyServersInfo, das speziell für vSphere Native Key Provider gilt. Weitere Informationen hierzu finden Sie unter Rechte für Verschlüsselungsvorgänge.

vSphere Native Key Provider – Alarme

Sie müssen einen vSphere Native Key Provider sichern. Wenn ein vSphere Native Key Provider nicht gesichert wird, generiert vCenter Server einen Alarm. Wenn Sie den vSphere Native Key Provider, für den ein Alarm generiert wurde, sichern, setzt vCenter Server den Alarm zurück. Standardmäßig überprüft vCenter Server einmal täglich, ob vSphere Native Key Provider gesichert wurden. Sie können das Prüfintervall ändern, indem Sie die Option vpxd.KMS.backupCheckInterval ändern.

vSphere Native Key Provider – regelmäßige Standardisierungsprüfung

vCenter Server Prüft regelmäßig, ob die vSphere Native Key Provider-Konfiguration auf den vCenter Server- und ESXi-Hosts übereinstimmt. Wenn sich ein Hoststatus ändert, z. B. wenn Sie einen Host zum Cluster hinzufügen, weicht die Konfiguration des Schlüsselanbieters auf dem Cluster von der Konfiguration auf dem Host ab. Wenn die Konfiguration (keyID) auf dem Host abweicht, aktualisiert vCenter Server die Konfiguration des Hosts automatisch. Es ist kein manueller Eingriff erforderlich.

Standardmäßig überprüft vCenter Server die Konfiguration alle fünf Minuten. Sie können das Intervall mit der Option vpxd.KMS.remediationInterval ändern.

Verwenden von vSphere Native Key Provider mit einer Site für die Notfallwiederherstellung

Sie können vSphere Native Key Provider mit einer Site für die Notfallwiederherstellung als Backup verwenden. Durch den Import des vSphere Native Key Provider-Backups vom primären vCenter Server zum vCenter Server-Backup am Disaster Recovery-Standort kann dieser Cluster Ihre verschlüsselten virtuellen Maschinen entschlüsseln und ausführen.

Testen Sie immer Ihre Notfallwiederherstellungslösung. Verlassen Sie sich nicht darauf, dass Ihre Lösung funktioniert, ohne testweise eine Wiederherstellung durchzuführen. Stellen Sie sicher, dass eine Kopie der vSphere Native Key Provider-Sicherung auch für Ihre DR-Site verfügbar ist.

Nicht unterstützte Funktionen in vSphere Native Key Provider

Aktuell bietet vSphere Native Key Provider keine Unterstützung für Folgendes:

  • FCD-Verschlüsselung (First Class Disk)

Migrieren von virtuellen Maschinen mithilfe von vSphere Native Key Provider über nicht verknüpfte vCenter Server-Systeme hinweg

Zu den allgemeinen Schritten zum Migrieren einer verschlüsselten oder mit einem vTPM über vSphere Native Key Provider aktivierten virtuellen Maschine von einem nicht verknüpften vCenter Server-System zu einem anderen gehören:

  1. Wiederherstellen des vSphere Native Key Provider auf dem vCenter Server-System, das als Migrationsziel vorgesehen ist.
  2. Migrieren der virtuellen Maschine mithilfe von vMotion.