Stand: 14.04.2022
Eigentlich wolle ich nicht noch einen Beitrag zum Thema der vollkommen übertriebenen Versprechen und Hoffnungen von Cloud-Services (SaaS 2) schreiben. Aber die jüngsten Ereignisse – Anfang April 2022 – rund um die Services von Atlassian zeigen sehr deutlich, wie banal die viel beschworene Cloud-Magie zurück auf den Boden des IT-Alltags geholt wird.

Recap zu Atlassian
Das Unternehmen Atlassian aus Australien nutzt eine AWS 1-Infrastruktur, um seine eigenen Services als SaaS in der Cloud anzubieten. Die bekanntesten zwei Softwarelösungen sind zum einen Jira, eine Software zur Fehlerverwaltung, Problembehandlung und zum operativen Projektmanagement und zum anderen Confluence, eine kommerzielle Wiki-Software, die von Atlassian entwickelt wurde. Beide Produkte und noch einige andere werden von zahlreichen Unternehmen umfangreich eingesetzt. Insbesondere hat der Hersteller vor etwa zwei Jahren Schlagzeilen damit gemacht, dass er bestehende On-Premises-Installationen prohibitiv verteuerte bzw. gar nicht mehr anbot, um seine Kunden in die Cloud zu zwingen.

In A Nutshell: Was ist passiert?
Atlassian hat kürzlich mit einem Skript versucht, alte Daten von seinen auf AWS laufenden Systemen zu entfernen. Offensichtlich ist dabei etwas gründlich schief gegangen, denn es wurden versehentlich nicht nur aktive Kundendaten, sondern auch korrespondierende Informationen zu gebuchten Produkten, Nutzern und Drittanbieteranwendungen gelöscht. Das klingt wirklich schlimm. Und das ist es auch. Vor allem deshalb, weil nach über einer Woche immer noch nicht klar ist, ob Daten unwiederbringlich verloren sind oder ob sie eventuell doch noch aus vorhandenen Sicherheitskopien wiederhergestellt werden können. Klar ist, dass dieser Vorgang noch bis zu zwei weiteren Wochen dauern kann. Denken Sie jetzt: „Wie bitte? Das wären ja in Summe circa vier Wochen? Ich dachte, das ist alles Cloudtechnologie und total sicher?“ Dann kann ich Ihnen nur sagen: Willkommen in der Realität!

Ohne die ganze Wahrheit dieses Falls zu kennen, liegt aber die Vermutung nahe, dass das besagte Skript direkt auf der Infrastruktur ausgeführt wurde. Also nicht über die Applikationsschicht, die entsprechende Sicherheitsmechanismen liefern sollte, um ein solches Desaster zu verhindern. Das berühmte Vier-Augen-Prinzip, gewissermaßen der De-facto-Standard für heikle IT-Operationen und Systemzugriffe, sollte auch in der Cloud gelten.

In diesem Zusammenhang kann man gar nicht oft genug wiederholen, dass jedes Angebot aus der Cloud eben keine Magie ist. Am Ende des Tages handelt es sich bei der „Cloud“ um Computer, die wie alle anderen Computer von Fehlern oder sonstigen Problemen betroffen sein können. Im konkreten Fall hat es laut Atlassian zwar „nur“ 400 Kunden erwischt, was allerdings ein sehr schwacher Trost ist, wenn man selbst zu diesem Kreis gehört und sich auf die vollmundigen Versprechen des Anbieters verlassen hat.

Aber was hat der Anbieter denn tatsächlich versprochen?
Ich habe mal auf der Homepage von Atlassian (Stand 14. April 2022) nachgeschaut:

• Atlassian:
  „Im Mittelpunkt unserer Arbeit steht (…) das Vertrauen unserer Kunden, und Sicherheit hat für uns oberste Priorität. Mit unserem transparenten Sicherheitsprogramm wollen wir erreichen, dass du dich bei der Nutzung unserer Produkte und Services ausreichend informiert und sicher fühlst.“

Ob sich die Kunden gut informiert fühlen, kann ich nicht beurteilen. Der Shitstorm, der zeitweise auf Twitter zu diesem Thema zu lesen war, lässt anderes vermuten. Allerdings sind diese öffentlichen Kommentare immer mit Vorsicht zu genießen. Ob sich die Kunden jedoch angesichts des Datenverlustes und einer mehrwöchigen Störung immer noch „sicher“ fühlen, wage ich stark zu bezweifeln.

