Wissensraum · Deep Dive 14 von 27
Warum Zugriffssteuerung zum Herzstück operativer Resilienz wird
Was dieser Deep Dive Ihnen zeigt
Was Identity & Access Management unter DORA regulatorisch verlangt, wie es sich von klassischem IAM unterscheidet – und warum Zugriffskontrollen zum Governance-Thema werden.
Ein erheblicher Anteil schwerer Sicherheitsvorfälle steht im Zusammenhang mit fehlerhaftem Identity- und Berechtigungsmanagement: übermäßige Zugriffsrechte, veraltete Accounts oder fehlende Funktionstrennung.
DORA rückt Identity- und Zugriffssteuerung nicht als isoliertes Technikthema, sondern faktisch als zentralen Baustein operativer Resilienz in den Fokus. Denn jede digitale Funktion, jeder Prozess und jede kritische Abhängigkeit wird letztlich über Zugriffe gesteuert. IAM wird damit zum Punkt, an dem Technik, Governance und Risiko zusammenlaufen.
Historisch gewachsene Einzelrechte
Fehlende Systematik
Geringe Transparenz
Erhöhtes Risiko lateraler Bewegungen (Angreifer bewegt sich seitwärts durch Systeme)
Kaum auditfähig
Einordnung
Dieser Ansatz ist operativ schwer kontrollierbar und stellt ein erhebliches Risiko dar.
Definierte Rollenmodelle
Regelmäßige Rezertifizierungen möglich
Oft grober Zuschnitt
Hoher manueller Pflegeaufwand
Begrenzte Einbettung in Architektur und Prozesse
Einordnung
RBAC schafft Struktur, stößt jedoch bei komplexen, dynamischen Umgebungen schnell an Grenzen.
Least-Privilege-Prinzip: Zugriff nur auf das, was tatsächlich benötigt wird
Berücksichtigung von Kontextfaktoren (Rolle, Gerät, Ort, Sensitivität)
Segmentierung nach kritischen Funktionen
Automatisiertes Joiner-/Mover-/Leaver-Management
Starke Authentisierung und Kontrollmechanismen
Enge Verzahnung mit Logging, Monitoring und Incident Management
Klar definierte Rollen und Verantwortlichkeiten
Dokumentierte Berechtigungsmodelle
Regelmäßige Rezertifizierungen
Technische Kontrollen für privilegierte Zugriffe (PAM)
Systematische Bereinigung historischer Berechtigungen
End-to-End-Nachvollziehbarkeit von Zugriffen
Im Kern muss beantwortbar sein: Wer hatte wann auf was Zugriff – und was wurde tatsächlich getan?
Ausgangslage
Ein externer Entwickler erhält für ein Projekt temporäre Administratorrechte.
Was passiert
Nach Projektende wird der Account nicht entfernt. Ein Angreifer nutzt diesen Zugang: Zugriff auf kritische Systeme, Aktivitäten bleiben lange unentdeckt, Logs zeigen Aktionen, aber keinen klaren Nutzerkontext.
Analyse
Kein strukturierter Offboarding-Prozess
Kein Privileged Access Management (PAM)
Keine regelmäßige Rezertifizierung
Service-Accounts ohne eindeutige Eigentümer
Konsequenzen
Potenziell meldepflichtiger Incident
Aufsicht fordert vollständige IAM-Übersicht
Erheblicher interner Anpassungsbedarf
Praxis-Impuls
Operative Resilienz beginnt dort, wo klar ist, wer Zugriff hat – und warum. Privileged Access Management (PAM) ist kein Luxus für Großunternehmen. Es ist die Grundlage für jeden nachvollziehbaren Admin-Zugang – und damit für jeden DORA-Nachweis.
Was bleibt
Identity ist nicht IT-Admin, sondern Governance. IAM unter DORA ist keine Technik-Frage mehr, sondern eine Frage über dokumentierbare Kontrolle. Wer hat Zugriff, warum, wie wird es überwacht? Die Antwort muss auditfähig sein.
Zero Trust funktioniert nur mit Kontextinformation. Einzelne Authentisierung reicht nicht. Kontinuierliche Risikobewertung – basierend auf Nutzer, Gerät, Verhalten, Sensitivität – ist der einzige Weg, um Least Privilege wirklich umzusetzen.
Privileged Access ist der kritischste Hebel. Admin-Accounts, Service-Accounts, API-Keys – ohne Oversight werden diese Zugänge zu blindem Fleck. PAM ist nicht optional; es ist der Prüfstein für jede DORA-Konformität.
Joiner-Mover-Leaver ist der Stress-Test. Wer sein IAM-System genauer prüft, offenbart sofort die Lücken: Provisioning funktioniert nicht, Offboarding wird vergessen, Rollenwechsel sind chaotisch. DORA zwingt zu operativen Standards, die vorher optional waren.