All About Security

31.08.2011 Virtualisierung, Fachartikel

Sicherheitsbetrachtungen zur Virtualisierung bestehender IT-Umgebungen

Im vergangenen Jahrzehnt haben in einem zunehmend rasanter ablaufenden Siegeszug Virtualisierungslösungen nahezu jeden Bereich der Unternehmens-IT erobert. Waren sie zunächst auf Host-Umgebungen sowie einzelne Rechenzentren beschränkt, die Speziallösungen von Sun oder IBM einsetzten, so gibt es heute kaum ein Unternehmen, in dem sich nicht im IT-Serverbereich zumindest einige virtualisierte Rechner fänden.

Zweck des Einsatzes solcher Lösungen ist vor allem die effizientere Nutzung der Hardware sowie die höhere Flexibilität durch eine dynamische Zuweisung von Ressourcen. Im Zuge derartiger Überlegungen wird häufig eine vollständige Umstellung auf virtuelle Systeme angestrebt. Dem stehen aber durchaus berechtigte Sicherheitsbedenken entgegen. Vielen Verantwortlichen ist dabei unklar, unter welchen Umständen der Einsatz von Virtualisierungslösungen auch aus Sicherheitssicht vertretbar ist und wo nicht. Dieser Artikel soll an einem fiktiven Beispiel die notwendigen Überlegungen darstellen, die bei einem Projekt im eigenen Hause vorzunehmen sind.

Für die nachfolgende Darstellung soll eine ebenso typische wie einfache Umgebung betrachtet werden (s. Abbildung-1): Es existiert eine Gruppe von Servern normalen Schutzbedarfs, die im Rechenzentrum betrieben werden. Diese Server werden von den Anwendern aus dem Büronetz heraus genutzt. Zusätzlich gibt es eine kleinere Gruppe Server, deren Schutzbedarf erhöht ist. Sie befinden sich innerhalb eines eigenen Netzwerksegmentes mit eigenem Switch, das vom übrigen Servernetz durch geeignete Maßnahmen getrennt ist (Perimeterschutz). Innerhalb dieses Netzes erfolgt die Kommunikation zwischen den Servern unverschlüsselt. Anwender greifen auf einige dieser Server über einen dedizierten Netzwerkübergang zu, an dem eine dem Schutzbedarf der Systeme angemessene Prüfung und Filterung des Datenverkehrs erfolgt (z.B. Firewall, Application Proxy, IDS). Auf Netzwerkebene sind die freigegebenen Server ohne Beschränkungen aus dem Büronetz erreichbar, auf Anwendungsebene erfolgt die Autorisierung erst nach einer geeigneten Authentisierung. Die Administration aller Systeme erfolgt durch dedizierte Administratoren über einen dedizierten Zugangsweg (Jumphost, Administrationsnetz oder ähnliches). Ein interaktiver Login auf den Server-Systemen ist nur für die Administratoren möglich, Anwender greifen ausschließlich über Anwendungsschnittstellen zu.

 

Abbildung-1: Schematische Darstellung zu einer virtualisierten Netzwerkumgebung

Ziel ist eine möglichst weitgehende Virtualisierung dieser Serverumgebung, dabei sollen vorhandene Sicherheitskomponenten wie Firewalls und IDS jedoch als eigenständige Systeme erhalten bleiben. Im konkreten Beispiel soll als Hypervisor der ESX-Server bzw. vSphere der Firma VMware Inc. eingesetzt werden. Zur Administration des Hypervisors dient das ebenfalls von VMware stammende vCenter. Als Hardware sollen Blade-Systeme in einem entsprechenden Blade Enclosure eingesetzt werden. Die hier vorgestellte Lösungsdiskussion ist jedoch leicht auf andere Produkte übertragbar.

Methodik

Im Folgenden soll ein praktischer Ansatz vorgestellt werden, mit dessen Hilfe ermittelt werden kann, ob das Risiko einer geplanten Virtualisierung noch tragbar ist. Hierzu ist die Sicherheit der eingesetzten Techniken und Systeme abzuschätzen. Das Problem bei solchen Betrachtungen besteht darin, dass die Sicherheit eines Systems natürlich nicht nur durch die bekannten Schwachstellen und Angriffe, sondern in sehr viel stärkerem Maße durch noch nicht bekannte Angriffe bedroht ist. Die Risikobewertung muss sich also auf Prognosen stützen – und die sind ja bekanntlich besonders schwierig, wenn sie die Zukunft betreffen.

Trotzdem müssen aber natürlich Abschätzungen des Risikos gemacht werden. Eine ausschließliche Betrachtung und Bewertung der verwendeten Protokolle hinsichtlich ihrer Sicherheit hilft nur begrenzt: Natürlich lassen sich nicht alle Protokolle überall einsetzen, doch ist ein Protokoll immer nur so sicher wie seine Implementierung – und hier hat sich in der Vergangenheit gezeigt, dass nahezu kein Hersteller vor (unbeabsichtigten) Fehlern gefeit ist. Weiterhin hängt die Einsetzbarkeit eines Protokolls auch sehr stark von der Art und dem Schutzbedarf des zu schützenden Systems ab. Eine Einteilung in sichere und unsichere Protokolle ist also nicht zielführend. In der Praxis hat sich dagegen eine andere Vorgehensweise bewährt:

Zunächst sollte die Betrachtung in zwei voneinander unabhängige Bereiche aufgeteilt werden: Den maximal zu erwartenden Schaden, der sich bspw. aus dem Schutzbedarf der auf einem System vorhandenen Daten und/oder aus den maximal erreichbaren Berechtigungen ergibt und somit mit dem jeweils betrachteten System verknüpft ist, sowie der Eintrittswahrscheinlichkeit für ein derartiges Ereignis, die grundsätzlich unabhängig vom jeweiligen System ist, sondern lediglich von der eingesetzten Soft- und/oder Hardware abhängt. Das Risiko ergibt sich als Produkt aus Schaden und Eintrittswahrscheinlichkeit, dieses Risiko muss immer geringer als ein für die gesamte Informationsinfrastruktur geltendes Grenzrisiko sein. Eine bestimmte Anwendung kann somit für ein System normalen Schutzbedarfs mit einem zu erwartenden mittleren Schaden durchaus ein noch tragbares Risiko darstellen, dieselbe Anwendung (d.h. dieselbe Eintrittswahrscheinlichkeit) würde aber bei einem höher schutzbedürftigem System mit höherem maximalen Schaden zu einem nicht mehr akzeptablen Risiko führen. Ggf. kann jedoch die Eintrittswahrscheinlichkeit durch zusätzliche Maßnahmen (z.B. Beschränkung der zugreifenden Benutzergruppe durch netzwerkseitige Zugriffsbeschränkungen, Prüfung der übermittelten Daten, Prüfung auf Protokollebene durch geeignete Proxies oder Intrusion Detection-Systeme u.v.a.m.) so weit reduziert werden, dass die Anwendung hinter entsprechenden Schutzeinrichtungen sehr wohl betrieben werden kann..

<< Erste < Vorherige 1 2 3 4 Nächste > Letzte >>

Diesen Artikel empfehlen

Autor: Dr. Torsten Johr, GAI NetConsult