PSD2-API-Sicherheit: Leitfaden zur Open-Banking-Integration in Google Cloud

In der heutigen Fintech-Landschaft ist die Richtlinie PSD2 (Payment Services Directive 2) keine regulatorische Neuheit mehr, sondern der De-facto-Betriebsstandard für die Interoperabilität von Banken. Für Softwarearchitekten und DevOps-Ingenieure hat sich die Herausforderung jedoch von der reinen Compliance hin zur Implementierung robuster, skalierbarer und vor allem sicherer Architekturen verlagert. Wenn ein proprietäres CRM über Bank-APIs mit Kundenkonten verbunden wird, wird die PSD2-API-Sicherheit zum fundamentalen Pfeiler, auf dem die gesamte Infrastruktur ruht.

Dieser technische Leitfaden untersucht, wie man ein sicheres API-Gateway unter Verwendung des Google Cloud-Ökosystems aufbaut, mit einem speziellen Fokus auf Apigee als Vermittlungsschicht. Wir analysieren die notwendigen Architekturmuster zur Handhabung von mTLS-Authentifizierung, komplexen OAuth 2.0-Flows, Verschlüsselung sensibler Daten (PII) und operativer Resilienz gegen Latenzen von Drittbanken.

Voraussetzungen und architektonischer Kontext

Bevor wir in den Code und die Konfigurationen eintauchen, muss der operative Umfang definiert werden. In einem Open-Banking-Szenario agiert Ihre Anwendung typischerweise als TPP (Third Party Provider), speziell als AISP (Account Information Service Provider) oder PISP (Payment Initiation Service Provider).

Um diesem Leitfaden zu folgen, wird Folgendes vorausgesetzt:

• Ein aktives Google Cloud Platform (GCP)-Konto.
• Eine konfigurierte Instanz von Apigee X oder Apigee Hybrid.
• Gültige eIDAS-Zertifikate (QWAC und QSEAL), die für die formale Identifizierung gegenüber europäischen Banken erforderlich sind.
• Grundkenntnisse in Containern (falls Cloud Run/GKE für die CRM-Microservices verwendet wird).

Die “Secure Hub”-Architektur

Der empfohlene Ansatz ist das “Secure Hub”-Muster. Anstatt dem CRM zu erlauben, die Bank-APIs direkt aufzurufen, wird ein API-Gateway (Apigee) dazwischengeschaltet, das als einziger Punkt für die Durchsetzung von Sicherheitsrichtlinien fungiert. Der Datenfluss ist wie folgt:

CRM (Backend) → Google Cloud Apigee (Gateway) → ASPSP (Bank-API)

1. Implementierung von mTLS (Mutual TLS) für die Server-zu-Server-Authentifizierung

Gemäß den technischen Regulierungsstandards (RTS) der PSD2 reicht eine einfache Authentifizierung per API-Key für die Kommunikation zwischen TPP und Bank nicht aus. Die Verwendung von Mutual TLS (mTLS) ist obligatorisch.

Bei mTLS verifiziert nicht nur der Client (Sie) das Zertifikat des Servers (die Bank), sondern auch die Bank muss Ihr Client-Zertifikat (das eIDAS QWAC-Zertifikat) verifizieren. So konfigurieren Sie dies in Apigee:

Konfiguration von Keystore und TargetServer

In Apigee erfolgt die Verwaltung von mTLS zum Backend (der Bank) über die Definition von TargetServers.

1. Laden des Zertifikats: Laden Sie Ihr QWAC-Zertifikat (öffentlicher und privater Schlüssel) in den Apigee Keystore.
2. SSLInfo-Definition: Aktivieren Sie SSL in der TargetServer-Konfiguration und referenzieren Sie den Keystore.

<TargetServer name="Bank-API-Target">
  <Host>api.partner-bank.com</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
    <Enabled>true</Enabled>
    <ClientAuthEnabled>true</ClientAuthEnabled>
    <KeyStore>ref://my-qwac-keystore</KeyStore>
    <KeyAlias>my-key-alias</KeyAlias>
    <TrustStore>ref://bank-truststore</TrustStore>
  </SSLInfo>
</TargetServer>

Technischer Hinweis: Stellen Sie sicher, dass der TrustStore die vollständige Kette der CA enthält, die das Zertifikat der Bank ausgestellt hat, da der Handshake sonst fehlschlägt.

2. Token-Management: OAuth 2.0 und OIDC

Die PSD2-API-Sicherheit erfordert, dass der Zugriff auf Kontodaten vom Endnutzer explizit durch eine starke Kundenauthentifizierung (Strong Customer Authentication, SCA) autorisiert wird. Dies wird technisch im OAuth 2.0 Authorization Code Grant-Flow umgesetzt.

Die Rolle von Apigee als Token-Vermittler

Ihr CRM sollte niemals direkt die rohen Zugriffstoken der Banken verwalten, es sei denn, dies ist unbedingt erforderlich. Ein sicheres Muster sieht vor, dass Apigee den Token-Austausch verwaltet und dem CRM ein internes, undurchsichtiges Token (Opaque Token) bereitstellt.

1. Weiterleitung: Der Benutzer wird zum Login auf das Portal der Bank weitergeleitet.
2. Callback: Die Bank gibt einen authorization_code an Ihren Callback-Endpoint auf Apigee zurück.
3. Token-Austausch: Apigee ruft den /token-Endpoint der Bank unter Verwendung von mTLS auf und tauscht den Code gegen einen access_token und einen refresh_token.
4. Sichere Speicherung: Apigee verschlüsselt diese Token und speichert sie in seinem sicheren Cache (oder einer externen verschlüsselten Datenbank) und gibt eine Sitzungs-ID an das CRM zurück.

Dieser Ansatz reduziert die Angriffsfläche: Sollte die CRM-Datenbank kompromittiert werden, finden Angreifer keine gültigen Bank-Token.

3. Verschlüsselung sensibler Daten (PII) mit Google Cloud KMS

Finanzdaten (IBAN, Saldo, Transaktionen) sind kritische personenbezogene Daten (PII). Die DSGVO- und PSD2-Konformität schreibt eine Verschlüsselung sowohl bei der Übertragung (bereits durch TLS 1.2+ abgedeckt) als auch im Ruhezustand vor.

Envelope Encryption

Für Sicherheit auf Unternehmensniveau sollten Sie den Google Cloud Key Management Service (KMS) verwenden. Kodieren Sie Verschlüsselungsschlüssel niemals fest im Code oder in den Apigee-Konfigurationen.

Implementieren Sie eine Richtlinie der Envelope Encryption:

• Verwenden Sie einen DEK (Data Encryption Key), um die Payload der Bankantwort zu verschlüsseln, bevor sie gespeichert oder protokolliert wird.
• Verwenden Sie einen von Cloud KMS verwalteten KEK (Key Encryption Key), um den DEK zu verschlüsseln.

In Apigee können Sie eine ServiceCallout-Policy verwenden, um die Cloud KMS-APIs aufzurufen und die Schlüssel nur dann zu entschlüsseln, wenn dies für die Verarbeitung erforderlich ist, wodurch die Daten in den Systemprotokollen unkenntlich bleiben.

4. Resilienz-Muster: Circuit Breaker und Throttling

Bank-APIs, insbesondere solche von Legacy-Instituten, die an PSD2 angepasst wurden, können unter unvorhersehbaren Latenzen oder Ausfallzeiten leiden. Ein CRM, das unbegrenzt auf eine Bankantwort wartet, bietet eine schlechte User Experience und riskiert einen Kettenabsturz.

Implementierung des Circuit Breaker

Das Circuit-Breaker-Muster verhindert, dass ein Fehler in einem externen Dienst (der Bank) die Ressourcen Ihres Systems überlastet.

In Apigee gibt es keine native “Circuit Breaker”-Policy out-of-the-box, aber sie kann durch die Kombination von KVM (Key Value Maps) und bedingter Logik implementiert werden:

