Offene Banking-Ökosysteme: … der Login ist nicht das Problem!

Die meisten Sicherheits­architekturen im Banking enden dort, wo der Angriff beginnt: nach der Authentifizierung. Ein erfolgreich geprüfter Login gilt weiterhin als Vertrauensanker für nachgelagerte Systeme, obwohl sich Identität, Kontext und Risiko im laufenden Betrieb verändern können. Genau diese Lücke adressiert DORA indirekt, während klassische IAM-Modelle weiterhin auf ein statisches Vertrauensmodell ausgerichtet sind.

Ein Fachbeitrag von Stephan Schweizer, CEO bei Nevis Security 

Die Mehrheit moderner Banking-Architekturen behandelt Authentifizierung als zentrale Sicherheitsgrenze.

Ist eine Identität einmal geprüft, wird sie im weiteren Verlauf einer Session als vertrauenswürdig eingestuft. Dieses Modell stammt aus einer Welt klar abgegrenzter Systeme.“

In Open-Banking-Ökosystemen mit FinTechs, Plattformen und ausgelagerten Services bricht diese Annahme strukturell. Der kritische Punkt liegt nicht im Login, sondern in der fortgesetzten Nutzung einer bereits ausgestellten Berechtigung. Zwischen Identitätsprüfung und tatsächlicher Systeminteraktion entsteht eine Sicherheitszone, die in vielen Architekturen nur unzureichend kontrolliert wird.

Access Tokens verlagern die Sicherheitsentscheidung in die Laufzeit

In föderierten Banking-Architekturen werden Zugriffe über OAuth 2.0 und OpenID Connect gesteuert. Access Tokens transportieren dabei nicht nur Identitäten, sondern auch delegierte Berechtigungen und Scopes, die externen Partnern den Zugriff auf Ressourcen der Bank ermöglichen. Technisch entsteht dadurch ein Modell, in dem ein einmal ausgestelltes Token über seine Gültigkeitsdauer hinweg akzeptiert wird, während sich die Rahmenbedingungen der Nutzung kontinuierlich verändern.

Typische Kontextveränderungen umfassen Gerätewechsel oder Netzwerkwechsel während einer laufenden Session, veränderte Risikosignale im Nutzerverhalten sowie aktualisierte Berechtigungen oder widerrufene Einwilligungen und Mandate im Partnerkontext. Viele Architekturen prüfen in dieser Situation lediglich Signatur, Integrität und Ablaufzeit des Tokens.

Ob die zugrunde liegende Nutzung im aktuellen Kontext noch legitim ist, bleibt unbeantwortet. Gerade in Partnerökosystemen entsteht dadurch eine Kontrolllücke zwischen der Vergabe einer Berechtigung und ihrer tatsächlichen Nutzung im Namen der Bank.

Zero Trust scheitert nicht am Konzept, sondern an der zeitlichen Umsetzung

Zero Trust wird in der Praxis häufig auf Multi-Faktor-Authentifizierung und Netzwerksegmentierung reduziert. In offenen Banking-Ökosystemen mit externen Partnern greift diese Interpretation zu kurz. Der entscheidende Unterschied liegt in der zeitlichen Stabilität von Sicherheits­­entscheidungen. Eine einmal getroffene Autorisierung verliert an Aussagekraft, wenn sich Kontext, Risiko und Berechtigungsgrundlagen dynamisch verändern.

Technisch entsteht daraus eine Architektur kontinuierlicher Autorisierung, in der mehrere Komponenten zusammenspielen. Der Identity Provider übernimmt Authentifizierung und Federation. API-Gateways setzen technische Zugriffskontrollen durch. Policy Decision Points bewerten Autorisierungsregeln auf Basis definierter Policies. Risiko- und Kontextsysteme liefern laufende Signale aus Gerätedaten, Netzwerkparametern, Standortinformationen, Nutzerverhalten und Session-Verläufen. Sicherheit entsteht damit nicht durch einen einzelnen Kontrollpunkt, sondern durch eine fortlaufende Kette von Entscheidungsprozessen entlang der gesamten Laufzeit einer Session.

Bei erhöhtem Risiko oder besonders sensiblen Aktionen können adaptive Autorisierungsmodelle zusätzliche Verifikationsschritte auslösen, ohne jede Interaktion pauschal mit denselben Sicherheitsmechanismen zu belasten.

