Bewertung der Eignung von Applikationslandschaften für den Betrieb in einer Cloud


Bachelorarbeit, 2016
89 Seiten, Note: 1,3

Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einleitung
1.1 Motivation und Zielsetzung
1.2 Aufbau der Arbeit

2. Theoretische Grundlagen des Cloud-Computing
2.1 Definition und Eigenschaften von Cloud-Computing
2.2 Cloud Technologien
2.2.1 Virtualisierung
2.2.2 Serviceorientierte Architekturen
2.2.3 Web Services
2.3 Service Ebenen des Cloud-Computing
2.3.1 Infrastructure-as-a-Service (IaaS)
2.3.2 Platform-as-a-Service (PaaS)
2.3.3 Software-as-a-Service (SaaS)
2.4 Organisationsformen des Cloud-Computing
2.4.1 Private Cloud
2.4.2 Public Cloud
2.4.3 Hybrid Cloud

3. Anforderungen an Applikationen für den Betrieb in der Cloud
3.1 Cloud Applikationsdesign
3.2 Cloud Server Bereitstellung
3.3 Cloud-Netzwerk
3.4 Datenschutz
3.5 Informationssicherheit
3.6 Verifizieren der Anforderungen mit Hilfe von Experteninterviews
3.6.1 Auswahl der Experten
3.6.2 Durchführung der Interviews
3.6.3 Auswertung der Interviews

4. Bewertung der Cloud Fähigkeit von Applikationslandschaften
4.1 Methodische Vorgehensweise
4.2 Cloud-Bewertungskriterien und deren Abstufungen
4.2.1 Applikationsdesign
4.2.2 Server
4.2.3 Datenbank
4.2.4 Netzwerk
4.2.5 Datenschutz
4.2.6 Informationssicherheit
4.3 Erstellung der Machbarkeits- und Potentialanalyse
4.4 Evaluation des Kriterienkatalogs anhand einer SAP ERP Applikation
4.4.1 Beschreibung der Anwendung
4.4.2 Machbarkeits- und Potentialanalyse
4.4.3 Handlungsempfehlung
4.5 Evaluation des Kriterienkatalogs anhand einer Web Applikation
4.5.1 Beschreibung der Anwendung
4.5.2 Machbarkeits- und Potentialanalyse
4.5.3 Handlungsempfehlung

5. Zusammenfassung und Fazit
5.1 Reflexion des Vorgehens
5.2 Beantwortung der Forschungsfragen
5.3 Kritische Betrachtung und Ausblick

Anhang 1: Zusammenfassung Experteninterviews

Anhang 2: Machbarkeits- und Potentialanalyse

Anhang 3: Quellen der Kriterien

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Charakteristische Merkmale des Cloud-Computings

Abbildung 2: Vergleich Bare Metal Hypervisor und Hosted Machine Monitor

Abbildung 3: Abbildung von virtuellen Netzen bei der Servervirtualisierung

Abbildung 4: Service Ebenen des Cloud-Computing mit Produktbeispielen

Abbildung 5: Service Ebenen des Cloud-Computing

Abbildung 6: vereinfachte Darstellung des SAP-ERP HCM Systems

Abbildung 7: vereinfachte Darstellung der On-Premise Web Applikation (Prod)

Tabellenverzeichnis

Tabelle 1: Schutzstufenkonzept des Landes Niedersachsen

Tabelle 2: Schutzbedarfskategorien

Tabelle 3: Punktebereich der Potentialanalyse

Tabelle 4: Machbarkeits- und Potentialanalyse des SAP ERP Systems

Tabelle 5: Machbarkeits- und Potentialanalyse der Web-Shop Applikation

1. Einleitung

1.1 Motivation und Zielsetzung

Cloud-Computing hat sich in den letzten Jahren von einem Hype-Thema zu einer ernsthaften Sourcing-Methode entwickelt, mit der IT-Leistungen angeboten werden. Das belegen die Zahlen der KPMG „Cloud Monitor“ Studie von 2015, da demzufolge 44% der Unternehmen in Deutschland Cloud-Computing einsetzen.[1]

Zum einen liegt das am stetig steigenden Produktportfolio vorgefertigter Services, zum anderen am Ausbau potentieller Cloud-Standorte bei gleichzeitiger Reduzierung der Preise. IT-Unternehmen hingegen sind durch Kostendruck und weniger Personal gezwungen wachsende Leistungsanforderungen und anspruchsvolle Dienstleistungen abzubilden.[2] Mit Hilfe der Nutzung von Cloud-Services können hohe Investitionskosten vermieden und unendliche Ressourcen beansprucht werden. Des Weiteren werden Komplexitäten reduziert und zugleich Mitarbeiteraufwände eingespart, indem fertige Cloud-Services genutzt werden können. Durch die Eigenschaften der Cloud flexibel beliebig viele Ressourcen zu reservieren, zu beanspruchen und wieder freizugeben entstehen neue Anwendungsbereiche. Beispielsweise können temporär große Datenmengen analysiert oder zeitlich begrenzte Testumgebungen bereitgestellt werden. Mit Hilfe der global verteilten Rechenzentren eines Cloud-Anbieters ist es möglich IT-Services weltweit für Kunden zur Verfügung zu stellen.

In der Fachliteratur vergleichen einige Autoren das Thema Cloud-Computing mit Strom, den man auch nach Bedarf nutzen kann.[3] Andere Eigenschaften, wie die nutzungsbasierte Abrechnung oder die Reduzierung von Komplexität unterstützen den Vergleich. Der Stromnutzer muss ebenso wenig über die Stromerzeugung wissen, wie der Cloud Nutzer über die Entstehung seines Cloud Services. Er nutzt ihn genau dann und genau dort, wo er sich gerade befindet und eine Steckdose verfügbar ist.

Heutige IT-Unternehmen stehen stetig vor der Herausforderung, neue Technologien aufzunehmen, zu bewerten und auf ihre eigene Struktur umzusetzen.[4] Auch beim Thema Cloud-Computing ist zu bewerten welcher Workload für die Cloud geeignet ist. Die Entscheidung, ob eine Anwendung in die Cloud migriert werden kann, hängt von verschiedenen Faktoren ab. Die Beurteilung von Faktoren aus den Bereichen Datenschutz, Informationssicherheit, Netzwerk, Ressourcen und Lizenzen bestimmen maßgeblich ob eine Anwendung in die Cloud zu migrieren ist.

Das Interesse besteht nun ein Modell zu entwickeln, mit dem eine Anwendung hinsichtlich ihrer Eignung für den Betrieb in einer Cloud überprüft werden kann. Konkrete Fragestellungen sind u.a.:

- Durch welche Kriterien lässt sich feststellen, ob eine Anwendung in der Cloud lauffähig ist oder nicht?
- Welche Anwendungseigenschaften verhindern eine Migration in die Cloud?
- Durch welche Kriterien lassen sich erhöhte Migrationsaufwände ableiten?
- Welche datenschutzrechtlichen Kriterien sind bei einer Anwendungsmigration in die Cloud zu beachten?

Bei der Beantwortung der Forschungsfragen wird sich die Bachelor-Thesis auf allgemeine, Cloud-Provider unabhängige Kriterien fokussieren. Kostenaspekte oder strategische Ausrichtungen der Anwendungsbetreibenden Unternehmen (z.B. Migration des kompletten Rechenzentrums in die Cloud) werden nicht berücksichtigt. Weitere übergreifende Themen, zum Beispiel die Cloud-Infrastruktur und deren Prozessintegration, sowie die vertraglichen Regelungen mit dem Cloud Provider sind ebenfalls nicht Bestandteil dieser Arbeit.

Die Bachelor-Thesis richtet sich an IT-Infrastruktur Architekten oder interessierten Lesern, die sich näher mit der Thematik des Cloud-Computings befassen möchten.

1.2 Aufbau der Arbeit

