TechnikCloud Escrow

Rettungsanker 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 Verhandlungsposition gegenüber dem Insolvenzverwalter zu verbessern.

13. November 2014

Nomen est Omen – im vergangenen Herbst musste der Cloud-Provider Nirvanix seinen Betrieb einstellen. Das Unternehmen hatte einen riesigen Speicherplatz in der Cloud geöffnet, Partner waren IBM und Intel, zu den Referenzkunden 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 herunterzuladen. 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 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.

Wenn der Cloud-Provider vom Himmel fällt?

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

Im Cloud-Modell erwirbt der Anwender kein dauerhaftes Nutzungsrecht, sondern zahlt nutzungsabhängig für bestimmte Funktionen oder Dienste – eben „as a Service“ bzw. „on Demand“. Da diese Dienste und die dabei generierten Anwendungsdaten zunächst vollständig auf der Infrastruktur des Cloud-Providers laufen, könnte der Zugriff – zumindest theoretisch ohne Eigenverschulden des Anwenders und ohne jegliche Vorwarnung – von einer Sekunde auf die andere unterbrochen werden. Das gilt auch für den Fall, dass von Dienstleistern individuell programmierte Anwendungen zur Verbindung verschiedener interner oder externer Cloud-Services nicht mehr weiterbetrieben werden können, weil niemand zur Wartung und Pflege auf den Quellcode zugreifen kann.

Neutraler Agent als Vermittler

Als letzter Rettungsanker hat sich das so genannte „Cloud Escrow“ herausgebildet, das sich vom altfranzösischen Wort für „Schriftrolle“ ableitet und aus dem klassischen Software-Lizenzgeschäft bekannt ist. „Ein Anwenderunternehmen schließt zusammen mit seinem Entwickler und einem neutralen Escrow-Agenten einen Vertrag, in dessen Mittelpunkt mögliche Herausgabegrü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 Anwaltskanzleien, die sich auf das Thema spezialisiert haben. Differenzierungsmerkmal im Markt ist die Prüfung der Software durch eine technische Verifizierung auf Vollständigkeit und Brauchbarkeit. „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 Risikobetrachtung

Das deutlich jüngere Cloud Escrow hat grundsätzlich die gleiche Aufgabe, allerdings mit der zusätzlichen Herausforderung, 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, mandantenfähigen Infrastruktur auf“, sagt Peters. Folglich kann die vom Cloud-Provider entworfene und eingesetzte technische Infrastruktur für einen einzelnen Anwender deutlich überdimensioniert sein, was die Herausgabe und den Nachbau über das Escrow-Modell wirtschaftlich schwieriger macht.

Zudem dreht sich Cloud Escrow um die Frage, wie zeitkritisch eine Wiederherstellung des Dienstes ist und mit wie viel potenziellem Datenverlust der Anwender auskommen könnte. „Das Risiko-Management des Anwenders muss definieren, welche Downtime und welcher Zeitraum eines Datenverlusts aus Geschäftssicht noch akzeptabel wären“, erläutert der Deposix-Manager. Hinzu kommt die extrem komplexe Wertschöpfungskette in der Cloud: Der Endanwender abonniert beispielsweise einen Dienst, zahlt dafür monatlich an Plattformbetreiber, nutzt eine Cloud-Entwicklungs-Plattform, bezieht Big-Data-Analysen eines weiteren Dienstleisters und verwendet dabei eine Lizenz der Apache Foundation.

Das Ineinandergreifen der Applikationen, Entwicklungsumgebungen und Services verdeutlicht, welchen neuen Herausforderungen sich Anwender, Lieferanten und Escrow-Agenturen gegenübersehen, wenn sie die Folgen des Ausfalls eines Gesamtsystems 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 Funktionalitäten eigenständig einarbeiten zu können.

Kann man große Anbieter zwingen, den Quellcode herauszugeben?

Die Schwierigkeit beim Cloud Escrow liegt darin, dass die einzelnen Bausteine der „Lösung“ präzise identifiziert, 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 Laufzeitumgebungen (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 Kontrollverlust in der Cloud zu nehmen. Das lohnt sich auch für die Anbieter, denn schließlich bringen die Geschäftsmodelle hinter den Cloud-Services auch den Lieferanten viele Vorteile im Wettbewerb.

Datensicherung 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ätzliche Sicherung des individuellen Datenbestandes geregelt sei. Neben der physisch-elektronischen Übermittlung 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 Anwendungsdaten aus der Cloud heraus muss der Anwender fünf 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.

1. Datensicherung: Ist ein Datenexport pro Anwender bereits vorgesehen oder erfordert der Datenexport eine individuelle Programmierung? 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 verarbeiteten 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, beispielsweise durch einen unformatierten Data Dump, strukturiert in einer „intelligenten“ Form oder in dem möglicherweise proprietären Datenformat des Cloud-Providers? Wird die Datenqualitä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 Echtzeitsicherung notwendig?

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