Database-as-a-Service für kleine und mittlere …...Vorwort...

Till HaselmannGottfried Vossen

25. November 2010

Database-as-a-Servicefür kleine und mittlereUnternehmen

Working Paper No. 3

Till HaselmannGottfried Vossen

Database-as-a-Service fürkleine und mittlere Unternehmen

Ein praxistauglicher Leitfaden für KMU,die „in die Cloud gehen“ möchten

DBIS GroupInstitut für WirtschaftinformatikWestfälische Wilhelms-Universität MünsterLeonardo-Campus 3D-48149 Münster

http://dbis-group.uni-muenster.de/


http://www.wi.uni-muenster.de/institut/

http://www.uni-muenster.de/


Prof. Dr. Gottfried Vossen, Till HaselmannLehrstuhl für InformatikInstitut für WirtschaftsinformatikWestfälische Wilhelms-Universität MünsterLeonardo-Campus 3D-48149 Münsterhttp://dbis-group.uni-muenster.de/

Bibliografische Information der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1868-0801

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere dieder Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und derSpeicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,vorbehalten. Eine Vervielfältigung dies Werkes oder von Teilen dieses Werkes ist auch im Ein-zelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bun-desrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sieist in der Regel vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungendes Urheberrechtsgesetzes.

Copyright © 2010 Förderkreis der Angewandten Informatik an der Westfälischen Wilhelms-Universität Münster e. V.Einsteinstraße 6248149 MünsterDeutschland2010

Printed in Germany

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesemWerk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Na-men im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wärenund daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größ-ter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhaf-te Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftungübernehmen.


http://dnb.ddb.de

Vorwort

Der Begriff „Cloud-Computing“ ist derzeit – zumindest innerhalb der IT-Welt – in aller Munde.Nach Ansicht bekannter Branchengrößen stellt das Cloud-Computing einen grundsätzlichenRichtungswechsel für das Angebot und den Einsatz von IT dar – einige sprechen sogar voneiner Revolution. Angebote aus der Cloud seien nach Expertenmeinung besonders für kleineund mittlere Unternehmen (KMU) interessant, weil diese überproportional profitieren könnten.Zum jetzigen Zeitpunkt ist allerdings unklar, wie dies von den KMU selbst gesehen wird. Auchist die Einführung von Cloud-Services in KMU anders anzugehen als für große Unternehmen.Dieser Leitfaden untersucht die Frage, wie KMU vorgehen sollten, um Cloud-Computing

einzuführen und ob es sich überhaupt lohnt. Dabei liegt der Fokus auf dem Bereich Cloud-Datenbanken, im Englischen als Database-as-a-Service bezeichnet. Dieser Themenfokus sollteaber auf keinen Fall abschrecken: Die meisten Ergebnisse dieses Berichts sind nämlich leicht zuverallgemeinern und können ebenso für andere Cloud-Projekte verwendet werden.Der vorliegende Leitfaden ist ein weiterer Arbeitsbericht, der durch den Förderkreis für An-

gewandte Informatik an der Westfälischen Wilhelms-Universität Münster finanziert wurde. DerFörderkreis wird von rund 30 Unternehmen aus der Region und der Industrie- und Handels-kammer Nord Westfalen getragen. Sein Hauptziel ist die Förderung der praxisorientierten For-schung und Lehre, sowie der schnelle Wissenstransfer. Um dieses sicherzustellen, gelingt esregelmäßig, interessierte Mitgliedsunternehmen zu finden, die sich aktiv am Projekt beteili-gen. Großer Dank gilt daher diesen Unternehmen für ihre Beteiligung am Projekt und die Be-reitschaft der Mitarbeiter, für Gesprächsrunden, individuelle Interviews und Erhebungen perFragebogen zur Verfügung zu stehen. Diese Bereitschaft bildet die Basis des Leitfadens.Besonderer Dank gebührt dem Leiter der Arbeitsgruppe für Datenbanken und Informations-

systeme (DBIS Group), Herrn Professor Dr. Gottfried Vossen, und seinem Mitarbeiter, HerrnTill Haselmann, für die außerordentlich engagierte und praxisnahe Umsetzung des Projektes.Bei der Darstellung der Inhalte wurde versucht, die Waage zu halten zwischen detaillierten

Erläuterungen und Praxisrelevanz. Zusätzlich haben wir zahlreiche Maßnahmen ergriffen, umein schnelles Erfassen der Inhalte zu ermöglichen: Regelmäßige Zusammenfassungen, Einschü-be, die „Das Wichtigste in Kürze“ wiedergeben und Fragenkataloge am Ende der Kapitel bietenhoch aggregierte Informationen. Zudem liegt diesem Bericht ein Faltblatt bei, das als schnellerÜberblick und Gedächtnisstütze dient. Wir wünschen viel Spaß bei der Lektüre.

Martin KittnerVorsitzender des Förderkreisesfür Angewandte Informatik

Dr. Christoph AsmacherIndustrie- und HandelskammerNord Westfalen

DBIS GroupWWU Münster � i

Inhaltsverzeichnis

Executive Summary 1

1 Einleitung 3

2 Grundlagen des Cloud-Computing 52.1 Was ist Cloud-Computing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Historische Entwicklung und Grundlagen . . . . . . . . . . . . . . . . . . 52.1.2 Evolution zum Cloud-Computing . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Fünf zentrale Charakteristika von Cloud-Computing . . . . . . . . . . . . . 102.1.4 Servicemodelle: XaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.5 Arten des Cloud-Betriebs . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Abgrenzung zum klassischen IT-Outsourcing . . . . . . . . . . . . . . . . . . . . 182.3 Spezialfall Database-as-a-Service (DaaS) . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Definition und Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.2 Der Cloud-Aspekt von DaaS . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.3 Mangelnde Elastizität der Daten . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Zusammenfassung der Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Grundsatzentscheidung „Cloud oder nicht?“ 253.1 Cloud Computing in vier Dimensionen . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Wirtschaftliche Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.2 Technische Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.3 Rechtliche Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1.4 Organisatorische Dimension . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Typische Szenarien für Cloud-Nutzung durch KMU . . . . . . . . . . . . . . . . . 353.2.1 Szenario 1: KMU↔ Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.2 Szenario 2: KMU↔ Cloud↔ Endkunde . . . . . . . . . . . . . . . . . . . 37

3.3 Entwicklung einer Cloud-Strategie und deren Umsetzung . . . . . . . . . . . . . . 383.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Auswahl eines DaaS-Anbieters 434.1 Wirtschaftliche Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.1 Reputation des Anbieters . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1.2 Preismodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.3 Lock-in-Effekte über die Daten . . . . . . . . . . . . . . . . . . . . . . . 46

DBIS GroupWWU Münster � iii

Inhaltsverzeichnis

4.1.4 Lock-in-Effekte über die Prozesse . . . . . . . . . . . . . . . . . . . . . . 474.2 Technische Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 Sicherung und Wiederherstellung von Daten . . . . . . . . . . . . . . . . 484.2.2 Leistungsfähigkeit der Cloud . . . . . . . . . . . . . . . . . . . . . . . . 494.2.3 Integration in bestehende Systeme . . . . . . . . . . . . . . . . . . . . . 51

4.3 Rechtliche Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.1 Erfüllung der gesetzlichen Anforderungen . . . . . . . . . . . . . . . . . . 524.3.2 Ausstiegsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3.3 Weitere Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3.4 Handlungsempfehlungen zur rechtlichen Dimension . . . . . . . . . . . . . 55

4.4 Organisatorische Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4.1 Vorgehen zur und Dokumentation der Anbieterwahl . . . . . . . . . . . . . 554.4.2 Support-Leistungen des Anbieters . . . . . . . . . . . . . . . . . . . . . . 564.4.3 Kommunikation mit dem Anbieter im Problemfall . . . . . . . . . . . . . . 58

4.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 Sicherheitaspekte von DaaS-Angeboten 615.1 Vorgehen für die Bewertung der Risiken in der Cloud . . . . . . . . . . . . . . . . 62

5.1.1 Analyse der eigenen Anforderungen . . . . . . . . . . . . . . . . . . . . . 625.1.2 Analyse der Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Das kleine Einmaleins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3 Organisatorische Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3.1 Sensibilisierung der Mitarbeiter für das Thema . . . . . . . . . . . . . . . . 665.3.2 Integration in ein bestehendes Sicherheitskonzept . . . . . . . . . . . . . . 675.3.3 Herstellen einer Vertrauensbeziehung zwischen Cloud-Konsument und Cloud-

Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.4 Verwaltung von kryptographischen Schlüsseln . . . . . . . . . . . . . . . . 685.3.5 Einsatz von Service-Level-Agreements (SLAs) . . . . . . . . . . . . . . . . 695.3.6 Überprüfung und Einhaltung des Sicherheitskonzepts . . . . . . . . . . . . 695.3.7 Einbindung des Anbieters . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.4 Technische Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.1 Sicherheit der Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.2 Sicherheit und Schutz der Daten . . . . . . . . . . . . . . . . . . . . . . . 73

5.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6 Zusammenfassung 79

Literaturverzeichnis 81

iv � DBIS GroupWWU Münster

Abkürzungsverzeichnis

AES Advanced Encryption StandardAPI Application Programming InterfaceASP Application Service ProviderBDSG BundesdatenschutzgesetzBGP Border Gateway ProtocolBSI Bundesamt für Sicherheit in der Informations-

technikCAPEX Capital ExpenditureCC Cloud-ComputingCDN Content Delivery NetworkCDS Cloud Data ServiceCERT Computer Emergency Response TeamCIO Chief Information OfficerCISO Chief Information Security OfficerCOO Chief Operating OfficerCPU Central Processing UnitCSIRT Computer Security Incident Response TeamCSV Comma-separated ValuesDaaS Database-as-a-ServiceDBMS DatenbankmanagementsystemDBS DatenbanksystemDNS Domain Name SystemDoS Denial-of-ServiceDSG DatenschutzgesetzEC2 Elastic Compute CloudEDoS Economic-Denial-of-SustainabilityHP Hewlett-PackardHTTP Hypertext Transfer ProtocolIaaS Infrastructure-as-a-ServiceIEC International Electrotechnical CommissionIPS Intrusion Prevention SystemIS InformationssystemISMS Informationssicherheits-ManagementsystemISO International Organization for StandardizationISO/IEC 27001 IT-Sicherheitsverfahren – ISMS –

AnforderungenISO/IEC 27002 IT-Sicherheitsverfahren – Leit-

faden für das Informationssicherheits-Management

ISP Internet Service ProviderIT InformationstechnikITIL IT Infrastructure LibraryJSON JavaScript Object NotationKMU kleines oder mittleres UnternehmenLAN Local Area NetworkMAC Message Authentication CodeMPLS Multiprotocol Label SwitchingNDA Non-disclosure AgreementNIST National Institute of Standards and Techno-

logyNoSQL Not only SQLNRW Nordrhein-WestfalenOLTP Online Transaction ProcessingOPEX Operational ExpenditurePaaS Platform-as-a-ServicePDA Personal Digital AssistantPDF Portable Document FormatRDBS relationales DatenbanksystemRDS Relational Database ServiceREST Representational State TransferRSS Really Simple SyndicationS3 Simple Storage ServiceSaaS Software-as-a-ServiceSAS 70 Statement on Auditing Standards No. 70SLA Service-Level-AgreementSOA Service-oriented ArchitectureSPI Software, Plattform und InfrastrukturSQL Structured Query LanguageSSL Secure Socket LayerSSO Single Sign OnTCO Total Cost of OwnershipTLS Transport Layer SecurityURL Uniform Resource LocatorVM virtuelle MaschineVPN Virtual Private NetworkWAN Wide Area NetworkXaaS Anything-as-a-ServiceXML Extensible Markup Language

DBIS GroupWWU Münster � v

Executive SummaryDieser Leitfaden richtet sich an Entscheider und IT-Leiter in kleinen und mittleren Unterneh-men (KMU), die über den Einsatz von Database-as-a-Service-Angeboten bzw. anderen Cloud-Diensten im eigenen Unternehmen nachdenken. Das Dokument gibt einen ersten Eindruckvon den Einsatzmöglichkeiten von Cloud-Computing. Insbesondere werden die zu erwarten-den Maßnahmen beschrieben, die mit der Einführung von Cloud-Computing im Unternehmeneinhergehen. Dabei werden – soweit möglich – konkrete Schritte oder Maßnahmen empfohlen.Wegen der hohen Diversität der Cloud-Dienste kann jedoch keine allgemeingültige Empfehlungfür oder gegen die Cloud gegeben werden.Cloud-Computing ist keine technische Revolution, sondern eine neuartige Kombination aus

vielen bekannten und einigen neuen Ansätzen. Charakterisiert wird es durch fünf Merkmale:1. Gemeinsame Nutzung physischer Ressourcen durch mehrere Anwender2. Unverzügliche Anpassbarkeit an den dynamischen Ressourcenbedarf3. Selbstbedienung nach Bedarf4. Umfassender Netzwerkzugriff5. Messung der Servicenutzung

Die Definition des Begriffs anhand dieser fünf Merkmale hat sich in der Fachwelt etabliert. Einedirekte Konsequenz aus diesen Merkmalen ist die Anwendung von Virtualisierungstechnologi-en, so dass manchmal auch dieser Aspekt genannt wird. In Folge arbeitet der Cloud-Anwendernur noch mit virtuellen Ressourcen, die vom Anbieter auf physische Ressourcen abgebildetwerden.Im Bereich des Cloud-Computing unterscheidet man typischerweise drei verschiedene Ser-

vicemodelle: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) sowie Software-Servicemodelleas-a-Service (SaaS). Database-as-a-Service (DaaS), der Fokus dieses Leitfadens, bezeichnet eine

Klasse von Diensten, die Funktionalitäten eines Datenbanksystems in der Cloud bereitstellen.DaaS kann dabei basierend auf einem der drei Servicemodelle angeboten werden. Die meistenAspekte aus diesem Leitfaden lassen sich direkt auf andere Arten von Diensten übertragen undsind nicht spezifisch für DaaS. Es gibt zudem vier verschiedene Arten des Cloud-Betriebs: dieöffentliche und die nichtöffentliche Cloud sowie die Community-Cloud und die hybride Cloud.Trotz der vielen neuen Begriffe ist Cloud-Computing nicht allzu verschieden vom klassischenIT-Outsourcing. Allerdings verschiebt sich die Gewichtung der zu beachtenden Aspekte.Die Betrachtung von Cloud-Computing geschieht in vier Dimensionen: wirtschaftlich, tech-

nisch, rechtlich und organisatorisch. Wirtschaftlich kann Cloud-Computing je nach Anwen-dungsfall sehr attraktiv sein – muss es aber auch nicht. Insbesondere für maßgeschneiderte

DimensionenCloud-Dienste, die von der „Stangenware“ abweichen, fordern die Anbieter hohe Gebühren,so dass die Vorteile schnell schwinden. Technisch birgt Cloud-Computing für das Anwender-unternehmen nur wenig wirklich neue Herausforderungen, fordert aber oft eine Anpassung

DBIS GroupWWU Münster � 1

Executive Summary

bestehender Systeme. Organisatorisch erfordert es stringente Abläufe, die gegebenenfalls imUnternehmen erst noch einzuführen sind. Das Hauptproblem ist jedoch die rechtliche Unsicher-heit, die der Tatsache geschuldet ist, dass die meisten Aspekte des Cloud-Computing juristischnoch ungeklärt sind. In jedem Fall muss auf Managementebene eine Cloud-Strategie entwickeltwerden. Sie ist eine essentielle Voraussetzung für jedes Cloud-Projekt.Bei der Auswahl des Anbieters müssen alle vier Dimensionen des Cloud-Computing betrach-

tet werden. Besondere Aufmerksamkeit sollte den erwarteten Lock-in-Effekten, der Integrationin bestehende Systeme und der Erfüllung rechtlicher Rahmenbedingungen gewidmet werden.Auch die Support-Leistungen und die Kommunikation mit dem Anbieter sind wichtige Aspekte.Auf jeden Fall ist ein strukturiertes Vorgehen zur Anbieterauswahl inklusive Dokumentation ge-fordert. Darüber hinaus muss eine regelmäßige Überprüfung des Marktes auf Änderungen stattfinden, um neue, bessere Angebote zu identifizieren.Die Sicherheit in der Cloud ist für alle Unternehmen ein zentrales Thema und muss explizit in

der Cloud-Strategie behandelt werden. Einige einfache Maßnahmen verhelfen bereits zu einerSicherheit soliden Grundsicherheit. Selbstverständlich müssen die eigenen Anforderungen an die Sicher-

heit im Vorfeld genau geklärt werden. Aus technischer Sicht müssen sowohl die Infrastrukturals auch die Daten geschützt werden. Ansätze für ersteres sind bekannt, der Aspekt der Daten-sicherheit stellt oft eine größere Hürde dar, da viele Anbieter nur ein durchschnittliches, aberkein hohes Schutzniveau erbringen. Trotz ungeklärter technischer Fragestellungen überwie-gen die organisatorischen Probleme. Unter anderem müssen die Mitarbeiter sensibilisiert undgeschult sowie bestehende und neue Sicherheitskonzepte integriert werden. Insgesamt ist dieSicherheit von Cloud-Diensten nicht notwendigerweise niedriger als von Lösungen im eigenenHaus.Beim Cloud-Computing verhält es sich nicht anders als bei anderen Fragestellungen der IT:

der Einsatz kann sehr sinnvoll sein, aber dies ist abhängig vom konkreten Szenario. Auch einsicherer und zuverlässiger Betrieb ist möglich. Je höher allerdings die Anforderungen an denDienstleister werden, desto unattraktiver wird eine Cloud-Lösung. Als Faustregel lässt sich da-her festhalten, dass Cloud-Computing vor allem für standardisierte Produkte attraktiv ist. Trotz-dem sollte sich jedes Unternehmen mit dem Thema auseinander setzen und eine individuelleCloud-Strategie erarbeiten – selbst wenn das Ergebnis die Festlegung ist, dass Cloud-Computingvermieden wird.

2 � DBIS GroupWWU Münster

1 Einleitung

Die Begriffe „Cloud-Computing“ und „die Cloud“ sind derzeit in aller Munde. Einige bezeichnendamit tatsächliche Computing-Dienste, also den Bezug reiner Rechenleistung z. B. in Form vonvirtuellenMaschinen über das Internet. Amazons Dienst Simple Storage Service (S3) ist in dieserDisziplin ein Pionier, viele andere Hosting-Anbieter haben inzwischen ähnliches im Programm.Für andere umfasst der Begriff Cloud-Computing jedoch jegliche Webapplikation, die nicht aufeigener Hardware läuft. Somit ist alles, was heutzutage unter die Stichworte „Web 2.0“ bzw.„Dynamic Web“ fällt, Cloud-Computing. Eine umgangssprachliche Definition zeigt anschaulichdie breite Spannweite des Begriffs:

“Cloud computing is using the internet to access someone else’s software runningon someone else’s hardware in someone else’s data center while paying only forwhat you use.” – Lewis Cunningham1

Ein erstes Ziel dieses Leitfadens ist deshalb die Begriffsklärung und die Abgrenzung des Kon-zepts. Zusätzlich liegt der Fokus in diesem Leitfaden auf Database-as-a-Service (DaaS), alsoder Klasse von Cloud-Datenbankdiensten. Nichtsdestotrotz sind viele der behandelten Aspekteallgemeingültig für Cloud-Computing an sich. Dieser Leitfaden behandelt die Grundlagen inKapitel 2.Nachdem ein Grundverständnis der Begrifflichkeiten geschaffen wurde, können die Chancen

und Risiken in den Vordergrund treten. Cloud-Computing wird von allen Anbietern als Univer-sallösung zur Kosteneinsparung bei gleichzeitigem Übertragen des Risikos beworben. Das diesnicht so sein muss, wird schnell klar, wenn die Angebote einem kritischen Blick unterzogenwerden. Auch ein Blick auf die rechtlichen Anforderungen ist ernüchternd. Kapitel 3 widmetsich der Grundsatzfrage, ob ein Unternehmen den Schritt in die Cloud wagen soll oder nicht,und thematisiert unter anderem diese Aspekte.Hat sich ein Unternehmen für eine Cloud-Lösung entschieden, so ist die Frage, welcher An-

bieter und welches Angebot am geeignetsten ist. Dabei ist die Auswahl des richtigen Anbietersalles andere als einfach. Kapitel 4 gibt einige wichtige Handlungsempfehlungen für die best-mögliche Wahl.Schließlich spielt die Sicherheit für die meisten Cloud-Anwender eine entscheidende Rolle.

Viele Unternehmen trauen sich nicht, eine Cloud-Lösung einzusetzen, weil sie die Befürchtunghaben, ihre Daten könnten nicht mehr sicher sein. Welche Ängste in dieser Hinsicht berechtigtsind und welche zerstreut werden können, zeigt das Kapitel 5. Die Struktur dieses Berichts wirdin der Abbildung 1.1 visualisiert. Die Kreise bezeichnen dabei die entsprechenden Kapitel imBericht.1http://it.toolbox.com/blogs/oracle-guide/cloud-computing-defined-28433


http://it.toolbox.com/blogs/oracle-guide/cloud-computing-defined-28433

1 Einleitung

Zusammen-fassung

Sicherheit inder Cloud

Auswahl des Anbieters

Grundsatz-entscheidung

Grundlagen

2 3 4 5 6

Abbildung 1.1: Struktur des Berichts mit Kapitelnummern.

Dieser Leitfaden richtet sich an Entscheider und IT-Leiter in kleinen und mittleren Unterneh-men (KMU), die über den Einsatz von Database-as-a-Service-Angeboten bzw. anderen Cloud-Diensten im eigenen Unternehmen nachdenken. Während des gesamten Leitfadens wird daher– wo nötig – auf Database-as-a-Service fokussiert. Außerdem sind die Empfehlungen vor demHintergrund der Situation von KMU entwickelt worden. Viele Aussagen sind jedoch auch aufbeliebige Cloud-Dienste oder größere Unternehmen verallgemeinerbar. Alle Empfehlungen zurechtlichen Fragestellungen sind nur als informative Hinweise zu sehen. Die Autoren könnenkeine Rechtsberatung bieten und weisen ausdrücklich darauf hin, dass alle problematischenrechtlichen Fragen mit ordentlichem Rechtsbeistand zu klären sind.Wenn bereits ein gutes Verständnis von Cloud-Computing vorhanden ist oder gar die Ent-

scheidung für den Schritt in die Cloud schon getroffen wurde, so kann direkt im Kapitel 3 bzw.Kapitel 4 eingestiegen werden. Ansonsten empfiehlt sich die Lektüre des Leitfadens von Anfangan. Die wichtigsten Punkte der Kapitel 3, 4 und 5 werden jeweils am Ende des Kapitels in Formvon zehn Leitfragen aufbereitet dargestellt.

..Tipp:Wenn Sie diesen Bericht als PDF am Bildschirm lesen, so können Sie oft auf URLs,Abkürzungen oder Verweise klicken, um direkt zur entsprechenden Stelle zu springen.Probieren Sie es doch einfach direkt bei „URL“ und „PDF“ aus.


2 Grundlagen des Cloud-Computing

..

Das Wichtigste in Kürze

� Cloud-Computing ist keine technischeRevolution, aber eine neue Kombination ausBekanntem und Neuem.

� Es gibt drei Servicemodelle: IaaS, PaaS, SaaS.� DaaS bezeichnet eine Klasse von Cloud-Diensten,die Funktionalitäten eines DBS bereitstellen.

� Es gibt vier Arten des Cloud-Betriebs: dieöffentliche und nichtöffentliche Cloud, dieCommunity-Cloud sowie die hybride Cloud.

� Cloud-Computing ist ähnlich dem klassischenIT-Outsourcing, verschiebt aber die Gewichtungder problematischen Aspekte.

In diesem Abschnitt wird ein kurzer Über-blick über den Themenkomplex „Cloud-Computing“ gegeben, um eine Grundlagefür die späteren Kapitel zu schaffen. Dazuwerden zuerst die Grundlagen des Cloud-Computings behandelt einschließlich eineskurzen historischen Abrisses der Entwick-lung bis dato. Im Anschluss erfolgt eine Ab-grenzung zum klassischen IT-Outsourcing.Entsprechend dem Thema dieses Leitfadenswird dann auf den Spezialfall Database-as-a-Service (DaaS) fokussiert.

2.1 Wasist Cloud-Computing?

Der Begriff „Cloud-Computing“ ist derzeitin aller Munde und wird als Symbol für eine bahnbrechende Neuerung verwendet. Bei vielenals revolutionär beworbenen Merkmalen des Cloud-Computings handelt es sich aber eigentlichum alten Wein in neuen Schläuchen. Um die tatsächlich neuartigen Facetten unterscheidenzu können, beginnt dieses Kapitel daher mit einem kurzen Überblick über die historischenVorläufer des Cloud-Computings. Dabei werden relevante Konzepte dargestellt, die sich heutein leicht abgewandelter oder sogar identischer Form im Rahmen des Cloud-Computings wiederfinden.Im Anschluss wird eine generelle Definition des Begriffs gegeben und die relevanten Kon-

zepte und Begrifflichkeiten des Themenfelds erklärt. Darauf aufbauend werden die für kleineund mittlere Unternehmen (KMU) relevanten Aspekte des Cloud-Computings anhand von vierDimensionen vorgestellt, die eine strukturierte Betrachtung des komplexen Felds ermöglichen.

2.1.1 Historische Entwicklung und Grundlagen

Bereits früh in den 1960er Jahren kamen erste Überlegungen auf, dass große Berechnungspro-bleme effizienter lösbar sein könnten, wenn man sie in viele kleine Teile zerlegt und getrenntberechnet. Dies führte zu der Idee, das Problem nicht mit einem einzigen immer größeren Su-percomputer, sondern mit vielen kleinen „zusammengeschalten“ Computern zu lösen. Einen



solchen Verbund von unabhängigen Computern, der nach außen hin als einzelnes, kohärentesSystem erscheint, nennt man verteiltes System. Die einzelnen Teil-Systeme nennt man Knoten,engl.Node. Es gibt verschiedene Klassen verteilter Systeme, von denen im Folgenden der Clusterund das Grid erläutert werden. Vorher gehen wir jedoch auf ein gemeinsames, fundamentalesKonzept aller verteilten Systemen ein.

Skalierbarkeit

Die Skalierbarkeit eines Systems beschreibt dessen Laufzeitverhalten bei einer Änderung ver-schiedener Input- oder Problemgrößen. Die Skalierbarkeit kann in drei Dimensionen gemessenwerden [21]. Für das heutige Cloud-Computing sind besonders die ersten beiden Dimensionenrelevant.

1. Das System kann skalierbar sein in Hinblick auf seine Größe. In diesem Fall können demSystem einfach weitere Ressourcen (oder Benutzer) hinzugefügt werden, ohne dass dieLeistung signifikant einbricht.

2. Das System kann skalierbar sein in Hinblick auf die geografische Verteilung der Ressourcen(oder Benutzer). In diesem Fall können die einzelnen Ressourcen weit verteilt auseinan-der liegen, ohne dass die Leistung des Systems stark beeinträchtigt wird.

3. Das System kann skalierbar sein in Hinblick auf seine Verwaltung. Solch ein administrativskalierbares System erstreckt sich über viele unabhängige Organisationen, ohne dass dieKomplexität der Verwaltung überproportional zunimmt.

Im Fall der Größenskalierung unterscheidet man außerdem die vertikale Skalierbarkeit unddie horizontale Skalierbarkeit (vgl. Abbildung 2.1). Im ersteren Fall wird die Anzahl der Res-sourcen pro Knoten variiert; man verwendet also einen „stärkeren Arbeiter“. Dieses Skalierenbezeichnet man daher auch als „scale up“. Ein Beispiel für vertikales Skalieren ist, wenn einArbeitsplatz-PC durch eine leistungsfähige Workstation ersetzt wird. Im zweiten Fall, der hori-zontalen Skalierung, erweitert man das System, indem mehr Knoten hinzugefügt werden. DieArbeit wird also „auf mehr Schultern“ verteilt. Daher bezeichnet man dieses Vorgehen als „sca-le out“. Ein Beispiel hierfür ist das zusätzliche Bereitstellen weiterer Berechnungsknoten ineinem Grid. Generell spricht man von einem skalierbaren System, wenn es proportional vonhorizontaler oder vertikaler Skalierung profitiert. In anderen Worten: Wenn die Ressourceneines Systems um einen Faktor α vergrößert werden, so sollte sich die Verarbeitungszeit beikonstanter Problemgröße um etwa den Faktor α verringern.

Cluster-Computing

Eine der ersten Arten von verteilten Systemen war das Cluster. In den 1960er Jahren verbandman zahlreiche identische Knoten über ein Hochgeschwindigkeitsnetzwerk. In vielerlei Hin-sicht erschien der Zusammenschluss als ein kohärentes System und ermöglichte so die einfacheAusführung hochverteilter Berechnungen. Durch die große Anzahl an Knoten wurde eine bis da-to unbekannte Verfügbarkeit und Leistungsfähigkeit erreicht, die im Vergleich zu einer Lösung


2.1 Was ist Cloud-Computing?

....Scale up

.

.......

.Scale out

.

VertikaleSkalierbarkeit:

Mehr Ressourcen proKnoten

.

HorizontaleSkalierbarkeit:

Mehr Knoten im System

Abbildung 2.1: Vertikale und horizontale Skalierung eines Systems.

aus einem einzelnen Großrechner auch noch deutlich günstiger war. Typische Anwendungenfanden sich bei großen, stark verbundenen Berechnungen, besonders in der Wissenschaft. Auchheute werden die meisten Supercomputer als Cluster konzipiert.

Grid-Computing

Eine Verallgemeinerung des Cluster wird durch das Grid-Computing realisiert. Statt der Homo-genität eines Cluster weist das Grid einen hohen Grad an Heterogenität auf. So können sich dieKnoten sowohl in Hardware und Software als auch in der Art der Anbindung an das Grid undin diversen weiteren Aspekten, wie z. B. Sicherheitsrichtlinien, unterscheiden. Hinzu kommt,dass Knoten sich zu einem beliebigen Zeitpunkt in das Grid ein- oder aus dem Grid ausklinkenkönnen. Ein Grid wird häufig durch die Ausnutzung der untätigen CPUs in vielen Rechnern ge-bildet (sogenanntes CPU-Scavenging). Es eignet sich besonders für aufwändige Berechnungen,bei denen nicht viele Daten transportiert werden müssen und deren Teilberechnungen weitge-hend unabhängig ausgeführt werden können. Bekannte Vertreter von Grids sind Projekt wieSETI@home1 oder Folding@home2.

Utility-Computing

Zeitgleich zu den Ideen des verteilten Rechnens kam auch das Konzept des Utility-Computingsauf. Hinter diesem Namen verbirgt sich die technologische Vision, Rechenleistung „wie Stromaus der Steckdose“ zu beziehen und nur nach Verbrauch zu bezahlen. Die Vision wurde vonJohn McCarthy geprägt, der in einem Vortrag auf dem MIT Centennial 1961 vorhersagte, dassRechenleistung zu einem Teil der öffentlichen Versorgung werden könnte, wie auch der Tele-fonanschluss oder das Stromnetz:

“If computers of the kind I have advocated become the computers of the future,then computing may someday be organized as a public utility just as the telephone

1http://setiathome.berkeley.edu/2http://folding.stanford.edu/


http://setiathome.berkeley.edu/

http://folding.stanford.edu/


system is a public utility … The computer utility could become the basis of a newand important industry.” [40]

Tatsächlich gab es auch Ansätze, diese Vision umzusetzen. Im Betriebssystem Multics wurdendie Ideen realisiert, allerdings ohne kommerziellen Erfolg. Das lag in der Rückschau hauptsäch-lich daran, dass weder ein allgemeiner Zugang zum Internet, noch ausreichend günstige Hard-ware existierte. Mit dem Aufkommen von Cloud-Computing und „On-Demand“-Applikationenin den 1990er Jahren, wurde allerdings auch diese Vision wieder aufgegriffen und in das Cloud-Computing-Konzept integriert.

Das Application-Service-Provider-Modell

Die Vorteile eines Outsourcing von Software-Anwendungen waren schon früh bekannt.3 Alserster Versuch, die Vorteile zu realisieren, wurde das Modell des Application Service Provi-der (ASP) eingeführt. Ein ASP bietet einem anderen Unternehmen üblicherweise eine einzelneAnwendung „on-demand“, also „bei Bedarf“, per Terminal-Server-Zugang an. Die Anwendungläuft auf der Hardware und im Rechenzentrum des Betreibers. Dieser übernimmt auch sämt-liche Wartungs- und Entwicklungsaufgaben. Klar ist, dass bei einer richtigen Umsetzung dieWartungskosten aufseiten des Anwenderunternehmens entfallen. Außerdem werden die einma-ligen Zahlungen, wie die Lizenzgebühr für die Software, durch den Provider in eine periodischeNutzungsgebühr umgewandelt. Trotz der theoretischen Vorzüge schlug das Konzept fehl, weildie Anbieter die notwendigen Skaleneffekte (noch) nicht erreichen konnten. Dies lag vor allemdaran, dass noch zu viel dedizierte Infrastruktur pro Kunde eingesetzt wurde und zu weniggemeinsame Nutzung der physischen Ressourcen vorlag. Zudem war die Netzwerkbandbreitein vielen Fällen noch zu knapp, was eine weitere Verbreitung verhinderte. Insgesamt konntenbeide Seiten nicht die erhofften monetären Einsparungen erzielen, so dass das ASP-Konzept inseiner ursprünglichen Form als gescheitert angesehen werden muss. Nichtsdestotrotz sind dieIdeen ein direkter Vorläufer des Cloud-Computings, welches nun erläutert werden soll.

2.1.2 Evolution zum Cloud-Computing

