In Zusammenarbeit mit VMware bietet Trend Micro jetzt einen umfassenden Virenschutzansatz für virtuelle Datenzentren auf der Basis von »vSphere 4/5«: »Deep Security«. Dieser Ansatz löst die zentralen Probleme traditioneller Konzepte, vereinfacht die Verwaltung, ermöglicht IT-Richtlinieneinhaltung und verbessert insgesamt die Sicherheit der Lösung.

Der Schwerpunkt heutiger Virtualisierungs-Vorhaben verlagert sich von der Realisierung der Kostenvorteile hin zu mehr Service-Qualität. Diese Entwicklung hat Zielvorgaben für Service Level Agreements (SLAs), Geschwindigkeit und Stabilität im Schlepptau. Allerdings setzen Unternehmen vielfach auf die Implementierung traditionell gestalteter Sicherheitslösungen in virtualisierten Umgebungen. Doch daraus ergeben sich vielfach auch unerwünschte Folgen: Im günstigsten Fall erhöht sich die Komplexität und beeinträchtigt es die Leistung. Im schlimmsten Fall entstehen dadurch sogar neue Sicherheitsrisiken, und das vermindert die Kostenvorteile der Serverkonsolidierung.

Zwei generelle Faktoren erschweren den sicheren Weg zur Virtualisierung: Zum einen sind das die Risiken, die im physischen Datenzentrum bestehen, und zum anderen Probleme, die nur in virtualisierten Umgebungen auftreten. Daher haben sich die führenden Anbieter von Produkten für die Unternehmenssicherheit und die Virtualisierung – Trend Micro und VMware –zusammengeschlossen: Sie wollen diese Probleme deutlich machen und in speziellen Bereichen zusammenarbeiten, um den Anwendern die notwendige Hilfestellung zu geben.

Traditionelle Ansätze reichen nicht

Mit der bisher üblichen Vorgehensweise, im Zuge der Servervirtualisierung die bestehenden Endpunkt-Sicherheitslösungen auf jede virtuelle Maschine (VM) und somit auf jedem Gastbetriebssystem einzusetzen, lassen sich nicht alle Probleme beheben. Denn es gilt in den meisten Konsolidierungsvorhaben die grundlegenden Unterschiede von physischen und virtuellen Architekturen zu  beachten.

Denn jede Betriebssysteminstanz in einer physischen Umgebung – also ohne den Einsatz der Virtualisierung – läuft direkt auf der Hardware-Plattform. Dagegen agieren Betriebssysteminstanzen in einer virtuellen Umgebung üblicherweise auf einem Hypervisor, der die darunter liegenden Hardware-Ressourcen entsprechend verteilen muss. Das zieht Auswirkungen nach sich, wenn erprobte Routineaktionen aus der physischen Architektur direkt in die virtuelle Umgebung übernommen werden. Ein gutes Beispiel sind das Durchsuchen von Dateien (etwa nach Viren-Signaturen) oder das Einspielen von Software-Updates. Wenn sie für eine Vielzahl von VMs gleichzeitig angestoßen werden, führt das zu einem Ressourcenkonflikt im Bereich der physischen Hardware.

Ein weiterer Aspekt betrifft die Verwaltung des Virenschutzes. Die Administratoren einer Virtualisierungs-Infrastruktur (VI) könnten zwar auf vorhandenes Potenzial zurückgreifen und durch Verwendung von Vorlagen die Installation beschleunigen. Zudem sind sie in der Lage,  sich die zentrale Verwaltung des Virenschutzes zunutze machen. Doch selbst mit einem gewissen Grad an Automatisierung lassen sich Installation und laufende Verwaltung des Virenschutzes auf jeder virtuellen Gastmaschine nicht endlos skalieren. Der Vorgang erweist sich bereits in der physischen Umgebung als mühsam genug und wird durch den dynamischen Charakter virtueller Umgebungen nur noch erschwert.

Der traditionelle Ansatz führt daher bei virtualisierten Umgebungen zu drei Schlüsselproblemen:

• Sofortlücken,
• Ressourcenkonflikte sowie
• Einhaltung von Richtlinien/fehlende Prüfprotokolle.

 Wenn virtuelle Maschinen in schnellem Wechsel aktiviert und deaktiviert werden, ist es unmöglich, für diese virtuellen Maschinen schnell und konsistent Schutz bereitzustellen und diesen auf dem neuesten Stand zu halten. Das führt zum Problem der Sofortlücken: Inaktive virtuelle Maschinen können im Laufe der Zeit soweit vom Basisschutz abweichen, dass allein das Aktivieren dieser Maschinen schwerwiegende Sicherheitsschwachstellen verursacht. Außerdem besteht beim Einsatz neuer virtueller Maschinen, auch wenn sie anhand einer Vorlage mit Virenschutz erstellt wurden, die Möglichkeit, dass sie das Gastsystem nicht sofort ohne Konfiguration des Agents und ohne Pattern-Datei-Updates schützen. Denn generell gilt: Wenn eine virtuelle Gastmaschine während der Installation oder des Updates der Antiviren-Software nicht online ist, bleibt sie in ungeschütztem Zustand inaktiv und ist bei erneuter Aktivierung sofort gefährdet.

