Wer eine Virtual-Desktop-Infrastructure (VDI) einsetzen möchte, muss das bisherige Sicherheitsmodell ändern. Die Grundidee dabei lautet: Alle meine Nachbarn sind mir feindlich gesinnt, ich darf mich nicht darauf verlassen, dass jemand für mich die Sicherheitsprobleme abdeckt.

Der Erfolgszug der Virtual-Desktop-Infrastructure (VDI) wird von den Einsparmöglichkeiten dieser Technologie angetrieben. Der Umstieg auf »Windows 7« auf den Desktop-Systemen hat zur Folge, dass viele Unternehmen sich neue Hardware anschaffen und damit gleich auf den aktuellen Betriebssystem-Sprössling von Microsoft umsteigen. Allerdings kommen auch Konzepte ins Spiel, die die Desktops zentral auf einem Server ablaufen lassen und die alte Client-Hardware verwenden, um diese Arbeitsumgebungen – Betriebssystem wie auch Applikationen – für den Benutzer bereitzustellen – also auf eine VDI-Konfiguration setzen.

Damit lassen sich die Hardware-Ressourcen weiter verwenden und zudem bekommen Unternehmen mehr Flexibilität als bei traditionellen Lösungen mit Terminalserver. Dieser Ansatz eignet sich gut, wenn weitgehend standardisierte Applikationen für die Mitarbeiter bereitgestellt werden müssen.

IT-Sicherheit bei VDI-Ansätzen

Allerdings gibt die aktuelle Bedrohungslage durch Malware Anlass zur Sorge. »Wir bekommen rein rechnerisch alle 1,5 Sekunden eine neue Variante von Schadsoftware, für die wir Abwehrmaßnahmen bereitstellen sollen«, gibt Udo Schneider, Solution Architect bei Trend Micro, zu Protokoll. Dabei gilt das Web als der wichtigste Kanal, über den die Bedrohungen in die Unternehmen gelangen: Ganze 90 Prozent der Malware wird darüber verteilt. »Was uns ebenfalls Kopfzerbrechen bereitet«, so Schneider, »ist das schnelle Ausnützen der Sicherheitslücken: 74 Prozent der Angriffe erfolgen am selben Tag, an dem der Patch für die Lücke bereitsteht.« Daher sei das möglichst aktuelle Einspielen von Patches das Gebot der Stunde.

In diesem Kontext sieht der Sicherheitsspezialist einige grundlegende Problempunkte: »Die konventionellen Sicherheitskonzepte im IT-Bereich haben sich über die Zeit entwickelt. Dabei wird um die eigenen Systeme ein Schutzwall gezogen – Perimeter –, indem Module wie Firewalls, Intrusion-Detection und Prevention-Systeme sowie Log-Systeme zum Einsatz kommen. Doch dieses Konzept deckt bei einer VDI nicht mehr alles ab«, erklärt Schneider. Denn es befinden sich bei einer VDI auf dem physischen Server, der die Desktops beherbergt, mehrere virtuelle Maschinen (VMs). Sie verfügen über ein eigenes Gastbetriebssystem und die gewünschten Applikationen – mit all ihren Angriffsflächen. Das hat zur Folge, dass alle VMs auf einem möglichst aktuellen Patch-Level stehen müssen.

Zum anderen bringt die Netzwerkarchitektur Probleme mit sich: Wenn die VMs auf einem physischen Host miteinander kommunizieren, laufen die Datenpakete nicht über die physische Schnittstelle, sondern sie werden im Kernel des Hypervisors zwischen den VMs verteilt. Damit bekommen externe Systeme wie eine Firewall oder ein IDS (Intrusion-Detection-System) von diesem Netzwerkverkehr gar nichts mit und können nicht kontrollierend eingreifen. Wenn nun ein System in einer VM infiziert ist und andere VMs auf demselben physischen Server infiziert, dann sehen die für Sicherheit zuständigen Systeme diese Angriffsmuster nicht.

Nicht aktive VMs brauchen beim Start schnelle Updates

Ein weiteres Problem taucht im Umgang mit den VMs auf: »Wird ein virtuelles System nicht mehr benötigt, friert es der Administrator ein, bis er es wieder braucht. In der Zwischenzeit können an dem System in der angehaltenen VM keine Aktionen wie etwa automatische Updates ausgeführt werden«, führt Schneider aus. Damit ergibt sich eine weitere Sicherheitslücke. Wird die VM zu einem späteren Zeitpunkt neu gestartet, fehlen die aktuellen Patches. Anders ausgedrückt: Der Sicherheitsstatus liegt auf dem Level wie beim Herunterfahren. Wenn man das Timing von Lücke und Exploit ansieht, wird einem die Bedrohung schnell klar. »Aktuelle Studien zeigen«, verrät Schneider, »wenn ich heute einen frischen PC ans Internet anschließe, dann dauert es im Schnitt nur 19 Sekunden, bis der erste versucht, das System zu entern«.

