vSphere Trust Authority: ESXi-Hosts über separaten Verwaltungs-Cluster absichern

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 Sicherheits­messungen zu erfassen und zu erkennen, ob das System mit authentischer Software und in einer vertrauens­wü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üsselungs­schlü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ängigkeits­schleife gäbe.

Zur Erinnerung: In vSphere 6.5 und 6.7 braucht die VM-Verschlüsselung zwingend einen vCenter Server, welcher seinerseits Verschlüsselungs­schlü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 Konfigurations­fehler, 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 vertrauens­wü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 Zugriffs­beschränkungen für Verschlüsselungs­schlü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-Administrator­benutzer ü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üsselungs­schlü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üsselungs­schlü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üsselanbieter­dienst aktiviert. Beim Konfigurieren der vTA kommunizieren die ESXi-Hosts im vertrauens­würdigen Cluster mit dem Bestätigungs­dienst. Der Schlüssel­anbieter­dienst residiert zwischen den vertrauens­würdigen Hosts und einem oder mehreren vertrauens­würdigen Schlüsselanbietern.

Konkret besteht vSphere Trust Authority also aus dem vSphere Trust Authority-Cluster (Verwaltungs-Cluster) und einem vertrauens­würdigen Schlüsselanbieter. Alle anderen normalen ESXi-Cluster werden gegen den vTA-Cluster bestätigt.

Der Trust-Authority-Administrator muss dazu zwei wichtige Parameter konfigurieren, nämlich zulässige Versionen von ESXi und vertrauenswürdige TPM-Hersteller oder Geräte. Zudem ist ein vertrauens­würdiger Schlüsselanbieter (KMS) erforderlich. Bevor diesem Zugriff gewährt wird, ist ein gültiger Attestierungs­bericht erforderlich.

Damit ergeben sich folgende Anwendungsfälle für den Einsatz von vSphere Trust Authority.

• Bereitstellen von ESXi-Hosts mit einem Hardware-Root of Trust einschließlich Funktionen für die Remote-Bestätigung
• Einschränkung der Verschlüsselungs­schlüssel­verwaltung, da Schlüssel stets nur für bestätigte ESXi-Hosts freigegeben werden
• Aufbau einer sichereren Verwaltungs­umgebung für die Verwaltung von Vertrauensstellungen
• Zentrale Verwaltung auch mehrerer Schlüssel-Server
• Durchführung von kryptografischen Operationen auf virtuellen Maschinen, jedoch mit erweiterter Verschlüsselungs­schlüssel­verwaltung.

Fazit

Ab vSphere 7 können vSphere-Admins eine vertrauens­würdige Basis aus einem sicheren und verwaltbaren Satz von ESXi-Hosts erstellen. Die vSphere Trust Authority implementiert einen Remote-Bestätigungsdienst für all jene ESXi-Hosts, denen vertraut werden soll und verbessert die schon mit vSphere 6.7 eingeführte Unterstützung für TPM 2.0-Attestations.

Ferner implementiert vSphere Trust Authority Zugriffs­beschränkungen für Verschlüsselungs­schlüssel und schützt die Secrets der einzelnen VM-Workloads besser. Außerdem können in vSphere 7 nur autorisierte Trust-Authority-Administratoren vTA-Dienste und -Hosts konfigurieren. Dabei sollte es sich im Idealfall um separate Benutzer handeln.