Masterarbeit

zum Thema

Technische Umsetzbarkeit rechtlicher und wirtschaftlicher

Anforderungen an Cloud Provider

eingereicht an der: Universität Rostock

Fakultät für Informatik und Elektrotechnik,

Institut für Informatik

Lehrstuhl für Informations- und Kommunikationsdienste

vorgelegt von: Denitsa Kirova

Matrikel-Nr.: 5206477

Studiengang: Business Informatics

Erstgutachter: Prof. Dr. rer. nat. Clemens H. Cap (Institut für Informatik)

Zweitgutachter: Prof. Dr. Hubertus Gersdorf (Juristische Fakultät)

Betreuer: Dr.-Ing. Thomas Mundt (Institut für Informatik)

Betreuerin: Dipl.-Jur. Diane Rataj (Juristische Fakultät)

Abgabetermin: 15.6.2012

ii

Inhaltsverzeichnis

Abbildungs- und Tabellenverzeichnis iv

Abkürzungsverzeichnis v

1 Einführung 1

1.1 Schwerpunkt und Ziele der Arbeit 3

1.2 Aufbau der Arbeit 4

2 Grundlagen des Cloud Computings 6

2.1 Definition / Begriffsklärung 6

2.2 Cloud Computing Modelle 7

2.2.1 Servicemodelle 7

2.2.2 Bereitstellungsmodelle (engl. Deployment Models) 9

2.3 Rollen und Zuständigkeiten bei Cloud Computing 11

2.3.1 Cloud Service Provider (CSP) 12

2.3.2 Cloud Service Consumer (CSC) 13

2.3.3 Cloud Service Auditor 14

2.3.4 Internet Service Provider (ISP) 14

2.4 Organisation eines Cloud Service Providers 16

2.4.1 Service Orchestrierung 16

2.4.2 Cloud Service Management 17

2.4.3 Sicherheit und Datenschutz 19

2.4.4 Zentrale Technologien bei Cloud Computing 21

3 Datenschutzrechtliche Aspekte bei Cloud Computing 23

3.1 Rechtslage in der EU / dem EWR 23

3.1.1 Personenbezogene, anonymisierte und besondere Kategorien personenbezogener Daten

24

3.1.2 Rechtsmäßigkeit der Datenverarbeitung 24

3.1.3 Pflichten der für die Verarbeitung Verantwortlichen und Rechte der Betroffenen 25

3.1.4 Datenverarbeitung im Auftrag 26

3.1.5 Weitergabe von Daten an Dritte 27

3.1.6 Übermittlung personenbezogener Daten in Drittländer 27

3.1.7 Kontrollstellen 28

3.1.8 EU-Datenschutzrichtlinie für elektronische Kommunikation 28

3.2 Die Rechtslage in Deutschland 30

3.2.1 Begriffsbestimmungen nach BDSG 30

3.2.2 Datenvermeidung und Datensparsamkeit 31

3.2.3 Technische und organisatorische Maßnahmen zur Gewährleistung des Datenschutzes 31

3.2.4 Datenschutzaudit 32

3.2.5 Beauftragter für den Datenschutz 32

3.2.6 Datenverarbeitung im Auftrag 33

3.2.7 Übermittlung von personenbezogenen Daten 34

3.2.8 Datenverarbeitung außerhalb der EU / des EWR 35

iii

3.2.9 Unrechtmäßige Kenntniserlangung von Daten 35

3.3 Wesentliche Probleme bei der Einhaltung datenschutz-rechtlicher Vorschriften bei CC 36

3.3.1 Zuordnung eines CSP-CSC-Verhältnisses zu einer der Kategorien

Auftragsdatenverarbeitung oder Datenübermittlung 36

3.3.2 Einhaltung der Richtlinien für eine Auftragsdatenverarbeitung nach § 11 BDSG 37

3.3.3 Verantwortlichkeiten bei der Datenübermittlung 38

3.3.4 Rechte der Betroffenen 38

3.3.5 Wann sind die Voraussetzungen nach § 28 Abs. 1 BDSG gegeben? 38

3.3.6 Datenschutz in den USA 39

3.3.7 Mangelnde einheitliche Gesetzesgrundlage 41

4 Auditierungen und Zertifizierungen zu Cloud Computing 42

4.1 Prüfen der Existenz CC-spezifischer und datenschutzrelevanter Auditierungs- und

Zertifizierungsverfahren 42

4.1.1 Zertifizierungsprogramme 42

4.1.2 Leitfäden und Checklisten 46

4.1.3 Online Register für Cloud-Dienste 47

4.2 Erstellung eines Fragenkatalogs zur Untersuchung von CSP auf datenschutzrechtliche

Anforderungen 50

4.3 Untersuchen der Lage bei ausgewählten führenden CSP anhand des vorgeschlagenen

Fragenkatalogs 58

5 Auswirkungen der Einhaltung rechtlicher Anforderungen auf die Wirtschaftlichkeit des

Cloud Computings 62

6 Lösungen und Ansätze zur Umsetzung rechtlicher und wirtschaftlicher Anforderungen bei

der CC-basierten DV 65

6.1 Identity and Access Management 66

6.2 Verschlüsselung 70

6.2.1 Vorhandene Lösungen 71

6.2.2 Lösungen in der Forschungsphase 72

6.3 Hybride Lösungsansätze 74

6.4 Gewährung von Verfügbarkeitskontrolle 78

7 Zusammenfassung 79

Literaturverzeichnis 81

Anlagen zum Kapitel 4.3 90

iv

Abbildungs- und Tabellenverzeichnis

Abbildung 1: CC ist das führende Thema in der ITK-Branche in 2012 1

Abbildung 2: Gründe für den zukünftigen Einsatz von CC-Lösungen bei deutschen KMU ([PwC11],

S. 27) 2

Abbildung 3: Gründe gegen den Einsatz von CC-Lösungen aus Nutzersicht ([De11], S. 9) 2

Abbildung 4: Herausforderungen des CC-Marktes aus CSP-Sicht ([PwC10], S. 25) 3

Abbildung 5: Anbieter von SaaS, PaaS & IaaS ([PHG11], S.11) 9

Abbildung 6: Private, Public & Hybrid Cloud 11

Abbildung 7: NIST Cloud Computing Reference Architecture ([LTM+11], S. 3) 11

Abbildung 8: Zusammenspiel mehrerer CSP 12

Abbildung 9: Verantwortungsbereiche von CSP und CSC bei unterschiedlichen Service- und

Bereitstellungsmodellen 13

Abbildung 10: Statur und Art der betroffenen persönlichen Daten bei ausgewählten

Safe-Harbor-zertifizierten Unternehmen (Stand 5.5.2012) 40

Abbildung 11: In wie weit werden gesetzte Ziele bei dem Einsatz vom CC-Lösungen erreicht ([De11],

S. 15) 63

Abbildung 12: Identity-as-a-Service von Symplified 68

Abbildung 13: Föderation von Organisationen mit eigenem FIdM 68

Abbildung 16: Funktionsweise eines Client-seitigen Mashup ([OBB07b]) 76

Tabelle 1: Federated Identity Management Anbieter & Lösungen 69

v

Abkürzungsverzeichnis

AHV Arithmetische Homomorphe Verschlüsselung

API Application Programming Interface (dt. Programmierschnittstelle)

AWS Amazon Web Services (die Cloud-Dienste von Amazon)

BDSG Bundesdatenschutzgesetz

BITKOM Bundesverband Informationswirtschaft, Telekommunikation und neue Medien

BS Betriebssystem

BSI Bundesamt für Sicherheit in der Informationstechnik

CC Cloud Computing

CRM Customer Relationship Management (dt. Kundenbeziehungsmanagement)

CSA Cloud Security Alliance

CSA STAR Cloud Security Alliance Security, Trust & Assurance Registry

CSC Cloud Service Consumer

CSP Cloud Service Provider

DuD Datenschutz und Datensicherheit

DV Datenverarbeitung

EDV Elektronische Datenverarbeitung

ERP Enterprise Resource Planning

EU Europäische Union

EWR Europäischer Wirtschaftsraum

FIdM Federated Identity Management

FAQ Frequently Asked Questions (dt. Häufig gestellte Fragen)

HRM Human Resource Management (dt. Personalwesen/Personalwirtschaft)

HV Homomorphe Verschlüsselung

IaaS Infrastructure-as-a-Service

ISP Internet Service Provider

ITK Informationstechnologie und Telekommunikation

KMU Kleine und mittelständische Unternehmen

MSOS Microsoft Online Services (die Cloud-Dienste von Microsoft)

NIST National Institute of Standards and Technology (eine US-Bundesbehörde)

PaaS Platform-as-a-Service

QoS Quality of Service (dt. Dienstgüte)

vi

SaaS Software-as-a-Service

SAML Security Assertion Markup Language

SLA Service Level Agreement (dt. Dienstgütevereinbarung)

SSO Single sign-on (dt. Einmalanmeldung)

SW Software

VHV Vollhomomorphe Verschlüsselung

VPN Virtual Private Network

WS Web Service(s)

1 Einführung

Cloud Computing (CC) oder „Rechnen in der Wolke“ ist eines der am häufigsten diskutierten

Themen in der IT in den vergangenen zwei Jahren. Laut einer Umfrage des Bundesverbands

Informationswirtschaft, Telekommunikation und neue Medien (BITKOM) gilt CC im Jahr

2012 weiterhin als das wichtigste Thema für die ITK-Branche (vgl. Abb. 1). Die

Diskussionen dazu sind vielfältig. Sie erstrecken sich von der immer noch aktuellen Debatte

über die Definition des Begriffs über ökonomische Fragen wie bspw. geeignete und

transparente Abrechnungsmodelle sowie technische / technologische Themen wie die

Entwicklung von CC-Standards und passenden Management- und Monitoring-Lösungen bis

zu rechtlichen Fragenstellungen zur Vertragsgestaltung und Vertragstypologie und

datenschutzrechtlichen Aspekten wie die Gewährleistung des Schutzes personenbezogener

und anderer besonderer Kategorien von Daten.

Abbildung 1: CC ist das führende Thema in der ITK-Branche in 20121

CC wird grundsätzlich in den drei Hauptmodellen bereitgestellt – Private, Public und Hybrid

Cloud. Alle drei Modelle weisen unterschiedliche Vor- und Nachteile auf und sind an Firmen

unterschiedlicher Größen gerichtet. IT-Experten und Cloud Service Provider (CSP) sind der

Meinung, dass vor allem kleine und mittelständische Unternehmen (KMU) sehr stark vom CC

profitieren können. Sie können bedarfsgerecht hoch qualitative und flexible Lösungen, welche

immer auf dem aktuellen technischen Stand sind, nutzen, ohne in Infrastruktur und

Managementpersonal investieren zu müssen. Dadurch können sie einen Großteil ihrer

IT-Kosten einsparen. Wie eine Studie der Wirtschaftsprüfer PricewaterhouseCoopers zeigt,

1 http://www.bitkom.org/files/documents/HIGHTECH_Download.jpg (8.6.2012)

2

sind diese auch die vorwiegenden Gründe, warum sich KMU zukünftig für den Einsatz von

CC-Lösungen entscheiden wollen (vgl. Abb. 2).

Abbildung 2: Gründe für den zukünftigen Einsatz von CC-Lösungen bei deutschen KMU ([PwC11], S. 27)

Gegenüber den genannten Vorteilen stehen jedoch einige Nachteile, welche das CC-Modell

zur Zeit unattraktiv machen und seine Verbreitung verhindern. Hier sind sich Nutzer und

Anbieter wiederum grundsätzlich einig. Die wichtigsten CC-Risiken aus Nutzersicht sind der

Kontrollverlust, die unzureichende Datensicherheit und die offenen Compliance- bzw.

rechtlichen Anforderungen (vgl. Abb. 3). Die größten Herausforderungen für das CC aus

Anbietersicht sind die Gewährleistung von Datenschutz und Compliance, die passgenaue

Gestaltung von Service Level Agreements sowie die Informationssicherheit (vgl. Abb. 4).

Abbildung 3: Gründe gegen den Einsatz von CC-Lösungen aus Nutzersicht ([De11], S. 9)

3

Abbildung 4: Herausforderungen des CC-Marktes aus CSP-Sicht ([PwC10], S. 25)

1.1 Schwerpunkt und Ziele der Arbeit

Diese Arbeit setzt den Schwerpunkt auf die rechtlichen und insbesondere auf die

datenschutzrechtlichen Aspekte, welche für die Verwendung von CC-basierten Diensten

relevant sind. Sie spielen eine ausschlaggebende Rolle sowohl für Nutzer als auch für

Anbieter. Auf der einen Seite müssen sie vom Cloud Service Consumer (CSC) bei der

Auswahl geeigneter Cloud-Service-Provider und –Lösungen im Betracht gezogen werden.

Auf der anderen Seite sind sie durch die CSP bei der Entwicklung von Diensten und der

Erstellung von Angeboten und Verträgen zu berücksichtigen. Die Anforderungen bei der

elektronischen Datenverarbeitung (EDV), welche sich aus unterschiedlichen gesetzlichen

Regelungen ergeben, haben insofern eine unmittelbare Auswirkung auf die technologische

Entwicklung des CC.

Des Weiteren ergeben sich aus diesen Anforderungen heraus einige Fragen zu der

Wirtschaftlichkeit dieses vielversprechenden Modells: Was kostet die rechtskonforme

CC-basierte DV und in wie weit werden die Kosten für eine solche Verarbeitung in den

aktuellen Angeboten von CSP und in den Kostenabschätzungen von CSC berücksichtigt? Die

Auswahl geeigneter CSP, die Vertragsüberprüfung und –verhandlung für die relevanten

Dienste, sowie die regelmäßigen Kontrollen der CSP, wie diese z. B. das

4

Bundesdatenschutzgesetzt vorschreibt, können sehr aufwendig sein und müssen demzufolge

in den Gesamtkostenbetrachtungen von IT-Entscheidern mitberücksichtigt werden.

Die vorliegende Arbeit hat vier grundlegende Ziele. Zunächst untersucht sie die

datenschutzrechtlichen Gesetze und Richtlinien auf deren Relevanz und Anwendbarkeit bei

der Verwendung von Cloud-Diensten. Ziel dabei ist es, aus den relevanten Vorschriften

technische Anforderungen abzuleiten, welche für eine rechtskonforme DV durch Cloud

Service Provider und Consumer abgedeckt werden müssen. Das zweite Ziel ist ein grobes

Konzept zur Überprüfung eines CSP auf rechtskonforme Verarbeitung von vor allem

personenbezogenen Daten zu erstellen und den Markt auf vorhandene CC-spezifische und auf

CC übertragbare Zertifizierungsprogramme zu sichten. Das dritte Ziel ist die Auswirkung,

welche die Umsetzbarkeit (datenschutz-)rechtlicher Anforderungen auf die Wirtschaftlichkeit

des CC-Modells haben kann, zu schildern. Zuletzt zielt die Arbeit darauf ab, Möglichkeiten

aufzuzeigen, mit deren Hilfe die rechtlichen Anforderungen an die CC-basierte DV

(vorwiegend mittels Public Clouds) weitgehend technisch umgesetzt werden können.

1.2 Aufbau der Arbeit

Die Arbeit ist in sieben Kapitel gegliedert. Nach einer kurzen Einführung in das Thema

werden im zweiten Kapitel zuerst die Grundlagen des Cloud Computings erläutert. Diese

beinhalten die wichtigsten Charakteristiken, die unterschiedlichen Bereitstellungs- und

Service-Modelle, die Rollen und die Zuständigkeiten der Hauptbeteiligten, die grundlegende

Architektur sowie die wichtigsten Technologien.

Kapitel 3 beschäftigt sich mit den rechtlichen Aspekten beim CC. Dabei wird der

Schwerpunkt auf die Richtlinien und Gesetze zum Schutz personenbezogener Daten gelegt,

da diese durch Cloud-Dienste wie z. B. Kalender- und Kontakteverwaltung,

Kundenbeziehungsmanagement (engl. Customer Relationship Management (CRM)) oder

Personalwirtschaft (engl. Human Resource Management (HRM)) verarbeitet werden. Im

Kapitel 3.1 wird die für alle EU-Mitgliedsstaaten geltende Datenschutzrichtlinie 95/46/EG

und im Kapitel 3.2 ihre Umsetzung in Deutschland durch das Bundesdatenschutzgesetzbuch

(BDSG) vorgestellt. Anschließend werden im Kapitel 3.3 wesentliche Probleme bei der

Umsetzung datenschutzrechtlicher Vorschriften in dem CC-Kontext erläutert.

Kapitel 4 beschäftigt sich mit Zertifizierungs- und Auditierungsverfahren zum CC. Zunächst

werden bereits existierende Zertifizierungsprogramme oder vorgeschlagene

Auditierungsverfahren grob beschrieben (siehe Kapitel 4.1). Als nächstes wird im Kapitel 4.2

5

ein Fragenkatalog zur Prüfung eines CSP auf die rechtskonforme Verarbeitung von

personenbezogenen Daten erarbeitet und im Kapitel 4.3 wird die Lage bei vier ausgewählten

CSP anhand des erstellten Katalogs untersucht.

Im Kapitel 5 folgt dann eine kurze Auswertung der Faktoren, welche auf die

Wirtschaftlichkeit vom CC Auswirkungen haben bzw. unter bestimmten Bedingungen haben

können. Insbesondere werden die Kosten beschrieben, die durch die Einhaltung von

datenschutzrechtlichen Bestimmungen verursacht werden.

Im sechsten Kapitel werden Lösungsansätze vorgeschlagen, welche für die Gewährleistung

von Datenschutz und Datensicherheit bei der CC-basierten DV sorgen und die rechtlichen

Anforderungen an CSP und CSC technisch weitgehend umsetzen können. Ein Teil der

Ansätze befindet sich allerdings noch in der Forschungsphase und liefert zur Zeit keine

praktikablen Lösungen.

Der Abschluss der Arbeit, Kapitel 7, fasst die Ergebnisse und die Schlussfolgerungen, welche

im Laufe der Arbeit entstanden sind, zusammen.

6

2 Grundlagen des Cloud Computings

2.1 Definition / Begriffsklärung

Cloud Computing ist ein Modell zur Bereitstellung von Rechenkapazitäten und Diensten, das

in den letzten Jahren besonders an Bedeutung gewonnen hat. Es bietet Nutzern die

Möglichkeit, unterschiedliche Ressourcen und Anwendungen bedarfsgerecht über das Internet

zu beziehen, verspricht hohe Flexibilität und die Reduzierung von IT-Kosten.

Das Wort Cloud (engl. für Wolke) wird in diesem Zusammenhang als Synonym für das

Internet benutzt und bezieht sich auf den Ort, von dem aus die Dienste angeboten werden,

nämlich das Internet. Gemäß der Grundidee des Modells soll für den Nutzer der Standort der

Dienste und Ressourcen irrelevant sein, da er von überall auf diese zugreifen kann.

Vorausgesetzt, er verfügt über eine Internetverbindung und ein Endgerät, mit bestimmten

Eigenschaften.

In der Literatur existiert keine einheitliche Definition für den Begriff Cloud Computing. Um

ihn zu erklären, wird am häufigsten auf seine wichtigsten Eigenschaften nach der Definition

des US-amerikanischen National Institute of Standards and Technology (NIST)2

zurückgegriffen. Diese sind [MG11]:

1) On-demand self-service – der Nutzer kann sich selbstständig und automatisch die

Rechenressourcen (Netzwerke, Server, Speicher, Anwendungen und Dienste)

beschaffen, die er benötigt, ohne auf die direkte Hilfe der Diensteanbieter angewiesen

zu sein.

2) Broad network access – die Dienste/Ressourcen sind einfach über das Internet aufrufbar

und sind nicht an bestmimte Geräte gebunden.

3) Resource pooling – die Ressourcen sind so organisiert, dass sie von mehreren Nutzern

gleichzeitig benutzt werden können. Je nach Bedarf können sie dynamisch reserviert

und wieder freigegeben werden. Der reale Standort der Ressourcen ist für die Nutzer

generell ungewiss und außerhalb ihrer Kontrolle. In manchen Fällen hat der Nutzer

jedoch die Möglichkeit zu bestimmen, aus welchem „abstrakten“ Standort (d. h. Land,

Stadt oder Rechenzentrum) die Ressourcen bezogen bzw. an welchem Ort seine Daten

gehostet werden sollen.

4) Rapid elasticity – Ressourcen können jederzeit schnell und zum Teil automatisch

erweitert werden, so dass der Kunde das Gefühl hat, dass diese unbegrenzt sind.

2 http://www.nist.gov/information-technology-portal.cfm

7

5) Measured service – Die Ressourcennutzung kann überwacht, kontrolliert, dokumentiert

und mit geeigneten Modellen gemessen werden, so dass für jeden Nutzer eine

Rechnung entsprechend der von ihm benutzten Ressourcen erstellt werden kann. Dieses

Abrechnungsmodell wird auch „pay-per-use“ oder „charge-per-use“ genannt.

Unter Berücksichtigung dieser Eigenschaften und der Tatsache, dass ihre komplette

Umsetzung nicht bei allen Bereitstellungsmodellen (vgl. Kapitel 2.2.2) möglich oder sinnvoll

ist, hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) die folgende Definition

für CC herausgebracht:

„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 der Informationstechnik

und beinhaltet unter anderem Infrastruktur (z. B. Rechenleistung, Speicherplatz),

Plattformen und Software.“ ([BSI11], S. 14)

2.2 Cloud Computing Modelle

In der Literatur existiert eine Vielzahl von unterschiedlichen CC-Modellen. Diese werden

meistens in zwei Hauptkategorien gegliedert – Servicemodelle und Bereitstellungsmodelle.

2.2.1 Servicemodelle

Bei den Servicemodellen wird hauptsächlich zwischen Software as a Service, Platform as a

Service and Infrastructure as a Service unterscheiden.

Software-as-a-Service (SaaS) ist ein Modell, bei dem bestimmte Softwarelösungen als

Dienste über das Internet angeboten und genutzt werden. Dabei greift ein Nutzer auf

ausgewählte Dienste direkt zu (mittels eines Webbrowsers oder einer

Programmierschnittstelle (API)) und kann diese nutzen, ohne dass eine lokale Installation

benötigt wird. Das Management, die Administration und die Wartung der Dienste, sowie der

darunter liegenden Infrastruktur liegen in der Verantwortung der CSP. Der CSC kann generell

nur bestimmte nutzerbezogene Einstellungen selbst verwalten [MG11]. Das Serviceangebot

beinhaltet die gesamte Palette an möglichen Anwendungssoftwarelösungen. Einige Beispiele

sind E-Mail- und Kalenderverwaltung, Text- und Dokumentenverarbeitung, CRM, HRM,

8

diverse ERP-Lösungen und andere. Studien zufolge werden SaaS-Lösungen am häufigsten bei

KMU eingesetzt (vgl. [De11], S. 12 und [PwC11], SS. 21-22).

Platform-as-a-Service (PaaS) ist ein Modell, das sich an Nutzer richtet, die neue

Softwarelösungen entwickeln, testen und testen lassen möchten, ohne in die Infrastruktur und

in die Entwicklungsumgebung investieren zu müssen. Der PaaS-Anbieter stellt eine

Programmierumgebung sowie Programmiersprachen, Bibliotheken, Test- und Deployment-

Tools bereit und ist für die Verwaltung dieser zuständig. Er kontrolliert und verwaltet

außerdem die unter der Entwicklungsumgebung und den -Tools liegende (physische)

Infrastruktur. Der PaaS-Nutzer kontrolliert und verwaltet seine Anwendungen und kann

möglicherweise bestimmte Einstellungen der Umgebung, auf welcher seine Anwendungen

gehostet werden, selbst konfigurieren [MG11]. Beispiele für PaaS-Dienste sind Microsoft

Azure, Google App Engine, Force.com und Amazon Web Services Developers Tools.

Bei Infrastructure-as-a-Service (IaaS) kann der Kunde unterschiedliche Rechen- und

Speicherkapazitäten, Netzwerke und Netzwerkinfrastrukturkomponenten von einem CSP

beziehen. Dem Kunden wird eine Benutzerschnittstelle zur Verfügung gestellt, die ihm

ermöglicht, auf die Ressourcen zuzugreifen und diese zu verwalten (vgl. [BKNT11], SS.31-

32). Die Dienstangebote erstrecken sich von Speichermedien oder Speicherplatz (z. B.

Amazon S3, Dropbox) bis zu virtuellen Servern (z. B. Amazon EC2, App Nexus Cloud) und

Rechenlandschaften (vgl. [BKNT11], S. 33-34). Falls der Kunde virtuelle Server nutzt, hat er

die Möglichkeit, diese mit weiteren Komponenten wie z. B. Betriebssysteme, Anwendungs-

und Managementsoftware auszustatten und somit sein eigenes virtuelles Rechenzentrum

aufzubauen. Die Verantwortung für die Verwaltung der physischen Infrastruktur bei diesem

Dienstmodell liegt wieder bei dem CSP.

Abbildung 5 zeigt einige Beispiele für Anbieter von SaaS, PaaS und IaaS.

Zusätzlich zu den vorgestellten drei Hauptmodellen existieren auch weitere Serviceformen.

Diese stellen generell eine Spezifizierung eines der oben genannten Modelle (z. B.

Security-as-a-Service, Identity-as-a-Service oder Communication-as-a-Service3 als

Unterkategorie von SaaS, oder Storage-as-a-Service als Unterkategorie von IaaS) oder eine

Mischung aus diesen dar. Alle möglichen Cloud-Dienstmodelle werden unter dem

einheitlichen Begriff XaaS (das X steht für anything oder everything) zusammengefasst.

3 Information zu dieser Form von Cloud-Diensten bei [RR10], Seiten 30-34

9

Abbildung 5: Anbieter von SaaS, PaaS & IaaS ([PHG11], S.11)

2.2.2 Bereitstellungsmodelle (engl. Deployment Models)

Bei den Bereitstellungsmodellen wird grundsätzlich zwischen Private, Public und Hybrid

Clouds unterschieden.

Bei einer Private Cloud stehen die Cloud-Dienste nur einem einzigen Unternehmen bzw. nur

einer einzigen Organisation zur Verfügung. Die Cloud-Infrastruktur kann sowohl von der

Organisation selbst, als auch von externen Unternehmen verwaltet werden oder von einer

Kombination aus beiden und kann im eigenen oder im fremden Rechenzentrum liegen.

Wenn die Organisation selbst die Cloud-Infrastruktur beschafft und verwaltet (dieses Modell

wird On-site Private Cloud genannt ([LTM⁺11], S. 10)), liegen einige der im Kapitel 2.1

erläuterten CC-Eigenschaften nicht vor. Der Nutzer kann z. B. nicht jederzeit die Ressourcen

beliebig erweitern und wieder reduzieren, da für die Erweiterung zuerst neue Komponenten

beschafft werden müssen, die dann nicht einfach freigegeben werden können. Sie bleiben

erhalten, auch wenn der Nutzer diese nicht mehr braucht und müssen verwaltet oder entsorgt

werden. Daraus ergeben sich zwei wesentliche Nachteile dieser Variante – weniger

Flexibilität und weniger Kosteneinsparungen. Diesen gegenüber stehen zwei entscheidende

Vorteile:

1) Eine solche Private Cloud ist sicherer, da keine externen Personen Zugang zu den

Systemen haben.

2) Die Organisation behält die Kontrolle über die eigenen Daten und weiß jederzeit, wo

diese liegen.

Aus diesen Gründen werden On-site Private Clouds in der Praxis bevorzugt.

10

Eine Public Cloud ist für eine unbegrenzte Anzahl von Nutzern und Organisationen offen

und wird von einem CSP zur Verfügung gestellt. Der Zugang zu den Diensten geschieht

i. d. R. über das Internet. Nach der Registrierung bei dem CSP erhält der Nutzer die Erlaubnis,

die gewünschten Dienste zu nutzen. Für den Nutzer agiert der CSP als die einzige Einheit, die

für die Verwaltung und die Kontrolle der Dienste zuständig ist. In der Praxis ist es jedoch

üblich, dass mehrere Unternehmen an der Bereitstellung der Dienste beteiligt sind, indem sie

z. B. Teile der Dienste liefern oder die physische Infrastruktur warten. Diese werden

Subunternehmer genannt und bleiben für den Nutzer meist anonym.

Public CSP haben generelle Geschäfts- und Nutzungsbedingungen,

Datenschutzbestimmungen und Service Level Agreements (SLA), die der Nutzer akzeptieren

muss, bevor er die Dienste nutzen kann. In den meisten Fällen sind diese Bestimmungen

allgemeingültig und nicht verhandelbar.

Public Clouds bieten hohe Flexibilität und Dienstvielfalt, haben jedoch zwei essentielle

Nachteile:

1) Der Schutz und die Sicherheit der Daten können noch nicht so gewährleistet werden,

wie es sich viele Unternehmen wünschen und

2) Dienste unterschiedlicher Anbieter sind oft nicht miteinander kompatibel (siehe dazu

Kapitel 2.4.2).

Aus diesen Gründen werden Public-Cloud-Dienste in der Praxis eher zurückhaltend genutzt.

Eine Hybrid Cloud ist eine Kombination aus Public und Private Cloud. Dabei existieren die

beiden Wolken als getrennte Entitäten und werden durch standardisierte oder proprietäre

