Compatibilidad con firmas digitales y transmisiones seguras de mensajes para sistemas de pago instantáneo brasileños con AWS CloudHSM

Por Lucas Lins, Arquitecto de Soluciones en AWS
João Paulo Aragão Pereira, Arquitecto de Soluciones en AWS

Las instituciones financieras, como bancos y compañías de seguros, están autorizadas a usar servicios en la nube, siempre y cuando cumplan con los requisitos legales y reglamentarios aplicables.

AWS cuenta con un centro de cumplimiento que ofrece a las instituciones financieras una ubicación central para investigar los requisitos normativos relacionados con la nube y cómo afectan a su industria. Por ejemplo, la Resolución 4658 prevé que las instituciones financieras observen la política de seguridad cibernética y los requisitos para la contratación de servicios de procesamiento de datos, almacenamiento de datos y computación en nube, y otras instituciones autorizadas por el Banco Central del Brasil (BACEN).

BACEN es la autoridad monetaria y regulatoria líder en el sector bancario brasileño, y las instituciones financieras brasileñas pueden estar sujetas a varios requisitos legales y regulatorios diferentes al usar servicios en la nube. En este link, tiene un marco que consta de cinco consideraciones clave en las que las instituciones financieras deben centrarse para ayudar a optimizar la lista de servicios en la nube para sus datos más confidenciales.

Un punto importante a tener en cuenta es que cuando las instituciones financieras migran o utilizan los servicios de la nube de AWS, AWS es responsable de proteger la infraestructura subyacente que admite la nube, y las instituciones financieras son responsables de todo lo que implementan en la nube o se conectan a la nube (Modelo de Responsabilidad Compartida).

Figura 1 – Modelo de responsabilidad compartida

Los pagos instantáneos son transferencias electrónicas de dinero en las que el envío de la orden de pago y la disponibilidad de fondos al usuario receptor tiene lugar casi en tiempo real. Los pagos instantáneos se pueden utilizar para transferencias entre:

B2B – empresa a empresa.

P2P – persona a persona.

P2B – persona a negocio.

P2G – persona al gobierno.

B2G – negocios al gobierno.

G2P – government a la persona.

G2B – gobierno a empresa.

BACEN establece las disposiciones relativas a las modalidades y criterios de participación en el Sistema de Pago Instantáneo (SPI) y los criterios de Acceso Directo al Directorio de Identificadores de Cuenta Transaccional (DICT). Los principales requisitos de seguridad están relacionados con el establecimiento de un túnel TLS de autenticación mutua, además de firmar digitalmente mensajes XML. AWS proporciona las certificaciones y los estándares de cumplimiento necesarios para que las instituciones financieras cumplan los requisitos del SPI.

Esta entrada de blog (parte uno de dos) describe paso a paso cómo las instituciones financieras al conectarse a un SPI pueden cumplir con las directrices de seguridad del Banco Central de Brasil, creando una arquitectura basada en el servicio criptográfico llamado AWS CloudHSM.

Ventajas para las instituciones financieras

A continuación se presentan algunas ventajas para las instituciones financieras cuando crean y configuran una arquitectura para conectarse al SPI mediante el servicio CloudHSM de AWS:

Mantenga los datos cifrados en reposo y en tránsito.
Firme digitalmente mensajes y establezca un túnel TLS con autenticación mutua.
Cada HSM admite 1100 TPS(transacciones por segundo) y es posible agregar 28 HSM en el mismo clúster de AWS CloudHSM.
Tener escalabilidad, disponibilidad e integración nativa con otros servicios de AWS.
Sea un servicio administrado por AWS para el almacenamiento y el uso seguro de claves criptográficas, validado en FIPS 140-2 nivel 3.
Dado que la mayor parte de la arquitectura no tiene servidor (serverless), hay una reducción en la carga operativa vinculada a la administración y seguridad de servidores.

Especificaciones técnicas de seguridad SPI