Der Begriff Cloud-Computing beschreibt ein Feld, das sich derzeit noch im Wandel befindet.Viele bekannte Technologien und Vorgehensweisen aus dem IT-Bereich werden in ein neu-es Gesamtkonzept zusammengeführt. Dabei ist eine zentrale Stoßrichtung, die Applikationenund Informationen von der zugrunde liegenden physischen Infrastruktur und der Art, sie demService-Nutzer bereitzustellen, zu trennen. Eine direkte Konsequenz aus dieser Trennung ist,dass die verschiedenen IT-Ressourcen, wie Speicherkapazität und Rechenleistung, dynamischerals bisher ausgenutzt werden können. Zudem spielen Unternehmensgrenzen, zumindest austechnischer Sicht, nur noch eine untergeordnete Rolle. Im Normalfall – wenn kein eigenesCloud-Rechenzentrum aufgebaut werden soll – ist Cloud-Computing auch gleichbedeutend mitdem Auslagern der Funktionalität zum Dienstanbieter, eine erweiterte Spielart des klassischenIT-Outsourcing.3Die Vor- und Nachteile werden in Abschnitt 3.1 genauer erläutert.



Als allgemein akzeptierte und inzwischen als stabil zu betrachtende4 Definition des BegriffsCloud-Computing kann die des amerikanischen National Institute of Standards and Technology(NIST) herangezogen werden [20]. Dieses definiert Cloud-Computing als Modell, das den kom-fortablen Zugriff nach Bedarf und über ein Netzwerk auf einen Vorrat gemeinsam genutzterRessourcen (z. B. Speicherplatz, Rechenleistung, Applikationen) erlaubt. Die Menge der bereit-gestellten Ressourcen muss sich jederzeit unverzüglich in Selbstbedienung an den tatsächlichenBedarf anpassen lassen. Der Benutzer erwartet dabei eine ständige Verfügbarkeit der Ressour-cen.Ähnlich sehen es auch Vaquero u. a. [34], die eine Übersichtsstudie über die verschiede-

nen Definitionen von Cloud-Computing durchgeführt haben. In ihrem Artikel kondensieren siedie Gemeinsamkeiten von über 20 verschieden Definitionen des Begriffs. In der Essenz besagtdie Definition, dass Clouds ein großer Vorrat einfach zu benutzender und leicht zugreifba-rer, virtualisierter Ressourcen (z. B. Hardware, Entwicklungsumgebungen oder Dienste) sind.Diese Ressourcen können dynamisch an den sich ändernden Bedarf angepasst werden („skalie-ren“), so dass die Ressourcen optimal ausgenutzt werden. Die Abrechnung erfolgt üblicherweisenach Nutzung („Pay-per-Use“) unter Beachtung vorher vereinbarter Service-Level-Agreements(SLAs).Beide Definitionen enthalten im Wesentlichen dieselben Charakteristika, wobei sie teilweise

unterschiedlich benannt werden. So sprechen Vaquero u. a. explizit von Virtualisierung, wäh-rend das NIST dies durch den „Vorrat von gemeinsam genutzten Ressourcen“ nur indirekt for-dert. Nichtsdestotrotz hat sich die Definition des NIST etabliert. Sie impliziert fünf zentraleCharakteristika von Cloud-Computing-Angeboten, die im Folgenden einzeln erläutert werden.Darüber hinaus grenzt das NIST drei Servicemodelle sowie vier Nutzungsmodelle für die Cloudab. Auch diese werden weiter unten einzeln vorgestellt.Zuerst definieren wir jedoch auf Basis der Definition des NIST für den Kontext dieses Leitfa-

dens den Begriff des Cloud-Service:Ein Cloud-Service ist die service-orientierte Bereitstellung von virtuellen IT-Ressourcen,d. h. virtualisierter Hard- oder Software, durch einen Cloud-Anbieter unter Ge-währleistung der fünf Cloud-Computing-Charakteristika:

1. Gemeinsame Nutzung physischer Ressourcen2. Unverzügliche Anpassbarkeit an den Ressourcenbedarf3. Selbstbedienung nach Bedarf4. Umfassender Netzwerkzugriff5. Messung der Servicenutzung

Abbildung 2.2 zeigt diese Merkmale in der Übersicht. Aus der in der Definition enthaltenen Ser-viceorientierung ergeben sich einige grundlegende Merkmale (vgl. [9]). Jeder Service ist somitunter anderem durch einen Servicevertrag, also eine Schnittstellenbeschreibung, nach außenspezifiziert und kann lose mit anderen Services gekoppelt werden. Die jeweiligen Implemen-tierungsdetails und die für den Betrieb verwendete Hard- und Software bleiben gemäß demAbstraktionsprinzip weitgehend verborgen, was die Services modular macht. Cloud-Servicessind darüber hinaus zustandslos (engl. stateless) [20].4Die aktuelle Version 15 der Arbeitsdefinition wurde seit Oktober 2009 nicht mehr geändert.



..CloudComputing

.

RapidElasticity

.

Broad NetworkAccess

.

On-demandSelf-service

.

MeasuredService

.

ResourcePooling

.

1

.

2

.

3

.

4

.

5

Abbildung 2.2: Die fünf Charakteristika des Cloud-Computings.

2.1.3 Fünf zentrale Charakteristika von Cloud-Computing

Um ein genaueres Verständnis dafür zu erhalten, was einen Cloud-Service auszeichnet, werdenim Folgenden die oben eingeführten fünf charakterisierenden Eigenschaften genauer erläutert.Die Eigenschaften sind in der Abbildung 2.2 dargestellt und werden der Reihe nach behandelt.

Resource-Pooling – Gemeinsame Nutzung physischer Ressourcen

Das Konzept des Resource-Pooling beschreibt das Zusammenfassen von physischen Ressourcenzu einem gemeinsamen Vorrat, der dann je nach Bedarf auf die verschiedenen Dienstnutzeraufgeteilt wird. Die Dienstnutzer können dabei nur logische Ressourcen anfordern, welche dieCloud-Software des Anbieters je nach Situation auf verschiedene physische Ressourcen ausdem Vorrat abbildet. Beispiele für Ressourcen sind Rechenleistung, Speicherkapazität, Netz-werkbandbreite, virtuelle Maschinen oder Dienstinstanzen.Das Konzept erfordert folglich zwingend die Trennung von logischen, d. h. virtuellen, und

physischen Ressourcen. Auf Hardware-Ebene wird dies durch diverse Methoden der Virtuali-Virtualisierung sierung realisiert. Einige Arten der Virtualisierung sind transparent, während andere spezielle

Unterstützung durch die Hard- und Software erfordern. Für einen Überblick über die einge-setzten Technologien siehe [39]. Obschon der Anbieter zuweilen erheblichen Aufwand für eineeffiziente Virtualisierung zu betreiben hat, ist die Virtualisierung für alle Cloud-Anbieter unver-zichtbar, da nur durch diese Technologien die Hardware in den Rechenzentren so ausgelastetwerden kann, dass für die Anbieter ausreichend große Skaleneffekte entstehen. Typischerwei-se können die Server in einem gut virtualisierten Rechenzentrum mit 70–80%iger Auslastunglaufen, anstatt wie in traditionellen Rechenzentren oft nur zu 5–10% ausgelastet zu sein [26].Dadurch steigt die Rentabilität der Geräte, es sinken die gesamten Hardware-Investitionen undauch die Kosten für Strom und Kühlung.Während Virtualisierung sich mit physischen Ressourcen befasst, kommt im Bereich der Da-



tenhaltung ein ähnliches Konzept zum Einsatz. Hier wird von physischen Datentöpfen mit ih-ren Schemata abstrahiert und stattdessen auf logischen Einheiten gearbeitet. Für relationaleDatenbanksysteme kann das beispielsweise bedeuten, dass physische Tabellen zwischen meh-reren Kunden geteilt werden. Jeder Kunde – in diesem Kontext als Mandant bezeichnet – ar-beitet dann mit einer logischen Version der Tabelle, in der scheinbar nur seine eigenen Datenvorhanden sind. Abstraktionen wie diese werden im Datenbankbereich unter dem Stichwort

MandantenfähigkeitMandantenfähigkeit (engl. Multi-tenancy) zusammengefasst.Der Kern der Mandantenfähigkeit ist, dass nur eine einzige Software-Basis für alle Kunden

eingesetzt wird, und die Kunden nur durch die Programmlogik separiert werden. So erscheintes dem Dienstnutzer, als stünde für ihn eine eigene, dedizierte Instanz des Systems bereit. In-tern wird die Trennung jedoch normalerweise wieder aufgehoben, so dass Daten verschiedenerKunden „nebeneinander“ auf der Festplatte landen können. Daher ist die konkrete Implemen-tierung der Mandantenfähigkeit für eine Sicherheitsanalyse durchaus relevant, zumal noch kei-ne optimale Lösung für die technische Realisierung gefunden ist. Für Anbieter, insbesondereSoftware-as-a-Service-Anbieter, ist die Mandantenfähigkeit jedoch unverzichtbar, da nur da-durch die entsprechenden Skaleneffekte erzielt werden können.Unabhängig davon, ob die Abstraktion auf Hardware- oder Software-Ebene erfolgt, hat der

Dienstnutzer in beiden Fällen kein Wissen und keine Kontrolle darüber, wie die zugrunde lie-genden physischen Ressourcen beschaffen sind oder wo sie sich befinden. Unter Umständenstellt der Cloud-Anbieter jedoch Möglichkeiten bereit, auf höherem Abstraktionsniveau auf dieBeschaffenheit der physischen Ressourcen Einfluss zu nehmen. Beispielsweise bieten inzwi-schen viele Anbieter eine Einschränkung nach geografischer Region (z. B. „Europa“) oder nachQualitätsstufen (z. B. „Paket XXL“) an.

Rapid Elasticity – Unverzügliche Anpassbarkeit an den Ressourcenbedarf

Cloud-Systeme können sehr dynamisch auf sich ändernde Last reagieren. Sie ermöglichen esüblicherweise, das Ressourcenangebot unverzüglich (oder zumindest mit sehr geringer Vorlauf-zeit) nach oben oder unten anzupassen. Dabei kann der Dienstnutzer die Ressourcen aus einemscheinbar unerschöpflichen Vorrat beziehen. Dieses Konzept bezeichnet man auf Englisch alsRapid Elasticity.5 Häufig muss der Dienstnutzer selbst aktiv werden und die bereitgestellte Res-sourcenmenge, für die er ja auch zahlen muss, händisch anpassen. Für einige Diensttypen kannjedoch auch eine automatische Anpassung konfiguriert werden. In diesem Fall erkennt dasCloud-System automatisch, dass mehr oder weniger Ressourcen benötigt werden und passt dieZahl der aktiven Ressourcen an. Obwohl beide Arten der Skalierung denkbar sind, kommt imBereich des Cloud-Computing eher die vertikale Skalierung (scale out) zur Anwendung. Profi-tieren tun die Cloud-Nutzer natürlich nur dann von dieser dynamischen Anpassung, wenn diejeweiligen Anwendungen auch tatsächlich skalierbar sind.

5Das Konzept der „Elasticity“ im Cloud-Kontext darf nicht verwechselt werden mit der Elastizität imwirtschaftswissenschaftlichen Sinne, z. B. der Preiselastizität der Nachfrage. In diesem Zusammen-hang ist mit „Elastizität“ gemeint, dass sich das Ressourcenangebot „elastisch“ verhält, also nichtstarr ist, sondern sich dem Bedarf recht dynamisch anpassen kann.



On-demand Self-Service – Selbstbedienung nach Bedarf

Eine wichtige Voraussetzung für die unverzügliche dynamische Anpassung der Ressourcen istdie Möglichkeit für den Kunden, die benötigte Menge jederzeit in Eigeninitiative und ohneEinbeziehung von Mitarbeitern des Anbieters ändern zu können. Die Services funktionierendabei weitgehend autonom und benötigen keine großartige Konfiguration durch den Anbietervor oder während des Betriebs. Sie sind mehr oder weniger selbstverwaltend und -optimierend(im Sinne des Autonomic Computing [15]). Dieser Aspekt ist sehr wichtig, denn nur durch ei-ne weitgehende Automatisierung auf Anbieterseite kann dieses Selbstbedienungsmodell über-haupt funktionieren. Außerdem kann der Cloud-Anbieter auch nur mithilfe dieses Modells unddem verbundenen Verzicht auf Personal attraktive Preise realisieren. Art, Umfang und Qualitätdieser Automatisierung sind, zumindest zurzeit noch, ein wichtiges Alleinstellungsmerkmal füreinen Cloud-Anbieter.

Broad Network-Access – Umfassender Netzwerkzugriff

In der Cloud bezogene Ressourcen sind über ein Netzwerk, typischerweise das Internet, zu er-reichen. Dabei kommen Standardprotokolle wie HTTP, XML, JSON etc. zur Anwendung. Für dieBenutzung der Cloud-Angebote stellen die Betreiber häufig Web-APIs oder REST-Schnittstellenzur Verfügung. Durch diese Fokussierung auf standardisierte Netzwerkzugriffe wird auch einebreite Palette von Endgeräten unterstützt. So können Mobiltelefone, PDAs, Netbooks und Slatesgenauso wie herkömmliche Arbeitsplatzrechner oder Laptops auf die Dienste zugreifen.6 Aller-dings muss die Verbindung der Geräte mit dem Internet eine ausreichend große Bandbreiteaufweisen, um die Dienste sinnvoll nutzen zu können.

Measured Service – Messung der Servicenutzung

Nach der ursprünglichen Idee des Utility-Computing sollten Cloud-Angebote streng nutzungsbe-zogen bezahlt werden. Dafür ist es nötig, dass der Anbieter die tatsächliche Ressourcennutzunggenau misst. Welche Messverfahren und Messgrößen zum Einsatz kommen, hängt natürlichvon der Art der Ressource ab. Beispiele sind auf der Platte gespeicherte GiB für Speicherplatz,benutzte CPU-Zyklen für Rechenleistung und gespeicherte Datensätze in einer Database-as-a-Service. Das System kann auf Basis der Messungen auch selbständig Aktionen ergreifen und z. B.physische Ressourcen anfordern oder umverteilen. Die Ressourcennutzung wird sowohl an denKunden als auch an den Anbieter gemeldet, einerseits für Abrechnungszwecke, andererseitsauch zur Kontrolle, falls z. B. durch Programmierfehler unerwartet hohe Kosten entstehen.Die Kombination von dynamischer Anpassung der Ressourcenmenge und der genauen Mes-

sung der Servicenutzung ermöglicht eine nutzungsabhängige Abrechnung der Gebühren für dieServicenutzung. Dieser Aspekt wird häufig sogar als Charakteristikum für Cloud-Computing ge-nannt, ist aber eigentlich nur eine logische Folge aus der Anwendung der vorgenannten Prinzi-6Dies gilt vor allem für SaaS, wobei die Voraussetzung ist, dass auf dem Endgerät ein ausreichendumfangreicher Webbrowser zur Verfügung steht. Nur mit Einschränkungen gilt dies auch für PaaSund IaaS, weil hier die Schnittstellen eher auf einen programmatischen Zugriff, z. B. durch eine „App“ausgelegt sind. Zur Klärung dieser Begriffe, siehe Abschnitt 2.1.4.



Tabelle 2.1: Vergleich der Eigenschaften von Cluster-, Grid- und Cloud-Computing.

Charakteristikum Cluster Grid Cloud

Gemeinsame Nutzung physischer Ressourcen 4 4 4

Allgemeiner Netzwerkzugriff 4 4 4

Unverzügliche Anpassbarkeit an Bedarf 6 6 4

Selbstbedienung nach Bedarf 6 6 4

Messung der Servicenutzung 6 4 4

Arbeiten mit virtuellen Ressourcen 6 6 4

pien. Im Englischen hat sich der Begriff Pay-per-Use eingebürgert, um diese nutzungsabhängigePay-per-UseBezahlung zu beschreiben. Als Randbemerkung sei an dieser Stelle darauf hingewiesen, dass der

Term „Pay-as-you-go“, den man in englischsprachigen Texten häufig synonym verwendet, nichtidentisch ist. Das Pay-as-you-go-Prinzip bedeutet, dass statt einer einmaligen Lizenzzahlung ei-ne periodisierte Zahlung anfällt. Diese Zahlung ist aber nicht notwendigerweise nutzungsab-hängig, sondern häufig eine „Monatsmiete“, die auch anfällt, wenn keine Nutzung erfolgt ist.Das Pay-per-Use-Konzept schließt zwar auch eine Periodisierung der Zahlungen ein und ist in-sofern ähnlich zum Pay-as-you-go. Es verlangt aber zwingend eine Korrelation der Gebühr mitder tatsächlichen Dienst-Nutzung.

Vergleich zwischen Cluster-, Grid- und Cloud-Computing

Um die Unterschiede zu den vorherigen Konzepten Cluster- und Grid-Computing zu verdeutli-chen, sollen die jeweiligen Eigenheiten in diesem Abschnitt kurz hervorgehoben werden. Alledrei Systeme sind verteilte Systeme mit ähnlichen Eigenschaften. Tabelle 2.1 zeigt die Unter-schiede zusammenfassend anhand der fünf Cloud-Charakteristika auf und bezieht zusätzlichexplizit den Aspekt der Virtualisierung mit ein. Wie aus der Tabelle ersichtlich wird, sind dieKonzepte vergleichbar in Bezug auf die gemeinsame Nutzung physischer Ressourcen (Resource-Pooling) und den Netzwerkzugriff. Allerdings erfolgt der Zugriff auf Clouds eher über öffentli-che Netze, während der Zugriff auf ein Grid und besonders ein Cluster eher über ein Intranetgeschieht.Abgesehen davon sind Cloud-Systeme jedoch deutlich dynamischer als ihre Vorgänger. Wäh-

Höhere Dynamikrend in Grid- und Cluster-Umgebungen meist eine Reservierung der Ressourcen im Vorfelderfolgt, werden bei Cloud-Systemen diese je nach aktuellem Bedarf bereitgestellt. Auf Schwan-kungen des Bedarfs können daher auch nur Cloud-Systeme angemessen schnell reagieren. Beider Messung der Servicenutzung lässt sich festhalten, dass Cloud- und Grid-Systeme diese un-terstützen. Cluster-Systeme bieten i. d. R. jedoch keine ausgefeilten Messmöglichkeit. Darüberhinaus unterscheidet sich das Cloud-Computing dadurch, dass explizit und ausschließlich mitvirtuellen Ressourcen gearbeitet wird. Beim Grid- und Cluster-Computing ist zwar auch eineAbstraktion von der physischen Hardware vorhanden. Jedoch fehlt der Aspekt der Virtualisie-rung der Ressourcen in der jeweiligen Softwareschicht, die stattdessen eine abstrakte Sicht aufdie physischen Ressourcen des Systems bietet.



Unternehmen erhalten also durch Cloud-Computing eine deutlich flexiblere Lösung im Ver-gleich zu anderen verteilten Systemen wie Grid und Cluster. Außerdem ist es, bedingt durchdie Natur des Cloud-Computings, sehr viel einfacher, die Dienste von externen Anbietern zubeziehen, so dass keine größeren Investitionen in die eigene Infrastruktur nötig werden.Jedoch gehen mit dem Einsatz von Cloud-Computing eine Reihe von Sicherheitsrisiken ein-

her, deren Ursachen meist auf mangelnden Einsatz und Unterstützung von Sicherheitstechno-logien zurückzuführen sind. Auch neu zu entwickelnde oder nicht ausgereifte Technologien

Sicherheit können eine sichere Benutzung von Cloud-Services verhindern [13]. Daher müssen Unterneh-men, die Cloud-Systeme einsetzen möchten, eine detaillierte Betrachtung der Sicherheitsrisi-ken durchführen, wenn sichergestellt sein soll, dass die neuen Cloud-Computing-Systeme das-selbe von internen Systemen gewohnte Sicherheitsniveau erfüllen. Diese Risiken können —beispielsweise bei Diebstahl vertraulicher Informationen — erheblichen Einfluss auf das Ge-schäftsmodell des Dienstnutzers haben. Die Cloud-Nutzung ist aktuell daher je nach Szenarionur eingeschränkt möglich. Weitere Details hierzu finden sich in Kapitel 5.

2.1.4 Servicemodelle: XaaS

Inzwischen gibt es eine nahezu unüberschaubare Vielfalt an Cloud-Services, die mannigfaltigeIT-Ressourcen anbieten. Sprach man zuerst von Software-as-a-Service und Infrastructure-as-a-Service, so kamen bald weitere Angebote wie Storage-as-a-Service, Logic-as-a-Service oderNetwork-as-a-Service hinzu. Inzwischen gibt es sogar seltsam anmutende Auswüchse wie Human-as-a-Service. Wegen des gemeinsamen Suffix fasst man alle Arten von Cloud-Services ger-ne unter dem Begriff Anything-as-a-Service (XaaS) zusammen. Zwar sind viele dieser Service-Bezeichner durchaus sinnvoll – wie z. B. der Terminus Database-as-a-Service, der in diesemLeitfaden behandelt wird –, aber es haben sich drei Hauptbegriffe herausgebildet, mit derenHilfe, Cloud-Angebote zumindest einigermaßen trennscharf kategorisiert werden können. DasNIST schlägt zur Einteilung drei sogenannte Servicemodelle vor, die eine Einteilung anhandder Art der angebotenen Dienstleistung erlauben:

� Software-as-a-Service (SaaS)

� Platform-as-a-Service (PaaS)

� Infrastructure-as-a-Service (IaaS)

Abgeleitet von den drei Anfangsbuchstaben spricht manmanchmal auch vom SPI-Ordnungsrah-men. Abbildung 2.3 stellt die drei Servicemodelle im Zusammenhang dar. Dabei ist zu beachten,dass weiter unten liegende Servicemodelle nicht verpflichtend eingesetzt werden müssen. Soist es denkbar, dass eine SaaS direkt auf einer IaaS realisiert wird (ohne dazwischen liegendePaaS). Ebenso könnte eine PaaS direkt auf virtualisierter Hardware aufsetzen, ohne IaaS zunutzen (etc.).Obschon eine Einteilung aktueller Cloud-Angebote anhand dieser Klassen nicht trennscharf

ist, bietet es sich an, die drei vom NIST vorgeschlagenen Klassen zur Grobeinteilung zu ver-wenden. Besonders die Grenze zwischen PaaS und SaaS verschwimmt jedoch aktuell noch.



..Software-as-a-Service.

Platform-as-a-Service

.

Infrastructure-as-a-Service

.

Virtualisierungsschicht

.

Hardware-Infrastruktur

.

Benutzerschicht

.

Wird transparentdurch denCloud-Anbieterverwaltet

.

Abbildung 2.3: Die typische Dreiteilung in SaaS, PaaS und IaaS.

Software-as-a-Service (SaaS)

Beim SaaS-Modell bietet der Provider eine Software an, die der Endkunde direkt einsetzenkann. Der Betrieb der Software liegt vollständig beim Anbieter, der sich um alle Aspekte derWartung, Aktualisierung, Weiterentwicklung oder Lizensierung der benötigten Soft- und Hard-ware kümmert. Üblicherweise werden mandantenfähige Programme eingesetzt, um die nötigenSkaleneffekte zu realisieren. Der Benutzer greift auf die Software per Webbrowser zu, anders alsbeim ASP-Modell, wo ein Terminalserver zum Einsatz kommt. Während der Benutzer nur seineDaten ins System eintragen muss und ggf. noch kleinere Einstellmöglichkeiten zur Individua-lisierung der Software hat, trägt der Anbieter Sorge, dass Backups der Daten gemacht werden.Softwareupdates erfolgen in der Regel vom Benutzer unbemerkt und in kleinen Inkrementen,anders als die großen Versionssprünge beim klassischen Software-Lizenzmodell. Beispiele fürSaaS sind SalesForce CRM, Google Docs, die Zoho On-Demand Suite oder Gliffy.

Platform-as-a-Service (PaaS)

Im Fall von PaaS bietet der Provider den Nutzern die Möglichkeit, eigene Programme auf einerPlattform in der Cloud bereitzustellen. Die gesamte Infrastruktur – von der Plattformsoftwareabwärts bis hin zur Hardware – wird vom Provider bereitgestellt und verwaltet. Dieser legt da-bei gewisse Rahmenbedingungen, wie z. B. die Programmiersprache und verwendbare Biblio-theken oder Schnittstellen fest. Der Kunde kann innerhalb dieses Rahmens seine Programmefrei gestalten. Oft wird nicht nur die Plattform für den Betrieb, sondern auch eine Umgebungfür die Entwicklung der Programme angeboten. Durch den festen Rahmen kann der Providerbestimmte Annahmen treffen und dadurch eine umfassende Automatisierung ermöglichen. Soist es üblich, dass PaaS-Anbieter eine automatische Skalierung abhängig von der Nachfrage an-bieten. Außerdem können leicht redundante Kopien der Programme auf andere Systeme verteiltwerden, so dass eine sehr hohe Verfügbarkeit garantiert werden kann. Typische Vertreter aus


http://www.salesforce.com/de/

http://docs.google.com/

http://www.zoho.com/

http://www.gliffy.com/


dem PaaS-Segment sind z. B. die Google App Engine, Heroku, Microsoft Windows Azure oderForce.com.

Infrastructure-as-a-Service (IaaS)

Das Modell, welches der Vision des Utility-Computing am nächsten kommt, ist das IaaS-Modell.Hierbei bietet der Cloud-Provider virtuelle Hardware oder Infrastrukturdienste an, wie z. B.Speicherplatz, Rechenleistung oder Netzwerkbandbreite. Der Cloud-Nutzer kann diese virtuel-le Infrastruktur in seine IT-Landschaft einbauen und von hoher Verfügbarkeit, automatischenBackups und transparenter Wartung durch den Anbieter profitieren. Die Benutzung der Res-sourcen ist dabei mit größtmöglicher Flexibilität möglich. Dafür muss der Nutzer aber auchalle Schichten oberhalb der Infrastrukturschicht (z. B. Betriebssystem, Webserver, Datenbank-server) selbst verwalten. Der prototypische Vertreter von IaaS ist die Rechenleistung („Com-pute“) aus der Cloud, was sich auch im Begriff „Cloud-Computing“ widerspiegelt. Angebote imBereich IaaS sind z. B. die Amazon Web Services (EC2, S3, SimpleDB, …), GoGrid, RackSpace,ScaleUp und viele andere.

2.1.5 Arten des Cloud-Betriebs

Neben der Art der erbrachten Services unterscheidet man verschiedene Arten des Cloud-Betriebsin Bezug auf die Öffnung der Cloud nach außen. Dabei ergeben sich zwei elementare Typen:

� Eine sog. öffentliche Cloud (engl. Public Cloud) ist die typische Art von Cloud, in derjeder die angebotenen Services beziehen kann. Ggf. wird dafür eine Nutzungsgebührerhoben, aber die Produktpalette an sich ist für die Allgemeinheit oder zumindest füreine hinreichend große Interessengruppe verfügbar. Verwaltet wird eine solche Clouddurch einen Anbieter, der sich darauf spezialisiert hat, Cloud-Services zu verkaufen. EinBeispiel ist die Cloud von Amazon.

� Eine sog. nichtöffentliche Cloud (engl. Private Cloud) hingegen wird ausschließlich für eineeinzige Organisation betrieben. Diese Organisation verwaltet die Cloud entweder selbstoder hat einen externen Dienstleister, der die Verwaltung übernimmt. Das Rechenzen-trum kann dabei sowohl auf dem Gelände der Organisation als auch ausgelagert sein.In jedem Fall ist der Zugang zu den Cloud-Diensten auf Mitglieder der Organisation be-schränkt. Dieses Modell ist in aller Regel nur für sehr große Organisationen attraktiv.Ein Beispiel wäre eine nichtöffentliche Cloud in einem Universitätsrechenzentrum, dieausschließlich Forschern dieser Universität zur Verfügung steht.

Neben diesen beiden elementaren Typen können noch zwei weitere, abgeleitete Typen desCloud-Betriebs unterschieden werden:

� Eine sog. Community-Cloud ist eine Art nichtöffentliche Cloud, die sich mehrere Organi-sationen mit ähnlichen Anforderungen teilen. Beispielsweise könnte es wegen bestimm-ter gesetzlicher Anforderungen im Gesundheitswesen sinnvoll sein, eine Cloud speziellfür eine Gruppe von Krankenhäusern bereitzustellen. Die beteiligten Organisationen ver-walten die Cloud entweder selbst oder geben diese Aufgaben an externe Dienstleister ab.


http://code.google.com/appengine/

http://heroku.com/

http://www.microsoft.com/windowsazure/

http://force.com/

http://aws.amazon.com/

http://aws.amazon.com/de/ec2/

http://aws.amazon.com/de/s3/

http://aws.amazon.com/de/simpledb/

http://www.gogrid.com/

http://www.rackspace.com/

http://www.scaleupcloud.com/


Unternehmen 1

Nicht-öffentliche

CloudÖffentliche

CloudÖffentliche

Cloud

Unternehmen 2

Nicht-öffentliche

Cloud

CommunityCloud

Unternehmen 3 Unternehmen 4

Unternehmen 5 Unternehmen 6

HybrideCloud

Internet

Abbildung 2.4: Die vier Arten des Cloud-Betriebs: öffentliche, nichtöffentliche, hybri-de und Community-Cloud.

Das Rechenzentrum kann sich dabei sowohl auf dem Gelände einer der Organisationenals auch bei einem externen Dienstleister befinden.

� Eine sog. hybride Cloud schließlich entsteht aus dem Zusammenschluss mehrerer andererClouds. Sie wird mehr oder weniger eng durch Standards oder proprietäre Technologi-en verknüpft und ermöglicht den Austausch von Daten und Programmen. Ein typischerAnwendungsfall ist das Cloud-Bursting, also das „Ausbrechen“ aus einer Cloud zusätzlichin eine weitere Cloud, wenn die Ressourcen der ersten nicht mehr ausreichen. Ein wei-teres Szenario könnte sein, dass eine Lastbalancierung zwischen mehreren Clouds einerOrganisation stattfinden soll.

Die vier Arten des Cloud-Betriebs sind in Abbildung 2.4 visualisiert. Es ist zu erwarten, das fürabsehbare Zeit die nichtöffentliche Cloud oder die Community-Cloud das für die meisten Unter-nehmen geeignete Modell ist. Nur diese beiden Modelle lassen die Auslagerung sensibler Datenund Funktionen zu, bis alle rechtlichen Unklarheiten beseitigt sind. Die hybride Cloud kann alsKompromiss ebenfalls eingesetzt werden, wenn sie nur aus nichtöffentlichen oder Community-Clouds besteht. Die öffentliche Cloud eignet sich derzeit nur für die Arbeit mit nicht-sensiblenDaten, z. B. höchst skalierbare Websites oder Massendatenverarbeitung auf anonymen Logfilesetc. Die Anwendungsmöglichkeiten für die öffentliche Cloud sind jedoch besonders im Bereichder KMU zurzeit noch nicht besonders vielfältig. Andererseits lohnt sich die Erstellung einereigenen, nichtöffentlichen Cloud erst aber einer recht ordentlichen Mindestgröße, was dieseLösung für die meisten KMU unattraktiv macht.



2.2 Abgrenzung zum klassischen IT-Outsourcing

Die Verwendung von Cloud-Diensten ist im Wesentlichen eine Spielart des IT-Outsourcing.Unter dem Begriff IT-Outsourcing wird die Auslagerung der IT ganz oder in Teilen an externeDienstleister verstanden. Werden nur einzelne IT-Funktionen ausgelagert, so spricht man vonselektivem Outsourcing, wird hingegen die gesamte IT ausgelagert, so nennt man dies totalesOutsourcing. Ja nach Variante können sich „ausgelagerte“ Infrastruktur und Software sowohlbeim Kunden als auch beim Anbieter befinden. Wichtig ist, dass die Verantwortung für dieseimmer auf den externen Anbieter übertragen wird.Außer im seltenen Fall einer reinen nichtöffentlichen Cloud im eigenen Rechenzentrum, be-

finden sich Hard- und Software beim Cloud-Computing notwendigerweise in den Rechenzen-tren des Anbieters. Für den Anwendungsfall DaaS hat dies die direkte Konsequenz, dass sichCloud-Dienste i. d. R. nicht gut eignen, um OLTP-artige Systeme auszulagern. Während man im

OLTP klassischen Modell die Möglichkeit hat, den Datenbank-Server ins eigene Rechenzentrum zustellen und nur die Verwaltung der Hard- und Software abzugeben, um weiterhin von schnel-len Netzwerkverbindungen und niedriger Latenzzeit zu profitieren, ist dies beim Outsourcing indie Cloud nicht möglich. Hier muss der Zugriff auf das Datenbanksystem (DBS) immer über eineInternetverbindung erfolgen, welche häufig nicht ausreichend schnell für OLTP-Anwendungenist.Gleichzeitig bietet diese Entkopplung aber auch das Potential, die Erbringung der Cloud-

Services dynamisch über zahlreiche Standorte zu verteilen. Außerdem erlaubt das Cloud-ComputingDynamik eine sehr kurzfristige Anpassung an den tatsächlichen Bedarf, viel schneller als dies beim klas-

sischen Outsourcing der Fall ist. Dabei bestimmt und konfiguriert der Cloud-Anwender einenGroßteil der Funktionalität über eine Webseite ohne Involvierung des Anbieters.Ein wichtiger Unterschied zwischen IT-Outsourcing und Cloud-Computing existiert auch im

Hinblick auf die Anpassung der Geschäftsprozesse. Während im klassischen Fall üblicherweiseder Anbieter dafür Sorge trägt, die angebotenen Systeme an die Geschäftsprozesse des Kun-den anzupassen („Customizing“), bieten Cloud-Provider hauptsächlich standardisierte Produk-te an, die geringe bis keine Anpassungsmöglichkeiten bieten. Der Kunde muss – je nach Artder Dienstleistung – die Angebote eigenständig anpassen (z. B. durch selbst programmierteGeschäftslogik) oder sogar die internen Abläufe ändern, um die Cloud-Services besser in dieeigenen Prozesse zu integrieren.Je nach Umfang der Anpassungen an die Geschäftsprozesse kann es beim Outsourcing zu

