(E) SAE DEEP DIVE SERIE TEIL 2 - Abgesicherte VMs in einer ESAE Umgebung mit VMWare - TEAL Technology Consulting GmbH
2472
post-template-default,single,single-post,postid-2472,single-format-standard,bridge-core-2.0.2,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-19.0.2,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,wpb-js-composer js-comp-ver-6.0.5,vc_responsive

(E) SAE DEEP DIVE SERIE TEIL 2 – Abgesicherte VMs in einer ESAE Umgebung mit VMWare

In unserem Januar Blog, haben wir eine SAE-Deep-Dive Serie gestartet und erklärt, wie man Hyper-V in einem (E)SAE Szenario als sicheren Hypervisor verwenden kann. Da längst nicht alle unsere Kunden Hyper-V einsetzen, sondern viele auch VMware im Einsatz haben, möchten wir in diesem Artikel erklären, wie wir die Schutzkonzepte von Hyper-V HGS und Shielded VMs auf die VMware Welt übertragen haben. Im Artikel beschreiben wir eine Lösung, die wir gemeinsam mit einer Partnerfirma für einen unserer SAE Kunden entwickelt und umgesetzt haben. Wie immer laden wir die Community herzlich ein, getroffene Entscheidungen zu diskutieren und Verbesserungen gemeinsam zu besprechen. Meldet euch also gerne bei uns 😊.

Hier als kleine Gedankenstütze noch einmal die Ziele, die wir im ESAE Kontext erreichen wollen:

  • VM Disks sind verschlüsselt
  • VMs können nur auf definierten Hosts gestartet werden
  • Die Hostkonfiguration wird attestiert
  • Virtualisierungsadministratoren können die VMs nicht verändern.
  • VM Administratoren können den Hypervisor nicht verändern

 

Im Projekt wurde eine neue VMware Instanz rein für die neu aufzubauende ESAE Infrastruktur implementiert. Um den Fokus auf die Sicherheitsaspekte nicht zu verlieren, beschreiben wir einige Themen wie die Hochverfügbarkeitskonfiguration oder Backup und Restore nicht oder nur in dem Maße, wie es relevant für das Thema des Artikels ist.

Verschlüsselung mit VMware

VMware kann seit der Version 6.5 von vSphere virtuelle Maschinen „at rest” und beim Verschieben mit vMotion verschlüsseln. Anders als bei Hyper-V findet die Verschlüsselung nicht im Betriebssystem (z.B. mit Bitlocker) sondern auf Hypervisor-Ebene statt. Vorteil davon ist, dass es unabhängig vom Betriebssystem funktioniert. Ein Nachteil an der Implementierung von VMware ist, dass ein externer Key Management Server benötigt wird. Anzumerken ist, dass die vCenter VM, die in unserem Fall auf der gleichen Virtualisierungs-Infrastruktur laufen soll, nicht verschlüsselt werden kann, da sie am Entschlüsselungsvorgang beteiligt ist:

Eine fertige „Architektur“ im Sinne des Host Guardian Service wie bei Hyper-V gibt es bei VMware leider nicht.

Projektarchitektur

Im nachfolgenden Bild seht ihr die konkrete Projektarchitektur, anhand derer wir die relevanten Konfigurationen erklären.

Storage

Eine Anforderung an die Architektur ist, dass alle (relevanten) Daten verschlüsselt werden. Da sowohl die KMS als auch die vCenter VM für den Entschlüsselungsprozess benötigt werden, können diese nicht mit VMware-Mitteln verschlüsselt werden. Deshalb hat man im Projekt entschieden, die ESXi Installation, die KMS und die vCenter auf lokalen, selbst verschlüsselnden SSDs zu speichern. Alle anderen VMs werden im SAN gespeichert. Somit sind auch diese Komponenten geschützt, sollte ein Angreifer es schaffen, an eine der Festplatten aus dem ESXi Host zu gelangen.

ESXi Hosts

