DORA · Identitäts- und Zugriffsmanagement
Zugriffskontrolle als Teil
der operationalen Resilienz
DORA gilt seit dem 17. Januar 2025. Für Finanzunternehmen gehören Identitätsdatensätze, Zugriffsrechte und Nachweise über deren Entzug in den IKT-Risikomanagementrahmen.
Ausführlichen DORA-Leitfaden lesen Zugriffsnachweise ansehen
Zuerst den anwendbaren Rahmen klären
Die Verordnung (EU) 2022/2554 legt in Artikel 2 fest, für welche Kategorien von Unternehmen sie gilt und welche ausgenommen sind. Artikel 4 verankert den Grundsatz der Verhältnismäßigkeit. Bestimmte Unternehmen unterliegen dem vereinfachten IKT-Risikomanagementrahmen nach Artikel 16. Gehen Sie nicht davon aus, dass jede Organisation im Finanzsektor dieselben Pflichten hat oder dass eine geringe Größe diese automatisch entfallen lässt.
DORA gilt unmittelbar. Das entbindet Sie nicht davon, Ihre zuständige Behörde zu ermitteln und die damit zusammenhängenden nationalen Aufsichts- und Durchsetzungsbestimmungen zu prüfen. Für kritische IKT-Drittdienstleister gilt zudem ein eigener Überwachungsrahmen; sie sollten nicht so beschrieben werden, als wären sie lediglich eine weitere Kategorie von Finanzunternehmen.
Was Art. 9 Abs. 4 Buchst. c für Zugriffe bedeutet
Der Zugang zu IKT-Assets muss auf das beschränkt sein, was rechtmäßige und zulässige Funktionen erfordern. Finanzunternehmen müssen Konzepte, Verfahren und Kontrollen für Zugangs- und Zugriffsrechte festlegen und deren gründliche Verwaltung gewährleisten. Die ergänzende Delegierte Verordnung (EU) 2024/1774 enthält in den Artikeln 20 und 21 weitere Anforderungen an Identitätsmanagement und Zugangskontrolle, soweit diese Bestimmungen für den jeweiligen Rahmen gelten.
Governance-Nachweise sollten eine Personen- oder Systemidentität mit ihren Konten, Genehmigungen, aktuellen Rechten und Lebenszyklusänderungen verknüpfen. Dabei muss klar zwischen einer Workflow-Entscheidung und dem Ergebnis im Zielsystem unterschieden werden.
Eine testbare Kontrollübersicht
| Bereich | Zu erfüllende Anforderung | Beispielnachweise |
|---|---|---|
| Identitätslebenszyklus | Lebenszyklen von Identitäten und Konten verwalten, einschließlich Erstellung, Änderung, Überprüfung, vorübergehender Deaktivierung und Beendigung. | Zuordnung von Identitäten zu Konten, verantwortliche Person und datierte Lebenszyklusaufzeichnungen. |
| Minimale Berechtigung und Funktionstrennung | Die Grundsätze „Kenntnis nur, wenn nötig“ (Need-to-know), der Nutzungsnotwendigkeit (Need-to-use) und der minimalen Berechtigung (Least Privilege) anwenden; Abtrennung der Aufgaben (Funktionstrennung) und Zurechenbarkeit regeln. | Rollendefinitionen, Genehmigungen, Umgang mit Konflikten und kontrollierte Ausnahmen. |
| Nicht mehr benötigte Zugriffsrechte | Rechte bei Beendigung oder wenn sie nicht länger erforderlich sind, umgehend entziehen. | Austritts- oder Rollenwechselereignis, Ergebnis des Entzugs und offene Ausnahmen. |
| Überprüfung und Aktualisierung | Rechte aktualisieren, wenn Änderungen notwendig sind; für den vollständigen Rahmen die Unterscheidung zwischen jährlichem und halbjährlichem Mindestintervall beachten. | Kritikalität des Systems, überprüfter Umfang, Entscheidungen, Nachverfolgung und Abschluss. |
| Starke Authentifizierung | Fernzugang, bevorrechtigten Zugang sowie bestimmte kritische oder öffentlich zugängliche Zugangswege nach Artikel 21 Buchstabe f abdecken. | Konfiguration von IdP und Anwendungen, durchgesetzte Methoden und getestete Abdeckung. |
Ergebnisse testen, auch Fehlschläge
Ein aussagekräftiges Pilotprojekt umfasst mehr als eine Genehmigungsansicht. Wählen Sie eine kritische oder wichtige Funktion, ermitteln Sie die Systeme, die sie unterstützen, und gleichen Sie Konten und Rechte ab. Prüfen Sie stichprobenartig eine neue Rechtevergabe, einen Rollenwechsel, einen Austritt und ein privilegiertes Konto. Bestätigen Sie das Ergebnis im Zielsystem und dokumentieren Sie, wie Fehler oder Ausfälle eines Konnektors eskaliert werden.
Halten Sie die Verantwortung für offene Maßnahmen ausdrücklich fest. Ein Export, der zeigt, dass die Entfernung eines Zugriffs genehmigt wurde, ist kein Nachweis dafür, dass die Entfernung gelungen ist. Ebenso beweist ein Identitätsdatensatz nicht, dass jede aktive Sitzung, jedes lokale Konto und jeder Notfallzugang kontrolliert wird.
Einsatzbereich und Grenzen von easyIGA
easyIGA bietet über midPoint eine Governance-Ebene, mit der die Fachbereiche arbeiten. Bewerten Sie die Workflows für Anfragen, Überprüfungen, Zuständigkeiten und Nachweise anhand Ihres Umfangs und der unterstützten Konnektoren. Audit-Nachweise können Ihren IKT-Risikomanagementprozess unterstützen, wenn Abdeckung und Datenqualität verifiziert sind.
IGA ersetzt weder einen PAM-Vault noch Kontrollen privilegierter Sitzungen, die Meldung IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz oder das Management des IKT-Drittparteienrisikos. Bei der Beschaffung müssen außerdem die Grenzen für Sicherheit und Datenverarbeitung bewertet werden. Kein Produkt garantiert Compliance oder eine günstige aufsichtsrechtliche Feststellung.
Primärquellen
- EUR-Lex: DORA, Artikel 2, 4, 9, 16 und 64
- EUR-Lex: Delegierte Verordnung 2024/1774, Artikel 20 und 21 sowie Bestimmungen zum vereinfachten Rahmen
Quellenprüfung: 12. September 2026. Ausführlichere Hinweise zur Umsetzung finden Sie im vollständigen Leitfaden.