Regulatorien, Sicherheit und Integrationsszenarien – How to Public Cloud

1. Überblick

Bis 2025 werden voraussichtlich 80% der Unternehmen Teile ihrer Applikationslandschaft in die Cloud migrieren. Die Public Cloud ermöglicht dabei den Aufbau einer hoch-performanten IT-Organisation, um den Ansprüchen des „Digital-Native“-Kunden gerecht zu werden. Neben Chancen bringt die Natur der Public Cloud auch neue Herausforderungen mit sich, besonders im Bereich Security, Regulatorik und Vendor-Management sowie bei der Integration in bestehende IT-Landschaften, z.B. im Hybrid-Cloud-Ansatz.

1.1 Services in der Public Cloud

Public Cloud meint die Bereitstellung einer Vielzahl an IT-Services wie Rechenleistung, Speicherplatz, Infrastrukturen oder Anwendungen in verschiedenen Ausbaustufen über das öffentliche Internet:

• Infrastructure as a Service (IaaS) ermöglicht die Nutzung virtualisierter Ressourcen von Computerhardware. Hierzu zählen u.a. virtuelle Rechner, Netzwerke oder Speichermöglichkeiten. Nutzer können ihre eigene Infrastruktur-Landschaft zusammenstellen und eigenständig Software hierauf betreiben. Für die Installation und den Betrieb der Software ist der Anwender selbst verantwortlich.
• Platform as a Service (PaaS) meint die Bereitstellung von Laufzeit- und Programmierumgebungen. Die Rechen- und Datenkapazitäten sind dabei flexibel anpassbar. Innerhalb der bereitgestellten PaaS-Umgebung können Anwendungen durch den Nutzer entwickelt und betrieben werden.
• Software as a Service (SaaS) beschreibt die höchste Form der Abstraktion und bietet dem Kunden einen direkten Zugang zu Anwendungen oder einer bestimmten Software zur Nutzung. Den Betrieb verantwortet hierbei der Dienstleister.

1.2 Eigenschaften der Public Cloud

Während die grundlegende Technik (IaaS, PaaS, SaaS) in der Private Cloud und der Public Cloud ähnlich realisiert wird, zeigen sich doch in der Ausgestaltung einige Unterschiede. Global agierende Anbieter wie Google (Google Cloud Platform), Amazon (Amazon Web Services) oder Microsoft (Azure) – auch „Big 3“ genannt – nutzen global verteilte Rechenzentren und können dementsprechend breit skalieren, insbesondere auch auf Basis einer enormen Bandbreite und einer sehr niedrigen Latenz mittels direkter Verbindungen zum Internet-Backbone. Selbst in Enterprise-Anwendungsfällen sollten hier keine technischen Grenzen gesetzt sein, wobei regulatorische Anforderungen, wie z.B. die aus der EU-DSGVO abgeleiteten, zu beachten sind. So wird der Zugriff auf Public-Cloud-Services für eine sehr große – wenn auch nicht näher zu bestimmende – Anzahl von Anwendern über das öffentliche Internet möglich, wobei eine Trennung der Mandanten auf der Virtualisierungsebene, nicht auf der Ebene der physischen Ressourcen erfolgt. Bei den „Big 3“ sind diese physischen Ressourcen zumeist Eigenentwicklungen, welche aufgrund vorhandener Skaleneffekte kostengünstig produziert werden können und gleichzeitig ein erhöhtes Sicherheitsniveau bieten.

Im Gegensatz zur Private Cloud, bei der meist dedizierte (physische) Ressourcen in einem oder wenigen Rechenzentren für den jeweiligen Kunden angeboten werden, können in der Public Cloud Leistungen flexibel im Selfservice zu- und abgebucht werden. Die Abrechnung erfolgt über ein standardisiertes, nutzungsabhängiges Modell für die tatsächlich erbrachte Leistung im Gegensatz zum Private-Cloud-Modell, das mit zumeist hochspezifischen Einzelverträgen verbunden ist. Während in einer Private Cloud – speziell, wenn diese im eigenen Rechenzentrum gehostet wird – ein „Anfassen“ der Hardware, und dementsprechend auch ein Auditing, möglich ist, ist der Zugang zu den Rechenzentren der Public Cloud stark reguliert. Ein Zugriff ist zumeist nur auf Softwareebene möglich. Eine Kontrolle, welche Mitarbeiter des Dienstleisters (physischen) Zugriff haben, ist in der Regel nicht gegeben. Die Wartung erfolgt durch den Anbieter der Public Cloud in definierten, kaum verschiebbaren Zeitfenstern.

