technische umsetzbarkeit - cloud computing - iuk … · · 2015-11-123.3.6 datenschutz in den usa...
TRANSCRIPT
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)