Technologien miteinander verbunden, so dass sie Daten und Anwendungen untereinander

austauschen können. Üblicherweise werden bei diesem Modell die privaten Ressourcen für

die regulären Aufgaben und Prozesse und die Bearbeitung sensibler Daten benutzt, während

spezielle Funktionalitäten und / oder Lastspitzen auf die öffentlichen Ressourcen ausgelagert

werden (vgl. [BKNT11], S. 29). Dadurch wird mit einer Hybrid Cloud versucht, die Vorteile

von Private und Public Cloud zu vereinigen und die Nachteile dieser Modelle zu minimieren.4

Abbildung 6 veranschaulicht die drei Bereitstellungsmodelle.

4 Die Firma Rackspace (http://www.rackspace.com/ ) ist bspw. ein Anbieter von Hybrid-Clouds-Lösungen.

11

Abbildung 6: Private, Public & Hybrid Cloud5

2.3 Rollen und Zuständigkeiten bei Cloud Computing

CC ist ein hoch komplexes Geschäfts- und Service-Modell, an dem viele Parteien beteiligt

sind. Die Anzahl der Beteiligten kann in Abhängigkeit von der CC-Architektur, die eine

Organisation implementieren möchte, variieren. Jedem Beteiligten wird eine bestimmte Rolle

zugeschrieben. Die NIST CC-Referenzarchitektur definiert z. B. fünf Hauptrollen (siehe Abb.

7), die IBM dagegen nur drei [IBM11]. Für den Zweck dieser Arbeit werden vier Rollen

definiert und erläutert. Diese sind: Cloud Service Provider, Cloud Service Consumer, Cloud

Service Auditor und Internet Service Provider.

Abbildung 7: NIST Cloud Computing Reference Architecture ([LTM+11], S. 3)

5 http://upload.wikimedia.org/wikipedia/commons/thumb/8/87/Cloud_computing_types.svg/800px-

Cloud_computing_types.svg.png (8.6.2012)

12

2.3.1 Cloud Service Provider (CSP)

Ein CSP ist eine Organisation oder Person, die Cloud-Dienste zur Nutzung bereitstellt. Der

CSP ist i. d. R. für die folgenden drei Haupttätigkeiten zuständig:

1) Er schafft die Cloud-Infrastruktur an und verwaltet diese.

2) Er betreibt eine Cloud-Managementsoftware, die für die Bereitstellung der

Cloud-Dienste notwendig ist.

3) Er organisiert die Auslieferung der Dienste an die Nutzer über das Internet (vgl.

[LTM⁺11], S. 7).

In Abhängigkeit von der Art der angebotenen Cloud-Dienste übernimmt ein CSP

unterschiedlich viel Verantwortung für die Verwaltung der Systeme und muss demzufolge

unterschiedlich viel Verwaltungsaufwand betreiben (vgl. Abb. 9). Bei SaaS z. B. hat der CSP

fast die gesamte Verantwortung für das Management und die Kontrolle der Cloud-Systeme –

von der Anwendungssoftware, die als Dienst angeboten wird, über die

Cloud-Managementsoftware bis zu der darunter liegenden Hardwareinfrastruktur. Bei IaaS

dagegen verwaltet er nur die physische Infrastruktur und die Cloud-Managementsoftware.

Wie bereits erwähnt betreibt ein CSP nur selten die gesamte CC-Landschaft selbständig. Im

Allgemeinen werden Teile eines CC-Gesamtsystems von Drittunternehmen zugeliefert und

verwaltet. Außerdem können in der Praxis auch folgende Szenarien vorkommen: ein SaaS-

oder PaaS-Anbieter kann seine Dienste auf einer physischen oder virtuellen Infrastruktur

betreiben, die ein anderer IaaS-Anbieter besitzt und managet (s. Abb. 8). Somit werden

mehrere Unternehmen in den CC-Prozessen eines CSP involviert und CSP werden

gleichzeitig auch Konsumenten von Cloud-Diensten.

Abbildung 8: Zusammenspiel mehrerer CSP

Die Organisation und die Hauptprozesse eines CSP werden im Kapitel 2.4 detailliert

dargestellt.

SaaS

PaaS

IaaS

CSP A CSP C

PaaS

CSP B

SaaS

13

2.3.2 Cloud Service Consumer (CSC)

Ein CSC ist eine Organisation oder Person, die Cloud-Dienste nutzt. Bevor mit der

tatsächlichen Dienste-Nutzung begonnen wird, muss der CSC allerdings einige Punkte

beachten. Diese sind im Allgemeinen:

Er registriert sich bei dem CSP.

Er macht sich mit den Allgemeine Geschäftsbedingungen (AGB) sowie den

Datenschutzbestimmungen des CSP vertraut und akzeptiert diese.

Er macht sich mit den unterschiedlichen Nutzungsbedingungen, die für die

unterschiedlichen Diensten relevant sind, sowie mit SLA vertraut.

Falls die SLA verhandelbar sind, kann der Nutzer versuchen, bessere Konditionen für

sich auszuhandeln ([LTM⁺11], S. 5).

Nach all diesen Schritten wird dem CSC Zugang zu den Diensten gewährt und er kann diese

nutzen.

Wie bereits erwähnt, hat ein CSC unterschiedliche Verwaltungs- und Kontrollrechte über die

von ihm verwendeten Dienste (vgl. Abb. 9). Im Falle einer On-site Private Cloud (Abb. 9

„Dedicated IT“) ist der CSC gleichzeitig der CSP und hat die gesamte Verantwortung in

seinen Händen. Wenn der CSC Public SaaS nutzt, dann besitzt er sehr begrenzte

Verwaltungs- und Kontrollrechte – er kann nur bestimmte nutzerdefinierte Einstellungen

verwalten. Nutzt er IaaS in Form von Virtuellen Maschinen, dann muss er selbständig

Anwendungen, Betriebssysteme und weitere Infrastrukturkomponente administrieren.

Abbildung 9: Verantwortungsbereiche von CSP und CSC bei unterschiedlichen Service- und

Bereitstellungsmodellen6

6 http://lotuscsp.files.wordpress.com/2011/11/picture1.png (8.6.2012)

14

2.3.3 Cloud Service Auditor

Hinter einem Cloud-Dienst verbergen sich komplexe Infrastrukturen und Prozesse.

Insbesondere bei sehr großen und international agierenden CSP wie z. B. Google, Amazon

und Microsoft ist es sehr schwierig für eine Organisation, welche die eigene IT durch

Cloud-Dienste ersetzen möchte, diese Anbieter und deren Diensten zu vergleichen und die

beste Alternative zu ermitteln. Um diese Aufgabe erfolgreich zu erledigen, muss die

Organisation in der Lage sein, die CSP aus verschiedenen Gesichtspunkten zu untersuchen.

Einige dieser Gesichtspunkte sind:

Sicherheit und Schutz der Nutzerdaten: Der Nutzer sucht Antworten auf die Fragen:

Wie geht der betrachtete CSP mit Kundendaten um? Sind meine Daten sicher

aufbewahrt und vor fremden Zugriffen geschützt? Wo, in der Welt, liegen Kopien von

meinen Daten und wer kann auf diese zugreifen?

Gesetzeskonformität: Ist aus juristischer Sicht die Nutzung von Cloud-Diensten eines

bestimmten CSP für meine Organisation, meine Branche und mein Land überhaupt

zulässig? Sind die Cloud-Dienste konform mit Datenschutz-, handelsrechtlichen,

steuerrechtlichen, Telekommunikations- und weiteren Gesetzen, die in meinem Land

gültig sind?

Stand der Technik, Performance und Standards: Arbeitet der CSP mit

allgemeingültigen und bewährten Standards und Technologien? Sind Interoperabilität

und Portabilität bei den Diensten und Systemen gegeben? Kann der Nutzer jederzeit

auf seine Daten zugreifen und wenn nicht, welche Folgen hat das für seine

Organisation und für den Anbieter?

Diese Fragen kann ein (potentieller) Nutzer nur begrenzt und mit sehr hohem Aufwand

beantworten. Aus diesem Grund muss diese Problematik in der Verantwortung von externen,

unabhängigen, auf diesem Gebiet spezialisierte Personen und/oder Organisationen liegen. Das

ist die Rolle des Cloud Service Auditors. Er soll CSP anhand der oben beschriebenen

Gesichtspunkte untersuchen und sowohl CSC als auch CSP die Sicherheit geben, dass sie

qualitative, sichere, gesetzeskonforme und den allgemeingültigen Standards entsprechende

Dienste nutzen bzw. anbieten.

2.3.4 Internet Service Provider (ISP)

Ein weiterer wichtiger Prozessbeteiligter bei CC ist der Internet Service Provider. Ein ISP hat

die Rolle eines Vermittlers. Er stellt einen virtuellen Ort bereit, wo sich Anbieter und Nutzer

treffen, kennenlernen und Geschäfte abwickeln. Seine Rolle stimmt in großem Maße mit der

15

NIST-Definition über die Rolle eines „Cloud Carriers“ überein. Laut [LTM⁺11] ist ein Cloud

Carrier „ein Vermittler, der die Konnektivität und den Verkehr von Cloud Diensten von CSP

zu CSC realisiert“. Mit der Aufnahme des ISP als wichtigen Beteiligten in den CC-Prozess

entstehen neue Fragen, zu welchen neue Lösungen gesucht werden müssen. Z. B.

Welche Verantwortung trägt der ISP bei der Bereitstellung von Cloud-Diensten?

Bietet ein ISP unterschiedliche Internet-Servicevarianten für CSP und CSC an bzw.

hat er überhaupt die Möglichkeit unterschiedliche Varianten anzubieten?

Was passiert, wenn die Internetverbindung ausfällt?

CSP müssen diesbezüglich auch über Lösungen nachdenken, welche die Fortsetzung der

Verwendung eines Dienstes bei nicht verfügbarer Internetverbindung ermöglichen würden

(sog. Arbeiten im Offline-Modus). Allerdings muss dabei berücksichtigt werden, dass solche

Lösungen mit zusätzlichen Kosten verbunden sein können und dass der Nutzer entsprechende

Software-Tools auf seinen Endgeräten installieren und pflegen muss. Bspw. bietet Google für

seine Dienste Google Mail, Kalender, Text & Tabelle bereits Offline-Modi an, allerdings mit

einigen Funktionseinschränkungen und zur Zeit nur in Verbindung mit der Nutzung von

Google Chrome7.

Ein Hindernis für die Verbreitung des CC stellt auch die mangelnde Internetverfügbarkeit in

bestimmten Regionen dar. Problematisch ist vor allem die Versorgung ländlicher Regionen

mit Internetzugang. In der EU verfügen bspw. circa 70 % der Bevölkerung in ländlichen

Gebieten über einen Breitband-Zugang im Gegensatz zu 98 % in städtischen Gebieten (Stand:

Dezember 2007)8. In den USA ist die Situation vergleichbar – ca. 66% der gesamten und nur

50% der ländlichen US-Bevölkerung verfügten im Jahr 2010 über eine Internetverbindung9.

Somit stehen sowohl ISP als auch CSP vor der Herausforderung, das Internet für möglichst

alle Interessierten zugänglich zu machen.

7 http://www.googlewatchblog.de/2011/08/offline-modus-fuer-google-mail-google-calendar-und-google-docs/,

http://support.google.com/docs/bin/answer.py?hl=de&answer=1628467&topic=1628465&ctx=topic

(5.5.2012) 8 http://europa.eu/legislation_summaries/information_society/strategies/si0005_de.htm (5.5.2012)

9 http://en.wikipedia.org/wiki/Internet_access#Rural_access (5.5.2012)

16

2.4 Organisation eines Cloud Service Providers

Abb. 7 auf S. 11 präsentiert die CC-Referenzarchitektur nach der NIST-Definition. Aus ihr

wird sichtbar, wie ein CSP organisiert werden muss und welche Aufgabenkomplexe in seiner

Verantwortung liegen. Dieses Kapitel beschäftigt sich im ersten Teil mit diesen

Aufgabenkomplexen und im zweiten Teil mit Technologien, welche das Erfüllen der

Aufgaben ermöglichen bzw. unterstützen.

2.4.1 Service Orchestrierung

Service Orchestrierung (engl. Service Orcherstration) beschreibt die flexible

Zusammensetzung von Systemkomponenten, die den CSP bei der Gestaltung, Koordination

und Verwaltung der Rechenressourcen unterstützt, so dass er in der Lage ist, Cloud Dienste

zur Verfügung zu stellen (vgl. [LTM⁺11], S. 12). Service Orchestrierung kann durch die

Realisierung eines Dreischichten-Modells erreicht werden.

Die oberste Schicht, die Serviceschicht (engl. Service Layer), repräsentiert die bereits

vorgestellten drei Haupt-Cloud-Dienstmodelle SaaS, PaaS und IaaS, welche dem Kunden zur

Auswahl stehen. Diese Schicht dient dazu, CSC Zugang zu den entsprechenden Diensten

mittels geeigneter Zugangsschnittstellen (engl. Access Interface) zu gewähren. Wie in der

Grafik (Abb. 7) dargestellt, können die drei Dienstmodelle aufeinander aufbauen und eine

Hierarchie bilden. In diesem Fall basiert SaaS auf PaaS und PaaS auf IaaS. Diese Struktur ist

jedoch nicht unbedingt erforderlich. Die Softwaredienste können auf den

Infrastrukturdiensten oder direkt auf der nächsten Schicht, der Ressourcenabstraktions- und

Kontrollschicht liegen.

Die Zwischenschicht ist die Ressourcenabstraktions- und Kontrollschicht (engl. Resource

Abstraction and Control Layer). Sie beinhaltet Komponenten, die durch

Ressourcenabstraktion den Zugriff auf die physischen Ressourcen bereitstellen und verwalten.

Die Aufgabe dieser Komponenten ist es, die physischen Ressourcen sicher und effizient zu

verwalten. Beispiele für solche Komponenten sind Hypervisors, virtuelle Maschinen und

virtuelle Speichermedien. Der zweite Teil dieser Schicht – die Kontrollkomponente – besteht

aus Middleware-Elementen, welche die Ressourcenbelegung organisieren, den Zugang zu den

Ressourcen kontrollieren und die Ressourcennutzung überwachen.

Die unterste Schicht dieses Modells, die Schicht der physischen Ressourcen (engl. Physical

Resource Layer), umfasst alle physischen Komponenten zum Aufbau und Betrieb der

benötigten Infrastruktur. Dazu zählen die Hardware (Server, Speicher, Monitore), die

17

Netzwerkkomponenten (Router, Switches, Firewalls) und die IT-unterstützenden Elemente

wie Stromversorgung, Kühlung, Verkabelung, Beleuchtung und andere.

2.4.2 Cloud Service Management

Das Management der Cloud-Dienste umfasst sämtliche Aufgaben und Funktionen, welche für

den Betrieb und die Verwaltung derjenigen Dienste notwendig sind, die den Nutzern

angeboten werden. Diese Aufgaben und Funktionen können in drei Bereiche gruppiert

werden – Business Support, Beschaffung und Konfiguration, Portabilität und Interoperabilität

(vgl. [LTM⁺11], S. 14).

Business Support

Dieser Bereich beschäftigt sich mit der Verwaltung der kundenbezogenen Prozesse. Zu diesen

Prozessen gehören Kunden- und Kontaktmanagement, Verwaltung eines Dienste-Katalogs,

Erstellung von Angeboten und Bildung von Preisen, Erfassung von verbrauchten Ressourcen,

Auditierung, Berichterstellung und Abrechnung.

Beschaffung und Konfiguration (engl. Provisioning and Configuration)

Der zweite Bereich hat die Aufgabe, die Cloud so vorzubereiten und auszustatten, dass sie in

der Lage ist, Cloud-Dienste bereitzustellen (vgl. [LTM⁺11], S. 22). An dieser Stelle werden

Technologien implementiert, die eine automatisierte und schnelle Bereitstellung von neuen

Diensten/Ressourcen sowie deren automatische Konfiguration ermöglichen. Weitere

Teilaufgaben dieses Bereichs sind:

Überwachung und Berichterstellung. Dabei handelt es sich um die stetige

Überwachung der Cloud-Prozesse und -Ressourcen, um das Dokumentieren von deren

Zustand und Verhalten und um das Erstellen von Berichten. Die

Überwachungsmechanismen überprüfen das Einhalten definierter SLA und leiten

relevante Informationen an die Dienste, welche für die Abrechnungserstellung

zuständig sind, weiter ([AG10], S. 30).

Management von Service Level Agreements. SLA regeln die Dienstgüte (engl. Quality

of Service (QoS)) und die Folgerungen für den CSC, wenn der CSP diese nicht

erfüllen kann. Die Verwaltung der SLA beinhaltet das Definieren der SLA, das

Überwachen der Einhaltung der SLA und das Ausführen der vereinbarten Schritte

beim Auftreten von Störungen. Bei CC begrenzt sich dieser Prozess zur Zeit

vorwiegend auf das Definieren der angebotenen Verfügbarkeit und das Auszahlen

einer Gutschrift bei Verletzung der Vereinbarung.

18

Metering (Messen / Zählwerteerfassung). Hier werden geeignete Modelle zur Bildung

und Erfassung von Messwerten eingesetzt, mit dem Ziel, die Dienste messbar zu

machen und die Rechnungserstellung für die Kunden transparent zu gestalten.

Portabilität und Interoperabilität

Der dritte Bereich ist der Bereich der Portabilität und der Interoperabilität bei CC. Er ist

äußerst wichtig im Hinblick auf die Beseitigung bzw. die Minimierung der Abhängigkeit der

CSC von einem CSP.

Die Portabilität beschreibt die Möglichkeit Daten und Anwendungen zwischen mehreren

Clouds übertragen zu können und dabei Kosten und Störungen minimal zu halten. Es kann

zwischen Daten- und Systemportabilität unterschieden werden. Datenportabilität setzt voraus,

dass die Daten problemlos aus einer Anwendung exportiert und in eine neue importiert

werden können. Diese Eigenschaft spielt vor allem bei SaaS-Angeboten eine wichtige Rolle

und erfordert die Anwendung von Standarddatenformaten. Systemportabilität bezeichnet die

Eigenschaft der Systeme, Anwendungen, Dienste und deren Inhalte von einem CSP zu einem

anderen migrieren zu können sowie die Fähigkeit, vollständig gestoppte Instanzen virtueller

Maschinen oder Maschinenimages zwischen diversen Anbietern verschieben zu können.

Diese Eigenschaft muss bei IaaS-Angeboten gegeben sein. ([LTM⁺11], S. 15)

Die Interoperabilität bezieht sich auf die Fähigkeit verschiedener Systeme „möglichst

nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise

auszutauschen, ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig

sind“10

. Allgemein wird Interoperabilität durch den Einsatz gemeinsamer Standards

gewährleistet.

Viele Organisationen, deren Überlegungen darauf gerichtet sind, Cloud-Dienste intensiver zu

nutzen, bewerten diesen Bereich als problematisch. Sie befürchten ein so genanntes „Vendor

Lock-in“ – eine Situation, bei welcher „eine nicht einfach auflösbare Abhängigkeit von einem

Anbieter“ existiert ([BSI11], S.48). Laut [BSI11] kann zur Zeit die Portabilität zwischen

verschiedenen CSP nicht zugesichert werden. Einige Beispiele zu dieser Problematik sind:

Bis zum Jahr 2009 war es für Google App Engine Nutzer möglich, nur in der

Programmiersprache Python Anwendungen zu schreiben. Dafür war es notwendig,

Google spezifische API zu nutzen. Die in Python entwickelten Anwendungen konnten

nur in der Google-Infrastruktur gut funktionieren (vgl. [R09], S. 17-18).

10

http://de.wikipedia.org/wiki/Interoperabilit%C3%A4t (9.3.2012)

19

Ein auf Google App Engine entwickelter Cloud-Dienst kann einen Microsoft Azure

Datenbank-Dienst nicht nutzen (vgl. [BSI11], S. 48).

IaaS-Anbieter nutzen vorwiegend eigene Formate für virtuelle Maschinenimages. Bei

Amazon sind sowohl die API zur Steuerung der Cloud-Dienste als auch das Format

der virtuellen Images proprietär (vgl. [BSI11], S. 49).

Mangelnde Kompatibilität zwischen Amazon Simple Storage Service (Amazon S3)

und den Speicherlösungen von IBM, Google und Dell (Stand 2010) ([RR10], S. 158).

Amazon S3 nutzt ein eigenes S3 Protokoll sowie eigene Speichermechanismen ([R09],

S. 174]).

Amazons Simple Queue Service nutzt sein eigenes nicht-standardisiertes Protokoll

und Nachrichtenformat (Stand 2009, [R09], S. 174]).

Die Wichtigkeit dieses Bereichs wurde in der Zwischenzeit gut erkannt. Viele Organisationen

beschäftigen sich aktuell mit der Entwicklung geeigneter Standards zur Bewältigung von

Interoperabilitäts- und Portabilitätsproblemen beim CC. Einige Beispiele findet der Leser bei

[BSI11] und 11

.

2.4.3 Sicherheit und Datenschutz

Die letzten zwei Säulen in der Organisation eines CSP sind die Sicherheit und der

Datenschutz. Datenschutz bezeichnet den Schutz des Persönlichkeitsrechts des Einzelnen bei

dem Umgang mit seinen personenbezogenen Daten (vgl. § 1 Abs. 1 S. 1 BDSG) sowie den

Schutz seiner „Grundrechte und Grundfreiheiten und insbesondere … der Privatsphäre bei

der Verarbeitung personenbezogener Daten“ (Art. 1 Abs. der EU-Datenschutzrichtlinie). Die

Sicherheit bezieht sich auf die technischen und organisatorischen Maßnahmen, welche

getroffen werden müssen, um die Ressourcen und Systeme gegen unberechtigten Zugang und

Verwendung und Daten gegen zufällige oder unrechtmäßige Zerstörung sowie gegen

unerlaubte Zugriffe, Änderung, Weitergabe und Löschung zu schützen.

Bei CC gelten grundsätzlich die gleichen Sicherheitsanforderungen, z. B. Authentifizierung,

Autorisierung, Verfügbarkeit, Vertraulichkeit, Integrität, Identitätsmanagement, Monitoring

etc., wie bei einem herkömmlichen IT-Betrieb. Spezifisch beim CC ist jedoch, dass die

Gewährleistung der Sicherheit mit der Art des jeweiligen Bereitstellungs- und Servicemodells

zusammenhängt. Die Sicherung einer Private Cloud, welche ausschließlich von einer

Organisation verwendet wird, ist einfacher als die Sicherung einer Public Cloud, welche

11

http://www.searchdatacenter.de/themenbereiche/cloud/infrastruktur/articles/238205/ (9.3.2012)

20

Dienste und Ressourcen für eine unbegrenzte Anzahl von Nutzern bereitstellt. CSP, die SaaS

anbieten, müssen andere Sicherheitsmaßnahmen implementieren als CSP, welche IaaS zur

Verfügung stellen, da die zwei Modelle unterschiedliche Angriffspunkte auf die Systeme

aufweisen. [LTM⁺11]

Des Weiteren liegt die Gewährleistung der Datensicherheit bei CC in der Verantwortung aller

Beteiligten. Sowohl CSP als auch CSC und ISP müssen die notwendigen Maßnahmen treffen,

um wichtige Daten und Informationen zu schützen. In der Literatur wird deswegen an dieser

Stelle von gemeinsamer Verantwortung (engl. „shared responsibility“) gesprochen (vgl.

[LTMG⁺11], S. 16). Dabei ist zu beachten, dass geprüft werden muss, welche Maßnahmen

durch welche Partei am sinnvollsten zu realisieren sind und dass eine klare Trennung und

Zuordnung der Zuständigkeiten zwischen allen Beteiligten vorzunehmen ist, um

Missverständnisse zu vermeiden.

Die Gewährleistung des Datenschutzes vor allem bei Public Clouds ist auch eine große

Herausforderung. Dafür sind grundsätzlich die folgenden Gründe zu nennen:

Kundendaten sind prinzipiell sowohl von dem Personal des CSP als auch von

Subunternehmen, welche z. B. die Systeme für die Cloud-Dienste beim CSP warten,

zugänglich und können durch diese manipuliert werden.

Dadurch, dass dieselben physischen Ressourcen durch mehrere Nutzer geteilt werden,

werden die Daten unterschiedlicher Nutzer auf denselben Systemen gelagert und

verarbeitet. Beim Verdacht auf gesetzliche Verstöße gerichtet an den CSP oder an

einen anderen Nutzer, der seine Daten bei demselben CSP hostet, können Sicherheits-

und/oder Finanzbehörden Zugang zu allen durch den CSP verarbeiteten Daten

bekommen. [W10]

Die Verarbeitung bestimmter Kategorien von Daten (z. B. personenbezogene,

steuerrelevante, etc.) unterliegt besonderen gesetzlichen Bestimmungen, welche an

den Ort der Verarbeitung gebunden sind. CC ist dagegen grundsätzlich

grenzüberschreitend, d. h. die DV kann sich auf mehrere Länder und sogar Kontinente

erstrecken. Daraus folgt, dass ein international agierender CSP immer die jeweiligen

lokalen Gesetze berücksichtigen muss.

Das Thema Datenschutz bei CC wird im folgenden Kapitel ausführlich behandelt.

21

2.4.4 Zentrale Technologien bei Cloud Computing

Die Bereitstellung und Verwaltung von Cloud-Diensten setzt den Einsatz von Technologien,

welche hohe Automatisierung, Flexibilität, Transparenz, Effizienz und Sicherheit anbieten,

voraus. Dabei ist zu beachten, dass der Begriff Transparenz in der EDV das Verbergen von

Informationen und Aktivitäten bedeutet. Dem Nutzer ist bspw. nicht bekannt, auf welchen

Systemen er gerade arbeitet, wo genau er seine Daten speichert und wer noch dieselben

Anwendungen nutzt. Einige Ansätze erlauben außerdem, dass mehrere Nutzer unbemerkt

dieselben Daten verarbeiten können und dass Dateien heimlich von einem System zu einem

anderen migriert werden können.

Im Folgenden werden drei der wichtigsten Technologien beim CC erläutert.

Virtualisierung ist eine Methode zur Trennung einer physischen Ressource (z. B. Server,

Speicher, PC) in mehrere logisch isolierte Einheiten bzw. zur Zusammenfassung mehrerer

physischer Ressourcen zu einer logischen. Das geschieht mit Hilfe von Software, die direkt

auf der physischen Maschine oder auf dem darauf laufenden Betriebssystem (BS) installiert

wird und dadurch eine zusätzliche Schicht einfügt. Diese Zusatzschicht wird Hypervisor

genannt. Ihre Aufgabe ist es, eine hardwareunabhängige, abstrakte Umgebung zur Verfügung

zu stellen, die es erlaubt, die darunter liegenden physischen Ressourcen effizienter zu

verwenden. Beispiele für verbreitete Virtualisierungslösungen sind VMware, Xen, KVM und

Microsoft Hyper-V. Die Gründe für den Einsatz von Virtualisierung sind:

bessere Auslastung der vorhandenen physischen Ressourcen,

Installation unterschiedlicher Betriebssysteme auf einer Maschine,

Schaffen von Kompatibilität zwischen i. d. R. inkompatiblen Softwareprodukten (z. B.

Verwaltung von Microsoft Windows Anwendungen unter Linux) ([RR10], S. 98),

Isolieren des Betriebssystems und anderer Anwendungen von schlecht geschriebener,

fehlerhafter Software ([RR10], S. 98),

Senken von Hardware-Kosten sowie niedriger Stromverbrauch.

Virtualisierung kann weiterhin auf Netzwerke angewendet werden, wobei die vorhandenen

Netzwerkressourcen wiederum zu einer logisch-getrennten Einheit (ein virtuelles Netzwerk)

zusammengefügt werden. Das so entstandene virtuelle Netzwerk kann dann von dem Nutzer,

dem sie „gehört“, eigenständig konfiguriert und verwaltet werden. Diese Möglichkeit bietet

z. B. Amazon seinen Kunden unter dem Namen Amazon Virtual Private Cloud (Amazon

22

VPC)12

an. Eine andere Form der Netzwerkvirtualisierung, welche bei CC eingesetzt wird, ist

die Bereitstellung von Virtual Private Networks (VPN). VPN bezeichnet den Aufbau einer

gesicherten logischen Kommunikationsverbindung zwischen zwei Kommunikationspartnern

(bzw. Rechnern) über ein öffentliches, unsicheres Kommunikationsnetz (meist das Internet)13

.

VPN werden von CSP angeboten, um den Kunden eine sichere Verbindung zu den

Rechenzentren mit den Cloud-Diensten zu ermöglichen.

Lastverteilung (engl. Load Balancing) ist eine Methode zur Verteilung von Berechnungen

oder Anfragen „auf mehrere parallel arbeitende Systeme“ oder gleichartige Komponenten.

Die Lastverteilung kann unterschiedlich erfolgen, z. B. auf mehrere Prozessoren innerhalb

eines Rechners, auf mehrere Rechnern/Servern oder auf mehrere Rechnercluster.14

Sie kann

sowohl mit Hardware-basierten als auch mit Software-basierten Lösungen realisiert werden,

wobei die Hardware-basierten Lösungen viel schneller als die Software-basierten sind