Als Nutzer einer Public Cloud ergibt sich der Vorteil, dass keine eigene IT-Infrastruktur und Software zu installieren und zu betreiben ist. Hohe Vorabinvestitionskosten lassen sich dementsprechend vermeiden. Zwar wird nichtsdestotrotz weiterhin ein grundlegendes Know-how über Infrastrukturkomponenten wie Server oder Netzwerke benötigt, allerdings auf einer höheren Abstraktionsebene. Die Public Cloud bietet im Vergleich zur Private Cloud sehr viele verschiedene Services mit einem starken Fokus auf Managed Services und der Abdeckung der ganzen Bandbreite von IaaS, SaaS und PaaS. Dadurch ergeben sich einerseits viele Vorteile, andererseits muss ein besonderes Augenmerk auf entsprechende Herausforderungen der Public Cloud gelegt werden.

2. Herausforderungen bei der Nutzung von Public-Cloud-Services

Aus den oben aufgeführten Unterschieden zwischen Public und Private Cloud ergeben sich nun Anforderungen an die Ausgestaltung der Servicenutzung.

2.1 Sicherheitsanforderungen an Systeme in der Public Cloud

Um der Komplexität von Cloud-Umgebungen gerecht zu werden, müssen traditionelle Sicherheitsansätze grundlegend geändert und neu gedacht werden. Da sich grundsätzlich jeder Teil der Applikation im Internet befindet, funktioniert die Verwendung von traditionellen Methoden der IT-Sicherheit wie bspw. die Nutzung von Netzwerk-DMZs nicht mehr. In einer Cloud-Umgebung, die auf SaaS- oder PaaS-Produkte setzt, bietet jeder neu angebundene Service ein potenzielles Einfallstor in die IT-Landschaft. IT-Sicherheitsrichtlinien und -Vorgaben müssen die konzeptuellen Voraussetzungen der Public Cloud berücksichtigen Die Lösung bieten hier Ansätze wie Zero-Trust-Architekturen sowie das vor allem durch Google entwickelte und propagierte Beyond-Corp-Paradigma. Im letztgenannten Ansatz wird darauf geachtet, dass jede Kommunikation zwischen Applikationen voll verschlüsselt erfolgt (z.B. über mTLS) und (technische) Nutzerrechte auf Basis des Least-Privilege-Ansatzes verteilt werden. So kann sichergestellt werden, dass selbst wenn eine Applikation kompromittiert wird, der Angreifer nur auf diese eine Applikation Zugriff hat, nicht aber auf das gesamte Netzwerk.

2.2 Regulatorische Herausforderungen in der Public Cloud

Unter dem Begriff Datenschutz wird laut §1 der EU-Datenschutz-Grundverordnung (EU-DSGVO) der Schutz des Persönlichkeitsrechts bei der Verarbeitung personenbezogener Daten verstanden. Neben den Grundprinzipien sowie den Schutzzielen des Datenschutzrechtes ist für die Nutzung von Public-Cloud-Services im Detail die Erfüllung der Datensicherheit besonders wichtig, also die Sicherstellung von Vertraulichkeit, Integrität und Verfügbarkeit. 

Zum Schutz dieser Ziele ist der Verarbeitende verantwortlich, geeignete technische und organisatorische Maßnahmen umzusetzen. Werden im Rahmen der Nutzung von Public-Cloud-Services Daten, die unter den Schutz der EU-DSGVO fallen, an einen Public-Cloud-Anbieter übertragen (z.B. zur Lagerung in einer Datenbank), verbleibt der ursprünglich für die Verarbeitung Verantwortliche der Daten weiterhin verpflichtet, die Schutzziele sicherzustellen. Im Blick auf Public-Cloud-Services bedeutet dies, dass die Anbieter – ähnlich wie andere Dienstleister – nach §40 der EU-DSGVO zertifiziert werden müssen bzw. durch eine unabhängige Zertifizierungsstelle nach §42 zertifiziert sind. Der Anbieter muss gewährleisten, dass IT-Prozessmodelle, Informationssicherheits-Managementsysteme, IT-Sicherheitskonzepte, Konzepte zur Mandantentrennung, zum Monitoring sowie eine regelmäßige Prüfung jeweils durch vertrauenswürdiges Personal erstellt bzw. durchgeführt werden.

