Security-Analyse von Cloud-Computing Mathias Ardelt

wolke.hs.furtwangen.de

Security-Analyse von Cloud-Computing Mathias Ardelt

Security-Analyse von Cloud-Computing

Thesis

zur Erlangung des Grades

Master of Science

im Studiengang Application Architectures

an der Fakultät Wirtschaftsinformatik

der Hochschule Furtwangen University

vorgelegt von

Mathias Ardelt

Referenten:

Prof. Dr. Martin Knahl

Frank Dölitzscher M.Sc.

Eingereicht am: 28. Oktober 2011


Eidesstattliche Erklärung

Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbständig und

ohne unzulässige fremde Hilfe angefertigt habe.

Die verwendeten Quellen sind vollständig zitiert.

Furtwangen, den

_____________________________

_____________________________

Mathias Ardelt


Abstract

V

Abstract

Cloud-Computing ermöglicht Unternehmen, IT Ressourcen flexibel einzusetzen

und von möglichen Kostenvorteilen des pay-on-demand Modells zu profitieren.

Sowohl fehlende Standards auf Seite der Cloud-Provider als auch unklare Sicherheitsbestimmungen

machen eine Risikoanalyse von Services, die in der Cloud

angeboten werden, schwierig. In dieser Arbeit wird analysiert, was die wichtigsten

Security und Privacy Gefahren bei Cloud-Computing sind. Dabei werden die

identifizierten Gefahren mit den Mindestsicherheitsanforderungen an Cloud-

Computing-Anbieter von dem Bundesamt für Sicherheit in der Informationstechnik

verglichen. Darüber hinaus wird eine bestehende Architektur zur Lösung der

Gefahren des Cloud-Computing dahingehend erweitert, um zwei der identifizierten

Gefahren zu lösen.


Inhaltsverzeichnis

VII

Inhaltsverzeichnis

Abstract ............................................................................................................ V

Inhaltsverzeichnis ......................................................................................... VII

Abkürzungsverzeichnis ................................................................................. IX

Abbildungsverzeichnis .................................................................................. XI

Tabellenverzeichnis .................................................................................... XIII

1. Einführung .................................................................................................... 1

1.1. Zielsetzung der Arbeit ....................................................................................... 1

1.2. Aufbau der Arbeit .............................................................................................. 1

1.3. Related Work ..................................................................................................... 2

2. Grundlagen ................................................................................................... 5

2.1. Virtualisierung ................................................................................................... 5

2.1.1. Der Begriff „Virtualisierung“ .................................................................................. 5

2.1.2. Funktionsprinzipien der Virtualisierung .................................................................. 5

2.1.3. Virtuelle Maschinen ................................................................................................. 7

2.1.4. Virtualisierungs-Techniken...................................................................................... 8

2.2. Verschlüsselung und Authentifizierung .......................................................... 15

2.2.1. Transport Layer Security (TLS) / Secure Sockets Layer (SSL)............................. 15

2.2.2. Virtual Private Network (VPN) ............................................................................. 16

2.2.3. Trusted Platform Module (TPM) ........................................................................... 17

2.3. Cloud-Computing ............................................................................................ 19

2.3.1. Charakteristiken der Cloud .................................................................................... 21

2.3.2. Service-Modelle der Cloud .................................................................................... 22

2.3.3. Einsatzmöglichkeiten der Cloud ............................................................................ 23

2.3.4. Vor- und Nachteile des Cloud-Computing aus Sicht des KMU ............................ 24

2.3.5. Cloud-Provider im Überblick ................................................................................ 26

2.4. BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter .......... 28

3. Security-Analyse von Cloud-Computing .................................................. 31

3.1. Analyse der Gefahren des Cloud-Computing .................................................. 31


VIII

Inhaltsverzeichnis

3.1.1. Gefahrenverstärkung der bekannten Gefahren durch den Einsatz von Cloud-

Computing .............................................................................................................................. 31

3.1.2. Neue Gefahren durch Cloud-Computing ............................................................... 39

3.2. Vergleich zwischen den Gefahren des Cloud-Computing und den BSI

Mindestsicherheitsanforderungen für Cloud-Computing ............................................. 45

4. Architektur zur Lösung der Gefahren des Cloud-Computing .............. 63

4.1. SMMaaS Architektur ....................................................................................... 63

4.1.1. Aufbau der SMMaaS Architektur .......................................................................... 63

4.1.2. Module der SMMaaS Architektur .......................................................................... 64

4.2. Erweiterung der SMMaaS Architektur zur Lösung der Gefahren des Cloud-

Computing .................................................................................................................... 65

4.2.1. Gefahr durch Missbrauch von Cloud-Ressourcen .................................................. 66

4.2.2. Gefahr durch unbekannte Laufzeitumgebungen der virtuellen Maschinen ............ 66

4.3. Evaluation der Erweiterung der SMMaaS Architektur zur Lösung der

Gefahren des Cloud-Computing ................................................................................... 72

4.3.1. Gefahr durch Missbrauch von Cloud-Ressourcen .................................................. 72

4.3.2. Gefahr durch unbekannte Laufzeitumgebungen der virtuellen Maschinen ............ 73

5. Fazit ............................................................................................................. 75

5.1. Zusammenfassung ........................................................................................... 75

5.2. Ausblick ........................................................................................................... 76

Literaturverzeichnis ...................................................................................... 77

Internetquellen ............................................................................................... 79

Anhang A ........................................................................................................ 83

Anhang B ........................................................................................................ 85


Abkürzungsverzeichnis

IX

Abkürzungsverzeichnis

AIK

API

AWS

BSI

CA

CRTM

EC2

ENISA

FTP

HTTP

HTTPS

IaaS

KMU

NIST

PaaS

SaaS

SLA

SMTP

SSL

TCG

TLS

TPA

TPM

TSS

VPN

vTPM

Attestation Identiy Keys

Application Programming Interfaces

Amazon Web Services

Bundesamt für Sicherheit in der Informationstechnik

Certificate Authority

Core Root of Trust for Measurement

Amazon Elastic Compute Cloud

European Network and Information Security Agency

File Transfer Protocol

Hypertext Transfer Protocol

Hypertext Transfer Protocol Secure

Infrastructure as a Service

Kleine und mittelständische Unternehmen

National Institute of Standards and Technology

Platform as a Service

Software as a Service

Service Level Agreements

Simple Mail Transfer Protocol

Secure Sockets Layer

Trusted Computing Group

Transport Layer Security

Trusted Platform Architektur

Trusted Platform Module

Trusted Software Stack

Virtual Private Network

Virtual Trusted Platform Module


Abbildungsverzeichnis

XI

Abbildungsverzeichnis

Abbildung 1: Funktionsprinzipien der Virtualisierung ..................................... 5

Abbildung 2: Normale Privilegienstufen eines x86 Prozessors ...................... 11

Abbildung 3: Paravirtualisierung .................................................................... 13

Abbildung 4: VPN Site-to-End Topologie ...................................................... 16

Abbildung 5: VPN End-to-End Topologie ...................................................... 17

Abbildung 6: VPN Site-to-Site Topologie ...................................................... 17

Abbildung 7: Basiskomponenten des TPM ..................................................... 18

Abbildung 8: Übersicht der Service-Modelle des Cloud-Computing ............. 22

Abbildung 9: Amazon Health Dashboard am 25.05.2011 .............................. 34

Abbildung 10: Amazon Health Dashboard am 31.05.2011 ............................ 34

Abbildung 11: CloudDataSec-Schichtenarchitektur ....................................... 63

Abbildung 12: Kernkomponenten des CloudDataSec ..................................... 64

Abbildung 13: vTPM Architektur ................................................................... 68

Abbildung 14: Virtual TPM Migrations-Protokoll ......................................... 70

Abbildung 15: Erweiterte SMMaaS Architektur ............................................. 72


Tabellenverzeichnis

XIII

Tabellenverzeichnis

Tabelle 1: Gegenwärtige Literatur zur Cloudsicherheit .................................... 3

Tabelle 2: Gefahren des Cloud-Computing im Überblick .............................. 31

Tabelle 3: BSI-Auszug „Anforderungen an das Personal“ ............................. 46

Tabelle 4: BSI-Auszug „ID- und Rechtemanagement“................................... 47

Tabelle 5: BSI-Auszug „Sicherheitsprüfung und –nachweis“ ........................ 48

Tabelle 6: BSI-Auszug „Ressourcen- und Patchmanagement“....................... 50

Tabelle 7: BSI-Auszug „Monitoring und Incident Management“ .................. 51

Tabelle 8: BSI-Auszug „Datenspeicherung, Speichervirtualisierung und

Datensicherheit ...................................................................................................... 52

Tabelle 9: BSI-Auszug „Monitoring und Incident Management“ .................. 53

Tabelle 10: BSI-Auszug „Transparenz“.......................................................... 55

Tabelle 11: BSI-Auszug „Rechenzentrumsicherheit“..................................... 56

Tabelle 12: BSI-Auszug „Sicherheitsprüfung und –nachweis“ ...................... 57

Tabelle 13: BSI-Auszug „Portabilität von Daten und Anwendungen“ ........... 58

Tabelle 14: BSI-Auszug „Organisatorische Anforderungen“ ......................... 59

Tabelle 15: BSI-Auszug „Interoperabilität“.................................................... 59

Tabelle 16: BSI-Auszug „Netzsicherheit“....................................................... 60

Tabelle 17: BSI-Auszug „Interoperabilität“.................................................... 61


Kapitel 1: Einführung 1

1. Einführung

1.1. Zielsetzung der Arbeit

Ziel dieser Arbeit ist es zu analysieren was die wichtigsten Security und Privacy

Probleme bei Cloud-Computing sind. Hierfür wird eine Analyse der aktuellen

Gefahren durchgeführt. Des Weiteren wird analysiert, ob die Gefahren durch

die „Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter“ des Bundesamts

für Sicherheit in der Informationstechnik abgedeckt werden. Diese Arbeit

beschäftigt sich außerdem mit einer vorhandenen Architektur zur Lösung der Gefahren

des Cloud-Computing. Hierfür werden zwei der identifizierten Gefahren

dahingehend analysiert, inwiefern die Architektur erweitert werden kann, um diese

Gefahren zu lösen.

1.2. Aufbau der Arbeit

Die Arbeit ist in 4 Kapitel aufgeteilt:

Das erste Kapitel beschäftigt sich mit den Grundlagen. Als Erstes werden hier

die Grundlagen der Virtualisierung erläutert. Anschließend wird auf die Verschlüsselung

und Authentifizierung eingegangen. Der dritte Teil des Kapitels beschäftigt

sich mit der Einführung in das Cloud-Computing. Der vierte Teil beschäftigt

sich mit den BSI-Mindestsicherheitsanforderungen an Cloud-

Computing-Anbieter.

In dem zweiten Kapitel wird die Security-Analyse von Cloud-Computing

durchgeführt. Hierzu werden die Gefahren des Cloud-Computing analysiert und

anschließend mit den BSI Mindestsicherheitsanforderungen für Cloud-Computing

verglichen.

Das dritte Kapitel erläutert die Architektur zur Lösung der Gefahren des

Cloud-Computing. Nach der Erläuterung der bestehenden Architektur wird in

diesem Kapitel die Erweiterung der Architektur aufgezeigt. Der letzte Teil dieses

Kapitels beschäftigt sich mit der Evaluation der Erweiterung der Architektur.

Das vierte Kapitel zieht ein Fazit über die behandelten Themen und bietet einen

Ausblick in die Zukunft.


2 Kapitel 1: Einführung

1.3. Related Work

Die wichtigste Literatur zu Cloud Sicherheit für IT-Entscheider sind aktuelle

Studien der Cloud Security Alliance (CSA), des Bundesamtes für Sicherheit in der

Informationstechnik (BSI), der European Network and Information Security

Agency (ENISA), des Fraunhofer Institutes sowie verschiedene wissenschaftliche

Paper. Tabelle 1 gibt einen Überblick über die wichtigsten aktuellen Studien zum

Thema Cloud Sicherheit und ihrer Intention:

Herausgeber Titel Inhalt

Cloud Security

Aliance (CSA)

Cloud Security

Alliance

(CSA)

Bundesamt für

Sicherheit in

der Informationstechnik

(BSI)

European

Network and

Information

Security

Agency

(ENISA)

European

Network and

Information

Security

Agency

Security Guidance

for Critical Areas of

Focus in Cloud-

Computing V2.1

Top Threats to

Cloud-Computing

V1.0

Eckpunktepapier

Sicherheitsemfehlungen

für Cloud-

Computing Anbieter

Cloud-Computing -

Benefits, risks and

recommendations for

information security

Security and Resilience

in Governmental

Clouds

Vorstellung von (allgemeinen) Cloud

Sicherheitsproblemen. Bereitstellung von

Best Practices zur Vermeidung klassischer

Cloud-Computing Fehler

Kurzübersicht über aktuelle Cloud Sicherheitsprobleme

Empfehlungen für sicheres Cloud-

Computing, die sich an Cloud Service

Provider (CSP) richten

Identifizierung von Cloud Sicherheitsproblemen,

Bereitstellung eines Allgemeinen

Risikofragebogens für Cloud-

Kunden bezüglich der Cloud-

Providersicherheit

Entscheidungsmodell für höheres Management

zur Risikoanalyse über Cloud

Nutzung für Behörden


Kapitel 1: Einführung 3

(ENISA)

Fraunhofer-

Institut für

Sichere Informationstechnologie

(SIT)

Luis M. Vaquero

Studie: Cloud-

Computing Sicherheit

Locking the sky: a

survey on IaaS cloud

security

Marktanalyse über Cloud-Provider und

Cloudsicherheit für kleine und mittelständische

Unternehmen

Gegenüberstellung aktuell verfügbarer

wissenschaftlicher Paper zu Cloud Sicherheitsproblemen.

Analyse des Lebenszyklus

von Cloud Sicherheitsproblemen

Tabelle 1: Gegenwärtige Literatur zur Cloudsicherheit


Kapitel 2: Grundlagen 5

2. Grundlagen

2.1. Virtualisierung

2.1.1. Der Begriff „Virtualisierung“

Der Begriff „virtuell“ kann bis zum mittelalterlichen Ausdruck „virtualis“

(„Leistung“, „Potenz“, „Effizienz“) zurückverfolgt werden. In der Computerwelt

tauchte der Begriff erstmals 1959 auf und stellt ein nicht physisch existentes, sondern

durch Software dargestelltes Objekt dar. 1

Virtualisierung beschreibt die Abstraktion von Ressourcen wie Hardware-,

Software- und logischen Komponenten, wie beispielsweise Konfigurationsmerkmale

wie IP- oder MAC-Adressen. Bei der Virtualisierung wird eine logische

Schicht zur Verwaltung und Aufteilung von Ressourcen eingefügt. Dadurch wird

eine logische Trennung von den tatsächlichen physischen Ressourcen erreicht.

Diese so genannten logischen Ressourcen können nun einzeln und getrennt voneinander

angesteuert werden. 2

2.1.2. Funktionsprinzipien der Virtualisierung

Die Virtualisierung wird von drei Funktionsprinzipien aufgebaut: Partitionierung,

Aggregation und Emulation.

Abbildung 1: Funktionsprinzipien der Virtualisierung 3

1 Vgl. Kircher, Herbert: „IT. Technologien, Lösungen, Innovationen“, S. 101

2 Vgl. Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum

3 Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum


6 Kapitel 2: Grundlagen

Partitionierung: Der Begriff „Partition“ ist in der Mengenlehre definiert und

bezieht sich hier auf die Aufteilung von physischen Ressourcen in logische virtuelle

Teilmengen (siehe Abbildung 1: a Partitionierung). Spricht man von einer

dynamischen Partitionierung, so wird die Kapazität einer virtuellen Ressource zur

Laufzeit geändert, indem sich die Aufteilung in Partitionen ändert. Die Summe

der virtuellen Ressourcen kann sowohl mehr als auch weniger als die physischen

Ressourcen sein. Ein Beispiel für weniger virtuelle als physische Ressourcen wäre,

wenn nicht alle physischen Ressourcen in virtuelle Ressourcen aufgeteilt werden

müssen und somit die restlichen unbenutzten Ressourcen unbelegt bleiben

können. Wenn der Vorgang der Virtualisierung selbst Ressourcen beansprucht,

dann stehen weniger physische Ressourcen für virtuelle Ressourcen zur Verfügung.

Dies wird im Allgemeinen als „Virtualisation Overhead“ bezeichnet. Im

umgekehrten Fall, in welchem die Kapazitäten virtueller Ressourcen in der Gesamtsumme

die vorhandenen physischen Kapazitäten übersteigen, spricht man

von einem Over-Commitment von Ressourcen. Ist der physische Server beispielsweise

mit vier physischen Prozessoren ausgestattet, können in der Gesamtsumme

auf diesem Server dennoch mehr virtuelle Prozessoren in virtuellen Servern

existieren. Dies steigert jedoch nicht die Leistungsfähigkeit der einzelnen

physischen Ressourcen. Das Verfahren sagt lediglich aus, dass virtuelle Ressourcen

nicht zwangsläufig physischen Ressourcen fest zugeordnet sein müssen. 4

Aggregation: Der Begriff „Aggregation“ stammt vom dem lateinischen Begriff

„aggregatio“ und wird als „Anhäufung“ oder „Vereinigung“ übersetzt. Aggregation

bedeutet in der Virtualisierung die Zusammenfassung physischer Ressourcen

in größere virtuelle Ressourcen oder logische Gruppierungselemente virtueller

Ressourcen (siehe Abbildung 1: b Aggregation). Bei diesem Verfahren

werden Ressourcen nicht tatsächlich physisch zusammengefasst, sondern sie werden

logisch gruppiert. Die virtuelle Gesamtmenge ist exakt so groß wie die Vereinigung

aller physischen Teilmengen. Auch bei diesem Verfahren kann ein Teil

der physischen Kapazitäten für die Verwaltung der logischen Gruppierungen aufgewendet

werden. Dies wird, wie bereits schon angesprochen, als „Virtualisation

4 Vgl. Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum


Kapitel 2: Grundlagen 7

Overhead“ bezeichnet. Ein praktisches Beispiel für dieses Verfahren wäre eine

Speichertechnik, bei der dem Anwender eine große virtuelle Festplatte angeboten

wird, welche jedoch aus vielen kleineren physischen Festplatten bestehen. 5

Emulation: Der Begriff „Emulation“ stammt von dem lateinischen Begriff

„Aemulari“ und bedeutet „nachahmen“. In der Virtualisierungstechnik wird die

funktionale Nachbildung einer Systemumgebung simuliert. Ziel ist es mit Hilfe

der Emulation eine Laufzeitumgebung oder Schnittstellen bereitzustellen, welche

die Architektur und das Verhalten eines nachzubildenden Originalsystems komplett

reproduzieren. Eine vollständige, richtig emulierte Laufzeitumgebung oder

Schnittstelle lässt sich von einer realen Schnittstelle oder Laufzeitumgebung in

Verhalten und Funktion nicht unterscheiden. Die emulierte virtuelle Laufzeitumgebung

kann sich jedoch in Funktion und Architektur von dem physischen System

unterscheiden. Mit Hilfe dieser Technik ist es möglich, aus einem bestimmten

Computersystem mittels einer Virtualisierungs-Software eine andere virtuelle Architektur

bereitzustellen. Dies könnten beispielsweise Hardwarekomponenten wie

Netzwerkadapter sein, welche sich zwar von dem physischen Netzwerkadapter

unterscheiden aber in Funktion und Verhalten identisch mit einer realen Schnittstelle

sind. 6

2.1.3. Virtuelle Maschinen

Wenn diese Virtualisierungsverfahren angewendet werden, dann entsteht daraus

eine virtuelle Maschine. So wird beispielsweise durch die Aggregation einzelner

physischer Festplatten eine neue virtuelle Festplatte erstellt und einer virtuellen

Maschine bereitgestellt. Eine virtuelle Maschine enthält in der Regel sämtliche

Komponenten welche auch eine physische Maschine verwendet. Dies wären beispielsweise

Netzwerkadapter, Festplatten, CD Laufwerke, Diskettenlaufwerke,

Arbeitsspeicher, Soundkarten, USB Anschlüsse und Prozessoren. Innerhalb einer

virtuellen Maschine befindet sich ein eigenständiges Betriebssystem mit den jeweiligen

Anwendungen. Das Betriebssystem und deren Anwendungen können bei

einer richtigen Virtualisierung nicht feststellen, dass dies eine virtuelle Maschine

5 Vgl. Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum

6 Vgl. Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum


8 Kapitel 2: Grundlagen

und keine physische Maschine ist. Eine virtuelle Maschine kann sowohl auf Prozessebene

sowie für Systemumgebungen verwendet werden. 7

Spricht man von einer virtuellen Maschine auf Prozessebene, so wird auf einer

physischen Maschine ein reguläres Betriebssystem installiert. Innerhalb dieses

Betriebssystems befindet sich wiederum eine Virtualisierungs-Software, welche

eine Laufzeitumgebung für Prozesse darstellt. Innerhalb ihrer Laufzeitumgebung

