VDI: nicht-virtuelle Probleme virtueller Maschinen und deren reale Lösungen

Die Virtualisierung tritt ihren Siegeszug über den Planeten an und zählt dabei nicht nur einzelne IT-Sicherheitsexperten und Unternehmen, in denen sie erfolgreich angewandt wird, zu ihren größten Fans, sondern auch ganze Segmente der IT-Sicherheit. Man findet heute kaum noch ein Rechenzentrum, in dem ausschließlich physische Server laufen – Strom und die physischen Plätze an sich sind heutzutage einfach zu teuer, um sie auf so uneffektive Weise zu verschleudern.

Doch die Möglichkeit, viele Server auf einem physischen Host unterzubringen, ist nur eine von zahlreichen Segnungen, die die Virtualisierung uns beschert.

Die wohl zweitwichtigste Anwendungsmöglichkeit von Virtualisierungstechnologien ist in unserer Zeit die Virtuelle Desktop Infrastruktur (Virtual Desktop Infrastructure, VDI). Während sie auf derselben Grundidee basiert, zahlreiche Computer in einem „Körper“ zu vereinen, ist sie doch für etwas vollständig anderes vorgesehen: Sie soll die Vielfalt der physischen Workstations durch eine einheitliche und einfach zu konfigurierende virtuelle Umgebung ersetzen.

Im Gegensatz zu der gewohnten – und nicht erst in den letzten zehn Jahren eingesetzten – Terminalserver-Infrastruktur, die einen verteilten Zugriff auf die Betriebssystemumgebung des Server-Hostes bietet, geht es bei der VDI um „echte“ Virtualisierung. Das bedeutet, dass jede virtuelle Workstation „eine Sache für sich“ ist, mit ihrer eigenen Auswahl an virtueller Hardware und einem eigenen Betriebssystem – und mit ihrer eigenen Auswahl an potentiellen Sicherheitsproblemen, die tatsächlich weitaus häufiger auftreten können, als bei der Server-Virtualisierung. Das ist besonders dann der Fall, wenn das Funktionsszenario den Zugriff auf das „große Internet“ vorsieht, mit allem, was dazu gehört, inklusive seiner Bedrohungslandschaft und der Armee von Cyberkriminellen, die nach dem Geld der Nutzer trachten. Und glauben Sie auch nicht nur eine Sekunde lang an den Mythos, dass virtuelle Umgebungen sicherer seien als physische. In keinster Weise – bezüglich der meisten Aspekte der Sicherheitsgewährleistung sind sie den gewohnten physischen Umgebungen überaus ähnlich – und einige ihrer Besonderheiten machen diese Aufgabe sogar noch komplizierter.

Und genau das sind die Themen dieses Blogposts: die Sicherheit von VDI, ihre Mythen und Besonderheiten und die richtige Herangehensweise, um die Sicherheit Virtueller Desktop Infrastrukturen zu gewährleisten.

VDI: Vor- und Nachteile

Vorteile von VDI-Lösungen

Bevor wir auf die Probleme von VDI zu sprechen kommen, möchten wir ein weiteres Mal aufzählen, wofür sowohl Systemadministratoren als auch IT-Sicherheitsexperten sie lieben. Also:

  • Eine VDI-Lösung ist praktisch unabhängig von Client-Hardware und Betriebssystem. Alles, was von dem Gerät gefordert wird – sei es ein gewöhnlicher Computer, ein Smartphone oder ein Notebook – ist die Fähigkeit, ein Client-Programm zu starten (und in einigen Fällen ist ein Webbrowser ausreichend).
  • Eine VDI-Lösung bietet ein wesentlich höheres Niveau an Datensicherheit: Im Prinzip werden alle wertvollen Informationen entfernt gespeichert und damit wird praktisch jedes Risiko physischer Verluste oder des Diebstahls von Daten zusammen mit dem Client-Gerät ausgeschlossen.
  • Eine VDI-Lösung gewährleistet eine flexible Verwaltung der Umgebung: Virtualisierte Workstations und Anwendungen können mit einer Leichtigkeit erstellt und verwaltete werden, die in physischen Umgebungen nicht denkbar ist. In einem gut justierten Arbeitsprozess müssen eventuell auftretende „virtuelle“ Probleme auf einer der Maschinen möglicherweise gar nicht gelöst werden; die Workstations werden mit Hilfe einer vorsorglich eingerichteten Schablone erneut erstellt, und die zentral gespeicherten Anwenderdaten sind sofort nach Start der Maschine und der Autorisierung des Clients verfügbar.

