ESXi-Hosts über separaten Verwaltungs-Cluster absichern vSphere 7 vSphere Trust Authority - Teil 1

Neben der Kubernetes-Integration ist Security ein Schwer­punkt von vSphere 7. Zu den Neu­heiten gehört dabei die vSphere Trust Authority (vTA), welche die ESXi-Infra­struktur schützen soll. Sie be­nötigt einen ver­trauens­würdigen Ver­waltungs-Cluster, der einen Be­stätigungs­dienst für die pro­duk­tiven Hosts ausführt.

Die erweiterten Sicherheits­funktionen 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 Sicherheits­messungen zu erfassen und zu erkennen, ob das System mit authentischer Software und in einer vertrauens­würdigen Konfiguration gestartet wurde.

Der vSphere-Client zeigt auf der Registerkarte Monitor im Abschnitt Sicherheit die Attestierung an.
Der vSphere-Client zeigt auf der Registerkarte Monitor im Abschnitt Sicherheit die Attestierung an.

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.

Aufbau einer vSphere-Umgebung, die vTA zur Attestierung sicherer Hosts nutzt
Aufbau einer vSphere-Umgebung, die vTA zur Attestierung sicherer Hosts nutzt.

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.

Kommunikation zwischen den Komponenten einer vTA-Infrastruktur, um einen Host als sicher auszuweisen
Kommunikation zwischen den Komponenten einer vTA-Infrastruktur, um einen Host als sicher auszuweisen.

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.