Professional Data Center @ CeBIT
Virtuelle Sicherheit
Fortsetzung des Artikels von Teil 2
Virtualization, Automation
Insbesondere die Server- und Desktopvirtualisierung sorgen dafür, dass wesentlich mehr Dynamik ins Datacenter kommt: Redundanz-/Failovermechanismen wie »vMotion« von Vmware oder auch die dynamische Nutzung und Optimierung von Host-Ressourcen durch Verschiebung der virtuellen Maschinen (VMs) mit Funktionen wie DRS (Dynamic-Ressource-Scheduling) von Vmware sorgen dafür, dass sich die gesamte Server- und Desktop-Landschaft sehr schnell ändern und verschieben kann. Hinzu kommt das sehr einfache Einbringen neuer Server und Services unter Zuhilfenahme von Virtualisierungstechniken.
Der Betreiber der darunter liegenden Netzinfrastruktur muss in der Lage sein, virtuelle Services (Server, Desktops, Applikationen) schnell zu lokalisieren, zuzuordnen und zu überwachen. Andernfalls steigt der Zeitaufwand für das Bereitstellen von Ressourcen und der Aufwand beim Troubleshooting deutlich an, die Verfügbarkeit nimmt deutlich ab. Aus diesem Grund muss automatisch eine dynamische Allokierung von Netzwerkressourcen und Sicherheitsparametern erfolgen. Ebenso muss eine »Null-Konfiguration«-Mobilität gewährleistet sein, die jedoch gleichzeitig ein wirkungsvolles Monitoring zulässt. Dazu müssen sich Services einfach gruppieren lassen können und das jeweilige sicherheitsrelevante Verhalten gemessen und überprüft werden.
Und dies in einer Umgebung, die durch die Virtualisierungstechniken noch mehr »moving parts« bekommen haben, so beispielsweise der so genannte »Virtual Switch« oder »vSwitch« im Hypervisor von Vmware oder Xen. Dadurch ergeben sich für den traditionellen Netzwerk- und Security-Verantwortlichen folgende Fragen:
-- Wer sorgt für die Sicherheit der neuen Software-Applikation Hypervisor, Patch-Management etc.?
-- Wer sorgt für die mit der physischen Netzwerkinfrastruktur und deren Sicherheitsmechanismen (Firewall, VLAN, Access-Listen, VRF etc) sowie abgestimmte Konfiguration der virtuellen Switches auf den Hosts so dass keine Sicherheitslücken entstehen?
-- Wer ist für das Change-Management auf der Server- und Netzseite zuständig? Wie kann man VMs überhaupt in der Infrastruktur erkennen und tracken (aus Compliance-Anforderungen heraus und für das Troubleshooting)?
-- Wer sorgt für die Kapazitätsplanung der physischen Infrastruktur um in allen Virtual-Machine/Host-Kombinationen ausreichend Bandbreite zur Verfügung zu stellen? Die Inter-VM-Kommunikation auf dem gleichen Host ist ja zunächst nicht sichtbar.
Zu beachten ist auch, dass die integrierten Vswitches der am Markt verfügbaren Virtualisierungslösungen nicht als »mature« betrachtet werden können. Sowohl was die Features als auch die Stabilität angeht. Weiterhin stellt sich dem erfahrenen Netzwerker die Frage, wie es denn mit der Performance und dessen Monitoring dieser software-basierten Komponenten bestellt ist. Und wie der entsprechende Einfluss auf den Host beim Einschalten zusätzlicher Features, soweit überhaupt vorhanden, zu quantifizieren ist. Man kann natürlich die virtuellen Switches nicht ausblenden, sondern sollte sein Betriebskonzept darauf abstimmen und sie integrieren, ohne jedoch zu viel Funktionen dort hinein zu verlagern: dies würde die Betriebskosten und die Komplexität erhöhen und zu eventuell nicht erwünschten Effekten führen.
Es gibt natürlich den Ansatz am Markt, der einfach den virtuellen Switch durch einen eigenen ersetzt, um das »CLI (command line interface)« identisch zu gestalten und so die Konfiguration zu »vereinfachen«. Aber damit bindet sich der Kunde zu 100 Prozent an die Anbieterkombination von Netzwerk- und Virtualisierungstechnologie – hier aber ist noch viele Bewegung zu sehen und ein Kunde wird in Zukunft wohl mehrere unterschiedlich Technologien nutzen. Sofern müsste man für jede Technologie von seinem Netzanbieter einen Vswitch bekommen. Und das ist aus der Erfahrung heraus nicht erstrebenswert oder praktikabel. Auch führt dies immer wieder zu »Version lock-ins«, das heißt, falls der eine Partner nicht rechtzeitig mitzieht kann eventuell eine neue Version aus Kompatibilitätsgründen nicht eingespielt und genutzt werden.
Einen grundlegend anderen Ansatz verfolgt hier Enterasys. Die Integration erfolgt über das Management-System mittels Web-Services-APIs. Dies sorgt unter anderem für eine Unabhängigkeit von der Virtualisierungstechnologie und ist schnell erweiterbar. Stand heute wird die Integration über bestehende APIs der Virtualisierungsanbieter Citrix mit »XENCenter« oder Vmware mit »ESX« oder »vCenter« unterstützt. Man nutzt hier Web-Services via XML/SOAP, um Daten und Konfigurationen zwischen VM- und Netzwerk-Management abzustimmen, auszutauschen und zu synchronisieren.
Das VM-Management bekommt vom Netzmanagement in Echtzeit den Status, die zugewiesene Policy und die Location (an welchem physischen Switchport befindet sich die VM) der VM geliefert und ermöglicht somit dem Serveradministrator den vollen Überblick über alle relevanten Parameter.
Auch werden die möglichen Netze und VLANs dem Server/VM-Administrator automatisch vorgegeben. Diese weist dann nur noch seine VMs einem Netz zu – diese Information wird automatisch ins Netzwerk-Management synchronisiert und hier an eine netzwerkspezifische Policy gebunden. Sobald eine VM Pakete sendet wird am Switchport für diese VM die entsprechende VLAN, Access-Listen und Quality-of-Service-Konfiguration bereitgestellt. Fehlkonfigurationen von externem Switch und Vswitch werden damit ausgeschlossen. Damit muss der Netzwerkadministrator nicht eingreifen aber er hat ebenfalls (wie auch der Serveradministrator) alle Daten einer VM direkt im Zugriff. Auch wiederum fürs Troubleshooting, für die Kapazitätsplanung und eventuelles (Compliance) Reporting unabdingbar.
Zur Zuweisung von Netzwerk- und Security-Konfiguration pro VM muss die verwendete Switch-Hardware so weit skalieren, dass Umgebungen mit potenziell mehreren 100 VMs (bei Desktopvirtualisierung) pro Host/physischem Server und mehreren 10000 Access-Listen unterstützt werden.
Das zuvor genannte Konzept kann man je nach Möglichkeiten der API noch ausbauen und vom Netzwerk-Management aus die Vswitch-Konfiguration weiter überschreiben, je nachdem, wer die Kontrolle über die Gesamtkonfiguration haben soll.
Der Kapazitätsplanung beziehungsweise dem Monitoring der aktuell und historisch genutzten Bandbreite muss in einer virtualisierten Serverumgebung ein besonderes Augenmerk gelten. Durch die potenzielle Verschiebung von Server-Ressourcen auf neue oder wenig genutzte Hosts, kann sich das gesamte Verkehrsprofil im Datacenter schlagartig ändern. Dem Netzwerkadministrator muss dies bewusst sein und er sollte sich entsprechend wappnen. Transparenz hat hier oberste Priorität – Verkehrsstatistiken pro VM sollten über präzise Technologien wie beispielsweise Netflow erhoben werden und auf Abruf bereit stehen. Hiermit kann man nicht nur Tendenzen erkennen beziehungsweise das Verhalten vorhersagen, Flowdaten eignen sich auch besonders zur Erkennung von Angriffen auf die VM-Infrastruktur. Network-Behavior-Analysis (NBA) ist hier das Stichwort. In Verbindung mit einem Security-Monitoring der aktuellen Generation kann man hiermit das gesamte Datacenter und die dort zur Verfügung gestellten Applikationen sicherheitstechnisch im Griff haben. Zusammenfassend kann der Einsatz vom Web-Services und auf SOA basierenden Management-Konzepten den Betrieb einer Virtual-Datacenter-Umgebung drastisch vereinfachen und einen hohen Automatisierungsgrad erzielen. Damit sind sowohl die in Aussicht gestellten Betriebskostensenkungen zu erreichen als auch die Sicherheit und Transparenz im Betrieb zu garantieren.
- Virtuelle Sicherheit
- Datacenter-Komponenten
- Virtualization, Automation
- Storage
- Connectivity and Topology
Lesen Sie mehr zum Thema
