Marius Franke
Masterarbeit
im Fach Information Systems
Anforderungen an die Zertifizierungskriterien einer
dynamischen Zertifizierung von Cloud-Diensten
Themasteller: Prof. Dr. Ali Sunyaev
Vorgelegt in der Masterprüfung
im Studiengang Information Systems
der Wirtschafts- und Sozialwissenschaftlichen Fakultät
der Universität zu Köln
Köln, März 2015
II
Inhaltsverzeichnis
Abkürzungsverzeichnis................................................................................................... IV
Tabellenverzeichnis ..........................................................................................................V
1 Einleitung ......................................................................................................................1
1.1 Problemstellung und Motivation ..............................................................................1
1.2 Ziel(e) der Arbeit ......................................................................................................3
1.3 Aufbau der Arbeit.....................................................................................................4
2 Grundlagen ....................................................................................................................5
2.1 Terminologie ............................................................................................................5
2.1.1 Cloud-Computing ...........................................................................................5
2.1.2 Zertifizierung, Zertifikat und Zertifizierungskriterium ..................................5
2.1.3 Kundenanforderungen an Zertifizierungskriterien .........................................7
2.2 Zertifizierungen im Cloud-Umfeld ..........................................................................8
2.2.1 Definition: Cloud-Zertifizierung.....................................................................8
2.2.2 Gründe und Nutzen einer Cloud-Zertifizierung..............................................9
2.2.3 Herausforderungen bei der Zertifizierung von Cloud-Diensten ...................12
3 Dynamische Cloud-Zertifizierung ..............................................................................14
3.1 Grundgedanke und Konzept ...................................................................................14
3.2 Auditierungsmethoden ...........................................................................................16
3.3 Transparenz als ein Erfolgsfaktor ..........................................................................17
3.4 Spezifikation und Prüfberichte ...............................................................................19
3.5 Zertifizierungskriterienkatalog ...............................................................................19
4 Methodik .....................................................................................................................20
4.1 Herleitung von Kundenanforderungen aus praxisorientierten CloudPublikationen..........................................................................................................20
4.1.1 Vorgehensweise zur Auswahl zielführender CloudPublikationen ................................................................................................20
4.1.2 Vorgehensweise zur Herleitung von Kundenanforderungen aus
den ausgewählten Cloud-Publikationen........................................................22
4.2 Workshop im Forschungsumfeld ...........................................................................23
4.3 Validierung der Ergebnisse mittels Expertenaussagen ..........................................25
5 Ergebnisse der einzelnen Phasen der Anforderungsermittlung ..................................27
5.1 Literaturbasierte Anforderungsermittlung..............................................................27
III
5.1.1 Auswahl zielführender Cloud-Publikationen................................................27
5.1.2 Untersuchung der ausgewählten Cloud-Publikationen .................................33
5.2 Workshop im Forschungsumfeld ...........................................................................35
5.3 Auswertung des Expertenworkshops .....................................................................38
6 Kundenanforderungen an Zertifizierungskriterien .....................................................42
6.1 Kundenanforderungen an die Spezifikation eines
Zertifizierungskriteriums ........................................................................................43
6.2 Kundenanforderungen an den Prüfbericht eines
Zertifizierungskriteriums ........................................................................................51
6.2.1 Kundenanforderungen zur Schaffung der Grundlagen .................................52
6.2.2 Kundenanforderungen an die Inhalte des Prüfberichtes ...............................56
7 Fazit.............................................................................................................................67
Literaturverzeichnis .........................................................................................................69
Anhang.............................................................................................................................78
A1. Zertifizierungskriterienkatalog ...............................................................................78
A2. Informationsblatt und Anforderungskatalog für den Workshop im
Forschungsumfeld ..................................................................................................81
A3. Transkript des Expertenworkshops ........................................................................81
A4. Codierung der Auswahl zielführender Cloud-Publikationen .................................81
A5. Codierung der Herleitung der Kundenanforderungen ............................................81
A6. Transkript des Workshops im Forschungsumfeld ..................................................81
A7. Inhalte der beigefügten CD-ROM ..........................................................................81
Erklärung .........................................................................................................................83
Lebenslauf........................................................................................................................84
IV
Abkürzungsverzeichnis
CSC
Cloud-Service-Customer
CSP
Cloud-Service-Provider
dCZ
dynamische Cloud-Zertifizierung
IaaS
Infrastructure-as-a-Service
PaaS
Plattform-as-a-Service
ROI
Return-on-Investment
SaaS
Software-as-a-Service
SCP
Sub-Cloud-Provider
V
Tabellenverzeichnis
Tab. 2-1: Eigenschaften einer Kundenanforderung an ein
Zertifizierungskriterium einer dynamischen Cloud-Zertifizierung ...................8
Tab. 4-1: Kriterien zur Ableitung von Kundenanforderungen ........................................23
Tab. 4-2: Schema zur Darstellung einer Anforderung.....................................................24
Tab. 4-3: Leitfragen zur Orientierung innerhalb des Workshops ....................................24
Tab. 5-1: Übersicht zu den formalen Auswahlkriterien und deren
Anwendungsreihenfolge .................................................................................28
Tab. 5-2: Quantitative Ergebnisse des Auswahlprozesses auf Basis formaler
Auswahlkriterien .............................................................................................29
Tab. 5-3: Übersicht zu den inhaltlichen Auswahlkriterien und deren
Anwendungsreihenfolge .................................................................................29
Tab. 5-4: Quantitative Ergebnisse des Auswahlprozesses auf Basis der
inhaltlichen Auswahlkriterien .........................................................................30
Tab. 5-5: Übersicht der ausgewählten Cloud-Frameworks .............................................31
Tab. 5-6: Quantitative Ergebnisse der Überarbeitung des
Anforderungskataloges ...................................................................................38
Tab. 6-1: Übersicht über die Kundenanforderungen an die Spezifikation der
Zertifizierungskriterien ...................................................................................44
Tab. 6-2: Übersicht über die Kundenanforderungen an die Prüfberichte der
Zertifizierungskriterien ...................................................................................52
1
1
Einleitung
1.1
Problemstellung und Motivation
Cloud-Computing besitzt das Potential, die Art und Weise, wie IT-Dienstleistungen
bisher in Unternehmen erbracht werden, grundlegend zu verändern.1 Die Gründe hierfür
liegen in den charakteristischen Vorteilen des Cloud-Computing-Paradigmas, wie
geringe Anfangsinvestitionen, hohe Skalierbarkeit und ausgeprägte Flexibilität. Trotz
der ökonomischen und technischen Vorteile stehen viele Unternehmen vor großen
Herausforderungen und schrecken vor dem Einsatz von Cloud-Computing-Lösungen
zurück.2 Die Gründe hierfür sind vielfältig und reichen vom Kontrollverlust3 über die
ausgelagerten Anwendungen und Daten bis hin zu organisatorischen4, technischen5 und
rechtlichen6 Hürden.
Darüber hinaus stellt das mangelnde Vertrauen zwischen dem Cloud-Kunden und dem
-Anbieter eine weitere Hürde dar und spielt bei der Adoption einer Cloud-ComputingLösung eine entscheidende Rolle.7 Kunden mangelt es jedoch häufig an ausreichenden
Ressourcen und Informationen, um das notwendige Vertrauensverhältnis zu einem
Cloud-Anbieter herzustellen.8 Vor diesem Hintergrund kann eine Zertifizierung von
Cloud-Diensten einen positiven Beitrag leisten und gegenüber potentiellen CloudKunden für Transparenz sorgen, ihre Entscheidungsprozesse unterstützen, das Risiko
von Sicherheitsvorfällen und Fehlinvestitionen reduzieren und somit das Vertrauen in
und die Akzeptanz für das Cloud-Computing steigern.9 Angesichts dieser Vorteile kann
angenommen werden, dass Cloud-Kunden ein dementsprechend großes Interesse an
Cloud-Zertifikaten besitzen.
1
Vgl. Bezzi, Kaluvuri, Sabetta (2011), S. 40.
2
Vgl. Bernnat u. a. (2012), S. 136 und zu den ökonomischen Vorteilen Jensen u. a. (2009), S. 109.
3
Vgl. Munoz, Mana (2013), S. 103.
4
Vgl. Marston u. a. (2011), S. 182.
5
Vgl. Armbrust u. a. (2010), S. 54.
6
Vgl. Armbrust u. a. (2010), S. 55, 58 und Lansing, Sunyaev (2013), S. 9.
7
Vgl. Garrison, Kim, Wakefield (2012), S. 67 und Sunyaev, Schneider (2013), S. 34.
8
Vgl. zum Ressourcenmangel Sunyaev, Schneider (2013), S. 34.
9
Vgl. Sunyaev, Schneider (2013), S. 34, Schneider, Lansing, Sunyaev (2013), S. 13 und Bernnat u. a.
(2012), S. 133.
2
Aufgrund der speziellen Charakteristika und der Komplexität des Cloud-ComputingModells stellt die Zertifizierung von Cloud-Diensten jedoch eine Herausforderung dar.10
Die derzeitigen Zertifizierungen von IT-Systemen, wie beispielsweise die Zertifizierung
nach ISO 27001, sind nur eingeschränkt auf Cloud-Lösungen anwendbar.11 Dies liegt
unter anderem daran, dass die Erfüllung der Zertifizierungskriterien nur zum Zeitpunkt
der Vergabe des Zertifikates bestätigt werden kann, da keine fortlaufende Kontrolle des
Erfüllungsstatus erfolgt. Werden nach der Vergabe des Zertifikates Veränderungen am
zertifizierten System vorgenommen, kann die Erfüllung der Kriterien und somit des
gesamten Zertifikates gefährdet sein.12 Da insbesondere Cloud-Dienste aufgrund der
essentiellen Eigenschaften des Cloud-Computing-Modells von einer inhärenten
Dynamik geprägt sind, die häufige Veränderungen der Cloud-Dienste zur Folge haben
können, sind diese Zertifizierungen in solch einem Umfeld unzureichend, um die
Einhaltung der Zertifizierungskriterien fortlaufend zu gewährleisten. Darüber hinaus
sind diese Zertifizierungen von einem manuellen Aufwand geprägt und gelten als
ineffizient und fehleranfällig.13 Als Folge dieser Mängel wird von WINDHORST und
SUNYAEV (2013) das Konzept einer dynamischen Cloud-Zertifizierung (dCZ)
beschrieben, welches sich aktuell noch in der Anfangsphase seiner Entwicklung
befindet.14 Die dCZ hat zum Ziel, die Gültigkeit der Zertifizierungskriterien möglichst
fortlaufend zu gewährleisten und die Zertifizierung von Cloud-Diensten effizienter und
zuverlässiger zu gestalten.
Da der Nutzen eines Cloud-Zertifikates aus Sicht der potentiellen Cloud-Kunden vor
allem von den Inhalten des Zertifikates abhängt,15 ist es für die Entwicklung einer dCZ
notwendig, einen besonderen Fokus auf diese Inhalte zu legen und sich an den
Kundenanforderungen zu orientieren. Bei der Entwicklung einer dCZ kann die
Berücksichtigung der Anforderungen die vom Kunden wahrgenommene Qualität des
Endergebnisses steigern und somit zu einer höheren Akzeptanz des Zertifikates führen.16
10
Vgl. Cimato u. a. (2013), S. 92 und Windhorst, Sunyaev (2013), S. 413.
11
Vgl. Windhorst, Sunyaev (2013), S. 413.
12
Vgl. Bezzi, Kaluvuri, Sabetta (2011), S. 41 und Munoz, Mana (2013), S. 103.
13
Vgl. Windhorst, Sunyaev (2013), S. 413 und Pinkett (2004), S. 45.
14
Vgl. Windhorst, Sunyaev (2013), S. 412 und Schneider u. a. (2014), S. 4999.
15
Vgl. Lansing, Sunyaev (2013), S. 2, 4 und Schneider u. a. (2014), S. 4998.
16
Vgl. zur geringen Akzeptanz aufgrund der unzureichenden Berücksichtigung der Kundenanforderungen
Schneider, Lansing, Sunyaev (2013), S. 15, 17.
3
Zu den zentralen inhaltlichen Bestandteilen einer Zertifizierung zählen die
Zertifizierungskriterien, nach denen ein Cloud-Dienst evaluiert wird. Qualitativ
hochwertige Zertifizierungskriterien sind eine fundamentale Voraussetzung für den
Erfolg und die Reputation eines Zertifikates.17
In der Praxis ist es allerdings unklar, wie die Zertifizierungskriterien einer dCZ aus
Kundensicht gestaltet werden sollen, um die gewünschte Wirkung eines Zertifikates zu
erzielen. Zur Lösung dieses Praxisproblems sind deshalb genauere Kenntnisse über die
Kundenanforderungen erforderlich. Trotz der Bedeutung der Zertifizierungskriterien für
den Nutzen und die Akzeptanz eines dynamischen Cloud-Zertifikates sind die
Kundenanforderungen an diese noch unerforscht und unbekannt. Dieser theoretische
Mangel erschwert die Lösung des Praxisproblems.
Vor diesen Hintergründen wird im Rahmen dieser Masterarbeit die Forschungsfrage
verfolgt,
welche
Anforderungen
potentielle
Cloud-Kunden18
an
die
Zertifizierungskriterien einer dCZ stellen, damit der Nutzen und die Akzeptanz eines
dynamischen Cloud-Zertifikates gewährleistet ist bzw. hergestellt werden kann. Die
nachfolgenden Ausführungen orientieren sich daher an folgender Leitfrage:
Welche
Anforderungen
müssen
die
Zertifizierungskriterien
einer
dynamischen Cloud-Zertifizierung erfüllen, um die Erwartungen und
Bedürfnisse der Cloud-Kunden zu erfüllen.
Die Beantwortung dieser Leitfrage kann einen Beitrag zur kundenorientierten
Entwicklung einer dCZ leisten, sodass sich diese mittelfristig als allgemein anerkannter
Standard auf dem Markt der Cloud-Zertifizierungen etablieren kann.
1.2
Ziel(e) der Arbeit
Das Hauptziel dieser Arbeit besteht in der Ermittlung der Anforderungen der CloudKunden, die sie an die Zertifizierungskriterien einer dCZ stellen. Zur Erreichung des
Hauptziels werden vier Teilziele verfolgt. Das erste Teilziel soll die theoretischen
17
Vgl. Meissner (2008), S. 525.
18
Zu potentiellen Cloud-Kunden zählen im Rahmen dieser Arbeit Unternehmen aus der Privatwirtschaft
oder dem öffentlichen Sektor. Potentiell bedeutet, dass diese Organisationen mögliche Endkunden
eines Cloud-Anbieters sind. Aus Gründen der Lesbarkeit wird im Folgenden nur noch von CloudKunden gesprochen.
4
Grundlagen dieser Arbeit schaffen und in den Bereich der Cloud-Zertifizierungen
einführen. Hierzu werden die Konzepte der statischen und dynamischen CloudZertifizierung beschrieben sowie auf deren Gründe, Nutzen und Herausforderungen
eingegangen. Zudem wird herausgearbeitet, welche Faktoren aus Kundensicht zur
Akzeptanz einer dCZ beitragen können und inwiefern diese Faktoren auf die
Zertifizierungskriterien einer dCZ übertragen werden können. Anschließend werden –
im
Sinne
des
zweiten
Teilziels
–
mögliche
Kundenanforderungen
an
Zertifizierungskriterien systematisch aus ausgewählten kunden- und praxisorientierten
Cloud-Publikationen ermittelt und in einem Anforderungskatalog gesammelt. Als drittes
Teilziel gilt es, die bisher theoretisch fundierten Ergebnisse aus den CloudPublikationen in einem Workshop im Forschungsumfeld zur Diskussion zu stellen und
die ermittelten Anforderungen insbesondere im Hinblick auf deren Kundenrelevanz und
Praxistauglichkeit zu bewerten. Die Ergebnisse dieses Workshops werden zur
Überarbeitung des Anforderungskataloges verwendet. Das vierte und letzte Teilziel
besteht
darin,
die
ermittelten
und
überarbeiteten
Anforderungen
mittels
Expertenaussagen von praxiserfahrenen Cloud-Auditoren, -Anbietern und -Beratern
einzuordnen und empirisch zu validieren.
1.3
Aufbau der Arbeit
Nachdem innerhalb dieses ersten Kapitels bereits die Problemstellung und die Ziele
dieser Ausarbeitung dargelegt werden, wird im zweiten Kapitel die Grundlage für diese
Arbeit geschaffen. Hierzu werden zunächst die zentralen Begriffe definiert (Kapitel 2.1)
sowie auf die Gründe, den Nutzen und die Herausforderungen einer Zertifizierung im
Cloud-Umfeld eingegangen (Kapitel 2.2). Im dritten Kapitel wird das Konzept einer
dCZ, deren technische Voraussetzungen sowie mögliche Erfolgsfaktoren im Hinblick
auf die Zertifizierungskriterien dargelegt. Die Methodik dieser Arbeit, die sich in drei
Phasen gliedert, wird im vierten Kapitel beschrieben. Das anschließende fünfte Kapitel
stellt die Resultate der drei Phasen vor. Im sechsten Kapitel werden die zentralen
Ergebnisse, die Kundenanforderungen an die Zertifizierungskriterien einer dCZ,
dargelegt. Den Abschluss dieser Masterarbeit bildet das siebte Kapitel mit einem Fazit.
In diesem wird insbesondere auf die Ergebnisse vor dem Hintergrund der Zielstellung
eingegangen. Zudem wird ein Ausblick auf weitere notwendige Forschungsschritte in
diesem Themenfeld gegeben.
5
2
Grundlagen
2.1
Terminologie
2.1.1 Cloud-Computing
Im Forschungsbereich des Cloud-Computings wurden über die letzten Jahre viele
verschiedene Definitionen für den Begriff des Cloud-Computings aufgestellt. Eine
umfassende Definition, die häufig in der Forschungsliteratur verwendet wird, ist die des
National Institute of Standards and Technology (NIST). Diese bildet auch in dieser
Arbeit die Grundlage zur Definition des Begriffs Cloud-Computing:
Cloud-Computing beschreibt ein Modell, welches dem Nutzer bei Bedarf Zugriff auf
einen dezentralen Pool von technischen Ressourcen, wie Netzwerke, Server,
Speicher, Anwendungen und Dienste ermöglicht, die individuell konfiguriert und
durch den Anbieter bereitgestellt werden können.19 Die Bereitstellung erfolgt mit
minimalem Verwaltungsaufwand durch den Cloud-Anbieter. Das Modell besteht aus
fünf essentiellen Charakteristiken (Selbstbedienung bei Bedarf, allgegenwärtiger
Zugriff über das Internet, Einsatz verteilter Ressourcen, hohe Skalierbarkeit,
dynamische Ressourcennutzung), drei Servicemodellen (Software-as-a-Service
[SaaS], Platform-as-a-Service [PaaS], Infrastructure-as-a-Service [IaaS]) und vier
Bereitstellungsmodellen (privat, öffentlich, gemeinschaftlich, hybrid).
Als Cloud-Service oder auch Cloud-Dienst wird eine Leistung bezeichnet, die ein
Cloud-Anbieter einem Cloud-Kunden zur Verfügung stellt, unabhängig vom Serviceund Bereitstellungsmodell.
2.1.2 Zertifizierung, Zertifikat und Zertifizierungskriterium
Eine Zertifizierung wird in der englischsprachigen ISO 17000:2004 definiert als die
Vergabe
einer
formalen
Bescheinigung,
welche
die
Erfüllung
spezifischer
Anforderungen in Bezug auf Produkte, Prozesse, Systeme oder Personen durch einen
Dritten bestätigt.20 Die Zertifizierung stellt gemäß dieser Auffassung nur eine Aktivität
19
Vgl. zu diesem Absatz Mell, Grance (2011), S. 2.
20
Vgl. International Organization for Standardization (2004), S. 2-4. Herangezogen wurden die
Begriffsdefinitionen 2.1, 3.1, 5.1, 5.2 und 5.5.
6
innerhalb des gesamten Zertifizierungsprozesses dar, welcher u. a. auch die Definition
des Prüfumfanges und die Erstellung eines Ergebnisberichtes umfasst.21 Im
deutschsprachigen Raum hingegen wird mit einer Zertifizierung üblicherweise das
gesamte Verfahren bezeichnet, mit dem die Erfüllung und Einhaltung der spezifischen
Anforderungen durch einen unparteiischen Dritten überprüft wird.22 Gemäß dieser
Auffassung wird auch der in dieser Arbeit verwendete Begriff der Zertifizierung
definiert. Die formale Bescheinigung wird auch Zertifikat genannt.23 Durch die Vergabe
des Zertifikates bestätigt der Herausgeber, die Zertifizierungsstelle, die Erfüllung der
dem Zertifikat zugrundeliegenden spezifischen Anforderungen.24 Im weiteren Verlauf
dieser Abhandlung wird eine spezifische Anforderung als Zertifizierungskriterium
bezeichnet.
Die
Menge
der
Zertifizierungskriterien
werden
in
einem
Zertifizierungskriterienkatalog oder kurz Kriterienkatalog zusammengefasst. Das
Verfahren, bei dem die Erfüllung der Zertifizierungskriterien geprüft und bewertet wird,
wird als Audit bzw. Auditierung bezeichnet. Zu unterscheiden sind hierbei je nach Art
der eingesetzten Auditierungsmethode die manuelle Auditierung und die (teil-)
automatisierte, kontinuierliche Auditierung.
Die Zertifizierung stellt eine von mehreren Aktivitäten im Rahmen einer
Konformitätsbewertung dar und trägt zur Signalisierung der Konformität bei.25 Eine
Zertifizierung kann als ein Mechanismus zur Vertrauensbildung angesehen werden, da
über den sogenannten Vertrauenstransfer Vertrauen von einer verlässlichen Partei
(bspw. einem Auditor, Zertifizierungsstelle) auf eine unbekannte Partei (bspw. einen
Cloud-Service) übertragen wird.26
21
Vgl. zu den einzelnen Aktivitäten innerhalb des Zertifizierungsprozesses Gadatsch, Klein,
Münchhausen (2013), S. 13 und Bundesamt für Sicherheit in der Informationstechnik (2014), S. 2527.
22
Vgl. Bruhn (2008), S. 424.
23
Vgl. Sabetta, Bezzi, Kaluvuri (2012), S. 1 und Rannenberg (2000), S. 3.
24
Vgl. Sabetta, Bezzi, Kaluvuri (2012), S. 1.
25
Vgl. zu den Aktivitäten einer Konformitätsbewertung International Organization for Standardization
(2004), S. 2. Begriffsdefinition 2.1.
26
Vgl. Doney, Cannon (1997), S. 37.
7
2.1.3 Kundenanforderungen an Zertifizierungskriterien
Im
Rahmen
dieser
Arbeit
sollen
die
Kundenanforderungen
an
die
Zertifizierungskriterien einer dCZ ermittelt werden. Für den weiteren Verlauf und im
Hinblick auf das Ziel der Arbeit ist es notwendig, die Begriffskombination
Kundenanforderungen an Zertifizierungskriterien zu definieren und ein klares
Verständnis zu schaffen.
Die in dieser Arbeit betrachteten Kunden sind Unternehmen aus der Privatwirtschaft
oder dem öffentlichen Sektor, die bereits einen Cloud-Dienst nutzen oder dies planen.27
Zertifizierungskriterien einer Cloud-Zertifizierung sind einzelne, meist in Frageform
formulierte Forderungen, die sich an vielfältige technische, rechtliche, organisatorische
oder auch personelle Aspekte eines Cloud-Dienstes richten.28 Diese werden im Rahmen
einer Cloud-Zertifizierung auf ihre Einhaltung hin überprüft. Eine Kundenanforderung
kann als eine Erwartung des Kunden aufgefasst werden. Diese Erläuterungen
zusammengenommen
definieren
Zertifizierungskriterien
die
und
beschreiben
Erwartungen,
die
Kundenanforderungen
an
Cloud-Kunden
die
an
Zertifizierungskriterien einer Cloud-Zertifizierung stellen.
Um die Begriffskombination weiter zu konkretisieren, werden die in Tabelle 2-1
dargestellten
Eigenschaften
festgelegt,
die
Kundenanforderungen
an
die
Zertifizierungskriterien einer dCZ charakterisieren. Eigenschaften 1 und 2 ergeben sich
aus der Zielstellung dieser Arbeit. Die 3. Eigenschaft, die besagt, dass die Umsetzung
der Anforderung für Cloud-Kunden einen Mehrwert bieten soll, wird aus der Annahme
abgeleitet, dass Kunden nur Anforderungen stellen, die für sie zu einem Vorteil bzw.
Nutzen führen. Eigenschaft 4 ergibt sich aus den vorhergehenden Ausführungen.29 Die
5. und letzte Eigenschaft resultiert aus dem beschriebenen Praxisproblem dieser Arbeit.
27
Vgl. hierzu Fußnote 18.
28
Vgl. hierzu die Dimension „Assurance“ in der Taxonomie von Schneider u. a. (2014), S. 5003.
29
Vgl. Kapitel 1.1, Absatz 3-5.
8
Nr. Eigenschaft
1
Die Anforderung bezieht sich auf einzelne bzw. auf alle Zertifizierungskriterien.
2
Die Anforderung ist für Cloud-Kunden relevant.
3
Die Umsetzung einer Anforderung soll Cloud-Kunden einen Mehrwert bieten.
4
Die Umsetzung einer Anforderung trägt zur Steigerung des Nutzens und der Akzeptanz
einer dCZ aus Kundensicht bei.
5
Aus der Anforderung können Gestaltungsempfehlungen abgeleitet werden, die bei der
Entwicklung einer dCZ berücksichtigt werden sollen.
Tab. 2-1: Eigenschaften einer Kundenanforderung an ein Zertifizierungskriterium einer dynamischen
Cloud-Zertifizierung
2.2
Zertifizierungen im Cloud-Umfeld
Im IT-Umfeld sind Zertifizierungen keine Neuheit, sondern werden schon seit längerer
Zeit als Instrument zur Vertrauensbildung eingesetzt.30 Aufgrund der essentiellen
Eigenschaften des Cloud-Computing-Modells sind jedoch spezielle, cloud-spezifische
Zertifizierungen erforderlich.31 Um die Grundlagen für die nachfolgenden Kapitel zu
schaffen, wird in diesem Kapitel auf die Zertifizierung von Cloud-Diensten und auf
deren Gründe und Nutzen eingegangen (Kapitel 2.2.1 und 2.2.2). Darüber hinaus wird
ein Einblick in die Herausforderungen bei der Zertifizierung von Cloud-Diensten
gegeben (Kapitel 2.2.3).
2.2.1 Definition: Cloud-Zertifizierung
In Anlehnung an die Ausführungen in Kapitel 2.1.2 wird eine Cloud-Zertifizierung
definiert als der Prozess zur Vergabe eines Cloud-Zertifikates, welches von einer
Zertifizierungsstelle ausgestellt wird und zum Zeitpunkt der Vergabe bestätigt, dass der
zertifizierte Cloud-Dienst die dem Zertifikat zugrundeliegenden Zertifizierungskriterien
erfüllt. Die Überprüfung und Bewertung der Einhaltung der Zertifizierungskriterien
wird von einem akkreditierten, unabhängigen Dritten, dem Auditor, durchgeführt und
als Auditierung bezeichnet.32 Der Auditor richtet sich hierbei nach einem Prüfstandard
und
einem
Zertifizierungsschema,33
welche
von
einer
Zertifizierungsstelle
30
Vgl. Munoz, Mana (2013), S. 103.
31
Vgl. hierzu Kapitel 1.1, Absatz 3 sowie Kapitel 2.2.3.
32
Vgl. International Organization for Standardization (2004), S. 4 und Cimato u. a. (2013), S. 92.
33
Vgl. zur Funktion eines Prüfstandards Voßbein (2006), S. 714.
9
herausgegeben werden. Dass sich Cloud-Kunden auf die durch das Zertifikat
zugesicherten Eigenschaften des zertifizierten Cloud-Services verlassen können, stellt
das Hauptziel einer Cloud-Zertifizierung dar.34
Im Laufe der letzten Jahre wurde eine Reihe von Cloud-Zertifizierungen entwickelt.35
Die Entwicklung dieser Cloud-Zertifizierungen erfolgte unabhängig voneinander, was
dazu führte, dass bereits eine Vielzahl an Cloud-Zertifizierungen existieren, die
überwiegend proprietär sind, auf verschiedenen Standards aufbauen und sich in ihrem
Umfang, den Auditprozessen und ihren zugrundeliegenden Zertifizierungsschemata
unterscheiden.36 Der Großteil der bestehenden Cloud-Zertifizierungen befindet sich
derzeit noch in der Entwicklung und es mangelt in der Praxis an einem weit
verbreiteten, von Kunden- und Anbieterseite anerkannten Zertifizierungsstandard für
Cloud-Dienste.37 Prominente Beispiele für bereits in der Praxis eingesetzte CloudZertifizierung sind die STAR-Zertifizierung der Cloud Security Alliance38 und die
ECSA-Zertifizierung (EuroCloud Star Audit) der EuroCloud Europe.39
2.2.2 Gründe und Nutzen einer Cloud-Zertifizierung
Neben den technischen und ökonomischen Vorteilen40, die Unternehmen beim Einsatz
von Cloud-Computing-Lösungen realisieren können, ist die Nutzung eines CloudDienstes und die Auslagerung von sensiblen Daten und Anwendungen für Unternehmen
mit Unsicherheiten und großen Risiken verbunden, weshalb Unternehmen vor dem
Einsatz von Cloud-Computing-Lösungen zurückschrecken. Zu diesen Risiken zählen
der
Kontrollverlust
über
die
Datenverarbeitung41,
diverse
Sicherheitsrisiken42
(Vertraulichkeit, Integrität und Verfügbarkeit), die mögliche Verletzung der
34
Vgl. zur Verlässlichkeit als Hauptziel der Cloud-Zertifizierung Munoz, Mana (2013), S. 103.
35
Für eine umfangreiche Übersicht zu bestehenden Cloud-Zertifizierungen
https://resilience.enisa.europa.eu/cloud-computing-certification.
36
Vgl. Schneider u. a. (2014), S. 4998.
37
Vgl. Munoz, Mana (2013), S. 104 sowie Schneider, Lansing, Sunyaev (2013), S. 17.
38
https://cloudsecurityalliance.org/star/certification/.
39
https://eurocloud-staraudit.eu/de/zertifizierungen/ecsa-audit.html.
40
Vgl. hierzu die Ausführungen des Kapitels 1.1.
41
Vgl. Hale, Gamble (2013), S. 125, Marston u. a. (2011), S. 181 und Munoz, Mana (2013), S. 103.
42
Vgl. Juels, Oprea (2013), S. 64, Subashini, Kavitha (2011), S. 1, 5-7, Marston u. a. (2011), S. 185
sowie Grobauer, Walloschek, Stöcker (2011), S. 50.
10
Datenschutzgesetze43 und Compliance-Vorgaben sowie die Abhängigkeit vom Provider
und der sogenannte Lock-In-Effekt44. Der Eintritt dieser Risiken kann für ein
Unternehmen weitreichende Folgen haben, die im schlimmsten Fall zu finanziellen
Einbußen (Störungen des eigenen Geschäftsbetriebes, Strafzahlungen) oder sogar zum
Verlust der Reputation und Kunden führen können.45 Aus Kundensicht entstehen
Unsicherheiten insbesondere durch die mangelnde Transparenz der beim CloudAnbieter eingesetzten Sicherheitsmaßnahmen und Abläufe.46 Aufgrund dieser
Unsicherheiten und Risiken erfordert die Nutzung von Cloud-Diensten ein umfassendes
Vertrauen in den Cloud-Anbieter.47 Jedoch ist das derzeitige Cloud-Ökosystem durch
Intransparenz geprägt,48 was die Bildung eines ausreichenden Vertrauensverhältnisses
zum Cloud-Anbieter erschwert.
Möchten Unternehmen (Cloud-Kunden) unter den zuvor beschriebenen Gegebenheiten
dennoch Cloud-Computing-Lösungen einsetzen, damit sie deren Vorteile realisieren
können, haben sie zwei Möglichkeiten, um den Unsicherheiten und Risiken angemessen
entgegenzuwirken und das Vertrauen zum Cloud-Anbieter herzustellen. Die erste
Möglichkeit besteht darin, dass Unternehmen selbst tätig werden und eine eigene
Risikoanalyse und -bewertung durchführen. Die eigenständige Risikoanalyse und
-bewertung ist jedoch nur bei einer ausreichenden Informationslage möglich. Auf
Kundenseite besteht hierbei das Problem, dass die Informationsbeschaffung und
Validierung der Informationen, um jeden in Frage kommenden Cloud-Service einer
umfangreichen Risikoanalyse unterziehen zu können, sehr aufwändig ist und es den
meisten Cloud-Kunden hierzu häufig an ausreichenden Ressourcen mangelt.49 Zudem
besteht die Gefahr, dass der Cloud-Anbieter Informationen vorenthält oder diese
verfälscht. Auf der Anbieterseite führt die Vielzahl der Kundenanfragen zu
zusätzlichem Aufwand. Um diese Problematik zu umgehen, besteht für Unternehmen
die zweite Möglichkeit darin, auf Cloud-Zertifikate zurückzugreifen, da diese die
43
Vgl. Paulus (2011), S. 319 und Kunz, Niehues, Waldmann (2013), S. 521.
44
Vgl. Armbrust u. a. (2010), S. 54-55 und Koehler, Anandasivam, Dan (2010), S. 3.
45
Vgl. Pearson (2013), S. 13.
46
Vgl. Kunz, Niehues, Waldmann (2013), S. 521.
47
Vgl. Windhorst, Sunyaev (2013), S. 412.
48
Vgl. Sunyaev, Schneider (2013), S. 33 und Cimato u. a. (2013), S. 92.
49
Vgl. Kapitel 1.1.
11
notwendige Transparenz zur Bewertung und Reduzierung von Risiken und
Unsicherheiten sowie das Vertrauen in Cloud-Dienste herstellen können.50
So zeigen bisherige Forschungsergebnisse, dass sowohl Cloud-Kunden als auch
-Anbieter einen Nutzen in einer Zertifizierung von Cloud-Diensten sehen. Der größte
Nutzen für Cloud-Kunden liegt darin, dass ihnen eine Cloud-Zertifizierung objektive
Informationen zu einem Cloud-Dienst und den damit verbundenen Risiken bereitstellen
kann,51 die ihnen ansonsten verborgen geblieben wären oder die sie selbst aufwändig
hätten ermitteln müssen. Hierdurch verbessert sich ihre Informationslage und die
Intransparenz sowie Unsicherheiten werden reduziert. Darüber hinaus kann sie durch
die Zusicherung bestimmter Eigenschaften des Cloud-Services Transparenz am Markt
schaffen, Entscheidungsträger bei der Suche und Auswahl geeigneter Cloud-Dienste
unterstützen sowie das Vertrauen in und die Akzeptanz für Cloud-Dienste herstellen,52
denn je mehr Informationen einem Kunden zu einem Cloud-Service zur Verfügung
stehen, desto leichter ist es, diesem Cloud-Anbieter zu vertrauen.53 Ein Zertifikat stiftet
für Kunden jedoch nur dann einen Nutzen, wenn sie sich auf die durch das Zertifikat
zugesicherten Eigenschaften eines Cloud-Dienstes verlassen können. Aus Sicht eines
Cloud-Betreibers können Cloud-Zertifikate zu Werbezwecken eingesetzt werden und zu
Wettbewerbsvorteilen führen, da sie die Kaufentscheidung von Konsumenten positiv
beeinflussen.54 Cloud-Anbieter, welche die Informationssicherheit gewährleisten und
dies insbesondere gegenüber Kunden nachweisen, können ein höheres Vertrauen
genießen.55 Zudem ermöglichen Cloud-Zertifikate die Überprüfung und Verbesserung
der eigenen Systeme und Prozesse.56 Damit Cloud-Anbieter einen ökonomischen
Nutzen in einer Cloud-Zertifizierung sehen und bereit sind, in diese zu investieren, muss
eine Cloud-Zertifizierung weit verbreitet und anerkannt sein sowie von Cloud-Kunden
nachgefragt werden.
50
Vgl. Sunyaev, Schneider (2013), S. 34 und Bernnat u. a. (2012), S. 133.
51
Vgl. Windhorst, Sunyaev (2013), S. 412.
52
Vgl. Schneider, Lansing, Sunyaev (2013), S. 13.
53
Vgl. Windhorst, Sunyaev (2013), S. 412.
54
Vgl. Schneider, Lansing, Sunyaev (2013), S. 14, Bock (2008), S. 611, Schneider, Lins (2015), S. 2 und
Sturm, Lansing, Sunyaev (2014), S. 10.
55
Vgl. Office of the Government Chief Information Officer (2013), S. 26.
56
Vgl. zu diesem und dem nachfolgenden Satz Schneider, Lansing, Sunyaev (2013), S. 14.
12
Der Nutzen und die Effektivität einer Cloud-Zertifizierung sind jedoch an bestimmte
Rahmenbedingungen geknüpft, welche die existierenden Cloud-Zertifizierungen derzeit
nur teilweise erfüllen.57 Dies wird insbesondere daran deutlich, dass sowohl CloudAnbieter als auch -Kunden die derzeitige Relevanz von Cloud-Zertifizierungen zur
Unterstützung von Entscheidungsprozessen als eher gering einschätzen. Das liegt zum
einen am aktuellen Entwicklungsstand des Zertifizierungsmarktes und zum anderen
daran, dass derzeitige Zertifizierungen die Anforderungen des Marktes noch nicht
umfassend abdecken. Diesem Umstand soll mit der Entwicklung einer dCZ Rechnung
getragen werden, indem hierbei die erforderlichen Rahmenbedingungen und
Kundenanforderungen berücksichtigt werden. Einen ersten Beitrag hierzu haben
LANSING, SCHNEIDER und SUNYAEV (2013) in einer empirischen Studie gelegt und
ermittelt, welche Anforderungen aus Praxissicht an eine effektive und nützliche CloudZertifizierung gestellt werden und daraus Gestaltungsempfehlungen abgeleitet.58 Jedoch
bleibt trotz dieses Forschungsbeitrages offen, welche Anforderungen Cloud-Kunden an
die Zertifizierungskriterien stellen, sodass mit dieser Arbeit ein weiterer Beitrag
geleistet werden soll, um eine effektive und nützliche dCZ entwickeln zu können.
2.2.3 Herausforderungen bei der Zertifizierung von Cloud-Diensten
Im Folgenden wird erläutert, warum die Zertifizierung von Cloud-Diensten keine
triviale Aufgabe ist, sondern eine Herausforderung darstellt.
Die Hauptgründe hierfür liegen in den charakteristischen Merkmalen und der
Komplexität des Cloud-Computing-Modells.59 Die charakteristischen Merkmale des
Cloud-Computing-Modells,
wie
Skalierbarkeit,
am
Bedarf
orientierte
Ressourcenallokation, flexible Servicezusammenstellung und rapide technologische
Weiterentwicklung führen zu einer hohen Dynamik des Cloud-Dienstes und zu
komplexen, sich ständig wandelnden Systemstrukturen.60 Die größte Gefahr dieser
Veränderbarkeit ist, dass der zertifizierte Cloud-Service den spezifischen Forderungen
57
Vgl. zu diesem und den anschließenden beiden Sätzen Schneider, Lansing, Sunyaev (2013), S. 13-15,
17.
58
Vgl. zu diesen Gestaltungsempfehlungen Schneider, Lansing, Sunyaev (2013), S. 15-16.
59
Vgl. zu den charakteristischen Merkmalen Kapitel 2.1.1.
60
Vgl. Kunz, Niehues, Waldmann (2013), S. 522 und Spanoudakis, Damiani, Mana (2012), S. 175.
13
eines oder mehrerer Zertifizierungskriterien nicht mehr entspricht bzw. diese verletzt.61
Als Folge ist die Zertifikatsaussage, auf die sich der Cloud-Kunde verlässt, nicht mehr
gültig. Die Eigenschaft der Skalierbarkeit und der am Bedarf orientierten
Ressourcenallokation bedeutet, dass die Software- und Hardware-Ressourcen eines
Cloud-Dienstes meist von vielen verschiedenen Mandanten (gleichzeitig) genutzt
werden und sich die Zuweisung der Ressourcen dynamisch verändert, was die
Komplexität einer Cloud-Zertifizierung erhöht.62 Die flexible Servicezusammenstellung,
bei der Cloud-Dienste und -Infrastrukturen aus einer Kombination mehrerer Dienste
bestehen, die zum Teil von verschiedenen Cloud-Anbietern an verschiedenen
Standorten betrieben werden, die unterschiedlichen nationalen Gesetzgebungen
unterliegen, führt zum einen dazu, dass bei einer Cloud-Zertifizierung mehrere CloudDienste überprüft werden müssen und zum anderen dazu, dass die verschiedenen
gesetzlichen Vorgaben von einer Cloud-Zertifizierung berücksichtigt werden müssen.63
Zudem muss auch die Veränderbarkeit des äußeren Cloud-Umfeldes bei einer CloudZertifizierung berücksichtigt werden, um das Zertifizierungsschema an diese
anzupassen.64 Zum Beispiel müssen neu aufkommende Sicherheitslücken und -risiken,
veränderte Gesetzgebungen und Compliance-Vorgaben von einer Cloud-Zertifizierung
einbezogen und gegebenenfalls bereits zertifizierte Cloud-Dienste nachgeprüft werden.
Neben den charakteristischen Merkmalen wird die Komplexität zusätzlich durch die
Vielzahl verschiedener Service- und Bereitstellungsmodelle erhöht, bei denen es
darüber hinaus vielfältige Kombinationsmöglichkeiten gibt. Durch diese verschiedenen
Modelle variieren die Zuständigkeits- und Verantwortungsbereiche des CloudAnbieters, respektive der Cloud-Kunden, in Abhängigkeit vom jeweiligen Modell.65
Beispielsweise stellt der Cloud-Anbieter eines IaaS die zugrundeliegende Infrastruktur
und Hardware bereit, jedoch liegt die Verantwortung für das Betriebssystem, die
Systemkonfiguration, das Einspielen von Patches, Updates, Upgrades und die
Einrichtung eines effektiven Backupsystems beim Cloud-Kunden. Fehlerhaftes
61
Vgl. zu diesem und dem nachfolgenden Satz Cimato u. a. (2013), S. 93, Rannenberg (1998), S. 68,
sowie Munoz, Mana (2013), S. 103.
62
Vgl. Kunz, Niehues, Waldmann (2013), S. 522.
63
Vgl. Windhorst, Sunyaev (2013), S. 413-414.
64
Vgl. zu diesem Absatz Schneider, Lins (2015), S. 1.
65
Vgl. zu diesem und dem nachfolgenden Satz Hogben, Dekker (2012), S. 22-23.
14
Verhalten des Cloud-Kunden, das eine Cloud-Zertifizierung nicht bzw. nur mit
zusätzlichem
Aufwand
abdecken
kann,
kann
hierbei
zu
schwerwiegenden
Sicherheitsrisiken führen.
Fasst man die genannten Punkte zusammen, so wird deutlich, dass die Zertifizierung
von Cloud-Diensten nicht mit der traditionellen Zertifizierung von IT-Systemen
vergleichbar ist. Daher sind spezifische Cloud-Zertifizierungen erforderlich, welche die
cloud-bezogenen Besonderheiten berücksichtigen und die daraus resultierenden
Herausforderungen angemessen adressieren.
3
Dynamische Cloud-Zertifizierung
Wie die Ausführungen in Kapitel 2.2.3 herausstellen, stellt die Zertifizierung von
Cloud-Diensten
eine
Herausforderung
dar.
Zudem
sind
cloud-spezifische
Zertifizierungen erforderlich, um die beschriebenen Herausforderungen angemessen zu
adressieren.
Die große Schwäche der bereits entwickelten Cloud-Zertifizierungen ist, dass die
Überprüfung der Zertifizierungskriterien in relativ großen Zeitabständen (bspw. alle 1-3
Jahre66) erfolgt, weshalb sie im Kontrast zur dCZ als statisch charakterisiert werden
können. Der große Zeitabstand birgt das Risiko, dass die Einhaltung von
Zertifizierungskriterien zwischen diesen Zeitpunkten nicht mehr gewährleistet ist,
wodurch unter Umständen kritische Sicherheitsrisiken entstehen. Aus Sicht der CloudKunden, für welche die Zuverlässigkeit eines Cloud-Zertifikates und die Sicherheit des
zertifizierten Cloud-Dienstes überaus wichtig sind, ist dieses Risiko allerdings nicht
akzeptabel. Aus dieser Problematik kann gefolgert werden, dass aus Praxissicht ein
großer Bedarf an dCZ besteht, dem mit der Entwicklung einer dCZ Rechnung getragen
werden soll.
3.1
Grundgedanke und Konzept
Die dCZ ist ein relativ neues Forschungsfeld, deren Entwicklung noch in den
Kinderschuhen steckt.67 Der Grundgedanke hinter diesem Konzept ist, die Gültigkeit der
66
Vgl. zu den Prüfintervallen verschiedener Cloud-Zertifikate Schneider, Lansing, Sunyaev (2013), S. 14.
67
Vgl. Windhorst, Sunyaev (2013), S. 412 und Schneider u. a. (2014), S. 4999.
15
Zertifizierungskriterien und des Zertifikates möglichst während des gesamten CloudLebenszyklus dauerhaft aufrecht zu erhalten.68 Um dies zu erreichen, ist es notwendig,
den derzeitigen statischen Zertifizierungsprozess im Hinblick auf die inhärente
Flexibilität und Dynamik der Cloud-Umgebung anzupassen und zu erweitern. Durch
diese Zielsetzung kann die dCZ im Vergleich zu herkömmlichen, statischen CloudZertifizierungen als zuverlässiger angesehen werden. Durch diese Anpassungen stellt
die dCZ eine Weiterentwicklung der statischen Cloud-Zertifizierungen dar.
Um die Gültigkeit aufrecht zu erhalten, ist es erforderlich, die Einhaltung der
Zertifizierungskriterien möglichst kontinuierlich zu überprüfen und zu bewerten. Es
kann in diesem Zusammenhang angenommen werden, dass die Zuverlässigkeit der
Einhaltung eines Zertifizierungskriteriums steigt, je häufiger die Gültigkeit dieses
Kriteriums überprüft wird. Die kontinuierliche Überprüfung und Bewertung der
Einhaltung von Zertifizierungskriterien stellt jedoch einen hohen Aufwand dar und ist
ohne den Einsatz technischer Hilfsmittel nicht effizient möglich. Daher stellen (teil-)
automatisierte Auditierungsmethoden zur kontinuierlichen Überprüfung und Bewertung
sowie das dauerhafte Monitoring des Cloud-Services die zentralen Eckpfeiler der dCZ
dar,69 mit denen die Effizienz und die Qualität des Auditierungsprozesses erhöht werden
können.70 Der Einsatz dieser Methoden kann mehrere Vorteile realisieren. Im Hinblick
auf die Effizienz und Wirtschaftlichkeit einer dCZ können diese Methoden die Arbeit
des Auditors vereinfachen, beschleunigen, zu einem geringerem Bedarf an personellen
Ressourcen führen und schlussendlich die Kosten einer dCZ senken und den ROI einer
Zertifizierung aus Sicht des Cloud-Providers erhöhen. Im Hinblick auf die
Verlässlichkeit wird die dCZ dadurch unterstützt, dass Auditierungen in kürzeren bzw.
fortlaufenden Intervallen ermöglicht werden und die Ergebnisse der Auditierungen
aufgrund der mit der Automatisierung einhergehenden Formalisierung der Methodik
messbar und vergleichbar sind. Diese Methoden können folglich die Qualität der dCZ
steigern und schließlich das Vertrauen in diese erhöhen, indem sie die dCZ effizienter
und zuverlässiger gestalten.
68
Vgl. zu diesem und den nachfolgenden beiden Sätzen Windhorst, Sunyaev (2013), S. 414.
69
Vgl. Windhorst, Sunyaev (2013), S. 416, Schneider, Lansing, Sunyaev (2013), S. 16 und Kunz,
Niehues, Waldmann (2013), S. 522.
70
Vgl. zu diesem Teilsatz und den nachfolgenden drei Sätzen Pinkett (2004), S. 45-46.
16
Allerdings besitzt auch der Einsatz dieser Methoden Grenzen, denn nicht alle
Zertifizierungskriterien können kontinuierlich überwacht und auditiert werden.71 Dies
gilt insbesondere für die Auditierung organisatorischer Abläufe und Maßnahmen zum
Schutz der physischen Infrastruktur, bei denen weiterhin die Präsenz des Auditors und
eine manuelle Auditierung erforderlich sind.72 Darüber hinaus kann für die
kontinuierliche Überprüfung der Zertifizierungskriterien auch eine dauerhafte
Anbindung an die Cloud-Systeme erforderlich sein, was gegebenenfalls bei CloudAnbietern aufgrund von dadurch entstehenden Sicherheitsrisiken auf wenig Akzeptanz
treffen könnte.73 Dessen ungeachtet erhebt eine dCZ den Anspruch, möglichst viele und
insbesondere sicherheitskritische Kriterien kontinuierlich zu prüfen.
3.2
Auditierungsmethoden
Wie in Kapitel 3.1 dargelegt, ist zur kontinuierlichen Auditierung der Einsatz (teil-)
automatisierter
Auditierungsmethoden
sowie
ein
kontinuierliches
Monitoring
unabdingbar. Sie stellen eine Grundvoraussetzung für eine effektive und effiziente dCZ
dar.
Die kontinuierliche Auditierung ist eine spezielle Form einer Auditierung und wird
definiert als eine Methode, die Auditresultate parallel zu oder in kurzer Zeit nach dem
Eintritt bestimmter Ereignisse generiert.74 Auf diese ereignisbasierten Auditresultate
kann ein Auditor reagieren und entsprechende Aktionen einleiten, wie beispielsweise
die Anpassung der Auditierungsergebnisse oder die Kontaktaufnahme zum CloudAnbieter. Durch den Einsatz (teil-)automatisierter Auditierungsmethoden können
bestimmte Zertifizierungskriterien fortlaufend, in kurzen Zeitabständen oder, gemäß der
Definition, ereignisbasiert daraufhin überprüft werden, ob sie vom betrachteten CloudService erfüllt werden.
Das kontinuierliche Monitoring wird definiert als eine technische Methode, die ein
stetiges Bewusstsein über den operativen Systemstatus und insbesondere im Hinblick
71
Vgl. Montesino, Fenz (2011), S. 285 und Kunz, Niehues, Waldmann (2013), S. 522.
72
Vgl. Kunz, Niehues, Waldmann (2013), S. 522.
73
Vgl. Schneider, Lins (2015), S. 2.
74
Vgl. Kogan, Sudit, Vasarhelyi (1999), S. 87, 88.
17
auf die Informationssicherheit und die Verfügbarkeit eines Cloud-Dienstes ermöglicht.75
Für einen Auditor liegt der Nutzen eines kontinuierlichen Monitorings darin, dass er bei
der Durchführung einer Auditierung auf die (historischen) Monitoring-Informationen
zurückgreifen kann, um auf deren Basis die Einhaltung der Zertifizierungskriterien zu
bewerten. Damit sich ein Auditor jedoch auf diese Informationen verlassen kann,
müssen diese authentisch und vollständig sein und vor internen und externen
Manipulationen geschützt werden.
Im Rahmen einer dCZ besteht die Hauptaufgabe der Auditierungsmethoden und des
kontinuierlichen Monitorings darin, ausreichende Nachweise zu generieren, auf deren
Basis die Einhaltung der Zertifizierungskriterien bewertet werden kann. Ob die
Bewertung der generierten Nachweise vollautomatisiert durch die Auditierungsmethode
erfolgen kann oder manuell durch den Auditor erfolgen muss, hängt von der
eingesetzten Methode ab. Eine umfangreiche Übersicht zu den verschiedenen
Auditierungsmethoden, die bei einer dCZ zum Einsatz kommen können, bietet der
Forschungsbeitrag von LINS U. A. (2015).76
3.3
Transparenz als ein Erfolgsfaktor
Die Transparenz ist ein entscheidender Faktor für den Erfolg einer dCZ. So trägt die
Transparenz des Zertifizierungsprozesses zur Glaubwürdigkeit und Akzeptanz einer
Zertifizierung bei.77 Der Zertifizierungsprozess soll ausreichend dokumentiert und
öffentlich zugänglich sein. Im Detail sollen u. a. die grundsätzlichen Regeln und
Schritte einer Zertifizierung, die Bedingungen zur Vergabe und zum Widerruf eines
Zertifikates sowie die Akkreditierungen der Auditoren eingesehen werden können.
Zudem müssen Unklarheiten über die Detailtiefe der Zertifizierung ausgeräumt
werden,78 was wiederum einen transparenten Zertifizierungsprozess erfordert. MUNOZ
und MANA (2013) verlangen in diesem Zusammenhang, dass der Zertifizierungsprozess
so gestaltet sein soll, dass die Zuverlässigkeit der Einhaltung der geprüften Kriterien
nachvollziehbar ist.79 Da PAULUS (2011) erwähnt, dass sich Cloud-Kunden nur auf ein
75
Vgl. National Institute of Standards and Technology (2013), S. F-61 und Dempsey u. a. (2011), S. 1.
76
Vgl. Lins u. a. (2015), S. 5354–5358.
77
Vgl. zu diesem und den nachfolgenden beiden Sätzen Bock (2008), S. 613.
78
Vgl. Schneider, Lansing, Sunyaev (2013), S. 15.
79
Vgl. zu diesem und dem nachfolgenden Satz Munoz, Mana (2013), S. 103.
18
Zertifikat verlassen sollen, wenn sie wissen, was zertifiziert wurde,80 soll nicht nur der
Prozess transparent sein, sondern auch die Zertifizierungsinhalte, zu denen insbesondere
die Zertifizierungskriterien zählen. Dies wird zusätzlich dadurch unterstützt, dass
LANSING, SCHNEIDER, SUNYAEV (2013) in einer Interviewstudie die Unklarheit über die
Zertifizierungsinhalte
und
den
-umfang
als
eine
Schwachstelle
aktueller
Zertifizierungen identifiziert haben,81 was wiederum auf eine fehlende Transparenz
zurückgeführt werden kann. Gemäß LANSING und SUNYAEV (2013) sollen die
Zertifizierungsinhalte aussagekräftig, für den zertifizierten Cloud-Dienst relevant und
vertrauensbildend sein, jedoch lassen die Autoren offen, wodurch dies erreicht werden
kann.82 Weiterhin sollen gemäß GORA (2009) die Ergebnisse einer Zertifizierung und
wie die Auditoren zu diesen gekommen sind für eine ausreichende Aussagekraft des
Zertifikates nachvollziehbar und sogar reproduzierbar sein.83 Folglich werden auch an
die Darstellung und den Informationsgehalt der Ergebnisse einer Zertifizierung hohe
Anforderungen gestellt.
Die vorhergehenden Ausführungen verdeutlichen, dass eine Zertifizierung in
verschiedenen Bereichen transparent sein soll. Dies gilt entsprechend auch für die dCZ.
Die Transparenz soll hierbei insbesondere in Bezug auf den Zertifizierungsprozess, die
Zertifizierungsinhalte und die -ergebnisse hergestellt werden. Sind diese Aspekte
gewährleistet, kann dies dazu beitragen, dass sich Cloud-Kunden von der Qualität, der
Zuverlässigkeit, dem Umfang und der Vertrauenswürdigkeit einer dCZ überzeugen
können. Hierdurch können sie schlussendlich das Vertrauen, welches die Voraussetzung
für die Akzeptanz darstellt,84 in eine dCZ entwickeln. Dass Kunden auf diese Weise
Vertrauen aufbauen können müssen, ist vor allem bei neuen Zertifikaten erforderlich, da
diese nur unter bestimmten Voraussetzungen85 von einer Reputation profitieren können.
Überträgt man diese Ergebnisse auf die zugrundeliegende Thematik der Ausarbeitung,
kann die Gewährleistung einer ausreichenden Transparenz in Bezug auf die
80
Vgl. Paulus (2011), S. 319.
81
Vgl. Schneider, Lansing, Sunyaev (2013), S. 16.
82
Vgl. Lansing, Sunyaev (2013), S. 4.
83
Vgl. zu diesem und dem nachfolgenden Satz Gora (2009), S. 238.
84
Vgl. Hofmann, Schumacher (2014), S. 14.
85
Vgl. Cimato u. a. (2013), S. 93 und Meissner (2008), S. 525.
19
Zertifizierungskriterien und den damit verbundenen Bereichen als eine Kernanforderung
der Cloud-Kunden angesehen werden. Von dieser Kernanforderung können weitere
detailliertere Anforderungen abgeleitet werden, die dazu beitragen, die Transparenz
herzustellen.
3.4
Spezifikation und Prüfberichte
Damit die Transparenz bezüglich der Zertifizierungskriterien hergestellt bzw. gesteigert
werden kann, muss eine dCZ den Cloud-Kunden zwei Informationsquellen bereitstellen.
Die erste Quelle ist der Zertifizierungskriterienkatalog, in dem die Spezifikation86 der
einzelnen Zertifizierungskriterien erfolgt und anhand dessen sich Cloud-Kunden über
die Inhalte einer Zertifizierung informieren können. Als zweite Quelle dienen die
Prüfberichte, in denen die Informationen zusammengefasst werden, die bei der
Überprüfung der Zertifizierungskriterien anfallen bzw. aus dieser resultieren. Anhand
der Prüfberichte sollen sich Cloud-Kunden von der Konformität eines zertifizierten
Cloud-Dienstes überzeugen können. Beide Quellen sollen dazu beitragen, dass CloudKunden die Zertifizierungsergebnisse nachvollziehen können und sich u. a. von der
Zuverlässigkeit, Detailtiefe und Angemessenheit der Zertifizierung überzeugen können.
Infolgedessen konzentriert sich die beabsichtigte Anforderungsermittlung insbesondere
darauf, wie die Transparenz innerhalb der beiden Informationsquellen durch
kundenrelevante Informationen in Bezug auf die Zertifizierungskriterien hergestellt
bzw. gesteigert werden kann.
3.5
Zertifizierungskriterienkatalog
Um im weiteren Verlauf zur Veranschaulichung der identifizierten Anforderungen auf
Zertifizierungskriterien einer dCZ zurückgreifen zu können, wird dieser Arbeit eine
Teilmenge eines Kriterienkataloges zugrunde gelegt, der von SCHNEIDER U. A. (2014)
entwickelt wurde.87 Dieser Kriterienkatalog umfasst 328 Zertifizierungskriterien, gegen
die ein Cloud-Dienst bei seiner Zertifizierung evaluiert werden soll. In einer an
SCHNEIDER U. A. (2014) anknüpfenden Forschungsarbeit wurde von LINS (2014) auf
Basis dieses Kriterienkataloges eine Teilmenge herausgearbeitet, die aus 63 Kriterien
86
Die Spezifikation eines Zertifizierungskriteriums wird definiert als die Gesamtheit aller Informationen,
die im Kriterienkatalog zu einem Zertifizierungskriterium angegeben werden.
87
Vgl. zu diesem und dem folgenden Satz Schneider u. a. (2014), S. 5003.
20
besteht, deren jeweiliger Erfüllungsstatus im Rahmen einer dCZ in relativ kurzen
Zeitintervallen erneut überprüft werden soll.88 Dieser Kriterienkatalog befindet sich in
Anhang A1.
4
Methodik
In diesem Kapitel wird das dieser Arbeit zugrundeliegende methodische Vorgehen zur
Ermittlung der Kundenanforderungen beschrieben. Der Ablauf dieses Vorgehens
gliedert sich in drei aufeinander aufbauende Phasen. In der ersten Phase werden
potentielle Kundenanforderungen auf Basis von cloud-bezogenen Publikationen
ermittelt und in einem Anforderungskatalog verzeichnet. In der zweiten Phase werden
die Ergebnisse der ersten Phase in einem Workshop mit Teilnehmern aus der Forschung
diskutiert. Die Ergebnisse des Workshops werden anschließend genutzt, um den
Anforderungskatalog zu überarbeiten. In der dritten Phase werden Expertenaussagen
herangezogen, um die ermittelten Kundenanforderungen zu validieren und einzuordnen.
Im Folgenden werden die einzelnen Schritte innerhalb dieser einzelnen Phasen
dargestellt.
4.1
Herleitung von Kundenanforderungen aus praxisorientierten CloudPublikationen
Die erste Phase dient der Grundlagenschaffung und hat zum Ziel, Kundenanforderungen
aus
kunden-
und
praxisorientierten
Cloud-Publikationen
zu
ermitteln.
Die
Vorgehensweise zur Herleitung dieser Kundenanforderungen lässt sich in zwei
aufeinander aufbauende Schritte unterteilen: Die Auswahl zielführender CloudPublikationen und die anschließende Herleitung von Kundenanforderungen aus diesen
Cloud-Publikationen.
4.1.1 Vorgehensweise zur Auswahl zielführender Cloud-Publikationen
Die Grundlage zur Auswahl zielführender Cloud-Publikationen stellt eine Literaturliste
dar, die in einer vorhergehenden, noch nicht veröffentlichten Forschungsarbeit im März
2014 systematisch zusammengestellt wurde.89 Diese Literaturliste umfasst eine Reihe
88
Vgl. Lins (2014), S. 6-7.
89
Es sei erwähnt, dass der Autor dieser Arbeit nicht an der Zusammenstellung beteiligt war.
21
von überwiegend cloud-bezogenen Publikationen. Zur Ermittlung dieser Publikationen
haben die Autoren dieser Forschungsarbeit in den Suchmaschinen EBSCOhost, Google
und Google Scholar nach folgendem Suchstring gesucht: ‚Cloud‘ AND (‚best practice‘
OR ‚framework‘ OR ‚guideline‘ OR ‚standard‘). Die jeweiligen Suchergebnisse wurden
in die Literaturliste aufgenommen. Zusätzlich haben die Autoren dieser Liste weitere
Publikationen
hinzugefügt,
auf
die
in
zuvor
ermittelten
wissenschaftlichen
Literaturbeiträgen zum Thema Cloud-Computing verwiesen wurden. Anschließend
wurde von ihnen auf den Webseiten der Herausgeber nach den Primärquellen dieser
Publikationen gesucht und der Link zur Primärquelle der Literaturliste hinzugefügt. In
der Literaturliste wurden der Titel, der Herausgeber und das Erscheinungsjahr zu den
einzelnen Publikationen angegeben. Die resultierende Literaturliste umfasst 77 cloudbezogene Publikationen, die sich vor allem in ihrem thematischen Fokus und ihren
Zielen unterscheiden.
Da die Zusammenstellung dieser Publikationen jedoch nicht vor dem Hintergrund der
Ermittlung von Kundenanforderungen an Zertifizierungskriterien erfolgte, kann
angenommen werden, dass nicht jede Publikation zur Zielerreichung dieser Arbeit
geeignet
ist.
Um
jedoch
zur
Ermittlung
der
Kundenanforderungen
an
Zertifizierungskriterien einer dCZ nur Publikationen zu untersuchen, die für diese
Arbeit zielführend sind, muss daher eine Auswahl getroffen werden. Dieser
Auswahlprozess wird im Folgenden beschrieben.
Aufgrund dessen, dass die systematische Zusammenstellung der Literaturliste zum
Zeitpunkt dieser Ausarbeitung bereits knapp neun Monate zurückliegt, werden die
aktuellen Versionen der Publikationen von den Webseiten der Herausgeber
heruntergeladen. Nachdem die Aktualisierung des Literaturbestandes erfolgt ist, startet
der Auswahlprozess. Der Auswahlprozess besteht aus zwei Schritten. Im ersten Schritt
wird eine Auswahl auf Basis formaler Auswahlkriterien getroffen. Zu diesen formalen
Auswahlkriterien gehören u. a. das Publikationsjahr und die öffentliche Verfügbarkeit
der Publikation. Im anschließenden zweiten Schritt erfolgt eine Auswahl auf der
Grundlage inhaltlicher Auswahlkriterien. Zu diesen zählen beispielsweise die
Zielgruppe der Publikation oder der direkte Bezug zur Cloud-Thematik. Um eine
Bewertung im Hinblick auf die Auswahlkriterien treffen zu können, müssen die
gelisteten Publikationen zunächst attribuiert werden. Hierzu werden die Einleitung, die
22
Zusammenfassung und das Inhaltsverzeichnis der einzelnen Dokumente gelesen. Ist
dies zur Bewertung nicht ausreichend, werden weitere Inhalte herangezogen.
Die getroffene Auswahl an Cloud-Publikationen bildet die theoretische Grundlage zur
Ermittlung der Kundenanforderungen.
4.1.2 Vorgehensweise zur Herleitung von Kundenanforderungen aus den
ausgewählten Cloud-Publikationen
Im zweiten Schritt werden mögliche Kundenanforderungen90 aus diesen ausgewählten
Cloud-Publikationen hergeleitet. Dieser Vorgang wird codiert, um die den
Anforderungen zugrundeliegenden Aussagen und Quellen zuordnen zu können und um
hierdurch die Nachvollziehbarkeit der Herleitung zu gewährleisten.
Zur Herleitung werden die ausgewählten Cloud-Publikationen vollständig gelesen und
auf Aussagen hin untersucht, die mindestens ein Ableitungskriterium erfüllen. Erfüllt
eine Aussage ein oder mehrere Ableitungskriterien, so werden diese Aussage und ihre
Quelle in das Codierungsschema übertragen und das zutreffende Ableitungskriterium
vermerkt. Diese Ableitungskriterien ergeben sich aus den vorherigen Ausführungen und
sind in Tabelle 4-1 aufgelistet.
Nr. Ableitungskriterium
1
Die Aussage bezieht sich unmittelbar auf eine Zertifizierung oder eine Auditierung.
2
Die Aussage bzw. ein Aspekt dieser Aussage lässt sich als Anforderung auf einzelne
oder auf alle Zertifizierungskriterien einer dCZ übertragen, um …