Se implementan requisitos de seguridad para garantizar la integridad, confidencialidad y disponibilidad de la información que se transfiere. La estructura de seguridad definida comprende todos los mecanismos de protección necesarios para fortalecer los sistemas de defensa contra acciones indeseables. Se dividen en obligatorios y recomendados.

Todos los mensajes enviados a BACEN deben ser autenticados mediante un criptograma por la institución financiera emisora (se requieren claves asimétricas).
La comunicación con BACEN debe estar cifrada.
Las instituciones financieras son responsables de la seguridad física y lógica del acceso a su clave privada.
Se recomienda que la institución financiera almacene la clave privada en un dispositivo especializado para la gestión de claves criptográficas, con el fin de reducir la exposición del sistema a fallas y otros tipos de vulnerabilidades en el entorno.
La entidad financiera debe conectarse a las operaciones API disponibles en el SPI exclusivamente a través del protocolo HTTP versión 1.1, utilizando cifrado TLS versión 1.2 o superior, con autenticación mutua obligatoria para establecer la conexión.

Existen otras pautas recomendadas y/o obligatorias por BACEN, por ejemplo, disponibilidad, redundancia, backup y recuperación del entorno. AWS puede apoyar a las instituciones financieras para que respalden estas directrices con el fin de ejecutar cargas de trabajo, programas, soluciones y servicios críticos.

Flujo de transacciones entre participantes directos

El acuerdo de nivel de servicio establecido por BACEN para la experiencia del usuario pagador es de 10 segundos para el 99% de las transacciones (p99). Vea el ejemplo a continuación el flujo de transacciones entre participantes directos. Existen dos tipos de formatos de mensaje: SPI (norma ISO 20.022) y DICT (que no utiliza la norma ISO 20.022).

Figura 2 – Ejemplo de flujo de transacciones entre participantes directos]

Principales servicios de AWS utilizados en la arquitectura propuesta

Aplicación

AWS Fargate es un motor informático sin servidor para contenedores que funciona con Amazon Elastic Container Service (Amazon ECS) y con Amazon Elastic Kubernetes Service (Amazon EKS). El uso de un enfoque de tecnología sin servidor tiene como objetivo centrarse en la agilidad del desarrollo de aplicaciones, reduciendo la sobrecarga operativa de la administración de servidores, lo que permite a la institución financiera centrarse en ofrecer valor al negocio.

AWS ofrece varias herramientas para supervisar los recursos de Amazon ECS y responder a posibles incidentes, como Amazon CloudWatch, Amazon CloudWatch Logs, AWS CloudTrail y AWS Trusted Advisor. Si desea obtener más información sobre cómo implementar estrategias de registro en la plataforma de AWS, haga clic aquí. Recopile datos de supervisión de todas las partes de su solución de AWS para facilitar la depuración de un fallo de varios puntos (si se produce).

Registro de registro (auditoría)

Uno de los requisitos de BACEN es que toda la institución financiera brasileña debe almacenar el registro de la solicitud y respuesta para cada transacción. El registro coherente de las transacciones es esencial para la auditoría, además de resolver e identificar problemas.

La arquitectura demostrada en este blog es una arquitectura impulsada por eventos. Por lo tanto, utilizamos Amazon Kinesis Data Firehose que es un servicio totalmente gestionado para streaming de los datos en tiempo casi real, como eventos, y persistimos en Amazon S3

Amazon Athena se puede utilizar para ejecutar consultas interactivas, en archivos de registro centralizados en Amazon S3, con SQL estándar. AWS Glue Data Catalog se utiliza para proporcionar un índice de métricas de ubicación, diseño y tiempo de ejecución de sus datos. Utilice la información del Catálogo de datos para crear y supervisar los trabajos de ETL. La información del Catálogo de datos se almacena como tablas de metadatos, donde cada tabla especifica un único almacén de datos. Normalmente, se ejecuta un rastreador para hacer un inventario de los datos, pero hay otras formas de agregar tablas de metadatos al catálogo de datos.

