Design einer sicheren Open-Banking-Umgebung
This post is also available in:
Englisch 
Französisch 
Italienisch 
Portugiesisch, Brasilien 
Spanisch 
Russisch
Viele von uns nutzen innovative Produkte wie Mint, Chime oder Venmo, ohne sich darüber bewusst zu sein, dass sie auf Open-Banking-APIs basieren.
Die Open-Banking-Initiative wurde vor allem von der zweiten europäischen Zahlungsdienste-Richtlinie (Payment Services Directive 2, kurz PSD2) vorangetrieben. Ihr Ziel lautet, geschlossene und proprietäre Kundendaten von Banken, die Einlagen entgegennehmen, über öffentliche APIs auf sichere Weise für externe Drittanbieter zugänglich zu machen. Dadurch sollen sowohl die Innovation als auch der Wettbewerb angekurbelt werden. Im Gegensatz zum traditionellen Bankwesen, bei dem alle Kundendaten von der Hauptbank verwaltet werden, können die Kundendaten beim Open Banking über APIs sicher an Drittanbieter weitergegeben werden – aber nur, falls der Kunde sein Einverständnis erteilt hat. Laut Gartner-Prognosen für 2022 werden sich API-Angriffe, die Datensicherheitsverletzungen in Webapplikationen von Unternehmen verursachen, zum häufigsten Angriffsvektor entwickeln. Für echte API-Sicherheit müssen mehrere Herausforderungen gemeistert werden: Abdeckung der Bedrohungen, einfache Integration sowie vollständige Transparenz für dokumentierte und nicht dokumentierte APIs.
Gemäß einer Celent-Studie von 2018 wird die Zahl der US-Finanzinstitutionen mit Open-Banking-Portalen, die den Drittanbieterzugriff auf Finanzdaten und andere Daten von Verbrauchern ermöglichen, bis Ende 2021 von 20 auf über 200 anwachsen. Im ersten Quartal 2020 waren im Vereinigten Königreich mehr als 300 Drittanbieter registriert. Andere Länder wie Indien und Australien, die der Vorgehensweise in der EU gefolgt sind, haben ein florierendes Open-Banking-Ökosystem.
Open-Banking-APIs – was kann schiefgehen?
Vor der Einführung von Open Banking setzten viele innovative FinTech-Anbieter auf Screen Scraping, um ohne Wissen der Hauptbank auf Kundendaten zuzugreifen, darunter auch Benutzerzugangsdaten. Open-Banking-APIs sollen die rechtlichen Auswirkungen der gemeinsamen Nutzung von Kundendaten über APIs sowie das damit verbundene Einverständnis und die Regulierung vereinfachen.
Neben diesen enormen Vorteilen bringen APIs aber auch Verfügbarkeits- und Sicherheitsrisiken mit sich, wie zum Beispiel:
- Serviceunterbrechungen: API-Services können aus verschiedenen Gründen nicht verfügbar sein, z. B. fehlerhafte Sicherheits-, Netzwerk- und Applikationskonfiguration, DoS-Angriffe auf APIs sowie Ausfälle der Applikations- oder Authentifizierungsinfrastruktur.
- Mangelndes Vertrauen: Viele Open-Banking-Lösungen beruhen auf einer reinen Cloud-Infrastruktur oder auf einer hybriden Infrastruktur. Bei der Migration auf Public Clouds mangelt es jedoch an Vertrauen, z. B. aufgrund von nicht kompatiblen Sicherheitslösungen, Schwierigkeiten bei der umgebungsübergreifenden Konfiguration, Fehlkonfigurationen oder Problemen mit Applikationssicherheitsrichtlinien und -profilen.
- Wachsende Angriffsfläche: API-Angriffe unterschiedlichster Art sind weitverbreitet. Aus einer Umfrage von Radware geht hervor, dass 55 % aller Unternehmen mindestens einmal monatlich einen DoS-Angriff auf ihre APIs verzeichnen. 48 % registrieren mindestens einen Injection-Angriff pro Monat, und 42 % sind mindestens einmal im Monat von einer Element-/Attribut-Manipulation betroffen. Daneben gibt es auch noch Angriffe auf die API-Authentifizierung und -Autorisierung, eingebettete Angriffe wie SQL-Injection, Cross-Site-Scripting (XSS) und Bot-Angriffe.
- Bot-Angriffe auf APIs: Bot-Angriffe nutzen automatisierte Programme für diverse Zwecke: Eindringen in Benutzerkonten, Identitätsdiebstahl, Zahlungsbetrug, Scraping von Inhalten, Preisen, Gutscheinen oder Daten, Verbreitung von Spam oder Propaganda und Beeinträchtigung der Geschäftsaktivitäten.
- Datendiebstahl: In vielen APIs werden sensible personenbezogene Daten verarbeitet. Die Kombination aus sensiblen, vertraulichen Informationen und dem mangelnden Einblick in die Funktionsweise dieser APIs und Drittanbieterapplikationen erweist sich im Fall von Sicherheitsverletzungen als echter Alptraum.
- Nicht dokumentierte, aber veröffentlichte APIs: Über nicht dokumentierte APIs können sensible Informationen versehentlich offengelegt werden, falls sie nicht getestet wurden. Außerdem sind diese APIs möglicherweise für Manipulationen und Schwachstellenausnutzung anfällig.
Warum reichen API-Gateway und WAF nicht aus?
Weil Bedrohungen vielfältig sind, erfordert API-Sicherheit eine Kombination aus verschiedenen Maßnahmen, darunter:
- API-Zugriffskontrollen für Authentifizierung, Autorisierung und Zugriffsmanagement
- Schutz vor Bot-Angriffen auf APIs
- Abwehr von DDoS-Attacken und Angriffen auf die Verfügbarkeit
- Schutz vor eingebetteten Angriffen, API-Schwachstellen und API-Manipulationen
- Verhinderung von Datenlecks bei personenbezogenen Daten und Vermeidung unnötiger Datenexposition
- Schutz vor Betrug und Phishing
DDoS-Schutz, WAFs und API-Gateways bilden traditionellerweise die wichtigsten Schutzmaßnahmen für APIs. API-Gateways ermöglichen zwar API-Management und eine Integration mit Authentifizierungs- und Autorisierungsfunktionen, bieten aber nur begrenzte oder gar keine Funktionen für API-Sicherheit, Bot-Abwehr und Webapplikationsschutz. Die meisten WAFs können nicht zwischen APIs und regulären Webapplikationen unterscheiden. Und selbst wenn sie dazu in der Lage sind, findet keine Inspektion oder Erkennung echter API-Sicherheitsrisiken statt.
[Das könnte Sie auch interessieren: 4 Questions to Ask About Open Banking Compliance]
Bots sind nicht immer freundlich oder sichtbar!
APIs sind auch durch Bot-Angriffe gefährdet. Laut Forrester stammen mehr als ein Viertel aller Webanfragen von schädlichen Bots. Mit diesen Bots werden automatisierte API-Angriffe verübt, deren Ziel in einer Kontoübernahme, Denial of Service, Zahlungsdatenmissbrauch oder Denial of Inventory besteht. APIs müssen auf andere Weise vor automatisierten Angriffen geschützt werden als Web- und mobile Applikationen, weil sich das Bot-Verhalten, der Navigationsablauf und die Indikatoren unterscheiden.
Weil die meisten Unternehmen keine speziellen Bot-Management-Tools einsetzen, haben sie ein höheres Risiko für erfolgreiche Hacker-Angriffe über APIs, z. B. in Form von Credential Stuffing, Brute Force und Scraping.
Was wird für sichere Open-Banking-APIs benötigt?
Die Radware-Lösung wurde für den Schutz von APIs vor Hackern und staatlich gelenkten Angriffen konzipiert. Die Lösung schützt die APIs von Applikationen vor Denial-of-Service-, Anwendungs- und Bot-Angriffen, Schwachstellen und Manipulationen sowie vor Serviceausfällen. Gleichzeitig werden Vertrauens- und Sicherheitsbedenken von Kunden ausgeräumt, die auf eine Multi-Cloud- oder Hybrid-Umgebung migrieren.
Fazit:
Obwohl Open Banking noch in den Kinderschuhen steckt, breitet es sich rasant aus. Mithilfe von Open Banking werden Kundendaten über APIs für externe Drittanbieter zugänglich, um innovative Services bereitzustellen. Dies geht jedoch mit einer breiteren Angriffsfläche einher, die es vor Missbrauch und bösen Absichten zu schützen gilt. Banken und FinTech-Unternehmen, die in diesem Umfeld aktiv sind, sorgen für sichere Lösungen, mit denen sich das Vertrauen der Kunden gewinnen lässt. Um mehr darüber zu erfahren, wie Radware Sie unterstützen kann, besuchen Sie folgende Radware-Webseite: Frictionless Security At The Pace of Innovation.