werden verschiedene Anwendungen ausgeführt. Ein praktisches Beispiel wären

Java- und .NET-Laufzeitumgebungen. 8

Handelt es sich um eine virtuelle Systemumgebung, so ist dies eine isolierte

Kopie der echten physischen Umgebung. Innerhalb dieser virtuellen Umgebungen

wird ein komplettes Betriebssystem und sämtliche dazugehörigen Anwendungen

installiert. Eine solche virtuelle Maschine greift auf ihre eigenen virtuellen Ressourcen

zu, welche vorher durch eine Virtualisierungs-Software zugeteilt werden

müssen. Eine solche Zuteilung findet von einer Virtualisierungs-Software statt,

welche auch als Virtual Machine Monitor (VMM) oder Hypervisor bezeichnet

wird. Diese Software stellt ein Kontrollprogramm dar, welches wiederum selbst

einen Teil der vorhandenen physischen Ressourcen beansprucht. 9

2.1.4. Virtualisierungs-Techniken

Server-Virtualisierung

Bei der Server-Virtualisierung handelt es sich um eine virtuelle Maschine auf

der Serverkomponenten laufen. In der Regel sind dies Betriebssysteme, welche

speziell für Serveranforderungen wie beispielsweise Windows Server 2003 oder

Ubuntu Server Edition, angepasst sind. Typischerweise greifen mehrere Clients

auf die Server zu und dadurch entsteht eine 1:N-Beziehung. Der Unterschied zu

dem klassischen Server ist hier, dass sämtliche Anwendungen nicht auf der physischen

Maschine laufen sondern auf einer virtuellen Umgebung welche von einem

Hypervisor zur Verfügung gestellt wird. Es gibt auch Virtualisierungsvarianten

bei denen mehrere virtuelle Maschinen auf einer gemeinsamen physischen Maschine

laufen. Aus diesem Grund können mehrere Server, zusammengefasst in

7 Vgl. Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum

8 Vgl. Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum

9 Vgl. Osterburg, Stefan: Neue Computing-Grundlagen für das Rechenzentrum


Kapitel 2: Grundlagen 9

mehrere virtuelle Maschinen, auf einer physischen Maschine laufen. Jede dieser

virtuellen Maschinen beinhaltet einen eigenen Netzwerkadapter und bekommt

somit unterschiedliche IPs zugeteilt. Dies ist notwendig, damit die Clients zwischen

den unterschiedlichen Servern unterscheiden können und nicht versehentlich

mit dem falschen Server kommunizieren.

Hardware-Emulation

Hardware-Emulation ist die funktionelle Nachbildung einer physischen Hardware

innerhalb einer virtuellen Umgebung. Das Ziel ist es, für eine virtuelle Maschine

die physische Hardware virtuell nachzubilden. Das bedeutet jedoch, dass

die Emulations-Software dabei die Schnittstellen der Originalhardware so nachbildet,

dass ein Betriebssystem, das ursprünglich für physische Hardware ausgelegt

war, genauso mit dem Emulator interagieren kann wie mit der echten Hardware.

Somit wird gewährleistet, dass für das Betriebssystem jederzeit der Betrieb

ermöglicht wird, selbst wenn eine andere physische Hardwarearchitektur vorhanden

ist. Darüber hinaus ist durch die Hardware-Emulation auch eine Bereitstellung

von Hardware, die physisch noch nicht entwickelt wurde oder nicht mehr entwickelt

wird, möglich. 10

Wenn man beispielsweise den aktuellen Markt beobachtet, dann findet man

heutzutage keine Festplatten mehr die kleiner als 40 GB sind. Veraltete Betriebssysteme,

die mit zu großen Festplatten nicht mehr arbeiten können, können durch

die Hardware-Emulation somit weiterhin verwendet werden. Ein Beispiel für noch

nicht entwickelte Hardware wäre das Testen von Software für Mobiltelefone, die

noch in der Entwicklung sind. Es wird somit möglich die Software zu testen, ohne

dass die tatsächliche Hardware fertig entwickelt wurde. Dies bedeutet einen zeitlichen

Vorsprung für die Software-Entwicklung, da diese nicht auf die Hardware-

Entwicklung warten muss.

Durch die Hardware-Emulation entsteht eine virtuelle Maschine, die völlig

von der tatsächlichen Hardware losgelöst von dem Emulator betrieben wird. Die

Kernfunktion des Emulators beinhaltet beispielsweise alle CPU-Befehle entgegenzunehmen,

zu interpretieren und anhand seiner Applikationslogik auszuführen

10 Vgl. Baun, Christian: Servervirtualisierung


10 Kapitel 2: Grundlagen

sowie das entsprechende Ergebnis an die virtuelle Maschine zurückzuliefern. Das

Ergebnis, das an die virtuelle Maschine zurückgeliefert wird, muss absolut identisch

mit dem Ergebnis sein, welches derselbe Systemaufruf auf der Originalplattform

liefern würde. Würde es bei diesem Ablauf auch nur eine geringe Abweichung

zwischen dem emulierten Prozessor und einem physischen Prozessor geben,

so könnte das Betriebssystem mit dem Ergebnis nicht arbeiten und das System

würde abstürzen. 11

Die vollständige softwareseitige Implementierung birgt jedoch gewisse Probleme,

da die Befehle eines Emulators nicht direkt auf dem echten Prozessor ausgeführt

werden, sondern vorher vom Emulator entgegengenommen, interpretiert,

ausgeführt und anschließend wieder an das System im Emulator zurückgegeben

werden. Dadurch entsteht ein großer Overhead, der sich teilweise durch dramatische

Geschwindigkeitseinbußen bemerkbar macht. Um diesem Problem entgegenzuwirken

implementieren deshalb einige Emulatoren Just-in-Time-Compiler,

die die Befehle des Gastsystems gleichzeitig ausführen und cachen, so dass beim

nächsten Aufruf des selben Befehls das Ergebnis aus dem Cache abgefragt werden

kann und nicht wieder erneut berechnet werden muss. 12

Hardware-Partitionierung

Durch die Hardware-Partitionierung können die gesamten Ressourcen eines

Computersystems in Teilsysteme geteilt werden. Dadurch werden Ressourcen wie

Prozessor, Hauptspeicher, Datenspeicher und Input/Output-Geräte (CD-

Laufwerke, Diskettenlaufwerk, USB-Speicher, etc.) partitioniert und den virtuellen

Maschinen zur Verfügung gestellt. Die Aufteilung der Ressourcen kann während

des laufenden Betriebs von dem Hypervisor geändert werden. 13

11 Vgl. Thorns, Fabian: „Das Virtualisierungs-Buch“, S. 35

12 Vgl. Thorns, Fabian: „Das Virtualisierungs-Buch“, S. 35

13 Vgl. Baun, Christian: Servervirtualisierung


Kapitel 2: Grundlagen 11

Vollständige Virtualisierung

Abbildung 2: Normale Privilegienstufen eines x86 Prozessors 14

Aktuelle Prozessoren haben vier Privilegienstufen für die Ausführung von Befehlen.

Diese Stufen gewährleisten eine Erhöhung des Schutzes und der Stabilität.

Ein Prozess, der von dem Prozessor bearbeitet werden muss, kann immer nur in

einem einzelnen Ring ausgeführt werden und kann nicht selbstständig seinen zugeteilten

Ring wechseln. Die Zugriffsprivilegien innerhalb der Ringe werden von

Ring 0 bis zu Ring 3 immer weiter eingeschränkt. Der Ring 0 hat beispielsweise

uneingeschränkten Zugriff auf die Hardware. Aus diesem Grund laufen innerhalb

dieses Rings in der Regel der Betriebssystemkern (Kernel) und die zum Start des

Betriebssystems notwendigen Hardwaretreiber. In Ring 3 laufen normalerweise

die Anwendungen. Die Abbildung 2 stellt diesen Aufbau grafisch dar. 15

Sobald ein Prozess in einem Ring, in welchem er weniger Privilegien besitzt

als für die Ausführung notwendig ist, ausgeführt wird, so wird eine Ausnahme

(Exception) ausgelöst und im benachbarten Ring abgefangen und dort behandelt.

Falls eine Ausnahme nicht abgefangen werden kann, verursacht sie eine allgemeine

Schutzverletzung (General Protection Fault) und bringt dabei den aufgerufenen

Prozess zum Absturz. Falls dieser Prozess von dem Betriebssystemkern gestartet

14 Baun, Christian: Servervirtualisierung

15 Vgl. Baun, Christian: Servervirtualisierung


12 Kapitel 2: Grundlagen

wurde, stürzt hierbei das gesamte System ab, da kein übergeordneter Ring zum

abfangen der Ausnahme verfügbar ist. 16

Bei der vollständigen Virtualisierung wird eine vollständig virtuelle Umgebung

inklusive eigenem BIOS zur Verfügung gestellt. Hierfür kommt der virtuelle

Maschinemonitor (VMM) zum Einsatz. Der virtuelle Maschinemonitor nutzt den

Vorteil, dass innerhalb der Ringstruktur unverwendete leere Ringe zur Verfügung

stehen. Aus diesem Grund wird der Betriebssystemkern von Ring 0 in Ring 1 verschoben.

In Ring 0 befindet sich nun der virtuelle Maschinenmonitor und hat dabei

uneingeschränkten Zugriff auf die Hardware des Systems. Die virtuellen Maschinen,

und somit deren Betriebssystemkerne, befinden sich nun in einem weniger

privilegierten Ring. 17

Da der virtuelle Maschinenmonitor sich nun im Ring 0 befindet, ist er dafür

verantwortlich sämtliche Ausnahmen zu bearbeiten. Wenn der virtuelle Maschinenmonitor

mehrere virtuelle Maschinen bearbeiten muss, dann entstehen hierbei

teilweise aufwändige Bearbeitungen durch die angehäuften Ausnahmen. Aus diesem

Grund ist dieses Verfahren mit gewissen Performanceeinbußen verbunden. 18

Falls innerhalb der virtuellen Maschine eine Ausnahme ausgelöst wird und

diese von dem Betriebssystemkern nicht bearbeitet werden kann, so bleibt dem

virtuellen Maschinenmonitor keine andere Wahl als die Ausnahme abzufangen

und die virtuelle Maschine zu stoppen. Wenn dies nicht geschehen würde und der

virtuelle Maschinenmonitor die Ausnahme nicht behandelt, dann hätte dies zur

Folge, dass der Ausfall des virtuellen Maschinenmonitors und somit der gesamten

physischen Maschine droht und somit sämtliche darin enthaltene virtuelle Maschinen

ebenfalls abstürzen würden. Aus Sicherheitsgründen sollte der virtuelle

Maschinenmonitor immer die einzelne virtuelle Maschine stoppen, um somit einen

Gesamtabsturz zu verhindern.

16 Vgl. Baun, Christian: Servervirtualisierung

17 Vgl. Baun, Christian: Servervirtualisierung

18 Vgl. Thorns, Fabian: „Das Virtualisierungs-Buch“, S. 27-28


Kapitel 2: Grundlagen 13

Paravirtualisierung

Abbildung 3: Paravirtualisierung 19

Bei der vollständigen Virtualisierung wird ein VMM in Ring 0 zur Verfügung

gestellt, der jeden Fehler innerhalb des Gastsystems abfängt und entsprechend

bearbeitet. Bei der Paravirtualisierung wird auf den VMM verzichtet und stattdessen

ein Hypervisor zur Verfügung gestellt. Hierfür wird der normale Befehlssatz

der virtuellen Maschinen um sogenannte „Hypervisor-Calls“ erweitert. Anders als

der VMM verhält sich der Hypervisor passiv. Er wird nur dann aktiv, wenn er

durch den erweiterten Befehlssatz direkt aufgerufen wurde. Da hier weniger Ausfälle

bearbeitet werden müssen, ergibt sich dadurch ein Geschwindigkeitsvorteil,

denn nun werden nicht mehr alle Ausnahmen behandelt, sondern nur eine bestimmte

Anzahl von kritischen Ausnahmen. Dies ist jedoch nur möglich, wenn

das Betriebssystem entsprechend modifiziert werden kann. Hierfür eignet sich

hervorragend das Betriebssystem Linux, da der Quellcode öffentlich zugänglich

ist und somit Veränderungen an den Befehlssätzen einfach gemacht werden. 20

Ein Hypervisor kann jedoch nicht wie der VMM eigenständig laufen. Er benötigt

immer ein Basisbetriebssystem in welchem er weitere Betriebssysteme virtuell

starten kann (siehe Abbildung 3). Die virtuell gestarteten Betriebssysteme verwenden

eine abstrakte Verwaltungsschicht, um auf gemeinsame Ressourcen wie

19 Bengel, Günther: „Masterkurs Parallele und Verteilte Systeme“, S. 401

20 Vgl. Thorns, Fabian: „Das Virtualisierungs-Buch“, S. 30-31


14 Kapitel 2: Grundlagen

Netzanbindung, Festplattenspeicher und Benutzereingaben/-ausgaben zugreifen

zu können. Hierfür kommen keine speziellen Treiber zum Einsatz sondern werden

vom Basisbetriebssystem zur Verfügung gestellt. Die Ressourcen werden nicht

wie bei dem VMM emuliert, sondern über die abstrakte Verwaltungsschicht angesprochen.

Dies hat den Vorteil, dass die Ressourcen sehr effizient genutzt werden

und die virtuellen Systeme nahezu ebenso performant wie die physischen Systeme

laufen. Ein Beispiel für die Paravirtualisierung ist der Xen Hypervisor. 21

Hardwarevirtualisierung

Wenn ein unmodifiziertes Betriebssystem oder ein Betriebssystem das nicht

modifiziert werden kann (z.B. Windows, da der Quellcode nicht öffentlich ist)

virtuell betrieben werden soll, muss der Prozessor selbst die Virtualisierungsfunktion

direkt unterstützen können. Aktuelle CPU-Generationen von Intel und AMD

implementieren daher Virtualisierungserweiterungen, die unter dem Begriff

Hardwarevirtualisierung zusammengefasst werden. Die beiden Prozessorhersteller

gehen bei der Realisierung der Hardwarevirtualisierung ähnliche aber dennoch

inkompatible Wege. AMD erweitert seit Juni 2006 seine Prozessoren um den sogenannten

Secure-Virtual-Machine-Befehlssatz (SVM). Diese Lösung trägt den

Namen AMD-V. Intel implementiert seine Lösung mit der Bezeichnung VT-x

bzw. VT-i und den sogenannten Virtual-Machine-Extensions-Befehlssatz (VMX).

Die neuen Befehle bei den beiden Prozessortypen bieten virtuellen Maschinen

einen Prozessor-Level-Support, indem sie eine Erweiterung zu den bereits angesprochenen

Privilegienstufen Ring 0 und Ring 3 definieren. Die Ringstruktur

wurde durch eine Erweiterung von Ring 0 um eine Ebene, die neue Hypervisor-

Schicht, ersetzt. Diese Ebene wird als Root-Betriebsmodus bezeichnet. Der Hypervisor

bzw. der VMM läuft in diesem Root-Betriebsmodus und besitzt somit die

volle Kontrolle über den Prozessor und die Ressourcen. Dies hat den großen Vorteil,

dass die Gastbetriebssysteme nicht angepasst werden müssen und der Kernel

nicht wie bei der Paravirtualisierung mit den Anwendungen auf einer Privilegienstufe

läuft. 22

21 Vgl. Bengel, Günther: „Masterkurs Parallele und Verteilte Systeme“, S. 400-401

22 Vgl. Baun, Christian: Servervirtualisierung


Kapitel 2: Grundlagen 15

2.2. Verschlüsselung und Authentifizierung

2.2.1. Transport Layer Security (TLS) / Secure Sockets Layer (SSL) 23

Die Transport Layer Security (TLS) ist eine Weiterentwicklung des SSL-

Protokolls durch die Internet Engineering Task Force (IETF), die das SSL-

Protokoll 1999 in Transport Layer Security umbenannte. Das Protokoll wird im

Internet eingesetzt, um dort die Absicherung von Hypertext Transfer Protocol-

Verbindungen (HTTP) zu ermöglichen. Bei einer erfolgreichen SSL-Verbindung

wird aus der HTTP-Verbindung eine Hypertext Transfer Protocol Secure-

Verbindung (HTTPS).

Beim ersten HTTPS-Request durch den Browser (Client) nutzt SSL die

asymmetrische Verschlüsselung. Hierzu versendet der Server seinen öffentlichen

Schlüssel (Public Key) und ein Zertifikat. Mit dieser Methode authentifiziert sich

der Webserver gegenüber dem Client. Das Zertifikat wurde vorher von einer Zertifizierungsstelle,

auch Certificate Authenticity (CA) genannt, ausgestellt. Die

Zertifizierungsstelle hat das Zertifikat mit ihrem privaten Schlüssel signiert, womit

die Echtheit der Daten bestätigt sind. Nach erfolgreicher Authentifizierung des

Servers, generiert der Browser einen symmetrischen Schlüssel. Dieser symmetrische

Schlüssel wird nun mit dem Public Key des Servers verschlüsselt und anschließend

an den Server übermittelt. Eine Nachricht, die mit dem Public Key

verschlüsselt wurde, kann nur mit dem Private Key entschlüsselt werden. Der

Server entschlüsselt diese Nachricht mit seinem privaten Schlüssel (Private Key)

und erhält somit den symmetrischen Schlüssel. Der symmetrischen Schlüssel hat

den Vorteil, dass die Ver- und Entschlüsselung wesentlich schneller durchgeführt

werden kann, als mit asymmetrischen Schlüsseln. Während der Datenübertragung

zwischen Client und Server wird immer wieder ein neuer Schlüssel ausgehandelt,

so dass ein möglicher Angreifer nur für eine kurze Zeit die Verbindung stören

kann.

23 Vgl. Elektronik-Kompendium.de: SSL - Secure Socket Layer


16 Kapitel 2: Grundlagen

2.2.2. Virtual Private Network (VPN) 24

VPN ist ein logisches privates Netzwerk auf einer öffentlich zugänglichen Infrastruktur.

Ziel ist es, dass nur die Kommunikationspartner, die zu diesem privaten

Netzwerk gehören, miteinander kommunizieren und Informationen und Daten

austauschen können. VPNs müssen Sicherheit der Authentizität, Vertraulichkeit

und Integrität sicherstellen. Authentizität bedeutet die Identifizierung von autorisierten

Nutzern und die Überprüfung der Daten. Es muss sichergestellt werden,

dass Daten nur von autorisierten Quellen übermittelt werden. Vertraulichkeit und

Geheimhaltung wird durch Verschlüsselung der Daten hergestellt. Die Verschlüsselung

wird ebenfalls wie bei SSL mit asymmetrischen und symmetrischen

Schlüsseln durchgeführt. Mit der Integrität wird sichergestellt, dass die Daten von

Dritten nicht verändert wurden. Um eine gesicherte Datenübertragung über das

unsichere Internet zu gewährleisten, wird mit einem Tunneling-Protokoll eine

verschlüsselte Verbindung, der VPN-Tunnel, aufgebaut. Hierbei handelt es sich

um eine logische Verbindung zwischen beliebigen Endpunkt. VPN wird in die

folgenden drei Topologien aufgeteilt:

Site-to-End Topologie

Abbildung 4: VPN Site-to-End Topologie

Hierbei können mehrere Clients zu einer Central Site verbinden. Die Clients

werden zu einem festen Bestandteil des Netzwerks der Central Site.

24 Vgl. Elektronik-Kompendium.de: VPN - Virtual Private Network


Kapitel 2: Grundlagen 17

End-to-End Topologie

Abbildung 5: VPN End-to-End Topologie

Bei dieser Topologie werden mehrere Clients zu einem virtuellen Netz eines

Servers verbunden. Die Clients können untereinander und mit dem Server kommunizieren,

jedoch nicht mit dem Netz hinter dem Server.

Site-to-Site Topologie

Abbildung 6: VPN Site-to-Site Topologie

Diese Topologie ermöglicht es mehrere Netze mit einem Hauptnetz zu verbinden.

Alle Clients können untereinander kommunizieren und sind direkt adressierbar.

2.2.3. Trusted Platform Module (TPM) 25

Das Trusted Platform Module (TPM) ist ein Chip, der einen Computer um Sicherheitsfunktionen

erweitert. In Kombination mit einer entsprechenden Software

bildet das TPM eine Trusted Computing Plattform – eine „vertrauenswürdige

Plattform“. Das TPM kann dazu verwendet werden ein System gegen softwareseitige

Manipulation durch unbefugte Dritte zu schützen. Bei dem aktuellen Stand ist

der Chip überwiegend passiv und beeinflusst weder den Bootvorgang noch den

Betrieb eines Computers.

Nach der Spezifikation 1.2 der Trusted Computing Group (TCG) beinhaltet

der Aufbau eines vertrauenswürdigen PCs eine Erweiterung der herkömmlichen

25 Vgl. BSI: Das Trusted Platform Module (TPM)


18 Kapitel 2: Grundlagen

PC-Architektur um ein Subsystem, welches aus einem Core Root of Trust for

Measurement (CRTM), einem Trusted Platform Module (TPM) und dem Trusted

