Sicherheitsaspekte der Desktop-Virtualisierung

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Essen
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Dipl-Inf._(FH)_Christian_Schäfer
Typ: Fallstudienarbeit
Themengebiet: Desktop Virtualisierung
Autor(en): Julia Borkes, Anne Urbisch, Nico Baumann, Christopher Stegmann
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS11
Studiensemester: 2
Bearbeitungsstatus: Bearbeitung abgeschlossen
Prüfungstermin:
Abgabetermin:


Inhaltsverzeichnis

1 Einleitung

Die Virtualisierung von Desktops oder anderen Komponenten beschäftigt die IT-Branche zurzeit mehr denn je. Doch wie kommt dieses gesteigerte Interesse zustande? Steigender Wettbewerbsdruck der mit dem Wirtschaftsaufschwung einhergeht führt dazu, dass IT-Fachleute gezwungen sind anfallende Kosten zu reduzieren und administrative Tätigkeiten wirtschaftlicher zu gestalten. Neue Anforderungen mit denen sich Unternehmen in Zeiten der Globalisierung konfrontiert sehen verlangen auch Administratoren und anderen IT-Fachleuten ab flexibel auf ständige Veränderungen zu reagieren. Zudem führt der Klimawandel dazu, dass vermehrt die Forderung nach „Green-IT“, also ökonomisch arbeitenden Systemen, die Ressourcen sparen und damit die Umwelt schonen und somit auch das Image eines Unternehmens verbessern, vorgebracht wird. Virtualisierung ermöglicht es, Ressourcen je nach Bedarf zu verteilen und überwindet somit die Schwierigkeiten physischer Systeme, die bei unerwarteten Ereignissen und den damit einhergehenden Anforderungen häufig an ihre Grenzen stoßen. Ein weiteres Argument für die Virtualisierung ist die immer größer werdende Abhängigkeit von der IT in die sich Unternehmen begeben. Deshalb müssen Serverumgebungen und Firmennetzwerke ausfallsicher gestaltet sein, auch dies ermöglicht die Virtualisierung. Die logische Konsequenz dieser Entwicklungen ist es, dass die Virtualisierung an Bedeutung gewinnt und neben dem Cloud-Computing Fachleute und Generalisten gleichermaßen beschäftigt, zumal die dafür erforderliche Technik inzwischen zu erschwinglichen Preisen erhältlich ist.

Ziel dieser Fallstudie des 2. Semesters an der FOM Essen ist es, das Thema Desktop-Virtualisierung unter dem Aspekt der Sicherheit zu betrachten. Um einen Einstieg ins Thema zu finden werden wir uns zunächst mit einigen Grundlagen beschäftigen. Anschließend werden Server und Clients (unterteilt in Fat Clients und Thin Clients) hinsichtlich ihrer Sicherheit überprüft und bewertet.

2 Grundlagen

2.1 Virtualisierung

Bei der Virtualisierung wird ein Computer, der die Rolle des Hosts übernimmt, in mehrere voneinander unabhängige Partitionen aufgeteilt, die keinen oder nur begrenzten Einfluss aufeinander haben. Hierdurch können verfügbare Ressourcen optimal verteilt und ausgenutzt werden. Virtualisiert werden können nicht nur Prozessoren (typischer Fall), sondern auch z.B. Festplatten (Partitionierung) oder Netzwerke (VLAN). Außerdem ermöglicht es die Virtualisierung verschiedene Umgebungen zu schaffen, in denen unterschiedliche Betriebssysteme laufen (z.B, Linux und Windows, oder Windows 7 und XP). Dies ermöglicht wiederum Software zu betreiben die sehr unterschiedliche Anforderungen hat.

2.1.1 Servervirtualisierung

Die Virtualisierung von Servern ist eine weit verbreitete Technik im Rahmen der Virtualisierung. Sie bietet Unternehmen die Möglichkeit mehrere Server auf einem Host zu betreiben und somit Geld und Ressourcen zu sparen. Bei der Umsetzung stehen Unternehmen verschiedene Techniken zur Auswahl:

Komplettvirtualisierung

Bei der Komplettvirtualisierung wird jedem virtuellen Server ein festgelegtes Volumen der Hardware des hostenden Systems zugewiesen, so dass der Server sich für den alleinigen Besitzer /Nutzer der Hardware hält. Dadurch müssen die Virtuelle Maschinen nicht an den Host angepasst werden und es können viele unterschiedliche virtuelle Maschinen gleichzeitig gehostet werden. Diese Vorgehensweise kostet jedoch Systemleistung (Virtualisierungsschwund 2-25%). Es wird zwischen Hosted- und Hypervisorprodukten unterschieden. Hosted-Systeme benötigen ein auf der Hardware installiertes Betriebssystem (z.B. Windows 2003 Server), Hypervisor-Produkte (Standardfall, z.B. Citrix XenServer) setzen direkt auf der Hardware auf. Diese muss allerdings vom Hypervisor unterstützt werden.

Paravirtualisierung

Bei der Paravirtualisierung weiß die virtuelle Maschine, dass sie nicht der alleinige Nutzer der Hardware ist. Hierzu wird der Kernel der virtuellen Maschinen so angepasst, dass er direkt mit der virtuellen Hardware kommuniziert. Dadurch muss die Hardware nur einmal für alle virtuellen Maschinen virtualisiert werden. Auch die verbrauchte Systemleistung fällt deutlich geringer aus, sie liegt bei 0,1-5%. Die virtuellen Maschinen sind, durch ihr Wissen eine virtuelle Maschine zu sein, sehr flexibel und können sogar im laufenden Betrieb angepasst werden. Updates der virtuellen Maschine können jedoch Auswirkungen auf den Host und andersrum haben.

Betriebssystemvirtualisierung

Nicht die Hardware, sondern das vorhandene Betriebssystem wird partitioniert. Somit werden den virtuellen Maschinen nur die individuellen Änderungen mitgegeben, alle Einstellungen und Betriebssystemdaten die gleich sind werden nicht virtualisiert und kommen von der statischen Hardware. Hierbei wird nur sehr wenig Systemleistung und Speicherplatz benötigt und es ist möglich sehr viele virtuelle Maschinen auf einem physischen Server zu betreiben. Außerdem die virtuelle Maschine bei dieser Art der Virtualisierung sehr schnell. Die virtuellen Maschinen sind jedoch sehr abhängig vom Host, weshalb nur gleichartige virtuelle Maschinen auf einem Host betrieben werden können und Updates des Hosts einen starken Einfluss auf sie haben.

Vor- und Nachteile der Servervirtualisierung

Das Virtualisieren von Servern bietet sich besonders für Unternehmen an, die eine Vielzahl verschiedener Server benötigen. Die bekanntesten Anbieter von Virtualisierungslösungen sind VMware, Microsoft und Citrix. Die Servervirtualisierung bildet auch die Grundlage fürs Cloud-Computing.

Pro Kontra
kostengünstig, da weniger Hardware benötigt wird kostet unter Umständen viel Systemleistung
flexibel, da Hardware je nach Bedarf aufgeteilt werden kann fatale Folgen bei Hardwareausfall, deshalb redundante Systeme empfehlenswert
einfaches Backup möglicherweise Skalierungsprobleme
ideal als Test- oder Entwicklungsumgebung
schnelle Verfügbarkeit neuer virtueller Server

2.1.2 Anwendungsvirtualisierung

Bei der Virtualisierung von Anwendungen wird auf einem Computer eine virtuelle Umgebung erzeugt in der eine Anwendung unabhängig vom Betriebssystem und den anderen Komponenten des Computers ausgeführt wird. Dies ermöglicht es dem Anwender Software zu nutzen, die auf seinem Computer nicht ausführbar wäre, zum Beispiel kann er eine Mac Anwendung nutzen, obwohl ein Microsoft-Betriebssystem auf seinem PC installiert ist. Auch ältere Software kann ähnlich wie bei der Emulation genutzt werden. Die Anwendungsvirtualisierung benötigt einen Fat Client, also einen physischen Computer mit eigenen Ressourcen. Voraussetzung für die für die Virtualisierung von Anwendungen (und von kompletten Desktops) ist das Vorhandensein eines Terminalservers, der die Verwaltung der Anwendungen übernimmt und per RDP die Ein- und Ausgabe weiterleitet.


Pro Kontra
geringer Administrativer Aufwand, da Updates und Installationen an zentraler Stelle durchgeführt werden können lokale Datenspeicherung stellt weiterhin Risikofaktor da
werden Anwendungen nicht ständig benötigt können mit Hilfe von concurrent Lizenzen Kosten gespart werden wird mit steigender anzahl der User komplexer
Anwendungen die auf Standard-PCs des Unternehmens nicht laufen (weil anderes Betriebssystem oder Systemvoraussetzungen benötigt werden) können trotzdem ausgeführt werden aufwändige Lizensierung
Kosteneinsparung, da Computer seltener aufgerüstet werden müssen Netzwerkverbindung notwendig
leicht skalierbar

2.1.3 Desktop-Virtualisierung

Bei der Desktop-Virtualisierung stellt ein Unternehmen seinen Anwendern keinen klassischen, statischen PC zur Verfügung, sondern eine virtuelle Arbeitsumgebung in Form einer virtuellen Maschine. Alle Daten und Einstellungen werden hierbei auf einem Hypervisor bereitgestellt. Die Programme laufen in einer unabhängigen abgeschlossenen virtuellen Umgebung. Jeder Client ist hierdurch von jedem Arbeitsplatz im Netzwerk erreichbar. Der Anwender bemerkt keinen Unterschied, da der Server seine Eingaben entgegennimmt und die Ausgabe auf seinen Monitor überträgt. Daten werden nicht mehr lokal, sondern zentral gespeichert und verwaltet. Bei der Desktop-Virtualisierung kommen auch Thin Clients zum Einsatz, diese besitzen keine bewegliche Hardware wie zum Beispiel Festplatten oder CD-Rom Laufwerke, sondern dienen nur der Ein- und Ausgabe. Hierdurch verbrauchen Sie weniger Strom als Fat Clients und sind deutlich robuster. Im Außendienst werden aber auch Fat Clients zur Desktop-Virtualisierung verwendet.

Pro Kontra
geringes Risiko des Datenverlustes, da zentrale Verwaltung erst ab einer bestimmten Client-Anzahl wirtschaftlich
geringerer administrativer Aufwand Netzwerk bzw. Internetanbindung erforderlich
Arbeitsplätze können ohne viel Aufwand an Bedürfnisse angepasst werden Hohe Kosten/hoher Arbeitsaufwand bei Einführung
erhöhte Lebensdauer der Clients, da die Leistung vom Server erbracht wird nicht jede Software ist Terminalserver-tauglich
Clients sind bei Virenangriffen, Malware etc. weniger gefährdet mehr Speicher auf dem Server benötigt als bei der Anwendungsvirtualisierung
von überall erreichbar (Voraussetzung: Internet)
Thin Clients sind sehr kostengünstig

2.2 Sicherheit

Da Heutzutage nahezu jeder Geschäftsprozess elektronisch gesteuert wird, sind die Speicherung und Verarbeitung von Daten für ein Unternehmen von existenzieller Bedeutung. Umso wichtiger ist es die Sicherheit dieser Daten auch in Zeiten der zunehmenden Vernetzung und Globalisierung zu gewährleisten. Um ein Unternehmen „sicher“ zu machen, müssen im Hinblick auf elektronische Daten insbesondere 3 Bedingungen erfüllt sein:

Sicherstellung der Verfügbarkeit: Durch den eigentlich positiven Trend hin zum „papierlosen Büro“ begeben sich Unternehmen in eine starke Abhängigkeit von elektronischen Informationen. Sind diese temporär nicht erreichbar, wird das Tagesgeschäft stark beeinflusst. Aufträge können nicht mehr eingegeben werden, Bestellungen können nicht aufgegeben werden, Überweisungen können nicht durchgeführt werden, etc.. Auch der Verlust eines Teils der Verfügbarkeit hat schon gravierende Folgen, da Geschäftsprozesse ineinander greifen und sich so gegenseitig beeinflussen. Kann so zum Beispiel der Verkauf keine Aufträge erfassen, fehlen auch dem Einkauf die nötigen Daten zum Bestellen und so weiter. Außerdem kann es durch fehlende Informationen zu falschen Entscheidungen kommen. Die Verantwortlichen müssen also dafür sorgen, dass Störungen im System frühzeitig erkannt und behoben werden, ein Backup von allen wichtigen Daten existiert und für den Fall eines Ausfalls im System ein Notfallplan ausgearbeitet wird.[1]

