Die Virtualisierung von Servern erfordert auch eine Änderung der IT-Betriebskonzepte. Dies gilt insbesondere für das Sicherheitskonzept, das beim Einsatz einer virtuellen Infrastruktur ganz neuen Regeln unterliegt. In der traditionellen physischen Welt ist beispielsweise häufig eine Security-Appliance im Kommunikationskanal zwischen zwei Server-Systemen eingeschleust. Als Security-Appliance soll im Kontext dieses Textes jegliche Sicherheitseinrichtung gelten wie etwa eine Firewall, ein Malware-Scanner, ein Intrusion-Detection- oder -Prevention-System oder ein VPN-Gateway.
Dem Trend der Virtualisierung folgend gehen die Hersteller jetzt aber dazu über, ihre ehemals physischen Security-Appliances virtuell nachzubilden. Die Sicherheitsanwendungen laufen dann in einer virtuellen Maschine auf einem Hypervisor. Doch das bleibt nicht ohne Auswirkungen auf den gesamten Sicherheitsstatus.
Wie verhält es sich beispielsweise, wenn zwischen zwei virtuellen Maschinen eine ebenso virtuelle Security-Appliance geschaltet ist und die Virtualisierungsschicht eine der Maschinen kurzerhand umzieht? Wie ist zu verfahren, wenn die virtuelle Appliance aufgrund der Ressourcenzuweisung zum Engpass wird? Diesen und ähnlichen Fragen wollen wir in diesem Beitrag nachgehen.
Ausfallsicherheit und Angriffsschutz wachsen zusammen
Die Absicherung eines Systeme ist aus zwei unterschiedlichen Blickwinkeln zu betrachten: die gegen Angriffe und die gegen den Ausfall des Dienstes. Erstere wurde in der Vergangenheit in der Regel durch die bekannten und traditionellen Sicherheitstools wie etwa Firewalls oder Intrusion-Detection-Systeme (IDS) erreicht. Die Sicherheit gegen den Ausfall wiederum, also die Gewährleistung der Business Continuity, war eine Domäne von Backup/Restore, Desaster Recovery oder Failover-Einrichtungen.
Diese Trennung in Ausfallsicherheit und Schutz vor Angriffen ist traditionell bedingt. Die Aspekte werden aber künftig ineinander fließen. Dies macht allein schon deswegen Sinn, weil es aus Sicht des Nutzers keinen Unterschied macht, ob der Dienst aufgrund eines Virenangriffs, einer DoS-Attacke, einer temporären Überlastung oder eines Server-Ausfalls verursacht wurde.
Migration der virtuellen Maschinen
Um die Dynamik von virtuellen Systemen auszunutzen und die Server-Hardware besser auszulasten, existieren mehrere Möglichkeiten zur Lastverteilung. Dabei müssen aber auch die Sicherheitseinrichtungen mit berücksichtigt werden. Durch das Verschieben einer virtuellen Maschine (VM) auf einen anderen physischen Host ändert sich beispielsweise die Verbindung zwischen VM und Security-Appliance. Falls es sich bei dem Sicherheitsmodul um eine externe, physische Komponente handelte, erscheint dies weniger aufwendig. In diesem Fall wird der gesamte Datenverkehr ohnehin vom Sender über die externe Appliance an den Empfänger gereicht.
Ob die beiden Partner, also der Sender und der finale Empfänger des Datenpaketes, dabei als virtuelle Maschinen auf einem gemeinsamen oder zwei getrennten physischen Hosts liegen, ändert am prinzipiellen Kommunikationsverhalten nichts. Die Datenpakete laufen immer von der VM des Senders über das physische Netzwerk-Interface zur externen Sicherheits-Appliance und von dort über ein weiteres Netzwerk-Interface zum Empfänger.
Laufen Sender, Empfänger und eine virtuelle Sicherheits-Appliances allerdings auf dem gleichen Host, bleibt der Datenverkehr innerhalb des Hypervisors; er verlässt den Rechner nicht. Bei der Migration einer der drei beteiligten virtuellen Maschinen auf einen zweiten Host muss dieser direkte Link daher aufgebrochen werden. Die Pakete müssen in jedem Fall aus dem Host geroutet werden.
Für die vSphere-Umgebungen bietet VMware die vShield Zones zum Management der Sicherheit einer kompletten virtuellen Infrastruktur an. Bei der Migration einer VM behält diese alle Security-Policies bei. Die Kommunikation zwischen den virtuellen Maschinen reißt dadurch nicht ab, sondern wird entsprechend umgeleitet. So soll laut VMware nicht einmal dann ein Sicherheitsrisiko entstehen, wenn ein virtueller Server aus dem Kernbereich der IT auf einen physischen Host wandert, der auch die Internet-Server aus der DMZ (demilitarisierte Zone) beherbergt.
Obwohl es also technische Lösungen gibt, ist deren Einsatz bei sicherheitskritischen Anwendungen generell skeptisch zu sehen. Sollte man daher auf den Einsatz von virtuellen Appliances gänzlich verzichten oder worin liegen deren Vorteile?
Vor- und Nachteile virtueller Security-Appliances
Der Einsatz von virtuellen Security-Appliances hat gegenüber den physischen Pendants Vor-, aber auch Nachteile. Zu den Vorteilen zählt die höhere Flexibilität. Je nach Auslastung kann man ihnen dynamisch mehr Rechenleistung gewähren. Virtuelle Security-Appliances laufen zudem auf einer emulierten Standardhardware, die weit verbreitet ist. Installationsprobleme und Ärger mit nicht unterstützter „Hardware“ treten daher selten auf. Dies vereinfacht auch die Verwaltung. Die Anforderungen beschränken sich meist auf gültige Lizenzen für die virtuelle Maschine und die darauf laufende Software.
Den Vorzügen stehen aber auch Nachteile gegenüber. Virtuelle können anders als physischen Appliances nicht auf spezielle Baugruppen zurückgreifen, die die Sicherheit oder den Durchsatz in Hardware erhöhen. Von der Leistung her erreicht eine virtuelle Appliance auch nicht das Niveau einer ASIC-Implementierung in physischen Sicherheitssystemen. Virtuelle Appliances unterliegen darüber hinaus den Bedingungen des Hypervisors und dessen Ressourcenzuweisung. Wenn der Hypervisor eine Mehrfachbelegung des Speichers (Memory Overcommit) unterstützt, kann beispielsweise durch Swapping plötzlich der Durchsatz einbrechen.
Die Hersteller von virtuellen Appliances scheuen daher davor zurück, Angaben zum Durchsatz und zur Leistung der Systeme zu machen. Bei physischen Boxen sind diese Daten bekannt und reproduzierbar messbar. Bei einer dynamischen CPU- und Speicherzuweisung durch den Hypervisor sind garantierte Performance-Werte aber fast unmöglich.
Virtuelle Appliances weisen außerdem eine größere Angriffsfläche auf, da sowohl Host als auch Client bedroht sind. Zudem läuft die Appliance auf einer virtuellen Maschine mit exakt definierten Eigenschaften. Durch deren massenhafte Verbreitung lohnt es sich für Angreifer auch, eine sehr komplexe Attacke zu entwickeln.
Wägt man diese Vor- und Nachteile ab, so ergibt sich kein eindeutiges Bild. Auf keinem Fall wird man bestehende Sicherheits-Appliances nur wegen der Migration der Server sofort außer Betrieb stellen. Mittelfristig geht der Trend aber beim Einsatz einer virtuellen Infrastruktur eindeutig in Richtung virtuelle Appliance. Für echtes dynamisches Cloud-Computing stellen sie die einzige sinnvolle Variante dar, denn eine physische Appliance lässt sich nicht so ohne Weiteres erzeugen oder im Durchsatz hochfahren.
Virtuelle Switche vereinfachen die Migration
Bei der Migration einer virtuellen Maschine auf einen anderen Host muss dessen Anbindung an die Umgebung berücksichtigt werden. Hierbei gilt es einige Fallstricke zu beachten. Die heute verfügbaren virtuellen Netzwerk-Switche der Virtualisierungslösungen existieren nur im Kontext eines einzelnen Hypervisor. Nach außen sind sie nicht sichtbar. Wird nun eine VM von einem Host auf einen anderen umgezogen, so verliert sie ihre Verbindung zum virtuellen Switch des ursprünglichen Hosts. Daher müssen bei der Umschichtung virtueller Maschinen immer auch die Netzwerkanbindungen beachtet werden.
Probleme mit der Netzwerkanbindung kann man vermeiden, indem auf beiden Hosts ein virtueller Switch mit den gleichen IP-Segmenten und Adressen eingerichtet wird. Allerdings erfordert dies die Konfiguration von je einem identischen Switch pro Host. Einfacher wird es hingegen, wenn die Netzanbindung aus dem Kontext des einzelnen Hypervisors herausgelöst wird und stattdessen eine zentral verwaltete Netzwerkkomponente die Aufgabe übernimmt.
Hierzu dienen sogenannte virtuelle Distributed-Switche, die VMware im Kontext von vSphere 4 liefert. Um auch Drittanbietern eine Integration ihrer Switche zu ermöglichen, öffnet der Virtualisierungsspezialist das Interface in der vNetwork API nach außen. In dieses klinkt sich beispielsweise Cisco mit seinem Nexus 1000V ein, der dann über die Standard-IOS-Tools verwaltet wird. Der virtuelle Switch kommuniziert über die vNetwork API mit vSphere und stellt virtuelle Switch-Funktionen bereit. Auch Citrix will in Zukunft virtuelle Switche im XenServer anbieten.
Der Switch verlässt den Hypervisor
Wenngleich sich die Konzepte der Implementierungen der verteilten virtuellen Switche unterscheiden, im Kern handelt es sich bei all diesen Varianten um übergreifende virtuelle Switche. Solch ein verteilter virtueller Switch ist damit für alle Hypervisors, die dafür konfiguriert sind, sichtbar. Wird nun eine VM von Host A nach Host B umgezogen, so behält sie alle Verbindungen zu den Ports des virtuellen Switchs. Angepasst werden muss lediglich der Uplink des Host zum externen Switch.
Der Einsatz eines virtuellen verteilten Switchs garantiert folglich, dass sämtliche Sicherheitsfunktionen bei einer Migration einer VM auch auf das Zielsystem übernommen werden. Dies vereinfacht die Migration erheblich. Die Definition eines verteilten virtuellen Switchs erfolgt immer außerhalb des Kontexts eines einzelnen Hypervisors. Im Idealfall kann damit die gesamte Konfiguration aller virtuellen Switche innerhalb einer einzigen Verwaltungskonsole erfolgen. Davon unberührt sind natürlich alle bestehenden physikalischen Switche und all jene, die innerhalb eines Hypervisors definiert wurden. Sie müssen entweder abgelöst werden oder sind in virtuelle Distributed-Switche zu überführen.
Die Verwendung von virtuellen Switchen und virtuellen Distributed-Switchen vereinfacht die Verwaltung enorm. Sie ist aber auch nicht ohne Risiken. Wenn durch wenige Konfigurationsschritte eine Verbindung zwischen virtuellen Geräten einzurichten ist, so genügt ein falscher Klick, und eine ungewollte Verbindung zwischen zwei VMs ist hergestellt. Das physische Patchen hingegen ist mit mehr Aufwand verbunden. Fehler sind daher nicht so schnell gemacht und lassen sich etwa durch farbig kodierte Kabel reduzieren.
In Enterprise-Umgebungen sollte in jedem Fall die Netzwerkverwaltung für die virtuelle Infrastruktur von den gleichen Netzwerkadministratoren vorgenommen werden, die auch die physischen Systeme verwalten. Sie können dann beide Umgebungen mit den gleichen Sicherheits- und Konfigurationseinstellungen versehen und aufeinander abstimmen.
Switche als zentrale Netzzugangsknoten
Ein Switch stellt immer den Zugang einer virtuellen Maschine zur weiteren Netzwerkumgebung dar. Diese gilt für physische und virtuelle Switche gleichermaßen. Durch die Konsolidierung mehrerer Rechner in einer virtuellen Umgebung wird der Netzwerkzugang aber stärker beansprucht und unter Umständen zum Engpass. Werden mehrere VMs über eine einzige physische Netzwerkkarte (NIC) geschleust, so wird diese auch zum Single-Point-Of-Failure für etliche Systeme. Daher sichert man diesen Zugang gegen einen Ausfall ab und legt ihn redundant aus.
Ferner muss dafür gesorgt werden, dass der maximale Kommunikationsbedarf aller virtuellen Maschinen durch die Netzwerkanbindung auch abgedeckt wird. Dazu können mehrere NICs im Teaming-Mode parallelgeschalten werden. Wenn beispielsweise ein virtueller NIC in VMware über den physischen NIC des ESX-Servers mit anderen Systemen kommuniziert, so wird dieser Zugang durch die Teaming-Funktion des Hypervisors immer abgesichert.
Generell werden virtuelle Maschinen, wie auch physische Rechner, auf OSI Layer 2 miteinander verbunden. Die VM wird somit mittels der virtuellen Switche in einen virtuellen Netzwerkport gepatched. Durch Softwareemulation wird außerdem dafür gesorgt, dass jede VM ihre eigene logische MAC-Adresse und IP-Adresse erhält, wenngleich diese physisch wieder auf wenige NICs zusammengeführt werden.
Virtuelle Maschinen auf einem Host lassen sich durch die Definition von VLANS zudem sicher trennen. Notwendig werden VLANS aber auch deswegen, da die physische Server-Hardware meist nicht über genügend Netzwerk-Slots verfügen, um alle benötigten Netzwerke durch separate NICs auch physisch zu trennen. Viele Unternehmen implementieren deshalb VLANs mit entsprechenden Sicherheitskonzepten.
Virtueller Netzwerkanschluss
Zum Anbinden der logischen IP-Adressen an die Netzwerke werden meist mehrere Switch-Ports benötigt. Dies kann unter Umständen zu komplexen mehrstufigen Netzwerkstrukturen mit einer recht aufwendigen Verkabelung führen. Um dem zu begegnen, offeriert beispielsweise HP mit Virtual Connect/Flex 10 eine hardwarebasierte Umsetzung in Form eines Erweiterungsmodules (Mezzanine Card). Dabei erfolgt eine Aufteilung eines physischen Netzwerkanschlusses auf vier logische Einheiten.
Gegenüber der virtuellen Maschine, aber auch der externen Switche entstehen dabei eigene Netzwerkanschlüsse, die in der Nutzung und Verwaltung jeweils getrennt sind und sich intern und extern wie eigene Ports verhalten. Jede VM erhält damit ihre eigene IP-Adress-Charakteristik. Im Kontext der virtuellen Maschine erhält sie einen physischen Netzwerkanschluss mit eigenem Treiber. Dies vereinfacht die IP-Adressverwaltung und Zuweisung für die VMs und ermöglicht eine bessere Lastverteilung. Bei einer Migration einer virtuellen Maschine auf einen anderen Host behält sie ihre IP-Adresse.
Die zur Verfügung stehende Bandbreite von 10 Gbit/s wird wahlfrei auf die vier Anschlüsse verteilt. Dies ermöglicht ein softwaregesteuerte Anpassen der Kommunikationsbandbreite einer virtuellen Maschine an die Anforderungen der Applikationen. Gleichzeitig reduziert dies den Overhead der externen Verkabelung. Virtual Connect/Flex 10 ermöglicht es somit, das Netzwerk zu konsolidieren und die benötigten Verbindungen zu reduzieren.
Fazit
Wer seine Systeme virtualisieren will, der ändert die bestehenden IT-Strukturen. Betroffen davon sind auch die Netzwerkanbindung und die Absicherung der Systeme. Virtuelle Appliances lösen dabei die physischen Security-Einrichtungen ab.
Durch verteilte virtuelle Switche wird die virtuelle Netzwerkinfrastruktur umfangreich orchestriert. Unterlegt mit dynamischen Zugangstechniken samt Bandbreitenoptimierung wird somit das „virtuelle Verdrahten“ der Systeme gewährleistet. Damit wird man den Anforderungen der Anwendungen dynamisch gerecht und kann so auch die Netzwerkinfrastruktur besser auslasten. (ala)