Sichere Virtualisierung erfordert KMS und HSM

von: Igor Jardim

In den frühen 2000er Jahren begann sich das Konzept der Virtualisierung als Ausweg für große Rechenzentren Sie waren sowohl mit einem Mangel an physischem Platz für Wachstum als auch mit der Verschwendung von Rechenleistung auf Servern konfrontiert, die letztendlich mehr ungenutzt blieben als sie tatsächlich genutzt wurden.

Im Laufe der Jahre Schwimmbäder Die Nutzung dedizierter physischer Server geriet zunehmend außer Gebrauch und die Virtualisierung wurde zu einem grundlegenden Teil der IT-Infrastruktur, sei es in der Architektur oder in Projekten, da sie eine höhere Flexibilität bei der Verwaltung und dem Betrieb von Unternehmen ermöglicht.

Während die Reaktionszeit der IT-Abteilungen und Cloud-Anbieter deutlich verbessert wurde, verschärfte sich gleichzeitig ein bis dahin ignoriertes Problem: die Datensicherheit, insbesondere auf Festplatten.

Heute, mit zahlreichen Datenlecks und der DSGVO Da dieses Problem bei allen an der Tür klopft, müssen Unternehmen unbedingt dieses immer größer werdende Haftungsproblem lösen, das nicht nur die Benutzer der Systeme, sondern auch die Kontinuität der Eigentümer der IT-Infrastruktur gefährdet.

Warum wird die Datensicherheit vernachlässigt?

Viele Administratoren verzichten beispielsweise auf die Festplattenverschlüsselung auf Servern, da zur Entschlüsselung der Festplatten nach dem Neustart des Geräts auf jeder Festplatte ein Kennwort eingegeben werden muss. Dies ist ein von Natur aus mühsamer Vorgang, der die Ausfallzeit der Infrastruktur erhöht, selbst wenn sie nur wenige Minuten beträgt.

Angesichts der Leichtigkeit, mit der sich virtuelle Server erstellen lassen, ist dies heute eine nahezu unpraktische Aufgabe, die letztendlich dazu führt, dass sich Systemadministratoren fälschlicherweise gegen die Verschlüsselung der Festplatte entscheiden.

Was die Sache komplizierter macht, ist, dass das Problem auf virtuellen Servern viel schlimmer ist: Jedes Mal, wenn eine virtuelle Maschine angehalten wird oder ein Snapshoot erstellt wird, landet nicht nur der Inhalt Ihrer Festplatten auf der physischen Festplatte des Servers, sondern auch die Speicherdaten! Mit anderen Worten: Alle Daten im Speicher der auf der virtuellen Maschine laufenden Anwendungen und Dienste – normalerweise kryptografische Schlüssel, persönliche Daten, Passwörter, Authentifizierungstoken usw. – landen offen auf der Festplatte des physischen Servers und geben so Daten preis, die geschützt werden müssen.

Eine Lösung für die Sicherheit

Wenn Sie dachten: aber was ist mit der Hypervisor, löst es das Problem nicht? Die kurze Antwort lautet: nicht allein.

Zum Verständnis sei daran erinnert: Der Hypervisor ist eine Softwareschicht zwischen der Hardware und dem Betriebssystem, die virtuellen Maschinen den Zugriff auf Hardwareressourcen ermöglicht. Es arbeitet in einer Schicht des Systems und hat dort die Möglichkeit, Datenmengen für virtuelle Maschinen bei Bedarf automatisch und transparent mit Schlüsseln zu verschlüsseln und zu entschlüsseln, ohne dass Passwörter eingegeben werden müssen.

Die Verwendung von ausschließlich Schlüsseln zum Verschlüsseln/Entschlüsseln eines Servers führt jedoch zu einem weiteren Problem: Es muss eine Möglichkeit gefunden werden, diese Schlüssel sicher aufzubewahren, da bei einem Leck nicht nur ein einzelner Server, sondern ein ganzer Gruppe, also mehrere verbundene Geräte, die zusammenarbeiten und parallel arbeiten, sind letztendlich anfällig.

Verwenden von KMS zum Speichern kryptografischer Schlüssel

Kryptus kNET HSM, das als KMS fungiert.

Um dieses Problem zu lösen und die Schlüssel sicher aufzubewahren, besteht die Lösung in der Verwendung eines KMS (Key Management Service). KMS sind ein Systemtyp, der den Lebenszyklus kryptografischer Schlüssel in Form eines Dienstes sicher verwalten kann. In diesem Dienst können Sie mehrere andere Systeme verbinden, die Datenverschlüsselung unterstützen, z. B. einen Hypervisor, eine Datenbank und sogar SIEMs.