([RR10], S. 93). Die Gründe für den Einsatz von Lastverteilung sind:

Optimierung der Nutzung von Ressourcen,

Reduzierung von Zugriffs- und Antwortzeiten,

Vermeidung von Systemüberlastung, wodurch die Ausfallsicherheit der Systeme

erhöht wird, und

Erhöhung der Datensicherheit durch redundante Datenhaltung.

Mandantenfähigkeit15

(engl. Multitenancy) – ist ein Verfahren in der Softwaretechnik, das

es mehreren Klienten (Mandanten) erlaubt, auf ein und dieselbe Anwendung unabhängig

voneinander zuzugreifen. Die Software ist so konstruiert, dass jeder Mandant nur Zugriff auf

die eigenen Daten hat. Er kann nur die eigenen Nutzer verwalten und „seine“ Anwendung in

gewisser Weise selber konfigurieren. Der Unterschied zur Virtualisierung besteht darin, dass

dieselbe Anwendung, die auf demselben Betriebssystem und derselben Hardware läuft, von

mehreren unabhängigen Nutzern verwendet wird.

Mandantenfähigkeit wird von allem bei SaaS eingesetzt. Sie ermöglicht das Teilen von

Ressourcen und Kosten zwischen einer Großzahl von Nutzern, spart Hardwareressourcen und

Lizenzen für Betriebssysteme und Datenbankmanagementsoftware. In Kombination mit

Servervirtualisierung sorgt sie für höhere Flexibilität und für bessere Performanz für die

Endnutzer [RR10 S. 54].

12

http://aws.amazon.com/de/vpc/ (5.5.2012) 13

http://de.wikipedia.org/wiki/Virtual_Private_Network (5.5.2012) 14

http://de.wikipedia.org/wiki/Lastverteilung (8.6.2012) 15

http://en.wikipedia.org/wiki/Multitenancy (7.2.2012)

23

3 Datenschutzrechtliche Aspekte bei Cloud Computing

Die vorwiegende Kategorie von Daten, die ein CSC bei seinem CSP verarbeitet, ist die

Kategorie der personenbezogenen Daten. Im Zusammenhang mit der Verwaltung von

entweder Personal, Kunden, Lieferanten oder Geschäftspartnern werden Daten wie Name,

Adresse und Telefonnummer sehr häufig erhoben und gespeichert. Der Umgang mit diesen

Daten ist in den unterschiedlichen Kontinenten und Ländern unterschiedlich geregelt. Zum

Vergleich: Während in der Europäischen Union und insbesondere in Deutschland strenge

gesetzliche Vorschriften für den Umgang mit personenbezogenen Daten existieren, sind

solche in den USA kaum vorhanden. Diese unterschiedlichen gesetzlichen Grundlagen führen

bei Cloud Computing zu einer Reihe von Problemen, da dabei häufig ein dauernder

Datenaustausch zwischen Parteien aus verschiedenen Ländern und Kontinenten stattfindet.

Dieses Kapitel hat zum Ziel, die vorhandenen gesetzlichen Vorschriften für die Verarbeitung

personenbezogener Daten in Europa und als Sonderfall in Deutschland vorzustellen und

daraus ableitend die Probleme, die zur Zeit die Verwendung grenzüberschreitender

Cloud-Dienste durch europäische Nutzer wesentlich erschweren, zu beschreiben.

3.1 Rechtslage in der EU / dem EWR

Wie bereits erwähnt, ist die Verarbeitung personenbezogener Daten in den EU-Ländern streng

geregelt. Die grundlegenden Vorschriften gibt an dieser Stelle die Richtlinie 95/46/EG des

Europäischen Parlaments und des Rates vom 24. Oktober 1995 zum Schutz natürlicher

Personen bei der Verarbeitung personenbezogener Daten und den freien Datenverkehr16

(auch Datenschutzrichtlinie genannt) [95/46/EG]. Sie findet Anwendung nicht nur auf die

EU-Mitgliedstaaten, sondern auch auf die Länder Liechtenstein, Norwegen und Island,

welche zusammen mit den EU-Mitgliedstaaten den Europäischen Wirtschaftsraum (EWR)

bilden. Ziele dieser Richtlinie sind vor allem eine einheitliche Rechtsgrundlage zu schaffen,

um die Zusammenarbeit und den sozialen und wirtschaftlichen Fortschritt der Europäischen

Union zu fördern und zu erleichtern, und gleichzeitig die Grundrechte und -freiheiten der

Bevölkerung der Mitgliedstaaten zu schützen (vgl. Erwägungsgründe Nr. 2 bis 8). Ein

weiteres Ziel der Richtlinie ist, den Datenaustausch mit bzw. die Datenübermittlung an

Länder außerhalb der EU / des EWR zu regeln.

16

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX%3A31995L0046%3Ade%3Ahtml

24

Die Richtlinie 95/46/EG definiert Mindestanforderungen an den Schutz personenbezogener

Daten von EU-Bürgern und -Bürgerinnen bei deren Verarbeitung. Sie gilt gem. Art. 3 Abs. 2

nicht für Tätigkeiten der Justiz, der öffentlichen und staatlichen Sicherheit und der

Landesverteidigung. Sie gilt für Niederlassungen fremder Unternehmen innerhalb der EU –

dabei ist das einzelstaatliche Recht, dort wo die Niederlassung ihre Sitz hat, zu beachten (vgl.

Art. 4 Abs. 1 a)) – und für Niederlassungen von EU-Firmen außerhalb der EU, wenn diese für

die Datenverarbeitung auf Mittel zurückgreifen, die sich in einem Mitgliedstaat befinden

(vgl. Art. 4 Abs. 1 c)).

3.1.1 Personenbezogene, anonymisierte und besondere Kategorien

personenbezogener Daten

Die Datenschutzrichtlinie regelt den Umgang mit personenbezogenen Daten, welche nach

bestimmten Kriterien strukturiert sind (vgl. Erwägungsgrund Nr. 27). Personenbezogene

Daten sind gem. Art. 2 a) alle Informationen über eine bestimmte oder bestimmbare

natürliche Person, die zu der direkten oder indirekten Identifizierung dieser Person verwendet

werden können. Beispiele für solche Informationen sind Kennnummer oder Elemente, die

Ausdruck der physischen, physiologischen, psychischen, wirtschaftlichen, kulturellen oder

sozialen Identität sind.

Daten, die so anonymisiert sind, dass die Identifizierung der betroffenen Personen nicht mehr

möglich ist, sind gem. Erwägungsgrund Nr. 26 keine personenbezogenen Daten im Sinne

dieser Richtlinie.

Die Verarbeitung besonderer (auch sensibler) Kategorien personenbezogener Daten ist

gem. Art. 8 Abs. 1 grundsätzlich verboten. Zu diesen Kategorien zählen Daten, aus denen die

rassische und ethnische Herkunft, politische Meinungen, religiöse oder philosophische

Überzeugungen oder die Gewerkschaftszugehörigkeit hervorgehen sowie Daten über

Gesundheit oder Sexualleben. Art. 8 Abs. 2 bis 4 erlauben allerdings die Verarbeitung solcher

Daten unter bestimmten Voraussetzungen, vor allem, wenn der Betroffene seine Zustimmung

ausdrücklich gegeben hat, eine arbeitsrechtliche Grundlage existiert oder zum Schutz

lebenswichtiger Interessen der betroffenen Person oder eines Dritten, sofern die betroffene

Person aus physischen oder rechtlichen Gründen nicht in der Lage ist, ihre Einwilligung zu

geben.

3.1.2 Rechtsmäßigkeit der Datenverarbeitung

Erwägungsgrund Nr. 28 sieht vor, dass

25

die DV gegenüber den betroffenen Personen nach Treu und Glauben erfolgen muss.

Das bedeutet, die betroffenen Personen müssen von der Verarbeitung erfahren können

und müssen über die Bedingungen der Datenerhebung informiert werden, wenn die

Erhebung geschieht (Erwägungsgrund Nr. 38).

die Zwecke der DV eindeutig und rechtmäßig und bei der Datenerhebung festgelegt

sein müssen, und

die Weiterverarbeitung der erhobenen Daten den bei der Erhebung festgelegten

Zwecken entsprechen muss.

Gem. Art. 7 ist die DV rechtmäßig, wenn

die betroffenen Personen ihre Einwilligung gegeben haben,

vertragliche oder gesetzliche Verpflichtungen zu erfüllen sind,

für die betroffenen Personen lebenswichtige Interessen zu schützen sind,

ein öffentliches Interesse wahrzunehmen ist oder

ein Interesse Dritter, das nicht den Rechten und Freiheiten der betroffenen Personen

entgegensteht, zu verwirklichen ist.

Unter Datenverarbeitung oder Verarbeitung von Daten werden gem. Art. 2 b) der

Richtlinie sämtliche Vorgänge, welche auf die Daten ausgeführt werden können wie Erheben,

Speichern, Organisieren, Aufbewahren, Ändern, Auslesen, Abfragen, Weitergeben, Sperren,

Löschen, Vernichten und andere verstanden.

Die Aufbewahrung der erhobenen Daten in einer Form, die die Identifizierung der

betroffenen Personen ermöglicht, ist nach Art. 6 Abs. 1 e) nur für den Zeitraum, welcher für

die Realisierung der vereinbarten Zwecke notwendig ist, zulässig.

3.1.3 Pflichten der für die Verarbeitung Verantwortlichen und Rechte der

Betroffenen

Erwägungsgrund Nr. 25 fasst die Pflichten der für die Verarbeitung Verantwortlichen und

die Rechte der betroffenen Personen (d. h. Personen, deren Daten Gegenstand von

Verarbeitungen sind, auch die Betroffenen) zusammen. Zu den ersten zählen:

die Datenqualität (definiert im Art. 6 ),

die technische Sicherheit,

die Meldung bei der Kontrollstelle (definiert im Art. 18) und

die Voraussetzungen, unter denen eine Verarbeitung vorgenommen werden kann

(definiert im Art. 7).

26

Die Rechte der Betroffenen umfassen:

das Recht auf Information, zumindest über die Identität des für die Verarbeitung

Verantwortlichen, über die Zwecke der Verarbeitung und ggf. über Empfänger der

Daten und das Bestehen von Auskunfts- und Berichtigungsrechten (gem. Art. 10 und

11);

das Auskunftsrecht über

o die verarbeiteten Daten, Zweck der Verarbeitung und Empfänger der Daten

o den logischen Aufbau der Verarbeitung sowie über

o Berichtigung, Sperrung und Löschung unvollständiger oder unrichtiger Daten

(Art. 12);

das Recht auf Zugang zu den Daten,

das Recht auf Korrektur und

das Widerspruchsrecht gegen die Verarbeitung (definiert in Art. 14).

Um den Schutz der betroffenen Personen bei der Verarbeitung personenbezogener Daten zu

gewährleisten, muss bei dem für die Verarbeitung Verantwortlichen gem. Art. 17 Abs. 1 ein

angemessenes Schutzniveau geschaffen werden. Das setzt die Umsetzung geeigneter

technischer und organisatorischer Maßnahmen, die den Stand der Technik berücksichtigen,

voraus.

Der für die Verarbeitung Verantwortliche ist gem. Art. 2 d) die natürliche oder juristische

Person, Behörde, Einrichtung oder Stelle, die allein oder gemeinsam mit anderen über die

Zwecke und Mittel der Verarbeitung entscheidet. Im Sinne von CC ist der Verantwortliche

der CSC, da er sich für die Nutzung eines Cloud-Dienstes für die Verarbeitung entscheidet.

Datenschutzrechtlich kann Cloud Computing entweder als eine Auftragsdatenverarbeitung,

als eine Weitergabe von Daten an Dritte oder, wenn die DV außerhalb der EU / des EWR

stattfindet, als eine Datenübermittlung in Drittländer betrachtet werden [IT-G11].

3.1.4 Datenverarbeitung im Auftrag

Im Falle einer Datenverarbeitung im Auftrag sieht Art. 17 Abs. 2 vor, dass der für die

Verarbeitung Verantwortliche einen Auftragsverarbeiter auszuwählen hat, der auch ein gem.

Art. 17 Abs. 1 angemessenes Schutzniveau aufweist und dass der für die Verarbeitung

Verantwortliche sich von den Gewährung des notwendigen Schutzniveaus überzeug muss.

Bei dieser Form der DV ist der Auftragsverarbeiter bzw. der Auftragnehmer (i. S. v. CC der

27

CSP) an den für die Verarbeitung Verantwortlichen bzw. den Auftraggeber (i. S. v. CC der

CSC) rechtlich gebunden. Der Auftragnehmer darf nur auf Weisung des Auftraggebers

handeln (vgl. Art. 17 Abs. 3). Weiterhin muss der Auftragnehmer die technischen und

organisatorischen Maßnahmen, die zur Gewährung des Datenschutzes notwendig sind, nach

Maßgabe der Rechtsvorschriften des Mitgliedstaates, in dem er seinen Sitz hat, treffen (vgl.

Art. 17 Abs. 3). Sitzt der Auftragnehmer außerhalb der EU oder des EWR, sind dann andere

besondere Regelungen zu berücksichtigen (s. DV in Drittländern unten). Art. 17 Abs. 4

schreibt ferner vor, dass die datenschutzrelevanten Aspekte des Vertrages und die

Anforderungen in Bezug auf die geeigneten technischen und organisatorischen Maßnahmen

zu dokumentieren sind.

3.1.5 Weitergabe von Daten an Dritte

Die Weitergabe von Daten an Dritte ist zunächst zulässig, wenn die oben erläuterten

Grundsätze der Rechtmäßigkeit der DV nach Art. 7 erfüllt sind, da die Datenweitergabe an

erster Stelle eine Form der DV ist (gem. Art. 2 b)). Weiterhin gilt: die Datenweitergabe an

Dritte ist rechtmäßigt, wenn sie bei der Datenerhebung festgelegt wurde (vgl.

Erwägungsgrund Nr. 28) oder, wenn spätestens bei der erstmaligen Weitergabe der Daten an

Dritte alle betroffenen Person darüber informiert sind (vgl. Erwägungsgrund Nr. 39).

Erwägungsgrund Nr. 30 S. 2 sieht außerdem vor, dass weitere Bedingungen definiert werden

können (dies ist dem einzelstaatlichen Recht überlassen), unter denen eine Weitergabe von

Daten an Dritte für Geschäftszwecke erlaubt ist. Dritter ist gem. Art. 2 f) jede natürliche oder

juristische Person oder Stelle, außer der betroffenen Person, dem für die Verarbeitung

Verantwortlichen und dem Auftragsverarbeiter (bei einer Verarbeitung im Auftrag). I. S. v.

CC wäre der Dritte der CSP.

3.1.6 Übermittlung personenbezogener Daten in Drittländer

Die für die beiden Formen der DV – DV im Auftrag und Weitergabe von Daten an Dritte –

vorgestellten Vorschriften gelten allerdings nur sofern die DV innerhalb der EU / des EWR

stattfindet. Geht die Verarbeitung über diese geographischen Grenzen hinaus, dann handelt es

sich um eine Übermittlung personenbezogener Daten in Drittländer. Diese ist gem.

Art. 25 Abs.1 erlaubt, wenn das Drittland, an das die Daten übermittelt werden, ein

angemessenes Schutzniveau aufweist. Ob diese Bedingung erfüllt ist, kann gem. Art. 25

Abs. 6 die EU-Kommission feststellen. Gem. Art. 25 Abs. 2 ist die Angemessenheit des

Schutzniveaus insbesondere unter Berücksichtigung der Art der Daten, der

28

Zweckbestimmung und der Dauer der geplanten Verarbeitung, des Herkunfts- und

Endbestimmungslandes und der in dem betreffenden Drittland geltenden Rechtsnormen,

Standesregeln und Sicherheitsmaßnahmen zu beurteilen. Die EU-Kommission hat bisher ein

angemessenes Schutzniveau für die Länder Schweiz, Kanada, Argentinien, Guernsey, Isle of

Man und Israel festgestellt17

. Ein angemessenes Schutzniveau ist auch anzunehmen, wenn die

Daten an einen Empfänger aus den USA übermittelt werden, der dem sog. Safe Harbor

Abkommen beigetreten ist [00/520/EG]. Diese Annahme ist jedoch umstritten, da es sich bei

diesem Abkommen um die Einhaltung selbst gesetzter Datenschutzrichtlinien handelt, die

nicht unbedingt den Vorschriften der EU-Richtlinie entsprechen (siehe dazu Kapitel 3.3.6).

Besitzt das Drittland kein angemessenes Schutzniveau, dann ist die DV in diesem Land nur

mit der expliziten Einwilligung der Betroffenen (Art. 26 Abs. 1 a)) oder unter bestimmten

Voraussetzungen (diese sind im Art. 26 Abs. 1 b) bis f) beschrieben) zugelassen. Zulässig ist

außerdem die DV in Drittländern ohne angemessenes Schutzniveau gem. Art. 26 Abs. 2 auch

dann, wenn der für die Verarbeitung Verantwortliche ausreichend garantieren kann, dass er

die Privatsphäre sowie die Grundrechte und -freiheiten der betroffenen Personen schützen

kann. Für diese Fälle existieren besondere EU-Standardvertragsklauseln18

, welche der für die

Verarbeitung Verantwortliche mit der Stelle, an die er die Daten weitergibt, abzuschließen

hat.

3.1.7 Kontrollstellen

Die EU-Mitgliedstaaten sind verpflichtet, die in dieser Richtlinie definierten Vorschriften in

einzelstaatliches Recht umzusetzen. Gem. Art. 28 Abs. 1 sind die EU-Mitgliedstaaten

außerdem verpflichtet, eine oder mehrere öffentliche unabhängige Kontrollstellen

einzurichten, welche die Anwendung der im einzelstaatlichen Recht umgesetzten Vorschriften

überwachen müssen. Diese Kontrollstelle hat eine Reihe von Aufgaben und Rechten,

insbesondere das Recht auf Zugang zu Daten, die Gegenstand von Verarbeitungen sind, das

Recht auf Einholung aller für die Erfüllung ihres Kontrollauftrags erforderlichen

Informationen (gem. Art. 28 Abs. 3) und das Recht, auf Antrag jeder Person, die

Rechtmäßigkeit einer Verarbeitung zu überprüfen (gem. Art. 28 Abs. 4).

3.1.8 EU-Datenschutzrichtlinie für elektronische Kommunikation

Zusätzlich zu der allgemeinen EU-Datenschutzrichtlinie existiert auch die Richtlinie

2002/58/EG des Europäischen Parlaments und des Rates vom 12. Juli 2002 über die

17

http://de.wikipedia.org/wiki/Datenschutz#Internationale_Regelungen (1.5.2012) 18

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:039:0005:01:DE:HTML

29

Verarbeitung personenbezogener Daten und den Schutz der Privatsphäre in der

elektronischen Kommunikation (auch Datenschutzrichtlinie für elektronische Kommunikation)

[02/58/EG]. Sie stellt gem. Art. 1 Abs. 2 eine Detaillierung und Ergänzung der allgemeinen

EU-Datenschutzrichtlinie konkret für den Bereich der elektronischen Kommunikation dar und

dient gem. Art. 1 Abs. 1 der Harmonisierung der gesetzlichen Vorschriften zum Schutz der

Grundrechte und -freiheiten natürlicher Personen, sowie den berechtigten Interessen von

juristischen Personen bei der Verarbeitung personenbezogener Daten in öffentlichen

Kommunikationsnetzen.

Diese Richtlinie gibt Definitionen und Regelungen zu Daten und Software, welche die

meisten CSP für unterschiedliche Zwecke verarbeiten bzw. verwenden (vgl. dazu die

Datenschutzerklärungen von z. B. Google oder Microsoft19

). Dazu gehören Verkehrs- und

Standortdaten (s. Art. 2 b) und c)) sowie Instrumente wie Cookies, die auf die Endgeräte von

Nutzern installiert werden, um Informationen aus den Geräten abzulesen oder die Aktivitäten

des Nutzers nachzuverfolgen. Ferner gibt sie Vorschriften zu der Verwendung elektronischer

Kontaktdaten für Zwecke der Direktwerbung (s. Art. 13) sowie zu der Gewährleistung der

Netzsicherheit durch die Betreiber öffentlich zugänglicher elektronischer

Kommunikationsdienste (s. Art. 4). Allerdings gilt die Richtlinie gem. Art. 3 Abs. 1 nur,

wenn personenbezogene Daten verarbeitet werden, um öffentlich zugängliche elektronische

Kommunikationsdienste in öffentlichen Kommunikationsnetzen bereitzustellen.

Elektronische Kommunikationsdienste sind gem. Art. 1 c) der Rahmenrichtlinie

[02/21/EG] Dienste, die ganz oder überwiegend in der Übertragung von Signalen über

elektronische Kommunikationsnetze (dazu gehört auch das Internet) bestehen, einschließlich

Telekommunikations- und Übertragungsdienste in Rundfunknetzen, jedoch ausgenommen

Dienste, die Inhalte über elektronische Kommunikationsnetze und -dienste anbieten oder eine

redaktionelle Kontrolle über sie ausüben. Beispiele für elektronische Kommunikationsdienste

nach dieser Definition sind Telefonie, E-Mail-Übertragung, Internetzugang (vgl.

Erwägungsgrund Nr. 10 der Rahmenrichtlinie). Cloud-Dienste zielen dagegen nicht ganz oder

überwiegend darauf ab, Signale zu übertragen, sondern Software, Rechen- oder

Speicherkapazitäten durch das Internet zur Verfügung zu stellen, so dass sie nicht dem

Anwendungsbereich dieser Richtlinie zugeordnet werden können.

19

http://www.google.com/intl/de/policies/privacy/ , http://privacy.microsoft.com/DE-DE/fullnotice.mspx#EJB

30

3.2 Die Rechtslage in Deutschland

In der Bundesrepublik Deutschland findet die Richtlinie 95/46/EG ihre Umsetzung in dem

Bundesdatenschutzgesetz. Es behandelt die Fälle, in welchen die DV durch eine öffentliche

und eine nicht-öffentliche Stelle durchgeführt wird, separat. Von größerem Interesse für diese

Arbeit sind die Fälle, wenn die DV von nicht-öffentlichen Stellen realisiert wird, da die

Angebote der international agierenden Public CSP vorwiegend an kleine und mittlere private

Unternehmen gerichtet sind, die in der Regel über wenig rechtliches und technisches Wissen

verfügen [W10].

Das BDSG definiert allgemeine und minimale Anforderungen an den Schutz

personenbezogener Daten in Deutschland. Sie gilt gem. § 1 Abs. 3 nur für die Fälle, die nicht

durch ein anderes, spezifisches Gesetz geregelt sind. Gem. § 1 Abs. 5 S. 1 findet BDSG keine

Anwendung, wenn die für die Verarbeitung verantwortliche Stelle außerhalb Deutschlands

und innerhalb der EU / des EWR ihren Sitz hat (dann gilt gemäß der EU-

Datenschutzrichtlinie das jeweilige staatliche Recht), es sei denn die DV erfolgt durch eine

Niederlassung in Deutschland. Das Gesetz gilt aber, wenn eine verantwortliche Stelle

außerhalb der EU / des ERW ihren Sitz hat und Daten in Deutschland erhebt, verarbeitet oder

nutzt (vgl. § 1 Abs. 5 S. 2).

Da das BDSG im Großen und Ganzen die Vorschriften umsetzt, die bereits im Kapitel 3.1

vorgestellt wurden, werden im Folgenden nur die Bestimmungen erläutert, welche über diese

Vorschriften hinausgehen.

3.2.1 Begriffsbestimmungen nach BDSG

Während die Richtlinie 95/46/EG sämtliche Vorgänge, welche auf personenbezogene Daten

ausgeführt werden können, unter den einheitlichen Begriff Verarbeitung zusammenfasst,

unterscheidet das BDSG zwischen Verarbeiten, Erheben und Nutzen. Verarbeiten ist gem.

§ 3 Abs. 4 lediglich das Speichern (einschließlich das Erfassen, Aufnehmen oder

Aufbewahren), Verändern, Übermitteln, Sperren und Löschen von Daten. Erheben ist nach

§ 3 Abs. 3 das Beschaffen von Daten. Nutzen ist gem. § 3 Abs. 5 jede Verwendung

personenbezogener Daten, soweit es sich nicht um Verarbeitung handelt.

Der Begriff der automatisierten Verarbeitung bezieht sich gem. § 3 Abs. 2 wiederum auf

alle drei Aktivitäten – auf die Erhebung, die Verarbeitung und die Nutzung

personenbezogener Daten unter Einsatz von DV-Anlagen.

31

Unterschiede existieren auch in der Definition für die verantwortliche Stelle. Gem. § 3

Abs. 7 BDSG ist dies jede Person oder Stelle, die personenbezogene Daten für sich selbst

erhebt, verarbeitet oder nutzt oder dies durch andere im Auftrag vornehmen lässt. Ob nach

BDSG die verantwortliche Stelle auch über die Zwecke und Mittel der DV entscheidet wird

nicht explizit definiert.

Ein weiterer wichtiger Begriff im BDSG ist Pseudonymisieren. Unter Pseudonymisieren

wird gem. § 3 Abs. 6a das Ersetzen des Namens und anderer Identifikationsmerkmale durch

ein Kennzeichen, um die Bestimmung einer Person auszuschließen oder wesentlich zu

erschweren, verstanden

3.2.2 Datenvermeidung und Datensparsamkeit

Der Grundsatz der Datenvermeidung und Datensparsamkeit besagt, dass die DV und die

Auswahl und Gestaltung von DV-Systemen an dem Ziel auszurichten sind, so wenig

personenbezogene Daten wie möglich zu erheben, zu verarbeiten oder zu nutzen (§ 3a). Als

geeignete Maßnahmen für die Erfüllung dieses Grundsatzes werden an dieser Stelle die

Anonymisierung und die Pseudonymisierung personenbezogener Daten angesehen, soweit das

nach dem Verwendungszweck möglich ist. Während anonymisierte Daten

datenschutzrechtlich nicht mehr als personenbezogen gelten, behalten pseudonymisierte

Daten ihren Personenbezug, da die Identifizierung der betroffenen Person immer noch

möglich ist, und bleiben unter dem Schutz des BDSG [IT-G11].

3.2.3 Technische und organisatorische Maßnahmen zur Gewährleistung des

Datenschutzes

In Bezug auf die technischen und organisatorischen Maßnahmen, die getroffen werden

müssen, um ein angemessenes Schutzniveau für eine automatisierte DV zu gewährleisten, legt

das BDSG folgende Vorschriften fest (vgl. Anlage (zu § 9 S. 1) BDSG):

1) Zutrittskontrolle – die DV-Anlagen sind vor unbefugtem Zutritt zu schützen,

2) Zugangskontrolle – das Nutzen der DV-Systeme von Unbefugten ist zu verhindern,

3) Zugriffskontrolle – nur berechtigte Personen müssen auf die Daten zugreifen können und

diese lesen oder manipulieren,

4) Weitergabekontrolle – Daten dürfen nicht bei der elektronischen Übertragung oder

während ihres Transports oder ihrer Speicherung auf Datenträgern unbefugt gelesen,

kopiert, verändert oder entfernt werden können und es muss überprüft und festgestellt

32

werden können, an welchen Stellen eine Übermittlung durch Einrichtungen zur

Datenübertragung vorgesehen ist,

5) Eingabekontrolle – es muss nachträglich überprüft und festgestellt werden können, ob

und von wem personenbezogene Daten in DV-Systeme eingegeben, verändert oder aus

diesen entfernt worden sind,

6) Auftragskontrolle – es ist zu gewährleisten, dass personenbezogene Daten, die im

Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers

verarbeitet werden,

7) Verfügbarkeitskontrolle – die Daten müssen gegen zufällige Zerstörung oder Verlust

geschützt sein,

8) Trennungskontrolle – es ist zu gewährleisten, dass zu unterschiedlichen Zwecken

erhobene Daten getrennt verarbeitet werden.

Für die Realisierung der Vorschriften 2) bis 4) sieht das BDSG als geeignete Maßnahme die

Verwendung von dem Stand der Technik entsprechenden Verschlüsselungsverfahren. Weitere

geeignete technische und organisatorische Maßnahmen für die Realisierung der aufgezählten

Gebote sind Vergabe von Rechten und Rechteverwaltung, Einsatz von Passwörtern,

Protokollieren von Zugriffen und Transaktionen, Einsatz Unterbrechungsfreier

Stromversorgung, Sicherung der Daten auf tragbaren Medien, redundante Speicherung und

Systemauslegung und andere (vgl. [TG-11]).

3.2.4 Datenschutzaudit

§ 9a sieht vor, dass mithilfe eines bundesweiten Datenschutzaudits DV-Stellen und Anbieter

von DV-Systemen und -Programmen ihre Datenschutzkonzepte und technische Einrichtungen

von unabhängigen und zugelassenen Gutachtern prüfen und bewerten lassen können. Das

würde zur Verbesserung des Datenschutzes und der Datensicherheit bei den Betroffenen

führen. Ein solches bundesweites Audit existiert bisher nicht (vgl. [BDSGa], S. 32). In der

Praxis sind jedoch zahlreiche national und international geltende Auditierungsverfahren

entstanden, die dieselben Aufgaben und Ziele erfüllen sollten. Diese Verfahren unterliegen