RBAC verliert im Ökosystem an Aussagekraft

Viele Banken basieren weiterhin auf RBAC-Strukturen. Rollen definieren dabei, welche Identität auf welche Ressourcen zugreifen darf. In Open-Banking-Szenarien reicht dieses Modell nicht mehr aus, da sich Berechtigungen nicht nur zwischen Organisationen, sondern auch innerhalb von Sessions dynamisch verändern können.

Ein OAuth-Token mit einem definierten Scope beschreibt zwar eine Berechtigung, jedoch nicht deren aktuelle Legitimität im konkreten Nutzungskontext.“

Deshalb verschiebt sich der Fokus zunehmend hin zu attributbasierten und policygesteuerten Modellen, bei denen Kontextsignale in Echtzeit in die Entscheidung einfließen. Entscheidend ist nicht die statische Definition einer Rolle, sondern die fortlaufende Bewertung ihrer Gültigkeit im aktuellen Zustand des Systems.

Der Engpass liegt in der konsistenten Durchsetzung

Die zentrale Herausforderung moderner Banking-Architekturen liegt nicht in der Definition von Policies, sondern in deren konsistenter Durchsetzung über verteilte Systeme hinweg. In realen Architekturen wirken mehrere Ebenen gleichzeitig auf Autorisierungs­entscheidungen ein: Identity Provider, API-Gateways, Policy Engines, Risikoanalysesysteme sowie Backend-Services und Microservices. Wenn diese Komponenten nicht konsistent zusammenspielen, entstehen Inkonsistenzen in der Zugriffskontrolle, die im laufenden Betrieb oft erst in Audit- oder Incident-Szenarien sichtbar werden. Entscheidend ist daher die Fähigkeit, Sicherheits­entscheidungen über alle Kanäle hinweg identisch, nachvollziehbar und reproduzierbar umzusetzen.

DORA verschiebt Nachvollziehbarkeit in die Architektur

Mit DORA wird Nachvollziehbarkeit zu einer expliziten architektonischen Anforderung. Denn auch wenn Prozesse, Zugriffe oder Dienstleistungen an externe Partner ausgelagert werden, bleibt die regulatorische Verantwortung weiterhin bei der Bank.

Banken müssen nicht nur den Schutz von Systemen nachweisen, sondern auch die Entscheidungslogik hinter jedem Zugriff rekonstruierbar machen.“

Dazu gehört die klare Zuordnung von Identitäten zu Aktionen, die Transparenz über genutzte Berechtigungen, die Dokumentation beteiligter Systeme und Partner, die Nachvollziehbarkeit angewendeter Policies sowie die Einordnung berücksichtigter Risikosignale. Besonders relevant wird dies dort, wo Partneridentitäten auf Systeme, Daten oder Prozesse zugreifen, die regulatorisch weiterhin in der Verantwortung des Instituts liegen. Ein isoliertes Logging einzelner Komponenten reicht dafür nicht aus. Erforderlich ist eine durchgängige Ereigniskette über Identitäts-, API- und Policy-Grenzen hinweg, die Entscheidungen konsistent abbildet. Damit wird Auditierbarkeit selbst zu einem Bestandteil der Architektur und nicht mehr zu einer nachgelagerten Kontrollfunktion.

Die Sicherheitsgrenze ist dynamisch

Die grundlegende Schwäche vieler bestehender Architekturen liegt in der Kopplung von Sicherheit an den Zeitpunkt der Authentifizierung. In offenen Banking-Ökosystemen markiert dieser Zeitpunkt jedoch nicht das Ende der Sicherheitsentscheidung, sondern lediglich ihren Beginn.

Sicherheit entsteht dort, wo Identitäten nicht nur einmal geprüft, sondern kontinuierlich im Kontext ihrer tatsächlichen Nutzung bewertet werden.“

Die entscheidende Grenze verläuft daher nicht zwischen authentifiziert und nicht authentifiziert, sondern zwischen statisch autorisierten und dynamisch kontrollierten Identitäten. Je stärker Banken ihre Wertschöpfung über Partner, Plattformen und externe Dienstleister organisieren, desto stärker wird die laufende Steuerung von Partneridentitäten zu einer zentralen Voraussetzung für Sicherheit, Governance und regulatorische Kontrolle. Stephan Schweizer, Nevis Security