Figura 3 – Ejemplo de canalización de ingestión: lago de datos sin servidor con AWS Glue y Amazon Kinesis (streaming)

Criptografía y firma digital

AWS CloudHSM es un servicio de criptografía basado en módulos de seguridad de hardware que las instituciones financieras pueden utilizar para almacenar y utilizar sus claves. Proporciona un clúster de HSM validados por FIPS 140-2 Nivel 3 (Hardware Security Module) bajo el control exclusivo de la institución financiera, conectado directamente a los clientes de Amazon Virtual Private Cloud (VPC). Este servicio le permite utilizar fácilmente HSM con aplicaciones que se ejecutan en instancias y/o contenedoresde Amazon EC2 . Con AWS CloudHSM, puede utilizar controles de seguridad de VPC estándar para administrar el acceso a HSM. Las aplicaciones se conectan a HSM mediante canales SSL mutuamente autenticados establecidos por el software cliente HSM.

AWS CloudHSM se puede utilizar para admitir una variedad de casos de uso, como la administración de derechos digitales (DRM), la infraestructura de clave pública (PKI), la firma de documentos y las funciones criptográficas mediante interfaces PKCS# 11, Java Cryptography Extensions (JCE), Microsoft CNG y OpenSSL, y proporciona disponibilidad automatizada, replicación y copia de seguridad de HSM dedicados en Zonas de Disponibilidad.

Características de AWS CloudHSM:

Acceso dedicado.
Generación y uso de claves de cifrado en HSM validados por FIPS 140-2 Nivel 3.
BYOK (familiaridad con el ciclo de vida de la clave actual del cliente).
Opción configurable para no extraer nunca las claves generadas dentro del límite de HSM.
Alta disponibilidad y durabilidad con una configuración mínima.
Precios de pago por uso basados en horas para cada HSM en uso.
Puede escalar rápidamente la capacidad de HSM agregando y eliminando HSM del clúster, según demanda.
Integrado con AWS CloudTrailen el registro de solicitudes de API de AWS y Amazon CloudWatch para el registro de acciones de administración de claves y usuarios.
Servicio gestionado, en el que AWS gestiona los aspectos de mantenimiento de hardware del servicio y los clientes controlan completamente los aspectos criptográficos del servicio.

Arquitectura

La arquitectura presentada en este blog puede ser parte de una solución más completa, basada en eventos, que puede contemplar todo el flujo de transmisión de mensajes de pago, desde el núcleo bancario. Por ejemplo, la solución completa de la Institución Financiera (pagando o recibiendo), podría contener otras arquitecturas complementarias como Autorización, Deshacer (basado en el modelo SAGA, Eficacia, Comunicación con entorno local [Nube híbrida], etc., utilizando otros servicios como Amazon EventBridge, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), AWS Step Functions, Amazon ElastiCache, Amazon DynamoDB.

En el diagrama de nuestra arquitectura, el cuadro verde representa el proxy de comunicación con BACEN, ya sea en modo sincrónico o asincrónico, teniendo en cuenta los servicios AWS CloudHSM, AWS Fargate y Elastic Load Balancing (ELB).

La idea del proxy es ser una ruta directa y obligatoria para cada transacción, con los siguientes objetivos:

Firma de mensajes XML.
Establecimiento del túnel TLS con autenticación mutua (mTLS).
Envío del registro de solicitudes al almacén de datos.

Opcionalmente, la institución financiera puede ver las transacciones que procesa esta solución mediante Amazon QuickSight. La arquitectura sin servidor de Amazon QuickSight le permite proporcionar información a todos los miembros de su organización y puede compartir paneles interactivos y sofisticados con todos sus usuarios, permitiéndoles realizar búsquedas detalladas y explorar datos para responder preguntas y obtener información relevante.

Si tiene una cuenta de seguridad independiente, utilice este procedimiento u otro, para compartir un clúster de CloudHSM con la otra cuenta de AWS.

Proxy

Mire el diagrama de la arquitectura de ejemplo y siga paso a paso el flujo de transmisión segura de mensajes a BACEN y la respuesta respectiva:

Figura 4 – Arquitectura de ejemplo

Almacene el nombre de usuario y la contraseña en AWS Secrets Manager, para comunicarse con AWS CloudHSM.
Cree o importe la clave privada en AWS CloudHSM.
Almacene los 3 certificados en el AWS Systems Manager Parameter Store: (1) certificado de clave generado para firma, (2) certificado generado para mTLS y (3) certificado para CloudHSM (CA del cliente).
El servicio/aplicación envía una solicitud de transacción en formato XML.
ELB equilibra la carga entre los contenedores de AWS Fargate.
La aplicación (Java Spring Boot framework) que se ejecuta en AWS Fargate utiliza AWS CloudHSM para la firma digital de XML.
La aplicación que se ejecuta en AWS Fargate utiliza AWS CloudHSM para establecer la autenticación TLS mutua y transmitir mensajes XML firmados a BACEN.
La aplicación que se ejecuta en AWS Fargate recibe la respuesta de BACEN y, si es necesario, valida la firma digital del XML recibido.
La aplicación (AWS Fargate) registra el registro de solicitudes enviándolo directamente a Amazon Kinesis Data Firehose.
El mensaje de respuesta se envía a través del ELB.
El mensaje de respuesta es recibido por el servicio/aplicación.
Amazon Kinesis Data Firehose utiliza AWS Glue Data Catalog para convertir los registros a formato de parquet.
Amazon Kinesis Data Firehose envía los registros a Amazon S3, ya divididos en «carpetas» (/año/mes/día/hora/).
Amazon Athena utiliza AWS Glue Data Catalog como ubicación central para almacenar y recuperar metadatos de tabla.
Crawlers de AWS Glue actualizan automáticamente las nuevas particiones en el repositorio de metadatos cada hora.
Puede consultar inmediatamente los datos directamente en Amazon S3 mediante servicios de análisis sin servidor, como Amazon Athena (ad hoc con SQL estándar) y Amazon QuickSight.

Costos y rendimiento de AWS CloudHSM

Se deben tener en cuenta los siguientes elementos para las cargas de trabajo de producción con el fin de optimizar los costos:

Aprovechar la elasticidad: escale el clúster hacia arriba o hacia abajo según la carga de trabajo varía. Puede encontrar más información sobre la supervisión de CloudHSM y el rendimiento aquí.
Maximizar la utilización: compartir un clúster de HSM de uso poco frecuente entre cuentas para aumentar la utilización del clúster
Optimizar el almacenamiento de claves: si es posible, para agrupar claves.

Ahora, usemos la calculadora de AWS para estimar el costo mensual de TPS (Transaction Per Second), en la región de São Paulo, para AWS CloudHSM. Recuerde que no hay costes iniciales para utilizar AWS CloudHSM y que paga una tarifa por hora por cada HSM iniciado hasta que lo cierre. Cada HSM admite 1100 TPS (operaciones de firma y verificación RSA de 2048 bits con claves asimétricas).

Tarifa horaria total por HSM = US $2,72.

Inicialmente, podemos considerar un clúster de AWS CloudHSM con 2x HSM, uno en cada Zona de Disponibilidad AWS, y recordar que es posible crear una instancia de hasta 28 HSM por clúster de AWS CloudHSM.

2x 1100 = 2200 TPS para operaciones con teclas asimétricas.
2 HSH x 730 horas en 1 mes x US 2,72 = US $3.971,20/mes.

Figura 5: Simulación con la calculadora de precios de AWS CloudHSM (2x HSM)

Conclusión

Al utilizar los servicios de AWS, las instituciones financieras tienen el control y la confianza necesarios para llevar a cabo su negocio de forma segura en el entorno informático en la nube más flexible y seguro disponible.