Die Arbeit beginnt zunächst mit der Beschreibung der theoretischen Grundlagen, die für das Verständnis der Arbeit notwendig sind. Zunächst wird dabei auf Cloud-Computing eingegangen indem Definitionen und Eigenschaften erläutert werden. Anschließend werden die Cloud Basistechnologien, Virtualisierung, Serviceorientierte Architekturen (SOA) und Web Services vorgestellt. Das Kapitel schließt mit den Themen Cloud Service-Ebenen und Organisationsformen der Cloud ab.

Das darauf folgende Kapitel „Anforderungen an Applikationen für den Betrieb in der Cloud“ behandelt die Identifikation möglicher Entscheidungskriterien zur Bestimmung einer Cloud-Tauglichkeit. Mit Hilfe einer Analyse der Fachliteratur werden zunächst Kriterien aus den bereits identifizierten Bereichen Anwendungsdesigns, Datenbanken, Server, Netzwerk sowie Datenschutz und Informationssicherheit diskutiert. Im Anschluss werden diese Kriterien mit Hilfe von Experten validiert und weitere Kriterien bestimmt. Hierzu wird die Methode des Experteninterviews auf die Problemstellung angewendet.

Kapitel 4 „Bewertung der Cloud Fähigkeit von Applikations-landschaften“ behandelt die Transformation der identifizierten Kriterien in eine Potential- und Machbarkeitsanalyse. Das erarbeitete Ergebnis wird im Anschluss anhand von zwei Beispielapplikationen überprüft.

Im abschließenden Kapitel wird die Arbeit reflektiert und die Ergebnisse der Arbeit gegenüber den definierten Forschungsfragen kritisch diskutiert. Zuletzt wird ein Ausblick auf weiteren Forschungsbedarf gegeben.

2. Theoretische Grundlagen des Cloud-Computing

2.1 Definition und Eigenschaften von Cloud-Computing

Trotz verbreitetem Nutzen des Cloud Begriffs gibt es keine einheitlich anerkannte Definition von Cloud-Computing.[5] Daher werden im folgenden Abschnitt verschiedene Definitionsansätze und Eigenschaften über Cloud-Computing dargelegt. Die von wissenschaftlichen Arbeiten am meisten zitierte Quelle ist die des NIST. Das National Institute of Standards and Technology ist als Bundesbehörde der Vereinigten Staaten von Amerika für die Beschreibung von Standards und Normen zuständig. Die Behörde definiert Cloud-Computing wie folgt:

„Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.“[6]

Aus der Definition des NIST geht indirekt hervor, dass Cloud-Computing die Mechanismen der Virtualisierung und das Internet als Basistechnologie nutzt, um Dienste dynamisch bereit zu stellen.[7] Nach Baun u. a. (2010) ist auch die nutzungsabhängige Abrechnung der Dienste ein Definitionsmerkmal von Cloud-Computing, daher lautet seine Definition folgendermaßen:

„Unter Ausnutzung virtualisierter Rechen- und Speicherressourcen und moderner Web-Technologien stellt Cloud-Computing skalierbare, netzwerk-zentrierte, abstrahierte IT-Infrastrukturen, Plattformen und Anwendungen als on-demand Dienste zur Verfügung. Die Abrechnung dieser Dienste erfolgt nutzungsabhängig.“[8]

Offen bleibt bei dieser Definition und auch bei der des NIST, wie die physikalische Infrastruktur unterhalb der Virtualiserungsebene aussieht. Es kommen zwei Möglichkeiten in Frage. Zum einen kann die Virtualisierung auf einem einzelnen, leistungsstarken System stattfinden, zum anderen auf einem verteilten Rechnersystem.[9] Aufgrund geringerer Anschaffungs- und Wartungskosten werden heutzutage fast ausschließlich verteilte Rechnersysteme eingesetzt.

Bereits 1964 wurde das Cloud-Computing Konzept von Martin Greenberger, einem Professor an der School of Industrial Management des Massachusetts Institute of Technology (MIT), im Artikel “The Computer of Tomorrow” erwähnt. Greenberger (1964) ahnte bereits damals, dass die starke Verbreitung von Computern nicht mehr zu stoppen ist und jeglichen „…sector of American life, .. into homes, offices, classrooms, laboratories, factories, and businesses of all kinds.“ erreiche. Er sah außerdem bereits Parallelen beim Konsumieren von Strom und Rechenleistung.[10] Strom ist ein homogenes Produkt, welches zentral hergestellt wird, und in beliebiger Menge von mehreren Konsumenten genutzt werden kann. Laut Greenbergs Vorstellungen wird es in der Zukunft ein sogenanntes „Information Utility“ geben, welches IT-Dienste für mehrere Nutzer anbietet. Aus den damaligen Überlegungen entstand das derzeitige Cloud-Computing, welches sich sowohl im Privat- als auch im Unternehmensbereich durchgesetzt hat.[11]

Durch das NIST werden fünf charakteristische Merkmale (siehe Abbildung 1) von Cloud-Computing beschrieben:

- Self-Service: Der Cloud Benutzer kann Ressourcen, wie Rechenleistung oder Speicherplatz, nach aktuellem Bedarf automatisiert bereitstellen lassen und nutzen, ohne mit dem Provider in Verbindung treten zu müssen.
- Zugriff über Netzwerk: Die Ressourcen sind über Netzwerk anhand von standardisierten Schnittstellen mit diversen Endgeräten erreichbar.
- Ressourcen-Poolbildung: Es existieren Hardwareressourcen, welche in Ressourcen-Pools zusammengefasst werden. Die Kapazitäten eines Pools werden gleichzeitig mehreren Benutzern zur Verfügung gestellt. Die Ressourcen werden dabei dynamisch zugeordnet.
- Skalierbarkeit und Flexibilität: Die Elastizität der Skalierbarkeit ist enorm hoch, sodass der Benutzer in sehr kurzer Zeit sehr viel Rechenleistung anfordern kann. Die Ressourcen können dabei zu jeder Zeit und über jede beliebige Dauer angefragt werden.
- Pay per use: Es existieren automatisierte Kontroll-, Mess- und Steuerungsmechanismen, die eine transparente und leistungsgerechte Abrechnung der in Anspruch genommenen Ressourcen ermöglichen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Abbildung nach Mell/Grance (2011)

Abbildung 1: Charakteristische Merkmale des Cloud-Computings[12]

In den 1990er Jahren beschrieb Eric Schmidt, Chief Technology Officier bei SUN Microsystems, den zukünftigen Computer in der Cloud. Der Begriff Cloud-Computing war geboren und sollte zukünftig vor allem als Marketingbegriff dienen. Der Ausdruck Cloud-Computing ist keineswegs einer, der von einer neuen Technologie geprägt wurde.[13] Vielmehr waren verschiedene Faktoren notwendig, um die heutige Cloud entstehen zu lassen. Cloud-Computing nutzt Basistechnologien, wie Virtualisierung, Internet-Technologie (Web Services, SOA, Web 2.0), verteiltes Computing (Cluster, Grids), sowie System Management (Automatisierung). Im Folgenden werden diese Basistechnologien kurz vorgestellt und voneinander abgegrenzt.

2.2 Cloud Technologien

2.2.1 Virtualisierung

Den Anfang der Virtualisierung läutete in den 1960er Jahren IBM ein.[14] Mit der Entwicklung eines Mainframes, dem Virtual Machine Facility/370, kurz VM/370 konnten Ressourcen auf mehrere Instanzen aufgeteilt werden und ermöglichten somit einen Mehrbenutzerbetrieb.[15] Doch nicht nur die Servervirtualisierung, sondern auch die Applikations-, Speicher- und Netzwerkvirtualisierung und das Management virtualisierter IT-Infrastruktur entwickelten sich zu bedeutenden Technologien in der IT-Branche.[16]

