PSD2 und OpenBanking in der Praxis – API-Sicherheit

Eines der größten Probleme bei der API-Sicherheit, vor allem im Finanzsektor, ist die mangelhafte Transparenz. So tun sich viele Unternehmen schwer damit, einen Überblick zu bekommen über sämtliche Netzwerkressourcen, Datenbanken, SaaS-Anwendungen und vor allem sensible Daten. Auch wissen sie in vielen Fällen nicht, welche und wie viele APIs sie im Einsatz haben, welcher Traffic bei welchem API fließt und wer sie tatsächlich nutzt. Die europäische PSD2-Richtlinie versucht, hier Klarheit zu schaffen. Doch ist bei ihr längst auch nicht alles Gold, was glänzt.

von Rob Otto, EMEA Field CTO, Ping Identity

Die europäische Zahlungsrichtlinie PSD2 betrifft vor allem zwei Teilbereiche des Finanzsektors, nämlich Banken auf der einen und Drittanbieter und Dienstleister auf der anderen Seite, die auf die Daten der Banken angewiesen sind. Im Rahmen von PSD2 haben die Banken dabei eine Reihe von Standards und APIs an die Hand bekommen, die sie wiederum ihren Kunden zur Verfügung stellen müssen. Dadurch hat sich bei den Banken das Bewusstsein für den Bedarf nach modernen IAM-Lösungen (Identity Access and Management) geschärft.

In der Vergangenheit setzten Banken hierfür häufig auf eigene proprietäre Lösungen. Diese gingen allerdings häufig zu Lasten der Benutzererfahrung – gerade, wenn ein Kunde Accounts bei mehreren unterschiedlichen Banken hat und jede eine eigene IAM-Lösung einsetzt. PSD2 hingegen setzt die Anmeldeprozesse und die Benutzererfahrung in den Fokus und gibt den Banken einen Regulierungs-„Schubs“, um diese Mechanismen zu verbessern.

Gleichzeitig sorgt PSD2 dafür, dass die Drittanbieter einen Teil der Sicherheitsanforderungen, die an sie gestellt werden, wieder zurück auf die Banken schieben können.”

Die API-Problematik

APIs sind heute fast allgegenwärtig und nun haben Finanzdienstleister die Möglichkeit, den Kundendialog zu vertiefen und die Kundenbindung zu stärken. Das sie dafür den Zugang zu wertvollen Unternehmensdaten gewähren, macht sie zu einem äußerst beliebten und gleichzeitig extrem kritischen Angriffsvektor.

Dabei ist eines der Hauptprobleme die mangelhafte Transparenz in vielen Unternehmen. So tun sich viele Banken und Finanzdienstleister schwer damit, einen Überblick zu behalten über sämtliche sensiblen Daten, die Datenbanken, in denen diese liegen sowie ihre Netzwerkressourcen und SaaS-Anwendungen.

Analog dazu kommt es auch schnell zu „API-Wildwuchs“. Denn sie wissen häufig auch nicht, welche und wie viele APIs sie im Einsatz haben, welcher Traffic über sie fließt und wer sie tatsächlich nutzt.”

Ebenfalls als schwierig stellt sich auch immer wieder die Verifizierung der Daten heraus. Denn diese müssen den Richtlinien entsprechen. Außerdem muss sichergestellt werden, dass die Anwender, die die API nutzen, auch tatsächlich die sind, die sie zu sein scheinen. Darüber hinaus kommt es häufig zu DDoS-Angriffen (Distributed Denial of Service) auf APIs, auch die wachsende Zahl der Bot-Netzwerke stellt ein nicht zu unterschätzendes Risiko dar.

APIs unter Beschuss

Diese zahlreichen Angriffspunkte sind auch der Grund dafür, warum in den vergangenen Jahren die Zahl der gezielten Attacken auf APIs rapide gestiegen ist.”

So zählen zu den Unternehmen und Behörden, die aufgrund unsicherer APIs zum Opfer von Datenschutzverletzungen geworden sind, unter anderem der Fastfood-Gigant McDonald’s, der Mobilfunkanbieter T-Mobile USA sowie das soziale Netzwerk Facebook.

Die klassischen Schutzmaßnahmen bei APIs beschränken sich meist auf WAF-basierte (Web Application Firewall) Ansätze, bei denen mittels Signaturen nach verbreiteten Angriffsarten gesucht wird. Ebenfalls zum Einsatz kommen auch API-Gateways, die aber vor allem vor DDoS-Angriffen schützen sollen. Doch bei Angriffen, die Credential-Stuffing, gestohlene Cookies oder Token nutzen, greifen diese Maßnahmen zu kurz. Denn hierbei gehen die Zugriffe auf die API von augenscheinlich „normalen“ Anwendern aus. In solchen Fällen hilft nur ein identitäts- und analysebasierter Ansatz. Denn nur ein solcher kann – im Idealfall unterstützt durch künstliche Intelligenz und maschinelles Lernen – ein normales Level des API-Verhaltens definieren.

PSD2 und OpenBanking eilen zur Rettung

Genau hier setzt PSD2 an. Denn sie schreibt vor Gewährung des API-Zugriffs eine sorgfältige Authentifizierung der Anwender mit mindestens zwei Faktoren vor. In Deutschland wird die Richtlinie jedoch vergleichsweise lax umgesetzt. So gibt es beispielsweise kein konkretes API-Gerüst, an dem sich die Banken orientieren können. Stattdessen haben sie relativ viele Freiheiten, was sie wie umsetzen können.

