Cloud – zu Risiken und Nebenwirkungen …

Cloud-Risiken minimieren durch digitale Souveränität

Fragen Sie Ihre Agentur und deren Provider.

Sie kennen sicher den Textbeginn: “Die besten Geschichten schreibt das Leben selbst“. Viele hören das nicht gerne, insbesondere nicht Autoren, Journalisten oder Schriftsteller. Und dennoch ist es manchmal genau so, vor allem wie im Fall dieses Beitrags, in welchem ich über „Cloud Risiken“ berichte. Doch ich sollte vielleicht von vorne beginnen. Denn ich bin sicher, dass auch Sie hinterher meine Einleitung teilweise oder ganz bestätigen werden. Also: wir beschäftigen uns ja unter anderem stark mit diesen beiden Themen:

Digitale Souveränität und Datensicherung bzw. Backup

Beide gehören zu meinen persönlichen Lieblingsthemen. Als wir neulich über der Newsletter- und Webcast-Themenplanung für das zweite Quartal 2022 brüteten, versuchte ich, mal wieder etwas über „Digitale Souveränität“ bzw. Unabhängigkeit generell im Kontext von Geschäftsentwicklung unterzubringen. Als Aufhänger wollte ich die unglaubliche deutsche Naivität im Umgang mit Gas- und Erdöl-Versorgung in den letzten 20 Jahren benutzen. Letztlich haben wir auf diesen Einstieg verzichtet und einen anderen gewählt. Oder genauer: Diesen Einstieg haben wir uns von der aktuellen Nachrichtenlage vorschlagen lassen. Letztlich haben wir unsere Gedanken im Schlagwort „Cloud Risiken“ zusammengefasst.

Die „Vorrede“

Nun komme ich zu meinem Thema, sogar ohne jeden weiteren Umweg. Und das geht so: Seit dem 5. April 2022 sind die weit verbreiteten Organisations-Tools des Anbieters „A“, die Softwares „J“, „C“ und einige weitere in ihrer Cloud-Version nicht mehr erreichbar. Diesen Beitrag habe ich am 13.04.2022 verfasst und dabei bewusst auf die konkrete Benennung der Beteiligten verzichtet. Der Anbieter hatte bis zum Zeitpunkt der Veröffentlichung das Ausfall-Problem immer noch nicht im Griff.

Wichtig zu wissen

Diese Werkzeuge gehören zu den verbreitetsten ihrer Art in einem typisch „kritischen Geschäftsprozess“. Denn sie werden häufig im Umfeld von Entwicklung, auch Software-Entwicklung eingesetzt. „J“ ist ein Ticketsystem, „C“ ist eine Wiki-Lösung. Nun sind beide nicht irgendwelche Software, die halt für längere Zeit nicht erreichbar sind. Mit den beiden Softwares werden ganze Unternehmen aller Grössenordnungen zentral verwaltet. Ohne diese sind viele Unternehmen nicht in der Lage, ihre Prozesse zu verwalten. Man kann durchaus sagen, dass Software- oder Entwicklungs- oder andere prozessorientierte Firmen bei Ausfall solch zentraler Werkzeuge arbeitsunfähig sind.

Zum Kern über den Zusammenhang von „digitaler Souveränität“, „Backup“, „Datensicherung“ und „Cloud Risiken“

Soweit zur Vorrede. Kommen wir zum „Eingemachten“. Was hat das alles zu tun mit „Digitaler Souveränität“ oder dem Unterschied zwischen „Backup“ und „Datensicherung“? Fangen wir an mit dem ersten Thema, denn es ist von grundlegender Bedeutung für die planmässige Erreichung von Unternehmenszielen.

Digitale Souveränität

Als Unternehmer möchte ich, dass das Unternehmen auf die von mir geplante Art und Weise funktioniert. Das lässt sich umso besser realisieren, als die strategischen Entscheidungen IM Unternehmen fallen. Je mehr diese Fähigkeit verloren geht, desto mehr wird mir auch die Entwicklungsmöglichkeit aus der Hand genommen.

Im Klartext bedeutet dies, dass zentrale Werkzeuge von hoher strategischer Relevanz eher nicht von Dritten beeinflusst werden sollten. Wenn ich es einem Aussenstehenden überlasse, ob meine Fahrzeuge fahren oder nicht oder ob meine Verwaltungssoftware bereit steht, dann bin ich in meinem betrieblichen Handeln eben NICHT souverän.

Mir ist klar, dass es die absoluten, 100 prozentigen Lösungsansätze selten, in manchen Umgebungen gar nicht gibt. Dennoch habe ich es in der Hand, für welchen Lösungsansatz oder Anbieter ich mich entscheide. Wenn wesentliche Kriterien nicht zu meinen Ansprüchen passen, MUSS ich eine Alternative suchen. Und die gibt es in den allermeisten Fällen.

„Ab in die Cloud“ als riskante Zwangsmaßnahme

Hier war es so, dass der Anbieter der genannten Softwarelösungen bis vor kurzem noch zwei Alternativen zur hier betroffenen Cloud-Variante anbot. Einmal die sogenannte On-Prem-Lösung (also zum selber betreiben auf dem eigenen Server) und die DataCenter-Lösung. Diese beiden Betriebsmodelle wurden aufgegeben bzw. durch eine preislich extreme Kosten-Erhöhung für den Kunden unrentabel gemacht. Der Anbieter drängte also seine Kunden in die Cloud. Damit lässt sich zwar mehr Gewinn erzielen, jedoch ist die Betriebssicherheit sehr oft nicht vergleichbar mit einer professionellen Hosting-Lösung. Ach so? Cloud wird doch immer als extrem sicher und stabil im Betrieb bezeichnet? Wie kam es dennoch zu dem initialen Ausfall und danach zu der mittlerweile mehr als einwöchigen Auszeit?

