Seguridad API PSD2: Guía de Integración de Open Banking en Google Cloud

En el panorama fintech actual, la directiva PSD2 (Directiva de Servicios de Pago 2) ya no es una novedad normativa, sino el estándar operativo de facto para la interoperabilidad bancaria. Sin embargo, para los arquitectos de software y los ingenieros DevOps, el desafío se ha desplazado del simple cumplimiento a la implementación de arquitecturas robustas, escalables y, sobre todo, seguras. Cuando se conecta un CRM propietario a las cuentas corrientes de los clientes a través de API bancarias, la seguridad api psd2 se convierte en el pilar fundamental sobre el que se sostiene toda la infraestructura.

Esta guía técnica explora cómo construir una pasarela API segura utilizando el ecosistema Google Cloud, con un enfoque específico en Apigee como capa de mediación. Analizaremos los patrones arquitectónicos necesarios para gestionar la autenticación mTLS, los flujos OAuth 2.0 complejos, el cifrado de datos sensibles (PII) y la resiliencia operativa contra las latencias de los bancos terceros.

Prerrequisitos y Contexto Arquitectónico

Antes de sumergirnos en el código y las configuraciones, es necesario definir el perímetro operativo. En un escenario de Open Banking, su aplicación actúa típicamente como TPP (Third Party Provider), específicamente como AISP (Account Information Service Provider) o PISP (Payment Initiation Service Provider).

Para seguir esta guía, se asume la disponibilidad de:

• Una cuenta de Google Cloud Platform (GCP) activa.
• Una instancia de Apigee X o Apigee Hybrid configurada.
• Certificados eIDAS (QWAC y QSEAL) válidos, necesarios para la identificación formal ante los bancos europeos.
• Conocimientos básicos de contenedores (si se utiliza Cloud Run/GKE para los microservicios del CRM).

La Arquitectura «Secure Hub»

El enfoque recomendado es el patrón «Secure Hub». En lugar de permitir que el CRM llame directamente a las API de los bancos, se interpone un API Gateway (Apigee) que actúa como punto único de aplicación de las políticas de seguridad. El flujo de datos es el siguiente:

CRM (Backend) → Google Cloud Apigee (Pasarela) → ASPSP (API Banco)

1. Implementación de mTLS (Mutual TLS) para la Autenticación Servidor a Servidor

Según los estándares técnicos regulatorios (RTS) de la PSD2, la simple autenticación mediante API Key no es suficiente para la comunicación entre TPP y Banco. Es obligatorio el uso de Mutual TLS (mTLS).

En mTLS, no es solo el cliente (usted) quien verifica el certificado del servidor (el banco), sino que el banco también debe verificar su certificado de cliente (el certificado eIDAS QWAC). Así es como se configura en Apigee:

Configuración del Keystore y TargetServer

En Apigee, la gestión de mTLS hacia el backend (el banco) se realiza mediante la definición de TargetServers.

1. Carga del Certificado: Cargue su certificado QWAC (clave pública y privada) en el Keystore de Apigee.
2. Definición SSLInfo: En la configuración del TargetServer, habilite SSL y haga referencia al 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: Asegúrese de que el TrustStore contenga la cadena completa de la CA que emitió el certificado del banco; de lo contrario, el handshake fallará.

2. Gestión de Tokens: OAuth 2.0 y OIDC

La seguridad api psd2 requiere que el acceso a los datos de la cuenta sea autorizado explícitamente por el usuario final a través de la Autenticación Reforzada de Cliente (SCA). Esto se traduce técnicamente en el flujo OAuth 2.0 Authorization Code Grant.

El Rol de Apigee como Mediador de Tokens

Su CRM nunca debería gestionar directamente los tokens de acceso brutos de los bancos si no es estrictamente necesario. Un patrón seguro prevé que Apigee gestione el intercambio de tokens y proporcione al CRM un token opaco interno.

1. Redireccionamiento: El usuario es redirigido al portal del banco para el inicio de sesión.
2. Callback: El banco devuelve un authorization_code a su endpoint de callback en Apigee.
3. Intercambio de Token: Apigee llama al endpoint /token del banco usando mTLS e intercambia el código por un access_token y un refresh_token.
4. Almacenamiento Seguro: Apigee cifra estos tokens y los almacena en su caché segura (o en una base de datos externa cifrada), devolviendo al CRM un identificador de sesión.

Este enfoque reduce la superficie de ataque: si la base de datos del CRM se ve comprometida, los atacantes no encontrarán tokens bancarios válidos.

3. Cifrado de Datos Sensibles (PII) con Google Cloud KMS