Gewährleistung der Vertraulichkeit von Informationen: Geraten Unternehmensdaten in die falschen Hände, können für ein Unternehmen große finanzielle Schäden entstehen. Gelangen zum Beispiel Marketingdaten, Konstruktionspläne oder Kundendaten in die Hände der Konkurrenz, wird diese versuchen den Plänen des Unternehmens zuvorzukommen oder anderswie einen Vorteil daraus zu ziehen. Dem betroffenen Unternehmen drohen dann finanzielle Einbußen und Mehrkosten die durch die unter Umständen folgenden Prozesse entstehen. Umso wichtiger ist es, genau zu regeln wer im Unternehmen Zugang zu welchen Daten hat und welche Informationen an Externe Personen weitergegeben werden dürfen. [1]

Korrektheit von Informationen: Liegen einem Unternehmen falsche Informationen vor, kann es zum Beispiel zu Falschlieferungen, Fehlbuchungen und Produktionsausschuss führen. Dem Unternehmen entstehen hierdurch nicht nur Mehrkosten durch die zusätzlich nötigen Korrekturen, sondern unter Umständen auch ein Imageverlust der noch weit schlimmere Folgen nach sich zieht. Um die Korrektheit von Informationen zu gewährleisten sollten zum Beispiel Verantwortliche für alle Bereiche benannt werden, regelmäßige Prüfungen stattfinden und die Mitarbeiter sollten sensibilisiert werden. [1] Welche Maßnahmen im konkreten Fall durchgeführt werden sollten hängt stark von der Art des Unternehmens und der Brisanz der Daten ab, mit Hilfe dieser Bedingungen ist es aber möglich ein Sicherheitskonzept zu erstellen dass auf das jeweilige Unternehmen zugeschnitten ist.

2.3 Protokollarten

Um Daten sicher zu befördern und sie vor widerrechtlichen Zugriffen zu schützen werden verschiedene Techniken der Protokollverschlüsselung verwendet. Die Protokollverschlüsselung findet auf verschiedenen Ebenen des OSI-Modells statt, einem genormten Referenzmodell das aus 7 verschiedenen Schichten besteht. Für jede Schicht existiert eine Beschreibung mit Anforderungen, die verschiedenen Kommunikationsprotokolle müssen diese Anforderungen erfüllen.

Abbildung 1: OSI-Modell
Abbildung 1: OSI-Modell

Transport Layer Security (TLS)

Die TLS-Verschlüsselung (auch als SSL bekannt) bildet die Grundlage für die SMTP, SSH, FTP und HTTP Verschlüsselung und basiert auf dem TCP/IP Standard. Sie dient der sicheren Datenübertragung im Internet, zum Beispiel findet der Versand von E-Mails mit SMTPS über dieses Protokoll statt. Die Übertragung findet in den anwendungsorientierten Schichten des OSI-Modells statt. Jedes höhere Protokoll kann implementiert werden, allerdings ist diese Art der Übertragung langsamer als unverschlüsselte Kommunikation.

Secure Shell (SSH)

SSH ist ein Netzwerkprotokoll (5. Schicht) mit dem man eine sichere Verbindung mit einem entfernten Gerät herstellen kann. Passwortübertragung und Datentransfer erfolgen durch kryptografische Algorithmen verschlüsselt, außerdem können TCP/IP Verbindungen getunnelt werden. SSH wird oft benutzt um über ein unsicheres Netzwerk Eingaben und Ausgaben zu übertragen, wie zum Beispiel bei der Fernwartung. Im Gegensatz zur TLS-Verschlüsselung kann die Kommunikation komprimiert und somit deutlich beschleunigt werden.

Hypertext Transfer Protocol Secure (HTTPS)

HTTPS ist eine Verschlüsselungsmethode die der sicheren Kommunikation zwischen Webserver und Browser im World Wide Web dient. Nachdem sich die Kommunikationspartner authentifiziert haben erfolgt die Datenübertragung mit Hilfe der TLS-Verschlüsselung.

Remote Desktop Protocol (RDP)

RDP ist ein Terminalserverprotokoll bei dem mit einem RC4-Algorithmus verschlüsselte Datenpakete auf der Darstellungsschicht versendet werden. Die Verschlüsselung erfolgt mit 40 (niedrige Verschlüsselung), 56 (mittlere Verschlüsselung in beide Richtung) oder 128 (Server- und Clientseitige Verwendung) Bit.

Independent Computing Architecture (ICA)

ICA ist eine von Citrix entwickelte Protokollart, die plattformübergreifende Verbindungen zwischen Terminalservern und Clients ermöglicht.

IPSEC

IPSec wurde von der IETF (The Internet Engineering Task Force ) [2]entwickelt um eine sichere Alternative zu IP (Internet Protokoll) zu haben. Es erweitert das Internet Protokoll um die Möglichkeit Daten verschlüsselt und mit einer Empfängerauthentifizierung zu versenden.

2.4 Sicherheitsaspekte/-lücken

Zwischen virtualisierten und statischen Computersystemen bestehen also gravierende Unterschiede. Doch werden Sie dadurch sicherer, oder ergeben sich eher neue Probleme? Um diese Frage beantworten zu können, werden wir zunächst mögliche Sicherheitsrisiken für Computersysteme und Netzwerke näher betrachten.

2.4.1 Keylogger

Keylogger zeichnen Tastaturanschläge auf, speichern diese und leiten sie an den Rechner weiter. Sie sind sowohl als Hardware als auch als Software erhältlich. Problematischer als Softwarekeylogger die meist von gängigen Antivirenprogrammen entdeckt werden sind die Hardwarekeylogger die zwischen Rechner und Tastatur gesteckt werden und kaum größer sind als der eigentliche Stecker. Da es an den USB bzw. PS/2 Schnittstellen keinerlei Sicherheitssysteme gibt ist die einzige Möglichkeit Keylogger zu entdecken die optische Kontrolle. Hardware-Keylogger sind legal übers Internet erhältlich.

2.4.2 Malware

Malware ist ein Sammelbegriff für verschiedene Computerprogramme die programmiert wurden um auf dem Zielsystem Schaden anzurichten. Zu Malware gehören:

Computerviren sind Programme, die sich selbst reproduzieren indem sie in lokale Objekte eindringen und sich so auf dem Zielsystem ausbreiten. Sie können sich in Programmdateien, Skripte oder Makros einfügen (Ausführung und Verbreitung beim Starten) oder den Bootsektor befallen (Ausführen und Verbreiten beim Hochfahren). Einzelne Techniken der Computerviren werden oft auch in Würmer und Trojaner eingebaut, so dass Mischformen entstehen.

Computerwürmer vervielfältigen sich nach dem ersten ausführen selber ohne fremde Dateien oder den Bootsektor zu infizieren. Sie verbreiten sich über Netzwerke und Wechselmedien, z.B. als E-Mailanhang oder per Link. Um sich zu verbreiten nutzen Würmer Sicherheitslücken in Betriebssystemen und Anwendungen, sowie in der Netzwerkkonfiguration und dringen so in den lokalen Speicher ein.

Trojanische Pferde tarnen sich als nützliche Anwendung, erfüllen im Hintergrund aber tatsächlich einen anderen, das Zielsystem schädigenden Zweck, wie zum Beispiel das Manipulieren oder löschen von Daten. Trojaner können auch zum Sammeln vertraulicher Informationen wie z.B. Bankdaten oder Passwörter genutzt werden, Massenangriffe auf andere Computer im Netzwerk ausführen oder für das Versenden von Spam-E-Mails verantwortlich sein. Außerdem gibt es die sogenannten Backdoor-Trojaner, die wie ein Fernwartungsprogramm funktionieren, den User aber nicht über die Installation und den Start des Programmes informieren. Einige Trojaner werden auch genutzt um andere Malware auf dem Computer zu installieren.

Spyware und Adware installieren sich meist zusammen mit Share- oder Freeware auf dem Zielsystem und führen dazu dass Werbung z.B. als Banner angezeigt wird (Adware) oder Marktforschungsdaten gesammelt werden die dann an den Auftraggeber gesendet werden.

Scare ware zeigt dem User Meldungen über Schäden am Computer oder fiktive Viren an. Teilweise handelt es sich hierbei um „Spaßmeldungen“, in einigen Fällen soll der User aber auch dazu gebracht werden ein angebliches Antivirenprogramm herunterzuladen oder eine bestimmte Website zu besuchen, über die sich dann wiederum andere Malware verbreitet.

2.4.3 Man in the Middle

Man in the Middle bezeichnet eine Methode bei der sich ein Angreifer zwischen 2 Kommunikationspartner stellt und sich als der jeweils andere ausgibt. So können Daten aufgezeichnet und manipuliert werden, wenn die Kommunikation mit Public-Key-Verfahren ohne signierte Zertifikate oder gar nicht verschlüsselt wird. Waren Man in the Middle Angriffe früher noch mit Hardware verbunden, funktionieren sie heute mit Software. Man in the Middle Angriffe können im lokalen LAN, WLAN oder im Internet (sogenanntes Phishing) durchgeführt werden. Diese Art der Angriffe hat in den letzten Jahren stark zugenommen, inzwischen sind sogar fertige Man-in-the-Middle-Toolkits im Internet erhältlich.

2.4.4 Authentifizierung

Die Authentifizierung ist die Überprüfung der Identität eines Users oder einer Maschine. Im Bereich der User-Authentifizierung werden meist Passwörtern oder Fingerabdrücken genutzt um unbefugten keinen Zugriff auf einen Computer, eine Website, ein Dokument etc. zu geben, aber auch PIN-Nummern, Chipkarten, Iriserkennung und zahlreiche weitere Methoden sind Heutzutage verfügbar. Nach der Authentifizierung erfolgt bei der Anmeldung an einen PC die Autorisierung, d.h. es wird überprüft welche Rechte und Zugriffe dem User gegeben werden. Wichtig ist es hierbei besonders in Unternehmen die Passwörter anhand von Richtlinien möglichst sicher zu gestalten (Verwendung von mindestens 3 Zeichenarten, ausschließen bestimmter Wörter, Ablauf nach 3 Monaten, etc.). Auch das Nutzen eines Key-Token (Schlüsselanhänger oder Karten die alle 30 Sekunden einen neuen 8 bis 10-stelligen Code anzeigen der bei der Authentifizierung eingegeben werden muss)bietet einen guten Schutz vor unerwünschten Computernutzungen.

2.4.5 Autorisierung

Bei der Autorisierung, die nach der Authentifizierung erfolgt, wird geprüft auf welche Ressourcen im Netzwerk ein User oder Server zugreifen darf und welche Rechte er hat. Ein User sollte immer nur so viele Rechte besitzen wie er unbedingt benötigt, um die Sicherheit im Unternehmen gewährleisten zu können. Gelingt es jemandem die Autorisierung zu umgehen hat dies schwerwiegende Folgen, da Zugriffe und Rechte dann nicht länger begrenzt sind und der Eindringling sich frei im Netzwerk bewegen kann.

2.4.6 Datenverlust

Datenverlust kann durch Schäden am Speichermedium, Software- oder Anwenderfehler, Malware oder durch Diebstahl und Verlust erfolgen. Besonders bei lokal auf einem PC oder Laptop gespeicherten Daten besteht ein erhöhtes Risiko des Datenverlustes, da hier meistens keine Sicherheitskopie existiert. Neben dem Verlust besteht das Risiko, dass Daten durch Diebstahl in die Hände von Dritten, z. Bsp. Mitbewerbern, gelangen können, die diese wiederrechtlich zu ihrem Vorteil nutzen. Datenverlust –in welcher Form auch immer- kann für ein Unternehmen schwerwiegende (finanzielle) Folge haben, da der Produktivbetrieb und das Tagesgeschäft hiervon beeinflusst werden können.

3 Server im Bereich der Desktop-Virtualisierung

Den Begriff Server gibt es in der Informationstechnologie in zwei Bereichen. In dem Bereich der Software ist ein Server ein Programm, das über ein Netzwerk-Protokoll Dienste zentral zur Verfügung stellt. In dem Bereich der Hardware bezeichnet man mit dem Begriff Server einen Computer, auf dem mindestens eine Server-Software installiert ist. Die von einem Server zur Verfügung gestellten Dienste können durch eine Client-Software genutzt werden. Hierzu muss die Client-Software entweder auf dem Server selbst installiert sein, oder auf einem Computer, der mit dem Server verbunden ist (z.B. über ein Netzwerk). Die bestehende Verbindung eines Clients mit einem Server wird Session genannt. Im Bereich der VDI(Virtual Desktop Infrastructure) gibt es Server für die Bereitstellung der virtuellen Maschinen sowie für die Verwaltung der Sessions. Für die Datensicherung ist in den meisten Netzwerken ein Backup-Server zuständig.