Besonderes Augenmerk liegt hierbei auf dem Ort der Lagerung und Verarbeitung von Daten. Grundsätzlich gilt das Sitzlandprinzip, also die Datenschutzverordnung des Landes, in dem die Daten liegen. Bei der Verarbeitung der Daten in Deutschland oder der EU gilt allerdings immer die EU-DSGVO und somit die Anforderung der Verarbeitung (Erhebung, Nutzung und Lagerung) der Daten innerhalb der Staaten der Europäischen Union. Für die Nutzung von Public-Cloud-Anbietern ergibt sich dementsprechend für die Verarbeitung von personenbezogenen Daten die Notwendigkeit sicherzustellen, dass sowohl bei der Nutzung als auch bei der Netzwerkkommunikation im Transit ausschließlich Komponenten innerhalb der EU genutzt werden.

2.3 Herausforderungen im Vendor-Management in der Public Cloud

Die Nutzung von Public-Cloud-Services gleicht nach aktueller Auffassung der Auslagerung von IT-Dienstleistungen an einen Dienstleister in vielen Punkten, es müssen allerdings aufgrund der Eigenschaften von Public-Cloud-Services (vgl. Abschnitt 1.2) einige Details berücksichtigt werden. Im Bereich Vendor-Management ist sicherzustellen, dass für die eigene Organisation keine erhöhte Abhängigkeit entsteht (Kontrollverlust), dass der Anbieter nicht gegen rechtliche Vorschriften verstößt (vgl. Abschnitt 2.2) und dass eine ausreichende Mandantentrennung gewährleistet ist.

Auch ist durch den Nutzer sicherzustellen, dass der Anbieter über ein ausreichendes Notfallkonzept für den Katastrophenfall verfügt. Für die Nutzung von Cloud-Services für Applikationen mit erhöhtem Schutzbedarf sollte zusätzlich durch den Nutzer sichergestellt werden, dass kein Vendor-Lock-in erfolgt bzw. die betriebenen Applikationen grundsätzlich portierbar sind, eigenständige Datensicherungen erfolgen, sämtliche Kommunikation verschlüsselt ist sowie Mitarbeiter des Anbieters in regelmäßigen Abständen auf ihre Eignung überprüft werden.

3. Anforderungen und Eigenschaften von IT-System für eine Nutzung in der Public Cloud

Grundsätzlich bietet die Public Cloud mit ihrem Fokus auf “Managed” Services, also von regelmäßig wiederkehrenden Leistungen wie der Bereitstellung, Kontrolle, Wartung und Fehlerbehebung von IT-Services, ein hohes Potential dafür, nicht-essentielle Komponenten einer Anwendung zu ersetzen und somit einerseits Kosten zu sparen, andererseits aber auch, sich auf die wesentlichen Aspekte und Wertschöpfungskomponenten zu konzentrieren. So können bspw. einzelne Komponenten einer Web­anwendung, wie etwa Loadbalancer, Server oder Datenbanken durch Managed Services ausgetauscht werden, die der Public-Cloud-Anbieter bereitstellt. Auf diese Weise lässt sich der Aufwand für die Konfiguration, das Einspielen von (Sicherheits-)Patches und weitere Wartungs­arbeiten reduzieren.

3.1 Skalierungsfähigkeit bei hohen Ressourcenanforderungen

Aufgrund der hervorragenden Möglichkeiten der Skalierung und nahezu unbegrenzten Bereitstellung von Rechenressourcen empfiehlt es sich insbesondere, sehr rechenintensive Anwendungen in die Cloud zu verlagern, um so Hardwarekosten in den eigenen Rechenzentren einzusparen. Durch die Nutzungsmöglichkeiten, die Public-Cloud-Anbieter (und unter diesen speziell die „Big 3“) bieten, kann hier auf einen quasi unbegrenzten Pool an Rechenleistung und Speicherpotenzial zugegriffen werden.

Somit können Lastspitzen abgefangen werden, für die Private Clouds ggf. nicht ausgelegt sind. Gleichfalls kann ein kontinuierlicher Anstieg der Nutzerzahlen durch das einfache und hochautomatisierbare Hochfahren weiterer Server im laufenden Betrieb gestemmt werden. Beispielhaft seien hier Systeme zu nennen, die aufgrund ihrer fachlichen Anforderungen Nutzungsschwankungen ausgesetzt sind, wie z.B. Antrags- oder Kundenportale, welche Endkunden zu bestimmten (saisonalen) Zeiten frequentieren. Ebenso gilt dies natürlich für Mitarbeitersysteme oder Entwicklungsumgebungen, welche am Wochenende geringere Nutzung erfahren und dementsprechend zurück skaliert werden können.