Dies verringert die Interoperabilität und führt fast wieder zu den oben beschriebenen Zuständen der proprietären Lösungen. Wie es besser geht, zeigt Großbritannien mit OpenBanking.”

OpenBanking ist die britische Umsetzung der europäischen PSD2-Gesetzgebung und wird mittels eines Frameworks abgesichert, das auf dem OpenID Connect-Standard basiert. Und während die erste Version des Sicherheitsprofils noch auf einem Modell mit Browser-Umleitungen basierte, das zwar maximale Sicherheit bot, von den Kunden jedoch größtenteils nicht akzeptiert wurde, gibt es nun eine Reihe alternativer Ansätze, mit denen sowohl Banken als auch Händler mit Hilfe der entkoppelten Authentifizierung und CIBA (Client Initiated Backchannel Authentication) die bisherigen Schwierigkeiten umgehen können.

Dabei ist eine der größten Herausforderungen beim Einsatz von CIBA für die entkoppelte Authentifizierung das Erkennen des richtigen Benutzers. Denn während bei einem klassischen Umleitungsmodell, wie es zunächst genutzt wurde, der Händler die Kundenidentität auf Bankseite nicht bestätigen muss, da diese nach der Weiterleitung auf der Banken-Website erfolgt, funktioniert dies bei einem entkoppelten Ablauf nicht, da hier der Benutzer nicht weitergeleitet wird. Stattdessen ist der Händler gefragt, die Identität des Nutzers zu prüfen und an die Bank weiterzuleiten.

Drei Ansätze zur Benutzerauthentifizierung

Im Folgenden werden drei unterschiedliche Ansätze vorgestellt am Beispiel eines Online-Kaufs von Sportbekleidung:

• Check-Out mit Einmal-Benutzerkennung: Hierbei wurde das Konto des Käufers noch nie bei dem speziellen Shop verwendet. Daher wird eine einmalige Benutzerkennung verwendet, die von der mobilen App der Bank generiert wird. Diese ist direkt mit dem Konto des Benutzers verbunden und kann nur einmal verwendet werden. Dadurch kann der Käufer die Kennung gefahrlos an den Webshop weitergeben. Sobald nun dieser den entkoppelten Authentifizierungsablauf mit CIBA für die Bestätigung der Zahlung anstößt, wird die Kennung als Authentifizierungshinweis an die Bank weitergegeben. Diese kann nun diese Einmal-Benutzer-ID neu referenzieren und so den echten Namen des Benutzers über einen einfachen API-Aufruf herausfinden. Im Anschluss wird dann automatisch die Benachrichtigung über die genehmigte Zahlung an das Smartphone des Käufers geschickt. Diese Herangehensweise bietet vor allem dann Vorteile, wenn ein Kauf über ein Terminal getätigt wird, beispielsweise bei einem In-Store-Kiosk. Dann könnte die Einmalkennung auch als scanbarer QR-Code angezeigt werden – so müssen auch keine Daten eingegeben werden.
• Checkout mittels QR-Code: Auch hier wurde das Konto noch nie für einen Kauf bei dem Beispielhändler verwendet. Allerdings generiert der Shop hierbei eine einzigartige Referenz für die Zahlungstransaktion. Dieser Wert wird anschließend als Login-Hinweis genutzt und im Rahmen eines CIBA-Abrufs an die Bank geschickt. Zur Sicherheit verschlüsselt der Händler die eindeutige Referenz in Form eines scanbaren QR-Codes, der innerhalb der Shop-Website eingeblendet wird. Der Käufer muss diesen Code anschließend mit der Mobil-App der Bank einscannen – schon ist die Zahlung bestätigt und der Kauf getätigt. In diesem Fall wird die Authentifizierung des Käufers über die App der Bank sichergestellt. Denn diese Anwendung ist mit dem Konto des Benutzers verknüpft und wurde bereits über Eingabe einer TAN oder ähnliches legitimiert.
• Verwendung eines ID-Tokens: Diese Methode bietet aus Sicht des Käufers die geringsten Brüche in der Customer Experience, funktioniert allerdings nur, wenn das Konto schon einmal in dem Shop zum Kauf benutzt wurde. So hat in diesem Fall der Händler das ID-Token, das er von der Bank im Rahmen des ersten Kaufs bekommen hat, in seinem eigenen Backend-Verzeichnis gespeichert und mit dem Benutzer-Account des Käufers verknüpft. So kann der Shop bei jedem weiteren Kauf direkt eine entkoppelte Authentifizierung starten und – genauso, wie es auch in der CIBA-Spezifikation beschrieben ist – das gespeicherte Token als ID-Token-Hinweis weitergeben. Die Bank kann nun aus diesem ID-Token genügend Informationen extrahieren, um sicherzugehen, dass es sich tatsächlich um den Kunden handelt, der augenscheinlich den Einkauf tätigt.

In allen Fällen behält der Shop dank OpenBanking und CIBA stets die volle Kontrolle über die Customer Experience, da der Kunde keine Medienbrüche erlebt – denn die Website des Händlers wird trotz mehrfacher Authentifizierungen nie verlassen. Gleichzeitig ist die Sicherheit deutlich höher, da der API-Zugriff besser abgesichert ist. Jetzt müssen nur die deutschen Banken nachziehen und sich auf ein gemeinsames Framework einigen. Dann gehen auch hierzulande Sicherheit und Benutzerfreundlichkeit Hand in Hand.Rob Otto, Ping Identity