Sicherheitsrelevante Aspekte des Cloud Computing

Aus Winfwiki

Name des Autors / der Autoren:	Oliver Heckert, Andreas Horst, Jens Lagemann, Melanie Wölfle
Titel der Arbeit:	"Sicherheitsrelevante Aspekte des Cloud Computing"
Hochschule und Studienort:	FOM Leverkusen

Inhaltsverzeichnis

1 Abkürzungsverzeichnis
2 Abbildungsverzeichnis
3 Einleitung
4 Begriff und Entstehung Cloud Computing
5 Sicherungsschichten innerhalb von Cloud Computing Infrastrukturen
6 Sicherungsmaßnahmen verschiedener Cloud Computing Anbieter
7 Fazit
8 Fußnoten
9 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
AES	Advanced Encryption Standard
AIP	Application Infrastructure Provider
ALC	Access Control List
API	Application Programming Interface
ARP	Address Resolution Protocol
ASP	Application Service Provider
AWS	Amazon Web Services
BDSG	Bundesdatenschutzgesetz
BSP	Business Service Provider
CPU	Central Processing Unit
CRC	Cyclic Redundancy Check
CRM	Customer Relationship Management
DB	Database
DDoS	Distributed Denial-of-Service
DES	Data Encryption Standard
DNS	Domain Name System
DOS	Denial-of-Service
FSR	Final Security Review
FTP	File Transfer Protocol
HA	High Availability
HRG	Harvard Research Group
HTTP	Hypertext Transfer Protocol
IBS	Internet Business Service
IDS	Intrusion Detection Systeme
IEC	International Electrotechnical Commission
I/O	Input/Output
IP	Internet Protocol
ISO	International Organization for Standardization
JVM	Java Virtual Machiene
MITM	Man In the Middle
OSR	Operational Security Review
OSSC	Online Services Security and Compliance Team
PaaS	Platform as a Service
RAID	Redundant Array of Independent Disks
RFCs	Request for Comments)
SaaS	Software as a Service
SAN	Storage Area Network
SAS	Statement of Auditing Standard
SDL	Security Development Lifecycle
SPI	Software, Plattform und Infrastruktur
SQL	Structured Query Language
SSH	Secure Shell
SSL	Secure Sockets Layer
SYN	Synchronize
TCP	Transmission Control Protocol
UDP	Internetwork Datagram Protocol
USA	United States of America
VLAN	Virtual Local Area Network

2 Abbildungsverzeichnis

Abbildung-Nr.	Abbildung
Abbildung 1	Übersicht über Cloud Computing
Abbildung 2	Cloud Computing Infrastrukturen
Abbildung 3	Storage Area Network
Abbildung 4	Paketfilter
Abbildung 5	Anwendungsschicht-Gateway
Abbildung 6	Proxy-Server
Abbildung 7	Man in the middle Angriffe
Abbildung 8	IP Spoofing
Abbildung 9	Beispiel Zertifikat der Deutschen Postbank AG
Abbildung 10	öffentlicher Schlüssel der Deutschen Postbank AG
Abbildung 11	Mircosofts Azure Plattform
Abbildung 12	Microsoft Kundengruppierung innerhalb der Cloud Infrastruktur
Abbildung 13	Prozess des "Security Lifecycle Development"
Abbildung 14	Übersicht der betrachteten Cloud Computing Anbieter

3 Einleitung

Cloud Computing ist in den letzten Monaten in Bereichen der Informationstechnologie ein gern verwendeter Begriff, um unbegrenzte Skalierbarkeit von IT-Ressourcen mit weniger Fixkosten zu beschreiben und damit Daten von überall auf der Erde abzurufen.

Jedoch unterscheiden sich die einzelnen Definitionen so stark voneinander so dass kein eindeutiger Begriff für Cloud Computing und dessen einzelnen Formen gefunden werden. Dieser Trend ist nicht neu, da ähnliche Konzepte in der Vergangenheit bereits existierten. So zum Beispiel als Software as a Service (SaaS) oder Computing on Demand. All diese Konzepte spiegeln sich in Teilen im Cloud Computing wieder.

Cloud Computing soll in der heutigen Zeit nicht nur einzelne Aspekte wie SaaS oder PaaS (Platform as a Service) umfassen, sondern frühere Formen integrieren, um damit einen Mehrwert für den Kunden zu bilden ohne das der Kunde besondere Kenntnisse oder Hilfsmittel hinsichtlich der Nutzung benötigt.

Im Rahmen von Cloud Computing stehen vor allem Skalierbarkeit und die verschiedenen Vertriebsmodelle wie Software as a Service, Platform as a Serviec und Infrastructure as a Service im Vordergrund, wobei sich die einzelnen Definitionen so stark voneinander unterschieden, dass bislang kein eindeutiger Begriff für Cloud Computing und dessen einzelnen Formen gefunden wurde. Gleichzeitig besteht auf Seiten der Kunden immer noch eine Ungewissheit gegenüber der Datensicherheit und –verfügbarkeit innerhalb der Cloud.

Aufgrund dieser Ungenauigkeiten wollen wir in der folgenden Arbeit das Thema Cloud Computing näher betrachten und die verschiedenen Ausprägungen des Cloud Computing näher darstellen. Zunächst werden wir einen Überblick über Cloud Computing im allgemeinen, sowie der einzelnen Ausprägungen verschaffen. Darauf folgen Beschreibungen diverser Sicherheitsrisiken, derer sich Cloud Computing Anbieter annehmen und versuchen eben diese möglichst klein zu halten. Im weiteren Verlauf gehen wir auf einzelne Anbieter ein und deren Produkte bezüglich Cloud Computing. Hierzu haben wir im Vorfeld einige Firmen (Microsoft, Amazon, Sun, IBM) ausgewählt, die unterschiedliche Cloud Computing Dienstleistung anbieten und zu den sogenannten Global-Playern zählen. Anhand der getätigten Angaben dieser Anbieter werden wir einen Vergleich ziehen, um zu ermitteln wie mit dem Thema Sicherheit, Allgemein und im Speziellen, umgegangen wird.

4 Begriff und Entstehung Cloud Computing

Der Begriff des Cloud Computing ist bisher nie fest definiert worden, verschiedene Unternehmen versuchen den Begriff für sich zu beanspruchen und Ihre Dienstleistungen darüber zu identifizieren. Man kann jedoch davon ausgehen, dass der Begriff des Cloud Computing durch die in der Literatur häufig verwendete Darstellungsform für das Internet als Wolke entstanden ist^[1].

Allgemein beschreibt dieser Begriff eine neue evolutionäre Stufe der Nutzung von Rechnern und Rechnernetzwerken. Es werden dabei Hardware-, Software- und Informationstechnische Ressourcen von einander getrennt um Infrastrukturen zu etablieren, die es ermöglichen skalierbare und kostenreduzierende Anwendungen und Rechenleistung bereitzustellen. Internetdienste, Anwendungen, Informationsarchitekturen und Infrastrukturen können somit in kürzester Zeit zusammengebracht werden.

Vorteilhaft sind dabei vor allem die Skalierbarkeit und das unproblematische Nachrüsten auf Anfrage. Dies unterstützend sind Cloud Computing Dienstleistungen meist virtualisiert, was ebenfalls die Dynamik der bereitgestellten Anwendungen und ihre Mobilität stärkt.

Im Vordergrund steht wie auch im Grid Computing das Outsourcing, zumindest im weitesten Sinne, da lediglich für den Zugriff auf externe Ressourcen investiert werden muss, jedoch nicht für die einzelnen bereitgestellten Mittel wie Server, Personal, Software und weitere anfallenden Kostenstellen. Es werden Ressourcen, Dienste und Applikationen bereitgestellt, die beispielsweise in Form von Rechenzeit auf den Servern von Cloud Computing Anbietern verkauft werden. Diese zur Verfügung gestellten Dienstleistungen erheben je nach Vertragslage den Anspruch, zu jeder Zeit an jedem Ort erreichbar zu sein^[2].

Es stellt sich immer noch die Frage, in wie weit sich Cloud Computing von bisherigen Modellen wie dem Grid Computing unterscheidet oder welche gleichen Ansätze es gibt.
Hinter Grid Computing steht der Ansatz, nicht genutzte Rechenleistung anderen Personen Unternehmen oder Organisationen zur Verfügung zu stellen, wobei die Art der Rechnerarchitektur möglichst keine Rolle spielen soll. Es sollen also beliebig viele verschiedenartige Rechnerarten angebunden werden können, die üblicherweise diversen Organisationen, wie öffentlichen Einrichtungen, Forschungsinstituten, oder ähnlichen angehören. „Grid Computing ist seit Ende der Neunzigerjahre eine Technik zur Integration und gemeinsamen, institutionsübergreifenden, ortsunabhängigen Nutzung von Rechenleistung, Speicherkapazität, Datenbanken, Lizenzen und so weiter über das Internet.“^[3]

Bei der Implementierung von Grid Computing Systemen besteht die größte Herausforderung darin, einheitliche Standards zu schaffen über die die verschiedenen Rechnersysteme miteinander kommunizieren können, die sogenannte Middleware. Dabei werden allgemeingültige Definitionen von Diensten und Protokollen definiert die die gemeinsame Zusammenarbeit erst ermöglichen^[4].

Abbildung 1: Übersicht über Cloud Computing^[5]

Cloud Computing Dienste basieren auf fünf grundlegenden Eigenschaften die teilweise aus den Ansätzen des Grid Computing entstammen.

Abstraktion der Infrastruktur: Jegliche bereitgestellten Ressourcen, also Rechnersysteme, Netzwerke oder Speicherkapazitäten sind unabhängig von den anwendungs- und informationstechnischen Ressourcen. An welchem Ort oder auf welchem Rechner Daten gespeichert und bearbeitet werden ist für nutzende Dienste nicht ersichtlich. Dies ist nötig um unterschiedlichste Dienste unabhängig vom Mietverhältnis der Ressourcen bereitstellen zu können. Die Umsetzung solcher infrastruktureller Anforderungen erfolgt in der Regel durch Virtualisierung auf verschiedenen Ebenen.
Allgemeine Ressourcenverfügbarkeit: Die Trennung von Ressourcen und Anwendungen führt dazu, dass alle Dienste die Zugriff auf eine Cloud Computing Infrastruktur besitzen auch auf deren gesamte Ressourcen zugreifen können, sofern entsprechende standardisierte Zugriffsmethoden genutzt werden.
Service Oriented Architecture: Durch die Trennung von Anwendungen von der Infrastruktur werden Dienstorientierte Architekturen geschaffen, welche über standardisierte Protokolle auf gemeinsam genutzte Ressourcen zugreifen können, wobei die Bereitstellung des Dienstes und nicht die Verwaltung der Infrastruktur im Vordergrund steht.
Dynamisierung / Skalierbarkeit: Cloud Computing basiert auf dem „on-demand model“ ^[6], also auf der Möglichkeit ohne großen Aufwand per Nachfrage weitere Dienste oder Zugriffsmöglichkeiten auf Dienste beispielsweise im Sinne von Benutzerkonten zukaufen beziehungsweise hinzumieten zu können. Dies wird ermöglicht durch einen hohen Grad der Automatisierung und Virtualisierung der nahezu überall verfügbaren Dienste.
Nutzungsbezogene Kostenmodelle: Die Trennung von Infrastruktur und Anwendungen, die gemeinsame Nutzung von Ressourcen, der hohe Grad der Automation und Virtualisierung sowie die einfache Skalierbarkeit von Applikationen führen dazu, dass kosteneffiziente Kostenmodelle angeboten werden können. Bei diesen Modellen Zahlt der Nutzer beispielsweise nur den genutzten Speicher oder die verwendeten Rechenressourcen^[7].

4.1 Cloud Computing Vertriebsmodelle

Es gibt drei verschiedene Vertriebsmodelle für Cloud Computing Dienste. Sie bestehen aus den verschiedenen Ebenen der Cloud Computing Architektur und gehören dadurch gewissermaßen zusammen. Zum einen gibt es das Modell Software as a Service, welches an der architektonischen Spitze des Cloud Computing steht und da es auf den anderen beiden Modellen aufbaut nur mit Ihnen zusammen verkauft beziehungsweise vermietet werden kann. Die nächst tiefere Ebene nennt sich Platform as a Service, welche ebenfalls nur zusammen mit der darunter angesiedelten Ebene des Infrastructure as a Service Modells vertrieben werden kann. Diese Ebene stellt zwar die Grundlage der anderen Modelle dar, kann jedoch auch unabhängig von ihnen genutzt werden. In diesem Fall muss sich jedoch der Kunde selbst um den Aufbau der weiteren Architektur kümmern.
Diese drei Modelle werden oft auch als „SPI“-Modell bezeichnet, was für Software, Platform und Infrastructure steht^[8].

4.1.1 SaaS

Software as a Service, auch bekannt unter der Bezeichnung ASP (Application Service Provider) ist eine in den letzten Jahren immer stärker werdende Art Software zu vertreiben.
Der Begriff Software as a Service ist wie auch der des Cloud Computing nicht einheitlich definiert. Das Verständnis des Begriffs wandelt sich immer weiter, da Unternehmen immer neue Bedeutungen erfinden beziehungsweise diese erweitern, um technologische Fortschritte oder Verkaufsstrategien anzupreisen. Beispiele hierfür sind die oben schon genannten ASP, Application Infrastructure Provider (AIP), Internet Business Service (IBS), Business Service Provider (BSP) und viele mehr.

Diese Verkaufs oder Unternehmensstrategien verfolgen alle das gleiche Ziel. Hinter ihnen steckt die Idee, den Zugriff auf kommerzielle Software zu verkaufen.
Software die folgende Eigenschaften erfüllt wird in der Regel als Software as a Service vertrieben:

Anwendungsausrichtung: Der Hauptnutzen wird durch einen Dienst bereitgestellt, der Zugriff und Verwaltung auf eine kommerzielle Anwendung erlaubt.
Verkauf des Zugriffs: Eine der wichtigsten Eigenschaften ist, dass Kunden den Zugriff auf eine Anwendung erhalten, ohne dass sie Kosten für Serverumgebungen, Lizenzen, Personal oder weitere benötigten Ressourcen aufwenden müssen. Der Anbieter von SaaS Leistungen muss dafür Sorge tragen, dass sich die vertriebene Software entweder in seinem Besitzt befindet, oder er im Besitz entsprechender Lizenzen ist.
Dies ist der zentrale Unterschied zu klassischen Outsourcing Lösungen, bei denen der Kunde in der Regel auch für Hardware, Wartung und weitere anfallende Investitionen aufkommen muss.
Zentrale Verwaltung: Die Anwendungsverwaltung findet an einer zentralen Stelle statt und somit nicht in jeder Niederlassung des Kunden.
Streuung: Ein Dienst soll von einer Zentralen Stelle aus möglichst viele Nutzer erreichen.
Vertragssicherheit: Es gibt in der Regel immer mehrere Organisationen die an der Distribution eines Dienstes beteiligt sind. Beispielsweise ein Unternehmen, welches Hardware bereitstellt, eines das das Netzwerk verwaltet und eines, welches die Software zur Verfügung stellt.
Die Instanz mit der der Kunde einen Vertrag abschließt, hat dafür zu sorgen, dass die gekauften Zugriffe auf die Anwendung wie vereinbart ermöglicht werden^[9].

Zusammengefasst ist Software as a Service die Möglichkeit über sogenannte „thin Clients“, z.B. einen Internet Browser, auf Anwendungen zuzugreifen die auf der Infrastruktur des Cloud Computing Anbieters betrieben werden, wobei sich Nutzer nicht um die Verwaltung der darunterliegenden Architekturebenen kümmern müssen.
SaaS-Dienste lassen sich am wenigsten vom Kunden selbst anpassen oder erweitern, stellen dafür jedoch das höchste Maß an Schutzmaßnahmen bereit^[10]^[11].

4.1.2 PaaS

Bei Platform as a Service wird dem Nutzer eine Infrastruktur bereit gestellt auf der er selbst Anwendungen bereitstellen oder in den vom PaaS-Dienstleister unterstützten Programmiersprachen entwickeln kann. Der Nutzer hat zwar ebenfalls wie bei Saas keinen Einfluss auf die darunter liegende Infrastruktur, er kann jedoch selbst über die eingesetzte Software bestimmen und diese vollkommen selbst verwalten. Hierdurch lassen sich die Entwicklungszeit und auch die Entwicklungskosten von Software reduzieren, da wie bei großen Softwareprojekten nicht unüblich, keine eigene Infrastruktur aufgebaut werden muss, welche getestet, gewartet und verwaltet werden muss.
Entwickler benötigen lediglich einen Computer mit Internetzugang und können darüber auf fremd gehostete skalierbare Ressourcen zur Softwareentwicklung zurückgreifen. Entwickler müssen hierbei jedoch selbst dafür sorgen, dass entsprechende Sicherheitsstandards umgesetzt werden ^[12].

4.1.3 IaaS

Infrastructure as a Service stellt Nutzern lediglich grundlegende Rechnerkomponenten zu Verfügung. Beispielsweise werden Rechenzeit, Speicherplatz oder Netzwerkumgebungen bereitgestellt auf denen der Nutzer dann Software einrichten kann.
Betriebssysteme und Anwendungen werden ausschließlich vom Nutzer eingerichtet und verwaltet. Teilweise ist es auch möglich selbst für Firewalls und Loadbalancer, sowie weitere Netzwerkkomponenten zu sorgen. Hier ist ein Höchstmaß an Eigenverantwortung gefordert, da vom Anbieter selbst kaum Sicherheitsmaßnahmen bereitgestellt werden können, welcher keinen Einfluss auf die verwendete Software nehmen kann^[13].

4.2 Verschiedene Arten von Cloud Infrastrukturen

Unabhängig von den diversen Vertriebsmodellen gibt es vier verschiedene Arten von Clouds, private, öffentliche, extern verwaltete und hybride.
Im Vorhinein ist noch zu sagen, dass sich die Nutzer von Cloud Diensten in zwei Gruppen aufteilen lassen: Interne und externe Benutzer. Interne Benutzer gehören der Organisationsstruktur des Unternehmens an, welches Cloud Computing Dienste bereitstellt. Dazu gehören Mutterkonzerne, Vertragspartner oder auch Business Partner und alle weiteren die rechtlich gesehen Partner oder Unterorganisationen eines Unternehmens sind.

Externe Nutzer sind diejenigen, welche die Dienstleistungen eines Cloud Computing Anbieters in Anspruch nehmen, jedoch nicht Teil dessen Organisationsstruktur sind.

Abbildung 2: Cloud Computing Infrastrukturen^[14]

4.2.1 Private Clouds

Private Clous sind Unternehmensinterne Clouds, die entweder vom Unternehmen selbst oder einem IT-Dienstleister des Unternehmens bereitgestellt wird. Der alleinige Nutzer der Cloud ist das Unternehmen selbst, also interne Nutzer, wobei trotzdem alle Eigenschaften wie Funktionalität und Skalierbarkeit von Cloud Computing Systemen bereitgestellt werden. Die dafür benötigte Hardware befindet sich im Besitz und auch räumlich gesehen im Unternehmen selbst oder des IT-Dienstleisters^[15].

4.2.2 Öffentliche Clouds

Öffentliche Clouds werden für externe Nutzer von Cloud Computing Anbietern bereitgestellt. Entweder werden Dienste nur für ein bestimmtes oder für mehrere Unternehmen bereit gestellt, wobei auch hier alle bisher beschriebenen Anwendungsmöglichkeiten von Cloud Computing Systemen dazu gehören. Die benötigte Infrastruktur wird in der Regel vom Anbieter selbst bereitgestellt und befindet sich auch räumlich in dessen Obhut.

4.2.3 Extern Verwaltete Clouds

Extern verwaltete Cloud Computing Systeme werden wie auch private Clouds vom nutzenden Unternehmen selbst für interne und externe Benutzer bereitgestellt, wobei ebenfalls keine Abstriche bei den genannten Dienstleistungen gemacht werden. Der Unterschied ist jedoch, dass sich die Hardware im Unternehmen befindet, diese aber von einem externen Unternehmen verwaltet wird^[16].

4.2.4 Hybride Clouds