Wie im Storage Kapitel beschrieben, wurde ESXi auf verschlüsselten SSDs installiert. Dafür wurde ein vom Hardware-Hersteller angepasstes Image verwendet. Aus Security Sicht viel interessanter ist allerdings, wie die Zugriffe auf die ESXi Hosts konfiguriert werden.

Zugriffsberechtigung

Folgende Grafik gibt Übersicht über die verschiedenen Zugriffsmöglichkeiten

Einerseits sollten die Hosts nach Best Practice von VMware nur durch vCenter administriert werden, andererseits hat man sich im konkreten Kontext entschieden, das vCenter als VM auf den ESXi Servern zu betreiben, die man damit verwaltet. Somit braucht man für Notfälle eine direkte Zugriffsmöglichkeit. Einschränken lässt sich der Zugriff durch die sogenannten Lockdown-Modes. Im normalen Lockdown Mode hat niemand Zugriff, außer den Benutzern, die in der Ausnahmeliste oder im „DCUI.access“ Parameter aufgeführt sind.

Im strikten Modus wird auch der DCUI Service ausgeschaltet, somit können Zugriffe nur mittels der Ausnahmeliste konfiguriert werden.

Nachfolgende Tabellen geben eine Übersicht über die verschiedenen Konfigurationen für root und lokale Benutzer:

Security setting Access to DCUI Access to ESXi Shell (if service enabled) Access via Host Client Access via vCLI / PowerCLI
None + + + +
Normal lockdown mode without Exception users entry and default DCUI.access setting. +

Root included in DCUI.Access by default

 

 

 

Normal lockdown mode without Exception users entry and root user removed from DCUI.access setting
Normal lockdown mode with root in Exception users list + + +
Strict lockdown mode without defined exception users Service disabled
Strict lockdown mode with root in exception users list Service disabled + +
Security setting Access to DCUI Access to ESXi Shell (if service enabled) Access via Host Client Access via vCLI / PowerCLI
None + + + +
Normal lockdown mode without Exception users entry and default DCUI.access setting
Normal lockdown mode with local or AD admin user in Exception users list + + + +
Normal lockdown mode with local user in DCUI.access setting +
Strict lockdown mode without defined exception users Service disabled
Strict lockdown mode with local user in exception users list Service disabled + + +

Da der vCenter Server eine virtuelle Maschine ist, die sich im einzigen Cluster des Inventars befindet, und in der Umgebung Verschlüsselung verwendet wird, ist der strict lockdown mode keine Option. Um im Notfall die Möglichkeit zur Wiederherstellung des vCenter Servers zu haben, muss es jedoch eine Möglichkeit geben, auf die ESXi-Hosts zuzugreifen. Die Lösung für diese Anforderung ist der normale Lockdown-Modus mit einer konfigurierten DCUI.access-Einstellung für einen anderen Benutzer als root. Die Dienste ESXi Shell und SSH bleiben standardmäßig deaktiviert. Diese Kombination von Einstellungen führt im Katastrophenfall zu einem einzigen Zugriffsweg auf die Umgebung. Im Notfall wird im 4-Augenprinzip der non-root Account verwendet, um sich anzumelden und den lockdown Modus zu deaktivieren. Im Anschluss sind dann die entsprechenden Interfaces wieder für den root User zugänglich.

Weitere Sicherheitsmaßnahmen

Weiterhin wurden verschiedene Security Settings aus VMwares Security Configuration guide konfiguriert, auf die wir an dieser Stelle nicht näher eingehen:

  • Audit the status of the SSH and ESXi shell services
  • Audit the “Exception user” list and the “DCUI.access” advanced setting
  • Configure Syslog
  • Configure a persistent log location (especially important for SD-booted hosts)
  • Disable the managed object browser (MOB)
  • Set session policies to project requirements
    • Auto-unlock-time
    • Account lockout policy
    • DCUI timeout
    • Password policies (for ESXI, vCenter OS and vSphere)
    • Shell timeout
    • Shell interactive timeout
  • Verify Transparent Page Sharing setting
  • Verify acceptance level of system is at least partner supported

x

vCenter

Zugriffsmaßnahmen

Um den Zugriff für die verschiedenen Administratorenrollen zu begrenzen, gibt es unter anderem zwei zentrale Rollen, die ein Administrator einnehmen kann. Diese Rollen wurden von uns im Zuge des Projektes definiert und bilden die Grundlage, um das Hyper-V shielded VM Feature nachzubauen.

  • VMware Admin: dieser Benutzer kann z.B. VMs erstellen, mehr Speicher zuweisen usw. Allerdings kann dieser Benutzer keine Consolenverbindung zur virtuellen Maschine aufbauen.
  • VM Admin: Im Gegensatz dazu kann ein VM Admin zwar Consolensessions zu einer VM aufbauen, diese neu starten etc. aber er kann keine Konfigurationen am Vcenter/ESXi selbst vornehmen.

Somit ist sichergestellt, dass Hypervisor Administratoren von den virtuellen Maschinen getrennt sind.

Weitere Sicherheitseinstellungen

Die vom vCenter verwendeten Zertifikate für nicht-VMware-interne Kommunikation werden durch Zertifikate der internen CA des Kunden ersetzt. Dies erfüllt auch eine Security-Vorgabe des Kunden, keine selbst signierten Zertifikate zu verwenden. Nicht vergessen werden darf in diesen Fall, dass die Zertifikate dann mit in den „normalen“ Zertifikats-Lifecycle aufgenommen werden müssen.

KMS

Leider braucht VMware eine externe Key Management Server Lösung zur Verschlüsselung. Am Markt gibt es mehrere Anbieter für solche Lösungen. Bei unserem Kunden kam HyTrust KeyControl zum Einsatz. Die Lösung basiert auf einem vom Hersteller gehärteten Free BSD, welcher als virtuelle Applicance (OFA) geliefert wird. Die Lösung wird als active-active Cluster betrieben.

Zugriffsberechtigung

Nachdem die Vertrauensstellung mit VMware konfiguriert wurde, muss eigentlich niemand mehr auf das System zugreifen, außer beim Upgrade der Lösung. Dafür wird das System an den ESAE Admin Forest angebunden und einem Domänen-Benutzer die benötigten HyTrust Rollen zugewiesen. Die Verwendung des Accounts wird mit dem 4-Augen-Prinzip organisatorisch gesichert, da der Account auch das Recht hat, Schlüssel zu lesen und zu exportieren.

VMs

An den VMs muss im Grunde genommen nicht viel konfiguriert werden. Um sicherzustellen, dass alle VMs identisch deployed werden, kommt ein VM Template zum Einsatz, die Verschlüsselung wird durch eine Storage Policy eingeschaltet. Alle weiteren Härtungsmaßnahmen kommen, wie gehabt per GPO aus der Active Directory Domäne.

Zusammenfassung

Auch bei VMware müssen zahlreiche Aspekte beachtet werden, doch auch hier ist es möglich, eine effektive Trennung von Virtualisierungsadmins und Workloads zu erreichen. Die Lösung ist nahezu identisch mit dem Sicherheitsniveau eines Hyper-V HGS / shielded VMs System, gleichwohl muss man an der einen oder anderen Stelle ein wenig improvisieren. Es gibt zwar nicht immer eine best practice direkt von VMware. Was sich im Projektkontext aber als nützlich erwiesen hatte, war ein Designreview durch einen erfahrenen VMware Consultant, das direkt vom Hersteller zur Verfügung gestellt wurde. Gerade um z.B. keinen Fehler bei den Notfallzugriffskonzepten zu machen, war dieses Review äußerst hilfreich. Des Weiteren haben wir durch das Review zwar keinen offiziellen „Support Stempel“ erhalten (dafür müssten viele Anwälte miteinander – ihr wisst vermutlich auf was das hinaus läuft 😉 ), aber dennoch die Sicherheit, dass ein erfahrener Consultant vom Hersteller die Lösung für vollständig und sehr gut befunden hat.

LATEST POSTS