Cloud-Escrow – Reißleine beim Provider-Absturz

Unlängst schrieb IDC-Analyst Matthias Zacher in einem Kommentar, dass Anwender beim Cloud Computing immer noch zu wenig auf das Ende einer Vertragsbeziehung achten, auf die "Exit-Strategie". Im Mittelpunkt stünden Preise und Leistungen sowie der Übergang, bis alles reibungslos läuft. Getreu dem Motto: Wir fahren hin und fragen uns dann durch. Angesichts der vielfältigen Risiken sei das jedoch eine zu kurzfristige Perspektive: "Nach Einschätzung von IDC werden bis zum Jahr 2018 etwa 50 Prozent der Global-1000-Unternehmen vor Ende der Vertragslaufzeit ihre Public- oder Hybrid-Cloud-Verträge beenden", prognostiziert Zacher.

Gründe gibt es viele: Beispielsweise erweisen sich Leistungsversprechen als unrealistisch, wenn etwa der Provider über einen längeren Zeitraum SLAs oder Abmachungen nicht einhalten kann und somit die Service-Bereitstellung nicht oder nur mit Einschränkungen erfolgt. Zu weiteren Faktoren, die das Verhältnis zwischen Provider und Auftraggeber belasten, zählt Zacher Probleme bei der Integration/Implementierung, unzureichendes Vertrags- und Änderungsmanagement, Gefahr des Vendor-Lock-In und Security- beziehungsweise Datenvorfälle. Wird der Provider übernommen, hat das zudem Auswirkungen auf grundlegende Rahmenbedingungen der Kunden. Die Unterbrechung der Verfügbarkeit kann diverse technische, rechtliche, operative oder kaufmännische Gründe haben, deren Ursachen beim Cloud-Provider selbst oder bei seinen Zulieferern liegen.

Insolvenzfall des Cloud-Service-Providers

William Maurer, Analyst vom Research- und Beratungsunternehmen Gartner, hat vergangenes Jahr prognostiziert, dass rund 25 Prozent der IT-Service-Provider im Bereich Infrastruktur bis zum Jahr 2015 den Markt verlassen werden - mehrheitlich durch Übernahmen, aber auch durch Insolvenzen. Dieser Worst Case ist nicht alltäglich, doch auch nicht gänzlich unbekannt: Vor rund einem Jahr traf es den US-Anbieter Nirvanix, der IBM und Intel zu seinen Partnern zählte und der Speicher an Referenzkunden wie National Geographics und die NASA vermietete. Der Provider MegaCloud rutschte 2013 ebenfalls in die Pleite. Längst nicht alle Kunden hätten ihre Daten zurückerhalten, berichteten US-Medien.

Das Potsdamer Hasso-Plattner-Institut (HPI) kam 2013 in einer Untersuchung (PDF) von großen Cloud-Anbietern - darunter auch noch Nirvanix - zum Schluss: "Was im Insolvenzfall des Providers mit den Daten geschieht, ist bei keinem der Anbieter vertraglich geregelt." Somit kann der Zugriff - zumindest theoretisch ohne Eigenverschulden des Anwenders und ohne jegliche Vorwarnung - über Nacht unterbrochen werden. Allerdings sind nicht nur die Daten betroffen, sondern auch individuell programmierte Anwendungen zur Verbindung verschiedener interner oder externer Cloud-Services und Applikationen. Diese können nur weiterbetrieben werden, wenn man zur Wartung und Pflege auf den Quellcode zugreifen kann.

Mit Cloud-Escrow den Zugriff sichern

Oberstes Ziel eines Unternehmens muss daher sein, den Zugriff auf eigene erfolgskritische Daten und notwendige Programme zu sichern - das gebietet schon die kaufmännische Sorgfaltspflicht. Eine Möglichkeit dazu eröffnet das so genannte "Cloud-Escrow", das sich vom Altfranzösischen Wort für "Schriftrolle" ableitet und aus dem klassischen Software-Lizenzgeschäft bekannt ist. In diesem Modell der doppelten Treuhand schließen das Anwenderunternehmen zusammen mit dem Cloud-Provider und einem neutralen Escrow-Agenten einen Vertrag, in dem mögliche Herausgabegründe für den Software-Quellcode oder die Daten konkret definiert sind. Escrow zielt darauf ab, dass eine technisch versierte Person mit dem hinterlegten Material die Anwendung oder den Service ohne Mithilfe Dritter nachbauen kann.

Komplexe Systeme und Abhängigkeiten

Beim Cloud-Escrow liegt die Herausforderung in der Komplexität der Systeme und Wertschöpfungsketten. Sie rührt daher, dass mehr funktionale und technische Komponenten von Drittherstellern für die Programmierung - treffender: für den "Zusammenbau" - der Anwendung herangezogen werden. Wenn diese Dienste eines Drittherstellers dann ebenfalls noch in der Cloud angesiedelt sind, wird die Entwicklung entsprechend schwierig. So kann der Endanwender beispielsweise einen Service abonnieren, eine Cloud-Entwicklungs-Plattform nutzen, Big-Data-Analysen eines weiteren Dienstleisters beziehen und dabei eine Lizenz der Apache Foundation verwenden. Das Ineinandergreifen der Applikationen, Entwicklungsumgebungen und Services verdeutlicht, wie schwierig es ist, die Folgen des Ausfalls eines Gesamtsystem oder einzelner Komponenten eindämmen wollen.

