Image: Rettungsanker für Programme und DatenFERCHAUFERCHAU
TechnikCloud Escrow

Rettungs­anker für Programme und Daten

Lesezeit ca.: 6 Minuten
Alexander Freimark

Alexander Freimark

freier Journalist

Wenn der Cloud-Dienstleister in die Insolvenz geht, ist guter Rat teuer: Programme können unter Umständen nicht mehr gewartet werden, Daten sind dem Zugriff entzogen. Doch gibt es Mittel und Wege, um die eigene Verhandlungs­po­si­tion gegenüber dem Insolvenz­ver­walter zu verbessern.

13. November 2014

Nomen est Omen – im vergangenen Herbst musste der Cloud-Provider Nirvanix seinen Betrieb einstellen. Das Unternehmen hatte einen riesigen Speicher­platz in der Cloud geöffnet, Partner waren IBM und Intel, zu den Referenz­kunden zählten National Geographics, Fox Sports und die NASA. Nach der Pleite wurde ihnen eine Frist von zwei Wochen eingeräumt, um die eigenen Daten herunter­zu­laden. Durch den Einfluss der starken Partner verlängerte sich dann zumindest die Zeitspanne.

Nirvanix war kein Einzelfall, auch der Provider MegaCloud strich vergangenes Jahr die Segel. Die Beispiele machen klar: Cloud-Services können temporär wegfallen oder komplett eingestellt werden – und der Zugriff auf eigene Daten und Programme ist beileibe nicht immer gesichert. Die Unterbre­chung der Verfügbar­keit kann diverse technische, rechtliche, operative oder kaufmänni­sche Gründe haben, deren Ursachen beim Cloud-Provider selbst oder bei seinen Zulieferern liegen.

Wenn der Cloud-Provider vom Himmel fällt?

Nicht ohne Grund wird die Verfügbar­keit als zentrales Cloud-Risiko gesehen, als größte Herausfor­de­rung und als Hauptgrund für die anhaltende, wenn auch abnehmende Zurückhal­tung der Nutzer. Auch das Potsdamer Hasso-Plattner-Institut (HPI) kam in einer aktuellen Untersuchung von großen Cloud-Anbietern zu einem bedenkli­chen Schluss: „Was im Insolvenz­fall des Providers mit den Daten geschieht, ist bei keinem der Anbieter vertraglich geregelt.“

Im Cloud-Modell erwirbt der Anwender kein dauerhaftes Nutzungs­recht, sondern zahlt nutzungs­ab­hängig für bestimmte Funktionen oder Dienste – eben „as a Service“ bzw. „on Demand“. Da diese Dienste und die dabei generierten Anwendungs­daten zunächst vollständig auf der Infrastruktur des Cloud-Providers laufen, könnte der Zugriff – zumindest theoretisch ohne Eigenver­schulden des Anwenders und ohne jegliche Vorwarnung – von einer Sekunde auf die andere unterbro­chen werden. Das gilt auch für den Fall, dass von Dienstleis­tern individuell programmierte Anwendungen zur Verbindung verschie­dener interner oder externer Cloud-Services nicht mehr weiterbe­trieben werden können, weil niemand zur Wartung und Pflege auf den Quellcode zugreifen kann.

Neutraler Agent als Vermittler

Als letzter Rettungs­anker hat sich das so genannte „Cloud Escrow“ herausge­bildet, das sich vom altfranzö­si­schen Wort für „Schriftrolle“ ableitet und aus dem klassischen Software-Lizenzge­schäft bekannt ist. „Ein Anwender­un­ter­nehmen schließt zusammen mit seinem Entwickler und einem neutralen Escrow-Agenten einen Vertrag, in dessen Mittelpunkt mögliche Herausga­be­gründe für den Software-Quellcode konkret definiert sind“, erläutert Stephan Peters, der die Münchener Escrow-Agentur Deposix leitet. Das Modell der doppelten Treuhand soll sicherstellen, dass Anwender ihre Software weiterpflegen können und dass der geheime Quellcode nur bei bestimmten Bedingungen wie einer Insolvenz übergeben wird. „Somit sind beide Parteien auf der sicheren Seite“, sagt Peters.

Als Escrow-Agent übernehmen Firmen wie Deposix, Hanse Escrow, SEI und NCC das Material vom Entwickler. Hinzu kommen einige Anwaltskanz­leien, die sich auf das Thema speziali­siert haben. Differen­zie­rungs­merkmal im Markt ist die Prüfung der Software durch eine technische Verifizie­rung auf Vollstän­dig­keit und Brauchbar­keit. „Dann lagern wir aktuelle und zukünftige Versionen des Programms sicher ein und garantieren dem Lizenznehmer im Notfall jederzeit Zugriff auf den Quellcode“, erläutert Deposix-Manager Peters.

Cloud-Modell verschärft Risikobe­trach­tung

Das deutlich jüngere Cloud Escrow hat grundsätz­lich die gleiche Aufgabe, allerdings mit der zusätzli­chen Herausfor­de­rung, dass die Applikation auf den Servern des Cloud-Providers in der Regel nicht nur für einen Anwender betrieben wird. „Die zentralen Vorteile von Cloud Computing bauen ja gerade auf einer geteilten, mandanten­fä­higen Infrastruktur auf“, sagt Peters. Folglich kann die vom Cloud-Provider entworfene und eingesetzte technische Infrastruktur für einen einzelnen Anwender deutlich überdimen­sio­niert sein, was die Herausgabe und den Nachbau über das Escrow-Modell wirtschaft­lich schwieriger macht.