Es ist klar, dass die Liste der Vorteile, die die Nutzung einer VDI mit sich bringt, hiermit noch nicht erschöpft ist. Doch selbst das bereits Aufgeführte reicht aus, um der VDI in einigen Bereichen, in denen gleichzeitig Mobilität und die Gewährleistung der Sicherheit von Kundendaten gefordert ist, eine uneingeschränkte Existenzberechtigung zu attestierten. Typische Beispiele für solche Bereiche sind das Gesundheitswesen, Versicherungen und Bankangelegenheiten; die Möglichkeit, in diesen Bereichen hochformalisierte Arbeitsprozesse anzuwenden, erleichtert den Integrationsprozess der Virtuellen Desktop Infrastruktur.

Nachteile von VDI-Lösungen

Leider gibt es auf der ganzen Welt keine Lösung, die ausschließlich Vorteile hat. Auch die VDI hat ihre Einschränkungen und Nuancen, die unbedingt berücksichtigt werden müssen:

  • Sensibilität gegenüber dem Ressourcenverbrauch. Virtuelle Arbeitsumgebungen werden für die Erfüllung von Aufgaben benötigt, die mehr oder minder mit denen übereinstimmen, die die Nutzer gewohntermaßen auch erledigen, wenn sie normale Computer benutzen. Doch unter diesen Aufgaben gibt es – selbst wenn im Arbeitsprozess alles Überflüssige eliminiert wurde – genügend ressourcenintensive Tasks – und bekanntermaßen demotiviert den Nutzer kaum etwas mehr als eine langsame Arbeitsausrüstung. Regelmäßig auftretende „Bremsen“ sind durchaus in der Lage, die Effizienz-Vorteile, die infolge der Integration einer VDI erlangt wurden, wieder zunichte zu machen. Das bedeutet, dass man ständig alle Elemente des responsiven Funktionierens des Systems berücksichtigen muss, die Auswirkungen der Arbeit von Schutzlösungen eingeschlossen.
  • Zweckmäßigkeit der Formalisierung des Arbeitsprozesses. Eine VDI funktioniert dann am besten, wenn der Arbeitsprozess vorhersehbar ist, alle gestarteten Anwendungen bekannt sind und der Nutzer keinerlei Möglichkeit hat, diesen Zustand zu ändern. Andernfalls könnten sich alle sorgfältigen Berechnungen des Ressourcenverbrauchs als hinfällig erweisen. Zudem können Programme unbekannter Herkunft, die nicht durch Politiken eingeschränkt sind und die der Nutzer installieren und starten kann, eine Bedrohung für die Unternehmenssicherheit darstellen.
  • Hohe Anforderungen an die Schutzlösung. Im Gegensatz zu Angriffen auf Datenspeicherserver und anderen derartigen Szenarien, bei denen entfernt verfügbare Daten das Hauptziel der Attacke darstellen, sind virtuelle Workstations praktisch dem gesamten Bedrohungsspektrum ausgesetzt, unter dem auch physische Workstations zu leiden haben. Solche Bedrohungen können beispielsweise körperlose Schädlinge sein oder direkte Einschleusungen in Prozesse mit Hilfe von Exploits usw. Das bedeutet, dass die meisten bekannten Lösungen für virtuelle Umgebungen, die all ihre Nuancen berücksichtigen, jedoch nur auf Datei-Ebene Schutz bieten, keine adäquate Sicherheitslösungen für Virtuelle Desktop Infrastrukturen sein können. Selbstverständlich kann man auch eine gewöhnliche „Desktop“-Lösung installieren – die Hersteller erklären meist munter, dass diese auch virtuelle Umgebungen unterstützen würden. Tatsächlich aber führt das im besten Fall zu einem steilen Abfalls der Ressourceneffizienz der VDI. Denn jede virtuelle Maschine verfügt über eine ganze Auswahl an Engines und sich unabhängig aktualisierenden Datenbanken. Im schlimmsten Fall könnte ein „Sturm“ gleichzeitiger Scans oder Updates zu einem katastrophalen Leistungsabfall führen – oder sogar zu einer DoS-Situation.

