Thought Leadership
Virtualisierung ist eines der Hypewörter dieses Jahres, wenngleich die grundlegenen Idenn alles andere als neu sind. Bei Mainframes gab es solche Techniken bereits vor vielen Jahres. Schon damals wurden mehrere nur virtuell existierende Systeme mit eigenem Betriebssystem auf einer gemeinsam genutzten Hardware abgebildet.
Auch in anderen Bereichen gibt es ähnliche Konzepte schon sehr lange. Man denke nur an virtuelle LANs auf Netzwerk-Switches. Entsprechend gibt es auch bei der Betrachtung der IT-Sicherheit von Virtualisierungssystemen viele Parallelen zu bekannten Problemen und etablierten Lösungsansätzen. Nur wird die Einführung von ESX-Servern, Xen, Sun LDoms oder auch Microsofts Hyper-V leider oft als Infrastruktur-Projekt betrachtet, bei dem entweder gar nicht oder erst viel zu spät an IT-Sicherheit gedacht wird.
Immer wenn eine neue IT-Technik imUnternehmen eingeführt wird, kann sie positive oder auch negative Auswirkungen auf die IT- Sicherheit haben. Wenn man Meldungen zur Virtualisierung und IT-Sicherheit verfolgt, so stößt man immer wieder auf Advisories über teilweise dramatische neu entdeckte Verwundbarkeiten. Die Bewertung dieser Verwundbarkeiten erfordert jedoch eine individuelle und differenzierte Betrachtung.
Bedrohungsszenario: Angriff aus demGast-System
In einer typischen virtualisierten Umgebung laufen mehrere Gast-Betriebssysteme auf einemgemeinsamen Host, der virtuelle Maschinen über einen Hypervisor abbildet. Der Host und die zugehörigen Verwaltungskomponenten sind dabei für normale Anwender meist gar nicht sichtbar und sowohl ein Anwender als auch ein Angreifer sollten zumindest ohne Login auf einem Gast-System nicht unterscheiden können, ob ein Dienst auf einem physisch eigenständigen Server oder auf einer virtuellen Maschine angeboten wird.
Das von Technikern am häufigsten diskutierte und sicherlich dramatischste Bedrohungsszenario ist der Angriff auf die Virtualisierungssoftware aus einem bereits kompromittiertenGast-System. ImExtremfall kann dieser Angriff zu einem Ausbruch aus der Virtuellen Maschine und schließlich zu einer direkten Kompromittierung aller anderen Gäste auf dem gleichen Host sowie des Hosts selbst
führen.
Vorfälle dieser Art sind nicht nur theoretisch denkbar. Bei fast allen bekannten Virtualisierungsprodukten sind bereits Schwachstellen bekannt geworden, die es ermöglicht haben, aus einer virtuellen Maschine auszubrechen. Dabei sollte man jedoch beachten, dass solche Angriffe nie der erste Schritt sind. Das hier beschriebene Risiko kann erst als Folgeangriff relevant werden, wenn ein Angreifer bereits in eines der Gastsysteme eingebrochen ist.
Ein direkter Angriff aus demNetz auf die Verwaltungskomponenten oder den Hypervisor ist kein naheliegendes Szenario, sofern nicht bei der Konzeption und Implementierung grobe Fehler gemacht wurden. Aber hier beginnt das Problembereits. Solange keine verbindlichen Richtlinien in den Firmen etabliert sind, muss man davon ausgehen, dass solche Fehler in der Hektik und im Kostendruck laufender Projekte gemacht werden.
Aspekte für die Risikoanalyse
Einer der wichtigsten Aspekte für eine konzeptionelle Betrachtung und für eine Risikoanalyse ist die Qualität der Trennung virtueller Maschinen auf einem gemeinsamen Host untereinander. Diese ist nicht so stark wie die Trennung physisch eigenständiger Server. Andererseits ist die Trennung von Applikationen, die im klassischen Sinne auf ein und demselben Server laufen, schwächer, als die Trennung von Applikationen, die auf verschiedenen virtuellen Maschinen laufen.
Ein Sicherheitsexperte wird immer bestrebt sein, eine Anwendung, die beispielsweise auf einem öffentlichen Server direkt aus dem Internet erreichbar ist, nicht ohne zwingenden Grund zu engmit einer zweiten internen Applikation zu koppeln, die vertrauliche Daten verarbeitet. Zwischen den Netzwerkbereichen der beiden Applikationen sind in der Praxismeist Firewalls vorhanden und beide Systeme sollten auch nicht auf einem gemeinsamen Host ablaufen. Wenn beide Applikationen sich einen normalen Server teilen und nicht einmal durch eigene virtuelle Maschinen getrennt wären, wäre das Sicherheitsniveau natürlich noch geringer.
Die Argumente und die Herangehensweise bei der Konzeption sind übrigens nahezu die gleichen, wie sie schon seit Jahren bei der Definition beziehungsweise Bildung von Firewall-Zonen und der Verteilung von Filterund Proxy-Komponenten angewendet werden. In den meisten Fällen sollten daher auch existierende Netzwerk- beziehungsweise Zonengrenzen nicht mit übergreifenden Virtualisierungs-Hosts überbrückt werden. Systeme, die bisher durch Firewalls voneinander getrennt werden, sollten in der Regel auch auf getrennten Virtualisierungs-Hosts ablaufen. Existierende Firewall-Strukturen sollten bei der Einführung von Virtualisierung nicht ohne ausführliche Risikoanalysen in Frage gestellt werden.
Intrusion Detection Systeme
Etwas anders verhält es sich mit Sicherheitssystemen wie Intrusion Detection (IDS) und Intrusion Protection Systemen (IPS). Diese Komponentenmüssen den Datenverkehr innerhalb von Netzwerkzonen mitlesen können.Wenn diese Kommunikation jedoch nur innerhalb der Gastsysteme auf einem gemeinsamen Host stattfindet, dann wird man Probleme bekommen, eine existierende IPS-Appliance weiter zu verwenden, da der Datenverkehr bevorzugt über einen virtuellen Switch im Host geleitet wird und außerhalb des Hosts nicht sichtbar ist. Hier ist deshalb eine Änderung der bisherigen Infrastruktur unumgänglich. Die Lösung besteht typischerweise darin, anstelle der existierenden IPS-Appliances neue virtuelle Appliances einzusetzen, die selbst auch virtualisiert sind.
In Diskussionen über die Sicherheit von Virtualisierungstechniken sollte man sich weder von den möglichen Problemen,Horrorszenarien und Listen mit bekannten Schwachstellen leiten lassen, noch die Angriffsszenarien als reine Theorie abtun. In jeder IT-Infrastruktur gibt es Risiken und Sicherheitsschwachstellen. Die entscheidende Frage ist, welche dieser Risiken für das eigene Unternehmen akzeptabel sind und welche Risiken nicht mehr tragbar sind. Dafür ist eine individuelle Betrachtung notwendig.
Richtlinien festlegen
Um derartige Diskussionen nicht monatlich neu führen zu müssen ist es äußerst wichtig, die eigenen Rahmenbedingungen und Regeln in einer Richtlinie festzuhalten, die dann für künftige Vorhaben gilt. Während Sicherheitsrichtlinien für Remote-Zugänge, Anbindung von Partnerfirmen und ähnliche Themen in den meisten Unternehmen etabliert sind, fehlen Sicherheitsrichtlinien für den Einsatz von Virtualisierung sehr häufig. Die Basis für solche Richtlinien können einerseits „Best Practices“ sein oder auch individuelle Bedrohungs- und Risikoanalysen, aus denen Schutzmaßnahmen beziehungsweise Vorgaben für Strukturen hergeleitet werden können. Ein wichtiger Aspekt in einer solchen Richtlinie ist beispielsweise die Frage, welche Gast-Systeme auf einemgemeinsamen Host-System laufen dürfen und welche nicht. Eine grundsätzliche Erwägung bei der Konzeption von IT-Strukturen unter Sicherheitsaspekten ist immer schon die Trennung von Systemen, die nicht zueinander passen. Dies beginnt bei der Konzeption der Netzwerksegmente und bei der Frage, welche Applikationen oder Systeme im gleichen Netzsegment stehen sollen und welche durch Firewalls voneinander getrennt werden müssen. Ebenso betrifft es die Kombination von Applikationen auf gemeinsamen Servern oder die Kombination virtuellerMaschinen auf gemeinsamen Host-Systemen.
Ein weiterer wichtiger Aspekt für die Entwicklung von Sicherheitsrichtlinien bei der Virtualisierung sind mögliche Härtungsmaßnahmen. Dabei geht es nicht umdieHärtung der Gast-Systeme, denn dafür sollten bereits etablierte Härtungsrichtlinien je Betriebssystem existieren, sondern umdie Härtung der Virtualisierungsplattform beziehungsweise der Management-Komponente. Bei fast allen Virtualisierungslösungen gibt es zahlreiche Einstellungsmöglichkeiten, die das Verhalten der virtuellen Switches oder generell die mögliche Kommunikation der Gäste untereinander betreffen. Ebenso können fast immer physische Interfaces in ihrer Verwendung für Gast-Systeme oder für die Management-Kommunikation reserviert werden. Alle diese Bereiche sollten unter Sicherheitsgesichtspunkten betrachtet werden. Die nötigen Einstellungen, die sich dabei ergeben, sollten dann in einer Richtlinie verbindlich vorgegeben werden.
Virtualisierung und Sicherheit
Man darf Virtualisierung nicht nur als neue Bedrohung betrachten. An der richtigen Stelle eingesetzt kann auch die IT-Sicherheit von Virtualisierungstechniken profitieren. Dies ist beispielsweise dann der Fall, wenn verschiedene Applikationen, die bisher ohne Virtualisierung auf einem gemeinsamen physischen Server und Betriebssystem installiert waren, auf getrennte virtuelle Server verteilt werden können. Damit kann man die Trennung dieser Systeme verstärken und dadurch auch das Sicherheitsniveau erhöhen, auch wenn es hier ein Restrisiko gibt, dass die Virtualisierungslösung selbst angreifbar ist.
Wenn man über Virtualisierung und Sicherheit spricht, kommt man an der Diskussion über spezielle Sicherheitsfeatures wie VMSafe von VMWare nicht herum. Dabei bieten die Hersteller der Virtualisierungslösung Schnittstellen an,mit denen Sicherheitsprodukte nicht nur als Gast-Systeme virtualisiert werden, sondern auch in den Hypervisor selbst eingreifen können. Da der Hypervisor oder die Management-Komponente der Virtualisierungslösung nahezu uneingeschränkten Zugriff auf alle virtuellen Maschinen besitzen, hat man auf dieser Ebene beste Voraussetzungen, um die Vorgänge und Zustände innerhalb virtueller Maschinen zu überwachen. Eine denkbare Anwendung ist ein Virenscanner, der alle Gäste einesHosts nach Viren und Trojanern durchsuchen kann, ohne in den Gastsystemen selbst installiert werden zu müssen. Dazu greift der Virenscanner über Schnittstellen wie VMSafe direkt auf die Internas der Gastsysteme zu.
Risiken gibt es immer
Leider gibt es auch diese zunächst sehr elegant klingende Funktion nicht ohne Risiken. Die Vergangenheit hat gezeigt, dass auch Sicherheitskomponenten wie Virenscanner oder IDS-Produkte selbst angreifbar sind. Meistens waren Fehler beim Auspacken von Archivdateien die Ursache des Problems. Durch geschickt manipulierteDateien konnte der Virenscanner bei der Analyse der Datei kompromittiert werden.Wenn man sich dies bei einem Virenscanner vorstellt, der quasi Superuser-Rechte über alle Gastsysteme auf dem betroffenen Host besitzt, dann wird klar, dass man hier ein sehr hohes Schadenspotential betrachtet.
Der Hypervisor ist ein kritisches Element für die Sicherheit einer Virtualisierungsumgebung. Je mehr Zusatzfunktionen in den Hypervisor eingeklinkt werden und je komplexer dieVerwaltung der virtuellen Maschinen wird, umso größer wird die Eintrittswahrscheinlichkeit für ein Sicherheitsproblem. Wenn gleichzeitig immer mehr wichtige Systeme als virtuelle Maschinen auf gemeinsamen Hosts ablaufen, dann erhöht sich auch die mögliche Schadenshöhe und diesen Trend sollte man nicht ohne sorgfältige Betrachtung der resultierenden Risiken hinnehmen.
Stefan Strobel
Diesen Artikel finden Sie auch in der Ausgabe 7/8 Juli/August der it management.