allerdings der laufenden Kritik und sind mit Vorsicht zu betrachten.

3.2.5 Beauftragter für den Datenschutz

Sofern eine nicht-öffentliche Stelle eine automatisierte DV vornimmt, ist diese gem. § 4f

Abs. 1 verpflichtet, einen Beauftragten für den Datenschutz (auch Datenschutzbeauftragter)

zu bestellen, wenn

33

mindestens 10 Personen mit der DV ständig beschäftigt sind, oder

sie geschäftsmäßig zum Zweck der Übermittlung oder der anonymisierten

Übermittlung erfolgt, oder

sie zum Zweck der Markt- oder Meinungsforschung erfolgt, oder

sie eine Vorabkontrolle erfordert, weil besonders risikoreiche Daten verarbeitet

werden.

§ 4f Absätze 2 bis 5 und § 4g definieren detailliert die Arbeit eines Datenschutzbeauftragten.

3.2.6 Datenverarbeitung im Auftrag

Die Datenverarbeitung im Auftrag ist in § 11 BDSG geregelt. Gem. Abs. 1 bleibt der

Auftraggeber bei dieser Form der DV der rechtlich Verantwortliche für den Schutz der

betroffenen personenbezogenen Daten. Abs. 2 S. 2 sieht vor, dass der Auftrag zwischen

Auftraggeber (der CSC) und Auftragnehmer (der CSP) schriftlich zu erteilen ist und dass er

mindestens die folgenden 10 Punkte enthält:

1) Gegenstand und Dauer des Auftrags,

2) Umfang, Art und Zweck der vorgesehenen Erhebung, Verarbeitung oder Nutzung von

Daten, wie die Art der Daten und der Kreis der Betroffenen,

3) die besonderen für den Fall zu treffenden technischen und organisatorischen Maßnahmen,

4) die Fälle in denen Daten zu berichtigen, zu löschen oder zu sperren sind,

5) die nach Abs. 4 bestehenden Pflichten des Auftragnehmers, insbesondere die von ihm

vorzunehmenden Kontrollen,

6) die etwaige Berechtigung zur Begründung von Unterauftragsverhältnissen,

7) die Kontrollrechte des Auftraggebers und die entsprechenden Duldungs- und

Mitwirkungspflichten des Auftragnehmers,

8) mitzuteilende Verstöße des Auftragnehmers oder der bei ihm beschäftigten Personen

gegen Vorschriften zum Schutz personenbezogener Daten oder gegen die im Auftrag

getroffenen Festlegungen,

9) der Umfang der Weisungsbefugnisse, die sich der Auftraggeber gegenüber dem

Auftragnehmer vorbehält,

10) die Rückgabe überlassener Datenträger und die Löschung der beim Auftragnehmer

gespeicherten Daten nach Beendigung des Auftrags.

Gem. Abs. 2 S. 4 muss sich der Auftraggeber vor Beginn der DV und dann regelmäßig von

der Einhaltung der beim Auftragnehmer getroffenen technischen und organisatorischen

Maßnahmen überzeugen und das Ergebnis dokumentieren. Weiterhin sieht Abs. 5 vor, dass

34

dieser Paragraph auch die Fälle betrifft, wenn die Prüfung oder Wartung automatisierter

Verfahren oder DV-Anlagen durch andere Stellen im Auftrag vorgenommen wird und dabei

ein Zugriff auf personenbezogene Daten nicht ausgeschlossen werden kann. Das bedeutet, der

Paragraph gilt auch für Subunternehmen. Diese Regelung ist i. S. v. CC sehr wichtig, da es in

der Praxis selten vorkommt, dass ein CSP seine Dienste völlig selbständig bereitstellt, pflegt

und wartet. Gem. Abs. 4 droht dem Auftragnehmer ein Bußgeld in Höhe von bis zu 300.000 €

(vgl. §43 Abs. 3), wenn er nicht rechtskonform handelt.

3.2.7 Übermittlung von personenbezogenen Daten

Wenn die Voraussetzungen für eine Auftragsdatenverarbeitung nicht gegeben sind, dann liegt

eine Datenübermittlung vor. Übermitteln ist nach § 3 Abs. 4 Nr. 3 das Bekanntgeben

personenbezogener Daten an einen Dritten, so dass die Daten an den Dritten weitergegeben

werden oder der Dritte zur Einsicht oder zum Abruf bereitgehaltene Daten einsieht oder

abruft. Dritter ist nach § 3 Abs. 8 S. 2 und 3 BDSG auch ein Auftragsdatenverarbeiter, der

außerhalb der EU / des EWR personenbezogene Daten erhebt, verarbeitet oder nutzt. Das

bedeutet, dass sofern die DV außerhalb der EU / des EWR stattfindet, dann sind die folgenden

Vorschriften zu beachten.

Allgemein ist die Datenübermittlung gem. § 4 Abs. 1 (wie bei der EU-Datenschutzrichtlinie)

nur zulässig, wenn eine Rechtsvorschrift besteht oder der Betroffene seine Einwilligung

gegeben hat. Sofern die Übermittlung auf der Einwilligung der Betroffenen beruht, dann sind

die Vorschriften in § 4a zu beachten. Es besteht nach § 28 BDSG jedoch auch die

Möglichkeit, personenbezogene Daten für die Erfüllung eigener Geschäftszwecke legal zu

übermitteln. Dafür definiert das Gesetz folgende drei Fälle:

1) § 28 Abs. 1 Nr. 1: Zwischen Betroffenen und der verantwortlichen Stelle existiert ein

Geschäftsvertrag und die Nutzung eines Cloud-Dienstes ist erforderlich, um den Vertrag

zu begründen, zu erfüllen oder zu beenden.

2) § 28 Abs. 1 Nr. 2: Sind die Voraussetzungen unter 1) nicht gegeben, dann muss zunächst

die Übermittlung für die Wahrung berechtigter Interessen der verantwortlichen Stelle

erforderlich sein. Ferner muss in diesem Fall das schutzwürdige Interesse der Betroffenen

gesichert werden. Das schutzwürdige Interesse der Betroffenen gilt als gesichert, sofern

der CSP das gleiche Datenschutzniveau garantieren kann wie die verantwortliche (in

diesem Fall auch die übermittelnde) Stelle, der Betroffene seine Rechte auch beim CSP

„auf einfache Weise geltend machen kann“ und gewährleistet ist, dass der CSP „die Daten

35

nur im Rahmen der festgelegten Zweckbestimmungen verarbeitet und nutzt“ (vgl.

[BSI11], S. 63).

3) § 28 Abs. 1 Nr. 3: Die Daten sind allgemein zugänglich oder die verantwortliche Stelle

durfte sie veröffentlichen und das schutzwürdige Interesse der Betroffenen ist wie unter

Punkt 2) gesichert.

Gem. §28 Abs. 5 dürfen die für die Erfüllung eigener Geschäftszwecke übermittelten Daten

durch den Dritten (bzw. des CSP) nur für die Zwecke verwendet werden, für die sie

übermittelt worden sind. Für die Übermittlung besonderer Arten personenbezogenen Daten

für eigene Geschäftszwecke existieren weitere besondere Regelungen (vgl. dazu § 28 Abs. 6).

3.2.8 Datenverarbeitung außerhalb der EU / des EWR

Sofern die DV außerhalb der EU / des EWR stattfindet, müssen zusätzlich zu den im Kapitel

3.2.7 beschriebenen Vorschriften, auch die §§ 4b und 4c berücksichtigt werden. Diese

entsprechen größtenteils den bereits vorgestellten Regeln der Richtlinie 95/46/EG zur

Übermittlung personenbezogener Daten in Drittländer. Einen Unterschied macht die

Erlaubnis nach § 4c Abs. 2 zur Übermittlung personenbezogener Daten an Drittländer, wenn

mittels verbindlicher Unternehmensregelungen der Schutz der Daten garantiert wird. Dabei

wird aber diskutiert, ob diese Bestimmung mit der EU-Datenschutzrichtlinie konform ist und

wie dadurch die Rechtsverbindlichkeit für die Betroffenen sichergestellt werden kann

[DG06].

3.2.9 Unrechtmäßige Kenntniserlangung von Daten

Gem. § 42a BDSG ist die verantwortliche Stelle verpflichtet, sofern sie eine unrechtmäßige

Kenntniserlangung feststellt, der zuständigen Aufsichtsbehörde sowie den Betroffenen den

Vorfall unverzüglich mitzuteilen. Eine derartige Kenntniserlangung tritt ein, wenn besondere

Arten personenbezogener Daten (vgl. § 3 Abs. 9) oder personenbezogene Daten, die einem

Berufsgeheimnis unterliegen, sich auf strafbare Handlungen oder Ordnungswidrigkeiten oder

den Verdacht strafbarer Handlungen oder Ordnungswidrigkeiten beziehen oder zu Bank- und

Kreditkartenkonten unrechtmäßig übermittelt oder auf andere Weise Dritten unrechtmäßig zur

Kenntnis gelangt sind, und dabei die Rechte oder die schutzwürdigen Interessen der

Betroffenen bedeutend verletzt werden können. Sofern die Anzahl der Betroffenen so hoch

ist, dass das Informieren jedes Einzelnen einen unverhältnismäßigen Aufwand erfordert, kann

der Verpflichtete z. B. die Öffentlichkeit informieren.

36

3.3 Wesentliche Probleme bei der Einhaltung datenschutz-

rechtlicher Vorschriften bei CC

Die Umsetzung der vorgestellten gesetzlichen Anforderungen zur Gewährung des Schutzes

personenbezogener Daten stößt derzeit an eine Reihe von Problemen. Einige sind damit

verbunden, dass das Gesetz an manchen Stellen wenig konkret und nicht eindeutig ist. Die

wichtigsten Probleme, die das CC-Modell betreffen, werden im Folgenden dargestellt.

3.3.1 Zuordnung eines CSP-CSC-Verhältnisses zu einer der Kategorien

Auftragsdatenverarbeitung oder Datenübermittlung

Bevor die entsprechenden Datenschutzrichtlinien geltend gemacht werden können, muss

zuerst bestimmt werden, welche Form der DV bei dem jeweiligen Sachverhalt vorliegt. Diese

Abgrenzung ist allerdings nicht immer unproblematisch. Zunächst ist die DV

datenschutzrechtlich an den Standort gebunden, an dem sie geschieht. Bei großen,

international agierenden CSP wie z. B. Microsoft, Google, Salesforce.com oder Amazon ist

der Standort der DV nicht immer eindeutig bestimmbar. Auch wenn der Kunde die

Möglichkeit bekommt, den Standort der DV selber auszuwählen (dies ist z. B. bei Amazon

möglich), ist nicht ausgeschlossen, dass die Daten aufgrund einer Havarie oder

Systemüberlastung diesen Standort verlassen würden oder dass Sicherheitskopien „aus

Sicherheitsgründen“ irgendwo anderes liegen. Darüber hinaus ist es bei CC schwierig zu

unterscheiden, ob es sich jeweils um eine Auftragsdatenverarbeitung oder um eine

Datenübermittlung handelt.

Wie bereits diskutiert, liegt datenschutzrechtlich eine Auftragsdatenverarbeitung vor, wenn

die verantwortliche Stelle dem Auftragnehmer konkrete Anweisungen gibt, wie mit den Daten

umzugehen ist. Das bedeutet, der CSC schreibt dem CSP vor, wie er die Daten erheben,

verarbeiten oder nutzen darf. Bei der Auslagerung der DV in eine Public Cloud passiert es

dennoch häufig, dass die CSP manche Bedingungen für den Umgang mit den Nutzerdateien,

die möglicherweise personenbezogene Daten enthalten, selber festlegen. Bspw. bestimmen

einige CSP selbständig, wie und wo Nutzerdateien gespeichert werden, wann und wie sie von

einem Standort an einen anderen transferiert werden, wie viele Sicherheitskopien gemacht

werden, wo und wie diese aufbewahrt werden, ohne dass der CSC die Möglichkeit erhält,

diese Bestimmungen zu verändern oder zu präzisieren (vgl. z. B. Amazon Web Services

37

(AWS) Security Processes20

von AWS oder Dropbox-Nutzungsbedingungen21

bzw.

Dropbox-Sicherheitsübersicht22

).

Eine Datenübermittlung liegt dagegen vor, wenn die Daten ohne eine Weisung der

übermittelnden Stelle an einen Dritten weitergegeben werden. Bei einer Übermittlung ins

Ausland ist nach § 4b Abs. 6 die Stelle, an die Daten übermittelt werden, auf den Zweck der

Datenübermittlung hinzuweisen. Somit kann eine Datenübermittlung im Sinne von § 4b

vorliegen, wenn ein Cloud-Dienst ausschließlich zum Zweck der Datenspeicherung

verwendet wird und der CSP selbständig über die Mittel der Datenaufbewahrung entscheiden

darf.

Die Nutzung eines SaaS kann dagegen nicht dieser Kategorie zugeordnet werden, da in

diesem Fall der CSP lediglich dem CSC die benötigten Mittel für die Realisierung der DV zur

Verfügung stellt.

3.3.2 Einhaltung der Richtlinien für eine Auftragsdatenverarbeitung nach

§ 11 BDSG

International agierende CSP verfügen über allgemeine Geschäfts-, Nutzungs- und

Datenschutzbestimmungen, die i. d. R. nicht verhandelbar sind. Der 10-Punkte Katalog nach

§11 BDSG ist selten in diesen vollständig erfasst. Insbesondere fehlen die Klauseln zu den

Kontrollrechten der CSC, zur Mitteilung von datenschutzrelevanten Verstößen der CSP und

zur Aufklärung von Unterauftragsverhältnissen. Die Überprüfung der technischen und

organisatorischen Maßnahmen zur Gewährung von Datenschutz und –Sicherheit von Seite

des CSC vor Beginn der DV und sodann regelmäßig ist praktisch nicht machbar. Dabei sind

hauptsächlich zwei Gründe zu nennen. Erstens wollen viele CSP so wenig wie möglich über

deren Rechenzentren transparent machen und zweitens ist die Cloud-Dienste-Infrastruktur so

komplex, dass der durchschnittliche CSC selten über das notwendige Wissen verfügt, um

diese verstehen und bewerten zu können. Darüber hinaus muss auch berücksichtigt werden,

dass das Wahrnehmen all dieser Pflichten möglicherweise auch negative Auswirkungen auf

die wirtschaftlichen Ziele, welche sowohl CSC als auch CSP mit dem CC-Modell verfolgen,

haben kann. (vgl. [PHG11], SS. 59-61)

20

http://aws.amazon.com/articles/1697 (5.5.2012) 21

https://www.dropbox.com/terms (2.5.2012) 22

https://www.dropbox.com/security (2.5.2012)

38

3.3.3 Verantwortlichkeiten bei der Datenübermittlung

Während bei einer Auftragsdatenverarbeitung das Gesetz explizit festlegt, dass der

Auftraggeber datenschutzrechtlich die Verantwortung für die DV vor den Betroffenen behält,

ist bei einer Datenübermittlung nicht klar definiert, wer für die DV nach der Übermittlung

verantwortlich ist. Es ist nur reglementiert, dass die Verantwortung für die Zulässigkeit der

Übermittlung die übermittelnde Stelle hat (vgl. § 4b Abs. 5 BDSG). [W10] & [IT-G11]

argumentieren, dass mit der Übergabe der Daten an Dritte datenschutzrechtlich auch die

Verantwortung für diese übergeben wird.

3.3.4 Rechte der Betroffenen

Die Ausübung der Rechte der Betroffenen zur Information und Auskunft vor allem über die

Empfänger oder die Kategorie von Empfänger der Daten dürfte bei Verwendung von

Cloud-Dienten auch Schwierigkeiten bereiten, da dann nicht nur der Haupt-CSP sondern auch

sämtliche Subunternehmer genannt werden müssten. Bei einer Datenübermittlung ist

weiterhin nicht eindeutig, wem gegenüber der Betroffene seine Rechte auf Auskunft,

Wiederruf, Datenkorrektur, -Löschung oder -Sperrung geltend machen kann (siehe oben).

3.3.5 Wann sind die Voraussetzungen nach § 28 Abs. 1 BDSG gegeben?

Die Voraussetzungen nach § 28 Abs. 1 Nr. 1 können gegeben sein, wenn z. B. die

verantwortliche Stelle Instrumente oder Programme für die Erfüllung eines mit dem

Betroffenen abgeschlossenen Geschäftsvertrags benötigt, die nur mit sehr großem Aufwand

bei der Stelle bereitgestellt werden können und die Nutzung eines Cloud-Dienstes an dieser

Stelle den Aufwand erheblich minimieren würde, oder wenn die eigenen Systeme auf Grund

von z. B. Fehlern oder Überlastung für einen Zeitraum außer Betrieb sind und schnell eine

Ersatzlösung gefunden werden muss. Ein berechtigtes Interesse nach §28 Abs. 1 Nr. 2 kann

wiederum vorliegen, wenn die Verwendung eines Cloud-Dienstes für die verantwortliche

Stelle wesentlich kostengünstiger ist als die Bereitstellung und der Betrieb eigener IT. Es ist

jedoch noch nicht nachgewiesen, dass Public Clouds gegenüber eigener IT tatsächlich große

Kosteneinsparungen für den CSC bringen. Insbesondere ist es kaum beweisbar, dass die

ausländischen (nicht nur die außereuropäischen) Cloud-Dienstangebote im Vergleich zu den

heimischen so erheblich günstiger sind, dass dies der Erforderlichkeit dieses Paragraphs

genügt (vgl. [W10], S. 683).

39

3.3.6 Datenschutz in den USA

Da die vorwiegende Zahl großer, international agierender CSP ihren Hauptsitz in den USA

haben und die Rechenzentren für ihre Cloud-Dienste dort betreiben, muss an dieser Stelle die

Datenschutzlage in den USA kurz erläutert werden.

Die USA gehören nach dem EU-Datenschutzrecht zu den Drittländern, die kein angemessenes

Datenschutzniveau aufweisen, da sie grundsätzlich kein umfassendes Gesetz zum Schutz

personenbezogener Daten und der Privatsphäre der Menschen haben. Jedoch sind die USA ein

wichtiger Handelspartner der EU und ein Datenaustausch mit ihnen ist unerlässlich. Um die

Handelsbeziehungen mit den USA nicht zu behindern, wurde im Jahr 2000 zwischen der EU

und den USA das EU-US Safe Harbor23

(Sicherer Hafen) Abkommen geschlossen

[00/520/EG]. Dieses ermöglicht, dass Daten an US-Unternehmen legal übermittelt werden

können, wenn die Unternehmen eine Safe Harbor Zertifizierung haben. Die Kritik an dieser

Zertifizierung ist allerdings sehr groß und wird durch zahlreiche Unstimmigkeiten, Beispiele

und Studien begründet. Im Folgenden sind nur einige der Gründe genannt. (Eine

umfangreiche Darstellung dieser findet der Leser bei [MS11].)

Bei Safe Harbor handelt es sich um eine freiwillige und „rein faktische

Selbstzertifizierung“, bei welcher die entsprechenden Unternehmen ihre Zustimmung zur

Einhaltung der 7 Safe Harbor Prinzipien und zum Beachten der Hinweise in den

Antworten der 15 Frequently Asked Questions (FAQ) geben. Eine Prüfung der Erfüllung

der Zertifizierungsanforderungen von Seite der zuständigen US-Behörde, die Federal

Trade Commission (FTC), findet in der Regel nicht statt.

Die Hinweise in den 15 FAQ sind unkonkret und erlauben einen großen

Umsetzungsspielraum für die betroffenen Unternehmen.

Die Zertifizierung betrifft nicht unbedingt alle Arten personenbezogener Daten. Sie kann

sich bspw. nur auf Personaldaten, Kundendaten, online oder offline24

Daten beziehen.

Z. B. die Safe Harbor Zertifizierung bei Microsoft, Salesforce.com und Google betrifft

nur Personaldaten, wobei diese bei Salesforce.com sich weiterhin nur auf online Daten

bezieht (vgl. Abb. 10).

23

http://export.gov/safeharbor/ 24

Online data = data collected directly on the Internet. Offline data = any digital data processed not through the

Internet – such as data collected through an Intranet. Manually processed data = data collected manually –

paper, trade shows, etc.

40

Abbildung 10: Statur und Art der betroffenen persönlichen Daten bei ausgewählten

Safe-Harbor-zertifizierten Unternehmen (Stand 5.5.2012)25

Viele Unternehmen geben ungerechtfertigter Weise an, Safe Harbor zertifiziert zu sein.

Um die Richtigkeit der Aussagen zu prüfen, können Interessierte oder Betroffene

theoretisch in der Liste des US Handelsministeriums nachschauen. Auf diese kann man

sich wiederum nicht verlassen, weil das Ministerium die Richtigkeit der Angaben nicht

garantiert26

.

Aus diesen und weiteren Gründen hat der Düsseldorfer Kreis am 28./29. April 2010

beschlossen, dass allein das Aufzeigen einer Selbstzertifizierung nach Safe Harbor nicht

genügt um anzunehmen, dass ein US-Unternehmen ein angemessenes Datenschutzniveau

gewährleistet [DK10]. Dadurch wurde die Entscheidung der Europäischen Kommission

[00/520/EG] für Deutschland praktisch als ungültig erklärt.

Ein weiteres wichtiges Problem beim Verwenden von Cloud-Diensten aus den USA

verursacht datenschutzrechtlich der sog. USA PATRIOT Act27

zur Bekämpfung des

Terrorismus. Dieses Gesetz soll US-Sicherheitsbehörden, wie das FBI, das Recht geben,

Daten von US-Unternehmen zu verlangen und einzusehen, auch wenn die Daten in

Rechenzentren außerhalb den USA liegen. CSP aus den USA argumentieren, US-Behörden

können nicht ohne wesentliche Begründung auf deren Kundendaten zugreifen, wenn sie im

europäischen Rechtsraum agieren [CW12]. Microsoft und Google haben jedoch zugegeben,

dass sie der Pflicht zur Weitergabe von Daten aus EU-Rechenzentren an US-Behörden nach

25

https://safeharbor.export.gov/list.aspx 26

siehe Fußnote Nr. 25 27

http://www.fincen.gov/statutes_regs/patriot/

41

dem PATRIOT Act bereits nachkommen müssten [iX], wodurch sich die Rechtsunsicherheit

bei der Arbeit mit US-Unternehmen weiter verschärft.

3.3.7 Mangelnde einheitliche Gesetzesgrundlage

Die vorgestellte Richtlinie 95/46/EG definiert Mindestanforderungen an den Schutz

personenbezogener Daten, welche bei ihrer Umsetzung in einzelstaatliches Recht der

betroffenen Länder weiter ergänzt und präzisiert werden können (vgl. Erwägungsgründe Nr.

22 und 68 der Richtlinie 95/46/EG). Insbesondere bei der Implementierung von geeigneten

technischen und organisatorischen Maßnahmen zur Gewährleistung des Datenschutzes und

der Datensicherheit (s. Art. 17 Abs. 1) ist den Mitgliedstaaten großer Spielraum gelassen.

Infolgedessen müssen EU-CSP in jedem EU-Mitgliedstaat, in dem sie eine Niederlassung

haben, möglicherweise unterschiedliche Maßnahmen treffen, um dem jeweiligen lokalen

Datenschutzrecht gerecht zu werden (vgl. [W11], S. 62). Damit kann das in dieser Richtlinie

gesetzte Ziel, eine einheitliche Datenschutzrechtsgrundlage innerhalb der EU zu schaffen,

nicht als erfüllt angesehen werden.

An einer Lösung zu dieser Problematik arbeitet bereits die EU-Kommission. Sie plant die

vorgestellte Richtlinie 95/46/EG durch eine Datenschutz-Grundverordnung zu ersetzen. Diese

Verordnung sollte ab dem Jahr 2014 in Kraft treten und die einzelstaatlichen

Datenschutzgesetze der EU-Länder ablösen28

. Der Entwurf der EU-Datenschutzverordnung

wurde am 25.1.2012 veröffentlicht29

. Die wichtigsten Änderungen, welche mit der neuen

Verordnung eintreten werden, sind:

einheitliche Datenschutzregeln für die gesamte EU,

einfacher Zugang zu privaten Daten sowie Datenportabilität von einem Dienstanbieter

zum anderen,

international agierende europäische Unternehmen wenden nur die Vorschriften des

EU-Staats an, in dem sie ihren Hauptsitz haben,

die Betroffenen erhalten das Recht, alle datenschutzrelevanten Fragen an deren heimische

Datenschutzbehörde zu richten, auch wenn die persönlichen Daten außerhalb ihres

Heimatlandes verarbeitet werden,

die Regeln gelten auch für außereuropäische Unternehmen, wenn diese Produkte oder

Dienste in der EU anbieten oder das Online-Verhalten von EU-Bürgern und Bürgerinnen

überwachen. [EC12a]

28

http://www.eu-datenschutzverordnung.de/ (10.6.2012) 29

http://www.eu-datenschutzverordnung.de/downloads/entwurf-eu-datenschutzverordnung-2012.pdf

42

4 Auditierungen und Zertifizierungen zu Cloud Computing

4.1 Prüfen der Existenz CC-spezifischer und datenschutzrelevanter

Auditierungs- und Zertifizierungsverfahren

Mit der zunehmenden Diskussion zur Sicherheit bei CC gewinnt das Thema Zertifizierungen

und Audits immer mehr an Bedeutung. IT-Sicherheitsexperten sehen eine allgemeine

Zertifizierung der CSP zu IT- oder Informationssicherheit wie z. B. nach ISO/IEC 27001 oder

den BSI-IT-Grundschutz-Standards30

als unerlässlich (vgl. [BSI11]). Aufgrund der hohen

Komplexität der IT-Landschaft und der Art und Weise wie Dienste und Ressourcen

insbesondere bei Public Clouds bereitgestellt werden, müssen bei CC darüber hinaus weitere

spezifische Sicherheitsaspekte berücksichtigt werden, welche die allgemeinen

Zertifizierungen nur begrenzt oder gar nicht betrachten.

Deutschen Organisationen wie z. B. BSI und BITKOM haben bereits Orientierungshilfen,

Leitfäden und Whitepapers herausgebracht, in welchen die Autoren CC-spezifische Probleme

schildern und Empfehlungen zur Lösung der Probleme geben. Einige dieser Probleme und

Empfehlungen sind in Form von Checklisten zusammengefasst, welche sich gut für die

Durchführung von Auditierungs- bzw. Zertifizierungsprozessen eignen. Jedoch bieten diese

Unternehmen noch keine speziellen CC-Zertifizierungen an.

Dieses Kapitel hat zum Ziel, sowie bereits existierende CC-spezifischen Zertifizierungen, als

auch öffentlich zugängliche Vorgehensweisen und Checklisten, welche für die Durchführung

CC-spezifischer Audits gut geeignet sind, vorzustellen. Darüber hinaus beschreibt das Kapitel

einige öffentliche Register, welche CSP auf die Erfüllung bestimmter Kriterien untersuchen

und zusammenfassen.

4.1.1 Zertifizierungsprogramme

EuroCloud Star Audit SaaS der EuroCloud Deutschland_eco e. V.31

EuroCloud Deutschland_eco e. V.32

ist der Verband der deutschen CC-Industrie und

beschäftigt sich mit allen Fragen rund um CC. Der Verband bietet seit Anfang 2011 die

Zertifizierung „EuroCloud Star Audit SaaS“ an. Diese Zertifizierung erfolgt nach einem

Anforderungskatalog, welcher in Zusammenarbeit mit Experten aus unterschiedlichen

Branchen – CSP, Berater, Auditoren, Anwälte und Behördenvertreter – und in Abstimmung

30

https://www.bsi.bund.de/ContentBSI/Publikationen/BSI_Standard/it_grundschutzstandards.html 31

http://www.saas-audit.de/ 32

http://www.eurocloud.de/

43

mit dem BSI erstellt wurde [eco_c]. Der Katalog besteht aus 200 Fragen aus den Kategorien

Profil, Vertrag und Compliance, Sicherheit, Betrieb und Infrastruktur, Betriebsprozesse,

Anwendung und Implementierung. Eine Checkliste zu den Vertragselementen der

Zertifizierung steht Interessierten im „Leitfaden Cloud Computing: Recht, Datenschutz &

Compliance“ zur Verfügung (vgl. [eco10a], Seiten 23-27). Vor Beginn der Auditierung muss

der CSP angeben, für welche Auditierungskategorien er sich entscheidet (er kann zwischen

drei Möglichkeiten auswählen – Auditierung bis-zu-max.-3-Sternen, bis-zu-max.-4-Sternen

oder bis-zu-5-Sternen [eco_d]). In Abhängigkeit von der ausgewählten

Auditierungskategorie sowie von der erfolgreichen Erfüllung der entsprechenden

Anforderungen, wird dem CSP ein Zertifikat mit 1 bis 5 Sternen verliehen. Sollte der CSP mit

dem Ergebnis der Zertifizierung nicht zufrieden sein, so kann er innerhalb von 6 Monaten

nach der Bekanntgabe des Ergebnisses eine Nachbesserungsauditierung beantragen [eco11].

Die Gültigkeit der EuroCloud Star Audit SaaS Zertifizierung beträgt 24 Monate. Die Kosten