Software Stack (TSS) besteht. Aufgrund der Komplexität und der Angreifbarkeit

der Software muss dies als Hardwarelösung umgesetzt werden. Ziel ist es eine

sichere Architektur, die so genannte Trusted Platform Architektur (TPA), zu erreichen.

Sie stellt sicher, dass für die gesamte Betriebsdauer immer wieder Vertrauen

zwischen entfernten Kommunikationspartnern hergestellt wird. Um dieses

Ziel zu erreichen sind die folgenden Zertifikate zur Sicherstellung der Authentizität

und der Integrität der beteiligten Systeme erforderlich:

Abbildung 7: Basiskomponenten des TPM 26


Endorsement Zertifikat: Durch das Endorsement Zertifikat wird sichergestellt,

dass das TPM von einem autorisierten Hersteller bereitgestellt wurde.

Ziel ist es durch das Endorsement Key Zertifikat, welches ein 2048 Bit langes

Schlüsselpaar enthält, das TPM eindeutig zu repräsentieren. Das Schlüsselpaar

kann sowohl bei der Herstellung des TPM-Chips vom Hersteller erzeugt

oder erst zu einem späteren Zeitpunkt im Chip gebildet werden. Der Endorsement

Key besitzt einen privaten und einen öffentlichen Schlüssel und wird

26 BSI: Das Trusted Platform Module (TPM)


Kapitel 2: Grundlagen 19




innerhalb des Chips gespeichert. Der private Teil des Endorsement Keys verlässt

den Chip aus Sicherheitsgründen nicht. Der Endorsement Key wird benötigt,

um die Attestation Identity Keys (AIK) herzustellen. Um eine anonyme

Identität zu erreichen, repräsentierte der AIK einen Alias mit dem der

Dienstleister durch Prüfung eines für seinen Service erzeugten AIK sicher

sein kann, eine vertrauenswürdige Plattform zu bedienen.

Platform Zertifikat: Der Hersteller einer Plattform, welche gesichert werden

soll (PCs, Laptops, Mobiltelefone), stellt ein Plattformzertifikat aus, mit welchen

er bestätigt, dass alle Plattformkomponenten den Spezifikationen der

TCG genügen und dass die Plattform ein gültiges TPM enthält. Das aktuelle

System wird somit als eine vertrauenswürdige Plattform bestätigt.

Conformance Zertifikat: Dieses Zertifikat bestätigt, dass das TPM-Design

in der Plattform der TCG-Spezifikation genügt und das TPM korrekt implementiert

ist.

Validation Zertifikat: Dieses Zertifikat stellt für Komponenten oder Komponentengruppen

(wie Grafikkarten oder Eingabegeräte) die Übereinstimmung

und Korrektheit der Implementierung gegenüber der TCG-

Spezifikation sicher.

2.3. Cloud-Computing

Bislang gibt es keine genaue Definition für Cloud-Computing, welche sich

allgemeingültig durchgesetzt hat. Aus diesem Grund wird Cloud-Computing oftmals

anhand ihrer Charakteristiken definiert. Das National Institute of Standards

and Technology (NIST) hat fünf Charakteristiken von Cloud-Computing definiert.

(siehe Kapitel 2.3.1. Charakteristiken der Cloud). Das Bundesamt für Sicherheit in

der Informationstechnik hat seine Definition zu Cloud-Computing folgendermaßen

veröffentlicht:

Cloud-Computing bezeichnet das dynamisch an den Bedarf angepasste Anbieten,

Nutzen und Abrechnen von IT-Dienstleistungen über ein Netz. Angebot

und Nutzung dieser Dienstleistungen erfolgen dabei ausschließlich über definierte

technische Schnittstellen und Protokolle. Die Spannbreite der im Rahmen von

Cloud-Computing angebotenen Dienstleistungen umfasst das komplette Spektrum


20 Kapitel 2: Grundlagen

der Informationstechnik und beinhaltet unter anderem Infrastruktur (z. B. Rechenleistung,

Speicherplatz), Plattformen und Software.“ 27

Cloud-Computing ist ein Ansatz bei dem die IT-Infrastruktur dynamisch an

den Bedarf angepasst wird. Jede netzwerkfähige Computing Ressource wird im

Cloud-Computing „as-a-Service“ zur Verfügung gestellt. Es erfolgt eine Abrechnung

bei Nutzung, was gleichzeitig den wichtigsten Unterschied zu bisherigen

Mainframe Computing Diensten oder reinen Virtualisierungslösungen darstellt.

Durch die automatische Auf- und Ab-Skalierbarkeit ermöglicht Cloud-Computing

Dienste jeglicher Art in einer Cloud Umgebung zu betreiben. Kleine und mittelständische

Unternehmen (KMUs) profitieren von Cloud-Computing durch eine

schnellere Markteinführung von neuen Softwareprodukten, ohne die sonst notwendige

kostenintensive Hardwareprovisionierung sowie vorausgehendem Know-

How Aufbau Ihrer Mitarbeitern (z.B. Hardware Administratoren). Bestellung und

Inbetriebnahme einer typischen Webserviceumgebung (Webserver, Datenbank,

Loadbalancer) kann innerhalb von Stunden geschehen anstatt mehrerer Tage. Typische

Lastspitzen bei einem Produktlaunch können durch die flexible Skalierung

nach oben vermieden werden. Sinkt die Zugriffsnachfrage, sorgt eine Rückskalierung

dafür, dass benutzte Cloudinstanzen ,meist virtuelle Maschinen (VMs), wieder

freigegeben werden und sich somit kostenneutral verhalten.

Der Einsatz von Cloud-Computing hat auch Implikationen auf die Makroökonomie.

Eine Studie besagt, dass durch die Einsparungen von deutschen Unternehmen,

welche bereits Cloud-Computing erfolgreich einsetzen, 55 Milliarden

Euro volkswirtschaftlicher Gewinn erzielt wird. Dies wird erreicht durch Geschäftszuwachs,

neue Geschäftsmodelle und direkte Kostensenkung durch geringere

Kapital- und Betriebskosten, sowie Einsparungen bei Energie und Kühlung.

Des Weiteren besagt die Studie, dass die untersuchten Länder Deutschland,

Frankreich, Italien, Großbritannien und Spanien bis zum Jahr 2015 zusammen 760

Milliarden Euro volkswirtschaftlichen Gewinn durch den Einsatz von Cloud-

27 BSI: Eckpunktepapier „Sicherheitsempfehlungen für Cloud-Computing Anbieter“ – finale

Fassung, S. 14


Kapitel 2: Grundlagen 21

Computing erreichen werden, solange sich die Marktdurchdringung von Cloud-

Technologien wie erwartet fortsetzt. 28

2.3.1. Charakteristiken der Cloud

Das National Institute of Standards and Technology (NIST) definiert fünf Eigenschaften

die eine Cloud aufweist:

1. On-demand Self Service: Die Ressourcen innerhalb eines Cloud-Systems

werden dorthin aufgeteilt, wo diese benötigt werden. Ressourcen können hier

beispielsweise Rechenleistung, Arbeitsspeicher oder Festplattenspeicher sein.

Diese Aufteilung erfolgt automatisch und benötigt keinerlei Interaktion mit

dem Cloud-Provider.

2. Broad Network Access: Die Services innerhalb eines Cloud-Systems sind

über Standard-Mechanismen über das Netz verfügbar und nicht an einen bestimmten

Client gebunden.

3. Resource Pooling: Sämtliche Ressourcen eines Cloud-Providers liegen in

einem Pool vor, aus denen sich eine Vielzahl von Anwendern bedienen kann.

Dieses Verfahren nennt man auch „Multi-Tenant Modell“. Hierbei wissen die

Anwender jedoch nicht, wo sich die Ressourcen tatsächlich befinden, sofern

keinerlei vertragliche Regelungen über den Speicherort, also zum Beispiel die

Region, Land oder Rechenzentrum, festgelegt wurden.

4. Rapid Elasticity: Die Services innerhalb der Cloud können schnell und elastisch

zur Verfügung gestellt werden. Da dies in der Regel automatisch erfolgt,

bekommt ein Anwender von diesem Vorgang meist nichts mit. Aus Sicht des

Anwenders scheinen die Ressourcen innerhalb der Cloud daher unendlich zu

sein.

5. Measured Services: Die Nutzung der Ressourcen wird gemessen und überwacht.

Diese Informationen dienen dem Cloud-Provider sowohl zur Überwachung

der Cloud um die Sicherheit zu gewährleisten, als auch zu Abrechnungszwecken

mit Anwendern der Cloud.

28 Vgl. CIO online - Holger Eriksdotter: 760 Milliarden Euro Gewinn bis 2015


22 Kapitel 2: Grundlagen

2.3.2. Service-Modelle der Cloud

Abbildung 8: Übersicht der Service-Modelle des Cloud-Computing

Software as a Service (SaaS)

SaaS bietet einem Cloud-Anwender die Möglichkeit Anwendungen, welche

auf der Cloud-Infrastruktur laufen, zu nutzen. Hierbei werden nur die Anwendungen

zur Verfügung gestellt und keinerlei Veränderungen an der darunterliegenden

Infrastruktur wie Netzwerk-, Firewall- oder Speichereinstellungen gestattet. Diese

Einstellungen werden von dem Cloud-Provider verwaltet. Der Zugriff auf diese

Anwendungen kann von einer Vielzahl von Clients durchgeführt werden. Ein Beispiel

für eine Cloud-Anwendungen ist „Google Docs“ (auch bekannt als „Google

Text & Tabellen“). Hierbei wird dem Anwender eine Webanwendung zur Textbearbeitung

zur Verfügung gestellt, welche auch zusammen mit anderen Nutzern

verwendet werden kann. Der Zugriff zu dieser Webanwendung wird mit jedem

üblichen Internet-Browser ermöglicht. Der Anwender kann diese Anwendung

verwenden, ohne dabei die Speicherung der Daten sowie deren Netzwerkfreigabe


Kapitel 2: Grundlagen 23

für andere Nutzer durchführen zu müssen, da dies von dem Cloud-Provider, in

diesem Beispiel Google, durchgeführt wird. 29

Platform as a Service (PaaS)

PaaS bietet einem Anwender die Möglichkeit Anwendungen auf die Cloud

einzuspielen (deployment) und dort ausführen zu lassen. Hierbei werden dem

Cloud-Anwender mehr Einstellungsmöglichkeiten als bei SaaS zur Verfügung

gestellt. Der Cloud-Provider legt dabei den Entwicklungsrahmen wie beispielsweise

die Programmiersprache fest. Die Funktionen der Anwendung sind hierbei

dem Kunden frei überlassen. Wie bei SaaS wird auch hier dem Kunden die Cloud-

Infrastruktur ohne Möglichkeit zur Verwaltung zur Verfügung gestellt. 30

Infrastructure as a Service (IaaS)

IaaS bietet dem Anwender direkten Zugang zu IT-Ressourcen wie Rechenleistung,

Datenspeicher oder Netze. Der Anwender kauft dabei diese virtuellen Dienste

und baut darauf eigene Dienste zum internen oder externen Gebrauch auf.

Durch die Anmietung von beispielsweise Rechenleistung, Arbeitsspeicher und

Datenspeicher kann der Anwender darauf Betriebssysteme mit Anwendungen

seiner Wahl laufen lassen. Bei diesem Modell erhält der Anwender die meiste

Kontrolle über die Administration. 31

2.3.3. Einsatzmöglichkeiten der Cloud 32

Die im vorigen Kapitel angesprochenen Service-Modelle können in vier Einsatzmöglichkeiten

implementiert werden:


Public Cloud: In der Public Cloud wird die Cloud-Infrastruktur der generellen

Öffentlichkeit oder einer großen Gruppe, beispielsweise einem bestimm-

29 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 26-27

30 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 26-27

31 Vgl. BSI:

Eckpunktepapier „Sicherheitsempfehlungen für Cloud-Computing Anbieter“ – finale Fassung,

S. 18

32 Vgl. Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud-

Computing V2.1, S. 17


24 Kapitel 2: Grundlagen




ter Industriebereich, zur Verfügung gestellt. Die Cloud ist Eigentum einer

Organisation welche Cloud-Dienste vermarktet.

Private Cloud: Die Private Cloud stellt seine Infrastruktur einer einzelnen

Organisation bereit. Hierbei kann die Cloud von dieser Organisation oder einem

Dritten verwaltet werden. Durch gesicherte Zugänge kann diese Verwaltung

sowohl vor Ort als auch aus der Ferne durchgeführt werden.

Community Cloud: Hierbei handelt es sich um eine Infrastruktur welche von

mehreren Organisationen verwendet wird, um einem bestimmten gemeinschaftlichen

Ziel zu verfolgen.

Hybrid Cloud: Bei einer Hybrid Cloud handelt es sich um eine Infrastruktur,

welche aus zwei oder mehreren Servicemodellen besteht. Hierbei wird die

Infrastruktur weiterhin als eine gemeinsame Entität gesehen. Ein Beispiel

hierfür wäre ein Private Cloud-Provider, welcher einen plötzlichen, ungeplanten

Ressourcenbedarf aufweist und kurzzeitig Ressourcen aus einer Public

Cloud anmietet.

2.3.4. Vor- und Nachteile des Cloud-Computing aus Sicht des KMU

Dieses Kapitel bietet einen kurzen Überblick über die Vor- und Nachteile

durch den Einsatz von Cloud-Computing aus der Sicht der kleinen und mittelständischen

Unternehmen (KMUs).

Vorteile durch den Einsatz von Cloud-Computing:

Reduzierung der Administration & Hardware: Durch den Einsatz

von Cloud-Computing, können mehrere Rechenzentren zusammengefasst

werden. Personal, welches bei den verschiedenen Rechenzentren

eingesetzt werden muss und dort jeweils die gleichen Arbeiten durchführt

wie beispielsweise das Update von Sicherheitssoftware, kann

ebenfalls eingespart werden. Die Administration beschränkt sich auf

das Cloud-System. Ein bekanntes Beispiel hierfür ist die US-

Regierung, welche im Juli 2011 angekündigt hat, 800 von 2000 Rechenzentren

stillzulegen. Diese Rechenzentren sollen zusammengefasst

werden in einem Cloud-System. Über vier Jahre soll durch die Einspa-


Kapitel 2: Grundlagen 25




rung von Hardware und Personal eine finanzielle Einsparung in Milliardenhöhe

erzielt werden. 33

Einsparung von Lizenzen: Durch den Einsatz von Cloud-Computing

kann eine Einsparung von Lizenzen ermöglicht werden. Wenn zum

Beispiel ganze Rechenzentren durch die Konsolidierung abgeschaltet

werden können so sind auch die Lizenzen nur noch einmal vorhanden.

Je nach Service-Modell des Cloud-Providers können auch einzelne Instanzen

mit vorinstallierten Diensten zur Verfügung gestellt werden.

So könnte ein Kunde diese Instanz wahlweise nur wenige Tage in Anspruch

nehmen und die Lizenzkosten könnten nur für diese Tage abgerechnet

werden. Ein Beispiel hierfür wäre ein Dienst, welcher die

Lohnabrechnungen für Personal durchführt. Wenn in einem Unternehmen

die Lohnabrechnungen nur einmal im Monat generiert werden und

diese Generierung nur wenige Tage benötigt, können diese Lizenzen

somit flexibel nur für diesen Zeitraum angemietet werden.

Bessere Übersicht der Dienste: Durch die Zentralisierung der Dienste

in einer Cloud ist eine bessere Übersicht für die Administration geschaffen.

Da die Dienste alle zentral an einem Punkt ausgeführt werden,

bietet sich hier für den Administrator ein besserer Überblick. Gerade

die Fehlersuche kann hierdurch beschleunigt werden, da sich diese

nicht über mehrere Rechenzentren erstreckt.

Flexible Erweiterung: Ressourcen werden in der Cloud flexibel vergeben

und können einfacher erweitert werden. Wenn beispielsweise

eine Public Cloud eingesetzt wird, so ist der Cloud-Provider dafür verantwortlich,

dass genügend Ressourcen vorhanden sind. Ein Cloud-

Kunde kann seine Anforderungen beliebig erweitern. Für ihn erscheint

es, als wären die Ressourcen endlos. Dadurch wird es möglich sehr

schnell an neue Ressourcen zu gelangen und das System beliebig zu

erweitern. Wenn sich die Anforderungen spontan ändern und weitere

Ressourcen benötigt werden, so können diese flexibel und schnell zur

Verfügung gestellt werden.

33 Vgl. Golem.de: Eine Amazon-Cloud speziell für die US-Regierung


26 Kapitel 2: Grundlagen

Nachteile durch den Einsatz von Cloud-Computing:

Anpassung bestehender Anwendungen: Je nach Cloud-Provider und

den eingesetzten Technologien wird es notwendig, dass bestehende

Anwendungen angepasst werden müssen. Bei dem Service-Modell

Software-as-a-Service wird einem Kunden die Möglichkeit gegeben,

bestehende Anwendungen zu verwenden. Wenn ein Kunde nun beispielsweise

seine eigene Anwendung, durch eine Anwendung innerhalb

der Cloud ersetzen möchte, so muss sichergestellt werden, dass

die Cloud-Anwendung das Dateiformat akzeptiert.

Verlust des Know-Hows: Durch die Hardwareabtretung an einen

Dienstleister besteht immer die Gefahr, dass das Know-How des eigenen

Personals verloren geht. Spezialisten für Sicherheitsmaßnahmen

oder Storage-Lösungen können durch den Einsatz von Cloud-

Computing überflüssig werden, da Kunden der Cloud von dem Cloud-

Provider abhängig werden.

Verlust der direkten Kontrolle: Wenn ein Unternehmen Cloud-

Computing einsetzt, so geht die direkte Kontrolle der Systeme verloren.

Die hauseigenen Administratoren können nicht mehr direkt Wartungsarbeiten

durchführen. Wenn beispielsweise Software-Updates

veröffentlicht werden, so muss darauf vertraut werden, dass der Cloud-

Provider diese Wartungsarbeiten zeitnah durchführt, um eventuelle kritische

Sicherheitslücken zu schließen. Falls das System ausfallen sollte,

so kann das eigene Personal nicht zur Fehlerbehebung eingesetzt

werden.

2.3.5. Cloud-Provider im Überblick 34

Dieses Kapitel behandelt fünf Cloud-Provider, welche sich auf dem Markt von

Cloud-Computing etabliert haben. Die Anbieter sind Amazon, Google, IBM,

Microsoft und Salesforce.com.

34 Vgl. Computerwoche.de – Herrmann, Wolfgang: Die wichtigsten Cloud-Anbieter im Überblick


Kapitel 2: Grundlagen 27

Amazon

Das Unternehmen Amazon ist in der Öffentlichkeit als Online-Händler bekannt

geworden. Anfangs wurden über die Online-Plattform von Amazon Bücher

vermarktet. Dieses Geschäftsfeld wurde mittlerweile dahingehend erweitert, dass

über die Plattform viele weitere Produktbereiche angeboten werden. Um die Produktbereiche

zu erweitern, hat Amazon die Plattform anderen Händlern zur Verfügung

gestellt und dafür eine Provision eingefordert. Daraus entstand die Amazon

Web Services (AWS). Das Unternehmen Amazon hat hierbei die Infrastruktur,

darunter die nötige Rechenkapazität, in ihrer Amazon Elastic Compute Cloud

(Amazon EC2) zur Verfügung gestellt. Geworben hat Amazon damit, dass eine

Stunde Linux für 0,10 € auf ihrer Infrastruktur angemietet werden kann. Mittlerweile

werden weitere Betriebssysteme wie beispielsweise Microsoft Windows

Server Instanzen oder SQL Server angeboten.

Google

Google ist in der Öffentlichkeit als Suchmaschinenbetreiber und Anbieter von

Online-Tools für den privaten Gebrauch bekannt geworden. Die Enterprise-Sparte

von Google beschäftigt sich mit Unternehmenskunden. Das Softwarepaket

„Google Apps Premier Edition“ ist ein Tool für den professionellen Einsatz innerhalb

Konzernen. Das Tool beschäftigt sich mit dem Web-basierten E-Mail-

Dienst Google Mail, der gemeinsam nutzbare Kalender und die Office-Suite

Google Docs, die grundlegende Funktion für Textverarbeitung, Tabellenkalkulation

und Präsentation, bereitstellt. Diese Dienste werden als SaaS-Dienste bereitgestellt.

IBM

IBM hat im Herbst 2007 bei der vorgestellten Initiative Blue Cloud seine

Cloud-Services eröffnet. Im Mittelpunkt stehen Software-Tools, die es Unternehmen

ermöglichen sollen, eine eigene Cloud-Infrastruktur aufzubauen. Blue Cloud

bietet eine Palette von Werkzeugen, mit deren Hilfe Kunden ihren Rechenzentrumsbetrieb

virtualisieren und automatisieren können. Hierbei werden Funktionen

für das Einrichten, Konfigurieren und Verwalten der IT-Infrastruktur im Rechenzentrum

zur Verfügung gestellt.


28 Kapitel 2: Grundlagen

Microsoft

Microsoft hat mit der „Azure Services Platform“ eine Infrastruktur zur Verfügung

