Zum Inhalt springen

Insights

DORA-konforme IT-Architektur: Ein Baukasten für Finanzdienstleister

DORA schreibt keine Technik vor, sondern Nachweise: Ausfallzeit, Datenverlust, Testergebnisse. Welche fünf Bausteine eine Architektur prüfungsfest machen und warum Staging der unterschätzte ist.

Dawid SochackiVeröffentlicht am Aktualisiert am 5 Min Lesezeit
DORA-konforme IT-Architektur: Ein Baukasten für Finanzdienstleister

Der Digital Operational Resilience Act (DORA) verlangt von Finanzunternehmen eine IT, die Ausfälle und Angriffe übersteht und nachweisbar in vereinbarter Zeit in den Normalbetrieb zurückkehrt. Für IT-Verantwortliche heißt das: Resilienz ist eine Eigenschaft der Architektur, nicht ein Ordner mit Notfallplänen, den man nachträglich anlegt.

Was eine DORA-konforme IT-Architektur ausmacht

Eine DORA-konforme Architektur ist ein Baukasten aus wenigen, wiederverwendbaren Bausteinen: redundante Datenhaltung, automatisierte Umschaltung im Störfall, durchgängiges Monitoring, eine Testumgebung, die der Produktion gleicht, und eine Dokumentation, die aus dem System selbst entsteht. Die Verordnung schreibt keine bestimmte Technik vor. Sie verlangt, dass Sie für jedes kritische System sagen können, wie lange es ausfallen darf, wie viel Datenverlust tolerierbar ist und wie Sie beides belegen. Wer diese drei Fragen nicht beantworten kann, hat kein Architekturproblem, sondern ein Nachweisproblem, und das ist bei einer Prüfung das schlimmere.

Warum DORA für IT-Leitungen im Finanzbereich zählt

DORA gilt inzwischen verbindlich für Finanzunternehmen in der EU, von der Bank über den Versicherer bis zum Zahlungsdienstleister, und greift über sie auf die IT-Dienstleister durch, die kritische Systeme betreiben. Sie regelt das Management von IKT-Risiken, die Meldung von Vorfällen, das Testen der Widerstandsfähigkeit und den Umgang mit Drittanbietern. Für die IT-Leitung ändert sich vor allem eines: Die Aussage „das haben wir im Griff“ reicht nicht mehr. Sie müssen es zeigen, regelmäßig, mit Testergebnissen und Vertragsklauseln.

Vier Bausteine einer DORA-konformen Architektur

Redundanz ohne Single Point of Failure

Kritische Systeme laufen an zwei Standorten, mit gespiegelten Datenbanken und getrennten Netzanbindungen. Fällt ein Standort aus, übernimmt der andere, ohne dass jemand nachts Kabel umsteckt. Wichtig ist die ehrliche Bestandsaufnahme: In den meisten Landschaften gibt es genau eine Komponente, die niemand redundant gebaut hat, weil sie „immer lief“. Diese Komponente ist Ihr Prüfungsrisiko.

Automatisierte Wiederherstellung

DORA verlangt, dass Wiederherstellungsabläufe dokumentiert sind und ohne Improvisation funktionieren. In der Praxis heißt das: Sicherungen in kurzen Abständen, unveränderlich gespeichert, und eine Rücksicherung, die per Skript in eine isolierte Umgebung läuft, statt per Handbuch. Wie Sie Wiederherstellungszeit und Datenverlust je System festlegen, beschreibt der Beitrag Backup: RPO und RTO dimensionieren.

Monitoring, das Anomalien meldet, bevor Kunden es tun

Ein zentrales Monitoring sammelt Systemauslastung, Netzwerkverkehr und Sicherheitsereignisse und alarmiert bei Abweichungen. Eine Lösung für Security Information and Event Management (SIEM) bündelt die Protokolle und prüft sie auf Muster. Entscheidend ist weniger das Werkzeug als die Frage, wer nachts den Alarm bekommt und was er dann tun darf.