für den Gesamtprozess (Audit, Bewertung der Ergebnisse und Zertifikaterstellung) variieren

je nach der Art der Zertifizierung (Erst-, Nachbesserungs- oder Anschluß-Auditierung) und

nach den ausgewählten Auditierungskategorien. Eine erste „bis-zu-5-Sternen-Zertifizierung“

für alle möglichen Kategorien kostet min. 25.000 € [eco11].

Weitere Informationen zu EuroCloud Star Audit SaaS sind unter http://www.saas-audit.de/ zu

finden.

Trusted Cloud Service-Zertifikat der TÜV Trust IT

Eine Zertifizierung „Trusted Cloud Service“ bietet die TÜV Trust IT33

(der

Unternehmensgruppe TÜV Austria) an. Die Zertifizierung erfolgt nach einem

Anforderungskatalog, der auf internationalen Standards basiert. Er umfasst „technische,

organisatorische und wirtschaftliche Prüfungen sowie Compliance-Eigenschaften wie

Datenschutz und Datensicherheit“34

. Ausführliche Informationen zu dem Ablauf und dem

Gegenstand der Zertifizierung sind auf der Webseite des Zertifizierers TÜV Trust IT nicht zu

finden. Das als erstes zertifizierte Unternehmen Host Europe35

veröffentlicht auf seiner

Webseite einige Informationen dazu. Es listet die Kriterien auf, nach welchen das

Unternehmen untersucht wurde36

. Diese entsprechen in großem Maße den Kriterien aus der

Checkliste des BSI zu Mindestanforderungen in der Informationssicherheit für CSP (vgl.

„Sicherheitsempfehlungen des BSI“ unten).

33

http://www.it-tuv.com/ 34

http://www.it-tuv.com/news/trusted-cloud-zertifikat-host-europe.html (12.5.2012) 35

http://www.hosteurope.de/ 36

Vgl. http://www.hosteurope.de/content/Unternehmen/TrustedCloud & [HE11]

44

TÜV-Siegel Geprüfter Datenschutz – Cloud Computing V1.0

Das TÜV-Siegel „Geprüfter Datenschutz – Cloud Computing V1.0“ soll, so salesforce.com37

,

die Erfüllung der Anforderungskriterien an den Schutz personenbezogener Daten auf

Grundlage deutscher Datenschutzgesetze durch das zertifizierte Unternehmen bestätigen.

Informationen zu genau dieser Zertifizierung sind auf der Webseite des Zertifizierers tekit

Consult Bonn GmbH38

(ein Unternehmen der TÜV Saarland Gruppe) nicht zu finden. Die

Seite gibt jedoch kurze Information zu der allgemeinen Zertifizierung „Geprüfter

Datenschutz“. Als Grundlagen für diese Zertifizierung werden vor allem das BDSG

(insbesondere §§ 9 und 11), BSI-Grundschutz, ISO 27001, sowie branchenspezifische

Gesetze und Regelungen in Betracht gezogen [TÜV].

Trust in Cloud von SaaS-EcoSystem e. V.

SaaS-EcoSystem e. V. bietet Beratungslösungen für Anbieter und Nutzer auf dem Gebiet

SaaS an. Das Angebot für CSP enthält Unterstützung bei der Planung und dem Aufbau von

SaaS-Lösungen. Das Angebot für Nutzer beinhaltet Beratung und Unterstützung bei der

Auswahl sowie bei der Integration geeigneter SaaS-Lösungen in den unternehmensinternen

Prozessen und in der IT-Landschaft39

. SaaS-EcoSystem e. V. bietet weiterhin die

Zertifizierung „Trust in Cloud“ an, welche anhand einer stark vereinfachten Checkliste

durchgeführt wird. Die Checkliste besteht aus 30 Fragen, aufgegliedert in 6 Bereiche –

Datensicherheit, Entscheidungssicherheit, Qualität der Bereitstellung, Vertragsbedingungen,

Service-Orientierung und Cloud-Architektur. Die Fragen können mit „Ja“ oder „Nein“

beatwortet werden und sind entsprechend nachzuweisen40

. Ein Unternehmen wird erfolgreich

zertifiziert, wenn es „mehr als 60 % der Fragen positiv beantwortet und mindestens 3

Referenzen nachgewiesen“ hat [SaaS11]. Eine Auditierung vor Ort findet nicht statt. Die

Teilnahme an Trust in Cloud Zertifikat kostet 1.500 € pro Jahr pro Lösung. Jede weitere

Lösung kostest 480 € pro Jahr. Zurzeit sind 7 Lösungen Trust in Cloud zertifiziert41

.

TRUSTed Cloud Data Privacy Certification von TRUSTe42

TRUSTe ist ein Anbieter für Datenschutzlösungen, welche in Form von unterschiedlichen

Datenschutz-Zertifizierungsprogrammen bereitgestellt werden.

37

http://www.salesforce.com/de/company/news-press/press-releases/2010/12/101201.jsp (12.5.2012) 38

http://tekit.de/ 39

http://www.saasecosystem.org/%C3%BCber-das-eco-system/ 40

http://www.saasecosystem.org/trust-in-cloud/teilnahmebedingungen/ (16.5.2012) 41

http://www.saasecosystem.org/trust-in-cloud/zertifizierte-anwendungen/ (16.5.2012) 42

http://www.truste.com/products-and-services/enterprise_privacy/cloud-certification

45

Die TRUSTed Cloud Data Privacy Zertifizierung ist auch ein Programm, das CSP auf die

Einhaltung von Datenschutzstandards bei der Erhebung und der Verarbeitung von Daten

untersucht. Die Datenschutzstandards werden durch den Zertifizierer TRUSTe selber definiert

und umfassen die Bereiche:

Privacy Practices (inkl. Nutzung, Transfer, Zugang, etc.),

Privacy Statement und

Data Governance (inkl. Datensicherheit, Datenqualität, Datenpannen u.a.)43

.

Die Unternehmen, die sich zertifizieren lassen möchten, müssen die Anforderungen des

Zertifizierungsprogramms erfüllen und sich jedes Jahr rezertifizieren lassen. Wie genau die

Überprüfung der Einhaltung der Anforderungen durch den Zertifizierer geschieht, ist jedoch

unklar.

EuroPriSe – European Privacy Seal44

Das europäische Datenschutzgütesiegel „EuroPriSe“ wird für IT-Produkte (SW und HW)

und IT-basierte Dienste (Web-Dienste wie Online-Banking, Suchmaschinen u. a., und

Datenverarbeitungsdienste wie z. B. E-Mail-Hosting) vergeben. Die Kriterien für die

Zertifizierung sind an die EU-Datenschutzrichtlinien (vor allem die EU-Richtlinien 95/46/EG

und 2002/58/EG) angeliehen und werden regelmäßig aktualisiert (generell, bei Änderungen

im EU-Datenschutzrecht). Sie sind in vier Themenbereiche geteilt:

Grundlegende Aspekte (engl. Fundamental Issues),

Rechtmäßigkeit der Datenverarbeitung (engl. Legitimacy of Data Processing),

Technische und Organisatorische Maßnahmen (engl. Technical-Organisational

Measures) und

Rechte der Betroffenen (engl. Data Subjects’ Rights) [EPriSe11].

Die Zertifizierung verläuft in zwei Phasen. Zunächst wird das Produkt bzw. der Dienst durch

zugelassene Rechts- und IT-Experten begutachtet und bewertet. Der Experte ist durch das

Unternehmen, dessen Produkt (Dienst) zertifiziert wird, aus einer Liste45

auszuwählen.

Anschließend wird der Begutachtungsbericht des Experten durch eine unabhängige

Zertifizierungsstelle des Landeszentrums für Datenschutz Schleswig-Holstein validiert. Das

Zertifikat bestätigt, dass das IT-Produkt oder der IT-basierte Dienst EU-Datenschutzrecht

konform ist.

43

http://www.truste.com/privacy-program-requirements/trusted-cloud/ (16.5.2012) 44

https://www.european-privacy-seal.eu/ 45

https://www.european-privacy-seal.eu/experts/register-experts

46

Ursprünglich wurde EuroPriSe im Jahr 2007 als Förderprojekt der Europäischen

Kommission, mit dem Ziel, einheitliche Anforderungen für eine europaweite Zertifizierung

von IT-Produkten und –Dienstleistungen festzulegen, gestartet. Nach der erfolgreichen

Pilotphase wurde EuroPriSe Ende 2008 „live geschaltet“ bzw. in die kommerzielle Nutzung

überführt46

. Weitere Informationen zu dem europäischen Datenschutzgütesiegel sowie eine

Liste der zertifizierten Produkte und Dienste sind auf der EuroPriSe-Webseite zu finden.

4.1.2 Leitfäden und Checklisten

Sicherheitsempfehlungen des BSI47

Das Eckpunktepapier „Sicherheitsempfehlungen für Cloud Computing Anbieter“ des BSI

definiert Mindestanforderungen an die Informationssicherheit für CSP. Die Anforderungen

sind in Checklisten zusammengefasst und in 17 Bereiche unterteilt (darunter

Rechenzentrums-, Server-, Netz-, Datensicherheit, Kontrollmöglichkeiten für Nutzer,

Notfallmanagement, Anforderungen an das Personal, SLA, Datenschutz und Compliance

u.a.). Sie sind weiterhin drei Schutzkategorien zugeordnet – Basisanforderungen,

Anforderungen für Bereiche mit hohem Verfügbarkeitsbedarf und Anforderungen für

Bereiche mit hohem Vertraulichkeitsbedarf. Des Weiteren wird angegeben, für welches

Bereitstellungmodell (Private oder Public Cloud) welche Anforderungen relevant sind. Als

Text werden dann Empfehlungen zur Erfüllung der Anforderungen beschrieben. Das

Eckpunktepapier soll an erster Stelle CSP bei der Umsetzung von Sicherheitsmaßnahmen

unterstützen. Es kann aber auch von CSC genutzt werden, um CSP zu sicherheitsrelevanten

Themen zu befragen. Weiterführende Informationen sind auf der Webseite des BSI sowie bei

[BSI11] zu finden.

BITKOM – Leitfaden und Checklisten48

BITKOM bietet, ähnlich wie BSI, keine CC-Zertifizierung an, jedoch einige Checklisten und

Leitfaden, welche sowohl für CSP als auch für CSC hilfreich sein können.

Cloud Computing – Checkliste für die Einführung im Unternehmen49

ist bspw. an CSC

orientiert. Sie fasst alle wichtigen Fragen, welche bei der Einführung einer Cloud-Lösung zu

berücksichtigen sind, zusammen. Die 74 Fragen sind in fünf Themengebiete bzw.

46

https://www.datenschutzzentrum.de/presse/20081016-europrise-betriebsphase.htm (16.5.2012) 47

https://www.bsi.bund.de/DE/Themen/CloudComputing/Eckpunktepapier/Eckpunktepapier_node.html

(12.5.2012) 48

http://www.cloud-practice.de/know-how/cloud-computing-%E2%80%93-checkliste-fuer-die-einfuehrung-im-

unternehmen 49

http://www.cloud-practice.de/know-how/cloud-computing-%E2%80%93-checkliste-fuer-die-einfuehrung-im-

unternehmen (16.5.2012)

47

„Integrationsfelder“ geteilt – Infrastruktur, Anwendungen, Prozesse, Rechtliche und

Vertragliche Aspekte und Organisation.

SaaS - Checkliste für ISVs50

ist für Softwarehersteller (Independent Software Vendors (ISVs))

gedacht, welche SaaS in deren Angebotssortiment aufnehmen wollen. Die Checkliste stellt

praktische Hilfestellungen zu technologischen und organisatorischen Anpassungen, die

notwendig für die Entwicklung und die Bereitstellung von SaaS sind, zur Verfügung. Sie ist

in fünf Teile gegliedert – Grundstruktur der Wertschöpfungskette, Organisation, Technologie,

Betrieb und Rechtliche Aspekte.

4.1.3 Online Register für Cloud-Dienste

CSA STAR - Cloud Security Alliance Security, Trust & Assurance Registry51

Die Cloud Security Alliance (CSA)52

ist eine gemeinnützige Organisation mit zwei

Hauptzielen. Das eine Ziel ist, die Verwendung von Best-Practices bei der Gewährleistung

der Sicherheit bei CC voranzubringen und das zweite – Schulungen und Ausbildung zum

Thema Sicherheit bei CC bereitzustellen.

CSA STAR ist ein öffentlich zugängliches Register, welches die Sicherheitsvorkehrungen, die

CSP für deren Cloud-Dienste treffen, dokumentiert. CSP, die sich in das Register eintragen

wollen, müssen einen „Self-assessment report“ (etwa Selbsteinschätzungs- oder

Selbstbeurteilungsbericht) einreichen, der die Erfüllung von Best-Practices-Anforderungen

bestätigt. Der Report kann in zwei Formen vorbereitet werden. Die eine Möglichkeit ist The

Consensus Assessments Initiative Questionnaire (CAIQ)53

(etwa der Fragenbogen der

Initiative für Konsensus auf Einschätzungen), welcher aus mehr als 140 Fragen zu

Sicherheitsvorkehrungen für IaaS-, PaaS- und SaaS-Angebote besteht, zu beantworten. Die

zweite Möglichkeit ist die Cloud Controls Matrix (CCM)54

(die Cloud-Kontrolle-Matrix)

auszufüllen. Die Matrix ist ein Rahmenwerk mit detaillierten Informationen zu

Sicherheitskonzepten und –gesetzmäßigkeiten, zusammengefasst in 13 Bereiche (darunter

Compliance, Data Governance, Human Ressources, Information Security, Legal und andere).

Die Selbsteinschätzungsberichte müssen jedes Jahr erneuert werden, ansonsten werden sie in

18 Monaten nach der Eintragung aus dem Register entfernt. Die Prozedur zur Eintragung in

das Register ist für CSP entgeltfrei. Eine Untersuchung der CSP auf die Einhaltung der in den

50

http://cloud-practice.de/know-how/saas-%E2%80%93-checkliste-fuer-isvs (16.5.2012) 51

https://cloudsecurityalliance.org/star/ 52

https://cloudsecurityalliance.org/ 53

Der Fragenbogen kann heruntergeladen werden unter: https://cloudsecurityalliance.org/research/cai/ 54

Die Matrix kann heruntergeladen werden unter: https://cloudsecurityalliance.org/research/ccm/

48

Berichten beschriebenen Maßnahmen und Vorkehrungen von Seite der CSA oder

unabhängiger Dritte findet jedoch nicht statt55

. Zurzeit enthält das Register vier Unternehmen,

darunter auch Microsoft für die Diensten Office 365, Dynamics CRM Online und Windows

Azure56

.

Initiative Cloud Services Made in Germany

Die Initiative Cloud Services Made in Germany führt und pflegt ein Register mit

Cloud-Lösungen, welche die folgenden Kriterien erfüllen:

„Das Unternehmen des Cloud Service-Betreibers wurde in Deutschland gegründet und

hat dort seinen Hauptsitz.

Das Unternehmen schließt mit seinen Cloud Service-Kunden Verträge mit Service

Level Agreements (SLA) nach deutschem Recht.

Der Gerichtsstand für alle vertraglichen und juristischen Angelegenheiten liegt in

Deutschland.

Das Unternehmen stellt für Kundenanfragen einen lokal ansässigen,

deutschsprachigen Service und Support zur Verfügung.“57

Zurzeit sind ca. 40 Unternehmen in dem Register aufgenommen. Vor der Aufnahme prüft ein

Projektteam, ob die vier Muss-Kriterien erfüllt sind. Wie die Prüfung verläuft, ist allerdings

nicht bekannt.

CloudServiceMarket

CloudServiceMarket58

ist ein in einem Forschungsprojekt an der Universität Osnabrück

entstandenes öffentliches Cloud-Dienste-Register. Die Idee des Projekts war es, eine

Datenbank und ein Reifegradmodell zu entwickeln, welche Cloud-Dienste anhand bestimmter

Kriterien auswerten um die Qualität der Dienste zu bestimmen. Als Kriterien für die

Auswertung werden Support, Skalierbarkeit, Flexibilität der SLA, Schnittstellen,

Rechenzentren, Compliance, Auditierbarkeit und Zertifikate sowie Sicherheit einbezogen.

Von dem Register sollen sowohl CSP als auch CSC profitieren. Es kann CSC dabei

unterstützen, sich einen Überblick über den komplexen Markt an Cloud-Angebote, zu

verschaffen und eine Vorauswahl zu treffen. CSP können die Datenbank nutzen, um sich und

ihre Dienste potentiellen Nutzern vorzustellen.

55

Siehe 12) unter https://cloudsecurityalliance.org/star/faq/ 56

https://cloudsecurityalliance.org/research/initiatives/star-registry/#star_a (16.5.2012) 57

http://www.cloud-services-made-in-germany.de/beteiligung (16.5.2012) 58

http://cloudservicemarket.info/default.aspx

49

Anwender können zu der Bewertung der Cloud-Dienste beitragen, indem sie Kommentare

und eigene Bewertungen abgeben. ([FR10], SS. 52-61)

50

4.2 Erstellung eines Fragenkatalogs zur Untersuchung von CSP

auf datenschutzrechtliche Anforderungen

Aus den unter Kapitel 3 geschilderten Problemen lassen sich eine Reihe von Fragen ableiten,

die jeder potentielle CSC beantworten muss, bevor er die gesamte oder Teile seiner DV in

einen (Public) Cloud-Dienst verlagert, um mögliche Verstöße gegenüber den gesetzlichen

Vorschriften zu vermeiden. Eine umfassende Untersuchung der CSP wie sie das BDSG

vorschreibt ist jedoch entweder praktisch nicht durchführbar oder nur mit unverhältnismäßig

hohem Aufwand möglich. Demzufolge muss eine Kompromisslösung gefunden werden,

welche den Aufwand für die Untersuchung der CSP in angemessenem Rahmen hält und

gleichzeitig die relevanten rechtlichen Anforderungen berücksichtigt.

Der im Folgenden vorgeschlagene Fragenkatalog stellt eine solche Kompromisslösung dar. Er

fasst die wichtigsten Fragen zusammen, anhand derer ein CSP auf seine Eignung (oder eher

Nicht-Eignung) für die Verarbeitung personenbezogener Daten untersucht werden kann. Der

Katalog ist nicht hundertprozentig BDSG-konform und eignet sich vor allem für die

Durchführung einer Vorabuntersuchung. Insbesondere, wenn dem CSC mehrere CSP zur

Auswahl stehen, kann der Katalog helfen, die Anzahl der in Betracht kommenden Anbieter zu

reduzieren. Nach der Vorabuntersuchung und der Festlegung der bei CSP zu verarbeitenden

Kategorien von Daten kann der Katalog dann entsprechend erweitert werden, um die

datenschutzrechtlichen Vorschriften vollständig zu decken. Der Katalog kann außerdem um

weitere branchenspezifische Muss-Kriterien ergänzt werden (so wie etwa aus dem HGB, dem

StGB, der AO oder andere), um die Eignung der CSP auf die Verarbeitung anderer

spezifischer Kategorien von Daten untersuchen zu können.

Anhand des vorgeschlagenen Fragebogens können CSP zunächst auf Transparenz (im Sinne

von Offenlegung und Klarheit) überprüft werden – ob sie die Mindestanforderungen an

Transparenz nach Datenschutzrecht erfüllen. Sollte das nicht der Fall sein, sind die

Informationen an einigen Stellen nicht eindeutig und irreführend oder sind manche

Bedingungen nicht zufriedenstellend für den Kunden, dann ist als nächstes direkt Kontakt mit

dem CSP aufzunehmen um die Unstimmigkeiten zu klären bzw. die von CSP vorgegebenen

Bedingungen nachzuverhandeln. Möchte der CSP nicht auf die Probleme des CSC eingehen,

dann sollte der CSC auf die Verwendung seiner Cloud-Dienste grundsätzlich verzichten.

Der vorgeschlagene Fragekatalog bezieht sich ausschließlich auf den CSP und sein Verhalten

gegenüber DuD-relevanten Aspekten. Die Untersuchung eines Cloud-Dienstes auf seine

Eignung die funktionalen Anforderungen des CSC abzudecken sollte völlig separat verlaufen.

51

Fragenkatalog zur Untersuchung CSP auf datenschutzrechtliche

Anforderungen

I Hauptsitz, Niederlassungen des CSP & Standorte der Cloud-Dienste

1) Hauptsitz des CSP?

2) Europazentrale?

3) Niederlassung(-en) in der EU und in Deutschland?

Im ersten Schritt der Untersuchung ist zu erfassen, wo der CSP seinen Hauptsitz und

weitere Niederlassungen hat und ob eine Europazentrale existiert. Aus diesen

Informationen leiten sich i. d. R. die anzuwendenden gesetzlichen Vorschriften zur

Vertragsgestaltung ab (vgl. Frage 7). Einige CSP mit Hauptsitz außerhalb Europas haben

eine Europazentrale, welche mit europäischen Kunden Verträgen nach europäischem

Recht schließen.

4) Wo sind die Standorte der Rechenzentren für die Cloud-Dienste?

5) Kann ein Nutzer selber festlegen, wo seine Daten gehostet / verarbeitet werden?

6) Ist es möglich, die Datenhaltung und –verarbeitung einzugrenzen auf

a. Deutschland,

b. die EU / den EWR oder

c. auf Drittländer, wo ein angemessenes Datenschutzniveau festgestellt wurde?

Die wichtigste Frage für europäische CSC lautet: „Wo liegen meine Daten, wenn sie in

der Wolke verarbeitet werden?“. Der Standort der Datenhaltung bzw. –verarbeitung ist,

wie bereits dargestellt, datenschutzrechtlich aus mehreren Gründen von Bedeutung –

damit hängen das anzuwendende einzelstaatliche Datenschutzrecht und die jeweils

einzuhaltenden Vorschriften zusammen. Fragen Nr. 5 und 6 sind insofern für den

Kunden wichtig, um ihm Sicherheit zu geben, dass er nicht gegen die Vorschriften des

Datenschutzrechts (oder gegen andere relevante Gesetzen) verstößt.

II Vertragsrecht & Vertragssprache

7) Anzuwendendes nationales Vertragsrecht & Gerichtsstand?

8) Vertragssprache?

CC-Verträge sind selten einem bestimmten Vertragstyp zuzuordnen. Sie sind typische

Mischverträge, mit vor allem miet-, dienst-, werk- oder leihvertraglichen Elementen. Aus

dem Vertragstyp werden jedoch die anzuwendenden gesetzlichen Regelungen zwischen

52

den Vertragspartnern abgeleitet (vgl. [Bitk10], S. 31-32). Weiterhin hängen die

Vertragsregelungen mit dem Sitz der Vertragspartner, welcher bei CC oft in

unterschiedlichen Ländern sein kann, zusammen. Des Weiteren kann die Ermittlung des

Sitzes des CSP problematisch sein, wenn z. B. eine im Inland ansässige Niederlassung

den Vertrag in Namen der Muttergesellschaft, welche in einem anderen Land ansässig

ist, schließt. Aus diesen Gründen sind die vertraglichen Vereinbarungen zwischen CSP

und CSC genau zu beschreiben und das allgemeingültige nationale Vertragsrecht sowie

der Gerichtsstand explizit zu benennen.59

Die Frage nach der Vertragssprache ist aus zwei Gründen wichtig. Sollten CSP und CSC

verschiedene Sprachen sprechen und die Verträge nur in einer der Sprachen verfügbar

sein, dann kann die sorgfältige Überprüfung dieser durch den Kunden mit zusätzlichem

Aufwand (und dadurch mit zusätzlichen Kosten) verbunden sein. Weiterhin ist es bei

Nicht-Übereinstimmung zwischen der Vertragssprache und der Sprache des

anwendbaren Rechts möglich, dass Probleme bei der Interpretation rechtlicher Begriffe

entstehen. In solchen Fällen empfiehlt es sich zumindest die Rechtsbegriffe in den

Verträgen in allen relevanten Sprachen anzugeben. (vgl. [Bitk10], SS. 37-38)

III Fragen zu der DV

(Großteil dieser Fragen sind aus dem BDSG abgeleitet)

9) Welche Kategorien von Daten werden vom CSP verarbeitet bzw. erhoben und zu

welchen Zwecken (allgemein)?

10) Werden personenbezogene Daten erhoben und verarbeitet?

11) Welche Dritte haben Zugriff auf die Daten bzw. können Zugriff auf diese auf Basis

von Verträgen oder rechtlichen Bestimmungen erlangen?

12) Nach welchen Vorschriften erfolgen die DV und der Datentransfer?

Mittels der sog. EU-Standardvertragsklausen können sich außereuropäische CSP

verpflichten, bei der DV europäischer Kunden die EU-Datenschutzrichtlinien

einzuhalten. Dies hat z. B. Microsoft für seinen Dienst Office 365 bereits gemacht60

.

59

Ausführliche Informationen zum Thema „Problematik der Vertragsgestaltung bei CC“ sind bei [Bitk10],

SS. 31-58 zu finden. 60

http://www.microsoft.com/de-de/office365/trust-center.aspx#fbid=0DFPd2grDsV (14.5.2012)

53

13) Sind die beim CSP getroffenen technischen und organisatorischen Maßnahmen zur

Gewährleistung des Datenschutzes offen beschrieben bzw. sind die Beschreibungen

dieser Maßnahmen für den CSC zugänglich?

Die beim CSP getroffenen technischen und organisatorischen Maßnahmen sind

ausschlaggebend bei der Auswahl eines CSP. Das Datenschutzrecht verlangt an dieser

Stelle Transparenz, so dass der Kunde seiner Überprüfungspflicht nachkommen kann.

14) Wie erfolgt die Löschung der Daten beim CSP (und die Vernichtung der bei ihm

vorhandenen Datenträger) nach Beendigung des Auftragsverhältnisses?

Das genaue Vorgehen bei der Datenlöschung ist zu definieren, da sowie die Daten als

auch Sicherungskopien von diesen generell redundant an mehreren Standorten gehalten

werden, wobei der Kunde i. d. R. keinen Zugang zu all diesen Orten hat.

15) Existieren Regelungen zur Informationspflicht (i. e. Pflicht zur Benachrichtigung der

zuständigen Behörden und der CSC) bei:

a. unrechtmäßigem Umgang mit den Daten von Seite der CSP bzw. von bei ihm

beschäftigten Personen?

b. unrechtmäßiger Kenntniserlangung von Daten (sog. Datenpannen oder

Datenlecks)?

Die rechtzeitige Benachrichtigung der CSC sowie der zuständigen Behörden bei

Datenpannen oder beim internen Datenmissbrauch kann hilfreich sein, um möglichen

Schaden für die Betroffenen zu minimieren.

16) Hat der CSP, sofern das einzelstaatliche Datenschutzrecht das vorsieht, einen

Beauftragten für den Datenschutz?

Ein Datenschutzbeauftragter, der dieselben Rechte und Pflichten wie nach §§ 4f und 4g

BDSG hat, kann sehr hilfreich für die CSC sein. Er kann dem Kunden bei

datenschutzrelevanten Fragen sowie beim Ausüben seiner Kontrollpflichten unterstützen.

17) Können die beim CSP zu verarbeitenden Daten verschlüsselt werden?

Wenn „JA“, dann

18) Wer ist für die Verschlüsselung und die Verwaltung der Schlüssel zuständig?

Verschlüsselte Daten fallen nicht unter dem Anwendungsbereich des

54

EU-Datenschutzrechts und können problemlos in einem Cloud-Dienst verarbeitet

werden. Das gilt jedoch nur für den Fall, dass ausschließlich die verschlüsselten Daten

beim CSP verarbeitet oder gespeichert werden. Ist der CSP auch für die Verschlüsselung

und vor allem für die Schlüsselverwaltung verantwortlich, dann existiert die Möglichkeit,

dass er die Daten entschlüsselt. Dadurch wird der Personenbezug wieder hergestellt und

sind wiederum die Datenschutzrichtlinien anzuwenden. Aus diesem Grund sollte die

Verschlüsselung in der Verantwortung des CSC liegen.

IV Kontrollrechte der CSC

Die Kontrollrechte eines CSC sollten sich auf die drei Ebenen erstrecken – Kontrolle des

CSP, Kontrolle der eigenen Dienste und Daten, und Kontrolle der in den SLA vereinbarten

Leistungen.

19) Kann der CSC vor Beginn der DV und sodann regelmäßig den CSP auf die Einhaltung

der bei ihm getroffenen technischen und organisatorischen Maßnahmen kontrollieren?

Wenn „JA“, dann

20) Wie kann die Kontrolle erfolgen?

a. Kann der Kunde die Rechenzentren, in welchen seine Daten gehostet werden,

besichtigen?

b. Kann der Kunde einen unabhängigen Dritten zur Durchführung der Kontrolle

(bzw. zur Auditierung) beauftragen?

c. Werden der für den CSC zuständigen Aufsichtsbehörde (für den Datenschutz)

entsprechende Kontrollrechte zugewiesen?

d. Existieren andere Möglichkeiten, welche der CSP dem CSC anbietet?

21) In wieweit behält der CSC die Kontrolle über die eigenen Daten bei?

22) Ist festgelegt, was genau der Kunde bei dem CSP kontrollieren kann bzw. was er

selber kontrollieren muss (bspw. die eigenen Ressourcen und Anwendungen)?