gestellt, auf der sich mehrere Instanzen eines Betriebssystems ausführen

lassen. Microsoft entwickelt eine eigene Hardwareabstraktions- und Virtualisierungsschicht

auf der Windows Server 2008 ausgeführt wird und setzt dabei nicht

auf quelloffene Hypervisor. Über dem Betriebssystem bietet das Unternehmen

eine Reihe von Web Services an, darunter die Dienste von „Live“ wie .NET-,

SQL-, Sharepoint- und Dynamics-CRM-Services.

Salesforce.com

Salesforce.com ist im Bereich SaaS bei Cloud-Computing bekannt geworden.

Der Anbieter bietet Entwicklern eine Infrastruktur an, auf der sie eigene Softwaredienste

entwickeln und später zur Miete anbieten können. Entwicklungs- und

Collaboration-Tools für die Plattformteilnehmer sowie ein Marktplatz für On-

Demand-Applikationen ergänzen das Angebot. Ziel des Anbieters ist es, Kunden

eine möglichst komplette Softwarepalette zur Nutzung über das Web anzubieten.

2.4. BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter 35

Das Bundesamt für Sicherheit in der Informationstechnik wurde am 1. Januar

1991 mit Sitz in Bonn gegründet und gehört zum Geschäftsbereich des Bundesministeriums

des Inneren. Das BSI ist ein zentraler IT-Sicherheitsdienstleister des

Bundes und ist operativ für den Bund, kooperativ mit der Wirtschaft und informativ

für die Bürger tätig. Durch die Grundlagenarbeit im Bereich der IT-Sicherheit

ist das BSI für die innere Sicherheit in Deutschland zuständig. Das Ziel des BSI

ist der sichere Einsatz von Informations- und Kommunikationstechnik in unserer

Gesellschaft. Die Sicherheitsaspekte sollen schon bei der Entwicklung von IT-

Systemen und -Anwendungen berücksichtigt werden.

Das Eckpunktepapier zum Thema Cloud-Computing gibt einen kompakten

Überblick über die wichtigsten organisatorischen, personellen, infrastrukturellen

35 BSI: Eckpunktepapier „Sicherheitsempfehlungen für Cloud-Computing Anbieter“ – finale

Fassung, S. 7


Kapitel 2: Grundlagen 29

und technischen Informationssicherheitsmaßnahmen für Cloud-Computing Anbieter.

Bei der Erstellung des Eckpunktepapiers wurde zunächst ein Entwurf mit dem

Titel „BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter –

Entwurf“ herausgegeben. Nachdem der Entwurf veröffentlicht wurde, hat das BSI

Verbesserungsvorschläge entgegengenommen und in ihre finale Fassung übernommen.


Kapitel 3: Security-Analyse von Cloud-Computing 31

3. Security-Analyse von Cloud-Computing

3.1. Analyse der Gefahren des Cloud-Computing

Nr. Titel Seite

G1 Unbekannte Richtlinien zur Mitarbeiterüberprüfung 31

G2 Mangelhafte Informationspolitik 33

G3 Gefahr durch Zentralisierung 35

G4 Verlust der direkten Kontrolle 36

G5 Interne Angriffe 37

G6 Unzureichende Abgrenzung der virtuellen Ressourcen 38

G7 Missbrauch von Cloud-Ressourcen 39

G8 Unbekannte Laufzeitumgebung der virtuellen Maschinen 40

G9 Unbekannter Speicherort der Daten 42

G10 Physischer Zugang zu Rechenzentren wird nicht gewährt 42

G11 Unbekannte Sicherheitsmechanismen 43

G12 Fehlende Interoperabilität & Portabilität und fehlende Transparenz 43

über Datenverbleib bei Providerkündigung / -wechsel

G13 Unzureichendes Sicherheits-Monitoring 44

G14 Unsichere API-Schnittstellen 45

Tabelle 2: Gefahren des Cloud-Computing im Überblick

3.1.1. Gefahrenverstärkung der bekannten Gefahren durch den Einsatz von

Cloud-Computing

G1 Unbekannte Richtlinien zur Mitarbeiterüberprüfung

Eine Auslagerung der Systeme bedeutet auch immer ein Vertrauen in den Provider

und seine Mitarbeiter. Bei einem Outsourcing-Projekt haben die Administratoren

Zugang auf die Systeme um Wartungsarbeiten durchzuführen. Wartungsarbeiten

wären beispielsweise die Installation von Softwareupdates oder die Ressourcenänderungen

aufgrund von Anforderungsänderungen. Bei Cloud-

Computing sind diese Wartungsarbeiten ebenfalls von Mitarbeitern des Providers

durchzuführen. Hier können virtuelle Maschinen als Managed Root-Server betrieben

werden und die Administratoren sind für die Administration der unterliegenden

Hostmaschinen zuständig. Obwohl ein Administrator nicht unbedingt direkt


32 Kapitel 3: Security-Analyse von Cloud-Computing

Zugriff auf die virtuelle Maschine hat, so hat er trotzdem Zugriff auf den Hypervisor,

was auch immer einen Zugriff auf laufende virtuelle Maschinen des Hostsystems

bedeutet. Dieser Zugang kann unter Umständen missbraucht werden. Insbesondere

wird diese Gefahr aufgrund der Tatsache verstärkt, dass ein Administrator

aufgrund der Größe der Cloud Zugang zu einer Vielzahl von Daten hat. Es muss

eine klare Transparenz für den Cloud-Kunden erreicht werden indem klargestellt

wird, welche Einstellungsanforderungen Cloud-Provider an ihre Administratoren

stellen. Ebenfalls muss klargestellt werden, welche Zugriffe erlaubt, protokolliert

36 37

und kontrolliert werden.

Eine weitere Gefahr für das Gesamtsystem ist die Kompetenz der Administratoren

des Cloud-Providers. Aufgrund der Größe der Cloud und der Vielzahl von

Cloud-Kunden kann hier ein einfacher Fehler eines Administrators sehr schwerwiegende

Folgen haben. Im Rahmen der Studie „IT Security in Deutschland

2011“ hat das Marktforschungsunternehmen IDC (International Data Corporation)

im Juni 2011 ermittelt, dass Mitarbeiter das größte Sicherheitsrisiko in der IT-

Security-Kette darstellen. 38 Die besten Sicherheitsmechanismen sind immer von

der korrekten Konfiguration und von der fehlerfreien Arbeit der Administratoren

abhängig. Es gibt viele Bereiche wo das fehlerfreie Arbeiten eine absolute Notwendigkeit

ist, wie zum Beispiel bei der Reparatur von Flugzeugen bei Fluggesellschaften.

Um dies zu bewerkstelligen werden Techniken eingesetzt wie z.B.

das 4-Augen-Prinzip, bei welchem jeweils zwei Mitarbeiter zusammen Arbeiten

durchführen müssen, anstatt diese alleine durchzuführen. Es kann nicht verhindert

werden, dass neue und noch unerfahrene Mitarbeiter in einem Betrieb arbeiten.

Ein Cloud-Provider kann jedoch sicherstellen, dass die Arbeit eines solchen Mitarbeiters

von einem erfahrenen Kollegen überprüft werden muss.

Ein Beispiel für die Auswirkung eines Fehlers im Bereich des Cloud-

Computing, ist der Vorfall vom 21. April 2011 bei dem Cloud-Provider Amazon

39 : Um die Kapazitäten der Cloud zu erhöhen, wurden routinemäßige Änderungen

an dem Netzwerk durchgeführt. Ziel war es die Kapazität des primären

36 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 18

37 Vgl. Network World – Brodkin, Jon: Gartner: Seven cloud-computing security risks, S. 1

38 Vgl. Elektroniknet.de – Kuppinger, Stefan: Mitarbeiter sind die gefährlichsten Trojaner

39 Vgl. Amazon Web Services: Summary of the Amazon EC2 and Amazon RDS Service Disruption

in the US East Region


Kapitel 3: Security-Analyse von Cloud-Computing 33

Netzwerkes zu erhöhen. Um dies zu bewerkstelligen, wurde der Datentransfer auf

einen redundanten Router innerhalb des primären Netzwerks umgeleitet. Jedoch

ist bei diesem routinemäßigen Vorgehen ein Fehler unterlaufen und die Umleitung

des Datentransfers wurde falsch ausgeführt. Der Datentransfer wurde nicht auf

einen redundanten Router des primären Netzwerks umgeleitet, sondern auf einen

redundanten Router eines sekundären Netzwerkes mit niedrigerer Kapazität. Dies

hatte zur Auswirkung, dass das sekundäre Netzwerk den erhaltenen Datentransfer

nicht korrekt verarbeiten konnte und Teile der Cloud isoliert wurden. Nachdem

der Fehler entdeckt wurde, wurde die Umleitung des Datentransfers sofort rückgängig

gemacht. Nachdem die Netzwerkkonnektivität wiederhergestellt wurde,

haben die einzelnen Knoten innerhalb der Cloud begonnen ihre Daten zu spiegeln.

Normalerweise würde dieses Vorgehen innerhalb weniger Millisekunden passieren.

Da jedoch eine große Anzahl von Knoten betroffen war, wurde die freie Kapazität

zur Spiegelung der Daten sehr schnell aufgebraucht. Dies hatte zur Folge,

dass die Knoten in einer Endlosschleife auf weiteren freien Datenspeicher warteten.

Diese Kettenreaktion führte dazu, dass eine Vielzahl von Diensten innerhalb

der Cloud ausfielen.

Betroffene Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität,

Autorisierung, Zurechenbarkeit, Verbindlichkeit, Datenschutz

G2 Mangelhafte Informationspolitik

Die Hardware-Abtretung an einen Dienstleister bedeutet auch gleichzeitig,

dass ein Kunde sich auf die Informationspolitik des Dienstleisters verlassen muss.

Es muss sichergestellt werden, dass eine vollständige Transparenz bei Sicherheitsvorfällen

existiert. Die Offenlegung von Sicherheitsvorfällen ist grundsätzlich

mit einem gewissen Imageschaden verbunden. Gerade Dienstleister sind

möglicherweise nicht daran interessiert, der Öffentlichkeit mitzuteilen dass ihre

Sicherheitsmechanismen unzureichend waren, um einen Angriff abzuwenden.

Wenn bei einem erfolgreichen Angriff ein Schaden verursacht wurde, kann dies

durch Nachrichtenkanäle publik werden, was somit auch gleichzeitig eine Stellungnahme

des Dienstleisters erzwingt. Falls jedoch eine Sicherheitslücke ge-


34 Kapitel 3: Security-Analyse von Cloud-Computing

schlossen wurde, bei welchem zunächst kein erkennbarer Schaden verursacht

wurde, ist fraglich ob dieser Vorfall die Öffentlichkeit erreicht.

Abbildung 9: Amazon Health Dashboard am 25.05.2011 40

Abbildung 10: Amazon Health Dashboard am 31.05.2011 41

40 http://status.aws.amazon.com (entnommen am 25.05.2011)


Kapitel 3: Security-Analyse von Cloud-Computing 35

Der Cloud-Provider Amazon hat bei seiner „Amazon Elastic Compute Cloud

(EC2) das so genannte „Service Health Dashboard“ eingeführt. Diese Oberfläche

stellt den Verfügbarkeitsstatus der EC2 dar und informiert den Kunden über Störungen

beziehungsweise Ausfälle innerhalb der Cloud. Der Verfügbarkeitsstatus

erstreckt sich allerdings nur über eine Historie von ca. 5 Wochen. Die Abbildung

9 und Abbildung 10 zeigt jeweils Zugriffe auf das „Service Health Dashboard“.

Bei dem ersten Zugriff (Abbildung 9) kann auf der letzten Seite des Berichts noch

ein Ausfall zwischen dem 21. und dem 24. April eingesehen werden und wenn

mit dem Mauszeiger auf den Tag gezeigt wird, können weitere Details über die

Störung eingesehen werden. Bei dem zweiten Zugriff (Abbildung 10) ist alles

grün hinterlegt und dieser Vorfall ist nicht mehr länger einsehbar.

Betroffene Schutzziele: Datenschutz, Integrität, Verfügbarkeit, Zurechenbarkeit

G3 Gefahr durch Zentralisierung

Durch Zentralisierung werden alle Dienste auf einen gemeinsamen physischen

Ort verschoben. Wenn ein Unternehmen beispielsweise mehrere Rechenzentren

betreibt, dann verteilt sich das Risiko eines Angriffes von außen. Es ist nicht unbedingt

gegeben, dass wenn in einem Rechenzentrum die Sicherheitsmaßnahmen

unzureichend waren und dadurch einen Angriff ermöglichten, dass die restlichen

Rechenzentren somit automatisch ebenfalls angreifbar werden. Durch die Zentralisierung

werden alle Dienste den gleichen Sicherheitsmechanismen unterworfen.

Darüber hinaus entsteht dadurch ein single-point-of-attack – also quasi eine „große

Zielscheibe“. Angriffe, wie beispielsweise Denial of Service Attacken, bei

welchen ein Server oder ein Rechenzentrum mit einer massiven Anzahl von unnötigen

Anfragen gestört wird, sind durch die Zentralisierung wesentlich effektiver,

da sämtliche Ressourcen für den Angriff auf nur ein Ziel gerichtet werden müssen.

Durch den Einsatz von Cloud-Computing erhöht sich diese Gefahr. Wenn ein

Angreifer einem bestimmten Cloud-Kunden durch einen Angriff Schaden zufügen

möchte, so können alle anderen Cloud-Kunden von diesem Angriff ebenfalls be-

41 http://status.aws.amazon.com (entnommen am 31.05.2011)


36 Kapitel 3: Security-Analyse von Cloud-Computing

troffen sein. Wenn zum Beispiel durch den Angriff das Rechenzentrum außer Betrieb

gesetzt wird, so sind andere Kunden dadurch betroffen, obwohl der Angriff

nicht gegen sie gerichtet war. 42

Die Zentralisierung von Diensten hat einen Einfluss auf die Fehleranfälligkeit.

Speziell bei dem Einsatz von Cloud-Computing kann beobachtet werden, dass die

Auswirkungen von Störungen verstärkt werden. Als Beispiel hierfür dient der

Cloud-Provider Amazon, welcher im August 2011 eine Störung des Rechenzentrums

zu beklagen hatte. Während eines Unwetters nahe dem Rechenzentrum in

Dublin, ist es zu Ausfällen von über 50 % gekommen. Nach Aussagen von Amazon

gab es eine Störung mit der Notstromversorgung, welche zu diesen Ausfällen

führte. Zwar sind solche Fehler auch bei bisherigen Rechenzentren ohne den Einsatz

von Cloud-Technologien zu beobachten, jedoch gab es durch die Größe der

Cloud hierbei Schwierigkeiten alle Dienste wieder hochzufahren. Da Cloud-

Systeme redundant aufgebaut sind, werden Daten grundsätzlich gespiegelt, um

einen Datenverlust bei Ausfällen vorzubeugen. Wenn innerhalb des Cloud-

Systems eine Verbindung zu den gespiegelten Daten unterbrochen wird, so werden

diese Daten automatisch auf einem anderen Ort repliziert damit sie immer

doppelt hinterlegt sind. Solange die Daten nicht vollständig gespiegelt wurden,

können die Instanzen innerhalb der Cloud keine Daten schreiben. Eine virtuelle

Maschine wäre in diesem Status „eingefroren“. Da während der Störung viele

Verbindungen ausgefallen sind, mussten alle Speichervolumen die Daten erneut

spiegeln. Dies führte dazu, dass innerhalb kürzester Zeit durch eine Kettenreaktion

der Speicherplatz innerhalb der Cloud aufgebraucht war. Während der Cloud-

Provider dafür sorgte, dass zusätzlicher Speicherplatz für die Cloud zur Verfügung

gestellt wurde, waren alle virtuellen Maschinen pausiert und somit nicht

mehr erreichbar. 43

G4

Verlust der direkten Kontrolle

Die Hardwareabtretung an einen Dienstleister bedeutet auch automatisch den

Verlust der direkten Kontrolle. Wenn die Dienste nicht mehr im eigenen Rechenzentrum

ausgeführt werden, können Wartungsarbeiten nicht mehr selbst durchge-

42 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 18

43 Vgl. Golem.de: Cloud-Computing: Amazons Speichersystem ging der Platz aus


Kapitel 3: Security-Analyse von Cloud-Computing 37

führt werden. Es muss darauf vertraut werden, dass der Cloud-Provider zeitnah

Wartungsarbeiten durchführt und Ausfälle beseitigt. Zwar ist diese Gefahr bei

Outsourcing generell gegeben jedoch wird sie durch den Einsatz von Cloud-

Computing verstärkt. Im Kapitel „Gefahr durch Zentralisierung“ wird erläutert,

wieso Cloud-Provider häufiger Angriffen aus dem Internet ausgesetzt sind. Aus

diesem Grund muss sichergestellt werden, dass sämtliche Sicherheitsmechanismen

und die eingesetzte Virtualisierungs-Software immer auf dem aktuellen Stand

sind. Durch die Abtretung der Hardware-Hoheit kann dies nicht mehr von dem

eigenen Personal durchgeführt werden und benötigt somit ein Vertrauen in das

Personal des Cloud-Providers, dass Updates und Patchs zum Schließen von Sicherheitslücken

rechtzeitig durchgeführt werden. 44

Betroffene Schutzziele: Verbindlichkeit, Verfügbarkeit, Datenschutz, Vertraulichkeit

G5 Interne Angriffe

Durch den Einsatz von Cloud-Computing ist man internen Gefahren ausgesetzt.

Wenn vorher ein eigenes Rechenzentrum betrieben wurde, in welchem nur

die eigenen Dienste ausgeführt wurden, war die Gefahr von internen Angriffen

ausgeschlossen. Bei dem Einsatz von Cloud-Computing können eine Vielzahl von

Kunden die Ressourcen der Cloud verwenden. Hierbei besteht die Gefahr, dass

ein Kunde sich Ressourcen anmietet und anschließend Angriffe von innen auf

andere Kunden der Cloud ausführt. In einem solchen Fall wären die Sicherheitsmechanismen,

die einem Kunden vor Angriffen von außen schützen, nutzlos. Es

muss also sichergestellt werden, dass nur Kunden, welche ausreichend überprüft

wurden, Zugang zu der Cloud ermöglicht wird. In der Praxis war es bereits möglich

mit einer einfachen Kreditkarte Cloud Ressourcen anzumieten. Bei einem der

größten Cloud-Provider Amazon, hat die mangelhafte Überprüfung von Kunden

bereits zu Problemen geführt. Bei dem Spielekonzern Sony wurden Daten von

über 100 Millionen Nutzern gestohlen nachdem ihre Rechenzentren angegriffen

wurden. Medienberichten zufolge wurden diese Angriffe mit Ressourcen aus der

44 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 15


38 Kapitel 3: Security-Analyse von Cloud-Computing

Amazon EC2 Cloud durchgeführt. Dem Bericht zufolge hatten sich Datendiebe

45 46

unter falschen Namen einen Account eingerichtet.

Aber nicht nur eine mangelhafte Überprüfung der Kundeninformationen kann

eine Gefahr für Cloud-Systeme bedeuten. So könnten beispielsweise auch die Zugangsinformationen

bestehender Kunden gestohlen werden. Fishing-Attacken,

gestohlene Laptops oder schwache Zugangsdaten sind einfache Beispiele für die

Beschaffung der Zugangsdaten legitimer Kunden.

Betroffene Schutzziele: Datenschutz, Integrität, Verfügbarkeit, Zurechenbarkeit

G6 Unzureichende Abgrenzung der virtuellen Ressourcen

Bei dem Einsatz von Virtualisierungs-Software werden physische Ressourcen

in virtuelle Ressourcen aufgeteilt. Dies ermöglicht die bessere Auslastung physischen

Ressourcen. Eine Gefahr besteht hier für den Anwender dahingehend, dass

die sichere Aufteilung der virtuellen Ressourcen gewährleistet sein muss. Es darf

beispielsweise nicht möglich sein, das Kunde A auf die virtuelle Ressourcen von

Kunde B zugreifen kann. Diese Trennung kann bei manchen physischen Ressourcen

einfach umgesetzt werden. Wenn beispielsweise physischer Datenspeicher

getrennt werden muss, so kann bei der Virtualisierung ein fester Anteil der physischen

Festplatte gesperrt werden. Falls ein Kunde mehr Speicherplatz benötigt, so

kann ein weiterer Anteil belegt werden. Falls ein Kunde weniger Speicherplatz

benötigt, so kann dieser Speicherplatz wieder freigegeben werden. Hierbei muss

jedoch sichergestellt werden, dass die Daten vollständig vernichtet wurden und

nicht wiederhergestellt werden können. Ansonsten könnte ein Kunde, welcher

neuen Speicherplatz zur Verfügung gestellt bekommt, auf Datenreste eines anderen

Kunden zugreifen, beziehungsweise diese wiederherstellen.

Es gibt jedoch auch Ressourcen, welche sehr schnell ihren Besitzer wechseln

müssen. Arbeitsspeicher ist eine Ressource, welche sehr häufig und schnell seinen