… die Transparenz und Nachvollziehbarkeit einer dCZ zu steigern.

… den Cloud-Kunden von der Zuverlässigkeit einer dCZ zu überzeugen.

… den Cloud-Kunden durch die Umsetzung der Anforderung bei einer dCZ
folgende Mehrwerte zu bieten:
o Die Umsetzung der Anforderung unterstützt Cloud-Kunden bei der
Bewertung, ob ein zertifizierter Cloud-Dienst ihren Anforderungen
gerecht wird.
o Die Umsetzung der Anforderung erhöht die Transparenz des CloudServices bzw. des Cloud-Anbieters.
3
Die Aussage stellt eine Empfehlung an Cloud-Kunden dar, welche Informationen sie zur
90
Da die Kundenanforderungen aus Cloud-Publikationen hergeleitet und nicht unmittelbar von CloudKunden ermittelt werden, wäre es präziser, von möglichen Kundenanforderungen zu sprechen. Um
den Lesefluss jedoch nicht zu stören, wird das Adjektiv möglichen im Folgenden jedoch
weggelassen.
23
Bewertung der Risiken und des Sicherheitsniveaus des Cloud-Dienstes heranziehen
sollen. (Diese Informationen könnten im Rahmen einer dCZ durch Zertifizierungskriterien ermittelt und allen Interessenten des Zertifikates, insbesondere den CloudKunden, bereitgestellt werden.)
4
Die Aussage stellt eine Empfehlung an Cloud-Anbieter dar, welche Informationen sie
Cloud-Kunden bereitstellen sollen. (Diese Informationen könnten im Rahmen einer dCZ
durch Zertifizierungskriterien ermittelt und allen Interessenten des Zertifikates,
insbesondere den Cloud-Kunden, bereitgestellt werden.)
5
Aussagen, welche Cloud-Kunden die Ausführung bestimmter Aktivitäten empfehlen, die
unter Umständen von einer Cloud-Zertifizierung übernommen werden können, um die
Cloud-Kunden zu entlasten.
6
Aussagen, die Cloud-Anbietern die Ausführung bestimmter Aktivitäten empfehlen, die
unter Umständen von einer Cloud-Zertifizierung übernommen werden können, um die
Cloud-Anbieter zu entlasten.
Tab. 4-1: Kriterien zur Ableitung von Kundenanforderungen
Die aus den Cloud-Publikationen hergeleiteten Kundenanforderungen dienen als
Grundlage für die anschließende Durchführung des Workshops.
4.2
Workshop im Forschungsumfeld
In der zweiten Phase wird der bisher erstellte Anforderungskatalog in einem Workshop
mit erfahrenen Forschern aus dem Cloud-Computing-Umfeld diskutiert. Die Diskussion
innerhalb des Workshops wird elektronisch aufgezeichnet.
Das Ziel des Workshops ist, die bisher theoretisch ermittelten Anforderungen im
Hinblick auf praxisrelevante Leitfragen (siehe Tabelle 4-3) zu diskutieren, um die
Ergebnisse für die Überarbeitung der ermittelten Kundenanforderungen verwenden zu
können. Als Methodik wird hierzu der Workshop ausgewählt. Dieser ist geeignet, eine
effiziente, kontrollierte und dynamische Arbeitsumgebung zu erzeugen, in der
Anforderungen schnell ermittelt, priorisiert und abgestimmt werden können.91 Bei der
Auswahl der Teilnehmer wird darauf geachtet, dass deren Forschungsschwerpunkt auf
dem Thema Cloud-Computing liegt und sie ein fundiertes theoretisches aber auch
praktisches Wissen in diesem Themenbereich aufweisen.
Zur Durchführung des Workshops werden die aus den Cloud-Publikationen abgeleiteten
Anforderungen in einem Dokument92 zusammengeführt, welches den Teilnehmern zur
91
Vgl. Gottesdiener (2003), S. 52.
92
Vgl. zu diesem Dokument sowie zu dem im übernächsten Satz genannten Informationsblatt Anhang
A2.
24
Vorbereitung auf den Workshop vorab zugesendet wird. Die einzelnen Anforderungen
werden hierzu in das in Tabelle 4-2 dargestellte Schema übertragen, um den
Teilnehmern die notwendigen Informationen zu den einzelnen Anforderungen zur
Vorbereitung bereitzustellen. Darüber hinaus wird den Wissenschaftlern vorab ein
Informationsblatt bereitgestellt, in dem die Ziele, die Vorgehensweise und die
Leitfragen des Workshops beschrieben werden.
ID:
Anforderungsbezeichnung:
Beschreibung:
Quelle(n):
Tab. 4-2: Schema zur Darstellung einer Anforderung
Um die Moderation zu vereinfachen und die Diskussion innerhalb des Workshops
thematisch einzugrenzen, werden die in Tabelle 4-3 aufgeführten Leitfragen eingesetzt,
die den Teilnehmern zur Orientierung während der Diskussion dienen.
Kategorie
Leitfrage
Kunden- und
Praxisrelevanz
Ist die Anforderung für Kunden in der Praxis relevant?
Bietet die Anforderung Kunden in der Praxis einen Mehrwert?
Verständlichkeit
Sind die Bezeichnungen und Beschreibungen der Anforderung präzise und
prägnant?
Strukturierung
Gibt es Anforderungen, die zusammengefasst oder aufgeteilt werden
sollen?
Umsetzbarkeit
Welche organisatorischen und technischen Voraussetzungen und
Herausforderungen existieren bei der Umsetzung der Anforderung?
Bezug
Bezieht sich die Anforderung auf Zertifizierungskriterien oder auf die
Zertifizierung?
Kann eine Anforderung, die spezifisch für bestimmte
Zertifizierungskriterien gilt, sinnhaft auf andere Zertifizierungskriterien
übertragen werden?
-
Gibt es Anforderungen, aus denen sich weitere Anforderungen ergeben
bzw. sich aus diesen ableiten lassen?
Tab. 4-3: Leitfragen zur Orientierung innerhalb des Workshops
Vor Beginn der eigentlichen Diskussion der Anforderungen werden den Anwesenden
die Thematik und Ziele des Workshops vorgestellt. Zudem wird ihnen das bisherige
Vorgehen zur Ermittlung von Anforderungen erläutert und die Vorgehensweise
innerhalb des Workshops vorgestellt. Im Anschluss daran werden offene Fragen seitens
25
der Anwesenden geklärt, um Verständnisprobleme auszuschließen. Danach werden die
Anforderungen der Reihe nach diskutiert. Jede Anforderung wird vom Moderator
vorgestellt und dann unmittelbar diskutiert. Nach Abschluss des Workshops wird die
elektronische Aufzeichnung transkribiert und manuell ausgewertet. Mit den Ergebnissen
des Workshops werden anschließend die Anforderungen überarbeitet.
4.3
Validierung der Ergebnisse mittels Expertenaussagen
Um die aus den Cloud-Publikationen ermittelten und mit den Ergebnissen des
Workshops überarbeiteten Kundenanforderungen einzuordnen und empirisch zu
validieren, wird auf Aussagen von Experten aus der Praxis zurückgegriffen. Diese
Expertenaussagen stammen aus einem vierstündigen Expertenworkshop93, der im
Rahmen des Projektes Next Generation Certification (NGCert)94 im Dezember 2014
durchgeführt wurde.95 Dieses Projekt verfolgt das Ziel, die Forschung und Entwicklung
dynamischer Zertifizierungen für Cloud-Services voranzutreiben und wird vom
Bundesministerium
für
Bildung
und
Forschung
gefördert.
An
diesem
Expertenworkshop nahmen neben einem Moderator und drei Wissenschaftlern vier
Cloud-Anbieter, drei Cloud-Service-Auditoren und zwei Cloud-Service-Berater teil, die
fundierte Praxiserfahrungen aufweisen. Anhand eines Fragenkataloges wurden die für
die Entwicklung einer dCZ relevanten Bereiche, wie möglicher Umfang einer dCZ,
technische
und
organisatorische
Anforderungen
und
Grenzen
einer
dCZ,
Anwendungsfälle einer dCZ, Wertschöpfungskette einer dCZ sowie Risiken und
Risikostrategien einer dCZ diskutiert.
Die Tabelle 4-1 gibt eine Übersicht über die Teilnehmer und deren Kurzbezeichnung.
Die Kurzbezeichnung wird bei der Zitation der Expertenaussagen in den Kapiteln 5 und
6 verwendet.
93
Zur Unterscheidung von dem in Kapitel 4.2 beschriebenen Workshop wird dieser Workshop im
weiteren Verlauf als Expertenworkshop bezeichnet.
94
http://www.isq.uni-koeln.de/ngcert.html und http://www.ngcert.de/.
95
Es sei erwähnt, dass der Autor dieser Ausarbeitung am Expertenworkshop nicht beteiligt war.
26
Kurzbezeichnung
Bezeichnung innerhalb des Transkriptes
CSA#1
Cloud-Service-Zertifizierer-1
CSA#2
Cloud-Service-Zertifizierer-2
CSA#3
Cloud-Service-Zertifizierer-3
CSP#1
Cloud-Service-Provider-1
CSP#2
Cloud-Service-Provider-2
CSP#3
Cloud-Service-Provider-3
CSP#4
Cloud-Service-Provider-4
CSB#1
Cloud-Service-Berater-1
CSB#2
Cloud-Service-Berater-2
W#1
Wissenschaftler-1
W#2
Wissenschaftler-2
W#3
Wissenschaftler-3
M
Moderator
Tab. 4-1:Übersicht über Teilnehmer des Expertenworkshops
Da die Diskussion und die Aussagen der Teilnehmer elektronisch mitgeschnitten und
anschließend transkribiert wurden, kann das Transkript96 nun in dieser Arbeit zur
Einordnung und Validierung der ermittelten Kundenanforderungen herangezogen
werden. Hierzu wird das Transkript mit Hilfe der Software „NVivo 10“97 codiert und in
einem,
zum
Teil
iterativen
Prozess
qualitativ
ausgewertet.
Ziel
des
Auswertungsprozesses ist, die für die Forschungsfrage und die ermittelten
Kundenanforderungen
relevanten
Inhalte
und
Aspekte
aus
dem
Transkript
herauszuarbeiten, um mit diesen die hergeleiteten Kundenanforderungen bewerten zu
können.
Der Auswertungsprozess gestaltet sich wie folgt. Zur Strukturierung der Inhalte des
Transkriptes wird zunächst ein initiales Codierungsschema erstellt, welches sich an dem
zugrundeliegenden Fragenkatalog des Expertenworkshops orientiert. Im Anschluss
daran werden die Aussagen der Teilnehmer den Themenknoten des initialen
Codierungsschemas thematisch zugeordnet. In dem darauffolgenden iterativen Prozess
wird das Codierungsschema zum einen durch die Bildung weiterer thematischer
Unterknoten und zum anderen durch die Erstellung von Codierungsknoten für jede
96
Das Transkript des Expertenworkshops befindet sich in Anhang A3.
97
Für weitere Informationen vgl. http://www.qsrinternational.com/products_nvivo.aspx.
27
bereits ermittelte Kundenanforderung verfeinert, wobei die Erweiterung des
Codierungsschemas grundsätzlich vor dem Hintergrund der Zielstellung dieser Arbeit
erfolgt. In mehreren Durchläufen werden dabei insbesondere Expertenaussagen
herausgearbeitet, die sich auf Cloud-Kunden oder die ermittelten Kundenanforderungen
beziehen, und diese den jeweiligen Unterknoten zugeordnet.
Das Resultat der beschriebenen Vorgehensweise und des Codierungs- und
Auswertungsprozesses ist der finale Anforderungskatalog, der in Kapitel 6 vorgestellt
wird.
5
Ergebnisse der einzelnen Phasen der Anforderungsermittlung
Wie im vorhergehenden Kapitel zur Methodik beschrieben, gliedert sich das Vorgehen
zur Ermittlung der Kundenanforderungen an die Zertifizierungskriterien einer dCZ in
drei Phasen. In diesem Kapitel werden die Ergebnisse dieser drei Phasen dargelegt.
5.1
Zur
Literaturbasierte Anforderungsermittlung
Vorstellung
der
Ergebnisse
des
Vorgehens
zur
literaturbasierten
Anforderungsermittlung wird in Kapitel 5.1.1 zunächst auf die notwendige Auswahl
zielführender Cloud-Publikationen eingegangen. Im Anschluss daran wird in Kapitel
5.1.2 die Herleitung von Kundenanforderungen aus diesen Publikationen anhand von
ausgewählten Beispielen beschrieben.
5.1.1 Auswahl zielführender Cloud-Publikationen
In den folgenden Ausführungen wird dargelegt, welche Auswahlkriterien zur Auswahl
zielführender
Cloud-Publikationen
konkret
angewendet
werden
und
welche
Publikationen schlussendlich zur Herleitung von Kundenanforderungen untersucht
werden.
Auswahl auf Basis formaler Auswahlkriterien
Die Tabelle 5-1 gibt zunächst eine Übersicht über die formalen Auswahlkriterien. Die
dort gelisteten Auswahlkriterien werden in der angegebenen Reihenfolge auf die
Publikationen angewendet. Das bedeutet, dass jedes nachfolgende Auswahlkriterium
nur noch auf die Publikationen angewendet wird, die nach Anwendung des
vorhergehenden Auswahlkriteriums verbleiben.
28
Nr. /
Reihenfolge
Auswahlkriterium
1
Die Cloud-Publikation ist im Jahr 2011 oder später veröffentlicht worden.
2
Die Cloud-Publikation ist kostenfrei und öffentlich (zum Download) verfügbar.
Eine Registrierung oder Mitgliedschaft ist für den Download nicht erforderlich.
3
Der Eintrag in der Literaturliste verweist auf ein in sich geschlossenes
Dokument im PDF-Format und nicht auf eine HTML-Seite oder Excel-Datei.98
4
Die Entwicklung der Cloud-Publikation ist abgeschlossen. Die Publikation
befindet sich nicht im Entwurfsstadium.
Tab. 5-1: Übersicht zu den formalen Auswahlkriterien und deren Anwendungsreihenfolge
Durch das 1. Auswahlkriterium wird festgelegt, dass nur Cloud-Publikationen
berücksichtigt werden, die im Jahr 2011 oder später veröffentlicht wurden. Hierdurch
soll gewährleistet werden, dass die Publikationen die jüngsten Entwicklungen und
Fortschritte im Themenfeld des Cloud-Computings berücksichtigen und aufnehmen
konnten. Dieses Auswahlkriterium reduziert die Anzahl an Publikationen von 77 auf 55.
Die Anwendung des 2. Auswahlkriteriums auf die verbleibenden 55 Publikationen
verringert die Anzahl auf 44 Publikationen, da elf Publikationen nur nach einer
Registrierung oder durch eine Mitgliedschaft verfügbar sind. Durch das 3. und 4.
Auswahlkriterium wird die Anzahl weiter auf 31 bzw. 30 Publikationen reduziert. Die
Tabelle 5-2 fasst die quantitativen Resultate der Auswahl auf Basis der formalen
Auswahlkriterien nochmals zusammen. Schlussendlich verbleiben 30 Publikationen, die
der folgenden Auswahl auf Basis der inhaltlichen Auswahlkriterien zugrunde gelegt
werden.
98
Bei der Attribuierung der Publikationen der Literaturliste wurde festgestellt, dass sich hinter einigen
Einträgen keine Publikationen verbergen, sondern Webseiten, Verweise auf eigenständige
Zertifizierungsprogramme oder Entwicklungsprojekte auf der Plattform Google Developers.
29
Auswahlkriterien
Anzahl99
Anzahl an Publikationen in der zugrundeliegenden Literaturliste.
77
1. Anzahl verbleibender Publikationen, die im Jahr 2011 oder später veröffentlicht
wurden.
55
2. Anzahl verbleibender Publikationen, die öffentlich verfügbar sind.
44
3. Anzahl verbleibender Publikationen, die als ein in sich geschlossenes PDFDokument verfügbar sind.
31
4. Anzahl verbleibender Publikationen, die sich nicht in der Entwicklung befinden.
30
Tab. 5-2: Quantitative Ergebnisse des Auswahlprozesses auf Basis formaler Auswahlkriterien
Auswahl auf Basis inhaltlicher Auswahlkriterien
Die verbleibenden 30 Publikationen werden in diesem Schritt inhaltlich untersucht und
daraufhin bewertet, ob sie den inhaltlichen Auswahlkriterien entsprechen. Die Tabelle
5-3 gibt eine Übersicht zu den inhaltlichen Auswahlkriterien, die diesem Schritt
zugrunde gelegt werden. Zur Bewertung werden die Einleitung, die Zusammenfassung
und das Inhaltsverzeichnis gelesen. Sofern dies zur Bewertung nicht ausreicht, werden
weitere Inhalte der Publikationen gelesen.
Nr. Auswahlkriterien
5
Zielgruppe: Die Publikation richtet sich insbesondere an Cloud-Kunden.
6
Die Publikation wurde speziell für das Cloud-Computing-Modell entwickelt.
7
Die Publikation behandelt nicht ausschließlich das Thema Datenschutz.
8
Die Publikation richtet sich nicht an Anwendungsentwickler.
9
Die Publikation ist nicht auf ein spezielles Cloud-Bereitstellungsmodell oder
-Servicemodell beschränkt.
10
Die Publikation behandelt nicht das Thema Geschäftsmodelle im Cloud-Computing.
Tab. 5-3: Übersicht zu den inhaltlichen Auswahlkriterien und deren Anwendungsreihenfolge
Die inhaltlichen Auswahlkriterien reduzieren die Publikationen von 30 auf 17 Stück.
Die quantitativen Ergebnisse dieses zweiten Schrittes werden in der Tabelle 5-4
aufgeführt.
99
Gibt die Anzahl der nach Anwendung des jeweiligen Auswahlkriteriums verbleibenden Publikationen
an.
30
Anzahl100
Auswahlkriterien
Anzahl der nach dem ersten Schritt des Auswahlprozesses verbleibenden
Publikationen
30
5. Anzahl verbleibender Publikationen, die sich an die Zielgruppe der CloudKunden richten.
24
6. Anzahl verbleibender Publikationen, die speziell für das Cloud-ComputingModell entwickelt wurden.
22
7. Anzahl verbleibender Publikationen, die nicht ausschließlich das Thema
Datenschutz thematisieren.
20
8. Anzahl verbleibender Publikationen, die sich nicht an Anwendungsentwickler
richten.
19
9. Anzahl verbleibender Publikationen, die nicht auf einzelne Service- oder
Bereitstellungsmodelle beschränkt sind.
18
10. Anzahl verbleibender Publikationen, die nicht das Thema Geschäftsmodelle im
Cloud-Computing thematisieren.
17
Tab. 5-4: Quantitative Ergebnisse des Auswahlprozesses auf Basis der inhaltlichen Auswahlkriterien
Die Liste der zur Untersuchung ausgewählten Cloud-Publikationen wird um fünf CloudPublikationen ergänzt, auf welche in den zuvor ausgewählten Publikationen verwiesen
wird. Diese werden aufgenommen, da sie für die Zielerreichung dieser Arbeit aufgrund
ihrer Inhalte besonders geeignet sind. Dementsprechend werden die Auswahlkriterien
bei diesen fünf Publikationen nicht angewendet.
Schlussendlich werden 22 Cloud-Publikationen ausgewählt, die detailliert auf
Kundenanforderungen an die Zertifizierungskriterien einer dCZ untersucht werden.
Eine Übersicht zu den ausgewählten Publikationen gibt die folgende Tabelle 5-5.101 Die
Codierung, aus der für jede einzelne Publikation hervorgeht, welche Auswahlkriterien
zum Ausschluss führen, befindet sich in Anhang A4.
Nr. ID
Titel
Herausgeber
Jahr
1
1
Sicherheitsempfehlungen für CloudComputing-Anbieter
Bundesamt für Sicherheit in der
Informationstechnik
2012
2
9_1* FedRAMP - Continuous Monitoring Strategy
General Services Administration
2014
3
10
Guidelines on Security and Privacy in Public
Cloud Computing (SP800-144)
National Institute of Standards and
Technology
2011
4
18
Security Guidance for Critical Areas of Focus
Cloud Security Alliance
2011
100
Gibt die Anzahl der nach Anwendung des jeweiligen Auswahlkriteriums verbleibenden Publikationen
an.
101
Cloud-Publikationen, die in der zugrundeliegenden Literaturliste nicht enthalten sind und zusätzlich
hinzugefügt werden, sind innerhalb der Tabelle mit einem „*“ gekennzeichnet.
31
in Cloud Computing
5
28
Guides for Small-to-Mid-Sized Enterprises
(SMEs) in Safe Use of Cloud Computing
ASP-SaaS-Cloud Consortium
2011
6
30
Practical Guide to Cloud-Computing
Cloud Standards Customer Council
2014
7
43
Moving to the Cloud
Cloud-Computing Use Cases
Group
2011
8
47
Sichere Nutzung von Cloud-Anwendungen
Bundesverband IT-Sicherheit e.V.
2012
9
49
Service Measurement Index (SMI)
Carnegie Mellon University
2014
10
61
Cloud Computing Security Considerations
Australian Signals Directorate
2012
11
64
PCI Data Security Standard (PCI DSS) Cloud
Computing Guidelines V2.0
PCI Security Standards Council
2013
12
65
The Notorious Nine: Cloud Computing Top
Threats in 2013
Cloud Security Alliance
2013
13
68
Cloud Computing Synopsis and
Recommendations
National Institute of Standards and
Technology
2012
14
73
Cloud Contracts – What Providers and
Customers should discuss
EuroCloud Austria, u. a.
2012
15
75
Good Practice Guide for securely deploying
Governmental Clouds
European Network and Information 2013
Security Agency
16
76
Eckpunkte für sicheres Cloud Computing –
Bundesverband
Leitfaden für die Auswahl vertrauenswürdiger Informationswirtschaft,
Cloud Service Provider
Telekommunikation und neue
Medien e.V.
2013
17
80*
Cloud Computing - Standards Roadmap (NIST National Institute of Standards and
SP 500-291)
Technology
2013
18
82
Practical Guide to Cloud Service Level
Agreements
Cloud Standards Customer Council
2012
19
83
Practice Guide for Procuring Cloud Services
Office of the Government Chief
Information Officer
2013
20
89*
Sichere Nutzung von Cloud-Diensten
Bundesamt für Sicherheit in der
Informationstechnik
2014
21
94*
Procure Secure – A guide to monitoring of
security service levels in cloud contracts
European Network and Information 2012
Security Agency
22
94_1 Cloud Computing Information Assurance
*
Framework
European Network and Information 2009
Security Agency
Tab. 5-5: Übersicht der ausgewählten Cloud-Frameworks
Im Folgenden wird kurz auf die Inhalte und Themen der ausgewählten CloudPublikationen eingegangen. Die 22 Publikationen besitzen aufgrund des 5. und 6.
Auswahlkriteriums die Gemeinsamkeit, dass sie sich an Cloud-Kunden richten und
einen direkten Bezug zur Cloud-Thematik aufweisen. Jedoch unterscheiden sie sich in
ihren Inhalten und Zielen, die sie verfolgen. Die Publikationen behandeln diverse cloudbezogene Themenbereiche wie verschiedene Sicherheitsaspekte, den Datenschutz, die
Compliance, die Portabilität und Interoperabilität sowie die Vertragsgestaltung
32
zwischen Cloud-Anbietern und -Kunden und konzentrieren sich hierbei vor allem auf
die damit verbundenen Probleme und Risiken aus Kundensicht. Der Detailgrad, mit
dem die Publikationen auf diese Themenbereiche eingehen, variiert. Beispielsweise
reicht die Bandbreite im Bereich der Sicherheitsrisiken von einer reinen Übersicht zu
verschiedenen Sicherheitsrisiken bis hin zu einer detaillierten Beschreibung dieser
Risiken
und
der
Darstellung
der
entsprechenden
Implikationen
für
das
Risikomanagement der Cloud-Kunden. Ein Großteil der Cloud-Publikationen spricht
konkrete Handlungsempfehlungen aus, die Cloud-Kunden in den verschiedenen Phasen
einer
Cloud-Adoption
(Suche,
Auswahl,
Implementierung
und
Beendigung)
berücksichtigen und umsetzen sollen. Die Cloud-Publikationen verfolgen primär das
Ziel, Cloud-Kunden bei der Risikobewertung und Einschätzung des Sicherheitsniveaus
eines Cloud-Anbieters bzw. dessen Cloud-Services zu unterstützen.
Warum
die
ausgewählten
Cloud-Publikationen
zur
Ermittlung
von
Kundenanforderungen an die Zertifizierungskriterien einer dCZ zielführend sind und
untersucht werden, wird im Folgenden dargestellt. Die ausgewählten CloudPublikationen entstammen nicht aus dem theoriegeprägten Bereich der Forschung,
sondern wurden von Branchen- und Interessenverbänden oder nationalen und
internationalen Behörden herausgegeben, die sich an der Praxis orientieren.102 Daher
weisen sie einen engeren Bezug zur Praxis auf, was sich insbesondere dadurch äußert,
dass sie Cloud-Kunden sehr konkrete und praktisch umsetzbare Empfehlungen und
Handlungsanweisungen geben. Genau an diesen vielfältigen praxisbezogenen
Empfehlungen
und
Handlungsanweisungen
setzt
die
Ermittlung
der
Kundenanforderungen an. Dies hat folgenden Grund: Würden Teile dieser
Empfehlungen von einer dCZ abgedeckt und erfüllt, so müssten Cloud-Kunden diese
selbst nicht mehr berücksichtigen, sondern könnten stattdessen auf die dCZ und die
Informationen, die sie zum zertifizierten Cloud-Dienst bereitstellt, zurückgreifen. Im
Rahmen dieser Arbeit wird der Fokus darauf gelegt, welche dieser Empfehlungen auf
die Zertifizierungskriterien einer dCZ übertragen werden können.
102
Die einzige Ausnahme stellt Cloud-Publikation 49 dar, welche von der Carnegie Mellon University
herausgegeben wurde.
33
5.1.2 Untersuchung der ausgewählten Cloud-Publikationen
Zur
Ermittlung der
Kundenanforderungen
werden
die ausgewählten
Cloud-
Publikationen vollständig gelesen und auf Aussagen hin untersucht, bei denen ein oder
mehrere der bereits angeführten Ableitungskriterien103 zutreffen.104 Im Anschluss daran
wird überprüft, inwiefern sich diese Aussagen in Form von Kundenanforderungen auf
die Zertifizierungskriterien einer dCZ übertragen lassen.
Aufgrund des eingeschränkten Seitenumfangs dieser Arbeit kann die Herleitung der
Kundenanforderungen an dieser Stelle nicht für alle identifizierten Anforderungen
beschrieben werden. Um das Vorgehen dennoch zu verdeutlichen, soll der Einsatz der
Ableitungskriterien und die Herleitung der Kundenanforderungen im Folgenden anhand
von vier repräsentativen Anforderungen (A6, A82a, A82b und A8b) dargestellt werden.
Das vollständige Codierungsschema, aus dem hervorgeht, welche Ableitungskriterien
die
einzelnen
Aussagen
erfüllen
und
aus
welchen
Aussagen
welche
Kundenanforderungen abgeleitet werden, befindet sich in Anhang A5.
Anforderung A6105: Angabe von Messgrößen und Messwerten
Mehrere Cloud-Publikationen enthalten Aussagen, die empfehlen, dass der CloudAnbieter dem Cloud-Kunden aus verschiedenen Gründen quantitative Angaben
bereitstellen soll bzw. der Cloud-Kunde diese vom Cloud-Anbieter ermitteln soll. So
wird beispielsweise in einer Publikation gefordert, dass sich der Cloud-Kunde über die
Wiederherstellungszeit nach einem Störfall oder über die Aufbewahrungszeit von
Protokolldaten beim Cloud-Anbieter informieren soll.106 In der gleichen Publikation
wird im Zusammenhang mit der möglichen Vergleichbarkeit verschiedener CloudDienste gefordert, dass quantitative Messwerte bereitgestellt werden sollen, um einen
fundierteren Vergleich zu ermöglichen.107 Bei beiden Forderungen treffen die
Ableitungskriterien 3 und 4 zu. Abstrahiert man von diesen Empfehlungen und
überträgt diese auf die Zertifizierungskriterien einer dCZ, so kann daraus Anforderung
103
Vgl. zu den Ableitungskriterien Kapitel 4.1.2.
104
Vgl. zu diesem Absatz Kapitel 4.1.2.
105
Vgl. für weitere Informationen zu Anforderung A6 Kapitel 6.2.2.
106
Vgl. zur Wiederherstellungszeit Catteddu, Hogben (2009), S. 20 und zu der Aufbewahrungszeit
Catteddu, Hogben (2009), S. 13, 21.
107
Vgl. Catteddu, Hogben (2009), S. 6, 21.
34
A6 abgeleitet werden: „Im Prüfbericht eines Zertifizierungskriteriums sollen Messwerte,
Messgrößen und/oder weitere quantitative Informationen angegeben werden, sofern
dies für dieses Zertifizierungskriterium möglich und sinnvoll ist.“
Anhand von zwei Beispielen wird die Notwendigkeit von quantitativen Angaben
nochmals verdeutlicht. Hierzu werden zwei Zertifizierungskriterien des von SCHNEIDER
U. A.
(2014)
erstellten
Kriterienkataloges
herangezogen.108
So
fordert
das
Zertifizierungskriterium ZKL-066, dass „alle Rollen und deren Rechte im Rahmen des
Zugriffsrechtemanagements regelmäßig überprüft“ werden, jedoch wird nicht definiert,
was unter „regelmäßig“ zu verstehen ist. Um den Informationsgehalt der
Zertifizierungsergebnisse für einen Cloud-Kunden zu erhöhen, soll daher nicht nur
angegeben werden, dass ein Cloud-Service dieses Kriterium erfüllt, sondern auch, in
welchen regelmäßigen Zeitabständen der Cloud-Anbieter die Rollen und deren Rechte
überprüft. Zertifizierungskriterium ZKL-077 verlangt, dass „die betroffenen Kunden
rechtzeitig über entsprechende Sicherheitslücken, -brüche oder -vorfälle informiert“
werden. In diesem Fall soll neben dem Erfüllungsstatus des Zertifizierungskriteriums
auch angegeben werden, in welchem Zeitabstand betroffene Kunden informiert werden.
Anforderungen A82a und A82b109: Angabe des Prüfzeitpunktes und der
auditierenden Organisation
In einer Cloud-Publikation wird u. a. gefordert, dass in der Beschreibung eines
Zertifizierungskriteriums angegeben werden soll, wann die letzte Überprüfung dieses
Zertifizierungskriteriums stattfand und wer diese Überprüfung durchführte.110 Da es sich
hierbei um eine Forderung handelt, die sich unmittelbar auf eine Zertifizierung bezieht,
trifft Auswahlkriterium 1 zu. Aufgrund einer Aussage in einer weiteren CloudPublikation („[…] which reputable third party has performed audits and other
vulnerability assessments?“111) kann das Wer in der zuvor identifizierten Forderung
dahingehend konkretisiert werden, dass explizit die auditierende Organisation
offengelegt
werden
soll,
um
durch
die
mögliche
Reputation
dieser
die
Vertrauenswürdigkeit der Zertifizierung gegenüber Cloud-Kunden signalisieren zu
108
Vgl. zu diesem Zertifizierungskriterienkatalog Kapitel 3.5.
109
Vgl. für weitere Informationen zu den Anforderungen A82a und A82b Kapitel 6.2.2.
110
Vgl. General Services Administration (2014), S. 27-28.
111
Vgl. Australian Signals Directorate (2012), S. 14.
35
können. Da durch die Offenlegung der auditierenden Organisation die Transparenz der
Zertifizierung gesteigert wird, trifft Auswahlkriterium 2 zu. Aus diesen Forderungen
werden
folglich
die
Anforderungen
A82a
(„Im
Prüfbericht
eines
Zertifizierungskriteriums soll der Zeitpunkt der letzten Überprüfung angegeben
werden.“) sowie A82b („Im Prüfbericht eines Zertifizierungskriteriums soll die für die
Auditierung des Zertifizierungskriteriums verantwortliche Organisation angegeben
werden.“) gebildet.
Anforderung A8b112: Angabe des Prüfintervalls
Die Anforderung A8b wird aus Aussagen abgeleitet, bei denen die Auswahlkriterien 2,
3 und 4 zutreffen. So verlangt eine Cloud-Publikation, dass Cloud-Kunden ermitteln
sollen, ob und wie oft der Cloud-Anbieter Penetrationstests und Tests auf
Sicherheitslücken
durchführt.113
Eine
weitere
Publikation
fordert
in
diesem
Zusammenhang, dass der Cloud-Anbieter diese Penetrationstests jährlich oder nach
signifikanten Veränderungen ausführen soll.114 Fasst man diese beiden Forderungen
zusammen, abstrahiert von diesen und überträgt diese auf die Zertifizierungskriterien, so
ergibt sich hieraus die Kundenanforderung A8b: „Bei der Spezifikation eines
Zertifizierungskriteriums soll angegeben werden, in welchem Prüfintervall die
Einhaltung des Zertifizierungskriteriums geprüft wird.“.
Auf diese Art und Weise konnten schlussendlich 62 Kundenanforderungen an die
Zertifizierungskriterien einer dCZ aus den ausgewählten Cloud-Publikationen ermittelt
und als Grundlage für den anschließenden Workshop im Forschungsumfeld verwendet
werden.
5.2
Workshop im Forschungsumfeld
In diesem Kapitel wird nun dargelegt, zu welchen Ergebnissen der Workshop im
Forschungsumfeld führte und wie diese zur Überarbeitung der Anforderungen
herangezogen werden.
112
Vgl. für weitere Informationen zur Anforderung A8b Kapitel 6.1.
113
Vgl. Catteddu, Hogben (2009), S. 21.
114
Vgl. General Services Administration (2014), S. 25.
36
Der Workshop wurde im Januar 2015 durchgeführt. An diesem zweistündigen
Workshop
haben
vier
erfahrene
Wissenschaftler
teilgenommen,
deren
Forschungsschwerpunkte auf dem Themenkomplex des Cloud-Computings liegen. Die
Tabelle 5-1 gibt einen Überblick über die Teilnehmer und deren Rolle und ordnet diesen
jeweils eine Teilnehmer-ID zu, die bei der Zitation von Aussagen in Kapitel 6
verwendet wird.
Ziel des Workshops war, die aus den Cloud-Publikationen theoretisch hergeleiteten
Kundenanforderungen115 im Hinblick auf ihre Praxisrelevanz und Umsetzbarkeit zu
diskutieren. Die Grundlage hierfür war ein Anforderungskatalog, welcher die 62 aus
den Cloud-Frameworks ermittelten Anforderungen enthält.
Teilnehmer-ID
Rolle
TN#1
Wissenschaftler
TN#2
Wissenschaftler
TN#3
Wissenschaftler
TN#4
Wissenschaftler
TN#5
Moderator
Tab. 5-1: Zuordnung von Teilnehmer zu Teilnehmer-ID
Die Diskussion innerhalb des Workshops wurde elektronisch aufgezeichnet,
transkribiert und manuell ausgewertet.116 Bei der Auswertung wurde wie folgt
vorgegangen. Da die Anforderungen der Reihe nach diskutiert wurden, konnten die
Aussagen der Teilnehmer den Anforderungen direkt zugeordnet werden. Diese
Aussagen wurden daraufhin untersucht, ob sie für oder gegen eine Anforderung
sprechen und welche Gründe jeweils genannt wurden. Wurde sich mehrheitlich gegen
eine Anforderung ausgesprochen, so wurde diese gestrichen. Deuteten Aussagen darauf
hin, dass Anforderungen zusammengefasst bzw. aufgeteilt werden sollen und ergab sich
hierzu ein Konsens unter den Teilnehmern, so wurden die betroffenen Anforderungen
zusammengefasst bzw. aufgeteilt. Auf Basis der Ergebnisse des Workshops wurden
darüber hinaus auch die Formulierungen mehrerer Anforderungen überarbeitet, um
diese zu präzisieren.
115
Zur Steigerung des Leseflusses werden Kundenanforderungen im weiteren Verlauf dieses Kapitels nur
noch als Anforderungen bezeichnet.
116
Das Transkript dieses Workshops befindet sich in Anhang A6.
37
Der Workshop führte dazu, dass Anforderungen aus verschiedenen Gründen aufgeteilt,
zusammengefasst oder auch vollständig gestrichen wurden. Im Folgenden wird daher
auf die Gründe für eine Aufteilung, Zusammenfassung oder Streichung von
Anforderungen eingegangen. Im Anschluss daran werden die quantitativen Ergebnisse
der Auswertung des Workshops nochmals kurz zusammengefasst dargelegt.
Gründe für die Streichung von Anforderungen
Es gibt mehrere Gründe, die zu einer Streichung von Anforderungen geführt haben. Der
Hauptgrund hierfür war, dass sich die jeweiligen Anforderungen nicht an
Zertifizierungskriterien richteten, sondern an die gesamte Zertifizierung, und sich diese
auch nicht auf Zertifizierungskriterien übertragen ließen. Ein weiterer Grund für eine
Streichung war, dass die Umsetzung der jeweiligen Anforderung von den Teilnehmern
als zu aufwändig angesehen wurde und folglich vor dem Hintergrund eines
angemessenen Kosten- und Nutzenverhältnisses einer dCZ nicht umsetzbar wäre. Bei
zwei der 62 Anforderungen hat sich innerhalb der Diskussion herausgestellt, dass diese
keine Anforderungen an Zertifizierungskriterien darstellen, sondern funktionale
Anforderungen an einen Cloud-Dienst repräsentieren, sodass auch diese gestrichen
wurden. Schlussendlich führten die genannten Gründe dazu, dass von den
ursprünglichen 62 Anforderungen 37 gestrichen wurden.
Gründe für die Aufteilung und Zusammenfassung von Anforderungen
Die Entscheidung, ob eine Anforderung aufgeteilt werden kann und soll, wurde daran
festgemacht, ob die Umsetzung der aus der Aufteilung resultierenden Anforderungen
unabhängig voneinander erfolgen kann und dennoch der Mehrwert der ursprünglichen
Anforderung für Cloud-Kunden erhalten bleibt. Die Auswertung des Workshops hat
ergeben, dass 7 Anforderungen in weitere 7 Anforderungen aufgeteilt werden konnten.
Zusammengefasst wurden Anforderungen, wenn innerhalb des Workshops festgestellt
wurde, dass deren Forderung und Intention schon durch eine andere, bereits diskutierte
Anforderung abgebildet wurden. In diesem Zusammenhang hat der Workshop ergeben,
dass 10 Anforderungen mit ähnlichen Anforderungen zusammengefasst werden
konnten.
Die Tabelle 5-6 fasst die quantitativen Ergebnisse der Streichung, Aufteilung und
Zusammenfassung nochmals zusammen.
38
Anzahl an…
Anzahl
… Anforderungen, die im Workshop diskutiert wurden:
62
… Anforderungen, die gestrichen wurden:
(-) 37
… Anforderungen, die aus einer Aufteilung resultieren:
7
… Anforderungen, die mit ähnlichen Anforderungen zusammengefasst wurden:
… Anforderungen, die nach der Einarbeitung der Ergebnisse des Workshops im
Anforderungskatalog verblieben:
(-) 10
22
Tab. 5-6: Quantitative Ergebnisse der Überarbeitung des Anforderungskataloges
Nachdem der Anforderungskatalog mit den Ergebnissen des Workshops überarbeitet
wurde, verblieben schlussendlich 22 Anforderungen, die in Kapitel 6 ausführlich
vorgestellt werden. Von diesen 22 Anforderungen beziehen sich 16 Anforderungen auf
den Prüfbericht eines Zertifizierungskriteriums und 6 auf die Spezifikation eines
Zertifizierungskriteriums.
Anpassung des Codierungsschemas
Aufgrund der beschriebenen strukturellen und inhaltlichen Veränderungen der
Anforderungen musste das Codierungsschema im Nachgang an den Workshop
überprüft sowie angepasst werden, wobei dies nur für Anforderungen erfolgte, die nicht
gestrichen wurden. Zum einen musste bei umformulierten Anforderungen geprüft
werden, ob sich die codierten Aussagen noch auf diese Anforderungen beziehen. Zum
anderen wurde bei zusammengefassten Anforderungen geprüft, ob sich die codierten
Aussagen auch auf die daraus resultierende Anforderung übertragen lassen. Die
Anforderungen innerhalb des Codierungsschemas wurden darüber hinaus um Verweise
auf Aussagen der Workshopteilnehmer ergänzt.117 Aufgrund des eingeschränkten
Seitenumfangs dieser Arbeit befinden sich die detaillierten Ergebnisse der Auswertung,
aus denen hervorgeht, welche Anforderungen aufgeteilt, zusammenfasst oder gestrichen
wurden, in Anhang A5.
5.3
Auswertung des Expertenworkshops
Die Auswertung des Expertenworkshops hatte zum Ziel, aus dem dazugehörigen
Transkript
Expertenaussagen
und
Zusammenhänge
herauszuarbeiten,
die
zur
Einordnung und Validierung der aus den Cloud-Publikationen ermittelten und mit den
117
Diese Verweise wurden innerhalb des Codierungsschemas mit einem „T“, gefolgt von der
Identifikationsnummer der Aussage innerhalb des Transkriptes gekennzeichnet.
39
Ergebnissen des Workshops überarbeiteten Kundenanforderungen herangezogen
werden können. Zu welchen Ergebnissen die Auswertung führte, wird im Folgenden
beschrieben.
Die Auswertung des Transkriptes hat ergeben, dass keine Expertenaussagen identifiziert
werden konnten, die die einzelnen Kundenanforderungen unmittelbar validieren.
Hierfür gibt es drei Gründe. Der Hauptgrund liegt darin, dass die ermittelten
Kundenanforderungen nicht die Grundlage des Expertenworkshops waren und somit
nicht zielgerichtet thematisiert wurden. Ein weiterer Grund ist, dass die inhaltlichen
Themen des Expertenworkshops weniger aus der Kundenperspektive betrachtet wurden
als vielmehr aus den Sichtweisen der Cloud-Anbieter und -Auditoren. Zuletzt
erschwerte auch der Unterschied in den Abstraktionsgraden, mit denen die Themen
innerhalb des Expertenworkshops diskutiert wurden und die die ermittelten
Kundenanforderungen
aufweisen,
die
unmittelbare
Validierung
einzelner
Kundenanforderungen. So wurden die Themen innerhalb des Expertenworkshops auf
einem hohen Abstraktionsgrad diskutiert, wohingegen sich die in dieser Arbeit
identifizierten Kundenanforderungen auf einer konkreteren Abstraktionsebene befinden.
Dennoch konnten aus dem Transkript Expertenaussagen herausgearbeitet werden, die
sich
zur
Validierung
der
Kundenanforderungen
auf
einer
übergeordneten
Abstraktionsebene und nicht auf der Ebene der einzelnen Kundenanforderungen
verwenden lassen. So thematisierten die Experten beispielsweise den in Kapitel 3.3
beschriebenen Bedarf an Transparenz und Nachvollziehbarkeit, wie im weiteren Verlauf
dieses Kapitels dargelegt wird. Zuvor sei noch erwähnt, dass aus dem Transkript
darüber hinaus wertvolle Aussagen und Standpunkte herausgearbeitet wurden, die
Teilaspekte der ermittelten Kundenanforderungen betreffen und zu diesen die Experten
wichtige
Informationen liefern. Diese
Informationen werden
aufgrund ihres
unmittelbaren Bezugs zu einzelnen Kundenanforderungen direkt in die Beschreibung
der Anforderungen in Kapitel 6 eingearbeitet, sodass auf diese im weiteren Verlauf
dieses Kapitels nicht weiter eingegangen wird.
Transparenz und Nachvollziehbarkeit
Wie in Kapitel 3.3 dargelegt wird, stellt die Transparenz eine Kernanforderung der
Cloud-Kunden an eine dCZ und deren Zertifizierungskriterien dar. Gleichermaßen
heben auch mehrere Teilnehmer im Expertenworkshop den grundsätzlichen Mangel
40
bzw. Bedarf an Transparenz und Nachvollziehbarkeit in Bezug auf Cloud-Dienste und
Cloud-Zertifizierungen hervor.
So berichtet ein Cloud-Anbieter bezüglich der Transparenz eines Cloud-Dienstes aus
seiner Praxiserfahrung, dass seine Cloud-Kunden häufig bemängeln, dass seine
Leistungen intransparent und nicht nachvollziehbar seien: „[…] diese Fragen: ‚Wie
können wir das nachvollziehen?‘ hören wir von jedem zweiten Kunden. […] Es kommt
immer wieder die Diskussion: ‚Das ist ja intransparent, was sie da machen.‘ […] Aber
das haben wir relativ oft diese Diskussion. Wie können wir das denn nachweisen. […]“
(CSP#3). Aufgrund dessen kann vermutet werden, dass die Transparenz und
Nachvollziehbarkeit der Leistungen des Cloud-Anbieters und -Dienstes für CloudKunden auch aus Praxissicht einen hohen Stellenwert besitzt. In Bezug auf die
Transparenz einer Cloud-Zertifizierungen hebt ein Cloud-Anbieter den Mangel hervor,
dass bei derzeitigen Cloud-Zertifizierungen keine ausreichende Transparenz gegeben
sei, diese jedoch, ohne weitere Gründe zu nennen, gegenüber Cloud-Kunden
gewährleistet sein soll.118 Zur Begründung gibt ein Cloud-Service-Berater an, dass eine
dCZ transparent gestaltet sein soll, um hierdurch das Vertrauen der Cloud-Kunden
gewinnen zu können.119 Dass eine dCZ auch grundsätzlich transparent sein soll, um
Cloud-Kunden
dadurch
die
Nachvollziehbarkeit
und
Nachprüfbarkeit
der
Zertifikatsaussagen zu ermöglichen, wird durch die folgenden Aussagen unterstützt:
„Aber kann nicht das Ziel eines Zertifikates auch sein, dass man eine gewisse
Transparenz darstellen muss, die man dann Kunden vorlegt. […]“ (CSP#4). „Sehe ich
als ganz wichtigen Punkt. […] Weil es kann nicht sein, dass es nur eine Blackbox im
Hintergrund ist und einfach nur den internen zur Verfügung steht. Damit ist ja gar keine
Aussage da, [die] nach Außen hingetragen worden. Es muss prüfbar sein. Der letzte
Prüfpunkt ist der Kunde selber am Ende.“ (M).
Vor
dem
Hintergrund
der
Transparenzthematik
ergeben
sich
aus
dem
Expertenworkshop auch Einblicke, in welchen konkreten Bereichen einer dCZ für
Transparenz gesorgt werden soll. So fordern zwei Cloud-Anbieter, dass eine dCZ den
System- und Sicherheitsstatus, mögliche Risiken sowie die operativen Prozesse und
Sicherheitseigenschaften eines Cloud-Anbieters (jederzeit) darstellen und gegenüber
118
Vgl. E1503-E1509, S. 38.
119
Vgl. E862-E864, S. 22.
41
Cloud-Kunden nachweisen können soll.120 Dass die erforderlichen Nachweise durch
eine dCZ erbracht werden können, wird von einem Cloud-Anbieter auch als
Voraussetzung dafür angesehen, dass er sich überhaupt zertifizieren lässt.121 Ein weiterer
Bereich, den eine dCZ durch eine ausreichende Transparenz unterstützen soll und der
von einem Teilnehmer dadurch begründet wird, dass bei Cloud-Kunden diesbezüglich
Unsicherheiten bestehen, ist die Rechtskonformität der Cloud-Nutzung, wobei
insbesondere
die
Unsicherheiten
bei
der
rechtskonformen
Datenverarbeitung
hervorgehoben werden:122 „[…] was wir mitbekommen am Markt, dass der Kunde sagt,
ich weiß gar nicht, ob ich meine Daten bei euch verarbeiten lassen darf. Weil ich weiß
nicht genau, was damit passiert. Und diese Transparenz zu schaffen, ich glaube, das ist
eine Herausforderung, die man im Cloud Business hat und das sollte mit solchen
Zertifizierungen irgendwo abgefangen werden.“ (CSP#4). Auch wird von einem CloudService-Berater in Bezug auf die Zertifizierungskriterien der Bedarf an einer
ausreichenden Transparenz hervorgehoben und damit begründet, dass die Anwendung
der Zertifizierungskriterien für Anwender häufig unklar ist: „Das sind Kriterien
irgendwo, ja, wer sie wie eigentlich anwendet ist völlig diffus, ist völlig unklar
eigentlich für einen Anwender und ich guck immer sehr stark aus dieser Anwendersicht
eigentlich. Also wer tut was oder wer hat was von diesem Zertifikat. Wir wollen ja
eigentlich Transparenz erzeugen. Das ist ein ganz wichtiger Aspekt von solchen Dingen
denke ich. Wir wollen erzeugen ein gewisses Vertrauen […]“ (CSB#2). Zudem wird
angemerkt, dass eine dCZ bei der Darstellung von Lücken der Zertifizierung sowie in
Bezug auf die Fehlerbehebung im Rahmen des Störungs-Managements des CloudAnbieters transparent sein soll.123
Deutlich wird auch, dass bei der Entwicklung einer dCZ und im Hinblick auf die
notwendige Transparenz die Informationsbedürfnisse der Cloud-Kunden berücksichtigt
werden sollen, wie auch die folgenden Aussagen darlegen:124 „In so einer Zertifizierung
ist es eigentlich auch wichtig: Was will der Kunde eigentlich wissen?“ (CSB#1). „Was
120
Vgl. E9-E12, S. 2, E1080-E1086, S. 28 sowie E103-E108, S. 4.
121
Vgl. E506-E511, S. 14.
122
Vgl. hierzu auch E1692-E1695, S. 43.
123
Vgl. zur Transparenz bei Lücken innerhalb einer dCZ E1325-E1331, S. 34 und zur fehlenden
Nachprüfbarkeit und Nachvollziehbarkeit des Fehler- und Störungsmanagements E927-E928, S. 24.
124
Vgl. E2213-E2216, S. 56, E15-E16, S. 2 und E1933-E1934, S. 49.
42
können wir tatsächlich messen und was davon will der Kunde tatsächlich sehen?“
(CSP#3). „Aber der Kunde sagt am Ende was er braucht und was er sich von einem
Zertifikat verspricht.“ (CSB#1). Dies kann als Bestätigung dafür angesehen werden,
dass, wie bereits in Kapitel 1 theoretisch dargelegt,125 bei der Entwicklung einer
effektiven dCZ kundenorientiert vorgegangen werden soll, was nochmals durch
folgende Expertenaussage eines Cloud-Service-Beraters unterstrichen wird: „[…] Was
Qualität ist, entscheidet immer der Kunde. […]“ (CSB#1). In diesem Zusammenhang
sei jedoch erwähnt, dass nicht nur die Informationsbedürfnisse der Cloud-Kunden eine
Rolle spielen, sondern auch die Bereitschaft der Cloud-Anbieter, sensible Informationen
nach außen zu geben, wie im Expertenworkshop von Cloud-Anbietern angemerkt
wird.126
Zusammenfassend kann festgehalten werden, dass auch aus Expertensicht eine
ausreichende Transparenz in verschiedenen Bereichen einer dCZ gewährleistet sein soll,
um hierdurch das Vertrauen der Cloud-Kunden in eine dCZ zu gewinnen und die
beschriebenen Mängel, wie die fehlende Nachvollziehbarkeit und Nachprüfbarkeit, zu
beheben. Da die ermittelten Kundenanforderungen an die Zertifizierungskriterien, wie
die Ausführungen des 6. Kapitels zeigen werden, darauf abzielen, die Transparenz einer
dCZ für Cloud-Kunden zu steigern, validieren die soeben dargelegten Expertenaussagen
die Kundenanforderungen insofern, als dass sie die Forderung nach einer ausreichenden
Transparenz und Nachvollziehbarkeit auch aus Expertensicht stützen und bestätigen.127
6
Kundenanforderungen an Zertifizierungskriterien
In diesem Kapitel werden nun die zentralen Ergebnisse dieser Arbeit, die ermittelten
Kundenanforderungen, die aus den Arbeitsergebnissen der drei Phasen der
Anforderungsermittlung resultieren, vorgestellt und beschrieben.
Wie die Ausführungen in den Kapiteln 3.3 und 5.3 darlegen, ist die Transparenz ein
entscheidender Faktor für den Nutzen, das Vertrauen sowie für die Akzeptanz einer
dCZ. Sie kann schlussendlich als eine der Voraussetzungen für den Erfolg einer dCZ
angesehen werden und soll daher auch bei einer dCZ gegeben sein. Die
125
Vgl. Kapitel 1.1, Absatz 4.
126
Vgl. E592-E594, S. 16, E835-E838, S. 22 und E1226-E1228, S. 31.
127
Vgl. zur Kernanforderung ‚Transparenz einer dCZ‘ Kapitel 3.3.
43
Kundenanforderungen besitzen daher die Gemeinsamkeit, die Transparenz im Hinblick
auf die Verständlichkeit, Zuverlässigkeit und Nachvollziehbarkeit einer dCZ gegenüber
Cloud-Kunden zu ermöglichen bzw. zu fördern.
Die finalen Kundenanforderungen lassen sich in zwei Kategorien einteilen. Die erste
Kategorie umfasst Kundenanforderungen an Zertifizierungskriterien, welche die
Spezifikationen der Zertifizierungskriterien betreffen. Diese werden im folgenden
Unterkapitel 6.1 vorgestellt. Die zweite Kategorie beinhaltet Kundenanforderungen an
Zertifizierungskriterien,
die
sich
auf
die
Prüfberichte
der
einzelnen
Zertifizierungskriterien beziehen. Auf diese wird in Unterkapitel 6.2 eingegangen. Bei
der Vorstellung der einzelnen Anforderungen werden diese jeweils mit einer
Überschrift, die die eindeutige Anforderungs-ID128 und die Bezeichnung der
Anforderung enthält, voneinander abgetrennt. Fußnoten, die auf Aussagen innerhalb des
Transkriptes des Workshops verweisen, werden mit einem „T“, gefolgt von der
Identifikationsnummer der Aussage gekennzeichnet.129 Fußnoten, die auf Aussagen
innerhalb des Transkriptes des Expertenworkshops verweisen, werden mit einem „E“,
gefolgt von der Zeilennummer der Aussage gekennzeichnet.
6.1
Kundenanforderungen an die Spezifikation eines Zertifizierungskriteriums
Durch die folgenden Anforderungen soll die Transparenz der Zertifizierungskriterien
für Cloud-Kunden gesteigert werden, indem ihre Spezifikationen mit weiteren
Informationen angereichert werden, die für Cloud-Kunden eine mögliche Relevanz
besitzen. Bevor die Kundenanforderungen der Reihe nach vorgestellt werden, gibt die
Tabelle
6-1
zunächst
einen
Gesamtüberblick
über
die
identifizierten
Kundenanforderungen an die Spezifikation eines Zertifizierungskriteriums.
ID
Anforderungsbezeichnung
A8b
Angabe des Prüfintervalls
A22a
Benachrichtigungsverhalten, Ereignisse
A22b
Benachrichtigungsverhalten, Art und Weise
A44
Veränderungen, bei denen eine erneute Auditierung des Zertifizierungskriteriums
notwendig ist
128
Diese Anforderungs-ID entspricht der Identifikationsnummer der Anforderung innerhalb des
Codierungsschemas.
129
Vgl. Fußnote 117.
44
A59a
Konsequenzen bei der Verletzung der Gültigkeit eines Zertifizierungskriteriums
A85
Klassifikation des Zertifizierungskriteriums hinsichtlich seiner Bedeutung für die
Informationssicherheit
Tab. 6-1: Übersicht über die Kundenanforderungen an die Spezifikation der Zertifizierungskriterien
A8b: Angabe des Prüfintervalls
Anforderung: Bei der Spezifikation eines Zertifizierungskriteriums soll angegeben
werden,
in
welchem
Prüfintervall130
die
Einhaltung
des
Zertifizierungskriteriums geprüft wird.
Das Prüfintervall gibt an, wann die Überprüfung eines Zertifizierungskriteriums erfolgt.
Die bisherigen Ausführungen dieser Arbeit zeigen, dass große Zeitabstände zwischen
der Überprüfung der Zertifizierungskriterien in der dynamischen Cloud-Umgebung
unzureichend sind, um die Gültigkeit der Zertifikatsaussage fortwährend aufrecht zu
erhalten. Der Bedarf an engmaschigeren Überprüfungen wird auch im Transkript des
Expertenworkshops von einem Cloud-Auditor hervorgehoben: „Ich denke mal, dass der
Druck des Marktes aber so sein wird, dass diese langen Abstände zwischen den
Zertifizierungen[,] wo man nicht weiß was passiert, dass das nicht mehr akzeptabel
ist.“ (CSA#2). Im Gegensatz zu den derzeitigen Cloud-Zertifizierungen, bei denen die
Zertifizierungskriterien üblicherweise in einem ein- bis dreijährigen Turnus überprüft
werden, soll daher die Überprüfung der Kriterien bei einer dCZ in engeren
Zeitabständen oder ereignisbasiert erfolgen. Durch die Verkürzung dieser Abstände, bis
hin zu einer kontinuierlichen Überprüfung, kann die Zuverlässigkeit der Einhaltung der
Zertifizierungskriterien gesteigert werden.131
Um diese Zuverlässigkeit gegenüber Cloud-Kunden zu signalisieren, soll das
Prüfintervall bei der Spezifikation des Zertifizierungskriteriums angegeben werden.
Durch diese Angabe kann sich ein Cloud-Kunde selbst von der Zuverlässigkeit des
Zertifizierungsprozesses überzeugen, wodurch wiederum sein Vertrauen in die
Zertifizierung gesteigert werden kann.
130
Das Prüfintervall bestimmt, wann eine Überprüfung der Einhaltung eines Zertifizierungskriteriums
erfolgt.
131
Vgl. zur Steigerung der Zuverlässigkeit aufgrund der verkürzten Abstände Kapitel 3.1.
45
Bei der Angabe des Prüfintervalls kann unterschieden werden, ob die Überprüfung in
bestimmten Zeitabständen und/oder bei Eintritt bestimmter Ereignisse erfolgt.132 Im
Detail soll daher bei der Spezifikation angegeben werden, ob die Überprüfung auf Basis
eines bestimmten Zeitintervalls und/oder ereignisbasiert stattfindet. Um den
Informationsgehalt der Spezifikation eines Zertifizierungskriteriums weiter zu erhöhen,
sollen zusätzlich der konkrete Zeitabstand und/oder die entsprechenden Ereignisse
dargelegt werden.
Die Angabe des Prüfintervalls bei der Spezifikation eines Zertifizierungskriteriums ist
jedoch nur sinnvoll, wenn das Prüfintervall statisch von der Zertifizierungsstelle, die für
die Gestaltung der Vorgaben einer Zertifizierung zuständig ist, festgelegt wird und sich
nicht in Abhängigkeit vom zu zertifizierenden Cloud-Dienst verändert. Soll vor dem
Hintergrund einer dCZ, um der Vielfalt der Cloud-Dienste gerecht zu werden, ein
dynamisches Prüfintervall zum Einsatz kommen, wie ein Cloud-Auditor im
Expertenworkshop fordert,133 so muss dieses aufgrund seiner Individualität entsprechend
im Prüfbericht eines Zertifizierungskriteriums und nicht bei seiner Spezifikation
angegeben werden.134
A22a: Benachrichtigungsverhalten, Ereignisse
Anforderung: Bei der Spezifikation eines Zertifizierungskriteriums soll angegeben
werden, ob und bei welchen Ereignissen in Bezug auf das
Zertifizierungskriterium
Cloud-Kunden
vom
Cloud-Anbieter
benachrichtigt werden.
Aus Sicht der Cloud-Kunden besteht aus verschiedenen Gründen ein Interesse daran,
bei Eintritt bestimmter Ereignisse (zeitnah) vom Cloud-Anbieter benachrichtigt zu
werden. Treten beispielsweise Ereignisse ein, die die Verfügbarkeit der Daten betreffen
oder eine Störung des gesamten Cloud-Dienstes zur Folge haben, so müssen die
betroffenen
Cloud-Kunden
zur
Gewährleistung
ihres
eigenen
regulären
Geschäftsbetriebes umfassend informiert werden. Darüber hinaus unterliegen CloudKunden gesetzlichen Vorgaben, wie beispielsweise dem Bundesdatenschutzgesetz,
132
Vgl. T168-T176, S. 16-17.
133
Vgl. E170-E171, S. 6.
134
Vgl. zur Angabe des Prüfintervalls im Prüfbericht Anforderung A8a Kapitel 6.2.2.
46
welches eine umgehende Benachrichtigung durch den Cloud-Anbieter fordert. Werden
personenbezogene Endkundendaten eines Cloud-Kunden kompromittiert, so ist dieser
gemäß
§42a
des
Bundesdatenschutzgesetzes135
gegenüber
seinen
Endkunden
verpflichtet, diese umgehend darüber zu informieren. Dieser Verpflichtung kann der
Cloud-Kunde natürlich nur nachkommen, wenn er vom Cloud-Anbieter entsprechend
informiert wird.
Überträgt man diese Forderung der Benachrichtigung der Cloud-Kunden auf die
Zertifizierungskriterien einer dCZ, so kann es als eine Kundenanforderung angesehen
werden, dass Cloud-Kunden bei bestimmten kritischen Ereignissen136 in Bezug auf ein
Zertifizierungskriterium
vom
Beispielsweise
die
kann
Cloud-Anbieter
benachrichtigt
Benachrichtigung
bei
der
werden
sollen.
Verletzung
eines
Zertifizierungskriteriums oder die Über- bzw. Unterschreitung bestimmter Schwellwerte
für Cloud-Kunden einen Mehrwert in einer dCZ bieten.137 Bei welchen Ereignissen
Cloud-Kunden
benachrichtigt
werden,
soll
bei
der
Spezifikation
eines
Zertifizierungskriteriums angegeben werden, damit Cloud-Kunden diese Ereignisse
einsehen und sich von ihrer Angemessenheit entsprechend der eigenen Anforderungen
überzeugen können. Um allerdings eine Informationsüberflutung der Cloud-Kunden zu
vermeiden, müssen die Ereignisse von der Zertifizierungsstelle gewissenhaft festgelegt
werden.
Im Zusammenhang mit der Benachrichtigung sind jedoch nicht nur die Ereignisse
relevant, sondern auch die Art und Weise, mit der die Benachrichtigung erfolgt.138 Dies
führt zu Anforderung A22b, die im folgenden Abschnitt vorgestellt wird.
A22b: Benachrichtigungsverhalten, Art und Weise
Anforderung: Bei der Spezifikation eines Zertifizierungskriteriums soll angegeben
werden, auf welche Art und Weise der Cloud-Kunde vom CloudAnbieter benachrichtigt wird.
135
Vgl. Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (2010), S. 35.
136
Vgl. T399, S. 35.
137
Vgl. zu den in diesem Satz erwähnten Ereignissen Hogben, Dekker (2012), S. 6, 13, 40, 41 und
Australian Signals Directorate (2012), S. 17.
138
Vgl. T397, S. 35.
47
In einem engen Zusammenhang mit der Anforderung A22a und den Ereignissen, bei
deren Eintritt Cloud-Kunden vom Cloud-Anbieter informiert werden, steht die Art und
Weise, mit der Cloud-Kunden über bestimmte Ereignisse benachrichtigt werden. Dies
hat den Grund, dass je nach Ereignis eine andere Form der Benachrichtigung
erforderlich und ausreichend sein kann. Mögliche Benachrichtigungsformen, die von
den Wissenschaftlern genannt werden, sind die unmittelbare, direkte Benachrichtigung
eines betroffenen Kunden, die Benachrichtigung über das Kunden-Dashboard139 sowie
die Benachrichtigung durch den Versand von Berichten in bestimmten Intervallen. 140
Neben den Ereignissen soll daher auch die Art und Weise, mit der eine
Benachrichtigung erfolgt, bei der Spezifikation eines Zertifizierungskriteriums
angegeben
werden.
Speziell
ist
die
Angabe
der
Art
und
Weise
bei
Zertifizierungskriterien relevant, die Cloud-Anbieter zu einer Benachrichtigung
verpflichten.141
A44: Veränderungen, bei denen eine erneute Überprüfung des
Zertifizierungskriteriums notwendig ist
Anforderung: Bei der Spezifikation eines Zertifizierungskriteriums soll angegeben
werden, bei welchen Veränderungen seitens des Cloud-Anbieters
eine erneute Überprüfung des Zertifizierungskriteriums durch den
Auditor erfolgt.
Mögliche Aktualisierungen und Veränderungen eines Cloud-Dienstes erhöhen die
Komplexität einer dCZ.142 Führt ein Cloud-Anbieter Veränderungen innerhalb seines
Cloud-Dienstes
durch,
könnten
diese
die
Gültigkeit
eines
oder
mehrerer
Zertifizierungskriterien gefährden. Um nach diesen Veränderungen dennoch die
Gültigkeit zu gewährleisten, ist eine erneute Überprüfung der von den Veränderungen
betroffenen Zertifizierungskriterien erforderlich. Die Notwendigkeit zur Überprüfung
von Veränderungen im Rahmen einer Zertifizierung wird insofern auch durch die
Expertenaussage eines Cloud-Beraters unterstützt, als dass er den Wert eines
139
Vgl. Anforderung A56.
140
Vgl. T395 sowie T398, S. 34.
141
Vgl. zur Existenz solcher Zertifizierungskriterien T392, S. 34 und ZKL-077.
142
Vgl. Kapitel 2.2.3 sowie E412-E414, S. 12.
48
Zertifikates, im Sinne des Nutzens, bei sich häufig ändernden Gegebenheiten in Frage
stellt.143
In diesem Zusammenhang stellt sich grundsätzlich die Frage, welche konkreten
Veränderungen eine erneute Überprüfung eines Zertifizierungskriteriums erfordern, wie
auch
ein
Cloud-Auditor
anmerkt.144
Aufgrund
der
Vielfalt
der
möglichen
Veränderungen innerhalb eines Cloud-Systems sowie aufgrund des damit verbundenen
hohen Prüfaufwandes145 ist es jedoch im Rahmen einer dCZ nicht möglich, sämtliche
Veränderungen daraufhin zu überprüfen, ob die Gültigkeit der Zertifizierungskriterien
weiterhin eingehalten wird. Zudem ist es nicht erforderlich, sämtliche Veränderungen
zu berücksichtigen, da diese sich auch im Hinblick auf ihre Relevanz für die Gültigkeit
der Zertifizierungskriterien unterscheiden können.146 Die Zertifizierungsstelle soll daher
vorgeben, bei welchen konkreten Veränderungen welche Zertifizierungskriterien erneut
überprüft werden müssen. Dies wird in der Praxis bereits in ähnlicher Form durch das
Zertifizierungsrahmenwerk FedRAMP147 umgesetzt. Dieses Zertifizierungsrahmenwerk
fordert, dass der Cloud-Anbieter einen Auditor bereits vor der Umsetzung bestimmter
Veränderungen
(„significant
changes“)
mit
einer
vorgegebenen
Vorlaufzeit
informiert.148 Der Auditor bewertet die geplanten Veränderungen anschließend im
Hinblick darauf, ob nach deren Umsetzung eine erneute Auditierung notwendig ist und
zugleich welche Zertifizierungskriterien erneut geprüft werden müssen.
Um Cloud-Kunden von der Zuverlässigkeit der Einhaltung der Zertifizierungskriterien
bei einer dCZ zu überzeugen, soll bei der Spezifikation eines Zertifizierungskriteriums
angegeben werden, bei welchen Veränderungen seitens des Cloud-Anbieters eine
erneute Überprüfung des Kriteriums erfolgt. Zur Umsetzung dieser Anforderung kann
die Zertifizierungsstelle eine Liste mit möglichen Veränderungen erstellen und diesen
143
Vgl. E373-E375, S. 11.
144
Vgl. E383-E385, S. 11.
145
Sofern die Überprüfung der von einer Veränderung betroffenen Zertifizierungskriterien nicht
vollautomatisiert erfolgt, entsteht ein hoher Prüfaufwand.
146
Beispielsweise erfordert die Inbetriebnahme eines weiteren Rechenzentrums oder der Wechsel des
Verschlüsselungsalgorithmus eine erneute Überprüfung bestimmter Zertifizierungskriterien,
wohingegen beim Hinzufügen eines zusätzlichen Administratorenzugangs keine erneute
Überprüfung notwendig wäre.
147
http://www.fedramp.gov/.
148
Vgl. zu diesem Absatz General Services Administration (2012), S. 39.
49
Veränderungen jeweils die Zertifizierungskriterien zuordnen, die bei der jeweiligen
Veränderung erneut überprüft werden müssen.149 Die Erstellung der Liste stellt für die
Zertifizierungsstelle zunächst einen hohen initialen Aufwand dar, besitzt jedoch
insbesondere für einen Auditor den Vorteil, dass dieser bei einer Veränderung anhand
der Liste ableiten kann, welche Zertifizierungskriterien erneut geprüft werden müssen.150
Daher wird hierdurch auch die Effizienz einer dCZ gesteigert.
Wurde die Zuordnung von möglichen Veränderungen zu Zertifizierungskriterien einmal
erstellt, können diese Informationen dazu genutzt werden, um die Zuverlässigkeit der
Einhaltung der Zertifizierungskriterien gegenüber Cloud-Kunden zu signalisieren,
indem diese Informationen in die Spezifikationen der einzelnen Zertifizierungskriterien
übertragen werden.
Obwohl diese Anforderung von den Wissenschaftlern Zuspruch erhält, muss kritisch
hinterfragt werden, ob die möglichen Veränderungen aufgrund der Vielfalt und
Komplexität der Cloud-Dienste überhaupt bei der Spezifikation statisch festgelegt
werden können oder ob diese nicht individuell in Abhängigkeit des zu zertifizierenden
Cloud-Dienstes festgelegt werden müssten.151
Zusammenfassend kann festgehalten werden, dass bei der Spezifikation der einzelnen
Zertifizierungskriterien angegeben werden soll, bei welchen Veränderungen innerhalb
des Cloud-Dienstes eine erneute Überprüfung eines Zertifizierungskriteriums erfolgt,
um hierdurch die Transparenz des Zertifizierungsprozesses für Cloud-Kunden zu
steigern und ihnen vor allem die Zuverlässigkeit des Zertifizierungsprozesses zu
signalisieren.
A59a: Konsequenzen bei der Verletzung der Gültigkeit eines
Zertifizierungskriteriums
Anforderung: Bei der Spezifikation eines Zertifizierungskriteriums soll angegeben
werden, welche Konsequenzen die von einem Auditor festgestellte
149
Alternativ könnte die Zertifizierungsstelle zu jedem Zertifizierungskriterium festlegen, bei welchen
Veränderungen eine erneute Überprüfung dieses Zertifizierungskriteriums erforderlich ist.
150
Vgl. T495, S. 42.
151
Vgl. T479-T483, S. 40-41.
50
Verletzung des Zertifizierungskriteriums für den Cloud-Anbieter
hat.
Um wiederum die Transparenz des Zertifizierungsprozesses und die Zuverlässigkeit der
Zertifikatsaussage gegenüber Cloud-Kunden zu signalisieren, soll bei der Spezifikation
eines Zertifizierungskriteriums angegeben werden, welche Konsequenzen eine vom
Auditor festgestellte Verletzung eines Zertifizierungskriteriums für den Cloud-Anbieter
besitzt. Die Konsequenzen sollen hierbei individuell für jedes Zertifizierungskriterium
festgelegt werden, da diese sich hinsichtlich ihrer Bedeutung für die Zertifikatsaussage
und Informationssicherheit unterscheiden können. Mögliche Konsequenzen wären, dass
der Auditor respektive die Zertifizierungsstelle dem Cloud-Anbieter eine Frist zur
Wiederherstellung der Einhaltung des verletzten Zertifizierungskriteriums setzt oder –
im schlimmsten Fall – dass das Zertifikat dem Cloud-Anbieter (vorübergehend)
entzogen wird.
Dass die Konsequenzen der Verletzung eines Zertifizierungskriteriums gegenüber
Cloud-Kunden dargestellt werden sollen, kann durch Expertenaussagen nur insoweit
bestätigt werden, als dass aufgrund einer ermöglichenden Nachvollziehbarkeit und
Nachprüfbarkeit die grundsätzliche Festsetzung von Fristen zur Wiederherstellung der
Gültigkeit gefordert wird.152
A85: Klassifikation des Zertifizierungskriteriums hinsichtlich seiner Bedeutung
für die Informationssicherheit
Anforderung: Bei der Spezifikation eines Zertifizierungskriteriums soll angegeben
werden, welche Bedeutung das Zertifizierungskriterium für die
Informationssicherheit eines Cloud-Services besitzt.
Wird eine dCZ so gestaltet, dass nicht alle Zertifizierungskriterien für die Vergabe des
Zertifikates vom Cloud-Dienst erfüllt werden müssen, so sollen Cloud-Kunden zur
Einschätzung des Sicherheitsniveaus des zertifizierten Cloud-Dienstes genau prüfen
können, welche konkreten Zertifizierungskriterien nicht erfüllt werden, bevor sie diesen
Cloud-Dienst nutzen. Um Cloud-Kunden in diesem Zusammenhang bei der
Einschätzung der Relevanz eines nicht erfüllten Zertifizierungskriteriums zu
152
Vgl. E918-E921, S. 24 und E925-E928, S. 24.
51
unterstützen,
soll
die
Bedeutung
des
Zertifizierungskriteriums
für
die
Informationssicherheit eines Cloud-Dienstes angegeben werden, was auch von drei
Wissenschaftlern als sinnvoll erachtet wird.153 Nutzen Cloud-Kunden bereits einen
zertifizierten Cloud-Dienst und wird die Gültigkeit eines Zertifizierungskriteriums nach
der Vergabe des Zertifikates verletzt, so können Cloud-Kunden anhand dieser
Informationen auch erkennen, ob es sich um ein weniger wichtiges oder um ein
bedeutendes Kriterium handelt, welches akut die Sicherheit des genutzten CloudDienstes gefährden könnte.
Die Herausforderung bei der Angabe der Bedeutung besteht darin, diese gegenüber
Cloud-Kunden verständlich und einfach darzulegen. Eine praxistaugliche Möglichkeit
hierzu, die bereits durch die Cloud-Zertifizierung EuroCloud Star Audit umgesetzt
wird,154 ist der Einsatz eines mehrstufigen Klassifizierungsschemas, in dessen Klassen
die einzelnen Zertifizierungskriterien anhand ihrer Bedeutung einsortiert werden.
Obwohl diese Anforderung von drei Wissenschaftlern als sinnvoll angesehen wird, wird
von diesen auch darauf hingewiesen, dass solch eine Klassifikation zum einen von einer
gewissen Subjektivität geprägt ist und zum anderen die Bedeutung eines
Zertifizierungskriteriums auch vom betrachteten Cloud-Service abhängig ist, was die
Umsetzung der Anforderung erschwert.155
Wie von einem Workshopteilnehmer angemerkt wird, ist diese Klassifikation zudem im
Zusammenhang mit der Anforderung A22a hilfreich, um sich bei der Festlegung der
Benachrichtigungsereignisse und der Art und Weise wie die Benachrichtigung erfolgt
auch an der Bedeutung der einzelnen Zertifizierungskriterien orientieren zu können.156
6.2
Kundenanforderungen an den Prüfbericht eines Zertifizierungskriteriums
Die Kundenanforderungen, die in diesem Kapitel vorgestellt werden, zielen darauf ab,
die Transparenz einer dCZ für Cloud-Kunden zu steigern, indem die Prüfberichte der
Zertifizierungskriterien mit Inhalten angereichert werden, die aus der Überprüfung der
153
Vgl. T517, T519 sowie T527, S. 43-44.
154
Vgl. https://eurocloud-staraudit.eu/de/publications/ecsa-controls.html und T523, S. 44.
155
Vgl. T517, T522, T523, S. 42-44.
156
Vgl. zu diesem Absatz T517, S. 43.
52
Zertifizierungskriterien resultieren und die für Cloud-Kunden relevant sind. Damit diese
Inhalte den Cloud-Kunden bereitgestellt werden können, müssen hierfür zunächst die
Grundlagen
geschaffen
werden.
Daher
unterteilt
sich
die
Vorstellung
der
Kundenanforderungen innerhalb dieses Kapitels in zwei Unterkapitel, wobei im
folgenden Unterkapitel 6.2.1 zunächst die Anforderungen zur Herstellung dieser
Grundlagen beschrieben werden, bevor in Unterkapitel 6.2.2 die ermittelten
Anforderungen an die Inhalte der Prüfberichte vorgestellt werden.
Die Tabelle 6-2 gibt einen Gesamtüberblick über die Kundenanforderungen an den
Prüfbericht eines Zertifizierungskriteriums.
ID
Anforderungsbezeichnung
A1a
Existenz eines Prüfberichtes zu jedem Zertifizierungskriterium
A1b
Einsichtnahme in die Prüfberichte
A56
Existenz eines Kunden-Dashboard
A33
Vergleichbarkeit des Prüfberichtes
A79
Angabe der Auditierungsmethode(n)
A9a
Angabe der Evaluationsobjekte
A9b
Angabe der Prüftiefe
A6
Angabe von Messwerten, Messgrößen und weiteren quantitativen
Informationen
A13
Angabe des Ausführungsintervalls
A8a
Angabe des Prüfintervalls
A82a
Angabe des Prüfzeitpunktes
A82b
Angabe der auditierenden Organisation
A59b
Konsequenzen bei der Verletzung der Gültigkeit eines Zertifizierungskriteriums
A15a, A15b
Sub-Cloud-Provider
A2
Angabe von Parametern, Aktivitäten und Ereignissen, die ein Cloud-Anbieter
und ein Auditor überwachen (kontinuierliches Monitoring)
Tab. 6-2: Übersicht über die Kundenanforderungen an die Prüfberichte der Zertifizierungskriterien
6.2.1 Kundenanforderungen zur Schaffung der Grundlagen
A1a: Existenz eines Prüfberichtes zu jedem Zertifizierungskriterium
Anforderung: Jedes Zertifizierungskriterium soll einen Prüfbericht besitzen.
Eine grundlegende Kundenanforderung stellt die Existenz eines Prüfberichtes dar,
wobei jedes Zertifizierungskriterium einen Prüfbericht besitzen soll. Diese Anforderung
53
wurde nicht aus einer Cloud-Publikation abgeleitet, sondern resultiert aus einer Aussage
eines Workshopteilnehmers: „Es muss für jedes Kriterium, was überprüft wurde, ein
Ergebnis, […] ein Ergebnissatz, also eine Zertifikatsaussage [vorhanden sein].“
(TN#3).
Jedoch reicht die alleinige Existenz der Prüfberichte nicht aus, um Cloud-Kunden einen
Mehrwert zu bieten. Darüber hinaus sollen sie die für Cloud-Kunden relevanten
Informationen in einem angemessen Detailgrad enthalten. Welche Informationen die
Prüfberichte enthalten sollen, wird durch die in Kapitel 6.2.2 beschriebenen
Anforderungen dargelegt.
A1b: Einsichtnahme in die Prüfberichte
Anforderung: Jeder Prüfbericht soll von Cloud-Kunden eingesehen werden
können.
Damit sich Cloud-Kunden von den Inhalten der Prüfberichte sowie insbesondere vom
Zertifizierungsstatus überzeugen können, sollen die Prüfberichte öffentlich zugänglich
sein.157 Da sich die Informationen innerhalb der Prüfberichte bei einer dCZ häufig
ändern können, ist es zur Abbildung der aktuellen Informationen darüber hinaus
erforderlich, Cloud-Kunden eine geeignete Plattform bereitzustellen. Die Notwendigkeit
dieser Plattform führt zur folgenden Anforderung A56.
A56: Existenz eines Kunden-Dashboard
Anforderung: Jedes
Zertifizierungskriterium
soll
im
Kunden-Dashboard
enthalten sein.
Damit sich Cloud-Kunden im Rahmen einer dCZ jederzeit vom aktuellen
Zertifizierungsstatus eines Cloud-Dienstes überzeugen können und die Inhalte der
Prüfberichte dargestellt werden können, muss die Zertifizierungsstelle Cloud-Kunden
eine elektronische Plattform bereitstellen. Über diese Plattform, die im weiteren Verlauf
Kunden-Dashboard
genannt
und
auch
von
mehreren
Teilnehmern
des
Expertenworkshops gefordert wird, können sich Cloud-Kunden selbst Transparenz
157
Vgl. T48-T49, S. 7.
54
herbeiführen.158 Insbesondere besteht vor dem Hintergrund einer dCZ, bei der sich die
Zertifizierungsergebnisse
durch
die
kontinuierliche
Überprüfung
der
Zertifizierungskriterien häufig ändern können, die Notwendigkeit eines KundenDashboards, auf dem die aktuellen Zertifizierungsstatus abgebildet werden können.
Außerdem kann es bei einer dCZ erforderlich sein, die Zertifizierungskriterien und
Prüfintervalle159 an veränderte Umstände und Anforderungen anzupassen oder auch
neue Zertifizierungskriterien aufgrund neuer Sicherheitslücken hinzuzufügen.160
Solch ein Kunden-Dashboard soll jedoch auch zu jeder Zeit den aktuellen
Sicherheitsstatus sowie den operativen Systemstatus eines Cloud-Dienstes darstellen
und gegenüber Cloud-Kunden nachweisen können.161 Hierzu soll das KundenDashboard neben Kennzahlen zur Verfügbarkeit und Laufzeit noch weitere
systemrelevante Parameter umfassen, die Cloud-Kunden von außen selbst nicht
ermitteln können.162 Allerdings muss sich in diesem Zusammenhang auch an der
Bereitschaft der Cloud-Anbieter orientiert werden, sensible Informationen nach außen
zu geben.163 Der Vorteil eines Kunden-Dashboards aus Sicht eines Cloud-Anbieters liegt
darin, dass dieses die Anzahl der Supportanfragen reduzieren kann.164
Von den Experten wird auch deutlich hervorgehoben, dass eine dCZ gegenüber CloudKunden
verständlich
Informationsbedürfnisse
sein
soll
sowie
und
deren
die
verschiedenen
unterschiedliche
Zielgruppen,
technische
deren
Kenntnisse
berücksichtigt werden sollen.165 Um auch innerhalb des Kunden-Dashboards der
Forderung nach der Verständlichkeit nachzukommen, wird von mehreren Experten der
Einsatz eines Ampelsystems vorgeschlagen, welches die Informationen in einer leicht
verständlichen Art und Weise darstellen soll.166 Die abzubildenden Informationen
158
Vgl. E66-E68, S. 3 und E1775-E1777, S. 45.
159
Vgl. zur Anpassung der Prüfintervalle Anforderung A8a.
160
Vgl. E117-E120, S. 4, E283-E291, S. 8 sowie zur Abdeckung aktueller Sicherheitsbedrohungen E180E182, S. 6, E208-E211, S. 6-7.
161
Vgl. E103-E104, S. 4 und E68, S. 3.
162
Vgl. E1430-E1432, S. 36.
163
Vgl. E2031-E2040, S. 51.
164
Vgl. E315-E329, S. 9.
165
Vgl. E211-E212, S. 7 und E310-E312, S. 9.
166
Vgl. E108, S. 4, E220, S. 7, E322-E329, S. 9 und E297-E303, S. 9.
55
zielgruppengerecht zu aggregieren sowie angemessene Schwellwerte für den Übergang
zwischen den Ampelstufen festzulegen, stellen die Herausforderungen bei der
Umsetzung eines Ampelsystems dar.167
Grundsätzlich sollen das Dashboard und die darin enthaltenen Informationen
zuverlässig, authentisch und manipulationssicher sein, um für Cloud-Kunden einen
tatsächlichen Nutzen zu stiften.168
A33: Vergleichbarkeit des Prüfberichtes
Anforderung: Der Prüfbericht eines Zertifizierungskriteriums soll immer den
gleichen Aufbau und vergleichbare Inhalte besitzen.
Damit Cloud-Kunden die Inhalte der einzelnen Prüfberichte über verschiedene
zertifizierte Cloud-Dienste hinweg vergleichen können, soll der Prüfbericht eines
Zertifizierungskriteriums immer den gleichen Aufbau und vergleichbare Inhalte
besitzen. Der Bedarf an einer möglichen Vergleichbarkeit wird auch von zwei
Teilnehmern innerhalb des Workshops bestätigt.169
Jedoch stellt sich die Frage, inwiefern die Vergleichbarkeit der Prüfberichte vor dem
Hintergrund der Vielfalt an Cloud-Services, die sehr individuell und spezifisch sein
können, sowie aufgrund der Subjektivität eines Auditors hergestellt werden kann. 170
Laut einem Teilnehmer des Workshops ist eine gewisse Vergleichbarkeit durch die
Beschreibung
der
Prüfmethode,
der
geprüften
Evaluationsobjekte
und
der
Prüfergebnisse inklusive quantitativer Angaben gegeben,171 es bleibt jedoch offen, ob
diese Angaben Cloud-Kunden ausreichen, sodass in diesem Bereich weiterer
Forschungsbedarf besteht. Innerhalb des Expertenworkshops wird die Vergleichbarkeit
im Sinne eines Benchmarkings von einem Teilnehmer kurz angesprochen und auch dort
angemerkt, dass die vergleichbare Messung von Leistungen verschiedener Cloud-
167
Vgl. zur Aggregation und Verdichtung E1238-E1242, S. 32, E242-E248, S. 7, E1011-E1014, S. 26
und zu den verschiedenen Zielgruppen E332-E335, S. 10.
168
Vgl. zur Zuverlässigkeit E868-E874, S. 23 und zur Authentizität und Manipulationssicherheit E632E647, S. 17, E1367-E1368, S. 35.
169
Vgl. T240-T242, T245, S. 23 sowie Gora (2009), S. 240.
170
Vgl. T256, T260, T263-T268, S. 24-25.
171
Vgl. T246, S. 23.
56
Dienste eine Herausforderung darstellt und herausgearbeitet werden soll, inwiefern dies
möglich ist.172
6.2.2 Kundenanforderungen an die Inhalte des Prüfberichtes
Die Anforderungen, die in diesem Unterkapitel vorgestellt werden, beschreiben, welche
Informationen der Prüfbericht eines Zertifizierungskriteriums enthalten soll, um CloudKunden von der Zuverlässigkeit und Angemessenheit einer dCZ zu überzeugen und um
ihnen die Zertifizierungsergebnisse in einer nachvollziehbaren und verständlichen Art
und Weise bereitzustellen. Angemessenheit bedeutet in diesem Zusammenhang, dass
sich Cloud-Kunden davon überzeugen können müssen, ob die Zertifizierung ihren
Anforderungen an die Informationssicherheit gerecht wird. In Bezug auf die
Zuverlässigkeit muss sich ein Cloud-Kunde davon überzeugen können, mit welcher
Zuverlässigkeit die Einhaltung der Zertifizierungskriterien überprüft und gewährleistet
wird.
Grundsätzlich kann zwischen den umfangreichen, vertraulichen Prüfberichten für die
Zertifizierungsstelle und den Prüfberichten für Cloud-Kunden unterschieden werden.173
Da die Prüfberichte der Cloud-Kunden gemäß Anforderung A1b öffentlich sein sollen,
muss bei ihren Inhalten unbedingt beachtet werden, dass sie keine Informationen
enthalten, die die Sicherheit des zertifizierten Cloud-Services oder die Vertraulichkeit
von Kundendaten gefährden.
A79: Angabe der Auditierungsmethode(n)
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll (sollen) die vom
Auditor
eingesetzte(n)
Auditierungsmethode(n)
genannt
und
beschrieben sein.
Um die Transparenz der Zertifizierung zu steigern und die Glaubwürdigkeit und
Akzeptanz
eines
Zertifikates
zu
stärken,
soll
die
Dokumentation
des
Zertifizierungsprozesses öffentlich verfügbar sein.174 Ein zentraler Bestandteil des
Prozesses ist die Überprüfung der Einhaltung der Zertifizierungskriterien, wofür
172
Vgl. E1967-E1971, S. 49-50.
173
Vgl. Bock (2008), S. 613 und T53, S. 7.
174
Vgl. Bock (2008), S. 613.
57
Auditierungsmethoden eingesetzt werden. Welche Auditierungsmethoden bei der
Überprüfung eines Zertifizierungskriteriums zum Einsatz kommen, besitzt neben dem
Prüfintervall einen Einfluss auf die Zuverlässigkeit der Einhaltung. So kann
beispielsweise
die
Zuverlässigkeit
durch
den
Einsatz
kontinuierlicher
Auditierungsmethoden erhöht werden, da durch diese eine fortlaufende Kontrolle der
Einhaltung
erfolgen
zugrundeliegenden
kann.
Aufgrund
technischen
der
Vielfalt
Infrastrukturen
der
könnten
den
Cloud-Diensten
(teil-)automatisierte
Auditierungsmethoden jedoch nicht grundsätzlich bei allen Cloud-Diensten eingesetzt
werden.175 Infolgedessen sollen die tatsächlich eingesetzten Auditierungsmethoden nicht
bei der Spezifikation eines Zertifizierungskriteriums angegeben werden, sondern nur im
Prüfbericht.
Um Zuverlässigkeit der Einhaltung gegenüber Cloud-Kunden zu signalisieren und die
eingangs erwähnte Transparenz, Glaubwürdigkeit und Akzeptanz eines dynamischen
Cloud-Zertifikates aus Kundensicht zu steigern, sollen daher die vom Auditor
eingesetzten Auditierungsmethoden im Prüfbericht des Zertifizierungskriteriums
angegeben werden und für Cloud-Kunden nachvollziehbar sowie verständlich
beschrieben werden. Dass die Angabe der Auditierungsmethode zur Steigerung der
Transparenz beiträgt, wird auch im Expertenworkshop von einem Cloud-Anbieter
hervorgehoben.176
A9a: Angabe der Evaluationsobjekte
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll angegeben
werden, welche Evaluationsobjekte bei der Auditierung des
Zertifizierungskriteriums überprüft werden.
Mit dem Begriff Evaluationsobjekt wird das Objekt bezeichnet, welches zur
Beschaffung
der
erforderlichen
Nachweise177
vom
Auditor
bzw.
der
Auditierungsmethode untersucht bzw. herangezogen wird, um die Bewertung der
Einhaltung eines Zertifizierungskriteriums durchführen zu können. Zur Verdeutlichung
dieser Definition wird im Folgenden ein Beispiel angeführt, für das auf ein
175
Vgl. E563-E566, S. 15 sowie E619-E621, S. 16-17.
176
Vgl. E789-E792, S. 21.
177
Vgl. zu den Nachweisen Kapitel 3.2.
58
Zertifizierungskriterium
zurückgegriffen
wird.
Beispielsweise
fordert
das
Zertifizierungskriterium ZKL-248, dass geprüft wird, ob die „[…] Informationssysteme
des Cloud-Anbieters regelmäßig dahingehend überprüft [werden], ob bestimmte
Sicherheitsstandards erfüllt werden können […]“. Mögliche Evaluationsobjekte dieses
Zertifizierungskriteriums sind:

Die schriftlichen Dokumentationen des Prüfprozesses, aus denen u. a.
hervorgeht, welche Informationssysteme überprüft werden, auf welche
Sicherheitsstandards diese überprüft werden, wer für die Überprüfung beim
Cloud-Anbieter verantwortlich ist und wie die Regelmäßigkeit der Überprüfung
geregelt ist.

Vergangenheitsorientierte Nachweise, die die Durchführung der regelmäßigen
Überprüfungen bestätigen.

Die für die Überprüfung der Informationssysteme verantwortlichen Mitarbeiter
des Cloud-Anbieters, die vom Auditor befragt werden.
Bleibt eine Zertifizierung bei der Beschreibung der Evaluationsobjekte zu vage, stellt
dies nach BOCK (2008) einen schwerwiegenden Mangel dar und Cloud-Kunden können
nicht nachvollziehen, welche Evaluationsobjekte im Zentrum der Überprüfung
standen.178 Damit Cloud-Kunden jedoch nachvollziehen können, ob die dCZ ihren
Anforderungen entspricht, sollen die Evaluationsobjekte daher in den einzelnen
Prüfberichten genannt werden.
A9b: Angabe der Prüftiefe
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll angegeben
werden, in welcher Prüftiefe die Evaluationsobjekte untersucht
wurden.
Die Prüftiefe gibt an, in welchem Umfang die einem Zertifizierungskriterium
zugrundeliegenden Evaluationsobjekte überprüft wurden. Es kann eine vollumfängliche
oder stichprobenartige Überprüfung unterschieden werden. Sie kann als ein Attribut zur
näheren Beschreibung des Prüfumfangs angesehen werden und steht daher in einem
engen Zusammenhang mit Anforderung A9a. Die Angabe der Prüftiefe und der enge
178
Vgl. zum Mangel aufgrund der fehlenden Beschreibung der Evaluationsobjekte Bock (2008), S. 614.
59
Zusammenhang zum Evaluationsobjekt werden anhand des folgenden Beispiels
verdeutlicht. Das Zertifizierungskriterium ZKL-039179 fordert, dass, „wenn eine
Leistung eines Sub-Cloud-Anbieters für einen Cloud-Service notwendig ist […]“,
geprüft wird, ob „[…] die Kommunikation mit diesem Sub-Cloud-Anbieter
verschlüsselt […]“ wird. Bei diesem Kriterium soll im Sinne der Prüftiefe angegeben
werden, ob der Auditor nur einen Teil der Kommunikationsverbindungen zu mehreren
Sub-Cloud-Providern (SCP) geprüft hat oder ob er die Verschlüsselung bei jeder
Kommunikationsverbindung geprüft hat.
Wird die Prüftiefe im Prüfbericht zu jedem Evaluationsobjekt angegeben, so können
Cloud-Kunden hieran den Umfang der Überprüfung erkennen und somit abschätzen, ob
diese Prüftiefe für ihren Sicherheitsbedarf angemessen ist. Reicht die Prüftiefe eines
Zertifizierungskriteriums einem Cloud-Kunden nicht aus, da er einen besonders hohen
Schutzbedarf besitzt, so kann er sich in diesem Fall selbst an den Cloud-Anbieter
wenden und weitere Nachweise einfordern oder sogar eine eigene Überprüfung
durchführen. Dass Cloud-Kunden die Prüftiefe nachlesen können sollen, wird auch
durch eine Aussage eines Workshopteilnehmers unterstützt: „Das ist Aufgabe des
Zertifikats, den angemessenen Prüfumfang festzulegen [und] zu definieren. Und die
Anforderungen vom Kunden, die können ja individuell sein, aber er muss es nachlesen
können. Das ist das Wichtige.“ (TN#3).
A6: Angabe von Messwerten, Messgrößen und weiteren quantitativen
Informationen
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums sollen Messwerte,
Messgrößen
und/oder
weitere
quantitative
Informationen
angegeben werden, sofern dies für dieses Zertifizierungskriterium
möglich und sinnvoll ist.
Um den Informationsgehalt des Prüfberichtes für Cloud-Kunden zu erhöhen, soll der
Prüfbericht um Messgrößen und konkrete quantitative Angaben, wie beispielsweise
Messwerte oder auch Ausführungsintervalle180, ergänzt werden. Hierdurch kann die
Vergleichbarkeit der Prüfberichte verschiedener zertifizierter Cloud-Dienste, die bisher
179
Vgl. zur Herkunft dieses Zertifizierungskriteriums Kapitel 3.5.
180
Vgl. zum Ausführungsintervall Anforderung A13.
60
oftmals nur auf einer reinen Ja/Nein-Bewertung des Kriteriums basiert, verfeinert
werden, um Cloud-Kunden somit eine fundiertere Entscheidung im Auswahlprozess zu
ermöglichen.181
Wie im Workshop erwähnt wird, ist die Angabe von Messwerten, Messgrößen und
weiteren quantitativen Werten jedoch nicht für alle Zertifizierungskriterien sinnvoll
möglich,182 weshalb bei der Entwicklung einer dCZ jedes Zertifizierungskriterium
daraufhin untersucht werden muss, welche quantitativen Angaben sinnvoll und für
Cloud-Kunden relevant sind. Zudem besteht die Herausforderung bei der Angabe und
Interpretation von quantitativen Angaben darin, diese ins Verhältnis zum betrachteten
Cloud-Service bzw. Cloud-Anbieter zu setzen, wie im Workshop angemerkt wird.183
Anhand der folgenden Beispiele soll gezeigt werden, bei welcher Art von
Zertifizierungskriterien die oben genannten Angaben für Cloud-Kunden hilfreich sind.
So kann beispielsweise im Zusammenhang mit dem Zertifizierungskriterium ZKL404184, welches prüft, ob ein Cloud-Anbieter eine „schnelle Skalierungsfähigkeit“
besitzt,
angegeben
werden,
innerhalb
welcher
Zeit
Cloud-Kunden
weitere
Systemressourcen bereitgestellt werden können. Die Angabe von reinen Messgrößen
hingegen ist beispielsweise in Anbetracht des Zertifizierungskriteriums ZKL-362185
hilfreich, um offenzulegen, zu welchen Messgrößen konkrete Messwerte in Echtzeit auf
der
Webseite
des
Cloud-Anbieters
publiziert
werden.
In
Bezug
auf
das
Zertifizierungskriterium ZKL-077186 stellt die Angabe, innerhalb welcher Zeit die
betroffenen Cloud-Kunden vom Cloud-Anbieter informiert werden, eine weitere
hilfreiche Information für Cloud-Kunden dar.
181
Vgl. T124, S. 14.
182
Vgl. T121, T123, S. 14.
183
Vgl. T118, S. 13.
184
ZKL-404: „Besitzt der offerierte Cloud-Service eine schnelle Skalierungsfähigkeit; kann er also nach
Bedarf schnell und elastisch zur Verfügung gestellt werden?“.
185
ZKL-362: „Verfügt der Cloud-Anbieter über ein Availability Management Information System, das
die Performance des angebotenen Cloud-Services ermittelt? Werden Informationen des AMIS in
Echtzeit auf der Webseite des Cloud-Anbieters publiziert?“.
186
ZKL-077: „Werden die betroffenen Kunden rechtzeitig über entsprechende Sicherheitslücken, -brüche
oder -vorfälle informiert?“.
61
A13: Angabe des Ausführungsintervalls
Anforderung: Im
Prüfbericht
eines
Ausführungsintervall
Zertifizierungskriteriums
angegeben
werden,
soll
wenn
das
das
Zertifizierungskriterium die regelmäßige Ausführung bestimmter
Tätigkeiten vom Cloud-Anbieter fordert.
Der dieser Arbeit zugrundeliegende Kriterienkatalog mit kontinuierlich zu prüfenden
Zertifizierungskriterien umfasst unter anderem auch Zertifizierungskriterien, die vom
Cloud-Anbieter die regelmäßige Ausführung bestimmter Tätigkeiten fordern. Zu diesen
Tätigkeiten zählen beispielsweise die Durchführung von Penetrationstests187 oder die
regelmäßige Überprüfung der Kontrollziele, Kontrolltätigkeiten und Prozesse des
Informationssicherheits-Managementsystems (ISMS)188. Der zeitliche Abstand, mit dem
ein Cloud-Anbieter diese Tätigkeiten ausführt, wird als Ausführungsintervall
bezeichnet. Da die Durchführung von Penetrationstests und die Überprüfung des ISMS
zur Sicherheit eines Cloud-Dienstes beitragen, kann angenommen werden, dass das
Sicherheitsniveau des Cloud-Dienstes zunimmt, je häufiger diese Tätigkeiten ausgeführt
werden. Daher kann das jeweilige Ausführungsintervall Cloud-Kunden als Indikator für
die Sicherheit des zertifizierten Cloud-Dienstes dienen, weshalb dieses in den
Prüfberichten der Zertifizierungskriterien, die die Ausführung bestimmter Tätigkeiten
von Cloud-Anbietern fordern, angegeben werden soll.
A8a: Angabe des Prüfintervalls
Anforderung: Im
Prüfbericht
eines
Zertifizierungskriteriums
soll
das
Prüfintervall des Zertifizierungskriteriums angegeben werden.
Die hier beschriebene Anforderung unterscheidet sich von der bereits vorgestellten
Anforderung A8b darin, dass das Prüfintervall nicht bei der Spezifikation des
Zertifizierungskriteriums, sondern im Prüfbericht angegeben werden soll. Das hat den
Hintergrund,
dass
die
Angaben
innerhalb
der
Spezifikation
eines
Zertifizierungskriteriums Standardvorgaben darstellen, die grundsätzlich bei einer dCZ
gelten. Von diesen Standardvorgaben kann jedoch beispielsweise durch die Festlegung
187
ZKL-092: „Werden beim Cloud-Anbieter regelmäßig Penetrationstests durchgeführt?“.
188
ZKL-160: „Werden interne Audits zu den geplanten Intervallen durchgeführt, um zu überprüfen, ob
die Kontrollziele, Kontrolltätigkeiten, Prozesse und Prozeduren des ISMS […]“.
62
eines individuellen Prüfintervalls abgewichen werden. Ein Grund für solch eine
Abweichung könnte sein, dass bei der letzten Überprüfung des Zertifizierungskriteriums
ein Verstoß festgestellt wurde und der verantwortliche Auditor zur Vermeidung von
zukünftigen Verstößen eine engmaschigere Überprüfung festsetzt. Die Notwendigkeit
von individuellen Prüfintervallen in Abhängigkeit vom jeweils zu zertifizierenden
Cloud-Dienst wird zudem von einem Cloud-Auditor innerhalb des Expertenworkshops
hervorgehoben und mit der unterschiedlichen Dynamik innerhalb der betrieblichen
Prozesse eines Cloud-Anbieters und der rapiden Veränderbarkeit der den CloudDiensten
zugrundeliegenden
Technologien
begründet.189
Da
das
individuelle
Prüfintervall von den Standardvorgaben der Spezifikation abweicht, soll es folglich im
Prüfbericht angegeben werden.
Können Cloud-Kunden das individuelle Prüfintervall eines Zertifizierungskriteriums
einsehen, so trägt dies dazu bei, sie von der Zuverlässigkeit der Einhaltung des
Zertifizierungskriteriums zu überzeugen. Zudem können sie anhand dieser Information
in Kombination mit der Angabe, an welchem Zeitpunkt die letzte Prüfung190 erfolgt ist,
ableiten, wann die nächste Überprüfung des Zertifizierungskriteriums erfolgen soll.
A82a: Angabe des Prüfzeitpunktes
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll der Zeitpunkt
der letzten Überprüfung angegeben werden.
Der Prüfzeitpunkt gibt an, wann die letzte Überprüfung der Einhaltung eines
Zertifizierungskriteriums erfolgt ist. Wird der Prüfzeitpunkt im Prüfbericht eines
Zertifizierungskriteriums angegeben, so können Cloud-Kunden den Zeitpunkt der
letzten Überprüfung nachvollziehen.
Insbesondere ist die Angabe des Prüfzeitpunktes für Cloud-Kunden vor dem
Hintergrund neuer Sicherheitslücken relevant. Werden neue Sicherheitslücken bekannt,
so liegt es im Interesse der Cloud-Kunden, dass die dCZ überprüft, ob ein CloudAnbieter angemessene Schutzmaßnahmen gegen diese Sicherheitslücken umgesetzt hat.
Ob diese Überprüfung nach dem Zeitpunkt des Bekanntwerdens einer Sicherheitslücke
189
Vgl. E155-E172, S. 5-6.
190
Vgl. zur Angabe des Prüfzeitpunktes Anforderung A82a.
63
auch erfolgt ist, können Cloud-Kunden anhand des Prüfzeitpunktes ermitteln. Des
Weiteren können Cloud-Kunden anhand der Angabe des Prüfzeitpunktes und des
Prüfintervalls ableiten, wann eine erneute Überprüfung des Zertifizierungskriteriums
erfolgt.
A82b: Angabe der auditierenden Organisation
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll die für die
Auditierung
des
Zertifizierungskriteriums
verantwortliche
Organisation angegeben werden.
Um die Vertrauenswürdigkeit einer dCZ zu erhöhen, soll im Prüfbericht eines
Zertifizierungskriteriums die Organisation genannt werden, die für die Auditierung des
Zertifizierungskriteriums verantwortlich ist.
Dies hat verschiedene Gründe. Zum einen trägt diese Information grundsätzlich zur
Transparenz des Zertifizierungsprozesses bei und kann über die nachvollziehbare
Akkreditierung
der
auditierenden
Organisation
die
wahrgenommene
Vertrauenswürdigkeit des Zertifizierungsprozesses steigern.191 Zum anderen können
Cloud-Kunden bei Rückfragen zu einem Zertifizierungskriterium die jeweilige
verantwortliche Organisation kontaktieren.
A59b: Konsequenzen bei der Verletzung der Gültigkeit eines
Zertifizierungskriteriums
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll angegeben
werden, welche Frist dem Cloud-Anbieter zur Wiederherstellung
der Gültigkeit des betroffenen Zertifizierungskriteriums auferlegt
wird
und
wann
eine
erneute
Überprüfung
des
Zertifizierungskriteriums erfolgt.
Wird eine Verletzung eines Zertifizierungskriteriums durch den Auditor festgestellt, so
soll
191
die Einhaltung des
Vgl. Bock (2008), S. 613.
Zertifizierungskriteriums
durch den
Cloud-Anbieter
64
schnellstmöglich wiederhergestellt werden, um die Gültigkeit des Zertifikates aufrecht
zu erhalten.192
Um Cloud-Kunden davon zu überzeugen, dass eine dCZ nach der Feststellung einer
Verletzung die schnellstmögliche Wiederherstellung der Einhaltung anstrebt, soll der
Prüfbericht eines verletzten Zertifizierungskriteriums um weitere Informationen ergänzt
werden. Zum einen soll der Prüfbericht um den Zeitpunkt, an dem die Verletzung
festgestellt wurde, und um eine Frist, die dem Cloud-Anbieter zur Wiederherstellung
der Gültigkeit des Zertifizierungskriteriums auferlegt wurde, ergänzt werden. 193 Zum
anderen soll dem Prüfbericht in diesem Zusammenhang auch der Zeitpunkt, an dem
eine erneute Überprüfung des verletzten Zertifizierungskriteriums erfolgt, hinzugefügt
werden.194
A15a, A15b: Sub-Cloud-Provider
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll angegeben
werden,
ob
der
Cloud-Anbieter
in
Bezug
auf
das
Zertifizierungskriterium eine Leistung eines Sub-Cloud-Providers
bezieht sowie ob und in welcher Form die Überprüfung des
Zertifizierungskriteriums beim SCP erfolgt ist.
Wie in Kapitel 2.2.3 dargelegt, kann ein Cloud-Dienst auch aus mehreren Diensten und
Ressourcen zusammengestellt werden, die von weiteren Cloud-Anbietern, den
sogenannten Sub-Cloud-Providern, bereitgestellt werden. Die Einbindung von SCP
birgt für einen Cloud-Anbieter das Risiko, dass sich die Sicherheitsrisiken eines SCP
auch auf seinen Cloud-Dienst auswirken können, wodurch ein entsprechendes
Gefährdungspotential entsteht. Da ein Cloud-Anbieter gegenüber seinen Endkunden für
die Gesamtsicherheit seines Cloud-Angebotes verantwortlich ist, müsste er in diesem
Fall auch die Sicherheit der von ihm eingebundenen Cloud-Dienste überprüfen und die
192
Es wird die Annahme getroffen, dass die Verletzung eines Zertifizierungskriteriums dazu führt, dass
das Cloud-Zertifikat vorübergehend seine Gültigkeit verliert.
193
Vgl. T381, S. 33.
194
Vgl. T298, S. 28.
65
erforderlichen Nachweise vom SCP einfordern, um seinen Kunden ein ausreichendes
Sicherheitsniveau gewährleisten zu können.195
Um dieses Gefährdungspotential durch eine dCZ zu reduzieren und eine möglichst
verlässliche Aussage zur Sicherheit des gesamten Cloud-Dienstes treffen zu können,
müssten auch die eingebundenen SCP auf die Einhaltung von Zertifizierungskriterien
hin überprüft werden. Die Überprüfung von SCP stellt aktuell jedoch noch eine
Herausforderung dar und wird zurzeit von keiner Cloud-Zertifizierung in der Praxis
umgesetzt.196 Folglich bleibt das genannte Gefährdungspotential bestehen, was eine
große Schwäche derzeitiger Cloud-Zertifizierungen darstellt. Diese Schwächen sollen
gegenüber Cloud-Kunden transparent dargestellt werden.197
Dementsprechend ist es erforderlich, im Prüfbericht eines Zertifizierungskriteriums die
folgenden Informationen in Bezug auf den Einsatz von SCP anzugeben, um CloudKunden über das vorhandene Gefährdungspotential eines zertifizierten Cloud-Dienstes
aufzuklären. Zunächst soll angegeben werden, ob der zertifizierte Cloud-Dienst in
Bezug auf das Zertifizierungskriterium eine Leistung eines SCP einsetzt.198 Darüber
hinaus soll angegeben werden, ob das Zertifizierungskriterium unmittelbar beim CloudAnbieter überprüft wurde oder ob dies aufgrund eines eingebundenen SCP nicht bzw.
nur eingeschränkt möglich war.199 Beispielsweise soll bei einer Zertifizierung eines
SaaS-Providers, der einen IaaS einsetzt, zum Zertifizierungskriterium ZKL-050200 im
Prüfbericht angegeben werden, dass die Speicherung der Daten bei einem SCP erfolgt
sowie ob und in welcher Form eine Überprüfung des Zertifizierungskriteriums bei
diesem SCP erfolgt ist.
195
Vgl. Bundesamt für Sicherheit in der Informationstechnik (2012), S. 60.
196
Vgl. zur Herausforderung aufgrund der Kombination mehrerer Cloud-Dienste Kapitel 2.2.3.
197
Vgl. E1325-E1331, S. 34.
198
Vgl. T447, S. 38.
199
Vgl. T201, T207, T211, S. 20.
200
ZKL-050: „Sind alle in der Cloud gespeicherten Kundendaten durch z.B. virtuelle Speicherbereiche,
Tagging etc. voneinander sicher isoliert?“.
66
A2: Angabe von Parametern, Aktivitäten und Ereignissen, die ein Cloud-Anbieter
und ein Auditor überwachen (kontinuierliches Monitoring)
Anforderung: Im Prüfbericht eines Zertifizierungskriteriums soll angegeben
werden, welche Parameter, Aktivitäten und Ereignisse in Bezug auf
das Zertifizierungskriterium durch den Cloud-Anbieter und den
Auditor überwacht werden.
Um die Zuverlässigkeit der Überprüfung und Einhaltung der Zertifizierungskriterien
gegenüber Cloud-Kunden zu signalisieren, soll in den Prüfberichten angegeben werden,
welche Parameter, Aktivitäten und Ereignisse der Cloud-Anbieter sowie der Auditor im
Rahmen
eines
kontinuierlichen
Monitorings
in
Bezug
auf
das
jeweilige
Zertifizierungskriterium überwachen.201 Diese Anforderung resultiert überwiegend
daraus, dass in mehreren untersuchten Cloud-Publikationen gefordert wird, dass CloudAnbieter bestimmte Parameter und Aktivitäten überwachen und protokollieren sollen
und Cloud-Kunden in Erfahrung bringen sollen, welche dies sind. 202 Beispielsweise
kann zum Zertifizierungskriterium ZKL-073203 angegeben werden, dass der Traffic des
Cloud-Dienstes oder auch die Anzahl erfolgreicher bzw. fehlgeschlagener LoginVersuche fortlaufend überwacht werden, um somit Anomalien aufdecken und
entsprechende Maßnahmen einleiten zu können. Da jedoch nicht zu allen
Zertifizierungskriterien Parameter und Aktivitäten überwacht werden können,
beschränkt sich diese Anforderung auf Zertifizierungskriterien, zu denen dies möglich
ist.
201
Vgl. T73-T75, S. 9 und T421, S. 36.
202
Vgl. Bundesamt für Sicherheit in der Informationstechnik (2012), S. 49-50 und Catteddu, Hogben
(2009), S. 13, 16, 21.
203
ZKL-073: „Können Angriffe und Sicherheitsvorfälle rechtzeitig erkannt und zeitnahe Reaktion
eingeleitet werden?“.
67
7
Mit
Fazit
dieser Arbeit
wurde das
Ziel verfolgt,
Kundenanforderungen an die
Zertifizierungskriterien einer dynamischen Cloud-Zertifizierung zu ermitteln, um
hierdurch einen Beitrag zur Entwicklung einer effektiven, kundenorientierten dCZ zu
leisten.
Zu diesem Zweck wurde zunächst ermittelt, welche Faktoren aus Kundensicht zur
Akzeptanz einer dCZ beitragen. Dabei hat sich herausgestellt, dass die Transparenz
einer dCZ ein entscheidender Faktor ist, damit Cloud-Kunden Vertrauen in eine dCZ
aufbauen können. Die Transparenz wurde dementsprechend als eine Kernanforderung
der Cloud-Kunden angesehen, vor deren Hintergrund Kundenanforderungen ermittelt
wurden, mit denen die Transparenz im Hinblick auf die Zertifizierungskriterien einer
dCZ gesteigert werden kann. Auf dieser Grundlage konnten schließlich 62 mögliche
Kundenanforderungen
aus
22
ausgewählten
Cloud-Publikationen
systematisch
hergeleitet und in einem initialen Anforderungskatalog zusammengeführt werden.
Dieser initiale Anforderungskatalog bildete die Ausgangsbasis für den darauffolgenden
Workshop im Forschungsumfeld, in dem die literaturbasierten Kundenanforderungen
bezüglich ihrer Kundenrelevanz und Praxistauglichkeit diskutiert wurden. Aufgrund der
Ergebnisse des Workshops wurden Kundenanforderungen aus verschiedenen Gründen
gestrichen, zusammengefasst, aufgeteilt oder auch umformuliert. Aufgrund dessen
wurde der Anforderungskatalog im Nachgang überarbeitet, sodass nach dem Workshop
schlussendlich 22 Kundenanforderungen verblieben, die von den teilnehmenden
Wissenschaftlern Zuspruch erhielten, da sie als sinnvoll und kundenrelevant angesehen
wurden. Diese Kundenanforderungen verfolgen das gemeinsame Ziel, die Transparenz
der
dCZ
zu
steigern,
indem
die
Spezifikationen
und
Prüfberichte
der
Zertifizierungskriterien mit für Kunden relevanten Informationen angereichert werden.
Die Kundenanforderungen wurden im 6. Kapitel vorgestellt. Aufgrund dieser Resultate
wurden die ersten drei Teilziele dieser Arbeit erreicht.
Jedoch gestaltete sich die empirische Validierung der Kundenanforderungen als
schwierig und die einzelnen Anforderungen konnten mittels Expertenaussagen aus der
Praxis nicht unmittelbar validiert werden. Der Hauptgrund hierfür liegt darin, dass die
Kundenanforderungen innerhalb des Expertenworkshops nicht zielgerichtet thematisiert
68
wurden. Trotz dieser Tatsache konnten die Anforderungen insofern validiert werden, als
dass auch die Experten die Notwendigkeit an einer ausreichenden Transparenz deutlich
hervorgehoben haben und hierdurch die grundlegende Kernanforderung und somit auch
unmittelbar die Kundenanforderungen bestätigten. Darüber hinaus konnten wertvolle
Informationen aus der Sicht der Experten gewonnen werden, die wichtige Teilaspekte
der Kundenanforderungen thematisieren und mit denen die Beschreibung der
Anforderungen
angereichert
werden
konnten.
Aufgrund
der
eingeschränkten
Validierung müssen die ermittelten Kundenanforderungen mit einer gewissen Skepsis
betrachtet werden und es sind weitere Forschungsarbeiten notwendig, um die
Anforderungen beispielsweise in einer quantitativen Studie gegenüber Cloud-Kunden
unmittelbar zu validieren.
Weiterhin sei erwähnt, dass die vorgestellten Kundenanforderungen keinen Anspruch
auf Vollständigkeit erheben, da die Ermittlung dieser auf einer Literaturuntersuchung
und nicht auf einer direkten Kundenbefragung basierte, sodass angenommen werden
kann, dass weitere wichtige Kundenanforderungen nicht identifiziert wurden. Zudem
sollte untersucht werden, welche Implikationen die Umsetzung der Anforderungen für
Cloud-Anbieter und Zertifizierungsstellen im Hinblick auf die damit einhergehenden
Aufwände besitzt und ob diese für sie akzeptabel sind.
Schlussendlich bleibt zu hoffen, dass die erarbeiteten Kundenanforderungen trotz der
genannten Einschränkungen einen Beitrag zur kundenorientierten Gestaltung einer
dynamischen Cloud-Zertifizierung leisten werden.
69
Literaturverzeichnis
Armbrust u. a. (2010)
Michael Armbrust, Armando Fox, Rean Griffith, Anthony Joseph, Randy Katz,
Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, Matei
Zaharia: A view of cloud computing. In: Communications of the ACM. Nr. 4,
Jg. 53, 2010, S. 50-58
Australian Signals Directorate (2012)
Australian Signals Directorate: Cloud Computing Security Considerations.
http://www.asd.gov.au/publications/protect/Cloud_Computing_Security_Consid
erations.pdf, Abruf am 20.11.2014
Bernnat u. a. (2012)
Rainer Bernnat, Wolfgang Zink, Nicolai Bieber, Joachim Strach: Das
Normungs- und Standardisierungsumfeld von Cloud Computing.
http://www.trustedcloud.de/media/content/20111222_BMWi_Cloud_Standards_Studie_Abschlussb
ericht_%28FINAL%29.pdf, Abruf am 15.02.2015
Bezzi, Kaluvuri, Sabetta (2011)
Michele Bezzi, Samuel Kaluvuri, Antonino Sabetta: Ensuring Trust in Service
Consumption Through Security Certification. In: ACM (Hrsg.): Proceedings of
the International Workshop on Quality Assurance for Service-Based
Applications (QASBA), September 14, 2011, Lugano, Schweiz. New York, NY,
USA 2011, S. 40-43
Bock (2008)
Kirsten Bock: EuroPriSe Trust Certification. In: Datenschutz und
Datensicherheit (DuD). Nr. 9, Jg. 32, 2008, S. 610-614
Bruhn (2008)
Manfred Bruhn: Qualitätsmanagement für Dienstleistungen. Grundlagen,
Konzepte, Methoden. 7. Aufl., Berlin, Heidelberg 2008
70
Bundesamt für Sicherheit in der Informationstechnik (2012)
Bundesamt für Sicherheit in der Informationstechnik: Sicherheitsempfehlungen
für Cloud Computing Anbieter - Mindestanforderungen in der
Informationssicherheit.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindestanforderunge
n/Eckpunktepapier-Sicherheitsempfehlungen-CloudComputing-Anbieter.pdf,
Abruf am 20.11.2014
Bundesamt für Sicherheit in der Informationstechnik (2014)
Bundesamt für Sicherheit in der Informationstechnik: Zertifizierung nach
Technischen Richtlinien - Verfahrensbeschreibung / Zertifizierungsschema.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/TechnR
ichtlinien/MaintenanceRe-Zert_pdf.pdf, Abruf am 20.11.2014
Catteddu, Hogben (2009)
Daniele Catteddu, Giles Hogben: Cloud Computing - Information Assurance
Framework. http://www.enisa.europa.eu/activities/riskmanagement/files/deliverables/cloud-computing-information-assuranceframework/at_download/fullReport, Abruf am 04.12.2014
Cimato u. a. (2013)
Stelvio Cimato, Ernesto Damiani, Francesco Zavatarelli, Renato Menicocci:
Towards the Certification of Cloud Services. In: IEEE (Hrsg.): 9th World
Congress on Services (SERVICES), Juni 27 - Juli 2, 2013, Santa Clara, CA,
USA. Washington, DC, USA 2013, S. 92-97
Dempsey u. a. (2011)
Kelley Dempsey, Nirali Chawla, Arnold Johnson, Ronald Johnston, Alicia
Jones, Angela Orebaugh, Matthew Scholl, Kevin Stine: Information Security
Continuous Monitoring (ISCM) for Federal Information Systems and
Organizations. http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137Final.pdf, Abruf am 16.12.2014
71
Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (2010)
Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit:
Bundesdatenschutzgesetz (BDSG).
http://www.bfdi.bund.de/SharedDocs/Publikationen/GesetzeVerordnungen/BDS
G.pdf, Abruf am 15.02.2015
Doney, Cannon (1997)
Patricia Doney, Joseph Cannon: An examination of the nature of trust in buyerseller relationships. In: Journal of Marketing. Nr. 2, Jg. 61, 1997, S. 35-51
Gadatsch, Klein, Münchhausen (2013)
Andreas Gadatsch, Henrik Klein, Manuel Münchhausen: Zertifizierte ITSicherheit für Cloud-Services. https://www.ittuv.com/fileadmin/datenpool/pdf/whitepaper/White-Paper_Zertifizierte-CloudServices-final-20130722.pdf, Abruf am 30.11.2014
Garrison, Kim, Wakefield (2012)
Gary Garrison, Sanghyun Kim, Robin Wakefield: Success factors for deploying
cloud computing. In: Communications of the ACM. Nr. 9, Jg. 55, 2012, S. 62-68
General Services Administration (2012)
General Services Administration: FedRAMP - Concept of Operations
(CONOPS). http://www.gsa.gov/graphics/staffoffices/FedRAMP_CONOPS.pdf,
Abruf am 04.12.2014
General Services Administration (2014)
General Services Administration: Continuous Monitoring Strategy & Guide.
http://www.gsa.gov/graphics/staffoffices/Continuous_Monitoring_Strategy_Gui
de_072712.pdf, Abruf am 04.12.2014
Gora (2009)
Stefan Gora: Security Audits. In: Datenschutz und Datensicherheit (DuD). Nr. 4,
Jg. 33, 2009, S. 238-246
Gottesdiener (2003)
Ellen Gottesdiener: Requirements by Collaboration: Getting It Right the First
Time. In: IEEE Software. Nr. 2, Jg. 20, 2003, S. 52-55
72
Grobauer, Walloschek, Stöcker (2011)
Bernd Grobauer, Tobias Walloschek, Elmar Stöcker: Understanding Cloud
Computing Vulnerabilities. In: Security Privacy. Nr. 2, Jg. 9, 2011, S. 50-57
Hale, Gamble (2013)
Matthew Hale, Rose Gamble: Building a Compliance Vocabulary to Embed
Security Controls in Cloud SLAs. In: IEEE (Hrsg.): 9th World Congress on
Services (SERVICES), Juni 28 - Juli 3, 2013, Santa Clara, CA, USA.
Washington, DC, USA 2013, S. 118-125
Hofmann, Schumacher (2014)
Georg Hofmann, Meike Schumacher: Studie zur Akzeptanz von Cloud
Computing. https://www.eurocloud.de/2012/news/cloud-akzeptanz/studie-cloudakzeptanz.html, Abruf am 18.11.2014
Hogben, Dekker (2012)
Giles Hogben, Marnix Dekker: Procure Secure - A guide to monitoring of
security service levels in cloud contracts.
http://www.enisa.europa.eu/activities/Resilience-and-CIIP/cloudcomputing/procure-secure-a-guide-to-monitoring-of-security-service-levels-incloud-contracts/at_download/fullReport, Abruf am 20.11.2014
International Organization for Standardization (2004)
International Organization for Standardization (Hrsg.): Conformity assessment Vocabulary and general principles. ISO 17000:2004. o.O. 2004
Jensen u. a. (2009)
Meiko Jensen, Jörg Schwenk, Nils Gruschka, Luigi Lo Iacono: On Technical
Security Issues in Cloud Computing. In: IEEE (Hrsg.): Proceedings of the 2009
IEEE International Conference on Cloud Computing (CLOUD 2009), September
21 - 25, 2009, Bangalore, Indien. Washington, DC, USA 2009, S. 109-116
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
73
Khan, Malluhi (2010)
Khaled Khan, Qutaibah Malluhi: Establishing Trust in Cloud Computing. In: IT
Professional. Nr. 5, Jg. 12, 2010, S. 20-27
Koehler, Anandasivam, Dan (2010)
Philip Koehler, Arun Anandasivam, Ma Dan: Cloud Services from a Consumer
Perspective. In: Association for Information Systems (Hrsg.): Proceedings of the
16th Americas Conference on Information Systems (AMCIS 2010), August 12 15, 2010, Lima, Peru. Atlanta, Georgia, USA 2010, S. 1-10
Kogan, Sudit, Vasarhelyi (1999)
Alexander Kogan, Ephraim Sudit, Miklos Vasarhelyi: Continuous Online
Auditing: A Program of Research. In: Journal of Information Systems. Nr. 2, Jg.
13, 1999, S. 87-103
Kunz, Niehues, Waldmann (2013)
Thomas Kunz, Peter Niehues, Ulrich Waldmann: Technische Unterstützung von
Audits bei Cloud-Betreibern. In: Datenschutz und Datensicherheit (DuD). Nr. 8,
Jg. 37, 2013, S. 521-525
Lansing, Sunyaev (2013)
Jens Lansing, Ali Sunyaev: Does Pain Result in Gain? Assessing Cloud Service
Certifications’ Effectiveness. In: Association for Information Systems (Hrsg.):
Proceedings of the 34th International Conference on Information Systems (ICIS
2013), Dezember 15 - 18, 2013, Mailand, Italien. Atlanta, Georgia, USA 2013,
S. 1-12
Lins (2014)
Sebastian Lins: Methoden und Modelle zur kontinuierlichen Auditierung von
Cloud-Services. Seminararbeit. Köln 2014
74
Lins u. a. (2015)
Sebastian Lins, Scott Thiebes, Stephan Schneider, Ali Sunyaev: What is Really
Going on at Your Cloud Service Provider? Creating Trustworthy Certifications
by Continuous Auditing. In: IEEE (Hrsg.): 48th Hawaii International Conference
on System Science, Januar 5 - 8, 2015, Kauai, Hawaii. Washington, DC, USA
2015, S. 5352-5361
Marston u. a. (2011)
Sean Marston, Zhi Li, Subhajyoti Bandyopadhyay, Juheng Zhang, Anand
Ghalsasi: Cloud Computing - The Business Perspective. In: Decision Support
Systems. Nr. 1, Jg. 51, 2011, S. 176-189
Meissner (2008)
Sebastian Meissner: Zertifizierungskriterien für das Datenschutzgütesiegel
EuroPriSe. In: Datenschutz und Datensicherheit (DuD). Nr. 8, Jg. 32, 2008, S.
525-531
Mell, Grance (2011)
Peter Mell, Timothy Grance: The NIST Definition of Cloud Computing.
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf, Abruf
am 04.01.2015
Montesino, Fenz (2011)
Raydel Montesino, Stefan Fenz: Information Security Automation: How Far Can
We Go? In: IEEE (Hrsg.): 6th International Conference on Availability,
Reliability and Security (ARES), August 22 - 26, 2011, Wien, Österreich.
Washington, DC, USA 2011, S. 280-285
Munoz, Mana (2013)
Antonio Munoz, Antonio Mana: Bridging the GAP between Software
Certification and Trusted Computing for Securing Cloud Computing. In: IEEE
(Hrsg.): 9th World Congress on Services (SERVICES), Juni 27 - Juli 2, 2013,
Santa Clara, CA, USA. Washington, DC, USA 2013, S. 103-110
75
National Institute of Standards and Technology (2013)
National Institute of Standards and Technology: Security and Privacy Controls
for Federal Information Systems and Organizations.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf,
Abruf am 16.12.2014
Office of the Government Chief Information Officer (2013)
Office of the Government Chief Information Officer: Practice Guide for
Procuring Cloud Services.
http://www.infocloud.gov.hk/themes/ogcio/media/practiceguideindividual/Practi
ce_Guide(2013-11)_EN.pdf, Abruf am 20.11.2014
Paulus (2011)
Sachar Paulus: Standards für Trusted Clouds. In: Datenschutz und
Datensicherheit (DuD). Nr. 5, Jg. 35, 2011, S. 317-321
Pearson (2013)
Siani Pearson: Privacy, Security and Trust in Cloud Computing. In: Siani
Pearson, George Yee (Hrsg.): Privacy and Security for Cloud Computing.
London 2013, S. 1-57
Pinkett (2004)
Fred Pinkett: Automating System Security Audits. In: Information Systems
Control Journal. Nr. 1, Jg. 4, 2004, S. 45-46
Rannenberg (1998)
Kai Rannenberg: Zertifizierung mehrseitiger IT-Sicherheit. Kriterien und
organisatorische Rahmenbedingungen. Braunschweig, Wiesbaden 1998
Rannenberg (2000)
Kai Rannenberg: IT Security Certification and Criteria - Progress, Problems and
Perspectives. In: Sihan Qing, Jan Eloff (Hrsg.): Proceedings of the IFIP TC11
15th Annual Working Conference on Information Security for Global
Information Infrastructures, August 22 - 24, 2000, Beijing, China. New York,
NY, USA 2000, S. 1-10
76
Sabetta, Bezzi, Kaluvuri (2012)
Antonino Sabetta, Michele Bezzi, Samuel Kaluvuri: Towards a Development
Environment to Orchestrate Services with Certified Security Properties. In:
ACM (Hrsg.): Proceedings of the 2012 ACM SIGSOFT Symposium on Industry
Day, Juni 25 - 28, 2012, Bertinoro, Italien. New York, NY, USA 2012, S. 1-4
Schneider, Lansing, Sunyaev (2013)
Stephan Schneider, Jens Lansing, Ali Sunyaev: Empfehlungen zur Gestaltung
von Cloud-Service-Zertifizierungen. In: Industrie Management. Nr. 4, Jg. 29,
2013, S. 13-17
Schneider, Lins (2015)
Stephan Schneider, Sebastian Lins: Dynamic Certification of Cloud Services. In:
Communications of the ACM. Noch nicht erschienen, voraussichtlich 2015, S.
1-4
Schneider u. a. (2014)
Stephan Schneider, Jens Lansing, Fangjian Gao, Ali Sunyaev: A Taxonomic
Perspective on Certification Schemes: Development of a Taxonomy for Cloud
Service Certification Criteria. In: IEEE (Hrsg.): 47th Hawaii International
Conference on System Sciences (HICSS), Januar 6 - 9, 2014, Waikoloa, USA.
Washington, DC, USA 2014, S. 4998-5007
Spanoudakis, Damiani, Mana (2012)
George Spanoudakis, Ernesto Damiani, Antonio Mana: Certifying Services in
Cloud: The Case for a Hybrid, Incremental and Multi-layer Approach. In: IEEE
(Hrsg.): 14th International Symposium on High-Assurance Systems Engineering
(HASE), Oktober 25 - 27, 2012, Omaha, USA. Washington, DC, USA 2012, S.
175-176
Sturm, Lansing, Sunyaev (2014)
Benjamin Sturm, Jens Lansing, Ali Sunyaev: Moving in the Right Direction?:
Mapping literature on Cloud Service Certifications’ Outcomes with
Practitioners’ Perceptions. In: Michel Avital, Jan Leimeister, Ulrike Schultze
(Hrsg.): 22nd European Conference on Information Systems (ECIS 2014), Juni 9
- 11, 2014, Tel Aviv, Israel. o. O. 2014, S. 1-17
77
Subashini, Kavitha (2011)
S. Subashini, V. Kavitha: Review: A Survey on Security Issues in Service
Delivery Models of Cloud Computing. In: Journal of Network and Computer
Applications. Nr. 1, Jg. 34, 2011, S. 1-11
Sunyaev, Schneider (2013)
Ali Sunyaev, Stephan Schneider: Cloud Services Certification. In:
Communications of the ACM. Nr. 2, Jg. 56, 2013, S. 33-36
Voßbein (2006)
Reinhard Voßbein: Prüfstandards für den Datenschutz - Hilfe für den
Datenschutzbeauftragten. In: Datenschutz und Datensicherheit (DuD). Nr. 11,
Jg. 30, 2006, S. 713-717
Windhorst, Sunyaev (2013)
Iryna Windhorst, Ali Sunyaev: Dynamic Certification of Cloud Services. In:
IEEE (Hrsg.): 8th International Conference on Availability, Reliability and
Security (ARES), September 2 - 6, 2013, Regensburg, Deutschland.
Washington, DC, USA 2013, S. 412-417
Yang u. a. (2006)
Shu-Chen Yang, Wan-Chiao Hung, Kai Sung, Cheng-Kiang Farn: Investigating
initial trust toward e-tailers from the elaboration likelihood model perspective.
In: Psychology & Marketing. Nr. 5, Jg. 23, 2006, S. 429-445
78
Anhang
A1. Zertifizierungskriterienkatalog
ZKL Zertifizierungskriterium
4 Wird ein standardisiertes Vorgehensmodell (z. B. ITIL oder COBIT) für die IT-Prozesse des
angebotenen Cloud-Services definiert und eingehalten? Besitzt der Cloud-Anbieter Zertifikate
dafür? Wenn ja, welche?
5 Ist ein Informationssicherheits-Managementsystem (ISMS) im Unternehmen des CloudAnbieters implementiert sowie nachhaltig gepflegt?
10 Existiert ein Datenschutzbeauftragter, der gegenüber Cloud-Kunden für seine Belange des
Datenschutzes und seinen Unterauftragnehmern gegenüber als Ansprechpartner zur Verfügung
steht?
11 Sind alle Mandanten eines Cloud-Services auf allen Ebenen des Cloud-Stacks, d. h.
Anwendung, Server, Netze, Storage etc., sicher und robust getrennt?
24 Ist die Grundkonfiguration für den Cloud-Server sicher erstellt? Wird also ein gehärtetes
Betriebssystem eingesetzt? Sind alle nicht benötigten Programme und Dienste abgeschaltet oder
deinstalliert?
25 Werden sämtliche Standardmaßnahmen für den Schutz des Cloud-Hosts, d. h. Host Firewalls,
Network-Intrusion-Prevention-System, Applikationsschutz, Antivirus, regelmäßige
Integritätsüberprüfungen wichtiger Systemdateien und Host-based Intrusion-Detection-Systems,
praktiziert?
31 Sind Sicherheitsmaßnahmen gegen Malware oder schadhafte Programmcodes, d. h.
Virenschutz, Trojaner-Detektion, Spam-Schutz etc., vorhanden?
32 Sind Sicherheitsmaßnahmen gegen netzbasierte Angriffe, d. h. IPS/IDS-Systeme, Firewall,
Application Layer Gateway etc., im Einsatz?
37 Ist die Kommunikation zwischen Cloud-Anbieter und -Nutzer mit einem robusten Algorithmus
verschlüsselt?
38 Ist die Kommunikation zwischen verschiedenen Cloud-Standorten mit einem robusten
Algorithmus verschlüsselt?
39 Wenn eine Leistung eines Sub-Cloud-Anbieters für einen Cloud-Service notwendig ist, wird
dann die Kommunikation mit diesem Sub-Cloud-Anbieter verschlüsselt?
40 Existiert eine redundante Vernetzung der Cloud-Rechenzentren?
42 Sind auf der I/PaaS-Plattform laufende Anwendungen von verschiedenen Cloud-Kunden durch
z. B. Sandboxing-Technologien voneinander isoliert?
46 Wird ein sicheres Patch-, Änderungs- und Release-Management durchgeführt (Sind
Abnahmekriterien für neue Informationssysteme und System-Upgrades etabliert? Finden
Eignungsprüfungen der Systeme vor der Abnahme statt?), damit Störungen im Betrieb
vermieden sowie Sicherheitslücken minimiert werden können?
48 Wurde die Patch-Verträglichkeit vor dem Einspielen in den Wirkbetrieb auf Testsystemen
sichergestellt?
50 Sind alle in der Cloud gespeicherten Kundendaten durch z. B. virtuelle Speicherbereiche,
Tagging etc. voneinander sicher isoliert?
51 Werden Daten, Software und Systeme basierend auf dem Datensicherungskonzept und der mit
Cloud-Kunden vereinbarten Backup-Politik regelmäßig gesichert und archiviert? Können
gesicherte Daten, Software und Systeme wiederhergestellt werden?
52 Gibt es beim Cloud-Anbieter einen Mechanismus, der sporadisch überprüft, ob die erzeugten
Datensicherungen zur Wiederherstellung verlorener Daten tatsächlich erfolgreich genutzt
79
werden können?
58 Werden kryptografische Maßnahmen vom Cloud-Anbieter unter der Voraussetzung eingesetzt,
dass alle Cloud-Kunden zugrundeliegenden relevanten Vereinbarungen, Gesetze und
Regulatorien eingehalten werden?
60 Wenn die gespeicherten Daten von Cloud-Anbieter verschlüsselt sind: Ist der für das
Schlüsselmanagement Verantwortliche fachlich geschult?
66 Werden alle Rollen und deren Rechte im Rahmen des Zugriffsrechtemanagements regelmäßig
überprüft?
71 Stellt der Cloud-Anbieter seinen Kunden die Möglichkeit bereit, alle im SLA vereinbarten
messbaren Größen einschließlich der Verfügbarkeit des angebotenen Services durch einen
neutralen Dritte kontinuierlich zu überwachen?
72 Wird der Cloud-Service 24/7 gegenüber Angriffen und Sicherheitsvorfällen umfassend
überwacht?
73 Können Angriffe und Sicherheitsvorfälle rechtzeitig erkannt und zeitnahe Reaktion eingeleitet
werden?
75 Werden alle Aktivitäten von Administratoren protokolliert und überwacht, damit
nachvollziehbar ist, wann wer welche Änderungen am Service vorgenommen hat?
76 Ist das handlungsfähige Team für Security-Incident-Handling und Trouble-Shooting 24/7
erreichbar?
77 Werden die betroffenen Kunden rechtzeitig über entsprechende Sicherheitslücken, -brüche oder
-vorfälle informiert?
79 Stehen alle relevanten Sicherheits-Protokolldaten in einem für die maschinelle Verarbeitung
geeigneten Format zur Verfügung?
83 Werden Notfallmanagement-Pläne regelmäßig getestet und erneuert, um deren Aktualität und
Wirksamkeit zu garantieren?
90 Sind standardisierte oder offengelegte Schnittstellen (API und Protokolle) für den CloudService, einschließlich seine Middleware und Speicherung, im Einsatz?
91 Werden die Cloud-Kunden regelmäßig über Sicherheitsmaßnahmen, Änderungen im ITSicherheitsmanagement, Sicherheitsvorfälle, die Ergebnisse durchgeführter
Informationssicherheitsrevision (IS-Revisionen) und Penetrationstests in Kenntnis gesetzt?
92 Werden beim Cloud-Anbieter regelmäßig Penetrationstests durchgeführt?
93 Erfüllt ein interner Sicherheitsprüfer/Auditor folgende Bedingungen:
1) Er verfügt über eine geeignete Qualifikation.
2) Er ist objektiv und unparteiisch.
3) Er war nicht an der Erstellung der zu prüfenden Gegenstände beteiligt.
100 Wird offengelegt, wo (Land und/oder Region) die Kundendaten gespeichert und verarbeitet
werden?
134 Gibt es einen Risikomanagementplan des Cloud-Anbieters dahingehend, welche angemessenen
Maßnahmen, Ressourcen, Verantwortlichkeiten und Priorisierungen für die Verwaltung der
Informationssicherheit bestehen? Wird dieser Plan unter Berücksichtigung neu auftretender
Sicherheitsherausforderungen kontinuierlich aktualisiert und verbessert?
156 Sind fachliche Kenntnisse und Fähigkeiten der Mitarbeiter des Cloud-Anbieters im Bereich der
Sicherheit durch ein anerkanntes Rahmenwerk wie CISA, CISSP, CISM, ITIL oder CPP
zertifiziert?
159 Können die Protokolle über die Ausbildung, Schulung, Fähigkeiten, Erfahrung und
Qualifikationen der Mitarbeiter aufrechterhalten werden?
160 Werden interne Audits zu den geplanten Intervallen durchgeführt, um zu überprüfen, ob die
Kontrollziele, Kontrolltätigkeiten, Prozesse und Prozeduren des ISMS: (ISO 10, 13)
1) die Anforderungen der ISO-27001 und anderen relevanten Vorschriften erfüllen;
80
2) die identifizierten Informationssicherheitsanforderungen leisten; und
3) wie erwartet funktionieren?
173 Werden passende Kontakte mit relevanten Behörden in Bezug auf die Sicherheit seitens des
Cloud-Anbieters gepflegt?
174 Werden geeignete Kontakte mit bestimmten Interessengruppen, anderen Spezialistenforen für
Sicherheit oder Fachverbänden seitens des Cloud-Anbieters gepflegt?
202 Sind Netzwerke des Cloud-Anbieters angemessen verwaltet und kontrolliert, um sie gegen
Bedrohungen zu schützen und die Sicherheit für alle Systeme und Applikationen, die das
Netzwerk nutzt, sowie die Daten beim Versand zu garantieren?
214 Kann die Integrität der öffentlich zugänglichen Information gewährleistet werden, um eine
unbefugte Modifikation auszuschließen?
216 Sind die Uhren aller relevanten Informationsverarbeitungssysteme des Cloud-Anbieters mit
einer anerkannten Zeitquellen synchronisiert?
219 Wird der logische Zugriff auf Diagnose- und Konfigurationsschnittstellen des Cloud-Anbieters
kontrolliert?
227 Ist die Verwendung von Systemprogrammen, mit denen System- und Softwareeinstellungen
überschrieben werden könnten, eingeschränkt und kontrolliert?
228 Werden inaktive Sessions nach einem vordefinierten Zeitraums der Inaktivität automatisch
geschlossen?
230 Sind Beschränkungen der Verbindungsdauer für die Anwendungen mit hohem Risiko des
Cloud-Anbieters im Einsatz?
241 Wenn ein Betriebssystem des Cloud-Anbieters geändert ist: Werden entsprechende
geschäftskritische Applikationen überprüft und getestet, um eine nachteilige Auswirkung auf
organisatorische Operationen oder die Sicherheit auszuschließen sind?
248 Werden Informationssysteme des Cloud-Anbieters regelmäßig dahingehend überprüft, ob
bestimmte Sicherheitsstandards erfüllt werden können?
251 Kann die finanzielle Überlebensfähigkeit, Bonität und Zahlungsfähigkeit des Cloud-Anbieters
sichergestellt werden?
282 Steht die Testbestätigung des Notfallmanagements (Business Continuity Management) des
Cloud-Anbieters für Cloud-Kunden zur Einsicht bereit?
283 Existiert ein Sicherheitsmanager im Unternehmen des Cloud-Anbieters, der die Durchsetzung
der Sicherheitsmaßnahmen leitet und gewährleistet? Kann sichergestellt werden, dass der
Sicherheitsmanager des Cloud-Anbieters direkt an seine strategische Unternehmensleitung
berichtet?
291 Ist die Historie für den Incident-Response (IR)-Prozess des Cloud-Anbieters dokumentiert und
für Cloud-Kunden zugänglich?
294 Stammen die Technologien und Produkte zur Verschlüsselung, Entschlüsselung, Signing und
Verifizierung des Cloud-Services aus zuverlässigen Quellen?
299 Ist die Test- bzw. Entwicklungsumgebung eines Cloud-Services von seiner Datenspeicherungbzw. Workload-Umgebung sicher separiert?
303 Werden Backup- und Ausfallsicherungssysteme entsprechend bereinigt, wenn VM-Images in
der Cloud gelöscht werden?
309 Ist die Netzwerkverbindung des Cloud-Anbieters zuverlässig in dem Sinn, dass die
Netzwerkverbindung ausreichend Bandbreite und eine geringe Latenzzeit für den Im- und
Export der erwarteten Menge an Kundendaten besitzt?
322 Stehen SLAs zwischen Cloud-Anbieter und -Kunden in einem standardisierten und für die
maschinelle Verarbeitung geeigneten Format bereit, um einerseits die automatisierte
Auswertung aller relevanten Voraussetzungen zu unterstützen, andererseits die Auswahl und
damit die Allokation der benötigten Ressourcen zu beschleunigen?
81
323 Werden die Aktivitäten von Rollen, die das Recht besitzen, Daten zu erstellen, einzusehen,
bekanntzugeben, zu transportieren und vernichten zu dürfen, überwacht und kontrolliert?
362 Verfügt der Cloud-Anbieter über ein Availability Management Information System, das die
Performance des angebotenen Cloud-Services ermittelt?
Werden Informationen des AMIS in Echtzeit auf der Webseite des Cloud-Anbieters publiziert?
366 Werden alle Events, die den Geschäftsbetrieb des Kunden tangieren und nicht auf technischer
Ebene automatisch behandelt werden, durch den Einsatz geeigneter Mechanismen wie EventDriven Messaging Patterns an die Kunden weitergeleitet, damit dieser entsprechende
Maßnahmen initiieren kann?
404 Besitzt der offerierte Cloud-Service eine schnelle Skalierungsfähigkeit; kann er also nach
Bedarf schnell und elastisch zur Verfügung gestellt werden?
57k Schlüsselwechsel müssen regelmäßig durchgeführt werden. Man muss regelmäßig auf die
Aktualität der verwendeten Schlüssel überprüfen.
A2. Informationsblatt und Anforderungskatalog für den Workshop im
Forschungsumfeld
Aufgrund seines Seitenumfangs befindet sich dieser Anhang auf der beigefügten CD.
A3. Transkript des Expertenworkshops
Aufgrund seines Seitenumfangs befindet sich dieser Anhang auf der beigefügten CD.
A4. Codierung der Auswahl zielführender Cloud-Publikationen
Aufgrund seines Seitenumfangs befindet sich dieser Anhang auf der beigefügten CD.
A5. Codierung der Herleitung der Kundenanforderungen
Aufgrund seines Seitenumfangs befindet sich dieser Anhang auf der beigefügten CD.
A6. Transkript des Workshops im Forschungsumfeld
Aufgrund seines Seitenumfangs befindet sich dieser Anhang auf der beigefügten CD.
A7. Inhalte der beigefügten CD-ROM
Auf der beigefügten CD-ROM befinden sich die folgenden Dokumente:
1. Masterarbeit im Word-Format (*.doc)
2. Masterarbeit im PDF-Format (*.pdf)
3. Auswertung des Expertenworkshops als NVivo-Projektdatei
4. Verwendete Quellen als Citavi-Projektordner
82
5. Anhänge A2-A6

Gebietsverkaufsleiter mit dem Potenzial zum Vertriebsleiter (m/w)

Zwei Buchstaben. Tausend neue Möglichkeiten. Eine große Zukunft.

Vertriebssachbearbeiter After Sales (m/w)

Sicher in die Cloud – aber wie?

Java Entwickler AEM/CQ5 (m/w)

Daten- & Fakten-Sheet - YOUR SL

Für unseren Standort Wetzlar suchen wir möglichst umgehend

Bachelor-/Masterarbeit

Große Klappe, viel dahinter!