Dokumentation, die aus dem System entsteht

Architekturentscheidungen, Abhängigkeiten und Konfigurationen müssen der Aufsicht gegenüber belegbar sein. Handgepflegte Diagramme veralten, sobald sie fertig sind. Infrastruktur als Code, versionierte Konfiguration und automatisch erzeugte Abhängigkeitslisten liefern den Nachweis als Nebenprodukt des Betriebs.

Der fünfte Baustein: Staging-Umgebung einrichten, sinnvoll für Tests ohne Produktionsausfall

Die Verordnung schreibt regelmäßige Tests der Widerstandsfähigkeit vor, bis hin zu Penetrationstests und Übungen am Tisch. Solche Tests darf niemand an der Produktion durchführen. Sie brauchen eine Testumgebung, die die Produktionsarchitektur exakt abbildet, in der Sie einen Ransomware-Angriff oder den Ausfall eines Rechenzentrums durchspielen können. Dieselbe Umgebung ist der Ort, an dem Sie Updates ohne Ausfallzeit einspielen, weil jede Änderung dort durchläuft, bevor sie produktiv geht. Ohne Staging ist jedes Update ein Test in Produktion, und genau das will DORA verhindern. Was eine solche Umgebung braucht, steht im Beitrag Staging-Umgebung für risikofreie Updates.

Wie wir Finanzdienstleister bei der Umsetzung unterstützen

Wir beraten nicht, wir bauen und betreiben. Für Finanzdienstleister heißt das: Wir analysieren die bestehende Landschaft, bauen die fehlenden Bausteine, richten Staging und automatisierte Wiederherstellung ein und übernehmen auf Wunsch den Betrieb mit verbindlichen Reaktionszeiten auf Infrastruktur in Deutschland. Offene Standards sind dabei Bedingung, damit Daten und Code jederzeit zu Ihnen wechseln können, auch weg von uns. Unsere Grenze benennen wir offen: Reaktionszeit garantiert, Lösung nach bestem Bemühen. Und wenn Ihre Landschaft einen anderen Partner braucht, sagen wir Ihnen auch das.

Häufige Fragen

Was ist der Unterschied zwischen DORA und NIS-2?

DORA gilt speziell für den Finanzsektor und regelt die digitale operationale Widerstandsfähigkeit im Detail. NIS-2 gilt branchenübergreifend für wichtige und besonders wichtige Einrichtungen. Für Finanzunternehmen ist DORA die speziellere und damit maßgebliche Vorgabe.

Wie lange dauert die Umstellung?

Das hängt vom Ausgangszustand ab. Wer bereits redundant betreibt und eine Testumgebung hat, ergänzt vor allem Nachweise. Wer auf einem gewachsenen Monolithen ohne Staging sitzt, plant einen schrittweisen Umbau über mehrere Etappen.

Können Sie Ihre bestehende Cloud weiter nutzen?

Ja, wenn sie Redundanz über getrennte Verfügbarkeitszonen, automatisierte Sicherungen und vertragliche Zusagen zur Widerstandsfähigkeit bietet. Der Vertrag mit dem Anbieter ist Teil Ihres DORA-Nachweises.

Brauchen Sie ein eigenes Rechenzentrum?

Nein. Viele Anforderungen lassen sich mit gemieteter Infrastruktur erfüllen. Entscheidend ist die Architektur, nicht der Besitz der Hardware.

Gehen Sie Ihre kritischen Systeme durch und markieren Sie, für welches davon Sie heute keine Testumgebung haben, die der Produktion gleicht. Diese Liste bringen Sie mit in den Potenzial-Check, eine halbe Stunde, kostenlos. Wir sagen Ihnen, welcher Baustein bei Ihnen zuerst fehlt und was er im Betrieb kostet. Potenzial-Check buchen

  • IT-Leitung mit Altsystem-Last

Mehr zum Thema