Mythen und Bedrohungen

Auch wenn virtuelle Desktops die Funktionalität physischer Maschinen so exakt wie möglich nachbilden – sowohl in Hinblick auf die Arbeit des Nutzers als auch bezüglich der Funktionsfähigkeit des Systems selbst – hält sich unter den Anwendern hartnäckig der Irrtum, dass sie trotzdem sicherer seien als physische Umgebungen. Zur Untermauerung werden unter anderen die folgenden Argumente vorgebracht:

  1. Schädlinge wittern in einer virtuellen Umgebung eine „Sandbox“ oder die Arbeitsumgebung eines Sicherheitsforschers und verzichten darauf, sich darin auszuführen.
  2. In einer klug konfigurierten VDI stellt eine virtuelle Maschine für sich genommen keinerlei Wert dar; im Fall einer Infektion ist es das Einfachste, die Maschine zu zerstören und aus der Schablone eine neue zu erstellen.

Versuchen wir einmal herauszufinden, was tatsächlich hinter diesen Argumenten steckt, und ob es Sinn ergibt, sich bei der Organisation des VDI-Schutzes auf sie zu verlassen.

Die virtuelle Maschine als Vogelscheuche für Schädlinge?

Dieses Argument basiert auf einer zutreffenden Tatsache: Viele Schädlinge suchen tatsächlich nach Anzeichen dafür, dass sie auf einer virtuellen Maschine gestartet werden. Doch werden solche Anzeichen entdeckt, sind die Folgen keinesfalls immer dieselben. Die Schädlingsautoren wissen sehr wohl, dass es auf virtuellen Maschinen, die KEINE „Sandboxes“ oder Computer von Virenanalysten sind, durchaus wertvolle Daten zu holen gibt, und sie lernen daher einzuschätzen, wie gefährlich – oder andersherum, wie interessant – die virtuellen Maschinen für sie sind. Zu diesem Zweck gilt es eine ganze Reihe von Faktoren zu beachten: die vorher festgestellten IP-Adressen der Forschersysteme, Typennamen der Anwender und der Computer, das Fehlen von Systemkomponenten, die zur Verringerung des Ressourcenverbrauchs „beschnitten“ wurden usw. Es gibt allerdings auch fortschrittlichere Methoden: das Hinterlassen von Markern im Dateisystem der Maschine, wiederholte Verbindungssessions des Schädlings mit den Steuerungsservern (C&C), die ihre Unversehrtheit bestätigen (die Überlebensdauer von „Sandboxes“, die im automatischen Modus laufen, ist normalerweise begrenzt) usw. Ganz zu schweigen von den zielgerichteten Attacken, bei denen die Entscheidung über den weiteren Verlauf des Angriffs von lebendigen Menschen auf der Grundlage von erhaltenen Aufklärungsdaten getroffen wird.

Das Fazit ist einfach: Die Wahrscheinlichkeit, dass der Schädling seine Arbeit gar nicht erst aufnimmt, besteht, doch beim Aufbau des Sicherheitssystems für eine VDI-Lösung (bei der es obendrein wesentlich mehr Infektions-Möglichkeiten als bei virtuellen Servern gibt) darauf zu hoffen, ist ein unverzeihlicher Fehler.

