Questa è una versione PDF del contenuto. Per la versione completa e aggiornata, visita:
Verrai reindirizzato automaticamente...
No panorama fintech atual, a diretiva PSD2 (Payment Services Directive 2) já não é uma novidade regulamentar, mas sim o padrão operacional de facto para a interoperabilidade bancária. No entanto, para os arquitetos de software e engenheiros DevOps, o desafio deslocou-se da simples conformidade para a implementação de arquiteturas robustas, escaláveis e, acima de tudo, seguras. Quando se liga um CRM proprietário às contas bancárias dos clientes através de APIs bancárias, a segurança api psd2 torna-se o pilar fundamental sobre o qual assenta toda a infraestrutura.
Este guia técnico explora como construir um gateway API seguro utilizando o ecossistema Google Cloud, com um foco específico no Apigee como camada de mediação. Analisaremos os padrões arquiteturais necessários para gerir a autenticação mTLS, fluxos OAuth 2.0 complexos, a encriptação de dados sensíveis (PII) e a resiliência operacional contra as latências de bancos terceiros.
Antes de mergulharmos no código e nas configurações, é necessário definir o perímetro operacional. Num cenário de Open Banking, a vossa aplicação atua tipicamente como TPP (Third Party Provider), especificamente como AISP (Account Information Service Provider) ou PISP (Payment Initiation Service Provider).
Para seguir este guia, assume-se a disponibilidade de:
A abordagem recomendada é o padrão “Secure Hub”. Em vez de permitir que o CRM chame diretamente as APIs dos bancos, interpõe-se um API Gateway (Apigee) que atua como ponto único de aplicação das políticas de segurança. O fluxo de dados é o seguinte:
CRM (Backend) → Google Cloud Apigee (Gateway) → ASPSP (API Banco)
De acordo com as normas técnicas regulamentares (RTS) da PSD2, a simples autenticação através de API Key não é suficiente para a comunicação entre TPP e Banco. É obrigatório o uso de Mutual TLS (mTLS).
No mTLS, não é apenas o cliente (vocês) a verificar o certificado do servidor (o banco), mas também o banco deve verificar o vosso certificado de cliente (o certificado eIDAS QWAC). Eis como configurá-lo no Apigee:
No Apigee, a gestão de mTLS para o backend (o banco) é feita através da definição de 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 técnica: Certifiquem-se de que o TrustStore contém a cadeia completa da CA que emitiu o certificado do banco, caso contrário o handshake falhará.
A segurança api psd2 exige que o acesso aos dados da conta seja autorizado explicitamente pelo utilizador final através de Strong Customer Authentication (SCA). Isto traduz-se tecnicamente no fluxo OAuth 2.0 Authorization Code Grant.
O vosso CRM nunca deve gerir diretamente os tokens de acesso brutos dos bancos, a menos que seja estritamente necessário. Um padrão seguro prevê que o Apigee gira a troca de tokens e forneça ao CRM um token opaco interno.
authorization_code para o vosso endpoint de callback no Apigee./token do banco usando mTLS e troca o código por um access_token e um refresh_token.Esta abordagem reduz a superfície de ataque: se a base de dados do CRM for comprometida, os atacantes não encontrarão tokens bancários válidos.
Os dados financeiros (IBAN, saldo, transações) são PII (Personally Identifiable Information) críticas. A conformidade com o RGPD e a PSD2 impõe a encriptação tanto em trânsito (já coberta pelo TLS 1.2+) como em repouso.
Para uma segurança de nível empresarial, utilizem o Google Cloud Key Management Service (KMS). Nunca coloquem chaves de encriptação hardcoded no código ou nas configurações do Apigee.
Implementem um critério de Envelope Encryption:
No Apigee, podem utilizar uma política ServiceCallout para invocar as APIs do Cloud KMS e decifrar as chaves apenas quando necessário para o processamento, mantendo os dados ofuscados nos logs do sistema.
As APIs bancárias, especialmente as de instituições legacy adaptadas à PSD2, podem sofrer de latências imprevisíveis ou downtime. Um CRM que aguarda indefinidamente uma resposta bancária oferece uma péssima Experiência de Utilizador e arrisca um crash em cadeia.
O padrão Circuit Breaker previne que um erro num serviço externo (o banco) sature os recursos do vosso sistema.
No Apigee, não existe uma política “Circuit Breaker” nativa pronta a usar, mas pode ser implementada combinando KVM (Key Value Maps) e lógica condicional:
Os bancos impõem limites severos ao número de chamadas API (ex. 4 chamadas por dia para a atualização de saldos em background). Exceder estes limites pode levar ao bloqueio temporário do vosso certificado TPP.
Utilizem a política Quota do Apigee para aplicar estes limites do lado do cliente:
<Quota name="CheckBankLimits">
<Interval>1</Interval>
<TimeUnit>day</TimeUnit>
<Allow count="4"/>
<Identifier ref="request.header.account_id"/>
<Distributed>true</Distributed>
</Quota>Para proteger, por outro lado, o vosso backend de picos de tráfego repentinos, utilizem a política SpikeArrest, que achata os picos de tráfego distribuindo-os ao longo do tempo.
Além do transporte, é vital validar o conteúdo. De acordo com as especificações FAPI (Financial-grade API), frequentemente adotadas no âmbito da PSD2, os tokens JWT devem ser assinados e, por vezes, cifrados.
Utilizem a política VerifyJWT do Apigee para garantir que os tokens recebidos do banco são válidos e não foram adulterados. Configurem a política para validar:
aud) para garantir que o token se destina a vocês.exp).Implementar a segurança api psd2 não é uma tarefa trivial; requer uma sobreposição de protocolos de rede (mTLS), padrões de autorização (OAuth 2.0/OIDC) e práticas de engenharia de software (Circuit Breakers). Ao utilizar o Google Cloud Apigee como hub central, centralizam a complexidade, permitindo que o vosso CRM permaneça leve e focado na lógica de negócio, enquanto o gateway assume a responsabilidade pela conformidade criptográfica e regulamentar.
Lembrem-se que a segurança é um processo contínuo: monitorizem constantemente os logs (ofuscados) através da Google Cloud Operations Suite e mantenham os vossos certificados QWAC atualizados para evitar interrupções de serviço.
Para implementar o Mutual TLS exigido pelas normas técnicas, é necessário configurar os TargetServers no Apigee carregando o certificado eIDAS QWAC no Keystore. Deve-se ativar o SSLInfo e garantir que o TrustStore contém a cadeia completa da CA do banco, garantindo assim que ambas as partes verifiquem as respetivas identidades digitais antes da troca de dados.
A abordagem recomendada é utilizar o Apigee como mediador de tokens, evitando que o CRM gira diretamente os tokens de acesso brutos. O gateway troca o código de autorização com o banco, cifra os tokens resultantes numa cache segura e devolve ao backend apenas um identificador de sessão opaco, reduzindo drasticamente a superfície de ataque em caso de violação da base de dados do CRM.
Para proteger dados críticos como IBAN e saldos, deve-se adotar a «Envelope Encryption» utilizando o Google Cloud KMS. Em vez de inserir chaves estáticas no código, utiliza-se uma Data Encryption Key para cifrar o payload e uma Key Encryption Key gerida pelo KMS para proteger a própria chave, decifrando os dados apenas no momento do processamento através de políticas específicas.
É fundamental implementar padrões de resiliência como o «Circuit Breaker» utilizando as Key Value Maps do Apigee para interromper as chamadas para bancos que não respondem, evitando estrangulamentos. Além disso, o uso das políticas de Quota e SpikeArrest permite respeitar os limites rígidos impostos pelas instituições financeiras, prevenindo o bloqueio dos certificados TPP por excesso de pedidos.
O uso de um gateway centralizado permite adotar o padrão «Secure Hub», onde a complexidade regulamentar e criptográfica é desacoplada da lógica de negócio do CRM. O Apigee gere centralmente o mTLS, a validação de tokens e o throttling, atuando como um escudo protetor e garantindo que as políticas de segurança sejam aplicadas uniformemente a todas as transações com as instituições bancárias.