vSphere Trust Authority: Komponenten und Funktionsweise

    vSphere Trust AuthorityDie vSphere Trust Authority (vTA) bestätigt die Vertrauens­würdigkeit von ESXi-Hosts, welche dann krypto­grafische Operationen ausführen können. Die Infrastruktur besteht aus vTA- und vertrauens­würdigen Clustern sowie einem externen KMIP-Server. Auf den ESXi-Hosts laufen zudem mehrere Dienste für vTA.

    Trust Authority-Cluster und die vertrauens­würdigen Cluster werden jeweils in separaten vCenter verwaltet. vCenter selbst fungiert aber im Hinblick auf kryptografische Operationen anders als unter 6.5/6.7 nur noch als eine Art Passthrough für Informationen zur vTA-Konfiguration und zum Trust-Authority-Status.

    Zur vTA-Konfiguration benötigt man einen Trust Authority-Administrator, der Mitglied der vCenter-Gruppe TrustedAdmins ist.

    Die meisten Konfigurations- und -Statusinformationen für vSphere Trust-Authority werden auf den ESXi-Hosts in der ConfigStore-Datenbank gespeichert, einige auch in vCenter-Datenbank. Allerdings verwaltet vCenter im vertrauens­würdigen Cluster die API-Aufrufe der Trust Authority und repliziert sie auf alle seine ESXi-Host.

    Wichtig ist zudem, dass vSphere Trust Authority keine neuen Kryptografie-Berechtigungen einführt. Die in Version 6.5 vorhandenen Kryptografie-Berechtigungen und Rollen gelten uneingeschränkt, auch für vTA.

    ESXi-Komponenten für Trusted Authority

    Jeder ESXi-Host in einer vTA-Infrastruktur führt die Dienste der vSphere Trust Authority aus. Diese sind der Bescheinigungs- bzw. Bestätigungs­dienst (attestd) und der Schlüssel­anbieter­dienst (kmxd). Darüber hinaus ist jeder ESXi-Host mit einem vertrauens­würdigen Infrastrukturagent (kmxa) ausgestattet.

    Der Attestierungsdienst überprüft die Software und Hardware des Hosts. Dazu erzeugt er ein signiertes Dokument, das Zusicherungen enthält und den Binär- sowie Konfigurations­status der ESXi-Hosts im vertrauens­würdigen Cluster beschreibt.

    vTA-Komponenten in den Hosts der attestiernden und vertrauenswürdigen vSphere-Cluster

    Zudem bestätigt er den Status der ESXi-Hosts mithilfe eines TPM 2.0-Chips. Dieser misst den Software-Stack sowie die Konfigurations­daten und meldet sie an den Attestierungs­dienst. Letzterer überprüft auch, ob er die Software-Mess-Signatur einem zuvor konfigurierten vertrauens­würdigen TPM-Endorsement-Schlüssel (EK) zuordnen kann, und stellt sicher, dass die Software-Messung mit einem Satz zuvor kompatibler ESXi-Images übereinstimmt.

    Schließlich signiert der Dienst ein SAML-Token, das der ESXi-Host erhält, und gibt die Aussagen zur Identität, Gültigkeit und Konfiguration des ESXi-Hosts an.

    Da der Attestierungsdienst von sich aus nicht weiß, wem oder was er vertrauen soll, muss der zuständige Trust-Authority-Administrator vorher konfigurieren, welche ESXi-Versionen, welche TPM-Geräteherstellern und (optional) welche spezifischen TPM-Geräten vertrauens­würdig sind.

    Der Key Provider-Dienst (kmxd) schließlich bietet ein Verfahren zum Kapseln von Verschlüsselungs­schlüssel­quellen. Er unterstützt (derzeit) nur KMIP-kompatible Schlüssel-Server und ermöglicht den Zugriff auf die Encryption Keys nur, wenn ein Client einen gültigen Bestätigungs­bericht vorlegt.

    Dank des neuen Key Provider-Dienstes brauchen vCenter-Server und ESXi-Hosts in vSphere 7 keine KMS-Anmelde­informationen (Direct Key Management Server) mehr. In vSphere Trust Authority kann ein ESXi-Host einfach auf einen Verschlüsselungs­schlüssel zugreifen, indem er sich beim Key Provider-Dienst und nicht mehr wie in vSphere 6.7 bei vCenter authentifiziert.

    Damit der Key-Provider-Dienst eine Verbindung zu einem KMS herstellen kann, muss der Administrator ein Vertrauens-Setup konfigurieren. Für die meisten Server, die mit dem Key Management Interoperability Protocol (KMIP) kompatibel sind, erstellt man dieses mittels Client- und Server-Zertifikaten.

    Der vertrauenswürdige Infrastruktur­agent (kmxa) kommuniziert also mit einem vertrauens­würdigen Key Provider-Dienst und einem Attestierungs­dienst. Dabei ruft er die Verschlüsselungs­schlüssel vom Dienst für vertrauenswürdige Schlüsselanbieter (kmxd) ab. Diesem Agenten können nur dann Verschlüsselungs­schlüssel ausgestellt werden, wenn der ESXi-Host die Bescheinigung besteht.

    Wichtig: Der ESXi-Host empfängt keine Verschlüsselungsschlüssel von vCenter Server, wenn der Host einen vertrauenswürdigen Schlüsselanbieter benutzt.

    Alle vTA-Dienste werden hinter dem Reverse Proxy und der API-Weiterleitung ausgeführt. Der kmxa kommuniziert zunächst über Port 443 extern mit den Hosts der vSphere Trust Authority. Intern verwendet der attestd den Port 7889, der kmxd den Port 7888 und kmxa den Port 7890.

    VM-Verschlüsselung

    Die Benutzererfahrung der VM-Verschlüsselung ändert sich nicht, wenn man vSphere 7 mit Trust Authority verwendet. Admins können also VMs nach wie vor verschlüsseln, indem sie eine Speicherrichtlinie zur Verschlüsselung auf die VM anwenden oder der VM ein virtuelles TPM-Gerät hinzufügen oder wenn die VM in einem attestierten Cluster mit vertrauens­würdigen Schlüssel­anbieter ausführt wird.

    Man kann aber problemlos auch eine Mischung aus einem vertrauenswürdigen Schlüsselanbieter und einem Standard­schlüsselanbieter in derselben vSphere-Umgebung verwenden. Bei vSphere 7 kann man in der VM-Zusammenfassung anhand des Symbols den Typ des Schlüsselanbieters erkennen, der für die Verschlüsselung verwendet wird.

    Die Migration von VMs zwischen Hosts, die verschiedene Schlüsselanbieter nutzen, scheitert an Kompatibilitätsproblemen.

    Allerdings kann eine VM, die mit einem vertrauens­würdigen Anbieter verschlüsselt ist, nicht auf einen ESXi-Host migriert werden, der nicht für denselben vTA-Cluster bestätigt wurde. Der vSphere-Client zeigt dann ein Kompatibilitäts­problem an, das darauf hinweist, dass der Ziel-Host nicht vertrauenswürdig und bestätigt ist.

    Keine Kommentare