Besitzer wechselt. Dieses Vorgehen findet im laufenden Betrieb statt und es muss

45 Vgl. Chip Online: Bericht: Sony-Hacker kamen von Amazon

46 Vgl. Dölitzscher, Frank et. al.: Security Audit as a Service (SAaaS) - An autonomous agent

based IDS for Cloud-Computing, S. 3


Kapitel 3: Security-Analyse von Cloud-Computing 39

gewährleistet sein, dass hier keinerlei Datenreste des Vorbesitzers ausgelesen

werden können. Bei der klassischen Virtualisierung kann einem Kunden einen

festen Teil des Arbeitsspeichers reserviert werden. Bei Cloud-Computing kann

dies nicht mehr durchgeführt werden, da hier die Zuteilung der Ressourcen flexibel

stattfindet. Arbeitsspeicher hat bei der Datensicherheit einen entscheidenden

Nachteil, da er kann nicht verschlüsselt werden kann. Wenn ein Kunde beispielsweise

Daten auf einer virtuellen Festplatte speichert, so kann er diese Daten trotzdem

intern verschlüsseln. Um diese Daten jedoch zu entschlüsseln, benötigt der

Kunde einen Schlüssel, welchen er im laufenden Betrieb in dem Arbeitsspeicher

zwischenspeichern muss. Wenn nun ein anderer Kunde den Schlüssel für die Entschlüsselung

der Daten aus den Überresten des Arbeitsspeichers auslesen könnte,

so wäre die Datensicherheit gefährdet. Die gleiche Gefahr gilt auch für den Prozessor-Cache.

Auch hier darf es nicht möglich sein, im laufenden Betrieb Infor-

47 48

mation eines anderen Kunden auszulesen.

Betroffene Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität,

Zurechenbarkeit, Verbindlichkeit, Datenschutz

3.1.2. Neue Gefahren durch Cloud-Computing

G7

Missbrauch von Cloud-Ressourcen

Die Möglichkeit eine Vielzahl von Ressourcen schnell zur Verfügung gestellt

zu bekommen, ist nicht nur für legal agierende Unternehmen attraktiv. Angreifer

können sich schnell Zugriff zu enormen Rechenleistungen verschaffen – dies zu

relativ günstigen Preisen und nahezu sofort. Ein Cloud-Provider kann aufgrund

der Größe der Cloud und der Vielzahl von Kunden schnell den Überblick darüber

verlieren, welche Dienste innerhalb der Cloud ausgeführt werden. Insbesondere

wenn neue Kunden nicht ausreichend überprüft wurden, können diese Ressourcen

unter falschem Namen anmieten und verwenden. Ein Beispiel hierfür ist der Angriff

auf die Spielefirma Sony. Hier haben Hacker Daten von über 100 Millionen

Kunden gestohlen. Der US-Informationsdienst Bloomberg hat hierbei berichtet,

dass für den Angriff Ressourcen der Amazon EC2 Cloud eingesetzt wurden. Ei-

47 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 38

48 Vgl. Vaquero Luis et. al: Locking the sky: a survey on IaaS cloud security, S. 100


40 Kapitel 3: Security-Analyse von Cloud-Computing

nem Bericht zufolge haben sich Datendiebe unter falschem Namen die Ressourcen

der Cloud angemietet. Der Cloud-Provider hat hierbei offenbar keine genaue

Kundenüberprüfung durchgeführt. 49

Der Missbrauch von Cloud Ressourcen hat auch Auswirkungen auf legitime

Kunden. Wenn Ressourcen der Cloud für illegale Zwecke verwendet werden, so

wird dabei der IP-Bereich des Cloud-Netzwerks verwendet. Es gab bereits Fälle,

wo für die Versendung von Spam E-Mails Ressourcen der Cloud angemietet wurden.

Zur Bekämpfung von Spam E-Mails werden die IP-Adressen von den Absendern

blockiert. Bei dem Cloud-Provider Amazon hatte dieser Vorfall Auswirkungen

auf alle Cloud-Kunden. Der IP-Bereich der gesamten Cloud wurde aufgrund

von dem massiven Versenden von Spam E-Mails auf die Blacklist gesetzt.

Dies hatte zur Auswirkung, dass alle Kunden der Cloud hiervon betroffen waren

und somit massive Probleme hatten, legitime E-Mails zu versenden. 50

Betroffene Schutzziele: Verfügbarkeit

G8 Unbekannte Laufzeitumgebung der virtuellen Maschinen

Bei einem bisherigen Outsourcing-Projekt mit Virtualisierung, wurde die

Hardware eines bestimmten Rechenzentrums angemietet. Ein Kunde wusste somit

automatisch, wo seine virtuellen Maschinen ausgeführt wurden. Im Idealfall konnte

er das Rechenzentrum persönlich betreten und sich einen Überblick über physikalische

Sicherheitsmaßnahmen verschaffen. Durch den Einsatz von Cloud-

Computing kann ein Cloud-Kunde nicht persönlich überprüfen, wo seine virtuellen

Maschinen ausgeführt werden. Es ist möglich, eine virtuelle Maschine auf ein

unterschiedliches System zu migrieren. Dies kann sowohl vor dem Start der virtuellen

Maschine erfolgen, sowie auch während dem laufenden Betrieb. Die Dienste

innerhalb der virtuellen Maschine laufen während diesem Migrationsprozess ungestört

weiter. Es ist somit nicht zu erkennen, dass die virtuelle Maschine das Rechenzentrum

verlassen hat. Bei einem solchen Fall kann nicht mehr sichergestellt

werden, dass hierbei dieselben Sicherheitsvorkehrungen eingehalten werden, die-

49 Vgl. Chip Online: Bericht: Sony-Hacker kamen von Amazon

50 Vgl. searchCloudComputing.com: Amazon EC2 email blocked by antispam group Spamhaus


Kapitel 3: Security-Analyse von Cloud-Computing 41

selben Ressourcen zur Verfügung gestellt werden und der reibungslose Betrieb

gewährleistet wird. Es ist somit möglich, dass die virtuelle Maschine an ein unbekanntes

Rechenzentrum weitergeleitet wird. Dieses Rechenzentrum muss nicht

unbedingt dem Cloud-Provider gehören, sondern kann auch ein Drittanbieter sein,

51 52

welcher ganz andere Sicherheitsvorkehrungen betreibt.

Eine virtuelle Maschine kann auch in ein Rechenzentrum migriert werden,

welches in einem anderen Land betrieben wird. Kritisch sind hierbei die Gesetze

des jeweiligen Land, da jedes Land eigene Gesetze zum Thema Datenschutz hat.

Eine Migration in ein anderes Land bedeutet auch gleichzeitig, dass man diesen

lokalen Gesetzen unterworfen ist. Ein bekanntes Beispiel ist der „USA Patriot

Act“. Wenn beispielsweise europäische Daten in einem Datenzentrum innerhalb

Europas abgelegt werden, somit den EU Raum unter keinen Umständen verlassen

können, und der Cloud-Provider ein amerikanisches Unternehmen ist, so ist er

diesem „USA Patriot Act“ trotzdem unterworfen. Der Patriot Act erlaubt den US-

Behörden die Überwachung von Kommunikationsmitteln. Das bedeutet dass persönliche

und geschäftliche Daten von vermeintlich verdächtigen Personen beschlagnahmt

werden können – eine Praxis die von Datenschützern kritisch betrachtet

wird. Zwar werben Cloud-Provider damit, dass sie ihre Kunden über

staatliche Eingriffe in Kenntnis setzen werden, jedoch kann dies in der Praxis

nicht erfolgen, da in dem Patriot Act auch eine Schweigeverpflichtung vorgesehen

ist. Somit kann ein Cloud-Provider trotz allen Versprechungen gegenüber einem

Kunden der Cloud gegen diese Herausgabe der Daten nichts unternehmen und ihn

dabei auch nicht über die Herausgabe in Kenntnis setzen. 53

Betroffene Schutzziele: Datenschutz, Vertraulichkeit, Verfügbarkeit

Daten

51 Vgl. Network World – Brodkin, Jon: Gartner: Seven cloud-computing security risks, S. 2

52 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 20

53 Vgl. CBS Interactive GmbH – Gassner, Sibylle: USA haben Zugriff auf europäische Cloud-


42 Kapitel 3: Security-Analyse von Cloud-Computing

G9 Unbekannter Speicherort der Daten

Bei der Gefahr „Unbekannte Laufzeitumgebung der virtuellen Maschinen“ ist

bereits erläutert, wieso ein unbekannter Speicherort eine Gefahr darstellt. Es muss

jedoch differenziert werden, zwischen einer unbekannten Laufzeitumgebung und

einem unbekannten Speicherort.

Betroffene Schutzziele: Datenschutz, Vertraulichkeit, Verfügbarkeit

G10 Physischer Zugang zu Rechenzentren wird nicht gewährt 54

Bei der Erteilung großer IT-Outsourcing-Projekte, bieten Dienstleister oftmals

eine Besichtigung des Rechenzentrums an. So kann sich der Kunde über die physischen

Sicherheitsmaßnahmen, wie z.B. Videoüberwachung, Ausweiskontrolle

und Protokollerstellung, selbst ein Bild machen. Es ist auch möglich zu sehen wie

in dem Rechenzentrum mit einem möglichen Kabelbrand umgegangen wird. Rechenzentren

können hierfür ein automatisches System haben, welches bei einem

Kabelbrand gewährleistet, dass technische Geräte automatisch abgeschaltet werden

und ein entsprechender Alarm ausgelöst wird. Auch kann in einem Rechenzentrum

beobachtet werden wie mit dem Temperaturanstieg durch die Geräte umgegangen

wird. Ein Rechenzentrum sollte in der Regel einen Wärme- und Kälte-

Kanal besitzen. Durch diese Methode ist eine effizientere Nutzung des Stromverbrauchs

gewährleistet.

Cloud-Provider legen nicht nur ihre technischen Sicherheitsmaßnahmen nicht

offen (siehe Gefahr „G11 Unbekannte Sicherheitsmaßnahmen“), sondern bieten

auch dem Kunden keinen physischen Zugang zu den Rechenzentren. Gerade in

Anbetracht dessen, dass ein Cloud-Provider eine sehr hohe Anzahl an Kunden hat,

steigt ebenfalls die physische Gefahr für die Rechenzentren. Eine physische Sabotage

hätte beispielsweise bei einem kleinen Outsourcing-Dienstleister keine so

große Wirkung, wie bei einem großen Cloud-Provider.

Betroffene Schutzziele: Datenschutz, Vertraulichkeit, Verfügbarkeit

54 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 50


Kapitel 3: Security-Analyse von Cloud-Computing 43

G11 Unbekannte Sicherheitsmechanismen

Bei dem Einsatz von Cloud-Computing sind die eingesetzten Sicherheitsmaßnahmen

unbekannt. Cloud-Provider legen absichtlich nicht ihre Sicherheitsmaßnahmen

offen, um sich und ihre Kunden vor gezielten Angriffen zu schützen. Ein

Cloud-Provider muss die aktuellen Sicherheitsstandards einsetzen, um seine Kunden

zu schützen. Die Cloud-Kunden hingegen haben keine Möglichkeit zu überprüfen

ob dies durchgeführt wird und müssen sich somit auf den Cloud-Provider

verlassen. Bis zum heutigen Tage sind keine Standardkriterien für die Sicherheit

einer Cloud Umgebung definiert worden. In dem von dem BSI veröffentlichten

Eckpunktepapier mit Sicherheitsempfehlungen für Cloud-Computing-Anbieter

werden sehr detaillierte Sicherheitsmaßnahmen aufgeführt. Diese sollten zwar

befolgt werden, jedoch handelt es sich hierbei lediglich um Sicherheitsempfehlungen

und nicht um Sicherheitsvorschriften. 55

Betroffene Schutzziele: Datenschutz, Integrität, Verfügbarkeit

G12 Fehlende Interoperabilität & Portabilität und fehlende Transparenz

über Datenverbleib bei Providerkündigung / -wechsel

Durch den Einsatz von Cloud-Computing ist ein Cloud-Kunde automatisch an

die providerspezifischen Monitoring-Schnittstellen gebunden. Dadurch dass

Cloud-Provider unterschiedliche Schnittstellen für den Einsatz von Cloud-

Computing verwenden, sind bei einem Wechsel diese Schnittstellen inkompatibel

zueinander. Eine Migration einer Cloud Instanz von einem Anbieter zu einem

anderen ist somit nicht möglich. Dies erhöht das Risiko der Anbieterabhängigkeit.

Auch muss sichergestellt werden, was mit den Daten der Kunden passiert wenn

diese die Mitgliedschaft in der Cloud kündigen. Es muss sichergestellt werden,

dass ein Cloud-Provider die effektive Vernichtung von Daten und Datenträgern

durchführt. Falls bei einem Cloud-Provider eine unerwartete Insolvenz eintritt,

muss sichergestellt werden, dass die Kundendaten wiederbeschafft werden können

und in welchem Format sich diese befinden werden. 56

55 Vgl. ENISA – Catteddu, Daniele: Security & Resilience in Governmental Clouds, S. 18-19

56 Vgl. Network World – Brodkin, Jon: Gartner: Seven cloud-computing security risks, S. 2


44 Kapitel 3: Security-Analyse von Cloud-Computing

Betroffene Schutzziele: Datenschutz, Vertraulichkeit

G13 Unzureichendes Sicherheits-Monitoring

Um die Sicherheit des Gesamtsystems innerhalb der Cloud zu gewährleisten,

sollte von dem Cloud-Provider eine Überwachung der Sicherheitsvorfälle durchgeführt

werden. In der Praxis wird aktuell ein Kunde nicht automatisch darauf

hingewiesen, dass gegenwärtig ein Sicherheitsproblem existiert. Gerade hier besteht

die Gefahr, dass sicherheitskritische Daten bei einem Angriff gestohlen werden

können. Es sollte dem Cloud-Kunden die Möglichkeit gegeben werden, über

ein bestehendes Sicherheitsproblem informiert zu werden, so dass er sich über die

Gefahr bewusst ist und selbst entscheiden kann ob er seine Systeme für die Dauer

des Vorfalls stoppen möchte. Dies hätte die Möglichkeit die Integrität der Daten

zu gewährleisten, sowie die Gefahr für eigene Systeme zu minimieren.

Falls ein Cloud-Kunde dennoch Opfer eines Angriffs geworden ist, benötigt er

für die strafrechtliche Verfolgung Beweise. Ein ganz wichtiges Werkzeug sind in

diesem Fall die Logdateien. Die Logdateien enthalten Informationen wie beispielsweise

IP-Adressen, Zugriffszeiten, Benutzernamen, Kennwörter, uvm. Mit

Hilfe dieser Informationen können Cyber-Verbrechen aufgeklärt werden. Durch

die Tatsache, dass beim Cloud-Computing die Kunden die Hardware gemeinsam

nutzen, erschwert sich die Erstellung der notwendigen Logdateien. Der Cloud-

Provider kann grundsätzlich nicht alle Informationen der Logdateien herausgeben,

da diese auch Informationen über andere Cloud-Kunden enthalten könnten. Würden

diese Informationen herausgegeben, wäre dies eine datenschutzrechtliche

Verletzung für Cloud-Kunden, welche möglicherweise nicht von dem Angriff

betroffen waren. Bei der Gefahr „unbekannte Sicherheitsmechanismen“ wird aufgezeigt,

dass Cloud-Provider absichtlich keine Information über ihre Sicherheitsmechanismen

herausgeben möchten, da dies einen Angriff unter Umständen erleichtern

könnte. Die Logdateien enthalten möglicherweise auch Informationen

über diese Sicherheitsmechanismen. Aufgrund dieser Umstände könnte eine Beweissicherung

bei einem Angriff unmöglich werden. In der Praxis werden bei

einem solchen Vorfall auch die Logdateien verändert, bzw. pseudonomisiert, damit

diese überhaupt herausgegeben werden können. Dieser Vorgang könnte entweder

dazu führen, dass wichtige Informationen vorenthalten werden oder wert-


Kapitel 3: Security-Analyse von Cloud-Computing 45

volle Zeit für die Ermittlung der Täter verloren geht, da erst auf die Pseudonomisierung

gewartet werden muss. 57

Betroffene Schutzziele: Verbindlichkeit, Verfügbarkeit, Datenschutz, Vertraulichkeit

G14 Unsichere API-Schnittstellen

Bei dem Einsatz von Virtualisierung wird ein Hypervisor verwendet, welcher

der Kernpunkt des gesamten Virtualisierungsystems ist. Er übernimmt die Verwaltung

der gesamten physischen Ressourcen und muss entsprechend geschützt

werden. Ziel ist es den Hypervisor abzuschotten, damit er nicht von außen verändert

werden kann. Bei Cloud-Computing wird nicht nur ein Hypervisor eingesetzt,

sondern auch APIs, um eine Schnittstelle zwischen dem Anwender und der Cloud

zu ermöglichen. Mit APIs werden unter anderem Verwaltungs- und Überwachungsaufgaben

ermöglicht. Eine erhöhte Gefahr entsteht dadurch, dass APIs Sicherheitslücken

aufweisen können, welche dann bei jedem Anwender vorhanden

wären. Die Sicherheit und Verfügbarkeit der Cloud-Dienste ist abhängig von der

Sicherheit der APIs. Es muss sichergestellt werden, dass die Authentifizierung,

Zugangskontrolle, Verschlüsselung und das Überwachen der Aktivitäten durch die

58 59

APIs gewährleistet wird und nicht umgangen werden kann.

Betroffene Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit, Zurechenbarkeit,

Verbindlichkeit, Datenschutz

3.2. Vergleich zwischen den Gefahren des Cloud-Computing und

den BSI Mindestsicherheitsanforderungen für Cloud-Computing

In diesem Kapitel wird ein Vergleich zwischen den identifizierten „Gefahren

des Cloud-Computing“ und dem „BSI-Mindestsicherheitsanforderungen an

Cloud-Computing-Anbieter“ durchgeführt. Hierfür wird zunächst bei jeder Gefahr

57 Vgl. Network World – Brodkin, Jon: Gartner: Seven cloud-computing security risks, S. 2

58 Vgl. Vaquero Luis et. al: Locking the sky: a survey on IaaS cloud security, S. 95

59 Vgl. Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud-

Computing V2.1, S. 68


46 Kapitel 3: Security-Analyse von Cloud-Computing

eine kurze Zusammenfassung der Gefahr aufgezeigt. Anschließend werden Auszüge

aus dem „BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter“ dargestellt und analysiert. Bei den Auszügen des BSI wird jeweils unterschieden

zwischen der Kategorie „Basic Schutz“ (B), „Vertraulichkeit hoch“

(Vt+) und „Verfügbarkeit hoch“ (Vf+)

G1 Unbekannte Richtlinien zur Mitarbeiterüberprüfung

Zusammenfassung der Gefahr

Bei der Hardwareabtretung an einen Cloud-Provider ist eine Vertrauensbasis

mit dem Cloud-Provider und dessen Mitarbeitern notwendig. Eine Gefahr besteht

darin, dass die Einstellung der Mitarbeiter des Cloud-Providers nicht persönlich

durchgeführt werden kann und somit die Richtlinien zur Mitarbeiterüberprüfung

unbekannt sind. Ein Administrator der Cloud hat Zugriff auf den Hypervisor, was

auch immer einen Zugriff auf laufende virtuelle Maschinen des Hostsystems bedeutet.

Dieser Zugang kann unter Umständen missbraucht werden. Das Personal

muss außerdem ausreichend ausgebildet werden, um die Stabilität des Systems zu

gewährleisten.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Anforderungen an das Personal B Vt+ Vf+

Vertrauenswürdiges Personal


Ausbildung der Mitarbeiter des Cloud-Anbieters (Regelmäßige ✓

Schulung)

Sensibilisierung der Mitarbeiter des Cloud-Anbieters für Informationssicherheit


und Datenschutz

Verpflichtung der Mitarbeiter auf Datenschutz, Sicherheitsmaßnahmen,

Vertraulichkeit der Kundendaten


Tabelle 3: BSI-Auszug „Anforderungen an das Personal“ 60

60 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 12


Kapitel 3: Security-Analyse von Cloud-Computing 47

ID- und Rechtemanagement B Vt+ Vf+

Sichere Identifikation der Cloud-Nutzer und Mitarbeiter des ✓

Cloud-Anbieters

Starke Authentisierung (z. B. Zweifaktor-Authentisierung) für ✓

Administratoren des Cloud-Anbieters

Zugriffskontrolllisten für Cloud-Nutzer und Mitarbeiter des ✓

Cloud-Anbieters

Regelmäßige Kontrolle und Aktualisierung der Zugriffskontrolllisten


Least Privilege Model (Nutzer bzw. Administratoren sollen nur ✓

die Rechte besitzen, die sie zur Erfüllung ihrer Aufgabe benötigen)

Vier-Augen-Prinzip für kritische Administrationstätigkeiten ✓ ✓

Starke Authentisierung (z. B. Zweifaktor-Authentisierung) für

Cloud-Nutzer



Angebot verschiedener Authentisierungsverfahren ✓ ✓

Tabelle 4: BSI-Auszug „ID- und Rechtemanagement“ 61