Auf eine VM bezogen, sieht die Bedrohung bei einem konstruierten Beispiel wie folgt aus: Ein Template für eine VM wird zum Zeitpunkt X erstellt. Zwei Monate später wird dann dieses Template verwendet, um zum Beispiel ein virtuelles System mit einem Webserver aufzusetzen. Dann dauert es nach dem Erstellen der VM und ihrem Start erst eine Zeit, bis alle relevanten Patches heruntergeladen sind, die in den zwei Monaten angefallen sind. In der Regel erfolgen die ersten Angriffe auf das System schneller als das Herunterladen und Installieren der Patches.

Aber auch angestammte Vorgehensweisen sind bei einem VDI-Einsatz zu überdenken. Eine gängige Praxis in einem normalen Desktop-Umfeld sieht vor, dass zum Beispiel an jedem Dienstag um 12:00 Uhr – wenn die Mitarbeiter beim Mittagessen sind – ein kompletter Scan des Dateisystems gefahren wird. Diese Richtlinie führt bei einer VDI zu einer enormen Belastung des physischen Servers, der die VMs mit den virtuellen Desktops beherbergt. Denn die Systemlast auf dem physischen Server entspricht der akkumulierten Systemlast aller Desktops. Daher muss man versuchen, parallele Aufgaben möglichst intelligent zu serialisieren.

Beim Verschieben von VMs muss Sicherheit mitziehen

In einem VDI-Ansatz ist das Verschieben von VMs mit Tools wie der »Live Migration« oder »VMotion« auf freie Ressourcen eine gängige Praxis. Sie wird herangezogen, um eine möglichst effiziente Auslastung der physischen Ressourcen zu erzielen. Dabei wird nach den verschiedensten Kriterien das Umziehen von VMs erfolgen: Dazu gehören zum Beispiel die Stromkosten von Rechenzentren – das ist aus betriebswirtschaftlicher Sicht extrem interessant.

Doch das kann sich sehr schnell auch als problematisch erweisen: Wenn die Sicherheitsfunktionen implizit für die VMs konfiguriert sind, können sie auf einem anderen physischen Host ganz anders ausgeprägt sein.

Virtualisierungs-Hersteller nehmen Sicherheit ernst

Vor diesem Szenario ist es sehr wichtig, dass die Hersteller der Virtualisierungs-Plattformen für diese Aspekte sensibilisiert sind. Vor allem VMware zieht hier mit, aber auch die Schnittstellen von Microsofts Hyper-V und von Citrix Xenserver sind in diese Richtung ausgelegt. VMware bringt für seine Lösung »vSphere 4« eine Programmierschnittstelle (API) mit, um in die Funktionsweise des Hypervisors eingreifen zu können. Es wird für die Hersteller von Security-Lösungen möglich, Erweiterungen einzubauen, so dass man zum Beispiel mit einer VM sehen kann, welche Netzwerkpakete an andere VMs geschickt werden.

Somit lassen sich lokale Agenten auf VM erstellen, die Funktionen wie Firewalling etc. aufweisen. Zudem können derartige Aufgaben auch von einer Virtual-Appliance übernommen werden, die den Datenverkehr überwacht – etwa wenn kein Agent eingesetzt werden kann oder es für bestimmte Gastbetriebssysteme keine Agenten gibt.

Virtual-Patching bringt Luft

Eine weitere Lösung kommt mit dem »Virtual Patching« ins Spiel: Werden Applikationen in einer VM betrieben und sind für sie neue Sicherheitslücken (in der Applikation selbst oder der zugehörigen Middleware) bekannt, gibt es dafür meistens recht schnell einen Patch. Doch viele Administratoren haben dann ein Problem mit dem Wartungsfenster: Wenn ein Patch verfügbar ist, darf er ihn nicht sofort einspielen, denn bei einem Produktionssystem ist das oftmals nicht sinnvoll: Daher wurden spezielle Wartungsfenster definiert, wie zum Beispiel samstags zwischen 2 und 3 Uhr morgens.

Doch dann stellt sich die Frage, was man in der Zwischenzeit machen soll. Hier hilft das Virtual-Patching: Es unterbindet die Lücken, die bei Angriffen über Netzwerk-Verbindungen ausgenützt werden. Erkennt das System ein entsprechendes Angriffsmuster, wird die Kommunikation unterbrochen. Damit bekommt man als Administrator etwas Luft bis zum Wartungsfenster.