1. Wenn ein Aufruf an den TargetServer fehlschlägt oder ein Timeout auftritt, erhöhen Sie einen Zähler in der KVM.
2. Wenn der Zähler einen Schwellenwert überschreitet (z. B. 5 Fehler in 1 Minute), aktivieren Sie ein “Open Circuit”-Flag.
3. Nachfolgende Anfragen werden sofort mit einem benutzerdefinierten 503-Fehler abgelehnt, ohne zu versuchen, die Bank zu kontaktieren, damit sich das externe System erholen kann.
4. Nach einer Cool-down-Periode wechselt der Schaltkreis in den Status “Half-Open”, um die Konnektivität erneut zu testen.

Umgang mit Throttling (Spike Arrest und Quota)

Banken legen strenge Limits für die Anzahl der API-Aufrufe fest (z. B. 4 Aufrufe pro Tag für die Aktualisierung von Salden im Hintergrund). Das Überschreiten dieser Limits kann zur vorübergehenden Sperrung Ihres TPP-Zertifikats führen.

Verwenden Sie die Quota-Policy von Apigee, um diese Limits clientseitig anzuwenden:

<Quota name="CheckBankLimits">
    <Interval>1</Interval>
    <TimeUnit>day</TimeUnit>
    <Allow count="4"/>
    <Identifier ref="request.header.account_id"/>
    <Distributed>true</Distributed>
</Quota>

Um hingegen Ihr Backend vor plötzlichen Verkehrsspitzen zu schützen, verwenden Sie die SpikeArrest-Policy, die Verkehrsspitzen glättet, indem sie sie über die Zeit verteilt.

5. Validierung von Zertifikaten und Sicherheit der Payload

Neben dem Transport ist es wichtig, den Inhalt zu validieren. Gemäß den FAPI (Financial-grade API)-Spezifikationen, die im PSD2-Bereich häufig übernommen werden, müssen JWT-Token signiert und manchmal verschlüsselt sein.

Verwenden Sie die VerifyJWT-Policy von Apigee, um sicherzustellen, dass die von der Bank empfangenen Token gültig und nicht manipuliert sind. Konfigurieren Sie die Policy zur Validierung von:

• Der Signatur (unter Verwendung des öffentlichen Schlüssels der Bank, der via JWKS offengelegt wird).
• Der Zielgruppe (aud Claim), um sicherzustellen, dass das Token für Sie bestimmt ist.
• Dem Ablaufdatum (exp Claim).

Fazit

Die Implementierung der PSD2-API-Sicherheit ist keine triviale Aufgabe; sie erfordert eine Überlagerung von Netzwerkprotokollen (mTLS), Autorisierungsstandards (OAuth 2.0/OIDC) und Software-Engineering-Praktiken (Circuit Breakers). Durch die Verwendung von Google Cloud Apigee als zentralen Hub zentralisieren Sie die Komplexität, sodass Ihr CRM schlank bleibt und sich auf die Geschäftslogik konzentrieren kann, während das Gateway die kryptografische und regulatorische Compliance übernimmt.

Denken Sie daran, dass Sicherheit ein kontinuierlicher Prozess ist: Überwachen Sie ständig die (verschleierten) Protokolle über die Google Cloud Operations Suite und halten Sie Ihre QWAC-Zertifikate aktuell, um Dienstunterbrechungen zu vermeiden.

Häufig gestellte Fragen

Quellen und Vertiefung

1. Delegierte Verordnung (EU) 2018/389 (Technische Regulierungsstandards für SCA und sichere Kommunikation)
2. BaFin – Informationen zur Zweiten Zahlungsdiensterichtlinie (PSD2)
3. Deutsche Bundesbank – PSD2 und Zahlungsdienste
4. BSI – Informationen zur eIDAS-Verordnung und Vertrauensdiensten
5. Wikipedia – Mutual Transport Layer Security (mTLS)

Francesco Zinghinì

Elektronikingenieur mit der Mission, die digitale Welt zu vereinfachen. Dank seines technischen Hintergrunds in Systemtheorie analysiert er Software, Hardware und Netzwerkinfrastrukturen, um praktische Leitfäden zu IT und Telekommunikation anzubieten. Er verwandelt technische Komplexität in für alle zugängliche Lösungen.

LinkedInFacebookVollständige Biografie →