Mir kannst du vertrauen

von Bertram Wöhrmann

Mit vSphere 7.0 und Trust Authority hat VMware seine Sicherheitsarchitektur in großen Teilen überarbeitet und auf Gebiete jenseits der VM-Verschlüsselung erweitert. Mit Trust Authority lassen sich Dienste mit besonders hohem Schutzbedarf so einrichten, dass sie nur auf sicheren Hosts laufen, denen die gesamte Umgebung vertraut. Dies erfordert zwar den Aufbau neuer Komponenten in der Virtualisierungsinfrastruktur, soll aber dank TPM und Zertifikaten für maximale Sicherheit sorgen.

Virtuelle Maschinen waren in vSphere schon vor Version 7 gut geschützt und selbst hier hat VMware mit der neuesten Ausgabe seines Hypervisors noch optimiert. Doch mit vSphere Trust Authority wendet sich der Anbieter der Absicherung der zugrundeliegenden Infrastruktur zu und hat dafür bestehende Funktionen verbessert. Trust Authority (vTA) soll garantieren, dass nur sichere Hosts mit gesicherter Konfiguration in der Lage sind, verschlüsselte VMs zu hosten. Die zentrale Erweiterung besteht darin, dass vSphere nun auch die Hardware betrachtet.

Die vSphere Trust Authority ist ein Framework zur Erhöhung der Sicherheitsstandards in einer vSphere-Infrastruktur und dient zur Absicherung der virtuellen Infrastruktur an sich und der darin tätigen Workloads. Trust Authority ermöglicht dem Administrator, besonders sicherheitsrelevante Workloads auf Hosts zur Verfügung zu stellen, die einen hohen Sicherheitsstandard haben, um einen ungewollten Zugriff zu unterbinden. Es geht dabei nicht um eine Sekt-oder-Selters Strategie: Sie können dediziert auf Basis jeder einzelnen virtuellen Maschine festlegen, ob sie auf einem entsprechend hoch abgesicherten Cluster laufen soll oder auf einem Cluster, der nicht diesen hohen Sicherheitsanforderungen entspricht.

VMware hat dafür die Kommunikationswege zum Teil geändert, damit sich auch ein vCenter-Server absichern lässt. Der Key-Management-Server (KMS) kommuniziert nun nicht mehr mit dem vCenter, sondern mit dem vTA-Cluster. Dieser wiederum überträgt die Informationen an die attestierten ESXi-Hosts, alle anderen Hosts bekommen diese Informationen nicht.

Trust Authority und TPM regeln, was auf dem Host läuft

Die Basis dafür bietet das Trusted Platform Module (TPM). Dieses enthält erweiterte Sicherheitsfunktionen, die einen Server eindeutig identifizieren – quasi ein Fingerabdruck für den ESXi-Host. VMware setzt hier mindestens die TPM-Version 2.0 voraus. Es gibt Serversysteme, die bereits über entsprechende Module verfügen, aber TPMs lassen sich auch zu geringen Kosten nachrüsten. Wir reden hier von 20 bis 40 Euro, an den Kosten sollte die Sicherheit also nicht scheitern.

Grundsätzlich ist das TPM dafür verantwortlich, die Integrität des ESXi-Servers zu garantieren, der Hochsicherheits-VMs hosten soll. Die Kombination aus Serverhardware und TPM erzeugt eine Eindeutigkeit, die die Sicherheit enorm steigert. Sie müssen dabei keine Angst haben, dass ein Bösewicht einfach das TPM in einen anderen Server steckt und damit die Identität eines Servers übernimmt – dies ist technisch nicht möglich.

Darüber hinaus sind genaue Festlegungen dahingehend möglich, welche vSphere-Version erlaubt ist, welche Treiber zum Einsatz kommen, welche Software Sie gestatten et cetera. Auf dieser Ebene definieren Sie granular, was erlaubt und was verboten ist. Wurde beispielsweise eine nicht freigegebene Software installiert, verliert der Host seinen Status und nimmt entsprechend definierte Workloads nicht mehr auf. Es handelt sich dabei um einen dynamischen Prozess, der den Host-Status regelmäßig überprüft, um einen Missstand direkt mit einem Ausschluss des entsprechenden Hosts zu quittieren.

Erweiterte Verschlüsselung