Los requisitos de seguridad de BACEN regulan el sistema bancario brasileño. Por lo tanto, con los servicios de AWS, incluido el servicio de cifrado CloudHSM de AWS, la institución financiera puede mejorar su capacidad para cumplir los requisitos clave de seguridad y cumplimiento, como la ubicación, la protección de datos y la confidencialidad. AWS le permite automatizar las tareas de seguridad manuales para que pueda centrarse en escalar e innovar su negocio. Además, las Instituciones Financieras sólo pagan por los servicios que utilizan.

La arquitectura de ejemplo presentada incluye la parte de seguridad para la firma digital y la transmisión (mTLS) de mensajes, y también incluye el registro obligatorio de solicitudes.

Artefactos

Puede encontrar muchos ejemplos de código e implementación en el repositorio oficial de AWS (aws-samples). Para facilitar la comprensión e implementación de nuestra solución, compartimos el código fuente.

Todas las características de la implementación del proxy con AWS CloudHSM, mencionadas en esta publicación de blog, están disponibles en el repositorio oficial de AWS (pix-proxy-samples). Se puede clonar, cambiar, ejecutarlo, pero no se debe utilizar como base para construir la integración final de la Institución Financiera con BACEN (SPI y DICT).

Toda la información necesaria para implementar y probar el ejemplo se puede encontrar directamente en el archivo README del repositorio.

Para el desarrollo y la prueba de la solución, desarrollamos un simulador para representar el entorno BACEN. En este simulador, requerimos autenticación de cliente (Proxy) para garantizar el requisito de mTLS. Además, realizamos la validación de firma digital de las solicitudes recibidas, y firmamos digitalmente la respuesta a ser enviada al Proxy.

En promedio, las solicitudes Get Claims obtienen un tiempo de respuesta de 65 ms (depende de la cantidad de recursos computacionales en el contenedor y el tamaño del mensaje de respuesta), medido desde el servicio/aplicación. Mira el flujo:

Servicio/Aplicación → Proxy (mTLS) → Simulador (señal respuesta) (mTLS) → Proxy (valida firma de respuesta) (almacena registro de solicitud) → Servicio/Aplicación.

En promedio, las solicitudes de Insert Claim obtienen un tiempo de respuesta de 109ms (depende de la cantidad de recursos computacionales en el contenedor y el tamaño de los mensajes de solicitud y respuesta), medido desde el Servicio/Aplicación. Mira el flujo:

Servicio/Aplicación → Proxy (firmar la solicitud) (mTLS) → Simulador (validar la firma de la solicitud) (firmar la respuesta) (mTLS) → Proxy (firma válida de la respuesta) (almacenar el registro de solicitud) → Servicio/Aplicación.

Recursos futuros

Además de las instituciones financieras, los arquitectos de soluciones de AWS también tienen el ADN de un constructor. Por lo tanto, pronto publicaremos otro blog con arquitectura (parte 2 de 2), utilizando otro servicio de cifrado llamado AWS KMS.

Lecturas adicionales

Cómo ejecutar cargas de trabajo de AWS CloudHSM en AWS Lambda (blogpost).
Cómo implementar CloudHSM para compartir de forma segura sus claves con su proveedor de SaaS. (blogpost)
Detección de vida para la autorización de pagos.
Cómo aprobar los servicios de AWS para datos altamente confidenciales en instituciones financieras (blogpost).

Este artículo fue traducido del Blog de AWS en Inglés.

Sobre los autores

Lucas Lins es un arquitecto de soluciones en AWS con más de 10 años de experiencia en arquitectura de software y desarrollo de soluciones que implican sistemas empresariales y de misión crítica. Trabaja con énfasis en el segmento Enterprise, guiando y apoyando a los clientes en su viaje en la nube.

João Paulo Aragão Pereira es un arquitecto de soluciones de AWS con sede en São Paulo/Brasil, centrado en el sector de servicios financieros (LATAM) y sus principales temas: prevención y detección de fraudes, Open Banking, modernización de sistemas heredados, detección de vida, Instantánea Sistemas de pago. He estado trabajando con bancos y compañías de seguros durante más de 15 años.

Blog de Amazon Web Services (AWS)