X - Ali Sunyaev

SEMINAR
FÜR WIRTSCHAFTSINFORMATIK
UND SYSTEMENTWICKLUNG
Jun.-Prof. Dr. Ali Sunyaev
Hauptseminar Wirtschaftsinformatik
im Wintersemester 2014/2015
Thema-Nr. 12
Sicherheitsrisiken von Cloud-Computing-Bereitstellungsmodellen
vorgelegt von:
Rogge, Sebastian
II
Inhaltsverzeichnis
Abkürzungsverzeichnis................................................................................................... IV
Abbildungsverzeichnis ..................................................................................................... V
Tabellenverzeichnis ........................................................................................................ VI
1. Einleitung ......................................................................................................................1
1.1 Problemstellung........................................................................................................1
1.2 Zielsetzung ...............................................................................................................2
2. Cloud-Computing .........................................................................................................3
3. Methodisches Vorgehen................................................................................................5
3.1 Bildung der Literaturbasis ........................................................................................5
3.2 Identifikation der Sicherheitsrisiken und Bereitstellungmodelle .............................6
3.3 Analyse und Aggregation der Sicherheitsrisiken .....................................................7
3.4 Beziehungsbildung zwischen Sicherheitsrisiken und Bereitstellungsmodellen ...................................................................................................................7
4. Deskriptive Resultate ....................................................................................................7
5. Sicherheitsrisiken der Bereitstellungsmodelle ..............................................................8
5.1 Cloud-Computing-Bereitstellungsmodelle ..............................................................8
5.1.1 Public-Cloud ...................................................................................................8
5.1.2 Private-Cloud ..................................................................................................9
5.1.3 Community-Cloud ........................................................................................10
5.1.4 Hybrid-Cloud ................................................................................................11
5.1.5 Virtual-Private-Cloud ...................................................................................11
5.2 Sicherheitsrisiken des Cloud-Computings .............................................................12
5.2.1 Virtualisierung und Mandantenfähigkeit ......................................................12
5.2.2 Anwendung und Schnittstellen .....................................................................14
5.2.3 Kommunikation und Perimeter-Sicherheit ...................................................16
5.2.4 Datenverarbeitung und Datenspeicherung ....................................................17
5.2.5 Daten- und Service-Verfügbarkeit ................................................................17
5.2.6 Ressourcen-Zugang und Datenzugriff ..........................................................18
5.2.7 Unbekannte Sicherheitsrisiken .....................................................................19
5.2.8 Physische Datenlokation ...............................................................................19
5.3 Sicherheitsrisiken in Abhängigkeit der Bereitstellungsmodelle ............................20
6. Einschätzung der Anwendbarkeit der Bereitstellungsmodelle für die Verarbeitung gesundheitsbezogener Daten.......................................................................25
III
7. Fazit.............................................................................................................................26
Literaturverzeichnis .........................................................................................................28
Anhang.............................................................................................................................32
Thesenpapier ....................................................................................................................34
Erklärung .........................................................................................................................35
IV
Abkürzungsverzeichnis
API
Application Programming Interface
CPU
Central Processing Unit
DNS
Domain Name System
DoS
Denial of Service
DDoS
Distributed Denial of Service
HTTPS
Hypertext Transfer Protocol Secure
IaaS
Infrastructure as a Service
IP
Internet Protocol
NIST
National Institute of Standards and Technology
PaaS
Platform as a Service
SaaS
Software as a Service
SOAP
Simple Object Access Protocol
SQL
Structured Query Language
VM
Virtuelle Maschine
VPC
Virtual Private Cloud
VPN
Virtual Private Network
Web
World Wide Web
XML
Extensible Markup Language
V
Abbildungsverzeichnis
Abb. 3-1 : Suchstring zur Bildung der Literaturbasis ........................................................5
VI
Tabellenverzeichnis
Tab. 3-1: Include- und Exclude-Kriterien .........................................................................6
Tab. 4-1: Deskriptive Resultate der Literatur-Recherche ..................................................7
Tab. 5-1 : Beziehungsbildung zwischen Bereitstellungsmodellen und
Sicherheitsrisiko-Kategorien ........................................................................21
1
1.
Einleitung
1.1
Problemstellung
Cloud-Computing hat in den letzten Jahren zunehmend an Relevanz für Organisationen
gewonnen, da der Einsatz dieser Technologie eine höhere Effizienz und die potentielle
Realisierung von Kosteneinsparungen bei der Bereitstellung von IT-Dienstleistungen
und IT-Ressourcen ermöglicht.1 Die Effizienz- und Kostenvorteile resultieren unter anderem daraus, dass Cloud-Computing-Systeme über einen hohen Grad an Flexibilität
und Skalierbarkeit verfügen, was eine allzeit bedarfsgerechte Bereitstellung und Abrechnung, sowie effiziente Leistungsfähigkeit der IT-Dienstleistung und -Ressourcen
ermöglicht.
Im Zuge der Adoption einer Cloud-basierten IT-Dienstleistung oder -Ressource (nachfolgend kurz als Cloud-Service bezeichnet) haben Organisationen die Wahl zwischen
verschiedenen Arten von Cloud-Computing-Bereitstellungsmodellen, wie z.B. einem
Public- oder Private-Cloud-Modell.2 Diese Bereitstellungsmodelle unterscheiden sich
zum einen hinsichtlich der Kosten, die für die Akquirierung des Cloud-Services anfallen. Zum anderen hat die Art des Bereitstellungsmodells einen Einfluss auf die Höhe
des Sicherheitsrisikos, das mit der Nutzung eines Cloud-Services einhergeht. Die Analyse, Einschätzung und Berücksichtigung des Sicherheitsrisikos bei der Wahl des Bereitstellungsmodells ist unter anderem dann wichtig, wenn der Cloud-Service zur Verarbeitung, Speicherung und/oder Transfer von sensiblen Daten mit hohem Schutzbedarf
verwendet werden soll.3 Ein derartiges Anwendungsszenario ist die Verarbeitung von
gesundheitsbezogenen Daten, wie z. B. elektronische Patientenakten, durch Organisationen aus dem Gesundheitswesen. Der hohe Schutzbedarf von gesundheitsbezogenen
Daten wirft die Frage auf, welche Sicherheitsrisiken die einzelnen Cloud-ComputingBereitstellungsmodelle mit sich bringen und inwiefern diese dazu geeignet sind, die
Integrität, Vertraulichkeit und Verfügbarkeit derartiger Daten zu gewährleisten.
1
Vgl. zu diesem und dem folgenden Satz Gupta, Gupta (2012), S. 82–83.
2
Vgl. zu diesem und den folgenden zwei Sätzen Fernandes u. a. (2014), S. 7–8.
3
Vgl. zu diesem und dem folgenden Satz Regola, Chawla (2013), S. 2–3.
2
In der einschlägigen Literatur zum Thema Cloud-Computing existieren bereits Publikationen, die das Thema Sicherheit von Cloud-Computing behandeln. Die exakten Beziehungen zwischen Sicherheitsrisiken und Cloud-Computing-Bereitstellungsmodellen
werden jedoch nicht ausreichend thematisiert und sind in Folge dessen weitestgehend
unklar. Ein systematisches Literatur-Review, welches die Sicherheitsrisiken des CloudComputings mit den einzelnen Cloud-Computing-Bereitstellungsmodellen in Beziehung
setzt und die Abhängigkeiten untersucht, kann diese Lücke schließen. Dieses ist für Organisationen, die eine Verarbeitung gesundheitsbezogener Daten mittels eines CloudService anstreben, von Bedeutung, um die von einem Bereitstellungsmodell ausgehenden Sicherheitsrisiken einschätzen zu können.
1.2
Zielsetzung
Das
Ziel
dieser
Ausarbeitung
ist
es,
die
existierenden
Cloud-Computing-
Bereitstellungsmodelle und deren potenzielle Sicherheitsrisiken zu identifizieren. Die
ermittelten Sicherheitsrisiken werden im weiteren Verlauf aggregiert und in Abhängigkeit zu den Bereitstellungsmodellen in eine strukturierte Darstellungsform überführt.
Darüber hinaus wird eine erste Einschätzung der Eignung der verschiedenen Bereitstellungsmodelle für die Verarbeitung gesundheitsbezogener Daten abgegeben.
Die genannte Zielsetzung setzt sich aus insgesamt fünf Teilzielen zusammen: Das erste
Teilziel
beinhaltet
die
Ermittlung
der
existierenden
Cloud-Computing-
Bereitstellungsmodelle. Des Weiteren werden die potentiellen Sicherheitsrisiken des
Cloud-Computings als zweites Teilziel identifiziert. Das dritte Teilziel umfasst eine
Analyse der Beziehung zwischen den ermittelten Sicherheitsrisiken und identifizierten
Cloud-Computing-Bereitstellungsmodellen. Teilziel 4 beinhaltet die Aggregation und
Strukturierung der identifizierten Sicherheitsrisiken in Abhängigkeit der CloudComputing-Bereitstellungsmodelle. Das letzte Teilziel besteht aus einer ersten Einschätzung der Eignung der einzelnen Cloud-Computing-Bereitstellungsmodelle für die
Verarbeitung gesundheitsbezogener Daten.
3
2.
Cloud-Computing
Für die Begrifflichkeit Cloud Computing gibt es eine Vielzahl von Definitionen. Eine
Definition, die in der Literatur oft zitiert wird, ist die des US National Institute of Standards and Technology (NIST):
„Cloud computing is a model for enabling ubiquitous, convenient, on-demand network
access to a shared pool of configurable computing resources (e.g., networks, servers,
storage, applications, and services) that can be rapidly provisioned and released with
minimal management effort or service provider interaction.”4
Der Definition des NIST zur Folge, setzt sich das Cloud-Computing-Modell aus fünf
wesentlichen Charakteristiken zusammen: On-Demand Self-Service, Broad Network
Access, Resource Pooling, Rapid Elasticity und Measured Service. 5 Das Charakteristikum On-Demand Self-Service bezieht sich auf die Akquirierung von Rechenressourcen
durch den Nutzer und besagt, dass ein Cloud-Service-Nutzer bei Bedarf selbständig und
automatisch die benötigten Ressourcen beziehen kann, ohne das eine Interaktion mit
dem Cloud-Service-Anbieter erforderlich ist. Darüber hinaus sind alle Rechenressourcen breitbandig über das Netzwerk verfügbar und über Standardmechanismen zugänglich, was durch das Cloud-Computing-Charakteristikum Broad Network Access beschrieben wird. Resource Pooling bezieht sich auf die Bündelung oder Aggregation der
angebotenen Rechenressourcen (z.B. Speicherplatz) auf Seiten des Anbieters, um diese
dynamisch mehreren Nutzern im Rahmen eines mandantenfähigen Modells zur Verfügung zu stellen. Rapid Elasticity bezeichnet die Fähigkeit der Cloud-ComputingSysteme, zugeteilte Rechenressourcen schnell und elastisch hoch- und herunter zu skalieren, um diese an die Bedürfnisse der Nutzer anzupassen. Durch das fünfte Charakteristikum Measured Service wird realisiert, dass Cloud-Computing-Systeme automatisch
die Ressourcenzuteilung bzw. -nutzung überwachen, messen und optimieren können.
Hierdurch entsteht eine Transparenz bzgl. der Ressourcennutzung für Anbieter und
Nutzer.
Neben den vorab erläuterten fünf Cloud-Computing-Charakteristiken werden im Rahmen der NIST-Definition des Weiteren drei Service-Modelle des Cloud-Computings
4
Mell, Grance (2011), S. 2.
5
Vgl. zu diesem Absatz Mell, Grance (2011), S. 2.
4
unterschieden: Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) und Infrastructure-as-a-Service (IaaS).6 Beim Service-Modell SaaS wird den Nutzern eine Anwendung als Dienst durch einen Cloud-Service-Anbieter bereitgestellt. Die Anwendung
wird hierbei innerhalb einer Cloud-Computing-Infrastruktur betrieben und ist in der
Regel beispielsweise über einen Webbrowser zugänglich. Eine Cloud-ComputingInfrastruktur ist eine Zusammenstellung von Hard- und Software-Ressourcen, die die
fünf erläuterten Charakteristiken des Cloud-Computings realisiert. Im Rahmen des Service-Modells PaaS erhält der Nutzer Zugang und Zugriff auf eine (Entwicklungs-) Plattform innerhalb einer Cloud-Computing-Infrastruktur, mittels derer akquirierte oder
selbstentwickelte Anwendungen bereitgestellt werden können. Diese Anwendungen
nutzen zumeist Entwicklungswerkzeuge, Frameworks und Bibliotheken, die vom
Cloud-Service-Anbieter unterstützt werden. Das letzte der drei Service-Modelle, IaaS,
ist dadurch charakterisiert, dass dem Nutzer grundlegende Rechenressourcen, wie z.B.
Rechenleistung oder Speicherplatz, zur Verfügung gestellt werden. Diese Rechenressourcen können vom Nutzer unter anderem dazu verwendet werden, eigene Anwendungen und Betriebssystemen bereitzustellen.
Neben Charakteristiken und Service-Modellen werden im Rahmen der NIST-Definition
zudem verschiedene Cloud-Computing-Bereitstellungsmodelle unterschieden.7 Bereitstellungsmodelle charakterisieren zum einen die Managementverantwortlichkeiten und
Bezugsquelle eines Cloud-Services bzw. einer Cloud-Computing-Infrastruktur und unterscheiden zum anderen verschiedene Nutzerklassen, die Zugriff auf einen CloudService haben. Die Bezugsquelle eines Cloud-Services kann beispielsweise ein externer
oder ein organisationsinterner Cloud-Service-Anbieter sein. Darüber hinaus kann ein
Cloud-Service öffentlich für alle Nutzer bereitgestellt werden oder nur dediziert für eine
bestimmte Organisation bzw. Gruppe von Organisationen. Die NIST-Definition unterscheidet insgesamt vier verschiedene Bereitstellungsmodelle, welche namentlich als
Private-Cloud, Public-Cloud, Community-Cloud und Hybrid-Cloud bezeichnet werden.
Diese und weitere identifizierte Bereitstellungsmodelle werden im nachfolgenden Kapitel 5.1 tiefergehend erläutert.
6
Vgl. zu diesem Absatz Mell, Grance (2011), S. 2-3.
7
Vgl. zu diesem Absatz Jansen, Grance (2011), S. 3-4.
5
3.
Methodisches Vorgehen
Im Rahmen dieses Kapitel wird das gewählte methodische Vorgehen zur Erreichung der
Zielsetzung erläutert. Dieses umfasst die Bildung der Literaturbasis, sowie die Identifikation und Analyse der Sicherheitsrisiken und Bereitstellungsmodelle des CloudComputings.
3.1
Bildung der Literaturbasis
Zur Bildung der Literaturbasis wurden die drei Literaturdatenbanken Ebscohost
(Academic Search Complete & Business Source Complete), ProQuest und ScienceDirect mithilfe eines Suchstrings systematisch durchsucht. Wie in der nachfolgenden Abb.
3-1 ersichtlich ist, setzt sich der verwendete Suchstring primär aus zwei Blöcken zusammen, die mit einer UND-Verknüpfung verbunden sind.
("*cloud*" OR "SaaS" OR “Software as a Service" OR “PaaS" OR “Plattform
as a Service” OR "IaaS" OR “Infrastructure as a Service”)
AND
("security" OR "risk*" OR "privacy" OR "vulnerabilit*" OR "issue*" OR “threat*”)
Abb. 3-1 : Suchstring zur Bildung der Literaturbasis
Der erste Block beinhaltet verschiedene Begrifflichkeiten zur Begrenzung der Suchergebnisse auf das Thema Cloud-Computing. Neben dem Begriff „Cloud“ selbst, sind im
ersten Block die verschiedenen Service-Modelle aufgeführt. Die einzelnen Bereitstellungsmodelle wie Public- oder Private-Cloud werden durch den Begriff „Cloud“ in
Kombination mit den eingefügten Platzhaltern (*) im ersten Block ebenfalls berücksichtigt. Der zweite Block beinhaltet verschiedene Synonyme zu den Begrifflichkeiten „Sicherheit“ und „Risiko“, um die Suchresultate weitergehend einzuschränken. Die einzelnen Begrifflichkeiten innerhalb eines Blocks sind mit einer ODER-Verknüpfung verbunden. Der Suchstring wurde ausschließlich auf Publikationstitel und definierte
Schlüsselwörter (engl. Keywords) angewendet, um nur Suchergebnisse mit einer möglichst hohen Relevanz zu erhalten.
Neben dem Suchstring wurden zur Bildung der finalen Literaturbasis des Weiteren vier
Include- und Exclude-Kriterien definiert, welche in der nachfolgenden Tab. 3-1 ersichtlich sind.
6
Include-Kriterien
Exclude-Kriterien
Englischsprachiger Artikel
Nicht englischsprachiger Artikel
Veröffentlichungsdatum > 01.01.2012
Veröffentlichungsdatum < 01.01.2012
Peer-Reviewed Artikel
Kein Peer-Reviewd Artikel
Erkennbarer Fokus des Artikels auf Si- Kein erkennbarer Fokus des Artikels auf
cherheitsrisiken des Cloud-Computings Sicherheitsrisiken des Cloud-Computings
auf Basis von Titel und Abstrakt.
auf Basis von Titel und Abstrakt.
Tab. 3-1: Include- und Exclude-Kriterien
In die finale Literaturbasis werden gemäß der definierten Include- und ExcludeKriterien nur Quellen einbezogen, die englischsprachig und Peer-Reviewd sind. Durch
das Merkmal Peer-Reviewed weisen die Quellen ein gewisses Maß an Qualität auf.
Darüber hinaus wurden nur Artikel für die finale Literaturbasis berücksichtigt, die nach
dem 01.01.2012 veröffentlich wurden, um die Anzahl potentiell relevanter Artikel im
Hinblick auf den vorgegebenen Zeitrahmen zur Fertigstellung dieser Ausarbeitung auf
eine handhabbare Menge zu reduzieren. Des Weiteren werden in der finalen Literaturbasis nur Artikel berücksichtigt, die auf Basis von Titel und Abstrakt einen erkennbaren
allgemeinen Fokus auf Sicherheitsrisiken des Cloud-Computings aufweisen. Artikel, die
z.B. konzeptionelle Lösungsstrategien für spezifische Sicherheitsrisiken aufweisen, entfallen somit.
3.2
Identifikation der Sicherheitsrisiken und Bereitstellungmodelle
Für die Identifikation der Sicherheitsrisiken und Bereitstellungsmodelle wurde anfänglich jede einzelne Quelle der Literaturbasis hinsichtlich Sicherheitsrisiken und Bereitstellungsmodelle des Cloud-Computings durchsucht. Nachfolgend wurden die ermittelten Inhalte aus den Quellen extrahiert und in eine separate Liste als Variablen aufgenommen. Die dadurch entstandene Liste enthält somit eine Menge von Variablen, wobei
jede einzelne Variable ein identifiziertes Sicherheitsrisiko bzw. Bereitstellungsmodell
repräsentiert. Da in verschiedenen Quellen oftmals identische Sicherheitsrisiken bzw.
Bereitstellungsmodelle mit unterschiedlicher Benennung und Detaillierungstiefe erläutert werden, handelt es sich bei diesem Vorgehen um einen iterativen Prozess, wobei die
einzelnen Variablen und deren Definition konsequent angepasst und erweitert werden.
Das geschilderte Vorgehen wurde von den Autoren Lacity u.a. adoptiert.8
8
Vgl. Lacity u. a. (2010), S. 398, 401.
7
3.3
Analyse und Aggregation der Sicherheitsrisiken
Für die Aggregation der einzelnen Sicherheitsrisiken wurden die entsprechenden gebildeten Variablen (siehe Kapitel 3.2) analysiert und anschließend mit Hilfe eines Affinitätsdiagramms nach Ähnlichkeit bzw. Gemeinsamkeit geclustert. Jedes resultierende
Cluster repräsentiert eine eigene Sicherheitsrisiko-Kategorie, welche im weiteren Verlauf mit einer passenden Bezeichnung versehen wurde. Die Cluster-Bezeichnung spiegelt die Gemeinsamkeiten der enthaltenen Variablen in abstrahierter bzw. aggregierter
Form wider.
3.4
Beziehungsbildung zwischen Sicherheitsrisiken und Bereitstellungsmodellen
Die Beziehungsbildung zwischen Bereitstellungsmodellen und Sicherheitsrisiken erfolgt auf Basis der in den nachfolgenden Kapiteln 5.1 und 5.2 erläuterten Charakteristiken eines jeweiligen Bereitstellungsmodells bzw. Sicherheitsrisikos. So gelten beispielsweise Sicherheitsrisiken webbasierter Nutzerschnittstellen für Bereitstellungsmodelle, die typischerweise über eine derartige Schnittstelle verfügen und zugänglich sind.
4.
Deskriptive Resultate
Auf Basis des in Kapitel 3.1 beschriebenen Vorgehens zur Bildung der Literaturbasis
konnten in den Datenbanken EBSCOhost, ProQuest und ScienceDirect insgesamt 748
Suchergebnisse für potenziell relevante Literaturquellen erzielt werden. Im Rahmen der
Auswertung der erzielten Suchresultate wurde die Anzahl durch Anwendung der definierten Include- & Exclude-Kriterien auf insgesamt 61 relevante Quellen eingegrenzt.
Diese 61 Literaturquellen bilden die zugrunde liegende Literaturbasis für diese Ausarbeitung. Die exakte Aufteilung der 61 relevanten Literaturquellen auf die einzelnen Literatur-Datenbanken ist in der nachfolgenden Tab. 4-1 ersichtlich.
LiteraturDatenbank
EBSCOhost
Suchresultate
(Anzahl Treffer)
471
Relevante Literaturquellen
nach Auswertung
33
Datum
der Suche
11.11.2014
ProQuest
128
10
11.11.2014
ScienceDirect 149
18
12.11.2014
Summe
61
748
Tab. 4-1: Deskriptive Resultate der Literatur-Recherche
8
In den 61 relevanten Literaturquellen konnten gemäß dem in Kapitel 3.2 beschriebenen
Vorgehen insgesamt 28 verschiedene Sicherheitsrisiken (siehe Anhang I) und fünf Bereitstellungsmodelle des Cloud-Computings identifiziert und extrahiert werden. In Folge
der Aggregation der identifizierten Sicherheitsrisiken wurden insgesamt acht Sicherheitsrisiko-Kategorien gebildet, welche in dem nachfolgenden Kapitel 5.2 vorgestellt
werden. In jeder Sicherheitsrisiko-Kategorie wurden einzelne Sicherheitsrisiken zusammengefasst, die Gemeinsamkeiten bzw. Ähnlichkeiten aufweisen.
5.
Sicherheitsrisiken der Bereitstellungsmodelle
Inhalt dieses Kapitels ist neben der Erläuterung der ermittelten Bereitstellungsmodelle
die Vorstellung der identifizierten und aggregierten Sicherheitsrisiken des CloudComputings, welche potenziell die Vertraulichkeit, Integrität und Verfügbarkeit gesundheitsbezogener Daten gefährden. Darüber hinaus werden im Rahmen dieses Kapitels die Beziehungen zwischen Sicherheitsrisiken und Bereitstellungsmodelle analysiert
mit dem Ziel, den einzelnen Bereitstellungmodellen potenzielle Sicherheitsrisiken zuzuordnen.
5.1
Cloud-Computing-Bereitstellungsmodelle
Im Rahmen des Literaturreviews konnten insgesamt fünf verschiedene CloudComputing-Bereitstellungsmodelle identifiziert werden, welche nachfolgend erläutert
werden.
5.1.1
Public-Cloud
Das Public-Cloud-Bereitstellungsmodell zeichnet sich primär dadurch aus, dass ein
Cloud-Service der allgemeinen Öffentlichkeit zur Verfügung gestellt wird und eine
Vielzahl von Mandanten den angebotenen Service nutzen.9 Ein Public-Cloud-Service
wird in der Regel durch einen externen Cloud-Service-Anbieter bereitgestellt und in
dessen Cloud-Computing-Infrastruktur betrieben.10 Die Kunden des Cloud-ServiceAnbieters zahlen lediglich für die Nutzung des Services, die in der Regel mit geringen
Kosten verbunden ist. Dieses führt zu einer typischerweise hohen Kosteneffizienz von
9
Vgl. Brender, Markov (2013), S. 727 sowie Nicho, Hendy (2013), S. 160.
10
Vgl. zu diesem und dem folgenden Satz Fernandes u. a. (2014), S. 7.
9
angebotenen Public-Cloud-Services.11 Der Zugang bzw. Zugriff auf einen angebotenen
Public-Cloud-Service erfolgt in der Regel webbasiert über einen Browser oder über eine
spezielle Software-Anwendung, die vom Cloud-Service-Anbieter bereitgestellt wird
und die implementierten Web- bzw. Programmier-Schnittstellen des Cloud-Services
nutzt.12 Die Verantwortlichkeit für die Sicherheit und die ordnungsmäßige Funktionsweise des Cloud-Services liegt typischerweise beim Anbieter.13 Die Tatsache, dass ein
angebotener Public-Cloud-Service von vielen verschiedenen Mandanten genutzt wird,
über das Internet zugänglich ist und durch einen externen Cloud-Service-Anbieter bereitgestellt wird, impliziert eine Vielzahl von potenziellen Sicherheitsrisiken und erhöht
die Anfälligkeit für schädliche bzw. böswillige Aktivitäten.14 Darüber hinaus ist die
Nutzung eines Public-Cloud-Services für eine Organisation mit einem Kontrollverlust
über Daten verbunden, die im Zuge der Service-Nutzung an den externen CloudService-Anbieter übertragen und dort vorgehalten werden.15 Daher wird die allgemeine
Sicherheit des Public-Cloud-Bereitstellungsmodells im Vergleich zu den anderen existierenden Bereitstellungsmodellen in der Literatur als gering eingestuft.16
5.1.2
Private-Cloud
Das Private-Cloud-Bereitstellungsmodell zeichnet sich dadurch aus, das eine CloudComputing-Infrastruktur und die bereitgestellten Cloud-Services exklusiv von einer
Organisation und deren Mitgliedern genutzt bzw. für diese betrieben wird.17 Die PublicCloud wird laut NIST-Definition von der Organisation selbst oder von einem externen
Dritten bereitgestellt.18 Andere Definitionen dieses Bereitstellungsmodells legen jedoch
ausschließlich die Organisation selbst als Betreiber einer Private-Cloud innerhalb des
11
Vgl. Aleem, Sprott (2013), S. 10.
12
Vgl. Fernandes u. a. (2014), S. 7 sowie Gupta, Gupta (2012), S. 81.
13
Vgl. Aleem, Sprott (2013), S. 10 sowie Kalloniatis, Mouratidis, Islam (2013), S. 301.
14
Vgl. King, Raja (2012), S. 309 sowie Fernandes u. a. (2014), S. 7-8.
15
Vgl. Ahamed, Shahrestani, Ginige (2013), S. 5 sowie Leavitt (2013), S. 16.
16
Vgl. Fernandes u. a. (2014), S. 7 sowie Ramgovind, Eloff, Smith (2010), S. 2.
17
Vgl. Aleem, Sprott (2013), S. 10 sowie Kalloniatis, Mouratidis, Islam (2013), S. 301.
18
Vgl. Mell, Grance (2011), S. 3.
10
eigenen Rechenzentrums fest.19 Im Rahmen dieser Ausarbeitung gilt die Definition des
NIST, wobei auch externe Dritte als Bezugsquelle und Betreiber in Frage kommen.
Die Management- und Sicherheitsverantwortlichkeiten liegen im Falle einer PrivateCloud entweder bei der Organisation selbst oder bei einem externen Dritten.20 Zudem
orientieren sich die angebotenen Cloud-Services zumeist stark an den Anforderungen
der Organisation und sind somit auf diese zugeschnitten. Die Nutzung einer PrivateCloud gibt Organisationen mehr Kontrolle über Sicherheit, Transparenz und Einhaltung
von Compliance-Vorgaben.21 Daher wird diese Art von Bereitstellungsmodell in der
Regel für die Verarbeitung und Vorhaltung sensibler Daten, wie z.B. gesundheitsbezogene Daten, bevorzugt. Im Vergleich zur Public-Cloud wird für die Realisierung einer
Private-Cloud jedoch ein höheres Budget benötigt, da zumeist Investitionen für die Erweiterung der IT-Infrastruktur notwendig sind.22 Darüber hinaus wird für eine organisationsinterne Bereitstellung und Betrieb einer Private-Cloud Personal mit entsprechenden
Fähigkeiten und Know-how benötigt.
5.1.3
Community-Cloud
Das Bereitstellungsmodell Community-Cloud weist im Wesentlichen die Charakteristiken einer Private-Cloud auf, wobei die Cloud-Computing-Infrastruktur jedoch nicht
exklusiv von einer Organisation genutzt wird sondern von einer Gemeinschaft verschiedener Organisationen. 23 Diese Gemeinschaft von Organisationen verbindet in der Regel
ein gemeinsames Interesse, wie zum Beispiel die Umsetzung bestimmter Sicherheitsanforderungen oder die Einhaltung von Compliance-Vorgaben. Die Cloud-ComputingInfrastruktur kann im Rahmen dieses Modells durch externe Dritte oder durch Organisationen innerhalb der Gemeinschaft bereitgestellt und kontrolliert werden. Die Community-Cloud bietet eine höhere Kosteneffizienz im Vergleich zur Private-Cloud und ein
verringertes Sicherheitsrisiko im Vergleich zur Public-Cloud, da die Kosten in der Re19
Vgl. Leavitt (2013), S. 15.sowie Ramgovind, Eloff, Smith (2010), S. 2.
20
Vgl. zu diesem und dem folgenden Satz Fernandes u. a. (2014), S. 8 sowie Ramgovind, Eloff, Smith
(2010), S. 6.
21
Vgl. zu diesem und dem folgenden Satz Aleem, Sprott (2013), S. 10.
22
Vgl. zu diesem und dem folgenden Satz Fernandes u. a. (2014), S. 8.
23
Vgl. zu diesem und den folgenden zwei Sätzen Fernandes u. a. (2014), S. 8 sowie Aleem, Sprott
(2013), S. 11.
11
gel durch alle Organisationen der Gemeinschaft getragen werden und der Nutzerkreis
sowohl beschränkt als auch wohl definiert ist.24
5.1.4
Hybrid-Cloud
Das Bereitstellungsmodell Hybrid Cloud setzt sich aus zwei oder mehreren CloudComputing-Infrastrukturen unterschiedlichen Typs (Public, Private, Community) zusammen.25 Hierbei bleiben die einzelnen Cloud-Computing-Infrastrukturen eigenständige Entitäten, welche mittels standardisierter oder proprietärer Technologie gekoppelt
werden, was die Portabilität von Daten und Services ermöglicht. Im Rahmen dieses
Modells wird die Cloud-Computing-Infrastruktur zumeist zum einen Teil von der nutzenden Organisation selbst26 und zum anderen Teil von einer externen dritten Partei
bereitgestellt und gemanagt.27 So werden beispielsweise unkritische Services von einem
Public-Cloud-Anbieter bezogen und unternehmenskritische Services und Daten mit höheren Sicherheitsanforderungen in einer organisationsintern Private-Cloud bereitgestellt
bzw. vorgehalten, um die Kontrolle über derartige Services und Daten zu wahren.28
Hybrid-Clouds vereinigen die Kostenersparnis und Elastizität der Public-Cloud mit der
Sicherheit, Anpassungsfähigkeit und Kontrolle einer Private-Cloud.29 Hierdurch ist im
Falle auftretender Lastspitzen eine schnelle Akquisition zusätzlicher Rechenressourcen
möglich, ohne das eine Erweiterung der internen IT-Infrastruktur erforderlich ist.
5.1.5
Virtual-Private-Cloud
Das Bereitstellungsmodell Virtual-Private-Cloud findet in der Literatur bisher wenig
Berücksichtigung und wird nur in vereinzelten Quellen aufgegriffen.30 Bei diesem Modell handelt es sich um eine spezielle Form der Private-Cloud, die zumeist innerhalb
einer Public-Cloud-Infrastruktur betrieben und bereitgestellt wird. Im Rahmen einer
Virtual-Private-Cloud werden die Rechenressourcen, die einem Nutzer vom Anbieter
24
Vgl. Fernandes u. a. (2014), S. 8.
25
Vgl. zu diesem und dem folgenden Satz Li u. a. (2012), S. 381 sowie Brender, Markov (2013), S. 727.
26
Dieses ist nur der Fall, wenn eine Private-Cloud durch die Organisation selbst intern im eigenen Rechenzentrum bereitgestellt wird und dieses nicht durch eine externe dritte Partei geschieht.
27
Vgl. Fernandes u. a. (2014), S. 8.
28
Vgl. Aleem, Sprott (2013), S. 10-11 sowie Venters, Whitley (2012), S. 186.
29
Vgl. zu diesem und dem folgenden Satz Leavitt (2013), S. 15 sowie Fernandes u. a. (2014), S. 8.
30
Vgl. zu diesem Absatz Fernandes u. a. (2014), S. 8 sowie King, Raja (2012), S. 309.
12
zugewiesen werden, von den Ressourcen anderer Nutzer weitestgehend isoliert. Hierdurch werden Sicherheitsrisiken, die mit geteilten oder öffentlich zugänglichen Ressourcen einhergehen, reduziert bzw. neutralisiert. Die Kommunikation zwischen Nutzer
bzw. Organisation und der Virtual-Private-Cloud wird mittels VPN (Virtual-PrivateNetwork)-Technologie geschützt, wobei ein verschlüsselter virtueller Kommunikationskanal zwischen beiden Parteien aufgebaut wird. Allgemein bietet eine Virtual-PrivateCloud mehr Kontrolle und Sicherheit im Vergleich zur Public-Cloud. Die Höhe der anfallenden Kosten und die Managementverantwortlichkeiten sind jedoch bisher unklar.
5.2
Sicherheitsrisiken des Cloud-Computings
Im Rahmen dieses Kapitels werden die in der Literatur identifizierten Sicherheitsrisiken
des Cloud-Computings erläutert, welche zu insgesamt acht SicherheitsrisikoKategorien31 aggregiert wurden. Jedes der nachfolgenden acht Unterkapitel repräsentiert
eine Sicherheitsrisiko-Kategorie.
5.2.1
Virtualisierung und Mandantenfähigkeit
Virtualisierung bildet die Basis zur Realisierung einer Cloud-Computing-Infrastruktur,
in der Ressourcen und Services schnell und elastisch bereitgestellt und parallel von einer Vielzahl Mandanten genutzt werden können.32 Im Rahmen der Virtualisierung wird
eine logische Abstraktionsschicht zwischen den physischen Hardware-Ressourcen und
den Services, Anwendungen oder Betriebssystemen geschaffen, die diese Ressourcen
nutzen. Dieses ermöglicht eine logische Bündelung bzw. Aufteilung der physischen
Hardware-Ressourcen, welche im weiteren Verlauf von mehreren virtuellen Maschinen
(VM) und Mandanten parallel genutzt werden. Eine VM kann als virtuelle SystemUmgebung betrachtet werden, innerhalb derer Betriebssysteme, Anwendungen und Services betrieben werden. Die Allokation der Hardware-Ressourcen für die einzelnen
VMs wird durch den sogenannten Hypervisor verwaltet, der als abstrahierende Schicht
zwischen physischer Hardware und virtuellen Maschinen fungiert.
Der Einsatz von Virtualisierung als auch die Realisierung der Mandantenfähigkeit innerhalb einer Cloud-Computing-Infrastruktur birgt eine Vielzahl potenzieller Sicher31
Die Kategorisierung ist angelehnt an Fernandes u. a. (2014), S. 13 sowie Modi u. a. (2013), S. 586-587.
32
Vgl. zu diesem Absatz Nanavati u. a. (2014), S. 71-72 sowie Fernandes u. a. (2014), S. 11-12 und
Mouratidis u. a. (2013), S. 2279
13
heitsrisiken. Innerhalb einer Cloud-Computing-Infrastruktur teilen sich mehrere VMInstanzen typischerweise dieselben physischen Hardware-Ressourcen, wobei die einzelnen VMs und genutzten Ressourcen logisch voneinander isoliert werden.33 Eine perfekte Ressourcen-Isolation konnte bisher jedoch noch nicht realisiert werden und Hypervisor weisen des Öfteren Sicherheitslücken, z.B. in Form von Programmierungsfehlern,
auf. Dieser Sachverhalt birgt das Risiko, das böswillige Mandanten bzw. Angreifer potenzielle Schwachstellen des Hypervisors oder der Isolation ausnutzen, um aus der eigenen VM heraus die Daten einer anderen VM und somit eines anderen Nutzers auszulesen bzw. zu manipulieren (z.B. Daten im geteilten CPU-Cache). Derartige Angriffsszenarien werden als Side-Channel- bzw. Covert-Channel-Angriffe oder VM-Hopping bezeichnet. Darüber hinaus ist der Hypervisor ein beliebtes Angriffsziel, um die Kontrolle
über eine Vielzahl von VMs unterschiedlicher Nutzer zu erlangen.34 Sicherheitslücken
des Hypervisors oder der Isolation können dazu führen, dass der Hypervisor selbst aus
einer VM heraus kompromittiert und z.B. mit Malware infiziert wird. Dieses Angriffsszenario wird als VM-Escape bezeichnet und hat zur Folge, dass die Sicherheit aller
VMs, die der kompromittierte Hypervisor verwaltet, potentiell gefährdet ist.
Zudem kann ein unzureichendes Management der existierenden VM-Instanzen durch
den Cloud-Service-Anbieter zu weiteren Sicherheitsrisiken führen. Dieses ist zum Beispiel der Fall, wenn nicht in allen vorhandenen, aktiven und inaktiven, VM-Instanzen
aktuelle Schutzmechanismen und Sicherheitsaktualisierungen implementiert bzw. installiert wurden.35 Hierdurch entstehen Sicherheitslücken, die ggf. zur Kompromittierung vertraulicher Daten ausgenutzt werden.
Ein weiteres Sicherheitsrisiko stellt die Mobilität von VMs dar, was in der zugrundeliegenden Literatur als VM-Mobility bezeichnet wird.36 Die virtuellen Festplatten der VMs
werden typischerweise als Dateien auf einem Datenträger in einer physischen Maschine
innerhalb der Cloud-Computing-Infrastruktur vorgehalten und können über das interne
33
Vgl. zu diesem und den folgenden drei Sätzen Fernandes u. a. (2014), S. 21, 24 sowie Nanavati u. a.
(2014), S. 71-72, 76-77 und Bhadauria u. a. (2014), S. 167.
34
Vgl. zu diesem und den folgenden zwei Sätzen Bhadauria u. a. (2014), S. 167 sowie Modi u. a. (2013),
S. 570.
35
Vgl. zu diesem und dem folgenden Satz Kalloniatis, Mouratidis, Islam (2013), S. 312 sowie Fernandes
u. a. (2014), S. 21-22 und Karadsheh (2012), S. 320.
36
Vgl. zu diesem Absatz Fernandes u. a. (2014), S. 24 sowie Tsai u. a. (2012), S. 35.
14
Netzwerk schnell an andere Lokationen kopiert bzw. verschoben werden. Dieses birgt
das Risiko, das Angreifer durch Ausnutzung einer Sicherheitslücke zum einen virtuelle
Festplatten duplizieren und entwenden können. Zum anderen können VMs mit Malware
infiziert und schnell auf andere physische Maschinen innerhalb der Cloud-ComputingInfrastruktur verbreitet werden. In Folge dessen ist die Sicherheit der anderen physischen Maschinen und der dort befindlichen Hypervisor und VMs gefährdet.
5.2.2
Anwendung und Schnittstellen
Cloud-Services verfügen typischerweise über Nutzer- und Programmierschnittstellen,
mittels derer der Zugriff auf den Service erfolgt bzw. Interaktionen und Transaktionen
zwischen Cloud-Service und Nutzer abgewickelt werden.37 Nutzerschnittstellen sind
zumeist webbasiert und für Angreifer ein attraktives Ziel, da sie einfach über einen
Browser zugänglich und potenziell anfällig für eine Vielzahl bekannter Angriffsszenarien und Sicherheitsschwachstellen sind.38 Sollte es einem Angreifer gelingen, eine dieser
Schwachstellen auszunutzen, kann dieses ggf. die gesamte Service-Sicherheit kompromittieren und Vertraulichkeits- und Integritätsverletzungen sensibler Daten zur Folge
haben. In der Literatur häufig genannte Sicherheitsschwachstellen sind bspw. mögliche
Anfälligkeiten webbasierter Nutzerschnittstellen für Cross-Site-Scripting-Angriffe,
Web-Parameter-Manipulationen (z.B. Hidden-Field-Manipulationen) sowie die Injektion von SQL-Befehlen oder Malware in die Cloud-Service-Anwendung. Darüber hinaus
stellt eine schwache bzw. lückenhafte Umsetzung der Nutzer-Authentifizierung ein potenzielles Sicherheitsrisiko dar.39 Hierdurch werden ggf. Brut-Force- und WörterbuchAngriffe möglich, wodurch Angreifer an fremde Zugangsdaten gelangen und den Service sowie gespeicherte Daten anderer Nutzer kompromittieren können.
Eine weitere Quelle für Sicherheitsrisiken sind die Programmierschnittstellen (engl.
Application Programming Interface, kurz API) eines Cloud-Services, die unter anderem
zur Abwicklung von Interaktionen und Transaktionen zwischen Cloud-Service und
37
Vgl. Kalloniatis u. a. (2014), S. 764 sowie Mouratidis u. a. (2013), S. 2278 und Mackay, Bakerb, AlYasiri (2012), S. 683.
38
Vgl. zu diesem und den folgenden zwei Sätzen Fernandes u. a. (2014), S. 17-18, 30 sowie Khorshed,
Ali, Wasimi (2012), S. 838 und Bhadauria u. a. (2014), S. 166, 168.
39
Vgl. zu diesem und dem folgenden Satz Fernandes u. a. (2014), S. 20, 36 sowie Zissis, Lekkas (2012),
S. 586.
15
Nutzer eingesetzt werden.40 Derartige APIs sind oftmals komplex und bieten daher ein
großes Potential für Sicherheitslücken. Darüber hinaus werden Schutzmaßnahmen in
den APIs des Öfteren nur unzureichend umgesetzt. Die in der Literatur identifizierten
Sicherheitsrisiken umfassen APIs ohne Transaktionsunterstützung zur Gewährleistung
der Datenintegrität, sowie unsichere bzw. unzureichend implementierte Authentifizierungsmechanismen in den Programmierschnittstellen, was z.B. eine Authentifizierung
im Klartext zur Folge haben kann.41 Darüber hinaus bringen Schnittstellen, die als
Webservice implementiert werden, weitere potentielle Sicherheitsrisiken mit sich.42 Das
Simple Object Access Protocol (SOAP) wird im Rahmen eines Web-Services für den
Austausch strukturierter Informationen verwendet und basiert auf XML. Durch sogenannte XML-Signature-Wrapping-Angriffe auf eine SOAP-Schnittstelle eines CloudServices können z.B. unberechtigterweise neue VM-Instanzen in der Cloud erzeugt als
auch existierende VM-Instanzen gestartet und gestoppt werden. Dieses kann beispielsweise zu einer eingeschränkten Verfügbarkeit des Cloud-Services führen. Des Weiteren
sind bei Webservices neben SQL- und Schadcode-Injektionen, sogenannte MetadataSpoofing-Angriffe potentiell möglich, bei denen Metadaten zur Schnittstellenbeschreibung manipuliert werden.
Programmfehler und Schwachstellen im Design einer Cloud-Service-Anwendung sind
ebenfalls potentielle Sicherheitsrisiken, die zu einer Kompromittierung von sensiblen
Daten führen können.43 Darüber hinaus können durch Sicherheitslücken im Browser
und den Browser-Erweiterungen (Plugins) weitere Risiken für die Cloud-ServiceSicherheit entstehen. Ein Beispiel hierfür ist der automatische Download eines Trojaners bei Besuch einer kompromittierten Webseite, der ggf. die Zugangsdaten zu einem
Cloud-Service protokolliert und an einen Angreifer weiterleitet.
40
Vgl. zu diesem und den folgenden zwei Sätzen Mouratidis u. a. (2013), S. 2278 sowie Kalloniatis u. a.
(2014), S. 764 und Ahamed, Shahrestani, Ginige (2013), S. 3.
41
Vgl. Fernandes u. a. (2014), S. 29, 36 sowie Modi u. a. (2013), S. 565-566.
42
Vgl. zu diesem und den folgenden vier Sätzen Ahamed, Shahrestani, Ginige (2013), S. 4 sowie Somorovsky u. a. (2011), S. 3 und Modi u. a. (2013), S. 565, 570.
43
Vgl. zu diesem Satz Fernandes u. a. (2014), S. 16-17, 30 sowie Ramgovind, Eloff, Smith (2010), S. 6.
16
5.2.3
Kommunikation und Perimeter-Sicherheit
Eine weitere Quelle potentieller Sicherheitsrisiken stellen anfällige Kommunikationsprotokolle und –standards dar.44 Diese werden für die webbasierte Kommunikation zwischen Cloud-Service und Nutzer verwendet und können Angriffe auf die Datenübertragung ermöglichen. Das IP- und DNS-Protokoll sind bekannte Beispiele für Protokolle
mit Sicherheitsschwachstellen, wodurch unter anderem Angriffsszenarien wie DNSCache-Poisoning oder IP- und DNS-Spoofing ermöglicht werden. Darüber hinaus stellt
eine unzureichende oder fehlende Verschlüsselung des Kommunikationskanals zwischen Cloud-Service und Nutzer ein Sicherheitsrisiko dar. Bei einer nicht vorhandenen
Verschlüsselung oder einer fehlerhaften Implementierung einer beispielsweise HTTPSbasierten Kommunikation oder eines virtuellen privaten Netzwerks (VPN) können ggf.
sensible Daten im Klartext übertragen und durch Ausführung einer Man-in-the-MiddleAttacke durch einen Angreifer abgefangen werden.
Darüber hinaus stellt eine unzureichende bzw. lückenhafte Perimeter-Sicherheit auf
Seiten des Cloud-Service-Anbieters ein Sicherheitsrisiko dar.45 Die NetzwerkInfrastruktur einer Cloud ist wesentlich dynamischer und flexibler als herkömmliche
Netzwerkstrukturen innerhalb eines Rechenzentrums. Dieses ist dadurch begründet, das
innerhalb einer Cloud-Computing-Infrastruktur VMs schnell und dynamisch bei Bedarf
bereitgestellt bzw. entfernt und verschoben werden, was eine konsequente und kontinuierliche Veränderung der Netzwerk-Infrastruktur nach sich zieht. Zudem müssen externe Nutzer auf ihre VMs bzw. Services via Internet zugreifen können. Diese Sachverhalte stellen zusätzliche Anforderungen an die Perimeter-Sicherheit und somit an Firewallund Intrusion-Detection-Systeme. Durch unsichere und lückenhafte Konfigurationen
der Firewall- und Intrusion-Detection-Systeme können potentielle Sicherheitslücken
entstehen, die Angriffsszenarien ermöglichen und die Datensicherheit gefährden. Zudem stellt eine mangelhafte Überwachung & Protokollierung des Netzwerkverkehrs ein
potenzielles Sicherheitsrisiko dar.
44
Vgl. zu diesem Absatz Fernandes u. a. (2014), S. 26, 28-29 sowie Alzain, Soh, Pardede (2012), S. 55
und Morsy, Grundy, Müller (2010), S. 4.
45
Vgl. zu diesem Absatz Fernandes u. a. (2014), S. 34-35.
17
5.2.4
Datenverarbeitung und Datenspeicherung
Mit der Verarbeitung und Speicherung von Daten innerhalb einer Cloud-ComputingInfrastruktur gehen potentielle Sicherheitsrisiken einher, die die Vertraulichkeit und
Integrität vorgehaltener Daten gefährden.46 Ein Beispiel hierfür ist, dass Daten zumeist
in unverschlüsselter Form durch einen Cloud-Service verarbeitet werden. Dieses eröffnet Angreifern bzw. böswilligen Nutzern die potentielle Möglichkeit, in der Verarbeitung befindliche Daten anderer Nutzer durch weitere Schwachstellen des CloudServices im Klartext auszulesen. Darüber hinaus kann eine fehlerhafte Verarbeitung, z.
B. durch Programmfehler im Cloud-Service, zu ungewollten Manipulationen und somit
zu einem Integritätsverlust der Daten führen.47
Ein weiteres Sicherheitsrisiko bringt die unverschlüsselte Speicherung von Daten bzw.
die Verwendung unsicherer und veralteter Verschlüsselungsmethoden und -algorithmen
mit sich.48 Hierdurch ist es für einen Angreifer ggf. möglich, Daten im Klartext auszulesen bzw. eine unsichere Verschlüsselung durch Anwendung der Brut-Force-Methode
oder anderer Techniken auszuhebeln.
Des Weiteren stellt die unzureichende Löschung von Daten bzw. die Wiederverwendung von physischen Festplatten ein potentielles Sicherheitsrisiko dar, da hierdurch eine
Wiederherstellung von sensiblen Daten durch Dritte potentiell möglich ist.49
5.2.5
Daten- und Service-Verfügbarkeit
Distributed-Denial-of-Service (DDos) und Denial-of-Service (DoS) sind Angriffsszenarien, bei denen externe Angreifer einen Cloud-Service mit einer Flut von Anfragen
(engl. Requests) überlasten, sodass die Kapazitäten des Services überschritten werden
und dieser für autorisierte Nutzer nicht mehr erreichbar und zugänglich ist.50 DoS- und
DDos-Angriffe führen somit typischerweise zu einer Service-Diskontinuität, was eine
Beeinträchtigung der Verfügbarkeit in der Cloud vorgehaltener Daten mit sich bringt.
46
Vgl. zu diesem und den folgenden zwei Sätzen Čapek (2012), S. 29.
47
Vgl. Juels, Oprea (2013), S. 66.
48
Vgl. zu diesem Absatz Modi u. a. (2013), S. 565, 567, 577.
49
Vgl. Bhadauria u. a. (2014), S. 170 sowie Brender, Markov (2013), S. 731.
50
Vgl. zu diesem Absatz Ahamed, Shahrestani, Ginige (2013), S. 5 sowie Shini, Thomas, Chithraranjan
(2012), S. 3458 und Bhadauria u. a. (2014), S. 168.
18
Auch innerhalb einer Cloud-Computing-Infrastruktur können DoS-Angriffe ausgeführt
werden. Im Zuge dessen verursacht ein Angreifer bzw. böswilliger Mandant eine ungerechtfertigt hohe Konsumierung geteilter Ressourcen, was typischerweise zu einem
Ressourcenmangel bei virtuellen Maschinen und Services anderer Nutzer führt.
Des Weiteren kann die Verfügbarkeit von Daten gefährdet sein, wenn der CloudService-Anbieter keine bzw. eine unzureichende interne Datensicherung vornimmt.51 Im
Falle eines Systemausfalls durch Hardwarefehler oder Naturkatastrophen sowie einer
ungewollten Löschung bzw. Manipulation von Daten kann dieses unmittelbar zu einem
Datenverlust führen. Darüber hinaus können die durch den Cloud-Service-Anbieter
verwendeten Wiederherstellungstechniken für versehentlich gelöschte Daten und Migrationspraktiken für die Übernahme von Daten in ein neues System fehlerhaft sein,
wodurch ebenfalls ein Datenverlust entstehen kann.
Ein weiteres Risiko für die Datenverfügbarkeit ist die Internet-Verbindung eines Nutzers, die für den Zugang und die Nutzung eines Cloud-Services typischerweise essentiell ist.52 Sollte die Internetkonnektivität eines Nutzers eingeschränkt sein, ist ein Zugriff
auf in der Cloud vorgehaltene Daten nicht möglich und die Datenverfügbarkeit somit
beeinträchtigt.
5.2.6
Ressourcen-Zugang und Datenzugriff
Die Bereitstellung von Cloud-Services erfolgt bei der Mehrheit der Bereitstellungsmodelle durch einen externen Anbieter.53 Dieser Sachverhalt stellt ein potentielles Sicherheitsrisiko dar, wenn böswillige Mitarbeiter (engl. Malicious Insider) des Anbieters ihre
privilegierten Zugriffsrechte und physischen Zugangsmöglichkeiten zur CloudComputing-Infrastruktur dazu missbrauchen, sensible Daten der Nutzer zu stehlen oder
anderweitig zu kompromittieren. Ein identisches Sicherheitsrisiko liegt ebenfalls vor,
wenn sich böswillige Außenstehende physischen Zugang zur Cloud-ComputingInfrastruktur verschaffen und in Folge dessen illegalen Zugriff auf sensible Daten, z.B.
durch Hardware Diebstahl, erhalten.
51
Vgl. Kshetri (2013), S. 379 sowie Bhadauria u. a. (2014), S. 169 und Fernandes u. a. (2014), S. 10, 19.
52
Vgl. zu diesem Absatz Gupta, Gupta (2012), S. 84 sowie Dutta, Alex Peng, Choudhary (2013), S. 45.
53
Vgl. zu diesem Absatz Khan u. a. (2013), S. 1279 sowie Yusop, Abawajy (2014), S. 582, 584.
19
Ein permanentes Sicherheitsrisiko geht zudem von externen Angreifern bzw. Hackern
aus.54 Diese besitzen in der Regel keinen physischen Zugang zur Infrastruktur sondern
identifizieren Sicherheitsschwachstellen z.B. in der Perimeter-Sicherheit oder in der
webbasierten Nutzerschnittstelle eines Cloud-Services. Die identifizierten Sicherheitslücken werden im weiteren Verlauf für unautorisierte Datenzugriffe ausgenutzt. Des
Weiteren nutzen Hacker oftmals Angriffsmethoden wie Phishing, Brute-Force-Attacken
oder Social-Engineering, um an Zugangsinformationen für Cloud-Service-Konten legitimer Nutzer zu gelangen. Sobald ein Angreifer Zugang zu einem Nutzerkonto erlangt
hat, kann dieser zumeist die gesamte Kontrolle darüber übernehmen. Ein derartiges Angriffsszenario wird als Account- bzw. Service-Hijacking bezeichnet.
5.2.7
Unbekannte Sicherheitsrisiken
Ein weiteres Risiko stellen bisher unbekannte Sicherheitsschwachstellen eines CloudServices dar. Werden Sicherheitsschwachstellen am selben Tag, an dem diese bekannt
werden, durch einen Angreifer oder intelligente Schadsoftware ausgenutzt, wird dieses
Vorgehen als Zero-Day-Exploit bezeichnet.55 Es gibt bisher keine bekannten Mechanismen, unbekannte Sicherheitslücken in einer proaktiven Art und Weise zu identifizieren und zu beheben, bevor ein Angriff stattfindet.
Darüber hinaus besteht in der zumeist vorhandenen Intransparenz bzgl. der angewendeten Sicherheitspraktiken innerhalb einer Cloud-Computing-Infrastruktur ein potenzielles
und nicht einschätzbares Sicherheitsrisiko.56 Für einen Nutzer ist es in der Regel nicht
ersichtlich, welche Sicherheitsvorkehrungen ein Cloud-Service-Anbieter implementiert
bzw. nicht implementiert hat, um den Service und die vorgehaltenen Daten zu schützen.
5.2.8
Physische Datenlokation
Mit der Auslagerung sensibler Daten in die Cloud geht für den Nutzer in der Regel ein
Kontrollverlust einher, sofern die Daten nicht innerhalb einer organisationsinternen Private-Cloud-Infrastruktur vorgehalten werden.57 Der Nutzer muss darauf vertrauen, dass
der Cloud-Service-Anbieter angemessene Sicherheitsmaßnahmen zum Schutz der Daten
54
Vgl. zu diesem Absatz Gold (2012), S. 23-24 sowie Rabai u. a. (2013), S. 72.
55
Vgl. zu diesem Absatz Ahamed, Shahrestani, Ginige (2013), S. 4 sowie Fernandes u. a. (2014), S. 23.
56
Vgl. zu diesem Absatz Khorshed, Ali, Wasimi (2012), S. 840 sowie Kalloniatis u. a. (2014), S. 765.
57
Vgl. zu diesem Absatz Kalloniatis u. a. (2014), S. 765 sowie Mouratidis u. a. (2013), S. 2279.
20
ergreift, da die Wahrung der Vertraulichkeit und Integrität nur schwer bzw. nicht durch
den Nutzer auditiert werden kann. Darüber hinaus ist es bei der Nutzung eines CloudServices oftmals nicht ersichtlich, an welcher Lokation bzw. in welchem Land die Nutzer-Daten physisch vorgehalten werden. Dieser Sachverhalt kann ein Sicherheitsrisiko
darstellen, da Daten typischerweise den gesetzlichen Regelungen und Datenschutzbestimmungen des Landes unterliegen, in dem sie physisch vorgehalten werden. Sollten
sensible Daten z.B. in einem Land vorgehalten werden, dessen Gesetzeslage einen Zugriff auf alle Daten innerhalb der Landesgrenzen durch Regierungsbehörden erlaubt, ist
die Vertraulichkeit der Daten gefährdet.
5.3
Sicherheitsrisiken in Abhängigkeit der Bereitstellungsmodelle
Die nachfolgende Tab. 5-1 visualisiert die Beziehungsbildung zwischen den fünf identifizierten Bereitstellungsmodellen und den acht identifizierten SicherheitsrisikoKategorien. Die Bildung der Beziehungen erfolgt gemäß dem in Kapitel 3.4 erläuterten
Vorgehen. Das in Tab. 5-1 ersichtliche Symbol „
“ bedeutet, dass ein Bereitstel-
lungsmodell potentiell durch die Sicherheitsrisiken in einer Kategorie gefährdet ist. Das
Symbol „X“ hingegen meint, dass die Sicherheitsrisiken einer Kategorie im Rahmen des
jeweiligen Bereitstellungsmodells keine Gültigkeit besitzen. Des Weiteren kennzeichnet
das Symbol „
/ X“, dass die Sicherheitsrisiken einer Kategorie nur bedingt für ein Be-
reitstellungsmodell gültig bzw. ungültig sind. Die jeweiligen Bedingungen werden im
weiteren Verlauf dieses Kapitels zusammen mit den gebildeten Beziehungen erörtert.
X
/X
/X
/X
/X
/X
/X
/X
/X
/X
/X
/X
/X
/X
Virtual-PrivateCloud
Hybrid-Cloud
CommunityCloud
SicherheitsrisikoKategorien
Virtualisierung &
1.
Mandantenfähigkeit
Anwendung &
2.
Schnittstellen
Kommunikation &
3.
Perimeter-Sicherheit
Datenverarbeitung &
4.
Datenspeicherung
Daten- & Service5.
Verfügbarkeit
Ressourcen-Zugang &
6.
Datenzugriff
Physische
7.
Datenlokation
Unbekannte
8.
Sicherheitsrisiken
Private-Cloud
Bereitstellungsmodelle
Public-Cloud
21
/X
Tab. 5-1 : Beziehungsbildung zwischen Bereitstellungsmodellen und Sicherheitsrisiko-Kategorien
Wie Tab. 5-1 zeigt, sind sensible Daten innerhalb einer Public-Cloud durch die Sicherheitsrisiken aller acht Sicherheitsrisiko-Kategorien potentiell gefährdet. Dieses ist unter
anderem dadurch begründet, das Public-Cloud-Services typischerweise über webbasierte Nutzer- und Programmierschnittstellen zugänglich sind, wodurch die Sicherheit vorgehaltener Daten durch Sicherheitsrisiken der Kategorien Anwendung & Schnittstellen,
Kommunikation & Perimeter-Sicherheit sowie Daten- & Service-Verfügbarkeit potentiell gefährdet ist. Darüber hinaus wird eine Public-Cloud-Infrastruktur von einer Vielzahl verschiedener Mandanten genutzt, was Sicherheitsrisiken der Kategorien Virtualisierung & Mandantenfähigkeit sowie Datenverarbeitung & Datenspeicherung mit sich
bringt, in denen böswillige Mandanten Sicherheitsschwachstellen der Virtualisierung
oder Datenverarbeitung dazu ausnutzen, Daten anderer Mandanten zu kompromittieren.
Des Weiteren werden Public-Cloud-Services typischerweise durch einen externen Anbieter bereitgestellt. Mit diesem Charakteristikum einer Public-Cloud gehen Sicherheitsrisiken der Kategorien Ressourcen-Zugang & Datenzugriff sowie Physische Datenloka-
22
tion einher. Das Public-Cloud-Bereitstellungsmodell bietet somit die größte Angriffsfläche im Vergleich zu den anderen Bereitstellungsmodellen.58
Das Community-Cloud-Bereitstellungsmodell weist die gleichen Charakteristiken wie
das Public-Cloud-Bereitstellungsmodell auf, da ein Community-Cloud-Service ebenfalls webbasiert zugänglich ist, von mehreren Mandanten bzw. Organisationen genutzt
wird und die Bereitstellung ggf. durch einen externen Anbieter bzw. eine andere Organisation erfolgt. Lediglich der Kreis der Mandanten ist auf eine Menge bestimmter Organisationen und deren Mitarbeitern begrenzt. Es ist jedoch nicht generell ausschließbar, das sich in diesem Mandantenkreis Nutzer mit böswilligen Absichten befinden, die
potentielle Sicherheitsschwachstellen des Cloud-Services für unberechtigte Datenzugriffe etc. auszunutzen. Aus diesem Grund erfolgt die Zuordnung der SicherheitsrisikoKategorien analog zum Public-Cloud-Bereitstellungsmodell, obwohl das generelle Sicherheitsniveau einer Community-Cloud im Vergleich zur Public-Cloud als höher einzustufen ist.59
Im Rahmen des Private-Cloud-Bereitstellungsmodells wird eine Cloud-ComputingInfrastruktur exklusiv von einer Organisation genutzt bzw. alleinig für diese betrieben.
Aus diesem Grund stellen die Sicherheitsrisiken der Kategorie Virtualisierung & Mandantenfähigkeit kein potenzielles Risiko für die Datensicherheit innerhalb einer PrivateCloud-Infrastruktur dar. Diese Annahme beruht darauf, dass eventuell vorhandene
Schwachstellen in der Virtualisierung nicht durch den Mandanten selbst für die Kompromittierung des eigenen Datenbestandes ausgenutzt werden. Darüber hinaus erweist
sich die Beziehungsbildung zwischen den Sicherheitsrisiko-Kategorien und dem Private-Cloud-Bereitstellungsmodell als stark abhängig von den Managementverantwortlichkeiten und der physischen Lokation einer Private-Cloud-Infrastruktur. Wird eine
Private-Cloud-Infrastruktur durch die Organisation selbst bereitgestellt, verwaltet und
im organisationsinternen Rechenzentrum betrieben, so erfolgt der Zugriff auf einen Private-Cloud-Service typischerweise über das interne Netzwerk und nicht über das Web.
In diesem Szenario stellen die Sicherheitsrisiken der meisten Kategorien keine Bedrohung für die Sicherheit sensibler Daten dar (vgl. Tab. 5-1: Sicherheitsrisiken der Kategorien
2
bis
7
unter
genannten
Bedingungen
für
58
Vgl. Bhadauria u. a. (2014), S. 162-163 sowie Fernandes u. a. (2014), S. 7-8.
59
Vgl. Fernandes u. a. (2014), S. 8.
das
Private-Cloud-
23
Bereitstellungsmodell nicht gültig). Dieses ist dadurch begründet, das keine externen
Parteien in der Bereitstellung involviert sind, von denen eine potentielle Gefahr ausgehen kann. Zudem erfolgt der Zugriff und Datentransfer nicht über das Web bzw. Internet, was eine Vielzahl der in Kapitel 5.2 erläuterten Sicherheitsrisiken ausschließt. Wird
eine Private-Cloud-Infrastruktur jedoch durch einen externen Anbieter bereitgestellt und
innerhalb dessen Rechenzentrum betrieben, so wird der Zugriff und Zugang zur PrivateCloud in der Regel mittels webbasierter Schnittstellen realisiert. In diesem Szenario
vergrößert sich die Angriffsfläche des Private-Cloud-Bereitstellungsmodells, da neue
Angriffsvektoren hinzukommen. Dieses hat zur Folge, dass die Datensicherheit durch
eine Vielzahl an Sicherheitsrisiken verschiedener Kategorien potenziell gefährdet wird.
Zudem ist ein Kontrollverlust über sensible Daten gegeben, da diese bei einem externen
Anbieter vorgehalten werden (vgl. Tab. 5-1: Sicherheitsrisiken der Kategorien 2 bis 7
sind unter genannten Bedingungen für das Private-Cloud-Bereitstellungsmodell gültig).
Die
in
Tab.
5-1
ersichtlichen
Beziehungen
zwischen
dem
Hybrid-Cloud-
Bereitstellungsmodell und den Sicherheitsrisiko-Kategorien sind nahezu identisch mit
den vorab erläuterten Beziehungen im Falle des Private-Cloud-Bereitstellungsmodells.
Dieses ist weitestgehend dadurch begründet, dass es für die Zuordnung der Sicherheitsrisiko-Kategorien entscheidend ist, ob sensible Daten im Rahmen des Hybrid-CloudModells innerhalb einer organisationsinternen Private-Cloud oder in einer externen
Public-Cloud vorgehalten und verarbeitet werden. Werden alle schützenswerten Daten
in einer organisationsinternen Private-Cloud vorgehalten und eine angebundene bzw.
angekoppelte Public-Cloud-Infrastruktur beispielsweise nur für die Bereitstellung unkritischer Services verwendet, so ist die Sicherheit der sensiblen Daten kaum gefährdet
(vgl. Tab. 5-1: Sicherheitsrisiken der Kategorien 1 bis 7 unter genannten Bedingungen
für das Hybrid-Cloud-Bereitstellungsmodell nicht gültig). Sollte die Private-CloudInfrastruktur als Teil der Hybrid-Cloud hingegen durch einen externen Dritten bereitgestellt oder sensible Daten gar in einer angebundenen Public-Cloud-Infrastruktur vorgehalten werden, so vergrößert sich wie vorab erläutert die Angriffsfläche und die Sicherheit der sensiblen Daten ist durch eine Vielzahl potenzieller Sicherheitsrisiken gefährdet
(vgl. Tab. 5-1: Sicherheitsrisiken der Kategorien 1 bis 7 unter genannten Bedingungen
für das Hybrid-Cloud-Bereitstellungsmodell gültig).
24
Im Rahmen des Virtual-Private-Cloud-Bereitstellungsmodells (kurz VPC) wird eine
virtuelle Private-Cloud innerhalb einer Public-Cloud-Infrastruktur betrieben, wobei ein
großer Fokus auf der Sicherheit der VPC liegt. Die Beziehungsbildung zwischen den
Sicherheitsrisiko-Kategorien und der VPC wird dadurch erschwert, dass dieses Bereitstellungsmodell in der zugrundeliegenden Literaturbasis kaum Berücksichtigung findet
und daher wesentliche Charakteristiken dieses Modells unklar sind. Mit Bezug auf die
Sicherheitsrisiko-Kategorie Virtualisierung & Mandantenfähigkeit konnte in der Literaturbasis keinerlei Information darüber identifiziert werden, ob eine logische oder physische Isolierung von geteilten Ressourcen Anwendung findet. Sollte typischerweise eine
physische Ressourcenteilung vorgenommen werden, stellen die Sicherheitsrisiken der
Kategorie Virtualisierung & Mandantenfähigkeit keine Bedrohung für die Sicherheit
sensibler Daten dar. Werden geteilte Ressourcen jedoch nur logisch voneinander isoliert, ist es nicht generell ausschließbar, dass die Isolierung oder Virtualisierung
Schwachstellen aufweist (vgl. Kapitel 5.2.1). In diesem Fall stellen die Sicherheitsrisiken der Kategorie Virtualisierung & Mandantenfähigkeit ein potenzielles Risiko für die
Datensicherheit dar. Darüber hinaus ist eine VPC typischerweise über das Web bzw.
webbasierte Schnittstellen zugänglich. Obwohl die Kommunikation zwischen VPCAnbieter und Nutzer typsicherweise mittels eines VPN realisiert und verschlüsselt wird,
sind Sicherheitslücken in der VPN-Konfiguration oder eine Anfälligkeit des Services
für Denial-of-Service-Angriffe nicht generell ausschließbar. Daher können die Sicherheitsrisiken der Kategorien Anwendung & Schnittstellen, Kommunikation & PerimeterSicherheit sowie Daten- & Service-Verfügbarkeit eine potenzielle Bedrohung der Datensicherheit in einer VPC darstellen. Darüber hinaus wird eine VPC in der Regel durch
einen externen Anbieter bereitgestellt, der mehrere VPCs in seiner Public-CloudInfrastruktur betreibt. Aus diesem Grund sind Sicherheitsrisiken der Kategorien Datenverarbeitung & Datenspeicherung, Ressourcen-Zugang & Datenzugriff sowie Physische Datenlokation nicht generell ausschließbar und somit für das VPCBereitstellungsmodell gültig. Trotz dieser kritischen Betrachtungsweise der Sicherheit
einer VPC kann nach Meinung des Autors dieser Ausarbeitung davon ausgegangen
werden, dass das Sicherheitsniveau einer VPC allgemein höher ist als bei einer PublicCloud oder sogar einer Community-Cloud, da die Sicherheit bei diesem Bereitstellungsmodell primär im Fokus steht.60
60
Vgl. Fernandes u. a. (2014), S. 8 sowie King, Raja (2012), S. 309.
25
Die Sicherheitsrisiken der Kategorie Unbekannte Sicherheitsrisiken sind darüber hinaus
für alle Bereitstellungsmodelle gültig, da für keines dieser Modelle ausgeschlossen werden kann, das die Sicherheit sensibler Daten durch unbekannte Sicherheitsrisiken potenziell bedroht wird.
6.
Einschätzung der Anwendbarkeit der Bereitstellungsmodelle für die Verarbeitung gesundheitsbezogener Daten
Die Einschätzung der Anwendbarkeit der Bereitstellungsmodelle für die Verarbeitung
gesundheitsbezogener Daten erfolgt auf Basis der Beziehungsbildung zwischen den
aggregierten Sicherheitsrisiken und den Bereitstellungsmodellen, welche im vorherigen
Kapitel erläutert wurde.
Das Public-Cloud- sowie das Community-Cloud-Bereitstellungsmodell sind nach Meinung des Autors dieser Ausarbeitung nicht für die Vorhaltung und Verarbeitung gesundheitsbezogener Daten geeignet. Dieses ist dadurch begründet, dass die beiden genannten Bereitstellungsmodelle gemäß ihrer Charakteristiken die größte Angriffsfläche
aufweisen und die Datensicherheit durch alle identifizierten Sicherheitsrisiken bzw.
Sicherheitsrisiko-Kategorien potenziell gefährdet ist. In der zugrundeliegenden Literatur
wird das Sicherheitsniveau einer Community-Cloud als höher im Vergleich zur PublicCloud eingestuft.61 Die Einschränkung des Mandantenkreises auf eine bestimmte Menge an Organisationen bzw. Mandanten ist nach Meinung des Autors jedoch nicht ausreichend, um Sicherheitsrisiken kategorisch auszuschließen, in denen böswillige Mandanten bzw. Mitarbeiter des externen Anbieters eine primäre Rolle spielen.
Für das Virtual-Private-Cloud-Bereitstellungsmodell erweist sich die Einschätzung der
Anwendbarkeit für die Verarbeitung und Vorhaltung gesundheitsbezogener Daten als
schwierig. Allgemein betrachtet zeichnet sich eine Virtual-Private-Cloud durch ein hohes Sicherheitsniveau aus, was durch die Implementierung mehrerer Sicherheitsmaßnahmen, wie z.B. einer Verschlüsselung der Kommunikation und einer weitgehenden
Isolierung geteilter Ressourcen, erreicht wird. Gemäß der Beziehungsbildung in Kapitel
5.3 ist eine Virtual-Private-Cloud jedoch nicht für die Verarbeitung und Vorhaltung
gesundheitsbezogener Daten geeignet. Dieses ist unteranderem dadurch begründet, dass
61
Vgl. Fernandes u. a. (2014), S. 8.
26
eventuelle Sicherheitslücken, durch z. B. Konfigurationsfehler oder einer angreifbaren
Isolierung geteilter Ressourcen, trotz des hohen Sicherheitsniveaus nicht vollends ausgeschlossen werden können.
Die Bereitstellungsmodelle Private-Cloud und Hybrid-Cloud sind unter Einhaltung bestimmter Bedingungen für die Verarbeitung und Vorhaltung gesundheitsbezogener Daten geeignet. Eine Bedingung für die Eignung ist, dass die gesundheitsbezogenen Daten
innerhalb einer organisationsinternen Private-Cloud vorgehalten werden und somit die
Cloud-Computing-Infrastruktur durch die Organisation selbst betrieben, verwaltet und
kontrolliert wird. Eine ähnliche Bedingung gilt auch für die Verwendung einer HybridCloud. In diesem Fall sollten gesundheitsbezogene Daten ebenfalls ausschließlich innerhalb einer organisationsinternen Private-Cloud vorgehalten und verarbeitet werden.
Eine angebundene bzw. angekoppelte Public- oder Community-Cloud kann weitergehend für die Bereitstellung und Verarbeitung unkritischer Services bzw. Daten verwendet werden.
7.
Fazit
Im Rahmen dieser Ausarbeitung konnten insgesamt fünf verschiedene Bereitstellungmodelle in der zugrundeliegenden Literaturbasis identifiziert werden, welche in Kapitel
5.1 erläutert werden: Private-Cloud, Public-Cloud, Community-Cloud, Hybrid-Cloud
und Virtual-Private-Cloud. Darüber hinaus konnten 28 verschiedene Sicherheitsrisiken
(siehe Anhang I) in der Literatur identifiziert werden, die zu insgesamt acht Sicherheitsrisiko-Kategorien aggregiert wurden: Virtualisierung & Mandantenfähigkeit, Anwendung & Schnittstellen, Kommunikation & Perimeter-Sicherheit, Daten- & ServiceVerfügbarkeit, Ressourcen-Zugang & Datenzugriff, Physische Datenlokation sowie
Unbekannte Sicherheitsrisiken. Die einzelnen Kategorien mit den enthaltenen Sicherheitsrisiken werden in Kapitel 5.2 erläutert.
Im Zuge der Beziehungsbildung zwischen Bereitstellungsmodellen und Sicherheitsrisiko-Kategorien und einer sich anschließenden Einschätzung bzgl. der Eignung der einzelnen Bereitstellungsmodelle für die Verarbeitung gesundheitsbezogener Daten konnten nur die Bereitstellungsmodelle Private- und Hybrid-Cloud als ausreichend sicher
eingestuft werden. Diese Einschätzung unterliegt jedoch der Bedingung, dass eine organisationsinterne Public-Cloud zur Vorhaltung und Verarbeitung gesundheitsbezogener
27
Daten, auch im Falle einer Hybrid-Cloud, eingesetzt wird. Die Bereitstellungsmodelle
Public- und Community-Cloud bieten hingegen die größte Angriffsfläche bzw. besitzen
mehr Angriffsvektoren im Vergleich zu den anderen Bereitstellungsmodellen und sind
in Folge dessen nicht für die Verarbeitung gesundheitsbezogener Daten geeignet. Auch
die Virtuell-Private-Cloud ist nach Meinung des Autors dieser Ausarbeitung nicht für
die Verarbeitung gesundheitsbezogener Daten geeignet, da trotz eines hohen Sicherheitsniveaus eventuelle Schwachstellen und Sicherheitslücken nicht kategorisch ausgeschlossen werden können.
Durch die vorab geschilderten Resultate und der durchgeführten Beziehungsanalyse
(vgl. Kapitel 5.3) konnte die in der Einleitung dieser Ausarbeitung thematisierte Unklarheit der Beziehungen zwischen Bereitstellungsmodellen und Sicherheitsrisiken des
Cloud-Computings vollends ausgeräumt werden, was eine Erreichung der definierten
Zielsetzung dieser Ausarbeitung impliziert.
Des Weiteren konnte im Rahmen der Durchführung des Literaturreviews eine potenzielle Forschungslücke ausgedeckt werden. Wie in den vorangegangen Kapiteln thematisiert, findet das Virtual-Private-Cloud-Bereitstellungsmodell in der zugrundeliegenden
Literatur größtenteils wenig Berücksichtigung. In Folge dessen sind wesentliche Charakteristiken dieses Bereitstellungsmodells unklar, wie z.B. die Höhe der anfallenden
Kosten oder die Management- und Sicherheitsverantwortlichkeiten. Dieser Sachverhalt
könnte einen Bedarf nach weiterer Forschung zur Beseitigung der Unklarheiten mit sich
bringen.
Die vorliegende Ausarbeit enthält gewisse Limitationen. Zum einen wurden aufgrund
des vorgegebenen Zeitrahmens zur Erstellung dieser Ausarbeitung im Zuge der Literaturbildung nur Publikationen berücksichtigt, die ab dem 01.01.2012 veröffentlicht wurden. Darüber hinaus wurde keine Vor- und Rückwärtssuche in den insgesamt 61 Literaturquellen zur Erweiterung der Literaturbasis vorgenommen. Des Weiteren wurde die
Beziehungsbildung zwischen den identifizierten Sicherheitsrisiken und Bereitstellungsmodellen ausschließlich auf Basis der Charakteristiken der Modelle und Risiken
durchgeführt. Weitere potenzielle Einflussfaktoren auf die Beziehungen, wie z.B. Service-Level-Agreements oder die vertraglich fixierte Einhaltung bestimmter Sicherheitsstandards, wurden nicht berücksichtigt und diskutiert, um den vorgegebenen Umfang
dieser Ausarbeitung nach Möglichkeit zu wahren bzw. nicht maßlos zu überschreiten.
28
Literaturverzeichnis
Ahamed, Shahrestani, Ginige (2013)
Farhad Ahamed, Seyed Shahrestani, Athula Ginige: Cloud Computing: Security
and Reliability Issues. In: Communications of the IBIMA. Nr. 655710, Jg. 2013,
2013, S. 1-12
Aleem, Sprott (2013)
Azeem Aleem, Christopher R. Sprott: Let me in the cloud: Analysis of the benefit and risk assessment of cloud platform. In: Journal of Financial Crime. Nr.
1, Jg. 20, 2013, S. 6-24
Alzain, Soh, Pardede (2012)
Mohammed A. Alzain, Ben Soh, Eric Pardede: A new model to ensure security
in cloud computing services. In: Journal of Service Science Research. Nr. 1, Jg.
4, 2012, S. 49-70
Bhadauria u. a. (2014)
Rohit Bhadauria, Rituparna Chaki, Nabendu Chaki, Sugata Sanyal: Security
Issues in Cloud Computing. In: Acta Technica Corvininesis - Bulletin of Engineering. Nr. 4, Jg. 7, 2014, S. 159-177
Brender, Markov (2013)
Nathalie Brender, Iliya Markov: Risk perception and risk management in cloud
computing: Results from a case study of Swiss companies. In: International
Journal of Information Management. Nr. 5, Jg. 33, 2013, S. 726-733
Čapek (2012)
Jan Čapek: Cloud Computing and Information Security. In: Scientific Papers of
the University of Pardubice. Series D, Faculty of Economics & Administration.
Nr. 24, Jg. 18, 2012, S. 23-30
Dutta, Alex Peng, Choudhary (2013)
Amab Dutta, Guo Chao Alex Peng, Alok Choudhary: Risks in Enterprise Cloud
Computing: The perspective of IT experts. In: Journal of Computer Information
Systems. Nr. 4, Jg. 53, 2013, S. 39-48
Fernandes u. a. (2014)
Diogo Fernandes, Liliana Soares, João Gomes, Mário Freire, Pedro Inácio:
Security Issues in Cloud Environments - A survey. In: International Journal of
Information Security. Nr. 2, Jg. 13, 2014, S. 1-53
Gold (2012)
Joshua Gold: Protection in the Cloud: Risk Management and Insurance for Cloud
Computing. In: Journal of Internet Law. Nr. 12, Jg. 15, 2012, S. 23-28
Gupta, Gupta (2012)
Anil K. Gupta, Manoj K. Gupta: A New Era of Cloud Computing in Private and
Public Sector Organization. In: International Archive of Applied Sciences &
29
Technology. Nr. 2, Jg. 3, 2012, S. 80-85
Jansen, Grance (2011)
Wayne Jansen, Timothy Grance: Guidelines on Security and Privacy in Public
Cloud Computing. Gaithersburg, Maryland 2011
Juels, Oprea (2013)
Ari Juels, Alina Oprea: New Approaches to Security and Availability for Cloud
Data. In: Communications of the ACM. Nr. 2, Jg. 56, 2013, S. 64-73
Kalloniatis u. a. (2014)
Christos Kalloniatis, Haralambos Mouratidis, Manousakis Vassilis, Shareeful Islam, Stefanos Gritzalis, Evangelia Kavakli: Towards the design of secure and
privacy-oriented information systems in the cloud: Identifying the major concepts. In: Computer Standards & Interfaces. Nr. 4, Jg. 36, 2014, S. 759-775
Kalloniatis, Mouratidis, Islam (2013)
Christos Kalloniatis, Haralambos Mouratidis, Shareeful Islam: Evaluating cloud
deployment scenarios based on security and privacy requirements. In: Requirements Engineering. Nr. 4, Jg. 18, 2013, S. 299-319
Karadsheh (2012)
Louay Karadsheh: Applying security policies and service level agreement to IaaS
service model to enhance security and transition. In: Computers & Security. Nr.
3, Jg. 31, 2012, S. 315-326
Khan u. a. (2013)
Abdul N. Khan, M. L Mat Kiah, Samee U. Khan, Sajjad A. Madani: Towards
secure mobile cloud computing: A survey. In: Special Section: Hybrid Cloud
Computing. Nr. 5, Jg. 29, 2013, S. 1278-1299
Khorshed, Ali, Wasimi (2012)
Md. Tanzim Khorshed, A. B. M. Ali, Saleh A. Wasimi: A survey on gaps, threat
remediation challenges and some thoughts for proactive attack detection in cloud
computing. In: Future Generation Computer Systems. Nr. 6, Jg. 28, 2012, S.
833-851
King, Raja (2012)
Nancy J. King, V. T. Raja: Protecting the privacy and security of sensitive
customer data in the cloud. In: Computer Law & Security Review. Nr. 3, Jg. 28,
2012, S. 308-319
Kshetri (2013)
Nir Kshetri: Privacy and security issues in cloud computing: The role of institutions and institutional evolution. In: Telecommunications Policy. 4/5, Jg. 37,
2013, S. 372-386
Lacity u. a. (2010)
Mary C. Lacity, Shaji Khan, Aihua Yan, Leslie P. Willcocks: A review of the IT
outsourcing empirical literature and future research directions. In: Journal of In-
30
formation Technology (Palgrave Macmillan). Nr. 4, Jg. 25, 2010, S. 395-433
Leavitt (2013)
Neal Leavitt: Hybrid Clouds Move to the Forefront. In: Computer. Nr. 5, Jg. 46,
2013, S. 15-18
Li u. a. (2012)
Jianxin Li, Bo Li, Tianyu Wo, Chunming Hu, Jinpeng Huai, Lu Liu, K. P. Lam:
CyberGuarder: A virtualization security assurance architecture for green cloud
computing. In: Future Generation Computer Systems. Nr. 2, Jg. 28, 2012, S.
379-390
Mackay, Bakerb, Al-Yasiri (2012)
M. Mackay, T. Bakerb, A. Al-Yasiri: Security-oriented cloud computing platform for critical infrastructures. In: Computer Law & Security Review. Nr. 6, Jg.
28, 2012, S. 679-686
Mell, Grance (2011)
Peter Mell, Timothy Grance: The NIST Definition of Cloud Computing:
Recommendations of the National Institute of Standards and Technology.
Gaithersburg, Maryland 2011
Modi u. a. (2013)
Chirag Modi, Dhiren Patel, Bhavesh Borisaniya, Avi Patel, Muttukrishnan
Rajarajan: A survey on security issues and solutions at different layers of Cloud
computing. In: Journal of Supercomputing. Nr. 2, Jg. 63, 2013, S. 561-592
Morsy, Grundy, Müller (2010)
Mohamed A. Morsy, John Grundy, Ingo Müller: An analysis of the cloud computing security problem. In: Proceedings of APSEC 2010 Cloud Workshop, 3.
November, 2010, S. 1-6
Mouratidis u. a. (2013)
Haralambos Mouratidis, Shareeful Islam, Christos Kalloniatis, Stefanos Gritzalis: A framework to support selection of cloud providers based on security and
privacy requirements. In: Journal of Systems and Software. Nr. 9, Jg. 86, 2013,
S. 2276-2293
Nanavati u. a. (2014)
Mihir Nanavati, Patrick Colp, Bill Aiello, Andrew Warfield: Cloud Security: A
Gathering Storm. In: Communications of the ACM. Nr. 5, Jg. 57, 2014, S. 70-79
Nicho, Hendy (2013)
Mathew Nicho, Mahmoud Hendy: Dimensions Of Security Threats In Cloud
Computing: A Case Study. In: The Review of Business Information Systems
(Online). Nr. 4, Jg. 17, 2013, S. 159
Rabai u. a. (2013)
Latifa Ben Arfa Rabai, Mouna Jouini, Anis B. Aissa, Ali Mili: A cybersecurity
model in cloud computing environments. In: Journal of King Saud University -
31
Computer and Information Sciences. Nr. 1, Jg. 25, 2013, S. 63-75
Ramgovind, Eloff, Smith (2010)
S. Ramgovind, M. M. Eloff, E. Smith: The management of security in Cloud
computing. In: Information Security for South Africa (ISSA), 2010, S. 1-7
Regola, Chawla (2013)
Nathan Regola, Nitesh V. Chawla: Storing and Using Health Data in a Virtual
Private Cloud. In: Journal of medical Internet research. Nr. 3, Jg. 15, 2013, S.
e63
Shini, Thomas, Chithraranjan (2012)
S. G. Shini, Tony Thomas, K. Chithraranjan: Cloud Based Medical Image
Exchange-Security Challenges. In: International Conference on Modelling Optimization and Computing. Nr. 1, Jg. 38, 2012, S. 3454-3461
Somorovsky u. a. (2011)
Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, Luigi Lo Iacono: All Your Clouds Are Belong to Us: Security Analysis of
Cloud Management Interfaces. In: Proceedings of the 3rd ACM Workshop on
Cloud Computing Security Workshop. Nr. 1, CCSW’11, 2011, S. 3-14
Tsai u. a. (2012)
Hsin-Yi Tsai, Melanie Siebenhaar, Andre Miede, Yulun Huang, Ralf Steinmetz:
Threat as a Service?: Virtualization's Impact on Cloud Security. In: IT Professional Magazine. Nr. 1, Jg. 14, 2012, S. 32-37
Venters, Whitley (2012)
Will Venters, Edgar A. Whitley: A critical review of cloud computing: researching desires and realities. In: Journal of Information Technology (Palgrave
Macmillan). Nr. 3, Jg. 27, 2012, S. 179-197
Yusop, Abawajy (2014)
Zulkefli M. Yusop, Jemal Abawajy: Analysis of Insiders Attack Mitigation Strategies. In: 2nd International Conference on Innovation, Management and Technology Research. Nr. 1, Jg. 129, 2014, S. 581-591
Zissis, Lekkas (2012)
Dimitrios Zissis, Dimitrios Lekkas: Addressing cloud computing security issues.
In: Future Generation Computer Systems. Nr. 3, Jg. 28, 2012, S. 583-592
32
Anhang
Anhang I: Identifizierte Sicherheitsrisiken
ID
1
2
3
4
5
Sicherheitsrisiko
Unsichere und fehlerhafte Programmier- und
Nutzerschnittstellen
Programmfehler und Design-Schwachstellen in der
Cloud-Service-Anwendung
Unsichere Authentifizierungsmechanismen &
Zurücksetzungsmechanismen für Zugangsdaten
Web-Service-Schwachstellen (Metadata-SpoofingAttacken, XML SOAP wrapping attacks)
Web-Technologie-Schwachstellen (Cross-SiteScripting, Schadcode- & SQL-Injektion; HTML-Hidden
Field-Manipulation, Drive-by Malware Download)
6 Verarbeitung von Daten im Klartext
7 Ungewollte Manipulation von Daten
8
Fehlende bzw. unsichere & veraltete Verschlüsselung
oder fehlerhafte Verschlüsselungsalgorithmen
9 Unzureichende Löschung von Daten
Denial of Service (DoS)- und Distributed Denial of
Service (DDoS)-Angriffe
Fehlerhafte & lückenhafte Datensicherung auf Seiten
11
des Cloud-Service-Anbieter
Systemausfälle durch Hardwarefehler oder
12
Naturkatarstrophen
10
13 Fehlende Internetkonnektivität
Unverschlüsselte Datenübertragung bzw. fehlerhafte
Konfiguration der Kommunikationsverschlüsselung
Schwachstellen der Perimeter- & Netzwerksicherheit
15
durch unsichere Firewall- oder IDS-Konfiguration
SicherheitsrisikoKategorie
Anwendung &
Schnittstellen
Anwendung &
Schnittstellen
Anwendung &
Schnittstellen
Anwendung &
Schnittstellen
Anwendung &
Schnittstellen
Datenverarbeitung &
Datenspeicherung
Datenverarbeitung &
Datenspeicherung
Datenverarbeitung &
Datenspeicherung
Datenverarbeitung &
Datenspeicherung
Datenverfügbarkeit
Datenverfügbarkeit
Datenverfügbarkeit
Datenverfügbarkeit
Kommunikation &
Perimeter-Sicherheit
Kommunikation &
Perimeter-Sicherheit
Kommunikation &
16 Man-in-the-Middle Angriffe auf die Datenübertragung
Perimeter-Sicherheit
Schwachstellen in Kommunikationsprotokollen & Kommunikation &
17
standards (IP, DNS, DHCP, HTTP)
Perimeter-Sicherheit
14
33
Physische
Datenloaktion
Physische
Physische Daten-Lokation
Datenloaktion
Böswillige Mitarbeiter (Malicious Insider) beim Cloud- Ressourcen-Zugang &
Service-Anbieter mit physischem Ressourcen-Zugang Datenzugriff
Ressourcen-Zugang &
Hacker (Malicious Outsider)
Datenzugriff
Ressourcen-Zugang &
Account- und Service-Hijacking
Datenzugriff
Unbekannte
Zero-Day Exploits
Sicherheitsrisiken
Angriffe auf virtuelle Maschinen anderer Nutzer durch
Sicherheitsschwachstellen in der Virtualisierung oder Virtualisierung &
Isolierung geteilter Ressourcen (Side- & CovertMandantenfähigkeit
Channel-Angriffe, VM-Hopping)
Kompromittierung von VM-Templates mit
Virtualisierung &
Schadsoftware/Malware
Mandantenfähigkeit
Kompromittierung des Hypervisors durch Injektion von Virtualisierung &
Schadsoftware/Malware
Mandantenfähigkeit
VM-Mobility (Diebstahl von virtuellen Festplatten,
Virtualisierung &
schnelle Verbreitung korrupter VMs)
Mandantenfähigkeit
Fehlende aktuelle Schutz- und Sicherheitsmaßnahmen Virtualisierung &
in allen VM-Instanzen
Mandantenfähigkeit
18 Kontrollverlust über Daten
19
20
21
22
23
24
25
26
27
28
34
Thesenpapier
These 1:
Die Sicherheit bzw. Angriffsfläche eines Cloud-Computing-Bereitstellungsmodells ist
stark davon Abhängig, ob der Nutzer-Zugriff über webbasierte Schnittstellen erfolgt
und externe Dritte in der Bereitstellung und Nutzung involviert sind.
These 2:
Die Cloud-Computing-Bereitstellungsmodelle Public-Cloud und Community-Cloud
sind für die Vorhaltung und Verarbeitung gesundheitsbezogener Daten, wie z. B. elektronische Patientenakten, nicht geeignet.
These 3:
Gesundheitsbezogene Daten, wie z.B. elektronische Patientenakten, sollten ausschließlich innerhalb einer organisationsinternen Private-Cloud-Infrastruktur bzw. innerhalb
des organisationsinternen Rechenzentrums vorgehalten und verarbeitet werden.
These 4:
Das Virtual-Private-Cloud-Bereitstellungsmodell bietet zwar ein hohes Sicherheitsniveau, ist aber dennoch für die Vorhaltung gesundheitsbezogener Daten nicht geeignet,
da dieses noch nicht hinreichend erforscht ist und Sicherheitsschwachstellen nicht ausgeschlossen werden können.