Los datos financieros (IBAN, saldo, transacciones) son PII (Información de Identificación Personal) crítica. El cumplimiento del RGPD y la PSD2 impone el cifrado tanto en tránsito (ya cubierto por TLS 1.2+) como en reposo.

Envelope Encryption

Para una seguridad de nivel empresarial, utilice Google Cloud Key Management Service (KMS). Nunca codifique las claves de cifrado directamente en el código o en las configuraciones de Apigee.

Implemente un criterio de Envelope Encryption:

• Utilice una DEK (Data Encryption Key) para cifrar el payload de la respuesta bancaria antes de que sea guardado o registrado.
• Utilice una KEK (Key Encryption Key) gestionada por Cloud KMS para cifrar la DEK.

En Apigee, puede utilizar una política ServiceCallout para invocar las API de Cloud KMS y descifrar las claves solo cuando sea necesario para el procesamiento, manteniendo los datos ofuscados en los logs del sistema.

4. Patrones de Resiliencia: Circuit Breaker y Throttling

Las API bancarias, especialmente las de instituciones heredadas adaptadas a la PSD2, pueden sufrir latencias impredecibles o tiempos de inactividad. Un CRM que espera indefinidamente una respuesta bancaria ofrece una pésima Experiencia de Usuario y arriesga un fallo en cadena.

Implementación del Circuit Breaker

El patrón Circuit Breaker evita que un error en un servicio externo (el banco) sature los recursos de su sistema.

En Apigee, no existe una política «Circuit Breaker» nativa lista para usar, pero se puede implementar combinando KVM (Key Value Maps) y lógica condicional:

1. Si una llamada al TargetServer falla o entra en timeout, incremente un contador en KVM.
2. Si el contador supera un umbral (ej. 5 errores en 1 minuto), active un flag «Open Circuit».
3. Las solicitudes posteriores son rechazadas inmediatamente con un error 503 personalizado, sin intentar contactar al banco, permitiendo que el sistema externo se recupere.
4. Después de un periodo de enfriamiento, el circuito pasa a estado «Half-Open» para probar nuevamente la conectividad.

Gestión del Throttling (Spike Arrest y Quota)

Los bancos imponen límites severos sobre el número de llamadas API (ej. 4 llamadas al día para la actualización de saldos en segundo plano). Superar estos límites puede llevar al bloqueo temporal de su certificado TPP.

Utilice la política Quota de Apigee para aplicar estos límites del lado del 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, en cambio, su backend de picos de tráfico repentinos, utilice la política SpikeArrest, que aplana los picos de tráfico distribuyéndolos en el tiempo.

5. Validación de Certificados y Seguridad del Payload

Además del transporte, es vital validar el contenido. Según las especificaciones FAPI (Financial-grade API), a menudo adoptadas en el ámbito PSD2, los tokens JWT deben estar firmados y a veces cifrados.

Utilice la política VerifyJWT de Apigee para asegurarse de que los tokens recibidos del banco sean válidos y no hayan sido manipulados. Configure la política para validar:

• La firma (usando la clave pública del banco expuesta vía JWKS).
• La audiencia (aud claim) para asegurarse de que el token esté destinado a usted.
• La caducidad (exp claim).

Conclusiones

Implementar la seguridad api psd2 no es una tarea trivial; requiere una superposición de protocolos de red (mTLS), estándares de autorización (OAuth 2.0/OIDC) y prácticas de ingeniería de software (Circuit Breakers). Utilizando Google Cloud Apigee como hub central, centraliza la complejidad, permitiendo que su CRM permanezca ligero y enfocado en la lógica de negocio, mientras la pasarela se hace cargo del cumplimiento criptográfico y normativo.

Recuerde que la seguridad es un proceso continuo: monitoree constantemente los logs (ofuscados) a través de Google Cloud Operations Suite y mantenga actualizados sus certificados QWAC para evitar interrupciones del servicio.

Preguntas frecuentes

Fuentes y Profundización

1. Directiva (UE) 2015/2366 del Parlamento Europeo y del Consejo (PSD2)
2. Reglamento Delegado (UE) 2018/389 sobre normas técnicas de regulación (RTS) para la autenticación reforzada
3. Autoridad Bancaria Europea (EBA) – Marco regulatorio de la PSD2
4. Comisión Europea – Reglamento eIDAS sobre identificación electrónica y servicios de confianza
5. Wikipedia – Definición y contexto del Open Banking

Francesco Zinghinì

Ingeniero Electrónico con la misión de simplificar lo digital. Gracias a su formación técnica en Teoría de Sistemas, analiza software, hardware e infraestructuras de red para ofrecer guías prácticas sobre informática y telecomunicaciones. Transforma la complejidad tecnológica en soluciones al alcance de todos.

LinkedInFacebookBiografía completa →