3.2 Spezifische Technologieanforderungen

Gleiches gilt für sehr spezifische Anforderungen an die eingesetzte Hardware. Durch die Nutzung von Cloud-Computing kann hierbei auf vorhandene Ressourcen des Cloud-Anbieters zurückgegriffen werden, welche dieser aufgrund der vorhandenen Skaleneffekte kostengünstig zur Verfügung stellen kann. Zusätzlich entfällt hier der Bedarf des kostenaufwändigen Aufbaus von Know-how für den Betrieb.

Nischenprodukte wie spezielle Betriebssysteme oder Systeme für neuartige Anwendungsfälle wie Machine Learning müssen nicht mehr im Eigenbetrieb eingesetzt werden. Als Beispiel sei hier die Nutzung bereitgestellter Apple-Hardware für die Entwicklung von iOS-Apps genannt, welche zwingend auf einem mit MacOS ausgestatteten Rechner gebaut werden müssen. Im Cloud-Computing kann in diesem Fall durch die Nutzung von SaaS-Lösungen wie Bitrise auf den eigenen Aufbau und Betrieb von Hardware verzichtet werden.

3.3 Optimierung für Endkundennutzung

Durch ein gut ausgebautes und verteiltes Rechenzentrumsnetz ermöglichen Public-Cloud-Lösungen eine kundennahe Bereitstellung, das Caching von Content und somit niedrige Latenzen und höhere Geschwindigkeiten aufweist, als dies bei der Nutzung einer Private Cloud möglich wäre. Ein passendes Nutzungsbeispiel wäre hier die Verteilung von Lehrvideos oder Antragsdokumenten. 

3.4 Eignung aufgrund regulatorischer Anforderungen

Bei allen Vorteilen müssen dennoch bei der Auswahl zu migrierender IT-Systeme die zuvor erläuterten, allgemeinen Herausforderungen beachtet werden. Insbesondere bei Systemen, die aufgrund ihrer Art, z.B. durch die Verarbeitung personenbezogener Daten, strenge regulatorische bzw. datenrechtliche Anforderungen erfüllen müssen, empfiehlt sich vor einer Migration eine genaue Prüfung, um sicherzugehen, dass alle rechtlichen Rahmenbedingungen eingehalten werden können.

4. Integrationsszenarien der Public Cloud in bestehende Enterprise-IT-Landschaften

Zur Unterscheidung möglicher Szenarien der Integration von Cloud-Landschaften, muss zuerst eine klare Abgrenzung möglicher Szenarien erfolgen – werden doch viele Begriffe heutzutage gleichbedeutend oder nicht trennscharf verwendet.

Bei der Integration können zwei Modelle unterschieden werden:

• Hybrid Cloud bezeichnet die partielle Aufteilung von IT-Ressourcen sowohl auf eine Public Cloud als auch in On-Premises-Umgebungen, also firmeneigene Rechenzentren oder in durch Dienstleister bereitgestellte Rechenzentren (ggf. auch ausgestaltet als Private Cloud).
• Multi Cloud bezeichnet die Aufteilung von IT-Ressourcen auf mehrere Public Clouds.

Aus Sicht eines Unternehmens oder einer Organisation ergibt sich ein signifikanter Unterschied zwischen beiden Modellen. Während der Aufbau und die Nutzung eines Hybrid-Cloud-Modells bis zum Abschluss einer Cloud-Migration und ggf. über den Zeitraum der Migration hinaus unausweichlich ist, ist die Nutzung eines Multi-Cloud-Modells eine explizite Entscheidung. Die Notwendigkeit für den (temporären) Einsatz einer Hybrid-Cloud-Lösung ergibt sich aus der Übergangsphase: Während einige Applikationen bereits in die Cloud migriert sind oder gerade migriert werden, müssen andere Anwendungen noch On-Premises betrieben werden oder können ggf. gar nicht migriert werden.