Lock-in-Effekten kommen, da der Anbieter nach den aufwändigen Anpassungen häufig eine lan-ge Vertragslaufzeit erzwingt. Das klassische IT-Outsourcing ist daher durch mittel- bis langfris-tige Vertragsverhältnisse gekennzeichnet. Beim Cloud-Computing sind die Mindestlaufzeiten

Lock-in-Effekte der Verträge häufig extrem kurz, z. B. monatlich kündbar. In der Praxis ist jedoch zu erwarten,dass die Auslagerungen in die Cloud auch eher einen mittel- bis langfristigen Horizont habenwerden, da die Anpassungen auf Kundenseite zurzeit noch einen häufigen Anbieterwechselnicht sinnvoll erscheinen lassen. Andererseits möchte vielleicht sogar der Kunde eine längereLaufzeit durchsetzen, um Sicherheit in der Planung seiner Systeme und Schnittstellen zu haben.Dies ist zumindest mit den Standardverträgen der aktuellen Angebote nicht möglich.


2.3 Spezialfall Database-as-a-Service (DaaS)


Einer der vielen Cloud-Services, die unter dem XaaS-Dach zusammengefasst werden, ist dieDatabase-as-a-Service. Dieser Abschnitt erläutert die Details verschiedener Varianten diesesKonzepts und klärt über die Besonderheiten von Database-as-a-Service im Vergleich zu ande-ren Cloud-Services auf. Nach einer Definition und Abgrenzung des Begriffs, werden die fünfCloud-Charakteristika beleuchtet und schließlich ein kritischer Ausblick auf das Problem derfehlenden Elastizität von Daten gegeben.

2.3.1 Definition und Abgrenzung

Nachdem in Abschnitt 2.1.4 die grundlegende Dreiteilung in SaaS, PaaS und IaaS vorgestelltwurde, soll nun der Begriff Database-as-a-Service (DaaS) geklärt werden. Wie der Begriff sugge-riert, werden bei dieser Art von Diensten Funktionalitäten eines Datenbanksystems als Dienst-leistung angeboten. Dies entspricht auch dem kleinsten gemeinsamen Vielfachen der in derLiteratur vorherrschenden Definitionen.7 Hinter DaaS steckt also die Bereitstellung eines Da-tenbanksystems in einer service-orientierten Art und Weise. Präziser wäre es daher, den Be-griff „Database-System-as-a-Service“ zu verwenden, da eine Datenbank nur eine Sammlung vonDaten repräsentiert und keine Funktionalität im eigentlichen Sinne bereitstellt [36, S. 10]. Indiesem Leitfaden benutzen wir trotzdem die zwar etwas unpräzise, aber inzwischen etablier-te Bezeichnung Database-as-a-Service (DaaS) und meinen damit alle Cloud-Datenbanksysteme.Tatsächlich gibt es aber bereits Angebote, die ausschließlich Daten in einer Datenbank in derCloud zur Verfügung stellen. Um diese explizit mit einzuschließen, sprechen manche Autorenauch von Cloud Data Services (CDSs) [31].Bei konservativer Betrachtungsweise besteht der Kern von DaaS aus der Bereitstellung grund-

legender Funktionalität eines relationalen Datenbanksystems (RDBS). Insbesondere ist die Vor-gabe eines Datenmodells, das eine Strukturierung und Beschreibung der zu speichernden Datenermöglicht, als elementar anzusehen. Damit verbunden sollten die bewährten drei Abstrakti-onsebenen (physische, logische und externe Ebene, vgl. [36]) und die Möglichkeit der Defini-tion von Schemata für jede Ebene ermöglicht werden. Zudem muss die Möglichkeit gegebensein, mittels einer Sprache – üblicherweise der Structured Query Language (SQL) – oder einerProgrammierschnittstelle auf die Daten und Datendefinitionen des Systems zuzugreifen bzw.diese manipulieren zu können. Für den Einsatz im Unternehmensbereich wird darüber hinausein Benutzer- und Rechtekonzept benötigt, mit dem der Zugriff auf einzelne Datenelementeoder Gruppen von Datenelementen gesteuert werden kann. Gleichzeitig ist die Unterstützungeines Transaktionskonzept zu gewährleisten. Ein Beispiel für diese Art von DaaS-Dienst ist derRelational Database Service (RDS) von Amazon, bei dem mit MySQL ein klassisches RDBS alsCloud-Dienst angeboten wird.Diese konservative Sicht wird allerdings bei aktuellen Cloud-Angeboten des öfteren abgelegt.

7Gelegentlich wird „Database-as-a-Service“ auch als „DAS“ abgekürzt. In Analogie zum SPI-Ordnungsrahmen („XaaS“) erscheint jedoch die Abkürzung „DaaS“ sinnvoller. Die ebenfalls in der (äl-teren) Literatur verwendete Bezeichnung „Outsourced Database (ODB) Model“ hat sich nicht durch-gesetzt.



IaaS

PaaS

SaaS

DaaS

AmazonSimpleDB

Amazon RDS

DabbleDB

CaspioBridge

Amazon S3Amazon EC2 Joyent

HerokuGoogle

AppEngineForce.com

SalesforceGoogle Docs

Akamai …DynaGrid

BungeeConnect

…SaaSGrid

MicrosoftAzure SQL

GMail

Gliffy SugarCRM …

Google Base

…

Abbildung 2.5: Die drei Servicemodelle des NIST im Vergleich zu DaaS.

Hier finden sich neue Konzepte, die keine Schemata unterstützen, nur eingeschränkte Abfrage-möglichkeiten bieten oder die strenge Konsistenz der traditionellen RDBS aufweichen. Geradeim Bereich der Verarbeitung riesiger Datenmengen weichen Firmen wie Google oder Ama-zon auf sog. NoSQL-DBS aus, die z. B. laxere Konsistenzgarantien geben, dafür jedoch höchsteVerfügbarkeit ermöglichen (vgl. Abschnitt 2.3.2 zur Eventual Consistency). Beispielhafte DaaS-Produkte, die vom Angebot eines klassischen relationales Datenbanksystem (RDBS) abweichen,sind z. B. Amazon SimpleDB, DabbleDB oder Google HBase.Entsprechend der vielfältigen Ausgestaltungsmöglichkeiten des DBS-Aspektes eines DaaS-

Dienstes ist es nicht möglich, DaaS insgesamt einer der drei Service-Klassen aus dem SPI-Ordnungsrahmen zuzuordnen. Vielmehr ist DaaS orthogonal zu den drei Klassen anzuordnen,wie Abbildung 2.5 zeigt. Viele konkrete DaaS-Dienste können aber eindeutig einer der dreiKlassen zugeordnet werden. Beispielhafte Angebote für die jeweilige Schicht werden ebenfallsin der Abbildung 2.5 gezeigt.Nicht immer gelingt die Einordnung eines DaaS-Dienstes im allgemeinen Fall, weil die Ver-

wendungsmöglichkeiten des Dienstes zu vielfältig sind. Konkrete DaaS-Angebote können jedocheindeutig einer der drei Schichten zugeordnet werden, wenn man nicht eine Analyse der tech-nischen Merkmale des Dienstes durchführt. Stattdessen sollten die Services aus Benutzersichtkategorisiert werden, abhängig vom Verwendungszweck. Will der Benutzer als Endanwendereine eigenständige Software nutzen, die ihm DBS-Funktionalität bietet – z. B. als „erweitertesExcel“ für die Controlling-Abteilung – so fällt dieser DaaS-Dienst in die Kategorie Software-as-a-Service. Entsprechend können auch die übrigen beiden Klassen abgegrenzt werden. Abbil-dung 2.6 verdeutlicht das Vorgehen bei der Einordnung von DaaS-Diensten.Zusammenfassend lässt sich der Begriff Database-as-a-Service wie folgt definieren:

Database-as-a-Service (DaaS) ist ein Konzept, bei dem Datenbanksystemfunktiona-lität unterschiedlicher Granularitätsstufen, von Teilfunktionalität bis zur Gesamt-funktionalität, als Cloud-Service bereitgestellt wird. DaaS fasst Cloud-Services da-bei durch ihre Funktion zu einer vierten Klasse zusammen, die orthogonal zu derSPI-Klassifikation ist. Konkrete DaaS-Dienste lassen sich jedoch abhängig vom



...

Ich benötige ein DBS fürAnalysen, „manuelle DV“ etc.

...

SaaS

.

Endanwender

...

Ich will Logik fürApplikationen bereitstellen

...

PaaS

.

(Web-)Entwickler

...

Ich will Daten (strukturiert)speichern

...

IaaS

.

Systemarchitekt

Abbildung 2.6: Die Spielarten von DaaS aus Benutzerperspektive.

Verwendungszweck einer der drei Klassen zuordnen.Der Begriff des Cloud-Service wird dabei so verstanden, wie in Abschnitt 2.1.2 definiert.

2.3.2 Der Cloud-Aspekt von DaaS

Laut obiger Definition aus Abschnitt 2.3.1 weist ein DaaS-Dienst die fünf charakteristischenMerkmale für Cloud-Services aus Abschnitt 2.1.3 auf. Die konkrete Ausgestaltung für DBS wirdim Folgenden genauer erläutert.

Resource-Pooling

Die physische Implementierung des Dienstes bleibt dem Benutzer verborgen. Diverse physischeHardwarekomponenten werden in einen gemeinsamen Topf geworfen. Die Benutzer arbeitenmit abstrakten Einheiten, z. B. logischen Tabellen oder Datentöpfen, die der Cloud-Anbieter be-liebig auf konkrete Datenstrukturen und Hardwarekomponenten abbilden kann. Entsprechendkommt auch hier der Virtualisierungstechnologie eine Schlüsselrolle zu. Wird DaaS als SaaSangeboten, so werden die Systeme in aller Regel auch mandantenfähig konzipiert.

Rapid Elasticity

Entsprechend der Idee der flexiblen Anpassbarkeit des Ressourcenangebots kann das DBS schein-bar beliebig viele Daten aufnehmen und scheinbar beliebig viele Anfragen gleichzeitig bearbei-ten. Die Skalierung sollte dabei völlig transparent erfolgen, da der Anbieter normalerweiseausreichend genaue Annahmen treffen kann, um den Vorgang komplett zu automatisieren. Sokann vom Anbieter erwartet werden, dass die Verarbeitung der Anfragen per Lastbalancierungauf verschiedene Systeme verteilt wird und die Daten kontinuierlich auf andere Systeme repli-ziert werden.



Durch eine automatische Replikation der Systeme in andere Rechenzentren kann der Anbietereine hohe Verfügbarkeit und Datensicherheit garantieren. Andererseits erfordern diese Garan-tien üblicherweise die Lockerung des verwendeten Konsistenzkonzepts.8 Die meisten Anbietersetzen dabei auf die sog. Eventual Consistency – zu Deutsch etwa „letztendliche Konsistenz“ –,bei der die Konsistenz der Daten erst nach einem gewissen Zeitfenster garantiert wird. Erfolgenkeine Änderungen an den Daten, so bewegen sich alle Repliken hin zu einem einheitlichen, kon-sistenten Datenstand. Dieses Prinzip wird bereits seit langem im Domain Name System (DNS)verwendet und ist für viele Anwendungen (z. B. Online-Shops) durchaus ausreichend. Anwen-der müssen sich jedoch dessen bewusst sein, dass die ACID-Garantien der klassischen RDBS beiDaaS häufig nicht mehr gelten. Statt ACID9 gilt im Internet oft BASE10 mit einer der folgendenzwei typischen Garantien:11

� Monotonic Reads Hat ein Prozess einen bestimmten Wert gelesen, so ergeben nachfol-gende Anfragen garantiert diesen oder einen neueren Stand, aber nie einen älteren.

� Read-Your-WritesHat ein Prozess einen bestimmtenWert geschrieben, so sieht er garan-tiert diese eigene Änderung bei den nächsten Lesevorgängen und erhält nie eine ältereVersion.

Pay-per-Use

Die Abrechnung erfolgt abhängig von der Nutzung. Typischerweise zahlt der Nutzer für den be-legten Speicherplatz und den ein- und ausgehenden Datenverkehr (z. B. pro GiB) sowie für dieverbrauchte Rechenleistung (z. B. pro CPU-Stunde). Oft sind diese eher physischen Größen je-doch nicht ganz passgenau zur Abstraktion durch das Resource-Pooling. Beispielsweise ist nichtganz klar, wie viel Platz ein Datensatz auf dem Speichermedium beansprucht, weil Anbieter wieAmazon auch den durch interne Metadaten belegten Platz in Rechnung stellen. Eigentlich wür-de sich der Benutzer daher noch abstraktere Messgrößen wünschen, so dass die Servicenutzungz. B. pro Transaktion, pro Abfrage oder pro Datensatz bezahlt wird.

Measured Service

Um die Abrechnung abhängig von der Nutzung zu gewährleisten, muss natürlich der Ressour-cenverbrauch erhoben werden. Außerdem können durch die Messung bestimmter Servicepara-meter auch die Einhaltung von SLAs überwacht und ggf. Verstöße gegen diese gemeldet werden.Der Anbieter kann so physische Ressourcen umverteilen, um die SLAs der wertvolleren Kunden8Das CAP-Theorem [12] besagt, dass ein verteiltes System (mit bestimmten Voraussetzungen), nichtgleichzeitig maximale Konsistenz (Consistency), Verfügbarkeit (Availability) und Toleranz in Bezugauf Netzwerkprobleme (Partition Tolerance) aufweisen kann. Nur zwei der drei Attribute könnengleichzeitig maximiert werden. Daher nehmen hochverfügbare Cloud-DBS i. d. R. Abstriche bei derKonsistenz in Kauf, um den Ausfall einzelner Knoten und Netzwerkprobleme verkraften zu können.

9ACID steht für Atomic, Consistent, Isolated, Durable. Vgl. hierzu z. B. [36, S. 643 f.].10BASE steht für Basically Available, Soft State, Eventually Consistent. Vgl. hierzu [29].11Es gibt noch weitere Arten, Eventual Consistency zu garantieren.


2.4 Zusammenfassung der Grundlagen

einzuhalten, während nicht so hoch priorisierte Kunden dadurch ein schlechteres Serviceniveauerleben.

Broad Network-Access

Der Zugriff auf den Service erfolgt über das Internet unter Nutzung üblicher Webstandards.Normalerweise kommen hier Standards wie HTTP, REST, XML, SOAP, JSON, RSS etc. zumEinsatz. Dies ermöglicht die Nutzung auf diversen Plattformen und Endgeräten, einschließlichneuerer Smartphones oder Netbooks. Im Endeffekt kann jedes Endgerät, das über einen einiger-maßen vollständigen Webbrowser verfügt, auf SaaS- und PaaS-Dienste zugreifen. IaaS-Dienstewerden in der Regel nicht direkt vom Endanwender angesprochen, sondern (ebenfalls überWebstandards) in andere Dienste oder Anwendungen integriert.

2.3.3 Mangelnde Elastizität der Daten

Ein wichtiger Vorteil von Cloud-Diensten ist ihre oft beworbene „Elastizität“, die auch in Ab-schnitt 2.1.3 bereits vorgestellt wurde. Für echte Computing-Produkte in der Cloud ist dieseElastizität relativ einfach zu erlangen. Virtuelle CPUs oder auch virtuelle Maschinen können inkurzer Zeit an- und abgeschaltet werden. Ob dann der Berechnungsauftrag zu einer Ressourceoder einer anderen geroutet wird, ist für das Ergebnis und die Geschwindigkeit unerheblich.Für Cloud-Storage-Dienste stellt sich die Situation schon anders dar. Zwar ist die Erweite-

rung der vorhandenen Speicherkapazität in der Regel einigermaßen unproblematisch, aber dieReduzierung kann nur durchgeführt werden, wenn die Daten nicht mehr benötigt werden. ImRegelfall muss vorher eine Sicherungskopie erstellt werden, was bei großen Datenmengen Stun-den oder Tage dauern kann und entsprechende Bandbreitenkosten verursacht. Anders als beiComputing-Diensten sind die Daten eher ortsgebunden und nicht so flexibel zu handhaben.Diese Problematik stellt sich natürlich auch für DBS in der Cloud, die mit größeren Mengen

von Daten arbeiten. Dazu kommt aber nun auch das Problem der Skalierbarkeit des DBS alssolches. Die Cloud allein bringt keine Lösung für das aus dem eigenen Rechenzentrum wohl-bekannte Skalierungsproblem von traditionellen RDBS. Zwar existieren skalierbare DBS, diegewisse Abstriche im Vergleich zu den bekannten RDBS machen (vgl. z. B. Passage zur Even-tual Consistency in Abschnitt 2.3.2). Übliche Cloud-Dienste für ein RDBS, wie der AmazonRelational Database Service (RDS), bieten z. B. eine vertikale Skalierbarkeit (scale up) in Be-zug auf Prozessorleistung, Hauptspeicher und Plattenspeicher an. Eine wirklich befriedigendeLösung für das Problem steht allerdings noch aus, weswegen die tatsächliche Elastizität beidatenintensiven Cloud-Diensten nur eingeschränkt existiert.

2.4 Zusammenfassung der Grundlagen

Die generelle Idee der Kapselung von Funktionalität als Dienst ist im IT-Kontext, insbesondereim Rahmen einer SOA, schon länger bekannt. Im Suffix „as-a-Service“ werden genau diese Ideenwieder aufgegriffen und mit den neuen Konzepten des Cloud-Computing – vornehmlich Elas-tizität, Virtualisierung und Zugriff per Internet – zum Konzept des Cloud-Service kombiniert.



Es gibt verschiedene Servicemodelle für Cloud-Dienste und vier denkbare Arten des Cloud-Betriebs. Zusätzlich gibt es Service-Klassen, wie z. B. DaaS, die thematisch gleichartige Dienstezusammenfassen.Wie im diesem Kapitel dargelegt, handelt es sich bei den technischen und wirtschaftlichen

Grundlagen der Cloud-Dienste nur selten um grundlegend neue Konzepte; das Gesamtpaketist jedoch durchaus neuartig. Cloud-Computing und insbesondere Database-as-a-Service kannfür KMU sehr attraktiv sein, wenn die angebotenen Dienste zu den Rahmenbedingungen desgeplanten Einsatzes passen. Welche Aspekte dabei genau beachtet werden müssen, beschreibtdas folgende Kapitel.


3 Grundsatzentscheidung „Cloud odernicht?“

..


� Cloud-Computing wird in vier Dimensionenbetrachtet.

� Wirtschaftlich kann Cloud-Computing sehrattraktiv sein, muss es aber nicht, insbesonderebei individuellen Verträgen.

� Technisch birgt Cloud-Computing für denAnwender nur wenig wirklich neueHerausforderungen, fordert aber oft eineAnpassung bestehender Systeme.

� Rechtlich ist Cloud-Computing noch höchstproblematisch und derzeit weitgehend ungeklärt.

� Organisatorisch erfordert Cloud-Computingstringente Abläufe, die gegebenenfalls imUnternehmen erst noch einzuführen sind.

� Die Entwicklung einer Cloud-Strategie aufManagementebene ist eine essentielleVoraussetzung für jedes Cloud-Projekt.

Nachdem in Kapitel 2 durch eine Klä-rung der Grundlagen von Cloud-Computingund Database-as-a-Service ein gemeinsa-mes Verständnis der Thematik geschaffenworden ist, geht es in diesem Kapitel um diegrundsätzliche Entscheidung, ob eine Lö-sung mit Cloud-Computing angestrebt wer-den sollte oder nicht. Dazu werden eini-ge Vorzüge und Probleme von aktuellenCloud-Angeboten analysiert. Zudem wer-den einige Handlungsempfehlungen gege-ben, für den Fall, dass Cloud-Computingtatsächlich in Frage kommt. Zum Ende desKapitels stellen wir zwei übliche Szenari-en des Einsatzes von Cloud-Diensten vorund erläutern die resultierenden Anforde-rungen. Bedingt durch die Leitfrage desForschungsprojekts fokussieren wir in die-sem Kapitel – wo nötig – auf das Spezialge-biet Database-as-a-Service. Ein kurzer Kata-log von Leitfragen, die eine direkte Anwen-dung der Erkenntnisse auf das jeweilige Szenario ermöglichen, rundet das Kapitel ab.

3.1 Cloud Computing in vier DimensionenIm Folgendenwerden die wichtigsten Vor- und Nachteile bzw. Neuerungen des Cloud-Computingserörtert. Da das Feld unter anderem durch die Verschiedenheit der Angebote recht unübersicht-lich ist, wird die Diskussion zur besseren Übersichtlichkeit entlang von vier Dimensionen struk-turiert, die im Rahmen der Analysen zu diesem Leitfaden identifiziert wurden. Diese Strukturwird auch im weiteren Verlauf dieses Leitfadens beibehalten. Zur Sprache kommen

1. wirtschaftliche,2. technische,3. rechtliche und


3 Grundsatzentscheidung „Cloud oder nicht?“

..CloudComputing

.

Wirtschaftlich

.

Technisch

.

Rechtlich

.

Organisatorisch

.

3.1.1

.

3.1.2

.

3.1.3

.

3.1.4

Abbildung 3.1: Die vier Dimensionen des Cloud Computings und gleichzeitig dieStruktur des vorliegenden Kapitels mit der jeweiligen Abschnittsnum-mer.

4. organisatorischeAspekte. Abbildung 3.1 stellt die Struktur des Kapitels inklusive der entsprechenden Abschnitts-nummern grafisch dar.

3.1.1 Wirtschaftliche Dimension

Zweifellos sind die wirtschaftlichen Vorteile des Cloud-Computing die Hauptargumente, war-um sich Unternehmen überhaupt mit dem Thema beschäftigen möchten. In diesem Abschnittsollen daher die am häufigsten genannten Vorteile aufgelistet und hinterfragt werden, dennnicht immer sind die angepriesenen Vorzüge auch wirklich positiv zu bewerten. Üblicherweisewerden sinngemäß folgende Punkte angesprochen (vgl. auch [32, S. 12]):

� Vorteile durch Bezahlung nur für die tatsächliche Nutzung� Kostenvorteile des Anbieters, die an den Cloud-Nutzer weiter gegeben werden� Kostenvorteile des Cloud-Anwenders, durch gesteigerte Flexibilität

Im Folgenden werden die Punkte jeweils detailliert erläutert. Zuvor sei allerdings noch aufeinen Aspekt hingewiesen: Für einen Vergleich, ob sich Cloud-Computing im Vergleich zu einerLösung im eigenen Haus lohnt, ist allerdings offensichtlich die erste Voraussetzung, dass dieKosten für eine solche Lösung im eigenen Unternehmen bekannt oder berechenbar sind. Solltedies nicht möglich sein, so kann keine objektive Entscheidung für oder gegen Cloud-Computinggetroffen werden.

Pay-per-Use – Nutzungsabhängige Bezahlung

Wie bereits in Abschnitt 2.1.3 angedeutet, werden die Cloud-Dienste in der Regel abhängigvon der Nutzung abgerechnet; im Englischen spricht man von Pay-per-Use. Wird der Ansatz


3.1 Cloud Computing in vier Dimensionen

in Reinform angewendet, so hat dies zur Konsequenz, dass die Kosten für die Cloud-Nutzungganz direkt mit der tatsächlichen Ressourcennutzung korrelieren. Benötigt der Nutzer zeitweiligsehr viele Ressourcen, so bezahlt er für diese Zeit höhere Gebühren. Werden in einem Zeitraumjedoch keine Ressourcen benutzt, so fallen auch keine Kosten an. Oft findet man aber einenhybriden Ansatz bestehend aus einer Grundgebühr und einem nutzungsabhängigen Anteil. DieGrundgebühren sind aber in der Regel so niedrig, dass man trotzdem von einer nutzungsab-hängigen Bezahlung sprechen kann.Das Pay-per-Use-Prinzip hat im Allgemeinen zur Folge, dass effektiv nur ungefähr so viele

Ressourcen bezahlt werden, wie es die Nachfrage erfordert. Somit bezahlt der Cloud-Nutzer,vereinfacht gesagt, die durchschnittliche Last. Im eigenen Rechenzentrum wird üblicherweiseso geplant, dass auch die erwarteten Lastspitzen, z. B. zum Quartalsende, befriedigt werdenkönnen. Somit muss hier, wieder vereinfacht ausgedrückt, die maximale Last bezahlt werden,wenn der Dienst auf dedizierter Hardware läuft.Gleichzeitig hat die nutzungsabhängige Bezahlung auch die Folge, dass sich das Investiti-

onsrisiko größtenteils vom Nutzer zum Cloud-Anbieter verlagert. Der Anbieter übernimmt dieKosten für die benötigte Soft- und Hardware und trägt somit auch das Investitionsrisiko. DerKunde bezahlt nur für die tatsächliche Nutzung des Dienstes. In der englischsprachigen Weltwird dieser Punkt häufig als Transformation von Capital Expenditure (CAPEX) in OperationalExpenditure (OPEX), also im weitesten Sinne als Umwandlung von einmaligen in laufende Kos-ten, bezeichnet. Der Dienstanbieter wird natürlich das Investitionsrisiko bei der Preisgestaltungberücksichtigen. Jedoch wird das Risiko „auf viele Schultern“ verteilt, so dass jeder Kunde imEndeffekt nur einen geringen Bruchteil davon bezahlt.Die nutzungsabhängige Bezahlung hat allerdings auch Auswirkungen bei der Berechnung

der wirtschaftlichsten Alternative. Soll eine SaaS-Lösung mit einer Lösung verglichen werden,die den Kauf von Software-Lizenzen beinhaltet, so sollten die Kosten, wenn möglich, über dengesamten prognostizierten Nutzungszeitraum verglichen werden. In jedem Fall müssen aberMigrations- und Anpassungkosten einbezogen werden. Für die Lösung im eigenen Unterneh-men fallen darüber hinaus meist noch Wartungsgebühren und Kosten für den Betrieb (Personal,Hardware, zusätzliche Software) an. Eventuell sollten auch zwischenzeitliche Upgradekosteneinkalkuliert werden [16]. Insgesamt empfiehlt es sich, einen ganzheitlichen Ansatz, z. B. ba-sierend auf der Total Cost of Ownership (TCO), zu wählen, um die gesamten Kosten der Alter-nativen zu vergleichen.Bereits ohne aufwändige TCO-Berechnung können einige generelle Vor- und Nachteile der

nutzungsabhängigen Bezahlung genannt werden. Offensichtlich lohnt sich ein Pay-per-Use-Modell, wenn die „Stückkosten“ in der Cloud günstiger sind als im eigenen Rechenzentrum.Kostet beispielsweise eine CPU-Stunde auf einer VM in Amazons EC2 weniger als eine CPU-Stunde im eigenen Unternehmen, so ist es auf jeden Fall günstiger, das Cloud-Angebot wahr-zunehmen. Oft werden die Stückkosten in der Cloud jedoch geringfügig höher sein als die dereigenen Ressourcen. Selbst dann kann sich der Schritt in die Cloud rechnen, wenn nämlich derPreisaufschlag, im Englischen als Utility-Premium bezeichnet [38], kleiner ist als das Verhältnisvon erwarteten Lastspitzen zu erwarteter Durschnittslast für den Dienst. Wenn z. B. in Spitzen-

Faustregelzeiten doppelt so viele Ressourcen benötigt werden wie im durchschnittlichen Fall, so ist derCloud-Dienst trotzdem günstiger, sobald die Stückkosten für die Cloud weniger als 200% der



internen Kosten betragen [38]. Diese Faustregel sollte jedoch nur ein erster Anhaltspunkt sein,um abzuschätzen, ob sich der Schritt in die Cloud rein monetär lohnen könnte oder nicht, danoch weitere Faktoren in die Berechnung hineinspielen.

Kostenvorteile durch Skaleneffekte beim Anbieter

Durch die hohe Spezialisierung des Anbieters und einen hohen Grad an Automation im Rechen-zentrum wird es möglich, die Betriebskosten deutlich unter das Niveau zu senken, das ein gutorganisiertes KMU erreichen könnte. Auf Beschaffungsseite entsteht ein großer Kostenvorteildurch die Skaleneffekte, die der Anbieter in Bezug auf die Investitionen in die Infrastrukturseiner Rechenzentren realisieren kann. Hochverfügbare Systeme und Maßnahmen für den Ka-tastrophenfall können auf größerer Skala eingekauft und auf eine größere Anzahl von Nutzernverteilt werden. Auf diese Weise lassen sich für sehr große Rechenzentren – also solche in derGrößenordnung von 50 000 Servern – Stückkosten realisieren, die nur 15-20% der Kosten be-tragen, die ein mittleres Rechenzentrum in der Größenordnung von 1 000 Servern realisierenkönnte. Zudem können die Kosten für Brandschutz, Kühlung usw. auf viele Kunden umgelegtwerden. Diese Skaleneffekte wird der Anbieter zumindest teilweise an seine Kunden weiterge-ben, um attraktive Preise anzubieten.Auf technischer Seite kann der Anbieter durch Verfahren des Autonomic Computing [15]

zusätzliche Einsparungen erreichen. Indem alle Aspekte der Verwaltung und der Konfigurationder Cloud-Infrastruktur weitestgehend automatisiert werden, lässt sich die Zahl der benötigtenMitarbeiter im Rechenzentrum und in der Verwaltung drastisch reduzieren. Auch aufseiten desKundenunternehmens bedeutet die Auslagerung eine Entlastung beim IT-Personal, das sich nunum komplexere Aufgaben kümmern kann. Von der Theorie her bietet das Cloud-Computing alsodie Möglichkeit für eine Win-Win-Situation.

Kostenvorteile durch Ausnutzung der Elastizität

Der Einsatz von Cloud-Computing kann dem Unternehmen die Möglichkeit geben, bisher unge-nutzte IT-Kapazitäten durch dynamische Zuweisung je nach aktuellem Bedarf Nutzen stiftendeinzusetzen und die Investitionen in neue Hardware zu reduzieren. Diese Dynamik ermög-licht neue Geschäftsabläufe und kürzere Reaktionszeiten. So können z. B. neue Datenbankeneinfach per Mausklick erzeugt werden, anstatt den oft langwierigen Weg über die traditionel-len Prozesse zu nehmen. Im Endeffekt kann das Unternehmen so auch das Problem der Über-bzw. Unterversorgung deutlich reduzieren. Wird die Elastizität richtig ausgenutzt, werden dieRessourcen kostenmäßig nur noch etwa für den durchschnittlichen Fall vorgehalten. Unnöti-ge Investitionen in eigene Hardware, um Lastspitzen befriedigen zu können, entfallen, ebensoProbleme, falls unvorhergesehene Lasten zu einer Ressourcenknappheit führen.Die Elastizität bietet zudem Vorteile in Bezug auf die Bearbeitungsgeschwindigkeit einer

Aufgabe. Ist beispielsweise ein Berechnungsproblem oder eine Massendatenverarbeitung gutparallelisierbar, so kann das Problem einfach auf eine große Zahl von Knoten verteilt werden.Das Pay-per-Use-Modell zusammen mit der Elastizität versprechen dann, dass ein Problem wel-ches n Stunden auf einem Knoten benötigt, auch in einer Stunde durch n Knoten gelöst werden



kann – zu demselben Preis. Dieses Phänomen wird als Cost-Associativity bezeichnet [1]. Da-durch können Unternehmen große Batchjobs sehr viel schneller berechnen lassen als auf dereigenen Infrastruktur, so dass sich zeitliche Vorteile bei konstanten Kosten ergeben.Diese zwei viel beworbenen Vorteile von Cloud-Computing werden in der Praxis aber nur

dann zu realisieren sein, wenn eine stringente Cloud-Strategie verfolgt und umgesetzt wird.Außerdem eignet sich nicht jede Art von Problem gleichermaßen für die Anwendung der Cost-Associativity (vgl. Abschnitt 2.3.3). Für die ersten Gehversuche in der Cloud sollten die Zieledaher in dieser Hinsicht nicht zu hoch gesteckt werden, um keine unnötige Enttäuschung zuerleben.

3.1.2 Technische Dimension

Obgleich viele der beworbenen Vorteile von Cloud-Computing wirtschaftlicher Natur sind, gibtes trotzdem auch einige technische Vorteile, insbesondere die Elastizität und Leistungsfähig-keit der Cloud-Infrastruktur. Zudem gibt es einige neue technische Aspekte, die beachtet wer-den wollen, die zum einen mit der eingesetzten Virtualisierung zusammen hängen und die sichandererseits aus neuen Technologien wie NoSQL-DBS ergeben. Als häufigster technischer As-pekt wird jedoch die Sicherheit der Cloud-Lösung angezweifelt, weswegen diese zuerst kurzbehandelt wird.

Sicherheit der Cloud

Cloud-Anbieter legen gezwungenermaßen sehr hoheMaßstäbe für die Sicherheit und Leistungs-fähigkeit der eigenen Systeme an. Entsprechend stehen mehr Ressourcen und besser geschulteMitarbeiter zur Verfügung, die sich ein KMU in der Regel nicht leisten kann. Zumindest beiden etablierten Anbietern kann daher von einem sehr hohen Sicherheitsstandard ausgegangenwerden, der dem eines eigenen Rechenzentrums in nichts nachsteht. Insbesondere im Hinblickauf die Abwehr von Denial-of-Service-Angriffen, die durch die zunehmende Kommunikationüber öffentliche Netze an Bedeutung gewinnen, sind etablierte Cloud-Anbieter üblicherweisesehr viel besser gerüstet als ein traditionelles Rechenzentrum.Zwar müssen die Daten, die in der Cloud verarbeitet werden sollen, in der Regel über unsi-

chere Netze an den Anbieter gesendet werden. Bei den allermeisten Anbietern lässt sich aberbereits durch einfache Maßnahmen, wie der Verwendung des SSL-Protokolls, ein akzeptablesMaß an Sicherheit gewährleisten. Die pauschale Befürchtung, durch Cloud-Computing nähmedie Sicherheit grundsätzlich ab, ist schlicht falsch. Bei kleineren Unternehmen mit weniger pro-fessionellem IT-Personal kann sogar leicht das Gegenteil der Fall sein. Kapitel 5 widmet sichim Detail den verschiedenen Aspekten der Sicherheit.