Die einzelnen Bausteine einer "Lösung" müssen präzise identifiziert, isoliert und gesichert werden, um sie beim Escrow-Agenten "einlagern" und im Worst Case reproduzieren zu können. Keine Frage: Dies wird nicht für alle Elemente von Cloud-Diensten mit einem vertretbaren Aufwand möglich sein. So wird bei den Laufzeitumgebungen (PaaS - Platform as a Service) meist pragmatisch unterstellt, dass sie einfach stets verfügbar sind. Zudem werden sich zumindest die großen Cloud-Anbieter kaum darauf einlassen, den Sourcecode ihrer Lösungen zu hinterlegen. Daher bezieht sich Escrow hier in erster Linie auf mittlere bis kleine Anwendungen sowie individuell angepasste Programme, etwa Schnittstellen zur Integration von Cloud-Services mit lokalen Softwareinstallationen. Ein Beispiel hierfür wäre die Verbindung von SAP und Skyvva.

Hinzu kommt, dass Applikation auf den Servern des Cloud-Providers in der Regel nicht nur für einen Anwender allein betrieben werden. Schließlich besteht der zentrale Vorteil von Cloud Computing in der geteilten, mandantenfähigen Infrastruktur. Folglich kann das vom Cloud-Provider entworfene und eingesetzte technische System für einen einzelnen Anwender deutlich überdimensioniert sein, was die Herausgabe und den Nachbau einer Applikation über das Escrow-Modell unwirtschaftlich machen kann. Zudem muss sich der Anwender immer die betriebswirtschaftliche Frage stellen, wie zeitkritisch eine Wiederherstellung des Dienstes ist und über welchen Zeitraum ein potenzieller Datenverlust für das Unternehmen vertretbar wäre.

Verifizierung des hinterlegten Materials

Im klassischen Lizenzgeschäft wird der hinterlegte Quellcode vom Escrow-Agenten verifiziert, um sicherzustellen, dass er vollständig und lauffähig ist und weiter bearbeitet werden kann. In der Regel folgen hierbei auf eine quantitative Prüfung der Nachbau der Entwicklungsumgebung, die Kompilierung und Installation, ein Test der Lauffähigkeit sowie eine Dokumentation. Letzteres umfasst sowohl die Überprüfung der eingereichten Systemdokumentation als auch die Dokumentation der Prüfung.

Diese Prüfungsreihenfolge wird grundsätzlich auch für das Cloud Computing eingehalten. Vom traditionellen Herangehen unterscheidet sich die Verifizierung von Cloud-Diensten jedoch in der Regel durch:

1. Eine größere Komplexität, bedingt durch die höhere Anzahl von Komponenten, beteiligten Parteien und Lizenzen, was sich typischerweise in der Anzahl der Applikations-Server, Web-Server und Datenbanken niederschlägt;

2. Eine im Verhältnis zum geplanten Einsatzzweck überdimensionierte Architektur und Infrastruktur (Stichwort: Mandantenfähigkeit) und einen dadurch höheren Aufwand beim Nachbau;

3. Proprietäre Entwicklungsplattformen, Laufzeitumgebungen oder andere Komponenten, die außerhalb des Zugriffs der Parteien liegen (z.B. PaaS-Nutzung nur per Onlinezugriff) und deren Verfügbarkeit damit als gegeben angenommen werden muss.

Im Ergebnis bedeutet die Verifizierung der vom Cloud-Service-Provider bereitgestellten Anwendungen beziehungsweise Dienste somit potenziell einen Mehraufwand verglichen mit klassischen Anwendungen, stellt die Parteien aber mit Sicherheit nicht vor unlösbare Aufgaben und bleibt damit ein wesentlicher Baustein der angestrebten Absicherung gegen Cloud-Provider-Ausfälle. Cloud-Verifizierungen sind in der Praxis inzwischen ein normaler Teil des Tagesgeschäfts geworden wie die Nutzung von Cloud-Diensten selbst.

Datensicherung in der Cloud

Ein zweiter Aspekt neben dem Schutz der Anwendungen in der Cloud ist der Zugriff auf die eigenen Daten. Dies gilt besonders für den Fall, dass kein Backup vor Ort möglich ist - wenn etwa die Fachabteilung den Cloud-Service ohne Abstimmung mit der IT-Organisation bezieht. Die grundsätzliche Sicherung des individuellen Datenbestandes sollte neben der physisch-elektronischen Übermittlung vom Cloud-Provider in eine gesicherte Infrastruktur auch Tests umfassen, ob die übertragenen Daten durch den Anwender überhaupt technisch verarbeitet werden können.

Zugriff auf eigene Daten

Zur Sicherung der eigenen Anwendungsdaten aus der Cloud heraus muss der Anwender fünf offene Punkte klären und sein Sicherheitsniveau abwägen. Dies kann in den meisten Fällen nur in enger Zusammenarbeit mit dem Cloud-Provider sowie im Rahmen der technischen Möglichkeiten gelöst werden:

Fazit

Cloud-Escrow ist eine Antwort auf die Frage, wie ein IT-Service weiterbetrieben werden kann, wenn der Cloud-Provider seine Leistungen nicht mehr erbringt. Das muss nicht gleichbedeutend mit der Insolvenz des Lieferanten sein - es kann sich auch um Probleme entlang der gesamten Wertschöpfungskette handeln. Cloud-Escrow zielt darauf ab, mit dem hinterlegten Material einen Service ohne Mithilfe Dritter nachbauen zu können.

Ein zweiter Bestandteil ist die Rücksicherung von Daten aus der Cloud. In beiden Fällen müssen Unternehmen mit spitzer Feder rechnen, welches Schutzniveau sie für welche Anwendung und welchen Datenbestand benötigen. Grundsätzlich gilt: Je kürzer der zulässige Ausfallzeitraum für Cloud-Anwendungen, desto höher ist der technische Aufwand für die Sicherstellung einer entsprechenden Verfügbarkeit. Oder anders formuliert: Je kritischer eine Anwendung für die Kernprozesse des Anwenders ist, desto größer sollten auch die Anstrengungen für die Absicherung sein. (sh)