GlobalSign Blog

19 Sep 2018

Sichere APIs für Open Banking-Partnerschaften: Teil 1 - Starke Kundenauthentifizierung

Jon Scheele, Berater und Trainer für Open Banking, erläutert in seiner Beitragsreihe wie Finanzinstitute und FinTechs neue Technologien in der Verordnungslandschaft der Europäischen Union (EU) am besten implementieren.

In einem vorangegangenen  Beitrag hat sich der Autor damit befasst, was notwendig ist, um Cybersicherheit in Partnerschaften zwischen Finanzinstitutionen und FinTechs zu integrieren. In diesem Text konzentriert sich der Autor auf die Auswirkungen von Cybersicherheit auf die Verordnungslandschaft der EU nach der Open-Banking-Ära und welche Rolle sichere APIs dabei spielen.

Behördliche Vorgaben wie die Open-Banking-Initiative im Vereinigten Königreich und die überarbeitete Richtlinie für Zahlungsdienste (PSD2) in Europa sollen Innovationen, Wettbewerb und finanzielle Inklusion fördern. Zukunftsorientierte Finanzinstitute sehen das als vielversprechende Möglichkeit, ihr Werteversprechen auszubauen. Partnerschaften mit sogenannten FinTechs gehören dazu. Das sind Finanzdienstleister, die über moderne Technologien funktionieren und mit Banken über offene APIs (Application Programming Interfaces) kooperieren. Mit neuen Partnern das bisherige Angebot verbessern, das klingt gut. Es setzt allerdings voraus, dass die Anbieter mit den aktuellen IT-Sicherheitsvorgaben rund um die Datenweitergabe konform gehen.

Dazu beschäftigen wir uns zuerst mit den Verordnungen, die Open Banking-Partnerschaften betreffen.

Geltende Verordnungen für Open Banking-Partnerschaften

eIDAS

Mit eIDAS haben wir uns bereits an anderer Stelle befasst. "Der Weg zu eIDAS":

„Um das Ziel eines sich wandelnden digitalen Marktes umzusetzen, wurde die Verordnung der Europäischen Union über elektronische Identifizierung und Vertrauensdienste (eIDAS) ins Leben gerufen. eIDAS stellt einen elektronischen Identifikationsstandard auf, um sichere und optimierte Online-Transaktionen in ganz Europa zu gewährleisten. Zu diesem Zweck stützt sich die Verordnung auf elektronische Vertrauensdienste.“

Vor eIDAS scheinen digitale Identitätsdienste für Finanzinstitute im Vereinigten Königreich eine eher untergeordnete Rolle gespielt zu haben. Wenigstens verglichen mit anderen Bereichen, wie Diensten für das Initiieren von Zahlungen und die Aggregation von Konten beispielsweise. Das ist nicht in allen europäischen Staaten so. Die italienische Regierung hat SPID (Sistema Pubblico Identita Digitale) ins Leben gerufen, ein nationales Identitätssystem, das den Zugang zu öffentlichen Diensten über eine einzige digitale Identität erlaubt. Damit hat die Regierung effizientere Prozesse etabliert und die wirtschaftliche Entwicklung Italiens gefördert. Frankreich, die Niederlande und Deutschland ziehen jetzt nach, die nordischen Länder haben hier schon länger die Nase vorn.

Wenn Finanzinstitute APIs für ihre FinTechs entwickeln, braucht man zwingend ein einziges agiles Rahmenwerk. Schließlich sind Reporting-Services über mehrere Geschäftsbereiche hinweg nötig, zeitweise sogar über Grenzen und zwischen unterschiedlichen Infrastrukturen.

PSD2