Keine Maschine – keine Infektion?

Der wesentliche Fehler des zweiten Arguments besteht darin, dass es keinen Sinn ergibt, jede einzelne Infektion einer virtuellen Maschine gesondert zu betrachten. In einem typischen Fall läuft in ein und demselben Netzsegment eine Vielzahl von VMs, und greift ein Schädling eine von ihnen an – und berücksichtigt man dabei insbesondere die blitzartige Geschwindigkeit, mit der in einem virtuellen Netzwerk gearbeitet wird – , so kann sich dieses Schadprogramm äußerst schnell über das ganze Segment verbreiten. Und dabei ist es völlig unwichtig, ob die Maschine, die die Rolle des „Patienten Null“ einnimmt, rasch zerstört wird oder nicht; kreuzweise Infektionen von Maschinen können sich im Netz theoretisch unendlich fortsetzen, genauer gesagt, solange, bis das ganze Netz ausgelöscht wird, in dessen Grenzen sich der Schädling ausbreiten kann. Hinzu kommt, dass alle Spuren, die die erfolgreiche Aktivität eines Schädlings im System des „Patienten Null“ hinterlassen hat, zusammen mit dieser virtuellen Maschine verschwinden – dabei sind sie für die Untersuchung des Vorfalls von großem Nutzen!

Man sollte auch bedenken, dass moderne Schadprogramme es bestens verstehen, der Detektion auf Dateiebene zu entgehen, indem sie eine komplexe, vielschichtige Packmethode und Obfuskation anwenden. Dabei funktioniert die Mehrheit der spezialisierten Lösungen nur auf Dateiebene und verfolgt dabei nicht, was im Betriebssystem vor sich geht. Das könnte ein ausreichend großes Zeitfenster zum Diebstahl wichtiger Daten schaffen, noch bevor die virtuelle Maschine deaktiviert und gelöscht wird.

Bei Entdeckung einer Infektion ist die Möglichkeit, die infizierte VM zu zerstören bestenfalls dazu geeignet, die Wiederherstellung des Arbeitsprozesses zu erleichtern, sie wirkt sich aber in keiner Weise auf sie Sicherheit insgesamt aus.

Das komplette Bedrohungsspektrum

Es liegt auf der Hand, dass virtuelle Desktops praktisch demselben Bedrohungsspektrum ausgesetzt sind, wie physische Maschinen auch. Und was ist mit den spezialisierten Attacken – denen, die die Besonderheiten von virtuellen Umgebungen ausnutzen? Auf Konferenzen haben Forscher bereits nicht wenige Proof-of-Concept-Attacken auf virtuelle Maschinen vorgestellt, die potentiell dazu geeignet sind, großen Ärger zu verursachen. Bisher wurde jedoch noch kein einziger Fall registriert, in dem solche Attacken unter realen Bedingungen umgesetzt wurden. Doch davon darf man sich nicht blenden lassen: Was die Angreifer antreibt, ist der Bedarf. Sobald der Vormarsch virtueller Umgebungen in alle Bereiche des Lebens einen gewissen Level erreicht haben wird, könnten die konzeptionellen Attacken bald Realität werden. Und in diesem Fall haben wir es dann mit vergleichsweise massenhaften Bedrohungen zu tun. Wenn es nötig ist, ein speziell ausgewähltes, wichtiges Ziel anzugreifen – und wenn beim Auftraggeber die Mittel für eine solche komplexe Attacke vorhanden sind – können alle beliebigen bekannten und unbekannten Schadprogramme eingesetzt werden, unter anderem auch solche, die die Besonderheiten von Virtuellen Desktop Infrastrukturen als solche ausnutzen.

Doch selbst ohne die konzeptionellen Bedrohungen ist das, was es bereits gibt, mehr als genug, um den VDI und ihren Betreibern dieselben Probleme zu bescheren, die sie auch mit herkömmlichen Maschinen hätten.

VDI-Schutz: Strategie und Taktik

