Startseite > Security > Mehr Sicherheit für Banken-APIs

Payment Services Directive 2

Mehr Sicherheit für Banken-APIs

4. Dezember 2019, 12:08 Uhr | Autor: Daniel Heck / Redaktion: Diana Künstler

Fortsetzung des Artikels von Teil 1

Sintflutartige Anfragen

Entscheidende Gründe also, APIs mit einer starken Sicherheitsstrategie zu versehen. Eine API-Sicherheit muss gewährleisten, dass Anfragen nur von autorisierten Nutzern stammen. Die Anfragen müssen zudem auf Schadcodes überprüft werden. Und auch die Anzahl der Anfragen muss kontrolliert werden. Denn ein sogenannter Distributed-Denial-of-Service-Angriff (DDoS) auf die API kann den gesamten Service einer Bank lahmlegen. Angreifer senden dabei sintflutartige Anfragen an das Netzwerk des jeweiligen Opfers. Die Masse eingehender Nachrichten erzwingt ein Abschalten des Systems und aller über dieses System bereitgestellten Dienste. DDoS-Attacken haben in der Vergangenheit bereits schwerwiegende Schäden ausgelöst. Die Bewältigung eines solchen Ransom-DDoS-Angriffs kann eine Bank mehrere Hunderttausende Euro kosten.

Wie lassen sich APIs schützen?
Gegen solche Attacken können herkömmliche Netzwerk-Firewalls wenig ausrichten. Da Firewalls in der Regel die erste Verteidigungslinie gegen Attacken aus dem Internet darstellen, sollten sie zwar beim Sicherheitskonzept auf keinen Fall fehlen. Da APIs jedoch auf Webebene kommunizieren, sind zusätzliche Schutzmechanismen erforderlich.

Kern dieses Schutzes ist eine sogenannte „Web Application Firewall“. Diese kann – im Unterschied zu herkömmlichen Firewalls – Daten überprüfen, die im HTTP- beziehungsweise HTTPS-Protokoll verkehren. Sobald bestimmte Inhalte als verdächtig eingestuft werden, verhindert die Web Application Firewall den Zugriff. Im Falle von DDoS- oder DoS-Attacken greift ein Scoring-Modell: Nimmt man als Schwellenwert zum Beispiel die Anzahl der Anfragen, die eine einzelne IP innerhalb eines festgelegten Zeitraums übermitteln darf, werden Anfragen gestoppt, die über diese Anzahl hinausgehen. Auf diese Weise sind Finanzinstitute geschützt und brauchen Attacken dieser Art nicht zu fürchten. Eine Web Application Firewall stellt das Kernelement zur Absicherung von APIs dar. Sie analysiert den Datenaustausch zwischen Clients und Webservern, prüft alle eingehenden Anfragen an den Webserver sowie dessen Antworten. Wenn bestimmte Inhalte als verdächtig eingestuft werden, wird der Zugriff über die Web Application Firewall verhindert. Insbesondere bietet sie Schutz vor Angriffen, die beispielsweise durch sogenannte Injektionsangriffe („SQL-Injection“), „Cross Site Scripting“ (XSS), „Session-Hijacking“ und andere Arten von Webangriffen ausgeführt werden.

Zusätzlicher API-Schutz
Da die Sicherheitsmaßnahmen bei einer Web Application Firewall sehr nah am Nutzer implementiert werden, kann kein bösartiger Datenverkehr ins Backend oder andere Bausteine, wie das API-Gateway, gelangen. Sie kann zudem die vom Gesetzgeber geforderten technischen Regulierungsstandards umsetzen. Mit zusätzlichen Sicherheitsmaßnahmen ist es zudem möglich, APIs mit einer Web Application Firewall noch umfassender zu schützen:

Starke Authentifizierungsmechanismen: In eine Web Application Firewall lassen sich moderne Authentifizierungsprotokolle wie OAuth/OpenID auf Basis von JSON Web-Tokens implementieren. Sie wird damit zum Authentifizierungsserver. Ein solcher „Resource Server“ verifiziert bereits authentifizierte Anfragen, die über ein Access-Token verfügen beziehungsweise blockt sie bei Bedarf ab.
Flow-Sanitization: Nicht mehr benötigte Daten werden in regelmäßigen Abständen aus dem Gedächtnisspeicher gelöscht. Auf diese Weise lassen sich beispielsweise Code-Injection-Angriffe verhindern.
API-spezifische Validierung: Wird eine Web Application Firewall nach den Spezifikationen der jeweiligen API programmiert, lässt sie nur Anfragen durch, die mit diesen Spezifikationen übereinstimmen.
Schutz vor „XXE” (XML External Entity)-Attacken: Die Auszeichnungssprache XML wird neben der Speicherung von Daten auch für die standardisierte Weitergabe dieser Daten verwendet. Aufgrund von Bugs kam es bei XML in der Vergangenheit zu Lücken, über die ein Zugriff auf den Code möglich ist und sich beliebige Dateien auslesen lassen. Ein XML-Parser erkennt sogenannte externe Entities im Payload, so dass die Web Application Firewall entsprechende Anfragen blockiert.
Signaturen: Werden die Nutzdaten signiert, kann sichergestellt werden, wer der Absender der Nachricht ist und dass die Nachricht nicht verändert wurde.
Verschlüsselung: Durch eine Verschlüsselung lässt sich die Vertraulichkeit einer Nachricht erhöhen. Nur autorisierte Nutzer mit dem richtigen Schlüssel können die Nachricht entschlüsseln.

Ein weiterer Aspekt sollte bei der API-Absicherung nicht außer Acht gelassen werden: Die vor allem mittelständisch aufgestellten Banken und Sparkassen benötigen IT-Sicherheitsstrategien, die auf die vorhandenen Ressourcen zugeschnitten sind. IT-Sicherheitsanwendungen dürfen daher nicht zu komplex sein, sodass auch ein kleines Team mit wenig Manpower sie bedienen kann. Zudem sollten die Lösungen nicht zu viel interne Rechenleistung belegen – denn das kann teuer werden. Hier können sich Software-as-a-Service-Lösungen anbieten. Web-Application-Firewall-as-a-Service-Lösungen ermöglichen Finanz-Instituten, ihre Webanwendungen zu schützen, ohne die gesamte erforderliche Backend-Infrastruktur verwalten und neue Fähigkeiten erlernen zu müssen. Je nach Bedarf lassen sich Features an die Bedürfnisse einer Bank anpassen. Entscheidend dabei ist allerdings, dass die Daten innerhalb der EU gespeichert und so die europäischen Datenschutzvorschriften erfüllt werden.

Daniel Heck ist Vice President Marketing bei Rohde & Schwarz Cybersecurity