Daran hat´s gelegen

Die eigentliche Ursache war laut Anbieter ein Fehler in einem Service-Script. Dadurch löschte man nicht etwa, wie geplant ausschließlich nicht mehr benötigte Daten (Legacy-Daten) sondern verschob sie in den „Kernspeicher“ (Wer kann mir erklären, was das hier bedeutet? Wir vermuten: „Papierkorb-Funktion“), sondern auch andere wie zum Beispiel: Zugangsdaten, Profile und mehr. Das führte letztlich zum Ausfall. Wie bereits beschrieben mit dem Resultat, dass alle betroffenen Kunden, das sind ziemliche viele und auch große, seit Tagen ohne Ticketsystem und Wikis für ihr Prozessmanagement dastehen.

Halt! Fehler machen wir alle …

Bevor nun ein Shitstorm gestartet wird: Solche Programmierfehler sind schon jedem untergekommen, der programmiert hat. Und sei es nur ein mehr oder weniger umfangreiches (hier sicher letzteres) Skript. Was aber zum Handwerk eines jeden Programmierers gehören sollte, fängt mit Test an und hört mit Test auf. Das ist ganz offensichtlich hier nicht passiert. Ob es nun vergessen wurde oder ob es keine Testumgebung gab, ist nicht bekannt und auch gänzlich irrelevant. Denn dieses Serviceskript hätte so niemals laufen dürfen. Punkt.

Aus einer Mitteilung des Geschäftsführers von “A“ geht hervor, dass das Team, das den Prozess plante, nicht mit dem Team kommunizierte, das die geplanten Service-Arbeiten durchführen sollte. Hier geht es um Projektplanung im konkreten Sinne. „A“ ist in genau diesem Bereich als Anbieter von Softwarelösungen aktiv. Es scheint so, als würden die eigenen Werkzeuge nicht verwendet. Das gibt viel Spielraum für Interpretationen.

Für unser Thema spannend

Wie gesagt, dieser Fehler betraf und betrifft nun viele Kunden. Wäre derselbe Fehler innerhalb der DataCenter-Version passiert, hätte er idealerweise exakt einen Kunden oder mehrere betroffen. Gleiches trifft bei der sogenannten On-Prem-Lösung zu. Doch der mögliche Schaden ist bei Cloud-Lösungen immer größer als bei allen anderen Varianten. Schließlich ist die angeblich höhere Sicherheit bei Cloud-Lösungen nur in Ausnahmefällen real. Wenn also eine für das Unternehmen essentielle Software zu betreiben ist, sollte diese nicht als Cloudlösung realisert sein.

In einem IT-Forum wurde den Kunden von „A“ nun vorgeworfen, dass sie ja ein Backup hätten anlegen können. Dies hätten sie leider versäumt und müssten nun halt mit den Konsequenzen leben. Doch dummer Weise ist es bei derartigen Cloud-Angeboten regelmässig für die Anwender nicht möglich, ein Backup zu erstellen, da dies nur bei vollem Zugriff auf die Datenbank und die Software möglich ist. Hier haben wir also ein Systemproblem. Denn die Cloud – eigentlich müsste man in diesem Fall von SasS, also Software as a Service reden – bedeutet eben im Normalfall für den Kunden Verzicht auf eigene Sicherungsmassnahmen. Er muss sich in jeder Hinsicht auf den Service-Anbieter verlassen. Und das bedeutet eben auch für die Anforderung „digitale Souveränität“: Null, also nicht vorhanden. Genau dies ist eine der größten Cloud Risiken.

Datensicherung vs Backup

Kommen wir zum Thema Backup vs. Datensicherung, auch dies wieder betrachtet am Beispiel des oben angeführten Service-Ausfalles. Der Anbieter schreibt, dass derzeit einzelne Accounts der einzelnen Kunden der Reihe nach wieder hergestellt werden. Zu Beginn der Reparatur-Maßnahmen war es nur möglich, je einen Account zu einer Zeit zu bearbeiten. Mittlerweile sind wohl mehrere gleichzeitig möglich. Der Geschäftsführer schrieb heute, also nach mehr als zehn Tagen, dass es noch 14 Tage dauern würde, bis alle Accounts bearbeitet sein würden. Die Formulierung „vollständige Wiederherstellung“ oder vergleichbar findet man übrigens nirgends.

Ich trete kurz zurück und betrachte diese Schilderung im Geiste. Was genau steckt hinter „einer nach dem anderen“ bzw. „Kunde für Kunde“? Das sieht stark nach Handarbeit aus. Genau so funktioniert normale Rücksicherung aus einer Datensicherung im schlimmsten Fall. Das dauert bei einem Totalverlust von Daten dann eben SEHR lange, weil sehr grosse Datenmengen kopiert werden müssen. Das ist normal bei dieser Methode. Und da sind wir dann auch bei einem wesentlichen Unterschied im Vergleich zum Backup. Anders als umgangssprachlich verwendet ist Backup ein vollständiger, selbständig einsetzbarer Ersatz. Und der wird „einfach“ nur gestartet, wenn er gebraucht wird.

Beispiele für echtes Backup

Hier seien beispielhaft genannt: Netzersatzanlage im Umfeld von Rechenzentren. Das sind dann eben (in der Regel: Schiffs-) Diesel-Aggregate, die bei Ausfall der normalen Stromnetzversorgung ebendiesen „ersetzen“, nachdem vorher für einige Minuten die USV gearbeitet hat. Oder der BB-ONE.net eigene Service „ActiveBackup“ als Standard unserer individualisierten Managed Hosting Angebote. Hier wird ein Spiegelserver für den ausgefallenen Live-Server gestartet. Das dauert Sekunden bis wenige Minuten.