14.05.2012, 17:00 Uhr
Zeitbombe Virtualisierung
Virtualisierung ist die Basistechnologie der Cloud. Die Vorteile überzeugen. Aber Vorsicht: Mit dem neuen Virtualisierungslayer holen sich Schweizer Unternehmen auch zusätzliche Sicherheitsrisiken ins Haus.
Vorsicht: Mit dem neuen Virtualisierungslayer holen sich Unternehmen auch zusätzliche Sicherheitsrisiken ins Haus.
Die Schweiz virtualisiert heftig und übernimmt damit eine Vorreiterrolle. Zu überzeugend sind die Vorteile der Virtualisierung, als dass man es sich leisten könnte, abseits zu stehen. Zuvorderst locken eine flexiblere IT und eine effizientere Auslastung der physikalischen Ressourcen, sprich fallende IT-Kosten. Mit einer Marktdurchdringung von 82 Prozent ist Servervirtualisierung in der Schweiz mittlerweile De-Facto-Standard. Etwas vorsichtiger gehen Schweizer Unternehmen die Virtualisierung ihrer Speicherlandschaften und Netzwerke an. 38 respektive 34 Prozent setzen dort bereits Virtualisierungstechnologie ein. Zu diesen Ergebnissen kamen die Marktforscher von IDC, die branchenübergreifend 146 Schweizer Unternehmen mit mehr als 100 Mitarbeitern befragten (Computerworld.ch berichtete). Unbestritten sind die Vorteile der Virtualisierung, die Risiken jedoch kehren Technologieanbieter gerne unter den Teppich. Da wäre zunächst einmal der zusätzliche Virtualisierungslayer – er macht den Software-Stack komplexer und das IT-Management anspruchsvoller, mithin auch fehleranfälliger. Das klingt banal, ist es aber nicht. Die Datenretter von Kroll Ontrack, die immer dann gerufen werden, wenn das Kind bereits in den Brunnen gefallen ist, können ein Lied davon singen, und machen folgende Rechnung: In traditionellen Systemen (ohne Virtualisierung) haben Datenverluste zu 74 Prozent technische und zu 26 Prozent menschliche Ursachen. In virtualisierten Systemen kehrt sich das Verhältnis um: Dort sind Datenverluste zu 35 Prozent auf technische Probleme und zu 65 Prozent auf menschliches Fehlverhalten zurückzuführen (Kroll Ontrack: Statistik 2011). In virtualisierten Systemen avanciert der Mensch zur Gefahrenquelle Nummer eins. Lesen Sie auf der nächsten Seite: Super-GAU in Liechtenstein
Super-GAU in Liechtenstein
Holger Engelland von Kroll Ontrack berichtet von einer Beinahe-Katastrophe, die gerade noch einmal einen guten Ausgang nahm. Ein Liechtensteiner Treuhänder wollte sein Virtual Machine File System (VMFS), also das komplette Datenmanagement, von einem alten auf einen neuen VMware-ESX-Server migrieren. Die Migration schlug fehl, das alte VMFS war auf dem neuen ESX-Server nicht mountfähig, verweigerte also die Zusammenarbeit. Zudem wies das Backup Lücken auf. Es drohte der Totalverlust von Rechnungsdaten, die Kunden aus dem Finanzsektor dem Liechtensteiner Treuhänder übergeben hatten. Kroll Ontrack konnte den Super-GAU gerade noch einmal abwenden. Von Katastrophen solcher Art erzählt natürlich niemand gern. Die grösste Gefahr auf dem Virtualisierungslayer gehe von Bedienungsfehlern und falschen Konfigurationen aus, bestätigt auch Stephan Bohnengel, Specialist Systems Engineer beim Virtualisierungsmarktführer VMware. Aber nicht nur nachlässig arbeitende, schlecht ausgebildete Mitarbeiter können Schweizer Unternehmen gefährlich werden. Gefahr ist auch im Verzug, wenn die Systemingenieure der Konkurrenz zu clever sind. Sicherheitsexperten sprechen dann von sogenannten Cloudburst-Attacken, gemeint ist Folgendes: Die Basiseinheit der oberen Virtualisierungslayer ist die Virtuelle Maschine (VM), die wie eine Sandbox die Kunden eines Public-Cloud-Service-Anbieters voneinander trennt. Alle Kunden teilen sich zwar die Infrastruktur-ressourcen des Anbieters, fahren aber ihre eigenen Virtuellen Maschinen (Multi-Tenancy). Ein Cloudburst-Angreifer könnte nun versuchen, durch gezielte Systemaufrufe dem abgeschotteten Gefängnis seiner eigenen VM zu entkommen, um sich zum Beispiel Zugriff auf die Memory-Bereiche anderer Kunden respektive VMs zu verschaffen (memory corruption). Das heisst konkret: Im ungünstigsten Fall liest die Konkurrenz Ihre Unternehmensinterna mit. Lesen Sie auf der nächsten Seite: VMware: 591 Schwachstellen
VMware: 591 Schwachstellen
Die Chancen für solche Hacks scheinen auf den ersten Blick nicht schlecht zu stehen. Punkto VMware-Technologie hat René Bersier, Systems Consultant bei IBM Schweiz, einen klaren Trend zu mehr Unsicherheit ausgemacht. Bersier befragte die «Vulnerabilities Database» des National Institute of Standards and Technology (NST). Im Dezember 2010 verzeichnete die Risikodatenbank des NST für VMware 542 Sicherheitslücken. Ein halbes Jahr später im Juni waren es 586, zum Jahresende im Dezember 2011 bereits 591 sogenannte «Vulnerabilities». Nach Bersier wird VMware-Technologie also immer unsicherer. Er rät deshalb, möglichst per Hardware-Bare-Metal-Hypervisor zu virtualisieren. Denn für IBMs PowerVM-Server konnte das NST laut Bersier keine einzige Sicherheitslücke ausfindig machen. (Betreibern von Intel-x86er-Infrastrukturen wird dieser Tipp jedoch kaum weiterhelfen: IBMs Virtualisierungstechnologie läuft dort nicht.) Gemeinsam mit dem Bundesamt für Sicherheit in der Informationstechnik haben Cisco, EMC und VMware die eigenen Virtualisierungslösungen auf den Prüfstand gestellt. Die Sicherheitsstudie dekliniert insgesamt 32 Gefährdungsszenarien durch. An erster Stelle steht die bereits erwähnte Cloudburst-Attacke, auch «Virtual Machine Escape» genannt. Ein Kunde bricht aus seiner VM aus und erlangt privilegierten Zugriff auf ein fremdes Gastsystem oder sogar auf den Hypervisor, also den Virtualisierungslayer selbst. Denkbar wäre auch, dass ein Angreifer ein bereits kompromittiertes Gastsystem als Einstiegsluke nutzt.
Intels x86-Schutzring
Ein Kinderspiel ist eine Cloudburst-Attacke jedoch keineswegs. VMware benutzt das von Intel eingeführte x86-Ringmodell, das vier Schutzstufen zur Ausführung von x86-CPU-Befehlen enthält. Lediglich der Ring 0 hat vollen Zugriff auf alle Host-Betriebssystemressourcen. Applikationen und Gastbetriebssysteme, die auf nachgeordneten Ringen laufen, dürfen nur beschränkt zugreifen. VMware zieht daraus den Schluss: «Ein gegenseitiges Auslesen von Speicher der VMs ist aufgrund des Designs der CPU- Instruction-Set-Virtualisierung nicht möglich. Es können grundsätzlich auch keine Buffer-Overflow-Attacken gegen den VMkernel gefahren werden.» Gleichwohl sei es unerlässlich, das Herz von VMwares Virtualisierungslösung, den ESX Hypervisor, privilegiert zu patchen, also mit Sicherheits-Updates gegen Angriffe zu härten. Cloudburst-Attacken sind sehr komplex, das Risiko ist zwar existent, in der Praxis aber wohl eher als gering einzuschätzen. Ausserdem können Schweizer Unternehmen dem Risiko Mensch und dem Risiko Virtuelle Maschine einen Riegel vorschieben, in dem sie ihr IT-Personal kompetent schulen und konsequentes Patching praktizieren. Eine dritte Gefahr aber beginnt sich heute erst abzuzeichnen: der Kampf um die virtuelle Vorherrschaft in der Cloud, mit unangenehmen Konsequenzen für die Kunden. Lesen Sie auf der nächsten Seite: 5-Schritte-Strategie
5-Schritte-Strategie
Nach Jason Nolet, Vice President beim Speichernetzwerkspezialisten Brocade, müssen Schweizer Unternehmen auf dem Weg in die Cloud fünf Etappen zurücklegen: Das Fundament bildet die Servervirtualisierung (82% der Schweizer machen das bereits), dann folgen Skalierung und Automatisierung, die Private Cloud (inklusive etwa Load Balancing und IT as a Service), die hybride Mix-Cloud und schliesslich die Public Cloud. Nolet präsentierte auf dem Brocade Executive Forum in Frankfurt das attraktive Konzept der «clouds over distance». Der Business Case: Unternehmen lagern im laufenden Betrieb ihre Virtuellen Maschinen auf die Infrastrukturressourcen von Public-Cloud-Serviceanbietern aus, wenn sie dort punkto Performance und Kosten besser bedient werden. Erhöht der Cloud-Anbieter die Preise oder hält Service Level Agreements nicht ein, zieht der Kunde seine VMs wieder zurück auf unternehmensinterne Ressourcen oder sucht sich einen Alternativanbieter. «Clouds over distance» gestatte, so Nolet, ein effizientes Pooling von Ressourcen über die Grenzen mehrerer Rechenzentren hinweg. Die dafür nötige Technologie, mit der Unternehmen ihre VMs im laufenden Betrieb «live» migrieren können, stellte VMware im Herbst letzten Jahres auf der VMworld in Kopenhagen vor. Die Schlüsselkomponenten heissen vMotion und vCloud Connector. Eine Live-Demo in Kopenhagen zeigte, dass die Migration funktioniert, wenn auch nicht ganz ohne Eigenarbeit. Die Krux an der Sache ist nur: Virtuelle Maschinen lassen sich nur dann von on-premise in die
Public Cloud und vice versa migrieren, wenn auf beiden Seiten des Migrationspfads VMware-Technologie läuft. Das migrierende Unternehmen und der Public-Cloud-Serviceanbieter müssen also VMware-Kunden sein. Lesen Sie auf der nächsten Seite: Cloud ohne Grenzen
Public Cloud und vice versa migrieren, wenn auf beiden Seiten des Migrationspfads VMware-Technologie läuft. Das migrierende Unternehmen und der Public-Cloud-Serviceanbieter müssen also VMware-Kunden sein. Lesen Sie auf der nächsten Seite: Cloud ohne Grenzen
Cloud ohne Grenzen
Demgegenüber propagiert Scott Crenshaw, Vice President des Open-Source-Anbieters Red Hat, das Konzept einer offenen Cloud ohne Grenzen. Crenshaw sieht keinen Sinn darin, unternehmensinterne Silos, die man gerade mühsam überwunden hat, in der Public Cloud wieder zu errichten. Eine Schlüsselrolle spielt dabei Red Hats Software-Stack, der unter anderem auch CloudForms enthält, eine Plattform zum Management von offenen, hybriden Clouds. Jedes Layer des Stacks, so Crenshaw zu Computerworld, lasse sich durch die Lösungen von Fremdanbietern ersetzen. Zu den Layern zählen unter anderem Red Hat Enterprise Linux als Betriebssystem, Red Hat Storage, Enterprise Virtualization und CloudForms Hybrid Cloud Management. Mit der Entwicklungsumgebung DeltaCloud API, Bestandteil von CloudForms, liessen sich Software-Treiber für die gängigen Public-Cloud-Serviceanbieter in maximal zwei Tagen programmieren. Das DeltaCloud API ist seit etwa einem Jahr auf dem Markt und wird von Unternehmen wie NTT, Fujitsu und Amazon eingesetzt.
Red Hats Architektur einer offenen Cloud ohne Grenzen besticht, Kunden vermeiden damit den berüchtigten Vendors Lock-in. Das Konzept hat nur einen Haken: Es funktioniert bislang nur auf dem Infrastruktur-Level, also für Server und Storage aus der Cloud. Virtuelle Maschinen im laufenden Betrieb «live» migrieren kann man damit noch nicht.
Red Hats Architektur einer offenen Cloud ohne Grenzen besticht, Kunden vermeiden damit den berüchtigten Vendors Lock-in. Das Konzept hat nur einen Haken: Es funktioniert bislang nur auf dem Infrastruktur-Level, also für Server und Storage aus der Cloud. Virtuelle Maschinen im laufenden Betrieb «live» migrieren kann man damit noch nicht.