Virtual Desktop Infrastructure – Möglichkeiten, Technologie, Sicherheit

Gerade die verschiedenen (alten und neuen) Client-Varianten, die für eine VDI erforderlich sind, können etwas verwirrend sein.

Der moderne Büroarbeitsplatz kommt heute nicht mehr ohne einen Arbeitsplatz-PC aus. Doch der Rechner des Mitarbeiters, egal ob Desktop-PC oder Notebook, bringt einen erheblichen Aufwand mit sich. Das gilt auch für die Sicherheit dieser Systeme. Daher wünscht sich mancher Administrator die Möglichkeit, die Clients nicht nur zentral zu verwalten, sondern auch zentral bereitzustellen und möglichst einfache Endgeräte bei den Mitarbeitern zu platzieren. Hier bietet sich eine „Virtual Desktop Infrastructure“ (VDI) an.

VDI erlaubt genau diese zentralisierte Bereitstellung von (virtuellen) Clients für die Mitarbeiter. Hersteller preisen ihre jeweilige Lösung als besonders sicher, einfach und kostengünstig an. Was wirklich dahinter steckt, wird in diesem Artikel genauer beleuchtet.

Gerade die verschiedenen (alten und neuen) Client-Varianten, die für eine VDI erforderlich sind, können etwas verwirrend sein. In diesem Artikel werden dafür die folgenden Begriffe genutzt, wie auch in Abbildung 1 dargestellt:

• Der (physische) Client bezeichnet den „klassischen“ Arbeitsplatzrechner eines Mitarbeiters.
• Der virtuelle Client ist der per Virtualisierungstechnik zentral bereitgestellte Client.
• Als Endgerät bzw. der zugreifende Client wird der physische PC oder das physische Notebook am Arbeitsplatz des Benutzers bezeichnet. In einer VDI-Umgebung wird von hier aus der virtuelle Client bedient. Der Begriff Endgerät betrifft stärker das physische Gerät, während der zugreifende Client mehr Fokus auf die Software für die Verbindung zum virtuellen Client legt.
• Der Benutzer bedient mithilfe des zugreifenden Clients den virtuellen Client.
• Der Begriff VDI umfasst die notwendigen Komponenten für die Verwaltung der virtuellen Clients und den Zugriff auf diese.

Ausgehend von einer typischen Umgebung werden die üblichen Argumente für den Einsatz von VDI und danach die technischen Grundlagen für eine solche Lösung dargestellt. Aber unabhängig von der Technik will eine solche Lösung auch vernünftig geplant und betrieben werden. Zusätzlich werden Sicherheitsaspekte beleuchtet und die Kosten betrachtet.

Ausgangslage – Warum möchte ein Administrator VDI einsetzen?

Nur noch wenige Branchen können vollständig auf IT-Systeme verzichten. Jedes Handwerksunternehmen setzt Computer ein und sei es nur zur Rechnungserstellung und Buchhaltung.

Doch ist die Anzahl der genutzten Arbeitsplatzrechner üblicherweise deutlich größer. In international tätigen Unternehmen wird die Zahl schnell fünf- oder gar sechsstellig. Und man kommt auch schon lange nicht mehr mit einem „One-size-fits-all“-Ansatz aus. In einer CAD-Abteilung wird beispielsweise eine ganz andere Leistung von den Clients erwartet als in der Buchhaltung. Software-Entwickler benötigen andere Umgebungen als der Empfang. Dadurch ergeben sich nicht nur viele Endgeräte, sondern auch viele verschiedene Client-Typen. Will man all diese Systeme zuverlässig verwalten und die Nutzer im Fehlerfall unterstützen, braucht man entsprechend ausgestattete Support-Abteilungen. Zwar lässt sich durch eine zentrale Software-Verwaltung der Aufwand reduzieren, aber spätestens wenn der Benutzer „nichts gemacht hat“ und der Client trotzdem nicht funktioniert, ist häufig doch ein Vor-Ort-Besuch notwendig.

Hier wäre eine zentrale Umgebung wünschenswert, in der man die Clients vollständig ausstatten und die Leistung flexibel festlegen kann. Wir kennen das aus dem Server-Bereich: Wenn ein neuer Server für eine vorgegebene Aufgabe benötigt wird, kann die IT diesen in wenigen Minuten bis Stunden zur Verfügung stellen. Und wenn etwas schiefgeht, kann man den Server auch wieder zurücksetzen.

Hier setzt Virtual Desktop Infrastructure an: Man verwendet diese Server-Technologien auch für Clients und gibt dem Benutzer nur noch ein möglichst einfaches Endgerät (engl. Desktop), mit dem er sich mit einem virtuellen Client über ein Firmennetz oder das Internet verbindet. Im optimalen Fall ist dies sogar so transparent und leistungsfähig, dass der User den Unterschied zu einem vollausgestatteten eigenen Endgerät gar nicht bemerkt. Aber ergibt eine solche Lösung wirklich immer Sinn? Natürlich nicht und im folgenden Abschnitt beschäftigen wir uns mit genau dieser Fragestellung.

Wo ergeben virtuelle Clients einen Sinn?

Bevor wir uns mit den technischen Grundlagen von VDI beschäftigen, soll kurz erläutert werden, in welchen Bereichen VDI sinnvoll sein kann und wo nicht. Dabei spielt ein Aspekt eine zentrale Rolle: Ich benötige eine Netzverbindung zur VDI, um auf „mein“ System zugreifen zu können.