Elastizität und Leistungsfähigkeit der Infrastruktur

Die Elastizität von Cloud-Diensten gibt dem Kundenunternehmen die Möglichkeit, Ressourcenbei Bedarf dynamisch hinzuzufügen und wieder freizugeben. Mögliche Projektziele hängen so-mit nicht mehr davon ab, ob genügend Rechenleistung oder Speicherkapazität vorhanden ist.



Dieser Vorteil wird allerdings hauptsächlich für IaaS und mit Einschränkungen PaaS relevant.Dienste auf SaaS-Ebene bieten eher selten nennenswerte Chancen in dieser Hinsicht.Für alle drei Servicemodelle gilt jedoch, dass die Cloud-Infrastruktur tendenziell mindes-

tens so leistungsfähig ist, wie die Infrastruktur im eigenen Rechenzentrum. Besonders aufgrundausbleibender Investitionen in Hardware, die viele KMU z. B. aufgrund der unklaren Kosten-Nutzen-Bilanz scheuen, wird in den Unternehmen oft ältere oder sogar veraltete Hardwareeingesetzt. Diese Hardware kann Ausfälle oder starke Schwankungen in der Last nicht so gutabfangen, wie die hochverfügbare Infrastruktur im Rechenzentrum des Cloud-Anbieters. Ten-denziell lässt sich also festhalten, dass sowohl die Leistungsfähigkeit der Infrastruktur als auchdie Flexibilität im Hinblick auf den Ressourceneinsatz durch Cloud-Computing verbessert wird.

Virtualisierung

Als weiterer technischer Vorteil wird der Einsatz von Virtualisierungstechnologie in der Cloudangeführt. Zwar ist ein solcher Einsatz an sich erst einmal nur für den Anbieter von Nutzenund nicht so sehr für den Kunden. Es entstehen aber auch einige positive Nebeneffekte fürden Cloud-Anwender. Während der Cloud-Anbieter die Virtualisierung eher deshalb einsetzt,um seine physische Infrastruktur ausreichend hoch auszulasten, kann der Kunde von der Vir-tualisierung profitieren, weil sie eine Abstraktionsschicht zwischen der Dienstimplementierungund der Kundenanwendung bildet. Im Falle von IaaS kann der Cloud-Nutzer so z. B. standar-disierte, virtuelle Ressourcen beziehen ohne sich um die konkrete Realisierung zu kümmern.Der Anbieter kann die zugrunde liegende Hardware beliebig tauschen und sogar grundlegendändern, solange die Abstraktionsschicht unberührt bleibt. Im Fall von PaaS und SaaS bleibt diezugrunde liegende Software-Schnittstelle unverändert, selbst wenn der Anbieter die Implemen-tierung neu konzipiert. Der wirkliche Vorteil der Virtualisierung für den Kunden liegt also inder Standardisierung der Ressourcen. Im Endeffekt ist zu erwarten, dass die Standardisierungsogar über Anbieter hinweg stattfindet und z. B. eine standardisierte CPU-Stunde bei einembeliebigen Anbieter eingekauft werden kann. Dieser Zustand ist jedoch noch nicht absehbar,selbst wenn viele Cloud-Anbieter und -Nutzer ihn sich wünschen.1

NoSQL-Datenbanken

Besonders im Hinblick auf DaaS gibt es in der Cloud eine weitere interessante Entwicklung:Große Vorreiter der Cloud, vornehmlich Amazon und Google, sind von den traditionellen RDBSabgerückt hin zu den neu aufgekommenen NoSQL-DBS. Dabei handelt es sich nicht zwangsläu-fig um DBS, die überhaupt keine SQL-Anweisungen mehr verarbeiten können, sondern maninterpretiert diesen Bezeichner als Not only SQL. Es gibt verschiedene Typen dieser NoSQL-DBS, wobei die bekanntesten die folgenden sind:

� dokumentenorientierte DBS, wie MongoDB oder CouchDB� Key-Value-Stores, wie Memcached oder SimpleDB� spaltenorientierte Speicher, wie BigTable oder HBase� Graph-Datenbanken, wie AllegroGraph oder Neo4j

1Vgl. http://opencloudmanifesto.org/.


http://www.mongodb.org/

http://couchdb.apache.org/

http://memcached.org/

http://aws.amazon.com/simpledb/

http://de.wikipedia.org/wiki/BigTable

http://hbase.apache.org/

http://www.franz.com/agraph/allegrograph/

http://neo4j.org/

http://opencloudmanifesto.org/


Allen NoSQL-DBS ist gemein, dass sie dem relationalen Modell den Rücken kehren, um hori-zontale Skalierbarkeit zu erreichen, die in der Cloud eine sehr viel größere Bedeutung erlangtals zuvor (vgl. hierzu Abschnitte 2.3.2 und 2.3.3). Je nachdem, welche Funktionalität in dieCloud ausgelagert werden soll, kann es sinnvoll sein, sich vom klassischen relationalen Mo-dell zu lösen und sich auf die neuen Technologien einzulassen. Da diese speziell für die Cloudentwickelt wurden, können mit ihnen die Vorteile deutlich effektiver ausgenutzt werden.

Problematische Anbindung an andere Systeme

Die erfolgreichsten Cloud-Projekte, mit denen die Anbieter werben, sind normalerweise solche,die ausschließlich mit einem Dienst oder zumindest durch einen Anbieter realisiert wurden. Dasist leicht erklärlich, denn ein Hauptproblem, das nach wie vor ungelöst ist, besteht in der Kopp-lung der neuen Cloud-Dienste mit einander und insbesondere mit bestehenden Systemen. Zumeinen ist der bereits thematisierte Transport der Daten zwischen den Systemen problematisch(vgl. Abschnitt 2.3.3). Zum anderen erschweren aber verschiedene weitere Hürden den Erfolg;die wichtigsten Hürden sind dabei:

� Die Anbieter offerieren häufig nur eine einzige, proprietäre Schnittstelle zu dem Cloud-Dienst. Oft basiert diese auf dem REST-Paradigma (oder ist zumindest daran angelehnt).Diese Wahl erschwert es, die neuen Dienste mit älteren Systemen zu koppeln, wenn diesenoch nicht für die Kommunikation mit dieser Art von API ausgelegt sind.

� Der Cloud-Dienst bietet nur beschränkte Im- und Export-Möglichkeiten, so dass nichtalle benötigten Daten automatisch eingespielt oder ausgelesen werden können.

� Die bestehenden Systeme im Unternehmen bieten keine Schnittstellen für eine Kopplungmit anderen Diensten, sondern lediglich Batchfunktionen für Import bzw. Export.

� Die transaktionsorientierte Natur der bestehenden Systeme ist inkompatibel mit der neu-en Idee der Eventual Consistency bzw. mit der Möglichkeit, dass ein anderes System, z. B.aufgrund von Netzwerkproblemen, nicht erreichbar ist.

Zur Ehrenrettung der bestehenden Systeme sollte aber auch gesagt werden, dass selbst dieKopplung zwischen zwei Cloud-Diensten aus denselben oder ähnlichen Gründen bei weitemnicht immer reibungslos funktioniert. Insgesamt bleibt daher festzuhalten, dass die geplanteAnbindung an andere Systeme sehr genau geprüft werden muss, bevor der Schritt in die Cloudvollzogen wird.

3.1.3 Rechtliche Dimension

Aus juristischer Perspektive ist das Auslagern von Funktionalität in die Cloud ganz ähnlichzum klassischen IT-Outsourcing zu behandeln, da es sich beim Cloud-Computing ja im We-sentlichen um ein solches handelt. Jedoch verschärft sich die rechtliche Situation insofern, alsdass die Transparenz der Cloud-Lösung deutlich niedriger ist als im klassischen IT-Outsourcing-Szenario. Während bei klassischen Outsourcing-Verträgen oft das genaue Rechenzentrum be-zeichnet wird, in dem die Datenverarbeitung stattfindet, ist bei Standardverträgen zu Cloud-



Diensten noch nicht einmal festgelegt, in welchem Teil der Erde sich die Daten befindenwerden.Daher müssen bei Cloud-Diensten einige Aspekte besonders beachtet werden.Zudem ist zu bemerken, dass viele rechtlichen Aspekte noch nicht final geklärt sind. So

ist z. B. das Problem einer Haftung für Vermögensschäden im Fall eines Fehlers durch denAnbieter noch offen. Denkbar wäre beispielsweise der Fall, dass die Berechnung von Finanz-daten fehlerhaft geschieht. Wer haftet und wie kann ein Fehler nachgewiesen werden, wennder Cloud-Dienst falsche Ergebnisse liefert? Auch die Problematik der Reproduzierbarkeit bzw.Nachvollziehbarkeit von wichtigen Berechnungen, wie dem Jahresabschluss, ist noch unklar.Hier benötigt man oft die Möglichkeit, die Herkunft der Daten (Data-Provenance) oder den Be-rechnungsweg (Data-Lineage) nachzuweisen. An dieser Stelle soll daher nur eine Auswahl derwichtigsten Handlungsempfehlungen aus Sicht zahlreicher Praktiker vorgestellt werden [3].

� Die Rechtsabteilung und die für die Vertragsgestaltung zuständigen Mitarbeiter müssenfrühzeitig miteinbezogen werden. Viele Standardverträge der Cloud-Anbieter werdenden Anforderungen des eigenen Unternehmens nicht gerecht werden, so dass die ent-sprechenden Fachleute direkt auf problematische Klauseln oder Aspekte hinweisen undentsprechende Verbesserungen vorschlagen können. Auch grundsätzliche rechtliche Pro-bleme mit dem Auslagern bestimmter Systeme können so rechtzeitig erkannt werden.

� Die Rechtsabteilung muss ebenfalls frühzeitig zusammen mit den betroffenen Fachab-teilungen untersuchen, in welchem Ausmaß das Auslagern in die Cloud juristische Re-gularien und interne Vorgaben berührt. Zumindest die Gesetzgebung zum Datenschutzist für die meisten Cloud-Projekten relevant. Damit einher gehen in der Regel auch An-forderungen an die Datensicherheit (vgl. Kapitel 5). Eventuell werden auch gesetzlicheVorgaben zur eingesetzten Infrastruktur oder zur Kontrolle über diese gemacht. In die-sem Fall muss überprüft werden, ob es Cloud-Anbieter gibt, die diese Vorgaben erfüllenkönnen.

� Da die Cloud für den Kunden bewusst undurchsichtig gestaltet wird, um die oben be-schriebenen Vorteile der Abstraktion zu erlangen, sollten Maßnahmen zur teilweisenAufhebung dieser Intransparenz vorgesehen werden. Hier könnte die aus klassischenIT-Outsourcing-Verträgen bekannte Überprüfungsklausel (Right-to-Audit-Klausel) helfen,die es dem Cloud-Nutzer ermöglicht, die Rechenzentren des Providers vor Ort zu über-prüfen. Oft wird von dieser Möglichkeit zwar kein Gebrauch gemacht, aber sie kann hel-fen, eine Vertrauensbeziehung zwischen den Parteien aufzubauen. Besser noch als einesolche Klausel sind natürlich einschlägige Zertifikate externer Gutachter, die der Cloud-Anbieter vorweisen kann. Hier ist insbesondere die Zertifizierung nach ISO/IEC 27001zu nennen.

� Wenn die Zertifizierung nach ISO/IEC 27001 noch nicht erfolgt ist, sollte zumindest derstrategische Plan des Anbieters in Bezug auf diese Zertifizierung erfragt werden. Zusätz-lich kann hilfsweise auch die Umsetzung von ISO/IEC 27002 demonstriert werden.

� Genauso wichtig wie die Analyse des tatsächlichen Cloud-Anbieters ist die Untersuchungder vorgelagerten Dienstleister desselben. Zum einen ist dies für die eigene Einschätzung



der Zuverlässigkeit sinnvoll. Zum anderen kann das aber auch durch gesetzliche Anfor-derungen erforderlich werden, wenn z. B. die Daten zur Verarbeitung noch an weitereDienstleister übergeben werden.

� Im Vertragswerk sollte eine klare Vereinbarung über die jeweiligen Zuständigkeiten derParteien getroffen werden, damit klar ist, welche Partei welche Aufgaben (z. B. Sicherungder Daten) wahrnehmen muss.

� Durch Rechts- und Fachabteilungen muss geklärt werden, wie der Nachweis über dieErfüllung der gesetzlichen Normen statt finden könnte. Es muss ein Prozess installiertwerden, der die Sammlung von z. B. Log-Dateien oder Aktivitätsberichten formalisiertund mit dessen Hilfe ein juristisch ausreichend sicherer Nachweis über die Erfüllungder verschiedenen Anforderungen möglich ist. Viele dieser Informationen kann nur derCloud-Provider liefern, was im Vorfeld geklärt werden muss.

Es bleibt zu bemerken, dass ein Cloud-Computing-Projekt aus rechtlicher Sicht keine Vorteilesondern eher zusätzliche Problemstellungen mit sich bringt. Insofern sollten die Vorteile austechnischer und wirtschaftlicher Sicht verglichen werden mit den zusätzlichen Problemen, dieauf der juristischen Dimension aufkommen. Je nachdem, wie kooperativ der Cloud-Anbieter indieser Hinsicht ist, kann sich diese Dimension derzeit leider als K.O.-Kriterium für das Cloud-Projekt erweisen. Insbesondere durch die sehr restriktive Datenschutzgesetzgebung in Deutsch-land kann es zu Problemen kommen, wenn der Cloud-Anbieter Daten in einem Land mit laxerenVorgaben verarbeiten lässt.2 Weitere Aspekte hierzu werden in Abschnitt 4.3 diskutiert. Dasrechtliche Risiko nimmt allerdings stark ab, wenn bereits Präzedenzfälle existieren, in denenandere Unternehmen in vergleichbarer Situation ähnliche Lösungen realisiert haben. Dann ist– gesetzt den Fall, dass die Lösungen schon eine Weile existieren – davon auszugehen, dass dasentsprechende Risiko stark reduziert ist.

3.1.4 Organisatorische Dimension

Aus organisatorischer Sicht ist die Cloud-Nutzung nahezu identisch mit einem klassischen IT-Outsourcing. Sind entsprechende Prozesse bereits im Unternehmen installiert, so muss für eineVerwaltung der Cloud-Dienste nur eine entsprechende Erweiterung stattfinden. Wichtiger alsbeim klassischen Modell ist in der Cloud allerdings, dass regelmäßig geprüft wird, ob es inzwi-schen einen günstigeren Anbieter gibt. Da sich der Markt noch stetig wandelt, kann es leichtsein, dass neue, besser passende Angebote auftauchen oder dass andere Anbieter identischeDienstleistungen zu deutlich niedrigeren Preisen anbieten. Für solche Fälle sollte ein struktu-riertes Vorgehen vorgesehen werden, um die Möglichkeit eines Anbieterwechsels zu erörtern.Dazu bietet es sich an, die Dokumentation der ursprünglichen Anbieterwahl zu Rate zu zie-hen, um die damals ausschlaggebenden Punkte der Reihe nach zu prüfen und so bereits einenKriterienkatalog für den Vergleich verschiedener Produkte an der Hand zu haben.2Eine grafische Übersicht über die verschiedenen Datenschutzniveaus bietet http://forrester.com/cloudprivacyheatmap.


http://forrester.com/cloudprivacyheatmap

http://forrester.com/cloudprivacyheatmap


Auch die technische Betreuung der Systeme ist aus Sicht des Systemadministrators so gutwie identisch zur Verwaltung der physischen Systeme im eigenen Rechenzentrum. Abgese-hen davon, dass nun keine physische Box mehr im Serverraum steht, werden auch Cloud-Systeme mit denselben Fernwartungsprogrammen und Werkzeugen verwaltet wie lokale Sys-teme. Verwendet man z. B. virtuelle Maschineninstanzen in der Cloud, so werden diese ge-nauso verwaltet wie virtuelle Maschinen im eigenen Haus. Im Fall eines relationalen Cloud-DBS hat der Administrator zwar weniger Eingriffsmöglichkeiten in die Konfiguration des Da-tenbankmanagementsystems per se (z. B. Nutzung des Hauptspeichers, Größen von Pufferspei-chern), aber die Verwaltung innerhalb des RDBS bleibt wie gehabt (z. B. Benutzerrechteverwal-tung, Anlegen von Datenbanken und Relationen) [18].Die Verwaltungsfunktionen werden dabei je nach Art des bezogenen Dienstes entweder durch

die virtualisierte Anwendung (IaaS, PaaS) oder durch eine Web-Oberfläche des Anbieters (SaaS,PaaS) durchgeführt. Zudem stellen Drittanbieter bereitsWerkzeuge zur Überwachung der Cloudsanderer Anbieter bereit, mit deren Hilfe Ausfälle oder Leistungseinbrüche erkannt werden kön-nen. Als kleine Auswahl dieser Anbieter – ohne Anspruch auf Vollständigkeit – seien folgendeDienste genannt (alle Angaben mit Stand August 2010):

� CloudSleuth3 visualisiert die Zuverlässigkeit und Verfügbarkeit der populärsten IaaS-und PaaS-Anbieter, indem von zurzeit 50 Standorten in den USA und 75 internationalenStandorten auf die jeweiligen Dienste zugegriffen wird.

� CloudHarmony4 führt Tests zur Leistungsfähigkeit durch, indem die Geschwindigkeitund Latenzzeit für ein- und ausgehenden Datenverkehr gemessen wird. Im Blog werdenaußerdem weitere Analysen publiziert, die sich unter anderem mit CPU-Leistung oderDatendurchsatz befassen.

� Cloudstone5 ist eine Desktop-Anwendung zur Analyse von Cloud-Computing- und Web-2.0-Diensten. Dazu erzeugt Cloudstone künstliche Serverlast und berechnet entsprechen-de Kennzahlen. Das Projekt stellt zwar aktuell keine Ergebnisse zur Verfügung, mit derAnwendung können aber eigene Analysen durchgeführt werden.

� Cloud CMP6 schickt nach eigenen Angaben „Clouds gegeneinander in den Ring“. Dabeiwerden die Leistungsfähigkeit von Rechenleistung, Speicher und Netzwerk verglichen.Als Resultat wird unter anderem ermittelt, was der Betrieb einer bestimmten Applikationbei einem bestimmten Cloud-Anbieter kosten würde.

� CloudFail.net7 gibt Auskunft über Ausfälle und Störungen verschiedener Cloud-Anbieter.Dazu aggregiert der Dienst verschiedene RSS-Feeds, unter anderem von Amazon, Googleund Rackpace. Auch Web-2.0-Dienste wie Twitter, die streng genommen keine Cloud-Dienste sind, sind berücksichtigt.

3http://www.cloudsleuth.net/4http://www.cloudharmony.com/5http://radlab.cs.berkeley.edu/wiki/Projects/Cloudstone6http://cloudcmp.net/7http://cloudfail.net/


http://www.cloudsleuth.net/

http://www.cloudharmony.com/

http://radlab.cs.berkeley.edu/wiki/Projects/Cloudstone

http://cloudcmp.net/

http://cloudfail.net/

3.2 Typische Szenarien für Cloud-Nutzung durch KMU

Öffentliche Cloud

Unternehmen

Abbildung 3.2: Schematische Darstellung des Szenarios KMU ↔ Cloud.

� Cloutage.org8 hilft bei der Einschätzung der Sicherheit verschiedener Cloud-Dienste.Das Projekt möchte eine einheitliche Anlaufstelle für bekannte und veröffentlichte si-cherheitsrelevante Vorfälle (Incidents) in der Cloud werden.

Diese oder vergleichbare Werkzeuge sollten bei der regelmäßigen Beurteilung der Cloud-Anbieter zur Hilfe gezogen werden.


Aus den Diskussionen der Cloud Use Case Group, einer offenen Interessengemeinschaft ausCloud-Anbietern und -Nutzern, sind verschiedene Szenarien für die Cloud-Nutzung entstanden,welche in einem regelmäßig aktualisierten Dokument [28] bereitgestellt werden. DiejenigenSzenarien, die für KMU am wahrscheinlichsten sind, werden im Folgenden zusammen mit denjeweiligen Implikationen kurz vorgestellt.

3.2.1 Szenario 1: KMU↔ Cloud

In diesem Szenario nutzt ein KMU Cloud-Services in seinen internen Prozessen (vgl. Abbil-dung 3.2). Die Dienste werden also nur von den Mitarbeitern des Unternehmens einsetzt. Kun-den kommen nicht mit der Cloud in Berührung. Dies ist zu Anfang vermutlich das häufigste Sze-nario für die Cloud-Nutzung [28], da sich die Unternehmen so erst einmal intern mit den neuenCloud-Diensten vertraut machen können, bevor diese für die Kunden freigegeben werden. EinUnternehmen kann in diesem Szenario beispielsweise Speicherplatz für die Datensicherung inder Cloud einsetzen, virtuelle Maschinen auf Cloud-Infrastruktur zur Erweiterung der Rechen-kapazitäten und Befriedigung von Bedarfsspitzen bereitstellen oder Cloud-Anwendungen fürbestimmte Unternehmensprozesse (z. B. E-Mail, Kalender, CRM, Kollaboration, usw.) einset-zen. Insbesondere können aber auch Cloud-Datenbanken im Rahmen der Datenverarbeitung8http://cloutage.org/


http://cloutage.org/


im Unternehmen verwendet werden, um z. B. Daten mit Vertragspartnern oder sogar Regie-rungsstellen auszutauschen.Die wichtigsten Anforderungen, die sich aus diesem Szenario ergeben, sind:

Identität und Identitätsverwaltung Der Cloud-Service muss den Benutzer authentifizieren. EinBenutzer, der einem Unternehmen angehört, hat häufig schon eine Identität innerhalbdieses Unternehmens. Daher sollte diese Identität möglichst auch für den Zugriff auf dieCloud-Dienste verwendet werden, z. B. im Rahmen eines Single Sign On (SSO). Gege-benenfalls sind weitere Sicherheitsanforderungen z. B. zum Schutz der Privatsphäre desBenutzers zu beachten.

Offener Zugriff Die Nutzung des Cloud-Services sollte keine bestimmte Plattform oder Tech-nologie benötigen, die den Zugriff auf den Cloud-Service einschränkt, denn dies würdedem Cloud-Gedanken entgegen wirken.

Ortsbezug Ein Grundprinzip des Cloud-Computings lautet zwar, dass die physische Realisie-rung des Dienstes vor dem Benutzer verborgen bleibt. In einigen Situationen kann es je-doch notwendig werden, den genauen Ort der physischen Ressourcen zu kennen. Wennbeispielsweise Daten Ländergrenzen überschreiten, können dadurch ungewollte juristi-sche Konsequenzen entstehen. Es sollte deshalb für ein Unternehmen immer nachvoll-ziehbar bleiben, in welchen Rechenzentren ihre Daten und Anwendungen geografischaufzufinden sind. Der Cloud-Anbieter könnte hierzu beispielsweise eine API bereitstel-len.

Verbrauchsmessung und Überwachung Für alle Cloud-Services ist dringed zu empfehlen, dasssie während ihrer Ausführung überwacht und bezüglich ihrer Ressourcenverwendunggemessen werden. Dadurch kann zum einen die Dienstnutzung abgerechnet werden.Zum anderen können Vertragsverletzungen und Sicherheitsprobleme oder Störungen imBetriebsablauf festgestellt werden. Die Messgrößen sollten im Vorfeld im Rahmen einesSLA vereinbart werden.

Service-Level-Agreements (SLAs) Unternehmen benötigen die Möglichkeit, SLAs kontinuier-lich zu überwachen (siehe vorherigen Punkt). In einem SLA muss eindeutig festgehal-ten werden, was der Cloud-Anbieter liefern wird und wie dies gemessen wird. Dabeiist es wichtig, dass eine ausreichendes Abstraktionsniveau für die Messgrößen gewähltwird. Wünschenswert aus Nutzersicht sind tendenziell eher fachliche Größen („Transak-tion“, „Vorgang“, „Datensatz“) und nicht so sehr technische („Gigabyte“, „CPU-Stunde“,„Stromverbrauch“), da sich so das Verhalten und die Kosten der Nutzung des Dienstesaus der betriebswirtschaftlichen Sicht ableiten lassen.

Sicherheit Wie bereits erwähnt, stellt die Sicherheit von Cloud-Services eine große Herausfor-derung dar. Anforderungen bezüglich der Sicherheit müssen die fünf Cloud-Charakteristikaberücksichtigen. Die Sicherheitsaspekte werden im weiteren Verlauf, insbesondere inAbschnitt 5, detailliert betrachtet.



Interoperabilität und Portabilität Es sollte möglich sein, Anwendungen, Daten und virtuelleMaschinen zwischen den verschiedenen Systemen der Cloud-Anbieter zu portieren. Da-zu bedarf es einer Menge an standardisierten Schnittstellen für den Zugriff auf die Ser-vices, wie beispielsweise Speicherdienste oder Middleware- bzw. Plattformdienste. ImKontext von PaaS und IaaS sind auch Hilfsmittel relevant, die eine vom Anbieter unab-hängige Bereitstellung der Applikation oder Infrastruktur ermöglichen (indem sie z. B.die verschiedenen APIs kompensieren). Dadurch werden Lock-in-Effekte vermieden undCloud-Services verschiedener Anbieter verknüpfbar. Allerdings ist zu bemerken, dassheutige Systeme – insbesondere im Bereich DaaS – noch bei weitem nicht ausreichendstandardisiert sind [14]. Im Gegenteil scheint der Fokus derzeit noch auf Diversifikationzu liegen.

Verteilung Eng mit der Interoperabilität und Portabilität verknüpft ist die Verteilung der An-wendungen und Daten. Unter Umständen müssen komplexe Systeme mit zahlreichenbeteiligten Cloud-Diensten koordiniert werden. Diese Koordination kann durch Werk-zeuge des Anbieters oder auch externe Dienste unterstützt werden (vgl. Abschnitt 3.1.4).Anforderungen bei der Verteilung können auch extern durch die juristischen Rahmen-bedingungen vorgegeben sein.

Lebenszyklusverwaltung Unternehmen müssen auch bei der Nutzung von Cloud-Diensten dieMöglichkeit haben, den Lebenszyklus ihrer Anwendungen, Daten oder Identitäten ver-walten zu können. Dazu werden entsprechende Prozesse und Sicherheitsmechanismengefordert, die dies unterstützen und nachvollziehbar umsetzen. Im Rahmen von DaaSspielen z. B. Aufbewahrungspflichten oder kontrollierte Löschverfahren für Daten eineRolle.

Governance Anbieter von öffentlichen Clouds setzen die Einstiegsbarrieren absichtlich mög-lichst niedrig an, so dass es sehr einfach ist, sich ein Benutzerkonto zu eröffnen und dieDienste zu nutzen. Diese Einfachheit birgt jedoch Risiken, da Mitarbeiter des Unterneh-mens am geregelten IT-Prozess vorbei Cloud-Dienste beziehen können. So können siesehr leicht z. B. sensible Daten „in die Cloud“ transferieren. Es ist daher wichtig, durchGovernance verbindliche Regeln und Vorgehensweisen zu etablieren. Die Governance-Anforderungen sollten in einem Sicherheitskonzept berücksichtigt werden.

Industriespezifische Standards und Protokolle Werden Cloud-Dienste zur Bereitstellung vonbranchenspezifischer Funktionalität benutzt, so sind bestehende Industriestandards undProtokolle zu berücksichtigen. Diese branchenspezifischen Anforderungen sind sehr viel-fältig und werden i. d. R. am besten vom Unternehmen selbst verstanden, so dass sie indiesem Leitfaden nicht weiter vertieft werden.

3.2.2 Szenario 2: KMU↔ Cloud↔ Endkunde

Eine Variante des ersten Szenarios ist die Verwendung von Cloud-Diensten durch ein Unterneh-men mit dem Ziel, diese Dienste nicht nur für die unternehmensinternen Prozesse einzusetzen,sondern sie auch externen Akteuren wie beispielsweise Geschäftspartnern oder Endbenutzern



Öffentliche Cloud

Unternehmen

Abbildung 3.3: Schematische Darstellung des Szenarios KMU↔ Cloud↔ Endkunde.

zur Verfügung zu stellen (vgl. Abbildung 3.3). Ein typischer Fall für dieses Szenario ist die Aus-lagerung der Web- und Datenbankserver in die Cloud, so dass die Website des Unternehmensvon der Elastizität der Cloud-Infrastruktur profitieren kann. Doch auch andere Konstellationensind denkbar, wenn z. B. große Filme durch den Kunden direkt von Amazon S3 heruntergeladenwerden sollen oder eine SaaS für die Durchführung einer Umfrage verwendet wird.Durch die Beteiligung einer zusätzlichen, nicht vertrauenswürdigen Partei verkompliziert

sich das Szenario leicht. Im Wesentlichen müssen die Mechanismen, die den Zugriff auf dieDienste und Ressourcen regeln etwas ausgefeilter sein, um eine feinere Abstimmung der Rechtezu erlauben. Auch kann der Zugriff auf die Dienste nicht einfach z. B. auf ein IP-Subnetz be-grenzt werden, so dass eine etwas größere Angriffsfläche entsteht. Im Endeffekt treffen aber alleÜberlegungen aus dem ersten Szenario unverändert zu und es kommen keine grundlegendenProblemstellungen hinzu. Lediglich ist zu beachten, dass ein Ausfall, ein Konfigurationsfehleroder eine falsche Bedienung des Cloud-Systems jetzt nicht nur interne Konsequenzen hat, son-dern auch durch den Kunden wahrgenommen wird. Insofern ist dieses Szenario riskanter fürden guten Ruf des Unternehmens, wenn noch keine ausreichende Cloud-Erfahrung vorhandenist.

3.3 Entwicklung einer Cloud-Strategie und derenUmsetzung

Nachdem nun die verschiedenen Chancen und Risiken des Cloud-Computing geklärt wurden,stellt sich die Frage nach der Entscheidung für oder gegen die Cloud. Der erste und wichtigsteSchritt dabei ist die Entwicklung einer Cloud-Strategie für das Unternehmen auf Management-ebene. Die Strategie definiert, welche Geschäftsbereiche oder -prozesse „in die Cloud verlagert“bzw. durch Cloud-Dienste unterstützt werden sollen. Ebenso wird definiert, für welche Berei-che oder Prozesse Cloud-Computing nicht einzusetzen ist. Das Management muss zudem imVorfeld entscheiden, welche Risiken abzusichern sind und welche auf keinen Fall eingegangenwerden dürfen. Erst nachdem auf Managementebene eine klare Strategie entwickelt wurde,


3.4 Zusammenfassung

kann mit den weiteren Schritten in Richtung Cloud-Computing fortgefahren werden. Natur-gemäß spielen bereits hierbei Sicherheitsaspekte eine entscheidende Rolle. Diese werden inKapitel 5 aufgegriffen und erläutert.Die Cloud-Strategie dient als Basis für das weitere Vorgehen. Für die Umsetzung der Strate-

gie empfiehlt sich ein klar definiertes Vorgehen bestehend aus den fünf Phasen, die in Abbil-dung 3.4 auf Seite 40 dargestellt und erläutert werden.Zudem muss für das weitere Vorgehen sichergestellt sein, dass einerseits die notwendigen

Verantwortlichkeiten klar zugewiesen werden, dass andererseits aber auch alle betroffenenParteien wie Management, Rechtsabteilung, Betriebsrat, Datenschutzbeauftragte, Sicherheits-beauftragte und Fachabteilungen von Anfang an einbezogen werden. Es sollte explizit ein Si-cherheitsbeauftragter für die Cloud-Systeme benannt werden, der sowohl während des Aufbausals auch später während des Betriebs zuständig bleibt (vgl. [33]).

3.4 ZusammenfassungIn diesem Kapitel wurden die wichtigsten Neuerungen, die Cloud-Computing mit sich bringt,sowie die resultierenden Vor- und Nachteile einer Cloud-Lösung dargestellt. Tatsächlich ist esgerade bei kleineren Unternehmen aber häufig so, dass nicht die rationalen Abwägung derpositiven und negativen Aspekte den Ausschlag gibt, sondern die Grundhaltung eines Ent-scheidungsträgers [16]. Kommt ein Unternehmen jedoch nach Abwägung der grundsätzlichenVor- und Nachteil und nach Berücksichtigung aller Ausschlusskriterien zu dem Schluss, dassCloud-Computing geeignet ist, so bietet das folgende Kapitel 4 Hilfestellung bei der Auswahldes Cloud-Anbieters. Vorher sollen aber die wichtigsten Aspekte der Grundsatzentscheidung inForm von zehn Leitfragen formuliert werden, die als erste Hilfestellung bei der Entscheidungfür oder wider die Cloud genutzt werden können.



..Planung.

Auswahl desCloud-Anbieters

.

Vertragsgestaltung

.

Migration

.

Betrieb

.� Festlegung der auszulagernden Funktionalitäten imEinklang mit der Cloud-Strategie

� Ermittlung der entsprechendenSicherheitsanforderungen (siehe Abschnitt 5.1.1)

.

� Aufstellung eines Kriterienkatalogs zurAnbieterauswahl (siehe Abschnitt 4.4.1)

� Analyse der verschiedenen Angebote und Anbieter� Dokumentation der Ergebnisse� Festlegung auf einen Anbieter

.

� Aushandlung der Verträge auf Basis der Aspekte ausdiesem Kapitel und Kapitel 4

� Dabei Berücksichtigung der Sicherheitsanforderungenz. B. in Form von SLAs

� Insbesondere Vereinbarung zur Vertraulichkeit desAnbieters und Ausstiegsszenarien

� Herstellen von persönlichem Kontakt zwischenMitarbeitern des Anwenderunternehmens und desCloud-Anbieters

� Falls sich Anbieter doch noch als ungeeignetherausstellt, Rückkehr zum vorherigen Schritt

.

� Definition der konkreten Sicherheitskonzepte für dieMigration in Zusammenarbeit mit dem Anbieter

