Disaster Recovery im Bankenumfeld Wenn beide Rechenzentren ausfallen

Raiffeisen Informatik sichert Mainframe-Daten auf physisch getrennten Speichersystemen. Damit soll sich die gesamte Anwendungsumgebung nach einem Totalausfall innerhalb von ein bis zwei Stunden wiederherstellen lassen.

Der in Wien ansässige IT-Dienstleister für Banken verarbeitet monatlich eine Milliarde Transaktionen für mehr als drei Millionen Endkunden. Die Frage nach der Ausfallsicherheit, die seine Architekturarbeit in den letzten zwei Jahren bestimmt hat, ist nicht die übliche – wie man Angreifer fernhält –, sondern deutlich pointierter: Was passiert, wenn beide Rechenzentren gleichzeitig ausfallen?

IBM-Systemdesign aus Hardware, Software und Cloud

Power11 verbindet autonome IT mit KI-Beschleunigung

Die Raiffeisen Informatik erbringt IT-Dienstleistungen für einige der größten Finanzinstitute Österreichs, darunter die Raiffeisen Bank International, Raiffeisenlandesbank Niederösterreich-Wien, Raiffeisenlandesbank Burgenland, Raiffeisenlandesbank Vorarlberg und die UNIQA-Versicherungsgruppe. Als konzerneigener IT-Dienstleister innerhalb der Raiffeisen-Bankengruppe unterliegt Raiffeisen Informatik denselben aufsichtsrechtlichen Anforderungen wie seine Bankkunden. Vor diesem Hintergrund hat das Unternehmen in den letzten zwei Jahren seine Disaster-Recovery-Strategie grundlegend überdacht.

Der Auslöser war der „Digital Operational Resilience Act“ (DORA) der Europäischen Union, der im Januar 2025 in Kraft trat. Für Werner Georg Mayer, Geschäftsführer bei Raiffeisen Informatik, war DORA jedoch weniger eine Compliance-Belastung als vielmehr ein nützlicher Spiegel. „DORA ist eine kluge Regelung“, sagt er. „Sie spiegelt wider, was moderne IT tatsächlich bedeutet und auf welchem Reifegrad wir operieren sollten. Das Interessante daran ist, dass es einen zwingt, das tatsächliche Worst-Case-Szenario zu testen, nicht das bequeme.“

Das tatsächliche Worst-Case-Szenario

In der Praxis ist der Worst-Case nicht der Ausfall einer einzelnen Komponente. Es ist der gleichzeitige Ausfall beider Standorte – physisch oder logisch –, wobei die Produktionsdatenbanken auf beiden Seiten betroffen sind. Mayer spricht das ganz offen an. „Manche Institute glauben, ihr Host sei das sicherste System der Welt. Es gibt dokumentierte Beispiele, die das Gegenteil belegen. Beide Standorte ausgefallen, Datenbanken verloren, Ende der Geschichte. Die Frage lautet dann: Wie schnell kann man tatsächlich wieder den Betrieb aufnehmen?“

Für Raiffeisen Informatik hatte diese Frage eine unbequeme Antwort. Die bestehende Architektur war auf dem Papier solide: zwei Produktionsspeichersysteme an zwei Rechenzentrumsstandorten, tägliche FlashCopies, Batch-Backups, die in eine virtuelle Bandbibliothek geschrieben wurden. Die vertraglich vereinbarten Wiederherstellungszeiten betrugen vier Stunden. Angenommen jedoch, ein Angreifer zerstört gleichzeitig alle Festplatten in beiden Rechenzentren, hätte eine vollständige Wiederherstellung aus klassischen Backup-Medien mehrere Tage gedauert.

Der Grund dafür ist struktureller, nicht betrieblicher Natur. Bankumgebungen laufen nach einem 7/24-Transaktionsmodell. Es gibt keinen Zeitpunkt, zu dem ein konsistentes Backup der gesamten Anwendungslandschaft erstellt werden kann. Die Wiederherstellung muss aus einzelnen Tabellen und Forward-Recovery-Verfahren zusammengesetzt werden – bestenfalls halbmanuell. Für eine einzelne Anwendung funktioniert das. Für eine vernetzte Kernbankumgebung, die mehrere Institute bedient, funktioniert es nicht.

Entschlüsselung der Datenverwaltung

Die Integration von Mainframe- und Cloud-Systemen

Von der Perimeterverteidigung zum Recovery-Engineering