Damit fallen einige Einsatzmöglichkeiten sofort weg:

• Bei Mitarbeitern, die viel unterwegs sind, ist VDI häufig nicht das Mittel der Wahl. Abgesehen von der eventuell suboptimalen Netzverbindung am jeweiligen Einsatzort spielt auch die geografische Entfernung der VDI eine Rolle. Je weiter weg, desto schlechter lässt sich ein virtueller Client bedienen.
• Wenn spezielle Hardware verbaut ist, zum Beispiel für die Entwicklung von IoT-Geräten, kann diese in einer VDI ebenfalls nicht einwandfrei reproduziert werden. Zwar kann man USB-Geräte wie USB-Sticks oder Kameras an den virtuellen Client weiterreichen, aber sobald man spezielle Zusatzkarten einsetzt, ist eine Nutzung von VDI ausgeschlossen.
• Wenn der Zugriff über das Internet erfolgen soll, muss auch die Internetleitung, über die zugegriffen werden soll, ausreichend dimensioniert sein. Das gilt sowohl für das Endgerät als auch für die Internetanbindung der VDI.
• Außerdem macht VDI erst ab einer bestimmten Größe der Umgebung wirklich Sinn. Wenn Sie alle Ihre Clients auf einem Server virtualisieren können und dieser immer noch zu viel Leistung hat, ist es gegebenenfalls nicht wirtschaftlich, die Clients zu virtualisieren.
  Demgegenüber steht eine ganze Reihe von Szenarien, in denen eine VDI den Betrieb extrem vereinfachen kann:
• Es existieren nur wenige verschiedene Client-Typen? Dann kann eine VDI mit wenigen Vorlagen und Gruppen den Bereitstellungsprozess von dann virtuellen Clients extrem vereinfachen.
• Ein Unternehmen arbeitet mit vielen externen Partnern zusammen, die gelegentlich Zugriff auf interne Ressourcen benötigen? Eine VDI kann schnell virtuelle Clients bereitstellen, die nur auf genau diese Ressourcen zugreifen können, ohne dass Notebooks verschickt oder größere Anpassungen an der Firewall gemacht werden müssen.
• Es gibt Systeme und Netze, in denen besonders schützenswerte Daten verarbeitet werden und auf die Clients typischerweise nicht zugreifen sollen, z. B. eine Management-Umgebung? Eine VDI ermöglicht es, solche Sprungsysteme einfach und einheitlich zu verwalten. Die zugreifenden Clients bekommen dann nur Zugang zur VDI und nicht zu den eigentlichen Systemen.
• Ein Mitarbeiter arbeitet immer wieder in verschiedenen Bereichen mit unterschiedlichen, vielleicht sogar gegenläufigen Anforderungen an die Clients? In einer VDI können einem Benutzer mehrere virtuelle Clients zur Verfügung gestellt werden.

Das klingt alles vielversprechend und es wurde schon die Nähe zur Server-Virtualisierung erwähnt. Aber wie funktioniert die Technik genau?

Technische Grundlagen einer Virtual Desktop Infrastructure

Das Kernstück der Virtual Desktop Infrastructure (VDI) ist eine Virtualisierungsumgebung, in der Clients virtualisiert werden. Dem jeweiligen Benutzer können sowohl komplette virtuelle Clients als auch einzelne Anwendungen bereitgestellt werden. Letzteres überträgt dann nur das oder die Fenster der jeweiligen Anwendung an den zugreifenden Client.

Virtualisierung ist als Technik mittlerweile über 20 Jahre alt und kann als beherrschbar gelten, daher ist dieser Ansatz naheliegend und in den oben genannten Fällen auch sinnvoll.

Es ergeben sich jedoch einige Unterschiede zur klassischen Server-Virtualisierung:

• Ein zentraler Unterschied ist, dass die virtuellen Clients nicht nur einzelne Dienste bereitstellen wie DNS oder einen Webserver, sondern dass – der Name sagt es schon – Client-Anwendungen ausgeführt werden, mit denen ein Benutzer in Echtzeit interagieren kann. Wo ein Server einen, vielleicht zwei Dienste bereitstellt, laufen auf einem virtuellen Client Dutzende von Applikationen, von einem Browser über Office-Programme bis hin zu CAD-Tools und sonstigen Spezialanwendungen. Dabei wird entweder der vollständige Desktop des virtuellen Clients oder nur eine bestimmte Anwendung auf dem zugreifenden Client sichtbar und kann so genutzt werden, als ob man direkt „vor“ dem virtuellen Client sitzt.
• Im Gegensatz zu einem virtuellen Server handelt es sich um einen Client. Dieser muss auch auf Netzebene so behandelt werden − inklusive aller Zugriffsbeschränkungen auf andere Systeme.
• Zwar gibt es je nach Branche auch bei virtuellen Servern immer wieder Lastspitzen, bei virtuellen Clients sind diese aber klarer ersichtlich: Morgens zu Beginn der Arbeitszeit werden alle Nutzer nahezu gleichzeitig versuchen, sich anzumelden und die VDI mit der zugrunde liegenden Infrastruktur aus Virtualisierungsservern und Speichern stark belasten. Ob diese Anmeldeversuche funktionieren und wie angenehm das Erlebnis für die Benutzer ist, hängt von der Dimensionierung der Umgebung ab.
• Und ein letzter Punkt, der trotz der Verbreitung von Virtualisierung eine Rolle spielen kann: Nicht jede Client-Software ist für den Einsatz in einer virtuellen Umgebung geeignet. Dies kann einerseits an besonderer Hardware liegen. Andererseits gibt es durchaus Softwarehersteller, die den Einsatz ihrer Software in einer VDI explizit untersagen oder eine andere, häufig kostenintensivere Lizenzierung verlangen.