Auf Servern liegen in der Regel relevante Daten, wie virtuelle Festplatten und somit alle Daten der virtuellen Desktops. Ein Ausfall oder die Störung eines Servers ist daher zumeist mit hohen Kosten verbunden. Aus diesem Grund sind Server sicherheitstechnisch immer relevant. Aufgrund dieser Tatsachen sind Server oft das Hauptziel von Hackerangriffen, Viren oder auch Betriebsspionage.

3.1 Aufbau einer Virtual Desktop Infrastructure

Für den Aufbau einer VDI sind mindestens zwei Virtualisierungsserver notwendig, die die Virtualisierung der einzelnen Desktop-Arbeitsplätze übernehmen. Zusätzlich wird ein Session- bzw. ein Connection-Broker benötigt, der die Authentifizierung der Benutzer gegenüber einem Verzeichnis (z.B. Active Directory) übernimmt und die entsprechend passende virtuelle Maschine des Benutzers startet. Um mit der virtuellen Maschine arbeiten zu können, greift der Benutzer mit einer Client-Software über ein RDP(Remote Display Protocol) auf seinen Desktop zu. Zusätzlich können Management-Werkzeuge oder ein weiterer Server als Managementplattform eingesetzt werden, über die die Verwaltung der virtuellen Maschinen und der Benutzerprofile möglich ist.

Folgendes Bild beschreibt einen möglichen Aufbau einer VDI. Auf diesem stellen die Clients (Thin Client, Fat Client und der Laptop) eine Anfrage an den Session-Broker. Dieser Prüft an dem Directory-Server ob diese zugriffsberechtigt sind. War die Authentifizierung erfolgreich, wird der Broker den Start der virtuellen Maschinen bei der Management Plattform in Auftrag geben. Diese startet dann auf dem Virtual Machine Monitor die virtuellen Maschinen. Über RDP-Verbindungen werden dann Eingaben des Clients an die virtuelle Maschine, sowie der Bildschirm der virtuellen Maschine an die Clients übertragen.

Möglicher Aufbau einer VDI:

3.2 Der Hypervisor

Ein Hypervisor, auch VMM (Virtual Machine Monitor) genannt, ist eine Virtualisierungssoftware, die eine Umgebung für virtuelle Maschinen schafft. Diese Umgebung besteht aus einem Satz von Treibern virtualisierter Hardware, durch die die physikalische Hardware für virtuelle Maschinen abstrahiert wird. Dadurch wird den virtuellen Maschinen suggeriert, dass es selbst über diese abstrahierte Hardware verfügt. Der Hypervisor kontrolliert die Ressourcen und den Prozessor und weißt den jeweiligen virtuellen Maschinen diese nach Bedarf und Konfiguration zu. Man unterscheidet zwischen Hypervisoren des Typ 1 und des Typ 2. [3]

Hypervisoren des Typ 1 sind direkt auf der Hardware installiert. Auf dem Schaubild "Hypervisor Typ 1" sieht man einen physikalischen Server mit einem Typ 1 Hypervisor, der direkt auf der Hardware läuft und die virtuellen Ressourcen den drei virtuellen Maschinen zur Verfügung stellt.

Abbildung 3: Hypervisor Typ1
Abbildung 3: Hypervisor Typ1

Aktuelle Hypervisoren vom Typ1 sind VMware ESX Server, Microsoft Hyper-V, Xen, Citrix XenServer.

Für einen Hypervisor des Typ 2 ist auf dem Server ein Betriebssystem erforderlich, auf dem der Hypervisor eingesetzt wird. Siehe Schaubild "Hypervisor Typ 2".

Abbildung 4: Hypervisor Typ2
Abbildung 4: Hypervisor Typ2

Aktuelle Hypervisoren vom Typ2 sind VMware Server (GSX), VMware Workstation, VMware Fusion, QEMU, Microsoft Virtual PC


3.2.1 Vergleich Typ1 und Typ2

Hypervisoren von Typ1 sind durch das Fehlen des Betriebssystems effizienter, und sicherer als Hypervisor von Typ2. Die virtuellen Maschinen müssen nicht durch die Schichten des Betriebssystems und des Hypervisors um auf die Hardware zuzugreifen. Ein Typ2 Hypervisor verbraucht durch das installierte Betriebssystem mehr Ressourcen und bietet durch das installierte Betriebssystem auch mehr Angriffsfläche (Sicherheitslücken, Bugs) für potentielle Angreifer. Typ2 Hypervisoren werden zumeist auf Clients eingesetzt, auf denen die Geschwindigkeit nicht so hoch priorisiert wird oder dort, wo bestimmte Hardware nicht durch den Hypervisor direkt unterstützt wird.[4]

3.2.2 Sicherheitsrelevante Aufgaben und Eigenschaften von Hypervisoren

Der Hypervisor hat verschiedene sicherheitsrelevante Aufgaben. Eine Hauptaufgabe ist das Einteilen der Ressourcen des Computers. Dies ist deshalb sicherheitsrelevant, da die virtuellen Maschinen auf dem Server und der Hypervisor selbst ungestört nebeneinander gleichzeitig arbeiten und auch in angemessener Zeit z.B. auf Eingaben reagieren oder Prozesse abarbeiten. Wird beispielsweise in einer virtuellen Maschine ein Forkbombe gestartet und somit schnell viele Ressourcen verbraucht, so soll dies keine Auswirkungen auf die anderen virtuellen Maschinen auf dem Server und dem Hypervisor haben. Eine Forkbombe ist ein Programm, welches sich selbst in einer Endlosschleife rekursiv aufsucht und somit immer mehr Ressourcen in Anspruch nimmt. Viele Hypervisoren bieten die Möglichkeit, Ressourcen dynamisch anzupassen[5]. Benötigt z.B die virtuelle Maschine A gerade viel Arbeitsspeicher weil gerade der Benutzer A auf dieser mit einer Bildbearbeitungssoftware arbeitet, so wird dieser Maschine mehr Speicher zugeteilt, wenn die anderen Maschinen diesen nicht benötigen. Ein potentieller Angreifer könnte den Betrieb stören, wenn er es schafft, die Ressourceneinteilung des Hypervisors auszuschalten oder unwirksam zu machen: z.B durch Bugs in der Software, des Hypervisors.

Eine weitere Hauptaufgabe ist die Isolation. Der Hypervisor isoliert die virtuellen Maschinen gegenseitig voneinander und vor dem Hypervisor selbst. Es ist also grundsätzlich nicht möglich von einer virtuellen Maschine auf die andere oder auf den Hypervisor direkt zuzugreifen obwohl sie sich auf dem gleichen physikalischen Server befinden. So ist es z.B. möglich sicherheitskritische Dienste wie Spam und Virenfilter vor unternehmenskritischen Anwendungen zu kapseln. Bei der Desktop-Virtualisierung werden so die Desktoparbeitsplätze der Benutzer voneinander getrennt. Eine Gefahr besteht, wenn ein Angreifer aus einer virtuellen Maschine ausbricht [dies wird auch Hypervisor Escape genannt]. Im Jahr 2009 gab es z.B. in dem VMware Hypervisor eine Sicherheitslücke, die dies ermöglichte[6]. Ein Angreifer hat, aus der virtuellen Maschine heraus, direkten Zugriff auf den Hypervisor und somit auch auf alle Daten der anderen virtuellen Maschinen. Je nach Art der Speicherung, ist so der Zugriff auf alle Daten der virtuellen Maschinen möglich, denn oft liegen diese in einem SAN und auf dieses hat der Hypervisor und somit auch der Angreifer Zugriff auf alle virtuelle Maschinen in dem SAN.

Eine andere Aufgabe ist die Steuerung der virtuellen Maschinen. Der Hypervisor hat die Möglichkeit die virtuellen Maschinen zu starten, zu stoppen, die Art der Netzwerkanbindung der Maschinen zu steuern, das Netzwerk filtern, oder aber Snapshots erstellen und über diese virtuelle Maschinen in frühere Zustände zurück zu versetzen[7]. Die Steuerung der virtuellen Maschinen wird in der Regel als Dienst zur Verfügung gestellt. Eine Management-Software kann sich mit dem Dienst verbinden und somit alle virtuellen Maschinen Steuern.

Ein Hypervisor allein kann ein Single-Point-of-Failure sein. Bei einer herkömmlichen Serverfarm laufen im Normalfall andere Server noch, wenn ein Server ausfällt. Fällt eine virtuelle Maschine aus, so hat die keine Auswirkungen auf die anderen virtuellen Maschinen, sie laufen weiter. Fällt jedoch der Hypervisor aus, so fallen alle auf ihm laufenden virtuellen Maschinen aus. Die Hersteller von Hypervisoren haben dies erkannt und bieten daher Clustermöglichkeiten und Hochverfügbarkeit an.[8]

Es ist möglich virtuelle Maschinen von einem Hypervisor auf einen anderen Hypervisor zu migrieren. Hierbei wird die virtuelle Maschine pausiert (in den Ruhezustand versetzt) und die dazugehörigen Daten auf den anderen Hypervisor verschoben. Danach wird die virtuelle Maschine auf dem Ziel wieder gestartet. Wird für die beteiligten Hypervisor ein gemeinsamer Speicher wie z.B. ein SAN oder NAS verwendet, so ist eine Live Migration möglich, denn das Kopieren der Festplattendateien entfällt und nur der Arbeitsspeicher-Snapshot muss auf dem neuen Hypervisor kopiert werden. Die virtuelle Maschine ist so nur wenige Sekunden nicht erreichbar. Jon Oberheide beschrieb 2008 auf der BlackHat Conference einen Angriff auf die Live Migration[9]. Hypervisor Firewalls können einen Schutz vor Angriffen dieser Art bieten.[10] Auf dem folgenden Schaubild sieht man auf der linken Seite einen Hypervisor mit einer virtuellen Maschine. Diese soll Migriert werden. Durch einen Man-in-the-Middle Angriff werden von dem Angreifer während der Migration Daten auf der virtuellen Maschine geändert. Beispielsweise fügt der Angreifer einen Trojaner hinzu, damit er so später Zugriff auf die virtuelle Maschine erhält. Ist die Migration abgeschlossen so hat der Angreifer auf dem Ziel Hypervisor nun eine virtuelle Maschine mit seinem eingeschleusten Trojaner laufen.

Schaubild: Live-Migration-Attack

3.3 Sicherheit im virtuellen Netzwerk

Durch die Virtualisierung der Desktops wird auch ein Teil des Netzwerkes virtualisiert. Es ist möglich, virtuelle Netzwerke aufzubauen, die keine Verbindung zu dem physikalischen Netz haben. Die Kombination aus virtuellen und physikalischen Netzen macht die Konfiguration von Firewalls komplex. Es muss berücksichtigt werden, dass virtuelle Maschinen auf den verschiedenen Hypervisor ggfs. verschoben werden. Ein Ansatz sind hier virtuelle Maschinen die als Firewall funktionieren. Bietet die Virtualisierungslösung die Möglichkeit virtuelle Maschinen mit mehreren Netzwerkkarten einzurichten, so kann eine Firewall auch virtuell als Brücke zwischen Netzen realisiert werden. Ein anderer Absatz ist das physikalische Firewalls vor und hinter den virtuellen Netzen arbeiten und so den Zugriff in diese Filtern können.

Ein weiterer Ansatz ist eine Firewall welche auf dem Hypervisor installiert ist. Diese agiert als virtueller Switch und ist in dem virtuellen Netzwerk unsichtbar, hat aber durch den Hypervisor Zugriff auf alle Pakete im virtuellen Netz und auch alle Filtermöglichkeiten. Zudem kann der Traffic zwischen den virtuellen Maschinen gefiltert und überwacht werden.[10] Einen ähnlichen Ansatz verfolgen auch physikalische Firewalls, die in einem Switch integriert sind.

Das folgende Bild zeigt einen beispielhaften Aufbau eines Netzwerkes. Auf den Hypervisoren 1-3 verteilt befinden sich die virtuellen Netzwerke für die Produktion und die Verwaltung. Die virtuelle Firewall trennt diese beiden Netze, so dass beispielsweise nur gewisse virtuelle Maschinen der Verwaltung Zugriff auf einzelne Rechner der Produktion haben. Die Server in der DMZ (demilitarisierte Zone) wurden als kritisch eingestuft, da sie aus dem Internet erreichbar sind. Über die virtuelle Firewall wird der Zugriff von der DMZ auf die beiden internen Netze verhindert. Die virtuelle Firewall erlaubt aus den internen Netzen Zugriff auf Web, Mail und Datenbank-Server. Die physikalische Firewall filtert die Verbindung zwischen dem Internet, der DMZ und der virtuellen Firewall.

Schaubild: Beispielaufbau eines virtuellen Netzwerkes

3.4 Management der VDI