Hybride Clouds werden sowohl für interne als auch für externe Nutzer zur Verfügung gestellt. Dabei können Informationen und Anwendungen über standardisierte Schnittstellen zwischen verschiedenen Cloud Computing Anbietern ausgetauscht werden, unabhängig von Ort und Besitzer der darunterliegenden Hardware ^[17].

4.3 Virtualisierung

Bei der Virtualisierung werden die Ressourcen eines Rechnersystems aufgeteilt und können von mehreren unabhängigen Betriebssysteminstanzen genutzt werden. Wobei mehrere grundsätzlich verschiedene Konzepte und Technologien existieren die den Begriff Virtualisierung verwenden, siehe Auflistung. Generell benutzt jede Virtuelle Maschine die Ressourcen seines Host Systems mit, jedoch verhält sie sich innerhalb seiner Umgebung wie ein eigenständiger PC mit eigenen Komponenten, wie CPU, Hauptspeicher, Festplatten, Grafikkarte, Netzwerkkarten, usw. Einige Komponenten werden durch das Host System Emuliert und zur Verfügung gestellt zum Beispiel Netzwerkkarten. Andere Komponenten haben direkten Zugriff auf die Ressourcen des Host Systems wie zum Beispiel die CPU und der Hauptspeicher. Für eine installierte Software ist es nicht möglich zu erkennen ob sie nun innerhalb einer Virtuellen Instanz läuft oder ob sie auf wirklicher Hardware läuft. Hierdurch ergibt sich eine bessere Ausnutzung der Ressourcen und eine Serverkonsolidierung. Desweiteren können auch Kosten im Bezug auf Hardware und Verbrauchskosten (Strom, Kühlung) eingespart werden. Neue Instanzen können binnen Minuten gebildet und gestartet werden, diese Option ist auch für die Cloud Computing Provider sehr Interessant. Eine Erweiterung der Hardware ist hier auch sehr einfach zu Realisieren, so kann man dem System einfach neuen Speicherplatz oder Arbeitsspeicher sogar Prozessoren zur Verfügung stellen ohne einen wirklichen Eingriff an der Hardware vorzunehmen. Durch diese Virtualisierungstechniken senken sich auch die Ausfallzeiten im falle eines Hardware defektes auf ein Minimum, da die selbe Instanz auf einem neuen Server einfach wieder hoch gefahren werden kann. Zudem können Snapshots vom aktuellen Zustand einer virtuellen Maschine erzeugt und zu einem späteren Zeitpunkt wieder hergestellt werden. Leider sinkt die Performance eines Virtuellen Systems gegenüber einem realen Systems deutlich. Bei der Serverkonsolidierung können virtuelle Maschinen einen Single Point of Failure darstellen. Beim Ausfall eines Hosts würden mehrere virtuelle Server ausfallen. Ausfallkonzepte und Redundante Installationen sind somit notwendig.

Ist von Virtualisierung die Rede, ist immer mindestens eines der folgenden Konzepte gemeint:

*Applikationsvirtualisierung
*Hardware-Emulation
*Virtueller Maschinen-Monitor
*Paravirtualisierung
*Hardware-Virtualisierung
*Betriebssystem-Virtualisierung bzw. Container

Applikationsvirtualisierung:

Bei der Applikationsvirtualisierung werden Anwendungen lokal, unter Verwendung lokaler Ressourcen in einer virtuellen Umgebung gestartet, die alle Komponenten bereitstellt. Als bekanntestes Beispiel ist hier die Java Virtual Machiene (JVM) zu nennen. Die Applikation ist ist für die Ausführung des Java-Bytecodes verantwortlich, somit kann dieser Bytecode von jeder Plattform ausgeführt werden auf der die Java Virtual Machiene installiert ist. Die Plattformunabhängikeit ist der größte Vorteil dieser Maßnahme gegenüber der nativen Programmausführung.

Hardware-Emulation:

Hierbei wird meistens versucht die komplette Hardwareplattform eines schon existierenden Systems, welches auf einer vollständig anderen Architektur basiert zum Beispiel einem anderen Prozessor, nachzubilden.

Virtual Machine Monitor:

Hierbei werden Hardwareressourcen des Rechners durch Hardware-Emulation an die virtuelle Maschiene übergeben. Somit hat jedes Gast-Betriebssystem einen eigenen virtuellen Rechner mit CPU, Hauptspeicher, Laufwerken, Netzwerkkarten, und so weiter zur Verfügung. Desweiteren werden kaum Änderungen am Hostsystem vorgenommen beispielsweise sind hier VMware Server, VMware Workstation und VMware Fusion zu nennen.

Paravirtualisierung

Bei der Paravirtualisierung wird keine Virtuelle Hardware geschaffen sondern es wird eine abstrakte Verwaltungsschicht, der Hypervisor, geschaffen um auf die physischen Ressourcen wie Speicherplatz, Ein-/Ausgabegeräte und Netzwerkinterfaces zuzugreifen. Bei Paravirtualisierung steht den Gast-Betriebssystemen keine emulierte Hardwareebene zur Verfügung, sondern eine API.

Hardware-Virtualisierung

Hierbei sind Virtualisierungserweiterungen zum Beispiel in der CPU gemeint, die unter dem Begriff Hardwarevirtualisierung zusammengefasst werden können. Intel bezeichnet die Technologie beispielsweise als Intel Virtualization Technology, das Gegenstück von AMD bezeichnet die Technologie als Pacifica bzw. AMD-V.

Betriebssystem-Virtualisierung bzw. Container

Bei der Betriebssystem-Virtualisierung werden Verschiedene Laufzeitumgebungen geschaffen welche alle den gleichen Kernel für die laufenden Anwendungen verwenden. Hierdurch lässt sich eine hohe Performance Realisieren da der Kernel meistens einen direkten Hardwarezugriff besitzt^[18].

5 Sicherungsschichten innerhalb von Cloud Computing Infrastrukturen

Es gibt viele verschiedene Quellen für Risiken im Internet, seien es Angriffe auf Services mit dem Ziel Daten zu zerstören, Serversysteme lahm zu legen und zum abstürzen zu bringen, Datenverlust durch Serverausfälle oder viele mehr.
Unternehmen die im Internet Dienste bereitstellen zur gemeinsamen Arbeit, als Datenspeicher oder auch als Wissensplattformen, versuchen in der Regel eine möglichst hohe Ausfallsicherheit und Verfügbarkeit zu erreichen. Durch Hochleistungsrechenzentren, redundante Datenhaltung und weitere Maßnahmen beispielsweise zum Schutz vor Stromausfällen oder sonstigen Gefahrenquellen schaffen es Unternehmen heutzutage Verfügbarkeitsquoten von über 99% zu erreichen. 100%ige Sicherheit vor ausfällen kann und wird es jedoch niemals geben können. Beispielsweise sind auch große Unternehmen wie Amazon sind trotz starker Sicherheitsmaßnahmen nicht 100%ig vor Ausfällen geschützt, beispielsweise gab es Anfang 2008 (19.02.08) einen Zwischenfall bei dem die „Amazon Simple Storage Services“ für mehrere Stunden nicht erreichbar waren. Von diesem Ausfall waren Tausende Websites und Unternehmen, unter anderem auch das soziale Netzwerk Twitter, betroffen, die keinerlei Möglichkeiten hatten auf Ihre ausgelagerten Datenbestände zuzugreifen^[19].

Im folgenden Abschnitt wird näher auf die Risiken eingegangen vor denen sich Cloud Computing Anbieter versuchen zu schützen, wobei zu beachten ist, dass auch die genannten Sicherheitsmaßnahmen durch kreative und innovative Angreifer ausgehebelt werden können und nie völlige Sicherheit besteht.

5.1 Schicht der physikalischen- und Netzwerksicherung

5.1.1 Physikalische Sicherung

"Bei anderen Anbietern oder Diensten besteht die Gefahr, dass man die Kontrolle über den Zugriff auf seine Daten abgibt. Das technische Personal des Providers kann vollständigen Zugang zu allem haben, was in der Wolke verarbeitet wird. Der Eigentümer verliert in dem Fall die Kontrolle darüber, was mit seinen Daten geschieht und wer genau auf sie zugreifen kann. Generell davon auszugehen, dass Administratoren vertrauenswürdig sind, mag für einfache, unproblematische Anwendungen noch hinnehmbar sein. Aber sobald es um kritische Geschäftsdaten oder datenschutzgesetzlich relevante Informationen geht, bewegt man sich mit dieser Vermutung auf dünnem Eis." ^[20]

5.1.1.1 Ausfallsicherheit / Hochverfügbarkeit

"Ein System gilt als hochverfügbar, wenn eine Anwendung auch im Fehlerfall weiterhin verfügbar ist und ohne unmittelbaren menschlichen Eingriff weiter genutzt werden kann. In der Konsequenz heißt dies, dass der Anwender keine oder nur eine kurze Unterbrechung wahrnimmt. Hochverfügbarkeit (abgekürzt auch HA, abgeleitet von engl. High Availability) bezeichnet also die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten einen uneingeschränkten Betrieb zu gewährleisten."^[21] Wie man an der Tabelle sehen kann bedeutete selbst eine Verfügbarkeit von 99% eine Downtime von pro Jahr 3,7 Tagen.

99 % = 438,3 Minuten/Monat, 7,3 Stunden/Monat oder 87,66 Stunden/Jahr (Verfügbarkeitsklasse 2)
99,9 % = 43,8 Minuten/Monat oder 8,76 Stunden/Jahr (Verfügbarkeitsklasse 3)
99,99 % = 4,38 Minuten/Monat oder 52,6 Minuten/Jahr (Verfügbarkeitsklasse 4)
99,999 % = 26,3 Sekunden/Monat oder 5,26 Minuten/Jahr (Verfügbarkeitsklasse 5)

Je höher die Verfügbarkeit eines Systems sein muss desto mehr finanzielle Mittel werden benötigt. Desweiteren müssen bei den Kunden zusätzliche Redundanzen geschaffen werden um die Cloud Computing Dienste hochverfügbar zu machen, da z.B. 2 getrennte Internetzugänge, am besten noch über 2 Verschiedene Provider, benötigt werden. Die Anzahl der eingesetzten Komponenten steigt unweigerlich zu einer nicht mehr genau erfassbaren Zahl, da der Datenverkehr im Internet nicht genau nachzuvollziehen und dynamisch ist. Da es für ein Datenpaket innerhalb des Internets unendlich viel Möglichkeiten gibt um an das Ziel zu kommen.

Die Harvard Research Group (HRG) teilt Hochverfügbarkeit in sechs Klassen ein:

Conventional: Funktion kann unterbrochen werden, Datenintegrität ist nicht essenziell.
Highly Reliable: Funktion kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein.
High Availability : Funktion darf nur innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit minimal unterbrochen werden.
Fault Resilient: Funktion muss innerhalb festgelegter Zeiten oder während der Hauptbetriebszeit ununterbrochen aufrechterhalten werden.
Fault Tolerant: Funktion muss ununterbrochen aufrechterhalten werden, 24*7-Betrieb (24 Stunden, 7 Tage die Woche) muss gewährleistet sein.
Disaster Tolerant: Funktion muss unter allen Umständen verfügbar sein^[22].

Klassischerweise ist ein Outsourcer über genau definierte redundante Pfande angebunden, dies ist beim Cloud Computing nicht der Fall. Es können unter Umständen mehrere Provider zwischengeschaltet sein ohne das der Kunde an sich etwas von dem Vorgang merkt. Dadurch ist die Überprüfbarkeit durch den Kunden des Cloud computing Providers nur sehr eingeschränkt vorhanden. Über die Verfügbarkeit des ausgelagerten Dienstes muss sich der Kunde im klaren sein. Die Problematik des Single Points of Failure gilt zwar als behoben, jedoch ist die Verfügbarkeit dieses Dienstes von sehr viel mehr Faktoren abhängig als eine Bereitstellung eines Dienstes innerhalb des eigenen Unternehmens^[23].

5.1.1.2 Datenintegrität

Wie stelle ich sicher dass meine übertragenen Daten auch genauso bei dem Cloud Computing Provider angekommen sind. Genau mit dieser Frage beschäftigt sich die Datenintegrität. Es muss sichergestellt werden dass die Daten nicht unvollständig oder verändert beim Provider eintreffen. Dies geschieht meistens durch sogenannte Prüfsummen (z.B. CRC), welche mit Hilfe eines Algorithmus überprüft ob die Bitreihenfolge der gesendeten Daten gleich der Bit folge der empfangenen Datei ist. Sobald sich ein Bit innerhalb der Daten geändert hat ändert sich auch die Prüfsumme der Datei. Ist dies der Fall ist die Datei beschädigt oder verändert worden und wird nicht mehr angenommen und eine erneute Übertragung der Daten ist somit erforderlich. Problematisch wird es wieder wenn man sich erneut den Abschnitt Datensicherheit vor dem Punkt der Datenintegrität durchließt, denn hier stellt man erneut fest das man den physikalischen Zugriff auf die Daten und somit auch Ihre Veränderung durch den Cloud Computing Provider nicht verhindern kann. Über dieses Sicherheitsrisiko muss sich der Kunde genau bewusst sein. Deswegen wird generell auch abgeraten Cloud Computing Dienste für Sensible Daten zu benutzen, da die Datenintegrität nicht gewährleistet werden kann^[24].

5.1.1.3 Datensicherheit

Datensicherheit beschreibt generell den Schutz seiner eigenen persönlichen Daten gegenüber unbefugten dritten. Da Cloud Computing Dienste zumeist auf einem großen System laufen, hat die Datensicherheit natürlich einen sehr hohen Stellenwert, da es hier sonst sehr einfach möglich ist über seine eigenen Daten hinaus auch Daten dritter einzusehen und vielleicht sogar zu Manipulieren (siehe Datenintegrität). Um zu verhindern dass jemand Fremdes auf die von einem selbst bereitgestellten Daten und Programme unbefugten Zugriff nimmt gibt es von den einzelnen Cloud Computing Anbietern verschiedene Sicherheitssysteme. Zwar sind die Daten bei den meisten Anbietern durch eine Firewall sowie eine Benutzerkontensteuerung vor unbefugten Zugriff geschützt, jedoch ist es nicht wirklich möglich die Daten direkt vor dem Anbieter des Cloud Computing Dienstes zu schützen. Da dieser immer einen physikalischen Zugriff auf Daten besitzt. Es ist nur möglich diesen Zugriff durch den Anbieter durch eine dem Anbieter nicht bekannte Verschlüsslung zu umgehen, jedoch wird dadurch der Zugriff auf die Daten auch für erlaube Benutzer erschwert und möglicherweise auch unterbunden. Diese Lösung ist jedoch nur bei einem reinen Datenspeicher praktikabel, da die meisten Applikationen die nicht unterstützen oder wenn sie es unterstützen jedoch die Daten innerhalb des Paging Space und dem Speichers immer noch Unverschlüsselt vorliegen und eingesehen werden können. Die Applikation in der Wolke muss schließlich auf die Daten zugreifen und sie verarbeiten können^[25]. Eine Firewall schützt die Daten gegenüber unbefugten Zugriffen, z.B. durch Rechner im Internet, in dem es nur bestimmten IP Adressen oder Port bzw. eine Kombination aus beidem den Zugriff auf das System erlaubt. Die Benutzerkontensteuerung beschreibt genau, welcher Benutzer welches Recht hat auf welche Daten zuzugreifen. So unterscheidet man generell zwischen 3 Rechten, einem User der keinen Zugriff auf die Daten hat, einem User der die entsprechenden Daten Lesen darf und einem User der Daten verändern sowie neue Daten Anlegen darf. Das größte Problem hierbei besteht in Zusammenhang mit den Passwörtern, da es oft sehr einfach möglich ist die Passwörter mit Hilfe eines Wörterbuch herauszufinden, sobald der Benutzername bekannt ist. Jedoch bieten solche Systeme nur einen ausreichenden Schutz wenn diese auch richtig eingerichtet und betreut werden. Wie immer ist es im Internet nicht möglich seine Persönlichen Daten zu 100% vor fremden Zugriff zu schützen, jedoch haben die meisten Cloud Computing Anbieter einen größtmöglichen Schutz der Daten gegenüber Fremden realisiert^[26].

5.1.1.4 Dateisystemverschlüsselung

Es gibt verschiedene Formen der Dateisystemverschlüsselung, auf Windows Ebene zum Beispiel Encrypting File System. Linux hat ebenfalls entsprechende Verschlüsselungsverfahren, so zum Beispiel Linux Unified Key Setup. Beide Varianten verschlüsseln das Dateisystem an sich. Somit werden unbefugte Zugriffe auf dieses Dateisystem größtenteils ausgeschlossen. Encrypting File System basiert auf einem hybriden Verfahren auf Basis von DESX. Vorbei hingegen das Linux Unified Key Setup auf einem TKS1 verfahren basiert. Bei Verschlüsslungen haben dasselbe Ziel, nämlich es für andere Personen unmöglich zu machen seine Persönlichen Daten zu lesen. Eine besondere Bedeutung muss der Verschlüsselung geschenkt werden, wenn es um Datenspeicher oder Virtuelle Applikationen geht. Leider können viele Applikationen nur auf im Klartext vorliegende Informationen zugreifen und somit wird eine Verschlüsselung der zugrunde liegenden Daten erschwert. Die Verschlüsselung des Dateisystems erschwert dem Cloud Computing Provider natürlich seine Backup Funktion, da er nicht mehr sagen kann wann eine Datei das letzte Mal geändert wurde, etc.. Dadurch stellt sich die Frage ob man sein Dateisystem überhaupt verschlüsseln darf oder ob die bei dem Provider gar nicht erlaubt ist, beziehungsweise ob der Betreiber das Kundendateisystem automatisch verschlüsselt um es vor Fremden Zugriffen zu schützen^[27]. Die Planung dieser Verschlüsselung ist mit einem hohen Aufwand verbunden und hat somit auch einen Einfluss auf das Kosten-Nutzen-Verhältnis. Zusätzlich müssen die Cloud Computing Provider auch sicherstellen das die Kundendaten untereinander zur Laufzeit getrennt sind auch wenn sie einen gemeinsames Storage-System verwenden^[28].

5.1.1.5 Patch Management

Das informieren von Nutzern über Sicherheitslücken und -updates in Softwareprodukten geschieht heutzutage sehr schnell über das Internet. Dies hat jedoch nicht nur positive Aspekte. Zwar können Administratoren in der Regel auch direkt über das Internet Softwareanpassungen herunterladen und das Sicherheitsrisiko reduzieren, jedoch können sich auch potentielle Angreifer problemlos über das Internet über neue Sicherheitslücken informieren und diese ausnutzen, wenn diese nicht schnell genug durch Softwareaktualisierungen geschlossen wurden ^[29]. Einer Studie aus dem Jahr 2008 zufolge gibt es für neunzig Prozent aller Sicherheitslücken, die von Angreifern ausgenutzt werden bereits seit mindestens sechs Monaten Sicherheitsupdates, die jedoch nicht von Administratoren eingespielt wurden und somit ein unnötiges Sicherheitsrisiko darstellen.^[30]
Das ist vor allem auch für Cloud Computing Nutzer interessant. Wenn diese beispielsweise PaaS-Dienstleistungen in Anspruch nehmen und selbst Anwendungen zur Verfügung stellen, muss auch vom diesem selbst das Patch Management, also das informieren über neue Sicherheitslücken und deren Schließung durch Updates, durchgeführt werden.

Die immer höher werdende Zahl an Patches die von Softwareanbietern zur Verfügung gestellt werden hat verschiedene Gründe. Zum einen werden vor allem aus Wettbewerbstechnischen Gründen neue Versionen von Anwendungen immer schneller zur Verfügung gestellt, was aber ebenfalls dazu führt, dass immer weniger Zeit zum Testen von Software aufgewendet wird.
Desweiteren machen es die immer komplexer werdenden Softwarelösungen inzwischen unmöglich hundertprozentig sicher vor Angriffen zu sein, da auch Angreifer kreativ sind und immer erfahrener werden und dadurch neue Arten finden Softwaresicherheit zu umgehen^[31].

Patch Management ist außerdem ein problematischer Faktor in Unternehmen, da trotz der großen Anfälligkeit von nicht aktuell gehaltener Software für Angreifer diese immer noch kein flächendeckendes Patch Management betreiben^[32], da es dazu in der Regel an personeller Ressourcen fehlt und es zudem auch sehr arbeitsintensiv und zeitaufwändig ist.