� Umsetzung der Auslagerung in die Cloud� Ständige Prüfung auf Übereinstimmung mit dentechnischen und fachlichen Anforderungen

.

� Ständige Aktualisierung der Sicherheitskonzepte� Regelmäßige Prüfung der aktuellen Marktsituation aufbessere Angebote

� Kontinuierliche Prüfung der SLAs

Abbildung 3.4: Vorgehen bei der Umsetzung der Cloud-Strategie.


Zehn Leitfragen zur Grundsatzentscheidung..

10Fragen

1. Gibt es grundsätzliche Vorbehalte, das System auszulagern, bzw. wäre ein klassischesOutsourcing des Systems denkbar?

2. Was genau soll ausgelagert werden und durch welche Art von Cloud-Ressourcen soll dieAuslagerung realisiert werden?

3. Handelt es sich bei der auszulagernden Funktionalität um eine, die das Kerngeschäft desUnternehmens direkt betrifft, oder um eine unterstützende, „nicht-vitale“?

4. Welche speziellen rechtlichen (und ggf. internen) Rahmenbedingungen müssen beimAuslagern des Systems eingehalten werden?

5. Benötigt die Anwendung eher einen intensiven Datenaustausch zwischen Cloud und Un-ternehmen oder funktioniert sie eher isoliert? In anderen Worten: Befinden sich Datenund Logik am selben Ort?

6. Wie ist die Last des Systems zu charakterisieren? Gibt es nennenswerte regelmäßigeoder unvorhersehbare Schwankungen? Wie ist das Verhältnis von Lastspitzen zur durch-schnittlichen Last?

7. Profitiert die Anwendung von „Elastizität“, d. h., ist sie (bevorzugt horizontal) skalier-bar?

8. Soll ein bestehendes System ausgelagert und durch einen Cloud-Dienst ersetzt werdenoder soll neue Funktionalität durch die Cloud bereitgestellt werden? Müsste im letz-teren Fall für die Einführung im eigenen Unternehmen neue Hardware oder Softwareangeschafft werden?

9. Hat das System eine beschränkte Lebensdauer, z. B. durch ein klar definiertes Projekten-de?

10. Gibt es bereits Präzendenzfälle am Markt, in denen Unternehmen in vergleichbarer Si-tuation ähnliche Lösungen realisiert haben?

4 Auswahl eines DaaS-Anbieters

..


� Bei der Auswahl des Anbieter müssen alle vierDimensionen des Cloud-Computing betrachtetwerden.

� Wirtschaftlich spielen die Reputation desAnbieters, sein Preismodell und die zuerwartenden Lock-in-Effekte die wichtigste Rolle.

� Technisch muss vor allem auf dieDatensicherung, die Leistungsfähigkeit der Cloudund die Integration in bestehende Anwendungengeachtet werden.

� Rechtlich ist zu klären, ob der Anbieter allerelevanten Regularien erfüllt. Ebenfalls zu klärensind Ausstiegsszenarien und z. B.Preisänderungen während der Vertragslaufzeit.

� Organisatorisch ist ein strukturiertes Vorgehenzur Anbieterauswahl inklusive Dokumentationgefordert. Wichtige Aspekte dieser Dimensionsind die Support-Leistungen und dieKommunikation mit dem Anbieter.

Inzwischen gibt es eine Vielzahl von Anbie-tern, die sich als Cloud-Anbieter positionie-ren möchten. Ebenso vielfältig wie die An-bieter sind leider auch die Angebote, da dieAnbieter im sich entwickelnden Markt nochkeine optimale Preis- und Produktstrate-gie gefunden haben und folglich an vielenStellen noch experimentieren. Obwohl vie-le Services im Wesentlichen also dieselbeFunktionalität erbringen, gibt es de factokeine zwei, die sich gleichen. Die Anbie-ter locken die IT-Manager daher auch mitsehr kurzen Vertragslaufzeiten, so dass einrecht gefahrloses Ausprobieren der Diens-te möglich ist. Allerdings sollten die IT-Verantwortlichen trotzdem ein disziplinier-tes Vorgehen in Bezug auf die Evaluationund Auswahl des Cloud-Anbieters an denTag legen, damit nicht plötzlich böse Über-raschungen drohen.Die Anbieter werben mit wohlklingenden

Zahlen zu Stabilität und Verfügbarkeit ih-rer Dienste oder locken mit der gebotenen„Elastizität“. Obschon diese Aspekte für die Auswahl des Cloud-Dienstes wichtig sind, solltedie Entscheidung für oder gegen einen Anbieter immer durch eine ganzheitliche Betrachtungbegründet werden und besonders berücksichtigen, wie gut sich das Cloud-Angebot in die beste-hende IT-Architektur einfügt. Weitere Punkte, die meist nicht ausdrücklich beworben werden,aber äußerst relevant für die Entscheidung sein sollten, sind die Support-Leistungen des An-bieters, das garantierte Serviceniveau, Sicherheitsaspekte sowie Datenschutz- und Compliance-Anforderungen.Auch nachdem der Markt für Cloud-Services sich nun schon seit einiger Zeit entwickelt, gilt

immer noch: Jeder Cloud-Dienst ist ein wenig anders. Jeder Dienst hat eine eigene Architekturfür die Systeme, das Netzwerk, die Speicherhierarchie sowie andere Preismodelle, Support-Angebote und Sicherheitsmerkmale. Außerdem unterscheidet sich die Palette der Selbstbedie-nungsfunktionen sowie die Erfüllung von spezifischen juristischen Anforderungen. Gleichzeitigversuchen zahlreiche Unternehmen ihre Produkte unter dem Titel „Cloud Computing“ zu ver-



kaufen, obwohl es sich dabei um herkömmliche Produkte wie Hosting oder Managed Serviceshandelt. Ein genauer Blick auf den vermeintlichen Cloud-Dienst und den Anbieter ist daherunvermeidlich.Insgesamt lässt sich bereits jetzt festhalten, dass der Cloud-Computing-Markt – insbeson-

dere der DaaS-Sektor – sich immer noch schnell wandelt. Unternehmen sollten daher einenAnbieter anhand der Übereinstimmung mit den aktuellen Bedürfnisse wählen, in regelmäßi-gen Abständen die Marktsituation erneut prüfen und wechselbereit bleiben. Es darf niemandenüberraschen, wenn sich zwei Jahre nach der ersten Entscheidung für einen Anbieter heraus-stellt, dass dieser inzwischen nicht mehr die beste Übereinstimmung mit den Bedürfnissen desUnternehmens bietet. Im Verlauf dieses Kapitels wird daher genauer analysiert und bewertet,welche Aspekte bei der Wahl des Cloud-Anbieters relevant sein sollten. Die Struktur orientiertsich dabei an den vier Dimensionen, die im Kapitel 3 eingeführt wurden. Zum Ende des Ka-pitels werden die Inhalte in einigen grundsätzlichen Empfehlungen zusammengefasst und eswird wieder ein Bündel von Fragen bereitgestellt, die bei der Anbieterwahl hilfreich sind.

4.1 Wirtschaftliche Dimension

Der in der Praxis vorrangige Aspekt bei der Auswahl des Cloud-Anbieters ist vermutlich diewirtschaftliche Dimension. Im Folgenden wird beschrieben, inwiefern die Reputation des An-bieters sowie das angebotene Preismodell zu bewerten sind. Außerdem werden zwei Arten vonLock-in-Effekten dargestellt, die es nach Möglichkeit zu vermeiden gilt.

4.1.1 Reputation des Anbieters

Ein erster wichtiger Schritt bei der Auswahl des Cloud-Anbieters sollte eine Einschätzung derGröße und Bekanntheit des Anbieters sein. Die Branchengrößen wie Amazon, Google und Mi-crosoft werden vermutlich auch auf längere Sicht Ihrer Cloud-Strategie treu bleiben. Bei klei-neren Anbietern, Neulingen im Markt oder Firmen ohne klare Cloud-Strategie (z. B. Hewlett-Packard) kann man sich nicht so sicher sein [35]. Wenn es sich um ein großes bzw. wichtigesProjekt handelt, sollte folglich eher einem etablierten Hersteller der Vorzug gegeben werden.Diese Bewertung ist eher subjektiv, aber nichtsdestotrotz hilfreich. Sie sollte ergänzt werden

um den subjektiven Eindruck, wie transparent der Anbieter in seiner Informationspolitik ist:� Werden detaillierte Informationen zu allen Fragen rund um die Servicenutzung bereit-

gestellt?� Wird das Preismodell ausführlich erläutert? Wird auch auf nicht offensichtliche Kosten

hingewiesen?� Werden Informationen zu den Sicherheitsvorkehrungen und zum Stand der Technik in

den Rechenzentren des Anbieters angeboten?

Auf Basis dieser subjektiven Eindrücke sollte ein erstes Bild von der Zuverlässigkeit der Anbieterentstehen.



Darüber hinaus sollte der Kunde aber versuchen, historische Kennzahlen zur Zuverlässig-keit des Dienstes für jeden Anbieter zu erlangen, am besten natürlich in den Dimensionen,die auch für die spätere Definition des SLA relevant sein könnten. Einige Anbieter geben sol-che Zahlen auf Anfrage heraus. Für andere gibt es teilweise Berichte in Blogs oder Online-Magazinen. Außerdem bietet es sich an, eine Recherche in einschlägigen Diskussionsforen undOnline-Communitys durchzuführen. Dabei können sowohl einschlägige Web-Seiten1, aber auchDienste wie Twitter und Facebook hilfreich sein, in denen die Nutzer unmoderiert, aber auchungenierter ihre Meinung äußern.Zusätzliches Vertrauen in die Verlässlichkeit des Anbieters kann auch dadurch erlangt wer-

den, dass geklärt wird, wie der Anbieter seine Mitarbeiter und Dienstleister aussucht. Dabeisollte beachtet werden, wie beispielsweise Mitarbeiter vor der Einstellung überprüft werden.Das ist insbesondere für das Personal interessant, das nachher mit sicherheitsrelevanten Syste-men oder Daten in Berührung kommt. Dasselbe gilt für die gesamte „Supply Chain“ des Anbie-ters, also alle Subunternehmer oder beauftragten Dienstleister. Beispielsweise könnten Backupsbei anderen Cloud-Anbietern gespeichert werden, die andere Standards an den Tag legen. Hierist also wichtig zu erfahren, wie gewissenhaft der eigene Cloud-Anbieter seine Dienstleister vorder Auftragsvergabe aussucht.Auf jeden Fall sollte eine Bewertung stattfinden, wie viel Schaden in dem Fall entsteht, dass

die Nutzung eines Cloud-Dienstes aus unvorhergesehenen Gründen plötzlich beendet werdenmuss. Diese Bewertung gibt einen Hinweis darauf, wie genau der Cloud-Provider ausgesuchtwerden muss.

4.1.2 Preismodell

Wie schon eingangs erwähnt, sollte bei der Analyse des Preismodells genau auf versteckte Kos-ten geachtet werden. Die meisten Cloud-Anbieter erheben nämlich nicht nur Nutzungsentgeltefür den Kern-Service, sondern auch für den Datentransfer in das und aus dem Rechenzentrum.Meistens erfolgt die Berechnung dabei anhand des transferierten Datenvolumen (z. B. pro GiB),wobei eingehender Datenverkehr oft günstiger ist als ausgehender.2 Außerdem kann es auchsein, dass Support-Anfragen kostenpflichtig sind. Schließlich lassen sich viele Anbieter zusätzli-che Dienstleistungen ebenfalls bezahlen. Es lohnt sich also, im Vorfeld genau zu recherchierenbzw. im Zweifelsfall genauere Informationen vom Anbieter anzufordern.Ein wichtiger Aspekt des Preismodells ist die nutzungsabhängige Abrechnung (Pay-per-Use).

Je nach Art der geplanten Verwendung der Cloud-Dienste lohnt sich der Schritt zum Cloud-Computing vielleicht erst, wenn (hauptsächlich) anhand der Nutzung abgerechnet wird. Dasist besonders dann interessant, wenn die Dienste zwischendurch überhaupt nicht verwendetwerden und entsprechend keine Kosten anfallen sollten. Bei DaaS ist dies eher nicht der Fall, dazumindest der Speicherplatz für die Daten bezahlt werden muss. Es könnte jedoch vorkommen,dass die Daten nur zu ganz bestimmten Terminen benötigt werden und es daher günstiger ist,1Z. B.: http://cloutage.org/ oder http://www.cloud-hosting-providers.com/2Derzeit berechnet Amazon beispielsweise eingehenden Datenverkehr für die Elastic Compute Cloud(EC2) überhaupt nicht, während ausgehender mit bis zu etwa 0,15 € pro GB zu Buche schlägt (StandOktober 2010).


http://www.twitter.com/

http://www.facebook.com/

http://cloutage.org/

http://www.cloud-hosting-providers.com/


die Datenbank für die Ruheperioden komplett zu löschen. Dies muss jedoch immer im Einzel-fall entschieden werden. Hohe Grundgebühren widersprechen eigentlich dem Cloud-Gedanken,können aber bei intensiver Nutzung eventuell zu günstigeren Tarifen beim Anbieter verhelfen.Zu bedenken ist hierbei auch, dass im Rahmen der in Kapitel 3 beschriebenen Cost-Associativity,die Möglichkeit besteht, Zeit gegen höhere Ressourcennutzung abzuwägen. Im Rahmen einerrein nutzungsabhängigen Abrechnung ergeben sich daraus oft attraktive Zeitersparnisse.Eng verwandt mit der nutzungsabhängigen Abrechnung ist auch die Frage, wie die Nutzung

gemessen wird. Hier haben die Kunden bei großen Anbietern wie Amazon im Rahmen kleinererProjekte vermutlich keine Wahlmöglichkeit. Bei kleineren Anbietern oder bei Aushandlungeines individuellen SLA sollte jedoch darauf geachtet werden, möglichst betriebswirtschaftlichmotivierte Messgrößen zu verwenden. Das erleichtert die Prognose der Gebühren erheblich,da meistens die Zahl der erwarteten Transaktionen besser zu schätzen ist, als deren Dauer undgenaue Beschaffenheit.Obwohl viele Anbieter auf ihren Webseiten nur die Bezahlung per Kreditkarte oder PayPal

angeben, bieten sie auf Anfrage meistens auch andere Modalitäten an, wie z. B. Zahlung gegenRechnung [18]. Es lohnt sich also auch hier immer, genauer nachzufragen, falls die gewünschteZahlungsart laut Webseiten nicht vorgesehen ist.Zur Verwaltung der Cloud-Dienste stellen die Anbieter i. d. R. ein Webportal bereit, über

das die Kunden den Dienst in Eigenregie verwalten können. Die bereitgestellte Funktionalitätkann jedoch stark variieren. Als Minimum sollte das Portal eine Überwachung der Ressour-cennutzung (Monitoring) inklusive einer Historie, eine Übersicht über die entstandenen Kostenund eine Schnittstelle zum Kundendienst („Trouble Tickets“ oder „Service Requests“) anbie-ten. Gerade in Bezug auf die Darstellung und Analyse der entstandenen Kosten gibt es großeUnterschiede bei den Anbietern [18]. Einige Daten erscheinen vielleicht nur mit großer Zeit-verzögerung oder werden anders aufgeschlüsselt, so dass ein Vergleich mit der vorliegendenRechnung schwierig wird. Wenn die entstandenen Gebühren intern auf verschiedene Verursa-cher umgelegt werden sollen, so bietet es sich an, darauf zu achten, dass die Cloud-Ressourcenmit Metadaten (z. B. Tags) versehen werden können. Außerdem sind in solchen Fällen maschi-nenlesbare Rechnungen sowie Aufschlüsselungen der Servicenutzung inklusive Metadaten vonVorteil, um diese automatisiert zuordnen zu können.Soll mehr als nur ein einzelner Dienst bezogen werden, kann es günstige Kombinationen ge-

ben. Amazon berechnet z. B. keinen Datenverkehr innerhalb der eigenen Cloud, so dass Trans-fers zwischen S3 und EC2 kostenlos sind. Auch lohnt es sich bei größeren Projekten, die mög-licherweise eine breite Masse an Kunden ansprechen, auf zusätzliche Leistungen des Cloud-Anbieters wie spezielle SSL-Endpunkte für SSL-Offloading, Applikationsbeschleuniger oder einContent Delivery Network (CDN) zu achten.Abschließend sei bemerkt, dass es sich bei allen Anbieter lohnt, nach Rabatten zu fragen.

Häufig kann man durch Vorauszahlung oder Vereinbarung einer Mindestnutzung bereits güns-tigere Preise erzielen. Besonders dann, wenn es sich um ein größeres Projekt handelt, sollte aufjeden Fall ein individuelles Angebot angefragt werden.

4.1.3 Lock-in-Effekte über die Daten



..

Erfahrung aus der Praxis:Während der Vorbereitung dieses Leitfadensberichtete uns ein KMU davon, dass einSaaS-Anbieter die Daten, die im Rahmen derServicenutzung angefallen waren, nachBeendigung des Vertragsverhältnisses nichtherausgeben wollte. Das Argument lautete,dass die internen Datenstrukturen einGeschäftsgeheimnis darstellten. Das KMUmusste in diesem Fall genaue Angabenmachen, welche Attribute und Datensätze vomAnbieter exportiert werden sollten – einlangwieriger Prozess. Im Endeffekt war es fürdas KMU quasi unmöglich zu entscheiden, oballe relevanten Daten extrahiert worden warenoder nicht.

Der wohl wichtigste Aspekt für ein Unternehmen inBezug die Auslagerung seiner Daten ist die Frage, obdas Unternehmen alleiniger und vollwertiger Eigen-tümer der Daten ist und bleibt. Das muss sowohl inBezug auf die in das System explizit eingetragenenDaten gelten, als auch in Bezug auf die automatischerstellten Daten und Metadaten. Insbesondere letzte-rer Aspekt wird leicht übersehen. Dies ist auch kei-neswegs selbstverständlich, da SaaS-Anbieter nichtimmer vollständigen Zugriff auf alle Daten erlauben,die im Rahmen der Nutzung der Software im Systemangefallen sind. Auch ist es manchmal schwierig, dieDaten in einem verwendbaren Format zu erhalten(vgl. Kasten „Erfahrung aus der Praxis“).Als Kunde sollte also eine klare Absprache mit dem

Anbieter getroffen werden, dass dieser entweder re-gelmäßig oder auf Anfrage eine vollständige Kopieder Daten in für den Kunden verwendbarer Form zurVerfügung stellt. Eine „verwendbare Form“ kann dabei je nach Anwendungsfall eine Kopie derDatenbank in Form eines SQL-Dump oder einer Access-Datenbank sein. Eventuell ist auch einExcel-Dokument oder ein CSV-Export in eine Textdatei angemessen. Als letzte Möglichkeit wä-re auch ein PDF-Dokument denkbar. Im besten Fall bietet die Weboberfläche die Möglichkeit,einen solchen Export ohne Interaktion mit dem Anbieter durchzuführen.Wie einfach die Daten auch aus dem jeweiligen Dienst exportiert werden können, so muss

doch immer ein gewisser Lock-in-Effekt einkalkuliert werden. Auch im Fall eines vollständigenSQL-Dump müssen die Daten vor der Verwendung in anderen Systemen im Normalfall nochrecht aufwändig konvertiert und aufbereitet werden. Die von Cloud-Anbietern suggeriertenextrem kurzfristigen Ein- und Ausstiegsmöglichkeiten sind daher mit entsprechender Vorsichtzu genießen.

4.1.4 Lock-in-Effekte über die Prozesse

Neben dem Lock-in-Effekt über die Daten, kann es auch leicht zu einem solchen Effekt über dieGeschäftsprozesse kommen. Wie bereits in Abschnitt 2.2 angesprochen erfordert die Integra-tion eines Cloud-Dienstes immer auch eine gewisse Anpassung der eigenen Geschäftsprozesse.Je nachdem, wie weit diese Anpassungen gehen, kann auch durch sie eine Lock-in-Situationentstehen.Die nötigen Anpassungen der Prozesse lassen sich zum großen Teil über die funktionalen

Anforderungen an die Software abschätzen. Bietet der Cloud-Dienst bereits in seiner Basisaus-führung alle benötigten Funktionen, so ist der Anpassungsaufwand tendenziell niedrig. UnterUmständen können fehlende oder unpassende Funktionen durch Anpassung der Anwendung(Customizing) nachgerüstet werden. Gerade in Bezug auf die Funktionen, die nicht in die Kern-kompetenz der Software fallen, ist dies aber häufig nicht möglich. Hier muss Abhilfe dann



entweder durch Anpassung der internen Abläufe oder durch zusätzliche Bereitstellung lokalerHilfsprogramme geschaffen werden. Es ist für die Anpassung sehr hilfreich, wenn der Cloud-Dienst vielfältige Schnittstellen zur Verfügung stellt (vgl. Abschnitt 4.2.3).Die Kompatibilität des Cloud-Anbieters zu bestehenden Geschäftsprozessen darf nicht un-

terschätzt werden. Im Zweifelsfall ist eine Anpassung der Software oder gar die Änderung derinternen Prozesse deutlich aufwändiger und teurer als die Wahl eines teureren Cloud-Anbieters,der sich aber besser in die bestehenden Abläufe einfügt.

4.2 Technische Dimension

Abgesehen von den wirtschaftlichen Aspekten, spielen auch die technischen Fragestellungeneine wichtige Rolle bei der Auswahl des Anbieters. Insbesondere die Fragen nach der Sicherungder Daten, der Zuverlässigkeit und der Leistungsfähigkeit der Cloud sind hierbei relevant. Esdarf jedoch nicht vergessen werden, ebenfalls zu prüfen, ob sich die Dienste eines konkretenAnbieters gut in die bestehende Systemlandschaft einfügen. Dieser Aspekt wird daher ebenfallsthematisiert. Fragen zur technischen Sicherheit der Angebote werden detailliert in Kapitel 5behandelt und daher hier weitgehend ausgeblendet.

4.2.1 Sicherung und Wiederherstellung von Daten

Eine essentielle Voraussetzung für den Schritt in die Cloud ist häufig, dass die Daten beimCloud-Anbieter mindestens genauso gut vor Datenverlust geschützt werden, wie im eigenen Re-chenzentrum. Alle großen Cloud-Anbieter implementieren eine vorbildliche Backupstrategie,aber es lohnt sich immer, genauer nachzufragen. Es gibt zahlreiche Aspekte, die im Rahmendieser Fragen zu klären sind. Als erstes ist zu klären, wie oft und zu welchen Zeitpunkten voll-ständige und inkrementelle Sicherungskopien der Daten durchgeführt werden. Außerdem istinteressant, ob die Daten auf Festplatten oder Bändern gesichert werden und wo die Daten auf-bewahrt werden. Der Aufbewahrungsort ist zum einen interessant, um zu beurteilen, wie sicherdie Daten aufbewahrt werden und wie schnell sie wieder hergestellt werden können. Zum ande-ren können dadurch aber auch rechtliche oder sicherheitstechnische Probleme auftreten. Nutztdas Unternehmen bereits einen Dienstleister, der die Archivierung der Backups übernimmt, sosollte der Cloud-Anbieter die Backups auch zu diesem Dienstleister schicken können. In jedemFall muss die gesamte Prozess der Datensicherung mit den Compliance-Anforderungen und denbranchenspezifischen rechtlichen Rahmenbedingungen abgeglichen werden.Je nach Anwendung kann auch dieWiederherstellungsprozedur sehr wichtig werden. Es kann

z. B. erforderlich werden, die Daten auf einen bestimmten Stand „zurückzusetzen“. Das erfor-dert regelmäßige Snapshots durch den Anbieter. Für kritische Daten kann auch die Möglichkeiteiner Forward-Recovery wichtig sein. Zudem ist die Frage, wie und unter welchen Umständender Kunde die Daten wiederherstellen kann. Kann eine Wiederherstellung beispielsweise auchim Fall logischer3 Fehler durchgeführt werden? Sollen die Daten wiederhergestellt werden, so3Das Auftreten logischer Fehler bedeutet, dass die Datenbasis fachlich falsche Daten enthält. Beispiels-weise könnte ein Programmierfehler dazu führen, dass widersprüchliche Informationen zu Konten-



sollte außerdem klar definiert werden, wie lange dies dauern darf. Handelt es sich um eineSaaS-Anwendung, so kann es gut sein, dass der Anbieter keine nach Mandanten getrenntenBackups aufbewahrt, weil die internen Datenstrukturen dies nicht leicht erlauben. Das hat zurKonsequenz, dass eine Wiederherstellung lange dauert und vielleicht nur sehr eingeschränktmöglich ist. Im optimalen Fall kann der Anwender die Wiederherstellung über eine Webober-fläche völlig automatisiert anstoßen.

4.2.2 Leistungsfähigkeit der Cloud

Auch wenn die Versprechen des Cloud-Anbieters gut klingen und der angebotene Service ins-gesamt gut zu passen scheint, sollte immer noch eine Reihe von Tests durchgeführt werden.Schon mit einfachen Mitteln, z. B. einem Verbindungstest („Ping“-Test) lässt sich die durch-schnittliche Latenz der Verbindung zu verschiedenen Tageszeiten testen. Bereits durch Testsder Provider-Infrastruktur im kleinen Maßstab lassen sich belastbare Aussagen treffen. Soll eingrößeres Projekt in der Cloud gestartet werden, so sollte auch die Skala der Tests größer aus-fallen, damit mögliche Ressourcenengpässe auf Anbieterseite frühzeitig erkannt werden.

Verfügbarkeit

Der Verfügbarkeit des Cloud-Dienstes kommt dabei eine besondere Rolle zu. Kann ein Unter-nehmen etwas längere Laufzeit bei Anfragen oft noch tolerieren, so ist die Nichterreichbarkeiteines Dienstes – insbesondere einer Database-as-a-Service – oft hoch problematisch. Typischer-weise wird heutzutage eine Verfügbarkeit von 99,95% garantiert [18], vergleichbar mit denSLAs, die traditionelle Hosting-Anbieter für hochverfügbare dedizierte Server bieten. Für diemeisten Einsatzzwecke werden diese Garantien anfangs ausreichen. Sollte jedoch eine höhereVerfügbarkeit benötigt werden, so muss dies mit dem Cloud-Anbieter genau abgesprochen wer-den. Aktuelle Angebote sind von der Infrastruktur nicht dafür ausgelegt, mehr als 99,95%igeVerfügbarkeit zu bieten. Bei diesen Überlegungen ist immer zu beachten, dass die Verfügbarkeitüblicherweise ohne Berücksichtigung der angekündigten Systemabschaltungen und Wartungs-fenster berechnet wird. Je nachdem, wie viel Zeit der Anbieter hierfür einplant, kann sich dietatsächliche Verfügbarkeit deutlich nach unten verschieben.Sinnvollerweise sollte auch die Netzanbindung des Anbieters durch das SLA zugesichert wer-

den. Teilweise kann es auch sinnvoll sein, die Leistung des internen Netzwerks im Rechen-zentrum des Cloud-Anbieters vertraglich zu vereinbaren. Hierbei legt man oft Grenzwerte fürVerfügbarkeit, Latenzzeit, Paketverlust und Jitter fest. Gleichermaßen ist es oft notwendig, dieInternetanbindung des eigenen Unternehmens durch ein entsprechendes SLA mit dem eigenenInternet Service Provider (ISP) abzusichern.

bewegungen und dem Saldo gespeichert werden. Rein technisch ist die Datenbank nach wie vor inOrdnung; sie weist keine physischen Fehler auf, die z. B. durch einen defekten Sektor auf der Fest-platte verursacht werden. Im Gegensatz zu physischen Fehlern kann nur der Kunde (und nicht derAnbieter) die logischen Fehler erkennen.



Leistungsfähigkeit der Cloud-Infrastruktur

Neben der Verfügbarkeit spielt natürlich auch die Leistungsfähigkeit der Infrastruktur des Cloud-Anbieters eine entscheidende Rolle. Der Dienst soll schließlich nicht nur erreichbar sein, son-dern auch reibungslos funktionieren, damit z. B. von der Elastizität der Cloud profitiert werdenkann. Um sicherzustellen, dass die Infrastruktur des Anbieters den Anforderungen gewachsenist, kann das Anwenderunternehmen im Fall eines DaaS-Dienstes z. B. Testdaten hin und herzu kopieren sowie Dummy-Abfragen auszuführen. Beim Kopieren sollte sowohl die Geschwin-digkeit zwischen eigenem Intranet und der Cloud als auch die Geschwindigkeit innerhalb derCloud gemessen werden, falls mehrere Dienste beim Cloud-Anbieter bezogen werden. Bei derDurchführung von Dummy-Abfragen sollte besonderes Augenmerk auf die Funktionen zur au-tomatischen Skalierung des Ressourcenangebots gelegt werden, denn das ist normalerweise einHauptargument für die Nutzung einer DaaS.Die Reaktionszeit auf den geänderten Ressourcenbedarf ist je nach Anbieter unterschiedlich.

Normalerweise sollte die Bereitstellung neuer bzw. Freigabe nicht mehr benötigter Ressourcenweitgehend automatisch erfolgen. Je nach Service-Typ muss entweder der Benutzer den geän-derten Bedarf über eine Weboberfläche (oder eine API) mitteilen oder – wie für eine DaaS üb-lich sein sollte – die Erkennung und Anpassung erfolgt vollautomatisch. Einige Cloud-Anbietersprechen auch Garantien für diese Reaktionszeit im SLA aus [18].

Verbindung zur Cloud

Obwohl Cloud-Anbieter ihre Dienste per Internet anbieten, gibt es bei einigen auch die Mög-lichkeit, eine dedizierte, private Verbindung zur Cloud aufzubauen. Eine Möglichkeit bestehtdarin, ein Virtual Private Network (VPN) über das Internet zum Anbieter aufzubauen, so dasssämtlicher Verkehr zum Dienst automatisch gesichert wird. Bei anderen Anbietern ist es sogarmöglich, eine dedizierte Netzwerkverbindung zu erhalten, so dass ein Multiprotocol Label Swit-ching (MPLS) VPN aufgebaut werden kann (was allerdings mittel- bis langfristige Verträge mitdem Telekommunikationsanbieter nach sich zieht). Gerade im Bereich der größeren Firmen-kunden könnte diese Option interessant sein, zumal einige Anbieter sie nicht extra berechnen.[18]

Vorgehen für die Performance-Analyse

Die beschriebenen Tests können und sollten zum einen durch die eigenen IT-Abteilung durch-geführt werden – so werden auch die eigenen Systeme als Faktor einbezogen. Eine Studie derHarvard-Universität [10] zeigt auf, wie man prinzipiell vorgehen kann. Zusätzlich sollten aberauch die in Abschnitt 3.1.4 auf Seite 34 beschriebenen Werkzeuge und Informationsportaleverwendet werden.Bei der Evaluation sollten nicht nur die aktuellen Garantien betrachtet werden, sondern auch

die Vergangenheit: Hat der Anbieter es in den letzten Monaten und Jahren geschafft, seineVersprechen einzuhalten? Hierzu kann es hilfreich sein, in Diskussionsforen zu recherchieren,um Kundenstimmen zu hören, die von Problemen oder guten Erfahrungen mit dem Anbieterberichten. Interessant ist in diesem Zusammenhang auch, ob die SLAs mit angemessenen Strafen



versehen sind und ob der Anbieter die Strafen auch bezahlt. Welche Strafe angemessen ist,muss allerdings immer im Einzelfall entschieden werden. Für hochverfügbare Cloud-DBS ist ein10%iger Rabatt auf die Nutzungsgebühr unangemessen, da der drohende Schaden durch einenAusfall des Systems oft viel schwerer wiegt. Für zeitlich unkritische Berechnungen hingegenkann diese Regelung völlig in Ordnung sein.Bei der gesamten Analyse ist zu bedenken, dass viele Cloud-Anbieter rapide wachsen. Das

kann sich negativ auf die Stabilität und Verfügbarkeit der Infrastruktur auswirken. Die Qua-lität der Architektur und des Personals wirken sich ebenso direkt darauf aus, ebenso wie klardefinierte Change- und Release-Management-Prozesse. In der Realität können daher die ver-sprochenen und erbrachten Werte für Verfügbarkeit und Stabilität auseinander klaffen. Einegründliche Analyse ist unabdingbar. [18]Bei aller Analyse der harten Fakten sollte jedoch nie vergessen werden, dass der Dienst auch

von den Nutzern im Unternehmen akzeptiert werden muss. Daher sollte als weitere nicht-funktionale Anforderung auch die Benutzungsfreundlichkeit in Betracht gezogen werden.

4.2.3 Integration in bestehende Systeme

Sollen Cloud-Dienste und bestehende Systeme eng zusammenarbeiten, so zeigt sich schnell, dasseine Integration von Cloud-Diensten und Nicht-Cloud-Systemen oft sehr problematisch ist. DieErfahrung zeigt, dass Cloud-Dienste untereinander oft einigermaßen einfach zu koppeln sind,vor allem, wenn sie von demselben Hersteller angeboten werden. Sollen Cloud-Dienste jedochin bestehende, vielleicht sogar „(wild) gewachsene“ Systeme integriert werden, so treten ver-stärkt Integrationsprobleme auf und in deren Folge die Lock-in-Effekte, die in den Abschnitten4.1.3 und 4.1.4 bereits betrachtet wurden.Eine technische Gegenmaßnahme stellen offene Schnittstellen dar. Daher sollte bei der Wahl

des Cloud-Dienstes darauf geachtet werden, dass ausreichend mächtige APIs zur Verfügungstehen. Dies ist insbesondere für DaaS-Angebote essentiell, weil eine ihrer Hauptaufgaben imLesen und Schreiben von Daten besteht. Durch geeignete Schnittstellen können die Daten fle-xibel und in passenden Formaten im- oder exportiert werden, so dass eine Integration keineallzu große Anpassung bestehender Systeme erfordert. Im Rahmen des Open Cloud Manifes-to4 organisieren sich zahlreiche kleinere Cloud-Anbieter und -Nutzer, die gemeinsame, offeneSchnittstellen für Cloud-Dienste befürworten bzw. entwickeln wollen. Die Branchengrößen wieAmazon und Google fehlen allerdings – ebenso wie praxisrelevante Ergebnisse.Abgesehen vom reinen Datenaustausch und der Konvertierung zwischen verschiedenen Da-