Eine hybride Cloud-Architektur zeichnet sich durch die Aufteilung von Applikationen zwischen Public Cloud und On-Premises-Umgebung aus, welche einheitlich verwaltet und gemeinsam orchestriert wird. Der Fokus liegt insbesondere auf den Interaktionen der Applikationen zur Erfüllung von Anwendungsfällen oder Prozessen.

4.1 Integrationsszenarien in einem Hybrid-Cloud-Ansatz

Die verschiedenen Integrationsszenarien lassen sich grob in drei verschiedene Bereiche einteilen:

1. Applikationsgetriebene Ansätze, deren Aufteilung sich an Art und Aufbau der zu betreibenden Applikationen orientiert,
2. Datengetriebene Aufteilungen und
3. Betriebsorientierte Aufteilungen.

Allen Ansätzen gemein ist, dass die technische Integration zumeist über die Nutzung dedizierter Netzwerkstrecken erfolgt, wie z.B. VPN-Tunnel oder „Dedicated Interconnects“, welche eine Hardware-gestützte Verbindung zwischen den Rechenzentren des Public-Cloud-Anbieters und den Rechenzentren der nutzendenden Firma darstellen.

4.1.1 Applikationsgetriebene Ansätze

Die Strategie, das Frontend bzw. frontendnahe Komponenten in die Cloud zu migrieren, während die Backend-Services (zumeist Mainframe-Applikationen) vorerst in der On-Premises-Umgebung verbleiben, ist in der Praxis am weitesten verbreitet. Verschiedene Faktoren, wie z.B. die notwendige Exponierung von Web-Frontends über das Internet oder die stark fluktuierende Nutzung durch Endbenutzer, legen diesen Ansatz nahe.

In der Praxis ist er jedoch problematisch, da die Skalierung stets auf der Skalierbarkeit der gesamten Applikation beruht: Das Abfangen von Lastspitzen nur im Frontend kann so zu unerwünschten Ausfällen der Backend-Services in der On-Premises-Umgebung führen. Anders zeigen sich die Ansätze, die eine Aufteilung nach Kriterien wie Alter oder Kritikalität der Anwendung vornehmen, da hier jeweils ganze Applikationen in die Cloud migriert werden bzw. dort entstehen.

Vorsicht ist bei der Neuentwicklung von Applikationen in der Cloud geboten, da hier die gleiche Problematik entstehen kann wie bei der Aufteilung nach Frontend und Backend. Für eine Aufteilung nach dem Kriterium der Kritikalität spricht insbesondere in regulatorisch stark überwachten Sektoren, dass die Hauptkomponenten in der absoluten Verfügungsgewalt des Nutzers bleiben, während für unkritische Applikationen die Vorteile der Cloud genutzt werden können. Die Aufteilung nach dem Kriterium des Lebenszyklus ist in der Praxis eher selten zu beobachten, insbesondere aufgrund des Anspruches, Umgebungen über den gesamten Lebenszyklus hinweg so gleichförmig wie möglich zu halten.

4.1.2 Datengetriebene Ansätze

Während die applikationsgetriebenen Ansätze relativ einfach und klar umzusetzen sind, ergibt sich bei den datengetriebenen Ansätzen insbesondere die Problematik des Data-Lock-ins. Bei der Aufteilung nach dem Kriterium non-sensitiv und sensitiv können einerseits sehr gut die regulatorischen Anforderungen erfüllt werden, die sich z.B. aus der EU-DSGVO ergeben, andererseits lässt sich das Exposure im Falle eines Datenlecks gut absichern. Die Verlagerung von Backups in die Cloud ermöglicht zwar die Nutzung kostengünstiger Speichertarife, kann aber bei einer zu hohen Zugriffsrate aufgrund der anfallenden Netzwerkkosten beim Cloud-Anbieter schnell teurer als die Speicherung in einer On-Premises-Umgebung werden.

Bei beiden Ansätzen muss jedoch darauf hingewiesen werden, wie groß die Abhängigkeit von einer guten Absicherung der eigenen Rechenzentren ist. Mit der Verlagerung auch nur von Teilen der eigenen Daten in die Public Cloud geht immer das Risiko einher, dass Angreifer diese als Übergangssystem („hop“, im Sinne von Einfallstor) in die eigene Infrastruktur nutzen, insbesondere, da die Absicherung gegen hoch entwickelte Angriffe, wie sie heutzutage von organisierten Hackern durchgeführt werden, schwierig ist.

4.1.3 Betriebsorientierte Ansätze