5.1.1.6 Storage security

Abbildung 3: Storage Area Network

Wie werden die Daten gesichert? Genau dies ist die Frage die sich viele Cloud Computing Kunden stellen, denn nachvollziehbarkeit wie die Daten innerhalb des Storage Systems des Cloud Comuting Providers gespeichert werden ist nicht vorhanden. Hierbei kann man nur auf die Angaben des Anbieters vertrauen. Je mehr Geld man in die Hand nimmt desto mehr Datensicherheit verspricht einem der Cloud Computing Provider, jedoch nachvollziehbar ist diese Sicherheit für den Kunden nicht. Ob nun der Kunde um Ausfallsicherheit herzustellen ein Raid System oder ein SAN mit gespiegelten Platten oder ein Bandlaufwerk oder doch nur ein Diskettenlaufwerk benutzt ist nicht Überprüfbar, selbst hohe Vertragsstrafen ändern an diesem Aspekt nichts. Ein Raid System basiert darauf das Daten nicht immer nur auf einer, sondern immer direkt auf mehreren Festplatten gespeichert werden. Somit kann ein Ausfall einer Festplatte schnell durch die Ersatz Festplatte kompensiert werden, jedoch ist ein kompletter Ausfall der dahinter steckenden Hardware nicht ohne weiteres Kompensierbar. Bei einem SAN System hingegen werden die Daten auf „Virtuellen Festplatten“ innerhalb eines Netzwerkes abgelegt, somit kann selbst ein Ausfall der dahinter steckenden Hardware nahezu ohne Zeitverlust wieder lauffähig sein, da direkt mehrere Identische System einen Zugriff auf die Daten haben und bei einem Ausfall sofort einspringen können um die Dienste wieder zu übernehmen. Je besser die Daten gegen Ausfall an sich geschützt sind ändert leider immer noch nichts gegen den direkten Zugriff des Providers auf die Daten, welche die Datensicherheit und Integrität weiterhin gefährdet^[33].

5.1.2 Netzwerksicherung

5.1.2.1 Internet

Unter Internet versteht man einen Weltweiten Verbund von Computernetzen. Innerhalb dieses Netzwerkes werden Daten nahezu unbeschränkt gegeneinander ausgetauscht und bereitgestellt. Generell gibt es keine zentrale Steuerungsinstanz die das Internet überwacht. Das Internet hat sich von einem kleinen militärischen Netzwerk innerhalb kürzester Zeit zum Weltweit größten Netzwerk entwickelt. Erst durch diese Vernetzung innerhalb der Computerwelt ist es möglich Cloud Computing Dienste anzubieten^[34].

5.1.2.2 Betriebssystemsicherheit bei der Virtualisierung

Host Operating System

Als Host Operating System wird das Betriebssystem bezeichnet welches auf einem Server für Virtuellen Maschine installiert ist. Hierbei hat jedes der möglicherweise eingesetzten Betriebssysteme seine Vor- und Nachteile. Leider teilen einem die Cloud Computing Provider nicht mit welches Betriebssystem sie nun genau als Grundlage für Ihre Virtuellen Maschinen verwenden. Somit ist es schwierig zu beurteilen wie anfällig das eingesetzte Betriebssystem gegenüber einstweiligen Angriffen geschützt ist. Es ist hier erneut nur möglich zu hoffen dass der Anbieter seine Host Systeme auf die bestmögliche weise gegenüber Angriffen aus der Außenwelt absichert. Vermutlich Basieren die meisten der eingesetzten Host Systeme auf einem Linux Kernel.

Guest Operating System

Das Guest Operating System ist so wie auch das Host Operating System auch ein reales Betriebssystem, welches jedoch nur auf von Host Operating Systemen zur Verfügung gestellten Virtueller Hardware läuft. Für das Guest Operating System ist dieses jedoch nicht ersichtlich. Als Guest Operation System kommen die alle Betriebssysteme in Frage, bei denen die Hardware vom Host Operating System emuliert werden kann. Somit hat der User hier "freie Hand" welches Betriebssystem er nun für seine Applikation oder ähnliches Verwenden möchte und welches nicht. Hierbei kommen meistens Unix- und Linuxderivate sowie Microsoft Betriebssysteme zum Einsatz. Die Cloud Computing Provider haben meist schon einige vordefinierte Guest Operating Systeme, welche dann auf einen "klick" für den bestimmten Benutzer nutzbar gemacht werden können. Dies geschieht meistens indem der Vordefinierte Computer in den Speicher des Kunden kopiert und dann für den Kunden gestartet wird. Die Wartung dieses System obliegt meistens nicht dem Cloud Computing Providers, sondern dem Kunden an sich. Denn dieser kann am besten einschätzen wie sich bestimmte Sicherheitsupdates auf sein Programm auswirken und in wie fern es weiterhin Nutzbar bleibt.

5.1.2.3 Denial-of-Service Angriffe

Eine Angriffsart, welche nicht den Zweck hat Daten zu stehlen oder zu zerstören sind sogenannte Denial-of-Service Angriffe (DoS).
Diese Attacken verfolgen den Zweck, dass Zielsystem, beispielsweise Online Services in Clouds schwer oder unerreichbar zu machen und es somit für die breite Masse normaler Nutzer unzugänglich zu machen.
Dabei werden Schwachstellen auf sämtlichen Ebenen der Kommunikationsarchitektur ausgenutzt. Das wirklich gefährliche an dieser Art von Angriff ist, dass sich das Opfer nur schwer dagegen wehren kann, es jedoch verhältnismäßig einfach ist solche Angriffe durchzuführen.

Es gibt verschiedene Arten von Denial-of-Service Attacken, eine davon ist das SYN-Flooding. Dabei wird eine Sicherheitslücke im TCP-Verbindungsaufbau ausgenutzt um dem Angreifer zu ermöglichen einen Server mit sinnlosen Anfragen nach Verbindungen zu überhäufen. Die dabei gesendeten Pakete werden mit gefälschten Absenderportnummern und unbekannten IP-Adressen versehen, sodass es dem angegriffenen Server nicht möglich ist auf eine Verbindungsbestätigung eine korrekte Antwort zu erhalten. Der Server reserviert jedoch für jede angefragte Verbindung Puffer- und Speicherplatz in einer internen Verbindungswarteschlange, da er davon ausgeht, dass weitere Pakete von der gefälschten Adresse ankommen.
Bis diese fälschlicherweise reservierten Ressourcen wieder freigegeben werden dauert es einige Zeit in welcher der normale Verbindungsaufbau von legitimen Nutzern erschwert oder aufgrund der hohen Anzahl der Falschanfragen unmöglich wird.

Eine weitere Technik stellen Distributed Denial-of-Service Attacken (DDoS) dar. Dabei werden nicht nur einzelne Systeme zum Angriff verwendet, sondern gleich eine große Menge verteilter Systeme, welche von einer zentralen Stelle aus kontrolliert werden. Der Angreifer baut dabei ein Netzwerk aus sogenannten Handlern und Agenten auf. Er selbst steuert und synchronisiert die Handler, welche wiederum Befehle an die Agenten delegieren, welche dann mittels SYN-Flooding und IP-Kontrollnachrichten, worüber normalerweise Informations- und Fehlermeldungen ausgetauscht werden, die Ressourcen des Opfers auszehren. Dadurch, dass sich zwischen dem Angreifer und dem Opfer zwei weitere Schichten befinden, welche in der Regel aus Systemen bestehen die zuvor vom Angreifer übernommen wurden und zu Handlern oder Agenten umfunktioniert wurden, wird die Zurückverfolgeung derartiger Angriffe stark erschwert^[35]. In Zeiten des Cloud Computing sind Denial-of-Service Attacken nicht nur in der Lage einzelne Unternehmen bei ihrer Arbeit zu behindern, sondern auch, durch die große Zahl an unterschiedlichen Unternehmen die auf Services eines einzelnen Unternehmens zurückgreifen, durch die Störung des Cloud Computing Anbieters in relativ kurzer Zeit große Schäden anzurichten, da dadurch der Informationsfluss vieler Unternehmen auf einmal behindert wird. „Denial-of-Service-Angriffe können nur begrenzt abgewehrt werden.
Solange ein Dienst der Allgemeinheit zugänglich ist, kann er auch von der Allgemeinheit missbraucht werden. Selbst auf höchstem Niveau abgesicherte Dienste können so längere Zeit und anonym praktisch unzugänglich gemacht werden.“^[36]

5.1.2.4 Firewall

Als Firewall-Systeme werden alle Schutzmaßnahmen bezeichnet, die einen unerlaubten Zugriff von außen auf ein Privates Netzwerk verhindern. Diese Systeme können in Form von Hardware, Software oder einer Kombination von beidem realisiert werden. Hauptsächlicher Anwendungsbereich liegt im Schutz von Intranets die mit ungesicherten Netzwerken verbunden sind. Die Grundlegende Schutzfunktion eines Firewall-Systems ist das Blockieren von Kommunikationsdaten zwischen den Netzen. Firewall Systeme sollen verhindern: Unerlaubten Zugriff auf Daten, Datenverlust und Einschleppen von Viren oder ähnlichem^[37].

Bei Firewall Systemen unterscheidet man generell zwischen 3 Verschiedenen Systemen: Paket Filter, Application gateway und Proxy Server

Paket Filter

Abbildung 4: Paketfilter^[38]

Ein Paket Filter analysiert alle ein- und ausgehenden Datenpakete auf den Layern 3 und 4 des OSI-Referenzmodells. So können z.B. die Quelladresse, Zieladresse, Portnummern von TCP und UDP Paketen und die Richtung des Datenverkehrs. Der Paketfilter übernimmt auch eine gewisse Überwachungsinstanz, so ist es möglich jedes bzw. nur bestimmte Pakete die den Paketfilter durchlaufen protokollieren zu lassen. Dies eröffnet dem Anbieter die Möglichkeit bei einstweiligen Einbruchsversuchen Nachforschungen zu betreiben. Leider schützt dieses System leider nicht gegen gezielte Datenverfälschungen wie zum Beispiel Adress Spoofing^[39]. Die Entscheidung ob der Paket Filter ein Daten Paket durchlässt oder nicht wird anhand einer Access Control List (kurz ALC) durchgeführt.

Die Access Control Lists definieren auf welche Dienste zugegriffen werden kann. Dafür benötigt man viele Informationen über den Datenverkehr zwischen dem Absender und dem Empfänger. Dazu gehören Quelladresse, Zieladresse, Portnummern von TCP und UDP Paketen und die Richtung des Datenverkehrs. Dadurch kann genau definiert werden welche Kommunikation unter welchen Bedingungen erlaubt ist und welche nicht. Dies machen sich Cloud Computing Provider zu Nutzen um die Kommunikation zwischen den einzelnen API's zu Unterbinden bzw. gezielt zu erlauben. Bei zustandsbehafteten Paket filtern wird die Filtertabelle dynamisch, um die Parameter einer aufgebauten Verbindung derart erweitert, dass nur die Datenpakete, die zu einer bestehenden Verbindung gehören, den Paketfilter passieren dürfen. Dies ist notwendig, um den Transfer von Daten über etablierte (und damit erlaubte) Verbindungen gegen unberechtigten Zugriff abzusichern^[40].

Applikation Gateway

Abbildung 5: Anwendungsschicht-Gateway

Ein Applikation Gateway zu Deutsch Anwendungsschicht-Gateway ist ein Kommunikationsrechner, welcher in der Regel mit mind. 2 Netzwerkkarten ausgestattet ist. Es trennt die Angeschlossenen Netze sowohl logisch als auch physikalisch voneinander. Nach erfolgreicher Authentifizierung am Gateway arbeitet das Applikation Gateway transparent und lässt den Verkehr zum internen Netzwerk zu. Aufgrund ihrer Trägheit sind Applikation Gateways nur begrenzt für Cloud Computing Provider einsetzbar^[41]. Filter auf der Anwendungsschicht untersuchen ihre Dienste detailliert und sind meist komplexer als Paketfilter, woraus auch ihre Trägheit resultiert. Solche Filter basieren üblicherweise nach dem Store- and Forward Verfahren. Der Hauptnachteil der Anwendungsschicht-Gateways ist das für die meisten angebotenen Dienste spezielle Benutzeroberflächen oder Programme bereitgestellt bzw. sogar neu Programmiert werden müssen. Dies bedeutetet einen erheblichen Mehraufwand im Vergleich zu einem normalen Paket Filters. Daraus Resultiert dass meistens nur die wichtigsten Dienste über ein Applikation Gateway angeboten werden. Jedoch lassen sich die meisten proprietären Protokolle nicht über ein Applikation Gateway schützen, da es nicht möglich ist etwas undefiniertes zu Filtern. Wenn auch diese Protokolle gefiltert werden müssen birgt dieses durch Zusatzprogramme innerhalb der Firewall ein erhöhtes Einbruchsrisiko^[42].

Proxy Server

Abbildung 6: Proxy-Server

Als Proxyserver wird eine Verwaltungsinstanz bezeichnet welche jeglichen Netzwerkverkehr vom Intranet in das Internet abwickelt. Diese Server merkt sich jegliche Anfragen an ihn, speichert diese und sendet daraufhin die Informationen mit seiner Adresse weiter in das Internet. Somit fungiert dieser Server als Relais in das Internet. Da jetzt jeglicher Verkehr über diesen Server abgewickelt wird ist für einen dritten nicht ersichtlich ob dieser Server nun wirklich dieser ist der auch die Anfrage gestellt hat oder nicht. Dies erhöht die Sicherheit dramatisch, da die hinter dem Proxy Server liegende Infrastruktur von Angriffen auf dem Internet geschützt ist. Je größer die Sicherheit desto langsamer ist auch der Datenverkehr. Somit ist der Proxy Server die langsamste, da jedes Datenpaket kopiert und neu erstellt werden muss, der 3 Schutz varianten, jedoch auch die sicherste, da die Infrastruktur nach außen nicht ersichtlich wird^[43].

5.1.2.5 Intrusion Detection

Unter Intrusion versteht man einen nicht autorisierten Vorgang, also einen Einbruch in ein Netzwerksystem. Intrusion Detection Systeme überwachen Rechnersysteme oder Netzwerke auf unbefugte Zugriffe und ungewöhnliche Systemaufrufe, sogenannte Anomalien. Es gibt verschiedene Arten von IDS die jeweils auch verschiedene Arten von Anomalien erkennen können.
Zum einen gibt es netzwerkbasierte IDS, die den Netzwerkverkehr mitschneiden, analysieren und dann wieder weitergeben, und hostbasierte IDS, welche zur Überwachung einzelner Rechner und der darauf laufenden Prozesse, Anwendungen und Kommunikationen eingesetzt werden. Dazu gibt es auch hybride IDS, die sowohl Netzwerkverkehr, als auch Rechnersysteme auf Anomalien überwachen.^[44]

Bezogen auf die Sicherheit von Cloud Computing Systemen ist es wichtig, dass IDS in der Lage sind den Netzwerkverkehr zwischen zwei virtuellen Maschinen überwachen zu können, die sich auf dem selben Server befinden. Hier stoßen nämlich Hardwarebasierte Sicherheitsmaßnahmen in der Regel an ihre Grenzen.^[45]

5.1.2.6 IP spoofing

Abbildung 8: IP Spoofing^[46]

IP Spoofing bezeichnet die Nutzung einer gefälschten IP Adresse zum Übermitteln von Daten. Dies ist gefährlich, da viele Computer- und Netzwerksysteme diese als eindeutige Adresse zur Identifikation verwenden und IP-Adressen als Vertrauensbasis verwenden. Zum Beispiel erlauben Firewalls nur Nutzungsberechtigten Rechnern ihres Adressraumes den Zugang zum Internet. Da es nicht ungewöhnlich ist, dass ein System von mehreren Personen genutzt wird, kann die Authentifizierung nicht personenbezogen geschehen.

Beim IP Spoofing werden Daten mit der IP Adresse eines dem Opfer gegenüber vertrauenswürdigen Systems versendet. Aufgrund der Authentifizierung über die IP Adresse werden die Anfragen des Angreifers am System des Opfers weitergeleitet, da das Zielsystem von einer rein internen Kommunikation ausgeht, wodurch der Angreifer in die Lage versetzt wird auf sensible Daten Dritter zugreifen zu können^[47].

5.1.2.7 Man In the Middle (MITM) attacks

Abbildung 7: Man in the middle Angriffe

Eine "Man in the Middle"-Attacke beschreibt einen bestimmten Vorgang wie man probiert an Daten des Absenders zu gelangen ohne das dieser etwas von dem Angriff mitbekommt. Dies läuft in der Regel nach folgendem Muster ab: Der Angreifer stellt sich gegenüber dem Opfer als seine gewünschtes Ziel dar. Dieser leitet jeglichen Verkehr auch an die wirkliche Ziel Adresse weiter, somit bekommt das Opfer nichts von diesem Angriff, bis auf vielleicht eine längere Reaktionszeit, mit. Dieser Angriff kann beispielsweise über eine manipulierte Host Datei auf dem System oder eine gefälschten Arp Table realisiert werden. Jetzt ist es dem Angreifer möglich jeglichen Netzwerkverkehr zu analysieren und entsprechend Passwörter oder Firmengeheimnisse auszulesen. Böswilliger wird es wenn versucht wird diese Datenstrom zum Ziel oder Quellrechner zu manipulieren, besonders dann wenn Firmengeheimnisse damit involviert sind. Dieses Risiko lässt sich mit verringern bzw. ausschließen wenn man die Echtheit der Absender bzw. Quelladresse verifizieren kann. Bei verschlüsseltem Datenverkehr kann der Angreifer zwar den gesamten Verkehr mitlesen, jedoch werden die Daten nicht im Klartext übertragen und sind somit für den Angreifer von keinem Wert mehr^[48].

5.1.2.8 Packet sniffing

Computer die miteinander vernetzt sind versenden Datenpakete um miteinander zu kommunizieren.
Normalerweise nehmen Netzwerkkarten nur diejenigen Datenpakete an, die auch an sie adressiert sind und diejenigen die als Broadcast- und Multicastadressen gesendet werden. Es ist jedoch auch möglich mithilfe sogenannter Sniffer-Software Daten zu empfangen, die an andere Adressen als die eigene im Netzwerk gerichtet sind. Zwar muss ein Angreifer um den Netzwerkverkehr analysieren zu können innerhalb des Netzwerkes Datenpackete im "Promiscuous Mode" abfangen, jedoch können zum Beispiel per E-Mail Trojaner in Unternehmensnetzwerke eingeschleust werden, welche ein Angreifer dann über das Internet steuern kann und dadurch Zugriff zu sensiblen Unternehmensdaten, wie Passwörtern die unverschlüsselt über das Netzwerk übertragen werden, erhalten kann^[49].

5.1.2.9 Port scanning

Unter Port scanning versteht man den Prozess Systematisch alle möglichen Port auf einem Zielsystem zu scannen um mögliche Sicherheitsschwachstellen auszunutzen. Dieser Vorgang ist besonders dann effektiv wenn eine fehlerhafte Firewallkonfiguration und ein Veralteter Patchstand des Zielsystems vorliegen. Wenn offene Ports gefunden werden, so kann probiert werden die auf diesen Port lauschende Anwendung so anzusprechen das diese eine bestimmte Aktion auf dem Zielsystem ausführt. Durch diesen Aktion können dann weitere Hintertüren geöffnet oder auch direkt Einfluss auf die Maschiene genommen werden. Dieser Vorgang wird für die meisten Cloud Computing Provider nur eine nachrangige Bedeutung haben, da die Gefahr durch ihre Sicherheitsmaßnahmen nur sehr gering ist^[50].

5.1.2.10 Protokolle

Über Protokolle und Zertifikate lassen sich Sicherheitsmaßnahmen im Bezug auf die Datenübertragung zum oder vom Cloud Computing Provider Realisieren, welches das Mithören des Datenverkehrs zwischen Absender und Empfänger zwar nicht verhindert die Daten für den Mithörenden aber unbrauchbar macht. Dies geschieht meistens Anhand eines Zertifikates zur Authentifizierung des Servers und zur Verschlüsselten Übertragung. Die meist benutzten Verfahren werden im weiteren Verlauf kurz vorgestellt.^[51]

Secure Socket Layer