Offensichtlich kann KMS keine virtuelle Maschine sein, daher basieren effektive Schlüsselverwaltungssysteme/-dienste auf oder verwenden kryptografische Schutzausrüstung der Klasse HSM (Hardware-Sicherheitsmodul), im logischen und physischen Sinne abgeschirmtes Gerät gegen Diebstahl und Missbrauch kryptografischer Schlüssel.

Wenn Sie nach einer Lösung für dieses Problem suchen, haben wir zwei gute Neuigkeiten!

Erstens hat VMware mit der Veröffentlichung von vSphere 6.5 die Möglichkeit eingeführt, die virtuelle Maschine (VM) selbst transparent zu verschlüsseln, unabhängig vom Betriebssystem, auf dem sie läuft. Dies löst die bereits erwähnten Sicherheitsprobleme und hilft außerdem bei der Einhaltung von Datenschutzbestimmungen wie DSGVO! Für diese Funktionalität verwendet vSphere ein KMS, um Ihre Verschlüsselungsschlüssel zu schützen!

Die zweite Neuigkeit ist, dass die kNET HSM arbeitet als KMS und ist vollständig mit VMware vSphere kompatibel.

Kommunikation zwischen vSphere und kNET

Die folgende Abbildung erläutert allgemein, wie die Kommunikation zwischen VMware vSphere und Kryptus kNET erfolgt:

1- Zunächst muss eine Vertrauensbeziehung zwischen kNET (KMS) und vCenter bestehen.

2- vCenter fordert einen Schlüssel von KMS an;

3- KMS sendet einen Key Encryption Key (KEK) an vCenter;

4- vCenter speichert nur die Schlüssel-ID und sendet den KEK+ID-Satz an ESXi (Hypervisor);

5- ESXi empfängt und speichert den KEK ausschließlich im Speicher;

6- Mit dem empfangenen KEK generiert ESXi den Data Encryption Key (DEK) zum Verschlüsseln der VM-Dateien.

7- ESXi verschlüsselt jetzt die VM-Festplatten mit dem DEK und verschlüsselt dann den DEK mit dem KEK;

Hinweis: Beim Neustart von ESXi fordert vCenter KMS erneut zur Eingabe des Schlüssels auf und der gesamte Vorgang wird wiederholt.

Das Vertrauensverhältnis zwischen den VMware vCenter und Kryptus kNET erfolgt auf einfache und praktische Weise: mithilfe des KMIP-Schlüsselmanipulationsprotokolls. Fügen Sie hierzu den zu verwendenden KMS-Cluster zu vCenter hinzu und geben Sie die KNET-IP, den Port, den Benutzer und das Kennwort an. Anschließend wird eine Zertifikatsignieranforderung (CSR) generiert, die von KMS signiert und an vCenter zurückgesendet werden muss, das ab diesem Zeitpunkt die Vertrauensbeziehung mit KMS herstellt.

Vorteile der VMware- und kNET-Integration

Durch die Integration verfügt der Servercluster über zwei Schutzebenen! Dies liegt daran, dass jede VM mit einem eindeutigen DEK-Schlüssel verschlüsselt ist und jeder DEK-Schlüssel wiederum mit einem eindeutigen KEK-Schlüssel verschlüsselt ist. Selbst wenn der Angreifer den DEK-Schlüssel entdeckt, hat er ohne den KEK-Schlüssel – der sicher im kNET HSM gespeichert ist – keinen Zugriff auf die Dateien.

„Bevor wir ein in VMware integriertes KMS zur Verwaltung und Speicherung von Schlüsseln nutzten, mussten wir die Passwörter auf jedem Server manuell eingeben. Jetzt ist dieser Prozess deutlich praktischer und verbessert die Sicherheit der gesamten Umgebung deutlich“, sagt Igor, IT-Manager bei Kryptus.

Igor gibt außerdem den Tipp, dass man die Konfiguration von mehr als einem kNET in Betracht ziehen sollte, also die Erstellung eines KMS-Clusters, um die Systemverfügbarkeit zu erhöhen, da ESXi beim Neustart und/oder der Instanziierung einer neuen VM Schlüssel anfordert, die bei Gefahr der Nichtverfügbarkeit bereitgestellt werden müssen.