Es führt also kein Weg daran vorbei, VDI-Lösungen zu schützen. Wie aber geht man richtig an die Sache heran, um die Vorteile, die man durch die Einführung virtueller Desktops erlangt hat, nicht im Keim zu ersticken?

Konfiguriere sicher!

Wie wir schon seit langem wissen, ist die gefährlichste Schwachstelle jedes beliebigen Systems der Mensch. Man darf aber nicht vergessen, dass sich das nicht nur auf die normalen Durchschnittsanwender bezieht, die unbedacht auf einen Link klicken, den ihnen Unbekannte geschickt haben, sondern auch auf IT-Spezialisten, die den Cyberkriminellen bei der Konfiguration des Systems Möglichkeiten eröffnen. An welchen Schrauben sollte man also stellen, um den Angreifern das Leben so schwer wie möglich zu machen? Es folgen einige Beispiele, die theoretisch sowohl in physischen als auch in virtuellen Netzwerken anwendbar sind.

  • Mittels Domain-Policies jegliche lokale Autorisierung verbieten. Das gilt insbesondere in Umgebungen mit „Einmal“-Maschinen, die je nach Bedarf erstellt und wieder verworfen werden; es ist praktisch ausgeschlossen, dass es zu Abstürzen im Arbeitsprozess der Maschine kommt.
  • In jedem beliebigen formalisierten Arbeitsprozess sollten die Möglichkeiten, Drittanwendungen zu starten, weitestgehend eingeschränkt werden – bis hin zur Anwendung des Prinzips „standardmäßig verbieten“ (Default Deny). Bei bekannter Spezifikation der Arbeitsszenarien unter Verwendung von VDI-Lösungen, insbesondere in Bereichen wie dem Gesundheits- und dem Versicherungswesen, ist die Implementierung dieses Ansatzes überaus einfach und problemlos.
  • Java und alle Befehlsinterpreter verbieten, inklusive Powershell und sogar CMD.EXE, wenn sie für die Erfüllung irgendwelcher Aufgaben im Arbeitsprozess nicht absolut unerlässlich sind. Java ist nach wie vor eins der am häufigsten ausgenutzten Objekte, und Script-Strings finden als „legale“ (d.h. integrierte Systemmöglichkeiten nutzende) Mittel zur Umgehung von Detektionsmechanismen immer weitere Verbreitung.
  • Wenn es die Netzwerkkonfiguration erlaubt, Private VLANs (private virtuelle Netze) zu benutzen, um die virtuellen Maschinen voreinander zu isolieren. In den allermeisten Szenarien besteht keine Notwendigkeit, dass sie sich gegenseitig im Netz sehen, nur der Zugriff auf das Internet und die Server mit den Datenbanken/Backends der Unternehmensanwendungen ist notwendig. Mit Hilfe einer solchen Konfiguration lassen sich die Möglichkeiten zur Verbreitung einer Infektion wesentlich einschränken. Interessant ist, dass das in einigen Fällen von physischen Switches gefordert wird, wenn solche im Kommutationsschaltkreis vorhanden sind, der Unterstützung des PVLAN. Doch bereits jetzt gibt es im Rahmen des Paradigmas von Software Defined Networks virtuelle Switches, die dazu beitragen einen Flood von Switches zu vermeiden, die das PVLAN nicht unterstützen.

1_de

Mit Hilfe von virtuellen privaten Netzwerken kann der Netzwerkzugriff zwischen den virtuellen Maschinen eingeschränkt werden, ohne die Adress-Kapazität der IP-Subnetze auszuschöpfen. Quelle: VMware

Vielschichtiger Schutz

Unter Berücksichtigung der rasanten Entwicklung der Bedrohungslandschaft sollte der Schutz von VDI nicht hinter dem von herkömmlichen Maschinen zurückstehen, insbesondere dann nicht, wenn sie direkt mit dem Internet arbeiten.