tenformaten oder -strukturen können aber auch durch das nunmehr entfernte DBS Problemeentstehen. Während die Verbindung zum DBS im eigenen Rechenzentrum nur marginale La-tenzzeiten und hohe Transferraten bietet, bedingt ein Cloud-DBS prinzipiell eine höhere Latenzund niedrigere Bandbreite. Gleichzeitig steigt durch die Vielzahl von beteiligten Parteien dasRisiko, dass die Verbindung zwischen Unternehmen und Cloud nicht mehr hergestellt wer-den kann. Diese Faktoren müssen bei der Integration des neuen Dienstes berücksichtigt wer-den. Sollten bestehende Anwendungen Annahmen zur Verfügbarkeit, Antwortzeit oder Über-tragungsgeschwindigkeit treffen, so müssen diese eventuell aufwändig umgearbeitet werden.4http://www.opencloudmanifesto.org/


http://www.opencloudmanifesto.org/


Als Alternative bieten einige Cloud-Provider die Möglichkeit, eigene dedizierte Hardware indas Cloud-Rechenzentrum zu stellen. Der Anbieter kümmert sich dann um die Verwaltung undWartung der Server und bietet eine Verbindungsqualität zwischen den dedizierten Systemenund den Cloud-Diensten, die der eines lokalen Intranet in nichts nachsteht. Diese „Hybridisie-rung“ der Firmen-IT wird in Zukunft zunehmen (vgl. [18]).

4.3 Rechtliche DimensionEine ganz entscheidende Fragestellung bei der Entscheidung für oder gegen einen Cloud-Anbieterkönnen die rechtlichen Aspekte sein. Im Rahmen der Grundsatzentscheidung aus Kapitel 3 solltebereits eine grundsätzlich juristische Prüfung stattgefunden haben, ob die zur Debatte stehendeAnwendung generell ausgelagert werden darf. Ist diese Frage geklärt, so ist die Auswahl desgeeigneten Cloud-Anbieters glücklicherweise deutlich einfacher.

4.3.1 Erfüllung der gesetzlichen Anforderungen

Als Ergebnis der grundsätzlichen Analyse existiert im Unternehmen bereits eine Liste aller rele-vanten gesetzlichen Vorschriften für die spezielle Branche und das konkrete Szenario. Im güns-tigsten Fall hat der Anbieter die Konformität mit den entsprechenden Normen bereits geprüftund kann diese auf Anfrage bestätigen. Zumindest die Zusage über die Konformität mit demBundesdatenschutzgesetz (BDSG) sollte für alle DaaS-Anbieter eine Selbstverständlichkeit sein.Im ungünstigen Fall ist die Prüfung jedoch noch nicht passiert und entweder der Anbieter oderdas Anwenderunternehmen müsste sie noch durchführen. Sollte der Anbieter nicht aus eigenenStücken zu der Konformitätsprüfung bereit sein, so sollte das Anwenderunternehmen von demCloud-Dienst Abstand nehmen. Die rechtlichen Probleme in diesem juristischen Neuland sindnur schwer absehbar.Als Anhaltspunkt für die Konformität mit den relevanten Normen können Zertifizierungen

nach ISO/IEC 27001 oder SAS 70 sein. Das Bundesamt für Sicherheit in der Informationstech-nik (BSI) bietet außerdem weitere Zertifizierungen an. Diese Standards sind jedoch alle nurbehelfsmäßig auf die Situation im Cloud-Computing angewendet worden. Insbesondere beider SAS 70-Zertifizierung muss daher genau der Volltext der Zertifzierungsurkunde studiertwerden, da der Standard keine Vorgaben über den Umfang der Zertifizierung macht. Einenwirklichen „Cloud-Sicherheitsstandard“ gibt es noch nicht.Im Rahmen der Frage, ob ein Angebot konform zum BDSG ist, bietet der Ort der Daten-

verarbeitung einen guten Anhaltspunkt. Kann der Cloud-Anbieter schriftlich bestätigen, dassdie Daten nur innerhalb der EU verarbeitet und gespeichert werden, so ist bereits eine wich-tige Vorgabe des Datenschutzrechts erfüllt. Diesem Aspekt tragen heute bereits viele Cloud-Anbieter Rechnung. Amazon bietet z. B. geografische Einschränkungsmöglichkeiten für die Ser-vices an, um die Datenverarbeitung auf „Europe“ zu begrenzen. Von allen Anbietern, die keineBeschränkung der Datenverarbeitung auf die EU anbieten, sollte zurzeit noch abgesehen wer-den. Selbst Zertifikate wie der „US Safe Harbor“, der eigentlich US-Unternehmen als konformzur EU-Datenschutzrichtlinie ausweisen soll, sind nicht praxistauglich. Eine Studie zur Praxis-tauglichkeit des Safe-Harbor-Siegels zeigt auf, dass Ende des Jahres 2008 nur 54 von den 1597


4.3 Rechtliche Dimension

Tabelle 4.1: Einschätzung der Relevanz von Zertifikaten und Qualitätssiegeln imCloud-Computing

Zertifikat/Siegel Aussagekraft Bemerkung

ISO/IEC 27001 mittel bis hoch Empfehlung des BSISAS 70 niedrig bis mittel Umfang der Prüfung entscheidendUS Safe Harbor ohne Aussagekraft Keine Prüfung, vgl. [5]PrivacyMark niedrig Beschränkung auf Japan

Unternehmen, die zu dem Zeitpunkt als „US Safe Harbor“ gelistet waren, die grundlegendenAnforderungen des Safe-Harbor-Siegels umsetzten [5]. Daher sind die juristischen Konsequen-zen einer Zusammenarbeit mit solchen Anbietern nicht absehbar. Tabelle 4.1 gibt einen kurzenÜberblick über die bekanntesten Zertifikate und ihre Aussagekraft in Bezug auf die zertifizier-ten Cloud-Anbieter. Eine grafische Übersicht über die verschiedenen Stufen der Gesetzgebungzum Datenschutz findet sich unter http://www.forrester.com/cloudprivacyheatmap.Über den sorgfältigen Umgang mit den personenbezogenen Daten hinaus fordert das BDSG

allerdings auch geregelte Löschverfahren für personenbezogene Daten. Zu beachten ist hierbei,dass höchstwahrscheinlich auch archivierte und replizierte Datensätze betroffen sind. In die-ser Hinsicht stellen sich einige wichtige, teilweise bis dato unbeantwortete Fragen (vgl. [19,S. 150 f.]):

� Wie löscht der Cloud-Anbieter die personenbezogenen Daten tatsächlich? Wie werdenreplizierte und archivierte Daten gelöscht? Kann ein Datum überhaupt je gänzlich ge-löscht werden, sobald es in die Cloud gespielt wurde?

� Hat der Anbieter die Daten tatsächlich physikalisch gelöscht („zerstört“) oder nur perSoftware als gelöscht markiert („in den Papierkorb verschoben“)? Reicht eine Löschungim Dateisystem oder müssen die Daten auch gänzlich aus den physikalischen Speicher-medien getilgt werden? Ist ein weit verzweigtes Netz aus replizierten Daten eine „beson-dere Art der Speicherung“ im Sinne des §35Abs. 3Nr. 3 des BDSG, was zur Folge hätte,dass die Daten nur gesperrt, nicht aber gelöscht werden müssen?

� Der Anbieter darf die Daten nicht zu früh löschen, aber andererseits auch nicht über denZeitpunkt der geforderten Löschung hinaus aufbewahren. Wie kann also der richtigeZeitpunkt der Löschung sichergestellt und nachgewiesen werden?

Nach aktuellemWissensstand bietet derzeit keiner der großen Cloud-Provider eine vollständigeLöschung von personenbezogenen Daten an.5

4.3.2 Ausstiegsszenarien

Im Rahmen der Verträge mit dem Cloud-Anbieter sollten auch die Szenarien klar definiert wer-den, in denen das Anwenderunternehmen bzw. der Anbieter das Vertragsverhältnis beenden5Stand: September 2010.


http://www.forrester.com/cloudprivacyheatmap


kann. Das übliche Szenario ist dabei, dass der Cloud-Nutzer die Anwendung nicht mehr län-ger nutzen möchte. Für diesen Fall sollte der Zugriff auf den gesamten Datenbestand ebensosichergestellt werden wie die Kooperation des bisherigen Anbieters bei der Migration.Um eine gewisse Sicherheit gegenüber der plötzlichen Einstellung des Dienstes oder der

unverhofften Kündigung zu haben, kann das Anwenderunternehmen gewisse Vorsichtsmaß-nahmen treffen. Im optimalen Fall sichert der Anbieter dem Cloud-Nutzer die Möglichkeit zu,zur Not auf ein lokales System (unter eigener Kontrolle) umzuschalten. Dazu wird die Cloud-Anwendung lokal beim Anwender installiert. Im Notfall darf das Unternehmen auf die lokaleVersion umschalten. Zu klären sind die genauen Konditionen und die Dauer für eine solcheUmschaltung.Da größere Anbieter sich i. d. R. nicht auf so einen Handel einlassen und die Kosten für die

Bereithaltung eines solches Backup-Systems meistens die Vorteile der Cloud-Nutzung aufwie-gen, besteht außerdem die Möglichkeit, den Programm-Code des Systems bei einem Notar oderTreuhänder zu hinterlegen (engl. Escrow). Im Fall, dass der Anbieter seinen vertraglichen Ver-pflichtungen zur Weiterentwicklung und Wartung der Software nicht mehr nachkommen kann,hat das Anwenderunternehmen zumindest die theoretische Möglichkeit, dies selbst durchzufüh-ren.Schließlich sollte auch der Fall berücksichtigt werden, dass der Anbieter den Betrieb des

Systems nicht mehr gewährleisten kann.

4.3.3 Weitere Aspekte

Ein weiterer Aspekt, der bei der Wahl des Anbieters bzw. der Vertragsgestaltung berücksichtigtwerden sollte sind mögliche nachträgliche Änderungen am Produkt, insbesondere Preisände-rungen. Im Vertragswerk sollte festgelegt werden, welche Möglichkeiten zur Preisänderung sichder Cloud-Anbieter vorbehält. Oft werden die Preise nicht festgeschrieben, sondern können vomAnbieter recht frei angepasst werden. Ein Sonderkündigungsrecht bei Änderung der Preise istoft nur Makulatur, weil der Aufwand des Anbieterwechsels im Hinblick auf die oben beschrie-benen Lock-in-Effekte zu hoch ist. Im Vorfeld muss daher geklärt werden, welche Preisände-rungen möglich sind. Ist es nicht möglich oder zu unattraktiv fixe Gebühren zu vereinbaren,so sollte zumindest eine Berechnung erfolgen, in welchem Preiskorridor der Dienst attraktivbleibt. Mithilfe der geschätzten Wahrscheinlichkeit für die entsprechende Preissteigerung kanndann eine Entscheidung erfolgen, ob das Angebot trotzdem attraktiv ist.Im Hinblick auf alle individuellen Verträge mit dem Cloud-Anbieter muss bemerkt werden,

dass jede Abweichung vom Standardprodukt und den Standardverträge für den Anbieter zugesteigerter Komplexität und damit in der Regel auch zu höheren Preisen führt. Besonders imHinblick auf die mehrfach erwähnten individuellen SLAs ist abzuwägen, ob die oft deutlichhöheren Kosten dem zusätzlichen Nutzen angemessen sind. Zwar sind solche individuellen An-passungen aus Sicht des Cloud-Anwenders oft notwendig, aber aus Anbietersicht nicht immereinfach realisierbar. Ob Cloud-Computing wirklich zu einer Kostenreduktion führt, hängt des-halb maßgeblich davon ab, mit welchen Risiken man seine Geschäftsprozesse aussetzen kannund will.


4.4 Organisatorische Dimension

4.3.4 Handlungsempfehlungen zur rechtlichen Dimension

Abschließend bleibt festzuhalten: Selbstverständlich ist jeder Vertrag juristisch gründlich zu prüfen.Besonderes Augenmerk muss dabei der Compliance, Datensicherheit, den Ausstiegsszenarienund Möglichkeiten zur Preisänderung gelten [16]. Aus der aktuellen juristischen Situation sindaußerdem drei empfehlenswerte Vorgehensweisen für den Schritt „in die Cloud“ abzuleiten:

1. Im besten Fall garantiert der Anbieter die Konformität zu den bestehenden gesetzlichenRegelungen, so dass das juristische Risiko größtenteils auf diesen abgewälzt werdenkann.

2. Weit verbreitete Vorgehensweisen und Dienste wie z. B. das CRM-Outsourcing zu Sa-lesforce können de facto als unbedenklich angesehen werden, da eine breite Masse anPräzedenzfällen existiert.

3. Im Zweifelsfall, besonders beim Betreten von „Neuland“ in der Cloud, sollte lieber Ab-stand davon genommen werden, sensible oder personenbezogene Daten an einen Cloud-Anbieter zu übergeben.


Auch aus organisatorischer Sicht ist das Cloud-Computing ähnlich zu behandeln wie klassi-sches IT-Outsourcing. Die wichtige Frage im Hintergrund ist, wie viel Kontrolle das Anwen-derunternehmen über den Cloud-Anbieter ausüben kann. Dazu gehört auch die Frage, wie dietatsächliche Umsetzung der versprochenen Maßnahmen und Leistungen vor Ort überprüft wer-den können. Konkret äußern sich diese Aspekte unter anderem in der Zusammenarbeit mit demAnbieter sowohl im Falle üblicher Probleme bei der Servicenutzung sowie im „Notfall“, wennetwas wirklich schief läuft. Zuvor soll jedoch kurz erläutert werden, wie ein systematischesVorgehen zur Anbieterwahl aussehen könnte.

4.4.1 Vorgehen zur und Dokumentation der Anbieterwahl

Wie in Kapitel 3.1.4 angedeutet, ist es sinnvoll, die Auswahl des Cloud-Anbieters strukturiertanzugehen. Dafür bietet es sich an, einen Kriterien- bzw. Anforderungskatalog aufzustellen,der die Anforderungen des eigenen Unternehmens an einen hypothetischen, optimalen Cloud-Anbieter aufzeigt. Als zweiter Schritt kann dann ein Vergleich der tatsächlich verfügbaren An-gebote mit den Anforderungen durchgeführt werden. Das Ergebnis wird häufig ein kleiner Kreisder „am wenigsten schlecht passenden“ Cloud-Anbieter sein, aus welcher der geeignetste aus-gewählt werden kann. Welche Kriterien in dem Katalog auftauchen, ist sehr stark abhängig vomjeweiligen Anwendungsfall und kann hier nicht allgemein beantwortet werden. Viele Anregun-gen werden sich jedoch aus diesem Leitfaden sowie aus dem Katalog vonMindestanforderungenfür Cloud-Anbieter des BSI [4] ergeben.Ein bedeutsamer Teilaspekt der Anbieterwahl ist die nachvollziehbare Dokumentation der-

selben. Im Bereich der Cloud-Angebote muss auf mittlere Sicht damit gerechnet werden, dass



sich der Markt recht dynamisch ändern wird. Daher ist eine regelmäßige Prüfung nötig, ob deraktuelle Anbieter noch immer der am besten geeignetste ist. Eventuell gibt es inzwischen besserpassende Angebote oder identische Produkte zu günstigeren Preisen. Anhand der früheren Kri-terien und Anforderungen kann die neue Marktlage relativ schnell und strukturiert analysiertwerden. Zudem erschließen sich eventuell Entwicklungen im Zeitverlauf, die für oder gegeneinen Provider sprechen, wenn dieser seine Produktpalette beispielsweise deutliche langsamerweiterentwickelt als der Rest des Marktes.

4.4.2 Support-Leistungen des Anbieters

Ein sehr wichtiger Aspekt bei der Zusammenarbeit mit dem Cloud-Anbieter ist die Frage, wiedieMitarbeiter des Anwenderunternehmensmit der Kundenbetreuung in Kontakt treten könnenund welche Reaktionszeiten zugesagt werden. Dabei können drei Aspekte der Kundenbetreuungunterschieden werden [18]:

� Reaktion auf Kundenanfragen Die Kundenbetreuung wird kontaktiert, weil ein Pro-blem aufgetreten ist. Hierbei ist es wichtig, dass der Anbieter zu offener Kommunikationund zügiger Problemlösung bereit ist. Dies ist der klassische Fall für Kundenbetreuung.

� Anbieter-initiierter Support Der Anbieter weist bereits im Vorfeld auf drohende Proble-me (z. B. Ressourcenengpässe, nötige Wartungsarbeiten) hin bzw. alarmiert den Nutzersobald ein Fehler auftritt. Der Provider bietet dabei entweder eine Lösung oder zumin-dest Hilfestellung bei der selbständigen Lösung an. Im Rahmen von Verträgen, in de-nen der Anbieter viele bis alle Aspekte der Infrastruktur verwaltet (also jegliche Cloud-Computing-Verträge), sollte dieser Aspekt berücksichtigt werden.

� Projekt-Unterstützung Der Cloud-Anbieter unterstützt den Kunden bei komplexen Pro-jekten wie z. B. beim Versionswechsel, bei Migrationen oder bei dem Produktivschaltenneuer Systeme. Diese Art von Support muss in aller Regel zusätzlich eingekauft werden.

In Bezug auf die Kontaktaufnahme mit dem Cloud-Anbieter ist zu klären, welche Kanäle dafürvorgesehen sind. Während viele Anbieter nur die Kommunikation per Web-Formular erlauben,erhalten die Nutzer bei anderen spezielle E-Mail-Adressen für ihre Anfragen. Eventuell bietetder Provider auch eine telefonische Unterstützung. In jedem Fall ist es wichtig zu wissen, ob essich um einen Rund-um-die-Uhr-Support („24/7“) handelt, oder ob nur bestimmte Geschäfts-zeiten vorgesehen sind. Im Rahmen des durch den Anbieter initiierten Supports ist es wichtig,die Ansprechpartner zu klären, um sicherzustellen, dass Meldungen zu anstehenden Wartungs-arbeiten oder Systemabschaltungen auch bei den richtigen Mitarbeitern in der Unternehmungankommen. Eventuell werden entsprechende Nachrichten aber auch nur über einen Newsfeed(z. B. mit Really Simple Syndication, RSS) veröffentlicht, der regelmäßig gelesen werden muss.Die Kundenbetreuung hat bei jedem Anbieter eine etwas andere Zielgruppe, die bei der Ent-

scheidung für oder gegen einen Anbieter mit berücksichtigt werden sollte. Typische Zielgruppenfür den Support sind z. B.:

� Anwendungsentwickler, die sich nicht mit dem laufenden Betrieb der Systeme auskennen



� Systemintegratoren oder Drittanbieter, die im Auftrag eines Kunden dessen Systeme indie Cloud bringen, aber selbst nur wenig Wissen über den Betrieb dieser Systeme mit-bringen

� Systemadministratoren, die sich noch nicht tiefgehender mit der Cloud auseinander ge-setzt haben und daher grundlegende Fragen haben, die aber auch detaillierte technischeProbleme klären möchten

� Systemadministratoren, die bereits viel Erfahrung mit Cloud-Computing gesammelt ha-ben und Unterstützung bei komplexen Cloud-Projekten benötigen

� Nutzer aus Fachabteilungen, die Cloud-Dienste (besonders SaaS) nutzen, um sich nichtum die technischen Details kümmern zu müssen, und daher wenig technisches Wissenmitbringen

..

Beispiel aus der Praxis:Ein sehr positives Beispiel in Bezug auf denSupport durch einen SaaS-Anbieter haben wirwährend der Vorbereitungen dieses Leitfadenserfahren. Ein KMU wollte seine internenKreativprozesse durch eine SaaS-Lösungunterstützen. Während der Nutzung im Haustraten einige Defizite des Dienstes zu Tage.Nach einer klärenden E-Mail-Kommunikationmit dem Anbieter fand dieser dievorgeschlagenen Erweiterungen sehr sinnvoll.Bereits wenige Tage später konnte dasUnternehmen die „Beta-Version“ der neuenFunktionen nutzen – wie natürlich auch alleanderen Nutzer des Dienstes.

Je nachdem wie die Zielgruppe im Anwender-unternehmen eingeschätzt wird, sollte ein passen-der Provider ausgewählt werden. Neben „Verstän-digungsproblemen“ stellt die richtige Wahl auch si-cher, dass die bestehenden Support-Prozesse bessermit den Prozessen des Cloud-Anbieters in Einklanggebracht werden können. Dabei spielt natürlich auchdas Support-Personal auf Provider-Seite eine Rol-le. Hier ist wichtig, dass es sich um ausreichendgeschulte und fähige Mitarbeiter handelt. Wendetsich beispielsweise immer die technisch versierte IT-Abteilung an den Support, welche das Problem viel-leicht sogar schon identifiziert hat, so sollte sicherge-stellt sein, dass die Mitarbeiter nicht lange in Warte-schleifen bei technisch nicht ausreichend geschultenKundenbetreuern aufgehalten werden.Einige Cloud-Anbieter geben auch für die Kunden-

betreuung Dienstgütegarantien im SLA ab. Sie garan-tieren dann die mittlere Antwortzeit (Mean-Time-to-respond) oder die durchschnittliche Repa-raturdauer (Mean-Time-to-repair) im Problemfall. Außerdem können verschiedene Dringlich-keitsstufen vorgesehen sein (z. B. „Systemausfall“ ggü. „Feature Request“). Schließlich könnenauch die Schritte zur Eskalation formalisiert werden [18].Grundsätzlich gilt jedoch häufig: je größer die Unternehmung, destomühsamer ist die Support-

Anfrage, falls man die normale Hotline benutzt. Um im Bedarfsfall größeren Ärger zu vermei-den, sollte die Kundenbetreuung daher bereits im Vorfeld geprüft und als Kriterium in dieAnbieterauswahl einbezogen werden.



4.4.3 Kommunikation mit dem Anbieter im Problemfall

Ein sehr wichtiger und leider oft viel zu spät beachteter Aspekt ist die Kommunikation mit demCloud-Anbieter im Problemfall. Als erstes ist zu beachten, dass eine Situation nicht notwen-digerweise für beide Parteien einen „Problemfall“ darstellt. Es muss also im Fehlerfall zuerstidentifiziert werden, in wessen Verantwortungsbereich das Problem fällt. Bereits dabei hilft esjedoch ungemein, wenn die Kommunikationskanäle zum Cloud-Anbieter wie oben beschriebenim Vorfeld festgelegt wurden und die Kooperation der Support-Mannschaft gesichert ist. Selbstwenn das Problem durch das Anwenderunternehmen verschuldet wurde, kann der Anbieterdurch die bessere Kenntnis der zugrunde liegenden Systeme und den physischen Zugriff auf dieHardware oft effektivere Lösungen realisieren. Besonders für den Notfall empfiehlt es sich, inregelmäßigen Abständen die Aktualität der Daten zu prüfen, um z. B. nicht erst in einer drin-genden Situation zu erfahren, dass der entsprechende Ansprechpartner inzwischen in einemanderen Unternehmen arbeitet.Neben der reinen Kommunikation sollten auch die Aktionen für den Notfall abgestimmt wer-

den. Existieren im eigenen Unternehmen bereits Maßnahmen zum betrieblichen Kontinuitäts-management (engl. Business Continuity), so können diese mit den entsprechenden Maßnahmenauf Anbieterseite koordiniert werden. Ansonsten ist es empfehlenswert, zusammen mit dem An-bieter einen Ablaufplan für den Notfall auszuarbeiten. Ein seriöser Cloud-Anbieter sollte bereitseinen passenden, generischen Plan als Grundlage anbieten können.

4.5 Zusammenfassung

Cloud-Computing wird auch in den nächsten Jahren noch keine „Stangenware“ werden. DieAnbieter führen kontinuierlich neue Funktionalitäten ein und experimentieren mit neuen Tech-nologien und Geschäftsmodellen. Derzeit entwickelt sich der Markt noch zügig und die Anbieterintegrieren neu entstehende Technologien schnell in ihre Dienste. Gleichzeitig werden existie-rende Schwachstellen ausgebessert.In der aktuellen Situation sollten Unternehmen daher denjenigen Anbieter wählen, der mo-

mentan am besten auf die Problemstellung und die Situation in der eigenen Unternehmungpasst. Allerdings muss besonders im Bereich des Cloud-Computing eine regelmäßige Prüfungdurchgeführt werden, ob diese Übereinstimmung immer noch gegeben ist und ob es nicht in-zwischen deutlich bessere Alternativen gibt. Dazu ist es nötig, sich möglichst wenig an denProvider anzupassen (siehe Abschnitte 4.1.3 und 4.1.4 zu den Lock-in-Effekten). Die Migra-tionskosten beim Anbieterwechsel sollten nicht unterschätzt werden. Um einen zuverlässigenAnbieter auszuwählen bietet sich eine ausführliche Internet-Recherche in Foren, Blogs undWeb-2.0-Diensten wie Twitter an, die deutlich besser Auskunft geben können als traditionelleAuswahlverfahren.Abschließend bleibt zu bemerken, dass bei der Anbieterwahl mindestens drei ähnliche Anbie-

ter anhand eines strukturierten Anforderungskatalogs untersucht und getestet werden sollten,bevor intern eine Entscheidung getroffen wird. Zu beachten ist auch, dass nicht immer allewichtigen Informationen auf den Webseiten der Anbieter dargestellt sind. Für größere Projektesollte daher immer telefonisch oder schriftlich nach weiteren Informationen gefragt werden.


4.5 Zusammenfassung

Im Hinblick auf den Vergleich der Kosten sollte – wie schon bei der Grundsatzentscheidung füreine Cloud-Lösung – immer eine ganzheitliche Sicht verwendet werden, z. B. nach dem Ansatzder Total Cost of Ownership (TCO). Nur so werden auch die unterschiedlichen Mitarbeiteran-forderungen, Einarbeitungszeiten, Gebühren und Maßnahmen zur Risikominimierung erfasst.Cloud-Angebote dürfen nicht nur – wie von den Anbietern häufig propagiert – mit den reinenHardwarekosten verglichen werden.Als Hilfestellung bei der Auswahl des Cloud-Anbieters sind auf der folgenden Seite die wich-

tigsten Aspekte der Wahl des Anbieters in Form von zehn Leitfragen aufgelistet. Natürlich han-delt es sich auch bei dieser Liste nur um ein Instrument für eine erste Auswahl, die durch eineintensivere Analyse der Anbieter verfeinert werden muss.


Zehn Leitfragen zur Wahl des Anbieters..

10Fragen

1. Wie etabliert, groß und zuverlässig ist der Cloud-Anbieter nach eigener Meinung undnach Meinung seiner (un-)zufriedenen Kunden? Kann der Cloud-Anbieter dies durchrelevante Zertifizierungen z. B. nach SAS 70 oder ISO/IEC 27001 belegen?

2. Wie viel Kontrolle kann das Unternehmen über den Cloud-Anbieter ausüben? Wie kön-nen die tatsächliche Umsetzung der versprochenen Maßnahmen und Leistungen vor Ortüberprüft werden?

3. Ist und bleibt das Anwenderunternehmen alleiniger Eigentümer seiner Daten? Stellt ihmder Cloud-Anbieter (auf Anfrage oder regelmäßig) eine vollständige Kopie Ihrer Daten infür Sie verwendbarer Form zur Verfügung?

4. Wo und in welchen Rechenzentren werden die Daten durch den Anbieter verarbeitet?Bieten alle Rechenzentren dasselbe Serviceniveau?

5. In welchem Ausmaß muss das Anwenderunternehmen seine Prozesse und Systeme an-passen, um sinnvoll mit dem Anbieter zusammenarbeiten zu können?

6. Erfüllt der Cloud-Service alle notwendigen gesetzlichen Vorschriften für die spezielleBranche? Wird insbesondere das BDSG vollständig umgesetzt?

7. Wie umfangreich, flexibel und praxistauglich sind die Möglichkeiten, individuelle SLAszu vereinbaren?

8. Wie umfangreich ist die durch den Anbieter implementierte Backupstrategie und wieflexibel können Daten wiederhergestellt werden?

9. Sind die Support-Leistungen des Anbieters für die Bedürfnisse des Cloud-Nutzers an-gemessen, z. B. in Bezug auf Art der Kommunikation, Erreichbarkeit, Ausbildung desSupport-Personals?

10. Wie überprüft der Anbieter seine Mitarbeiter bzw. Dienstleister vor der Einstellung bzw.Auftragsvergabe?

5 Sicherheitaspekte vonDaaS-Angeboten

..


� Sicherheit in der Cloud ist ein zentrales Thema.Einige einfache Maßnahmen verhelfen bereits zueiner soliden Grundlage.

� Im Vorfeld müssen die eigenen Anforderungenan die Sicherheit genau geklärt werden.

� Es überwiegen die organisatorischen Probleme.Unter anderem müssen die Mitarbeitersensibilisiert und geschult werden sowiebestehende und neue Sicherheitskonzepteintegriert werden.

� Auf technischer Seite müssen sowohl dieInfrastruktur als auch die Daten geschütztwerden. Ansätze für ersteres sind bekannt. DerAspekt der Datensicherheit ist zwar teilweiseauch bekannt, stellt aber größere Hürden in denWeg, da viele Anbieter nur ein durchschnittliches,aber kein hohes Schutzniveau erbringen.

� Insgesamt ist die Sicherheit von Cloud-Dienstennicht notwendigerweise schlechter als vonLösungen im eigenen Haus.

Im Rahmen der aktuellen Entwicklung imBereich des Cloud-Computings gibt es nochimmer eine große Unklarheit, wie Sicher-heit auf den verschiedenen Ebenen inder IT-Landschaft erreicht werden kann.Die unklare Situation verleitet viele IT-Verantwortliche zu der Aussage, dass dieSicherheit in der Cloud für sie als das größ-te Problem erscheint (vgl. [19, S. 31]). Ei-ne aktuelle Umfrage unter KMU mit demSchwerpunkt auf dem Münsterland1 zeigtebenfalls, dass die Entscheider um dieSicherheit besorgt sind: die Vertraulich-keit der eigenen Daten gegenüber Drittenist die wichtigste Voraussetzung für dieCloud-Nutzung. Interessanterweise zeigendie Antworten ein ausgeprägtes Misstrau-en gegenüber den Cloud-Anbietern, dennan zweiter Stelle wird auch die Vertraulich-keit der Daten gegenüber dem Provider ge-fordert – noch deutlich vor einschlägigenZertifikaten, z. B. nach ISO/IEC 27001. Tat-sächlich gibt es hinsichtlich der Datenver-traulichkeit noch einige ungeklärte Aspek-te, wie dieser Abschnitt zeigen wird. Das Hauptproblem liegt aber eigentlich nicht in der Si-cherheit, sondern in den Steuerungs- und Kontrollmöglichkeiten, die der Cloud-Nutzer überden Cloud-Anbieter haben möchte. Nach dem aktuellen Stand der Technik ließen sich vieleCloud-Szenarien prinzipiell sicher realisieren. Der eigentlich problematische Punkt ist, wie dasAnwenderunternehmen bestimmte Richtlinien vorgeben und ihre Einhaltung durch den Cloud-Anbieter sicherstellen kann (vgl. [7]).

1Eine ausführliche Ausarbeitung der Studie durch die DBIS Group ist zurzeit in Vorbereitung. Bei Inter-esse wenden Sie sich bitte an die Autoren dieses Leitfadens. Die Kontaktdaten finden Sie auch unterhttp://dbis-group.uni-muenster.de/.



5 Sicherheitaspekte von DaaS-Angeboten

Dieses Kapitel soll daher zum einen für die verschiedenen zu beachtenden Aspekte sensibi-lisieren und – wo möglich – erste Schritte oder Handlungsempfehlungen nahe legen. In derKürze dieses Leitfadens ist es jedoch unmöglich, die Erstellung eines vollständigen Sicherheits-konzepts umfassend zu beschreiben. Hierzu sei auf die einschlägige Literatur verwiesen, wiez. B. [8, 19, 32], die Dokumentation im Internet, z. B. [3], oder die umfangreiche Dokumenta-tion zum IT-Grundschutz, die das Bundesamt für Sicherheit in der Informationstechnik (BSI)veröffentlicht2 [22, 23, 24, 25, 27].

5.1 Vorgehen für die Bewertung der Risiken in der Cloud

Häufig wird als Vorteil von Cloud-Computing genannt, dass „das Risiko“ einfach auf den Cloud-Anbieter abgewälzt werden könne. Dies ist jedoch ein Trugschluss. Obwohl sich gewisse Risi-ken, wie z. B. das Investitionsrisiko, teilweise sich auf den Anbieter übertragen lassen, „verpufft“Risiko nicht einfach in der Cloud (vgl. [7]). Es wird auch niemals vollständig an den Cloud-Anbieter abgegeben werden, da eine Beeinträchtigung des Anbieters in den meisten Fällen Kon-sequenzen für seinen Kundenstamm hat. Es ist daher für eine ordentliche Bewertung der Cloud-Strategie essentiell, eine ganzheitliche Übersicht zu gewinnen und eine wohlüberlegte Mengevon Verantwortung in die Cloud auszulagern, aber auch Überprüfungsmöglichkeiten und dieeigene Verantwortung zu klären. Viele Vertrauens- und Risikoaspekte des Cloud-Computingsind noch weitgehend unerforscht und können daher gefährlich werden [7]. Nur eine gründ-liche Analyse im Vorfeld kann ein vernünftige Entscheidungsgrundlage für den Schritt zumCloud-Computing liefern.Im Hinblick auf die Sicherheit von Cloud-Angeboten heißt dies, dass zuerst festgelegt werden

