IKT-Architektur · DORA Art. 8
IKT-Referenzarchitektur: Der Bebauungsplan für Ihre IT
Was eine IKT-Referenzarchitektur als normativer Zielzustand bedeutet, welche wesentlichen Architekturmerkmale sie zeigt – und warum sie sich grundlegend vom Asset-Register unterscheidet.
Was ist eine IKT-Referenzarchitektur?
Eine IKT-Referenzarchitektur ist ein normativer Bebauungsplan für die IT-Landschaft eines Unternehmens. Wie ein städtebaulicher Bebauungsplan festlegt, was wo wie gebaut werden darf, legt die IKT-Referenzarchitektur fest, wie die IT-Landschaft strukturiert sein soll — auf einer Ebene, die verbindlich und strategisch ist, ohne in die Tiefe einzelner Systeme oder Konfigurationen zu gehen.
Sie zeigt die wesentlichen Merkmale der IT auf hoher Ebene: das Netzwerkmodell, die Cloud- und Hosting-Strategie, das Integrationsparadigma, das Identitäts- und Zugriffsmodell, Resilienzanforderungen je Systemkategorie sowie Sicherheits- und Kryptografiestandards. Diese Merkmale sind normativ — sie gelten als Maßstab für Planungs-, Beschaffungs- und Architekturentscheidungen.
Wichtige Abgrenzung: Eine Referenzarchitektur benennt keine konkreten Server, weist keine Anwendungen einzelnen Maschinen zu und dokumentiert keine Konfigurationsstände oder Lizenzen. Das ist Gegenstand des Asset-Registers und der IST-Aufnahme — eigenständige Dokumente, die gegen die Referenzarchitektur gemessen werden, aber nicht mit ihr identisch sind.
Wesentliche Architekturmerkmale: Was eine Referenzarchitektur zeigt
Eine IKT-Referenzarchitektur enthält keine Inventarlisten, sondern normative Architekturentscheidungen — Muster, Modelle und Prinzipien, die den Rahmen für alle konkrete Umsetzung vorgeben. Typische Merkmale mit Beispielen:
Netzwerkmodell und Zonierung
"Das Netzwerk gliedert sich in vier logisch getrennte Zonen: Internet-DMZ, Applikationszone, Kerndatenzone und Out-of-Band-Management-Netz. Direkte Verbindungen zwischen nicht-benachbarten Zonen sind unzulässig; jede Zonengrenze wird durch Firewall-Regeln kontrolliert."
Dieses Modell ist der Maßstab, gegen den die tatsächliche Netzwerktopologie geprüft wird — nicht eine Beschreibung bestehender Switches oder IP-Adressen.
Cloud- und Hosting-Strategie
"Kernsysteme und personenbezogene Daten verbleiben on-premise oder in privaten Cloud-Umgebungen innerhalb der EU. Kollaborations- und Analyseanwendungen können in zertifizierten Public-Cloud-Umgebungen betrieben werden."
Die Strategie legt fest, welche Systemkategorien wo betrieben werden dürfen — unabhängig von konkreten Produktentscheidungen oder Vertragskonditionen.
Integrationsparadigma
"API-first: Die Kommunikation zwischen Anwendungsdomänen erfolgt ausschließlich über dokumentierte APIs. Direkte Datenbankverbindungen zwischen Domänen sind nicht zulässig."
Das Integrationsparadigma steuert, ob eine neue Anwendung zur Architektur passt — und wie Ausnahmen formal genehmigt werden müssen.
Identitäts- und Zugriffsmodell (IAM)
"Alle Systemzugänge erfordern identitätsbasierte Authentifizierung über den zentralen Identity Provider mit obligatorischer MFA. Privilegierte Zugriffe (Administratorzugänge) erfolgen ausnahmslos über ein dediziertes PAM-System."
Das IAM-Modell ist die normative Grundlage — es legt das Muster fest, nicht welche konkrete Software eingesetzt wird oder welche Accounts existieren.
Resilienzklassen
"IKT-Systeme werden in drei Resilienzklassen eingeteilt: Kritisch (aktiv-passiv, RTO < 4h), Wichtig (Backup-Recovery, RTO < 24h) und Standard. Die Referenzarchitektur definiert Klassenzugehörigkeit nach Systemkategorie — nicht die Zuweisung einzelner Systeme."
Resilienzklassen ermöglichen konsistente Anforderungen an Infrastruktur, Backup-Konzepte und Failover-Szenarien — ohne vorab alle konkreten Systeme aufzulisten.
Kryptografie- und Sicherheitsstandards
"Mindeststandard Transportverschlüsselung: TLS 1.2. Ruheverschlüsselung: AES-256. PKI: zweistufige Hierarchie mit Offline-Root-CA. Zertifikate werden ausschließlich über die interne CA ausgestellt."
Diese Standards sind der normative Bezugspunkt für das Zertifikatsregister (IST-Aufnahme) — nicht selbst das Register.
Referenzarchitektur vs. IST-Aufnahme: Die entscheidende Unterscheidung
In der Praxis werden Referenzarchitektur und IST-Aufnahme häufig verwechselt. Der Unterschied ist fundamental:
| Referenzarchitektur (Bebauungsplan / Soll) | IST-Aufnahme / Asset-Register (Bestand / Ist) |
|---|---|
| "Netzwerk ist in vier Zonen gegliedert" | "Server-A steht in Zone 2, IP 10.10.2.5" |
| "Kritische Systeme: aktiv-passiv, RTO < 4h" | "SAP-Prod läuft auf Node X, Failover auf Node Y" |
| "API-first — keine direkten DB-Verbindungen" | "Schnittstelle CRM → ERP via REST API v2.3" |
| "PKI: zweistufige Hierarchie, Offline-Root-CA" | "Root-CA-Zertifikat läuft ab am 12.03.2026" |
| "Privilegierter Zugang nur via PAM" | "Admin-Account admin@prod mit letztem Login 2025-04-01" |
| "Public Cloud nur für nicht-kritische Workloads" | "Anwendung XY läuft in AWS eu-central-1" |
Die linke Spalte ist Gegenstand der Referenzarchitektur. Die rechte Spalte ist Gegenstand der IST-Aufnahme. Nach DORA Art. 8 sind beide Dokumente Pflicht — aber sie sind klar getrennt.
Das Drei-Ebenen-Modell: Referenzarchitektur, IST-Aufnahme, Maßnahmenplan
Ein strukturiertes IKT-Sicherheitsprogramm — und im regulierten Umfeld eine belastbare DORA-Strategie — baut auf drei aufeinander aufbauenden Ebenen auf:
Referenzarchitektur – der Zielzustand (Bebauungsplan)
Die Referenzarchitektur definiert, wie die IT aussehen soll. Sie ist präskriptiv und zukunftsgerichtet: Sie legt Architekturprinzipien, Netzwerkmodelle, Integrationsparadigmen, IAM-Konzepte, Resilienzklassen und Sicherheitsstandards normativ fest — ohne konkrete Systeme zu benennen. Sie ist der Maßstab für alle weiteren Schritte.
IST-Aufnahme – der aktuelle Zustand
Die IST-Aufnahme dokumentiert, wie die IT tatsächlich aufgestellt ist: vorhandene Systeme, Netzwerktopologie, Konfigurationen, Abhängigkeiten, Drittanbieter. Erst vor dem Hintergrund der Referenzarchitektur ergibt die IST-Aufnahme ihren eigentlichen Zweck: Sie misst, wie weit der aktuelle Zustand vom normativen Zielzustand entfernt ist.
Maßnahmenplan – der Pfad zum Zielzustand
Der Maßnahmenplan entsteht aus dem Vergleich beider Dokumente. Jede Abweichung der IST-Aufnahme von der Referenzarchitektur wird zu einem Gap, jeder Gap zu einer priorisierten Maßnahme. Ohne definierte Referenzarchitektur ist dieser Vergleich nicht möglich: Man kann nicht feststellen, was fehlt, wenn man nicht weiß, wie es aussehen soll.
IKT-Referenzarchitektur nach DORA Art. 8
Der Digital Operational Resilience Act (DORA, EU 2022/2554) macht das Drei-Ebenen-Modell für Finanzunternehmen zur Pflicht. Artikel 8 DORA verlangt ausdrücklich eine Referenzarchitektur — einen normativen Zielzustand, nicht lediglich eine Bestandsdokumentation. Separat davon fordert DORA das vollständige IKT-Asset-Register als IST-Aufnahme. Beide Anforderungen stehen nebeneinander; sie sind komplementär, aber nicht dasselbe.
Verantwortlich für die Referenzarchitektur ist das Leitungsorgan des Finanzunternehmens. Es genehmigt den normativen Zielzustand und trägt die strategische Verantwortung dafür, dass Abweichungen erkannt, bewertet und durch einen Maßnahmenplan adressiert werden.
DORA-Anforderungen im Drei-Ebenen-Modell
Die Referenzarchitektur als Grundlage weiterer DORA-Pflichten
Die normative Zielarchitektur ist nicht eine Anforderung unter vielen — sie schafft den Rahmen, in dem alle anderen DORA-Pflichten ihre Grundlage finden:
Business-Impact-Analyse (Art. 11)
Die Referenzarchitektur definiert Resilienzklassen und normative Abhängigkeitsmuster zwischen Systemkategorien. Die BIA nutzt diese Muster, um pro Geschäftsprozess zu bestimmen, welche Systemkategorien kritisch sind — und leitet daraus RTO und RPO ab. Die Resilienzklasse ist das normative Maß; der konkrete Systembestand ist die Messung dagegen.
TLPT-Scope-Definition (Art. 26)
Der TLPT-Scope nach TIBER-EU basiert auf der Referenzarchitektur: Welche Zonen und Systemkategorien sind im Zielzustand kritisch genug für einen Angriffssimulationstest? Die normative Architekturstruktur macht den Scope gegenüber Testern, Aufsichtsbehörde und Leitungsorgan verteidigbar.
→ PenetrationstestsIKT-Drittanbieter-Management (Art. 28)
Die Referenzarchitektur legt normativ fest, an welchen Architekturstellen externe Dienste zugelassen sind und welche Anforderungen sie erfüllen müssen — Datenlokation, Zertifizierungen, Verschlüsselungsstandards. Diese Architekturvorgaben sind der Maßstab, gegen den DORA-konforme Outsourcing-Verträge bewertet werden.
Incident Response (Art. 17)
Incident-Response-Pläne müssen Eindämmungs- und Isolationsmaßnahmen vordenken. Die Referenzarchitektur definiert dafür die normativen Segmentierungsmöglichkeiten: Welche Zonen können isoliert werden? Welche Übergangspunkte gibt es? Im Ernstfall wird nach diesen vorgedachten Strukturen gehandelt — nicht improvisiert.
Kryptografie- und PKI-Standards
Die Referenzarchitektur definiert normative Kryptografiestandards: zugelassene TLS-Versionen, Algorithmen, PKI-Strukturmodell. Das Zertifikatsregister als Teil der IST-Aufnahme wird gegen diese Vorgaben gemessen. Die Referenzarchitektur sagt, wie es sein soll; das Register dokumentiert, wie es ist.
→ DORA-ZertifikatsregisterGovernance und Leitungsorgan (Art. 5)
Das Leitungsorgan genehmigt die Referenzarchitektur als strategisches IKT-Dokument. Sie ist der Rahmen, in dem Investitionen, Architekturentscheidungen und Beschaffungen bewertet werden. Abweichungen vom normativen Zielzustand erfordern eine explizite Risikoentscheidung auf Leitungsebene.
→ DORA-BeratungVon der Referenzarchitektur zum 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 einen priorisierten DORA-Maßnahmenplan ab. Regulatorische Einordnung und technische Umsetzung kommen dabei aus demselben Projekt.
Häufige Fragen zur IKT-Referenzarchitektur
Was versteht man unter einer IKT-Referenzarchitektur?
Eine IKT-Referenzarchitektur ist der normative Zielzustand für die IT-Landschaft eines Unternehmens — ein Bebauungsplan, der auf hoher Ebene beschreibt, wie die IT aufgebaut sein soll. Sie legt wesentliche Merkmale der IT-Architektur fest: Netzwerkmodell, Cloud-Strategie, Integrationsparadigma, IAM-Konzept, Resilienzklassen und Sicherheitsstandards. Sie benennt keine konkreten Server und führt keine Konfigurationsstände — das ist Gegenstand der IST-Aufnahme.
Was ist der Unterschied zwischen IKT-Referenzarchitektur und IST-Aufnahme?
Die Referenzarchitektur beschreibt, wie die IT aussehen soll — sie ist präskriptiv. Die IST-Aufnahme dokumentiert, wie die IT tatsächlich aufgestellt ist — sie ist deskriptiv. Beispiel: Die Referenzarchitektur legt fest, dass das Netzwerk in vier Zonen segmentiert sein soll. Die IST-Aufnahme dokumentiert, welche Server, Switches und Firewall-Regeln tatsächlich vorhanden sind. Erst der Vergleich beider Dokumente ergibt den Gap — und daraus den Maßnahmenplan.
Was zeigt eine IKT-Referenzarchitektur konkret?
Eine IKT-Referenzarchitektur zeigt die wesentlichen Merkmale der IT-Landschaft auf hoher Ebene: z.B. "Netzwerk ist in vier Zonen gegliedert — DMZ, Applikationszone, Kerndatenzone, Management-Netz; keine direkte Verbindung zwischen nicht-benachbarten Zonen", oder "Alle Domain-übergreifende Kommunikation erfolgt über APIs; keine direkten Datenbankverbindungen zwischen Domains". Sie definiert Muster, Klassen und Prinzipien — nicht konkrete Systeme oder Konfigurationen.
Was fordert DORA Art. 8 zur IKT-Referenzarchitektur?
DORA Art. 8 verpflichtet Finanzunternehmen, eine dokumentierte IKT-Referenzarchitektur zu entwickeln und aktuell zu halten. Separat davon fordert DORA ein vollständiges IKT-Asset-Register als IST-Aufnahme. Beide Anforderungen ergänzen sich: Die Referenzarchitektur ist der normative Maßstab; das Asset-Register misst den aktuellen Zustand dagegen. Die Verantwortung liegt beim Leitungsorgan des Finanzunternehmens.
Wie hängen Referenzarchitektur, IST-Aufnahme und Maßnahmenplan zusammen?
Sie bilden ein Drei-Ebenen-Modell: Die Referenzarchitektur definiert den Soll-Zustand. Die IST-Aufnahme erfasst den Ist-Zustand. Der Maßnahmenplan schließt die Lücke. Ohne definierte Referenzarchitektur gibt es keinen Maßstab für die IST-Aufnahme — man weiß nicht, was fehlt, wenn man nicht weiß, wie es aussehen soll. Ohne IST-Aufnahme gibt es keine belastbare Gap-Analyse. Das Modell ist der Kern jeder DORA-Strategie.
Das Drei-Ebenen-Modell
DORA-Einordnung
Verwandte Themen
IKT-Referenzarchitektur aufbauen
Blackfort Technology begleitet den Aufbau der Referenzarchitektur, die IST-Aufnahme und die Ableitung des DORA-Maßnahmenplans — aus einer Hand.
Jetzt anfragenKontakt aufnehmen
Bereit für den nächsten Schritt?
Sprechen Sie mit uns über Ihre Sicherheitsanforderungen – konkret, ohne Verpflichtung und auf Augenhöhe.