Antiviren-Stürme sind riskant

Ressourcenintensive Vorgänge, wie regelmäßige Virensuchen und Updates der Pattern-Dateien, führen als direkte Konsequenz der Serverkonsolidierung schnell zu einer extremen Systembelastung. Wenn Virensuche oder zeitgesteuerte Updates gleichzeitig auf allen virtuellen Maschinen auf nur einem physischen System in Aktion treten, führt dies zu einem regelrechten »Antiviren-Sturm«. Diese Entwicklung führt einem Ansturm auf die Ressourcen, sprich letztendlich auf Arbeitsspeicher, Speicherplatz und CPU. Serveranwendungen und virtuelle Desktop-Umgebungen (VDI, Virtual Desktop Infrastructure) werden durch diese Leistungseinbußen behindert.

Nimmt die Zahl der virtuellen Maschinen auf einem einzelnen Host zu, steigt in der traditionellen Architektur auch der Speicherbedarf linear mit an. In physischen Umgebungen muss Antiviren-Software auf jedem Betriebssystem installiert werden. Wendet man diese Architektur auf virtuelle Systeme an, so stellt jede virtuelle Maschine eine erhebliche, zusätzliche Belastung des Arbeitsspeichers dar – ein unerwünschter Effekt, der die Bemühungen um eine Serverkonsolidierung zunichtemacht.

Als dritter Aspekt kommt noch die Einhaltung von Richtlinien ins Spiel: Branchenspezifische Bestimmungen und Sicherheitsvorgaben in Unternehmen sind zu erweitern, um mit den Virtualisierungs-Technologien Schritt zu halten. Denn diese weisen spezielle Probleme hinsichtlich der Richtlinieneinhaltung auf. Transparenz und Kontrolle von System- und Netzwerkaktivitäten erweisen sich  in virtuellen Umgebungen als noch komplexer, da herkömmliche, Host-basierte Sicherheitssoftware und Netzwerk-Sicherheitsanwendungen nicht in die Selbstprüfungsebene integriert sind.

Virtualisierungs-Plattform übernimmt Antiviren-Funktionen

Das Problem kann am wirksamsten bewältigt werden, indem die Antiviren-Funktion direkt in die Virtualisierungs-Plattform integriert wird, und zwar durch die Hypervisor-Selbstprüfung, also die Fähigkeit, eingehenden und ausgehenden Datenverkehr auf der Hypervisor-Ebene zu überwachen und zu steuern. Um dieses Potenzial zu nutzen, ist die Zusammenarbeit mit Anbietern von Virtualisierungs-Plattformen erforderlich.

Wie effektiv die Malware-Erkennung in physischen Umgebungen heute auch sein mag, eine Lösung zu implementieren, die für diese Umgebungen entwickelt wurde, verursacht neue Probleme in der virtuellen Welt, da ihre spezifischen Unterschiede unberücksichtigt bleiben. Hierzu steht für Vmware-Plattformen mit »vShield Endpoint« ein passender Ansatz bereit. Mit der Konzentration auf das virtuelle Data Center hat Vmware die eigene Plattform ständig erweitert. Sie ermöglicht die Hypervisor-Selbstprüfung, die zur Optimierung von Sicherheitsfunktionen in virtualisierten Umgebungen mit Vshield Endpoint erforderlich ist. Dieser Ansatz stärkt die Sicherheit virtueller Maschinen und ihrer Hosts, während es gleichzeitig die Leistung für den Endpunktschutz um ein Vielfaches verbessert. Dazu ermöglicht diese Technik das Auslagern von Antiviren-Prozessen auf eine dedizierte, sicherheitsoptimierte virtuelle Maschine, die von Trend Micro bereitgestellt wird.

Sicherheitsprodukte belasten Speicher

Daraus ergibt sich eine Reduzierung der Speicherbelastung durch die Sicherheitsprodukte auf den virtuellen Hosts, da die Antiviren-Software auf den virtuellen Gastmaschinen entfällt und diese Sicherheitsfunktionen auf der dedizierten virtuellen Sicherheitsmaschine zentralisiert werden. Administratoren können Vshield Endpoint zentral über die Vshield Manager-Konsole verwalten, die im »vCenter Server« integriert ist, um die Plattform für Antiviren-Lösungen von Trend Micro zu verwalten.

Dazu wird Vshield Endpoint direkt in die Vsphere-Plattform integriert und auf jedem Host installiert. Die Lösung besteht aus drei Komponenten:

• Eine gehärtete virtuelle Appliance (bereitgestellt durch Trend Micro)
• Treiber für virtuelle Maschinen, um Dateiereignisse auszulagern, und
• das ESX-Modul »Endpoint SecuritV (EPSEC), um die ersten beiden Komponenten auf Hypervisor-Ebene zu verknüpfen.