Das Protokoll Secure Socket Layer wird zum aufbau von sicheren Verbindungen über das HTTP Protokoll genutzt. Es setzt auf die Transportebene des OSI-Referenzmodels auf und wurde von der Firma Netscape entwickelt. Mittlerweile ist die Secure Socket Layer Version 3 aktuell. Die Integration von Secure Socket Layer ist Mittlerweile in fast jedem Browser vohanden. Hierbei wird, vereinfacht ausgedrückt, ein sicherer Kanal zwischen den beiden Gesprächspartnern aufgebaut und dann die Daten über das normale HTTP Protokoll übertragen. Es können auch viele andere Dienste über Secure Socket Layer Übertragen werden, wie zum Beispiel FTP, Telnet oder Email. Dies erhöht die Sicherheit der angebotetenen Dienste enorm, da der Datenverkehr verschlüsselt wird. Es werden Abweichend zum normalen Datenverker im Secure Socket Layer Verschlüsselten Datenverkehr andere Ports für die Datenverkehr verwendet. So benutzt zum Beispiel HTTPS den Port 443 oder FTPS die Ports 990 und 889^[52].

Transport Layer Security

Auf Basis der Secure Socket Layer Spezifikationen wurde das Transport Layer Security Protokoll als Internetstandard enwickelt. Bei Transport Layer Security handelt es sich im Kern um ein etwas weiterentwickeltes Secure Socket Layer der Version 3.1. Die Version 1.1. wurde auch im April 2006 im RFC 4346^[53] standarisiert und hat somit den früheren Standard RFC 2246^[54] abgelöst. Im gegensatz zu dem Secure Socket Layer PRotokoll verwendet das Transport Layer Security Protokoll das kyptografisch sichere HMAC-Verfahren zur Berechnung der MAC-Werte. Das Transport Layer Security Verfahren basiert wie auch Secure Socket Layer auf dem TCP-Protokoll somit ist eine Verschlüsselung von UDP Daten (wie zum Beispiel Streams) nicht möglich^[55].

Secure Shell

Das Secure Shell Protokoll (SSH) bietet die Möglichkeit eine verschlüsselte Verbindung zu einem entfernten System über ein unsicheres Netzwerk aufzubauen ^[56]. Typische Anwendungen hierfür sind Remotesessions zu der Konsole eines Servers für Administrationszwecke. SSH unterstützt Authentifizierung, sichert die zu übertragenden Daten durch Verschlüsselung und gewährleistet die Integrität der Daten. Bei SSH findet eine beidseitige Authentifizierung statt, das bedeutet, dass sich sowohl der Client gegenüber dem Server wie auch der Server gegenüber dem Client authentifiziert. Jeder Server verfügt über einen eigenen Host Key. Ist der Client noch nicht im Besitz dieses öffentlichen Schlüssels, so schickt der Server einen Fingerprint seines öffentlichen Schlüssels an den Client ^[57]. Vertraut der Client darauf, dass es sich um den richtigen Server handelt, kann er den öffentlichen Schlüssels des Servers akzeptieren und speichern. Stimmt der Schlüssel bei der nächsten Anmeldung an den Server nicht mehr überein, erhält der Client eine entsprechende Meldung darüber. Die clientseitige Authentifizierung mittels SSH kann per Public-Key Verfahren, host- oder passwortbasiert erfolgen^[58].

Sicherheit von Protokollen

Secure Socket Layer und Transport Layer Security ermöglichen eine authentifizierte, vertrauliche und vor unbefugten Modifikationen geschützte Datenkommunitkation zwischen zwei Kommunikationendpunkten. Durch die Unterstützung von Verschiedensten Authentifikationsschematas wie zum Beispiel X.509 Zertfikaten, wird eine relativ hohe Datensicherheit während der Übertragung sichergestellt. Da die Daten auf dem Transportweg bis zum Endpunkt verschlüsselt sind und somit von anderen nur schwierig beziehungsweise gar nicht in brauchbare Daten verwandelt werden können. Je höher der Verschlüssellungsgrad der Verbindug um so sicherer ist diese. Somit sollte immer darauf geachtet werden eine möglichst hohe Verschlüsselung zwischen den beiden Partnern auszuhandeln. Und genau diese Aushandelung der Verschlüsselung ist auch die Schwachstelle dieser Verfahren, denn wenn der Angreifer weiß mit welchem Schlüssel ein Datenpaket verschlüsselt wurde, so kann er auch diesen Datenstrom im Klartext auslesen^[59].

5.2 Schicht der Daten- und Zugriffsverwaltungssicherung

5.2.1 Datensicherheit

5.2.1.1 Sicherheit durch Kryptographie

Unter Kryptographie versteht man allgemein Maßnahmen und Verfahren, um eine geschützte Kommunikation und damit den Austausch von Informationen zu ermöglichen. In der Informationstechnik stehen verschiedene kryptographische Verfahren zur Verfügung, z.B. in den Bereichen Verschlüsselung, digitale Signaturen oder in Form von digitalen Zertifikaten. Die Ziele dieser Verfahren sind zum einen die Sicherung der Vertraulichkeit und Integrität von Informationen wie auch die Authentifizierung der Kommunikationspartner, also der Sicherstellung, dass sich kein Unbefugter (siehe auch MITM-Attacken) an der Kommunikation beteiligt und somit vertrauliche Daten abgreifen kann.

Verschlüsselung

Informationen wie z.B. Daten auf Datenspeichern oder auf ihrem Weg durch Kommunikationsnetze liegen in der Regel zunächst im Klartext vor. Somit besteht das Risiko, dass jeder der potentiell Zugriff auf diese Daten erlangt, diese ungehindert lesen und missbrauchen kann. Durch geeignete Verschlüsselung kann dieses Risiko jedoch vermindert werden. Hierbei wird zwischen symmetrischer und asymmetrischer Verschlüsselung unterschieden.

Bei der symmetrischen Verschlüsselung erfolgt die Ver- und Entschlüsselung von Informationen über einen gemeinsamen geheimen Schlüssel, der den an der Kommunikation beteiligten Parteien bekannt sein muss ^[60]. Zu den Verschlüsselungsstandards zählen beispielsweise der Data Encryption Standard (DES) mit 56 bzw. 64 Bit Schlüssellänge und der Advanced Encryption Standard (AES) mit Schlüssellängen von 128 bis 256 Bit.

Bei der asymmetrischen Verschlüsselung hingegen besitzt jeder Kommunikationsteilnehmer ein eigenes Schlüsselpaar bestehend aus einem öffentlichen (public) und einem privaten (private) Schlüssel ^[61]. Zur Verschlüsselung von Informationen über dieses sogenannte Public-Key Verfahren wird dann der zuvor bereitgestellte öffentliche Schlüssel der Gegenstelle verwendet. Die Gegenstelle kann dann mit Hilfe des eigenen privaten Schlüssels die verschlüsselten Daten wieder entschlüsseln. Ein bekanntes Verfahren auf diesem Gebiet ist z.B. RSA.

Digitale Signaturen

Anders als bei einer Kommunikation von Angesicht zu Angesicht, besteht bei der Kommunikation über zum Teil unbekannte, ungesicherte Netzwerke wie dem Internet zunächst keine Möglichkeit die Identität seines Gegenüber zu prüfen (z.B. durch reine Sichtkontrolle oder Ausweiskontrolle). Des weiteren muss sichergestellt sein, dass die übermittelten Informationen „auf dem Weg“ nicht manipuliert werden bzw. der Empfänger eine solche Manipulation erkennen kann. Digitale Signaturen ermöglichen es, die Authentizität eines Absenders und die Integrität von Informationen zu gewährleisten. Die digitale Signatur verwendet ebenfalls die Public-Key Verschlüsselung wie folgt ^[62]: von den zu signierenden Informationen, z.B. einem Text-Dokument oder einer E-Mail wird über eine Hashfunktion ein Hashwert erzeugt, welcher anschließend über eine Signaturfunktion mit dem privaten Schlüssel des Absenders verschlüsselt und als digitale Signatur der Nachricht angehängt wird. Diese digitale Signatur entschlüsselt der Empfänger mit dem öffentlichen Schlüssel des vermeintlichen Absenders und vergleicht den enthaltenen Hashwert mit dem selbst erzeugten Hashwert auf die empfangenen Daten. Passt der öffentliche Schlüssel zum privaten Schlüssel der Signatur und sind die Hashwerte identisch, ist sichergestellt, dass es sich um den ausgewiesenen Absender handelt und die Informationen nicht manipuliert wurden.

Digitale Zertifikate

Verschlüsselung und Signatur von Informationen mittels Public-Key Verfahren wie oben beschrieben, ist nur dann sicher, wenn die an der Kommunikation Beteiligten davon ausgehen können, dass der genutzte öffentliche Schlüssel auch tatsächlich zu dem vermeintlichen Partner gehört.Sobald sich ein Dritter unter falscher Identität mit seinem eigenen öffentlichen Schlüssel ausgibt und dieser von den anderen Beteiligten genutzt wird, sind die zuvor beschriebenen Schutzmaßnahmen (s. Verschlüsselung und digitale Signaturen) nichtig. Digitale Zertifikate dienen der Überprüfbarkeit des Inhabers eines öffentlichen Schlüssels ^[63]. Durch eine unabhängige vertrauenswürdige Instanz, die Zertifizierungsstelle wird versichert, dass öffentlicher Schlüssel und Inhaber zusammengehören. Hierüber wird ein entsprechendes Zertifikat ausgestellt. Dieses Zertifikat enthält Angaben zum Besitzer und der ausstellenden Zertifizierungsstelle sowie den öffentlichen Schlüssel des Inhabers und der Zertifizierungsstelle. Das Zertifikat ist von der Zertifizierungsstelle signiert.

Ein Beispiel für ein häufig genutztes digitales Zertifikat ist das X.509 Zertifikat. Die Allgemeine Struktur eines X.509 Zertifikates ist standarisiert, so dass jeder Computer, der dieses Protokolle versteht, mit einem X.509 Zertifikat umgehen kann. Damit wird sichergestellt, dass die Kommunikation zwischen einem Kunden und seinem Provider mittels eines verschlüsselten Datenaustauschs stattfindet. Anhand des Zertifikates wird dann genau gesteuert auf welche Applikation oder Server ein Benutzer Zugriff haben soll. Desweiteren kann das Zertifikat und damit der Zugriff auf das System vom Cloud Computing Provider sehr schnell, zum Beispiel bei Diebstahl, zurückgezogen werden ^[64].

Abbildung 9: Beispiel Zertifikat der Deutschen Postbank AG

Abbildung 10: öffentlicher Schlüssel der Deutschen Postbank AG

5.2.1.2 rechtliche Aspekte

Die heutige deutsche als auch europäische Rechtslage zum Datenschutz gehen im Prinzip davon aus dass man jederzeit feststellen kann, wo sich die Daten auf den Rechnern und Speichern befinden. Leider ist dies aber beim Cloud Computing nicht mehr gewährleistet. Die Datensätze können über die gesamte Welt verstreut sein und auch von einem auf den anderen Augenblick ihren Standort wechseln. Selbst wenn die Daten durch fragmentierung nicht mehr in ihrer gesamtheit an einem Punkt lagern, so sind es dennoch Personen bezogene Daten.

Nach der gegenwärtigen Rechtslage im BDSG sind persönliche Daten dann geschützt, wenn die datenschutzrechtlich relevanten Handlungen im Inland vorgenommen werden -- egal, ob die Daten aus den USA oder aus Deutschland stammen. Es gilt dann nach § 1 Abs. 5 BDSG grds. das Territorialprinzip. Dieses Konzept ist beim Cloud Computing aber nur schwer aufrechtzuerhalten. Ein IaaS-Anbieter, wie Amazon, kann wahrscheinlich gar nicht genau feststellen, auf welchem Server sich die Daten zu einem bestimmten Zeitpunkt befinden.

Die rechtlichen Lösungsansätze stecken noch in den Kinderschuhen^[65]

5.2.2 Zugriffsverwaltung (Identitätssicherung/ Authentifikation)

Authentifikation

Authentifikation wird als Vorgang zum Beweis der eigenen Identität bezeichnet^[66]. Dabei muss im Vorfeld unterschieden zwischen Identifikatio, als Zusicherung der Identität und der Autorisierung zur Ableitung von bestimmten Benutzerrechten.

Eine Authentifizierung wird in drei Faktoren unterschieden^[67]:

"Wissen", in Form des Wissens von Passwörter und PIN's
"Gegenstände", unterstützende Geräte zur zusätzlichen Authentifizierung, wie z.B. Chip- oder Magnetkarten und Hardware-Tokens
"Eigenschaften", die sich anhand der benutzerspezifischen Eigenschaften (Biometrik), wie dem Fingerabdruck oder der Stimme ableitet

Um eine umfangreiche und sichere Authentifizierung zu gewährleisten, sollten mindestens zwei unterschiedliche Funktionen, wie z.B. Passwörter und Hardware-Tokens angewendet werden.

Da es unterschiedliche Verfahren zur Authentifizierung gibt und diese unter Berücksichtigung der Benutzerfreundlichkeit ausgewählt werden können, muss zunächst das Risiko beurteilt werden, welches für die jeweilige Anwendung besteht und welches Verfahren letztlich aufgrund der jeweiligen Verfahrenskosten am effizientesten erscheint. Grundsätzlich werden Passwörter als weniger starke Authentifizierung bewertet, da das selbstgewählte Passwort i.d.R. sehr leicht einprägbar ist, aber infolgedessen wenig sicher ist^[68].

Es existieren verschiedene Authentifikationsverfahren (Einmal-Passwörter, Smart Cards und Biometrik), die im Folgenden anhand eines Beispiels aus den obengenannten Faktoren kurz erläutert werden soll.

5.2.2.1 Einmal-Passwörter

Eine einfache Form der Authentifizierung ist die Verwendung von zeitbasierten Einmal-Passwörtern, welche im Folgenden näher erläutert wird. In diesem Zusammenhang existieren weitere Formen, wie das Challenge/ Response-Einmal-Passwort und das Lamports-Einmal-Passwort-Verfahren, die hier der vollständigkeitshalber nur erwähnt werden^[69].

Zeitbasierte Einmal-Passwörter bieten eine erhöhte Sicherheit im Vergleich zu "normalen" Passwörtern. Sie zeichnen sich dadurch aus, dass sie nur einmal verwendet werden können und anschließend ungültig werden. Dadurch bietet sich ein erhöhter Schutz gegenüber Lauschern oder komprimierten telnet-Befehlen, da zwar das Passwort abgefangen werden, dieses aber dann nicht mehr ein zweites Mal verwendet werden kann. Das bekannteste und verbreiteste Prinzip im Bezug auf zeitbasierte Einmal-Passwörter ist der Hardware-Token durch die Firma RSA Security, der auch als Dongle oder Token bezeichnet wird^[70].

Das Prinzip des zeitbasierten Einmal-Passwortes besteht aus einer internen Uhr, einem geheimen Schlüssel und eines Display, welches auf einem Hardware-Token integriert sind. Über eine interne Funktion wird mit der aktuellen Uhrzeit und dem geheimen Schlüssel des Benutzers ein Ergebnis berechnet. Dieses Ergebnis wird alle 60 Sekunden neu berechnet und kann zusätzlich mit einer PIN-Abfrage zu Authentifizierung kombiniert werden. Aufgrund der Einmaligkeit des errechneten Wertes, kann dieser nur einmal innerhalb der 60 Sekunden verwendet werden. Sobald der Benutzer den berechneten Wert des Tokens in das System eingegeben hat, wird dieser Wert an einen Server übermittelt, der wiederum den Wert an einen angeschlossenen Authentifikationsserver weiterleitet. Der Authentifikationsserver führt daraufhin ebenfalls eine Berechnung mittels der aktuellen Uhrzeit und einer Kopie des geheimen Schlüssels durch. Anschließend wird der eingegebene Wert des Benutzers mit dem Wert des Servers verglichen. Sollten beide Werte identisch sein, so wird die Identität des Benutzers bestätigt^[71].

In diesem Zusammenhang ist ebenso eine sichere Übertragung der Daten zwischen dem Server und dem Authentifikationsserver notwendig, um die jeweilige Identität der übertragenden Stellen sicherzustellen^[72].

5.2.2.2 Smart Cards (Chipkarten)

Smart Cards basieren auf der zweiten Kategorie, sprich der „Gegenstände“ zur Authentifikation. Sie beschreibt eine scheckkartengroße Gerät, welches aus einem Chip, mehreren I/O-Kanälen und einem nichtflüchtigen Speicher mit mehr als 1000 Byte, der von der CPU genutzt wird^[73].

Der Zugriff und die Freischaltung des Benutzers erfolgt mittels eines Lesegerätes, um über unterschiedliche Authentifizierungsverfahren den Benutzer zu identifizieren. Die Chipkarte bietet den Vorteil, dass die Verschlüsselung des geheimen Schlüssels des Benutzers direkt auf der Karte durch die Public-Key-Verschlüsselung erfolgen kann, so dass dessen Ergebnisse direkt über die I/O-Kanälen an den Host übertragen werden kann^[74].

5.2.2.3 Biometrik

Biometrische Verschlüsselungsverfahren sind in der dritten Kategorie der Benutzerauthentifizierung angesiedelt, da hier bestimmte biometrischen Eigenschaften des Benutzers als Authentifikation und Identifikation genutzt werden. Diese biometrischen Eigenschaften können z.B. der Fingerabdruck, ein Stimmmuster sowie das Retina- oder Iris-Muster sein^[75].

In diesem Zusammenhang werden zusätzliche Hardwarekomponenten notwendig, um die biometrischen Daten zu erkennen und auszuwerten^[76].

Diese Form der Authentifizierung wird vor allem besonders sicheren Anlagen verwendet, da diese als sicher gilt, da die biometrischen Kennzeichen nicht gestohlen oder weitergegeben werden können^[77].

5.3 Schicht der Anwendungsicherung

5.3.1 Passwortverwaltung / Passwortsicherung

Passwort

Ein Passwort, welches z.B. als Zeichenkette eingegeben werden kann, dient dazu die Identität des Benutzers zu authentifizieren. Die Authentifikation besteht aus dem Paar der User-ID (Benutzername) und des Passwortes. Sind beide Angaben korrekt in dem System angegeben, erfolgt die Authentifizierung des Benutzers, da i.d.R. das Passwort nur dem Benutzer bekannt sein sollte^[78].

Über die jeweilige User-ID des Benutzers werden die spezifischen Privilegien auf dem System definiert. Infolge der ID/Passwort Kombination lassen sich unterschiedliche Zugriffskonten angeben, auf denen unterschiedliche Privilegien hinterlegt sind. Als Beispiel hat "Gast"-Konto nur eingeschränkte Systemrechte wohingegen das "Supervisor“- oder „Administrator"-Konto fast uneingeschränkte Systemrechte besitzt^[79].

Ein Passwort wird aufgrund dieser Definiton als "erste Verteidiungslinie"^[80] bezeichnet, um unbefugte Benutzer von dem Systemzugriff abzuhalten.

Jedoch bestehen im Zusammenhang mit Passwörtern zwei mögliche Bedrohungsarten. Zum Einen kann ein Benutzer über einen unberechtigten Gastzugang oder einen anderen Methoden Zugang auf das System erhalten oder mittels eines Passworterkennungsprogramms (Passwort-Cracker) bis zu tausend unterschiedliche Passwortkombinationen zu testen, bis er das jeweilige Passwort findet^[81]. Dieses Problem wird dann zusätzlich verstärkt durch das allgemeine Problem, dass Passwörter i.d.R. meist zu leicht zu merken sind, d.h. zu kurz sind oder Passwörter verwenden, die in Form eines Namens, einer Strasse oder eines sonstigen einfach zu merkenden Begriffes gespeichert werden.

5.3.2 Wahl des richtigen Passwortes

Bei der Wahl des richtigen Wahl des Passwortes ist darauf zu achten, ein Gleichgewicht zwischen eines zu kurzen Passwortes (kleiner als drei Zeichen), welches leicht zu merken ist und eines Passwortes aus bis zu acht zufälligen Zeichen, welches sich der Nutzer nur schwer merken kann, herzustellen^[82].

In diesem Zusammenhang bestehen vier Grundtechniken zur Wahl des richtigen Passwortes^[83]:

