Cyberresilienz
Souveräne Notfallpläne: Der blinde Fleck der Cyberresilienz
Kubermatic weist auf blinden Fleck der Cyberresilienz hin
Manchmal braucht es nur einen einzigen Ausfall, um eine ganze Branche daran zu erinnern, wie physisch die „Cloud“ eigentlich ist. Genau das ist in der vergangenen Woche passiert, als Rechenzentren von Amazon Web Services im Nahen Osten teilweise offline gingen. Zwei von drei Verfügbarkeitszonen der Region me-central-1 waren betroffen – und plötzlich standen 109 Dienste still.
Banken konnten ihre Systeme nicht erreichen, Fahrdienst-Apps funktionierten nicht mehr, KI-Plattformen waren nicht verfügbar. Für viele Unternehmen fühlte sich die Situation an wie ein digitaler Stromausfall. Die naheliegende Empfehlung des Cloud-Anbieters: Workloads in andere Regionen migrieren. Doch genau an dieser Stelle beginnt das eigentliche Problem.
Wenn Resilienz auf Regulierung trifft
Viele Unternehmen fragen sich in solchen Momenten: Wohin sollen wir überhaupt migrieren? Nach Irland? Virginia? Singapur?
Für internationale Unternehmen klingt das zunächst logisch. Doch für Organisationen im Nahen Osten – etwa Banken oder Finanzdienstleister – ist das oft gar keine Option. Der Grund sind nationale Datenschutz- und Finanzregulierungen.
Darauf weist auch Sebastian Scheele hin, CEO und Co-Gründer des Hamburger Cloud-Unternehmens Kubermatic . Seiner Einschätzung nach offenbart der Vorfall einen blinden Fleck in der Cyberresilienz vieler Organisationen.
Denn zahlreiche Gesetze schreiben klar vor, wo Daten gespeichert werden dürfen:
- Das saudi-arabische Datenschutzgesetz PDPL verbietet die Übertragung personenbezogener Daten ins Ausland ohne Genehmigung.
- In den Vereinigten Arabischen Emiraten verlangt die Bankenaufsicht, dass Finanzdaten innerhalb der Landesgrenzen bleiben.
- Bahrains Datenschutzgesetz fordert eine explizite Einwilligung für grenzüberschreitende Datenübermittlungen.
Das Ergebnis:
Ein CTO einer Regionalbank steht plötzlich vor einer extremen Entscheidung.
- Offline bleiben und Millionenverluste pro Stunde riskieren.
- In eine andere Cloud-Region migrieren und möglicherweise gegen regulatorische Anforderungen verstoßen. Beides ist keine wirklich gute Option.
Der blinde Fleck vieler Souveränitätsstrategien
Viele aktuelle Regulierungsrahmenwerke beschäftigen sich ausführlich mit Datensouveränität – etwa:
- NIS2 Directive
- Personal Data Protection Law
- Dubai International Financial Centre
- Abu Dhabi Global Market Doch sie alle haben eine gemeinsame Schwäche: Sie definieren den Normalbetrieb.
Sie legen fest, wo Daten gespeichert werden müssen – aber nicht, was passiert, wenn eine Cloud-Region plötzlich nicht mehr verfügbar ist und ein Anbieter seine Kunden zum spontanen Umzug auffordert. Genau diese Situation hat der Ausfall im Nahen Osten sichtbar gemacht.
Drei architektonische Lehren für Unternehmen
Aus Sicht vieler Cloud-Architekten lassen sich aus dem Vorfall drei wichtige Erkenntnisse ableiten.
1. Multi-AZ schützt nicht vor regionalen Ausfällen
Ein Multi-Availability-Zone-Ansatz sorgt für Ausfallsicherheit bei Hardware- oder Rechenzentrumsproblemen. Doch wenn eine gesamte Region ausfällt, sind meist alle Zonen betroffen. Resilienzstrategien müssen daher auch regionale Störungen einplanen – etwa Stromausfälle, Netzprobleme oder geopolitische Ereignisse.
2. Datensouveränität ist eine Architekturentscheidung
Souveränität ist nicht nur eine Compliance-Checkliste. Wenn eine Organisation ihre Daten ausschließlich bei einem Anbieter in einer einzigen Region betreibt, entsteht ein klassischer Single Point of Failure. Multi-Region- oder Multi-Cloud-Architekturen sind komplexer im Betrieb – aber sie sind oft die einzige Möglichkeit, regionale Ausfälle zu überstehen, ohne gegen regulatorische Vorgaben zu verstoßen.
3. Jede Organisation braucht einen Exit-Plan
Unternehmen sollten sich eine einfache, aber entscheidende Frage stellen: Was passiert, wenn mein Cloud-Anbieter mich plötzlich auffordert, diese Region zu verlassen? Wer darauf keine dokumentierte Antwort hat, besitzt faktisch keinen vollständigen Notfallplan.
Die Cloud ist kein abstrakter Ort
Der Begriff „Cloud“ vermittelt oft das Gefühl von etwas Schwerelosem, Unendlichem. Doch in Wirklichkeit besteht sie aus Beton, Silizium und Kupfer – in Gebäuden mit klaren Adressen. Der Vorfall im Nahen Osten hat das wieder deutlich gemacht. Infrastrukturplanung darf sich deshalb nicht nur auf Verfügbarkeits-SLAs konzentrieren. Sie muss auch Regulierung, Datensouveränität und Notfallszenarien zusammendenken. Oder anders gesagt: Souveränität endet nicht beim Datenschutz – sie beginnt im Notfallplan.