Die Vorteile der Virtualisierungstechnologie überwiegen klar die Nachteile. Durch die Abbildung von Anwendungen auf virtualisierter Hardware können ganze Applikationslandschaften auf wenige physikalische Server konsolidiert werden.[17] Aufgrund dessen steigt die Auslastung der Hardware und damit ihre Effizienz. Die Einsparung von physikalischen Systemen wiederum reduzieren den Energieverbrauch im Rechenzentrum. Dadurch lassen sich Energiekosten für den laufenden Betrieb, sowie für die Kühlung verringern.[18] Durch die Bereitstellung erhöhter Leistung auf weniger Fläche werden Rechenzentrumsflächen effizienter genutzt. Im Bereich der Administration helfen automatisierte Provisionierungsprozesse Ressourcen dynamisch auf den Bedarf des Kunden zuzuschneiden. Da VMs innerhalb ihrer Ressourcenpools flexibel und ohne Downtime verschoben werden können, ist die Abbildung von Service Level Agreements (SLA) mit hohen Verfügbarkeiten problemlos umsetzbar.[19] Auch Hardwaredefekte mit daraus resultierenden Systemausfällen können mit Hilfe der Virtualisierung besser abgefangen werden. Ferner verschafft sie dem Betreuer der Infrastruktur Wartungsfenster, die nicht mit dem Kunden abgestimmt werden müssen.

Nachteile sind bei der Virtualisierung nur schwer zu finden. Zum einen wird der erhöhte Ressourcenverbrauch für die Virtualisierungsschicht angeführt.[20] Zum anderen müssen mehr Systeme betreut und verwaltet werden als im reinen physikalischen Umfeld. Da heutzutage jedoch Management-Tools die Verwaltung der Ressourcen vereinfachen, fällt kein erhöhter Personalbedarf an.[21]

Hardwarevirtualisierung

Grundsätzlich bezeichnet Hardwarevirtualisierung die Abbildung von vielen virtuellen Maschinen auf ein physikalisches System. Eine VM besteht dabei aus Software die Ressourcen, wie CPU oder RAM nachbildet. Zusätzlich werden Zugriffe auf Netzwerk- und Speicherressourcen eingerichtet. Die VM ist ein isoliertes, abgeschlossenes System, welches sich wie eine normale physikalische Maschine verhält. Die Hardwarevirtualisierung wird in zwei Technologievarianten, Hosted und Bare Metal Virtualisierung unterteilt (s. Abbildung 2). Der grundlegende Unterschied ist, dass die Virtualisierungsschicht bei der Bare Metal Variante direkt auf der Hardware aufsetzt, anstatt als Applikation im Betriebssystem. Durch den Einsatz eines minimalen Metabetriebssystems, dem sogenannten Hypervisor, lassen sich im Bare Metal virtualisiertem Umfeld Performancevorteile gegenüber der Hosted-Variante erzielen. Nachteilig ist jedoch die Abhängigkeit von der Hardware, da die Unterstützung von kompatiblen Treibern gegeben sein muss. Die Flexibilität ist beim betriebssystembasiertem Virtualisieren höher, da die Softwareprodukte (z.B. VMware Workstation[22], Hyper-V[23], VirtualBox[24], uvm.) nur auf das Betriebssystem zugeschnitten sein müssen und damit unabhängig von der darunterliegenden Hardware sind. Die Hosted Virtual Machine Monitor Virtualisierungslösung ist im Desktopumfeld, die Bare Metal Virtualisierung hingegen im Serverumfeld, stark verbreitet.[25]

Abbildung in dieser Leseprobe nicht enthalten

a) Bare Metal Hypervisor b) Hosted Virtual Machine Monitor

Quelle: Eigene Abbildung nach Meinel u. a. (2011)

Abbildung 2: Vergleich Bare Metal Hypervisor und Hosted Machine Monitor[26]

Applikationsvirtualisierung

Eine weitere Form der Virtualisierung stellt die Applikationsvirtualisierung dar. Ziel ist, es Applikationen in virtuelle Hüllen / Kapseln zu packen und sie dadurch von Programmen und dem Betriebssystem zu entkoppeln.[27] Demzufolge wird eine einfache Verwaltung von Applikationen erzielt, da z.B. ein zentrales Update- und Patchmanagement durchgeführt werden kann.[28] Weitere Vorteile liegen in der Kompatibilität, da jeder Nutzer mit demselben Softwarestand arbeitet. Der Sicherheitsaspekt ist weiterhin positiv zu bewerten, da keinerlei Anwendungen oder Daten das unternehmenseigene Rechenzentrum verlassen. Die Bereitstellung der Anwendungen selbst kann anhand von zwei unterschiedlichen Methoden ablaufen. Die Anwendung selbst kann auf einem Streaming-Server installiert werden und direkt aus dem Internet via Streaming-Protokoll abgerufen werden. Diese Form der Bereitstellung wird von Baun u. a. als Hosted Application bezeichnet, Vogel/Koçoğlu/Berger nennt sie Online-Virtualisierung. Die zweite Methode erlaubt es, die komplette virtuelle Appliance herunterzuladen.[29] Demzufolge kann der Nutzer auch offline seine Anwendung ausführen, da dazugehörige Komponenten und Dateien als Zwischenspeicher lokal bereitstehen.

Desktopvirtualisierung

Eine weiterentwickelte Form der Applikationsvirtualisierung stellt die Desktopvirtualisierung (kurz VDI – Virtual Desktop Infrastructure) dar. Hierbei wird der komplette Desktop, inklusive Anwendungen und Benutzereinstellungen, virtuell abgebildet.[30] Auf dem PC, Smartphone oder Thin Client des Benutzers sorgt ein Installationspaket des VDI Herstellers für das Verbinden und die Kommunikation mit dem virtuellen Desktop. Der User greift über das Netzwerk auf diese Ressourcen zu und bekommt die Bildschirmausgabe angezeigt. Tastatur und Mauseingaben werden über das Netzwerk zum Desktop geleitet. Die Authentifizierung erfolgt an einem sogenannten Connection Broker.[31] Diese Komponente kennt alle zugelassenen Benutzer und deren Zuordnungen zu den jeweiligen virtuellen Systemen. Ein virtueller Desktop kann aus einem Pool entnommen und genutzt werden.[32] Dann handelt es sich um einen sehr standardisierten Computer mit vorinstallierten Standardanwendungen wie Microsoft Office oder den Adobe Reader. Benutzereinstellungen werden gespeichert und sind bei der nächsten Einwahl wieder verfügbar. Eine Installation von zusätzlichen Anwendungen ist nicht möglich, da alle Desktops im Pool gleich aufgebaut sein müssen. Bei Anwendern, die Spezialsoftware nutzen, ist jedoch auch eine persönliche Zuordnung möglich, sodass individuelle Installationen möglich sind.

Netzwerkvirtualisierung

Nicht nur Applikationen oder Hardware können virtuell abgebildet werden, sondern das Netzwerk ist ebenfalls ein Anwendungsbereich der Virtualisierung. Auch bei dieser Art der Virtualisierung werden physikalische Netzwerkressourcen logisch abgebildet und verwaltet. Ein lokales Netz (LAN) kann somit aus mehreren logischen Netzen (VLAN) zusammengesetzt sein. Dadurch können VLANs voneinander isoliert werden, sodass diese nicht miteinander kommunizieren können. Bei der Servervirtualisierung können virtuelle Netzwerkkarten der jeweiligen VMs den VLANs zugeordnet werden, ohne dass physische Verkabelungen stattfinden müssen (siehe Abbildung 3).

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Abbildung nach Runge u. a. (2009)

Abbildung 3: Abbildung von virtuellen Netzen bei der Servervirtualisierung[33]

Die verschiedenen VLANs werden von einem VLAN-fähigen Router verwaltet. Dieser nutzt LAN-Switching (auch Statisches VLAN genannt) oder virtuelles Routing, um die IP-Adressen der jeweiligen Zonen zu vergeben.[34] Die Vorteile der Netzwerkvirtualisierung entsprechen denen der anderen Virtualisierungsrechnologien. Auch hier werden physikalische Ressourcen besser ausgenutzt, Bereitstellungszeiten verkürzt und der Administrationsaufwand reduziert.

