Segurança API PSD2: Guia de Integração Open Banking na Google Cloud

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.

Pré-requisitos e Contexto Arquitetural

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:

• Uma conta Google Cloud Platform (GCP) ativa.
• Uma instância de Apigee X ou Apigee Hybrid configurada.
• Certificados eIDAS (QWAC e QSEAL) válidos, necessários para a identificação formal perante os bancos europeus.
• Conhecimentos básicos de contentores (se utilizar Cloud Run/GKE para os microsserviços do CRM).

A Arquitetura “Secure Hub”

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)

1. Implementação de mTLS (Mutual TLS) para Autenticação Server-to-Server

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:

Configuração do Keystore e TargetServer

No Apigee, a gestão de mTLS para o backend (o banco) é feita através da definição de TargetServers.

1. Carregamento do Certificado: Carreguem o vosso certificado QWAC (chave pública e privada) no Keystore do Apigee.
2. Definição SSLInfo: Na configuração do TargetServer, ativem o SSL e referenciem o Keystore.

<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á.

2. Gestão de Tokens: OAuth 2.0 e OIDC

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 Papel do Apigee como Mediador de Tokens

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.

1. Redirecionamento: O utilizador é redirecionado para o portal do banco para o login.
2. Callback: O banco devolve um authorization_code para o vosso endpoint de callback no Apigee.
3. Troca de Token: O Apigee chama o endpoint /token do banco usando mTLS e troca o código por um access_token e um refresh_token.
4. Armazenamento Seguro: O Apigee cifra estes tokens e armazena-os na sua cache segura (ou numa base de dados externa cifrada), devolvendo ao CRM um identificador de sessão.

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.

3. Encriptação de Dados Sensíveis (PII) com Google Cloud KMS

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.

Envelope Encryption

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:

• Utilizem uma DEK (Data Encryption Key) para cifrar o payload da resposta bancária antes de ser guardado ou registado em log.
• Utilizem uma KEK (Key Encryption Key) gerida pelo Cloud KMS para cifrar a DEK.

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.

4. Padrões de Resiliência: Circuit Breaker e Throttling

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.

Implementação do Circuit Breaker

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:

1. Se uma chamada ao TargetServer falhar ou entrar em timeout, incrementem um contador no KVM.
2. Se o contador exceder um limite (ex. 5 erros em 1 minuto), ativem uma flag “Open Circuit”.
3. As requisições subsequentes são rejeitadas imediatamente com um erro 503 personalizado, sem tentar contactar o banco, permitindo que o sistema externo recupere.
4. Após um período de cool-down, o circuito passa ao estado “Half-Open” para testar novamente a conectividade.

Gestão de Throttling (Spike Arrest e Quota)

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.

5. Validação de Certificados e Segurança do Payload

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:

• A assinatura (usando a chave pública do banco exposta via JWKS).
• A audiência (claim aud) para garantir que o token se destina a vocês.
• A validade (claim exp).

Conclusões

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.

Perguntas frequentes

Fontes e Aprofundamento

1. Texto oficial da Diretiva (UE) 2015/2366 relativa aos serviços de pagamento (PSD2)
2. Autoridade Bancária Europeia: Normas Técnicas (RTS) sobre autenticação forte e comunicação segura
3. Banco de Portugal: Enquadramento da Diretiva de Serviços de Pagamento (DSP2)
4. Comissão Europeia: Regulamento eIDAS sobre identificação eletrónica e serviços de confiança
5. Wikipédia: Visão geral sobre o conceito e funcionamento do Open Banking

Francesco Zinghinì

Engenheiro Eletrônico com a missão de simplificar o digital. Graças à sua formação técnica em Teoria de Sistemas, analisa software, hardware e infraestruturas de rede para oferecer guias práticos sobre informática e telecomunicações. Transforma a complexidade tecnológica em soluções acessíveis a todos.

LinkedInFacebookBiografia completa →