Die Tabelle 3 zeigt auf, welche Anforderungen das BSI an das Personal stellt,

damit das fehlerfreie Arbeiten der Administratoren verbessert wird. Hier wird

sichergestellt, dass Mitarbeiter regelmäßige Schulungen erhalten und für Informationssicherheit

und Datenschutz sensibilisiert werden. Des Weiteren werden Mitarbeiter

verpflichtet, den Datenschutz und die Sicherheitsmaßnahmen einzuhalten.

Um Nachweise für Administratortätigkeiten zu erstellen, wird in der Tabelle 4

definiert, dass Zugriffskontrolllisten für Mitarbeiter der Cloud-Provider erstellt

werden. Im Falle eines Missbrauchs von Administratorrechten kann hier festgestellt

werden, welcher Mitarbeiter des Cloud-Providers Zugang zu dem System

hatte. Zusätzlich werden die Rechte der Administratoren auf das nötigste beschränkt.

Administratoren erhalten nur die Rechte, die sie zur Erfüllung ihrer

Aufgaben benötigen. Bei der Kategorie „Vertraulichkeit hoch“ ist zusätzlich si-

61 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 10


48 Kapitel 3: Security-Analyse von Cloud-Computing

chergestellt, dass bei kritischen Administratortätigkeiten ein Vier-Augen-Prinzip

angewendet werden muss. Hierdurch kann das Risiko von Fehlern durch Administratoren

zusätzlich verringert werden.

G2 Mangelhafte Informationspolitik

Zusammenfassung der Gefahr

Ein Cloud-Kunde muss sich auf die Informationspolitik des Cloud-Providers

verlassen können. Es muss sichergestellt werden, dass vollständige Transparenz

bei Sicherheitsvorfällen existiert, auch wenn dies ein negatives Bild auf den

Cloud-Provider werfen kann.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Sicherheitsprüfung und –nachweis B Vt+ Vf+

Der Cloud-Anbieter muss dem Cloud-Nutzer regelmäßig berichten

über Sicherheitsmaßnahmen, Änderungen im IT-

Sicherheitsmanagement, über Sicherheitsvorfälle, über die Ergebnisse

durchgeführter IS-Revisionen und Penetrationstests.

Auch im Falle einer drohenden Insolvenz ist der Cloud-Nutzer

zu unterrichten.

Regelmäßige Penetrationstests

Regelmäßige Penetrationstests bei Subunternehmen




Regelmäßige und unabhängige Sicherheitsrevisionen ✓ ✓

Regelmäßige und unabhängige Sicherheitsrevisionen bei Subunternehmern

✓ ✓

Tabelle 5: BSI-Auszug „Sicherheitsprüfung und –nachweis“ 62

Um eine erfolgreiche Transparenz zwischen Cloud-Provider und Kunde zu erreichen,

schreibt das BSI in ihrer Tabelle 5 vor, dass ein Cloud-Kunde regelmäßig

über Sicherheitsmaßnahmen und Änderungen im IT-Sicherheitsmanagement in-

62 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 12


Kapitel 3: Security-Analyse von Cloud-Computing 49

formiert wird. Zusätzlich werden Penetrationstests verpflichtet, die die Sicherheitsmaßnahmen

des Cloud-Providers überprüfen. Diese Tests müssen regelmäßig

durchgeführt werden. Bei der Kategorie „Vertraulichkeit hoch“ ist zusätzlich festgelegt,

dass Sicherheitsrevisionen regelmäßig von unabhängigen Parteien durchgeführt

werden müssen.

G3 Gefahr durch Zentralisierung

Diese Gefahr ist eine generelle Gefahr durch den Einsatz von Cloud-

Computing. Die Gefahr könnte dadurch verringert werden, dass Cloud-Kunden

die Dienste auf unterschiedliche Rechenzentren des Cloud-Providers verteilen.

Dies kann jedoch nur durch den Kunden der Cloud durchgeführt werden und ist

somit nicht in den BSI Mindestsicherheitsanforderungen für Cloud-Computing

enthalten.

G4 Verlust der direkten Kontrolle

Zusammenfassung der Gefahr

Die Hardwareabtretung an einen Dienstleister bedeutet auch automatisch den

Verlust der direkten Kontrolle. Es muss sichergestellt werden, dass der Cloud-

Provider zeitnah Wartungsarbeiten durchführt und Ausfälle beseitigt. Sämtliche

Sicherheitsmechanismen und die eingesetzte Virtualisierungs-Software müssen

immer auf dem aktuellen Stand sein.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Ressourcen- und Patchmanagement B Vt+ Vf+

Konfigurationsmanagement


Sichere Provisionierung und Deprovisionierung von Ressourcen

Patch- und Änderungsmanagement (zügiges Einspielen von

Patches, Updates, Service Packs) sowie Release Management

Sicherstellung der Patchverträglichkeit auf Testssystem vor




50 Kapitel 3: Security-Analyse von Cloud-Computing

Einspielen in Wirkbetrieb

Tabelle 6: BSI-Auszug „Ressourcen- und Patchmanagement“ 63

In der Tabelle 6 wird von dem BSI definiert, dass der Cloud-Provider dazu

verpflichtet ist Patches, Updates und Service Packs auf dem System zügig einzuspielen.

Dies stellt sicher, dass aktuelle Sicherheitslücken schnellstmöglich geschlossen

werden und somit nicht mehr für Angriffe ausgenutzt werden können.

Des Weiteren wird definiert, dass die Verträglichkeit der Sicherheitspatches auf

einem Testsystem sichergestellt werden muss, bevor diese in Live-Systeme eingespielt

werden dürfen.

G5 Interne Angriffe

Zusammenfassung der Gefahr

Angriffe auf Kunden der Cloud könnten von innen durchgeführt werden. Hierfür

könnten Angreifer die Ressourcen der Cloud anmieten und interne Angriffe

durchführen und somit die externen Sicherheitsvorkehrungen umgehen.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Monitoring und Incident Management B Vt+ Vf+

24/7 Überwachung der Cloud (z. B. Verfügbarkeit der Services ✓

bzw. von Ressourcen)

Einbindung in die CERT-Strukturen und in das nationale IT- ✓

Krisenmanagement

Anbieter stellt sicher, dass 24/7 auf Angriffe, die aus der Cloud

heraus durchgeführt werden, reagiert werden kann

Anbieter stellt sicher, dass interne Angriffe von Cloud-Nutzern ✓

auf andere Cloud-Nutzer erkannt werden

Logdatenerfassung und Auswertung (z. B. Systemstatus, fehlgeschlagene

Authentisierungsversuche, etc.)


63 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 9


Kapitel 3: Security-Analyse von Cloud-Computing 51

24/7-erreichbares, handlungsfähiges Cloud-Management und ✓

Trouble-Shooting

Verfügbarkeit der Services überwachen und messen und Messergebnisse

den Kunden zur Verfügung


stellen

Tabelle 7: BSI-Auszug „Monitoring und Incident Management“ 64

Um sicherzustellen, dass interne Angriffe von Cloud-Kunden auf andere

Cloud-Kunden erkannt werden, wird in der Tabelle 7 definiert, dass der Cloud-

Provider ein solches Verhalten erkennen muss. Hierfür muss der Cloud-Provider

eine 24-stündige Überwachung gewährleisten. Zusätzlich ist eine Logdatenerfasssung

und Auswertung vorgeschrieben, damit ein Angriff entsprechend ausgewertet

werden kann.

G6 Unzureichende Abgrenzung der virtuellen Ressourcen

Zusammenfassung der Gefahr

Bei Cloud-Computing können eine Vielzahl von Cloud-Kunden die gemeinsamen

Ressourcen nutzen. Eine Gefahr besteht darin, dass die virtuelle Abgrenzung

der physischen Ressourcen unzureichend ist und somit Informationen von

anderen Cloud-Kunden abgegriffen werden können. Ressourcen, welche sehr

schnell ihren Besitzer wechseln, sind hierbei besonders gefährdet.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Datenspeicherung, Speichervirtualisierung

B Vt+ Vf+

und Datensicherheit

Datensicherheit im Lebenszyklus der Daten definieren und umsetzen


Sichere Isolierung der Kundendaten (virtuelle Speicherbereiche,


Tagging, etc.)

Regelmäßige Datensicherung und Möglichkeit der Datenwie- ✓

64 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 11


52 Kapitel 3: Security-Analyse von Cloud-Computing

derherstellung (außer nach Löschung) muss gesichert sein (z. B.

redundante Replikate, evtl. auch Kundentests)

Datenarchivierung nach einschlägigen Gesetzen bzw. Bestimmungen

Daten bei deren Vernichtung komplett und unwiderruflich löschen

(sicheres Löschen)

Option der verschlüsselten Speicherung sensitiver Daten unter

vollständiger Schlüsselkontrolle des Kunden (nur IaaS)

Tabelle 8: BSI-Auszug „Datenspeicherung, Speichervirtualisierung und Datensicherheit

“65




In der Tabelle 8 wird definiert, dass die sichere Isolierung der Kundendaten

gewährleistet werden muss. Wenn Ressourcen wieder zur Verfügung gestellt werden,

müssen diese komplett und unwiderruflich gelöscht werden, um ein sicheres

Löschen zu gewährleisten. Bei der Kategorie „Vertraulichkeit hoch“ wird zusätzlich

eine Option definiert, dass sensitive Daten verschlüsselt gespeichert werden

können. Hierbei findet die Schlüsselkontrolle vollständig bei dem Kunden statt,

sodass der Cloud-Provider die sensitiven Daten nicht entschlüsseln kann.

Bei den BSI Mindestsicherheitsanforderungen für Cloud-Computing wird allgemein

von Ressourcen und Kundendaten gesprochen. Hierbei findet keine Unterscheidung

zwischen den unterschiedlichen Ressourcen statt. Bei Virtualisierungsprojekten

ist bei der Zuteilung von Festplattenspeicher die Gefahr von Altbeständen

bekannt. Durch den Einsatz von Cloud-Computing ist die Gefahr von

Altbeständen bei Ressourcen welche schnell zugeteilt werden müssen neu. Arbeitsspeicher

wechselt bei Cloud-Computing schnell den Besitzer. Dadurch muss

sichergestellt werden, dass bei der schnellen Zuteilung ebenfalls eine sichere Löschung

durchgeführt wird und keine Altbestände vorhanden sind. Hierfür könnten

bei dem BSI Mindestsicherheitsanforderungen für Cloud-Computing Katalog

Tests vorgeschrieben werden, welche die sichere Isolierung der Ressourcen bestätigt.

65 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 9


Kapitel 3: Security-Analyse von Cloud-Computing 53

G7 Missbrauch von Cloud-Ressourcen

Zusammenfassung der Gefahr

Aufgrund der Tatsache, dass Ressourcen der Cloud sehr schnell zur Verfügung

gestellt werden können, besteht hier eine Gefahr dass diese Ressourcen missbraucht

werden können. Ein Cloud-Provider kann aufgrund der Größe der Cloud

und der Vielzahl von Kunden schnell den Überblick darüber verlieren, welche

Dienste innerhalb der Cloud ausgeführt werden.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Monitoring und Incident Management B Vt+ Vf+

24/7 Überwachung der Cloud (z. B. Verfügbarkeit der Services ✓

bzw. von Ressourcen)

Einbindung in die CERT-Strukturen und in das nationale IT- ✓

Krisenmanagement

Anbieter stellt sicher, dass 24/7 auf Angriffe, die aus der Cloud

heraus durchgeführt werden, reagiert werden kann

Anbieter stellt sicher, dass interne Angriffe von Cloud-Nutzern ✓

auf andere Cloud-Nutzer erkannt werden

Logdatenerfassung und Auswertung (z. B. Systemstatus, fehlgeschlagene


Authentisierungsversuche, etc.)

24/7-erreichbares, handlungsfähiges Cloud-Management und ✓

Trouble-Shooting

Verfügbarkeit der Services überwachen und messen und Messergebnisse

den Kunden zur Verfügung stellen


Tabelle 9: BSI-Auszug „Monitoring und Incident Management“ 66

Damit der Missbrauch von Cloud Ressourcen verhindert wird, hat das BSI in

der Tabelle 9 definiert, dass 24 Stunden am Tag auf Angriffe, die aus der Cloud

heraus durchgeführt werden, reagiert werden kann. Es wurde nicht spezifiziert,

wie diese Angriffe erkannt werden sollen. Es ist somit nicht ersichtlich, ob diese

66 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 11


54 Kapitel 3: Security-Analyse von Cloud-Computing

Angriffe von dem Cloud-Provider erkannt werden müssen oder ob dieser auf externe

Hinweise reagieren soll. Das Kapitel „4.2.1. Gefahr durch Missbrauch von

Cloud-Ressourcen“ behandelt ein Konzept, durch welches ein automatisches System

anomales Verhalten innerhalb der Cloud erkennen und den Cloud-Provider

darüber informieren kann.

G8 Unbekannte Laufzeitumgebung der virtuellen Maschinen

Zusammenfassung der Gefahr

Durch die Netzanbindung bei Cloud-Computing ist es möglich, virtuelle Maschinen

in unterschiedlichen Rechenzentren zu migrieren. Ein Cloud-Kunde kann

somit nicht sicher sagen, in welcher Laufzeitumgebung seine virtuelle Maschine

sich befindet. Eine virtuelle Maschine könnte an einen Drittanbieter ausgelagert

werden, welcher unbekannte oder gar keine Sicherheitskriterien erfüllt oder anderen

länderspezifischen Datenschutzgesetzen unterstellt ist.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Transparenz B Vt+ Vf+

Offenlegung der Standorte des Cloud-Anbieters (Land, Region)

Offenlegung der Subunternehmer des Cloud-Anbieters

Transparenz, welche Eingriffe der Cloud-Anbieter in Daten und

Verfahren der Kunden vornehmen darf

Regelmäßige Unterrichtung über Änderungen (z. B. neue oder

abgekündigte Funktionen, neue Subunternehmer, andere Punkte,

die für das SLA relevant sind)

Transparenz, welche Software durch den Cloud-Anbieter auf

Seiten des Kunden installiert wird sowie über die daraus resultierenden

Sicherheitserfordernisse /-risiken

Transparenz über staatliche Eingriffs- und Einsichtrechte, über

gerichtlich festlegbare Einsichtrechte Dritter und über Prüfpflichten

zu gespeicherten Daten durch den Cloud-Anbieter an

allen potenziellen Standorten








Kapitel 3: Security-Analyse von Cloud-Computing 55

Darlegung der Rechts- und Besitzverhältnisse des Cloud-

✓ ✓

Anbieters sowie der Entscheidungsbefugnisse

Erlaubnisvorbehalt des Kunden vor Eingriffen auf seinen Client

gegenüber dem Cloud-Anbieter

✓ ✓

Tabelle 10: BSI-Auszug „Transparenz“ 67

In der Tabelle 10 wird von dem BSI definiert, dass der Cloud-Provider seine

Standorte gegenüber dem Cloud-Kunden offenlegen muss. Hierfür muss das Land

und die Region definiert werden. Darüber hinaus müssen auch die Subunternehmer

des Cloud-Providers offengelegt werden. Falls sich hierbei Änderung ergeben,

so muss der Cloud-Kunde regelmäßig darüber unterrichtet werden. Bei der

Kategorie „Vertraulichkeit hoch“ wird definiert, dass staatliche Eingriffe beziehungsweise

gerichtlich festlegbare Einsichtsrechte Dritter gegenüber dem Cloud-

Kunden offengelegt werden müssen.

In den BSI Mindestsicherheitsanforderungen für Cloud-Computing werden

keine Möglichkeiten definiert mit welcher ein Cloud-Kunde überprüfen kann, ob

sich die Laufzeitumgebung der virtuellen Maschinen verändert hat. Das Kapitel

„4.2.2. Gefahr durch unbekannte Laufzeitumgebungen der virtuellen Maschinen“

beschreibt eine Architektur mit welcher es möglich wird, unterschiedliche Laufzeitumgebungen

zu erkennen und unbekannte Laufzeitumgebungen zu blockieren.

G9 Unbekannter Speicherort der Daten

Diese Gefahr unterscheidet sich zu der Gefahr „Unbekannte Laufzeitumgebung

der virtuellen Maschinen“ dahingehend, dass es sowohl unbekannte Laufzeitumgebungen

als auch unbekannte Speicherorte gibt. Die Analyse der BSI-

Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter ist der Analyse

der Gefahr „Unbekannte Laufzeitumgebung der virtuellen Maschinen“ gleichgestellt.

G10 Physischer Zugang zu Rechenzentren wird nicht gewährt

Zusammenfassung der Gefahr

67 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 13


56 Kapitel 3: Security-Analyse von Cloud-Computing

Bei der Erteilung großer IT-Outsourcing-Projekte bieten Dienstleister oftmals

eine Besichtigung des Rechenzentrums an. So kann sich der Kunde über die physischen

Sicherheitsmaßnahmen, wie z.B. Videoüberwachung, Ausweiskontrolle

und Protokollerstellung, selbst ein Bild machen. Bislang bieten Cloud-Provider

den Cloud-Kunden keinen physischen Zugang zu den Rechenzentren, weshalb

diese Sicherheitsmaßnahmen nicht überprüft werden können.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Rechenzentrumsicherheit B Vt+ Vf+

Redundante Auslegung aller wichtigen Versorgungs-


Komponenten (Strom, Klimatisierung der RZ, Internetanbindung,

etc.)

24/7 Überwachung des Zugangs, inkl. Videoüberwachungssysteme,


Brandmelder, Bewegungssensoren, Sicherheitspersonal,

Alarmsysteme, etc.

Kontrollierte Zugangskontrolle für das Rechenzentrum ✓

Zwei redundante Rechenzentren, die mindestens so weit von

einander entfernt sind, dass eine Katastrophe (z. B. Explosion,

Feuer) in einem Rechenzentrum, das andere nicht beeinträchtigt.


Tabelle 11: BSI-Auszug „Rechenzentrumsicherheit“ 68

In der Tabelle 11 werden die Sicherheitsmechanismen für das Rechenzentrum

definiert. Eine lückenlose Überwachung des Zugangs mit einer Videoüberwachung,

Sicherheitspersonal und einem Alarmsystem garantiert einen Schutz vor

unbefugten Personen. Zusätzlich sind Brandmelder installiert, sodass Kabelbrände

sofort entdeckt werden können. Bei der Kategorie „Verfügbarkeit hoch“ wird zusätzlich

definiert, dass zwei redundante Rechenzentren betrieben werden müssen,

welche mindestens so weit voneinander entfernt sind, dass eine Katastrophe wie

68 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 7


Kapitel 3: Security-Analyse von Cloud-Computing 57

zum Beispiel eine Explosion oder Feuer in einem Rechenzentrum das andere Rechenzentrum

nicht beeinflussen kann.

Das BSI definiert jedoch keine Möglichkeiten, dass diese physischen Sicherheitsmaßnahmen

von den Cloud-Kunden überprüft werden können. Hierfür könnte

definiert werden, dass das Rechenzentrum entweder von den Cloud-Kunden

persönlich besichtigt werden kann oder dass die physischen Sicherheitsmaßnahmen

des Rechenzentrums von unabhängigen Parteien überprüft werden können.

G11 Unbekannte Sicherheitsmechanismen

Zusammenfassung der Gefahr

Bei dem Einsatz von Cloud-Computing sind die eingesetzten Sicherheitsmaßnahmen

unbekannt. Cloud-Provider legen absichtlich nicht ihre Sicherheitsmaßnahmen

offen, um sich und ihre Kunden vor gezielten Angriffen zu schützen.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Sicherheitsprüfung und –nachweis B Vt+ Vf+

Der Cloud-Anbieter muss dem Cloud-Nutzer regelmäßig berichten


über Sicherheitsmaßnahmen, Änderungen im IT-

Sicherheitsmanagement, über Sicherheitsvorfälle, über die Ergebnisse

durchgeführter IS-Revisionen und Penetrationstests.

Auch im Falle einer drohenden Insolvenz ist der Cloud-Nutzer

zu unterrichten.

Regelmäßige Penetrationstests


Regelmäßige Penetrationstests bei Subunternehmen


Regelmäßige und unabhängige Sicherheitsrevisionen ✓ ✓

Regelmäßige und unabhängige Sicherheitsrevisionen bei Subunternehmern

✓ ✓

Tabelle 12: BSI-Auszug „Sicherheitsprüfung und –nachweis“ 69

69 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 12


58 Kapitel 3: Security-Analyse von Cloud-Computing

Tabelle 12 zeigt auf, dass Cloud-Provider die Cloud-Kunden darüber in

Kenntnis setzen müssen wenn Änderungen der Sicherheitsmaßnahmen oder Änderungen

im IT-Sicherheitsmanagement durchgeführt werden. Ebenfalls müssen

regelmäßige Penetrationstests bei dem Cloud-Provider und seinen Subunternehmern

durchgeführt werden. Die Ergebnisse dieser Tests müssen dem Cloud-

Kunden zur Verfügung gestellt werden. Bei der Kategorie „Vertraulichkeit hoch“