Sind all diese Unterschiede berücksichtigt, lohnt sich ein Blick auf den Aufbau einer typischen VDI-Umgebung, inklusive des Zugriffs durch den Benutzer, wie es in Abbildung 2 dargestellt ist. Dabei sind die VDI-spezifischen Systeme rot eingefärbt, die für die Verwaltung und den Zugriff notwendig sind.

Die eigentliche Arbeit, insbesondere das Ausführen der virtuellen Clients, übernimmt eine Virtualisierungsinfrastruktur, die auf den gleichen Technologien und Prinzipien aufbaut wie eine Server-Virtualisierung.

Die eigentliche VDI wird durch zusätzliche Komponenten umgesetzt, die ggf. auch virtualisiert bereitgestellt werden können:

• Eine Management-Komponente, über die die gesamte Lösung verwaltet werden kann. Diese Komponente steuert die Bereitstellung und Verwaltung der virtuellen Clients. Dies umfasst die Erstellung von virtuellen Maschinen ebenso wie die Verwaltung von Vorlagen und die Erstellung von Snapshots. Bei vielen Produkten können mit der Management-Komponente auch die restlichen VDI-spezifischen Systeme gesteuert werden.
• Ein Zugriffssystem, über das sich der jeweilige Benutzer anmeldet. Hier erhält ein angemeldeter Benutzer eine Übersicht über die für ihn verfügbaren virtuellen Clients.
• Ein „Connection Broker“, der dafür sorgt, dass ein am Zugriffssystem angemeldeter Benutzer nur „seine“ virtuellen Clients sieht und die Verbindung zum richtigen Virtualisierungshost aufbaut.

Diese Systeme arbeiten Hand in Hand und ermöglichen ein einfaches Interface, über das Benutzer „ihren“ virtuellen Client nutzen können. Natürlich sollten alle Komponenten mit einem zentralen Benutzermanagement verknüpft sein, um dort Zugriffsrechte auf Gruppen- und Benutzerbasis festzulegen, die dann in der VDI ebenfalls genutzt und umgesetzt werden.

Damit dann auch der Benutzer den virtuellen Client so bedienen kann, wie er es von seinem (alten) Client gewöhnt ist, müssen beide Seiten mit entsprechender Software ausgestattet werden. Auf der Seite des virtuellen Clients übernimmt Software des VDI-Herstellers diese Aufgabe. Ist der VDI-Hersteller auch der Hersteller der Virtualisierungslösung, ist diese Funktionalität schon in den Gast-Werkzeugen der Virtualisierungslösung integriert und muss nur von der VDI aktiviert werden, ansonsten ist es eine zusätzliche Agentensoftware.

Das Endgerät, vor dem der Benutzer sitzt, muss ebenfalls über eine Client-Software verfügen, über die er auf die VDI-Umgebung zugreifen kann. Ein zentraler Punkt ist, dass die von der VDI-Umgebung verwendeten Protokolle unterstützt werden müssen.

Sind alle Voraussetzungen erfüllt, überträgt der virtuelle Client eine grafische Ausgabe an den zugreifenden Client und der zugreifende Client überträgt die Eingaben des Benutzers – typischerweise Tastatureingaben und Mausklicks – an den virtuellen Client. Die zugrundeliegenden Technologien und Protokolle hierfür werden schon sehr lange erfolgreich in Terminalservern eingesetzt.

Über diese Software und die zugrunde liegenden Protokolle ist es auch möglich, Peripherie oder auch Daten des zugreifenden Clients an den virtuellen Client „weiterzureichen“. Gerade in Zeiten von Corona waren das häufig die Kamera oder das Headset für Online-Konferenzen. Auch 3D-Mäuse für CAD oder sonstige per USB angeschlossene Hardware können in einer VDI abgebildet werden.

Doch das waren bisher alles Aspekte eines relativ einfachen virtuellen Clients. Was ist, wenn der Benutzer zusätzliche Leistung benötigt, insbesondere für die Darstellung von 3D-Grafiken? Auch hier bieten gängige VDIs in Kooperation mit Hardwareherstellern eine Lösung: Es gibt speziell für RZ-Umgebungen optimierte 3D-Grafikkarten, die an die virtuellen Clients angebunden werden können. Und da in vielen – aber nicht allen – Fällen ein virtueller Client nur einen Teil der Leistung des Beschleunigers benötigt, kann man diese Beschleuniger auch auf mehrere virtuelle Clients aufteilen. So können die Leistungsanforderungen mehrerer Benutzer optimal abgedeckt werden. Die Nutzung solcher Beschleuniger ist jedoch häufig mit zusätzlichen Kosten verbunden, meist pro Benutzer und Jahr.

