Wie jeder Hersteller von Standardsoftware steht auch VMware vor der Herausforderung, Produkte zu entwickeln, die sich in unterschiedlichste Konstellationen aus Hardware, Software, Drittanbieter-Integrationen und IT-Verwaltungsprozessen einfügen. Dennoch ist in allen Einsatzszenarien eine gute Performance und Usability bei hoher Sicherheit des Gesamtsystems gefragt. Die geforderte Flexibilität führt im Fall von vSphere zu einem recht komplexen System. Mit steigender Komplexität steigt aber auch die Anzahl der Schnittstellen und Protokolle, die sich potenziell missbrauchen lassen.

VMware veröffentlicht für die wichtigsten Produkte umfangreiche Security Best Practices im "Security Hub". Dort finden sich neben zahlreichen Erklärvideos und White Papers auch die "Security Configuration Guides" (SCG), so auch den Guide für die jeweils aktuelle vSphere-Version. Die Anleitungen sind nach Komponenten von vSphere unterteilt (ESXi-Hosts, vCenter Server, VM-Hardware und Gastbetriebssystem) und enthalten Konfigurationsempfehlungen in drei Stufen:

• P0: Die Empfehlung ist wichtig für die Sicherheit und es existiert keine spezielle Voreinstellung oder Vorrichtung in vSphere, um eine sichere Konfiguration zu erreichen. Sie müssen also eine Einstellung vornehmen oder einen zusätzlichen Prozess implementieren.
• P1: Die Empfehlung ist wichtig und es existiert eine Voreinstellung oder eine andere Mitigation, die jedoch angepasst werden sollte, um eine sichere Konfiguration zu erreichen.
• P2: Die Empfehlung ist wichtig, und die Voreinstellung dazu in vSphere ist bereits auf Sicherheit optimiert, sodass Sie diese lediglich überwachen müssen.

Anders als bei manch anderen abgestuften Sicherheitsleitfäden sollten Sie diesen also nicht in der Reihenfolge der Prioritäten "von oben nach unten" abarbeiten, sondern müssen die Empfehlungen stets im Gesamtkontext Ihrer Umgebung betrachten. Die Anleitungen zielen auf eine solide Grundhärtung der Infrastruktur ab und sollten bei der Sicherheitsbewertung Ihrer Plattform stets als Mindestmaßstab herangezogen werden. Ein weiterer nützlicher Inhalt des SCG sind Codebeispiele für PowerCLI, die bei den meisten Konfigurationskomponenten zu finden sind. Daraus können Sie wertvolle Hinweise für Ihre eigenen Auditskripte und in vielen Fällen auch für automatische Korrekturen der Fehlkonfigurationen entnehmen.

Physische Sicherheit schaffen

Der Zugriff auf die Hardware Ihrer ESXi-Hosts bildet das Fundament der Plattformsicherheit. Wie bei allen Computersystemen sollten Sie auch hier den physischen Zugriff durch geeignete Maßnahmen möglichst einschränken. Sorgen Sie durch den fachgerechten und sorgfältigen Einbau der Serverhardware dafür, dass eine persönliche Visite im Serverraum möglichst selten notwendig ist.

Stellen Sie außerdem sicher, dass die Systemmanagement-Karten (je nach Server-Hersteller können diese Geräte iLO, iDRAC, iRMC oder anders heißen) stets auf dem aktuellen Softwarestand sind und sichere Konfigurationen aufweisen. Ändern Sie die Standardkennwörter und, falls möglich, auch Standardbenutzernamen. Verwenden Sie auch für den Managementzugriff personalisierte Admin-Accounts. Ferner sollten Sie das Hardwaremanagement nicht an Ihre zentralen Verzeichnisse, allen voran das Active Directory, zur Authentifizierung und Autorisierung anschließen. Noch vor einigen Jahren lautete die Empfehlung gegenteilig und der SCG hat sie insofern abgeschwächt, als dass Sie wenigstens darauf achten sollten, weder einen "Abhängigkeits-Loop" noch eine Sicherheitslücke zu erzeugen.

Vergeben Sie weiterhin gute (also starke und einzigartige) Konfigurationskennwörter für das BIOS und andere einstellbare Firmwarekomponenten und speichern Sie diese in einem zentralen Passwortmanager. Nutzen Sie bei Rackservern und Blade-Enclosures fixe IPv4-Konfigurationen und deaktivieren Sie IPv6, solange Sie das neue Protokoll im Management-Subnetz nicht benötigen.

Auch sollten Sie virtuelle Netzwerkkarten deaktivieren, die manche Managementcontroller verwenden, um mit dem installierten Betriebssystem zu kommunizieren. ESXi macht davon keinen Gebrauch. Schalten Sie zudem alle administrativ nicht benötigten Schnittstellen wie serielle Ports oder nicht gepatchte Netzwerkkarten ab. Dokumentieren Sie diese Maßnahmen, damit Sie später nachvollziehen können, warum eine bestimmte Schnittstelle nicht aktiv ist. Konfigurieren Sie für alle Zugriffsprotokolle auf das Managementinterface die Variante mit Verschlüsselung als verpflichtend: HTTPS statt HTTP, SSH statt Telnet, SFTP statt FTP und so weiter. Stellen Sie die entsprechenden TLS-Zertifikate aus Ihrer internen PKI aus.