müssen zusätzlich regelmäßige unabhängige Sicherheitsrevision bei dem Cloud-

Provider und seinen Subunternehmern durchgeführt werden.

G12 Fehlende Interoperabilität & Portabilität und fehlende Transparenz

über Datenverbleib bei Providerkündigung / -wechsel

Zusammenfassung der Gefahr

Durch den Einsatz von Cloud-Computing ist ein Cloud-Kunde automatisch an

die providerspezifischen Monitoringschnittstellen gebunden. Da Cloud-Provider

unterschiedliche Schnittstellen für den Einsatz von Cloud-Computing verwenden

sind bei einem Wechsel diese Schnittstellen inkompatible zueinander. Auch muss

sichergestellt werden, was mit den Daten der Kunden passiert, wenn diese die

Mitgliedschaft in der Cloud kündigen. Es muss sichergestellt werden, dass ein

Cloud-Provider die effektive Vernichtung von Daten und Datenträgern durchführt.

Falls bei einem Cloud-Provider eine unerwartete Insolvenz eintritt, muss sichergestellt

werden, dass die Kundendaten wiederbeschafft werden können und in welchem

Format sich diese befinden werden.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Portabilität von Daten und Anwendungen B Vt+ Vf+

Import und Export der Daten in einem geeigneten Format

Anwendungen müssen plattformunabhängig sein (nur SaaS)



Tabelle 13: BSI-Auszug „Portabilität von Daten und Anwendungen“ 70

70 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 14


Kapitel 3: Security-Analyse von Cloud-Computing 59

Organisatorische Anforderungen B Vt+ Vf+

Definierte Sicherheitsleistungen durch Security-SLA oder im

SLA deutlich hervorgehoben

Einsicht in Security-SLA bzw. SLA von Subunternehmern



Rahmenbedingungen zur Gültigkeit des SLAs aufführen (z. B. ✓

keine Verpflichtung zur Leistungserbringung aufgrund Höherer

Gewalt)

Sicherstellung des Betriebs oder der Bereitstellung der Daten

im Falle einer Insolvenz des Cloud-Anbieters

✓ ✓

Tabelle 14: BSI-Auszug „Organisatorische Anforderungen“ 71

Interoperabilität B Vt+ Vf+

Standardisierte oder offen gelegte Schnittstellen (API und Protokolle)


Tabelle 15: BSI-Auszug „Interoperabilität“ 72

Tabelle 13 fordert, dass der Import und Export der Daten in einem geeigneten

Format sichergestellt wird. Anwendungen bei einem SaaS-Modell müssen hierfür

ebenfalls plattformunabhängig sein. Hierdurch wird die Portabilität von Daten und

Anwendungen gewährleistet. In Tabelle 14 wird sichergestellt, dass bei der Kategorie

„Verfügbarkeit hoch“ die Bereitstellung der Daten im Falle einer Insolvenz

des Cloud-Providers weiterhin gegeben ist. Zu der Erhöhung der Interoperabilität

wird in Tabelle 15 definiert, dass standardisierte oder offen gelegte Schnittstellen

verwendet werden müssen.

G13 Unzureichendes Sicherheits-Monitoring

Zusammenfassung der Gefahr

Um die Sicherheit des Gesamtsystems innerhalb der Cloud zu gewährleisten

sollte von dem Cloud-Provider eine Überwachung der Sicherheitsvorfälle durchgeführt

werden. In der Praxis wird aktuell ein Kunde nicht automatisch darauf

71 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 13

72 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 15


60 Kapitel 3: Security-Analyse von Cloud-Computing

hingewiesen, dass gegenwärtig ein Sicherheitsproblem existiert. Es sollte dem

Cloud-Kunden die Möglichkeit gegeben werden, über ein bestehendes Sicherheitsproblem

informiert zu werden, so dass er sich über die Gefahr bewusst ist

und selbst entscheiden kann, ob er seine Systeme für die Dauer des Vorfalls stoppen

möchte.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Netzsicherheit B Vt+ Vf+

Sicherheitsmaßnahmen gegen Malware (Virenschutz, Trojaner- ✓

Detektion, SPAM-Schutz, etc.)

Sicherheitsmaßnahmen gegen netzbasierte Angriffe (IPS/IDS- ✓

Systeme, Firewall, etc.)

DDoS-Mitigation (Abwehr von DDoS-Angriffen)


Fernadministration durch einen sicheren Kommunikationskanal ✓

(SSH, SSL, IPSec, VPN, etc.)

Gewährleistung der hohen Verfügbarkeit bei den Verbindungen

zwischen den Rechenzentren der Cloud und zum Nutzer; physisch

und logisch redundante Anbindung der Cloud-Standorte

und der Nutzer


Tabelle 16: BSI-Auszug „Netzsicherheit“ 73

In Tabelle 16 wird definiert, dass Sicherheitsmaßnahmen gegen netzbasierte

Angriffe verpflichtend sind. Diese Sicherheitsmaßnahmen beinhalten unter anderem

ein Intrusion Detection System (IDS), welches das Netzwerk und die Systeme

überwacht. Hierbei können Angriffsmuster erkannt und eine entsprechende Warnung

herausgegeben werden. In Tabelle 16 ist nicht definiert, dass diese Warnungen

an den Cloud-Kunden weitergeleitet werden müssen. Bei der Kategorie „Vertraulichkeit

hoch“ wäre es möglich zu verpflichten, dass ein erkannter Angriff

automatisch an einen Cloud-Kunden weitergeleitet werden muss. Der Cloud-

Kunde kann dann entscheiden, ob er seine Systeme weiterhin ausführen möchte.

73 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 11


Kapitel 3: Security-Analyse von Cloud-Computing 61

In der finalen Fassung des „Eckpunktepapier – Sicherheitsempfehlungen für

Cloud-Computing Anbieter“ wurde dies berücksichtigt indem die folgende Textpassage

hinzugefügt wurde: „Mitteilungspflichten des CSP gegenüber dem Kunden

über Sicherheitsvorfälle oder Hinweise auf Sicherheitsvorfälle, die den Kunden

betreffen könnten“ 74

G14 Unsichere API-Schnittstellen

Zusammenfassung der Gefahr

Mit APIs werden unter anderem Verwaltungs- und Überwachungsaufgaben

ermöglicht. Eine erhöhte Gefahr entsteht dadurch, dass APIs Sicherheitslücken

aufweisen können, welche dann bei jedem Anwender vorhanden wären. Die Sicherheit

und Verfügbarkeit der Cloud-Dienste ist abhängig von der Sicherheit der

APIs.

Analyse der BSI-Mindestsicherheitsanforderungen an Cloud-Computing-

Anbieter

Interoperabilität B Vt+ Vf+

Standardisierte oder offen gelegte Schnittstellen (API und Protokolle)


Tabelle 17: BSI-Auszug „Interoperabilität“ 75

Das BSI definiert in Tabelle 17, dass standardisierte oder offen gelegte APIs

und Protokolle verwendet werden müssen. Somit hat ein Cloud-Kunde die Möglichkeit,

die Sicherheit der APIs selbst zu überprüfen oder von unabhängigen Parteien

überprüfen zu lassen.

74 BSI: Eckpunktepapier „Sicherheitsempfehlungen für Cloud-Computing Anbieter“ – finale

Fassung, S. 44

75 BSI: BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf, S. 15


Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing 63

4. Architektur zur Lösung der Gefahren des Cloud-

Computing

4.1. SMMaaS Architektur

Die Security Management und Monitoring as a Service (SMMaaS)-

Architektur ist eine Entwicklung des Cloud Research Lab der Hochschule Furtwangen

University. Sie ist Teil des CloudDataSec-Projektes, welches das Ziel

verfolgt, die Sicherheit und das Vertrauen in Cloud-Computing zu steigern. Diese

Ziele sollen hierbei mit den europäischen und nationalen Datenschutzgesetzen

vereinbar sein. Die Zielgruppe des gesamten Projekts sind die kleinen und mittelständischen

Unternehmen. Die SMMaaS-Architektur wurde erstmals in einem

Paper von Dölitzscher et al. 76 noch unter der Abkürzung „SMaaS“ vorgestellt. 77

4.1.1. Aufbau der SMMaaS Architektur

Abbildung 11: CloudDataSec-Schichtenarchitektur 78

Abbildung 11 zeigt die Schichtenarchitektur des CloudDataSec. Die Schichten

sind von oben „Benutzer nahe“ nach unten „Technik nahe“ aufgebaut. Die oberste

76 Vgl. Dölitzscher, Frank et. al.: Designing Cloud Services Adhering to Government Privacy

Laws

77 Vgl. Thomas, Marc et. al.: Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud-

Computing, S. 35

78 Thomas, Marc et. al.: Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud-

Computing, S. 35


64 Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing

Schicht „Risk Analysis“ kann nicht technisch gelöst werden und benötigt das

Management des Kunden beziehungsweise des Cloud-Providers. Bei der Schicht

Security Guidelines“ wird die Einhaltung von gesetzlichen Bestimmungen sichergestellt.

Hierbei werden diese Bestimmungen in Regelwerken definiert. Bei

der Schicht „QoS Monitoring“ wird sichergestellt, dass vertragliche Regelungen,

welche in Service Level Agreements (SLA)s definiert wurden, eingehalten werden.

Hierzu muss diese Schicht auf viele Informationen wie beispielsweise Logging-Daten

Zugriff haben. Diese Informationen ermöglichen es, zu verifizieren

dass die vertraglichen Regelungen erfüllt wurden. Die drei letzten Schichten „Data

Encryption“, „Logging“ und „Encrypted Communication“ sind für die Daten-

bzw. Kommunikationssicherheit verantwortlich. Die Datensicherheit wird

dabei durch Verschlüsselung der Daten sowie das Protokollieren der Datenzugriffe

sichergestellt. Dies wird ermöglicht durch Techniken der Kommunikationsverschlüsselung,

wie beispielsweise SSL und VPN. 79

4.1.2. Module der SMMaaS Architektur

Abbildung 12: Kernkomponenten des CloudDataSec

Abbildung 12 zeigt die Kernkomponenten des CloudDataSec-Projektes. Es

handelt sich hierbei um einen Architekturentwurf, welcher als Vorlage zur Implementierung

dient. Die SMMaaS-Architektur besteht aus folgenden Modulen: 80

79 Thomas, Marc et. al.: Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud-

Computing, S. 35-36

80 Vgl. Thomas, Marc et. al.: Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud-

Computing, S. 36-37


Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing 65










Crypto Modul: Ist für das Verschlüsseln der Daten zuständig, wenn dies aktiviert

wird.

Customer PKI: Das Modul sorgt für die Benutzerauthentifizierung und die

Datensegmentierung.

Data Leakage Prevention Modul: Das Modul überwacht Datenströme.

SLA Monitoring: Durch dieses Modul werden QoS Attribute sichergestellt.

Policy Modul: Ist für das Konfigurieren des Monitoring, den Datenzugriff

und den Zustand der Systeme zuständig. Des Weiteren generiert es Berichte

über den Status der durch den Kunden genutzten Umgebung.

Logging: Das Modul stellt ein lückenloses Logging von Ereignissen und Datenzugriffen

sicher. Es beinhaltet einen Timestamp Service um die Logeinträge

fälschungssicher und den Gesetzen entsprechend zu erstellen.

Intrusion Detection Modul: Ist für das Erfassen unberechtigter Zugriffe zuständig

und arbeitet eng mit dem Data Leakage Prevention Modul zusammen.

Management: Dieses Modul ist die einzige direkte Schnittstelle zu dem

Kunden. Ein Kunde kann über dieses Modul die anderen Module konfigurieren

und Funktionen der andern Module nutzen. Des Weiteren bekommt er

mittels des Management Moduls alle Reports sowie Ereignisse von der kompletten

SMMaaS Umgebung übersichtlich dargestellt. Das Management Modul

kann dabei auch komplette Prozessabläufe koordinieren und überwachen,

wie beispielsweise die Initialisierung einer SMMaaS-Umgebung für einen

Kunden.

Rollen- und Rechtemanagement: Dieses Modul ist für die Rechteverwaltung

verantwortlich. Hierbei hat ein Kunde die Möglichkeit, einem Administrator

die Verwaltung von einer bestimmten Anzahl von Modulen zu ermöglichen.

Hierdurch wird verhindert, dass ein Administrator Zugriff zu Bereichen

erhält, in denen er sie nicht unbedingt braucht.

4.2. Erweiterung der SMMaaS Architektur zur Lösung der Gefahren

des Cloud-Computing

In diesem Kapitel wird eine Erweiterung der SMMaaS Architektur aufgezeigt,

um die Gefahren „Gefahr durch Missbrauch von Cloud-Ressourcen“ und „Gefahr


66 Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing

durch unbekannte Laufzeitumgebungen der virtuellen Maschinen“ zu lösen. Hierfür

wird zunächst eine kurze Zusammenfassung der Gefahr dargestellt. Anschließend

wird das Konzept zur Lösung der Gefahren erläutert.

4.2.1. Gefahr durch Missbrauch von Cloud-Ressourcen

Zusammenfassung der Gefahr

Ressourcen in einer Cloud können sehr schnell zur Verfügung gestellt werden.

Durch die Größe der Cloud wird es für Cloud-Provider schwierig, zu überblicken

welche Dienste zurzeit ausgeführt werden. Es besteht die Gefahr, dass die Cloud

Ressourcen für illegale Dienste missbraucht werden können.

Aufbau und Funktionalität eines trust-based mandatory access control-

System

Ein trust-based mandatory access control-System bezeichnet ein Konzept, dass

anormales Verhalten in einer virtuellen Maschine erkennt. Um dies zu erreichen,

wird zunächst einmal definiert was das normale Verhalten einer virtuellen Maschine

ist. Hierzu ist es notwendig, dass die Dienste der virtuellen Maschine lückenlos

definiert werden. Die Dienste, welche auf einer virtuellen Maschine laufen,

können sich über die Zeit verändern. Jede Änderung muss dem Cloud-

Provider mitgeteilt werden, damit das System keine Falschmeldungen erzeugt.

Wenn eine virtuelle Maschine unerwartet ein nicht festgelegtes Verhalten aufweist,

so kann der Cloud-Provider dies automatisch erkennen und reagieren. Welche

Reaktionen bei einem anormalen Verhalten durchgeführt werden, kann bei

dem SLA mit dem Cloud-Kunden definiert werden.

4.2.2. Gefahr durch unbekannte Laufzeitumgebungen der virtuellen Maschinen

Zusammenfassung der Gefahr

Durch die Netzanbindung bei Cloud-Computing ist es möglich, virtuelle Maschinen

in unterschiedlichen Rechenzentren zu migrieren. Ein Cloud-Kunde kann

nicht persönlich überprüfen, wo seine virtuellen Maschinen ausgeführt werden.

Eine virtuelle Maschine könnte an einen Drittanbieter ausgelagert werden, welcher

unbekannte oder gar keine Sicherheitskriterien erfüllt oder anderen länder-


Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing 67

spezifischen Datenschutzgesetzen unterstellt ist. Die Dienste innerhalb der virtuellen

Maschine laufen während diesem Migrationsprozess ungestört weiter und somit

ist nicht zu erkennen, dass die virtuelle Maschine das Rechenzentrum verlassen

hat.

Aufbau und Funktionalität eines vTPM

In dem Paper „vTPM: Virtualizing the Trusted Platform Module“ 81 wird ein

Design und die Implementation von einer Architektur vorgestellt, welche virtuelle

Maschinen mit einem einzelnen Hardware Trusted Platform Module verbindet. Es

wird dadurch erreicht, dass ein Hardware TPM zu einem vTPM virtualisiert wird.

Dies ermöglicht es, dass die Hardware TPM Funktionen, wie beispielsweise der

Generierung des Endorsement Key oder der Generierung des Attestation Identity

Key, der virtuellen Maschine zur Verfügung gestellt werden. Innerhalb der virtuellen

Maschine werden diese Fähigkeiten von dem Betriebssystem und den darin

laufenden Anwendungen aufgegriffen. Ziel der Architektur ist es, die Softwareintegrität

innerhalb virtualisierten Umgebungen genauso zu beglaubigen, wie dies

auch mit Hardware TPMs erreicht werden kann. Dies wird zum Beispiel dadurch

erreicht, dass durch das TPM eine digitale Signatur mit kryptographischen Hashwerten

von Software Komponenten erstellt wird.

Für jede virtuelle Maschine wird eine vTPM Instanz erstellt und zugeteilt.

Diese Instanzen emulieren die Funktionen der Hardware TPMs vollständig. Jedoch

gibt es hierbei neue Anforderungen, welche bei den Hardware TPMs bisher

nicht vorhanden waren. Durch den Einsatz von Virtualisierung werden Techniken

eingesetzt, welche mit den Hardware TPMs nicht kompatibel sind. Eine Hardware

TPM funktioniert für genau eine Hardwareplattform. Wenn beispielsweise ein

physikalischer Server eine Anwendung, welche die Funktionalität von TPM benötigt,

ausführt, dann werden die TPM Funktionalitäten beim Hochfahren des Servers

der Anwendung zur Verfügung gestellt. Wenn die Anwendungen auf einem

anderen Server ausgeführt wird, dann wird diese vorher beendet und auf dem neuen

Server gestartet. Ab diesem Punkt beginnt sie die Informationen des TPMs

erneut zu laden und bindet anschließende die Funktionalitäten erneut ein. Bei ei-

81 IBM Research Center – Berger, Stefan et. al.: vTPM: Virtualizing the Trusted Platform

Module


68 Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing

ner virtualisierten Umgebung ist es jedoch möglich, im laufenden Betrieb eine

virtuelle Maschine auf eine andere Plattform zu migrieren. Hierfür wird weder das

Betriebssystem neu gestartet, noch deren Anwendungen. Aus diesem Grund kann

die Anwendung, welche TPM-Funktionalitäten einbindet, nicht mehr normal weitergeführt

werden, da die Hostplattform durch dem neuen TPM neue Schlüssel

generiert. Bei der Implementierung des vTPM wurde diese neue Anforderung

berücksichtigt. Nachdem die virtuelle Maschine auf eine neue Plattform migriert

wurde, muss die virtuelle TPM Instanz erneut die Vertrauenskette auf der neuen

Plattform herstellen, indem es Kontakt mit dem vTPM Manager aufnimmt. 82

Abbildung 13: vTPM Architektur 83

Abbildung 13 zeigt verschiedene virtuelle Maschinen, welche Befehle an das

TPM übermitteln. Eine Problematik besteht darin festzustellen, von welcher virtu-

82 Vgl. IBM Research Center – Berger, Stefan et. al.: vTPM: Virtualizing the Trusted Platform

Module

83 IBM Research Center – Berger, Stefan et. al.: vTPM: Virtualizing the Trusted Platform

Module, S. 5


Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing 69

ellen Maschine die Befehle übermittelt werden, da dies anhand des Inhaltes nicht

erkannt werden kann. Um eine Antwort zu senden ist es notwendig zu wissen wer

der Absender des Befehls war. Um dieses Problem zu lösen wurde die Architektur

folgendermaßen aufgebaut: Die virtuellen Maschinen kommunizieren mit dem

vTPM über einen device-Driver. Ein client-side Driver wird innerhalb jeder virtuellen

Maschine ausgeführt, welche Zugang zu der virtuellen TPM Instanz haben

möchte. Der server-side driver wird innerhalb einer zusätzlichen virtuellen Maschine

ausgeführt. Diese virtuelle Maschine wird speziell dafür verwendet den

vTPM darin auszuführen. In Abbildung 13 ist zu erkennen, wie die vTPM Instanzen

innerhalb dieser vTPM Server-VM ausgeführt werden. Die Verwaltung der

Instanzen wird mit dem vTPM Manager durchgeführt. Dieser ist dafür zuständig

die Instanzen zu erstellen oder zu löschen. Hieraus entsteht eine 1:N-Beziehung

mit der vTPM Server-VM und allen virtuellen Maschinen, welche die Funktionen

der vTPM implementieren möchten. Abbildung 13 zeigt ebenfalls die Kommunikation

mit dem Hardware TPM. Diese Kommunikation wird nur der vTPM Server-VM,

beziehungsweise deren vTPM Manager, gestattet. Für jede virtuelle Maschine

wird eine dazugehörige vTPM Instanz innerhalb der vTPM Server-VM

erstellt. Die Kommunikation zwischen den vTPM Instanzen und den dazugehörigen

virtuellen Maschinen erfolgt über den Hypervisor. Für die Koordination der

Kommunikation wird für jede vTPM Instanz ein Identifikator zugeteilt. Der client-side

Driver erstellt einen eindeutigen Identifikator und übermittelt diesen bei

jeder Kommunikation an den vTPM Manager. Der vTPM Manager ordnet diesen

Identifikator der jeweiligen vTPM Instanz zu. Jedes Nachrichtenpaket, welches

die vTPM Befehle transportiert, bekommt diesen 4-byte Identifikator angehängt.

Dadurch wird es möglich die Kommunikation genau zuzuordnen. Abbildung 13

zeigt die Kommunikation zwischen vTPM und den virtuellen Maschinen über den

Hypervisor. 84