Genauso wie normale nicht virtuelle Desktop-Clients in einem Netzwerk, benötigen auch virtuelle Desktop-Clients Pflege und Wartung. Bei einer großen Anzahl von Clients ist ein zentralisiertes Management der Clients nötig, denn alle Clients sollten mit den aktuellsten Updates, und Software versorgt sein in denen Sicherheitslücken weitestgehend behoben sein sollten. Auch sollten Virenscanner immer mit den neusten Signaturen versorgt sein. Nur durch die regelmäßige Pflege kann die Sicherheit der Desktops gewährleistet werden. Management Werkzeuge/Plattformen sorgen für die automatisiere Inventarisierung, Installation, Verteilung der Software, Update-Management, Fernwartung und Fernsteuerung sowie Backup, Benutzerprofilmanagement und Client-Migrationen. Um die Managementaufgaben zu bewältigen, werden Schnittstellen wie Management Ports für die Management Werkzeuge und Konsolen benötigt.

Schwachstellen in dieser Software ermöglichen Angreifern es die Management-Fähigkeiten zu Missbrauchen. Beispiele wären:

  • Fälschung der Inventarisierung
  • Der Angreifer legt sich eine eigene virtuelle Maschine an
  • Nutzung der Softwareverteilung für Malwareverteilung
  • Nutzung von Fernwartung und Fernsteuerungsfunktionen um:
    • Passwörter zu erlangen
    • den Betrieb zu stören
    • Spionage zu betreiben

3.5 Session Verteiler/Loadbalancer

Der Session Verteiler auch Connection Broker oder Session Broker genannt, koordiniert in einer VDI die Verteilung der Remote-Zugriffe der Benutzer auf die richtigen virtuellen Maschinen. Bei einem Zugriff startet er ggfs. die virtuellen Maschinen auf den Hypervisor und stoppt nicht benutzte virtuelle Maschinen. Hierdurch entsteht das Problem das gestoppte virtuelle Maschinen nicht mit Updates versorgt werden.

Sind mehrere Hypervisoren zu einem Cluster zusammengefasst, so kann der Session Verteiler auch als Loadbalancer fungieren und die neuen virtuellen Maschinen dort starten wo genügend echte Ressourcen für die virtuelle Maschine zur Verfügung stehen. Der Connection Broker übernimmt die Authentifizierung bzw. leitet er diese an einen Directory Server wie z.B. Microsofts Active Directory weiter.

Ein Sicherheitsaspekt ist an dieser Stelle die Speicherung des Passwortes. Um das Ausspähen von Passwörtern zu verhindern, werden Passwörter verschlüsselt abgespeichert. Hierzu wird aus dem Passwort durch Algorithmen eine Zeichenkette erzeugt, die keine Rückschlüsse auf das Passwort ermöglicht. Diese Zeichenkette nennt man Hash. Verglichen wird der gespeicherte Hash mit dem Hash des eingegebenen Passwortes, welcher hierfür nach der Eingabe erzeugt wird. Gleiche Passwörter haben so den gleichen Hashwert. Sicherer wird es, wenn an die Passwort-Hash Zeichenkette ein weitere zufällige Zeichenkette, genannt Salt, angehangen und dann erneut ein Hash gebildet wird. Der Salt muss dem System bekannt sein, damit der Passwortvergleich noch funktioniert. Durch ein zufälligen Salt-Wert haben gleiche Passwörter unterschiedliche Hashwerte. [11]

Ein Angriff auf den Connection Broker kann z.B: folgende Konsequenzen haben:

  • Clients können sich nicht mehr Anmelden
  • Passwörter könnten abgefangen werden (Angreifer auf dem Connection Broker als Man in the Middle)
  • Der Angreifer kann durch Stoppen und Starten von virtuellen Maschinen den Betrieb stören

3.6 Verbindungsmöglichkeiten

Die Clients verbinden sich über ein Protokoll mit den virtuellen Maschinen. So kann Bild und Audio des Desktops auf dem Client dargestellt werden und die Eingaben vom Client an die virtuelle Maschine weitergegeben werden. Eine Steuerung des Desktop wird somit ermöglicht. In diesem Bereich gibt es verschiedene Protokolle die je nach VDI-Lösung eingesetzt werden. Damit die Eingaben oder das Bild nicht abgefangen werden können bieten die meisten der Protokolle eine Verschlüsselung. Gängige Protokolle sind z.B: VNC, Microsofts RDP, Citrix ICA, ALP von SUN und PCoIP.

Protokoll mögliche Verschlüsselung
VNC keine[12]
RDP Mit 128-Bit High Encryption pack [13]
ICA SSL [14]
ALP Ja [15]
PCoIP AES 128-Bit [16]

Generell ist es auch möglich, die Verbindungen durch ein verschlüsselten VPN-Tunnel herzustellen.

3.7 Zwischenfazit: Server im Bereich der Desktop-Virtualisierung

In der Praxis werden zumeist Hypervisoren des Typs 1 eingesetzt, denn sie sind im Bereich der Desktop-Virtualisierung effizienter als Typ 2. Bei Typ2 ist im Gegensatz zu Typ1 ein Betriebssystem auf dem der Hypervisor installiert ist erforderlich. Dadurch entsteht mehr Overhead bei der Virtualisierung und die Angriffsfläche ist größer. Im Serverbereich der Desktop-Virtualisierung gibt es ähnliche Gefahren wie bei der Virtualisierung von Servern. Das Clustern von Hypervisoren ist besonders wichtig, da viele Mitarbeiter bei einem Ausfall oder Störung eines Hypervisors nicht mehr arbeiten können. Benötigt eine virtuelle Maschine mehr Ressourcen so kann diese Live auf einen anderen Server migriert werden. Die regelmäßige Wartung und Pflege der Server ist wichtig, damit die die Isolation und Kontrolle der virtuellen Maschinen auf den Hypervisoren gewährleistet ist und auch bleibt. Ebenfalls müssen alle virtuellen Maschinen müssen regelmäßig mit Sicherheitsupdates und Patches versorgt werden. Auch virtuelle Maschinen die nur selten genutzt werden, sollten hierzu regelmäßig hochgefahren werden.

Unternehemenskritische virtuelle Server und Desktops sollten nicht auf den gleichen Server laufen. Durch einen Guest-Hopping-Angriff könnte ein Angreifer von einem virtuellen-Desktop auf einen virtuellen Server "springen" und so großen Schaden anrichten.

Durch die größere Anzahl der virtuellen Maschinen, ist die Gefahr eines Angriffs aus einer virtuellen Maschine heraus wahrscheinlicher, da es durch die Vielzahl von virtuellen Desktops, die zusätzliche Möglichkeit gibt, die VDI anzugreifen. Potentielle Angreifer in dem internen Netz einer Firma haben zusätzliche Angriffsmöglichkeiten durch die virtuelle Maschine auf den Hypervisor, Management Schnittstellen und den Session Verteiler/Loadbalancer.

Auf dem Session Verteiler sollten Protokolle genutzt werden, die eine Verschlüsselung erlauben. Ist dies nicht möglich sollte die Verbindung durch einen VPN-Tunnel aufgebaut werden. Der Administrator sollte möglichst die sicherste Hash-Methode zum Speichern der Passwörter auf dem Session Verteiler oder dem ggfs. verbundenen Directory Server wählen.

4 Clients im Bereich der Desktop-Virtualisierung

Der Begriff Client beschreibt sowohl ein Computerprogramm, das Kontakt zu dem Server aufnimmt, um dessen Dienstleistung zu nutzen als auch ein Endgerät. Für die Kommunikation zwischen Client und Server sind mehrere verschiedene Aufteilungen möglich. Ein Thin Client besitzt nur die notwendigsten Funktionen und ist somit nur die Benutzerschnittstelle für Applikationen, die auf dem Server liegen. Der voll ausgestattete Fat Client hingegen bietet die Möglichkeit Anwendungen clientseitig zu bearbeitet und ist somit nicht dauerhaft auf einen Server angewiesen. Alternativ gibt es noch den Rich-Client, auch als Smart Client bezeichnet, der die Vorteil der Thin Clients und Fat Clients vereint. Bestimmte Basisfunktionen können clientseitig ausgeführt werden, komplexere Anwendungen hingegen verwenden den Server.

4.1 Möglichkeiten der Authentifizierung

Die Authentifizierung dient der Identifizierung des Anwenders und der Bestimmung seiner Nutzerrechte. Für eine erfolgreiche Authentifizierung muss ein Anwender sich mithilfe verschiedener, in den folgenden Unterkapiteln genannter Methoden, zu erkennen geben. Der Mitarbeiter sendet dazu persönliche Daten wie zum Beispiel Benutzernamen und Passwort an einen sogenannten Authentifizierungsserver, welcher entweder vom eigenen Unternehmen gestellt wird oder bei einem beauftragten Dienstleister verwaltet wird. Dabei sind zwei Faktoren zu unterscheiden, das Wissen und der Besitz. Bei Authentifizierungen mittels eines Passworts trifft nur der Faktor Wissen zu, was recht einfach weitergegeben werden kann. Bei anderen Authentifizierungsmethoden kommt der Faktor Besitz hinzu. Es wird zusätzlich einen Karte oder ein Token benötigt, was nicht aus Versehen weitergegeben werden kann. Bei Verlust oder Diebstahl kann das zusätzliche Medium auch gesperrt werden. Diese beiden Faktoren in Kombination sorgen somit für eine wesentlich höhere Sicherheit.

4.1.1 Benutzername, Kennwort

Standardmäßig wird der Zugriff auf Netzwerkressourcen mittels Benutzernamen und Kennwort gesichert. Statische Passwörter bieten allerdings keinen 100%igen Schutz. Oftmals wählen die Mitarbeiter bewusst leicht zu merkende und somit auch leicht zu erratende Passwörter, weil der vorgeschriebene Passwortwechselrhythmus zu kurz gewählt ist, um sich an sein neues Passwort zu gewöhnen. Unsicher ist die einfache Benutzernamen und Kennwort Authentifizierung auch, weil sich viele Mitarbeiter ihre zu komplizierten Passwörter auf einen Zettel schreiben und diesen bei ihrem Clientrechner aufbewahren. Daher analysieren diverse Studien immer wieder die am häufigsten verwendeten Passwörter. Die Top 10 wird angeführt von "123456", gefolgt von weiteren Zahlreihen oder ganz simpel "passwort" bzw. "password". [17] Dies führt dazu, dass Brute Force Attacken (rohe Gewalt, also das simple Ausprobieren häufiger Passwörter) ziemlich erfolgreich sind. Durchschnittlich braucht ein Hacker nur etwa 110 Versuche, um Zugang zu einem Konto zu bekommen. Das macht bei maschineller Ausführung etwa einen neuen Zugang pro Sekunde oder 17 Minuten für Zugang zu 1000 Konten.

4.1.2 Smartcard/Chipkarte

Um eine sichere Authentifizierung zu erreichen, können spezielle Chipkarten verwendet werden. Dieser Chip beinhaltet benutzerspezifische Zertifikate, die innerhalt eine PKI (Public-Key-Infrastruktur) erstellt wurden. Dabei ist hohe Sicherheit geboten, um die sichere Authentifizierung zu gewährleisten und Missbrauch zu verhindern. Dieses Zertifikat mit einer Passphrase - am besten PIN-geschützt auf einer Smartcard - erhöht somit die Sicherheit der Authentifizierung und ermöglicht auch die sichere Nutzung von Anwendungen über das Internet. Bei dieser Methode besteht also eine Kombination aus "Wissen" und "Besitz". Ein Weitergeben der PIN-Nummer genügt nicht, um an die Daten des Benutzers zu gelangen, ebenso der Verlust oder Diebstahl der Chipkarte.

4.1.3 Fingerprint

Bei einer Fingerabdruck Authentifizierung umgeht man den ständigen Passwortwechsel und das Mitführen eines Tokens oder einer Smartcard. Je hochwertiger der dahinter steckende Fingerabdruckscanner ist, umso schwerer lässt sich ein Fingerabdruck fälschen. Da keine zwei Menschen den gleichen Fingerabdruck haben, kann man hier bei hochwertigen Scannern von einer eindeutigen Identifizierung sprechen. Der Nachteil an den Fingerabdruckscannern ist jedoch, dass die Mitarbeiter nur an Rechnern arbeiten können, die über einen solchen Scanner verfügen.

4.1.4 Key-Token