Technisch ist der Einsatz von VDI also auf den ersten Blick unproblematisch und kann viele Vorzüge der Server-Virtualisierung in die Client-Welt bringen. Aber die Vergangenheit hat gezeigt, dass die Benutzer VDI häufig negativ bewerten. Hier spielt eine sinnvolle und umfassende Planung die entscheidende Rolle.

Planung einer VDI

Die häufig negativen Eindrücke einer VDI bei den Benutzern ist für viele Unternehmen eine Herausforderung oder sogar ein Hindernis bei der Einführung. Typische Aussagen der Benutzer sind:

• „Das ist alles viel zu langsam!“
• „Das ruckelt viel zu viel!“
• „Mit diesem lahmen Thin Client kann das ja gar nicht vernünftig funktionieren!“

All diese Aussagen spiegeln eine nicht ausreichende Leistung der VDI wider. Der „lahme Thin Client“ ist nicht das Problem. Er kann die grafische Anzeige nicht schneller darstellen als der virtuelle Client ihn liefert. Und hier gibt es verschiedene Aspekte, die die Qualität für den Benutzer einschränken können:

• Zu hohe Latenz zwischen zugreifendem und virtuellem Client
• Zu geringe Bandbreite zwischen zugreifendem und virtuellem Client
• Zu wenig zugewiesene Leistung des virtuellen Clients
• Keine ausreichenden Ressourcen auf dem zugrunde liegenden Virtualisierungsserver

Die Ursache für all diese Punkte ist in vielen Fällen eine Planung der VDI-Umgebung, die von falschen Voraussetzungen ausgeht. Abgesehen von Notfällen, wie beispielsweise die Bereitstellung von virtuellen Clients für ein Homeoffice während einer Pandemie, sind diese Schwierigkeiten vermeidbar. Dies stellt sich für die oben genannten Aspekte wie folgt dar:

Hohe Latenz

Eine hohe Latenz führt zu einer (stark) verzögerten Reaktion des virtuellen Clients auf Benutzereingaben. Dadurch leidet die wahrgenommene Leistung des virtuellen Clients, auch wenn dieser mit ausreichenden Ressourcen ausgestattet ist. Für den Benutzer fühlt sich alles zäh und langsam an. Der größte Faktor ist die geografische Distanz zwischen Endgerät und Standort der VDI-Umgebung. Aus der Projekterfahrung der ComConsult hat sich gezeigt, dass eine Entfernung von mehr als 1.000 km die Arbeitsfähigkeit der Benutzer sehr stark einschränkt. Man wird also in einem global tätigen Unternehmen niemals alle Mitarbeiter aus einem Standort mit virtuellen Clients ausstatten können.

Geringe Bandbreite

Die zu geringe Bandbreite zwischen zugreifendem Client und virtuellem Client kann natürlich auf beiden Seiten begrenzt sein. Habe ich als Benutzer nur eine sehr langsame Internetverbindung, kann ich nicht erwarten, dass ich auf dem virtuellen Client einen 4k-Film auf YouTube flüssig anschauen kann. Diese Einschränkung spielt vor allem eine Rolle, wenn der Benutzer über eine Mobilfunkverbindung Zugriff auf den virtuellen Client hat.

Es kann allerdings auch auf der anderen Seite zu Schwierigkeiten kommen: Werden viele virtuelle Clients auf einem Virtualisierungsserver ausgeführt, summieren sich die Bandbreiten aller zugreifenden Nutzer. Und unterschiedliche Nutzer haben evtl. unterschiedliche Anforderungen an die Bandbreite. Ein CAD-Designer wird beispielsweise mehr Bandbreite benötigen als ein Mitarbeiter der Verwaltung, der primär Office-Anwendungen nutzt. Hier muss im Vorfeld geplant werden, wie viele und welche Benutzer auf einem gemeinsamen Host arbeiten sollen.

Zusätzliche Anforderungen an die Bandbreite bestehen, wenn auch Video- oder Telefonkonferenzen über die virtuellen Clients durchgeführt werden sollen. Einerseits müssen alle Audio- und Videodaten der Kommunikationspartner erst zum jeweiligen Virtualisierungshost und danach zum zugreifenden Client übertragen werden. Andererseits müssen Audio- und Videosignal auch vom zugreifenden Client zum virtuellen Client zum Konferenzserver übermittelt werden. Damit ergibt sich bei einem hohen Konsolidierungsgrad oder hochauflösenden Videos ein potenzieller Flaschenhals. Zusätzliche Latenz- und Bandbreitenlimitierungen können auftreten, wenn ein Cloud-Dienst genutzt wird.

Je nachdem, wie miteinander kommuniziert wird, kann es sogar sein, dass Benutzer im gleichen Büro über ihre virtuellen Clients in einem entfernten Rechenzentrum kommunizieren und dadurch eine erhebliche Latenz entsteht. Bei Nutzung der Cloud laufen im ungünstigsten Fall alle Daten über die Internet-Anbindung des Rechenzentrums, in dem die VDI-Lösung betrieben wird. Ist die Internet-Anbindung nicht dafür dimensioniert, kann es hier ebenfalls zu einer schlechten Benutzererfahrung kommen. Die verschiedenen Kommunikationsformen sind in 3 bis 5 dargestellt.