• „Änderungsmanagement in unserer Umgebung -
  Wir (...) verfolgen einen Ansatz im Open-Source-Stil, den wir "Peer Review, Green Build" (PRGB) nennen. Im Gegensatz zu herkömmlichen Änderungsmanagementprozessen verlangt der PRGB-Ansatz, dass jede Änderung – sei es eine Codeänderung oder eine Infrastrukturänderung – von einem oder mehreren Mitarbeitern überprüft wird, um Probleme zu identifizieren, die möglicherweise durch die Änderungen entstehen können.“

Es gibt eigentlich ein organisatorisches Vier-Augen-Prinzip, das derartige Katastrophen verhindern soll. In der Realität scheint das aber nicht zu funktionieren.

• „Backups -
  Atlassian verfolgt ein umfassendes Backup-Programm. Dies schließt unsere internen Systeme ein, bei denen unsere Backup-Maßnahmen in Einklang mit den Anforderungen zur Systemwiederherstellung erstellt wurden. Wir bieten ebenso umfangreiche Backup-Maßnahmen für unsere Atlassian Cloud-Angebote, insbesondere für Kunden- und Anwendungsdaten. Atlassian nutzt die Snapshot-Funktion von Amazon RDS (Relational Database Service), um automatische tägliche Backups jeder RDS-Instanz anzulegen.“

Es ist gut, ein umfassendes Back-up-Konzept zu haben. Es scheint aber leider so, als funktioniere das hier beworbene Konzept genauso wenig wie das zuvor gepriesene „PRGB“-Vier-Augen-Prinzip.

• „Geteilte Verantwortung bei der Verwaltung von Kundendaten -
  Atlassian übernimmt die Verantwortung für die Sicherheit, Verfügbarkeit und Leistung der von uns bereitgestellten Anwendungen, der Systeme, auf denen sie ausgeführt werden, und der Umgebungen, in denen die Systeme gehostet werden.“

Als Kunde würde ich mich hier fragen, in welcher Form dieser Verantwortung bei einer so langen Störung und gegebenenfalls sogar einem Datenverlust nachgekommen werden soll. Erhalten alle betroffenen Unternehmen nun automatisch ihr Geld zurück, zuzüglich eines Ausgleichs der entstandenen Schäden? Das würde ich jedenfalls als Kunde unter diesem Versprechen verstehen.

• „Kontrolle des Zugriffs auf Kundendaten -
  Für alle Kundendaten gilt dieselbe Vertraulichkeitsstufe und der Zugriff auf diese Daten wird streng kontrolliert. (…) Unser für Wartungs- und Supportprozesse zuständiges Supportteam befolgt strenge Regeln zur Authentifizierung und Autorisierung. Der Zugriff auf die gehosteten Anwendungen und Daten erfolgt zur Überwachung der Anwendungsfunktionen und zur Durchführung der System- und Anwendungswartung oder nach Kundenanfrage über unser Supportsystem. Über unseren Consent Control Checker können Kunden zudem prüfen, welche Supporttechniker im Rahmen einer ausdrücklichen Zustimmung auf ihre Daten zugreifen dürfen.“

Das ist doch mal eine Aussage! Oder sollte diese Behauptung am Ende des Tages nicht ganz korrekt sein? Wenn man auf Kundendaten gar nicht ohne deren Zustimmung zugreifen kann, frage ich mich, warum dann ein Skript ausgeführt werden konnte, dass einfach „Amok läuft“ und wild Datenbanken bzw. Tabellen löscht. Das aktuelle Problem spricht wohl eher dafür, dass Administratoren sehr wohl an irgendwelchen Standard APIs 3 vorbei auf die Daten der Kunden zugreifen können. Alles andere wäre auch etwas erstaunlich. Oder besser gesagt überraschend, denn warum sollte es in der Cloud anders sein als bei einem On-Premises-System? Dieser Vorgang ist ein schönes Beispiel dafür, wie wenig die Realität unter Umständen zu dem passt, was große Anbieter ihren Kunden erzählen.

Unter dem Strich gibt es in der Regel keinerlei verbindliche und gerichtsfeste Zusicherungen der Cloud-Provider für eine echte Verantwortungsübernahme bei ihren SaaS-Angeboten. Im Kleingedruckten ist für gewöhnlich immer manifestiert, dass die Kunden-Verantwortung für eine Systemlösung auch immer beim Kunden allein verbleibt. Ich würde mich wundern, wenn die betroffenen Unternehmen im aktuellen Fall aktiv und freiwillig durch Atlassian entschädigt werden.

1 AWS = Amazon Web Services

2 SaaS = Software as a Service

3 API = Application Programming Interface, standardisierte Programmierschnittstelle