Ausbildung der Nutzer
Computergenerierte Passwörter
Reaktive Passwortüberprüfung
Proaktive Passwortüberprüfung

Mithilfe der Ausbildung der Nutzer sollen bestimmte Regeln für Nutzer erstellt werden, die ihn dabei unterstützen das richtige Passwort zu finden. Die Problematik die in diesem Zusammengang auftreten kann, beruht auf der Tatsache, dass sich der Benutzer, trotz der Hilfestellung, weiterhin unsicher ist, ob sein neues Passwort sicher ist. Gleichzeitig kann die Hilfestelle durch einzelne User ignoriert werden^[84].

Computergenerierte Passwörter bieten den Vorteil, dass der Nutzer sich nicht um die Erstellung eines Passwortes kümmern muss, sondern die zufällige Auswahl von Zeichenketten von einem Programm übernommen wird. Hier besteht allerdings auch das Problem, dass der Nutzer sich das Passwort nicht merken kann, da dessen Zusammenstellung für ihn zu fällig ist und er sich das Passwort aufschreiben muss, wodurch der Sinn eines Passwortes hinfällig wird^[85].

Bei der reaktiven Passwortüberprüfung nutzt das System einen eigenen Passwort-Cracker, um leicht erratbare Passwörter zu ermitteln, die aktuell von den Benutzern verwendet werden. Anschließend werden diese Passwörter vom System gelöscht und der Benutzer benachrichtigt für die Eingabe eines neuen Passwortes. Dieses Prinzip besitzt den Nachteil, dass es hohe Speicherressourcen benötigt, um alle Passwörter zu speichern, welche zu anfällig für eine Passwortnutzung sind. Ebenfalls wird das System sehr stark ausgelastet, um die Passwörter konsequent zu prüfen. Letztlich ist das Passwort auch so lange anfällig, bis es vom Passwort-Cracker nicht überprüft wurde^[86].

Mithilfe der proaktiven Passwortüberprüfung kann der User zunächst weiterhin sein eigenes Passwort wählen. Allerdings wird dieses eingegebene Passwort direkt vom System anhand dessen Sicherheit überprüft und kann das unsichere Passwort ablehnen. Der Vorteil liegt in der breiteren Akzeptanz der Benutzer, da der Benutzer weiterhin ein Passwort selbst wählen kann, was er sich leicht merken kann, aber auch gleichzeitig ein Feedback hinsichtlich dessen Sicherheit erhält^[87].

Grundsätzlich besteht allerdings bei allen Passwörtern die Problematik, dass ein Passwort gestohlen werden kann, wenn dieses vom Benutzer aufgeschrieben wird, so dass es in der Aufgabe des Benutzers steht, dafür Sorge zu tragen, dass seine Passwörter nicht aufgeschrieben werden und nicht Fahrlässigkeit mit diesen Daten umgeht. In diesem Zusammenhang kann auch eine kombinierte Nutzung von Passwörtern mit unterschiedlichen Authentifizierungsarten genutzt werden.

6 Sicherungsmaßnahmen verschiedener Cloud Computing Anbieter

6.1 Amazon

6.1.1 Amazon Web Services

Der Online-Händler Amazon bietet mit seinen Amazon Web Services eine Cloud Computing Infrastruktur für Kunden wie auch für Entwickler über Amazons bereitgestellte Plattformen an. Nach Amazon handelt es sich bei den Amazon Web Services um eine hoch skalierbare Cloud Computing Plattform, die sich durch Hochverfügbarkeit und Zuverlässigkeit auszeichnet ^[88]. Zu dem Dienstleistungspaket der Amazon Web Services zählen Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3) und Amazon SimpleDB. Amazon EC2 stellt seinen Kunden Rechenkapazität in Form von virtuellen Maschinen zur Verfügung, welche auf Amazons eigener Hardware gehostet werden. Der Kunde kann je nach Bedarf die Hardwareausstattung, Betriebssysteme und Applikationen wählen und nach seinen Anforderungen ausbauen ^[89].

Mit Amazon Elastic Block Storage steht den jeweiligen Rechnerinstanzen permanenter Datenspeicher in Form von Standard Block Devices zur Verfügung, der zum Beispiel von den Instanzen als lokale Festplatte genutzt werden kann ^[90]. Die sogenannten Amazon Machine Images, vom Kunden fertig installierte Instanzen, können anschließend im S3 abgelegt werden. Der Zugriff des Kunden auf die Instanzen erfolgt per Web Interface. Mit S3 stellt Amazon Kunden hoch verfügbaren Datenspeicher „im Internet“ bereit, der per Web Interface von überall erreichbar ist ^[91]. Mit SimpleDB hält Amazon eine „abgespeckte“ Datenbank bereit, mit der die Basisfunktionalitäten wie das Indizieren und Abfragen von Daten möglich sind ^[92]. Die strukturierten Daten werden hierbei vom Kunden in sogenannten logischen Domains in SimpleDB abgelegt. Nach Amazon sind „the issues of end-to-end security and end-to-end privacy within the cloud computing world [..] more sophisticated than within a single data center not facing the Internet.“ ^[93]. Amazon hat daher verschiedene Sicherheitsmaßnahmen im Rahmen der Cloud-Umgebung beziehungsweise der Amazon Web Services implementiert, die die Vertraulichkeit und Integrität der Systeme und Daten der Kunden schützen und ihnen Hochverfügbarkeit gewährleisten sollen. Dies betrifft auf der einen Seite Maßnahmen für physikalische und operative Sicherheitsaspekte im Rahmen von Amazons Funktion als Provider der Infrastruktur und des Netzwerkes (Amazon-intern, betrifft nicht den Internetanschluss des Kunden) und auf der anderen Seite spezielle Maßnahmen für die einzelnen Amazon Web Services ^[94]. Zusätzlich zu dem reinen Schutz der Daten ist es für die Amazon Web Services ebenfalls von Bedeutung, das Vertrauen der Kunden zu erhalten. Neben den hauptsächlich technischen Maßnahmen zur Sicherung der Systeme und Daten spielen daher für Amazon auch organisatorisch-wirtschaftliche Aspekte des eigenen Unternehmens wie z.B. erworbene Zertifikate nach Statement on Auditing Standards No. 70 und Akkreditierungen eine Rolle in ihrem Sicherheitskonzept ^[95].

6.1.2 Sicherheitsmaßnahmen Cloud Computing Amazon

6.1.2.1 Physikalische Sicherheit

Die Einrichtungen, in denen die AWS Rechenzentren untergebracht sind, sowie die Rechenzentren selbst werden durch verschiedene Zugangs- und Überwachungssysteme geschützt. Amazon nennt hier professionelles Sicherheitspersonal, Videoüberwachungen und nicht näher spezifizierte Intrusion Detection Systeme sowie mehrmalige Zwei-Faktor Authentifizierung für den Zugang zu den Bereichen der Rechenzentren. Den Zugang zu seinen Rechenzentren beschränkt Amazon ausschließlich auf Mitarbeiter, die dieses Recht „berufsbedingt“ benötigen und explizit auf diesen Zeitraum. Der physikalische und elektronische Zugang wird laut Amazon protokolliert und regelmäßig überprüft. Für Externe besteht eine Ausweis- und Eintragungspflicht. Der Zugang ist desweitern nur in Begleitung des autorisierten Personals gestattet ^[96].

6.1.2.2 Netzwerk Sicherheit

Laut Amazon bietet das AWS Netzwerk Schutz vor traditionellen Netzwerkangriffen, wie beispielsweise DDos-, MITM-Attacken, IP Spoofing, Port Scanning und Packet Sniffing durch andere Kunden ^[97]. Als Maßnahmen gegen DDos-Attacken setzt Amazon Syn Cookies und Verbindungslimits ein. Desweiteren schützt sich Amazon vor möglichen DDos Angriffen, indem eine höhere interne Bandbreite bei der Verwendung von Amazon Services bereitgestellt wird als die, die externe Provider Amazon zur Verfügung stellen, wodurch Verbindungsstaus abgeschwächt werden ^[98]. Schutz vor MITM-Attacken bieten SSH Host Keys, die beim ersten Boot einer Instanz automatisch erzeugt werden. Damit nicht schon beim ersten Zugriff per Web Interface auf eine virtuelle Maschine und den Host Key eine MITM-Attacke stattfinden kann, setzt Amazon SSL-geschützte Endpunkte mit Server-Authentifizierung ein. IP Spoofing von EC2 Instanzen wird von Amazon mittels Firewall verhindert. Port Scans von EC2 Kunden sind zwar generell möglich, sind aber per Amazon EC2 Acceptable Use Policy verboten und werden geahndet. Der Versuch Traffic mitzuschneiden, in dem das Interface einer EC2 Instanz in Promiscuous Mode geschaltet wird, wird durch den Einsatz des Xen Hypervisors auf den Host-Systemen von Amazon verhindert.Jeder EC2 Kunde muss nach Amazon zwingend die von Amazon bereitgestellte Inbound Firewall einsetzen. Der eingehende Datenverkehr wird per Default geblockt. Eine Anpassung der Firewall Konfiguration kann der Kunde auf Protokoll-, Port- oder auf Basis von Source IP Adressen vornehmen. Hieraus kann der Kunde unterschiedliche Regeln, die auf die Funktion seiner Instanzen ausgerichtet sind, einrichten. Amazon legt somit dem Kunden in die Hände, den Datenverkehr durch eine sinnvolle Firewall Konfiguration einzuschränken und dadurch die Sicherheit seiner Systeme und Daten zu erhöhen sowie durch zusätzliche Applikationen auf den eigenen Instanzen, beispielsweise IPTables den eingehenden und hiermit auch ausgehenden Datenverkehr noch granularer einzuschränken ^[99].

6.1.2.3 Datensicherheit

Die Verfügbarkeit der in S3, SimpleDB und EBS abgelegten Daten gewährleistet Amazon durch redundante Datenhaltung an mehreren physikalischen Orten. Backup und Recovery von Daten innerhalb der laufenden Instanzen von EC2, S3 oder Simple DB wie z. B. duch bekannte Backup- und Recovery Lösungen wie Symantecs NetBackup oder IBMs Tivoli Storage Manager möglich, stellt Amazon nicht bereit. Diese Aufgabe obliegt laut Amazon den Kunden ^[100]. Den Schutz der Daten vor Manipulation, unberechtigtem Zugriff durch andere EC2 Instanzen/Kunden und durch AWS Administratoren stellt Amazon über verschiedene Mechanismen sicher. Die AWS Administratoren einerseits können laut Amazon nicht auf die Instanzen der Kunden zugreifen und sich an den Gast-System anmelden, der unberechtigte Zugriff durch Instanzen/Kunden wird andererseits bereits über den Einsatz der zuvor beschriebenen Firewalls eingeschränkt. Auf den von Amazon bereitgestellten Host-System laufen verschiedene virtuelle Instanzen unterschiedlicher Kunden zur selben Zeit, teilen sich also die selbe physikalische Hardware. Dass laufende Instanzen nicht untereinander auf ihre Daten zugreifen können, verhindert Amazon durch die Verwendung von Paravirtualisierung und des Xen Hypervisors, der die einzelnen Instanzen und ihre Interfaces voneinander isoliert ^[101]. Die Zuweisung des physikalischen RAMs erfolgt laut Amazon durch gleichartige Mechanismen ^[102]. Gemäß Amazon werden die vom Kunden genutzten Datenblöcke auf den bereitgestellten virtualisierten Festplatten durch den AWS proprietären Disk Virtualization Layer automatisch gelöscht, so dass die Daten vor dem Zugriff anderer geschützt sind. Auch an dieser Stelle weist Amazon ausdrücklich daraufhin, dass der Kunde weitere Schutzmaßnahmen ergreifen sollte, wie z.B. verschlüsselte Dateisysteme ^[103]. Die Vergabe von Berechtigungen auf die Daten innerhalb von S3 und SimpleDB legt Amazon vollständig in die Hände des Kunden, der über differenzierte Zugriffslisten den Zugriff auf die Daten verwalten kann. Löscht der Kunde Daten aus S3 und SimpleDB, wird dieser Vorgang umgehend repliziert und die Speicherbereiche ausschließlich für Schreibvorgänge wieder freigegeben, so dass die Daten überschrieben werden ^[104].

6.1.2.4 Identitäts- und Zugriffsverwaltung

Alle AWS Administratoren verfügen über individuelle stark verschlüsselte SSH Schlüssel für den Zugriff auf die Bastion-Hosts. Bei diesen Bastion-Hosts handelt es sich laut Amazon um spezielle Systeme, die auf den Schutz der Management-Ebene der Cloud Infrastruktur ausgerichtet sind ^[105]. Das Berechtigungskonzept von Amazon bezüglich Zugriff auf die verschiedenen Systeme sieht eine strikte Trennung zwischen den Management-Aufgaben der AWS Administratoren und der Kunden vor. AWS Administratoren besitzen wie bereits zuvor erwähnt keinen Zugriff auf die Instanzen der Kunden. Der Kunde hat die volle Kontrolle über seine Instanz bzw. sein Gast-Betriebssystem, wozu auch unter anderem vollständige Root-Rechte gehören. Amazon empfiehlt seinen Kunden in diesem Zusammenhang anstelle des passwortbasierten Zugriffs auf die Systeme mit Tokens oder bestimmten schlüsselbasierten Methoden zuzugreifen und einen Privilege Escalation Mechanismus einzuführen ^[106]. Unter Privilege Escalation versteht man im Allgemeinen eine Ausweitung von Benutzerrechten. Dies ist z.B. der Fall, wenn ein Administrator zwecks Administrationsaufgaben auf einem System von einem herkömmlichen Benutzer- in den Administratorenkontext wechselt, um über die vollständigen Root-Rechte auf diesem System zu verfügen. Unbedachte, versehentliche Aktionen von Administratoren, aber besonders gezielte Aktionen von Angreifern im Administratorenkontext können erheblichen Schaden auf einem System ausrichten. Es ist anzunehmen, dass Amazon aus diesem Grund seinen Kunden rät, hier einen Schutzmechanismus einzurichten. Anweisungen der Kunden an ihre Instanzen oder z.B. ihre Firewall werden mit dem eigenen X.509 Zertifikat oder dem Amazon Secret Access Key signiert und sind auch nur mit dieser Signatur gültig ^[107].

6.1.2.5 Anwendungssicherheit

Der Kunde greift auf die Amazon Web Services wie auch auf die Instanzen in EC2 und die Daten innerhalb S3 und SimpleDB via Web Interface über das Internet zu. Amazon bietet daher SSL-geschützte Endpunkte für den Zugriff über das Internet wie auch innerhalb der AWS Infrastruktur ^[108]. Hierdurch wird zwar die Verschlüsselung der Verbindung sichergestellt, jedoch keine explizite Verschlüsselung der zu übertragenden Kundendaten. Ebensowenig werden die Daten in S3 oder SimpleDB von Amazon verschlüsselt. Der Kunde muss sich daher überlegen, ob und wie er z.B. durch den Einsatz einer speziellen Verschlüsselungssoftware, seine Daten selber schützt.

6.2 IBM

6.2.1 IBM Blue Cloud

IBM Blue Cloud umfasst unterschiedliche Produkte und Services im Rahmen des Cloud Computing, um integrierte Cloud-Lösungen für Unternehmen entwickeln zu können ^[109].

In diesem Rahmen existieren unterschiedliche Angebote, um skalierbare Systeme, serviceorientierte Architekturen und offene Standards für Unternehmen zu entwickeln, z.B. On Demand Services, um neue Services flexibel und kosteneffizient zu nutzen.

Weiterhin bietet IBM im Rahmen seines Cloud Computing Service das IBM Service Management Center für Cloud Computing an, um Rechenzentren effizient nutzen zu können und alle notwendigen Verfahren und Werkzeuge bereitzustellen. Mit dessen Hilfe ist es möglich, virtuelle Operationen zu optimieren und einzelne Aufgaben innerhalb der Rechenzentren zu automatisieren.

Für eine effektive Verwaltung der Cloud Computing Struktur inklusive des Sicherheitsmanagements bietet IBM das IBM Service Management an, um unterschiedliche Aufgaben innerhalb der virtuellen Umgebungen zu verwalten und zu steuern.

Durch die Nutzung des IBM Service Management Centers und des IBM Service Managements sollen die Kosten gesenkt und die Effizienz, z.B. bei der Verwaltung der Cloud Computing Umgebung gesteigert werden.

6.2.2 Sicherheitsmaßnahmen Cloud Computing IBM

IBM verwendet verschiedene interne Sicherheitspolitiken für eine sichere Umgebung und Operationen innerhalb der Cloud Computing Umgebung. Diese Sicherheitspolitiken sind unabhängig von dem Datenformat oder dem Datentyp. Die jeweiligen Richtlinien richten sich an den folgenden Merkmalen aus ^[110]:

Physikalische Kontrollen
Logische Kontrollen
Sicherheitschecks und Scannen von Schwachstellen
Mitteilen von Sicherheitsvorfällen

IBM weist im Vorfeld darauf hin, dass die dargestellten Informationen hinsichtlich der Systemarchitektur nicht vollständig sind, um deren Sicherheits- und Kontrollfunktionen nicht zu gefährden.

6.2.2.1 Physikalische Sicherheit

Der Zugang zu den einzelnen Kundendaten, den Komponenten des Netzwerks sowie den Gebäuden selbst erfolgt durch mehrere Zugangskontrollen. Die jeweiligen Levels der Zugangsmöglichkeiten richten sich vor allem anhand der Wichtigkeit der Netzwerkkomponenten und gespeicherten Daten aus, d.h. je wichtiger bzw. sensibler die jeweiligen Komponenten innerhalb des spezifischen Bereichs sind, umso größer sind die Sicherungs- und Authentifizierungsmaßnahmen.

Folgende physikalische Sicherheitsvorkehrungen verwendet IBM ^[111] :

Integration der Datenzentren innerhalb des IBM Betriebsgeländes
Überwachung der Gebäudeeingänge mittels Kameras
Datenzentren sind stets verschlossen und Notausgänge alarmgesichert
Datenzentren sind ausgestattet mit wiederkehrenden Kontrollstellen und Einbruchsmeldern
Personal muss sich mittels elektronisch kontrolliertem Zugangssystem autorisieren (CAS – Electronic Controlled Access System)
Vierteljährliche Überprüfung der CAS Zugangslisten auf unautorisierte Änderungen
Jährliche Überprüfung der CAS Zugangslisten auf die Notwendigkeit der erteilten Berechtigungen

Zusätzlich zu den physikalischen Schutzmaßnahmen vor Ort werden weitere Schutzmaßnahmen für den Remotezugriff, z.B. durch das IBM Personal, von außerhalb der Rechenzentren vorgenommen. Dabei sind vor allem die regelmäßige Passwortänderung im Fokus aber auch welche Berechtigungen an eine Personengruppe verteilt werden, um festzulegen, dass nur berechtigtes Personal auf die Systeme in den Rechenzentren zugreifen kann ^[112].

Für die Vergabe spielt die Sicherheitsadministration und deren Verwaltung der Sicherheitskontrollen eine wichtige Rolle. Die Verwaltung der Sicherheitskontrollen erfolgt über das IBM Netzwerk Management Gruppen (Network Management Group) auf Gruppenbasis.

6.2.2.2 Netzwerk Sicherheit

IBM unterscheidet im Zusammenhang mit der physikalischen Sicherheit zwischen der physikalischen Sicherung und der logischen Sicherung. Dabei sind die Zugänge der Netzwerkanwendungen und Services des Kunden von den Infrastrukturanlagen und Funktionen getrennt. Hierbei entsteht die Problematik, dass der Schutz des logischen Zugangs komplizierter ist als die Kontrolle des physikalischen, da die Kontrolle und Sicherung weit komplexer ist als der reine physikalische Zugang.

Ziel der logischen Kontrolle ist es einerseits autorisiertem Personal benötigten Zugriff zu gewähren und andererseits unautorisiertem Personal Zugriff auf Informationen zu entziehen ^[113].

Folgende Sicherheitskontrollen werden im Zusammenhang mit der Sicherung des logischen Zugriffs angewendet ^[114]:

