Neben der Kubernetes-Integration ist Security ein Schwerpunkt von vSphere 7. Zu den Neuheiten gehört dabei die vSphere Trust Authority (vTA), welche die ESXi-Infrastruktur schützen soll. Sie benötigt einen vertrauenswürdigen Verwaltungs-Cluster, der einen Bestätigungsdienst für die produktiven Hosts ausführt.
Die erweiterten Sicherheitsfunktionen in vSphere 7 umfassen neben einer verbesserten Zertifikatverwaltung neue Features wie vSGX, Identity Federation und vSphere Trust Authority. Letztere baut auf den mit vSphere 6.7 eingeführten Support für TPMs bzw. virtuelle TPMs.
Attestierung mit TPM-Unterstützung
Ein TPM ist eine kostengünstige Hardware-Komponente, die auf dem Server-Mainboard integriert ist. Sie dient als kryptografischer Prozessor und kann kryptografisches Material wie Schlüssel, Zertifikate sowie Signaturen speichern.
Außerdem kann ein TPM dabei helfen, über eine so genannte Attestierung festzustellen, ob die Integrität eines Systems gegeben ist. Wenn auf einem Server UEFI Secure Boot und TPM aktiviert sind, dann ist ein vCenter Server in der Lage, diese Sicherheitsmessungen zu erfassen und zu erkennen, ob das System mit authentischer Software und in einer vertrauenswürdigen Konfiguration gestartet wurde.
Schwächen der Umsetzung in vSphere 6.7
VMware vSphere 6.7 kann diese Attestierung allerdings nur anzeigen. Zwar generiert vSphere einen Alarm, wenn es ein Problem gibt, ansonsten hat eine fehlgeschlagene Attestierung keine weitere Auswirkung. Dies führt unter Umständen dazu, dass ein zunächst sicherer Workload, der die VM-Verschlüsselung verwendet, durch DRS wieder auf einen nicht kryptografisch sicheren Host verschoben wird.
Zudem sind die Verschlüsselungsschlüssel möglicherweise anfällig, da der vCenter Server, der diese Keys in vSphere 6.5 und 6.7 für einen Cluster verarbeitet, selbst bisher nicht verschlüsselt werden kann, weil es sonst eine Abhängigkeitsschleife gäbe.
Zur Erinnerung: In vSphere 6.5 und 6.7 braucht die VM-Verschlüsselung zwingend einen vCenter Server, welcher seinerseits Verschlüsselungsschlüssel von einem KMS (Key Management Server) abruft, (nur) deren IDs selbst speichert und sie TLS-gesichert an die jeweiligen ESXi-Hosts weiterleitet.
Diese Architektur ist zwar per se sicher, aber nicht robust gegen einen beschädigten vCenter Server, böswillige vCenter-Administratoren oder Konfigurationsfehler, welche das Beschädigen oder Stehlen der geheimen Daten begünstigen könnten.
vSphere Trust Authority
Die vSphere-Version 7.0 begegnet diesem Problem mit vSphere Trust Authority. Hierbei schafft der Administrator einen vertrauenswürdigen Verwaltungs-Cluster (Trusted Computing Base) auf Basis eines sicheren, verwaltbaren Satzes von ESXi-Hosts.
Bei diesem Verbund handelt es sich um einen stark untersuchten, kleinen Cluster völlig außerhalb der normalen Struktur einer vSphere-Umgebung. Er ist idealerweise von allen anderen Clustern getrennt und hat nur sehr wenige entsprechend berechtigte Administratoren.
Die Hosts, aus denen dieser Cluster besteht, müssen ESXi 7 ausführen. Es können aber durchaus kleine Maschinen sein, weil sie keine regulären Workloads aufnehmen sollen. Anstelle eines separaten Clusters kann ein vorhandener Verwaltungs-Cluster auch als vTA-Vertrauensbasis dienen, um den Einstieg zu vereinfachen.
Dieser Verwaltungs-Cluster implementiert einen Remote-Bestätigungsdienst für alle ESXi-Hosts, die man als vertrauenswürdig einstufen möchte. Zudem bietet vSphere Trust Authority verbesserte Unterstützung von TPM 2.0-Bestätigungen durch effiziente Zugriffsbeschränkungen für Verschlüsselungsschlüssel und somit höheren Schutz für die geheimen Schlüssel der Workload-VMs.
Zudem sollten nur speziell autorisierte Administratoren vTA-Dienste und -Hosts konfigurieren dürfen. Der Trust Authority-Administrator kann mit dem vSphere-Administratorbenutzer übereinstimmen oder ein separater User sein.
Sobald der vTA-Verwaltungs-Cluster eingerichtet ist, kümmert er sich um zwei wesentliche Aufgaben. Zum einem übernimmt er die Verteilung der Verschlüsselungsschlüssel, so dass sich der eigentliche vCenter Server nicht mehr im kritischen Pfad für diese Schlüssel befindet. Somit kann man auch den vCenter Server selbst verschlüsseln.
Zum anderen übernimmt vTA die Attestierung anderer Hosts. Da vTA die Verschlüsselungsschlüssel verarbeitet, hält sie die Schlüssel zurück, wenn ein Host die Attestierung nicht besteht. Dadurch verhindert sie, dass sichere Workloads auf solche Host verschoben werden, bis das Problem behoben ist.
Daher werden durch die Konfiguration des Trust Authority-Clusters automatisch der Bestätigungs- und der Schlüsselanbieterdienst aktiviert. Beim Konfigurieren der vTA kommunizieren die ESXi-Hosts im vertrauenswürdigen Cluster mit dem Bestätigungsdienst. Der Schlüsselanbieterdienst residiert zwischen den vertrauenswürdigen Hosts und einem oder mehreren vertrauenswürdigen Schlüsselanbietern.