VMware hat dieses Thema nicht erst mit vSphere 7.0 entdeckt, die Verschlüsselung von virtuellen Maschinen gibt es schon seit geraumer Zeit. Aber VMware hat den Blick auf die gesamte Systemkette geworfen und festgestellt, dass es hier Verbesserungspotential gibt. Schon mit vSphere 6.5 ließen sich VMs verschlüsseln, um sie etwa vor Diebstahl zu schützen. Dabei geht es aber nicht um eine Verschlüsselung im Betriebssystem der VM, sondern der Dateien der VM auf dem Datastore. VMware optimiert mit ESXi 7.0 und vSphere Trust Authority nicht nur die Verschlüsselung der VM selbst, sondern sichert den gesamten Arbeitszyklus.

Auch bei betrieblichen Prozessen ist der Sicherheit Rechnung zu tragen: Was nützt eine verschlüsselte VM, wenn Sie unverschlüsselt übertragen wird? Aus diesem Grund hat VMware die vMotion-Technologie entsprechend erweitert, sodass diese bei einer Verschiebung von VMs Hackern keine Angriffsfläche mehr bietet. Dabei erstellt der KMS-Client im vCenter einen zufälligen 256-Bit-Schlüssel und einen zufälligen 64-Bit-Einmalkode. Beide Werte werden auf den Quell- beziehungsweise Ziel-Host übertragen und verschlüsseln dort den vMotion-Datenstrom. Der Vorgang ist von den VMs entkoppelt, somit ist ein Zugriff auf die Schlüssel nicht möglich.

Verschlüsselte VMs wandern dabei auch immer verschlüsselt durchs Netz, bei unverschlüsselten VMs lässt sich wahlweise der vMotion-Prozess verschlüsseln oder die Übertragung erfolgt ohne einen solchen Schutz. Dabei sollten Sie sich bewusst sein, dass die Verschlüsselung nicht in der virtuellen Maschine stattfindet, sondern nur auf der unterliegenden VMware-Ebene – das tut der Sicherheit aber keinen Abbruch. Auch sind Sie in der Lage, in einem Cluster beziehungsweise auf einem Host verschlüsselte und nicht verschlüsselte VMs parallel zu betreiben. Die Verschlüsselung selbst erfolgt seit vSphere 6.5 über eine Speicherrichtlinie. Diese zielt auf einen Datenbereich und alle VMs, die diese Richtlinie betrifft, landen auf einem Datenspeicher, der die dort gehosteten VMs verschlüsselt.

Unter vSphere 6.5 verteilte das vCenter die Schlüssel an die ESXi-Hosts. Für die Kommunikation zum KMS-Server war einzig das vCenter verantwortlich. Die Attestierung diente nur als auslesender Task und Fehler blieben ohne Konsequenzen. Aufgrund der Abhängigkeiten in und um das vCenter war es daher nicht möglich, das vCenter selbst zu verschlüsseln.

Architektur eines Trust-Authority-Clusters

Der vTA-Aufbau benötigt einen Cluster, der selbst keine klassischen Workloads aufnimmt, sondern dem Management der Trust Authority dient. Er besteht aus einem vCenter-Server und drei ESXi-Hosts. VMware nennt dies eine "Trusted Computing Base" (TCB). Den Zugriff auf dieses vCenter sollten Sie stark einschränken und idealerweise nur wenigen Administratoren erlauben, damit eine Manipulation weitgehend auszuschließen ist.

Workload-Cluster zur Aufnahme der abzusichernden VMs liegen in einer eigenen virtuellen Infrastruktur mit vCenter-eigenen ESXi-Hosts. Dabei dürfen Sie jedoch die vCenter-Topologie nicht aus den Augen verlieren, bei der sich mit vSphere 7.0 einiges geändert hat. Letztendlich unterstützt der vTA-Einsatz nur zwei Topologien: Diese enthalten mindestens zwei Infrastrukturen, eine für das Management und eine für die Workloads. Dabei hat jede Infrastruktur einen eigenen vCenter-Server. Dieser steht entweder in einer gemeinsamen SSO-Domäne oder alternativ in zwei unterschiedlichen SSO-Domänen. Mehr Optionen haben Sie hier nicht. Die Verbindung von einem vTA-Cluster zu anderen vCenter-Servern ist keine 1-zu-1-, sondern eine 1-zu-n-Verbindung.

Aufgaben der vTA-Hostkomponenten

ESXi-Hosts beinhalten automatisch installierte Komponenten, die für vTA notwendig sind: Attestation Service (attestd), Key Provider Service (kmxd) und Trusted Infrastructure Agent (kmxa). Die Ablage der Konfigurationsdaten erfolgt dabei zum Teil in der vCenter-Server-Datenbank und zum Teil in der ConfigStore-DB auf den ESXi-Hosts.