Und das bedeutet, dass die Lösung neben dem traditionellen Signatur-basierten Schutz und auch neben dem fortschrittlichen Datei-Schutz auf der Grundlage von heuristischen Algorithmen zusätzlich mindestens über Methoden der Verhaltensanalyse und einem Schutz vor Exploits verfügen sollte. Und im Idealfall über zusätzlich proaktive Ebenen, wie etwa einer Anwendungskontrolle, einer Webkontrolle und einer Gerätekontrolle.

Standard-Ansatz

Zumeist werden für den Schutz von VDI-Lösungen gewöhnliche Schutzprogramme mit vollständigem Agenten verwendet, die ursprünglich für den Schutz von physischen Maschinen vorgesehen waren. Dieser Ansatz bringt eine Vielzahl von Problemen mit sich, und selbst wenn diese Lösungen an die Arbeit in virtuellen Umgebungen „angepasst“ sind, bleibt das Hauptproblem bestehen – der wesentlich höhere Ressourcenverbrauch.

Agentenloser Ansatz

Ein verbreiteter Typ spezialisierter Lösungen zum Schutz virtueller Umgebungen ist auf den Schutz ausschließlich von Systemen unter VMware-Produkten ausgerichtet. Für den Zugriff auf die virtuellen Maschinen verwenden sie einen „agentenlosen“ Ansatz auf der Grundlage des Mechanismus‘ VMware vShield – oder, etwas moderner, auf Basis der in VMware integrierten Netzwerk-Virtualisierungsplattform NSX. Bei dieser Variante ist eine spezielle virtuelle Schutzmaschine für den Sicherheit verantwortlich (Security Virtual Machine, SVM), die die Technologie der Plattform für den Zugriff auf die zu schützenden VM nutzt. Es ist selbstverständlich, dass ein solcher Ansatz wesentlich ökonomischer ist als der mit einem vollwertigen Agenten, da die Notwendigkeit entfällt, die Update- und Scan-Tasks zu synchronisieren – das erledigt die SVM. Die löst auch das Problem des Aktivitätssturms: Es werden ausschließlich die Datenbanken auf der SVM aktualisiert, und der Scan der Maschinen wird automatisch zeitlich aufgeteilt, um Belastungsspitzen zu vermeiden.

Für Infrastrukturen, die nur begrenzten Kontakt mit der äußeren Umgebung haben und die die Installation von Drittagenten innerhalb der Client-Maschinen nicht erlauben, z.B. in Rechenzentren, kann der agentenlose Ansatz eine sinnvolle Alternative sein. Allerdings ist es bei diesem Ansatz nicht möglich, die Prozesse im Speicher der Maschine zu kontrollieren. Das bedeutet, wenn eine VDI-Lösung verwendet wird, beispielsweise unter Horizon, Hersteller von VMware, ist ein solcher Schutz nicht ausreichend.

Ansatz unter Verwendung eines leichten Agenten

Doch es gibt auch einen neuen Typ von Lösungen, der vollständig auf virtuelle Umgebungen spezialisiert ist und den hohen Anforderungen an den Schutz einer VDI Rechnung trägt.
Ähnlich wie „agentenlose“ Lösungen wird auch bei diesem Ansatz eine separate virtuelle Maschine eingesetzt (Security Virtual Machine, SVM), dank derer die Scan- und Aktualisierungsmechanismen nicht auf jeder virtuellen Maschine synchronisiert werden müssen. Zudem gewährleisten kleine Programmagenten, die für die Kommunikation der SVM mit den Anwendermaschinen zuständig sind, auch die vollständige Kontrolle der Prozesse im Speicher und bieten so die Möglichkeit einer verhaltensbasierten Erkennung. In Lösungen, die auf diesem Prinzip fußen, können überdies auch zusätzliche Sicherheitsebenen umgesetzt werden.