Um das vTPM erfolgreich umzusetzen, wurden die bereits vorhandenen Befehle

aus dem TPM um die folgenden Befehlen erweitert: 85

84 Vgl. IBM Research Center – Berger, Stefan et. al.: vTPM: Virtualizing the Trusted Platform

Module, S. 4-5

85 Vgl. IBM Research Center – Berger, Stefan et. al.: vTPM: Virtualizing the Trusted Platform

Module, S. 6


70 Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing

Virtual TPM Management commands

CreateInstance

DeleteInstance

SetupInstance

Virtual TPM Migration commands

GetInstanceKey / SetInstanceKey

GetInstanceData / SetInstanceData

Virtual TPM Utility commands

TransportInstance

LockInstance / UnlockInstance

ReportEnvironment

Die Virtual TPM Management Befehle sind für den Lebenszyklus der vTPM

Instanzen verantwortlich und stellen Funktionen für deren Erstellung (CreateInstance)

und Löschung (DeleteInstance) bereit. Der Befehl SetupInstance bereitet

eine vTPM Instanz für die sofortige Verwendung mit der dazugehörigen virtuellen

Maschine vor. Die Virtual TPM Migration Befehle ermöglichen die Migration

von vTPM Instanzen auf eine neue Plattform.

Abbildung 14: Virtual TPM Migrations-Protokoll


Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing 71

Abbildung 14 zeigt den Migrationsprozess eines vTPMs. Das gesamte Vorgehen

findet in den folgenden 10 Schritten statt: 86

1. Es wird eine vTPM Instanz auf der Zielplattform durch den Befehl „CreateInstance“

erstellt.

2. Von der neuen vTPM Instanz der Zielplattform wird ein Identifikator erstellt.

3. Der Identifikator wird auf die Quellplattform übermittelt. Vor der Übertragung

wird diese mit dem Public-Key der Quellplattform verschlüsselt, damit

nur die Quellplattform den Identifikator entschlüsseln kann.

4. Auf der Quellplattform wird die vTPM Instanz durch den Befehl „LockInstance“

gesperrt. Dies ermöglicht es, dass das vTPM nur auf der dazugehörigen

Zielplattform weiter ausgeführt werden kann. Somit wird verhindert,

dass das vTPM dupliziert und auf mehr als einer Zielplattform ausgeführt

wird.

5. Mit Hilfe des Befehls „GetInstanceKey“ wird von der Quell-vTPM Instanz

ein symmetrischer Schlüssel erstellt.

6. Mit diesem symmetrischen Schlüssel werden alle Inhalte der Quell-vTPM

verschlüsselt und anschließend wird die vTPM Instanz mit dem Befehl „DeleteInstance“

gelöscht.

7. Nachdem das vTPM erfolgreich verschlüsselt wurde, wird das vTPM auf die

Zielplattform übertragen.

8. Auf der Zielplattform wird eine neue Instanz innerhalb des vTPM erstellt.

9. Mit dem symmetrischen Schlüssel wird in Kombination mit dem Identifikator

der Zielplattform das vTPM entschlüsselt und mit den Informationen des

Quell-vTPM gefüllt.

10. Der letzte Schritt beinhaltet die Entsperrung der vTPM Instanz, damit der

normale Betrieb auf der neuen Plattform weitergeführt werden kann.

Bei einer Live Migration muss überprüft werden, ob der Migrations-Prozess

reibungslos und schnell durchgeführt wird. Während einer Live Migration kann es

86 Vgl. IBM Research Center – Berger, Stefan et. al.: vTPM: Virtualizing the Trusted Platform

Module, S. 7-8


72 Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing

so lange Zeitverzögerungen geben, bis das vTPM erfolgreich auf die Zielplattform

übertragen wurde und seinen normalen Betrieb wieder aufgenommen hat. 87

4.3. Evaluation der Erweiterung der SMMaaS Architektur zur

Lösung der Gefahren des Cloud-Computing

Abbildung 15: Erweiterte SMMaaS Architektur

4.3.1. Gefahr durch Missbrauch von Cloud-Ressourcen

Bei der Ausgangssituation hatte der Cloud-Provider Schwierigkeiten zu erkennen

wenn Ressourcen der Cloud für illegale Zwecke missbraucht wurden.

Wenn die Funktionalität der virtuellen Maschinen der Cloud-Kunden vorher nicht

definiert wurde, so konnte der Cloud-Provider nicht feststellen, wann ein anormales

Verhalten eintritt. Wenn beispielsweise der Zugang zu einer virtuellen Maschine

eines Cloud-Kunden gestohlen wird, so können darauf unbefugte Personen

illegale Dienste ausführen. Wenn in einem trust-based mandatory access control-

System das normale Verhalten einer virtuellen Maschine definiert wurde, so kann

festgestellt werden, wenn ein anormales Verhalten eintritt.

Ein Beispiel für einen definierten Dienst einer virtuellen Maschine, wäre ein

File Transfer Protokoll (FTP) Server. Diese virtuelle Maschine hätte als Aufgabe

Verbindungen mit Clients aufzubauen und über diese Verbindungen Dateien zu

transferieren. Dieser Dienst würde dem Cloud-Provider mitgeteilt werden und

würde somit als normales Verhalten der virtuellen Maschine definiert.

87 Vgl. IBM Research Center – Berger, Stefan et. al.: vTPM: Virtualizing the Trusted Platform

Module, S. 7


Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing 73

Ein Beispiel für ein Dienst, der vorher nicht definiert wurde, wäre ein Simple

Mail Transfer Protocol (SMTP) Server. Ein SMTP-Server ist ein Dienst, welcher

für das Versenden von E-Mails zuständig ist. Wenn dieser Dienst dem Cloud-

Provider nicht mitgeteilt wurde, würde ein anormales Verhalten der virtuellen

Maschine vorliegen. Dies könnte beispielsweise der Fall sein, wenn der Zugang

zu der virtuellen Maschine gestohlen wurde und die Ressourcen der Cloud dazu

verwendet werden, Spam-E-Mails zu versenden.

Zwischen dem Cloud-Provider und dem Cloud-Kunden muss definiert werden,

welche Schritte bei einem anormalen Verhalten einer virtuellen Maschine durchgeführt

werden. Hierbei könnte beispielsweise definiert werden, dass die virtuelle

Maschine von dem Cloud-Provider automatisch abgeschaltet werden darf. Wenn

bei der virtuellen Maschine eine besonders hohe Verfügbarkeit festgelegt wurde,

so könnte beispielsweise definiert werden, dass bei einem anormalen Verhalten

eine Warnung an den Cloud-Provider und den Cloud-Kunden herausgegeben wird

und die virtuelle Maschine vorerst nicht abgeschaltet wird.

4.3.2. Gefahr durch unbekannte Laufzeitumgebungen der virtuellen Maschinen

Bei der Ausgangssituation hatte der Cloud-Kunde keine Möglichkeit festzustellen,

in welchem Rechenzentrum sich seine virtuelle Maschine aktuell befindet.

Eine virtuelle Maschine kann vor dem Start, während dem Betrieb und nach dem

Betrieb in ein anderes Rechenzentrum verschoben werden.

Durch den Einsatz von vTPM wird einer virtuellen Maschine Zugang zu den

Funktionalitäten des TPM ermöglicht. Eine Funktionalität des TPM ist der Endorsement

Key beziehungsweise der Attestation Identity Key. Hiermit kann ein

Hardware TPM einen eindeutigen Schlüssel basierend auf der Plattform generieren.

Mit Hilfe dieses eindeutigen Schlüssels kann die Plattform identifiziert werden.

Der Schlüssel wird von den Hardware TPMs an die vTPMs weitergeleitet

und kann somit von virtuellen Maschinen innerhalb der Cloud ausgelesen werden.

Somit kann die aktuelle Laufzeitumgebung der virtuellen Maschinen eindeutig

festgestellt werden.

Bei einem praktischen Einsatz könnten beispielsweise die eindeutigen Schlüssel

der Hardware TPMs definiert werden. Wenn ein Cloud-Kunde seine virtuelle


74 Kapitel 4: Architektur zur Lösung der Gefahren des Cloud-Computing

Maschine nur auf Rechenzentren innerhalb eines bestimmten Landes ausgeführt

haben möchte, so können ihm die eindeutigen Schlüssel der TPMs dieser Rechenzentren

zur Verfügung gestellt werden. Während dem laufenden Betrieb der virtuellen

Maschine kann somit überprüft werden, ob die aktuelle Laufzeitumgebung

mit den vorher definierten eindeutigen Schlüsseln übereinstimmt. Wenn die virtuelle

Maschine in ein anderes Rechenzentrum migriert wird, so ändert sich der eindeutige

Schlüssel. Der neue eindeutige Schlüssel wird über den vTPM Manager

an die virtuelle Maschine weitergeleitet. Wenn der neue eindeutige Schlüssel nicht

mit den vorher definierten Schlüsseln übereinstimmt, ist die virtuelle Maschine in

eine nicht definierte Laufzeitumgebung migriert worden oder in einer nicht definierten

Laufzeitumgebung gestartet worden. Der Cloud-Kunde hat danach die

Möglichkeit zu entscheiden, ob die virtuelle Maschine weiterhin ausgeführt werden

soll. Innerhalb des SLA zwischen dem Cloud-Provider und den Cloud-

Kunden kann zusätzlich definiert werden, was für vertragsrechtliche Folgen die

Migration oder die Ausführung der virtuellen Maschine in einer unbekannten

Laufzeitumgebung mit sich bringt.

Wenn die Plattform innerhalb eines Rechenzentrums erweitert wird, muss dies

dem Cloud-Kunden mitgeteilt werden. Danach kann durch die neue Plattform ein

eindeutiger Schlüssel generiert werden, welcher ebenfalls in den Katalog der eindeutigen

Schlüssel der bekannten Laufzeitumgebungen aufgenommen wird.

Um sicherzustellen, dass ein eindeutiger Schlüssel eines Hardware TPMs tatsächlich

zu dem richtigen Rechenzentrum gehört, könnten beispielsweise Sicherheits-Audits

von unabhängigen Parteien durchgeführt werden.

Durch den Einsatz von TPM bzw. vTPM kann überprüft werden, welche aktuelle

Laufzeitumgebung eingesetzt wird. Es kann jedoch nicht überprüft werden,

wo die virtuelle Maschine vor dem Start gespeichert wurde oder wo die virtuelle

Maschine nach dem Abschalten gespeichert wird.


Kapitel 5: Fazit 75

5. Fazit

5.1. Zusammenfassung

Bei der Analyse der Gefahren des Cloud-Computings wurde aufgezeigt, dass

ein Großteil der Gefahren bereits vollständig von den BSI Mindestsicherheitsanforderungen

für Cloud-Computing abgedeckt wurde. Es wurde ebenfalls aufgezeigt,

dass noch weitere Verbesserungen möglich sind. Bei der Gefahr „unzureichende

Abgrenzung der virtuellen Ressourcen“ wurde festgestellt, dass es keine

Trennung zwischen schnell wechselnden Ressourcen und nicht schnell wechselnden

Ressourcen gibt. Bei schnell wechselnden Ressourcen muss sichergestellt

werden, dass trotzdem eine vollständige Löschung der Daten des Vorbesitzers

durchgeführt wird. Als Verbesserungsvorschlag wurde hier angebracht, dass Tests

vorgeschrieben werden können, welche die sichere Isolierung der Ressourcen

bestätigen. Bei der Gefahr „Physischer Zugang zu Rechenzentren wird nicht gewährt“

wurde aufgezeigt, dass nicht definiert wurde, dass ein Cloud-Kunde ein

Rechenzentrum physisch betreten darf.

Bei der Gefahr „Missbrauch von Cloud-Ressourcen“ wurde eine Erweiterung

der bestehenden Architektur aufgezeigt, mit der es möglich wäre zu überprüfen

welche Dienste in einer virtuellen Maschine ausgeführt werden. Der Cloud-

Provider muss hierfür die Funktionalität der virtuellen Maschine mit den Kunden

genau definieren, um Anomalien innerhalb der virtuellen Maschine entdecken zu

können. Zusätzlich muss vertraglich festgelegt werden, welche Maßnahmen im

Falle eines anormalen Verhaltens der virtuellen Maschine durchgeführt werden

sollen.

Bei der Gefahr „unbekannte Laufzeitumgebung der virtuellen Maschinen“

wurde aufgezeigt, wie mit Hilfe des vTPMs eine Möglichkeit besteht, zu überprüfen

auf welcher Plattform eine virtuelle Maschine ausgeführt wird. Hierfür ist es

nötig, dass den Cloud-Kunden sämtliche eindeutigen Schlüssel der Hardware

TPMs zur Verfügung gestellt werden. Hiermit kann festgestellt werden, in welchem

Rechenzentrum sich die virtuelle Maschine zur Laufzeit befindet. Es wurde

außerdem aufgezeigt, dass die Richtigkeit der eindeutigen Schlüssel von unabhängigen

Instituten bestätigt werden kann, damit sich ein Cloud-Kunde sicher sein


76 Kapitel 5: Fazit

kann, dass die eindeutigen Schlüssel tatsächlich zu den richtigen Rechenzentren

gehören.

5.2. Ausblick

Die Forschung im Bereich der Gefahrenbeseitigung bei Cloud-Computing ist

eine immer weitergehende Entwicklung. So wurde beispielsweise die Initiative

„Open Cloud“ gegründet um mehr Interoperabilität für Cloud-Computing zu erreichen.

Ziel ist es hierbei den uneingeschränkten Wettbewerb zwischen Cloud-

Anbietern und ein barrierefreien Zugang für Nutzer zu erreichen. Erreicht wird

das Ziel durch offene Formate, in denen Nutzer- und Metadaten definiert sind

sowie offene Schnittstellen, über die die Cloud-Funktion angesprochen werden. 88

Aber nicht nur Softwarelösungen tragen zur Gefahrenbeseitigung bei. Hardwarehersteller

implementieren Hardwarelösungen um Virtualisierung sicherer zu

machen. Der Hardwarehersteller Intel hat beispielsweise 2010 AES instructions in

die Prozessorreihe eingeführt um timing attacks zu minimieren. 89

88 Vgl. Heise online: Für mehr Standards in der Wolke

89 Vgl. Vaquero Luis et. al: Locking the sky: a survey on IaaS cloud security


Literaturverzeichnis 77

Literaturverzeichnis

Bengel, Günther:

Masterkurs Parallele und Verteilte Systeme

1. Auflage, Wiesbaden: Vieweg+Teubner, 2008

Baun, Christian:

Servervirtualisierung

In: Informatik-Spektrum, Springer-Verlag, vom 24. Januar 2009

Dölitzscher, Frank et. al.:

Security Audit as a Service (SAaaS) - An autonomous agent based IDS for

Cloud-Computing

Hochschule Furtwangen University

Dölitzscher, Frank et. al.:

Designing Cloud Services Adhering to Government Privacy Laws

In: Proceedings of the 3rd IEEE International Symposium on Trust, Security and

Privacy for Emerging Applications (TSP-10)

Kircher, Herbert:

IT. Technologien, Lösungen, Innovationen.

1. Auflage, Berlin: Springer-Verlag, 2007

Mather, Tim et al.:

Cloud Security and Privacy

1. Auflage, Sebastopol: O´Reilly Media Inc., 2009

Osterburg, Stefan:

Neue Computing-Grundlagen für das Rechenzentrum.

In: Informatik-Spektrum, Springer-Verlag, vom 16. Dezember 2008


78 Literaturverzeichnis

Thorns, Fabian:

Das Virtualisierungs-Buch – Konzepte, Techniken und Lösungen

2. Auflage, Böblingen: C&L Computer und Literaturverlag, 2008

Thomas, Marc et. al.:

Anwendbarkeit von BSI IT-Grundschutz Standards auf Cloud-Computing

Hochschule Furtwangen – Masterthesis 2010

Vaquero Luis et. al:

Locking the sky: a survey on IaaS cloud security

1. Auflage, Berlin: Springer-Verlag, 2010


Internetquellen 79

Internetquellen

Amazon Web Services:

Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US

East Region

http://aws.amazon.com/de/message/65648/

Entnommen am 17.05.2011

BSI:

(Bundesamt für Sicherheit in der Informationstechnik)

BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter – Entwurf

https://www.bsi.bund.de/

Entnommen am 05.03.2011

BSI:

(Bundesamt für Sicherheit in der Informationstechnik)

Eckpunktepapier „Sicherheitsempfehlungen für Cloud-Computing Anbieter“ –

finale Fassung

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindestanforderung

en/Eckpunktepapier-Sicherheitsempfehlungen-CloudComputing-

Anbieter.pdf?__blob=publicationFile

Entnommen am 13.07.2011

BSI:

(Bundesamt für Sicherheit in der Informationstechnik)

Das Trusted Platform Module (TPM)

https://www.bsi.bund.de/DE/Themen/weitereThemen/SicherePlattformen/

TrustedComputing/TrustedPlatformModuleTPM/

dastrustedplatformmoduletpm_node.html

Entnommen am 01.08.2011


80 Internetquellen

CBS Interactive GmbH – Gassner, Sibylle:

USA haben Zugriff auf europäische Cloud-Daten

http://www.silicon.de/management/cio/0,39044010,41554478,00/usa_haben_z

ugriff_auf_europaeische_cloud_daten.htm?DE_RECHECK_MOBILE=1

Entnommen am 30.06.2011

Chip Online:

Bericht: Sony-Hacker kamen von Amazon

http://business.chip.de/news/Bericht-Sony-Hacker-kamen-von-

Amazon_49035080.html

Entnommen am 16.05.2011

CIO online - Holger Eriksdotter:

760 Milliarden Euro Gewinn bis 2015

http://www.cio.de/_misc/article/printoverview/index.cfm?pid=558&pk=22628

87&op=lst

Entnommen am 14.08.2011

Cloud Security Alliance:

Security Guidance for Critical Areas of Focus in Cloud-Computing V2.1

https://cloudsecurityalliance.org/csaguide.pdf

Entnommen am 05.03.2011

Computerwoche.de – Herrmann, Wolfgang:

Die wichtigsten Cloud-Anbieter im Überblick

http://www.computerwoche.de/_misc/article/articleprintpopup/index.cfm?pid=

3369&pk=1881599

Entnommen am 03.10.2011

Dölitzscher, Frank et. al.:

Designing cloud services adhering to government privacy laws

http://www.wolke.hs-furtwangen.de/assets/downloads/CRL-2010-02.pdf

Entnommen am 13.07.2011


Internetquellen 81

ENISA – Catteddu, Daniele:

(European Network and Information Security Agency)

Security & Resilience in Governmental Clouds

http://www.enisa.europa.eu/act/rm/emerging-and-futurerisk/deliverables/security-and-resilience-in-governmentalclouds/at_download/fullReport

Entnommen am 05.03.2011

Elektronik-Kompendium.de:

SSL - Secure Socket Layer

http://www.elektronik-kompendium.de/sites/net/0902281.htm

Entnommen am 10.10.2011

Elektronik-Kompendium.de:

VPN - Virtual Private Network

http://www.elektronik-kompendium.de/sites/net/0512041.htm

Entnommen am 10.10.2011

Elektroniknet.de – Kuppinger, Stefan:

Mitarbeiter sind die gefährlichsten Trojaner

http://www.elektroniknet.de/automation/news/article/81154/0/Mitarbeiter_sin

d_die_gefaehrlichsten_Trojaner/

Entnommen am 09.08.2011

Golem.de:

Cloud-Computing: Amazons Speichersystem ging der Platz aus

http://www.golem.de/1108/85718.html

Entnommen am 15.08.2011

Golem.de:

Eine Amazon-Cloud speziell für die US-Regierung

http://www.golem.de/print.php?a=85786


82 Internetquellen

Entnommen am 22.08.2011

IBM Research Center – Berger, Stefan et. al.:

vTPM: Virtualizing the Trusted Platform Module

http://www.usenix.org/event/sec06/tech/full_papers/berger/berger.pdf

Entnommen am 31.05.2011

Network World – Brodkin, Jon:

Gartner: Seven cloud-computing security risks

http://www.idi.ntnu.no/emner/tdt60/papers/Cloud_Computing_Security_Risk.

pdf

Entnommen am 05.03.2011

Heise online:

Für mehr Standards in der Wolke

http://www.heise.de/developer/meldung/Fuer-mehr-Standards-in-der-Wolke-

Open-Cloud-Initiative-gegruendet-1286362.html

Entnommen am 27.07.2011

searchCloudComputing.com:

Amazon EC2 email blocked by antispam group Spamhaus

http://searchcloudcomputing.techtarget.com/news/1371369/Amazon-EC2-

email-blocked-by-antispam-group-Spamhaus

Entnommen am 02.10.2011


Anhang A 83

Anhang A

DVD-Inhalt

Arbeit als PDF-Datei (Master-Thesis_Ardelt.pdf)

Internetquellen (Quellen.zip)


Anhang B 85

Anhang B

Kontaktdaten

Mathias Ardelt

Am Pfarrgarten 4

79219 Staufen im Breisgau

E-Mail: m.ardelt@gmx.de

Weitere Magazine dieses Users
Ähnliche Magazine