Bevor der CSC seine Kontrollpflicht erfüllen kann, muss der CSP die dafür notwendigen

Voraussetzungen schaffen. Eine Kontrolle kann z. B. vor Ort, durch Vorzeigen

entsprechender Dokumente, Zertifikate oder Erklärungen (vgl. [eco10a], S. 15) oder

durch die Beauftragung eines unabhängigen Drittes erfolgen. Dabei ist allerdings mit der

jeweils zuständigen Datenschutzbehörde abzustimmen, ob die individuelle CSC-

Kontrolle durch die Kontrolle externer Dritter ersetzt werden darf.

55

23) Bietet der CSP dem Kunden standardisierte Verfahren und Werkzeuge zur Kontrolle

an?

Wenn „JA“, dann

24) Entstehen dadurch zusätzliche Kosten für den Kunden? Welche?

Eine weitere wesentliche Frage für CSC ist, in wie weit sie die Kontrolle über die

eigenen Daten beibehalten, wenn diese irgendwo in der Wolke liegen und wie die

Kontrolle über diese Daten erfolgen kann. Die Überwachung der eigenen Ressourcen,

Anwendungen und Daten in der Cloud ist selten ohne die Unterstützung von passenden

Schnittstellen und Werkzeugen möglich. Dazu muss der CSC wissen, ob der CSP die

benötigten Werkzeuge zur Verfügung stellen kann oder ob er sich diese selber besorgen

muss. Eine weitere Frage an dieser Stelle ist, ob für die Ausübung der Kontrolle für den

CSC zusätzliche Kosten anfallen.

V Zertifizierungen

25) Besitzt der CSP Zertifikate, welche ein bestimmtes Niveau an Datenschutz und

Datensicherheit garantieren?

Wenn „JA“, dann

26) Die folgenden Fragen sind zu beantworten:

a. Welche Zertifikate besitzt der CSP?

b. Was sagen die Zertifikate über das Niveau an DuD genau aus?

c. Sind diese international anerkannt bzw. werden sie in der EU anerkannt?

d. Sind sie noch gültig?

e. Werden sie nach einem Auditierungsprozess durch unabhängige Dritte erworben?

Steht der unabhängige Dritte bei Fragen von Seite der CSP-Kunden zur

Verfügung?

Eine gute Möglichkeit zur Feststellung, ob ein CSP das notwendige Niveau an DuD

aufweist, ist der Besitz relevanter Zertifikate. Hier ist jedoch Vorsicht geboten. Das

Vorzeigen von Zertifikaten ist in den letzten Jahren eher zu einem Marketinginstrument

geworden, als Garantie für Qualität oder das Einhalten bestimmter Regeln. Deswegen

sind die vorhandenen Zertifikate zumindest auf die unter Frage Nr. 26 definierten 5

Punkte zu untersuchen. Ein Zertifikat, das ohne die Durchführung eines

Auditierungsprozesses erworben wird (sog. „Selbst-Zertifizierungen“), wie z. B. Safe

Harbor, sollte für den CSC keine Aussagekraft haben.

56

VI Subunternehmen

27) Wird der CSC über sämtliche Subunternehmen und deren Tätigkeiten informiert bzw.

ist es im Vertrag geregelt, dass der CSP den CSC über Subunternehmern und deren

Tätigkeiten zu informieren hat?

28) Wird angegeben, an welche Angaben und Vorschriften sich die Subunternehmen beim

Umgang mit Kundendaten zu halten haben?

29) Hat der CSC gegenüber den Subunternehmen dieselben Kontrollrechte wie gegenüber

dem CSP?

Das Einbinden weiterer Unternehmen in die Bereitstellung eines Cloud-Dienstes bereitet

weitere Probleme, sofern nicht ausgeschlossen werden kann, dass diese Unternehmen auf

die Kundendaten zugreifen können. Die Übertragung der Vorschriften des BDSG (vgl. §

11 Abs. 5) auf die Verhältnisse CSC-CSP-Subunternehmen in vollem Umfang ist, wie

bereits diskutiert, praktisch nicht machbar. Eine praktikable Lösung an dieser Stelle

wäre, alle relevanten Subunternehmen (d. h. Unternehmen, die Zugriff auf die Daten

haben könnten) zu benennen und festzulegen, dass die im Vertrag zwischen CSC und

CSP definierten Regeln auch für diese Unternehmen gelten sowie dem CSC dieselben

Kontrollrechte gegenüber den Subunternehmen wie gegenüber dem CSP zu gewähren

(vgl. [eco10a], S. 16).

VII Portabilität

30) Ist ein „problemloser“ Wechsel des CSP möglich bzw. stellt der CSP dem CSC

Techniken und Instrumenten zum problemlosen Datentransfer zur Verfügung (z. B.

standardisierte Schnittstellen zur Anbindung an „fremde“ Anwendungen, Daten-

Export-/Import-Schnittstellen oder andere Migrationstools)?

31) Fallen für die Schnittstellen und die Werkzeuge zusätzliche Kosten an?

Bevor sich ein Nutzer für einen bestimmten CSP entscheidet muss er auch

berücksichtigen, welche Möglichkeiten der Anbieter zum Datentransfer und Datenexport

anbietet, so dass er die DV nach der Ablösung des CSP problemlos und in kurzer Zeit

fortsetzen kann.

VIII SLA

32) Werden SLA definiert?

Wenn „JA“, dann

33) Sind die in den SLA definierten Bedingungen ausreichend bzw. zufriedenstellend?

57

Wenn „Nein“, dann

34) Können die SLA nachverhandelt werden?

Die vorwiegende Anzahl Public CSP haben allgemeine, öffentlich zugängliche SLA.

Diese sind jedoch meist sehr knapp gehalten. Aus diesem Grund ist zu prüfen, ob die

Bestimmungen in dem SLA für den konkreten Fall ausreichend sind und ob diese

entsprechend geändert bzw. ergänzt werden können.

35) Kann der CSC die Einhaltung der SLA kontrollieren?

Der Kunden muss die Möglichkeit haben, die in den SLA vereinbarten Werte zu

überwachen, um sicher zu sein, dass er die Leistung bekommt, wofür er auch bezahlt.

Dazu kann der CSP z. B. eine Webschnittstelle oder API zur Verfügung stellen. (vgl.

[BSI11], SS. 41 & 60)

XI Haftung

36) Welche Haftung übernimmt der CSP?

Nicht zuletzt muss geprüft werden, wofür der CSP haftet bzw. nicht haftet und welche

Konsequenzen sich daraus für den CSC ergeben können. Falls der CSP jegliche Haftung

ablehnt (was bei manchen großen CSP der Fall ist), dann wäre auch zu überprüfen, ob

dieser Punkt in dem Vertrag nachverhandelt werden kann.

58

4.3 Untersuchen der Lage bei ausgewählten führenden CSP

anhand des vorgeschlagenen Fragenkatalogs

Anhand des im vorherigen Kapitel vorgeschlagenen Fragenkatalogs wurde die Lage bei vier

führenden, international agierenden CSP untersucht. Die Untersuchungen beziehen sich auf

die Dienste Amazon Web Services (AWS), Microsoft Online Services (MSOS), Google Apps

und Salesforce.com und wurden anhand öffentlich verfügbarer Informationen, welche auf den

Webseiten der Anbieter zu finden sind, durchgeführt. Im Folgenden werden die Ergebnisse

der Untersuchungen zusammengefasst. Ausführliche Informationen befinden sich in den

Anlagen 1 bis 4.

Die Geschäftsbedingungen der CSP sind generell in sog. „Nutzungsbedingungen“,

„Nutzervereinbarungen“ oder „Online-Abonnement-Verträgen“ festgelegt und der Umgang

mit personenbezogenen Daten in „Datenschutzbestimmungen“ beschrieben. Viele

Informationen zum Datenschutz und zu den technischen und organisatorischen Maßnahmen

zur Gewährung der Sicherheit sind

im „Sicherheits- und Compliance-Zentrum“61

für AWS,

im „Vertrauensstellungcenter“62

und dem „Office 365-Trust Center“63

für MSOS,

auf der Sicherheitsseite64

für Google Apps und

auf der „Trust“-65

und „Database“-Seite66

für Salesforce.com

zu finden.

Hauptsitz & Niederlassungen. Alle vier Anbieter sind US-Unternehmen. Zwei davon –

Microsoft und Google – haben ihre EU-Zentrale in Irland (Dublin). Amazons Europazentrale

ist in Luxemburg. Vertragspartner für europäische Kunden für Salesforce.com ist die

Tochterfirma in der Schweiz. Alle Anbieter haben eine oder mehrere Niederlassungen in

Deutschland.

Standorte der Rechenzentren. Die genauen Standorte der Rechenzentren werden bei

Google, Salesforce.com und teilweise auch bei Microsoft „aus Sicherheitsgründen“ nicht

vollständig bekannt gegeben. Alle untersuchten Anbieter bis auf Salesforce.com haben

Rechenzentren in der EU. Bei Amazon und Microsoft ist es grundsätzlich möglich, den

Standort für die DV auszuwählen. Die Anbieter behalten sich jedoch das Recht vor, die Daten

61

http://aws.amazon.com/de/security/ 62

http://www.microsoft.com/online/legal/v2/?docid=21&langid=de-de 63

http://www.microsoft.com/de-de/office365/trust-center.aspx#fbid=NvOBsMXZzFu 64

http://www.google.com/apps/intl/de/business/infrastructure_security.html 65

https://trust.salesforce.com/trust/de/ 66

http://www.database.com/en/howitworks/trusted

59

an einen anderen Ort zu verschieben, wenn das notwendig ist (z. B. bei Ausfällen oder um

Fehler zu beheben). Außerdem ist es aus den verfügbaren Dokumenten nicht hundertprozentig

nachvollzierbar, wo überall Replikationen der Daten gespeichert werden.

Vertragsrecht & Vertragssprache. Bei Amazon und Google gilt amerikanisches Recht als

allgemein anzuwendendes Vertragsrecht und bei Microsoft und Salesforce.com –

europäisches Recht. Die Dokumente, die als vertragliche Vereinbarungen dienen, sind bei

Salesforce.com und bei Amazon nur auf Englisch erhältlich. Bei Microsoft und Google sind

diese Dokumente in unterschiedlichen Sprachen verfügbar.

Zugriff externer Dritte auf Kundendaten. Alle vier Anbieter veröffentlichen Informationen

darüber, welche Dritte Zugriff auf die Daten haben bzw. Zugriff auf diese auf Basis von

Verträgen oder rechtlichen Bestimmungen erlangen können.

Regelungen zu DV und Datentransfer. Bei der DV von EU-Kunden halten sich die

Anbieter generell an die EU-US Safe Harbor Vereinbarung. Microsoft hält sich außerdem an

die EU-Datenschutzrichtlinie und schließt für den Dienst Office 365 mit EU-Kunden die sog.

„EU-Standardvertragsklauseln“ in Verbindung mit einer erweiterten

Auftragsdatenverarbeitungserklärung67

. Eine Auftragsdatenverarbeitungserklärung nach § 11

BDSG schließt außerdem Salesforce.com mit deutschen Kunden.

Löschung von Kundendaten. Wie die Löschung der Kundendaten bei den CSP nach

Beendigung des Auftragsverhältnisses genau erfolgt, wird nur bei Google und zum Teil auch

bei Microsoft beschrieben. Bei allen vier Anbietern wird erwähnt, wann die Löschung erfolgt.

Informationspflicht bei Datenpannen. Regelungen zur Informationspflicht bei

unrechtmäßigem Umgang mit den Daten von Seite der CSP oder bei ihm beschäftigten

Personen und bei Datenpannen existieren bei Microsoft und bei Google (Google hält sich

dabei an die geltenden Security Breach Notification Laws68

).

Datenschutzbeauftragter. Über einen Datenschutzbeauftragten verfügt ausschließlich

Microsoft. Er ist zuständig für den EWR und die Schweiz und kann bei Microsoft Irland

kontaktiert werden.

67

http://www.microsoft.com/de-de/office365/trust-center.aspx#fbid=kTzP5Dj4qew 68

Security Breach Notification Laws sind Gesetze, welche in fast allen US-Bundesstaaten existieren. Sie

beziehen sich generell auf elektronische oder rechnergestützte personenbezogene Daten und verpflichten

Organisationen, welche solche Daten besitzen, erheben oder verarbeitet, bestimmte Parteien (manchmal auch die

Personen, den die Daten gehören oder das Recht haben, die Daten zu verwenden) beim Auftreten von

Sicherheitsverletzungen zu benachrichtigen. [S12]

60

Verschlüsselung. Für die Verschlüsselung der Daten sind bei Amazon grundsätzlich die

Kunden verantwortlich, bei Microsoft und Google die Anbieter.

Kontrolle beim CSP. Die Kontrolle/Überprüfung der Sicherheit sowie des

Datenschutzniveaus bei den vier CSP kann grundsätzlich anhand der Dokumentation, welche

für diese Zwecke bereitgestellten wird, erfolgen. Dabei beziehen sich alle vier CSP vor allem

auf die Zertifizierungen, welche durch unabhängigen Dritte regelmäßig durchgeführt werden

und ein bestimmtes Sicherheits- und Schutzniveau garantieren. Alle vier Anbieter haben eine

ISO 27001 Zertifizierung und weitere Zertifikate, die grundsätzlich für die USA relevant sind.

Ausnahme macht hier Salesforce.com, das außerdem das TÜV-Gütesiegel Geprüfter

Datenschutz Cloud Computing V1.0 und das TRUSTe Privacy Seal (vgl. Kapitel 4.1.) hat.

Darüber hinaus erlaubt nur Salesforce.com seinen Kunden ein selbständiges vor-Ort Audit bei

Salesforce.com Inc. in den USA durchzuführen.

Kontrolle über Kundendaten. Gemäß allen vier Anbietern behalten die Kunden die

vollständige Kontrolle über ihre eigenen Daten. Sie sind verantwortlich für die Nutzerrechte-

und Kontenverwaltung, für die sichere Aufbewahrung von Anmeldeinformationen und

Passwörtern. Für die Überwachung der eigenen Daten und Anwendungen (den Zugriff auf

diese) bieten die vier Anbieter unterschiedliche Funktionen und Werkzeuge an.

Subunternehmer. Informationen zu sämtlichen Subunternehmen (Drittanbieter und

Vertragspartner), deren Tätigkeiten und die Bedingungen, unter welchen diese auf die

CSC-Daten zugreifen können, erhalten die Kunde nur bei Microsoft für den Dienst Office

365. Microsoft stellt außerdem CSC Werkzeuge bereit, mit welchen die CSC die Zugriffe von

Subunternehmen auf ihre Daten verwalten und überwachen können. Informationen über

einige der Subunternehmen, welche bei der Bereitstellung von AWS eine Rolle spielen, sind

auch teilweise vorhanden (es handelt sich vor allem um Unternehmen, die bestimmte

Software für EC2 zur Verfügung stellen).

Portabilität. Alle Anbieter bieten unterschiedliche Migrationsfunktionen und -tools zum

Importieren/Exportieren von Kundendaten.

SLA & Status der Dienste. Standardisierte SLA für die unterschiedlichen Cloud-Dienste

haben Google, Amazon und Microsoft. Sie garantieren eine Serviceverfügbarkeit von

„mindestens“ 99,9 %. Der Status der Dienste (Verfügbarkeit, Performanz) kann bei Amazon,

Microsoft und Salesforce.com online überwacht werden.

61

Haftung. Die vier Anbieter haften grundsätzlich höchstens bis zu dem Betrag, welchen der

Kunde vor der Geltendmachung des Anspruchs für das Produkt, das Grund für den Anspruch

ist, bezahlt hat.

62

5 Auswirkungen der Einhaltung rechtlicher Anforderungen auf

die Wirtschaftlichkeit des Cloud Computings

Die Anwendung von Abrechnungsmodellen wie Pay-per-Use oder Pay-as-You-Go erlaubt es,

dass die Nutzung von Cloud-Diensten mit der Nutzung von Ressourcen wie Strom und

Wasser verglichen werden können. Entsprechende Software-Werkzeuge werden bei CC als

Teil des Cloud Service Managements implementiert, um eine verbrauchsabhängige

Abrechnungserstellung zu ermöglichen. Diese Werkzeuge erfassen die Zahlen, welche für die

Berechnung des genauen Verbrauchs eines Nutzers notwendig sind. Ziel dabei ist es, dass der

Kunde nur für das bezahlen muss, was er tatsächlich verbraucht hat.

Für die Erfassung des Verbrauchs wird vor allem auf die folgenden Werte zugegriffen:

bei IaaS und PaaS – die Anzahl der verwendeten virtuellen Maschinen oder Instanzen

pro Stunde, reservierte IP-Adressen pro Stunde, gespeicherte GB pro Stunde,

eingehende oder ausgehende Daten über das Internet (in GB) und die Anzahl der

Transaktionen bei Zugriffsanfragen.

bei SaaS – Gebühr pro Anwendung und Nutzer pro Monat.

Laut CSP sind Cloud-Diente im Vergleich zur Nutzung einer selbst-betriebenen IT

preiswerter. Die am häufigsten angegebenen Gründe dafür sind:

keine Investitionen in die physische Infrastruktur,

keine Betriebskosten (Strom, Miete, etc.),

keine Wartungskosten und niedrige bis keine Managementkosten,

Personalkosteneinsparungen und

keine Kosten für die Entsorgung von Geräten.

Diese Annahmen sind jedoch nicht bei allen Bereitstellungs- und Service-Modellen gegeben.

Sie gelten an erster Stelle für Public Clouds und vor allem für SaaS- und PaaS-Lösungen. Bei

IaaS werden Kosten für Administration und Verwaltung der (virtuellen) Infrastruktur

weiterhin anfallen. Auch wenn mehrere Softwarelösungen von unterschiedlichen CSP in einer

Organisation verwendet werden, ist mit Kosten für Administration und Rechteverwaltung der

Nutzer zu rechnen.

Die Frage, ob Cloud-Dienste auf Dauer tatsächlich günstiger sind verglichen mit einer

selbst-betriebenen IT, ist umstritten. Sie bedarf der tiefen Untersuchung und eines

umfassenden Vergleichs unterschiedlicher Konzepte und Varianten. Eine Studie von Deloitte

und BITKOM aus dem Jahr 2011 hat bspw. gezeigt, dass „die Produktivsetzung einer Cloud

63

Computing-Lösung oft aufwendiger ist als erwartet“ ([De11], S. 8). Mehr als die Hälfte der

befragten Unternehmen (ca. 300) gaben an, die eingesetzten Ziele wie Kostenreduktionen und

die Vermeidung von größeren Investitionen nicht erreicht zu haben (vgl. Abb. 11).

Abbildung 11: In wie weit werden gesetzte Ziele bei dem Einsatz vom CC-Lösungen erreicht ([De11], S. 15)

Deswegen sind in den Kosten- und Wirtschaftlichkeitsanalysen von IT-Entscheidern

unterschiedliche Kostenverursachungsfaktoren zu berücksichtigen. Zu diesen gehören auch

die Auswirkungen, welche sich aus der Einhaltung rechtlicher Anforderungen bei der

Verwendung von vor allem Public Cloud-Diensten ergeben können.

Abgeleitet aus den Pflichten, die das BDSG bei der Verarbeitung personenbezogener Daten

im Auftrag für den Auftraggeber vorschreibt, werden im Folgenden die Kosten

zusammengefasst, welche durch die Einhaltung der Datenschutzvorschriften zusätzlich bei

der Verwendung von Cloud-Diensten entstehen können.

Zunächst sind die Kosten, welche für die Auswahl eines geeigneten CSP notwendig sind, zu

beachten. Zu diesen gehören:

Kosten für die Untersuchung/Überprüfung von Nutzungsbedingungen,

Datenschutzbestimmungen und SLA. Falls diese unzureichend oder nicht

befriedigend sind, dann

Kosten für Vertragsverhandlungen (und Aushandeln besserer Bedingungen).

Dabei kann es sich sowohl um interne Personalkosten, als auch um Kosten für die

Beauftragung eines Dienstleiters mit diesen Aufgaben handeln. Der zweite Fall kann

besonders dann notwendig sein, wenn die relevanten Dokumente in einer anderen als der

durch den CSC verwendeten Sprache verfasst sind.

Als zweitens sind die Kosten für die Durchführung von regelmäßigen Kontrollen zu nennen.

Diese können sich ergeben aus:

64

internen Personalkosten, falls die Kontrollen durch das Unternehmen selbst

durchgeführt werden, oder

Kosten für die Beauftragung externer Dritter und

Kosten für spezielle Monitoring- und Überwachungswerkzeuge. Diese können sowohl

extern angeschafft, als auch vom CSP angeboten und bereitgestellt werden.

Des Weiteren können Kosten für die Auswahl des Standorts (der Standorte) der DV bzw. für

die Begrenzung der Datenverarbeitung und -haltung auf ausgewählte Standorte anfallen.

Bspw. bietet Amazon seinen Kunden die Möglichkeit an, zwischen unterschiedlichen

Verfügbarkeitszonen, welche auch unterschiedliche Preise haben, auszuwählen.

Weitere Kosten, welche sich nicht unmittelbar aus den gesetzlichen Vorschriften ergeben aber

unbedingt bei der Kosten- und Wirtschaftlichkeitsanalyse zu berücksichtigen sind, sind die

Kosten für die Ablösung des CSP. Dazu zählen vor allem Kosten für Migrations- und

Export-Werkzeuge. Werden die Daten in einem nicht-standardisierten Format extrahiert, dann

können auch Kosten für das „Überführen/Übersetzen“ der Datenbestände in ein

standardisiertes oder durch andere Systeme lesbares Format entstehen.

Darüber hinaus können Kosten für die Übernahme von Daten in eine CC-Lösung auch

anfallen. So hat eine Studie, durchgeführt mit ca. 50 Anbietern von Cloud-Diensten, ergeben,

dass nur knapp 20% der Anbieter kostenlose Migrationstools oder –funktionen im Rahmen

ihres Dienstes anbieten. Circa 40% der Befragten unterstützen ihre Neukunden bei der

Datenübernahme mit zusätzlichen kostenpflichtigen Diensten ([PwC10], S. 34). Dieselbe

Studie hat außerdem ergeben, dass bei 26% der Anbieter nach der Vertragskündigung weitere

Kosten für die Kunden entstehen, von welchen bei ca. 40% der Fälle die Kosten aus

gesetzlichen Aufbewahrungsfristen resultieren ([PwC10], SS. 29-30).

65

6 Lösungen und Ansätze zur Umsetzung rechtlicher und

wirtschaftlicher Anforderungen bei der CC-basierten DV

Kapitel 3 beschreibt viele Anforderungen des Gesetzgebers an die DuD bei der Verarbeitung

unterschiedlicher Kategorien von Daten. Bei einer DV in der Wolke wird ein Großteil diese

Anforderungen vom CSC auf den CSP übertragen. Dennoch wird der CSC nicht von seinen

Pflichten befreit, einen geeigneten CSP sorgfältig auszuwählen und diesen bezüglich der

technischen und organisatorischen Maßnahmen zur Gewährleistung der DuD regelmäßig zu

kontrollieren. Viele internationalagierende CSP weisen außerdem selber darauf hin, dass

deren Dienste aufgrund von den unterschiedlichen gesetzlichen Vorschriften für bestimmte

Unternehmen, Branchen oder Zwecke nicht angemessen sein können und dass sich der Kunde

erkundigen muss, bevor er auf diese zugreift.

Im Kontext von CC wird von einer „gemeinsamer Verantwortung“ gesprochen. Konsumenten

und Anbieter teilen sich die Verantwortung für den Schutz von Daten, Anwendungen und

Systemen bei der Verwendung von Cloud-Diensten. Infolgedessen müssen beide Parteien

geeignete technische und organisatorische Maßnahmen treffen, so dass die rechtlichen

Anforderungen bei der DV erfüllt werden können.

Dieses Kapitel fasst einige technische Möglichkeiten zusammen, welche für die

rechtskonforme Verarbeitung von Daten in der Cloud signifikant beitragen können. Zusätzlich

zu den technischen Lösungen sind an manchen Stellen auch organisatorische Vorkehrungen

zu treffen, da ohne diese die technischen Lösungen ihre Wirkung entweder verlieren oder

diese geschwächt wird. Die Lösungen betreffen in unterschiedlichen Maßen Konsumenten

und Anbieter – einige sind vom CSP, andere vom CSC, wieder andere von beiden Parteien

entsprechend umzusetzen. Da die Umsetzbarkeit der beschriebenen rechtlichen

Anforderungen eine unmittelbare Auswirkung auf die Wirtschaftlichkeit des CC-Modells

haben, ist vor allem auf Lösungen zurückzugreifen, die die Prozesse bei der DV so weit wie

möglich automatisieren.

Die vorgeschlagenen Lösungen sind als eine Erweiterung der allgemeinen DuD-Maßnahmen,

die für jeden IT-Betrieb und dadurch auch für CSP und CSC gelten und bereits in anderen

Quellen ausführlich beschrieben sind (siehe z. B. bei BSI), zu betrachten.

66

6.1 Identity and Access Management

Ein Identity and Access Management ((IAM), deutsch: Identitäts- und Zugangs-/

Berechtigungsverwaltung) ist eine Lösung zur Verwaltung von Nutzeridentitäten zum Zwecke

der Authentifikation, Autorisierung und des Zugangs zu Systemen und Anwendungen.

Grundlegendes Ziel dabei ist es, sicherzustellen, dass ausschließlich berechtigte Personen

Zugriff auf vorhandene Ressourcen (Hard- und Software, Dateien) erhalten und diese nur zu

bestimmten Zwecken verwenden können.

Beim CC kommt dem IAM eine sehr wichtige Bedeutung zu. Ein umfassendes, gut

strukturiertes und funktionierendes IAM kann zum großen Teil die Anforderungen an

Zutritts-, Zugangs-, Zugriffs-, Eingabe-, Trennungs- und teilweise auch Weitergabekontrolle

bei der EDV erfüllen (vgl. Anlage (zu § 9 Satz 1) S. 2 Nr. 1, 2, 3, 4, 5, und 8 BDSG). Um das

zu ermöglichen, muss jedoch Folgendes berücksichtigt werden:

Das IAM kann nicht nur durch den Einsatz geeigneter Hard- und Software-Lösungen

und Werkzeuge realisiert werden. Es bedarf auch eine Reihe organisatorischer

Maßnahmen. Insbesondere sind:

Regeln zu definieren – z. B. Zugriffs- und Zugangsrechte sind auf das

erforderliche Minimum zu begrenzen, mehrere Nutzer dürfen nicht mit

demselben Konto arbeiten, Passwörter sind nach bestimmten Regeln zu bilden

und vertraulich zu halten, etc. –,

Nutzer für die Problematik zu sensibilisieren und regelmäßig zu schulen sowie

die Einhaltung der festgelegten Regeln ist regelmäßig zu kontrollieren.69

Das IAM muss organisationsübergreifend sein. Das bedeutet, es muss sich vom CSC

auf den bzw. die CSP sowie auf Geschäftspartner erstrecken können.

Ein geeignetes IAM muss entsprechend durch alle beteiligten Parteien – CSC, CSP,

Subunternehmer und Geschäftspartner – umgesetzt werden.

Für die Wahrnehmung von Kontrollpflichten muss das IAM weiterhin

Funktionalitäten zur Überwachung und Protokollierung von Nutzeraktivitäten, sowie

zur Meldung von Problemen anbieten.

Im CC-Kontext betreiben CSP und CSC meistens ein eigenes IAM. CSP bieten i. d. R. deren

Kunden Lösungen und Werkzeuge für die Verwaltung der eigenen Endnutzerrechte und

-konten für den jeweiligen Dienst oder für alle durch ihn bereitgestellten Dienste an. Die

herkömmlichen IAM-Lösungen haben allerdings den Nachteil, dass sie ausschließlich für die

69

Für ausführliche Informationen siehe z. B. [GSW12]

67

Nutzerverwaltung innerhalb einer Organisation bzw. einer Sicherheitsdomain konzipiert

wurden ([RR10] SS. 141, 178). Für CC werden jedoch Lösungen benötigt, welche

Nutzeridentitäten und –rechte sicher und effizient auch außerhalb der Unternehmensgrenzen

und zwischen mehreren Systemen verwalten und sich dadurch für hybride Cloud-Modelle

oder für die parallele Nutzung von Diensten unterschiedlicher CSP gut eignen. Eine solche

Lösung stellt z. B. das „Federated Identity Management“ dar.

Federated Identity Management

Eine Föderierte Identität (engl. Federated Identity) ist eine Identität, welche aus

Identitätsinformationen gehalten (verteilt) in unterschiedlichen Systemen zusammengefasst

wird.70

Das „Federated Identity Management (FIdM)“ fasst Verfahren zur Verwaltung von

Nutzeridentitäten innerhalb eines Kreises unterschiedlicher, untereinander vernetzter Systeme

zusammen. Ein FIdM weist generell folgende wichtige Charakteristiken auf:

Es basiert auf offenen Industriestandards und/oder offenen Spezifikationen wie z. B.

SAML (Security Assertion Markup Language)71

oder WS-Federation72

, welche für

Interoperabilität zwischen den Systemen sorgen.

Es dient der Authentifizierung von Personen. Es kann auch die Authentifizierung von

Anwendungen unterstützen.

