Netzwerk und Storage in VMware-Umgebungen absichern (2)

Lesezeit
4 Minuten
Bis jetzt gelesen

Netzwerk und Storage in VMware-Umgebungen absichern (2)

12.06.2023 - 07:13
Veröffentlicht in:

Eine virtuelle Maschine allein bietet kaum einen Mehrwert. Vielmehr fließen zwischen VMs und auch zur Außenwelt hin fleißig Daten. Hierfür ist eine passende wie sichere Netzwerkarchitektur notwendig. Wie diese und auch ein richtig administrierter Daten-Storage im Fall von ESXi aussieht, zeigt dieser Workshop. Im zweiten Teil erläutern wir den richtigen Umgang mit physischen Netzwerkkarten und zeigen, wie die Architektur des Storage in VMware-Umgebungen aussieht.

Netzwerkarten in vSphere
Auf einem ESXi-Server müssen Sie eine Reihe von Netzwerkarten berücksichtigen. Dazu gehören vSphere-Infrastrukturnetzwerke für Funktionen wie vMotion, vSphere-Fehlertoleranz und Storage oder Overlay-Netzwerke für NSX. Diese Netzwerke müssen Sie aufgrund ihrer spezifischen Funktionen und Kritikalität streng von VM-Nutz-Traffic isolieren.

Oft wurden vMotion-VLANs gar nicht geroutet und somit nur den ESXi-Servern Zugriff gegeben. In modernen Designs findet sich jedoch häufig eine Layer-3-Leaf-Spine-Architektur, die natürlich auch ein Routing im Bereich der Infrastrukturnetze benötigt. Mittlerweile ist auch ein geroutetes vMotion unterstützt.

Bild 2: VMs verbinden sich über Portgruppen mit Standard-Switches.
Bild 2: VMs verbinden sich über Portgruppen mit Standard-Switches.
 

Nachfolgend erläutern wir in diesem Zusammenhang verschiedene VMkernel-Arten. Sie können natürlich jeden VMkernel-Port auf ein eigenes VLAN legen, was aber laut VMware Validated Design (VVD) nicht notwendig ist.

  • vMotion: Ermöglicht dem VMkernel-Adapter, sich bei einem anderen Host als die Netzwerkverbindung zu bewerben, über die der vMotion-Verkehr gesendet wird. Die Migration mit vMotion auf den ausgewählten Host ist nicht möglich, wenn der vMotion-Dienst für keinen VMkernel-Adapter auf dem Standard-TCP/IP-Stack aktiviert ist oder wenn es keine Adapter gibt, die den vMotion-TCP/IP-Stack verwenden.
  • Provisioning: Verwaltet die übertragenen Daten für die Kaltmigration virtueller Maschinen, das Klonen und die Snapshot-Migration.
  • Fault Tolerance Logging: Aktiviert die Fehlertoleranzprotokollierung auf dem Host. Sie können einen VMkernel-Adapter für FT-Datenverkehr je Host nutzen.
  • Management: Aktiviert den Management-Datenverkehr für den Host und vCenter Server. Normalerweise haben Hosts einen solchen VMkernel-Adapter bei der Installation der ESXi-Software erstellt. Sie können mehrere VMkernel-Adapter für den Management-Datenverkehr auf dem Host erstellen, um Redundanz zu gewährleisten.
  • vSphere Replikation: Verarbeitet die ausgehenden Replikationsdaten, die vom Quell-ESXi-Host an den vSphere-Replication-Server gesendet werden.
  • vSphere Replikation NFC: Verwaltet die eingehenden Replikationsdaten auf dem Zielreplikationsstandort per Network File Copy.
  • vSAN: Aktiviert den vSAN-Verkehr auf dem Host. Jeder Host, der Teil eines vSAN-Clusters ist, muss über einen solchen VMkernel-Adapter verfügen.
  • NSX-Transport (optional): Installieren Sie NSX und verwenden Overlays, gibt es eigene VMkernel-Ports, um zwischen NSX-Transportknoten via Geneve-Tunnel Traffic auszutauschen.

Das Bedeutendste ist das Managementnetzwerk, das Client-, Befehlszeilenschnittstellen- (CLI) oder API- und Softwaredatenverkehr von Drittanbietern isoliert vom normalen Datenverkehr der VMs verarbeitet. Der Zugriff auf dieses Netzwerk sollte auf Administratoren für das System, das Netzwerk und die Sicherheit beschränkt sein. Hierfür bieten sich Security-Mechanismen wie Firewalls, Intrusion-Detection-Systeme und Zweifaktor-Authentifizierung an.