Die meisten Diskussionen über Ausfallsicherheit in der Bank-IT drehen sich nach wie vor um Prävention: Wie hält man Angreifer fern, wie verbessert man die Erkennung, wie fügt man eine weitere Verteidigungsebene hinzu? Mayers Team hat die Frage auf den Kopf gestellt. „Wir haben fast alles getan, was wir können, um unsere Daten zu schützen“, sagt er. „Jetzt bereiten wir uns auf den schlimmsten Fall vor. Nicht ‚Wie halten wir sie fern?‘, sondern ‚Wie schnell sind wir wieder einsatzbereit?‘ Das ist eine radikalere Denkweise – und wahrscheinlich auch eine ehrlichere.“

Intern gab das Team diesem Ansatz einen Namen: „Hardcore Resilience“. Der Begriff fasst sowohl den technischen Anspruch als auch den institutionellen Wandel zusammen. Mayer äußert sich auch offen darüber, wo der Rest der europäischen Bankenbranche steht. „Bei IBM-Sicherheitsveranstaltungen zu diesen Themen sieht man niemanden, der so weit fortgeschritten ist wie wir. Die meisten Institute, die ihre Umgebungen vorgestellt haben, haben kleine Systemkonfigurationen eingerichtet, keine vollständigen Anwendungslandschaften.“

Diese Position hat weitreichende Konsequenzen. Raiffeisen Informatik berät nun aktiv andere Unternehmen, darunter einen vergleichbaren Dienstleister in Dänemark, bei der Beantwortung der Frage, die Mayer jedem IT-Leiter einer Bank stellt, der sich an ihn wendet: Gehen Sie davon aus, dass Ihr Host ausfallen kann?

Architektur als Lösung

Die daraus entstandene Architektur geht das Konsistenzproblem direkt an. An beiden Mainframe-Standorten wurden neben dem bestehenden Produktionsspeicher zwei zusätzliche NVMe-basierte Hitachi Vantara VSP 5600-Arrays installiert, die über Dark Fiber verbunden sind.

Produktionsdaten werden kontinuierlich auf eine separate Speicherebene repliziert, die wiederum unveränderliche Snapshots auf einem vierten System erstellt. Der entscheidende Punkt ist, dass diese Snapshots auf physisch getrennten Speichern liegen, auf die der Mainframe nicht zugreifen kann, sodass selbst ein Angreifer mit vollständigen Administratorrechten auf der Produktionsseite sie weder einsehen, ändern noch löschen kann. Snapshots werden alle zwei Stunden geschrieben und können während ihrer Aufbewahrungsfrist nicht überschrieben werden – sie sind physisch „Air gapped” und gleichzeitig logisch schreibgeschützt.

Die technische Innovation, betont Mayer, ist nicht der Snapshot-Mechanismus an sich. Es ist das, was die Architektur ermöglicht. „Ausgehend von einem Snapshot können wir die Anwendungsumgebung mit einem konsistenten Datenzustand innerhalb von ein bis zwei Stunden wiederherstellen. Eine Wiederherstellung der gesamten Anwendungsumgebung auf Datei- oder Datenbankebene dauert Tage, und es ist schwierig oder unmöglich, einen konsistenten Zustand über die gesamte Landschaft hinweg zu erreichen. Snapshots, die auf unveränderlichen Speicher geschrieben werden, können vom Betriebssystem nicht adressiert und daher nicht zerstört werden.“

Zwei Eigenschaften des Snapshot-Ansatzes machen dies möglich. Erstens startet die Wiederherstellungsumgebung direkt vom Snapshot-Speicher aus, ohne dass Daten zurück auf die Produktionshardware kopiert werden müssen, was bei diesem Datenvolumen Tage dauern würde. Zweitens, und noch wichtiger: Der Snapshot erfasst jede Datenbank und jede Anwendung genau zum selben Zeitpunkt. In einer rund um die Uhr betriebenen Bankumgebung laufen in jeder Sekunde Tausende miteinander verknüpfter Transaktionen ab. Ein herkömmliches Backup-Verfahren sichert einzelne Datenbanken zu leicht unterschiedlichen Zeitpunkten, was bei der Rekonstruktion zu halb abgeschlossenen Transaktionen führt, die kein automatisiertes Verfahren vollständig auflösen kann. Der Snapshot umgeht dies vollständig, da alles im selben Augenblick eingefroren wurde. Dies ist das wesentliche Argument für regulierte Branchen. Eine Cyber-Wiederherstellung ohne forensische Integritätsprüfungsschleife ist kein Widerspruch mehr, da die Validierung direkt in die Architektur integriert wurde.

Risiken für Großrechner und ein Angebot der Bewältigung

Darauf kommt es an, wenn sich Mainframe-Sicherheits­dienste entfalten dürfen