Es ermöglicht das sog. „Single-Sign-on“ (SSO, Einmalanmeldung), bei welchem der

Nutzer sich nur einmal anmeldet und Zugang zu mehreren unabhängigen aber in

einem Netzwerk verbundenen Softwaresystemen bekommt.

Es unterstützt rollenbasierte Zugangskontrollen und Sitzungsverwaltung.

Es ist organisations-, sicherheitsdomänen- und anwendungsplattformenübergreifend.

([RR10] SS. 140-141)

Das FIdM ermöglicht die dezentralisierte Identitätsverwaltung, bei welcher keine

große Datenbanken verwaltet werden müssen. Identitätsinformationen werden nur in

dem jeweiligen System gehalten, für welches sie relevant sind. Dadurch werden auch

die Nutzeridentitäten besser geschützt.73

Das FIdM steigert die Automatisierung der IAM-Prozesse und führt dadurch zur

Senkung von Verwaltungsaufwand und Kosten.74

Ein FIdM funktioniert grundsätzlich in folgender Weise:

70

http://de.wikipedia.org/wiki/F%C3%B6derierte_Identit%C3%A4t (1.6.2012) 71

http://saml.xml.org 72

http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html 73

http://de.wikipedia.org/wiki/F%C3%B6derierte_Identit%C3%A4t (1.6.2012) 74

http://en.wikipedia.org/wiki/Federated_identity_management (1.6.2012)

68

Alle zu einer Föderation gehörenden Teilnehmer bilden auf Grundlage offener

Standards und gemeinsamer organisatorischer Regeln einen sog. „vertrauenswürdigen

Kreis“ (engl. „Circle of Trust“ (siehe Abb. 12 und 13)).

Ein Nutzer, der sich einmal in dem Kreis authentifiziert hat, kann sich innerhalb dieses

Kreises entsprechend seiner jeweilige Rechte „bewegen“, ohne sich bei jedem

Teilnehmer (d. h. Unternehmen oder System) neu ausweisen zu müssen.75

Die Authentifizierung geschieht bei einer vertrauenswürdigen Stelle, welche auch

„Identitätsanbieter“ (engl. Identity Provider (IdP)) genannt wird. Ein IdP verwaltet die

Konten der Nutzer, welche einen sicheren Zugang zu Webdiensten oder zu

Anwendungen externer Organisationen benötigen. Die Webdienste und die

Anwendungen externer Organisationen werden Service Provider genannt. Sie bilden

mit dem IdP eine Vertrauensbeziehung und gewähren Zugang für die Nutzer, welche

sich bei dem IdP authentifiziert haben. (vgl. [RR10] SS. 142-143)

CSC haben grundsätzlich zwei Möglichkeiten Identitätsföderation und SSO für

unternehmensinterne und Cloud-basierte Anwendungen zu realisieren ([MKL09], S. 94):

1) durch die Implementierung einer FIdM-Lösung im Haus (siehe Abb. 13) oder

2) durch die Verwendung eines Cloud-Dienstes (siehe Abb. 12). Hierbei handelt es sich

um ein CC-Modell, das „Identity-as-a-Service“ bezeichnet wird (vgl. [RR10] SS. 144-

145).

Abbildung 12: Identity-as-a-Service von Symplified76

Abbildung 13: Föderation von Organisationen mit eigenem FIdM

77

75

http://de.wikipedia.org/wiki/F%C3%B6derierte_Identit%C3%A4t (1.6.2012) 76

http://wikibon.org/w/images/e/e7/Merit_architecture.jpg (1.6.2012) 77

http://www.switch.ch/aai/about/federation/Federation_Structure.png (1.6.2012)

69

Einige Beispiele für FIdM-Lösungen für CC-Zwecke sind in Tabelle 1 aufgelistet.

Amazon bietet z. B. seinen AWS-Kunden ein IAM zur Verwaltung von Nutzeridentitäten und

-rechten an, welches die Identitätsföderation und SSO innerhalb der AWS unterstützt. Mit

etwas Programmieraufwand können AWS-Nutzer außerdem einen „Identitätsverbund“

zwischen ihrem Unternehmen und AWS erstellen und somit auch die Identitätsföderation

außerhalb des AWS-Kreises ermöglichen78

. Viele weitere CSP wie z. B. Salesforce.com,

Google und Microsoft nutzen den offenen Standard SAML für die Implementierung von

Identitätsmanagementlösungen und SSO ([RR10] SS. 142, 144). Unternehmen, welche auch

ein SAML-basiertes Identitätsmanagement bereits im Einsatz haben, können problemlos eine

Identitätsföderation mit diesen Anbietern erstellen.

Weiterführende Informationen zu FIdM-Lösungen und -Standards für CC-Zwecke sind bei

[MKL09], Seiten 73-104, und [RR10], Seiten 140-145, zu finden.

Anbieter & Lösung In-House Lösung Cloud-Dienst

CA IdentityMinder™ &

CA CloudMinder™ Identity Management79

√

√

Microsoft Identity & Access Management80

√

Oracle Identity Federation81

√

Ping Identity82

√

Siemens IT Solutions and Services83

√

SafeNet Authentication Manager (SAM) 84

√

Symplified85

√

VisualGuard86

√

Tabelle 1: Federated Identity Management Anbieter & Lösungen

Wie bereits erwähnt, müssen IAM-Lösungen weiterhin die Funktion haben, alle

Nutzerzugriffe auf die Ressourcen zu überwachen und zu protokollieren und Probleme zu

melden. Die meisten führenden CSP haben in deren IAM umfangreiche Überwachungs- und

Reporting-Funktionen implementiert. CSC haben aber i. d. R keinen Zugang zu Berichten und

78

http://aws.amazon.com/de/iam/ 79

http://www.ca.com/us/identity-management.aspx 80

http://www.microsoft.com/en-us/server-cloud/identity-access-management/default.aspx 81

http://www.oracle.com/us/products/middleware/identity-management/oracle-identity-

federation/overview/index.html 82

https://www.pingidentity.de/ 83

http://partnerdialog.siemens-enterprise.com/portal/security-news/content/identity-demand 84

http://www.safenet-inc.com/products/data-protection/two-factor-authentication/etoken-tms/ 85

http://www.symplified.com/index.html 86

http://www.visual-guard.com/EN/net-powerbuilder-application-security-authentication-permission-access-

control-rbac/visual-guard-identity-federation.html

70

Logdateien ([RR10], S. 159). Eine weitere Funktion muss deswegen den Kunden Zugang zu

relevanten Berichten/Logdateien ermöglichen. Aus Sicherheitsgründen kann es unvorteilhaft

sein, einen direkten Zugang zu diesen Dateien für externe Dritte zu gewähren, so dass diese

Idee auf geringe bis keine Akzeptanz bei den CSP stoßen kann. Deswegen bietet es sich an

dieser Stelle an, solche Informationen zu exportieren. Außerdem müssen CSC im Vertrag mit

dem CSP festlegen, wann bzw. wie oft die Exporte stattfinden sollen. Je nach Sensibilität der

verarbeitenden Daten sollen die Berichte regelmäßig (z. B. einmal in der Woche oder im

Monat), beim Auftreten von Problemen oder bei Verdacht auf Missbräuche dem CSC zur

Verfügung gestellt werden.

6.2 Verschlüsselung

Die Verschlüsselung ist eine der Methoden, welche auch durch den Gesetzgeber als besonders

geeignet angesehen wird, den Schutz und die Sicherheit personenbezogener Daten zu

gewähren. Auf der einer Seite trägt die Verschlüsselung dazu bei, Daten so zu anonymisieren,

dass sie deren Personenbezug verlieren, auf der anderen Seite kann sie eingesetzt werden, um

die Anforderungen des BDSG an Zugangs-, Zugriffs- und Weitergabekontrolle zu erfüllen

(vgl. Anlage (zu § 9 Satz 1) BDSG).

Verschlüsselungsverfahren können für unterschiedliche Zwecke eigesetzt werden. Bei CC

sind besonders Daten und Datenbestände, Zugänge, Kommunikationen und Verbindungen zu

verschlüsseln. Dabei müssen vor allem drei Aspekte berücksichtigt werden.

Zunächst ist aus Sicht der Wichtigkeit und der Sensibilität der Daten eine sinnvolle

Entscheidung zu treffen, was und wie verschlüsselt werden soll bzw. muss. Dateien und

Inhalte, welche keinen besonderen Schutz benötigen, können entweder unverschlüsselt oder

mittels einfacher kryptographischer Mechanismen, welche in vielen Softwareanwendungen

bereits vorhanden sind, verschlüsselt werden, um die hohe Kosten für starke

Verschlüsselungslösungen zu vermeiden.

Als zweites muss klar definiert werden, welche Partei für welche Aufgaben aus dem

Verschlüsselungsmanagement zuständig ist. Insbesondere die Verwaltung von Schlüsseln ist

rechtlich gesehen ausschlaggebend und muss so weit wie möglich in dem

Verantwortungsbereich des CSC liegen. Die Verschlüsselung von Daten und Backups kann

komplett vom CSC verwaltet werden. Dabei gilt die Regel: private Schlüssel (Schlüssel, die

zur Entschlüsselung der Daten dienen) müssen sicher, getrennt von den verschlüsselten Daten

71

aufbewahrt werden und dürfen nie in einer Public Cloud oder beim CSP gespeichert werden.87

Die Verschlüsselung der Kommunikation zwischen CSC und CSP ist generell eine Aufgabe

des CSP und kann bspw. durch den Einsatz von VPN realisiert werden. Der CSP muss

darüber hinaus auch dafür sorgen, dass die Verbindungen zwischen den unterschiedlichen

Rechenzentrumsstandorten sowie die Kommunikation mit Geschäftspartnern und

Subunternehmen auch gesichert sind.

Der dritte wichtige Aspekt der Verschlüsselung im Kontext des CC ist damit verbunden, dass

der Einsatz von Verschlüsselungsverfahren in den unterschiedlichen Ländern unterschiedlich

reglementiert ist. Während strikte Verschlüsselungsverbote (d. h. generelles Verbot des

Einsatzes etlicher Verschlüsselungsverfahren oder Genehmigungspflicht für den Einsatz von

Verschlüsselungsverfahren) zurzeit nur in nicht-demokratischen Ländern, wie z. B. China,

Russland und Iran existieren, besteht in vielen demokratischen und EU-Ländern eine Pflicht

zur Entschlüsselung von Dateien oder Herausgabe von Schlüsseln und Passwörtern an

staatliche Behörde in bestimmten Fällen. Beispiele für solche Länder sind Australien,

Belgien, Frankreich, Irland, die Niederlande, das Vereinigte Königreich, Singapur und andere.

Darüber hinaus ist in einigen Ländern die sog. „Schlüsselhinterlegungspflicht“ vorhanden,

welche die Verwendung von Verschlüsselungsverfahren nur in Zusammenhang mit der

Hinterlegung der Schlüssel beim Staat erlaubt. Eine solche Pflicht „scheint es“ in Spanien zu

geben und in den USA wird über ihre Einführung immer wieder diskutiert.88

In Deutschland

existieren keine gesetzlichen Beschränkungen für den Einsatz von kryptographischen

Verfahren. (vgl. [G10], SS. 116-120)

Das ist ein weiterer Grund für CSC auf Verschlüsselungsangebote von CSP so weit wie

möglich zu verzichten oder zusätzlich zu den Verschlüsselungsleistungen der CSP ihre

wichtigen Daten und Inhalte selber zu verschlüsseln.

6.2.1 Vorhandene Lösungen

Für die Verschlüsselung von Dateien durch den CSC bevor diese in die Cloud ausgelagert

werden (wobei die Schlüssel beim Nutzer verbleiben), existiert bereits eine Reihe von

Lösungen. Dabei handelt es sich vorwiegend um Werkzeige, welche für Speicherlösungen

(sog. Storage in the Cloud) entwickelt und geeignet sind. Einige Beispiele sind BoxCryptor89

,

Wuala90

, TrueCrypt91

, CipherCloud92

, Sophos93

, Cloudfogger94

, Apsec95

. Bei dem letzteren

87

Für Best-Practices der Schlüsselverwaltung siehe [BSI11], Seiten 36-37 88

http://www.zeit.de/digital/internet/2010-09/obama-cryptowar (28.5.2012) 89

http://www.boxcryptor.com/?lang=de 90

http://www.wuala.com/

72

handelt es sich außerdem um eine Verschlüsselungslösung für Microsoft SharePoint, welche

„alle Dokumente automatisch bereits auf dem Arbeitsplatz jedes SharePoint-Nutzers“

verschlüsselt bevor die Dokumente in die SharePoint-Datenbank eingelegt werden. Diese

Verfahren sind jedoch nur dafür geeignet, Daten und Ordner vor deren Auslagerung in die

Cloud zu verschlüsseln. Um die Daten verarbeiten zu können, müssen diese entschlüsselt

werden.

6.2.2 Lösungen in der Forschungsphase

In der Forschung wird seit einigen Jahren an Projekten gearbeitet, welche die Ausführung

bestimmter Funktionen auf verschlüsselten Daten ermöglichen. Die Projekte zielen darauf ab,

die sichere Verarbeitung von Daten in der Cloud zu ermöglichen. Im Folgenden werden zwei

solche Projekte dargestellt.

CS2: A Searchable Cryptographic Cloud Storage System [KPR11]

„CS2: A Searchable Cryptographic Cloud Storage System“ ist ein Projekt von Microsoft

Research, das sich mit der Entwicklung eines kryptographischen Datenspeichersystems

beschäftigt. Das System strebt folgende Eigenschaften an:

korrekte Ausführung von Suchanfragen auf verschlüsselte und in der Cloud

gespeicherte Dateien,

sicheres Einfügen und Löschen von Dateien,

Überprüfung der Integrität der beim CSP gespeicherten Daten und

die Versicherung, dass CSP nicht an Informationen über CSC-Daten erlangen können,

indem sie die Daten oder die Anfragen auf diese Daten analysieren.

Die Lösung basiert auf neuen kryptographischen Primitiven und Protokollen, welche durch

Microsoft Forscher verbessert und weiterentwickelt werden, so dass sie „hoch effizient und

nachweislich sicher“ sind. Diese sind:

Symmetric Searchable Encryption (SSE) (etwa Symmetrische Verschlüsselung mit

Suchfunktion) – ein Verfahren zur Durchführen von Suchanfragen auf verschlüsselte

Dateien.

91

http://www.truecrypt.org/ 92

http://www.ciphercloud.com/cloud-encryption.aspx 93

http://www.sophos.com/de-de/products/encryption/safeguard-enterprise/product-modules/cloud-

encryption.aspx 94

https://www.cloudfogger.com/de/home/index.aspx 95

https://www.apsec.de/loesungen/produkte/fideas-file-enterprise/cloud-protection

73

Such-Authentifikatoren – kryptographische Stammfunktion, welche dem CSC die

Sicherheit gibt, dass der CSP auf seine Suchanfrage korrekt und vollständig

geantwortet hat – und

„Proof of Storage“ (PoS) – ein Protokoll zur Sicherstellung der Integrität der Daten,

ohne die Daten aufrufen bzw. herunterladen zu müssen.

Auch wenn die im Projekt erzielten Resultate durch die Forscher als „effizient und praktisch“

bewerten wurden, findet die vorgeschlagene Lösung noch keinen Einsatz in die Praxis.

Homomorphe Verschlüsselung [LNV11]

Die „homomorphe Verschlüsselung“ (HV) stellt eine Möglichkeit zur sinnvollen

Verarbeitung verschlüsselter Daten ohne diese zu entschlüsseln dar. Es werden zwei Formen

der HV unterschieden – arithmetische und nicht-arithmetische HV. Die arithmetische

homomorphe Verschlüsselung (AHV) unterstützt die Ausführung von Addition und/oder

Multiplikation auf die verschlüsselten Daten. Ein AHV-Schema, das beide Operationen

Addition und Multiplikation unterstützt, wird „vollhomomorphe Verschlüsselung“ (VHV)

genannt. [KR11]

Die VHV kann es dadurch, dass sie eine beliebige Anzahl von Additionen und

Multiplikationen auf die verschlüsselten Daten unterstützt, ermöglichen, dass jede beliebige

Funktion auf diese Daten ausgeführt werden kann. Sie hat jedoch einen wesentlichen

Nachteil. Sie ist sehr ineffizient und somit auch unpraktisch.

In dem Paper „Can Homomorphic Encryption be Practical?“ zeigen Microsoft Forscher, dass

bereits eine sog. „etwas (engl. somewhat) homomorphe Verschlüsselung“, d. h. HV, welche

nur eine der Operationen Addition oder Multiplikation und dadurch nur eine begrenzte

Anzahl an homomorphen Berechnungen auf die verschlüsselten Daten unterstützt, sinnvoll für

bestimmte Diensten eingesetzt werden kann. Die „etwas“ homomorphe Verschlüsselung ist

im Gegensatz zu der VHV viel schneller und kompakter. Sie erlaubt die Ausführung einfacher

statistischer Operationen wie z. B. Durchschnitt, Standardabweichung, logistische Regression

u. a., welche generell für die Erstellung von Vorhersagen zu erwünschten oder unerwünschten

Folgen wie z. B. die Wahrscheinlichkeit, dass ein Patient einen Herzanfall bekommt,

verwendet werden.

[LNV11] beschreiben drei Szenarien, in welchen eine semantisch sichere „etwas“

homomorphe Verschlüsselung eingesetzt werden kann, um in der Cloud

medizinische oder gesundheitsrelevante Daten auszuwerten,

74

Funktionen auf finanzielle Daten durchzuführen und

Informationen zum Zwecke der Werbung zu verarbeiten.

Dabei berücksichtigen die Forscher auch die Tatsache, dass nicht nur die Daten besonders

schützenswert sein können und verschlüsselt werden müssen, sondern, dass auch die

Funktionen, welche auf die Daten auszuführen sind, sensibel sein können, so dass sie auch in

verschlüsselter Form in einer Public Cloud ausgelagert und ausgeführt werden müssen. Diese

Funktionen werden dann „private oder proprietäre“ Funktionen bezeichnet.

Die Verarbeitung homomorph-verschlüsselter Daten nimmt grundsätzlich den folgenden

Verlauf an:

1) Der CSC verschlüsselt die Daten und schickt sie an den CSP.

2) Wenn der CSC eigene „private“ Funktionen auf die Daten ausführen möchten, muss er

diese auch verschlüsseln und an den CSP verschicken.

3) Der CSP verarbeitet die Daten mittels homomorpher Operationen und schickt die

Resultate der Verarbeitung in verschlüsselter Form an den CSC zurück.

4) Der CSC entschlüsselt die Resultate.

Da in der Regel die Kommunikation zwischen CSC und CSP über das Internet mittels

nicht-homomorph verschlüsselter Texte geschieht, werden außerdem zwei weitere Schritte

notwendig. Bevor die verschlüsselten Daten beim CSP verarbeitet werden können, müssen

diese zunächst in die homomorph-verschlüsselte Form gebracht werden. Nach der

Berechnung müssen die Ergebnisse, welche homomorph-verschlüsselt sind, wieder in die

entsprechende Verschlüsselungsform überführt werden, so dass sie an den CSC verschickt

werden können und er diese auch entschlüsseln kann.

Die Tests der Microsoft-Forscher zeigen, dass schon „etwas“ homomorphe Verschlüsselung

für bestimmte Cloud-Dienste ausreichend ist. Die Lösung ist jedoch noch nicht effizient

genug, um sie in der Praxis einsetzen zu können.96

6.3 Hybride Lösungsansätze

Im Kern der hybriden Lösungsansätze steht die Segmentierung bzw. die Teilung von Daten

und Datenbeständen nach unterschiedlichen Wichtigkeits- und Sensibilitätsstufen. Die in

diesem Abschnitt zusammengefassten Konzepte unterscheiden sich in folgender Maße:

96

http://www.technologyreview.com/computing/38239/ (30.5.2012)

75

Die ersten zwei setzen voraus, dass bzw. eignen sich für die Fälle, wenn eine klare

Trennung der im Unternehmen zur verarbeitenden Daten in unterschiedlichen

Kategorien sich manuell ohne großen Aufwand durchführen lässt.

Die letzten zwei beziehen sich auf die Situationen, bei welchen die Daten so vermischt

sind, dass ihre Klassifizierung/Kategorisierung nur mit sehr hohem Aufwand manuell

durch den Nutzer realisiert werden kann.

Hybride Clouds

In manchen Fällen lässt sich die Einhaltung von rechtlichen Vorschriften an die DV effektiv

und effizient durch die Implementierung eines Hybrid-Cloud-Modells gewährleisten. Dabei

wird die Private Cloud ausschließlich für die Verarbeitung besonders schützenswerter Daten

verwendet und Daten oder Prozesse, welche kein hohes Maß an Schutz erfordern, werden in

die Public Cloud ausgelagert. Darüber hinaus können auch Daten, welche sich sicher (z. B.

durch geeignete Verschlüsselungsverfahren) außerhalb der privaten Cloud aufbewahren

lassen und nur selten verarbeitet werden müssen, auch in die Public Cloud ausgelagert

werden.

Die Implementierung eines Hybrid-Cloud-Modells ist technisch und wirtschaftlich nur

sinnvoll, wenn einige Bedingungen erfüllt sind. Diese sind:

Es werden sowohl sensible als auch nicht sensible Daten verarbeitet.

Die sensiblen Daten lassen sich eindeutig und ohne großen Aufwand von den

nicht-sensiblen trennen.

Die Verarbeitung der nicht-sensiblen Daten kann separat von der Verarbeitung der

sensiblen erfolgen. Im Idealfall werden für die Verarbeitung der unterschiedlichen

Datenkategorien verschiedene Anwendungen benötigt.

Mashups

Mit dem CSP Salesforce.com haben CSC die Möglichkeit sensible Daten zu verarbeiten, ohne

diese in den Salesforce.com-Dienst laden zu müssen. Die Daten werden „lediglich am

Bildschirm zur Laufzeit angezeigt“ und verbleiben auf dem Rechner des Kunden. Dafür kann

auf Technologien zugegriffen werden wie z. B. „Mash-up von Daten“. [SF10]

In der Informatik existiert keine einheitliche Definition des Begriffs Mashup. Generell wird

darunter das Vermischen von Daten aus einer Quelle (i. d. R. einer Webseite) mit Daten oder

Funktionen aus einer zweiten Quelle (generell ein Webdienst), mit dem Ziel neue Inhalte zu

erstellen, verstanden. Dafür stellt die zweite Quelle der ersten Quelle, welche auch als Nutzer

76

bezeichnet werden kann, eine Programmierschnittstelle zur Verfügung.97

Aus

Architektur-Sicht werden zwei Haupttypen von Mashups unterschieden – Client-seitige und

Server-seitige. Bei Client-seitigen Mashups werden die Daten und Funktionen aus den beiden

Quellen geladen und direkt in dem Client, was generell der Webbrowser des Nutzers ist,

vermischt (vgl. Abb. 14). Server-seitige Mashups vermischen Daten und Funktionen auf

einem entfernten (Web-)Server und verschicken die Resultate an den Webbrowser des

Nutzers [OBB07a], [OBB07b]. Client-seitige Mashups können somit für die Verarbeitung

von Daten durch einen Cloud-Dienst eingesetzt werden, ohne dass die Daten den Standort des

CSC verlassen zu müssen.

Abbildung 14: Funktionsweise eines Client-seitigen Mashup ([OBB07b])

(Semi-)Automatisierte Datensegmentierung

Wie bereits erwähnt, müssen für die Segmentierung vermischter Daten, d. h. Daten, welche

sowohl aus sensiblen als auch aus nicht-sensiblen Elementen bestehen, Techniken eingesetzt

werden, die die automatisierte oder die semi-automatisierte Trennung der unterschiedlichen

Datenelemente unterstützen.

Datensegmentierung wird bspw. für die Verarbeitung gesundheitsrelevanter Daten in den sog.

elektronischen Patientenakten (ePA) in den USA bereits eingesetzt. Die Lösungen

ermöglichen, dass bestimmte Daten/Informationen als „sensibel“ oder „privat“ eingestuft

werden können. Die Kategorisierung kann, je nach Implementierung, entweder automatisiert

geschehen oder manuell durch den Patienten oder das medizinische/pflegende Personal

97

http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29 (3.6.2012)

77

vorgenommen werden. Manche Ansätze erlauben auch beide Ausführungen. Eine

automatisierte Kategorisierung basiert generell auf Regeln und Grundsätzen, welche aus den

Gesetzen zur Gesundheitsversorgung abgeleitet werden. Die Regeln können bspw. als Filter

implementiert werden, welche „sensible“ Datenelemente beim Exportieren der Daten

erkennen und ausfiltern. Die als „sensibel“ eingestuften Datenelemente können außerdem bei

der Ausführung anderer Operationen auf die Daten wie z. B. lesen, schreiben oder kopieren

versteckt oder ausgeblendet werden. In den meisten Fällen müssen die Daten in den Akten so

strukturiert sein, dass anhand von Identifikationen erkannt werden kann, um was für

Informationen es sich jeweils handelt (z. B. um allgemeine Patienteninformationen wie Alter,

Größe, Gewicht, etc. oder um Informationen zu besonderen Krankheiten wie

Geistesstörungen oder AIDS). [GR10]

Die für die Verwaltung ePA vorhandenen Konzepte und Lösungen können auf das

CC-Modell übertragen werden, um sensible Datenelemente bei der DV in der Cloud

auszufiltern, zu verstecken oder zu anonymisieren. Dieser Ansatz ist allerdings nur dann

sinnvoll, wenn die so veränderten Daten in dieser Form in einer Public Cloud sinnvoll

verarbeitet werden können und ihre ursprüngliche Bedeutung nur im Zusammenhang mit den

beim CSC gehaltenen Inhalten wieder hergestellt werden kann (vgl. [Bitk10] S. 76).

Daten- und Programmpartitionierung

An einer weiteren Möglichkeit zur sicheren und rechtskonformen Verarbeitung von Daten

mittels Cloud-basierter Lösungen arbeitet derzeit die Forschungsgruppe Rechnerarchitektur

der Universität Rostock98

im Projekt „Secure Cloud: Sicherheit im Cloud Computing“. Sie

untersucht die Möglichkeit zur Entwicklung geeigneter Verfahren zur Partitionierung sowohl

von Daten als auch vom Programmcode. Das Projekt besteht aus drei Hauptteilen, von

welchen an dieser Stelle zwei grob beschrieben werden.

„Data Partitioning“ (Datenpartitionierung). Anhand bestimmter Kriterien werden Daten,

welche ein besonders hohes Maß an Sicherheit erfordern wie z. B. personenbezogene Daten,

Firmengeheimnisse, etc., (teil-)automatisiert erkannt. Diese werden nicht in die Cloud zur

Verarbeitung übertragen, sondern verbleiben beim CSC.

„Code Partitioning“(Programmpartitionierung). Ein Programm, das im Besitz des CSC ist,

wird (teil-)automatisiert in „private“ und „öffentliche“ Teile getrennt. Die „öffentlichen

Programmteile“ werden an den CSP geschickt. Funktionsaufrufe werden in Remote Procedure

Calls (RPC) umgewandelt und die „privaten Programmteile“ werden entfernt aufgerufen. Die

98

https://wwwra.informatik.uni-rostock.de/

78

privaten Programmteile verbleiben beim CSC und werden dort ausgeführt. Die

Programmpartitionierung hat zum Ziel, sowohl sensible Daten als auch wichtige

Programmteile/Funktionen, welche nicht in eine Public Cloud übertragen werden sollen, zu

schützen.

Das Projekt befindet sich noch in der Anfangsphase, so dass keine ausführlicheren

Informationen oder Forschungsergebnisse vorhanden sind.

6.4 Gewährung von Verfügbarkeitskontrolle

Fälle, wie die Anmeldung einer Insolvenz durch den CSP oder das Auftreten von Störungen

und Ausfällen bei den Systemen des CSP, können zu dem Verlust oder der Zerstörung von

Daten führen. CSC müssen sich vor solchen Fällen schützen, wenn bestimmte Arten von

Daten beim CSP verarbeitet werden (vgl. Anlage (zu § 9 Satz 1) S. 2 Nr. 7 BDSG). Das kann

mit wenig Aufwand erreicht werden, indem Backups regelmäßig erstellt und sicher

aufbewahrt werden. Backups können entweder vom CSP durchgeführt werden oder durch den

CSC selbst. Im ersten Fall ist vertraglich zu vereinbaren, dass die Backups regelmäßig an den

CSC zu übergeben sind. Die Backups müssen außerdem getrennt vom CSP gelagert werden.

Das bedeutet nicht, dass die Lagerung unbedingt im eigenen Haus beim CSC stattfinden soll.

Es kann für diesen Zweck ein weiterer (sekundärer) CSP eingeschaltet werden. In diesem Fall

ist aber zu berücksichtigen, dass zwischen den zwei CSP keine Interdependenzen existieren.

Das bedeutet, es darf kein Anbieter als sekundär CSP ausgewählt werden, der seine Dienste

auf der Infrastruktur des ersten CSP betreibt (vgl. [R09], SS. 131-132). Bspw. sollten

Dropbox-Nutzer auf keinen Fall als sekundären Cloud-Storage-Anbieter Amazon nehmen, da

die Dropbox-Dienste auf Amazon S3 basieren99