muss, welche Anforderungen an die Sicherheit von der wirtschaftlichen Seite her gestellt wer-den, bevor irgendeine sinnvolle Entscheidung getroffen werden kann, ob der jeweilige Cloud-Anbieter „ausreichend sicher“ ist (vgl. [18]). Erst auf Basis der individuellen Anforderungenkann ein Cloud-Anbieter evaluiert werden. Wie bereits in Abschnitt 3.3 erläutert, ist dabei dieEntwicklung einer klaren Cloud-Strategie und eine stringente Umsetzung derselben sehr wich-tig. Ein explizit benannter Sicherheitsbeauftragter sollte von Anfang an über die Umsetzungdes Sicherheitskonzepts für die Cloud-Computing-Lösung wachen. Nur so lässt sich eine wirk-lich sichere Umsetzung gewährleisten. Dieser Bericht leistet dabei insofern Unterstützung, alsdass die wichtigsten Themenbereiche diskutiert werden, die im Rahmen einer solchen Um-setzung behandelt werden müssen. Eine allgemeingültige Handlungsempfehlung kann jedochnicht ausgesprochen werden.

5.1.1 Analyse der eigenen Anforderungen

Durch die Einbindung von Cloud-Diensten werden die IT-Systeme im Unternehmen immerkomplexer. Verteilte Systeme bestehen aus einer Vielzahl von Komponenten und Teilsyste-men auf unterschiedlichen Schichten. Ein systematisches Vorgehen muss dabei Schicht fürSchicht die relevanten Sicherheitsaspekte untersuchen. Hilfestellung bei einer vollständigen2https://www.bsi.bund.de/gshb


https://www.bsi.bund.de/gshb

5.1 Vorgehen für die Bewertung der Risiken in der Cloud

Analyse gibt eine Taxonomie wie die des Fraunhofer SIT [32] und die Bausteine aus denIT-Grundschutzkatalogen [27]. Im Folgenden werden die wichtigsten Aspekte der jeweiligenSchichten kurz angerissen, um einen ersten Eindruck von den notwendigen Schritten zu erhal-ten.Zusätzlich ist auch die Vorgehensweise nach den IT-Grundschutz-Standards des BSI zu emp-

fehlen [22, 23, 24, 25]. In diesen Standards, früher als „IT-Grundschutz-Handbuch“ bekannt,veröffentlicht das BSI empfohlene Vorgehensweisen zu Erstellung eines vollständigen Sicher-heitskonzepts. Zusätzlich zur Beschreibung des Vorgehen bietet das BSI auch die sogenanntenGrundschutz-Kataloge an, in denen mögliche Gefährdungen und Gegenmaßnahmen aufgeführtsind. Die Dokumentation zum IT-Grundschutz ist zwar noch nicht explizit an die neuen Ge-gebenheiten des Cloud-Computings angepasst. Jedoch lässt sich ein auf dieser Basis erstell-tes Sicherheitskonzept für das Unternehmen auch um die Cloud-Dienste erweitern und bie-tet daher eine gute Ausgangsposition. Alle Dokumente zum IT-Grundschutz finden sich aufhttps://www.bsi.bund.de/gshb.

Schutzziele

Um die eigenen Anforderungen an die Sicherheit zu verstehen, müssen zuerst die grundlegen-den Schutzziele verstanden werden. An dieser Stelle werden sie nur sehr kurz aufgelistet. Füreine genauere Beschreibung sei auf die einschlägige Literatur, z. B. [8, 32], verwiesen. Die dreizentralen Schutzziele für jegliche Informationssysteme sind:

1. Vertraulichkeit: das System ermöglicht keine unautorisierte Informationsgewinnung[8, S. 8]

2. Integrität: die Daten im System können nicht unbemerkt und unautorisiert manipuliertwerden [8, S. 7]

3. Verfügbarkeit: berechtigte Nutzer können nicht durch unautorisierte Aktionen externerAkteure in ihrer Nutzung des Systems beeinträchtigt werden (in Anlehnung an [8, S. 10]und [32, S. 23])

Diese Schutzziele müssen auf jeden Fall berücksichtigt werden, da dies auch durch den Gesetz-geber, z. B. in §10Abs. 2 DSG NRW, gefordert wird. Auch aus praktischen Erwägungen herausmüssen diese drei Ziele adressiert werden, weil sonst ein sinnvoller Einsatz des Systems imUnternehmenskontext nicht gewährleistet werden kann.Im Rahmen von Cloud-Computing liegt es nahe, zwei weitere, abgeleitete Schutzziele zu

beachten:

4. Authentizität: die Identität des Kommunikationspartners bzw. Akteurs (sei es ein Sys-tem oder ein Subjekt) kann eindeutig bestimmt werden

5. Verbindlichkeit (engl. Non-repudiation): Aktionen im System lassen sich eindeutig Sub-jekten zuordnen und die Ausführung einer Aktion durch ein Subjekt kann auch im Nach-hinein nicht abgestritten werden


https://www.bsi.bund.de/gshb


Diese beiden Schutzziele sind besonders wichtig in Umgebungen, in denen mehrere Akteurebeteiligt sind. Dies trifft also auf fast jedes IT-System im Unternehmenseinsatz zu, insbesondereauch auf Cloud-Anwendungen.Je nach Anwendungsfall können eventuell auch noch weitere Schutzziele aufgenommen wer-

den:

6. Schutz der Privatsphäre: das System bietet durch Anonymisierung oder Pseudonymi-sierung einen Schutz vor der Zuordnung schützenswerter Daten zu einer Person

7. Transparenz: die Verarbeitung der Daten im System erfolgt gut dokumentiert und ein-fach nachvollziehbar

Speziell für das Szenario von Database-as-a-Service müssen spezielle Facetten der genann-ten Schutzziele berücksichtigt werden. Zusätzlich muss jedoch auch ein weiteres spezifischesSchutzziel miteinbezogen werden:

8. Inferenzkontrolle: das System muss sicherstellen, dass durch das Zusammenführen fürsich genommen nicht schützenswerter Einzelinformationen keine weiteren Informatio-nen abgeleitet werden können, die dem betreffenden Subjekt eigentlich nicht zugänglichsein dürften (vgl. [8, S. 9])

Dieses Problem tritt besonders in Datenbanken auf. In diesen kann sich beispielsweise durchgeschicktes Formulieren von Abfragen auf pseudonymisierten Daten die Ergebnismengen unterUmständen so stark einschränken lassen, dass eine Zuordnung zu einer Person möglich wird.Für eine ausführlichere Beschreibung siehe [6].

5.1.2 Analyse der Anbieter

Um die Schutzziele zu gewährleisten müssen einerseits im Anwenderunternehmen entsprechen-de Maßnahmen getroffen werden. Andererseits ist aber im Rahmen von Cloud-Computing be-sonders auch der Cloud-Anbieter in der Pflicht. Um eine Erfüllung der Schutzziele sicherzustel-len, muss daher der Anbieter gründlich untersucht werden. Es gibt drei prinzipielle Möglich-keiten, diese Analyse des Anbieters durchzuführen:

1. Analyse der Situation vor Ort durch einen Besuch beim Provider

2. Analyse der vorhandenen Dokumentation und Antworten auf entsprechende Anfragen

3. Vertrauen in die Untersuchung durch neutrale Dritte

Während bei der Analyse der eigenen Systeme mit der vollen Kooperation durch das jeweiligeFachpersonal zu rechnen ist, muss das bei der Analyse der Cloud-Anbieter nicht so sein. Geradebei größeren Anbietern ist es dem einzelnen Kunden nicht möglich, detaillierte Einblicke in dieSysteme des Anbieters zu erhalten. In diesem Fall entfällt die erste Möglichkeit und die Analysemuss sich auf vorhandene Dokumente, Aussagen des Anbieters und durch Dritte attestierteTatsachen stützen.


5.2 Das kleine Einmaleins

Für den dritten Fall hat der Anbieter die entsprechenden Zertifikate oder Zeugnisse hoffent-lich bereits vorliegen. Relevante Urkunden sind beispielsweise Zertifikate nach ISO/IEC 27001und SAS 70. Auf jeden Fall müssen die zertifizierten Aspekte gründlich analysiert werden, wiebereits in Abschnitt 4.3.1 beschrieben. Wenn es spezielle Compliance-Anforderungen gibt, sosollte im Vorfeld eine schriftliche Erklärung des Providers eingeholt werden, dass entsprechen-de Kontrollen (Audits) durchgeführt werden dürfen.Inhaltlich sollte die Analyse natürlich einerseits prüfen, ob die im eigenen Unternehmen iden-

tifizierten Anforderungen an den Cloud-Dienstleister erfüllt werden. Zusätzlich bietet es sichjedoch auch an, weitere Aspekte in die Untersuchung mit aufzunehmen, um ein umfassenderesBild von der Seriosität des Cloud-Anbieters zu erhalten. Insbesondere sollte überprüft werden,welche Prozesse und Technologien der Anbieter selbst etabliert hat, um mögliche Angriffsvek-toren und Schwachstellen zu identifizieren und zu adressieren. Wichtig ist auch zu erfahren,welche Prozesse beim Anbieter gewährleisten, dass alle Sicherheitsmechanismen korrekt funk-tionieren, und welche Maßnahmen für den Fehlerfall vorgesehen sind. Dazu gehört auch eineReaktion auf mögliche Angriffe auf die Cloud-Dienste oder -Infrastruktur.

5.2 Das kleine Einmaleins

Durch die Umsetzung von drei einfachen Punkten kann oft schon ein vernünftiger Anfang fürdie Cloud-Sicherheit gemacht werden (vgl. [32]):

1. Unterstützende Dienste des Cloud-Anbieters verwenden: Die meisten Anbieter offe-rieren bereits einige grundlegenden Sicherheitsfunktionenwie z. B. Firewalls sowie ande-re grundlegende Zusatzdienste aus den Bereichen Integration, Bereitstellung, Verteilungund Sicherheit. Diese Funktionen sollten auf jeden Fall genutzt werden, da die Anbieterin der Regel ein sehr gutes Verständnis für die schutzbedürftigen Schwachstellen dereigenen Services haben. In einem hybriden Ansatz kann der Dienst eventuell um eige-ne dedizierte Hardware ergänzt werden. Wenn der Cloud-Anbieter seine IT-Landschaftvernünftig verwaltet, kann mithilfe dieser Dienste ohne großen Aufwand ein recht or-dentliches Sicherheitsniveau erreicht werden. Ein guter Cloud-Anbieter steht auch imRahmen der vereinbarten Support-Leistungen bei der sicheren Einbindung seiner Ser-vices beratend zur Seite.

2. Schutz der Netzinfrastruktur: Die Cloud-Dienste werden üblicherweise über das Inter-net bezogen. Daher sollte darauf geachtet werden, dass alle Verbindungen zum Anbieterverschlüsselt sind. Oft reicht eine Verwendung von SSL bzw. TLS („HTTPS“) anstelle derunsicheren Verbindung per HTTP. Etwas ausgefeiltere Szenarien können VPNs ausnut-zen, Firewalls verschiedener Ebenen und redundante Kommunikationskanäle umfassen.Auf jeden Fall ist die Netzinfrastruktur hinsichtlich der Sicherheit und Zuverlässigkeitals besonders schutzbedürftig einzustufen.

3. Kein Verzicht auf Sicherheitskonzepte aus ökonomischen Überlegungen heraus:Wann immer Sicherheitsmechanismen diskutiert werden, sollten fachliche Argumente



Tabelle 5.1: Übersicht über die Verteilung der Verantwortlichkeit zwischen Cloud-Anbieter und -Nutzer auf den drei Service-Ebenen.

Ebene Provider Nutzer Bsp. für Maßnahmen

SaaS Sicherer Betrieb der Anwen-dung

Sichere Konfiguration derAnwendung

Sinnvolle Vergabe vonRechten, sichere Passwörter

PaaS Sicherer Betrieb der Platt-form

Sichere Konzeption, Pro-grammierung und Konfigu-ration der Anwendung

Sicheres Konzept für dieApplikationslogik, Überprü-fung von Stored Procedures

IaaS Sicherer Betrieb derHardware, des Host-Betriebssystems und derVirtualisierungsschicht

Sicherer Betrieb und Konfi-guration der virtualisiertenSoftware

Härtung der Software,Sichere Konfiguration desDBMS

zu einer Entscheidung für oder gegen bestimmte Maßnahmen führen. Es ist nicht rat-sam, auf Basis rein ökonomischer Überlegungen auf bestimmte Aspekte des Sicherheits-konzepts zu verzichten, wenn diese durch fachliche Argumente, z. B. etablierte Sicher-heitsrichtlinien im Unternehmen, motiviert werden. Auch wenn dieser Hinweis trivialklingen mag, so werden in der Praxis vielfältige Argumente zum Verstoß gegen diesenGrundsatz verführen. Die gesetzlichen Anforderungen zum Datenschutz erfordern bei-spielsweise in der Praxis fast zwingend den Einsatz von kryptographische Verfahren.Diese sind jedoch in den Standardprodukten vieler Cloud-Anbieter nicht vorgesehen, sodass der sichere Einsatz dieser Angebote erschwert und damit teurer wird (vgl. [33]).

5.3 Organisatorische AspekteBei der Sicherheit im Cloud-Computing geht es nicht so sehr um neue technische Aspekte, son-dern um organisatorische Aspekte wie die Absprache und Verteilung von Verantwortung zwi-schen Cloud-Anbieter und Cloud-Nutzer. Es müssen trennscharfe Grenzen, sogenannte TrustBoundaries, gezogen werden, die festlegen, welche Aufgaben vom Provider erbracht werdenund an welchen Stellen das Anwenderunternehmen Hand anlegen muss. Tabelle 5.1 gibt ei-ne Übersicht über die generelle Aufteilung der Verantwortlichkeiten auf den verschiedenenService-Ebenen und nennt beispielhaft einige typische Maßnahmen, die der Cloud-Nutzer selbstdurchführen muss. Abgesehen von der Klärung der Verantwortlichkeiten, die je nach Anwen-dungsfall sehr unterschiedlich ausfallen können, gibt es viele generelle organisatorische Aspek-te, von denen im Folgenden die wichtigsten kurz angerissen werden.

5.3.1 Sensibilisierung der Mitarbeiter für das Thema

Eine Vielzahl von Sicherheitsproblemen ist heute direkt oder indirekt auf die Mitarbeiter deseigenen Unternehmens zurückzuführen. Die Mehrheit der bekannt gewordenen Sicherheits-GAUs ist von eigenen Mitarbeitern oder Dienstleistern verursacht worden, welche die Schad-


5.3 Organisatorische Aspekte

software über ihre Laptops oder USB-Sticks ins Intranet des Unternehmens eingeschleust hatten.Das derartige Umgehen der Firewalls ist eine offene Hintertür, die alle Schutzmaßnahmen amHaupteingang unsinnig erscheinen lässt. Die Ursache solcher Sicherheitslücken ist dabei imleichtsinnigen Verhalten der IT-Nutzer zu finden und kann durch Technik nur begrenzt kon-trolliert werden. Stattdessen ist es erforderlich, die Mitarbeiter für die Themen der IT-Sicherheitzu sensibilisieren.Derartige Programme laufen neudeutsch unter dem Titel Security Awareness und werden

bislang hauptsächlich bei großen Unternehmen aufgesetzt. Die Programme kommen offenbarBewusstsein fürIT-Sicherheit

hauptsächlich zustande, wenn es im Unternehmen einen Sicherheitsverantwortlichen gibt –zum Beispiel einen Chief Information Security Officer (CISO) –, der sie vorantreibt. Empfehlens-wert ist es außerdem, die Programme in einen größeren Rahmen, ein Informationssicherheits-Managementsystem (ISMS), einzubetten.Die Programme sollen Mitarbeiter aus IT- und Nicht-IT-Abteilungen gleichermaßen für The-

men wie Sicherheitsrichtlinien, Bedrohungen und wirksame Gegenmaßnahmen aufklären (vgl.auch Abschnitt 5.4.1). Wie noch aus der Schulzeit bekannt, sind interaktive Maßnahmen dabeierfolgreicher als „Frontalunterricht“. Wird der Inhalt zudem durch für die Mitarbeiter persön-lich interessante Aspekte, wie Sicherheit für den heimischen PC, aufgepeppt, ist die Teilnahmeerfahrungsgemäß höher. Es muss aber nicht immer eine aufwändige Schulung sein: Auch we-niger umfangreiche Maßnahmen wie Newsletter, Poster und kleine „Werbegeschenke“ könneneine Erhöhung des Sicherheitsbewusstseins unterstützen. Selbstverständlich sollte hierbei eineKlassifikation der Mitarbeiter erfolgen, um solche, die mit sensibleren Daten hantieren, gründ-licher zu schulen, als weniger risikobehaftete Mitarbeiter.Die Messung des Erfolgs sowie der Akzeptanz der Kampagnen ist erfahrungsgemäß alles an-

dere als trivial. Ein Erfolg wird sich auch nicht nach der ersten Veranstaltung einstellen, sondernerst im Laufe mehrerer Monate oder sogar Jahre. Nichtsdestotrotz ist die Sensibilisierung derMitarbeiter für die IT-Sicherheit ein zentraler Faktor für eine sichere Gesamtlösung.

5.3.2 Integration in ein bestehendes Sicherheitskonzept

Wie sich in Abschnitt 5.4 zeigen wird, ergeben sich durch das Cloud-Computing nicht zwangs-läufig grundlegend neue Problemstellungen in Bezug auf das Sicherheitskonzept. Existiert imUnternehmen bereits ein gut ausgearbeitetes Sicherheitskonzept, so ist es daher oft relativunproblematisch, dieses um „Cloud-Aspekte“ zu erweitern. Wichtig ist eine tatsächliche In-tegration in das bestehende Konzept, inklusive einer Versicherung, dass die entsprechendenMaßnahmen auch angewandt und durchgesetzt werden. Unter Umständen müssen bestehen-de Systeme für die Integration von Cloud-Diensten angepasst werden. Auch diese Änderungensind im Sicherheitskonzept zu berücksichtigen, um z. B. weiterhin eine zentrale Verwaltung derIT-Systeme zu gewährleisten. [32]Außerdem müssen die Verantwortlichkeiten geklärt werden, damit im Fall eines dringen-

den Handlungsbedarfs nicht erst ein Pokern zwischen den Abteilungen anfängt, welche vonihnen nun Ressourcen und Mitarbeiter aufwenden muss, um die Probleme zu beheben. Je nachCloud-Dienst, der zur Debatte steht, muss diese Frage nämlich gar nicht eindeutig sein. Sollteder Dienst dem Chief Operating Officer zugeordnet werden oder eher dem Chief Information



Officer? Oder ist es sogar eher eine Aufgabe für die entsprechende Fachabteilung?

5.3.3 Herstellen einer Vertrauensbeziehung zwischenCloud-Konsument und Cloud-Anbieter

Während beim klassischen IT-Outsourcing eine recht konkrete Zusammenarbeit mit dem Per-sonal des externen Dienstleisters üblich ist, kann es im Kontext des Cloud-Computing sogarsoweit kommen, dass überhaupt keine menschliche Interaktion mehr nötig ist. Durch den ho-hen Automatisierungsgrad der Systeme (vgl. Abschnitt 2.1.3) kann das Anwenderunternehmenvollständig in Selbstbedienung die nötige Konfiguration vornehmen. Erst bei schwierigerenProblemstellungen oder im Fehlerfall kommt es dann noch zu einer Kommunikation mit demAnbieter. Aus diesem Grund sollte ein Unternehmen vor der Nutzung der Cloud-Dienste einTreffen mit dem Anbieter vereinbaren, um vor Ort ein Bild von den Rechenzentren, den Mit-arbeitern, der Sicherheit und den Prozessen des Anbieters zu bekommen. Durch die konkretenKontakte zu Mitarbeitern entsteht auch eine gewisse Vertrauensbasis, die vieles erleichternkann. Bei dem Besuch sollten zudem Ansprechpartner vereinbart werden, die bei Fragen oderProblemen kontaktiert werden können [32]. Auf diese Weise wird die Akzeptanz für die Cloud-Lösung auch bei den eigenen Mitarbeitern steigen.

5.3.4 Verwaltung von kryptographischen Schlüsseln

Ein weiterer kritischer Punkt für die Umsetzung sicherer Cloud-Dienste ist die Verwaltung derkryptographischen Schlüssel, auf Englisch Key Management [19, S. 69]. Je nachdem, wie hochdie Anforderungen an die Datenvertraulichkeit sind, kann ein ausgefeiltes Schlüsselmanage-ment aufseiten des Anbieters erforderlich sein. Da dies jedoch organisatorisch und technischschnell komplex wird, scheuen sich die meisten Anbieter, eine entsprechende Lösung anzu-bieten. Falls die Sicherheitsanalyse jedoch ergibt, dass ein ausgefeiltes Schlüsselmanagementerforderlich ist, so sollte geprüft werden, dass der Anbieter die einschlägigen Best Practicesumsetzt (vgl. [4]):

� Die Administratoren des Cloud-Anbieters sollten keinen Zugriff auf die Schlüssel haben.

� Verschlüsselungsschlüssel sollten niemals in Klartext offen gelegt werden.

� Zugang zu Schlüsselverwaltungsfunktionen sollten eine separate Authentisierung erfor-dern. Es empfiehlt sich zusätzlich die Anwendung des Vier-Augen-Prinzips.

� Im Speicher zwischengespeicherte Schlüssel müssen vor unbefugtem Zugriff geschütztsein.

� Die Schlüssel müssen auf sichere Art und Weise archiviert werden.

� Die Replizierung der Schlüsseln muss auf sichere Art und Weise erfolgen.


5.3 Organisatorische Aspekte

Insgesamt gilt, dass der Umgang mit den Schlüsseln sehr penibel reguliert und überwacht wer-den sollte. Auf der technischen Seite sind dann selbstverständlich noch weitere Aspekte zu prü-fen, z. B. ob alle relevanten Daten auch ausreichend sicher und mit verschiedenen Schlüsselnverschlüsselt werden.

5.3.5 Einsatz von Service-Level-Agreements (SLAs)

Ein elementarer Aspekt bei der Nutzung von Cloud-Services ist die Vereinbarung geeigneterService-Level-Agreements (SLAs), in denen alle Rechte und Pflichten der beteiligten Akteurefestgeschrieben werden müssen. Die von den Cloud-Anbietern vorgefertigten SLAs sind aller-dings häufig unzureichend, so dass sie kritisch überprüft werden sollten. Bei Bedarf müssenindividuelle Vereinbarungen ausgehandelt werden, wobei die Rechtsabteilung des Unterneh-mens und insbesondere auch die für die Sicherheit verantwortlichen Mitarbeiter frühzeitig indie Vertragsgestaltung einbezogen werden sollten. Auf diese Weise kann eine Praxistauglichkeitund Durchsetzbarkeit der SLAs sicher gestellt werden [32, 3].Zusätzlich sollten die Anforderungen der Sicherheitsverantwortlichen in Bezug auf Metriken

und Standards in die SLAs einfließen, um das eigene Sicherheitsmanagement, aber auch dieErfüllung aller regulatorischen Anforderungen zu ermöglichen. Besondere Aufmerksamkeit er-fordert die Dokumentation und Nachvollziehbarkeit (Überprüfbarkeit) der Umsetzung seitensdes Anbieters [3]. Die Erfüllung der SLAs sollte möglichst automatisiert prüfbar sein, um sowohlAnbieter als auch Nutzer unnötigen Aufwand zu ersparen.Bei aller Freiheit, die manche Anbieter bei der Gestaltung der SLAs einräumen mögen, soll-

te trotzdem klar sein, dass jede Abweichung von dem Standard-SLA des Anbieters zusätzlicheKosten nach sich zieht. Die monetären Vorteile des Cloud-Computings können sich auf dieseWeise schnell relativieren. Andererseits bieten manche Cloud-Anbieter auch gar keine Möglich-keit an, neben den Standardverträgen weitere individuelle Vereinbarungen zu treffen. Derzeitmuss dieser Aspekt also leider für den Einzelfall geprüft werden.

5.3.6 Überprüfung und Einhaltung des Sicherheitskonzepts

Eine Überprüfung, ob das Sicherheitskonzept sowohl im eigenen Unternehmen als auch durchden Cloud-Anbieter eingehalten wird, ist alles andere als trivial. Wegen der Vielzahl von Ein-flussfaktoren kommt hier nur ein koordiniertes Vorgehen durch eine zuständige Stelle in Frage.Im Hinblick auf vertraglich festgelegte Messgrößen empfiehlt es sich, diese möglichst automati-siert zu überwachen und nur bei Über- oder Unterschreitung bestimmter Meldegrenzen aktiv zuwerden. Wer diese Überwachung vornimmt muss eindeutig zugewiesen sein. In der Regel über-nimmt dies der Chief Information Security Officer (CISO) des Unternehmens – so es ihn gibt. Inder ITIL finden sich bewährte Vorgehensweisen zur Installation eines ISMS im Unternehmen.Ähnliche Kontrollen beschreibt auch ISO/IEC 27001.Sollten diese Standards für das eigene Unternehmen als zu viel des Guten gesehen werden, so

sind trotzdem strukturierte Prozesse für das Sicherheitsmanagement Pflicht. Die Empfehlunglautet, einen Teil des durch Cloud-Computing gesparten Gelds in zusätzliche Sicherheitsprüfun-gen des Cloud-Anbieters und des Cloud-Dienstes zu investieren. In diesem Zusammenhang ist es



wichtig, die Messgrößen und (internen) Standards, die zur Messung der Effektivität des Sicher-heitsmanagements benutzt werden sollen, bereits vor dem Auslagern der Systeme in die Cloudzu definieren. Als absolutes Minimum sollten aktuelle Messgrößen und die erforderlichen Än-derungen verstanden und dokumentiert werden, da der Cloud-Anbieter höchstwahrscheinlichandere, möglicherweise inkompatible Maßstäbe anlegen wird [3].Die Installation entsprechender Prozesse ist – falls sie noch nicht vorhanden sind – sehr

aufwändig und zeitintensiv und darüber hinaus nicht Thema dieses Leitfadens. Das Cloud-Computing bringt keine neuen Themen, wohl aber eine Verschiebung der Schwerpunkte mitsich. Bewährte Vorgehensweisen sollten weiterhin funktionieren, wobei die detaillierten Hin-weise undMaßnahmen in [3] die neue Akzentuierung in der Cloud erläutern. Zusammenfassendlässt sich die Cloud-Sicherheit ungefähr so wie die Supply-Chain-Sicherheit auffassen: In beidenFällen müssen auch die vorgelagerten Glieder der Supply Chain, im Falle des Cloud-Computingsdie Dienstleister des eigentlichen Cloud-Anbieters, so weit wie möglich durchleuchtet werden.

5.3.7 Einbindung des Anbieters

Wie bereits in den Abschnitten 4.4.2 und 4.4.3 erläutert, ist die Klärung der Kommunikationmit dem Anbieter wichtig. Im Hinblick auf die Sicherheit der Systeme wird diese Wichtigkeitnoch einmal verstärkt, da Sicherheitsprobleme und eventuelle Angriffe auf die Cloud offenund zeitnah mit dem Kunden besprochen werden sollten. Zusätzlich sollte geprüft werden, obder Anbieter in ein Computer Emergency Response Team (CERT), manchmal auch treffenderals Computer Security Incident Response Team (CSIRT) bezeichnet, und in das nationale IT-Krisenmanagement eingebunden ist [4].

5.4 Technische Aspekte

Nach Umsetzung der erforderlichen organisatorischen Maßnahmen aus dem vorangegangenenAbschnitt 5.3 sind selbstverständlich auch technische Aspekte der Sicherheit zu beachten. Diewichtigsten Themenbereiche werden im Folgenden vorgestellt. Zuerst steht dabei die Sicher-heit der Cloud-Infrastruktur sowie der eigenen Infrastruktur im Unternehmen im Fokus. An-schließend wird das oft als zentral empfundene Thema der Datensicherheit und -vertraulichkeitbeschrieben.

5.4.1 Sicherheit der Infrastruktur

Je nachdem wie die bisherige Systemlandschaft im Unternehmen aussieht, muss sich durch dieEinführung von Cloud-Computing nicht unbedingt viel in Bezug auf die Sicherheitskonzepteändern. Im Rahmen einer eigenen nichtöffentlichen Cloud (Private Cloud) gibt es z. B. keinewirklich neuen Aspekte. Hier kann das bewährte Vorgehen für die „traditionelle“ IT-Landschaftangewendet werden. Werden bereits externe Websites oder Datenbanken von Partnerunter-nehmen über das Internet genutzt, so muss sich ebenfalls nicht zwangsläufig allzu viel an derBedrohungslage ändern, wenn nun auch noch eine öffentliche Cloud ins Spiel kommt. Da die



Situation durch die Nutzung von Cloud-Computing jedoch insgesamt komplexer wird, ist einegründliche Analyse in jedem Fall zu empfehlen.

Netzwerkebene

Ein wichtiger Aspekt auf der Netzwerkebene ist, dass Außenstehende nun unter Umständenleichter Störungen von internen Prozessen verursachen können, indem sie die Cloud-Dienste,insbesondere eine DaaS, bzw. die Verbindung mit diesen angreifen. Letzteres ist im Zweifelsfallsogar einfacher, da grundlegende Routing-Protokolle und das Domain Name System (DNS)relativ schlecht gesichert und daher anfällig für Angriffe sind.3 Im Gegensatz zu einer internenDatenbanklösung ist hier also die Verbindung über ein WAN einer größeren Gefahr ausgesetztals vorher die LAN-Verbindung. Insbesondere größere Anbieter wie Amazon sind jedoch durchdiverse technische Maßnahmen gegen solche Angriffe geschützt, so dass eine Gefahr eher voneinem gezielten Angriff gegen das eigene Unternehmen ausgeht. Wie hoch das Risiko dafür ist,muss jedes Unternehmen selbst bewerten.Allerdings muss nicht einmal ein gezielter Angriff Schuld an Verbindungsproblemen sein.

Auch beispielsweise ein bei Bauarbeiten durchtrenntes Glasfaserkabel, eine Fehlkonfigurationeines Router im Internet oder Probleme mit der Infrastruktur des eigenen ISP können eineStörung verursachen. Je nachdem, wie wichtig die Verfügbarkeit der DaaS ist, führt dann oftkeinWeg an einer redundanten Internetanbindung über mehrere, unabhängige Provider vorbei.Abgesehen von der Anbindung an die Cloud ist auch zu beachten, dass die klassische Vor-

gehensweise zur Isolation von Netzwerkzonen und Anwendungsschichten nicht mehr greift.Während es im traditionellen Szenario möglich ist, beispielsweise Entwicklungs- und Produk-tionsserver in logisch getrennte Zonen und physisch getrennte Server innerhalb des LAN zu or-ganisieren, steht in der Cloud normalerweise nur die Einordnung in „Domains“ zur Verfügung.Diese Einordnung ist aber rein organisatorisch, da die Systeme eventuell sogar auf demselbenphysischen Server laufen – die Entscheidung liegt allein beim Cloud-Anbieter. Einige Anbieterofferieren die Möglichkeit einer „Virtual Private Cloud“, also eines logisch abgetrennten Teilseiner öffentlichen Cloud, die zur privaten Verwendung eingerichtet wird. Dieses Vorgehen bie-tet – je nach konkreter Ausgestaltung – einige der Vorteile, die aus dem eigenen Rechenzentrumbekannt sind, und kann insbesondere für DaaS-Lösungen, die in der Regel nicht direkt aus demInternet angesprochen werden sollen, eine sehr sinnvolle Schutzvorkehrung sein.Zwar ist die Netzwerksicherheit ein Aspekt, dem durch Cloud-Computing ein sehr großer Stel-

lenwert zukommt. Realistisch betrachtet ändert sich durch die Einführung von Cloud-Computingfür die meisten Unternehmen aber wahrscheinlich nicht viel. In vielen KMU existieren bereitsSchnittstellen zu Partnerunternehmen oder sogar ganze Extranets, die einige Systeme des Un-ternehmens im Internet exponieren. In solchen Fällen müssen die neuen Risiken durch Cloud-Computing zwar genau analysiert werden, um sie passend zu adressieren. Oft sind aber keinegrundlegend neuen Vorgehensweisen erforderlich, sondern etablierte Prozesse und Maßnah-men müssen lediglich erweitert werden (vgl. [19, S. 35–46]).

3Stichworte für die weitere Recherche hierzu sind z. B. „Border Gateway Protocol (BGP) prefix hi-jacking“, „DNS cache poisoning“ oder „DNS forgery“.



Host-Ebene

Ähnlich wie auf der Netzwerkebene ergeben sich auch auf der Host-Ebene durch Cloud-Computingkeine grundlegenden neuen Sicherheitsaspekte. Zwar muss auch hier eine gründlichere Analysedurchgeführt werden, da der Host nun in der Regel aus dem gesamten Internet erreichbar ist,aber die prinzipielle Natur der Analyse bleibt wie gehabt.Großes Augenmerk sollte bei der Analyse auf die Virtualisierungsschicht des Anbieters ge-

richtet sein. Im Rahmen eines Geheimhaltungsvertrags (Non-disclosure Agreement, NDA) sollteder Anbieter die Details zur gewählten Virtualisierungslösung offenlegen. In der Regel wird einHypervisor an der Virtualisierung beteiligt sein. In diesem Fall ist besonders auf die Sicher-heitsmechanismen zu achten, die dafür sorgen, dass der Hypervisor nicht kompromittiert wird.Sollte der Hypervisor erfolgreich angegriffen werden, erhält der Angreifer Zugriff auf beliebigeDaten des physischen Host. Verschiedene Beiträge auf einschlägigen Sicherheitskonferenzenbeschäftigen sich mit möglichen (teilweise erfolgreichen) Angriffen auf aktuelle Virtualisie-rungssoftware (vgl. [19]).In Bezug auf die Host-Sicherheit muss man als SaaS- und PaaS-Nutzer dem Anbieter vertrau-