Zudem dreht sich Cloud Escrow um die Frage, wie zeitkritisch eine Wiederher­stel­lung des Dienstes ist und mit wie viel potenziellem Datenver­lust der Anwender auskommen könnte. „Das Risiko-Management des Anwenders muss definieren, welche Downtime und welcher Zeitraum eines Datenver­lusts aus Geschäfts­sicht noch akzeptabel wären“, erläutert der Deposix-Manager. Hinzu kommt die extrem komplexe Wertschöp­fungs­kette in der Cloud: Der Endanwender abonniert beispiels­weise einen Dienst, zahlt dafür monatlich an Plattform­be­treiber, nutzt eine Cloud-Entwicklungs-Plattform, bezieht Big-Data-Analysen eines weiteren Dienstleis­ters und verwendet dabei eine Lizenz der Apache Foundation.

Das Ineinander­greifen der Applikationen, Entwicklungs­um­ge­bungen und Services verdeutlicht, welchen neuen Herausfor­de­rungen sich Anwender, Lieferanten und Escrow-Agenturen gegenüber­sehen, wenn sie die Folgen des Ausfalls eines Gesamtsys­tems oder einzelner Komponenten eindämmen wollen. „Sie müssen eine technisch versierte Person mit dem hinterlegten Material in die Lage versetzen, den Service ohne Mithilfe Dritter nachzubauen“, sagt Peters. Ziel sei es, auch bei dem Ausfall eines Lieferanten Fehler beheben und zusätzliche Funktiona­li­täten eigenständig einarbeiten zu können.

Kann man große Anbieter zwingen, den Quellcode herauszu­geben?

Die Schwierig­keit beim Cloud Escrow liegt darin, dass die einzelnen Bausteine der „Lösung“ präzise identifi­ziert, isoliert und gesichert werden, um sie einlagern und reproduzieren zu können. „Dies wird nicht für alle Elemente von Cloud-Diensten mit einem vertretbaren Aufwand möglich sein“, berichtet Escrow-Experte Peters aus der Praxis. Ein Beispiel seien die Laufzeit­um­ge­bungen (PaaS – Platform as a Service), bei denen meist pragmatisch unterstellt wird, dass sie einfach verfügbar sind. Zudem werden sich zumindest die großen Anbieter kaum darauf einlassen, den Source Code zu hinterlegen.

Allerdings findet hier allmählich ein Umdenken statt: Escrow etabliert sich als eine Art Gütesiegel, um potenziellen Kunden die Angst vor dem Daten- und Kontroll­ver­lust in der Cloud zu nehmen. Das lohnt sich auch für die Anbieter, denn schließlich bringen die Geschäfts­mo­delle hinter den Cloud-Services auch den Lieferanten viele Vorteile im Wettbewerb.

Datensiche­rung in der Cloud

Unternehmen sind für die Fortführung ihrer Geschäfte vom umgehenden Zugriff auf ihre Daten abhängig. Das gilt auch in einem Cloud-Szenario. Somit muss auch die grundsätz­liche Sicherung des individu­ellen Datenbestandes geregelt sei. Neben der physisch-elektroni­schen Übermitt­lung vom Cloud-Provider in eine gesicherte Infrastruktur sollte dies auch Tests umfassen, ob die übertragenen Daten durch den Anwender überhaupt technisch verarbeitet werden können.

Zur Sicherung der eigenen Anwendungs­daten aus der Cloud heraus muss der Anwender fünf Punkte klären und sein Sicherheits­ni­veau abwägen. Dies kann in den meisten Fällen nur in enger Zusammen­ar­beit mit dem Cloud-Provider sowie im Rahmen der technischen Möglichkeiten gelöst werden.

1. Datensiche­rung: Ist ein Datenexport pro Anwender bereits vorgesehen oder erfordert der Datenexport eine individu­elle Programmie­rung? Wer soll die Daten erhalten: der Anwender, die Escrow-Agentur oder eine sonstige dritte Partei? Und wie werden die Daten technisch sowie rechtlich übertragen?

2. Quantität: Welche Art der verarbei­teten Daten können und sollen exportiert werden: Eingabedaten der Anwender, alle Service-intern generierten Daten oder nur Ausgabedaten?

3. Qualität: In welcher Form werden die Daten übertragen, beispiels­weise durch einen unformatierten Data Dump, strukturiert in einer „intelligen­ten“ Form oder in dem möglicher­weise proprietären Datenformat des Cloud-Providers? Wird die Datenqua­lität regelmäßig kontrolliert?

4. Zeit: Reicht ein Export bzw. eine Sicherung aller Daten einmalig pro Monat, sollen die Daten täglich gezogen werden oder ist sogar eine Echtzeit­si­che­rung notwendig?

5. Kosten: Rechnet sich der Aufwand für die Datensiche­rung mit den gewünschten Parametern überhaupt? Aufwand und erzielter Nutzen müssen sich wie immer die Waage halten.