Network Layer (Level 3) Technologie, diese beinhaltet z.B. In/Outbound Access Control Lists (ACLs)
Intrusion Detection System für eine ganzheitliche Netzwerküberwachung auf allen Ebenen
Firewall, um den ein- und ausgehenden Verkehr anhand spezifischer Sicherheitskriterien zu prüfen
Audit Logging, analysiert z.B. die Logdateien der unterschiedliche Netzwerkgeräte auf Informationen und Fehlermeldungen

Trennung der Daten und Anwendungen

Um innerhalb der IBM Cloud Architektur eine strikte Trennung der Daten und Anwendungen des Kunden von anderen Kundenanwendungen aber auch von IBMs internem Netzwerk und dem Intranet durchzuführen, verwendet IBM dedizierte Virtual Local Area Networks (VLANs) und Zugangskontrolllisten (ACLs) ^[115]. Zusätzlich werden die VLANs mit einer Firewall von IBMs internem Netzwerk getrennt.

Die Systemarchitektur besteht im Weiteren aus klaren Kontrollzonen (Zonen), die als Puffer zwischen vertrauenswürdiger und nicht vertrauenswürdigenr Software und Systemen dient ^[116]. Um die unterschiedlichen Zonen zu schützen werden mehrfach Netzwerksicherungskomponenten und unterschiedliche Mechanismen zur Authentifikation und Autorisierung eingesetzt, um die einzelnen Systeme, Kundendaten und Anwendungen vor Angriffen zu schützen. Sie werden weiterhin durch die jeweiligen Sicherheitsrichtlinien definiert, um ein bestimmtes Sicherheitslevel zu erreichen.

Die einzelnen Sicherheitszonen werden durch IBM als Trusted Zone, Semi-Trusted Zone und Untrusted Zone bezeichnet und werden folgendermaßen definiert ^[117].

Trusted Zone (vertrauenswürdige Zonen)

Die Trusted Zone definiert den primären Bereich, in dem Sicherheitsmaßnahmen bezüglich des Verhaltens, Kompetenzen von Benutzern und die direkte Kontrolle der Sicherheitsrisiken stattfindet. Die "IBM Blue Zone" ist die Trusted Zone innerhalb der IBM Cloud Architektur. Innerhalb dieser Trusted Zone können Anwendungen und Kunden auf andere Komponenten derselben Zone zugreifen.

Semi-Trusted Zone (halb-vertrauenswürdige Zonen)

Innerhalb dieser Zone können nur Komponenten verwendet werdet, die die Sicherheitsmaßnahmen berücksichtigen. Verknüpfungen z.B. außerhalb der Trusted Zone, können nicht auf Anwendungen innerhalb der Trusted Zone liegen. Die Semi-Trusted Zone bezeichnet IBM als Yellow und Green Zones.

Untrusted Zone (nicht vertrauenswürdige Zonen)

Innerhalb dieser Zonen können keine Sicherheitsrichtlinien oder –kontrollen durchgeführt werden. Sie ergeben sich z.B. wenn von außen per Remote-Zugriff auf eine Semi-Trusted oder Trusted Zone zugegriffen wird. Sobald die jeweilige Authentifizierung des Benutzers erfolgt ist, hat dieser dieselben Möglichkeiten wie ein Benutzer innerhalb der Semi-Trusted oder Trusted Zone.

6.2.2.3 Datensicherheit

Vertraulichkeit der Informationen

In diesem Zusammenhang konkretisiert IBM die Vertraulichkeit der Informationen und Daten, da nur eine richtige Kombination von physikalischen und logischen Zugangskontrollen eine stimmige Kontrolle bietet, um sicherzustellen das nur berechtigte Personen, Einheiten oder Prozesse auf diese Informationen zugreifen können.

Zusätzlich zu den vorhandenen Zugangskontrollen und der Vertraulichkeit der Informationen und Daten spielt die Integrität der Nachrichtenübertragung eine wichtige Rolle, da sie entscheidend ist, um zu gewährleisten, dass die erhaltene Nachricht der ursprünglich versendeten entspricht, sprich das die Nachricht authentisch ist ^[118]. In diesem Zusammenhang verwendet IBM die Virtela VPN, die eine sichere Datenübertragung über eine globale IP Infrastruktur der Firma Virtela sicherstellt. Die Virtela VPN überprüft die erhaltenen Daten mit den ursprünglichen Daten, so dass diese nicht verändert werden können ^[119].

6.2.2.4 Identitäts- und Zugangsmanagement

IBM verwendet unterschiedliche Authentifizierungsverfahren, um zu gewährleisten, dass zum Einen Personen nur Zugriff auf die Daten erhalten, zu denen sie berechtigt sind und zum Anderen, dass die beteiligten Personen auch wirklich die sind, die sie vorgeben zu sein ^[120]. In diesem Rahmen werden verschiedene Kombinationen von Authentifizierungskontrollen verwendet. Diese umfassen die Angabe von Passwörtern oder PINs und ID-Karten oder physikalischen Schlüsseln sowie Fingerabdruck- oder Signaturinformationen.

IBM verwendet für die Benutzerauthentifizierung innerhalb ihrer Cloud Architektur die Virtela VPN ^[121].

6.2.2.5 Anwendungssicherheit

Um zusätzlich zu den infrastrukturellen Sicherheitsmaßnahmen weiteren Schutz zu gewährleisten, sind weitere Maßnahmen auf der Kundenseite notwendig. Diese betreffen die Durchsetzung von Sicherheitspraktiken innerhalb der Ogranisation des Kunden, wie z.B. den Einsatz eines Service-Adminstrators als direkter Kontakt zur Cloud Computing Architektur oder auch die richtige Verwendung und Vergabe von Passwörtern durch Benutzer ^[122]. In diesem Rahmen spielt die regelmäßige Änderung von Passwörtern durch den Benutzer in festgelegten Intervallen und anhand bestimmter Kriterien, z.B. der Länge des Passwortes eine entscheidende Rolle.

6.2.2.6 Auditing

Im Rahmen des Auditing steht die Sicherheit der Netzwerkinfrastruktur im Fokus. Sie umfasst regelmäßige Sicherheitstests, um die Integrität der Sicherungsmaßnahmen und den damit verbundenen Netzwerken, Services und Anwendungen sowie den einzelnen Sicherheitsstandards zu gewährleisten und ständig zu verbessern ^[123]. Hierbei nimmt die Messung der Effektivität der Kontrollprozesse und die proaktive Einschätzung der Sicherheitsrisiken durch fortwährendes Melden, Beobachten, Messen und Bewerten von Sicherheitsverstößen eine wichtige Rolle ein.

6.3 Microsoft

6.3.1 Microsoft Azure

Abbildung 11: Mircosofts Azure Plattform ^[124]

Microsoft Azure bildet die Cloud Computing Umgebung von Mircosoft und beinhaltet Cloud-basierte Dienste, die es dem Kunden ermöglicht Hosting und Managementdienste im Internet zu nutzen. Im Rahmen von Microsoft Azure wird Entwicklern eine Entwicklungsumgebung zur Verfügung gestellt, um neuartige Anwendungen mittels des Service plus Services-Ansatzes herzustellen.

Die Microsoft Azure Plattform besteht aus den folgenden Diensten, welche der jeweilige Kunde nutzen kann ^[125]:

Server-Management und –Management
Microsoft SQL Services für Datenbankdienste und Berichtserstattung
Microsoft .NET Services
Live Services für gemeinsame Verwendung von Dokumenten, Daten und Informationen sowie dessen konsistente Speicherung und Synchronisierung mit mobilen Endgeräten, Anwendungen und Websites
Microsoft SharePoint und Dynamics CRM Services für die geschäftliche Nutzung von Anwendungen in der Cloud Umgebung

Azure stellt in diesem Zusammenhang die Entwicklungsplattform für Entwickler dar, die im Zuge der Entwicklung auf bestehende Technologien und Werkzeuge wie .NET und "Live" - Services aber auch Visual Studio, PHP, Active Directory, Eclipse, C# und OpenID zurückgreifen können ^[126].

Weiterhin beinhaltet die Cloud Infrastruktur Rechenzentren in den USA und Dublin, die entsprechende Rechenkapazitäten für die genutzten Anwendungen liefern.

6.3.2 Sicherheitsmaßnahmen Cloud Computing Microsoft

Im Zuge der Nutzung von Cloud Computing ergeben sich verschiedene Probleme, die von den Unternehmen gelöst werden müssen, um ein sicheres Produkt anzubieten und vor allem die gespeicherten Daten vor unautorisiertem Zugriff aber auch vor Datenverlust zu schützen. Diesem Problem muss weiterhin eine erhöhte Aufmerksamkeit zugeschrieben werden, da vor allem im Betrieb der gehosteten Anwendungen Man-in-the-Middle Attacken und andere Gefahren lauern, mit dem Ziel sensible Geschäftsdaten zu erhalten.

Microsoft hat im Zuge seiner Cloud Computing Infrastruktur drei Hauptschwerpunkte in den Fokus der Sicherheit gestellt ^[127]:

Erstellung eines risikobasierten Informationssicherheitsprogramms, um die aktuelle Sicherheit und mögliche Bedrohungen zu bewerten und entsprechend der potentiellen Gefahr zu priorisieren
Um die einzelnen Risiken bekämpfen und verwalten können bedarf es aktueller und detaillierter Sicherheitskontrollen
Um die erstellten Kontrollen effizient in allen Anwendungen und Infrastrukturen zu nutzen, muss zunächst ein Grundgerüst (Framework) erstellt werden, dass durch die Entwicklungsabteilung entwickelt und in den Anwendungen implementiert wird

Abbildung 12: Microsoft Kundengruppierung innerhalb der Cloud Infrastruktur ^[128]

Die Microsoft Cloud Computing Umgebung ist aufgeteilt in drei Ebenen. Der physischen, logischen Infrastruktur sowie der gehosteten Anwendungen und Plattform Services. Die physische Infrastruktur beinhaltet die einzelnen Datenzentren sowie deren Hardware und Komponenten um die Services und das Netzwerk zu unterstützen. Die logische Infrastruktur beinhaltet die operativen Systeminstanzen, Netzwerke und die unstrukturierten Datenspeicherungen egal ob diese auf virtuellen oder physischen Objekten ablaufen. Die Identitäts- und Verzeichnisspeicher, berechnende Anwendungen in Form von zum Beispiel Internet Information Services, .NET Framework und Microsoft SQL Server und dem Domain Name System (DNS) sowie weiteren Funktionen des Onliner Services sind in den Plattform Services integriert.

Aufgrund der unterschiedlichen Daten, die in der Microsoft Cloud gespeichert und verwendet werden, unterscheidet Microsoft unterschiedliche Formen und Ausprägungen der Sicherheits- und Datenschutzanforderungen je nach genutzter Anwendung. In diesem Zusammenhang wurden drei Nutzer- und Anwendungsgruppen ermittelt ^[129].

Consumer und Small Business umfasst Produkte und Anwendungen wie den Windows Live Messenger, Windows Live Hotmail und Microsoft Office Live sowie weitere Anwendungen. Unternehmensanwendungen wie Microsoft Dynamics CRM Online und Microsoft Productivity Online Standard Suite werden den Enterprise Services zugeordnet. Anwendungen, die von Drittanbietern bereitgestellt werden, werden den Third-Party Hosted Services zugeordnet.

Um die einzelnen Gefahren im Rahmen der Microsoft Cloud Computing Umgebung zu ermitteln und anhand dieser Erkenntnisse Sicherheitsmaßnahmen zu entwickeln, hat Microsoft eine eigene Abteilung, das „Online Services Security and Compliance Team“ (OSSC), gebildet ^[130]. Sie nimmt einen hohen Stellenwert innerhalb der Sicherheitsfunktionen von Microsoft ein und koordiniert, plant und testet die Umsetzung der jeweiligen internen Sicherheitsmaßnahmen auf der Ebene der Infrastruktur sowie während der Entwicklung von Anwendungen und Services. Für die Umsetzung von allgemein gültigen und standardisierten Sicherheitskonzepten und weltweiten Anforderungen verwendet Microsoft zertifizierte Verfahren. Sie umfassen z.B. die beiden Verfahren des International Organization for Standardization/ International Electrotechnical Commission 27001:2005 (ISO/IEC 27001:2005) und dem Statement of Auditing Standard (SAS) 70 Type I und Type II.

Alle Anwendungen und Services basieren auf den Cloud Platform Services und der Cloud Infrastruktur, um die gemeinsamen Ressourcen und deren Sicherheits- und Datenschutzanforderungen zu berücksichtigen. Auf die einzelnen Sicherheits- und Datenschutzanforderungen sowie deren Umsetzung wird im Laufe dieses Kapitels weiter eingegangen.

6.3.2.1 Datenschutz im Microsoft Azure

Aufgrund der Sensibilität der Kundendaten und der damit verbundenen Sicherheitsmaßnahmen für die gespeicherten Daten, werden neue Produkte, Services und Prozesse unter Berücksichtigung der jeweiligen globalen Datenschutzgesetzte von Microsoft entwickelt. In diesem Zusammenhang wurden unterschiedliche Sicherheitstechniken und Verfahren angewandt, um persönliche Daten vor dem unautorisierten Zugriff zu schützen ^[131]. Hierzu verfolgt Mircosoft das sogenannte „PD3+C“ – Prinzip. Es umfasst verschiedene Verfahren um sicherzustellen, dass der Datenschutz während der Entwicklungsphase von Produkten nicht vernachlässigt wird ^[132].

Das „PD3+C“ – Prinzip beinhaltet die folgenden Ansätze ^[133]:

Datenschutz durch Design ("Privacy by Design")
Datenschutz als Standard ("Privacy by Default")
Datenschutz im Einsatz ("Privacy in Deployment")
Kommunikation ("Communication")

Datenschutz durch Design: Datenschutz durch Design befasst sich mit der Speicherung der Kundendaten und wie die Sicherheit dieser Daten während der Phase der Anwendungsentwicklung, -veröffentlichung und –verwaltung sichergestellt wird. Die Speicherung muss in diesem Zusammenhang einen bestimmten Zweck erfüllen und der Kunde muss über diese Speicherung informiert werden, um zu entscheiden, ob er dieser Speicherung zustimmen möchte.; Zusätzlich werden die gespeicherten Daten anhand ihrer Sensibilität bewertet und anhand der Klassifizierung weitere Sicherheitsmaßnahmen, wie z.B. die Verschlüsselung während der Datenübertragung und/ oder Speicherung, angewandt.

Datenschutz als Standard: Die Datenspeicherung von wichtigen Daten erfolgt nur nach der vorherigen Einwilligung des Kunden. Weiterhin wird in diesem Prinzip festgelegt, dass der Zugriff auf diese Daten nur durch entsprechende Zugangskontrollen im Rahmen der Identitätsautorisierung erfolgen darf.

Datenschutz im Einsatz: Um einen allgemeinen Standard innerhalb der genutzten Anwendungen in Microsofts Cloud System zu gewährleisten, übermittelt Microsoft jedem Geschäftspartner seine Datenschutz- und Sicherheitsmaßnahmen

Kommunikation: Durch die Nutzung von White Papers oder Publikationen informiert Microsoft die breite Öffentlichkeit über Datenschutzmaßnahmen.

6.3.2.2 Security Incident Management

Aufgrund der Tatsache, dass es nicht möglich ist alle Gefahren, die im Rahmen des Cloud Computing auftreten können, auszuschließen, sondern nur abzuschwächen bzw. im Vorfeld Maßnahmen zu treffen, verwendet Microsoft ein Verfahren, um schnell und effizient auf entsprechende Vorfälle reagieren zu können und Schutzmaßnahmen einzuleiten. Hierzu hat Microsoft das sogenannte „Security Incident Management“ entwickelt.

Dieses Verfahren besteht aus insgesamt sechs Phasen, um auf einen Sicherheitsvorfall reagieren zu können.

Diese Phasen beinhalten die Vorbereitung in Form von Schulungen der Mitarbeiter und die Identifikation der Ursache für das Ereignis in den unterschiedlichen Schichten der Cloud Computing Umgebung. In dieser Phase ist eine enge Zusammenarbeit mit anderen Teams zur Identifizierung des Vorfalls wichtig. Im weiteren Ablauf des Prozesses folgen die Phase zur Eindämmung und Abschwächung des Risikos, sobald die Ursache ausfindig gemacht werden konnte. Zuletzt ist es notwendig innerhalb der Wiederherstellungsphase eventuell verloren gegangene Daten wiederherzustellen und Konsequenzen, im Erfahrungsprozess, aus dem Vorfall für zukünftige Probleme zu ziehen.

6.3.3 Sicherheitsebenen Cloud Computing Microsoft

Um einen wirksamen Schutz für die allgemeine Sicherheit der Cloud Computing Infrastruktur aber auch der Kundendaten im speziellen zu schaffen, verwendet Microsoft verschiedene Ebenen der Sicherung.

Dies umfasst die Sicherheit der physikalischen und der Netzwerkschicht sowie den Schutz der Daten mit einem umfassenden Identitäts- und Zugangsmanagements. Weiterhin ist jede einzelne Anwendung mit einem entsprechenden Sicherungsverfahren ausgestattet, welches sich vor allem in den Entwicklungsphasen des Produktes widerspiegelt. Zum Schluss bedarf es einer konsequenten Überprüfung und einer schnellen Informationsweitergabe der verbundenen Systeme innerhalb der Cloud Infrastruktur, um Schwachstellen schnellstmöglich beseitigen zu können.

Diese einzelnen Sicherheitsebenen seitens Microsoft werden im weiteren Verlauf näher erläutert.

6.3.3.1 Physikalische Sicherheit

Die physikalische Sicherheit umfasst hauptsächlich den Schutz der Datenzentren, um damit den Schutz der gespeicherten Kundendaten zu gewährleisten.

In diesem Zusammenhang wird ein kombiniertes Verfahren aus verschiedenen technischen Möglichkeiten angewendet, um einen größtmöglichen Schutz zu bewahren und sicherzustellen, dass nur zuständiges Personal Zugang zu sensiblen Bereichen der Datenzentren besitzt. Die verwendeten technischen Möglichkeiten sind z.B. Kameras, biometrische Zugangskontrollen, Kartenlesegeräte und Alarmsysteme sowie traditionellen Maßnahmen (Schlösser und Wachpersonal).

Im Folgenden werden die von Microsoft verwendeten drei Ebenen zur Sicherung des Zugriffs zu den Datenzentren erläutert ^[134]. In der ersten Ebene erfolgt die Zugangsbeschränkung des Personals auf bestimmte Bereiche der Datenzentren, die je nach Personengruppe, z.B. Personal des Datenzentrums oder das Lieferantenpersonal festgelegt wird. Hierbei wird unterschieden, welche Personengruppen Zugang zu welchen Bereichen der Gebäude erhalten, um damit nur bestimmten Personen Zugang zu den Serverräumen, in denen Applikationen und Services der Kunden gehostet werden, zu gewähren.

Die zweite Ebene beinhaltet die abgestuften Autorisierungsmaßnahmen zu den Kundendaten durch das operative Personal in den Datenzentren. Je nach Ausprägung der Sicherheitsbereiche wird das Level der Authentifizierung erhöht. Zu den Formen der Authentifizierung gehören Identifikation, Erfassung und Überwachung von Zugängen aber auch die Verwendung von Zugangstokens (access tokens).

Die letzte, dritte Ebene der Sicherheitsmaßnahmen innerhalb der Datenzentren umfasst ein zentralisiertes Zugangsmanagement. Dieses Zugangsmanagement verwaltet den Zugang zu den Anlagen und beinhaltet die Anfrage, Bestätigung und Gewährung des Zugangs auf die unterschiedlichen Bereiche der Datenzentren. Zusätzlich ist die Bestätigung des Zugangs von mehreren autorisierenden Stellen notwendig.

6.3.3.2 Netzwerk Sicherheit

Innerhalb der Ebene des Netzwerkes werden verschiedene Verfahren zur Sicherung der Geräte der Datenzentren aber auch deren Netzwerkverbindungen getroffen. Beispielsweise wird spezialisierte Hardware, wie Loadbalancer oder Firewalls, verwendet, um ein Eindringen zu verhindern, aber auch um Angriffe wie DDoS-Attacken abzuwehren. Durch die Verwendung von abgestuften Zugangskontrollisten (access control list - ACL’s) werden weiterhin VLAN‘s (virtual local area network) und Anwendungen voneinander getrennt. Gleichzeitig werden auf der Hardwareebene Application-Gateways verwendet, um einzelne Datenpakete zu prüfen und gegebenenfalls bei verdächtigen Daten zu alamieren oder betroffenen Netzwerkverkehr zu stoppen.