. Des Weiteren müssen die Backups, welche

in einer Public Cloud gelagert werden, unbedingt verschlüsselt werden.

99

https://www.dropbox.com/terms#privacy (2.6.2012)

79

7 Zusammenfassung

Diese Arbeit hatte zum Ziel, die technische Umsetzbarkeit gesetzlicher Vorschriften und

wirtschaftlicher „Versprechungen“ beim CC zu analysieren. Dafür wurden zunächst die

Grundlagen des CC vorgestellt. Technologien wie Virtualisierung, Lastverteilung und

Mandantenfähigkeit sind der Kern von Cloud-Diensten. Sie ermöglichen die effiziente

Nutzung von Ressourcen und sorgen für Transparenz.

Im dritten Kapitel wurden die datenschutzrechtlichen Aspekten bei der EDV vorgestellt und

deren Bezug zum CC erläutert. Aus datenschutzrechtlicher Sicht handelt es sich beim CC

grundsätzlich um eine Auftragsdatenverarbeitung, bei welcher der Auftraggeber (der CSC)

die vollständige Verantwortung über die zu verarbeitenden Daten trägt. Diese Verantwortung

spiegelt sich in den Pflichten des CSC zur sorgfältigen Auswahl und regelmäßigen Kontrolle

des Auftragnehmers (des CSP) wieder, welche bei vor allem großen CSP mit weltweit

verteilten Rechenzentren praktisch nicht erfüllt werden können. Darüber hinaus sieht das

EU-Datenschutzrecht vor, dass personenbezogene Daten ausschließlich in der EU / im EWR

verarbeitet werden sollen. Für die Verarbeitung personenbezogener Daten außerhalb dieser

Grenzen müssen zusätzliche Bedingungen berücksichtigt werden.

Die datenschutzrechtlichen Vorgaben stehen somit in Widerspruch zu der Vorstellung über

das CC, dass der Nutzer sich nicht mehr um die IT kümmern muss, sondern sich auf sein

Kerngeschäft konzentrieren kann. Der Nutzer ist für die Gewährleistung von Datenschutz und

Datensicherheit bei der CC-basierten Datenverarbeitung mitverantwortlich.

Im ersten Teil von Kapitel 4 wurden Zertifizierungsprogramme, Checklisten und Leitfäden

sowie Online Cloud-Dienste-Register vorgestellt. I. S. v. CC gelten Zertifizierungen als

wichtige Werkzeuge, um die Sicherheits- und Datenschutzvorkehrungen, welche bei den

Anbietern getroffen sind, zu beurteilen und Schlussfolgerungen zur Angemessenheit des

Datenschutz- und Datensicherheitsniveaus abzuleiten. Aktuell existieren jedoch keine

Zertifizierungs- und Auditierungsverfahren, welche alle CC-Besonderheiten umfassend

berücksichtigen und sich für alle Bereitstellungs- und Service-Modelle eignen.

Teil zwei des vierten Kapitels schlägt einen Fragenkatalog zur Untersuchung eines CSP auf

seine Eignung, personenbezogene Daten zu verarbeiten, vor. Der Katalog wurde praktisch

umgesetzt, indem die Lage bei vier großen CSP untersucht wurde. Die Untersuchungen

wurden nur anhand öffentlich zugänglicher Dokumente und Informationen durchgeführt. Sie

haben ergeben, dass diese Unternehmen sich bemühen, Transparenz zu schaffen, indem sie

80

viele Informationen zu technischen und organisatorischen Vorkehrungen offen legen.

Allerdings sind die Informationen an manchen Stellen nicht ausreichend und widersprüchlich.

Die praktische Umsetzung des Fragenkatalogs hat sich als schwierig und zeitaufwendig

erwiesen. Personen, welche diesen Katalog anwenden, müssen über ausreichendes Wissen aus

unterschiedlichen Fachgebieten – insbesondere IT und Recht – sowie über gute

Englischkenntnisse verfügen.

Im Kapitel 5 wurden Faktoren beschrieben, welche auf die Wirtschaftlichkeit vom CC

Auswirkungen haben und möglicherweise bei den Kostenanalysen von Entscheidern nicht

immer berücksichtigt werden. Dabei wurde vorwiegend auf Kosten eingegangen, welche aus

der Einhaltung datenschutzrechtlicher Vorschriften resultieren. Ob diese Faktoren tatsächlich

die Kosten für CSC wesentlich erhöhen, muss noch untersucht werden.

Das letzte Kapitel dieser Arbeit fasst einige technische Lösungsansätze zusammen, mit denen

sich die Risiken, die mit der Auslagerung der eigenen IT in die Cloud entstehen, wie z. B. der

Verlust der Kontrolle auf die eigenen Daten und der Verstoß gegen gesetzliche Vorschriften,

minimieren lassen. Ein Teil der Lösungen findet bereits in der Praxis Einsatz, ist jedoch mit

zusätzlichem Aufwand für die CSC verbunden und muss durch organisatorische

Vorkehrungen und an einigen Stellen auch durch vertragliche Regelungen unterstützt werden.

Für Unternehmen, die sowohl personenbezogene als auch andere Kategorien von Daten, die

keinen hohen bzw. großen Schutzbedarf aufweisen, scheint momentan die sinnvollste Lösung

ein hybrides Modell zu implementieren, bei welchem die sensiblen Daten beim CSC intern

und die nicht-sensiblen Daten in einer (oder mehreren) Public Cloud(s) verarbeitet werden, zu

sein. Der andere Teil der Lösungsansätze befindet sich noch in der Forschungsphase und kann

noch nicht in der Praxis eingesetzt werden. An dieser Stelle besteht noch ein großer

Forschungsbedarf.

81

Literaturverzeichnis

Bücher & Zeitschriften

[AG10] Antonopoulos, N. & Gillam, L.: Cloud Computing: Principles, Systems and

Applications, Springer-Verlag London Limited 2010

[BKNT11] Braun, C.; Kunze, M.; Nimis, J.; Tai, S.: Cloud Computing: Web-basierte

dynamische IT-Services, 2. Auflage, Informatik im Fokus, Springer-Verlag

Berlin Heidelberg 2011

[DG06] Dix, A.; Gardain, A. M.: Datenexport in Drittstaaten: Neue Wege zur

Gewährleistung ausreichender Datenschutzgarantien, DuD Datenschutz und

Datensicherheit, Volume 30, Ausgabe 6/2006, Seiten 343-346

[FR10] Fröschle, H. P. & Reinheimer, S. (Hrsg.): Cloud Computing & SaaS, HMD –

Praxis der Wirtschaftsinformatik, Heft 275, Oktober 2010, dpunkt Verlag

Heidelberg

[GSW12] Grünendahl, R. T.; Steinbacher, A. F. & Will, P. H.L.: Das IT-Gesetz:

Compliance in der IT-Sicherheit: Leitfaden für ein Regelwerk zur IT-Sicherheit

im Unternehmen, 2., aktualisierte Auflage, Springer Vieweg (Vieweg+Teubner

Verlag), Wiesbaden, 2012

[MKL09] Mather, T.; Kumaraswamy, S. & Latif, S.: Cloud Security and Privacy: An

Enterprise Perspective on Risks and Compliance, O’Reilly Media, Sebastopol,

CA, September 2009, First Edition

[MS11] Marnau, N.; Schlehahn, E.: Cloud Computing und Safe Harbor, DuD

Datenschutz und Datensicherheit, Volume 35, Ausgabe 5/2011, Seiten 311-316

[PHG11] Picot, A.; Hertz, U. & Götz, T.: Trust in IT – Wann vertrauen Sie Ihr Geschäft

der Internet-Cloud an?, Springer-Verlag Berlin Heidelberg 2011

[R09] Reese, G.: Cloud Application Architectures – Building Applications and

Infrastructure in the Cloud, O’Reilly Media, Sebastopol, CA, April 2009, First

Edition

[RR10] Rittinghouse, J. W.; Ransome, J. F.: Cloud Computing – Implementation,

Management, und Security, CRC Press, 2010

82

[W10] Weichert, T.: Cloud Computing und Datenschutz, DuD Datenschutz und

Datensicherheit, Volume 34, Ausgabe 10/2010, Seiten 679-687

Online Quellen

[AWS11a] AWS Customer Agreement, Last updated August 23, 2011

http://aws.amazon.com/de/agreement/ (20.12.2011)

[AWS11b] AWS Service Terms, Last updated: December 1st, 2011

http://aws.amazon.com/de/serviceterms/ (11.12.2011)

[AWS11c] Amazon Web Services: Overview of Security Processes, May 2011

http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf (13.12.2011)

[AWS11d] Amazon Web Services: Risk and Compliance, May 2011

http://d36cz9buwru1tt.cloudfront.net/pdf/aws-risk-and-compliance-whitepaper.pdf

(14.12.2011)

[BDSGa] Bundesdatenschutzgesetz – Text und Erläuterung, Der Bundesbeauftragte für

den Datenschutz und die Informationsfreiheit, 15 Auflage, Januar 2011, Druck

+ Verlag GmbH Rheinbach

http://www.bfdi.bund.de/SharedDocs/Publikationen/Infobroschueren/INFO1_Januar_

2011.pdf;jsessionid=24E5BA3B867790EE6B1674BF68F7D989.1_cid136?__blob=pu

blicationFile (1.4.2012)

[Bitk09] Cloud Computing - Evolution in der Technik, Revolution im Business

BITKOM- Leitfaden, Oktober 2009

http://www.bitkom.org/files/documents/BITKOM-Leitfaden-

CloudComputing_Web.pdf (11.3.2012)

[Bitk10] Cloud Computing – Was Entscheider wissen müssen. Ein ganzheitlicher Blick

über die Technik hinaus. Positionierung, Vertragsrecht, Datenschutz,

Informationssicherheit, Compliance; Leitfaden, BITKOM 2010

http://www.bitkom.org/files/documents/BITKOM_Leitfaden_Cloud_Computing-

Was_Entscheider_wissen_muessen.pdf (11.3.2012)

[Bitk12] Presseinformation: Die Hightech-Trends des Jahres 2012, BITKOM, Berlin,

18. Januar 2012

83

http://www.bitkom.org/files/documents/BITKOM-Presseinfo_IT-

Trends_des_Jahres_18_01_2012.pdf (8.6.2012)

[BSI11] Sicherheitsempfehlungen für Cloud Computing Anbieter

(Mindestsicherheitsanforderungen in der Informationssicherheit),

Eckpunktepapier, BSI 2011

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindestanforderungen/Eck

punktepapier-Sicherheitsempfehlungen-CloudComputing-

Anbieter.pdf?__blob=publicationFile (10.3.2012)

[CW12] Hackmann, J.: Datenschutz und Cloud Computing: Ärger um den Patriot Act,

23.4.2012, Computerwoche

http://www.computerwoche.de/management/cloud-computing/2503872/index2.html

(4.5.2012)

[De11] Cloud Computing in Deutschland: Ergebnisse der Umfrage von Deloitte und

BITKOM, Deloitte Consulting GmbH, Februar 2011

http://www.deloitte.com/view/de_DE/de/branchen/technology-media-

telecommunications/technologyfast50/47a8f3a12ed9d210VgnVCM3000001c56f00aR

CRD.htm# (8.6.2012)

[DK10] Beschluss der obersten Aufsichtsbehörden für den Datenschutz im nicht-

öffentlichen Bereich am 28./29. April 2010 in Hannover (überarbeitete Fassung

vom 23.8.2010), Prüfung der Selbst-Zertifizierung des Datenimporteurs nach

dem Safe Harbor-Abkommen durch das Daten exportierende Unternehmen,

Sitzung des Düsseldorfer Kreises am 28./29. April 2010 in Hannover

http://www.bfdi.bund.de/SharedDocs/Publikationen/Entschliessungssammlung/Duesse

ldorferKreis/290410_SafeHarbor.pdf?__blob=publicationFile (1.5.2012)

[eco10a] Leitfaden Cloud Computing – Recht, Datenschutz & Compliance

EuroCloud Deutschland_eco e. V., Köln, November 2010

http://www.eurocloud.de/2010/12/02/eurocloud-leitfaden-recht-datenschutz-

compliance/ (22.12.2011)

[eco10b] EuroCloud Star Audit Certificate Software as a Service – Kurzinformation

EuroCloud Deutschland_eco e.V., SaaS Gütesiegel 1.0, Stand 12/2010

http://www.saas-audit.de/files/2011/03/quick-reference_de.pdf (10.5.2012)

[eco_c] Der Qualitätsstandard für SaaS-Anwendungen – EuroCloud Star Audit

Certificate Software as a Service; EuroCloud Deutschland_eco e.V.

http://www.saas-audit.de/files/2011/03/saas-flyer_de.pdf (10.5.2012)

84

[eco_d] EuroCloud Star Audit Zertifizierung Software as a Service –

Zertifizierungsvertrag; EuroCloud Deutschland_eco e. V.

http://www.saas-audit.de/files/2011/02/Vertrag_de.pdf (10.5.2012)

[eco11] EuroCloud Star Audit Zertifizierungen Software as a Service – Allgemeine

Produktinformationen und Preise; EuroCloud Deutschland_eco e. V.,

Stand: 28.2.2011

http://www.saas-audit.de/files/2011/03/pricelist_de.pdf (10.5.2012)

[EC12a] Why do we need an EU data protection reform?, the European Commission

http://ec.europa.eu/justice/data-protection/document/review2012/factsheets/1_en.pdf

(1.5.2012)

[EC12b] How will the EU’s data protection reform strengthen the internal market?, the

European Commission

http://ec.europa.eu/justice/data-protection/document/review2012/factsheets/4_en.pdf

(1.5.2012)

[EPriSe11] European Privacy Seal – privacy at its best. EuroPriSe Criteria, May 2011

https://www.european-privacy-

seal.eu/criteria/EuroPriSe%20Criteria%20May%202011%20final.pdf (16.5.2012)

[G10] Gerhards, J.: (Grund-)Recht auf Verschlüsselung?, Vom Fachbereich Rechts-

und Wirtschaftswissenschaften der Technischen Universität Darmstadt

genehmigte Dissertation zur Erlangung des akademischen Grades eines Doctor

iuris (Dr. iur.), Darmstadt 2010

http://tuprints.ulb.tu-darmstadt.de/2821/ (28.5.2012)

[Goog11a] Google Apps for Business (Online) Vereinbarung, 24. August 2011

http://www.google.com/apps/intl/de/terms/premier_terms.html (12.6.2012)

[Goog11b] Security Whitepaper: Google Apps Messaging and Collaboration Products,

Google 2011

https://docs.google.com/file/d/0B5Y-

fwYJF2hLOTVmMzQ1MjAtMDFmNS00YjFhLWI3MmUtZjI5MDQ5Mzc3NmMz/e

dit?pli=1 (12.6.2012)

[Goog12a] Google Nutzungsbedingungen, 1. März 2012

http://www.google.de/policies/terms/regional.html (12.6.2012)

[Goog12b] Google Datenschutzerklärung, 1. März 2012

http://www.google.com/intl/de/policies/privacy/ (12.6.2012)

85

[GR10] Goldstein, M. M. & Rein, A. L.: Data Segmentation in Electronic Health

Information Exchange: Policy Considerations and Analysis, September 29,

2010

http://www.academyhealth.org/files/HIT/DataSegmentationWhitepaper.pdf

(28.5.2012)

[HE11] Host Europe – Trusted Cloud, 28.11.2011

http://www.hosteurope.de/download/Trusted_Cloud.pdf (12.5.2012)

[IBM11] IBM Cloud Computing Reference Architecture 2.0, Introduction and

Architecture Overview, 28.2.2011

http://navigatingthroughthecloud.com/wp-

content/uploads/2012/02/CCRA.IBMSubmission.pdf (22.1.2012)

[IT-G11] Rechtliche Anforderungen an Cloud Computing – Sichere Cloud-Dienste,

IT-Gipfel 2011, Version 1.0, 15. Nov. 2011

http://www.eurocloud.de/files/2012/03/Anford_Recht_beiCloudComputing_V1.pdf

(15.4.2012)

[iX] Böken, A.: Patriot Act und Cloud Computing: Zugriff auf Zuruf?, iX Magazin

für professionelle Informationstechnik, heise Online

http://www.heise.de/ix/artikel/Zugriff-auf-Zuruf-1394430.html (4.5.2012)

[KL10] Kamara, S. & Lauter, K.: Cryptographic Cloud Storage, Microsoft Research,

January 2010

http://research.microsoft.com/apps/pubs/?id=112576 (27.5.2012)

[KPR11] Kamara, S.; Papamanthou, C. & Roeder, T.: CS2: A Searchable Cryptographic

Cloud Storage System, Microsoft Research, May 2011

http://research.microsoft.com/apps/pubs/default.aspx?id=148632 (27.5.2012)

[KR11] Kamara, S. & Raykova, M.: Parallel Homomorphic Encryption, Microsoft

Research, November 2011

http://research.microsoft.com/apps/pubs/default.aspx?id=155853 (27.5.2012)

[LNV11] Lauter, K.; Naehrig, M. & Vaikuntanathan, V.: Can Homomorphic Encryption

be Practical?, Microsoft Research, 6 May 2011

http://research.microsoft.com/apps/pubs/default.aspx?id=148825 (27.5.2012)

[LTM⁺11] Liu, F.; Tong, J.; Mao, J.; Bohn, R.; Messina, J.; Badger, L. & Leaf, D.: NIST

Cloud Computing Reference Architecture, NIST Special Publication 500-292,

Gaithersburg, September 2011

86

http://collaborate.nist.gov/twiki-cloud-

computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/NIST_SP_500-

292_-_090611.pdf (14.1.2012)

[MG11] Mell, P. & Grace, T.: The NIST Definition of Cloud Computing, NIST Special

Publication 800-145, Gaithersburg, September 2011

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf (22.1.2012)

[MS10] Information Security Management System for Microsoft Cloud Infrastructure;

Online Services Security and Compliance, Published: November 2010

http://cdn.globalfoundationservices.com/documents/InformationSecurityMangSysfor

MSCloudInfrastructure.pdf (16.5.2012)

[MS11a] Nutzungsrechte für Microsoft-Onlinedienste, Deutsch (German), Oktober 2011

http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&Docume

ntTypeId=31 (21.12.2011)

[MS11b] Microsoft Online Services – Datenschutzbestimmungen: Ergänzung zu

Datenschutz und Sicherheit für Office 365, letzte Aktualisierung: Juni 2011

http://www.microsoft.com/online/legal/v2/?docid=22&langid=de-de (16.5.2012)

[MS11c] Microsoft Dynamics CRM 2011 – Datenschutzbestimmungen, Zuletzt

aktualisiert: September 2011

https://signin.crm.dynamics.com/portal/static/1031/privacy.htm (16.5.2012)

[MS11d] Microsoft Online Services: Customer Data Flows in Office 365: Europe,

Middle East, Africa, Published: November 23, 2011

go.microsoft.com/fwlink/?LinkId=213004&clcid=0x407 (16.5.2012)

[MS11e] Microsoft Office 365: Security and Service Continuity for Enterprises Service

Description, Published: June 28, 2011

http://www.microsoft.com/en-us/download/details.aspx?id=13602 (16.5.2012)

[MS11f] Trustworthy Computing: Privacy in the Public Cloud: The Office 365

Approach, December 2011

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=28540

(16.5.2012)

[MS12] Microsoft Online Services: Online-Abonnement-Vertrag

http://www.microsoft.com/online/MOSA/MOSA-de-emea.aspx (16.5.2012)

87

[MSA11] Microsoft Online Services: Technische Übersicht über die

Sicherheitsfunktionen der Windows Azure-Plattform, Zuletzt aktualisiert: April

2011

http://www.microsoft.com/online/legal/?langid=de-de&docid=11 (16.5.2012)

[MSA12] Windows Azure: Microsoft Online-Abonnement-Vertrag

http://www.windowsazure.com/mosa.aspx?country=de&locale=de-de (16.5.2012)

[OBB07a] Ort, E.; Brydon, S. & Basler, M.: Mashup Styles, Part 1: Server-Side Mashups,

May 2007

http://java.sun.com/developer/technicalArticles/J2EE/mashup_1/ (4.6.2012)

[OBB07b] Ort, E.; Brydon, S. & Basler, M.: Mashup Styles, Part 2: Client-Side Mashups,

August 2007

http://java.sun.com/developer/technicalArticles/J2EE/mashup_2/ (4.6.2012)

[PwC10] Cloud Computing – Navigation in der Wolke, Strategie, Organisation, Prozesse

und Systeme, Herausgeber PricewaterhouseCoopers AG, Oktober 2010

http://www.pwc.de/de/prozessoptimierung/trotz-einiger-bedenken-der-virtuellen-

datenverarbeitung-gehoert-die-zukunft.jhtml (9.3.2012)

[PwC11] Cloud Computing im Mittelstand: Erfahrungen, Nutzen und

Herausforderungen (Eine Kurzstudie zu den aktuellen Erfahrungen

mittelständischer Unternehmen mit der „IT aus der Wolke“), Herausgeber

PricewaterhouseCoopers AG Wirtschaftsprüfungsgesellschaf, Mai 2011

http://www.pwc.de/de/mittelstand/cloud-computing-im-mittelstand.jhtml (9.3.2012)

[S12] Stevens, G.: Data Security Breach Notification Laws, Congressional Research

Service, April 10, 2012

http://www.fas.org/sgp/crs/misc/R42475.pdf (12.6.2012)

[SaaS11] Trust in Cloud – Das Qualitätszertifikat für Cloud Lösungen, Check-Liste,

SaaS-EcoSystem e. V. 2011

http://www.saasecosystem.org/trust-in-cloud/checkliste/ (16.5.2012)

[SF] Salesforce.com Supplier Code of Conduct,

http://www2.sfdcstatic.com/assets/pdf/misc/salesforce_Supplier_Code_of_Conduct.pd

f (12.6.2012)

[SF10] Stellungnahme zu datenschutzrechtlichen Anforderungen bei der

Inanspruchnahme der Services von salesforce.com, Hogan Lovells

International LLP, München, Juli 2010

88

http://www.salesforce.com/de/trust/privacy.jsp (29.12.2011)

[SF11a] Master Subscription Agreement, Salesforce.com, 15. September 2011

http://www2.sfdcstatic.com/assets/pdf/misc/salesforce_MSA.pdf (2.1.2012)

[SF11b] Master Subscription Agreement for Data.com Services, Salesforce.com,

15. December 2011

http://www2.sfdcstatic.com/assets/pdf/misc/salesforce_MSA_Datadotcom.pdf

(2.1.2012)

[TÜV] TÜV-zertifizierter Datenschutz, tekit Consult Bonn GmbH, TÜV Saarland

Gruppe

http://tekit.de/wp-content/uploads/2012/04/gepr_datenschutz_web.pdf (12.5.2012)

[02/21/EG] Richtlinie 2002/21/EG des Europäischen Parlament und des Rates vom 7.

März 2002 über einen gemeinsamen Rechtsrahmen für elektronische

Kommunikationsnetze und -dienste (Rahmenrichtlinie), Amtsblatt der

Europäischen Gemeinschaften, 24.4.2002

http://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:108:0033:0033:DE:PDF

(1.5.2012)

[00/520/EG] 2000/520/EG: Entscheidung der Kommission vom 26. Juli 2000 gemäß der

Richtlinie 95/46/EG des Europäischen Parlaments und des Rates über die

Angemessenheit des von den Grundsätzen des „sicheren Hafens“ und der

diesbezüglichen „Häufig gestellten Fragen“ (FAQ) gewährleisteten Schutzes,

vorgelegt vom Handelsministerium der USA (Bekannt gegeben unter

Aktenzeichen K(2000) 2441), Amtsblatt der Europäischen Gemeinschaften,

25.8.2000

http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2000:215:0007:0047:DE

:PDF (1.5.2012)

[02/58/EG] Richtlinie 2002/58/EG des Europäischen Parlament und des Rates vom 12. Juli

2002 über die Verarbeitung personenbezogener Daten und den Schutz der

Privatsphäre in der elektronischen Kommunikation (Datenschutzrichtlinie für

elektronische Kommunikation), Amtsblatt der Europäischen Gemeinschaften,

31.7.2002

http://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:201:0037:0037:DE:PDF

(1.5.2012)

89

[95/46/EG] Richtlinie 95/46/EG des Europäischen Parlaments und des Rates vom 24.

Oktober 1995 zum Schutz natürlicher Personen bei der Verarbeitung

personenbezogener Daten und zum freien Datenverkehr

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:de:html

(8.1.2012)

90

Anlagen zum Kapitel 4.3

Erläuterungen zu den Zertifizierungen

ISO/IEC 27001

Die internationale Norm ISO/IEC 27001 spezifiziert Anforderungen für die Implementierung

von geeigneten Sicherheitsmechanismen im Bereich der Informationstechnologien. Sie

definiert, wie ein Informationssicherheits –Managementsystem (ISMS) aufgebaut, eingeführt,

betrieben, überwacht, gepflegt und verbessert werden soll. Welche Elemente enthalten sein

müssen, überlässt es aber den Anwendern, die Entscheidungen über die einzelnen Prozesse

und Maßnahmen zur Erfüllung der Anforderungen treffen. Eine Zertifizierung nach ISO/IEC

27001 ist 3 Jahre gültig.100

SAS 70 Typ II / SSAE 16 & ISAE 3402

SAS 70 – Statement on Auditing Standards No. 70 Service Organizations – ist ein

US-amerikanischer Standard. SAS 70 Typ II zielt darauf ab, das interne Kontrollsystem –

zusätzlich zur reinen Beschreibung des Kontrollsystems – umfassend zu testen und es

insbesondere hinsichtlich seiner Effektivität im Detail zu bewerten. Die Prüfung erfolgt über

einen Zeitraum von sechs Monaten. Der SAS 70 Report nach Typ II beinhaltet die Meinung

einer externen Prüfgesellschaft über das Kontrollwesen beim Serviceanbieter, eine

Beschreibung der Kontrollpunkte und Kontrollen sowie Angaben über die Prüfperiode, eine

Beschreibung der Prüfmethode und eine Aussage über die Wirksamkeit der Kontrollen.101

Das Audit ist jährlich zu wiederholen.

SSAE 16 – Statement on Standards for Attestation Engagements No. 16, Reporting on

Controls at a Service Organization.

ISAE 3402 – International Standard on Assurance Engagements No. 3402 – ist ein

international anerkannter Audit-Standard, welcher eine Berichterstattungsmöglichkeit für

Dienstleistungsorganisationen mit einem weltweit einheitlichen Berichtsaufbau darstellt.

ISAE 3402 ist das internationale Äquivalent zu SSAE 16. Bei einem ISAE 3402 Report wird

zwischen dem Typ I und II unterschieden. Während beim Typ I vor allem das Design der

Kontrollen beurteilt wird, beinhaltet der Typ II zusätzlich eine Prüfung der

Kontrollwirksamkeit.102

Die ISAE 3402 und SSAE 16 Standards ersetzen seit dem Jahr 2011 den bisherigen SAS 70.

100

http://de.wikipedia.org/wiki/ISO/IEC_27001 (13.6.2012) 101

http://www.foliocloud.com/sicher-und-zuverlaessig.html (13.6.2012) 102

http://www.iwb.ch/de/telekom/geschaeftskunden/telehouse/isae_3402_audit/ (13.6.2012)

2

PCI DSS (Level 1)

Der Payment Card Industry Data Security Standard ist ein Regelwerk für Organisationen,

die Kreditkartengeschäfte / -Transaktionen abwickeln. Er basiert auf den

Sicherheitsprogrammen Visa AIS (Account Information Security) und MasterCard SDP (Site

Data Protection). Dabei handelt es sich um teilweise extrem aufwendige und kostenintensive

Sicherheitsvorkehrungen, die zum Schutz der Datensicherheit von den

Kreditkartenunternehmen vorgeschrieben sind und in regelmäßigen Abständen kontrolliert

werden müssen. Je nach Anzahl des jährlichen Transaktionsvolumens unterteilen sich die

Zertifizierungsanforderungen in vier Kategorien. Für Payment-Service-Provider gelten

automatisch die strengsten Anforderungen des Level 1.103

FISMA

Federal Information Security Management Act ist ein Bundesgesetz der USA, das alle

Bundesbehörden dazu verpflichtet, ein umfassendes Programm zur Gewährleistung der

Sicherheit der Informationen und der Informationssysteme, welche die Prozesse der Behörde

unterstützen, zu entwickeln, implementieren und dokumentieren.104

Ein FISMA-Zertifikat ist eine wesentliche Voraussetzung für die Nutzung externer Services

durch eine US-Behörde.

103

http://www.payone.de/data/download/Infoblatt_PCI-DSS.pdf (13.6.2012) 104

http://en.wikipedia.org/wiki/Federal_Information_Security_Management_Act_of_2002 (13.4.2012)

3

Eidesstattliche Versicherung

Ich versichere eidesstattlich durch eigenhändige Unterschrift, dass ich die Arbeit selbständig

und ohne Benutzung anderer als der angegebenen Hilfsmittel gefertigt habe. Alle Stellen, die

wörtlich oder sinngemäß aus Veröffentlichungen entnommen sind, habe ich als solche

kenntlich gemacht.

Rostock, …………………. .…………………

(Abgabedatum) (Unterschrift)