Speichervirtualisierung

Auch im Bereich der Storagesysteme findet die Virtualisierung Anwendung. Die Grundidee besteht darin, den physikalischen Speicher in Pools zusammenzufassen und diesen dynamisch den Anwendungssystemen zuzuweisen.[35] Es existieren zwei unterschiedliche Typen der Speichervirtualisierung, die jedoch auch kombiniert einsetzbar sind. Die Technologie Network Attached Storage (NAS) bindet verschiedene Fileserver über das LAN ein.[36] Mit Hilfe von Redundant Array of Independent Disks (RAID) werden Redundanzen erstellt, um Plattenausfälle vorzubeugen.

Im Enterprise-Umfeld wird der Datentransfer über dedizierte Hochleistungsnetze, dem sogenannten SAN (Storage Area Network) abgebildet. Über das SAN, welches im Normalfall mit FibreChannel (Glasfasernetz) ausgestattet ist, lassen sich außerdem Datenbanken und Bandlaufwerke in Tape Libraries anbinden. Durch Speichervirtualisierung wird der Einsatz unterschiedlicher Storagesysteme verschiedener Hersteller ermöglicht.[37] Die daraus entstehenden Pools werden nach Kategorien eingeteilt (Tier-Konzept), welche verschiedene Anforderungen hinsichtlich Verfügbarkeit und Bandbreite abbilden. Ein weiterer Vorteil wird bei der Administration ersichtlich. Storage-Virtualisierungslösungen bieten Werkzeuge, mit denen das Erstellen von Snapshots, das Clonen von Speicherbereichen, Migrationshilfen (online Migrationen), Spiegelungen oder die Aufrechterhaltung einer Disaster-Recovery-Site ermöglicht wird.[38] Der Schulungsaufwand der Mitarbeiter wird verringert, da es ein einheitliches und vereinfachtes Bedienkonzept existiert.

2.2.2 Serviceorientierte Architekturen

Eine Serviceorientierte Architektur (kurz SOA) ist ein abstraktes Modell, dass für den Bereich Cloud-Computing Grundvoraussetzung ist.[39] Eine technische Umsetzung wird im Kapitel 2.2.3 anhand von Web Services erläutert. Eine geläufige und nachvollziehbare Definition zu SOA kann nach Heutschi wie folgt zitiert werden:

„Eine SOA ist eine mehrschichtige, verteilte Informationssystem (IS)-Architektur, die Teile von Applikationen für eine vereinfachte Prozessintegration als geschäftsorientierte Services kapselt und dabei bestimmte Designprinzipien berücksichtigt.“[40]

Durch SOA werden also verschiedene Basisdienste zu neuen, übergeordneten Diensten zusammengefasst, den sogenannten Services. Ein Service definiert Heutschi wie folgt:

„Ein Service stellt ein abstraktes Software-Element bzw. eine Schnittstelle dar, die anderen Applikationen über ein Netzwerk einen standardisierten Zugriff auf Anwendungsfunktionen anbietet“[41]

Nutzer der Services können nicht nur die Kunden direkt, sondern auch andere Applikationen sein. Im Cloud Kontext werden virtuelle Infrastrukturen, Plattformen oder Applikationen als Dienste bereitgestellt.[42] Vorteile der SOA liegen vor allem im Flexibilitätsgewinn, da Anwendungsteile durch andere ersetzt werden können.[43] Weitere Merkmale finden sich in der losen Kopplung, d.h. erst zur Laufzeit des Programms wird der nächste Dienst gesucht, gefunden und eingebunden.[44] Die Komplexität von Anwendungen mit einer Vielzahl von Schnittstellen wird auf ein Minimum an Schnittstellen reduziert. Die Nutzung von offenen Kommunikationsstandards ist erforderlich, um die Kommunikation mit einem Dienst eines unbekannten Anbieters zu gewährleisten.[45] Weiterhin bleiben die verschiedenen internen Daten-, Funktions- und Prozessmodelle innerhalb eines Services verborgen.[46] Dadurch gelingt es, Dienste in Geschäftsprozesse einzubinden.

2.2.3 Web Services

Während SOA nur ein abstraktes Model darstellt, sind Web Services eine konkrete technische Abbildung dessen. Eine Definition liefert die Web Services Architektur Arbeitsgruppe des World Wide Web Consortium:

“Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte Interaktion mit anderen Softwareagenten durch XML-basierte Nachrichten, die über Internetprotokolle ausgetauscht werden.“[47]

In der Definition finden sich die drei grundlegenden Komponenten einer SOA wieder. Die erste Komponente, der Verzeichnisdienst, sorgt dafür, dass Web Services anhand einer eindeutigen ID, der Uniform Resource Identifier (URI), erfasst werden. Wie die Struktur festgelegt wird, beschreibt die Spezifikation UDDI (Universal Description, Discovery and Integration Protocol). In der Praxis wird der Verzeichnisdienst selten verwendet, da er erhöhten Verwaltungsaufwand bedeutet und bei bekannten Services keine Notwendigkeit für ihn besteht.[48]

Bei der zweiten Komponente der Definition handelt es sich um die Beschreibung der Schnittstelle eines Web Services. Dafür wird eine XML basierte Sprache genutzt, die als Web Services Description Language (WSDL) spezifiziert wird. Für die Kommunikation wird als dritte Komponente ein Messaging Protokoll benötigt. Dieses ist ebenfalls XML basiert und als Simple Object Access Protocol (SOAP) bekannt. Eine weitere, einfach zu erlernende Alternativlösung stellt neben SOAP XML-RPC dar.[49] Im Zusammenhang mit Web Services fällt oftmals der Begriff REST. Bei einem Representational State Transfer (REST) handelt es sich um einen Architekturstil und kein eigenes Protokoll. Bestehende Web Protokolle, wie HTTP, werden verwendet, um Web Services aufzurufen. Während SOAP vom Transportmedium unabhängig ist, findet REST nur Anwendung bei Web Services im World Wide Web.[50] Die Aufrufe finden mit Hilfe einer URL statt, welche mittels einer HTTP-GET Operation an dem Webserver übermittelt wird.

2.3 Service Ebenen des Cloud-Computing

2.3.1 Infrastructure-as-a-Service (IaaS)

Im Allgemeinen hat sich die Einteilung der Cloud Services in drei verschiedene technische Bereiche durchgesetzt.[51] Alle Bereiche werden als virtualisierte IT-Dienste bereitgestellt und nutzungsabhängig abgerechnet.[52]

IaaS beschreibt die automatisierte Bereitstellung von Basisinfrastrukturservices. Diese bestehen aus Rechenleistung (Prozessorleistung), Datenspeicher (Storage) und Netzwerk. Der Nutzer kann selbstständig höherwertigere Services (z.B. Betriebssystem, Middleware oder Anwendungen) nutzen und ist damit verantwortlich für die Administration und dem Patchen des Servers, sowie den darauf befindlichen Anwendungen.[53]

Des Weiteren kann er den Server hoch-und herunterfahren, virtuelle Laufwerke hinzufügen oder Benutzerzugriffe, sowie Firewall-Regeln konfigurieren. Der Cloud-Provider garantiert SLAs, z.B. indem er physikalische Infrastrukturen redundant auslegt oder automatische Speicherreplikationen erstellt.

2.3.2 Platform-as-a-Service (PaaS)

