Die Verschlüsselung von VMs „in transit“ (vMotion) und „at rest“ erfordert vei VMware vSphere keine Verschlüsselungssoftware in den VMs. Im gesamten Workflow werden auf den ESXi-Hosts keine Schlüssel abgelegt, die kompromittiert werden könnten. Dafür muss der Nutzer aber einen Key Management Server (KMS) betreiben.
Die von VMware mit vSphere 6.5 eingeführte VM-Verschlüsselungsarchitektur besteht aus drei Komponenten:
- Ein KMS ist ein externer Server, der Schlüssel für Dienste generiert und von einem Sicherheitsanbieter bereitgestellt wird.
- Der vCenter-Server kommuniziert mit einem KMS und fordert Schlüssel im Namen der ESXi-Hosts an.
- ESXi-Hosts führen verschlüsselte VMs aus.
Insgesamt sind drei Arten von Schlüsseln in den Prozess involviert:
- Host-Keys sorgen dafür, dass Hosts kryptografisch sicher sind. Sie werden im Memory-Key-Cache eines im kryptografischen Modus betriebenen ESXi abgelegt. Um einen Host in den Verschlüsselungsmodus zu bringen, fordert vCenter beim erstmaligen Auftreten einer Verschlüsselungsoperation einen Key vom KMS an und sendet diesen an jeden Host im Cluster. Der Host installiert ihn dann im Memory-Key-Cache und aktiviert die Core-Dump-Verschlüsselung.
- Der vCenter-Server fordert auch die VM-Keys vom KMS an und leitet sie an die Hosts bzw. Cluster weiter, ohne sie selbst zu speichern. Er merkt sich nur die jeweilige Key-ID. VM-Keys werden auch als Schlüsselverschlüsselungsschlüssel (KEK) bezeichnet.
Dieser Schlüssel verbleibt bis zum Neustart eines Hosts im ESXi-Speicher, weshalb im Falle eines Systemabsturzes der jeweilige Core-Dump mit Hilfe des Host-Keys verschlüsselt wird. VM-Keys sind symmetrische AES-256-Schlüssel. - Den für jede kryptografische Operation benötigten Datenverschlüsselungsschlüssel (DEK), mit dem die virtuellen Maschinen nebst ihrer Festplatten kodiert werden, generiert jeder Hosts selbst. Er speichert den DEK, den er mit dem KEK verschlüsselt, im vmx-File der jeweiligen VM. Bei den Data Encryption Keys handelt es sich um symmetrische XTS-AES-256-Schlüssel.
Unterstützte KMS
Um die gesamte Umgebung für die Verschlüsselung virtueller Maschinen vorzubereiten, führt also kein Weg daran vorbei, einen KMS einrichten. Zulässige Systeme finden sich in der HCL. Das Portfolio ist dabei in den letzten Jahren deutlich erweitert worden.
Unterstützt werden zum Beispiel Dell Cloud Link, Fujitsu Eternus SF KM, Gemalto SafeNet Key Secure, HyTrust KeyControl, IBM Security Key Lifecycle Manager, Thales eSecurity Vormetric Data Security Manager, Townsend Security Alliance Key Manager, Ultimaco ESKM oder Zettaset Key Manager.
KMIP und KMS
Der verwendete KMS muss mit KMIP 1.1 kompatibel sein. Hierbei handelt es sich um eine Standardsprache für die Verwaltung von Sicherheitsschlüsseln. Ein standardkonformer KMS bietet einen Schlüsselverwaltungsdienst für KMIP-Clients wie vCenter und kann mit einem KMIP-Proxy-Server konfiguriert werden.
Auf den mit KMIP 1.1 kompatiblen KMS wird in der Regel mittels IPv4 zugegriffen. Größeren Unternehmen empfiehlt VMware, den Service ausfallsicher in einem Cluster aus KMIP-basierten Schlüsselverwaltungs-Servern zu betreiben, welche die Keys untereinander replizieren.
Kommunikation absichern
Der vCenter-Server speichert die KMS-Anmeldeinformationen und verwaltet die zur Verschlüsselung verwendeten Keys anhand der UUID. Ferner ruft das vCenter bei Bedarf Schlüssel vom KMS ab und übergibt sie an die ESXi-Hosts.
Um die Kommunikation zwischen dem KMIP-Server (KMS) und dem KMIP-Client (vCenter-Server) zu sichern, muss eine Vertrauensstellung eingerichtet werden. VCenter Server 6.7 verwendet TLS 1.2 für die Kommunikation mit dem KMS.
Der vom KMIP-Client verwendete Zertifikatstyp hängt vom KMS-Anbieter ab. Nicht alle akzeptieren selbst erstellte Zertifikate. Bei einigen Produkten generiert der KMS ein vertrauenswürdiges Zertifikat für den Client, das dieser herunterladen muss. Andere Anbieter akzeptieren nur ein vom KMS selbst bereitgestelltes Client-Zertifikat.