Questa è una versione PDF del contenuto. Per la versione completa e aggiornata, visita:
Verrai reindirizzato automaticamente...
Nel panorama fintech odierno, la direttiva PSD2 (Payment Services Directive 2) non è più una novità normativa, ma lo standard operativo de facto per l’interoperabilità bancaria. Tuttavia, per gli architetti software e i DevOps engineer, la sfida si è spostata dalla semplice conformità all’implementazione di architetture robuste, scalabili e, soprattutto, sicure. Quando si connette un CRM proprietario ai conti correnti dei clienti tramite API bancarie, la sicurezza api psd2 diventa il pilastro fondamentale su cui si regge l’intera infrastruttura.
Questa guida tecnica esplora come costruire un gateway API sicuro utilizzando l’ecosistema Google Cloud, con un focus specifico su Apigee come layer di mediazione. Analizzeremo i pattern architetturali necessari per gestire l’autenticazione mTLS, i flussi OAuth 2.0 complessi, la crittografia dei dati sensibili (PII) e la resilienza operativa contro le latenze delle banche terze.
Prima di immergerci nel codice e nelle configurazioni, è necessario definire il perimetro operativo. In uno scenario di Open Banking, la vostra applicazione agisce tipicamente come TPP (Third Party Provider), specificamente come AISP (Account Information Service Provider) o PISP (Payment Initiation Service Provider).
Per seguire questa guida, si assume la disponibilità di:
L’approccio raccomandato è il pattern “Secure Hub”. Invece di permettere al CRM di chiamare direttamente le API delle banche, si interpone un API Gateway (Apigee) che funge da punto unico di applicazione delle policy di sicurezza. Il flusso dei dati è il seguente:
CRM (Backend) → Google Cloud Apigee (Gateway) → ASPSP (API Banca)
Secondo gli standard tecnici normativi (RTS) della PSD2, la semplice autenticazione tramite API Key non è sufficiente per la comunicazione tra TPP e Banca. È obbligatorio l’uso di Mutual TLS (mTLS).
In mTLS, non è solo il client (voi) a verificare il certificato del server (la banca), ma anche la banca deve verificare il vostro certificato client (il certificato eIDAS QWAC). Ecco come configurarlo su Apigee:
In Apigee, la gestione di mTLS verso il backend (la banca) avviene tramite la definizione di TargetServers.
<TargetServer name="Bank-API-Target">
<Host>api.banca-partner.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>Nota tecnica: Assicuratevi che il TrustStore contenga la catena completa della CA che ha emesso il certificato della banca, altrimenti l’handshake fallirà.
La sicurezza api psd2 richiede che l’accesso ai dati del conto sia autorizzato esplicitamente dall’utente finale tramite Strong Customer Authentication (SCA). Questo si traduce tecnicamente nel flusso OAuth 2.0 Authorization Code Grant.
Il vostro CRM non dovrebbe mai gestire direttamente i token di accesso grezzi delle banche se non strettamente necessario. Un pattern sicuro prevede che Apigee gestisca lo scambio dei token e fornisca al CRM un token opaco interno.
authorization_code al vostro endpoint di callback su Apigee./token della banca usando mTLS e scambia il codice per un access_token e un refresh_token.Questo approccio riduce la superficie di attacco: se il database del CRM viene compromesso, gli attaccanti non trovano token bancari validi.
I dati finanziari (IBAN, saldo, transazioni) sono PII (Personally Identifiable Information) critiche. La conformità GDPR e PSD2 impone la crittografia sia in transito (già coperta da TLS 1.2+) sia a riposo.
Per una sicurezza di livello enterprise, utilizzate Google Cloud Key Management Service (KMS). Non hardcodate mai le chiavi di crittografia nel codice o nelle configurazioni di Apigee.
Implementate un criterio di Envelope Encryption:
In Apigee, potete utilizzare una policy ServiceCallout per invocare le API di Cloud KMS e decifrare le chiavi solo quando necessario per l’elaborazione, mantenendo i dati offuscati nei log di sistema.
Le API bancarie, specialmente quelle di istituti legacy adattati alla PSD2, possono soffrire di latenze imprevedibili o downtime. Un CRM che attende indefinitamente una risposta bancaria offre una pessima User Experience e rischia il crash a catena.
Il pattern Circuit Breaker previene che un errore in un servizio esterno (la banca) saturi le risorse del vostro sistema.
In Apigee, non esiste una policy “Circuit Breaker” nativa out-of-the-box, ma si può implementare combinando KVM (Key Value Maps) e logica condizionale:
Le banche impongono limiti severi sul numero di chiamate API (es. 4 chiamate al giorno per il refresh dei saldi in background). Superare questi limiti può portare al blocco temporaneo del vostro certificato TPP.
Utilizzate la policy Quota di Apigee per applicare questi limiti lato client:
<Quota name="CheckBankLimits">
<Interval>1</Interval>
<TimeUnit>day</TimeUnit>
<Allow count="4"/>
<Identifier ref="request.header.account_id"/>
<Distributed>true</Distributed>
</Quota>Per proteggere invece il vostro backend da picchi di traffico improvvisi, utilizzate la policy SpikeArrest, che appiattisce i picchi di traffico distribuendoli nel tempo.
Oltre al trasporto, è vitale validare il contenuto. Secondo le specifiche FAPI (Financial-grade API), spesso adottate in ambito PSD2, i token JWT devono essere firmati e talvolta cifrati.
Utilizzate la policy VerifyJWT di Apigee per assicurarvi che i token ricevuti dalla banca siano validi e non manomessi. Configurate la policy per validare:
aud claim) per assicurarsi che il token sia destinato a voi.exp claim).Implementare la sicurezza api psd2 non è un compito banale; richiede una sovrapposizione di protocolli di rete (mTLS), standard di autorizzazione (OAuth 2.0/OIDC) e pratiche di ingegneria del software (Circuit Breakers). Utilizzando Google Cloud Apigee come hub centrale, centralizzate la complessità, permettendo al vostro CRM di rimanere leggero e focalizzato sulla logica di business, mentre il gateway si fa carico della conformità crittografica e normativa.
Ricordate che la sicurezza è un processo continuo: monitorate costantemente i log (offuscati) tramite Google Cloud Operations Suite e mantenete aggiornati i vostri certificati QWAC per evitare interruzioni di servizio.
Per implementare la Mutual TLS richiesta dagli standard tecnici, è necessario configurare i TargetServers in Apigee caricando il certificato eIDAS QWAC nel Keystore. Bisogna abilitare SSLInfo e assicurarsi che il TrustStore contenga la catena completa della CA della banca, garantendo così che entrambe le parti verifichino le rispettive identità digitali prima dello scambio dati.
L’approccio raccomandato è utilizzare Apigee come mediatore di token, evitando che il CRM gestisca direttamente i token di accesso grezzi. Il gateway scambia il codice di autorizzazione con la banca, cifra i token risultanti in una cache sicura e restituisce al backend solo un identificativo di sessione opaco, riducendo drasticamente la superficie di attacco in caso di violazione del database CRM.
Per proteggere dati critici come IBAN e saldi, si deve adottare la Envelope Encryption utilizzando Google Cloud KMS. Invece di inserire chiavi statiche nel codice, si utilizza una Data Encryption Key per cifrare il payload e una Key Encryption Key gestita da KMS per proteggere la chiave stessa, decifrando i dati solo al momento dell’elaborazione tramite policy specifiche.
È fondamentale implementare pattern di resilienza come il Circuit Breaker utilizzando le Key Value Maps di Apigee per interrompere le chiamate verso banche che non rispondono, evitando colli di bottiglia. Inoltre, l’uso delle policy di Quota e SpikeArrest permette di rispettare i limiti rigidi imposti dagli istituti finanziari, prevenendo il blocco dei certificati TPP per eccesso di richieste.
L’uso di un gateway centralizzato permette di adottare il pattern Secure Hub, dove la complessità normativa e crittografica viene disaccoppiata dalla logica di business del CRM. Apigee gestisce centralmente mTLS, validazione dei token e throttling, fungendo da scudo protettivo e garantendo che le policy di sicurezza siano applicate uniformemente a tutte le transazioni verso gli istituti bancari.