Diese Herausforderung haben glücklicherweise auch die Anbieter von Videokonferenz- und UCC-Lösungen erkannt. Viele Anbieter stellen für VDI-Umgebungen optimierte UCC-Clients für die Endgeräte zur Verfügung, die die Audio- und Videodaten direkt zwischen den zugreifenden Clients austauschen. Damit werden die Virtualisierungshosts der VDI-Lösung sowie deren Netzwerkanbindung entlastet. Die Datenströme für eine solche Lösung sind in Abbildung 6 skizziert. Die Farben entsprechen dabei den Beispielen aus Abbildung 3 bis Abbildung 5.

Doch unterstützt nicht jeder Anbieter jede Kommunikationssoftware. Daher müssen Sie das Thema Kommunikation und VDI gewissenhaft planen:

• Ihre Mitarbeiter sind fast ausschließlich an einem zentralen Standort tätig und Ihre Internetleitung bietet ausreichende Reserven? Dann können die Medienströme einfach über die VDI-Lösung laufen.
• Sie haben viele Mitarbeiter im Homeoffice und sind an eine bestehende UCC-Lösung gebunden? Dann müssen Sie ggf. Einschränkungen bei der Auswahl der VDI-Lösung in Kauf nehmen.
• Ihre Virtualisierungslösung und der Hersteller der VDI-Lösung sind gesetzt, aber bei der Kommunikation sind Sie noch unschlüssig? Passen Sie die UCC-Lösung an die VDI-Umgebung an.

Ressourcenknappheit des virtuellen Clients oder des Virtualisierungsservers

Die häufigste Ursache für schlechte Erfahrungen der Benutzer ist die zu geringe Leistung der virtuellen Clients. Einerseits ist es heute kaum sinnvoll, einen (virtuellen oder physischen) Client mit nur 2 CPUs und 4 GB Arbeitsspeicher auszustatten. Von ihren bisherigen Clients sind die meisten Mitarbeiter mindestens 4 CPUs und 8 bis 16 GB Arbeitsspeicher gewöhnt. Dies wirkt sich signifikant auf die Arbeitsabläufe aus. Wenn auf einmal weniger Ressourcen zur Verfügung stehen, stoßen diese Abläufe schnell an ihre Grenzen. Ein typisches Beispiel: Internet-Browser mit vielen offenen Registerkarten benötigen viel Arbeitsspeicher.

Aber selbst wenn alle virtuellen Clients mit ausreichenden Ressourcen ausgestattet sind: Die Virtualisierung ermöglicht es, wesentlich mehr Ressourcen zu vergeben als die zugrunde liegende Hardware wirklich hat. Wenn dann alle Benutzer gleichzeitig versuchen, die ihnen zugewiesenen Ressourcen zu nutzen, werden alle darunter leiden. Es macht wenig Spaß, morgens Outlook zu starten und 5 Minuten warten zu müssen, bis das Fenster da ist!

Daher sollte eine Überbuchung von Ressourcen minimiert werden. Aktuelle CPUs besitzen neben ihren physischen Kernen noch logische Kerne, von Intel Hyperthreading genannt. Dadurch ergibt sich beispielsweise, dass eine CPU mit 16 physischen Kernen 32 logische Kerne bietet. Es hat sich in VDI-Projekten bewährt, pro logischer CPU eine CPU für virtuelle Clients einzuplanen. Der Arbeitsspeicher sollte ebenfalls nicht überbucht werden, da das Auslagern von Arbeitsspeicher zu enormen Leistungseinbußen führen kann.

Zusätzlich sind die Zugriffsmuster eines Clients auf Speichermedien anders als bei Servern. Daher sollte auch der Speicher für die Gesamtheit der virtuellen Clients so dimensioniert sein, dass pro virtuellem Client eine Leistung vergleichbar zu einem physischen Client ankommt. Das bedeutet mindestens einen hybriden Speicher mit SSD-Cache für die virtuellen Festplatten, besser noch All-Flash-Storage.

All diese Aspekte müssen übrigens nicht nur initial berücksichtigt, sondern auch später im Auge behalten werden. Dabei handelt es sich um klassisches Capacity Management, wie man es auch aus der Server-Virtualisierung kennt.

Wird das alles beachtet, kann VDI ein großer Erfolg werden. In einem Projekt der ComConsult hat es die gute Leistung der VDI-Umgebung sogar in den Flurfunk geschafft, sodass mehr Mitarbeiter Zugriff auf die Lösung haben wollten!

Und in dieser Situation kommt der nach der Planung zweitwichtigste Aspekt ins Spiel: Die VDI-Lösung will betrieben werden!

Betrieb einer VDI-Lösung

Wenn eine VDI-Lösung einmal eingerichtet ist und die User darauf zugreifen, fängt der interessante Teil der Arbeit an – der Betrieb. Und schon vorweg: In diesem Bereich kann eine VDI-Lösung im Gegensatz zu klassischen Clients ihre Vorteile ausspielen. Denn die Verwaltung der virtuellen Clients ist sehr viel angenehmer, effektiver und effizienter.

Wird ein neuer virtueller Client benötigt und ist noch Platz auf der Virtualisierungsumgebung, kann dieser zum Beispiel aus einer Vorlage mit wenigen Klicks und innerhalb weniger Minuten erstellt werden. Es sind meistens keine zeitaufwendigen und bürokratischen Bestellprozesse mehr notwendig. Nur wenn zusätzliche Server für die VDI benötigt werden, fällt weiterhin ein erhöhter Aufwand an!