Der Vshield Endpoint-Treiber unterstützt geschützte Vsphere-basierte virtuelle Maschinen und benötigt nur wenige Megabyte an Arbeitsspeicher. Der Treiber überwacht die Dateiereignisse virtueller Maschinen und benachrichtigt die Antiviren-Engine, die die entsprechenden Dateien durchsucht und eine Einschätzung der Dateiart zurückgibt. Außerdem unterstützt er zeitgesteuerte, vollständige und partielle Suchen in Dateien, die von der Antiviren-Engine in der virtuellen Sicherheits-Appliance ausgelöst werden. Gilt es eine Bedrohung zu beseitigen, können Administratoren den vorhandenen Antiviren-Manager nutzen, um die erforderlichen Aktionen festzulegen, während Vshield Endpoint die Beseitigungsaktion automatisch auf den entsprechenden virtuellen Maschinen durchsetzt.

Das Zusammenspiel von Vshield Endpoint und Deep Security löst die dringendsten Probleme – Sofortlücken und Ressourcenkonflikte. Mit Deep Security steht eine virtuelle Sicherheits-Appliance zur Verfügung, die die Antiviren-Engine beherbergt und die relevanten Aktionen ausführt. Dazu gehören das Suchen in Dateien (sei es zeitgesteuert oder beim Zugriff auf die Informationen), das Aktualisieren von Pattern-Dateien, Überprüfen der Dateiart (Test auf Malware) sowie die Anweisungen für die notwendigen Aktionen – wie das Verschieben in einen Quarantäne-Bereich oder das Löschen der Schaddatei.  Die eigentliche Durchsetzungsaktion erfolgt dann über Vshield Endpoint. Denn sie steuert die Datei-bezogenen Aktionen von Hypervisor und der jeweiligen virtuellen Gastmaschine.

Hypervisor kontrolliert internen Netzwerkverkehr

Die Kommunikation zwischen den VMs, die auf einem Host liegen, ist ein wichtiger Aspekt. Denn der Hypervisor selbst bildet den »logischen« Netzwerkverkehr ab. In diesem Bereich sind unter Umständen Eingriffe nötig. Sie finden über die entsprechenden Aufrufe an die Vmware-APIs statt. Zudem kommt der Prefilter von Trend Micro zum Einsatz. Er wird auf jedem ESX-Host installiert und dient dazu, Regularien durchzusetzen, sie zu überwachen oder eben einzuschreiten (Abbruch der Ein-Ausgabeoperation), wenn Verstöße oder Schadcode gefunden werden.

Eine weitere Aktion ist das Verschieben von VMs im laufenden Betrieb durch das Tool  »vMotion«: Hierbei müssen die Security-Einstellungen mitwandern. Damit eine umgezogene VM auf die Antiviren-Engine zugreifen kann, sind besondere Vorkehrungen nötig: Innerhalb eines ESX Clusters wird jeder ESX-Host mit einem Prefilter und einer virtuellen Appliance versehen. Das Vcenter selbst wird in Echtzeit mit dem »Deep Security Manager« verbunden, der wiederum in seinem Backend eine zentrale Datenbank hält, in der die gesamten Informationen für das Security-Netzwerk zusammengefasst sind. Tritt nun ein Vmotion-Event ein und virtuelle Maschinen mit zugewiesenem Sicherheitsprofil werden verschoben, wird der gesamte Schutz über die virtuelle Appliance durchgesetzt, die dann auf dem entsprechendem ESX Host vorhanden ist. Dabei dürfen die Appliances selber nie den Host verlassen. Damit das Ganze funktioniert ist es natürlich wichtig, dass auf jedem ESX-Host der Prefilter und die virtuelle Appliance ordnungsgemäß installiert sind.

Wenn die Demilitarisierte Zone (DMZ) und das geschützte Netzwerk als logische Konstrukte auf einem physischen Host liegen, kann Deep Security ebenfalls punkten. Denn diese Lösung kann nicht nur Verbindungen steuern (Firewalling), sondern ist in der Lage, auf Bedrohungen zu reagieren, also Schadcode beziehungsweise Angriffsmuster im Netzwerkverkehr zu erkennen. Auf einem physischen ESX-Host gilt der Schutz für jede VM, egal ob frisch erstellt oder längere Zeit online und aktiv. Der Schutz entfaltet sich auch bei der Kommunikation zwischen den VMs, wobei hier das Routing keine Rolle spielt. Normale »NIDS/NIPS« (Network Intrusion Detection Systeme und Network Intrusion Prevention Systeme) würden den auf dem Hypervisor stattfindenden Traffic normalerweise nicht sehen, es sei denn, man würde – über sehr aufwändige Wege – den Verkehr vom ESX Host über die physische Netzwerkstruktur, wieder zurück zum ESX-Host leiten. Sie sind also in der Lage den Verkehr auf schadhaften Inhalt zu untersuchen, der zwischen den VMs läuft, und lagern den Security Layer von den Systemen auf den Hypervisor aus.