Betriebliche Resilienz · ICT-Risikomanagement · Finanzdienstleistungen
Das Digital Operational Resilience Act (DORA), Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025 für Finanzunternehmen der Europäischen Union. Zu den zentralen Zielen gehört die Anforderung, dass Unternehmen ICT-Vorfälle (Informations- und Kommunikationstechnologie) unverzüglich erkennen und die Verfügbarkeit von Diensten, die kritische oder wichtige Funktionen unterstützen, aufrechterhalten.
Um dieses Ziel zu erreichen, ist ein Monitoring erforderlich, das die tatsächliche Verfügbarkeit kundenorientierter Dienste widerspiegelt und nicht nur die interne Systemgesundheit dahinter. Interne Observability-Tools berichten über Infrastruktur innerhalb des Unternehmensnetzwerks. Sie bestätigen nicht, ob ein Dienst von der Position eines externen Nutzers erreichbar und funktionsfähig ist. Externes synthetisches Monitoring greift dies auf, indem es skriptgesteuerte Transaktionen gegen Produktionsdienste von außerhalb des Netzwerks nach einem definierten Zeitplan ausführt.
Dieser Artikel beschreibt die spezifischen DORA-Verpflichtungen, die sich auf kontinuierliches Monitoring und Erkennung beziehen, und erläutert, wie externes synthetisches Monitoring und insbesondere die Dotcom-Monitor-Plattform diese erfüllen.
DORA-Erkennungs- und Verfügbarkeitsverpflichtungen
DORA ist ergebnisorientiert und gibt keine Werkzeuge vor. Es schreibt weder ein bestimmtes Monitoring-Produkt noch eine Prüffrequenz vor. Es legt Anforderungen an Erkennung, Verfügbarkeit und Überwachung fest, wobei das Monitoring die operative Steuerung ist, durch die mehrere dieser Verpflichtungen erfüllt werden. Vier Bestimmungen sind am relevantesten.
Artikel 9 (Schutz und Prävention) verlangt von Finanzunternehmen, die Sicherheit und Funktionalität von ICT-Systemen und -Werkzeugen kontinuierlich zu überwachen und zu steuern. Die Verpflichtung ist fortlaufend, was periodische oder manuelle Kontrollen als alleinige Maßnahme ausschließt.
Artikel 10 (Erkennung) verlangt Mechanismen, um anomale Aktivitäten, einschließlich ICT-Netzwerkleistungsprobleme und ICT-bezogene Vorfälle, unverzüglich zu erkennen und potenzielle wesentliche Single Points of Failure zu identifizieren. Artikel 10(2) verlangt zusätzlich, dass Erkennungsmechanismen mehrere Kontrollschichten ermöglichen, Alarmschwellen definieren und automatische Warnungen an das für die Vorfallreaktion verantwortliche Personal enthalten.
“Finanzunternehmen müssen Mechanismen zur unverzüglichen Erkennung anomaler Aktivitäten, einschließlich ICT-Netzwerkleistungsproblemen und ICT-bezogenen Vorfällen, vorhalten.”
DORA, Artikel 10 (Erkennung)
Artikel 17 und 19 (Vorfallmanagement und Meldung) verlangen einen dokumentierten Prozess zur Verwaltung ICT-bezogener Vorfälle und bei als schwerwiegend eingestuften Vorfällen eine Benachrichtigung der zuständigen Behörde innerhalb einer von der Aufsichtsbehörde vorgegebenen Frist, die in Stunden und nicht Tagen gemessen wird. Die Geschwindigkeit der Benachrichtigung hängt direkt von der Erkennungsgeschwindigkeit ab.
Artikel 28 (ICT-Drittanbieterrisiko) verpflichtet Organisationen, das Risiko aus ICT-Drittanbieterdiensten zu verwalten und zu überwachen. Unterstützt ein Anbieter eine kritische oder wichtige Funktion, fällt dessen Verfügbarkeit in den Überwachungsverantwortungsbereich des Unternehmens.
Aus diesen Bestimmungen folgen fünf erforderliche Monitoring-Fähigkeiten: kontinuierliches Monitoring, unverzügliche Vorfallerkennung, Verfügbarkeitsvalidierung, Überwachung von ICT-Drittanbietern und Frühwarnung bei Dienstverschlechterung. Die Abschnitte unten behandeln jeweils eine Fähigkeit.
Die Rolle der externen Verifikation
Interne Werkzeuge, einschließlich Application Performance Management (APM), Server-Metriken und Log-Analyse, überwachen Systeme von innerhalb des Netzwerks. Sie berichten genau über den Infrastrukturzustand, erkennen aber keine Ausfallarten, die zwischen dem Nutzer und den Servern auftreten. Dazu gehören:
- DNS-Änderungen, die für Nutzer in einer bestimmten Region oder einem Netzwerk falsch aufgelöst werden.
- Abgelaufene oder falsch konfigurierte TLS-Zertifikate, die von Clients abgelehnt werden.
- CDN- oder ISP-Routingfehler auf dem Weg ins Rechenzentrum.
- Drittanbieterskripte oder APIs, die hängen bleiben und die Seitenlade-Vervollständigung verhindern.
- Load-Balancer, die auf eine Gesundheitsprüfung mit gültiger Antwort reagieren, aber eine komplette Benutzertransaktion nicht bestehen.
In all diesen Fällen meldet das interne Monitoring normalen Betrieb, während der Dienst für Nutzer nicht verfügbar ist. Externes synthetisches Monitoring führt die Benutzertransaktion von außerhalb des Netzwerks aus und registriert den Ausfall genau an dem Punkt, an dem er die Nutzer beeinträchtigt.
Die externe Verifikation hat auch Beweiskraft für Compliance. Ein Verfügbarkeitsnachweis ist für Prüfer glaubwürdiger, wenn die Messung außerhalb des gemessenen Systems erfolgt. Unabhängige, zeitgestempelte Verfügbarkeitsdaten unterstützen die Prüf- und Meldepflichten, die DORA für die Erkennung vorsieht.
Abgleich der DORA-Anforderungen mit den Dotcom-Monitor-Fähigkeiten
Die folgenden Unterabschnitte nennen jede Anforderung und die zugehörige Fähigkeit, die sie erfüllt. Dotcom-Monitor ist eine synthetische Monitoring-Plattform, die Prüfungen von außerhalb des Netzwerks durchführt, was mit den oben aufgeführten Erkennungs- und Verfügbarkeitsanforderungen übereinstimmt.
Kontinuierliches Monitoring (Artikel 9)
Anforderung. Kontinuierliche Überwachung und Steuerung der Funktion von ICT-Systemen, die kundenorientierte Dienste unterstützen.
Wie es adressiert wird. Geplante synthetische Checks laufen in definierten Intervallen, bis zu einer Minute häufig, und bieten unterbrechungsfreie Überwachung der Dienste. Webanwendungsmonitoring lädt den Dienst in einem echten Browser und misst das gerenderte Ergebnis, anstatt nur zu bestätigen, dass ein Server antwortet. So entsteht eine kontinuierliche Aufzeichnung, ob der Dienst wie vom Nutzer erlebt funktioniert.
Unverzügliche Erkennung anomaler Aktivitäten (Artikel 10)
Anforderung. Unverzügliche Erkennung anomaler Aktivitäten, einschließlich ICT-Netzwerkleistungsproblemen und Vorfällen, und Identifikation wesentlicher Single Points of Failure.
Wie es adressiert wird. Eine synthetische Transaktion, die fehlschlägt oder eine definierte Antwortzeitgrenze überschreitet, identifiziert den Zustand im Prüfzyklus, unabhängig von Nutzerberichten. Vollständige Abläufe werden mit dem EveryStep-Recorder geskriptet, wodurch die Erkennung über die Seitenverfügbarkeit hinaus auf mehrstufige Prozesse wie Authentifizierung, Zahlung und Kontoeröffnung erweitert wird, bei denen ein einziger fehlgeschlagener Schritt einen Vorfall darstellt.
Alarmschwellen und automatische Warnungen (Artikel 10(2))
Anforderung. Definition von Alarmschwellen und automatische Warnungen für das für die Vorfallreaktion zuständige Personal.
Wie es adressiert wird. Konfigurierbare Warnungen werden bei definierten Bedingungen ausgelöst, darunter Antwortzeiten über einem Grenzwert, Fehlerantworten oder ein fehlgeschlagener Transaktionsschritt. Warnungen werden automatisch per E-Mail, SMS oder integrierten Vorfallmanagement-Tools an bestimmte Empfänger geschickt und nicht in eine gemeinsame Warteschlange gestellt. Schwellenwertbasierte Warnungen bei Leistungseinbußen, nicht nur bei vollständigen Ausfällen, unterstützen die in Artikel 10(2) verlangten mehrstufigen Kontrollmechanismen.
Verfügbarkeitsvalidierung und Prüfungsnachweise
Anforderung. Nachweis, dass Dienste, die kritische oder wichtige Funktionen unterstützen, verfügbar blieben, mit Aufzeichnungen, die für Prüfungen und Nachbewertungen geeignet sind.
Wie es adressiert wird. Uptime- und SLA-Berichte bieten zeitgestempelte Verfügbarkeitsverläufe für jeden überwachten Dienst. Da die Messung von außerhalb des Netzwerks erfolgt, stellen die Berichte unabhängige Nachweise über Verfügbarkeit sowie Zeitpunkt und Dauer von Unterbrechungen dar. Diese Aufzeichnungen unterstützen interne Überprüfungen und Prüfungsanfragen. Verfügbarkeitsziele werden in den Plattformressourcen zum Uptime-Monitoring erläutert.
ICT-Drittanbieterüberwachung (Artikel 28)
Anforderung. Überwachung der Verfügbarkeit und Leistung von ICT-Drittanbietern, die kritische oder wichtige Funktionen unterstützen.
Wie es adressiert wird. API-Monitoring prüft die REST-, SOAP- und GraphQL-Endpunkte, von denen eine Anwendung abhängt, auch solche von Drittanbietern. Für gehostete Anwendungen im Betrieb verfolgt SaaS-Monitoring die Verfügbarkeit des Anbieters direkt, sodass das Unternehmen unabhängige Sicht auf eine Abhängigkeit erhält und nicht allein auf die Statusmeldungen des Anbieters angewiesen ist.
Frühwarnung und Vorfallmeldung (Artikel 10, 17, 19)
Anforderung. Frühwarnung bei Dienstverschlechterung und rechtzeitige Erkennung schwerwiegender Vorfälle, um Meldefristen einzuhalten.
Wie es adressiert wird. Da Checks kontinuierlich von außerhalb des Netzwerks laufen, werden Verschlechterungen und Ausfälle nahe am Auftretensort erkannt, wodurch das Intervall zwischen Vorfallbeginn und Erkennung verkürzt wird. Dieses Intervall ist besonders für Artikel 17 und 19 relevant, bei denen die Meldungsfrist für einen schweren Vorfall in Stunden gemessen wird. Frühere Erkennung erhöht die Zeit zur Klassifizierung, Reaktion und Meldung eines Vorfalls. Dieselbe Fähigkeit unterstützt Früherkennung von Ausfällen und wird im Kontext von synthetischem Monitoring im Finanzdienstleistungsbereich weiter untersucht.
Abdeckung interner Systeme
Anforderung. Überwachung interner Anwendungen, die kritische oder wichtige Funktionen unterstützen, zusätzlich zu öffentlichen Diensten.
Wie es adressiert wird. Öffentliche Dienste werden vom globalen Monitoring-Netzwerk überprüft. Interne Anwendungen hinter der Firewall werden durch Private Agents innerhalb der Umgebung des Unternehmens überwacht, wobei dieselben Prüfungen auf interne und externe Systeme über eine einzige Plattform angewandt werden.
Übersicht der Anforderungen und Fähigkeiten
Die Tabelle fasst die oben dargestellten Zuordnungen zusammen.
| DORA-Bestimmung | Anforderung | Fähigkeit von Dotcom-Monitor |
|---|---|---|
| Artikel 9 | Kontinuierliches Monitoring von ICT-Systemen | Geplante Echtbrowser-Checks in Intervallen von bis zu einer Minute |
| Artikel 10(1) | Unverzügliche Erkennung anomaler Aktivitäten | Synthetische Transaktionen, die Ausfälle und Schwellenüberschreitungen pro Zyklus melden |
| Artikel 10(2) | Alarmschwellen und automatische Warnungen | Konfigurierbare Warnungen für bestimmte Empfänger bei Fehlern oder Verschlechterungen |
| Artikel 17, 19 | Rechtzeitige Vorfallerkennung für Meldungen | Kontinuierliche externe Erkennung, die die Zeit bis zur Kenntnis verkürzt |
| Artikel 28 | Überwachung von ICT-Drittanbietern | API- und SaaS-Monitoring externer Abhängigkeiten |
| Audit und Überprüfung | Nachweise der Verfügbarkeit | Zeitgestempelte Uptime- und SLA-Berichte von außerhalb des Netzwerks |
Beispielhafte Erkennungslücken
Zwei Ausfallbedingungen verdeutlichen, warum externe Verifikation erforderlich ist. Beide können durch internes Monitoring allein nicht erfasst werden.
Regionale DNS-Fehlkonfiguration. Eine DNS-Änderung wird für einen einzelnen Internetdienstanbieter falsch aufgelöst. Serverseitige Metriken bleiben nominal, da betroffene Anfragen die Infrastruktur nicht erreichen. Ein externer Check aus der betroffenen Region protokolliert den Ausfall im nächsten Zyklus und löst eine Warnung mit Angabe des betroffenen Standorts aus.
Drittanbieter-Authentifizierungslatenz. Ein externer Identitätsanbieter ist verfügbar, reagiert jedoch langsam und verursacht mehrere Sekunden Verzögerung pro Authentifizierung. Es wird kein interner Fehler gemeldet. Eine synthetische Transaktion, die die komplette Anmeldung durchführt, misst die erhöhte Antwortzeit, überschreitet den konfigurierten Schwellenwert und identifiziert die Abhängigkeit als Ursache. Dies ist die Sichtbarkeit, die Artikel 28 für Drittanbieter vorsieht.
Empfohlene Monitoring-Konfiguration
Die folgende Konfiguration stellt eine Monitoring-Basislinie sicher, die mit den oben beschriebenen Erkennungs- und Verfügbarkeitsverpflichtungen übereinstimmt. Sie priorisiert kritische Pfade statt vollständiger Abdeckung.
Schritt 1: Identifizieren Sie kritische oder wichtige Funktionen. Benennen Sie die kundenorientierten Dienste, deren Ausfall einen Vorfallbericht erforderlich macht, z. B. Authentifizierung, Zahlungen, Überweisungen, Kontoeröffnung und Kontoauszugzugriff. Diese definieren die Monitoring-Priorität.
Schritt 2: Skripten Sie vollständige Benutzerabläufe. Für jede Funktion zeichnen Sie den gesamten Benutzerfluss mit dem EveryStep-Recorder auf, der mit einem Schritt endet, der bestätigt, dass der Dienst seine Funktion erfüllt hat, z. B. eine abgeschlossene Überweisung oder eine geladene Kontenansicht. Nur eine Prüfung der Startseite erkennt keinen Fehler in einem späteren Schritt.
Schritt 3: Überwachen Sie von relevanten Standorten. Wählen Sie Monitoring-Standorte aus, die der Kunden-geografie des Unternehmens über das globale Monitoring-Netzwerk entsprechen, um regionale Ausfälle zu erkennen.
Schritt 4: Überwachen Sie Drittanbieterabhängigkeiten. Konfigurieren Sie separate Prüfvorgänge für Drittanbieter-APIs und gehostete Anwendungen, von denen kritische Funktionen abhängen, sodass Quellen für Ausfälle dem Unternehmen oder einem Anbieter zugeordnet werden können.
Schritt 5: Definieren Sie Schwellenwerte und Alert-Routing. Legen Sie Alarmgrenzen für Antwortzeiten und Fehlerbedingungen fest und leiten Sie Warnungen an zugewiesene Empfänger und Vorfallmanagementsysteme. Konfigurieren Sie Alarme bei Leistungseinbußen sowie vollständigen Ausfällen.
Schritt 6: Bewahren Sie Verfügbarkeitsaufzeichnungen auf. Aktivieren Sie Uptime- und SLA-Berichte von Anfang an, damit Verfügbarkeitsverläufe automatisch erfasst werden und für Prüfungen und Nachbewertungen zur Verfügung stehen.
Schritt 7: Erweitern Sie die Abdeckung auf interne Systeme. Setzen Sie Private Agents für interne Anwendungen ein, die kritische Funktionen unterstützen, damit diese Systeme gleichwertig kontinuierlich geprüft werden.
Anwendungsbereich und Einschränkungen
Externes synthetisches Monitoring ist eine Kontrollmaßnahme innerhalb eines DORA-Programms und allein nicht vollständig konform mit der Verordnung. Es liefert Verfügbarkeitsvalidierung und unverzügliche Erkennung, jedoch keine ICT-Risikogovernance, Vorfallklassifikation und Meldeverfahren, bedrohungsbasierte Penetrationstests, Backup und Recovery oder Vertragsregelungen mit Drittanbietern, die DORA ebenfalls fordert. Diese Verpflichtungen werden durch andere Kontrollen im Resilienzprogramm des Unternehmens erfüllt.
Synthetisches Monitoring verifiziert zudem nur die geskripteten Transaktionen. Nicht konfigurierte Benutzerabläufe werden nicht überwacht, daher muss die Monitoring-Abdeckung bei Änderungen der Dienste gepflegt werden. Innerhalb dieses festgelegten Rahmens bietet externes synthetisches Monitoring Erkennungs- und Verfügbarkeitsnachweise, die nur wenige andere Kontrollen erzeugen.
Fazit
DORA verlangt von Finanzunternehmen, ICT-Vorfälle unverzüglich zu erkennen sowie die Verfügbarkeit und deren Nachweis für Dienste zu gewährleisten, die kritische oder wichtige Funktionen unterstützen. Internes Monitoring berichtet über den Infrastrukturzustand, erkennt jedoch keine fehlerhaften Zustände zwischen Nutzer und Servern. Externes synthetisches Monitoring überprüft kontinuierlich die komplette Benutzertransaktion von außerhalb des Netzwerks und über relevante Regionen hinweg, einschließlich Drittanbieterabhängigkeiten, und speichert zeitgestempelte Ergebnisprotokolle.
Diese Fähigkeiten entsprechen direkt der Verpflichtung zum kontinuierlichen Monitoring nach Artikel 9, den Erkennungs- und Alarmierungspflichten des Artikels 10, der zeitlichen Vorgabe der Artikel 17 und 19 sowie der Drittanbieterüberwachung gemäß Artikel 28. Externes synthetisches Monitoring allein stellt keine DORA-Konformität dar, ist aber ein direkter und belegbarer Weg, die Erkennungs- und Verfügbarkeitsanforderungen der Verordnung zu erfüllen.