Durch PaaS wird dem Nutzer eine komplette Infrastruktur zur Verfügung gestellt. Die unteren Schichten, wie Hardware und Betriebssystem, werden dabei vom Cloud-Provider verwaltet, der Benutzer hat keinen Zugriff auf diese Komponenten. Dem Nutzer ist es somit möglich, standardisierte oder individuelle Anwendungen auf der Plattform bereitzustellen, ohne sich mit der Serveradministration beschäftigen zu müssen. Er muss dabei aber vom Anbieter verwaltete Dienste, Bibliotheken oder Werkzeuge nutzen. Standardisierte Schnittstellen verhelfen dem Cloud-Nutzer Software-as-a-Service-Komponenten anzubinden. Typische Nutzer von Platform Services sind nicht die Endkunden, sondern System-Architekten und Anwendungsentwickler.[54] Für die Datenspeicherung werden meist Cloud Providerspezifische Datenbanken genutzt, die eine Portierung zu einem anderen Cloud Anbieter oder ins eigene Rechenzentrum erschweren.[55]

2.3.3 Software-as-a-Service (SaaS)

SaaS, die dritte Form der Bereitstellung von Cloud Services, befasst sich mit dem Anbieten von Anwendungen über das Internet. Hard- und Software (Lizenzen), Wartung und Betrieb sind dabei in der Servicegebühr enthalten. Der Nutzer hat keine Kontrolle über die Anwendung, da diese komplett vom CSP (Cloud Service Provider) gemanagt wird. Der Anwender kann somit keine individuellen Anpassungen an der Anwendung durchführen.

Außerdem werden Entwicklungs- und Wartungsarbeiten unter Verantwortung des CSPs anhand seiner definierten Prozesse durchgeführt.[56] Sämtliche Nutzer greifen auf eine durch verschiedene Mandanten separierte Anwendungsumgebung zu.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Abbildung nach BITKOM (2009)

Abbildung 4: Service Ebenen des Cloud-Computing mit Produktbeispielen[57]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Abbildung nach Alberto, D., Baker, J., Cornellier, J. ,Hamel, J. u. a. (2015)

Abbildung 5: Service Ebenen des Cloud-Computing[58]

2.4 Organisationsformen des Cloud-Computing

2.4.1 Private Cloud

Aufgrund von verschiedenen Betriebs-, Eigentums- und Organisationsaspekten können Cloud-Services in verschiedenen Organisationsformen bereitgestellt werden. Bei einer Private Cloud werden alle Cloud-Services vom Kunden selbst betrieben und genutzt. Dabei erfolgt der Zugriff über das Intranet des Unternehmens oder über ein Virtual Private Network (VPN).[59] Der Betreiber der Cloud muss nicht zwingend der Eigentümer des Rechenzentrums, sowie der Hardware sein. Er kann die Ressourcen auch extern anmieten.[60] Die Haupteigenschaft einer Private Cloud stellt sich in der alleinigen Nutzung und Kontrolle einer Cloud-Umgebung heraus. Da die Services nur innerhalb des Unternehmens bereitgestellt werden, können unternehmensspezifische Security und Compliance Anforderungen umgesetzt werden. Aufgrund dessen können sensible Daten (z.B. personenbezogene Daten, Konstruktionspläne) besser geschützt werden.[61] Die Möglichkeiten nahezu unendlich hohe Skalierungen und kurze Peaks abzubilden, sind im Private Cloud Modell sehr eingeschränkt, da im Vergleich zu einem Public Cloud Provider nur wenig freie Hardwareressourcen zur Verfügung stehen. Die technische Umsetzung der eigenen Cloud-Services erfolgt mit dem Vorbild eines Public Cloud Providers. Automatisierte und standardisierte Cloud-Services sollen mit Hilfe von standardisierten Schnittstellen in die Lage versetzt werden in Public Clouds skalieren zu können (vgl. Hybrid Cloud). Das Abrechnungsmodell ist im Gegensatz zur Public Cloud nicht als pay-as-you-go Modell umgesetzt. Kosten werden beispielsweise auf Abteilungsebene verrechnet.

2.4.2 Public Cloud

Die Public Cloud befindet sich „off-premise“, d.h. dass die angebotenen Services nicht im eigenen Unternehmen gehostet werden. Ein Cloud-Betreiber stellt standardisierte, virtualisierte und multimandatenfähige Services über ein öffentliches Netz zur Verfügung. Dabei bleibt der Betreiber stets Eigentümer der physikalischen Hardware. Individuelle Anpassungen sind nicht oder nur eingeschränkt möglich, da der Cloud-Anbieter nur anhand von standardisierten Services und automatischen Provisionierungsprozessen entsprechende Skalierungen, und Effizienzsteigerungen erzielen kann.[62] Dadurch ist es ihm möglich kostengünstige stunden- oder auch minutengenaue Pay-Per-Use Kostenmodelle anzubieten.

2.4.3 Hybrid Cloud

Die Hybrid Cloud stellt eine Kombination aus Private und Public Cloud dar. Inkludiert sind dabei jedoch auch nicht cloudfähige Applikationen (Legacy IT Systeme), die mittels Schnittstellen an Cloud-Services angebunden sein können. Die Herausforderung des Modells ist die Möglichkeit der transparenten Servicebereitstellung aus beiden Cloud Modellen. Der Anwender erwartet eine homogene Darstellung der abgebildeten Geschäftsprozesse unabhängig vom Cloud-Betreibermodell.

3. Anforderungen an Applikationen für den Betrieb in der Cloud

3.1 Cloud Applikationsdesign

In den theoretischen Grundlagen wurden u.a. die drei Service Ebenen IaaS. PaaS und SaaS erläutert. Die Herausforderung des IT-Anwendungsarchitekten besteht nun darin das Service Portfolio des Cloud Anbieters für die Abbildung der Anwendung zu nutzen. Doch nicht nur passende Services sind auszuwählen, auch auf die von der Anwendung benötigten Kapazitäten ist zu achten. Sowohl bei IaaS als auch bei PaaS und SaaS Diensten limitiert der Cloud Provider z.B. Rechen-, Speicherressourcen oder die Anzahl an zuzuordnenden Serverinstanzen.

Ein Public Cloud Anbieter stellt Services aus seinen global verteilten Rechenzentrumsregionen über das öffentliche Netzwerk bereit. Näher an den Kunden gelegene IT-Ressourcen weisen geringere Reaktionszeiten auf, als weit entfernte Netzpunkte.[63] Anwendungen, die auf schnelle Reaktionszeiten angewiesen sind, werden somit nicht für die Public Cloud empfohlen. Neben den Antwortzeiten, zählen auch die Bandbreite und die Anzahl an Übertragungsfehlern zu berücksichtigende Messgrößen.

Im Gegensatz zu on-premise Anwendungen mit homogenen Rechnerverbünden können in der Cloud verschiedenartige heterogene Ressourcen eingesetzt werden.[64] Eine Anwendung sollte daher so konzipiert sein, dass sie diese Ressourcen über Web Services ansprechen kann. Aufgrund der globalen Verteilung der Services sollte für die Kommunikation eine schwach gekoppelte, asynchrone und nachrichtenbasierte Kommunikation eingesetzt werden.[65]

Durch die Realisierung von kompletten Anwendungen als SaaS oder PaaS Diensten können einige Vorteile gegenüber der Nutzung von klassischen IaaS Diensten erzielt werden. Cloud Provider bieten Software Herstellern die Möglichkeit Ihre Produkte in Form von Services im Marketplace anzubieten. Die Abrechnung, sowie mögliche Lizensierungen werden ebenso über die Dienste direkt abgebildet. Durch die Nutzung von Mietlizenzen können im Gegensatz zum Kauf Lizenzgebühren flexibel an die Nutzung angepasst werden. Hohe Anschaffungskosten fallen dann nicht mehr an. Ein weiterer Vorteil durch die Nutzung von Software Abonnements oder Subscription-Lizenzen ist die Nutzung einer stets aktuellen Softwareplattform.[66] Klassische Lizenzmodelle bieten oftmals bei einem Software Versionsupdate keine Möglichkeit der weiteren Nutzung.