PSD2 schreibt vor, dass Finanzinstitute (wie Banken) den Zugang zu ihren Kundendaten und Zahlungsnetzwerken für Dritte öffnen müssen. Banken stellen diesen Zugang über ein sicheres und standardisiertes Set von APIs bereit, so dass Kunden Kontoinformationen abrufen und Zahlungen auslösen können. Das setzt eine "starke Kundenauthentifizierung" voraus. Eine einfache Kombination aus Benutzername und Passwort reicht dafür nicht aus. Multi-Faktor-Authentifizierung, die zwei oder mehr Merkmale nutzt, ist zwingend vorgeschrieben. Sie werden aus dem ausgewählt, was ein Kunde weiß (‚Wissen‘), einem in das Mobiltelefon eingebetteten digitalen Zertifikat (‚Besitz‘) oder biometrischen Daten wie Fingerabdruck- oder Iris-Scans, um nachzuweisen, wer der Kunde ist (‚Inhärenz').

Die neue Verordnungslandschaft hat ambitionierte Ziele:

  • Ein erweitertes Cybersicherheits-Ökosystem über die Infrastruktur und Apps eines Finanzinstituts hinaus. Finanzinstitute sind aber nach wie vor für die Sicherheit und den Schutz von Kundendaten und -geldern verantwortlich. Daher müssen sie Cybersicherheits- und Datenschutzprozesse auch bei ihren Partnern sorgfältig überprüfen.
  • Skalierbare Cybersicherheitsmaßnahmen bei Finanzinstituten, um der wachsenden Zahl von Partnerschaften Rechnung zu tragen. Hier ist eine deutlich größere Angriffsfläche entstanden (die auch das Ergebnis der verstärkten Datensammlung und Datenweitergabe ist).
  • Das Festlegen von Richtlinien und Standards, nach denen Finanzinstitute mit FinTechs zusammenarbeiten. FinTechs arbeiten nach anderen Vorgaben und sind deutlich weniger reguliert. Banken können bei einer sicheren Integration Hilfestellung leisten.
  • Sicherheit mit einer positiven Kundenerfahrung in Einklang zu bringen.

PSD2 gewährt FinTechs wie zum Beispiel Drittanbietern von Zahlungsdiensten den Zugang zum europäischen Zahlungsmarkt. Und den Zugriff auf sensible Verbraucherdaten mit dem Ziel, bequeme und sichere Zahlungsdienste anzubieten. Dieser zusätzliche Komfort kommt allerdings nicht ohne zusätzliche Schutzmaßnahmen für alle sensiblen Daten aus, die sich in diesem Ökosystem bewegen.

Regulatory Technical Standards on Strong Customer Authentication (RTS SCA)

Darüber hinaus und ab September 2019 anzuwenden, spezifizieren die technischen Regulierungsstandards für eine starke Kundenauthentifizierung (RTS SCA) verschiedene Elemente, um eine starke Kundenauthentifizierung sowie gemeinsame, sichere und offene Kommunikationsstandards unter PSD2 zu gewährleisten. Dazu gehört eine detaillierte Definition der Elemente, die SCA erfordern, wie z. B. die Verwendung von Multi-Faktor-Authentifizierung (oben definiert).

Die Datenschutz-Grundverordnung (DSGVO)

Darüber hinaus erfordert die Datenschutzgrundverordnung (DSGVO) die Einwilligung des Kunden in die Partnerschaftsstrategie einzubinden. Kunden entscheiden darüber, welche Daten an wen und zu welchem Zweck weitergegeben werden dürfen. Sie müssen außerdem ihre Einwilligung widerrufen sowie das Löschen ihrer Daten einfordern können.

Alle Anforderungen unter einen Hut bringen

Um eine sichere Open Banking-Initiative zu verabschieden, sollten Finanzinstitute die folgenden Anforderungen berücksichtigen:

  • Kunden authentifizieren,
  • Einwilligung (Autorisierung) von Kunden, Daten an Partner weiterzugeben, einholen
  • Einwilligung für Prüfungszwecke aufzeichnen,
  • Kunden erlauben, die Einwilligung zu widerrufen,
  • Partner und deren Cybersicherheitsstatus überprüfen,
  • Partnern sicheren Zugang zu Kundendaten gewähren (und nur zu den Daten, in deren Weitergabe der Kunde eingewilligt hat).

Einwilligung erhalten und Kunden in Open Banking-Partnerschaften authentifizieren

Alle genannten Vorschriften und Anforderungen gehen in dieselbe Richtung. Finanzdienstleister (FinTechs und klassische Finanzinstitute) sollen die Möglichkeit haben ihr Werteversprechen auszuweiten. Dabei ruht der Erfolg auf mehreren Säulen:

  • Attraktive Partner gewinnen und zusätzliche Wahlmöglichkeiten anbieten, die für mehr Kundenzufriedenheit sorgen;
  • es Kunden einfach und sicher zu machen, ihre Einwilligung zur Weitergabe sensibler Daten an Partner und Dritte zu erteilen (oder zu widerrufen) und
  • sicherzustellen, dass Partner und Drittanbieter über starke Cybersicherheitsmaßnahmen zum Schutz der übermittelten Kundendaten verfügen.

Entwickler in Finanzinstituten sollten diese Maßnahmen implementieren, um die Einwilligung ihrer Kunden zu bekommen, bevor Daten an FinTechs weitergegeben werden.

Empfohlener Workflow für die API-Authentifizierung

Offene Standard-Protokolle zur Authentifizierung wie OAuth und OpenID Connect sind derzeit Best Practice, um Dritten Zugang zu Kontodaten zu gestatten und gleichzeitig die Vertraulichkeit der Anmeldedaten zu wahren. Abhängig von der aufgerufenen Aktivität wie z. B. einer Überweisung oder Zahlung, ist eine erneute Authentifizierung erforderlich.

Die Autorisierung läuft in folgenden Schritten ab:

  1. Der Kunde verwendet die Applikation eines Partners für Endbenutzer. Die Anwendung versucht, auf das Konto des Benutzers zuzugreifen und benötigt dazu dessen Erlaubnis.
  2. Die App wird zum Autorisierungsserver des Finanzinstituts geleitet. Dieser Server fungiert als Schnittstelle, an der ein Benutzer die Anforderung genehmigt oder ablehnt.
  3. Der Kunde wird nach OpenID Connect mittels Multi-Faktor-Authentifizierung authentifiziert (z. B. durch ein digitales Zertifikat, das in das Gerät des Kunden eingebettet ist).
  4. Der Kunde wird aufgefordert, die Weitergabe von Daten über die betreffende Anwendung zu autorisieren (einzuwilligen). Die tatsächlich weiterzugebenden Daten werden durch den "Umfang der Einwilligung" definiert.
  5. Der Kunde wird zur betreffenden App zurückgeleitet und die Einwilligung mit einem Autorisierungscode genehmigt.
  6. Die Endbenutzer-App fordert den Autorisierungsserver auf, seinen Autorisierungscode gegen ein Autorisierungs-Token zu tauschen. Dieser zusätzliche Schritt ermöglicht dem Autorisierungsserver eine weitere Prüfung. Sie stellt sicher, dass die Endbenutzeranwendung tatsächlich zur erwarteten Person gehört.
  7. Die Anwendung liefert ihr Autorisierungs-Token dem Ressourcenserver des Finanzinstituts, um Zugang zu den Daten zu bekommen, für die der Kunde seine Einwilligung gegeben hat.

Die oben erwähnten regulatorischen Anforderungen gewährleisten Best Practices für die Identifizierung und Authentifizierung. So soll vorab ein Sicherheitsniveau gewährleistet sein, das sich in Einklang mit einem Markt für vertrauenswürdige Transaktionen innerhalb der EU befindet. Finanzinstitute und FinTechs müssen diese Standards und Tools früher oder später in Dienste und im Rahmen ihrer Partnerschaften integrieren.

Im nächsten Beitrag geht es um die Referenzarchitektur von APIs für das Open Banking und darum wie Finanzinstitute und FinTechs innerhalb dieser Architektur Daten sicher weitergeben.

Weitere Informationen zu PSD2 und SCA, einschließlich Zeitleisten, finden Sie auch in dieser Infografik des European Payments Council - PSD2 Explained.

Über den Autor

Jon Scheele ist Berater und Trainer, der Finanzinstitute und FinTechs bei der Entwicklung von API-fähigen Partnerschaften unterstützt. In seinem Kurs Building Financial Services Open APIs (Aufbau von Open APIs für Finanzdienste) schult der Autor Finanzdienstleister in Strategie, Design, Implementierung und Produktmanagement von APIs.

Hinweis: Dieser Blog Artikel wurde von einem Gastautor geschrieben, um unseren Lesern eine breitere Vielfalt an Inhalten anzubieten. Die in diesem Gastautorenartikel ausgedrückten Meinungen sind nur die des Autors und geben nicht unbedingt die von GlobalSign wieder.

Artikel teilen