Es empfiehlt sich aus Sicherheitsgründen außerdem, Jumphosts mittels Terminal-services oder VDI (etwa VMware Horizon View oder XenDesktop) zum Zugriff auf das Management-Netzwerk zu verwenden. Auf diesen administrativen Managementhosts darf natürlich weder gesurft noch gemailt werden und sie sind mit Sicherheitstechnologien wie einem Endpunktschutz oder Whitelisting auszustatten. Der Zugriff innerhalb dieses Netzwerks auf mögliche Malwarequellen ist streng zu kontrollieren.

Die Isolierung virtueller Maschinen im Netzwerk lässt sich derweil durch virtuelle Firewalls wie VMware NSX verbessern, da Firewallregeln noch vor der vNIC greifen und sämtlichen Verkehr auf dem virtuellen Netzwerkcontroller filtern. Die Firewalleinstellungen verbleiben bei der virtuellen Maschine, wenn diese innerhalb eines vSphere-Clusters von Host zu Host migriert wird.

Bild 3: Das Schema der virtuellen Netzwerkarten und der Netzwerktrennungen in vSphere.
Bild 3: Das Schema der virtuellen Netzwerkarten und der Netzwerktrennungen in vSphere.
 

In Bild 3 sehen Sie ein Diagramm, das die verschiedenen Netzwerke in vSphere zeigt. Dies soll verdeutlichen, dass Sie den Datenverkehr für bestimmte Anwendungen und Funktionen voneinander isoliert müssen. Beispielsweise sollte der vMotion-Datenverkehr nicht über Netzwerke laufen, in denen sich virtuelle Maschinen befinden. Dies verhindert das Mitlesen des Verkehrs. Aus Leistungsgründen ist es auch empfehlenswert, das Netzwerk zu segmentieren – wenn nicht sogar aus Stabilitäts- und Skalierungsgründen den Einsatz von NSX zu erwägen. VMware empfiehlt, die Managementnetze von ESXi-Servern, vCenter und anderen VMware-Elementen wie NSX in einem VLAN zu betreiben. Achten Sie darauf, dass

  • der Zugang zur Management-Domäne unbedingt geschützt ist durch eine Segmentierung, Firewalls und Multifaktor-Authentifizierung.
  • VDS als Switch-Art in vSphere 7 bevorzugt zum Einsatz kommt.
  • der VST-Tagging-Modus und 802.1q verwendet werden.
  • Network I/O Control (NIOC) für Durchsatzlimits und -Garantien sorgt.
  • NSX eine Mikrosegmentierung zur Gastisolation vornimmt.

Architektur des Storage
Eine virtuelle Maschine auf einem ESXi-Host verwendet eine virtuelle Festplatte, um das Betriebssystem, die Anwendungsdateien und andere Daten für ihren Betrieb zu speichern. Virtuelle Festplatten sind große physische Dateien beziehungsweise Gruppen von Dateien, die wie jede andere Datei kopiert, verschoben, archiviert und gesichert werden können. Sie können VMs mit mehreren virtuellen Festplatten konfigurieren. Jede virtuelle Platte (VMDK-Datei im Verzeichnis der VM) gehört ausschließlich der VM, die in ihrer VMX-Konfigurationsdatei auf sie verweist. Keine andere virtuelle Maschine auf demselben oder einem anderen ESXi-Host darf auf diese virtuelle Festplatte zugreifen – außer, sie ist dafür konfiguriert.

Für den Zugriff auf virtuelle Festplatten verwendet eine virtuelle Maschine virtuelle SCSI-Controller. Zu diesen virtuellen Controllern gehören BusLogic Parallel, LSI Logic Parallel, LSI Logic SAS und VMware Paravirtual. Dies sind die einzigen SCSI-Controllertypen, die eine virtuelle Maschine anzeigen und auf die sie zugreifen kann. Jede virtuelle Festplatte befindet sich in einem Datenspeicher, der auf dem physischen Speicher bereitsteht. Jede virtuelle Festplatte wird vom Standpunkt der virtuellen Maschine aus so angezeigt, als wäre ein SCSI-Laufwerk mit einem SCSI-Controller verbunden. Ob der Zugriff auf den physischen Speicher über Speicher- oder Netzwerkadapter auf dem Host stattfindet, ist für das VM-Gastbetriebssystem und die Anwendungen normalerweise transparent. Auf diese gemeinsam genutzten LUNs hat das Gast-OS keine Sicht und kann also auch hier die VMDK nicht verlassen.

Wenn eine VM mit ihrer virtuellen Festplatte kommuniziert, die in einem Data -store gespeichert ist, ruft sie SCSI-Befehle auf. Da sich die Datenspeicher auf verschiedenen Arten physischer Speicher befinden können, werden diese Befehle je nach Protokoll, das der ESXi-Host zur Anbindung an ein Speichergerät verwendet, umgewandelt.

Bild 4: Veranschaulichung der Storage-Zugriffsarten für VMs.
Bild 4: Veranschaulichung der Storage-Zugriffsarten für VMs.
 