Lizenzmodelle, die auf die Anzahl der physikalischen Server oder der CPUs in einem Server basieren, sind in der Cloud aufgrund der Servervirtualisierung nicht umsetzbar. Daher kann eine Lizensierung nur anhand von installierten Betriebssystem- oder Applikationsinstanzen stattfinden.[67] Da noch nicht alle Software Hersteller Lizenzmodelle für die Cloud anbieten, können oft Entscheidungen bei der Migration in die Cloud negativ ausfallen.[68]

Die Nutzung von Plattform Diensten hat noch einen weiteren Vorteil. Die wie von der NIST beschriebene Eigenschaft der flexiblen Skalierbarkeit wird durch eine automatisierte Anpassung der Ressourcen bei steigenden oder sinkenden Bedarfen realisiert:[69]

- Vertikale Skalierung (scale up): Rechenleistung (CPU, RAM) wird erhöht
- Horizontale Skalierung (scale out): gleichwertige Serverkapazitäten werden dem Applikationsverbund hinzugefügt

Ob eine Applikation skaliert, und damit Eigenschaften der Cloud nutzen kann, wird anhand ihres Lastverhaltens festgestellt. Ein hoher Workload entsteht z.B., wenn viele Benutzer auf eine Web Applikation zugreifen oder Server eine Menge an Daten verarbeiten müssen.[70] Die verschiedenen Lastverhalten werden im Folgenden vorgestellt.

Statisches Lastverhalten

Eine Anwendung weist statisches Lastverhalten auf, wenn während einer bestimmten Laufzeit, z.B. innerhalb eines Jahres, keine zusätzlichen Ressourcen beansprucht werden. Applikationen die einen statischen Workload aufweisen, können die Eigenschaft der flexiblen Skalierung in der Cloud nicht nutzen und können dadurch auch nicht durch den „Pay-per Use“-Ansatz profitieren.[71]

Periodisches Lastverhalten

Geprägt ist dieses Verhalten durch regelmäßig auftretende Lastspitzen. Diese können beispielsweise aus monatlichen Abrechnungsabläufen (Batch-Verarbeitung) resultieren. Mit Hilfe der flexiblen Skalierung in der Cloud können Ressourcen bei Lastspitzen erweitert und danach wieder freigegeben werden. Im Gegensatz zur statischen Skalierung, bei der der Kunde auch die Ressourcen zahlt, die er nicht nutzt, kann er hingegen in der Cloud durch die stundengenaue Abrechnung entsprechende Kosten sparen.[72]

Einmalige Last

Dieses Lastverhalten zeichnet sich durch einen einmaligen Peak während der gesamten Lebenszeit der Applikation aus. Mit Hilfe der flexiblen Skalierung kann dieser kurzzeitige Ressourcenbedarf abgefangen werden. Der Peak kann auch durch eine manuelle Erweiterung abgefedert werden, falls die Anwendung keine automatische Anpassung der Ressourcen unterstützt oder der Aufwand für die Anpassung der Anwendung zu hoch ist.[73]

Unberechenbares Lastverhalten

Unberechenbare Lastverhalten sind vergleichbar mit denen des periodischen und benötigen ebenso die Funktionalität der flexiblen Skalierung. Auch hierbei muss die Anwendung die Erweiterung und Reduzierung von Ressourcen unterstützen.[74]

Stetiges steigendes/fallendes Lastverhalten

Auslöser von stetig steigenden Workloads kann z.B. wirtschaftliches Wachstum mit einem wachsenden Kundenstamm sein. Stetig sinkende Lastverhalten können von älteren Applikation ausgelöst werden, wenn einige User zu bereits neueren Applikationen gewechselt haben.[75]

Das Design einer Applikation muss dafür ausgelegt sein, horizontal skalieren zu können.[76] Ohne eine horizontale Skalierung kann keine Hochverfügbarkeit abgebildet werden, da nur eine einzelne Instanz betrieben werden kann und somit der einzelne Server zum SPOF (Single Point of Failure) wird. Des Weiteren ist die Gefahr gegeben, dass z.B. eine erhöhte Nutzerlast einen Webserver an seine Kapazitätsgrenze bringt und somit die Webseite nicht verfügbar ist.

Ein weiterer wichtiger Schritt in Richtung Cloud-Readiness ist die zustandslose (stateless) Applikationsprogrammierung. Der Unterschied zur zustandsbehafteten Variante ist, dass sämtliche Informationen zu vorhergehenden Anfragen oder Antworten nicht auf dem Server, sondern auf dem Client-PC gespeichert werden.[77]

Durch diese Art der Programmierung gelingt es die Applikationslogik von der Infrastruktur zu entkoppeln. Für die am Anfang dieses Kapitels erwähnte Skalierung ist die zustandslose Applikationsprogrammierung eine Grundvoraussetzung. Positiv zu bewerten ist außerdem, dass bei einem Serverausfall keine Daten verloren gehen. Die Aufwände für eine Änderung der Zustandslogik in einer Applikation schätzt Kavis als sehr hoch ein.[78] In der Praxis ist eine komplette Ablösung der Applikation gängig.

3.2 Cloud Server Bereitstellung

Die im vorhergehenden Kapitel gewonnenen Erkenntnisse im Bereich des Applikationsdesigns lassen einige Rückschlüsse auf die Serverbereitstellung in der Cloud zu. Um Applikationslandschaften nach Bedarf horizontal und vertikal skalieren zu können, ist es erforderlich einen automatisierten Bereitstellungsprozess in der Cloud zu implementieren. Die Möglichkeit der benutzerspezifischen Imageerstellung ist dafür Grundvoraussetzung. Das Maschinenimage enthält alle benötigten Programme in den entsprechend erfolgreich getesteten Versionen, sowie Client Programme für das Management der Maschine z.B. Monitoring und Patching oder Anti-Virus Tools. Sollten Änderungen an bereitgestellten Maschinen notwendig sein, so wird das Serverimage angepasst, getestet und die komplette Maschine automatisiert durch eine neue ersetzt.[79] Das Image sollte des Weiteren gehärtet werden. Beim Härten werden nicht genutzte Dienste entfernt. Alle Dienste werden statt mit dem Root Account mit einem Service Account ausgeführt und Berechtigungen soweit wie möglich eingeschränkt. Direkt nach der automatisierten Bereitstellung eines Servers bieten Cloud Anbieter die Möglichkeit weitere Skripte anzustoßen, die dann beispielsweise einen Cloud Storage anbinden.

3.3 Cloud-Netzwerk

Ein entscheidendes Element in der Cloud Architektur ist das Netzwerk. Entscheidend deshalb, weil der Zugriff auf die Public Cloud Ressourcen vorwiegend über das Internet erfolgt. Einige Cloud-Provider bieten die Möglichkeit, eine Verbindung via VPN herzustellen.[80] Der Vorteil dieses Tunnels ist die verschlüsselte Datenübertragung in die Cloud, der Nachteil die verringerte Performance. Um die Sicherheit in der Cloud zu erhöhen und sämtlichen Traffic aus dem Cloud-Rechenzentrum heraus zu verhindern, können sogenannte Virtual Private Clouds (VPC) eingerichtet werden. Diese bewirken auch eine Isolation untereinander, sodass diese funktional mit VLANs gleichzusetzen sind.

3.4 Datenschutz

Datenschutzrechtliche Aspekte haben, vor allem bei der Betrachtung Cloud-Dienste für den Betrieb einer Anwendung zu nutzen, eine große Bedeutung.[81] Eigenschaften einer Public Cloud, wie die lokale Unabhängigkeit von bereitgestellten Diensten, erlauben das flexible, weltweite Verschieben von Anwendungen. Aus Sicht des Datenschutzes ergeben sich dadurch viele Fragestellungen bezüglich der internationalen Zuständigkeit und des anwendbaren Rechts.[82] Im folgenden Abschnitt werden die rechtlichen Rahmenbedingungen zum Datenschutz auf den jeweiligen nationalen und internationalen Ebenen erläutert.