In unserem Produkt, Kaspersky Security for Virtualization in der Variante mit leichtem Agenten, wurden die folgenden Features umgesetzt:

  • Schutz vor Exploits (Automatic Exploit Prevention, AEP)
  • Anwendungskontrolle, die Cloud-basierte Dynamische Weiße Programmlisten verwendet
  • Webkontrolle mit Cloud-basierter Unterstützung der Webressourcen-Kategorien
  • Gerätekontrolle
  • nIDS/nIPS (Netzwerk-basiertes Intrusion Detection System/Netzwerk-basiertes Intrusion Prevention System)
  • HIPS (Host-basiertes Intrusion Prevention System)
  • Firewall, die auf mehreren Schichten des OSI-Modells läuft, inklusive Anwendungsebene
  • Anti-Phishing mit Unterstützung des Cloud-basierten Reputationsservices und autonomer Heuristik.

(Weitere Informationen zu der Lösung Kaspersky Security for Virtualization mit Leichtem Agenten finden Sie hier.)

Die Vielfalt an Schutzfunktionen kann dazu beitragen, die im Vergleich zu Servern große Auswahl an Bedrohungen abzuwehren, der Anwender-VM ausgesetzt sind. Selbstverständlich macht jedes zusätzliche Schutzlevel zusätzliche Ressourcen erforderlich, doch durch die Auslagerung der meisten ressourcenintensiven Prozesse auf die SVM bleibt die Möglichkeit erhalten, den Agenten so leicht wie möglich zu machen.

Ebenfalls von Bedeutung ist die höhere Fehlertoleranz dieses Systems: Treten Probleme mit der SVM auf, sind die Anwender aufgrund der zusätzlichen Schutzlevel nicht völlig angreifbar; die auf jeder Workstation protokollierten Systemereignisse können lokal gespeichert und später bei der Wiederherstellung der Verbindung mit der SVM verarbeitet werden. Oder aber regelmäßig zur Verarbeitung an eine andere SVM gesendet werden, die sich im selben Netz befindet.

Dabei berücksichtigt die Lösung uneingeschränkt alle Besonderheiten virtueller Umgebungen und insbesondere die von Virtuellen Desktop Infrastrukturen, Mechanismen wie die Migration von Maschinen zwischen Hypervisoren sowie die Unterstützung von „verbundenen Klonen“. Außerdem kann man die Mini-Agenten problemlos in den Schablonen der VM erstellen, so dass man sofort nach ihrer Aktivierung geschützt ist. Die Unterstützung dieser speziellen Mechanismen durch unser Produkt Security for Virtualization mit Leichtem Agenten wurde vielfach getestet, und zwar auch unter „Kampfbedingungen“, bei der Arbeit mit den populärsten VDI-Umgebungen, wie VMware Horizon und Citrix XenDesktop.

Da die Verbindung zwischen den Agenten und der SVM unabhängig von den Mechanismen der Virtualisierungsumgebung selbst umgesetzt wird, können auch andere Plattformen neben VMware unterstützt werden, wie etwa Microsoft HyperX, Citrix und KVM, wodurch der Schutz einer heterogenen Umgebung mit Hilfe nur einer Lösung angeboten werden kann.

Fazit

Auch wenn sich der vollständige Übergang in den virtuellen Raum noch nicht vollzogen hat, so nimmt die Zahl der Szenarien, bei denen VDI-Lösungen verwendet werden, doch mit jedem Tag zu. Komplexe, ressourcenintensive Tasks, wie die Verarbeitung von Grafiken oder die Softwareentwicklung in einer virtuellen Umgebung erschienen bis vor kurzem noch Zukunftsmusik zu sein und sind heute schon Realität. Leider ist es häufig schwierig, komplexe Arbeitsprozesse in die starren Rahmen von System-Policies zu sperren, und das bedeutet, dass die Aufgabe des effektiven Schutzes von virtuellen Workstations immer wichtiger wird. Das wiederum heißt: Vielschichtige Sicherheitssysteme, die sowohl traditionelle als auch innovative, proaktive Schutzmethoden in sich vereinen, sind hier das einzig Wahre.

Ähnliche Beiträge

Schreibe einen Kommentar

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