vSphere 7 U2 – native Key Provider

von René Gessinger · Veröffentlicht 9. März 2021 · Aktualisiert 8. Februar 2022

Mit vSphere 7 U2 hat eine neue Funktion Einzug gefunden die bestimmt einige sich gewünscht haben: Den native Key Provider:
vCenter - add native Key Provider

Nutzen

Der native Key Provider ist – wie der Name bereits vermuten lässt – eine vCenter native Implementation eines Key Management Servers (KMS) wie er in vSphere für die Encryption von VMs und Datenspeichern (vSAN) genutzt wird.
Musste man sich bisher auf einen KMS-Anbieter auf der HCL stützen, so kann man diesen nun direkt aus vSphere heraus erstellen.

Obwohl die Funktion in jeder vSphere Edition vorhanden ist, so sind manche Funktionen an Lizenzen gebunden. So kann man für die Data-At-Rest encryption von vSAN jeder Kunde die Funktion nutzen, so benötigt man für die Encryption auf VM-Ebene eine EnterprisePlus-Lizenz.

Einrichtung

Kommen wir direkt zu der Einrichtung. Diese ist denkbar einfach und ist, wie von VMware gewohnt, in den vSphere Client integriert.

In der Konfiguration der Key Provider drückt man auf "Add". — Zuerst ruft man die Konfigurationsseite der Key Provider in vSphere auf und betätigt die Schaltfläche “Add”.

In dem sich öffnenden Menü drückt man auf “Add Native Key Provider”. Darufhin öffnet sich der folgende Dialog:

Einen Namen für den nativen Key Provider angeben. — Man vergibt einen Namen und bestätigt mit “Add Key Provider”

Nachdem man den neu erstellten Key Provider gesichert hat (über die Schaltfläche Back-Up), ist dieser bereits aktiv und kann genutzt werden.

Der neu erstellte native Key Provider steht zur Verfügung. — Der neu erstellte native Key Provider ist aktiv.

Nutzung mit vSAN

Plant man nun die Data-At-Rest enryption in vSAN einzusetzen, aktiviert man die entsprechende Option beim Aktivieren des vSANs.

Bei der Erstellung eines vSAN aktivierten Clusters lässt sich der Key Provider auswählen. — Der native Key Provider lässt sich auswählen.

Natürlich lässt sich die Data-At-Rest encryption auch nachträglich aktivieren.

Natürlich kann man die Data-At-Rest encryption auch nachträglich aktivieren. — Um die Data-At-Rest encryption nachträglich zu aktivieren, wählt man einfach die entsprechende Schaltfläche.

Hier wählt aktiviert man die Data-At-Rest encryption und wählt den erstellten Key Provider aus. — Im daraufhin öffnendem Dialog aktiviert man die Data-At-Rest encryption und bestätigt mit Apply.

Per-VM encryption

Nutzt man dagegen kein vSAN oder möchte einfach nur spezifische VMs verschlüsseln, so benötigt man hierzu zwingend eine EnterprisePlus-Lizenz. Generell nutzt man die Storage Policies dazu.

Bei der VM Encryption benötigt man eine Storage Policy welche Hostbasierte Regeln enthält. — Man legt eine neue Storage Policy mit einem beliebigen Namen an und wählt die host basierten Regeln. In meinem Fall heißt diese “encrypted VMs”.

In dieser muss die Encryption aktiviert werden. — Auf der nächste Seite wählt man eine der beiden unteren Optionen und konfiguriert diese entsprechend.

Natürlich kann man die Encryption auch mit anderen Richtlinien kombinieren. So lassen sich auch Placement und vSAN Regeln in der selben Policy konfigurieren.

Weist man diese Policy einer VM zu, so wird man über den Status der Encryption informiert. — Weist man die neu erstelle Storage Policy einer VM zu, so wird diese korrekt verschlüsselt.

Sinnvoll und/oder sicher?

Schaut man sich die, sehr einfache, Erstellung eines solchen Key Providers an, so muss man sich fragen ob dies wirklich sinnvoll und sicher ist. Schließlich läuft der KMS in der VCSA, womit eine größere Abhängigkeit zwischen ESXi und VCSA entsteht.
Darüber hinaus kann ein Angreifer sich das vCenter kopieren und hat dann die entsprechenden Schlüssel.

Neu ist allerdings die Funktion der Key Persistence. Hiermit erhält ein ESXi. welcher mit TPM 2.0 ausgerüstet sein muss, die Funktion Encryption Keys zu cachen. Somit kann er auf die verschlüsselten Daten zugreifen, auch wenn der Key Provider offline ist. Man kann also die VCSA ebenfalls verschlüsseln oder auf einem vSAN-Datenspeicher ablegen welcher die Data-At-Rest Encryption nutzt.

In diesem Fall kann selbst ein Angreifer der physisch den gesamten Speicher abbaut (die Server aber stehen lässt), nichts mit den Daten anfangen. Ja, dies ist sehr unwahrscheinlich, so kommt ein Angreifer selten an die physischen Assets in ihrer Gänze.
Wesentlich realistischer ist es das ein Angreifer logischen Zugriff auf die Umgebung erhält und Daten aus dem Storage-Stack eines ESXis kopieren kann. Aber auch diese Daten sind verschlüsselt.
Ein anderer Punkt ist wenn ein Angreifer das vCenter angreift. Hier könnte es wirklich zu ernsthaften Schaden kommen, da damit auch der Key Provider kompromittiert sein wird. Der Angreifer kann nun die Encryption Keys auslesen oder auch ändern.

Abschluss

Möchte man die Sicherheit in seiner Umgebung vollumfänglich umsetzen und dabei alle Angriffsvektoren möglichst klein halten, wird man dabei nicht umhin kommen eine externe HMS-Appliance zu verwenden.
Ich kenne einige Umgebungen die ihren Storage mit einem statischen Passwort verschlüsseln, als Schutz vor Festplattenklau. Hierzu bietet der native Key Provider eine kostengünstige und vergleichbare sichere Möglichkeit als Alternative.
Ob man nun aber den nativen Key Provider nutzt oder doch lieber einen externen HSM, muss man selbst ermitteln.