Ein Recht auf Datenschutz ist international gesehen mittelbar aus der Menschenrechtserklärung der Vereinten Nationen ableitbar.[83] Der Artikel 12 der Erklärung sieht ein Recht auf Privatsphäre und damit ein Recht auf Datenschutz vor. Spezifischer geht eine Sammlung von Leitlinien der UN ein, die im Jahr 1990 verabschiedet wurde. Die „Guidelines Concerning Computerized Personal Data Files“ sind jedoch nicht verpflichtend für Staaten, bieten aber eine Grundlage für alle nachfolgenden Verabschiedungen.[84] Auch die Organisation für wirtschaftliche Zusammenarbeit (OECD) befasste sich in den 1970er Jahren mit der Definition und den Regelungen von datenschutzrechtlichen Standards.[85] Unter anderem entstand daraus die „OECD Guidelines on the Protection of Privacy and Transborder Data Flows of Personal Data“.[86] In den Richtlinien wird auch die Thematik des internationalen Datenaustausches behandelt. Wie auch die Empfehlungen zum Datenschutz der UN, sind diese Guidelines ebenso unverbindlich.

Auf Europäischer Ebene finden sich erste Ansätze zum Datenschutz in der Europäischen Menschenrechtskonvention (EMRK). Im Artikel 8 wird der Schutz des allgemeinen Persönlichkeitsrechts zugesichert.[87] Die Vorgaben der EMRK sind als allgemeine Grundsätze Teil des Europäischen Unionsrechts und damit verpflichtend für alle EU-Mitgliedsstaaten. Ein Übereinkommen konkret zum Datenschutz wurde 1981 vom Europarat verabschiedet. Die verbindliche Datenschutzkonvention sieht u.a. vor, dass persönliche Daten geschützt werden und dass eine automatische Verarbeitung personenbezogener Daten grenzüberschreitend zwischen den Vertragsparteien möglich ist.[88] Die Konvention gilt sowohl im öffentlichen (BND, Uni, etc.) als auch im privatem Bereich (Telekommunikationsanbieter, etc.).[89] Weiterhin wurde in der Konvention der Umgang mit sensiblen Daten, wie zum Beispiel Gesundheitsdaten, geregelt (Artikel 6). Es wurden Festlegungen getroffen, die das Recht von Betroffenen unterstützen. So können persönliche Daten von Unternehmen erfragt, eine Berichtigung oder Löschung der Daten bewirkt werden. 2001 wurde ein Zusatzprotokoll verabschiedet, das die Einrichtung von unabhängigen Kontrollstellen regelt.[90] Die Verträge zur Europäischen Union, wie der Vertrag über die Arbeitsweise der Europäischen Union (AEUV), regeln auch den Umgang mit persönlichen Daten.[91] Durch die Doppelung der Gesetzestexte wurde eine Gültigkeit auch auf primärer Unionsrechtsebene hergestellt.[92] Für Cloud-Computing ist die Datenschutzrichtlinie vom 24. Oktober 1995 entscheidend.[93] Sie hat einen hohen Stellenwert und bestimmt „…den Inhalt der gesamten Datenschutzgesetzgebung in der Europäischen Union“.[94]

Im Gegensatz zum Europäischen Grundgesetz ist in der Deutschen Verfassung kein Grundrecht auf Datenschutz ausdrücklich gewährt.[95] Jedoch werden aus den allgemeinen Persönlichkeitsrechten im Art. 2 Abs. 1 und dem Art. 1 Abs. 1 der Grundrechte auch Rechte im Umgang mit personenbezogenen Daten abgeleitet.[96] Seit dem 20.12.1990 gilt das Bundesdatenschutzgesetz (BDSG), in welchem die Erhebung, Verarbeitung und Nutzung von personenbezogenen Daten geregelt werden.[97] Personenbezogene Daten werden im BDSG § 3 Abs. 1 als „Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person (Betroffener)“ definiert.[98] Im Zusammenhang mit Cloud-Computing können personenbezogene Daten weltweit vom CSP verarbeitet werden. § 1 Absatz 5 des BDSG in Verbindung mit Artikel 4 der Datenschutzrichtlinie 95/46/EG regeln das anzuwendende nationale Recht.[99] Dabei bestimmt der Sitz des Nutzers von Cloud-Diensten das geltende Recht innerhalb der EU oder in Ländern des Europäischen Wirtschaftsraums (EWR).[100]

Das BSI empfiehlt personenbezogene Daten nach deren Schutzbedarf zu klassifizieren.[101] Die Umsetzung und Bestimmung der verschiedenen Klassifizierungen eines Schutzstufenkonzeptes liegt in Verantwortung des entsprechenden Datenschutz- und IT-Sicherheitsbeauftragten. Konkrete Schutzstufenkonzepte liefern die einzelnen Datenschutzbeauftragten der jeweiligen Bundesländer. Diese können als Richtlinie herangezogen werden.

Tabelle 1: Schutzstufenkonzept des Landes Niedersachsen

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Die Landesbeauftragte für den Datenschutz Niedersachsen (2010)[102]

3.5 Informationssicherheit

Informationssicherheit setzt sich zum Ziel, Informationen jeglicher Art und Herkunft zu schützen. Dabei handelt es sich primär um elektronisch gespeicherte Informationen und deren Verarbeitung. Um das Ziel zu erreichen, hat sich die Informationssicherheit die Aufgabe gestellt, die drei Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit von Informationen zu schützen.[103] Nach Lissen/Brünger/Damhorst können diesen drei Schutzzielen folgende Bedeutung zugeordnet werden:[104]

- Vertraulichkeit: Daten sind vor unbefugtem Zugriff geschützt
- Integrität: Daten sind vollständig und unverändert
- Verfügbarkeit: Eigenschaften der Leistungsbeschreibung stehen zur Verfügung

Das BSI liefert mit seiner Methodik des IT-Grundschutzes Vorgehensweisen für die Implementierung und Aufrechterhaltung eines Managementsystems für die Informationssicherheit (ISMS) in Unternehmen. Das ISMS stellt ein definiertes Sicherheitsniveau her und hält dieses aufrecht. In den IT-Grundschutzkatalogen des BSI sind Standardgefährdungen und Maßnahmen enthalten, sodass diese in das eigene ISMS einfließen können. Die Strukturierung der Kataloge erfolgt anhand von 5 Schichten, die nach verschiedenen Prozessen, Anwendungen und Komponenten der IT aufgeteilt sind:[105]

- Schicht 1 umfasst sämtliche übergreifenden Aspekte der Informationssicherheit. Beispiele sind die Bausteine Personal, Datensicherungskonzept und Outsourcing.
- Schicht 2 befasst sich mit den baulich-technischen Gegebenheiten. Beispiele sind die Bausteine Gebäude, Serverraum und häuslicher Arbeitsplatz.
- Schicht 3 betrifft die einzelnen IT-Systeme. Beispiele sind die Bausteine allgemeiner Client, allgemeiner Server, TK-Anlage, Laptop und Mobiltelefon.
- Schicht 4 betrachtet die Vernetzungsaspekte der IT-Systeme. Beispiele sind die Bausteine heterogene Netze, WLAN, VoIP sowie Netz- und Systemmanagement.
- Schicht 5 beschäftigt sich mit den eigentlichen Anwendungen. Beispiele sind die Bausteine E-Mail, Webserver und Datenbanken

Ein Unternehmen, welches Informationssicherheit erstmalig einrichtet, muss nach Grundschutzkatalog des BSI zunächst Sicherheitsziele definieren und datenschutzrechtliche Anforderungen zusammenstellen. Danach erfolgt eine Aufnahme aller Geschäftsprozesse, IT-Systeme, Anwendungen und die dabei verarbeitenden Informationen. Die gewonnenen Daten werden benötigt, um eine Schutzbedarfsfeststellung durchzuführen. Diese ermöglicht es für jede Anwendung den zu erwartenden Schaden zu betrachten, wenn die drei Schutzziele der zu verarbeitenden Informationen beeinflusst werden. Für die Einteilung setzten sich drei Schutzbedarfskategorien durch (s. Tabelle 2).106