Sorgen Sie ferner mit geeignetem Routing und Firewall-Regelwerk dafür, dass nur diejenigen Workstations Zugriff auf das Hardwaremanagement erhalten, von denen aus das physische Rechenzentrum auch tatsächlich verwaltet werden soll. Manche Organisationen stellen zu diesem Zweck einen Jump-Host ins Verwaltungsnetz. In diesem Fall betrifft die obige Regel den Zugriff auf den Jump-Host, beispielsweise per RDP oder SSH.

Stellen Sie die Boot-Reihenfolge in der Hardwarekonfiguration so ein, dass ein Angreifer Ihre Hosts nicht von einem Wechselmedium oder einem kompromittierten PXE-Server starten kann, um den installierten Hypervisor zu verändern. Falls Sie AutoDeploy in Ihrer vSphere-Umgebung verwenden, müssen Sie PXE-Boot natürlich zulassen. Deaktivieren Sie auch in diesem Fall alle anderen Startquellen. Leiten Sie nicht zuletzt die Zugriffsprotokolle des Hardwaremanagements in einen zentralen Logserver um. Sorgen Sie dafür, dass die Uhrzeit der Managementcontroller mit dem Rest der Infrastruktur synchronisiert ist – nur so können Sie die Logs für die Auswertung sinnvoll korrelieren.

Powermanagement über IPMI

Das Powermanagement über IPMI verdient aus Sicherheitssicht besondere Erwähnung, denn dieses Protokoll bildet die Grundlage für das "Distributed Power Management" (DPM) in vSphere. Die Benutzerauthentifizierung in IPMI basiert auf einem einfachen Challenge-Response-Verfahren und ist aus heutiger Sicht als unsicher einzustufen. Erschwerend kommt hinzu, dass in vielen IPMI-Implementierungen der User über höchstmögliche Berechtigungen verfügen muss, um den Server einschalten zu können. Daher sollten Sie sich nach Alternativen zu IPMI umschauen, falls Sie DPM in Ihrem vSphere-Datacenter nutzen möchten. Setzen Sie in den betreffenden ESXi-Clustern auf HPE-Hardware, können Ihre vCenter die iLO-Schnittstelle auf dem proprietären Protokoll direkt ansprechen. Leider benötigt auch dort der im vCenter zu hinterlegende User sehr hohe Berechtigungen. Die dritte Option – das klassische Wake-On-LAN (WOL) – ist ebenfalls nicht ganz ohne Tücken. WOL wird nicht etwa auf dem Management-, sondern am vMotion-Netzwerk der Hosts durchgeführt.

Beim Einsatz moderner konvergenter Netzwerkadapter ist die durchzuführende Konfiguration im Netzwerk nicht trivial. Dennoch sollten Sie aus den Überlegungen pro Sicherheit die WOL-Option wohlwollend prüfen, denn damit erhalten Sie die erforderliche Funktionalität wenigstens, ohne die unsicheren Authentifizierungsverfahren in Kauf nehmen zu müssen. Falls das BIOS Ihrer Server das zeitgesteuerte Hochfahren unterstützt, können Sie einen Kompromiss zwischen Energiesparen und Sicherheit fahren. Richten Sie DPM mit WOL-Option ein, ohne WOL technisch zu ermöglichen, und stellen Sie im BIOS einen Einschaltvorgang beispielsweise jeden Werktag um 6:30 Uhr ein. Dann wird DPM bei sinkender Last einige der Hosts evakuieren und in den Standby-Modus versetzen. Das Wiederhochfahren aus dem Standby erfolgt dann nicht mit DPM, sondern mit dem BIOS-eigenen Timer.

Das Zusammenspiel der Hardware und des darauf installierten Betriebssystems – im Fall von vSphere ist es der ESXi-Hypervisor – sollte ebenfalls in einer Konfiguration erfolgen, die maximale Sicherheit im Betrieb des Hypervisors verspricht. Aktivieren Sie unbedingt UEFI Secure Boot und stellen Sie bei Intel-basierten Servern sicher, dass die Trusted Execution Technology (TXT) aktiviert ist. Schalten Sie zudem den TPM-2.0-Chip ein und initialisieren Sie ihn bei Bedarf. Aktivieren Sie daneben SGX (Intel) beziehungsweise SEV-ES (AMD). Bei SEV-ES müssen Sie die maximale Anzahl der geschützten VMs entsprechend der Dimensionierung Ihrer Infrastruktur konfigurieren. Das Einschalten einiger dieser Features erfordert zwingend einen Neustart, daher sollten Sie sie selbst dann vor der Inbetriebnahme einschalten, wenn Sie sie nicht sofort einsetzen.

Im zweiten Teil der Workshopserie geht es darum, wie Sie den Virtualisierungshost lückenlos abdichten, warum NTP als Zeitquelle robuster ist als PTP und wie Sie schon auf Netzwerkebene für Schutz sorgen. Im dritten und letzten Teil schauen wir uns an, wie Sie das vCenter härten und wie Sie als letzten Schritt Ihre virtuellen Maschinen abschirmen.

Über den Autor: Evgenij Smirnov ist Senior Solutions Architect bei Semperis und Microsoft-MVP für Cloud & Datacenter Management sowie VMware Certified Implementation Expert für Datacenter-Virtualisierung.