Zusätzlich zu den Sicherheitsmaßnahmen auf der Hardwareebene werden globale, redundante, interne und externe DNS Infrastrukturen innerhalb der Cloud Computing Umgebung verwendet. Diese redundanten Maßnahmen bieten Fehlertoleranz und werden durch Clusterung der DNS Server erreicht ^[135]. Weitere Sicherheitsmaßnahmen können DDoS-Attacken abschwächen und DNS Cluster überwachen, um festzustellen, ob sich innerhalb der Konfiguration der DNS Zone eventuell unautorisierte Software befindet.

6.3.3.3 Datensicherheit

Die Datensicherheit wird durch Mircosoft allgemein mittels des Security Development Lifecycle (SDL) Kryptografiestandards sichergestellt, welcher die Konzeption und Entwicklung von Software im Bezug auf Sicherheitsstandards im Fokus hat^[136]. Im Zuge dieses Verfahrens wird z.B. definiert, dass mindestens eine 128 Bit Verschlüsselung bei Nutzung einer symmetrischen Codierung und mindestens 2048 Bit bei einer asymmetrischen Codierung verwendet werden muss^[137].

Weiterhin werden die Sicherheitsmaßnahmen hinsichtlich des zu erwartenden Schadens und der Sensibilität der Daten eingestuft. Das bedeutet, dass die Kategorien festlegen, welcher Schaden (finanziell und rufschädigend) bei einem Sicherheitsverstoß eintreten kann und welche Verschlüsselungsanforderungen an die zu speichernden bzw. zu übertragenden Daten gestellt werden. Zum Beispiel werden Daten die als „mittel“ eingestuft wurden lediglich bei externen Netzwerkübertragungen oder transportablen Datenträgern verschlüsselt. Wohingegen Daten mit einer hohen Einstufung im Speicher, in internen Systemen und während der Übertragung der Daten verschlüsselt werden^[138].

6.3.3.4 Identitäts- und Zugangsmanagement

Um Zugang zu bestimmten Programmen oder Anwendungen zu gewähren, verwendet Microsoft innerhalb seiner Cloud Computing Umgebung ein rollenbasiertes Zugangsverfahren, welches sich an den Aufgabenbereichen bzw. der Arbeitsbeschreibung der Person orientiert und anhand dessen Zugriffsrechte vergeben kann. Das bedeutet im Umkehrschluss, dass der Benutzer zunächst keine Rechte besitzt und diese erst, je nach Aufgabenbereich, freigeschaltet werden^[139].

Ferner sind unterschiedliche Autorisierungsverfahren für einzelne Anwendungen oder Anlagen notwendig. Diese sind, wie im Vorfeld bereits beschrieben, z.B. Passwörter, Hardware Tokens oder Smart Cards^[140].

Überdies wird ein ständiger Abgleich der Benutzerkonten durchgeführt, ob ein Benutzerkonto nicht mehr benötigt wird bzw. ob die jeweiligen Zugriffsrechte teilweise oder vollständig wieder entzogen werden müssen. Somit wird sichergestellt, dass kein Benutzer Zugriffsrechte für Anwendungen besitzt, welche er nicht benötigt bzw. dass keine ungenutzten Benutzerkonten existieren, die ggf. ein Sicherheitsrisiko darstellen könnten^[141].

6.3.3.5 Anwendungssicherheit

Die Sicherstellung der Anwendungssicherheit ist ein Schlüsselelement innerhalb von Microsofts Cloud Computing. Sie stellt sicher, dass die Daten in den Anwendungen, aber auch während der Übertragung von außen sicher und geschützt sind^[142].

Aufgrund dieses besonderen Fokus auf die Anwendungssicherheit verwendet Microsoft für alle entwickelten Produkte und Anwendungen den sogenannten „Security Development Lifecycle“ (SDL), der in 2004 entwickelt wurde. Dieser Prozess ist vollständig in den Entwicklungsprozess von Anwendungen integriert, von der Design- bis zur Fertigstellungsphase. Der Prozess ist aber nicht als Softwareentwicklungsprozess zu verstehen, wie z.B. das Wasserfallmodell oder agile Softwareentwicklungsmethoden sondern richtet den Fokus auf Sicherheitsmaßnahmen und deren strikte Integration in den Entwicklungsprozess. Während des SDL Prozesses spielen in allen Prozessphasen Training und Schulung der beteiligten Personen eine entscheidende Rolle, um genaue Kenntnis über die jeweiligen Gefahren und Sicherungsmaßnahmen zu erhalten^[143].

Der Prozess des „Security Development Lifecycle“ lässt sich anhand der folgenden Darstellung kurz näherbringen:

Abbildung 13: Prozess des "Security Lifecycle Development" (SDL) ^[144]

Im Folgenden werden die einzelnen Phasen des Prozesses näher erläutert^[145]:

Innerhalb der „Requirements“-Phase identifiziert das Entwicklungsteam die jeweiligen Sicherheitsrisiken in Abhängigkeit von einander um die Anwendung sicherer zu machen aber auch gleichzeitig die Bedienbarkeit für Kunden nicht zu beeinträchtigen.

Während der „Design“-Phase werden die notwendigen Sicherheitsmaßnahmen ermittelt und die potentiellen Gefahren dokumentiert. Aus den Daten der „Requirement“-Phase können zudem neue Risiken ermittelt werden, die im Umfeld der Anwendung stehen.

In der „Implementation“-Phase findet die eigentlich Codierung und das Testen der Anwendung statt. In dieser Phase ist es wichtig, auf die Schwachstellen der jeweiligen Codierung zu achten und diese ggf. zu beseitigen.

Nach Fertigstellung der Anwendung findet in der „Verification“-Phase der Beta-Test statt. Hierbei werden auch aktuelle Sicherheitsrisiken in Betracht gezogen, die eventuell im Vorfeld nicht bekannt waren, um somit ein möglichst reales Testresultat liefern zu können. Auch ist es notwendig aufgrund der aktuellen Sicherheitsrisiken, diese bekannten Risiken zu analysieren und ggf. zu beseitigen oder abzuschwächen.

Nach dem erfolgreichen Testen der Anwendung erfolgt in der „Release“-Phase der sogenannte „Final Security Review“ (FSR) und je nach Notwendigkeit der „Operational Security Review“ (OSR). Beide Prozesse sollen sicherstellen, dass alle notwendigen Sicherheitsrisiken berücksichtigt und Sicherheitsstandards eingehalten wurden, bevor das Programm letztlich in die Cloud Umgebung integriert werden kann.

Nach Integration des Programmes in die Cloud Umgebung werden durch das „Security Incident Management“ in der „Response“-Phase, gemeldete Sicherheitsvorfälle zusammen mit anderen Teams analysiert, untersucht und beseitigt.

6.3.3.6 Host Security Auditing and Reporting

Diese Sicherheitsphase innerhalb der Microsoft Cloud umfasst vielfältige Ebenen der Sicherheitskontrollen und kann daher nicht einer spezifischen Ebene, wie z.B. der physikalischen Schicht zugeordnet werden.

Dies ergibt sich aus der Tatsache, dass das „Host Security Auditing and Reporting“ zum Einen täglich die Hostsysteme auf eventuelle Schwachstellen überprüft, zum Anderen aber auch Log Dateien von kritischen Servern anhand vorher definierter Aktivitäten („Events-of-interest“) angefertigt werden. Diese „Events-of-Interest“ können z.B. Konfigurationsänderungen der Sicherheitsmaßnahmen oder ein unautorisierter Zugriff auf Systeme oder Anwendungen sein ^[146].

Mit Hilfe dieser ermittelten Daten soll das OSSC Team verdächtige Aktivitäten analysieren und erkennen, um damit die Sicherheit der Microsoft Cloud Umgebung sicherzustellen.

6.4 Vergleich der Anbieter

Abbildung 14: Übersicht der betrachteten Cloud Computing Anbieter

Im folgenden Teil der Betrachtung der "Sicherheitsrelevanten Aspekte des Cloud Computing" werden die Aussagen der Sicherheitskonzepte der dargestellten Anbieter (Amazon, IBM und Microsoft) zusammengefasst, um eine Aussage darüber treffen zu können, inwiefern die jeweiligen Anbieter unterschiedliche Konzepte verwenden und deren Einschätzung zu den jeweiligen Sicherheitsrisiken.

Zunächst muss vorangestellt werden, dass die Betrachtung der Sicherheitskonzepte der drei Anbieter auf deren Unterlagen erfolgte, welche im Internet abrufbar waren oder durch direkten Kontakt mit dem Anbieter zugesandt wurden. Es ist zu vermuten, dass die verwendeten Unterlagen keinen vollständigen Einblick in die Infrastruktur des Anbieters und dessen Sicherheitsmaßnahmen geben können, da dies ein Risiko für dessen Sicherheitskontrollen und -management darstellt und dadurch Schwachstellen für potentielle Angreifer entstehen können, wie es z.B. von IBM erwähnt wird.

Werden die Unterlagen der Anbieter herangezogen, die den Verfassern dieser Arbeit vorliegen, so ist festzustellen, dass zu den jeweiligen Sicherheitsmaßnahmen zum Schutz der Cloud Computing Infrastruktur und deren Anwendungen kein richtiger Vergleich gezogen werden kann. Dies ergibt sich daraus, dass je nach Anbieter lediglich Übersichten über die einzelnen Verfahren verfügbar waren, z.B. Amazon und damit ein Vergleich ohne detailliertere Angaben der Anbieter nur schwer möglich ist.

Weiterhin ist der Prozess zur Sicherung der Cloud Computing Infrastruktur ein kontinuierlicher Prozess, so dass eventuell vorliegende Sicherheitskonzepte überarbeitet werden und an aktuelle Sicherheitsrisiken angepasst werden. Dieser Prozess ist am Beispiel von Amazon und dessen Cloud Infrastruktur gut erkennbar, da in den letzten Tagen eine aktualisiertere Version des Whitepapers "Amazon Web Services: Overview of Security Processes" veröffentlicht wurde. Dieses Dokument, welches hier von der Amazon Website heruntergeladen werden kann, konnte jedoch aufgrund der späten Veröffentlichung nicht in dieser Arbeit berücksichtigt werden.

7 Fazit

Unter Betrachtung der oben gemachten Aussagen hinsichtlich der sicherheitsrelevanten Aspekte des Cloud Computing ist herauszustellen, dass die Sicherheit der Infrastruktur des Cloud Computings auf der Erkenntnis beruht, dass der Zugriff auf die jeweiligen Cloud Anwendungen nur über das Internet möglich ist und somit spezielle Sicherheitsmaßnahmen durch die Cloud Computing Anbieter getroffen werden müssen, um den Schutz der Anwendungen und der Cloud Infrastruktur zu gewährleisten.

Aufgrund dieser Erkenntnis ergibt sich eine logische Struktur, die auf der Erkenntnis beruht, dass unterschiedliche Ebenen, physikalisch wie auch logisch, innerhalb eines Sicherheitskonzeptes betrachtet werden müssen, um alle möglichen Gefahren abwehren zu können. Dabei müssen Fragen erörtet werden, wie sich ein Anbieter vor Netzwerkangriffen schützen kann, wie einzelne Instanzen und Daten isoliert werden können und wie auf diese Instanzen mittels Virtualisierung und der verwendeten Hardware zugegriffen werden kann. Da der Kunde das Hosting seiner Daten aber auch seiner verwendeten Anwendungen nicht mehr selber verwaltet, sondern dies durch einen externen Dienstleister durchführen lässt, stellt sich für ihn letztlich auch die Frage wie sicher seine Daten bei dem Anbieter sind (Verfügbarkeit) und wie diese sicher übertragen werden können (Verschlüsselung). Gleichzeitig muss die Frage geklärt werden, welche sicheren Zugangsarten durch den Provider angeboten werden und was man als Kunde selber tun muss, um sicherzustellen, dass keine unberechtigten Personen Zugriff auf eigene Daten und Anwendungen erhalten. Diese verwendete Struktur sieht daher ein Konzept vor, welches auf der untersten Ebene des Netzwerkes beginnt (physikalisch Schicht) und auf der Ebene des Anwenders endet. Hier ist zusätzlich zu erwähnen, dass die Herausgeber dieser Arbeit keine Kenntnis über die interne Struktur der jeweiligen Anbieter erlangen konnten, um einen detaillierten Einblick in die jeweiligen Sicherheitsmaßnahmen zu erhalten. Dies ergibt sich daraus, dass zu detaillierte Angaben zu der Infrastruktur oder den einzelnen Sicherheitsmaßnahmen eine Sicherheitslücke darstellen würden.

Unter Betrachtung dieser Aussagen ist zudem festzustellen, dass die erwähnten Sicherheitsmaßnahmen auch gleichzeitig Risiken darstellen, wenn diese Sicherheitsmaßnahmen nicht entsprechend ihrer Möglichkeiten und ihres Zwecks verwendet werden. Dies ist z.B. an einer Firewall erkennbar. Sie ist grundsätzlich eine Schutzmaßnahme, kann jedoch aufgrund einer falschen Konfiguration durch den Anbieter oder Kunden ein Risiko und eine erhebliche Sicherheitslücke darstellen. Diese Sicherheitslücke kann z.B. durch die Firewall Konfiguration "allow any any" bewirkt werden, da dadurch jeglicher Traffic für das Netzwerk erlaubt wird und damit potentielle Angreifer den vollen Zugriff auf das Netzwerk haben. Ein weiteres Beispiel sind Passwörter. Sie sind ein wirksamer Schutz gegenüber Eindringlingen, da nur dem Benutzer mit seinem individuellen Benutzernamen das entsprechende Passwort bekannt ist. Jedoch kann hier eine niedrige Passwortlänge oder die Verwendung eines einfachen und leicht zu merkenden Passwortes in Form eines Namens, Strasse oder Geburtsdatums dazu führen, dass das System anfällig wird, da das Passwort durch ein entsprechendes Programm leicht zu knacken ist. Daher ist die Berücksichtigung von verschiedenen Richtlinien, z.B. Passwortlänge und Komplexität sowie regelmäßige Änderung sowohl den Kunden wie auch den Cloud Computing Anbietern dringend anzuraten.

Letztlich ist nicht nur der Anbieter der Cloud Infrastruktur gefordert für entsprechende Sicherheitsmaßnahmen zu sorgen, sondern auch der Kunde selbst. Dies schließt vor allem Maßnahmen ein, die der Anbieter selbst nicht leisten kann oder will. Dies kann z.B. ein regelmäßiges Backup der gespeicherten Daten oder eine zusätzliche Verschlüsselung der Daten sein, wenn die Datenübertragung unverschlüsselt über das Netzwerk an den Anbieter erfolgt. Der Kunde kann somit nicht die komplette Verantwortung auf den Anbieter abschieben und darauf vertrauen, dass dieser alle möglichen Maßnahmen zur Sicherheit trifft. Es wird ebenso ein Mindestmaß an Verantwortung und ein entsprechendes technisches Verständnis verlangt, um die notwendigen Sicherheitsvorkehrungen treffen zu können.

Im Rahmen dieser Arbeit wurde zusätzlich festgestellt, dass der Begriff Cloud Computing noch nicht eindeutig definiert wurde und somit keine einheitlichen Standards hinsichtlich der beteiligten Anwendungen und Prozesse getroffen worden sind, da das Thema Cloud Computing derzeit noch "in den Kindersschuhen steckt". Damit einhergehend sind die damit verbundenen Sicherheitsmaßnahmen und -kontrollen nicht standardisiert und der Kunde erlangt keine Kenntnis darüber, welche Sicherheitsmaßnahmen notwendig sind und welche als Zusatznutzen für den Kunden verstanden werden können.

Abschließend lässt sich festhalten, dass derzeit unterschiedliche Ansätze zu dem Thema Cloud Computing, z.B. durch die Cloud Security Alliance existieren,um einen einheitlichen Standard und damit verbundene vereinheitlichte Sicherheitskontrollen zu entwickeln.

8 Fußnoten

↑ vgl. Dunkel (2008), S. 270
↑ vgl. Cloud Security Alliance (2009), S. 15 f.
↑ Baun (2008), S. 133
↑ vgl. Baun (2008), S. 132 ff.
↑ In Anlehnung an Wallbaum et al.(2009), S. 15
↑ Cloud Security Alliance (2009), S. 17
↑ vgl. Cloud Security Alliance (2009), S. 15 ff.
↑ vgl. Software & Information Industry Association (2001), S. 4 ff.
↑ Software & Information Industry Association (2001), S. 4 ff.
↑ vgl. Cloud Security Alliance (2009), S. 17 / 22 f.
↑ vgl. Software & Information Industry Association (2001)
↑ vgl. Cloud Security Alliance (2009), S. 17 / 22
↑ vgl. Cloud Security Alliance (2009), S. 17
↑ In Anlehnung an Cloud Security Alliance (2009) S.21
↑ vgl. Cloud Security Alliance (2009), S. 17
↑ vgl. Cloud Security Alliance (2009), S. 17
↑ vgl. Cloud Security Alliance (2009), S. 17
↑ Matthews (2008), S. 5 ff.
↑ vgl. Schonfeld (2008)
↑ Müller et al. (2009), S. 111
↑ Held (2004), S. 29
↑ Held (2004), S. 45 ff.
↑ Müller et al. (2009), S. 114
↑ Müller et al. (2009), S. 111
↑ Müller et al. (2009), S. 111
↑ Hübscher (2005), S. 363 ff.
↑ vgl. Eckert (2007), S. 580
↑ vgl. Müller et al. (2009)
↑ vgl. Aebi (2004), S. 62
↑ Baker et al. (2008), S. 2
↑ Tipton et al. (2007), S. 180
↑ Tipton et al. (2007), S. 180
↑ Orenstein (2003), S. 246
↑ Cheswick et al. (2004), S. 42
↑ vgl. Raepple (2001), S. 64 ff.
↑ Cheswick et al. (2004), S. 145
↑ Cheswick et al. (2004), S. 219
↑ In Anlehnung an Dinger et al. (2008), S. 259
↑ Hübscher (2005), S. 320
↑ Dinger et al. (2008), S. 258
↑ vgl. Hübscher (2005), S. 320
↑ vgl. Cheswick et al. (2004), S. 232
↑ Dinger et al. (2008), S. 232
↑ vgl. Kappes (2007), S. 221
↑ vgl. Third Brigade (2009), S. 6
↑ In Anlehnung an Alexander (2006) S.151
↑ vgl. Alexander (2006) S.151f
↑ vgl. Eckert (2007), S. 417 f.
↑ vgl. Alexander (2006) S.156f
↑ Kappes (2007), S. 231
↑ vgl. Eckert (2007), S. 404
↑ vgl. Eckert (2007), S. 729 ff.
↑ Dierks et al. (2006)
↑ Dierks et al. (1999)
↑ vgl. Eckert (2007), S. 732 ff.
↑ vgl. Ylonen et al. (2006), S. 1
↑ vgl. Schlyter et al. (2006), S. 2
↑ vgl. Ylonen et al. (2006a), S. 8 ff.
↑ vgl. Eckert (2007), S. 739 ff.
↑ vgl. Dustdar et al. (2003), S. 213
↑ Eckert (2007), S. 317
↑ vgl. Wölfl (2006), S. 6 f.
↑ vgl. Stallings (2001), S. 102
↑ vgl. Eckert (2007), S. 380
↑ vgl. Spies et al. (2009)
↑ vgl. Cheswick et al. (2004), S. 179
↑ vgl. Cheswick et al. (2004), S. 179
↑ vgl. Cheswick et al. (2004), S. 179
↑ vgl. Cheswick et al. (2004), S. 186 ff.
↑ vgl. Cheswick et al. (2004), S. 186
↑ vgl. Cheswick et al. (2004), S. 186
↑ vgl. Cheswick et al. (2004), S. 186
↑ vgl. Cheswick et al. (2004), S. 189
↑ vgl. Cheswick et al. (2004), S. 189
↑ vgl. Cheswick et al. (2004), S. 190
↑ vgl. Cheswick et al. (2004), S. 190
↑ vgl. Cheswick et al. (2004), S. 190
↑ vgl. Stallings (2001), S. 446
↑ Stallings (2001) S. 368
↑ Stallings (2001), S. 368
↑ vgl.Stallings (2001), S. 370
↑ vgl. Stallings (2001), S. 373
↑ vgl. Stallings (2001), S. 374
↑ vgl. Stallings (2001), S. 374
↑ vgl. Stallings (2001), S. 374
↑ vgl. Stallings (2001), S. 374
↑ vgl. Stallings (2001), S. 374
↑ vgl. Amazon Web Services (2008), S. 1
↑ vgl. Amazon Web Services (2009)
↑ vgl. Amazon Web Services (2009c)
↑ vgl. Amazon Web Services (2009b)
↑ vgl. Amazon Web Services (2009a)
↑ Amazon Web Services (2008), S. 1
↑ vgl. Amazon Web Services (2008), S. 1 f.
↑ vgl. Amazon Web Services (2008), S. 1 f.
↑ vgl. Amazon Web Services (2008), S. 2
↑ vgl. Amazon Web Services (2008), S. 6 f.
↑ vgl. Amazon Web Services (2008), S. 6
↑ vgl. Amazon Web Services (2008), S. 4
↑ vgl. Amazon Web Services (2008), S. 3
↑ vgl. Amazon Web Services (2008), S. 5 f.
↑ vgl. Amazon Web Services (2008), S. 6
↑ vgl. Amazon Web Services (2008), S. 6
↑ vgl. Amazon Web Services (2008), S. 8
↑ vgl. Amazon Web Services (2008), S. 3
↑ Amazon Web Services (2008), S.4
↑ vgl. Amazon Web Services (2008), S. 5
↑ vgl. Amazon Web Services (2008), S. 6
↑ vgl. IBM (2009)
↑ vgl. IBM (2008), S. 9
↑ vgl. IBM (2008), S. 13
↑ vgl. IBM (2008), S. 15
↑ vgl. IBM (2008), S. 13
↑ vgl. IBM (2008), S. 13 f.
↑ vgl. IBM (2008), S. 11
↑ vgl. IBM (2008), S. 11
↑ vgl. IBM (2008), S. 12 f.
↑ vgl. IBM (2008), S. 14
↑ vgl. IBM (2008), S. 15
↑ vgl. IBM (2008), S. 15
↑ vgl. IBM (2008), S. 15
↑ vgl. IBM (2008), S. 20
↑ vgl. IBM (2008), S. 17
↑ Reder (2008)
↑ Microsoft (2008)
↑ vgl. Reder (2008)
↑ vgl. Microsoft (2009), S. 5
↑ Microsoft (2009) S. 6
↑ vgl. Microsoft (2009), S. 6
↑ vgl. Microsoft (2009), S. 6
↑ vgl. Microsoft (2009), S. 8
↑ vgl. Microsoft (2009), S. 8
↑ vgl. Microsoft (2009), S. 8
↑ vgl. Microsoft (2009), S. 17
↑ vgl. Microsoft (2009), S. 17
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 18
↑ vgl. Microsoft (2009), S. 19
↑ vgl. Microsoft (2009), S. 19
↑ vgl. Microsoft (2009), S. 21