[...]


[1] Vgl. KPMG AG (2015), S. 5

[2] Vgl. Runge u. a. (2009), S. 72

[3] Vgl. Söbbing (2015), S. 2 oder vgl. Fehling (2014), S. 1

[4] Vgl. Kavis (2014), S. 27

[5] Vgl. Baun u. a. (2010), S. 4

[6] Zit. Mell/Grance (2011), S. 2

[7] Vgl. Baun u. a. (2010), S. 3

[8] Zit. Baun u. a. (2010), S. 4

[9] Vgl. Baun u. a. (2010), S. 5

[10] Vgl. Greenberger (1964), S. 2

[11] Vgl. Menken (2008), S. 19

[12] Vgl. Mell/Grance (2011)

[13] Vgl. Barton (2014), S. 41

[14] Vgl. Creasy (1981), S. 483-490

[15] Vgl. Meinel u. a. (2011), S. 8

[16] Vgl. Meinel u. a. (2011), S. 8

[17] Vgl. Lampe (2010), S. 57

[18] Vgl. Lampe (2010), S. 58

[19] Vgl. Baun u. a. (2010), S. 11

[20] Vgl. Baun u. a. (2010), S. 12

[21] Vgl. Baun u. a. (2010), S. 12

[22] Vgl. https://www.vmware.com/de/products/workstation

[23] Vgl. https://technet.microsoft.com/library/hh831531.aspx

[24] Vgl. https://www.virtualbox.org/

[25] Vgl. Meinel u. a. (2011), S. 14

[26] Vgl. Meinel u. a. (2011), S. 14

[27] Vgl. Vogel/Koçoğlu/Berger (2010), S. 14

[28] Vgl. Baun u. a. (2010), S. 18

[29] Vgl. Baun u. a. (2010), S. 18

[30] Vgl. Vogel/Koçoğlu/Berger (2010), S. 19

[31] Vgl. Vogel/Koçoğlu/Berger (2010), S. 20-21

[32] Vgl. Vogel/Koçoğlu/Berger (2010), S. 22

[33] Vgl. Runge u. a. (2009), S. 72

[34] Vgl. Runge u. a. (2009), S. 73

[35] Vgl. Baun u. a. (2010), S. 16

[36] Vgl. Luntovskyy/Gütter/Melnyk (2012), S. 245

[37] Vgl. Runge u. a. (2009), S. 70

[38] Vgl. Runge u. a. (2009), S. 71

[39] Vgl. Melzer (2010), S. 9

[40] Zit. Heutschi (2007), S. 22

[41] Zit. Heutschi (2007), S. 22

[42] Vgl. Baun u. a. (2010), S. 19

[43] Vgl. Nissen/Petsch/Schorcht (2008), S. 9

[44] Vgl. Melzer (2010), S. 11

[45] Vgl. Melzer (2010), S. 11

[46] Vgl. Heutschi (2007), S. 23

[47] Vgl. W3C (2002)

[48] Vgl. Melzer (2010), S. 63

[49] Vgl. Melzer (2010), S. 108

[50] Vgl. Melzer (2010), S. 111

[51] Vgl. BITKOM (2010), S. 15

[52] Vgl. Münzl/Pauly/Reti (2015), S. 10

[53] Vgl. Bedner (2013), S. 29

[54] Vgl. BITKOM (2009), S. 16

[55] Vgl. Szer (2013), S. 57

[56] Vgl. Münzl/Pauly/Reti (2015), S. 12

[57] Vgl. BITKOM (2009), S. 23

[58] Vgl. Alberto, D., Baker, J., Cornellier, J. ,Hamel, J. u. a. (2015), S. 16

[59] Vgl. BITKOM (2010), S. 18

[60] Vgl. Bedner (2013), S. 33

[61] Vgl. Baun u. a. (2010), S. 28

[62] Vgl. Münzl/Pauly/Reti (2015), S. 13

[63] Vgl. Matros (2012), S. 48

[64] Vgl. Matros (2012), S. 49

[65] Vgl. Baun u. a. (2010), S. 22-23

[66] Vgl. Pfister (2014)

[67] Vgl. Söbbing (2015), S. 147

[68] Vgl. Höllwarth (2012), S. 166

[69] Vgl. Rajaraajeswari/Pethuru (2013), S. 257

[70] Vgl. Fehling (2014), S. 23

[71] Vgl. Fehling (2014), S. 26

[72] Vgl. Fehling (2014), S. 29

[73] Vgl. Fehling (2014), S. 34

[74] Vgl. Fehling (2014), S. 36

[75] Vgl. Fehling (2014), S. 40

[76] Vgl. Reese (2009), S. 67

[77] Vgl. Kavis (2014), S. 25

[78] Vgl. Kavis (2014), S. 26

[79] Vgl. Sarna (2010), S. 78

[80] Vgl. Chandrasekaran (2015), S. 32

[81] Vgl. Niemann/Paul (2014), S. 60

[82] Vgl. Barnitzke (2014), S. 22

[83] Vgl. Allgemeine Erklärung der Menschenrechte (A/RES/217) v. 10.12.1948

[84] Vgl. UN General Assembly (1990)

[85] Vgl. Kroschwald (2016), S. 23

[86] Vgl. OECD (2013)

[87] Vgl. Europäischen Menschenrechtskonvention (EMRK) v. 1.11.1950

[88] Vgl. Übereinkommen zum Schutz des Menschen bei der automatischen Verarbeitung personenbezogener Daten (SEV 108) v. 28.1.1981, Artikel 12

[89] Vgl. Kühling/Seidel/Sivridis (2011), S. 10

[90] Vgl. Kühling/Seidel/Sivridis (2011), S. 11

[91] Vgl. Vertrag über die Arbeitsweise der Europäischen Union (AEUV) v. 1.12.2009

[92] Vgl. Streinz (2012), S. 2

[93] Vgl. Richtlinie zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr (RICHTLINIE 95/46/EG) v. 24.10.1995

[94] Kroschwald (2016), S. 29

[95] Vgl. Kroschwald (2016), S. 30

[96] Vgl. Grundgesetz für die Bundesrepublik Deutschland (GG) v. 23.5.1949; Vgl. Kroschwald (2016), S. 30

[97] Vgl. Bundesdatenschutzgesetz (BDSG) v. 20.12.1990

[98] Vgl. BDSG v. 20.12.1990

[99] Vgl. Lissen/Brünger/Damhorst (2014), S. 31

[100] Vgl. Lissen/Brünger/Damhorst (2014), S. 32

[101] Vgl. BSI (2016)

[102] Vgl. Die Landesbeauftragte für den Datenschutz Niedersachsen (2010)

[103] Vgl. Bundesamt für Sicherheit in der Informationstechnik (2008), S. 12

[104] Vgl. Lissen/Brünger/Damhorst (2014), S. 30

[105] Vgl. Bundesamt für Sicherheit in der Informationstechnik (2008), S. 11

Ende der Leseprobe aus 89 Seiten

Details

Titel
Bewertung der Eignung von Applikationslandschaften für den Betrieb in einer Cloud
Hochschule
FOM Essen, Hochschule für Oekonomie & Management gemeinnützige GmbH, Hochschulleitung Essen früher Fachhochschule
Note
1,3
Autor
Jahr
2016
Seiten
89
Katalognummer
V344705
ISBN (eBook)
9783668359987
Dateigröße
2379 KB
Sprache
Deutsch
Schlagworte
Cloud-Computing, Cloud, Anwendungen, IaaS, PaaS, SaaS, Public Cloud, AWS, Azure, Amazon, Microsoft
Arbeit zitieren
Manuel Wicke (Autor), 2016, Bewertung der Eignung von Applikationslandschaften für den Betrieb in einer Cloud, München, GRIN Verlag, https://www.grin.com/document/344705

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Bewertung der Eignung von Applikationslandschaften für den Betrieb in einer Cloud


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden