IT-Plattformen für Banken und Finanzdienstleister
DORA Artikel 9: Nachweisbares technisches Risikomanagement auf Systemebene. Ihr JBoss-Cluster verarbeitet täglich Zahlungstransaktionen. Was zeigen Sie dem BaFin-Prüfer?
DORA macht IT-Betrieb zum Gegenstand der Bankenaufsicht. Kernbanken-Plattformen auf JBoss EAP und RHEL brauchen dokumentierte Baselines, maschinenlesbare Audit-Trails und automatisierte Compliance-Nachweise. Nicht als nachgelieferte Projektdokumentation. Als technischen Standard.
Was DORA konkret von Ihrer IT-Plattform fordert
DORA ist kein reines Prozessrahmenwerk. Artikel 9 fordert technische Maßnahmen auf Systemebene. Für JBoss-Plattformen in Banken bedeutet das konkrete operative Konsequenzen, die manueller Betrieb nicht erfüllen kann.
- Artikel 9 — ICT-Risikomanagement Technische Maßnahmen zur Identifikation, zum Schutz und zur Erkennung von Risiken auf Systemebene. Härtungsstandards müssen definiert und nachweisbar sein, nicht nur beabsichtigt.
- Artikel 9 — Änderungskontrolle Jede Änderung an ICT-Systemen muss kontrolliert, dokumentiert und rückverfolgbar sein. Manuelles Ticket-basiertes Change-Management erfüllt diesen Anspruch nicht.
- Artikel 11 — Betriebliche Resilienz ICT-Systeme müssen in einen definierten Zustand wiederhergestellt werden können. Kein definierter Zielzustand bedeutet keinen reproduzierbaren Wiederherstellungspfad.
- Artikel 17 — Klassifikation von Vorfällen Vorfälle müssen mit Bezug auf den Konfigurationszustand betroffener Systeme nachvollziehbar sein. Konfigurationsdrift ist ein direkter Vorfallsrisikofaktor.
- Definierte Baselines je Instanz Jede JBoss-EAP-Instanz braucht einen dokumentierten Sollzustand: Härtungsstandard, Policy-ID, Geltungsbereich und Ausnahme-Log. Nicht im Wiki. Als versioniertes Artefakt.
- Maschinenlesbarer Audit-Trail Jede Konfigurationsänderung an JBoss oder RHEL braucht Author, Timestamp, Begründung und ggf. Freigabe. Git-basiertes Configuration-Management ist keine Kür, sondern Anforderung.
- Dokumentierte Ausnahmen Wo Härtungsregeln aus betrieblichen Gründen nicht umgesetzt werden, braucht es eine Risikoentscheidung mit Nachweis. Nicht als Ticket. Als Policy-Ausnahme mit ID und Approval.
- Nachvollziehbarer Konfigurationszustand Im Vorfallsfall muss der genaue Konfigurationszustand zum Vorfallszeitpunkt rekonstruierbar sein. Das erfordert kontinuierliches State-Tracking auf Systemebene.
So sieht eine typische Banken-Plattform aus
Kernbanken-Plattformen sind keine Greenfield-Installationen. Sie sind über Jahre gewachsen, von verschiedenen Teams gewartet, und tragen heute die Last regulatorischer Anforderungen, die bei ihrer Entstehung noch nicht galten. DORA fordert, dass dieser Zustand endet.
Kernbanking und Zahlungsverkehr
JBoss EAP läuft als Middleware unter Kernbank-Fachverfahren: Kontoführung, Zahlungsverarbeitung, Kreditscoring. Hochkritisch. Enges Wartungsfenster. Null Toleranz für ungeplante Ausfälle.
Problem: Konfigurationen gewachsen, heterogen, ohne definierten Sollzustand. Härtung nicht dokumentiert. Änderungen in Tickets und Wiki-Seiten verteilt.
Betriebssystem-Basis
RHEL-Server bilden die Grundlage für JBoss EAP und weitere Systemkomponenten. Manuell gewartet, unterschiedliche Konfigurationen je Team und Umgebung.
Problem: Keine einheitliche Härtungsbasis. Sicherheits-Patches reaktiv. Konfigurationswissen personengebunden. Bei Personalwechsel geht Kontext verloren.
Mitarbeiterzugang und Identitäten
Windows-Server und Active Directory steuern Mitarbeiterzugang und Berechtigungen. GPOs manuell verwaltet, Gruppen historisch gewachsen.
Problem: Berechtigungen nicht systematisch gepflegt. Keine automatisierte Compliance-Prüfung. Änderungen kaum rückverfolgbar.
Jede dieser Schichten wird von Spezialisten manuell betrieben. Wenn diese gehen, geht das Konfigurationswissen mit. DORA fordert, dass genau das strukturell endet. Nicht durch Dokumentationsprojekte. Durch Automatisierung, die Nachweisbarkeit als technisches Ergebnis produziert.
Was BaFin-Prüfer in manuellen Umgebungen finden
BaFin-Prüfer stellen konkrete technische Fragen. Die Antworten aus manuell betriebenen JBoss-Umgebungen zeigen ein bekanntes Muster.
Compliance-Frameworks für Banken und Finanzdienstleister
Banken operieren unter einem dichten Netz aus Regulierungen. lennlay adressiert die technische Plattformebene, den Bereich, der in Prüfungen am häufigsten Nachweislücken zeigt.
Digital Operational Resilience Act. ICT-Risikomanagement, Resilienztests, Incident-Reporting und Drittparteiensteuerung. Artikel 9 und 21 betreffen direkt die technische Plattformebene.
IT-Systeme und IT-Prozesse mit angemessener Dokumentation. Direkte BaFin-Anforderung. Plattformbetrieb ohne nachweisbare Dokumentation ist eine MaRisk-Nichtkonformität.
Bankaufsichtliche Anforderungen an die IT. Härtung, Dokumentation, Änderungskontrolle. BAIT konkretisiert MaRisk auf technischer Ebene und ist direkte Prüfungsgrundlage.
EBA Guidelines on ICT and Security Risk Management. Europäischer Rahmen, auf dem DORA und nationale Anforderungen aufbauen. Betrifft ICT-Risikomanagement auf Systemebene.
Banken ab einem bestimmten Schwellenwert gelten als kritische Infrastruktur. Besondere Pflichten zu IT-Sicherheitsmaßnahmen, Nachweisen und Meldepflichten gegenüber dem BSI.
NIS2-Umsetzungsgesetz. Banken als wesentliche Einrichtungen. Technische Sicherheitsmaßnahmen, Risikomanagement-Anforderungen und Incident-Meldepflichten.
Konkrete Leistungen für regulierte Banken-Plattformen
Keine generischen Plattformversprechen. Diese sechs Leistungsfelder adressieren direkt die Nachweislücken, die BaFin-Prüfer in JBoss-Umgebungen regelmäßig vorfinden.
Definierte JBoss-Baselines
CIS-Benchmarks-referenzierte Härtung für JBoss-EAP-Instanzen. Policy-Artefakt mit ID, Datum, Geltungsbereich und Ausnahme-Log. Maschinenlesbar, auditierbar, reproduzierbar. Nicht im Wiki. Als versioniertes Dokument mit Änderungshistorie.
Automatisierter Audit-Trail
Git-basiertes Configuration-Management. Jede Änderung an JBoss oder RHEL ist ein Commit: Author, Timestamp, Begründung und Freigabe. BaFin-Prüfer können jeden vergangenen Konfigurationszustand abfragen.
Compliance-Scan und Report
Automatisierter Scanner läuft gegen live JBoss- und RHEL-Instanzen. Strukturierter Output direkt verwendbar für BaFin-Prüfer und interne Revision. Kein manuelles Zusammentragen. Kein Nacharbeiten vor der Prüfung.
GIaaS JBoss-Baseline
Gehärtetes JBoss EAP als verwaltetes, policy-gesteuertes Artefakt. Policy, Build, Package, Deliver. Nicht von Ihrem Team gepflegt. Von lennlay verantwortet, versioniert und lifecycle-gemanagt. GIaaS verkauft keine Images. GIaaS verkauft Sicherheit, Verantwortung und Audit-Ruhe.
EaaS für kritische Phasen
Marcel König (RHCA/RHCE) und Matthias Siegl (RHCE) für eingebettetes Engagement verfügbar. Migrationssupport, DORA-Readiness, Plattform-Härtung. Zertifizierte Red-Hat-Experten mit definiertem Scope und transparentem Vorgehen.
Lifecycle-Management
JBoss-EAP-EOL-Tracking, Sicherheits-Updates strukturiert und nachvollziehbar. Kein reaktives Patch-Management. Migration von JBoss EAP 7 auf EAP 8 mit dokumentiertem Übergangszustand und klarem Rollback-Plan.
In welcher Situation befinden Sie sich?
DORA ist in Kraft. Die Prüfung kommt.
DORA gilt seit Januar 2025. Ihre Plattform-Dokumentation erfüllt die Anforderungen von Artikel 9 noch nicht. Zeit läuft. BaFin-Prüfer werden konkrete technische Nachweise einfordern, keine Konzeptpapiere.
lennlay liefert in 4 bis 8 Wochen: dokumentierte JBoss-Baselines, automatisierten Audit-Trail, ersten Compliance-Scan-Report, direkt verwertbar für die Prüfung.
Letzter Audit ergab Mängel. Nächste Prüfung: Nachweise.
Interne Revision oder externer Prüfer haben Feststellungen zu Plattformhärtung, Dokumentation oder Änderungskontrolle gemacht. Ein Remediation-Plan ist erwartet. Die nächste Prüfung will technische Umsetzung sehen.
lennlay setzt Remediation-Maßnahmen technisch um und liefert die Nachweisdokumentation, die die Folgeprüfung erwartet.
Kernbanking läuft auf JBoss 7.x. EOL kommt. Migration nötig.
JBoss EAP 7 läuft aus. Der Migrationsbedarf auf EAP 8 ist bekannt. Das Risiko: Migration bei laufendem Kernbanking-Betrieb ohne definierten Übergangszustand. Kein Produktionsstopp erlaubt.
lennlay managed die Migration mit definierten Übergangszuständen, Rollback-Plan und vollständiger Dokumentation für Revision und Aufsicht.
Plattform-Check für regulierte Finanzumgebungen
15 Minuten reichen, um einzuordnen, wo Ihre JBoss-Plattform heute steht und was DORA konkret von ihr fordert.
Unverbindlich · Keine Verkaufspräsentation · Vertraulich