9 Literatur- und Quellenverzeichnis

Aebi (2004)	Aebi, Daniel, Praxishandbuch sicherer It-betrieb, 1. Auflage, Gabler Verlag, Wiesbaden 2004
Alexander (2006)	Alexander, Michael: Netzwerke und Netzwerksicherheit Das Lehrbuch, 1. Auflage, Hüthig Verlag, Niederlande 2006
Amazon Web Services (2008)	Amazon Web Services (Hrsg.): Amazon Web Services: Overview of Security Processes, 2008, http://s3.amazonaws.com/aws_blog/AWS_Security_Whitepaper_2008_09.pdf (10.07.2009, 17:32)
Amazon Web Services (2009)	Amazon Web Services (Hrsg.): Amazon Elastic Compute Cloud (Amazon EC2), 2009, http://aws.amazon.com/ec2/ (11.06.2009, 09:32)
Amazon Web Services (2009a)	Amazon Web Services (Hrsg.): Amazon SimpleDB, 2009, http://aws.amazon.com/simpledb/ (11.06.2009, 09:40)
Amazon Web Services (2009b)	Amazon Web Services (Hrsg.): Amazon Simple Storage Service (Amazon S3), 2009, http://aws.amazon.com/s3/ (11.06.2009, 09:55)
Amazon Web Services (2009c)	Amazon Web Services (Hrsg.): Amazon Elastic Block Store (Amazon EBS), 2009, http://aws.amazon.com/ebs/ (11.06.2009, 10:23)
Baker et al. (2008)	Baker, Wade H.; Hylender, C. David; Valentine, J. Andrew; Tippett, Peter; Sartin, A. Bryan; Kang, Stan S.; Novak, Christopher; Verizon Business RISK Team: 2008 Data Breach Investigations Report - A study conducted by the Verizon Business RISK Team, Verizon Business (Hrsg.), 2008
Baun (2008)	Baun, Christian: Tonangebend - Grid-, Cloud-, Cluster- und Meta-Computing, in: c't magazin für computer technik, 2008, Ausgabe 21, Heise Zeitschriften Verlag, S.132 bis 133
Cheswick et al. (2004)	Cheswick, William R.; Bellovin, Steven M.; Rubin, Aviel D.: Firewalls und Sicherheit im Internt - Schutz vor cleveren Hackern, 2 Auflage, Addison Wesley Verlag, München 2004
Cloud Security Alliance (2009)	Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing, April 2009, http://www.cloudsecurityalliance.org/guidance/csaguide.pdf
Dierks et al. (1999)	Dierks, T.; Allen, C.: The TLS Protocol Version 1.0 (RFC 2246), 1999, http://www.rfc-editor.org/rfc/rfc2246.txt (09.06.2009, 17:15)
Dierks et al. (2006)	Dierks, T.; Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.1 (RFC 4346), 2006, http://www.rfc-editor.org/rfc/rfc4346.txt (09.06.2009, 17:32)
Dinger et al. (2008)	Dinger, Jochen; Hartenstein, Hannes: Netzwerk- und IT-Sicherheitsmanagement - Eine Einführung, Universitätsverlag Karlsruhe, Karlsruhe 2008
Dustdar et al. (2003)	Dustdar, Schahram ; Gall, Harald; Hauswirth, Manfred: Software-architekturen für verteilte Systeme: Prinzipien, Bausteine und Standardarchitekturen für moderne Software, 1. Auflage , Springer Verlag, Heidelberg 2003
Dunkel et al. (2008)	Dunkel, Jürgen; Eberhart, Andreas; Fischer, Stefan; Koschel, Arne; Kleiner, Carsten: Systemarchitekturen für verteilte Anwendungen: Client-server, Multi-tier, SOA, Event-driven Architectures, P2P, Grid, Web 2.0, 1. Auflage , Hanser Verlag, München 2008
Eckert (2007)	Eckert, Claudia: IT-sicherheit - Konzepte - Verfahren - Protokolle, 5. Auflage, Oldenbourg Wissenschaftsverlag, München 2007
Held (2004)	Held, Andrea, Oracle 10g Hochverfügbarkeit, 1. Auflage, Addison Wesley Verlag, München 2001
Hübscher (2005)	Hübscher, Heinrich, IT Handbuch, 4. Auflage, Westermann Verlag, Braunschweig 2005
Hülsenbusch (2008)	Hülsenbusch Ralph, Hinter den Wolken, Heise Zeitschriften Verlag, IX 12/2008, Hannover 2008
IBM (2008)	IBM (Hrsg.): IBM Computing on Demand Security Handbook, o. V., 2008
IBM (2009)	IBM (Hrsg.): Cloud Computing: Zugriff auf Ihre Anwendungen, von überall, zu jeder Zeit., 2009, http://www-05.ibm.com/de/cloud/service-management.html (13.06.2009, 15:34)
Kappes (2007)	Kappes, Martin: Netzwerk- und Datensicherheit, 1. Auflage, Vieweg+Teubner Verlag, Wiedbaden 2007
Matthews (2008)	Matthews, Jeanna; Dow, Eli M; Deshane, Todd; Hu, Wenjin; Bongio, Jeremy; Johnson, Brendan; Wilbur, Patrick F.; Hall, Prentice(Hrsg.): Running Xen: A Hands-on Guide to the Art of Virtualization, 1. Auflage, Prentice Hall Verlag, Stoughton 2008
Microsoft (2008)	Microsoft Corporation(Hrsg.): Microsoft stellt Windows Azure auf der PDC 2008 vor , 2008, http://www.microsoft.com/germany/presseservice/detail.mspx?id=532339
Microsoft (2009)	Microsoft Corporation(Hrsg.): Securing Microsoft’s Cloud Infrastructure, Mai 2009, http://www.globalfoundationservices.com/security/documents/SecuringtheMSCloudMay09.pdf
Müller et al. (2009)	Müller, Stephan, Siegert, Andreas: Sicherheitsaspekte rund um die Cloud - Heiter bis wolkig, Heise Zeitschriften Verlag, IX 05/2009, Hannover 2009
Orenstein (2003)	Orenstein, Gary : IP Storage Networking: Straight to the Core, 1. Auflage, Addison-Wesley Longman, Amsterdam 2009
Raepple (2001)	Raepple, Martin: Sicherheitskonzepte für das Internet: Grundlagen, Technologien und Lösungskonzepte für die kommerzielle Nutzung, 2. Auflage, dpunkt.verlag, Heidelberg 2001
Reder (2008)	Reder, Bernd: Microsoft stellt mit >>Windows Azure<< Plattform für Cloud-Computing vor, in:network Computing, Oktober 2008, http://www.networkcomputing.de/microsoft-stellt-mit-windows-azure-plattform-fuer-cloud-computing-vor/
Schlyter et al. (2006)	Schlyter, J.; Griffin, W.: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints (RFC 4255), 2006, http://www.rfc-editor.org/rfc/rfc4255.txt (13.06.2009, 14:45)
Schonfeld (2008)	Schonfeld, Erick, Amazon Web Services Goes Down, Takes Many Startup Sites With It, Februar 2008, http://www.techcrunch.com/2008/02/15/amazon-web-services-goes-down-takes-many-startup-sites-with-it/ (14.06.2009, 19:33)
Spies et al. (2009)	Spies, Axel; McCutchen, Bingham: USA: Cloud Computing -- Schwarze Löcher im Datenschutzrecht, Mai 2009, Stand 14. Juni 2009, http://www.bingham.com/Media.aspx?MediaId=8637
Software & Information Industry Association (2001)	Software & Information Industry Association (SIIA):Software as a Service: Strategic Backgrounder, Washington, DC Februar 2001, http://www.siia.net/estore/ssb-01.pdf
Stallings (2001)	Stallings, William: Sicherheit im Internet: Anwendungen und Standards, 1. Auflage, Addison-Wesley Verlag, München 2001
Third Brigade (2009)	Third Brigade deep security solutions: Whitepaper - Cloud Computing Security, Stand 12. Juni 2009, https://www.vtrenz.net/imaeds/ownerassets/863/ThirdBrigade_WhitePaper_CloudComputingSecurity.pdf ; http://resources.thirdbrigade.com/cloudcomputingsecuritywp/
Tipton et al. (2007)	Tipton, Harold; Krause, Micki: Information Security Management Handbook, 6. Auflage, CRC Press, Boca Raton 2007
Wallbaum et al.(2009)	Wallbaum, Michael;Hoff, Simon:"Cloud Computing" Dunkle Wolken über der IT-Sicherheit, in:ComConsult Research Der Netzwerk Insider, Juni 2009, Seite 1 und 11 bis 16
Wölfl (2006)	Wölfl, Thomas: Formale Modellierung von Authentifizierungs- und Autorisierungsinfrastrukturen: Authentizität von deskriptiven Attributen und Privilegien auf der Basis digitaler Zertifikate, 1. Auflage, Deutscher Universitäts-Verlag, Wiesbaden 2006
Ylonen et al. (2006)	Ylonen, T.; Lonvick, Ed. C.: The Secure Shell (SSH) Protocol Architecture (RFC 4251), 2006, http://www.rfc-editor.org/rfc/rfc4251.txt (13.06.2009, 14:30)
Ylonen et al. (2006a)	Ylonen, T.; Lonvick, Ed. C.: The Secure Shell (SSH) Authentication Protocol (RFC 4252), 2006, http://www.rfc-editor.org/rfc/rfc4252.txt (13.06.2009, 14:35)

[0] vgl. Dunkel (2008), S. 270

[1] vgl. Cloud Security Alliance (2009), S. 15 f.

[2] Baun (2008), S. 133

[3] vgl. Baun (2008), S. 132 ff.

[4] In Anlehnung an Wallbaum et al.(2009), S. 15

[5] Cloud Security Alliance (2009), S. 17

[6] vgl. Cloud Security Alliance (2009), S. 15 ff.

[7] vgl. Software & Information Industry Association (2001), S. 4 ff.

[8] Software & Information Industry Association (2001), S. 4 ff.

[9] vgl. Cloud Security Alliance (2009), S. 17 / 22 f.

[10] vgl. Software & Information Industry Association (2001)

[11] vgl. Cloud Security Alliance (2009), S. 17 / 22

[12] vgl. Cloud Security Alliance (2009), S. 17

[13] In Anlehnung an Cloud Security Alliance (2009) S.21

[14] vgl. Cloud Security Alliance (2009), S. 17

[15] vgl. Cloud Security Alliance (2009), S. 17

[16] vgl. Cloud Security Alliance (2009), S. 17

[17] Matthews (2008), S. 5 ff.

[18] vgl. Schonfeld (2008)

[19] Müller et al. (2009), S. 111

[20] Held (2004), S. 29

[21] Held (2004), S. 45 ff.

[22] Müller et al. (2009), S. 114

[23] Müller et al. (2009), S. 111

[24] Müller et al. (2009), S. 111

[25] Hübscher (2005), S. 363 ff.

[26] vgl. Eckert (2007), S. 580

[27] vgl. Müller et al. (2009)

[28] vgl. Aebi (2004), S. 62

[29] Baker et al. (2008), S. 2

[30] Tipton et al. (2007), S. 180

[31] Tipton et al. (2007), S. 180

[32] Orenstein (2003), S. 246

[33] Cheswick et al. (2004), S. 42

[34] vgl. Raepple (2001), S. 64 ff.

[35] Cheswick et al. (2004), S. 145

[36] Cheswick et al. (2004), S. 219

[37] In Anlehnung an Dinger et al. (2008), S. 259

[38] Hübscher (2005), S. 320

[39] Dinger et al. (2008), S. 258

[40] vgl. Hübscher (2005), S. 320

[41] vgl. Cheswick et al. (2004), S. 232

[42] Dinger et al. (2008), S. 232

[43] vgl. Kappes (2007), S. 221

[44] vgl. Third Brigade (2009), S. 6

[45] In Anlehnung an Alexander (2006) S.151

[46] vgl. Alexander (2006) S.151f

[47] vgl. Eckert (2007), S. 417 f.

[48] vgl. Alexander (2006) S.156f

[49] Kappes (2007), S. 231

[50] vgl. Eckert (2007), S. 404

[51] vgl. Eckert (2007), S. 729 ff.

[52] Dierks et al. (2006)

[53] Dierks et al. (1999)

[54] vgl. Eckert (2007), S. 732 ff.

[55] vgl. Ylonen et al. (2006), S. 1

[56] vgl. Schlyter et al. (2006), S. 2

[57] vgl. Ylonen et al. (2006a), S. 8 ff.

[58] vgl. Eckert (2007), S. 739 ff.

[59] vgl. Dustdar et al. (2003), S. 213

[60] Eckert (2007), S. 317

[61] vgl. Wölfl (2006), S. 6 f.

[62] vgl. Stallings (2001), S. 102

[63] vgl. Eckert (2007), S. 380

[64] vgl. Spies et al. (2009)

[65] vgl. Cheswick et al. (2004), S. 179

[66] vgl. Cheswick et al. (2004), S. 179

[67] vgl. Cheswick et al. (2004), S. 179

[68] vgl. Cheswick et al. (2004), S. 186 ff.

[69] vgl. Cheswick et al. (2004), S. 186

[70] vgl. Cheswick et al. (2004), S. 186

[71] vgl. Cheswick et al. (2004), S. 186

[72] vgl. Cheswick et al. (2004), S. 189

[73] vgl. Cheswick et al. (2004), S. 189

[74] vgl. Cheswick et al. (2004), S. 190

[75] vgl. Cheswick et al. (2004), S. 190

[76] vgl. Cheswick et al. (2004), S. 190

[77] vgl. Stallings (2001), S. 446

[78] Stallings (2001) S. 368

[79] Stallings (2001), S. 368

[80] vgl.Stallings (2001), S. 370

[81] vgl. Stallings (2001), S. 373

[82] vgl. Stallings (2001), S. 374

[83] vgl. Stallings (2001), S. 374

[84] vgl. Stallings (2001), S. 374

[85] vgl. Stallings (2001), S. 374

[86] vgl. Stallings (2001), S. 374

[87] vgl. Amazon Web Services (2008), S. 1

[88] vgl. Amazon Web Services (2009)

[89] vgl. Amazon Web Services (2009c)

[90] vgl. Amazon Web Services (2009b)

[91] vgl. Amazon Web Services (2009a)

[92] Amazon Web Services (2008), S. 1

[93] vgl. Amazon Web Services (2008), S. 1 f.

[94] vgl. Amazon Web Services (2008), S. 1 f.

[95] vgl. Amazon Web Services (2008), S. 2

[96] vgl. Amazon Web Services (2008), S. 6 f.

[97] vgl. Amazon Web Services (2008), S. 6

[98] vgl. Amazon Web Services (2008), S. 4

[99] vgl. Amazon Web Services (2008), S. 3

[100] vgl. Amazon Web Services (2008), S. 5 f.

[101] vgl. Amazon Web Services (2008), S. 6

[102] vgl. Amazon Web Services (2008), S. 6

[103] vgl. Amazon Web Services (2008), S. 8

[104] vgl. Amazon Web Services (2008), S. 3

[105] Amazon Web Services (2008), S.4

[106] vgl. Amazon Web Services (2008), S. 5

[107] vgl. Amazon Web Services (2008), S. 6

[108] vgl. IBM (2009)

[109] vgl. IBM (2008), S. 9

[110] vgl. IBM (2008), S. 13

[111] vgl. IBM (2008), S. 15

[112] vgl. IBM (2008), S. 13

[113] vgl. IBM (2008), S. 13 f.

[114] vgl. IBM (2008), S. 11

[115] vgl. IBM (2008), S. 11

[116] vgl. IBM (2008), S. 12 f.

[117] vgl. IBM (2008), S. 14

[118] vgl. IBM (2008), S. 15

[119] vgl. IBM (2008), S. 15

[120] vgl. IBM (2008), S. 15

[121] vgl. IBM (2008), S. 20

[122] vgl. IBM (2008), S. 17

[123] Reder (2008)

[124] Microsoft (2008)

[125] vgl. Reder (2008)

[126] vgl. Microsoft (2009), S. 5

[127] Microsoft (2009) S. 6

[128] vgl. Microsoft (2009), S. 6

[129] vgl. Microsoft (2009), S. 6

[130] vgl. Microsoft (2009), S. 8

[131] vgl. Microsoft (2009), S. 8

[132] vgl. Microsoft (2009), S. 8

[133] vgl. Microsoft (2009), S. 17

[134] vgl. Microsoft (2009), S. 17

[135] vgl. Microsoft (2009), S. 18

[136] vgl. Microsoft (2009), S. 18

[137] vgl. Microsoft (2009), S. 18

[138] vgl. Microsoft (2009), S. 18

[139] vgl. Microsoft (2009), S. 18

[140] vgl. Microsoft (2009), S. 18

[141] vgl. Microsoft (2009), S. 18

[142] vgl. Microsoft (2009), S. 18

[143] vgl. Microsoft (2009), S. 19

[144] vgl. Microsoft (2009), S. 19

[145] vgl. Microsoft (2009), S. 21

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]

[74]

[75]

[76]

[77]

[78]

[79]

[80]

[81]

[82]

[83]

[84]

[85]

[86]

[87]

[88]

[89]

[90]

[91]

[92]

[93]

[94]

[95]

[96]

[97]

[98]

[99]

[100]