en, dass er seine Aufgaben entsprechend der getroffenen Vereinbarungen ordentlich erfüllt.Diese Übertragung der Verantwortung ist aber gewollt, weil sie genau einen Vorteil des Cloud-Computing darstellt. Im Falle von IaaS-Angeboten muss der Dienstnutzer sich um zahlreicheAspekte selbst kümmern. Speziell für DaaS-Angebote auf IaaS-Niveau erfordert dies, das Da-tenbankmanagementsystem (DBMS) genauso abzusichern, wie man es für einen physischenDatenbank-Host im Internet auch getan hätte.

Applikationsebene

Auf Applikationsebene muss die Cloud-Datenbank im Endeffekt genauso abgesichert werden,wie eine traditionelle Datenbank im Internet. Bei der Konfiguration geht man nach gewohn-tem Muster vor und schaltet jegliche ungenutzte Funktionalität ab bzw. schränkt die Rechteder Nutzer entsprechend ein. Falls möglich sollte der Zugriff auf das DBS nur von vorgege-benen IP-Adressen aus dem Firmennetz zugelassen werden. Auch sollten den Benutzerkontenimmer nur die für den Zweck nötigen Rechte eingeräumt werden, z. B. keine Löschvorgängefür Programme, die nur Daten erzeugen, etc.Abgesehen von diesen hinreichend bekannten Standardmaßnahmen trägt der Benutzer mit

zunehmender Cloud-Nutzung auch immer mehr die Verantwortung seinen Webbrowser undArbeitsplatz-PC abzusichern. Es gilt der neue Grundsatz: „Der Browser ist das Betriebssystem“.Daher müssen aktuelle Sicherheitsupdates sowohl für das Betriebssystem als auch für denBrowser zeitnah eingespielt werden. Zusätzlich ist die Installation von Anti-Virus- und Anti-Malware-Software notwendig. Diese muss zudem mehrmals täglich aktualisiert werden, umausreichenden Schutz zu bieten. Die Vorsichtsmaßnahmen sind insbesondere deshalb wich-tig, weil der Zugriff auf die Cloud-Dienste häufig nur über ein Passwort oder – etwas besser– einen privaten Schlüssel gesichert ist. Angreifer versuchen inzwischen gezielt solche Datenauszuspähen, weswegen sie besonders sorgfältig gehandhabt werden müssen. Ein etabliertesIT-Sicherheitsmanagement vorausgesetzt, sind diese Aspekte jedoch bereits für UnternehmenRoutine.



Neben dem Ausspähen von Zugangsdaten bieten in die Cloud ausgelagerte Dienste auch mehrAngriffsfläche für gezielte Denial-of-Service-(DoS-)Angriffe auf Applikationsebene. Diese An-

Denial-of-Servicegriffe können z. B. darin bestehen, dass eine enorme Anzahl von Anfragen an den Dienst ge-stellt wird. Diese Anfragen lassen sich in der Regel nur sehr schwierig von legitimen Anfragenunterscheiden und daher auch kaum filtern. Abgesehen von der Beeinträchtigung des Cloud-Dienstes, ist die neuartige Bedrohung darin zu sehen, dass diese Angriffe bares Geld kosten.Da der Anbieter die Ressourcennutzung abrechnet, bedeuten viele Anfragen auch hohe Kosten.Teilweise zielen die Angriffe inzwischen sogar auf genau diese Verursachung von Kosten ab,weswegen man bei dieser Art von Angriff auch von Economic-Denial-of-Sustainability (EDoS)spricht.Als letzter, wichtiger Aspekt ist besonders für SaaS- und DaaS-Dienste zu klären, wie die Tren-

nung der Daten verschiedener Mandanten vom Provider vorgenommen wird. Das Vorgehen istMandantenfähigkeitals Sicherheitsaspekt

wichtig, um zu erkennen, welche potentiellen Sicherheitsrisiken von einer gemeinsamen Spei-cherung der Daten verschiedener Kunden ausgehen. Prinzipiell eröffnen sich dem Anbieter vieleMöglichkeiten, die Daten zu trennen. Oft werden einfach dieselben Tabellen verwendet, wobeidie Datensätze dann über ein zusätzliches Feld „Kunden-ID“ dem jeweiligen Mandanten zuge-ordnet werden. Eventuell werden auch getrennte Tabellen oder sogar Datenbanken verwendet.Im besten Fall werden die Daten pro Kunde mit einem individuellen Schlüssel verschlüsseltabgespeichert, was jedoch in der Praxis wegen der komplexen Schlüsselverwaltung von denCloud-Anbietern üblicherweise gescheut wird (vgl. Abschnitt 5.3.4). In jedem Fall ist es jedochwichtig zu wissen, welche Maßnahmen eingesetzt werden, um die Sicherheit des Diensts ins-gesamt beurteilen zu können. Zwar wird der Anbieter versuchen, hierüber mit einem Verweisauf das Geschäftsgeheimnis Stillschweigen zu bewahren. Im Rahmen eines Geheimhaltungsver-trags könnte sich der Informationsaustausch aber eventuell realisieren lassen. Alternativ könnteeine externe Begutachtung ein entsprechendes Testat erbringen.

5.4.2 Sicherheit und Schutz der Daten

Als zentrales Problem des Cloud-Computing wird meistens die Sicherheit der eigenen Daten inder Cloud angeführt. Die Sorge ist nicht ganz unberechtigt, da ja auch zahlreiche gesetzlicheVorgaben zum Schutz der Daten erfüllt werden müssen (vgl. Abschnitt 3.1.3). Zur Erfüllungdieser Vorgaben müssen kryptographische Methoden eingesetzt werden, die allerdings häu-fig den Einsatz von standardisierten Applikationen erschweren. Einige Anbieter machen daherAbstriche bei der Sicherheit oder versuchen durch eigene Lösungen Abhilfe zu schaffen. Im Fol-genden soll erörtert werden, an welchen Stellen das Anwenderunternehmen genau nachhakenmuss.Im Vorfeld zu klären ist, wer eigentlich bestimmte sensible Daten einsehen darf und wer

nicht. Diese zentrale Problemstellung wird leider häufig übersehen, ist aber essentiell wichtig,um die Sicherheit der gesamten Lösung bewerten zu können. Es muss sowohl auf der Seitedes Cloud-Anbieters als auch auf der Seite des Cloud-Nutzers klar definiert werden, welchePersonen bestimmte, sensible Daten einsehen dürfen und welche Maßnahmen verhindern, dassUnbefugte Zugriff auf die Daten erlangen.



Ansätze zur Wahrung der Datenvertraulichkeit

Das für Unternehmen wohl wichtigste Schutzziel ist die Vertraulichkeit der Daten. Dabei ist zubeachten, dass die Datenvertraulichkeit zwei Teilaspekte aufweist:

1. Zugriffskontrolle (Access Control)

2. Schutz der eigentlichen Daten

Durch die Zugriffskontrolle stellt das System sicher, dass nur authentifizierte und autorisierteBenutzer auf die Daten zugreifen dürfen. Diese Kontrolle besteht bei den Cloud-Anbietern der-zeit üblicherweise aus einem schwachen Authentisierungsverfahren („Benutzername + Pass-wort“) kombiniert mit einem dichotomen Autorisierungsverfahren (Anmeldung als „Adminis-trator“ oder „Benutzer“). Für Unternehmen kann diese Zugriffskontrolle schnell unzulänglichsein, insbesondere wenn keine weiteren Rollen- und Rechteverwaltung vorgesehen ist.Darüber hinaus müssen die Daten vor Zugriffen geschützt werden, die das System nicht per

Zugriffskontrolle absichern kann. Die Datenvertraulichkeit soll dabei auch gegeben sein, wennz. B. direkt auf das physische Speichermedium zugegriffen wird. Alle praxistauglichen Ansätzezur Datenvertraulichkeit involvieren heutzutage kryptographische Verfahren zur Verschlüsse-lung der Daten [19, S. 66 f.]. Die Verschlüsselung erfolgt mithilfe symmetrischer Verfahren –z. B. dem Advanced Encryption Standard (AES) – und sollte am besten direkt vom Providerunterstützt werden, um ordentliche Datenraten zu erzielen. Die meisten Anbieter übertragenjedoch diese Aufgabe gerne an den Kunden. Dadurch fallen aber gerade im DaaS-Bereich vieleVorteile wie serverseitige Auswertung von Abfragen weg, weil der Server nur noch verschlüs-selte Daten sieht. In der Praxis gibt es also bei den meisten Angeboten nur zwei Möglichkeiten:

� den Cloud-Dienst ohne Verschlüsselung der Daten im Rechenzentrum des Providers nut-zen,4 was ein Sicherheitsrisiko darstellen und daher inakzeptabel sein kann, oder

� die Daten vor dem Senden an den Cloud-Dienst verschlüsseln, was jedoch den Cloud-Dienst oft zu einer überteuerten Backup-Lösung degenerieren lässt.

Zwar existieren einige Ansätze aus der Wissenschaft, die verschlüsselte Indexstrukturen oderpartielle Unterstützung von Abfragen auf verschlüsselten Daten realisieren könnten.5 Es sindsogar erste Schritte in Richtung einer vollständig homomorphen Verschlüsselung erfolgt, dieerlauben würde, dass der Cloud-Anbieter ausschließlich mit verschlüsselten Daten arbeitete[11]. In der Praxis ist jedoch die einzige realisierbare Möglichkeit, dass der Cloud-Anbieter dieDaten zumindest verschlüsselt auf der Festplatte ablegt – und selbst diese Möglichkeit bestehtbei vielen Cloud-Anbietern noch nicht. Als Konsequenz müssen daher strikte Vereinbarungenüber die Verarbeitung und Speicherung der Daten mit dem Dienstanbieter getroffen werden,um zumindest Transparenz über die tatsächliche Lage zu erhalten.4Der Transportweg zum Rechenzentrum kann dabei natürlich trotzdem z. B. per SSL/TLS abgesichertwerden.

5Vgl. [17] für eine Übersicht.



Sicherheit der Daten des Anbieters

Zusätzlich zur Sicherheit der eigenen Daten sollte auch darauf geachtet werden, welche Datender Cloud-Anbieter sammelt und wie diese geschützt sind. Insbesondere in Bezug auf die in derCloud gespeicherten Daten über den eigenen Kundenstamm ist es interessant zu wissen, welcheMetadaten der Anbieter sammelt, wie er diese schützt und in welcher Form der Dienstnutzerdiese Daten einsehen kann.Abgesehen von den Daten, die Nutzer explizit mit dem Cloud-Dienst verarbeiten, fallen auch

noch reichlich zusätzliche sicherheitsrelevante Daten an, z. B. diverse Log-Dateien oder Statis-tiken. Einerseits benötigt der Cloud-Anbieter diese Informationen, um die Funktionsfähigkeitseiner verschiedenen System, wie Firewall, Intrusion Prevention System (IPS) oder eigener Ap-plikationen zu überwachen. Auch im Hinblick auf Zertifizierungen, digitale Forensik oder Ana-lyse von Störungen (Incidents) werden diese Daten benötigt. Andererseits lassen sich auf Basisdieser Metadaten bereits zahlreiche Schlussfolgerungen über die Geschäftstätigkeit der Dienst-nutzer ableiten. Reine Verbindungsdaten reichen beispielsweise aus, um Beziehungen innerhalbvon sozialen Netzen zu charakterisieren. Auf Basis der Routing-Protokolle lassen sich so z. B.Großkunden identifizieren. Daher muss sichergestellt werden, dass auch für diese Daten dierelevanten Schutzziele erreicht werden.

Weitere potentielle Probleme der Datenvertraulichkeit

Abgesehen von gezielten Angriffen oder Datenpannen kann die Datenvertraulichkeit auch durchzwei weitere, häufig nicht bedachte Ursachen verletzt werden (vgl. [33]):

� Insolvenz des Providers:Die Insolvenz eines Providers bedeutet nicht, dass alle Rechen-zentren, die für den Cloud-Dienst genutzt wurden, ebenfalls insolvent sind. Rechenzen-tren werden außerdem im Falle einer Insolvenz höchstwahrscheinlich weiterverkauft.In beiden Fällen ist nicht klar, was mit den sensiblen Daten, die wahrscheinlich nochim Rechenzentrum vorhanden sind, passiert und wie diese Daten vor unberechtigtemZugriff geschützt werden können.

� Beschlagnahmung von Hardware: Eine Beschlagnahmung von Hardware kann in al-len Ländern erfolgen in denen der Anbieter Cloud-Ressourcen betreibt. Die Beschlagnah-mung kann aus diversen Gründen erfolgen, für die der Dienstnutzer keine Verantwor-tung trägt. Sehr wohl können sich aber Daten des Cloud-Nutzers oder Metadaten überdie Cloud-Nutzung (z. B. Logs) auf den beschlagnahmten Servern befinden. Diese Datenkönnen unerwünschte Schlussfolgerungen über die Geschäftstätigkeit des Cloud-Nutzersermöglichen (s. o.).

Ansätze zur Wahrung der Datenintegrität

Zwar ist die Gewährleistung von Vertraulichkeit für die Daten genug, um die sensiblen Datenvor unberechtigtem Mitlesen zu schützen. Ein weiterer wichtiger Aspekt, insbesondere für eineDaaS, ist jedoch, sicherzustellen, dass die Daten nicht verändert oder manipuliert wurden. Wäh-rend für dieWahrung der Vertraulichkeit eine Verschlüsselung ausreicht, erfordert dieWahrung



der Datenintegrität kryptographische Hash-Funktionen, z. B. in Form eines Message Authenti-cation Code (MAC). Die richtige Anwendung dieser MACs ist jedoch nicht trivial und solltedaher mit dem Cloud-Anbieter abgeklärt werden. Zumindest erfährt das Kundenunternehmenauf diese Weise, wie gut sich der Anbieter mit diesen sicherheitsrelevanten Fragestellungen be-reits auseinander gesetzt hat. Im besten Fall hat der Anbieter bereits eine Lösung im Angebot,was jedoch – ähnlich wie bei der Verschlüsselung – derzeit nicht die Regel ist.Eine weitere Frage, die sich in diesem Zusammenhang stellt, ist die Überprüfbarkeit der Da-

tenintegrität bei großen Datenbanken. Wenn die DaaS-Lösung intensiv genutzt wird, will derKunde natürlich nicht immer die gesamte Datenbank herunterladen, bloß um die Integrität derDaten zu prüfen. Zum einen erzeugt dies unnötige Kosten, zum anderen dauert es lange. Dahermuss geklärt werden, wie eine Integritätsprüfung „in der Cloud“ durchgeführt werden kann.Hier gibt es ebenfalls Ansätze in der Wissenschaft unter dem Stichwort „Proof of Retrievabi-lity“ [30, 2, 37], die jedoch nach unserem Kenntnisstand von keinem Cloud-Anbieter angebo-ten werden. Daher bleibt in der Praxis nur die Möglichkeit, dem Anbieter in dieser Hinsichtzu vertrauen und gegebenenfalls anhand von Prüfsummen die Integrität der Daten zumindestplausibel zu machen.

5.5 ZusammenfassungWie in diesem Kapitel dargelegt, bringt das Cloud-Computing keine grundlegend neuen Sicher-heitsprobleme, sondern verändert lediglich den Schwerpunkt bzw. verschärft einige bekannteAspekte. Durch sorgfältige Planung und Analyse können die sicherheitsrelevanten Bereicheidentifiziert und kontrolliert werden. In Verbindung mit der Lektüre der ausführlichen Erläu-terungen, stellen die zehn Leitfragen auf der folgenden Seite ein Werkzeug zur ersten Einschät-zung der Sicherheit einer konkreten Cloud-Lösung dar. Selbstverständlich sollte vor dem tat-sächlichen Schritt „in die Cloud“ eine sehr viel gründlichere Analyse durchgeführt werden, dieauf den vorgestellten Verfahren und Standards beruht. Das BSI stellt mit [4] einen etwas detail-lierteren Leitfaden hierzu bereit. Das Vorgehen nach IT-Grundschutz bietet eine noch feinereGranularitätsstufe [23].


Zehn Leitfragen zur Sicherheit der Cloud-Lösung..

10Fragen

1. Wird die Sicherheit der Cloud-Computing-Lösung in einem ganzheitlichen Sicherheitskon-zept beurteilt, werden bestehende Sicherheitskonzepte angemessen berücksichtigt unddie neue Cloud-Computing-Lösung in diese eingearbeitet?

2. Hat der Provider eine ausführliche Analyse der Sicherheitsaspekte des Cloud-Dienstesdurchgeführt, bei der mögliche Angriffsvektoren und Schwachstellen analysiert und be-wertet sowie durch angemessene Technologien und Prozesse adressiert wurden?

3. Durch welche Zertifikate, Testate oder externe Überprüfungen kann der Cloud-Anbieterden sicheren Betrieb seiner Services glaubhaft machen und wie kann das Anwenderun-ternehmen dies überprüfen?

4. Wie wird die korrekte Funktion aller Sicherheitsmechanismen gewährleistet und wiewird im Fehlerfall vorgegangen?

5. Sind auch die sicherheitsrelevanten Aspekte der Servicenutzung durch ein SLA abge-deckt?

6. Wurde die gesamte Wertschöpfungskette inklusive der Dienstleister des Cloud-Anbietersanalysiert?

7. Wie werden die Kommunikationskanäle (Netzinfrastruktur) zur Cloud im Sicherheits-konzept berücksichtigt und geschützt?

8. Bieten alle Rechenzentren, in denen der Provider die Daten des Unternehmens verar-beitet, dasselbe Sicherheitsniveau, auch z. B. im Hinblick auf die politische Lage undrechtliche Situation im jeweiligen Land?

9. Ist klar definiert, wer bestimmte sensible Daten einsehen darf, und welche Kontrollme-chanismen bzw. technischen Maßnahmen kann der Anbieter vorweisen, um zu garantie-ren, dass diese Daten vor dem Zugriff durch unberechtigte Dritte geschützt sind, solangesie in seinem Wirkungsbereich gespeichert sind?

10. Wie erkennt der Cloud-Anbieter, dass ein Dienst angegriffen wird, und auf welche Artund Weise werden die Mitarbeiter des Cloud-Nutzers darüber informiert?

6 Zusammenfassung

Im Rahmen dieses Leitfadens wurde ein erster Eindruck von den Einsatzmöglichkeiten vonCloud-Computing gegeben. Es wurden vor allem auch die zu erwartenden Maßnahmen be-schrieben, die mit der Einführung von Cloud-Computing im Unternehmen einhergehen. Fest-zuhalten bleibt, dass Cloud-Computing keine technische Revolution, aber eine neuartige Kom-

Keine Revolutionbination aus vielen bekannten und einigen neuen Ansätzen ist. Die Definition des Begriffshat sich einigermaßen stabilisiert und man unterscheidet drei verschiedene Servicemodelle:Infrastructure-as-a-Service, Platform-as-a-Service sowie Software-as-a-Service. Database-as-a-Service (DaaS), der Fokus dieses Leitfadens, bezeichnet eine Klasse von Cloud-Diensten, dieFunktionalitäten eines DBS in der Cloud bereitstellen. DaaS kann dabei basierend auf einemder drei Servicemodelle angeboten werden. Die meisten Aspekte aus diesem Leitfaden lassensich direkt auf andere Arten von Diensten übertragen und sind nicht spezifisch für DaaS. Esgibt zudem vier verschiedene Arten des Cloud-Betriebs: die öffentliche und die nichtöffentli-che Cloud sowie die Community-Cloud und die hybride Cloud. Trotz der vielen neuen Begriffeist Cloud-Computing nicht allzu verschieden vom klassischen IT-Outsourcing. Allerdings ver-schiebt sich die Gewichtung der zu beachtenden Aspekte.Wirtschaftlich kann Cloud-Computing je nach Anwendungsfall sehr attraktiv sein – muss es

aber auch nicht. Insbesondere für Cloud-Dienste, die von der „Stangenware“ abweichen, for-dern die Anbieter hohe Gebühren, so dass die Vorteile schnell schwinden. Technisch bringtCloud-Computing für den Anwender nur wenig wirklich neue Herausforderungen, fordert aberoft eine Anpassung bestehender Systeme. Organisatorisch erfordert es stringente Abläufe, diegegebenenfalls im Unternehmen erst noch einzuführen sind. Das Hauptproblem ist jedochdie rechtliche Unsicherheit, die der Tatsache geschuldet ist, dass die meisten Aspekte desCloud-Computing juristisch noch ungeklärt sind. In jedem Fall muss auf Managementebene

RechtlicheUnsicherheit

eine Cloud-Strategie entwickelt werden. Sie ist eine essentielle Voraussetzung für jedes Cloud-Projekt.Bei der Auswahl des Anbieters müssen alle vier Dimensionen des Cloud-Computing betrach-

tet werden. Besondere Aufmerksamkeit sollte den erwarteten Lock-in-Effekten, der Integrationin bestehende Systeme und der Erfüllung rechtlicher Rahmenbedingungen gewidmet werden.Auch die Support-Leistungen und die Kommunikation mit dem Anbieter sind wichtige Aspek-te. Auf jeden Fall ist ein strukturiertes Vorgehen zur Anbieterauswahl inklusive Dokumentationgefordert.Die Sicherheit in der Cloud ist für alle Unternehmen ein zentrales Thema und muss explizit

in der Cloud-Strategie behandelt werden. Einige einfache Maßnahmen, sozusagen das „KleineEinmaleins der Cloud-Sicherheit“, verhelfen bereits zu einer soliden Grundlage. Selbstverständ-

Sicherheit in derCloud

lich müssen die eigenen Anforderungen an die Sicherheit im Vorfeld genau geklärt werden. Austechnischer Sicht müssen sowohl die Infrastruktur als auch die Daten geschützt werden. Ansät-


6 Zusammenfassung

ze für ersteres sind bekannt, der Aspekt der Datensicherheit stellt größere Hürden in den Weg,da viele Anbieter nur ein durchschnittliches, aber kein hohes Schutzniveau erbringen. Trotzungeklärter technischer Fragestellungen überwiegen die organisatorischen Probleme. Unter an-derem müssen die Mitarbeiter sensibilisiert und geschult werden sowie bestehende und neueSicherheitskonzepte integriert werden. Insgesamt ist die Sicherheit von Cloud-Diensten nichtnotwendigerweise schlechter als von Lösungen im eigenen Haus.Beim Cloud-Computing verhält es sich folglich nicht anders als bei anderen Fragestellungen

der IT: der Einsatz kann sehr sinnvoll sein, aber dies ist abhängig vom konkreten Szenario.Auch ein sicherer und zuverlässiger Betrieb ist möglich. Je höher allerdings die Anforderun-gen an den Dienstleister werden, desto unattraktiver wird eine Cloud-Lösung. Als Faustregellässt sich daher festhalten, dass Cloud-Computing vor allem für standardisierte Produkte at-traktiv ist. Trotzdem sollte sich jedes Unternehmen mit dem Thema auseinander setzen undeine individuelle Cloud-Strategie erarbeiten – selbst wenn das Ergebnis die Festlegung ist, dassCloud-Computing vermieden wird.


Literaturverzeichnis

[1] Armbrust, Michael ; Fox, Armando ; Griffith, Rean ; Joseph, Anthony D. ; Katz, Randy H. ; Konwin-ski, Andrew ; Lee, Gunho ; Patterson, David A. ; Rabkin, Ariel ; Stoica, Ion ; Zaharia, Matei: Abovethe Clouds: A Berkeley View of Cloud Computing / EECS Department, University of California,Berkeley. 2009 (UCB/EECS-2009-28). – Forschungsbericht

[2] Bowers, Kevin D. ; Juels, Ari ; Oprea, Alina: Proofs of retrievability: theory and implementation.In: CCSW ’09: Proceedings of the 2009 ACM workshop on Cloud computing security. New York,NY, USA : ACM, 2009. – ISBN 978–1–60558–784–4, S. 43–54

[3] Brunette, Glenn ; Mogull, Rich: Security Guidance for Critical Areas of Focus in Cloud Compu-ting / Cloud Security Alliance. Version: December 2009. http://www.cloudsecurityalliance.org/csaguide.pdf. 2009. – White Paper

[4] Bundesamt für Sicherheit in der Informationstechnik (BSI): BSI-Mindestsicherheitsanforderungen an Cloud-Computing-Anbieter. Entwurf zur Diskussion.http://tinyurl.com/35kfeua. Version: September 2010

[5] Connolly, Chris: The US Safe Harbor – Fact or Fiction? / Galexia Pty Ltd. 2008. – ResearchArticle

[6] Denning, Dorothy E.: Cryptography and data security. Addison-Wesley, 1982 (ACM ClassicBooks Series)

[7] Discini, Sonny ; Needle, David ; McGarvey, Robert ; Maguire, James: Understanding the SecurityChallenges of Cloud Computing / internet.com. 2010. – White Paper

[8] Eckert, Claudia: IT-Sicherheit: Konzepte – Verfahren – Protokolle. 6. Auflage. München : Olden-bourg, 2009

[9] Erl, Thomas: Service-Oriented Architecture – Concepts, Technology and Design. Prentice HallPTR, 2005 (Prentice Hall Service Oriented Computing Series)

[10] Garfinkel, Simson L.: An Evaluation of Amazon’s Grid Computing Services: EC2, S3 and SQS /Center for Research on Computation and Society, Harvard University, Cambridge, MA. 2007(TR-08-07). – Technical Report

[11] Gentry, Craig: A fully homomorphic encryption scheme, Stanford University, Diss., 2009. http://crypto.stanford.edu/craig


http://www.cloudsecurityalliance.org/csaguide.pdf

http://www.cloudsecurityalliance.org/csaguide.pdf

http://tinyurl.com/35kfeua

http://crypto.stanford.edu/craig

http://crypto.stanford.edu/craig


[12] Gilbert, Seth ; Lynch, Nancy: Brewer’s conjecture and the feasibility of consistent, available,partition-tolerant web services. In: ACM SIGACT News, 2002

[13] Grossman, Robert L.: The Case for Cloud Computing. In: IT Professional 11 (2009), Nr. 2,S. 23–27. http://dx.doi.org/10.1109/MITP.2009.40. – DOI 10.1109/MITP.2009.40. – ISSN1520–9202

[14] Haselmann, Till ; Thies, Gunnar ; Vossen, Gottfried: Looking into a REST-based API for Database-as-a-Service Systems. In: Proc. 12th IEEE Conference on Commerce and Enterprise Computing(CEC 2010) (to appear) (2010)

[15] Kephart, Jeffrey O. ; Chess, David M.: The Vision of Autonomic Computing. In: IEEE Computer36 (2003), Nr. 1, S. 41–50

[16] Kittlaus, Hans-Bernd ; Schreiber, Dirk: SaaS – wie können KMU profitieren? In:Wirtschafsinfor-matik & Management (2010), Nr. 02, S. 36–42

[17] Lansing, Jens: Aktueller Stand und zukünftige Entwicklungsmöglichkeiten von Database-as-a-Service-Angeboten, Lehrstuhl für Informatik, Institut für Wirtschaftsinformatik, WestfälischeWilhelms-Universität Münster, Diplomarbeit, Dezember 2008

[18] Leong, Lydia: How to Select a Cloud Computing Infrastructure Provider / Gartner Group. 2009(G00166565). – White Paper

[19] Mather, Tim ; Kumaraswamy, Subra ; Latif, Shahed: Cloud Security and Privacy. O’Reilly Media,2009. – ISBN 9780596802769

[20] National Institute of Standards and Technology (NIST): NIST Cloud Computing Project. http://csrc.nist.gov/groups/SNS/cloud-computing/. Version:May 2010, Abruf: 2010-08-09. – online

[21] Neuman, B. C.: Scale in Distributed Systems. In: Readings in Distributed Computing Systems,IEEE Computer Society Press, 1994, S. 463–489

[22] o. V.: BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS). Version 1.5.Bundesamt für Sicherheit in der Informationstechnik (BSI), 2008 (IT-Grundschutz)

[23] o. V.: BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise. Version 2.0. Bundesamt für Sicher-heit in der Informationstechnik (BSI), 2008 (IT-Grundschutz)

[24] o. V.: BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz. Version 2.5. Bundes-amt für Sicherheit in der Informationstechnik (BSI), 2008 (IT-Grundschutz)

[25] o. V.: BSI-Standard 100-4: Notfallmanagement. Version 1.0. Bundesamt für Sicherheit in derInformationstechnik (BSI), 2008 (IT-Grundschutz)

[26] o. V.: How VMware Virtualization Right-sizes IT Infrastructure to Reduce Power Con-sumption / VMware, Inc. Version: 2008. http://www.vmware.com/files/pdf/WhitePaper_ReducePowerConsumption.pdf. 2008. – White Paper


http://dx.doi.org/10.1109/MITP.2009.40

http://csrc.nist.gov/groups/SNS/cloud-computing/

http://csrc.nist.gov/groups/SNS/cloud-computing/

http://www.vmware.com/files/pdf/WhitePaper_ReducePowerConsumption.pdf

http://www.vmware.com/files/pdf/WhitePaper_ReducePowerConsumption.pdf


[27] o. V.: IT-Grundschutz-Kataloge. 11. EL. Bundesamt für Sicherheit in der Informationstechnik(BSI), 2009

[28] o. V.: Cloud Computing Use Case White Paper V4 / Cloud Computing Use Cases Group.Version: Juli 2010. http://cloudusecases.org/. 2010. – White Paper

[29] Pritchett, Dan: BASE: An Acid Alternative. In: ACM Queue 6 (2008), Nr. 3, 48–55. http://dx.doi.org/10.1145/1394127.1394128. – DOI 10.1145/1394127.1394128. – ISSN 1542–7730

[30] Shacham, Hovav ; Waters, Brent: Compact Proofs of Retrievability. Version: 2008. http://dx.doi.org/10.1007/978-3-540-89255-7_7. In: Pieprzyk, Josef (Hrsg.): Advances in Cryptology - ASIA-CRYPT 2008 Bd. 5350. Springer Berlin/Heidelberg, 2008. – DOI 10.1007/978–3–540–89255–7_7,S. 90–107

[31] Stonebraker, Michael ; Madden, Samuel ; Abadi, Daniel J. ; Harizopoulos, Stavros ; Hachem,Nabil ; Helland, Pat: The End of an Architectural Era (It’s Time for a Complete Rewrite). In:Koch, Christoph (Hrsg.) ; Gehrke, Johannes (Hrsg.) ; Garofalakis, Minos N. (Hrsg.) ; Srivastava,Divesh (Hrsg.) ; Aberer, Karl (Hrsg.) ; Deshpande, Anand (Hrsg.) ; Florescu, Daniela (Hrsg.) ;Chan, Chee Y. (Hrsg.) ; Ganti, Venkatesh (Hrsg.) ; Kanne, Carl-Christian (Hrsg.) ; Klas, Wolfgang(Hrsg.) ; Neuhold, Erich J. (Hrsg.): VLDB, ACM, September 2007. – ISBN 978–1–59593–649–3, S.1150–1160

[32] Streitberger, Werner ; Ruppel, Angelika: Cloud Computing Sicherheit - Schutzziele. Taxonomie.Marktübersicht. Parkring 4, Garching b. München : Fraunhofer-Institut für sichere Informati-onstechnologie, September 2009

[33] Störtkuhl, Thomas ; Wagner, Hans: Cloud Computing und die IT-Security. In: IT-Grundschutz(2010), Februar, Nr. 2, S. 7–9

[34] Vaquero, Luis M. ; Rodero-Merino, Luis ; Caceres, Juan ; Lindner, Maik: A Break in the Clouds:Towards a Cloud Definition. In: Computer Communication Review 39 (2009), Nr. 1, S. 50–55

[35] Velten, Carlo ; Janata, Steve: Cloud Vendor Benchmark – Cloud Computing Anbieter im Ver-gleich / Experton Group. 2010. – White Paper

[36] Vossen, Gottfried: Datenmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. 5.überarbeitete und erweiterte Auflage. München, Wien : R. Oldenbourg Verlag, 2008

[37] Wang, Cong ; Wang, Qian ; Ren, Kui ; Lou, Wenjing: Ensuring data storage security in CloudComputing. In: Proc. 17th International Workshop on Quality of Service (IWQoS). Charleston,SC, July 2009, S. 1–9

[38] Weinman, Joe: Mathematical Proof of the Inevitability ofCloud Computing. http://cloudonomics.wordpress.com/2009/11/30/mathematical-proof-of-the-inevitability-of-cloud-computing/. Version: November 2009,Abruf: 2010-08-09. – online


http://cloudusecases.org/

http://dx.doi.org/10.1145/1394127.1394128

http://dx.doi.org/10.1145/1394127.1394128

http://dx.doi.org/10.1007/978-3-540-89255-7_7

http://dx.doi.org/10.1007/978-3-540-89255-7_7

http://cloudonomics.wordpress.com/2009/11/30/mathematical-proof-of-the-inevitability-of-cloud-computing/

http://cloudonomics.wordpress.com/2009/11/30/mathematical-proof-of-the-inevitability-of-cloud-computing/


[39] Wikipedia (DE): Virtualisierung (Informatik). http://de.wikipedia.org/w/index.php?title=Virtualisierung_(Informatik)&oldid=79167522. Version: September 2010, Abruf: 2010-09-30.– online

[40] Wikipedia (EN): Utility Computing. http://en.wikipedia.org/w/index.php?title=Utility_computing&oldid=387678616. Version: September 2010, Abruf: 2010-09-30. – online


http://de.wikipedia.org/w/index.php?title=Virtualisierung_(Informatik)&oldid=79167522

http://de.wikipedia.org/w/index.php?title=Virtualisierung_(Informatik)&oldid=79167522

http://en.wikipedia.org/w/index.php?title=Utility_computing&oldid=387678616

http://en.wikipedia.org/w/index.php?title=Utility_computing&oldid=387678616

ISSN 1868-0801

Einsteinstraße 62

D-48149 Münster

Tel.: +49 251 83 33797

Fax : +49 251 83 33755

Förderkreis der Angewandten Informatik

an der Westfälischen Wilhelms-Universität Münster e.V.

Database-as-a-Service für kleine und mittlere …...Vorwort...

Documents

Transcript of Database-as-a-Service für kleine und mittlere …...Vorwort...