Wie eine europäische Bank ihre PSD2-starke Authentifizierung auf ihrer eigenen Identitätsgrundlage aufgebaut hat

Eine Bank, die sich vornimmt, eine starke Kundenauthentifizierung einzuführen, erwartet normalerweise, dass der schwierige Teil die Authentifizierung selbst ist: welche Faktoren zu kombinieren sind, welche App einzuführen ist, wie die regulatorischen Anforderungen erfüllt werden können. Die schwierigere Frage liegt oft einen Schritt früher. Wo leben die Benutzeridentitäten tatsächlich und kann heute etwas dagegen authentifiziert werden?

Wir haben mit einer Privatbank in Europa zusammengearbeitet, die zu uns kam, um starke Kundenauthentifizierung, SCA in der Sprache der PSD2, für die Kunden ihres Online-Bankings. Die Anforderung war klar, regulatorisch bedingt und aus Notwendigkeit On-Premises. Was bei näherer Betrachtung klar wurde, war, dass das Projekt breiter war als die ursprüngliche Anfrage. Die Bank war damit weiter fortgeschritten als viele Wettbewerber im selben Segment, und der Umfang erweiterte sich im Laufe der Arbeiten weiter.

Wo die Benutzer-IDs tatsächlich gelebt haben

Die Kunden der Bank hatten kein eigenes Verzeichnis. Ihre Identitäten existierten nur innerhalb der vorherigen E-Banking-Lösung, gespeichert in deren Datenbank, wo sie über die Jahre hinweg aufgelaufen waren. Das ist eine häufige Situation und funktioniert im täglichen Gebrauch gut. Sie beginnt, ihre Grenzen aufzuzeigen, wenn man eine konsistente Authentifizierungsschicht vor diese Benutzer legen muss, und hier kommt die starke Kundenauthentifizierung ins Spiel.

Die Modernisierung der Authentifizierung begann also einen Schritt früher, indem diesen Identitäten ein eigenes Verzeichnis gegeben wurde. Wir richteten ein On-Premises OpenLDAP für die Bankkunden und migrierten deren Identitäten aus der bisherigen E-Banking-Datenbank dorthin. Konten, die nur innerhalb der Anwendung existierten, konnten nun zentral verwaltet werden über WebADM, unsere zentrale IAM-Konsole, die die webbasierte Verzeichnisverwaltung bereitstellt, OpenOTP und den On-Premises-Identitätsanbieter ausführt und On-Premises- und Cloud-Identitätsquellen föderiert.

Warum die Identitätsschicht vor Ort bleiben musste

Für eine Bank ist der Speicherort der Authentifizierungsdaten keine Präferenz bei der Bereitstellung, sondern Teil der Kontrollfläche. Hier laufen das Verzeichnis, der Authentifizierungsserver und die Zugriffsbeschränkungen alle lokal, innerhalb der eigenen Umgebung der Bank, ohne dass etwas von der Kundenauthentifizierung diese verlässt. Wir haben WebADM und OpenOTP (unser Multi-Faktor-Authentifizierungsserver) als Hochverfügbarkeitscluster, vorgelagert durch zwei Reverse-Proxys, die nur die Endbenutzer-Services nach außen freigeben, und wir haben das Ganze über separate UAT- und Produktionsumgebungen aufgebaut, damit Änderungen validiert werden konnten, bevor sie jemals den Live-Kunden zugänglich gemacht wurden.

Was die PSD2 starke Kundenauthentifizierung über einen zweiten Faktor hinaus verlangt

Die Bank formulierte ihren Bedarf im Sinne der Starken Kundenauthentifizierung (SCAIn der Praxis ist SCA mehr als eine zweite Aufforderung beim Login: Es definiert, wie Authentifizierungsfaktoren kombiniert werden und erstreckt sich bei einer Bank bis zur Zahlungsautorisierung selbst. Wir lieferten zunächst starke Authentifizierung als Grundlage: einen On-Premises-Identitätsprovider, der von WebADM und OpenOTP unterstützt wird, was Folgendes bietet MFA für die Online-Banking-Kunden der Bank. Im Open-Banking-Kontext ist die Authentifizierung jedoch von der Kundeneinwilligung zu unterscheiden: Die Anmeldung überprüft die Identität des Nutzers, während die Einwilligung zum Zugriff auf Kontodaten oder zur Initiierung von Zahlungen über den geltenden PSD2/Open-Banking-Workflow erfasst werden muss.

Das Sichern der Zahlung selbst, nicht nur des Logins

Die Login-Authentifizierung beantwortet eine Frage: Ist das die richtige Person? PSD2 stellt zum Zeitpunkt der Zahlung eine zweite Frage: Hat diese Person diese spezifische Transaktion, für diesen Betrag, an diesen Zahlungsempfänger genehmigt?

Das ist die Transaktionsgenehmigung, und hier erweiterte sich der Umfang erneut. Wir haben sie so implementiert, dass bei einer Zahlungseinleitung die Transaktion dem Nutzer in der mobilen App zur expliziten Validierung vorgelegt wird, wobei die Zahlungsdetails klar angezeigt werden, bevor sie fortgesetzt werden kann.

Der Authentifizierungsfaktor wird daher nicht mehr nur zur Identitätsprüfung an der Schwelle verwendet. Er wird auch verwendet, um eine bestimmte Operation kryptografisch und kontextbezogen mit der zu genehmigenden Transaktion zu bestätigen.

Integration mit dem Open-Banking-System und den bereits bestehenden Interbankenzahlungen

Eine Bank führt die Authentifizierung nicht isoliert durch. Sowohl die starke Authentifizierung als auch die Transaktionsfreigabe mussten in zwei bereits vorhandene Systeme passen: das Open-Banking-System, das für die Online- und Open-Banking-Dienste der Bank genutzt wird, und den inländischen Anbieter, auf den sich die Bank für Interbankenzahlungen verlässt.

Keines der Systeme sollte durch einen Authentierungsanbieter ersetzt werden, und keines bot einen fertigen Integrationspunkt für den erforderlichen Genehmigungsablauf. Wir haben daher eine benutzerdefinierte Middleware entwickelt, um den Zahlungskontext zur Validierung zu übertragen und die Authentifizierungs- und Transaktionsgenehmigungsabläufe mit beiden Systemen zu verbinden.

Die Anforderung war eine starke Kundenauthentifizierung. Diese ordnungsgemäß zu erfüllen bedeutete, Identitäten eine eigene Authentifizierungsschicht zuzuweisen, diese Schicht vor Ort zu belassen, die Authentifizierung über die Anmeldung hinaus auf die Zahlungsgenehmigung auszudehnen und den Integrationscode zu schreiben, der für die Zusammenarbeit mit den bereits vorhandenen Systemen erforderlich ist, anstatt darum herum.