Aus betrieblicher Sicht begrenzt die neue Architektur den maximalen Datenverlust auf zwei Stunden und ermöglicht eine vollständige Wiederherstellung deutlich unterhalb des vertraglich vereinbarten 4-Stunden-Service-Levels. Die Wiederherstellung erfolgt direkt aus dem Snapshot, nicht durch das Wiederherstellen von Dateien. Die Verfahren werden jährlich in einer isolierten logischen Partition auf dem Mainframe getestet, die vollständig vom Produktionsnetzwerk getrennt ist. Während der Tests laufen Wiederherstellungs- und Produktionsumgebungen parallel, ohne dass Live-Systeme gefährdet werden.

Das Zwei-Stunden-Intervall ist der aktuelle Standard, nicht die Obergrenze. „Meine Stakeholder und Shareholder gehen in die Richtung der Forderung einer Wiederherstellung nach einem vollständigen Verlust innerhalb von Minuten, nicht von Stunden“, sagt Mayer. „So weit sind wir noch nicht. Aber zwei Stunden sind um Lichtjahre besser als das, was die meisten Host-Kunden erreichen. Wir optimieren weiter.“

Wo sich die Partnerschaft bezahlt macht

Raiffeisen Informatik gehörte weltweit zu den ersten Unternehmen, die diese Architektur einsetzten. Das Projekt dauerte von der Auftragserteilung bis zur Inbetriebnahme etwa vier Monate – ein Zeitrahmen, der sowohl durch die technischen Iterationen geprägt war, die Pionierprojekte erfordern, als auch durch die Notwendigkeit, mehrere Kunden einer gemeinsamen Plattform auf denselben Ansatz abzustimmen. Die Implementierung erfolgte in gemeinsamer Arbeit des hauseigenen Teams und der Professional Services von Hitachi Vantara. Es waren keine externen Integratoren beteiligt.

Mayer beschreibt die Partnerschaft in zurückhaltenden Worten. Er verweist auf zwei entscheidende Momente. Der erste war der Proof of Concept vor der vollständigen Einführung, bei dem mehrere iterative Entwicklungszyklen durchlaufen werden mussten. Der zweite war eine Reihe betrieblicher Probleme, insbesondere mit den Managementservern, die die unveränderliche Backup-Umgebung während des Patch-Managements steuern und die in Zusammenarbeit mit dem Hitachi-Support gelöst wurden. Zu einem Zeitpunkt während der Implementierung, als ein gegenüber dem Kunden zugesagter Termin unter Druck geriet, wurde die Angelegenheit bei Hitachi Vantara bis auf die CEO-Ebene eskaliert: Der Vorstandsvorsitzende flog persönlich aus Kalifornien ein, um sicherzustellen, dass das Projekt im Zeitplan blieb.

„Ohne die Unterstützung von Hitachi hätte die Lösung einfach nicht funktioniert.“ Werner Georg Mayer, Geschäftsführer, Raiffeisen Informatik.

Studie zu Mainframe-Infrastrukturen

Mainframes gewinnen für KI-Strategien an Bedeutung – Studie zeigt Wandel

Es ist die Art von Aussage, die ein erfahrener IT-Manager mit Zurückhaltung trifft – keine begeisterte Empfehlung mit Ausrufezeichen, sondern eine nüchterne Feststellung. Heute liegt der tägliche Betrieb vollständig in den Händen des Teams von Raiffeisen Informatik. Hitachi Vantara wird hinzugezogen, um Störungen zu beheben und Konfigurationsänderungen am Speicherlayout vorzunehmen.

Wie geht es weiter?

Für Raiffeisen Informatik ist die Mainframe-Frage weitgehend geklärt. Nun gilt es, dieselbe technische Disziplin auf den Rest des Plattform-Stacks anzuwenden. „Das Mainframe-Problem ist für uns im Grunde gelöst“, sagt Mayer. „Jetzt müssen wir diese Disziplin auf die anderen Plattformen übertragen und dort auf die gleiche Weise testen. Die Bedrohung macht nicht an der Grenze des Mainframes Halt, und das sollte auch unser Resilienzmodell nicht.“

Der eigentliche Wandel, den das Projekt darstellt, ist ein Umdenken, keine Umstellung der Hardware. Die Architektur ist die Folge, nicht das Hauptthema. Die Verteidigung des Perimeters reicht nicht mehr aus, und auch die Aufsichtsbehörden stimmen dem zunehmend zu. Die Institute, die dies verstanden haben, planen für den Tag, an dem alles ausfällt – nicht nur für den Tag, an dem etwas schiefgeht.

(ID:50992603)