Sicherheit in virtuellen Umgebungen
Gegen den Wolkenbruch
Dank Virtualisierung können IT-Infrastrukturen eine ungeahnte Dynamik und Flexibilität erlangen. Dies bringt aber nicht nur Vorteile wie eine schnellere Anpassung an sich ändernde Anforderungen im Unternehmen mit sich, sondern auch eine wesentlich höhere Komplexität, zum Beispiel durch zusätzliche Komponenten wie Hypervisoren und durch ständig veränderte Konfigurationen. Anders als bei realen Servern kann ein Administrator virtuelle Server ebenso einfach erzeugen wie verschwinden lassen. All das muss Konsequenzen für das Sicherheitskonzept haben.
Die virtuelle IT ist längst real. Schon 2008 gingen die Marktforscher von IDC davon aus, dass
mit 52 Prozent die Mehrheit aller gekauften Server virtualisiert werden würde. Genauso real wie die
virtuellen Server sind aber auch die neuen Sicherheitsrisiken, die sich ein Unternehmen mit der
Virtualisierung einhandelt.
Es ist ein Irrglaube, dass virtuelle Systeme die Sicherheit erhöhen, weil die Konfiguration
virtueller Netzwerke ja nur die Kommunikation bestimmter virtueller Maschinen miteinander erlaube
und die Zugriffe auf die virtuellen Speicherressourcen eingeschränkt sei. Vielmehr entstehen durch
die neue Virtualisierungs-Middleware zusätzliche Angriffsziele für geschickte Hacker und neue
Schwachstellen, die es gegen Angriffe wie "Guest Hopping" oder Hypervisor-Attacken zu schützen
gilt.
Wachsende Vielfalt
Mit der Zahl der (virtuellen) Server wächst die Komplexität der IT-Infrastruktur ebenso wie
durch die neue Dynamik im Provisioning sowie die Heterogenität der eingesetzten
Virtualisierungstechniken. Diese können von den Hardwareherstellern wie HP, IBM, Fujitsu oder Sun
stammen oder von Softwarehäusern wie VMware, Citrix, Microsoft, Red Hat, Novell oder Oracle.
Virtualisierung heißt auch: Die mit dem Server-Betriebssystem oder dem Hypervisor mitgelieferten
Sicherheitsfunktionen reichen nicht aus. Die IT-Verantwortlichen stehen vor einer echten
Herausforderung.
Virtualisierung bedingt also eine zusätzliche Lösung für das Zugriffs-Management, die Lücken im
Zusammenspiel der Sicherheitsmechanismen von Hypervisor und Gastbetriebssystem schließt und dafür
sorgt, dass auch die Rechte der Administratoren restriktiv ausgelegt sind und sich nicht vom
Hypervisor auf die Gäste vererben. Die virtualisierten Server drohen mangels angemessener
Sicherheitskontrollen zum "Wilden Westen" der IT-Welt zu werden, wenn die Sicherheit zugunsten
einer raschen Bereitstellung vernachlässigt wird. Dabei gilt: Virtuelle Server sind nicht per se
sicherer oder unsicherer als reale Server – sie sind einfach nur anders und erfordern daher auch
andere – zusätzliche -Sicherheitsmaßnahmen. Weil auch die virtuellen Gäste auf der Hardware nach
wie vor leistungsstarke Server sind, bleiben die bewährten Sicherheitsmechanismen wie Firewall,
Benutzerberechtigungen, Auditing, Logging oder Antiviren-Scans auch für sie unverzichtbar.
Manch eine sicherheitsrelevante Aufgabe bekommt aber in der virtuellen Welt eine neue Dimension,
zum Beispiel das Patch-Management. Denn in der Praxis finden sich immer wieder "verwaiste"
virtuelle Server, die zwar produktiv genutzt werden, aber in den Inventarlisten der
Systemadministratoren nicht mehr auftauchen oder für die klassische Software Delivery und das
Roll-out der Patches unerreichbar sind. Weil in diesen Fällen sicherheitsrelevante Fehler nicht
behoben sind, sind die Server einfacher angreifbar.
Es gibt zudem spezifische Attacken auf virtuelle Server, zum Beispiel Guest Hopping oder
Hypervisor-Attacken. Beim Guest Hopping versucht der Hacker zwei virtuelle Maschinen ausfindig zu
machen, die auf der identischen Hardware residieren. Wenn er Zugang zu einer dieser Maschinen hat,
versucht er desgleichen die andere zu penetrieren, auch wenn er auf direktem Wege keinen Zugang zu
ihr erlangen könnte. Publizierte Guest -Hopping-Angriffe sind zwar noch selten, dürften aber mit
zunehmender Virtualisierung häufiger werden. Hypervisor-Attacken richten sich gegen das
Basisbetriebssystem, das den Betrieb der virtuellen Server-Säste ermöglicht. Der Hypervisor hat
nicht nur direkten Zugriff auf die gesamte Hardware des IT-Systems, sondern vermittelt auch den
Zugang der virtuellen Server zu dieser Hardware und ermöglicht die Kommunikation der Server
untereinander. Wird der Hypervisor geknackt, ist die Wahrscheinlichkeit hoch, dass der Hacker auch
jeden seiner Gäste gefährden kann.
Das Risiko solcher Hypervisor-Attacken wird etwas dadurch gesenkt, dass ein Hypervisor schon aus
Performance-Gründen ein funktional sehr stark eingeschränktes Betriebssystem ist, was den wirksamen
Schutz sehr vereinfacht. Andererseits bildet ein Hypervisor gerade wegen seiner Kontrolle über die
gesamte Hardware ein attraktives Ziel speziell für "Denial of Service"-Attacken, denn wenn er zum
Absturz gebracht wird, folgen ihm unmittelbar all seine Gäste.
Einer der bisher bekannt gewordenen Angriffe ist das "Subvirt Virtual Machine Based Rootkit"
(VMBR). 2006 als Machbarkeitsstudie entwickelt, sorgte Subvirt VMBR für viel Wirbel, wird es doch
zwischen Hardware und das eigentliche Betriebssystem eingeschoben, das dann als Gastbetriebssystem
auf Subvirt läuft. Subvirt ist nicht nur sehr schwer zu entdecken, sondern kann auch beträchtlichen
Schaden anrichten. Bisher sind aber noch keine realen Subvirt-Angriffe bekannt geworden, vielleicht
auch, weil für das Einschleusen Administratorrechte notwendig sind.
Strikte Zugangskontrolle
Schon aus diesem Grunde sollte ein Unternehmen den Zugang zu jeder Hypervisor-Engine strikt
einschränken und kontrollieren. Zulässig sein sollten nur die absolut notwendigen administrativen
Arbeiten. Eine weitere dringend zu empfehlende Sicherheitsmaßnahme ist die Einschränkung des
Hypervisors auf das unbedingt erforderliche Funktionsspektrum; dies verringert die Angriffsfläche
ebenso wie den Schaden im Fall der Fälle. Beispielsweise lässt sich VMware ESX auch ohne Web-Server
installieren – oder Microsofts Hyper-V nur mit dem Kern von Windows Server 2008 statt mit dem
vollständigen Betriebssystem.
Zugang zum Hypervisor sollten nur privilegierte User erhalten, typischerweise die IT- oder
Netzwerkadministratoren, die für die Performance und Verfügbarkeit der Server-Farm zuständig sind.
Sie bekommen dafür Privilegien, die weit über die üblichen Rechte von IT-Nutzern hinausgehen, weil
sie zum Beispiel die Konfiguration des Servers ändern dürfen. Deshalb gefährdet es die
IT-Sicherheit eines Unternehmens, wenn ein solcher Super-User Fehler macht oder seine Rechte
missbraucht.
Vermeiden kann das nur der konsequente Dreisatz "Kontrollieren, Protokollieren und Auditieren".
Nach diesem Motto sollten Unternehmen ihre IT nicht nur vor unkontrollierten Zugriffen normaler
Anwender oder gar böswilliger Hacker schützen. Auch und gerade privilegierte User aus der IT gilt
es in diesen Kontrollmechanismus zu integrieren. Es geht vor allem darum, die meist vorhandenen und
durchaus funktionierenden Lösungen für ein Identity- and Access-Management (IAM) um spezielle
Features für das Privileged-User-Management (PUM) zu erweitern.
Das Hauptproblem liegt darin, die konkreten Zugangsberechtigungen manuell für eine rasch
wachsende Zahl von Servern einzurichten und zu pflegen. Dieser enorme Aufwand verführt dazu, allen
privilegierten Usern das Root-Passwort und damit die Berechtigung zu jeder Aktivität auf dem System
zu geben. So bekommen die meisten privilegierten Anwender nicht nur Rechte, die sie gar nicht
benötigen: Der inflationäre Gebrauch des Root-Passworts hält manches Unternehmen auch davon ab,
dieses zu ändern – wegen der Befürchtung, einen privilegierten Benutzer versehentlich nicht darüber
zu informieren und somit wichtige Aufgaben zu behindern. Je mehr Personen aber ein Passwort kennen
und je seltener es geändert wird, desto höher ist die Gefahr des Ausspähens.
Ein anderes Problem inflationär verbreiteter Root-Passwörter liegt darin, dass es im Fall eines
Datenmissbrauchs den unter Verdacht geratenen Systemadministratoren schwer fallen dürfte, ihre
Unschuld zu beweisen. Schon ein simples Check-in-/Check-out-System hilft hier nachzuvollziehen,
welcher Systemadministrator wann aktiv gewesen ist. Aber nur ein PUM-System kontrolliert und
dokumentiert, welcher privilegierte Benutzer wann aktiv war.
Lesen Sie mehr zum Thema
