Virtualisierung ohne Grenzen auch bei hohem Schutzbedarf?

Kommentieren Drucken

In modernen IT-Infrastrukturen geht nichts mehr ohne Virtualisierung von Netzen, Servern, Clients und Anwendungen. Dabei wird immer häufiger eine maximale Konsolidierung angestrebt, was in der Praxis letztendlich bedeuten würde, dass Systeme unterschiedlichsten Sicherheitsniveaus auf einer gemeinsamen Infrastruktur betrieben werden. Dies könnten beispielsweise VMs einer Internet DMZ und Datenbanken für hochkritische Unternehmensdaten sein, die zusammen auf einer Server-Farm laufen („Data Center in a Box“). Das andere Extrem sind Lösungen für BYOD, wo durch verschlüsselte Sandboxes sichere Laufzeitumgebungen für Unternehmens-Apps auf privaten Endgeräten geschaffen werden sollen. Egal um welche Technik und Anwendungsform es sich handelt, letztendlich geht es immer um die Realisierung einer möglichst wasserdichten logischen Trennung von Systemen auf einer gemeinsamen Hardwarebasis.

Dieses Thema hat der Informationssicherheit schon immer massive Sorgen bereitet, denn die Sicherheit einer logischen Trennung steht und fällt nun einmal mit Qualität der Sandbox (oder wie immer der Trennungsmechanismus bezeichnet wird). Der GAU ist dabei ein z.B. durch einen Implementierungsfehler ermöglichter Ausbruch aus der Sandbox in Verbindung mit schadenstiftenden Zugriffen.

Typische Formulierungen in Sicherheitsrichtlinien bzw. -konzepten versuchen daher der ungezügelten Virtualisierung und Sandbox-Nutzung Grenzen zu setzen: „Komponenten mit erheblich unterschiedlichem Sicherheitsniveau müssen auf getrennten Systemen realisiert werden.“ Nur wird es immer schwerer hier auch eine physikalische Trennung durchzusetzen. Notgedrungen wird die Informationssicherheit weich und lässt unter gewissen Rahmenbedingungen Virtualisierung ohne Grenzen zu.

Ein passendes Beispiel findet sich in den BSI IT-Grundschutz-Katalogen im Baustein B 3.304 Virtualisierung in Maßnahme M 5.153 „Planung des Netzes für virtuelle Infrastrukturen“. Hier heißt es:

„Wurden vor der Virtualisierung Netze aufgrund unterschiedlichen Schutzbedarfs physikalisch getrennt, müssen diese Netze auch in virtuellen Umgebungen voneinander isoliert werden. Es ist dann zu prüfen, ob die Mechanismen zur Netztrennung, sowie der Kapselung und Isolation der virtuellen IT-Systeme in der eingesetzten Virtualisierungslösung ausreichen, um virtuelle IT-Systeme mit hohem Schutzbedarf gemeinsam mit solchen niedrigen Schutzbedarfs auf einem Virtualisierungsserver betreiben zu können.

Die spannende Frage ist nun, wie eine solche Prüfung aussehen kann. Die eben zitierte Maßnahme sagt hierzu:

„Diese Prüfung kann z. B. darin bestehen, dass der Hersteller der betreffenden Virtualisierungslösung die genannten Mechanismen für diesen Einsatzzweck (Trennung von Maschinen unterschiedlichen Schutzbedarfs) als geeignet bezeichnet und dies durch eine entsprechende Zertifizierung nachweist.“

Wenn es ein allgemein anerkanntes Bewertungs- und Prüfschema gäbe, das eine Virtualisierungs- oder Sandboxing-Lösung hinsichtlich eines angestrebten Sicherheitsniveaus einordnen kann, das spezifische Sicherheitsanforderungen insbesondere an das Sandboxing stellt und eine Auditierung nach allen Regeln der Kunst inklusive Zertifizierung ermöglichen würde, wären wir einen Schritt weiter.

Nun gibt es ja seit geraumer Zeit die Zertifizierung nach Common Criteria (CC) und diverse IT-Systeme sind auf Basis verschiedener Schutzprofile (Protection Profiles) für unterschiedliche Vertrauenswürdigkeitsstufen (Evaluation Assurance Level, EAL) zertifiziert.

Beispielsweise hat VMware vSphere 5.0 seit Mai 2012 ein CC-Zertifikat mit EAL4+, was für IT-Komponenten eine durchaus hohe Stufe darstellt. Nur wurde als Prüfbasis das Protection Profile für Betriebssysteme in einer Netzwerkumgebung zu Grunde gelegt. Nun ja, die betrachtete Virtualisierungsplattform hat eine ganze Menge Ähnlichkeiten zu einem Betriebssystem, nur beinhaltet das angewendete Protection Profile beispielsweise keine Anforderungen hinsichtlich der Sicherheit der Kapselung und Isolation der virtuellen IT-Systeme. In der Spezifikation für die Prüfung von vSphere 5.0 wurden daher zusätzliche Anforderungen aufgenommen und im Rahmen der Zertifizierung getestet. Da es noch kein Protection Profile gibt, das spezifisch für Virtualisierungslösungen ist, gab es auch keine Alternative.

Nur was bedeutet dann ein solches Zertifikat? Dürften wir jetzt VMs mit unterschiedlichstem Sicherheitsniveau (vielleicht sogar interne VMs und Internet-DMZ-VMs, die permanent Angriffsversuchen ausgesetzt sind) auf einer Hardware betreiben? Solange keine strengen, dediziert für Virtualisierungslösungen entwickelten Schutzprofile vorliegen, ist die Antwort ein klares Nein.

Trotzdem ist dies besser als nichts und die Forderung nach einem CC-Zertifikat (möglichst natürlich EAL4+) bleibt auch bei Verwendung des Protection Profile für Betriebssysteme ein essentieller Bestandteil des Anforderungskatalogs für eine Ausschreibung. Nebenbei bemerkt: Wäre auch Java zertifiziert gewesen, hätte es vielleicht den GAU vom August dieses Jahres nicht gegeben, als dank einer Schwachstelle in Java ein effektiver Ausbruch aus der Sandbox demonstriert werden konnte. (Siehe z.B. http://www.heise.de/security/artikel/Java-0-Day-unter-der-Lupe-1676764.html)

Es bleibt daher bis auf weiteres, dass bei erheblich unterschiedlichem Sicherheitsniveau (was im Einzelfall individuell festzulegen ist) eine physikalische Trennung notwendig ist, und die Informationssicherheit sollte hier der Forderung nach Virtualisierung ohne Grenzen Widerstand leisten.

zugeordnete Kategorien: IT-Sicherheit
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.