IKT-Architektur · DORA Art. 8
IKT-Referenzarchitektur: Was DORA fordert – und was das bedeutet
DORA Art. 8 verlangt eine IKT-Referenzarchitektur, definiert aber nicht, was darunter zu verstehen ist. Wie klassische IT-Architektur-Frameworks wie TOGAF Orientierung geben und welche Rolle das Dokument im IKT-Risikomanagement spielt.
Was ist eine IKT-Referenzarchitektur?
DORA Art. 8 verpflichtet Finanzunternehmen, eine IKT-Referenzarchitektur zu entwickeln und aktuell zu halten. Was darunter konkret zu verstehen ist, definiert die Verordnung nicht — der Begriff bleibt bewusst offen.
Orientierung bietet TOGAF (The Open Group Architecture Framework), der weltweit meistgenutzte Standard für Enterprise-Architektur-Management. In TOGAF sind es zwei formell getrennte Artefakte, die zusammen den normativen Zielzustand einer IT-Landschaft beschreiben:
Architecture Principles
Normative Grundsätze, die alle Architekturentscheidungen prägen. Sie beantworten: Nach welchen Regeln wird entschieden? — z.B. Zero Trust, Security by Design, API-first.
Reference Architecture
Konzeptionelle und logische Strukturmodelle. Sie beantworten: Wie soll die IT strukturell aufgebaut sein? — z.B. dreischichtige Applikationsarchitektur, mehrstufige Firewall-Topologie.
Für eine IKT-Referenzarchitektur nach DORA werden beide Ebenen pragmatisch in einem Dokument zusammengeführt. Architekturprinzipien ohne strukturelle Referenzmodelle sind unvollständig — und umgekehrt.
Ebene 1: Architekturprinzipien
nach TOGAF Architecture Principles
Architekturprinzipien sind normative Grundsätze, die dauerhaft gelten und alle Planungs-, Beschaffungs- und Designentscheidungen prägen. In TOGAF werden sie mit Name, Aussage (Statement) und Begründung (Rationale) formuliert:
Zero Trust
Kein System und kein Nutzer erhält implizites Vertrauen aufgrund seiner Netzwerkposition. Jeder Zugriff wird unabhängig von Herkunft und Standort identitätsbasiert authentifiziert und autorisiert.
Rationale: Perimeter-basierte Sicherheitsmodelle bieten keinen wirksamen Schutz gegenüber kompromittierten internen Systemen oder Insider-Bedrohungen.
Security by Design
Sicherheitsanforderungen sind primäre Entwurfskriterien jeder Architektur- und Entwicklungsentscheidung — keine nachgelagerte Ergänzung.
Rationale: Sicherheitsmaßnahmen, die von Beginn an in die Architektur integriert werden, sind wirksamer und deutlich kostengünstiger als nachträgliche Korrekturen.
Cloud-Strategie
Die Referenzarchitektur legt verbindlich fest, nach welchem Modell Workloads betrieben werden — etwa Cloud-First als Standardvorgabe oder Cloud-by-Policy mit definierten Klassifizierungskriterien.
Rationale: Strategische Klarheit über zulässige Betriebsmodelle verhindert unkontrollierten Wildwuchs und schafft planbare Governance für Beschaffung und Betrieb.
API-first
Systemintegration erfolgt ausschließlich über dokumentierte, versionierte APIs. Proprietäre Direktverbindungen und undokumentierte Punkt-zu-Punkt-Kopplungen sind nicht zulässig.
Rationale: Unkontrollierte Systemkopplungen erzeugen intransparente Abhängigkeiten, erschweren die Risikoanalyse und gefährden die Anforderungen an Auditierbarkeit und Drittanbieter-Management nach DORA.
Defence in Depth
Sicherheitsmaßnahmen werden auf mehreren unabhängigen Ebenen implementiert — Netzwerk, Applikation, Identität, Daten. Kein einzelner Kontrollmechanismus gilt als hinreichend.
Rationale: Mehrschichtige Kontrollen reduzieren das Risiko eines vollständigen Sicherheitsversagens durch das Versagen einer einzelnen Komponente erheblich.
Ebene 2: Konzeptionelle Architekturmodelle
nach TOGAF Reference Architecture
Architekturmodelle beschreiben die strukturelle Form der IT-Landschaft auf konzeptioneller und logischer Ebene — ohne Bezug auf konkrete Produkte, Systeme oder Konfigurationen. Sie operieren in TOGAF bewusst oberhalb der physischen Architekturebene:
Dreischichtige Anwendungsarchitektur
Präsentationsschicht, Geschäftslogik und Datenhaltung werden in physisch oder logisch separierten Netzwerkzonen betrieben. Direkte Verbindungen zwischen nicht-benachbarten Schichten sind nicht zulässig; Kommunikation erfolgt ausschließlich über definierte Übergangspunkte.
Mehrstufige Firewall-Architektur
Der Netzwerkperimeter wird durch mindestens zwei Firewall-Stufen gesichert: Eine äußere Firewall trennt öffentliche Netze von der DMZ; eine innere Firewall trennt die DMZ von internen Applikations- und Datenbankzonen. Direkte Verbindungen aus öffentlichen Netzen in interne Zonen sind nicht zulässig.
Zentrales Identitäts- und Zugriffsmodell
Alle Systemzugänge werden über einen zentralen Identity Provider mit einheitlichen Authentifizierungsstandards verwaltet. Privilegierte Zugriffe erfolgen ausschließlich über ein dediziertes Privileged-Access-Management-System; direkte administrative Systemzugriffe ohne Protokollierung sind nicht zulässig.
Verschlüsselte Kommunikationsarchitektur
Alle Datenübertragungen zwischen Systemschichten sowie sämtliche externen Verbindungen werden kryptografisch gesichert. Unverschlüsselte Kommunikation zwischen Systemkomponenten ist nicht zulässig und erfordert eine explizite, dokumentierte Ausnahmeentscheidung.
Redundanz- und Wiederherstellungsmodell
Die Referenzarchitektur definiert Resilienzklassen nach Systemkategorie — nicht die konkrete Zuweisung einzelner Systeme. Kritische Systemkategorien erfordern redundante Betriebsmodelle; die Referenzarchitektur legt fest, welche Kategorien welchen Klassen zugehören.
Beide Ebenen zusammen bilden den normativen Zielzustand — den Bebauungsplan der IT. Sie beschreiben, wie die IT sein soll, ohne festzulegen, welche konkreten Systeme oder Produkte eingesetzt werden. Diese Konkretisierung ist Aufgabe der IST-Aufnahme und des Maßnahmenplans.
Die richtige Abstraktionsebene: konzeptionell und logisch — nicht physisch
TOGAF unterscheidet drei Architekturebenen: konzeptionell, logisch und physisch. Eine Referenzarchitektur operiert auf der konzeptionellen und logischen Ebene. Die physische Ebene — konkrete Systeme, Versionsstände, IP-Adressen, Konfigurationsdetails — gehört nicht zur Referenzarchitektur, sondern zur IST-Aufnahme.
Diese Einschränkung ist keine Schwäche des Dokuments, sondern Voraussetzung für seine normative Kraft. Eine Referenzarchitektur, die auf Ebene konkreter Produkte oder Konfigurationen formuliert ist, veraltet mit jeder Technologieentscheidung. Ein Prinzip wie Zero Trust oder ein Modell wie die dreischichtige Applikationsarchitektur hingegen behält seine Gültigkeit unabhängig davon, welche Technologien im Einsatz sind.
Die Abstraktionsebene schafft auch die richtige Governance-Verankerung: Die Referenzarchitektur ist das Dokument, das das Leitungsorgan genehmigt. Es trifft strategische Entscheidungen — nicht operative. Das ist nur möglich, wenn das Dokument auf einer Ebene formuliert ist, auf der echte strategische Aussagen getroffen werden können.
Prüffrage für die Einordnung: Beschreibt diese Aussage ein dauerhaft geltendes Prinzip oder Muster — unabhängig von konkreten Produkten und Konfigurationen? Dann gehört sie in die Referenzarchitektur. Beschreibt sie einen aktuellen Systemzustand, ein konkretes Produkt oder eine Konfiguration? Dann gehört sie in die IST-Aufnahme.
Das Drei-Stufen-Modell: Referenzarchitektur, IST-Aufnahme, Maßnahmenplan
Die Referenzarchitektur ist das erste Glied einer Kette. Das Modell entspricht dem TOGAF-Prinzip von Target Architecture, Baseline Architecture und Architecture Roadmap — auf die DORA-Anforderungen übertragen:
TOGAF: Target Architecture → Baseline Architecture → Architecture Roadmap
Referenzarchitektur – der normative Zielzustand
Architekturprinzipien und konzeptionelle Strukturmodelle, die verbindlich festlegen, wie die IT aufgebaut sein soll. Abstrakt, langlebig und produktunabhängig — der Maßstab für alle weiteren Schritte. Entspricht der Target Architecture in TOGAF.
IST-Aufnahme – der tatsächliche Zustand
Dokumentation der konkreten IT-Landschaft: vorhandene Systeme, Netzwerktopologie, Konfigurationen, Abhängigkeiten, Drittanbieter. Gemessen gegen den normativen Zielzustand ergibt sich der Gap. Entspricht der Baseline Architecture in TOGAF.
Maßnahmenplan – der Pfad zum Zielzustand
Aus jedem Gap zwischen Referenzarchitektur und IST-Aufnahme entsteht eine priorisierte Maßnahme. Der Maßnahmenplan strukturiert die Umsetzung. Entspricht der Architecture Roadmap in TOGAF.
IKT-Referenzarchitektur nach DORA Art. 8
Der Digital Operational Resilience Act (DORA, EU 2022/2554) macht die IKT-Referenzarchitektur für Finanzunternehmen zur Pflicht. Artikel 8 DORA fordert, dass Finanzunternehmen eine solche Architektur dokumentieren und aktuell halten — als Grundlage ihres IKT-Risikomanagementrahmens.
Separat davon fordert Art. 8 DORA das vollständige IKT-Asset-Register: die IST-Aufnahme mit konkreten Systemen, Konfigurationen und Abhängigkeiten. Beide Anforderungen stehen nebeneinander — sie sind komplementär, aber unterschiedliche Dokumente mit unterschiedlichen Funktionen.
Die Verantwortung für die Referenzarchitektur liegt nach Art. 5 DORA beim Leitungsorgan. Es genehmigt den normativen Zielzustand, verantwortet seine Aktualität und erhält regelmäßige Berichte über Abweichungen und Fortschritte im Maßnahmenplan.
DORA-Anforderungen im Drei-Stufen-Modell
Referenzarchitektur, IST-Aufnahme und Maßnahmenplan – aus einer Hand
Blackfort Technology entwickelt mit Finanzunternehmen die IKT-Referenzarchitektur als normativen Zielzustand, führt die strukturierte IST-Aufnahme durch und leitet daraus den priorisierten DORA-Maßnahmenplan ab. Regulatorische Einordnung und technische Umsetzung aus einem Projekt.
Häufige Fragen zur IKT-Referenzarchitektur
Was ist eine IKT-Referenzarchitektur nach DORA?
DORA Art. 8 fordert eine IKT-Referenzarchitektur, definiert aber nicht, was darunter zu verstehen ist. Orientierung bietet TOGAF, der führende Enterprise-Architecture-Standard: Eine Referenzarchitektur umfasst dort sowohl normative Architekturprinzipien (z.B. Zero Trust, Security by Design) als auch konzeptionelle Strukturmodelle (z.B. eine dreischichtige Anwendungsarchitektur oder ein mehrstufiges Firewall-Modell). Für DORA-Zwecke werden beide Ebenen pragmatisch in einem Dokument zusammengeführt.
Was unterscheidet Architecture Principles von Reference Architecture nach TOGAF?
In TOGAF sind Architecture Principles normative Grundsätze, die alle Architekturentscheidungen prägen – z.B. "Security by Design" oder "API-first". Sie beantworten die Frage: Nach welchen Regeln wird entschieden? Die Reference Architecture beschreibt dagegen konzeptionelle und logische Strukturmodelle – z.B. eine dreischichtige Applikationsarchitektur oder eine mehrstufige Firewall-Topologie. Sie beantwortet die Frage: Wie soll die IT strukturell aufgebaut sein? Eine vollständige IKT-Referenzarchitektur enthält beides.
Was ist der Unterschied zwischen IKT-Referenzarchitektur und IST-Aufnahme?
Die Referenzarchitektur ist der normative Zielzustand – abstrakt, präskriptiv, langlebig. Die IST-Aufnahme dokumentiert den tatsächlichen aktuellen Zustand – konkret, deskriptiv, laufend aktualisiert. In TOGAF-Begriffen entspricht das der Target Architecture (Zielzustand) gegenüber der Baseline Architecture (Ist-Zustand). Erst der Vergleich beider erzeugt den Gap, aus dem der Maßnahmenplan entsteht.
Warum bleibt die Referenzarchitektur auf einem abstrakten Niveau?
Die Abstraktion ist keine Schwäche, sondern die Voraussetzung für die normative Kraft des Dokuments. TOGAF unterscheidet konzeptionelle, logische und physische Architekturebenen. Eine Referenzarchitektur operiert auf der konzeptionellen und logischen Ebene – sie beschreibt Muster und Prinzipien, keine konkreten Systeme oder Konfigurationen. Ein Prinzip wie "Zero Trust" bleibt gültig, unabhängig davon, welche Produkte im Einsatz sind. Physische Ebene und Konfigurationsdetails gehören in die IST-Aufnahme.
Wer trägt nach DORA die Verantwortung für die Referenzarchitektur?
Das Leitungsorgan des Finanzunternehmens trägt nach DORA Art. 5 die persönliche Verantwortung für den IKT-Risikomanagementrahmen – und damit für die Referenzarchitektur als strategisches Kerndokument. Es genehmigt den normativen Zielzustand und stellt sicher, dass Abweichungen identifiziert, bewertet und durch einen Maßnahmenplan adressiert werden.
TOGAF-Einordnung
Das Drei-Stufen-Modell
DORA-Einordnung
Verwandte Themen
IKT-Referenzarchitektur aufbauen
Wir begleiten Finanzunternehmen von der Referenzarchitektur über die IST-Aufnahme bis zum priorisierten Maßnahmenplan.
Jetzt anfragenKontakt aufnehmen
Bereit für den nächsten Schritt?
Sprechen Sie mit uns über Ihre Sicherheitsanforderungen – konkret, ohne Verpflichtung und auf Augenhöhe.