Reglas de Cifrado de Carga Útil de APIs del Banco de Tailandia

Durante años, “cifrar los datos en tránsito” significaba simplemente habilitar HTTPS. TLS terminaba en el balanceador de carga, la carga útil (payload) circulaba por la red interna en texto claro, y todo el mundo lo consideraba protegido. El Banco de Tailandia (BOT) ha estado cerrando esa brecha de forma constante, y la dirección es clara: para transacciones y datos financieros críticos, el cifrado de transporte por sí solo ya no es suficiente.

La diferencia entre cifrado de transporte y cifrado de payload #

TLS protege los datos entre dos puntos de un cable de red. No protege los datos dentro de la arquitectura de la aplicación. En el momento en que TLS finaliza en el proxy inverso, el API Gateway o el balanceador, el cuerpo de la petición se descifra y viaja en texto plano.

Ese texto plano luego viaja por, y se queda en, lugares donde preferiría que no estuviera:

• Registros (Logs): Gateways que registran cuerpos de petición capturan números de tarjeta y cuentas bancarias completas.
• Service Mesh y saltos internos: El tráfico este-oeste entre microservicios a menudo no se cifra al asumir una red “confiable”.
• Memoria y cachés: Objetos en memoria, volcados de depuración y trazas de APM retienen el payload en claro.
• Pipelines de observabilidad: Herramientas de trazas que reenvían datos entre equipos y proveedores externos.

El cifrado en la capa de aplicación cierra esta brecha al cifrar el mensaje en sí mismo, manteniéndolo protegido sin importar cuántos saltos intermedios atraviese o qué haga la infraestructura con él.

Estándares criptográficos requeridos #

Los mecanismos de cifrado a nivel de aplicación están completamente estandarizados:

• JSON Web Encryption (JWE) (RFC 7516): El estándar de facto para cifrar payloads estructurados de API.
• AES-256-GCM: Cifrado simétrico autenticado que garantiza confidencialidad e integridad del mensaje.
• RSA-OAEP o ECDH: Mecanismos de encapsulamiento asimétrico para la distribución segura de claves.

El patrón es el mismo que usa el propio TLS: un cifrado simétrico rápido para los datos en volumen, envuelto en un intercambio de claves asimétrico, pero aplicado a nivel de mensaje para que sobreviva más allá de la sesión TLS.

Por qué el BOT exige este estándar #

El razonamiento del regulador no es exótico. Las APIs financieras constituyen hoy la columna vertebral de todo el ecosistema de pagos tailandés: bancos, PSPs, fintechs y comercios. Una simple mala configuración en un gateway no debe exponer datos bancarios a cualquiera con acceso a los logs. El cifrado de payload implementa defensa en profundidad: asume que el transporte será inspeccionado, registrado o comprometido en algún momento, y garantiza que los datos sensibles no sean legibles cuando eso ocurra.

Esto se alinea con el mismo principio detrás del requisito de PCI DSS de proteger los datos de tarjetas almacenados: en el momento en que deja de confiar en cualquier salto individual, deja de tratar «la red es segura» como su único control.

Implicaciones para su equipo de ingeniería #

Adoptar el cifrado de payload no es activar una opción de configuración. Significa:

• Gestión de claves (KMS/HSM): Rotación obligatoria, segregación de claves de firma y cifrado, y almacenamiento protegido de claves.
• Adaptación de middlewares: Todo lo que lee o registra cuerpos de petición debe reevaluarse, porque el cuerpo ya no es legible para el middleware.
• Contratos de API: Los consumidores finales deben poder descifrar, lo que implica distribución y versionado de claves entre todas las partes de la cadena.
• Pruebas: La observabilidad debe pasar de «volcar el payload» a «autenticar y autorizar, y descifrar solo donde sea necesario».

Nada de esto es opcional si opera en la órbita del BOT. Es un cambio de «cifrar el conducto» a «proteger el mensaje».

Nuestra Revisión de Seguridad de Código y APIs verifica la protección de sus payloads extremo a extremo, y nuestro servicio de Cumplimiento Normativo le ayuda a alinear sus sistemas con las directrices del BOT.