Wissensraum · Deep Dive 11 von 22
Cloud-Resilienz unter DORA
Warum Architektur entscheidend ist — nicht das Provider-Versprechen
Multi-Zone vs. Multi-Region · Exit-Strategien · Vendor Lock-in · Shared Responsibility · Abhängigkeits-Mapping
Was dieser Deep Dive Ihnen zeigt
Warum Cloud-Resilienz unter DORA mehr verlangt als Verfügbarkeits-SLAs – und welche Anforderungen an Exit-Strategien, Auditierbarkeit und Drittanbieter-Steuerung bestehen.
Cloud-Infrastrukturen werden häufig mit hoher Verfügbarkeit gleichgesetzt. DORA stellt jedoch klar: Die Nutzung von Cloud-Services garantiert keine automatische Resilienz.
Cloud kann ein wirksamer Baustein operativer Resilienz sein – sofern die zugrunde liegende Architektur entsprechend gestaltet ist. Die Nutzung eines Cloud-Providers entbindet das auslagernde Unternehmen nicht von seiner regulatorischen Verantwortung für Verfügbarkeit, Wiederanlauf und Steuerbarkeit. Daneben trägt der Provider seine eigenen gesetzlichen und vertraglichen Verantwortlichkeiten.
1. Reifegrade der Cloud-Resilienz
A) Single-Zone-Architektur (für kritische Funktionen in der Regel nicht ausreichend)
Betrieb in einer einzigen Availability Zone (eine Region genügt nicht automatisch; entscheidend ist die Zonen-/Regionsredundanz)
Zentrale Abhängigkeiten
Backups in derselben Zone
Einordnung
Fällt diese Zone aus, sind Systeme und Daten gleichzeitig betroffen. Ein Betrieb über mehrere Zonen einer Region schützt vor Zonen-, nicht vor vollständigen Regionsausfällen.
B) Multi-Zone-Architektur (verbreiteter Standard)
Nutzung mehrerer Availability Zones
Redundante Komponenten
Erste belastbare Resilienzschicht
Einordnung
Schützt vor lokalen Störungen, nicht jedoch vor regionalen oder systemischen Ausfällen.
C) Multi-Region- bzw. risikobasierte Architektur (DORA-orientierter Ansatz)
Ausfallsicherheit über Regionen hinweg
Getrennte Kontroll- und Wiederanlaufpfade
Dezentral gespeicherte Backups
Klare Trennung kritischer Funktionen
Hinweis DORA schreibt keine Multi-Cloud-Architektur vor. Unternehmen müssen jedoch nachvollziehbar begründen, warum ihre gewählte Architektur für das jeweilige Risikoprofil ausreichend ist.
2. Welche Anforderungen sich aus DORA ergeben
Transparenz über technische Abhängigkeiten
Dokumentierte und realistische Recovery-Strategien
Regelmäßig getestete Wiederherstellungs-, Umschalt- oder Ersatzmechanismen entsprechend der vorgesehenen Architektur
Exit- und Substitutionsstrategien für Cloud-Dienste, die kritische oder wichtige Funktionen unterstützen
Gesicherte Datenportabilität
Transparenz über Subdienstleister des Cloud-Providers
Einbindung der Cloud-Architektur in Governance- und Risikosteuerung
3. Typische Schwachstellen in der Praxis
Backups in derselben Zone oder Region („verdeckte Single Points of Failure“)
Failover-Mechanismen, die nie realistisch getestet wurden
Unzureichend segmentierte IAM-Strukturen in Cloud-Umgebungen
Fehlende Exit- oder Fallback-Konzepte bei Provider-Ausfällen
Mangelnde Überwachung kritischer Zonen und Komponenten
Nicht dokumentierte Abhängigkeiten zwischen Microservices
4. Fallstudie
Ausgangslage
Ein FinTech betreibt seine Systeme vollständig auf einer Public-Cloud-Plattform. Zwei Availability Zones und automatisiertes Failover vermitteln den Eindruck hoher Resilienz.
Was passiert
Eine regionale Störung führt dazu, dass beide Zonen gleichzeitig beeinträchtigt sind, das automatische Failover nicht greift und Datenbank-Replikate inkonsistent werden.
Die Analyse zeigt
Backups liegen ebenfalls in derselben Region
Keine dokumentierte manuelle Recovery-Prozedur vorhanden
Ein Cold-Standby in einer anderen Region wurde nie eingerichtet
Konsequenzen
Mehrstündiger Systemausfall
Potenziell meldepflichtiger Incident
Anforderung einer detaillierten Architekturübersicht durch die Aufsicht
Erhebliche Reputationsschäden
Praxis-Impuls
Cloud-Resilienz entsteht nicht durch Vertragszusagen oder Marketing-Versprechen. Stellen Sie die Frage: Haben wir unseren Cloud-Failover je unter realen Bedingungen getestet – nicht simuliert, sondern tatsächlich durchgeführt? Unter DORA gilt: Resilienz ist gestaltet – nicht ausgelagert.
Was bleibt
Cloud-Resilienz ist nicht Verfügbarkeit, sondern Kontinuität. Unter DORA gilt: Kritische oder wichtige Funktionen müssen entsprechend den festgelegten Kontinuitätszielen aufrechterhalten oder innerhalb der definierten Wiederanlaufzeit (RTO) wiederhergestellt werden können. Das bedeutet: risikobasierte Architektur, Backup-Pfade, nachweisbare Recovery-Szenarien – nicht nur SLA-Versprechen.
Exit-Fähigkeit ist ein Architektur-Problem. Wenn Sie heute aus der Cloud aussteigen müssten, wie lange würde es dauern? Wie viele Daten sind im proprietären Format gebunden? Unter DORA müssen Sie das vorausdenken, nicht nachdenken.
Drittanbieter-Abhängigkeiten sind Ihre Abhängigkeiten. Der Cloud-Provider bleibt ein externer ICT-Drittdienstleister; seine Dienste und Abhängigkeiten müssen jedoch in Ihre Risiko- und Kontinuitätssteuerung einbezogen werden. DORA verlangt: dokumentieren, bewerten, monitoren, kontrollieren, testen – regelmäßig.
Auditierbarkeit gehört bei kritischen oder wichtigen Funktionen zu den Vertragsanforderungen. Generische Datenschutzerklärungen genügen nicht mehr. Vertrag und Kontrollmodell müssen ausreichende Nachweise über relevante Zugriffe, Kontrollen und Sicherheitsereignisse ermöglichen – abgestuft nach Vertragsart und begrenzt durch Mandantentrennung, Datenschutz und den Schutz anderer Kunden.