ESXi unterstützt die Protokolle Fibre Channel (FC), Internet SCSI (iSCSI), Fibre Channel over Ethernet (FCoE) und NFS. Die virtuelle Festplatte wird unabhängig vom Typ des Speichergeräts, den Ihr Host verwendet, immer als gemountetes SCSI-Gerät angezeigt. Die virtuelle Festplatte verbirgt die physische Speicherebene vor dem Betriebssystem der virtuellen Maschine. Dadurch lassen sich in der VM Betriebssysteme ausführen, die nicht für bestimmte Storage-Systeme, zum Beispiel SAN, zertifiziert sind. Bild 4 zeigt die Unterschiede zwischen den Speichertypen: Die fünf beispielhaft dargestellten virtuelle Maschinen verwenden unterschiedliche Arten von Speichern.

Im Allgemeinen handelt es sich bei der Storage-Virtualisierung um eine logische Abstraktion von physischen Speicherressourcen und -kapazitäten. ESXi bietet Storage-Virtualisierung auf Hostebene. ESXi kann Fibre-Channel-, NFS- oder iSCSI-Protokolle verwenden, um Verbindungen zu Speichersystemen herzustellen.

SAN-Sicherheit
Im SAN-Umfeld ist ein Host, der auf dem ESXi-Server läuft, wie jeder andere Host an ein Fiber-Channel-SAN angeschlossen. Es kommen Fiber-Channel-HBAs (Host Bus Adapter) zum Einsatz, wobei die Treiber für die in der Softwareschicht installierten HBAs direkt mit der Hardware interagieren. In Umgebungen ohne Virtualisierungssoftware sind die Treiber auf dem Betriebssystem installiert.

Im Fall von ESXi werden die Treiber im ESXi-VMkernel eingespielt. Bei der SAN-Sicherheit gelten ähnliche Konzepte wie im Netzwerkbereich durch die Segmentierung mittels VLANs. FC-Switches legen fest, welche ESXi-Sever auf welche Storage-Arrays zugreifen dürfen. LUN-Masking ergänzt dies mit Definitionen, welche LUNs des gleichen Storage-Arrays (Targets) an die jeweiligen ESXi-Sever-Cluster herausgegeben werden.

ESXi unterstützt dabei unidirektionales CHAP für alle Arten von iSCSI-Initiatoren. Es unterstützt zudem bidirektionales CHAP für Software- und abhängiges Hardware-iSCSI. Auf alle Fälle ist mindestens unidirektionales CHAP zu verwenden.

ln/dr/Stephan Bohnengel und Christoph Buschbeck

Im dritten und letzten Teil des Workshops beschäftigen wir uns unter anderem mit dem Virtual Machine File System und den Besonderheiten der speicherrichtlinienbasierten Verwaltung. Im ersten Teil haben wir uns mit der Konfiguration von Portgruppen beschäftigt und haben den Unterschied zwischen einem vSphere-Standard-Switch und einem vSphere-Distributed-Switch erklärt.

Ähnliche Beiträge

VMware Aria Automation Orchestrator im Praxiseinsatz (3)

In Sachen Automatisierung ist Wiederverwendbarkeit das Ziel – etwa Skripte an verschiedenen Stellen erneut einzusetzen. Zu diesem Zweck stellt VMware Aria Automation Orchestrator (vormals vRealize Orchestrator) sogenannte Actions bereit. Dies umfasst etwa das Ausführen von Skripten in virtuellen Maschinen, das Registrieren einer VM im DNS oder die Integration ins Active Directory. Im dritten Teil der Workshopserie schildern wir Ausführen von Workflows mittels REST-API und widmen uns dem Verwalten von DNS-Einträgen.

VMware Aria Automation Orchestrator im Praxiseinsatz (2)

In Sachen Automatisierung ist Wiederverwendbarkeit das Ziel – etwa Skripte an verschiedenen Stellen erneut einzusetzen. Zu diesem Zweck stellt VMware Aria Automation Orchestrator (vormals vRealize Orchestrator) sogenannte Actions bereit. Dies umfasst etwa das Ausführen von Skripten in virtuellen Maschinen, das Registrieren einer VM im DNS oder die Integration ins Active Directory. Im zweiten Teil zeigen wir, wie Sie mithilfe des Guest Script Manager Skripte in einer VM ausführen.

VMware Aria Automation Orchestrator im Praxiseinsatz (1)

In Sachen Automatisierung ist Wiederverwendbarkeit das Ziel – etwa Skripte an verschiedenen Stellen erneut einzusetzen. Zu diesem Zweck stellt VMware Aria Automation Orchestrator (vormals vRealize Orchestrator) sogenannte Actions bereit. Dies umfasst etwa das Ausführen von Skripten in virtuellen Maschinen, das Registrieren einer VM im DNS oder die Integration ins Active Directory. Im ersten Teil schauen wir uns an, wie Sie Logging und Fehlerbehandlung betreiben.