Ein Benutzer hat neue Aufgaben, für die er mehr Leistung benötigt? Kein Problem. Dem entsprechenden virtuellen Client werden einfach zusätzliche Ressourcen zugewiesen.

Ein Benutzer meldet sich, dass sein virtueller Client nicht mehr funktioniert und er „nichts gemacht hat“? Der virtuelle Client kann wie ein Server aus einem Snapshot wiederhergestellt oder einfach gelöscht und neu eingerichtet werden. Jedoch gibt es hier eine Einschränkung: Die Daten des virtuellen Clients sollten noch an anderer Stelle, zum Beispiel auf einer zentralen Datenablage oder im Backup, vorhanden sein.

Natürlich muss man sich auch bei Nutzung einer VDI um Endgeräte und deren möglichen Ausfall kümmern. Da man sowohl die Server-Seite als auch die zugreifenden Clients betreiben muss, ist die Anzahl der Geräte auf den ersten Blick sogar größer geworden. Aber der Aufwand reduziert sich:

• Auf der Server-Seite greifen die üblichen Redundanzmechanismen: Redundante Netzteile und Netzanschlüsse, Clustermechanismen und redundanter Speicher, entweder zentral in Form einer entsprechend dimensionierten Storage-Lösung oder als verteilter Storage in der Virtualisierungsumgebung.
• Auf Client-Seite verringert sich die Anzahl der unterschiedlichen Geräteklassen und die notwendigen Ersatzteile. Im optimalen Fall kann man das defekte Endgerät eines Benutzers einfach austauschen oder den Benutzer an ein anderes freies Endgerät setzen und er kann weiterarbeiten. Das macht den Austausch schneller und minimiert die Ausfallzeiten.

Aber der zweite Punkt wird typischerweise nicht von heute auf morgen erreicht. Es gibt immer wieder Schauergeschichten, dass von oben entschieden wurde: Ab morgen machen wir VDI mit Thin Clients. Hier stellt sich gerade bei suboptimaler Planung der oben dargestellte Fall ein, dass die Benutzer sehr unglücklich sind und die Verschlechterung der Situation mit dem Endgerät assoziieren, an dem sie arbeiten: dem Thin Client.

Daher hat es sich als wesentlich sinnvoller erwiesen, eine stufenweise Migration auf neue, kleinere Endgeräte zu vollziehen. Zunächst können die Mitarbeiter ihre bisherigen Endgeräte behalten und erhalten nur zusätzliche Software, um auf die relevanten virtuellen Clients zugreifen zu können. Sobald die Mitarbeiter sich daran gewöhnt haben, können beim nächsten Austausch der Endgeräte auch kleinere Endgeräte eingesetzt werden. Die wahrgenommene Leistung ändert sich nicht. Und es müssen nicht immer Thin Clients sein. Leistungstechnisch sind viele aktuelle Thin Clients vergleichbar mit kleineren Office-PCs.

Das bedeutet zusammengefasst, dass man auf betrieblicher Ebene durch VDI einige Vorteile haben kann, diese aber in vielen Fällen nicht sofort bemerkbar sind und eine entsprechende Übergangszeit vorgesehen werden sollte.

Aber wenn wir allgemein von Clients reden, reden wir auch über das meistgenutzte Einfallstor für Angreifer. Wie sieht es also bei der Sicherheit von VDI aus? Was muss man beim Einsatz beachten? Wo ändert sich etwas?

Sicherheit einer VDI-Umgebung

Wir haben beim Betrieb die Vorteile einer VDI-Umgebung gesehen, dürfen dabei aber eine Sache nicht außer Acht lassen: Die virtuellen Clients werden im Rechenzentrum ausgeführt, in dem typischerweise nur Server betrieben werden. Dadurch ergeben sich einige sicherheitsrelevante Punkte, die unbedingt beachtet werden sollten:

• Unter der Annahme eines segmentierten Netzes müssen die virtuellen Clients im Rechenzentrum in Client-spezifischen Netzen platziert werden. Je nach Netzwerk-Architektur müssen so die Client-Netze aus dem Campus auch im Rechenzentrum verfügbar und entsprechend sicher abgetrennt sein oder es werden dedizierte Netze für die virtuellen Clients eingerichtet.
• Da mehrere virtuelle Clients auf einem Host laufen, können sich diese gegenseitig beeinflussen. Das betrifft nicht nur die Nutzung von geteilten Ressourcen, sondern auch Seitenkanalangriffe wie Spectre oder Meltdown.
• Der Zugriff auf die virtuellen Clients muss abgesichert werden. Die eigentliche Verbindung zwischen zugreifendem und virtuellem Client ist dabei meist weniger das Problem. Hier wird in den allermeisten Fällen verschlüsselt. Zusätzlich bietet die Zugriffskomponente einer VDI viele Sicherheitsfunktionen, sie kann jedoch auch zum Problem werden.

Jeder dieser Aspekte bietet noch Raum für eine Fehlkonfiguration durch die VDI-Administratoren. Wo ein voll ausgestattetes Endgerät an eine dedizierte Netzschnittstelle angeschlossen wird und die lokalen Ressourcen nicht geteilt werden müssen, kann eine Fehlkonfiguration bei VDI einem Benutzer Zugriff auf sehr sensible Daten gewähren. Das muss nicht mutwillig sein, aber Fehler passieren!