[Quelle: http://www.indevis.de/dokumente/rsa_authenticators.pdf (19.06.2011)]Abbildung 7: RSA SecurID 700
[Quelle: http://www.indevis.de/dokumente/rsa_authenticators.pdf (19.06.2011)]Abbildung 7: RSA SecurID 700

Der Key-Token ist, bei den nicht an einen standortgebundenen Clients, der verbreitetste. Ein solcher Token ist in etwa so groß wie ein handelsüblicher USB-Datenstick. Allerdings hat er keine Schnittstelle, die für Analyse der darauf befindlichen Daten tauglich wäre. Der Key-Token hat stattdessen ein kleines Display auf dem 6-8 Zahlen dargestellt werden (Siehe Abbildung 7 und 8). Diese Zahlen ändern sich alle 60 Sekunden. Dieser Zahlencode wird auch als „One Time Password“ bezeichnet und ist, wie der Name sagt, nur einmal gültig. Jeder Hersteller hat hier verschiedene Algorithmen, die zur Berechnung der Zahl verwendet werden können. Als Variable Daten verwendet der jeweilige Algorithmus das derzeitige Datum und die Uhrzeit. Damit ein Key-Token verwendbar ist, ist eine Initialisierung notwendig. Der Authentifizierungsserver merkt sich dann den zu diesem Zeitpunkt verwendeten Zahlencode. Sobald sich der Mitarbeiter dann mit seinem Benutzernamen einloggen will, errechnet der Authentifizierungsserver mithilfe des Datums, der Uhrzeit und des zuerst verwendeten Codes, ob der User auch der ist, der er vorgibt zu sein. Sollte ein Mitarbeiter seinen Key-Token verlieren, so kann der Finder selbst dann nichts damit anfangen, wenn er den Benutzernamen und das Passwort des Mitarbeiters hätte, da bei der Standardeinstellung neben dem One Time Password auch eine 4-8 stellige Pinnummer eingegeben werden muss, die der Mitarbeiter vorher festlegt. Dieses Verfahren wird als „Strong User Authentication“ bezeichnet. Das Ganze wird je nach Hersteller AES-128 BIT oder AES–256 BIT verschlüsselt. Hier gibt es allerdings noch die Unterscheidung in programmierbare und nicht programmierbare Tokens. Im Gegensatz zu den nicht Programmierbaren können die Programmierbaren vom Administrator selbst konfiguriert werden. Bei der Konfiguration kann unter anderem ein neuer Algorithmus für die Codegenerierung erstellt werden. Da dies dazu führen kann, dass der Token nicht so sicher ist wie bei der Auslieferung sollte dies nur von erfahrenen Administratoren gemacht werden.

4.1.5 USB- Token

[Quelle: http://www.indevis.de/dokumente/rsa_authenticators.pdf (19.06.2011)] Abbildung 9: RSA SecurID 800
[Quelle: http://www.indevis.de/dokumente/rsa_authenticators.pdf (19.06.2011)] Abbildung 9: RSA SecurID 800

Ein USB-Token setzt immer eine USB-Schnittstelle voraus. Sobald sich der Mitarbeiter in das Firmennetzwerk einwählen will, wird vom USB-Token der Authentifizierungscode generiert und übermittelt. Um die USB-Tokens sicherer zu machen, gibt es z.B. von der Firma RSA den SecurID 800 (Siehe Abbildung 9). Dieser kombiniert die Sicherheitsmechanismen des Key-Tokens und zusätzlich die Funktionalität des USB-Tokens.

4.1.6 Software-Token

Beim Software Token wird ein Programm auf dem jeweiligen Client installiert. Das Programm ermittelt dann anhand der Hardware, des Datums und der Uhrzeit den zu übermittelnden Code. Der Vorteil daran ist, dass man kein zusätzliches gerät mit sich führen muss um im Firmennetzwerk zu arbeiten. Allerdings hat der Software Token auch einige Nachteile. Sobald der Client (z.B. Notebook) verloren geht, kann jeder der an dem Betriebssystempasswort vorbei kommt auf das Firmennetzwerk zugreifen. Ein weiterer Nachteil ist, das man zum Arbeiten an einen bestimmten Client gebunden ist. Sobald der Client nicht verfügbar ist, so ist ein Arbeiten im Netzwerk mit einem Austauschgerät nicht ohne weiteres möglich. Ein weiteres Problem ist der Wechsel von einzelner Hardware. Danach müsste der Token neu registriert werden.

4.1.7 On Demand Token

Bei einem „On Demand Token“ wird der benötigte Code per E-Mail oder SMS angefordert. Bei der E-Mail Anforderung wird der Anforderer anhand der E-Mailadresse und einem Signaturzertifikat (in der Regel S/MIME) authentifiziert. Die Antwort Mail wird dann ebenfalls signiert und zusätzlich noch verschlüsselt. Ohne die Zertifikate wäre es ohne weiteres möglich ein Token mit einer gefälschten E-Mailadresse anzufordern und die Antwortmail abzufangen. Bei der SMS Anforderung erfolgt die Authentifizierung lediglich anhand der Telefonnummer des Anforderers.

4.1.8 Sonderformen

4.1.8.1 YUBIKEY

[Quelle: https://store.yubico.com/store/catalog/images/black_single.jpg (19.06.2011)] Abbildung 10: YubiKey
[Quelle: https://store.yubico.com/store/catalog/images/black_single.jpg (19.06.2011)] Abbildung 10: YubiKey

Der Yubikey von Yubico ist am ehesten mit dem USB-Token zu vergleichen. Genau wie ein USB-Token wird der Yubikey (Abbildung 10) über den USB-Port verbunden. Die Authentifizierung erfolgt hier über einen Druck auf den am Yubikey angebrachten Knopf. Alles war zur Anmeldung notwendig ist, erledigt der Yubikey dann selbstständig. Beim Yubikey kann man im Gegensatz zu den anderen Token die Authentifizierungsart wählen. Standardmäßig ist ein Code eingestellt, welcher sich aus 12 festen Zeichen und einem 32 Zeichen langen One Time Password zusammensetzt. Als Alternative gibt es noch die Open Authentifikation bei der 6 oder 8 zahlen übermittelt werden. Eine weitere Möglichkeit ist ein 1-38 Zeichen langes statisches Password.

4.1.8.2 GridID

Bei den sogenannten GridIDs erhält der Mitarbeiter eine kleine Karte, welche ein ähnliches Muster wie Schiffe versenken enthält. Es ist eine simple Tabelle, die als Spaltenüberschrift die Buchstaben A bis J enthält (je nach Sicherheitsstufe mehr oder weniger) und in der ersten Spalte in jeder Zeile die Zahlen 1 bis 5 (je nach Sicherheitsstufe mehr oder weniger). Die restlichen Felder der Karte sind mit zufallsverteilten Zahlen gefüllt. Jeder dieser Karten ist an einen bestimmten Mitarbeiter gebunden. Will sich der Mitarbeiter nun mit dem Netzwerk verbinden, wird er vom Authentifizierungsserver nach unterschiedlichen Zahlen in Form von F3, B1 und D1 gefragt. Nun muss der Anwender auf der Karte gucken, welche Codenummer sich hinter der Anfrage befindet. Da die Möglichkeit der Passwörter hierbei stark eingeschränkt ist und ein Angreifer anhand weniger abgefangener Authentifizierungen die komplette Karte rekonstruieren kann, ist diese Sicherheitsmethode als eher ungeeignet zu betrachten.

4.1.8.3 Keypad-Token

Die Keypad Tokens haben die Form einer Kreditkarte und sind etwas dicker als diese. Sie vereinen das One Time Password des Key-Tokens mit einem Eingabefeld. Will man sich in ein Netzwerk einwählen, so wird man, nachdem man sich mit seinem Benutzernamen und seinem Password eingewählt hat, an eine zweite Authentifizierungsmaske weitergeleitet. Hier erfährt man eine bestimmte PIN-Nummer, die man über das Eingabefeld des Keypad-Tokens eingeben muss. Anhand der Eingabe erfährt man dann sein gültiges „One Time Password“.

4.1.8.4 Grid-Token

Beim Grid-Token wählt der Anwender ein beliebig langes Passwort, bestehend aus Großbuchstaben, Kleinbuchstaben, Sonderzeichen und Zahlen. Beim Authentifizieren wird dem Anwender eine Tabelle mit 5x5, 6x6 oder 7x7 Feldern dargestellt. Gefüllt sind die einzelnen Felder mit allen, für das Password gültigen, Zeichen. Jedes Feld erhält dabei nur ein Zeichen. Der Anwender muss sich jetzt wie bei der PIN-Eingabe am Geldautomaten seine Zeichen raussuchen und in der richtigen Reihenfolge eingeben. Da je nach Länge des Passwortes mehr feste Zeichen im Grid vorhanden sein müssen, kann ein Angreifer, allein durch sehen mehrerer Grids, alle Zeichen, die das statische Password enthält, ermitteln. Je nach Passwortlänge braucht er dann nur wenige Versuche um die Zeichen in die richtige Reihenfolge zu bringen.

4.2 Fat Clients (u.a. Definition)

Abbildung 11: Die Hardwareabstraktionsschicht
Abbildung 11: Die Hardwareabstraktionsschicht

Hauptmerkmal des Fat Clients ist der, dass der Fat Client seine eigene Hardware einsetzt. Anders als der Thin Client hat der Fat Client also seine eigene Festplatte, seinen eigenen Arbeitsspeicher, eine Grafikkarte und in der Regel CD\DVD\Disketten-Laufwerke. Er ist also ein vollwertiger Rechner, der je nach Betriebssystem eigenständig operieren kann. Neben der Dateneingabe und Datenausgabe, die auch der Thin Client beherrscht, verarbeitet der Fat Client die Daten selbstständig ohne diese an den ihm zugewiesenen Server zu übermitteln. Das Ganze hat den Vorteil, dass auch ohne eine bestehende Netzwerkverbindung weitergearbeitet werden kann. Je nach Größe des eingesetzten Netzwerkes bzw. je nach Anzahl der Clients bedeutet dies allerdings auch einen enormen Aufwand um jeden Client mit den nötigen Updates zu versorgen. Fat Clients werden in den meisten Fällen in Form eines Notebooks außerhalb des lokalen Firmennetzwerkes eingesetzt. Realisiert wird dies entweder durch ein VPN-Netzwerk oder eine gesicherte Internetverbindung meist mit Hilfe von Passwörtern und/oder dem RSA-Kryptosystem. Der Fat Client besteht aus genau zwei Schichten. Zum einen sind dies die Hardwareabstraktionsschicht und zum anderen die Programmierschnittstelle. Die Hardwareabstraktionsschicht ist dafür vorgesehen, zu verhindern, dass keine Software, auch das Betriebssystem nicht, auf direktem Weg mit der Hardware kommuniziert. Die Hardwareabstraktionsschicht ist der Vermittler zwischen Software und Hardware (siehe Abbildung 11).

Die Programmierschnittstelle (API) stellt dem Anwendungsentwickler verschiedene Methoden, Funktionen, Konstanten und Variablen zur Verfügung, um seinem Programm die Kommunikation mit dem Betriebssystem bzw. der Hardware zu ermöglichen. Die Programmierschnittstelle dient also zur Kommunikation der Software mit der Hardwareabstraktionsschicht. Der eigentliche Fat Client dient in der Regel dazu um eine bestimmte Aufgabe zu erledigen. Dies sind z.B. E-Mails abrufen, E-Mails sende, FTP-Zugriff und Web-Zugriff. Neben dem eigentlichen Fat Client gibt es noch die Unterteilung in Rich Clients und die Smart Clients.

Der Smart Client kombiniert die Vorteile des Fat Clients mit den Vorteilen der Thin Clients. Wie der Fat Client hat der Smart Client die nötige Software auf der eigenen Festplatte Installiert. Dadurch kommt der Smart Client im Gegensatz zum Thin Client auch mit einer geringen Bandbreite klar, da er nur die benötigten Daten Laden muss und nicht den benötigten Programmcode. Die Kommunikation zwischen Client und Server erfolgt in der Regel per HTTPS. Gerade bei Mobilen Geräten mit einer geringen Bandbreite ist dies von entscheidendem Vorteil. Die Firma Citrix hat z.B. den sogenannten Citrix Receiver entwickelt um mit Smartphones oder z.B. einem iPad eine Verbindung mit dem XEN-Desktop herzustellen. Der Smart Client kombiniert den Benutzerkomfort und den Funktionsumfang des Fat Clients mit der Aktualität einer Onlineanwendung.

Im Gegensatz zum Fat Client ist der Rich Client in der Lage mehrere Aufgaben bzw. Probleme zu bewältigen. Dies ist z.B. die E-Mailkommunikation und eine FTP-Anbindung mit Upload und/oder Download Berechtigung. Bei einem Rich Client handelt es sich um ein leicht zu Modifizierendes Programmiergerüst. Der Nutzer ist in der Lage einen Rich Client mit vorgefertigten Modulen und Plugins zu erweitern, so dass er komplett auf den User bzw. die Hardware abgestimmt werden kann. In der Regel ist der Nutzer bei der Zusammenstellung seiner Plugins\Module nicht an einen Anbieter bzw. Hersteller gebunden und kann sich die für ihn am besten geeigneten auswählen und verwenden. Oft werden solche Erweiterungen auch als Bundle zusammen gefasst und separat distribuiert. Die Rich Clients zeichnen sich vor allem durch ihre einfache Verteilbarkeit und Aktualisierbarkeit aus. Dies wird meist, durch ein automatisches Onlineupdate oder einen Webstarter welcher vom Client ausgeführt wird, bewerkstelligt. Genau wie der Fat Client ist auch der Rich Client online und offline nutzbar. Bekannte Rich Client Plattformen sind Eclipse und NetBeans für Java und Microsoft Visual Studio für .net. Mit ihnen kann man die nötigen Plugins selbst entwickeln.

4.2.1 Starten einer virtuellen Maschine

Im Bereich der Desktop Virtualisierung gibt es verschiedene Möglichkeiten dies zu realisieren. Dies sind zum einen die Möglichkeit eine virtuelle Maschine über das Firmennetzwerk zu starten, oder über einen Web-Access.

4.2.1.1 Virtuelle Maschine aus dem Netzwerk starten

Bei Clients ohne eigene Festplatte gibt es die Möglichkeit das Betriebssystem aus dem Netzwerk zu starten. Mit Hilfe des BOOTSTRAP-Protokolls sendet er einen „Boot Request Broadcast“ . Als Antwort erhält er vom DHCP Server ein „Boot Reply„. Im Boot Reply erfährt der Client seine IP Adresse, welche der DHCP Server in seiner Datenbank mit der Mac-Adresse des Clients abgeglichen hat. Optional erfährt der Client noch die IP-Adresse und den Hostnamen des eigentlichen Boot-Servers sowie den Pfad zu der ihm zugewiesenen Bootdatei und des zu verwendenden Root-Pfades. Nachdem diese Daten ausgetauscht werden lädt der Client die Virtuelle Maschine vom angegebenen Pfad per TFTP Format. TFTP ist ein verbindungsloses Protokoll. Es wartet also nicht auf eine Rückmeldung, ob die gesendeten Daten wirklich angekommen ist. Im Gegensatz zu FTP gibt es bei TFTP keine rechtevergabe. Dadurch ist jeder Client, der den Boot Reply des DHCP-Servers belauscht, in der Lage die gleiche Virtuelle Maschine zu laden. Er muss dazu lediglich seine MAC-Adresse fälschen und an den Boot Server die notwendigen befehle senden. Da dies allerdings nur möglich ist, wenn sich beide Rechner im lokalen Netzwerk befinden, kann dies nur vor Ort durchgeführt werden. Ein Broadcast via Internet ist zwecklos.

4.2.1.2 Virtuelle Maschine per Web-Access starten

Neben der Möglichkeit Virtuelle Maschinen über das Lokale Netzwerk zu starten, gibt es noch die Möglichkeit die Virtuelle Maschine über eine Weboberfläche zu starten. Hierzu wird im Internet eine Seite bereitgestellt die in der Regel auf der Startseite nur Eingabefelder für Usernamen, Passwort und eine Authentifizierungsmethode. Zur Authentifizierung wird meist ein Key-Token verwendet, da man für Smartcards ein Lesegerät benötigt und dies nicht bei jedem Computer vorhanden ist. Je nach dahinter liegendem Server muss man Sich dann eine Clientsoftware runterladen. Mit Hilfe dieser Software wird dann die Verbindung zum Virtuellen Desktop aufgebaut. Als Beispiel ist hier der Hypervisor-Server (Siehe Kapitel 3.2) von der Firma Citrix zu nennen. Der Notwendige Client ist so konzipiert, dass er sogar auf Computern in einem Internetcafé ausgeführt werden kann. Er muss sich also nicht im Betriebssystem verankern. Die Notwendige Serversoftware gibt es bereits ab 1000$. Das eingesetzt Independent Computing Architecture Protokoll ermöglicht dem Terminalserver, für Microsoft Windows vorgesehene Programme, laufen zu lassen. Gleichzeitig kann der Terminalserver diese Programme so zum Client streamen, als hätte der Client diese selbst installiert. Durch die starke Datenverschlüsselung gibt es seitens der meisten IT-Abteilung eine Freigabe für Internetcafés. Neben der Verbindung via Desktop oder Notebook besteht bei einigen Server Herstellern auch die Möglichkeit eine Spezielle Clientsoftware für Smartphones oder Tabletts (z.B. iPhone) zu installieren.

4.2.2 Datensicherheit

Am ehesten lässt sich die Sicherheit der Fat Clients mit der eines normalen Desktop Computers vergleichen. Die beim Fat Client vorausgesetzte Hardware ist gleichzeitig die große Schwachstelle in punkto Sicherheit. Die Fat Clients, die im Außeneinsatz verwendet werden, benötigten Betriebssysteme, welche auch ohne Verbindung zum Firmennetzwerk arbeiten kann. Dieses Betriebssystem sollte wie jeder Desktop mit der neusten Antivirensoftware und einer Firewall ausgestattet sein, so dass er sich im Falle eines Angriffes sich selbst und seine gepufferten Daten schützen kann. Häufig infizieren sich die Clientnotebooks der Außendienstmitarbeiter mit Schadsoftware, durch unbedachte Privatnutzung der Notebooks. Dies sind im schlimmsten Fall Trojaner oder Keylogger.

Gefördert wird dies noch durch die Tatsache, dass die Clients unter Umständen nicht regelmäßig die notwendigen Systemupdates oder Sicherheitsupdates sowie die neusten Virendefinitionen installieren. Diese spionieren den Client nach verwendbaren Daten, wie z.B. Passwörter von Netzwerksystemen aus. Die Schadsoftware verankert sich dabei im installierten Betriebssystem und ist von den IT-Verantwortlichen nur zu entfernen, wenn diese am Notebook selbst sitzen. Um mit den Fat Clients zu arbeiten ist keine durchgängige Netzwerkverbindung notwendig. Während sich der Client außerhalb des Netzwerks befindet, sind alle Arbeiten an dem Client potentiell verlustgefährdet. Die Datensicherung kann erst wieder erfolgen, wenn eine Netzwerkverbindung zustande gekommen ist.

Während der Verbindungsunterbrechung kann es vorkommen, dass ein anderer Anwender, der durchgehend eine Netzwerkverbindung hat, bereits die Daten bearbeitet und aktualisiert hat. Hierbei können mehrere Fälle eintreten. Zum Beispiel überschreibt der Außendienstmitarbeiter die Daten des anderen Mitarbeiters, wodurch dessen Arbeit verloren geht. Bei schlecht programmierter Software kommt es auch vor, dass beim Außendienstclient ohne Rücksprache die Daten auf dem Client mit den Daten vom Server überschrieben werden, da diese den neueren Zeitstempel haben. Im Idealfall sollten Außendienstmitarbeiter allerdings zu einem Abgleich der Daten veranlasst werden.

Im Gegensatz zu den Thin Clients sind die Fat Clients durch Hardwarediebstahl gefährdet, da bei ihnen die Daten auch lokal auf der Festplatte liegen. Absichern kann man sich dagegen nur mittels eines Kensington-Schloss. Dieses Schloss sorgt dafür, dass der Client an einem Ort gebunden ist und nur mit dem richtigen Schlüssel verschleppt werden kann. Zusätzlich kann man sich noch mit einem im Notebook implantierten GPS Modul absichern. Durch dieses Modul ist es dem Anwender möglich sein Notebook weltweit zu orten. Voraussetzung dafür ist allerdings, dass das Modul mit Strom versorgt wird, also der Akku nicht entladen ist und der Dieb nicht auf die Daten aus ist und das Notebook nach Entfernen der Festplatte entsorgt.

Als Absicherung wäre die Datenverschlüsselung zu erwähnen. Hierbei werden alle Daten auf der Festplatte verschlüsselt gespeichert und können nur vom Anwender bzw. Administrator entschlüsselt werden. Dies kann sowohl durch Passwörter als auch durch einen Fingerabdruck realisiert werden. Ein weiteres Sicherheitsrisiko ist der Mitarbeiter selbst. Sollte der Mitarbeiter unzufrieden sein, besteht die Gefahr des Datenmissbrauchs. Zum Beispiel könnte der Mitarbeiter mit dem Fat Client zur Konkurrenz gehen. Ein weiteres Risiko der Fat Clients ist die Datensabotage bzw. Manipulation. Da der Client nicht an einen Ort gebunden ist und sich oft außerhalb des firmeninternen Netzwerkes befindet, muss man sich über das Internet mit dem Firmennetzwerk verbinden.

4.2.3 Netzwerksicherheit

Abbildung 12: VPN Tunnel
Abbildung 12: VPN Tunnel

Gerade bei den Fat Clients ist durch ihre Mobilität eine gesicherte Übertragsmöglichkeit von Nöten. Eine reine Passwort Sicherung auf Serverseite ist dafür eher ungeeignet. Zum einen liegt dies an dem oftmals von der IT vorgegebenen häufigen Passwortwechselrhythmus, so dass die meisten Mitarbeiter sich ein Passwort wählen, welches sich leicht merken lässt und damit auch leichter zu erraten ist oder aber das Passwort wird vom Mitarbeiter aufgeschrieben und in der Nähe des Clients aufbewahrt. Zum anderen besteht das Problem, dass um eine Verbindung zum Firmennetzwerk herzustellen oftmals das Internet verwendet werden muss. Ohne eine qualifizierte Verschlüsselung ist es ein leichtes die übertragenen Daten abzufangen. Für einen sicheren Datenaustausch mit dem Firmennetz ist neben dem Usernamen und dem Passwort noch eine Authentifikationsmethode, wie die Smartcard oder ein Key-Token zu verwenden, außerdem sollte die Verbindung selbst noch verschlüsselt werden. Neben SSL\TLS und HTTPS Verbindungen gibt es noch die Möglichkeit eine Verbindung per IPSec (Internet Protocol Security) abzusichern. IPSec siedelt sich im OSI-Schichten-modell in der 3. Schicht, der Bitübertragungsschicht, an. Mittels IPSec ist eine gesicherte VPN (Virtual Private Network) Verbindung zum Firmennetzwerk möglich. Bei einer VPN Verbindung wird der Client oder das Netzwerk in dem sich der Client befindet, mit einem anderen Netzwerk verbunden. Als Übertragungsmedium wird hierzu ein virtueller Tunnel in einem öffentlichen Netz gebaut (siehe Abbildung 12). Von außen ist diese Verbindung nicht sichtbar. Ist die VPN-Verbindung einmal hergestellt, ist es so, als wäre man im lokalen Firmennetzwerk

4.2.4 Zwischenfazit Sicherheit zur Fat Client-Authentifizierung

Viele Branchen erfordern ein hohes Maß an Sicherheit was ihre Daten angeht. Seien es nun Unternehmen der Rüstungsindustrie, die ihre Entwicklungspläne schützen wollen und müssen oder Banken, die ihre Kundendaten vor Fremdzugriff sichern müssen. Am Markt etabliert haben sich vor allem die Firmen RSA, Cryptocard und Yubico. In der untenstehenden Tabelle ist ein direkter Vergleich der drei Anbieter zu sehen.


Kategorie RSA Cryptocard Yubico
Batterie (Lebensdauer 5-6 Jahre) Wenn die Batterie leer ist, muss der Key eingeschickt werden und die Batterie wird vom Hersteller ausgetauscht Die Batterie kann vom Anwender selbständig gewechselt werden nicht notwendig
Lebensdauer Nach bis zu 5 Jahren läuft der Token ab, Ablaufdatum steht auf der Rückseite Frei konfigurierbar (bis unbegrenzt) wobei der Token beim Batteriewechsel neu initialisiert werden muss Unbegrenzt
Sicherheit Hoch Sehr hoch Mittel
Preis pro Token 30€ 20 € - 35 € - je nach Komplexität 25 € - 35 € - je nach Komplexität
Preis pro Server je nach Anzahl der Token mehrere 1000 € nicht angegeben Kostenloser Open Source Server
One Time Password Ja Ja Je nach Konfiguration
Programmierbar Nein Ja - Der Codegenerationsalgorithmus ist änderbar Es kann zwischen mehreren Authentifizierungen gewechselt werden
Verschlüsselung AES - 128 Bit Verschlüsselung AES - 256 Bit Verschlüsselung Je nach Auswahl der Authentifizierung
Shared Token Ja, dass Token wird auf dem Authentifizierungsserver und beim Hersteller gespeichert Nein – Token wird nur auf dem Authentifizierungsserver gespeichert Nein – Token wird nur auf dem Authentifizierungsserver gespeichert

Der Vorteil von Yubico ist, dass der Token je nach Bedarf konfiguriert werden kann. Dies kann allerdings auch zum Nachteil werden, wenn man statt des generierten Schlüssels ein statisches Passwort wählt. Sollte jemand den Datenverkehr abfangen, so hat diese Person jederzeit den gültigen Schlüssel um sich in das Netzwerk einzuwählen und sollte der Key verloren gehen, so hat der Finder sofort Kenntnis vom geschützten System und kann versuchen sich einzuloggen. Cryptocard ist RSA zwar durch die 256-Bit Verschlüsselung in punkto Sicherheit überlegen, allerdings ermöglichen die Open Source Server, dass mögliche Angreifer sich nach Sicherheitslücken umschauen. Beide Algorithmen gelten bisher als unknackbar. Dennoch musste RSA ihren Algorithmus im März abändern, da es einer Gruppe von Hackern bei einem Angriff gelungen ist, den Algorithmus mit dem die Codes erstellt werden, zu erbeuten. Obwohl sich der Anwender mit seinem Usernamen, seinem Passwort, einer PIN-Nummer und dem angezeigten Code authentifizieren muss und anhand des Algorithmus kein Rückschluss auf das geschützte System gezogen werden kann, musste RSA 40 Millionen ihrer Key-Token austauschen. [18]

4.3 Was sind Thin Clients?

Von den sechziger Jahren bis zum Anfang der achtziger Jahre waren auf der Schreibtischen vieler Mitarbeiter sogenannte Terminals zu finden. Ein Terminal ist ein Datensichtgerät mit angeschlossener Tastatur, dass alle Tastendrücke des Anwenders über eine Netzwerkverbindung an einen zentralen Server sendet. Auf dem Großrechner werden die Benutzereingaben verarbeitet, die Programmverarbeitung durchgeführt und die daraus resultierende Datenmaske zurück zum Terminal gesendet, das diese Maske lediglich anzeigt. Ein Terminal verfügt demnach über keine nennenswerte eigene Rechenleistung oder Verarbeitungskapazität. Thin Clients sind gewissenmaßen eine Weiterentwicklung von Terminals. Mehrere Hardware-Hersteller haben Richtlinien für die Ausstattung von Thin Clients erstellt, die beispielsweise, die Bildschirmauflösung festlegen und eine Tastatur, Maus und Soundfähigkeit voraussetzen. Festplatten sind nicht notwendig, aber optional möglich. Zu den bekanntesten Herstellern für Thin Clients gehören Hewlett-Packard und Wyse, die weltweit Markführer sind. Im Deutschland hat sich die Firma Igel als Marktführer durchgesetzt. [19]

Software- und Hardwareausstattung am Beispiel des Igel UD3:

Betriebssysteme IGEL Linux (LX), Microsoft Windows Embedded Standard (ES)
Prozessor VIA Nana E-Series 800MHz
RAM 512 MB (LX), 1 GB (ES)
Flash-Speicher 1 GB (LX), 2 GB (ES)
Grafik VIA Unichrome Pro 64-256 MB Shared Memory
Anschlüsse 1x DVI, 1x 10/100/1000 Base-T Ethernet, 1x Line-out, 1x Mic-in, 1x PS/2, 5x USB
Abmessungen & Gewicht 82x227x231mm 1,44kg
Stromverbrauch: Idle/Sleep 9W / 1W

[20]



4.3.1 Desktop-Virtualisierung mit Thin Clients

Bei der Verwendung von Thin Clients gibt es mehrere Möglichkeiten zur Nutzung. Die am häufigsten verwendete Variante sind Terminal-Server Dienste. Die Verbindung zwischen einen Thin Client und einem Terminal-Server funktioniert entweder über Microsoft RDP (Remote-Desktop-Protokoll) oder über Citrix XenApp bzw. Citrix ICA-Protokoll (Independent Computing Architecture). Dies führt dazu, dass mehrere Anwender parallel auf einem Server arbeiten.

Die Möglichkeit, die hier betrachtet wird, ist die Desktop-Virtualisierung. Der Unterschied zur Server-Virtualisierung besteht darin, dass der Anwender einen eigenen virtuellen Desktop zur Verfügung gestellt bekommt.

Für den Zugriff auf den Hypervisor müssen auf dem Thin Client die entsprechenden Zugriffsprotokolle wie das RDP-Protokoll oder ICA installiert sein. Die Installation der notwendigen Software und die Verwaltung der Thin Clients erfolgt zentral in den virtuellen Maschinen auf dem Hypervisor.

4.3.2 Datensicherheit

Wie bereits erwähnt sind in Thin Clients normalerweise keine Festplatten verbaut. Alle benötigten Daten, wie beispielsweise Betriebssystem, Programme und spezielle Benutzerdaten, liegen in der virtuellen Maschine auf dem Server. Dieser Aspekt sorgt bei Thin Clients für eine hohe Sicherheit der Daten, die sich im Regelfall im virtuellen Desktop bzw. auf einem speziellen File-Server befinden. Beides ist im Normalfall wesentlich besser abgesichert, als ein Fat Client.
Ein Diebstahl des Thin Clients, um an wichtige gespeicherte Daten zu gelangen, wäre vollkommen sinnlos, da lokal keine Daten gespeichert werden können. Desweiteren wird für dessen Verwendung ein Server notwendig ist, zur privaten Verwendung ist ein Thin Client somit nutzlos.
Ein weiteres Szenario ist der Befall durch Viren, Würmern und Trojaner. Wie im Kapitel 2.4 beschrieben, verankern sich diese heimlich in Dateien des Betriebssystems, was daher auf Thin Clients nicht möglich ist. Der Angriff müsste somit direkt auf dem Server erfolgen, um die Arbeitsumgebungen zu infizieren. Serverumgebungen sind im Regelfall wesentlich besser geschützt als einzelne Clients. Zum einen liegt dies an der besseren Kontrolle durch das IT-Management und zum anderen an der wesentlich geringeren Anzahl.
Um die Daten auf einem Fat Client zu sichern muss zuvor lokal eine spezielle Software installiert werden. Die virtuellen Maschinen können stattdessen normalerweise in den üblichen firmeninternen Sicherungsmechanismus (z.B. Backup-Server) eingebunden werden. Alternativ wird häufig zur Speicherung der benutzerspezifischen Daten ein spezieller Datenserver verwendet, der noch zusätzliche Sicherungsmöglichkeiten bietet. Bei allen Datensicherungen und Datenwiederherstellungen ist der Thin Client unbeteiligt, relevant sind nur die verwendeten virtuellen Arbeitsumgebungen.

da die virtuelle Maschine lokal auf dem Fat Client gespeichert ist, um sie außerhalb des Netzwerks verwenden zu können

4.3.3 Netzwerk-Sicherheit

Bei Thin Clients gibt es aus Sicht des Netzwerks noch einige entscheidende Sicherheitsvorteile. Virenscanner und andere Sicherheitsprogramme, wie beispielsweise Malware-Scanner, müssen nur auf dem oder die Server installiert und regelmäßig aktualisiert werden. Die Pflege bzw. Aktualisierung aller einzelnen Clients ist nicht notwendig. Dazu gehören beispielsweise auch Software-Firewalls, die denen je nach Bedarf Regeln angepasst werden müssen. Wenn diese Firewall-Regeln nur auf einem oder wenige Server gepflegt werden müssen, es ist weniger zeitintensiv und nicht so sehr Fehleranfällig.
Die firmeninterne Verbindung zwischen Thin Client und Hypervisor erfolgt wie bereits beschrieben über das RDP- oder ICA-Protokoll. Bei RDP lässt sich die Stärke der Verschlüsselung einstellen. Es kann beispielsweise ausgewählt werden, ob nur die Verbindung zum Server verschlüsselt werden soll um die sichere Übertragung von Passwörtern zu gewährleisten oder ob die Verbindung in beiden Richtungen verschlüsselt ist, um eine größere Sicherheit zu erreichen. Letztes hat nur den Nachteil, dass dadurch die Geschwindigkeit verlangsamt wird. Für sichere Verbindungen von Extern bietet Remote Desktop die Verbindung über SSL-Verschlüsselung. Zusätzlich wurde mit Microsoft Vista und Windows Server 2008 Network Level Authentication (NLA) als neue Authentifizierungsmethode eingeführt. Dies führt zu mehr Sicherheit, da die Remoteverbindung erst vollständig hergestellt wird, wenn die Authentifizierung erfolgreich war. Bei der Verwendung von Citrix XenApp wird ab Version 6.0 die Verschlüsselung mit Citrix ICA Encryption Services verwendet. Ab Version 6.20 wird zusätzlich SSL-Verschlüsselung und HTTPS-Browsing unterstützt. TLS-Verschlüsselung wird seit der Version 6.30 unterstützt.
Seit kurzem gibt es beispielsweise von dem Hersteller IGEL Thin Clients mit WLAN. Daher gewinnt auch die Verschlüsselung von WLAN-Verbindungen für Thin Clients an Bedeutung. Dazu wird bevorzugt WPA- und WPA2-Verschlüsselung verwendet.
Daraus ist erkennbar, dass die Angriffsfläche im Gegensatz zu Fat Clients wesentlich geringer ausfällt. Die Priorität liegt in der Absicherung der verwendeten Server, eine separate Absicherung der Thin Clients ist nicht notwendig.

4.3.4 Sonstige Sicherheitsaspekte

Wie bereits bekannt, wird auf Thin Clients keine Software installiert. Dies mindert somit das Risiko, dass Lücken in verschiedener Software ausgenutzt werden kann. Beispielsweise bei den Programmen Adobe Reader, Adobe Flash Player oder Oracle Java Runtime Enviroment werden regelmäßig Sicherheitslücken entdeckt, was zu wöchentlichen bis monatlichen Sicherheitsupdates der jeweiliges Programme führt. Das diese Programme standardmäßig auf jedem Client verfügbar sind bzw. sein müssen, stellen fehlende regelmäßige Aktualisierungen ein weiteres Sicherheitsrisiko dar. In Thin Client Umgebungen können die Sicherheitsupdates mit Hilfe entsprechender Management Software in den virtuellen Maschinen installiert werden.
Ein weiterer wichtiger Sicherheitsaspekt ist die Rechteverwaltung. Bei der Verwendung von Fat Clients erhalten die Benutzer in (zu) vielen Fällen Administratorrechte auf den Geräten, wodurch bösartige Software, die im Hintergrund läuft, diese Rechte übernehmen kann und somit gravierende Schäden im System anrichten kann. Anwender von Thin Clients bekommen ausschließlich Benutzerrechte, wodurch heimliche Eingriffe und Änderungen des Systems verhindert werden. Durch die fehlenden Rechte und Speichermöglichkeit können auch keine Software-Keylogger angewendet werden. Diese werden immer häufiger verwendend um Login-Daten, Passwörter und Kontoinformationen auszuspähen.
Die Authentifizierung sollte ebenfalls betrachtet werden, da Anwender und Administratoren aber auch Hacker sich dadurch Zugang zu Servern und Daten verschaffen. Standardmäßig wird die Passwort-Authentifizierung, die beispielsweise bei der Windows-Anmeldung üblich ist, verwendet. Bei dieser Methode stellt der Client, durch die bereits erwähnten Keylogger, sowie der Anwender, der das Passwort kennt, eine Sicherheitslücke dar. Daher werden immer häufiger Alternativen angeboten und verwendet, wie zum Beispiel Fingerabdruckscanner, USB-Token oder Smartcards. In vielen Thin Clients werden mittlerweile immer häufiger Smartcard-Reader verbaut, da in einzelnen Firmen bereits mit Smartcards gearbeitet wird. IGEL liefert zusätzlich eigene Smartcards aus, die für die Authentifizierung an deren Thin Clients verwendet werden können. Sobald die Karte erkannt und die zugehörige PIN-Nummer eingegeben wird, kann der Benutzer auf die bereitgestellten Anwendungen zugreifen, beim Entfernen der Karte wird die Sitzung sofort gesperrt.

5 Vergleich zwischen Fat Clients und Thin Clients

Thin Client Fat Client
Betriebssystem und Software Zentral (Server) Lokal
Lizenzen spezielle Netzwerklizenzen "normale" Einzelplatzlizenzen
Kosten günstiger ca. 1000 - 1200 €
Stromverbrauch 16 Watt 180 Watt
Nutzungsdauer ca. 7-8 Jahre ca. 3-4 Jahre
Installationsaufwand gering, Konfiguration vom Server Komplettes System muss aufgesetzt werden
Wartung Erfolgt über den Server Muss am Client selbst erfolgen
Administration Thin Client wird direkt am Server konfiguriert Administrator braucht die Freigabe des Mitarbeiters um an den Client zu kommen
Netzwerk Auf das Netzwerk angewiesen Kann ohne Netzwerkverbindung verwendet werden
USB häufig vorhanden, muss vom Server gemountet werden bei 99% aller Geräte vorhanden
Schadsoftware Praktisch immun gegen Viren, Trojaner, usw. Muss gesondert gesichert werden
Mobilität an Arbeitsort/Firmennetzwerk gebunden Kann praktisch überall verwendet werden
Updateaufwand Updates werden lediglich auf dem Server installiert Updates müssen auf jedem Client und dem Server installiert werden

Daraus lässt sich erkennen, dass Thin Clients sowohl unter dem Aspekt der Sicherheit wie auch Kosten- und Energieeinsparungen einige Vorteile gegenüber Fat Clients bietet. Bei der Verwendung von Thin Clients sind hingegen Nachteile in Bezug auf die Mobilität und Individualität zu beachten. Da es hier aber vorrangig um die Sicherheitsaspekte geht, schneidet der Thin Client wesentlich besser ab. Natürlich kann ein Fat Client auch sehr gut abgesichert werden, es ist nur je nach Anzahl der Clients ein höher Zeit- und Kostenaufwand vorhanden. Auch der Thin Client ist nicht zu 100% sicher, mittels eines oder mehrerer Server lässt sich ohne großen zusätzlichen Zeit- und Kostenaufwand ein hoher Sicherheitsstandard erreichen.

6 Fazit

In der Desktop-Virtualisierung gibt es viele Sicherheitsaspekte, die je nach Aufbau der VDI unterschiedlich betrachtet werden müssen. Diese sind häufig aus anderen Bereichen der IT bereits bekannt. Grundsätzlich gilt es die Verfügbarkeit der Desktops, die Vertraulichkeit der Informationen und die Korrektheit der Daten sicherzustellen. Dies erreicht man durch verschiedene Ansätze. Die Server werden hochverfügbar gemacht um das Ziel eines nahezu ununterbrochenen Betriebs sicherzustellen. Mit Verschlüsselungen der Verbindungen zu den virtuellen Maschinen, Authentifizierung und Autorisierung der Benutzer wird versucht die Vertraulichkeit der Daten sicherzustellen. Dies ist insbesondere bei mobil eingesetzten Clients von enormer Bedeutung, da diese oftmals über fremde Netzwerke (Internet) mit dem Firmennetzwerk verbunden werden. Durch Backups soll eine Sicherheit vor Datenverlust garantiert werden. Durch die regelmäßige Aktualisierung des Hypervisors soll verhindert werden, dass die Kontrolle der Ressourcen und die Isolation der virtuellen Maschinen ausgehebelt wird. Um Guest-Hopping Angriffe abzuschwächen, sollten virtuelle Clients und Server physikalisch voneinander getrennt werden. Dies entspricht dem empfohlenen Vorgehen bei nicht virtuellen Umgebungen. Werden virtuelle Netzwerke eingerichtet, so sollte auch eine Firewall diese absichern. Jedoch bringt die Virtualisierung nicht nur Vorteile mit sich, denn durch das Vorhandensein zusätzlicher Software entsteht auch mehr Angriffsfläche für potentielle Angreifer. Bei der Umsetzung der VDI hat man die Wahl zwischen verschiedene Arten von Clients. Je nach Art des Clients unterscheiden sich hier die zu beachtenden Sicherheitsaspekte. Werden Fat Clients verwendet, muss ein höherer Absicherungsaufwand betrieben werden. Da die virtuelle Maschine gegebenenfalls lokal auf dem Fat Client gespeichert ist und lediglich mit den Daten auf dem Server abgeglichen wird, ist der Fat Client oft Ziel von Wirtschaftsspionage und Diebstahl. Problematisch ist auch, dass zum Beispiel bei längeren Dienstreisen lange kein Backup der lokalen Daten durchgeführt wird und die Integrität der Daten, die dem Fat Client zur Verfügung stehen nicht mehr gewährleistet ist. Außerdem sind Fat Clients anfällig für Malware und Keylogger. Werden Thin Clients eingesetzt entfallen diese Sicherheitsbedenken fast komplett, da keine lokale Speicherung von Daten erfolgt. Hinzu kommt, dass die Kommunikation zwischen Thin Client und Server verschlüsselt erfolgt, was beispielsweise Man-in-the-Middle Attacken erschwert. Ein weiterer sicherheitskritischer Aspekt betrifft Softwareupdates, während bei Thin Clients der Administrator entscheiden kann, wann Updates durchgeführt werden, muss ein Fat Client warten bis er wieder eine Netzwerkverbindung aufbauen kann.
Abschließend ist zu sagen, dass die Desktop-Virtualisierung die Komplexität der Infrastruktur erhöht, wodurch mehr Sicherheitsmaßnahmen erforderlich sind.

7 Endnoten

  1. 1,0 1,1 1,2 vgl. Bundesamt für Sicherheit in der Informationstechnik
  2. vgl. IETF (2011)
  3. vgl. Goldberg (1972)
  4. vgl. Miller (2010)
  5. vgl. Lieberwirth (2010)
  6. vgl. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1244 (12.06.2011, 16:55)
  7. vgl. VMware (2010)
  8. vgl. VMware (2009)
  9. vgl. Oberheide (2008)
  10. 10,0 10,1 vgl. VMware (2011)
  11. vgl. Bachfeld (2011)
  12. vgl. http://www.realvnc.com/docs/rfbproto.pdf (18.06.2011, 20:56)
  13. vgl. http://support.microsoft.com/kb/275727/en (18.06.2011, 20:56)
  14. vgl. ftp://ftp.uibk.ac.at/pub/uni-innsbruck/th-physik/Manuscripts/ICAunix-de.pdf (S. 18 ff) (18.06.2011, 20:56)
  15. vgl. http://www.sun-rays.org/lib/hardware/sunray/ds/sunray3plus-ds-065316.pdf (18.06.2011, 20:56)
  16. vgl. ftp://ftp.leadtek.com.tw/entertainment_graphics/Manual/090410/WinFast_VP200_PCoIP_User_Guide_Series_1-Vol_I.pdf (18.06.2011, 20:56)
  17. vgl. http://www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf (23.06.11 19:29)
  18. vgl. http://www.cio.de/news/wirtschaftsnachrichten/2276946/ (19.06.2011)
  19. vgl. it-business
  20. http://www.igel.com/fileadmin/user/upload/documents/PDF_files/Datasheets_DE/DS_UD3_83-DE-11-11.pdf (23.06.11 19:27)

8 Abkürzungsverzeichnis

Abkürzung Bedeutung
TFTPTrivial File Transfer Protocol
RDPRemote Desktop Protocol
OSI-Modell Open Systems Interconnection Reference Model

9 Abbildungsverzeichnis

Abb.-Nr. Abbildung
1OSI-Schichtenmodell
2Aufbau einer Virtual Desktop Infrastructure
3Hypervisor Typ1
4Hypervisor Typ2
5Live Migration-Attack
6Aufbau eines Virtuellen Netzes
7RSA SecurID 700
8Cryptokart KT-Serie
9RSA SecurID 800
10Yubikey
11Die Hardwareabstraktionsschicht
12VPN Tunnel
13Vorderansicht des Igel UD3
14Rückansicht des Igel UD3

10 Tabellenverzeichnis

Tabelle Nr. Quelle
1 Vorteile und Nachteile der Servervirtualisierung
2 Vorteile und Nachteile der Anwendungsvirtualisierung
3 Vorteile und Nachteile der Desktop-Virtualisierung
4 Verbindungsprotokolle und deren Verschlüsselung
5 Vergleich von Herstellern verschiedener Authentifizierungsmöglichkeiten
6 Hardwarespezifikationen von Thin Clients
7 Vergleich Thin Client und Fat Client

11 Literatur- und Quellenverzeichnis

Kurzverweis Quelle
Bachfeld (2011) Bachfeld, Daniel: Cracker-Bremse / Passwörter unknackbar speichern http://www.heise.de/security/artikel/Passwoerter-unknackbar-speichern-1253931.html (18.06.2011, 21:20)
Bundesamt für Sicherheit in der Informationstechnik Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz - Basis für Informationssicherheit https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/allgemein/einstieg/01001.html (07.06.2011, 19:47)
Cio (2011) Cio: Hacker-Attacke gegen Lockheed Martin http://www.cio.de/news/wirtschaftsnachrichten/2276946 (23.06.2011, 13:34)
Cryptocard (2011) http://www.cryptocard.com (23.06.2011, 13:34)
Cryptoshop (2011) http://www.cryptoshop.com/index.php (23.06.2011, 13:34)
Eckert (2010/2011) Eckert, C. Kapitel 7: Zugriffskontrolle und Virtualisierung http://www.sec.in.tum.de/assets/lehre/ws1011/itsec/itsec-kap07-zugriffskontrolle-20110127.pdf (06.06.2011, 22:09)
Entrust (2011) http://www.entrust.com (23.06.2011, 13:34)
Goldberg (1972) Architectural Principles for Virtual Computer Systems http://www.dtic.mil/cgi-bin/GetTRDoc?AD=AD772809&Location=U2&doc=GetTRDoc.pdf (11.06.2011, 14:34)
IBM Systems (2005) IBM Systems: Virtualization Version 2 Release 1 http://publib.boulder.ibm.com/infocenter/eserver/v1r2/topic/eicay/eicay.pdf (02.06.2011, 15:15)
IT-Wissen http://www.itwissen.info/definition/lexikon/independent-computing-architecture-ICA.html (10.06.2011, 18:50)
indevis (2011) http://www.indevis.de (23.06.2011,13:34)
IETF (2011) http://www.ietf.org/ (23.06.2011, 15:00)
Kaspersky Kaspersky, Eugene: Malware: Von Viren, Würmern, Hackern und Trojanern und wie man sich vor ihnen schützt, Carl Hanser Verlag GmbH & CO. KG (6. Auflage März 2008)
Lieberwirth (2010) Lieberwirth, Frank Castro: Microsoft Hyper-V für Windows Server 2008 R2 – Das neue Service Pack zur TechEd 2010 http://www.searchdatacenter.de/themenbereiche/virtualisierung/loesungen/articles/288983/ (06.06.2011, 22:09)
PC Welt http://www.pcwelt.de/ratgeber/Desktop-im-Server-Was-bringt-Desktop-Virtualisierung-wirklich-37597.html (07.06.2011, 19:47)
Manager-Magazin http://www.manager-magazin.de/unternehmen/it/0,2828,485487,00.html (13.06.2011 17:33)
Miller (2010) Miller, Wes: Desktopvirtualisierung: Pflege und Haltung virtueller Umgebungen http://technet.microsoft.com/de-de/magazine/ff686691.aspx (05.06.2011, 14:09)
Oberheide (2008) Jon Oberheide / Evan Cooke / Farnam Jahanian: Empirical Exploitation of Live Virtual Machine Migration http://jon.oberheide.org/files/blackhat08-migration.pdf (06.06.2011, 22:09)
Runge Roland Runge, Christian Sturm, Nadin Ebel und Stefan Wißkirchen von Addison-Wesley: VMware Infrastructure 3 im Business-Umfeld: Virtualisierung von mittleren und großen Umgebungen mit VMware ESX 3.5 und ESXi 3.5, Addison-Wesley (München 2008)
RSA Authentifikatoren (2011) http://www.indevis.de/dokumente/rsa_authenticators.pdf (23.06.2011, 13:34)
RSA (2011) http://www.rsa.com (23.06.2011, 13:34)
Secunet (2011) http://www.secunet.com/fileadmin/user_upload/Download/Printmaterial/Factsheets/deutsch/sn_SINA_VW_FS_D.pdf (23.06.2011, 13:34)
Tech Republic http://www.techrepublic.com/article/the-pros-and-cons-of-server-virtualization/5057662 (07.06.2011, 19:47)
tecchannel (2009) http://www.tecchannel.de/server/virtualisierung/2020056/virtualisierung_sicherheit_firewall_angriff_attacke_virtuelle_maschine/ (23.06.2011, 15:12)
van Wasen van Wasen, Tim: Virtualisierung von Desktops versus Terminalserver: Technische und ökonomische Gegenüberstellung, Diplomica Verlag (2010)
VMware (2010) VMware Knowledge Base: Understanding virtual machine snapshots in VMware ESX http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180 (11.06.2011, 17:41)
VMware (2009) VMware: High Availability http://www.vmware.com/files/pdf/VMware-High-Availability-DS-EN.pdf (23.06.2011 13:38)
VMware (2011) VMware: VMware vShield App http://www.vmware.com/products/vshield-app/features.html (20:48 18.06.2011)
Yubico (2011) http://www.yubico.com (23.06.2011, 13:34)


Persönliche Werkzeuge