Der Attestierungsdienst erstellt einen abgesicherten Report über die Konfiguration des Hosts. Die Informationen dazu liefert der Trusted Infrastructure Agent. Es gilt dabei zu überprüfen, ob die vom Administrator vorgegebenen Randbedingungen passen und der betroffene Host Teil eines vTA-Clusters werden kann. Der Key-Provider-Dienst stellt eine Verkapselung der Verschlüsselungsschlüssel zur Verfügung, die KMIP-kompatible KMS-Server unterstützt. Die angefragten Schlüssel gibt der Service aber nur heraus, wenn der anfragende Client einen attestierten Report vorweisen kann.

Zusätzlich sorgt der Dienst dafür, dass keine direkte Anmeldung mit entsprechenden Accountdaten am KMS-Server notwendig ist, sondern auch hier Zertifikate zum Einsatz kommen, um den Prozess abzusichern. Der Trusted Infrastructure Agent kommuniziert dabei mit den beiden anderen Diensten. Er fragt beim Key-Provider-Dienst die Verschlüsselungsschlüssel bei vSphere Trust Authority an, nicht mehr wie früher beim vCenter. Wie schon erwähnt, ist der Agent auch für die Zusammenstellung der Attestierungsreports verantwortlich und sorgt zudem dafür, dass Schlüssel nicht mehr über das vCenter direkt angenommen werden. Die Kommunikation der Dienste beziehungsweise Agenten erfolgt dabei über unterschiedliche TCP-Ports:

- Trusted Infrastructure Agent: 7890

- Attestation Service: 7889

- Key Provider Service: 7888

Einrichtungsschritte

Die Einrichtung eines vTA-Clusters beginnt mit dem Ausstellen der Identität der ESXi-Hosts, die Teil des Clusters werden sollen. Diese Identität ist später notwendig, um die Freigabe für Hochsicherheits-Workloads zu erteilen. Es folgt das Aktivieren der Trusted-Hosts-Dienste auf den entsprechenden Hosts, damit die neuen Mechanismen auch laufen. Anschließend müssen Sie die Host-Identitäten in den vTA-Cluster importieren, gefolgt von der Anbindung eines KMS-Servers für die Schlüsselverwaltung. Damit ist das vTA-Grundgerüst aufgebaut. Die Attestierung kann jedoch nur erfolgen, wenn Sie auch die Identität des vTA-Clusters importiert haben.

Nun sind alle Puzzlestücke vorhanden, mit denen nun das System gefüttert werden muss, um die Sicherheit implementieren zu können. Im letzten Schritt geben Sie den Cluster für die hochsicheren VMs frei. Voraussetzung dafür ist der Abgleich der Attestierungen mit der Pflichtkonfiguration für den entsprechenden Cluster. Die beschriebene Infrastruktur kann aber nicht nur einen High-Security-Cluster managen, bei der Anzahl der zu managenden Cluster gibt es keine Einschränkungen.

VM-Verschlüsselung ohne dedizierten Datastore

War die Verschlüsselung von VMs vor vSphere 7.0 nur über einen Datastore mit entsprechendem Speicherprofil möglich, können Sie mit vTA eine VM auch anders verschlüsseln. Es ist nämlich möglich, einer VM ein virtuelles TPM-Gerät zu geben. Ist dieses eingebunden, wird die virtuelle Maschine automatisch verschlüsselt, solange auch eine vTA-Infrastruktur vorhanden ist.

Das erhöht die Flexibilität und spart am Ende sogar Plattenplatz, weil kein Datastore für die Verschlüsselung notwendig ist, auch wenn Sie nur eine VM verschlüsseln. Beide Technologien können Sie selbstverständlich auch mischen.

Fazit

Mit vSphere Trust Authority hat VMware einen großen Schritt getan, um das Thema Sicherheit signifikant zu verbessern. Das Hauptaugenmerk legt der Hersteller darauf, die gesamte Infrastruktur beziehungsweise den kompletten Prozess zu schützen – es geht nicht nur um die Verschlüsselung einer VM. Der Aufwand ist mit zusätzlichen Hosts und einem zusätzlichen vCenter-Server zwar hoch, aber wer in der IT arbeitet, weiß, dass Sicherheit immer Geld kostet. Und für Bereiche, in denen Workloads mit höchster Priorität zu schützen sind, liefert vTA die notwendigen Werkzeuge dafür.