Gerade bei virtuellen Clients mit unterschiedlichem Schutzbedarf und bei virtuellen Clients für unterschiedliche Mandanten ist es daher sinnvoll, für bestimmte Client-Gruppen oder für jeden Mandanten dedizierte Virtualisierungshosts bereitzustellen. Was zunächst aufwendig klingt, ist zum Glück wie bei Servern über Regeln in der Virtualisierungsumgebung abbildbar.

Damit geht eine andere wichtige Maßnahme einher: Virtuelle Clients sollten nicht auf Virtualisierungshosts ausgeführt werden, auf denen auch virtuelle Server laufen. Das heißt insbesondere: Die auf den vorhandenen Virtualisierungshosts verfügbaren Ressourcen sollten nicht für virtuelle Clients genutzt werden, auch wenn es verlockend sein kann!

Der Zugriff auf die virtuellen Clients sollte auch gut abgesichert werden. Die Nutzung eines vorhandenen Active Directory oder einer ähnlichen Lösung und damit die Authentisierung ist kein Problem, aber gerade wenn der Zugriff auf die VDI-Lösung auch aus dem Internet gewünscht ist, ergeben sich neue Herausforderungen.

In vielen Fällen soll der Zugriff so einfach wie möglich gestaltet werden. Dazu wird die Zugriffskomponente der VDI in der DMZ positioniert und ein externer Benutzer kann sich dort mit Benutzername, Passwort und ggf. einem weiteren Faktor anmelden. Danach erhält er Zugriff auf seine virtuellen Clients. Das bedeutet, dass die Zugriffskomponente in diesem Fall die Rolle eines VPN-Gateways und der Zugriffssteuerung für die VDI übernimmt. Bei einer Schwachstelle in dieser Komponente können also beide Funktionen kompromittiert werden − so passiert Anfang 2020 bei Citrix. Die Sicherheitslücke [1] hat aufgrund der enormen Auswirkungen auch den blumigen Namen „Shitrix“ [2] bekommen. Das BSI hat zu diesem Thema ein eigenes Papier veröffentlicht [3].

Demnach sollte der Zugriff auf eine VDI-Lösung und die entsprechende Zugriffskomponente grundsätzlich nur aus einem vertrauenswürdigen, z.B. dem internen Netz möglich sein. Das bedeutet im Umkehrschluss allerdings, dass ein Benutzer von außen erst einmal eine sichere Verbindung aufbauen muss. Das ist in den meisten Fällen eine von der Zugriffskomponente unabhängige VPN-Lösung.

Diese Aspekte zeigen, dass sich bei der Nutzung einer VDI-Lösung neue spannende Sicherheitsthemen ergeben, die natürlich mit einem gewissen Aufwand verbunden sind. Aber dafür hat man auch einige Bereiche, in denen sich eine VDI-Lösung positiv auf die IT-Sicherheit auswirken kann:

• Zwar gibt es ein Risiko für Fehlkonfigurationen durch den Administrator, dafür ist die einheitliche Bereitstellung von Vorlagen einer individuellen Betrachtung der Clients vorzuziehen. Ebenso können wichtige sicherheitsrelevante Einstellungen schon in der Vorlage vorgenommen werden – dann kann der Administrator diese nicht vergessen.
• Sollte es zu einer (möglichen) Kompromittierung eines virtuellen Clients kommen, ist der Austausch deutlich schneller erledigt und der jeweilige Benutzer ist schneller wieder arbeitsfähig. Wenn regelmäßige Snapshots der virtuellen Clients erstellt werden, kann der virtuelle Client in kürzester Zeit auf einen erwiesen „sauberen“ Zustand zurückgesetzt werden. Ansonsten ist ein Löschen und erneutes Bereitstellen ebenfalls schnell erledigt.
• Viele neue Sicherheitsfunktionen aus der Welt der Server-Virtualisierung können auf die virtuellen Clients angewandt werden. Dies umfasst einerseits die Bereiche Software Defined Networking und die häufig damit verbundene Mikrosegmentierung. Auf der anderen Seite können Servertechnologien wie ECC-Speicher und Speicherverschlüsselung ebenfalls zur Absicherung des virtuellen Clients beisteuern.

Im Bereich der Sicherheit gibt es bei VDI also Licht und Schatten.

Kosten einer VDI-Lösung

Kommen wir zum letzten Punkt und zur vielleicht häufigsten Frage bei der Betrachtung von VDI: Wie viel kostet das Ganze?

Hier muss man zwischen den Werbeversprechen der Hersteller und der Realität unterscheiden. Ein großes Argument für VDI ist die Annahme, dass die Virtualisierungsserver, auf denen die virtuellen Clients ausgeführt werden, deutlich günstiger sind als die Clients, die den Benutzern sonst zur Verfügung gestellt werden müssen. Die Projekterfahrung zeigt jedoch, dass das meistens nicht der Fall ist.

Natürlich können 200 virtuelle Clients auf einem Server mit 16 CPUs und 256 GB Arbeitsspeicher ausgeführt werden. Wenn dann mehr als 30 Benutzer gleichzeitig arbeiten wollen, wird es zäh. Da sind wir wieder im Bereich der suboptimalen Planung. Hält man sich an die oben genannte Daumenregel von einer Client-CPU pro logischer Server-CPU und vermeidet eine Überbuchung des Arbeitsspeichers, ergeben sich, wenn überhaupt, nur minimale Kosteneinsparungen.

