Questa è una versione PDF del contenuto. Per la versione completa e aggiornata, visita:
Verrai reindirizzato automaticamente...
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.
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:
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)
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:
In Apigee erfolgt die Verwaltung von mTLS zum Backend (der Bank) über die Definition von TargetServers.
<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.
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.
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.
authorization_code an Ihren Callback-Endpoint auf Apigee zurück./token-Endpoint der Bank unter Verwendung von mTLS auf und tauscht den Code gegen einen access_token und einen refresh_token.Dieser Ansatz reduziert die Angriffsfläche: Sollte die CRM-Datenbank kompromittiert werden, finden Angreifer keine gültigen Bank-Token.
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.
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:
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.
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.
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:
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.
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:
aud Claim), um sicherzustellen, dass das Token für Sie bestimmt ist.exp Claim).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.
Um die von den technischen Standards geforderte Mutual TLS zu implementieren, müssen die TargetServers in Apigee konfiguriert werden, indem das eIDAS QWAC-Zertifikat in den Keystore geladen wird. Man muss SSLInfo aktivieren und sicherstellen, dass der TrustStore die vollständige Kette der CA der Bank enthält, um so zu garantieren, dass beide Parteien ihre jeweiligen digitalen Identitäten vor dem Datenaustausch verifizieren.
Der empfohlene Ansatz ist die Verwendung von Apigee als Token-Vermittler, um zu vermeiden, dass das CRM direkt die rohen Zugriffstoken verwaltet. Das Gateway tauscht den Autorisierungscode mit der Bank aus, verschlüsselt die resultierenden Token in einem sicheren Cache und gibt nur eine undurchsichtige Sitzungs-ID an das Backend zurück, was die Angriffsfläche im Falle einer Verletzung der CRM-Datenbank drastisch reduziert.
Um kritische Daten wie IBAN und Salden zu schützen, muss die Envelope Encryption unter Verwendung von Google Cloud KMS angewendet werden. Anstatt statische Schlüssel im Code einzufügen, wird ein Data Encryption Key zur Verschlüsselung der Payload und ein von KMS verwalteter Key Encryption Key zum Schutz des Schlüssels selbst verwendet, wobei die Daten erst zum Zeitpunkt der Verarbeitung durch spezifische Policies entschlüsselt werden.
Es ist entscheidend, Resilienz-Muster wie den «Circuit Breaker» unter Verwendung der Key Value Maps von Apigee zu implementieren, um Aufrufe an nicht antwortende Banken zu unterbrechen und Engpässe zu vermeiden. Zudem ermöglicht die Nutzung von Quota- und SpikeArrest-Policies die Einhaltung der strengen Limits der Finanzinstitute und verhindert die Sperrung von TPP-Zertifikaten wegen übermäßiger Anfragen.
Die Nutzung eines zentralisierten Gateways ermöglicht die Einführung des Secure-Hub-Musters, bei dem die regulatorische und kryptografische Komplexität von der Geschäftslogik des CRM entkoppelt wird. Apigee verwaltet zentral mTLS, Token-Validierung und Throttling, fungiert als Schutzschild und garantiert, dass die Sicherheitsrichtlinien einheitlich auf alle Transaktionen mit Bankinstituten angewendet werden.