Ein weiterer Ansatz ist die Aufteilung mit Blick auf die Nutzung der Applikationen in Produktion. Einerseits kann in der Cloud ein Standby einer Anwendung für den Katastrophenfall bereitgestellt werden, andererseits lassen sich durch Verlagerung in die Cloud Lastspitzen abfedern. Diese beiden Modelle nutzen insbesondere das Potenzial elastischer Skalierungs- und Start-up-Fähigkeiten der Public Cloud, die allerdings grundlegend durch geltende Nutzungsgenehmigungen stark regulierter bzw. kontrollierter Organisationen eingeschränkt werden. Im Falle strenger regulatorischer Vorgaben zeigen die anderen Ansätze klare Vorteile im Vergleich mit den beiden betriebsorientierten.

4.2 Integrationsszenarien in einem Multi-Cloud-Ansatz

Für eine Multi-Cloud-Architektur haben sich in der Praxis fünf verschiedene Integrationsszenarien etabliert, welche jeweils verschiedene Vor- und Nachteile haben.

Willkürliche Verteilung ist ein klares Anzeichen fehlender Governance-Vorgaben innerhalb des Unternehmens und sollte maximal für einen kurzen Zeitraum zur Sondierung und Evaluierung des Serviceangebots genutzt werden (z.B. während einer ersten Versuchsphase).

Die segmentierte Verteilung sollte genutzt werden, wenn anhand der zu betreibenden Applikationen eine klare Governance etabliert werden kann, welche es erlaubt, über die Verwendung eines Cloud-Anbieters zu entscheiden. Der Vorteil ist hierbei, dass die jeweiligen Stärken und Schwächen des Cloud-Anbieters umfänglich berücksichtigt werden.

Ähnlich verhält es sich bei der wahlweisen Verteilung, wobei sich diese immer dann anbietet, wenn keine einfach ableitbare Governance etabliert ist und es somit den jeweiligen Projektteams oder Einheiten überlassen ist, welchen Anbieter sie wählen. Der Vorteil ist somit eine größere Flexibilität.

Der parallele Betrieb von Applikationen ist in der Praxis selten, rückt aber mittlerweile immer mehr in den Fokus der großen Anbieter (z.B. durch EKS Anywhere von AWS oder Anthos von Google). Die sehr hohe Ausfallsicherheit mag hier der Hauptvorteil sein, der allerdings durch eine erhöhte Komplexität durch die Nutzbarmachung zweier ggf. unterschiedlicher PaaS erkauft wird.

Die Sicherstellung der Portierbarkeit ist eine etwas reduzierte Version, welche allerdings eher als eine Variante der Vendor-Lock-in-Thematik verstanden werden sollte, als wirklich eine instantane Verschiebung von Applikationen. Im letzteren Fall ergäbe sich nämlich faktisch ein paralleler Betrieb mit einer Cloud als „Cold Standby“.

Gemeinsam ist allen fünf Szenarien, dass jeweils zu Beginn die explizite Entscheidung getroffen wurde, mehr als nur einen Public-Cloud-Anbieter zu nutzen. Während die verschiedenen Anbieter zwar alle ihre Stärken und Schwächen haben, zeigt sich doch in der Praxis, dass für die Standardanwendungsfälle keine signifikanten Unterschiede bestehen. Jedenfalls keine Unterschiede, welche die erhöhten Aufwände in Bezug auf Vendor-Management, Komplexität, Skill-Sets und Langzeitwartbarkeit rechtfertigen würden. Die wenigsten Organisationen, insbesondere dann, wenn sie noch keine Erfahrungen in der Public Cloud besitzen, würden von solch einem Setup profitieren.

5. Fazit

Die erfolgreiche Einführung und Nutzung von Public-Cloud-Services hängt stark von den fachlichen Anwendungsfällen der zu migrierenden Applikationen ab. In der Erfahrung zeigt sich, dass vorab eine klare Roadmap und die Klärung regulatorischer und hierbei speziell datenschutzrechtlicher Fragestellungen ein Muss sind, damit die Migration Chancen auf Erfolg hat. Dazu empfiehlt sich die Orientierung an bestehenden Auslagerungskonzepten für Cloud-Services, wie sie z.B. vom BSI im IT-Grundschutz-Kompendium kodifiziert sind. Erfolgt hier eine positive Rückmeldung auch nur für einen Teil der Applikationen, sollte nicht gezögert werden, die Chancen der Public Cloud zu ergreifen.