Dabei ist ebenfalls zu beachten, dass die Benutzer immer noch etwas brauchen, mit dem sie auf die VDI-Lösung und ihre virtuellen Clients zugreifen können. Zwar behaupten die Hersteller auch hier: Dann können die Mitarbeiter ja im Zweifelsfall ihre privaten Geräte für den Zugriff nutzen. Aber es ergibt sich eine ganze Reihe von neuen Schwierigkeiten:

• Die Mitarbeiter werden erwarten, dass das Unternehmen den Support für ihre privaten Geräte übernimmt. Das heißt, vom Vorteil des einfacheren Supports bleibt nicht viel übrig. Im Zweifelsfall wird der Support noch aufwendiger, da jeder Mitarbeiter ein anderes Gerät nutzen kann.
• Welche Daten der Mitarbeiter auf seinem privaten Gerät speichert, kann ebenfalls nicht streng kontrolliert werden. Es reicht schon, wenn er sich Notizen zu vertraulichen Informationen macht und dann sein Gerät kompromittiert wird.
• Viele Mitarbeiter werden nicht bereit sein, private Hardware für den Arbeitgeber zur Verfügung zu stellen.

Das heißt am Ende: Zusätzlich zum Server für die virtuellen Clients müssen doch wieder Endgeräte für die Nutzer beschafft werden. Thin Clients oder einfache Office-PCs sind zwar günstiger als vollwertige Desktop-PCs, zusammengenommen mit den Kosten für den Server relativiert sich das Ganze sehr schnell.

Bei den Stromkosten schneidet der Server jedoch meist besser ab als physische Clients. Wie groß hier der Einfluss ist, muss genau betrachtet werden.

Insgesamt ergeben sich für die Server einer VDI-Lösung für X virtuelle Clients keine großen Kostenvorteile gegenüber einer direkten Anschaffung von X physischen Clients.

Hinzu kommen noch die Lizenzierungskosten der VDI- und ggf. der Virtualisierungslösung. Meistens bezahlt man die VDI-Lösung pro zugreifendem Benutzer und pro Jahr. Kauft man Hypervisor und VDI von einem Hersteller, ergeben sich häufig Synergie-Effekte. Dann ist in den Lizenzkosten auch die Virtualisierungslösung inbegriffen. Man bewegt sich hier meistens im niedrigen dreistelligen Eurobereich pro Benutzer und Jahr.

Dabei ist zu beachten, dass dann nichts auf der Virtualisierungslösung ausgeführt werden darf außer den virtuellen Clients und den VDI-spezifischen Systemen. Will man zum Beispiel einen Dateiserver virtualisieren, muss man die Virtualisierungslösung vollständig lizenzieren.

Die Software innerhalb der virtuellen Clients kann ebenfalls mit zusätzlichen Lizenzkosten verbunden sein. Nicht jeder Betriebssystem-Hersteller erlaubt eine Nutzung in einer VDI-Lösung oder er verlangt zumindest einen Aufschlag für diese Möglichkeit. Auch die Nutzung von Beschleunigern muss, wie oben beschrieben, häufig zusätzlich bezahlt werden.

Das heißt: Bei den Kosten bietet eine sinnvoll dimensionierte VDI-Lösung inklusive Virtualisierungsinfrastruktur – wenn überhaupt – nur ein geringes Einsparpotenzial. Die Einsparungen erfolgen durch die schnellere Lösung von Supportanfragen und die schnellere Bereitstellung von virtuellen Clients.

Fazit

Virtual Desktop Infrastructure ist eine interessante Technologie, die in den letzten zwei Jahrzehnten immer wieder ausprobiert wurde und mittlerweile für viele Client-Typen durchaus sinnvoll ist, gerade bei großen Unternehmen mit externen Partnern, die Zugriff benötigen.

Allerdings wurde immer wieder gezeigt, dass nicht alle Clients virtualisiert werden können. Dabei ist in den meisten Fällen entweder Spezialhardware oder eine schlechte Netzverbindung der Stolperstein.

Sowohl die Technik als auch der Betrieb basiert auf bekannten und beherrschten Ansätzen und ermöglicht eine starke Vereinfachung der Client-Bereitstellung und des Supports, selbst für sehr ressourcenhungrige Clients.

Sicherheitsaspekte verlagern sich in Richtung der VDI-Administratoren, da diese für die sichere Vernetzung der virtuellen Clients verantwortlich sind und eine Zuordnung zwischen Client und Netzschnittstelle nicht mehr klar existiert. Hier kann man auf Technologien aus dem Server-Bereich zurückgreifen.

Bei den Kosten ändert sich leider nicht viel. Einsparungen sind in Betrieb und Support zu erwarten.

Verweise

[1] Mitre.org, CVE-2019-19781, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19781
[2] Golem.de, „Shitrix – Das Citrix-Desaster“, Januar 2020, https://www.golem.de/news/shitrix-das-citrix-desaster-2001-146047.html
[3] BSI, „Empfehlungen für den sicheren Einsatz von Application Delivery Controllern (ADC)“, Oktober 2020, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Hilfsmittel_Empfehlung_ApplicationDeliveryController_v1.html