Arquitectura con AWS KMS para admitir la firma digital y AWS Secrets Manager para la transmisión segura de mensajes al PIX

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

Como se comentó en un blog anterior, el nuevo Sistema de Pago Instantáneo (PIX) tiene como objetivo acelerar la transmisión del mensaje de pago y la disponibilidad de fondos finales para el beneficiario, reduciendo costos, aumentando la seguridad y, en última instancia, mejorando la experiencia del cliente. AWS proporciona las certificaciones y los estándares de cumplimiento necesarios para que las instituciones financieras cumplan con los requisitos PIX , como el cifrado y la firma digital de mensajes en formato XML.

Vale la pena recordar que la estructura de seguridad definida, entre los requisitos obligatorios y recomendados, se detalla en blog anterior.

En esta última publicación de blog de la serie (parte 2 de 2), describimos paso a paso cómo las instituciones financieras pueden utilizar el servicio de cifrado AWS Key Management Service (KMS)) y AWS Secrets Manager para cumplir con las directrices de seguridad del Banco Central Brasileño (BACEN) al conectarse al PIX.

Ventajas para las instituciones financieras

A continuación se presentan algunas ventajas para que las instituciones financieras brasileñas creen y configuren una arquitectura para conectarse al PIX, mediante AWS KMS:

Mantener los datos cifrados en reposo y en tránsito.
Firmar digitalmente mensajes y establecer el túnel TLS con autenticación mutua;
AWS KMS comienza con un valor predeterminado de 500 TPS (transacciones por segundo) para operaciones criptográficas con llaves asimétricas RSA. Sin embargo, es un soft limit y es posible aumentar fácilmente el valor a través de cuotas de servicio (Service Quotas);
Escalabilidad, disponibilidad e integración nativa con los servicios de AWS;
AWS KMS es un servicio gestionado de AWS para el almacenamiento seguro y el uso de llaves criptográficas, validado en FIPS 140-2 Nivel 2.
Debido a que es una arquitectura sin servidor (Serverless) se reduce la carga operativa y se reducen los costos operativos relacionados con la administración y la seguridad del servidor.

Principales Servicios de AWS usados en la arquitectura propuesta

Aplicación

Amazon API Gateway es un servicio gestionado que permite a los desarrolladores crear, publicar, mantener, supervisar y proteger APIs fácilmente a cualquier escala. API Gateway administra todas las tareas relacionadas con la recepción y el procesamiento de hasta cientos de miles de llamadas API simultáneas, incluida la administración del tráfico. Puede autorizar llamadas API y limitar el tráfico para garantizar que las operaciones de back-end admitan picos de tráfico y que los sistemas back-end no sean llamados innecesariamente.

Con la aplicación ejecutada en AWS Lambda, se permite a la institución financiera ejecutar código sin aprovisionar ni administrar servidores. Sólo paga por el tiempo de cómputo consumido. Con AWS Lambda, puede ejecutar código para prácticamente cualquier tipo de aplicación o servicio de back-end, todo sin necesidad de administración. Simplemente cargue el código y Lambda se encarga de todos los elementos necesarios para ejecutar y escalar su código con alta disponibilidad. Puede configurar el código para activarlo automáticamente por otros servicios de AWS o llamarlo directamente a través de cualquier aplicación web o móvil.

Se propone el uso de servicios con un enfoque sin servidor (Serverless) para centrarse en el desarrollo de aplicaciones gracias a la reducción de la carga operativa en la administración de servidores. Por lo tanto, la Institución Financiera se centra en aportar valor a la empresa.

AWS ofrece varias herramientas para supervisar y solucionar problemas de aplicaciones de AWS Lambda y responder a posibles incidentes, como: Amazon CloudWatch, Amazon CloudWatch Logs, AWS CloudTrail, AWS Trusted Advisor y AWS X-Ray. Si desea obtener más información sobre cómo implementar estrategias de logs en la plataforma de AWS, haga clic aquí. Debe recopilar datos de monitoreo de todas las partes de su solución en AWS para facilitar la depuración de un error múltiple (en caso de que ocurra).

Registro de logs (auditoría)

Uno de los requisitos de BACEN, para el PIX, es que la Institución Financiera debe almacenar el registro de la solicitud y respuesta de cada transacción. El registro consistente de transacciones es esencial para la auditoría, además de ayudar a identificar y resolver problemas.

Las arquitecturas que demostramos en este blog utilizan una arquitectura basada en eventos. Por lo tanto, utilizamos Amazon Kinesis Data Firehose que es un servicio totalmente gestionado para entregar datos de streaming casi en tiempo-real, como eventos, y persistencia en Amazon S3.

Amazon Athena se puede utilizar para ejecutar consultas interactivas, en archivos de registro centralizados en Amazon S3, utilizando el lenguaje SQL estándar. Además AWS Glue Data Catalog es un índice para las métricas de ubicación, esquema y tiempo de ejecución de sus datos. Utilice la información del catálogo de datos para crear y monitorear los trabajos de ETL. La información del Catálogo de datos se almacena como tablas de metadatos, donde cada tabla específica es un único almacén de datos. Normalmente, se ejecuta un crawler para hacer inventario de los datos.

Cifrado y firma digital

AWS Secrets Manager

El servicio AWS Secrets Manager permite a la institución financiera rotar, administrar y recuperar secretos con facilidad, como credenciales de base de datos, Keys de API y mucho más a lo largo de su ciclo de vida. Los usuarios y las aplicaciones recuperan secretos con una llamada a la API de AWS Secrets Manager, eliminando la necesidad de codificar información confidencial en texto plano.

Con Secrets Manager, puede ayudar a proteger los secretos cifrandolos con llaves que gestiona usted mismo con AWS KMS. Un secreto en AWS Secrets Manager se compone de datos secretos protegidos y la información importante necesaria para gestionar el secreto.

Utilizamos AWS Secrets Manager para almacenar la llave privada que se utilizará para establecer el túnel TLS con autenticación mutua con BACEN.

AWS KMS

AWS KMS es un servicio gestionado que facilita a las instituciones financieras la creación y el control de llaves maestras de clientes (CMK) y las llaves de cifrado utilizadas para cifrar los datos. Los CMK de AWS KMS están protegidos por módulos de seguridad de hardware (HSM) validados por el programa de validación de módulos criptográficos FIPS 140-2.

Figura 1: Arquitectura de AWS KMS

Características de AWS KMS

AWS KMS le permite realizar operaciones de firma digital utilizando pares de llaves asimétricas para garantizar la integridad de los datos.
Utiliza módulos de seguridad de hardware (HSM) validados o en proceso de validación por FIPS 140-2 en el nivel 2 y nivel 3 en varias categorías para generar y proteger las llaves.
API amigable (llaves simétricas y asimétricas) e integrada con AWS Encryption SDK(sólo llaves simétricas).
Imposibilidad de extraer las llaves privadas.
Integrado con AWS CloudTrail para registrar todas las solicitudes de API, incluidas las acciones de administración de llaves y el uso de las llaves.
Servicio de bajo costo. No hay ningún compromiso ni cargos anticipados para utilizar AWS KMS.
Servicio gestionado, donde AWS gestiona los aspectos de mantenimiento del servicio y los clientes controlan completamente los aspectos criptográficos del servicio.

Arquitectura

La arquitectura de ejemplo, presentada en este blog, puede ser parte de una solución más completa, basada en eventos, que puede cubrir toda la transmisión del mensaje de pago, desde la banca principal. Por ejemplo, la solución completa de la Institución Financiera (pagador o receptor), podría contener otras arquitecturas complementarias como Autorización, Deshacer (basado en el modelo SAGA), Eficacia, Comunicación con el entorno local (entorno híbrido), etc. La institución financiera puede utilizar 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, teniendo en cuenta AWS KMS, AWS Lambda, servicios de Amazon API Gateway y AWS Secrets Manager.

La idea de 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 de logs de solicitudes al datastream.

A diferencia de la arquitectura de AWS CloudHSM, donde usamos ELB para equilibrar los mensajes SPI y DICT, se utilizaron API privadas, a través de AWS API Gateway, para distinguir entre los dos tipos de mensajes.

Cabe detacar que para poder utilizar AWS KMS para firmar documentos con los requiSegue tudo OK! [passou para o vinicius]sitos requeridos por el PIX, es necesario generar una Solicitud de Firma de Certificados (CSR) y luego obtener un certificado digital BACEN. Para obtener información sobre cómo generar una CSR para llaves asimétricas administradas por AWS KMS, consulte aquí.

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

Proxy

El siguiente diagrama representa la arquitectura y paso a paso del flujo seguro de transmisión del mensaje a BACEN y su respuesta.

Cree la llave privada (para la firma) en AWS KMS.
Cree el secreto en AWS Secrets Managercon el contenido de la llave privada utilizada para mTLS.
Almacene los 2 certificados en AWS Systems Manager Parameter Store: certificado llave generado para la firma y certificado generado para mTLS.
El servicio/aplicación de la Institución Financiera envía la solicitud en formato XML.
Amazon API Gateway envía el mensaje XML a la aplicación que se ejecuta en AWS Lambda.
La aplicación (AWS Lambda) utiliza AWS KMS para la firma digital de XML.
La aplicación (AWS Lambda) utiliza la llave privada almacenada en AWS Secrets Manager para establecer mTLS.
La aplicación transmite el XML firmado, a BACEN, en un túnel cifrado (mTLS).
La aplicación (AWS Lambda) recibe la respuesta de BACEN y, si es necesario, valida la firma digital del XML recibido.
La aplicación (AWS Lambda) registra el log de solicitudes enviando directamente a Amazon Kinesis Data Firehose.
El mensaje de respuesta se envía a Amazon API Gateway.
El mensaje de respuesta lo recibe el servicio/aplicación.
Amazon Kinesis Data Firehose utiliza AWS Glue Data Catalog para convertir los registros al formato parquet.
Amazon Kinesis Data Firehose envía registros, a Amazon S3, ya particionados en «carpetas» (/año/mes/day/time/).
Amazon Athena utiliza AWS Glue Data Catalogcomo ubicación central para almacenar y recuperar metadatos de tabla.
Los rastreadores de AWS Glue actualizan automáticamente las nuevas particiones en el repositorio de metadatos cada hora.
Puede consultar datos inmediatamente directamente en Amazon S3 mediante servicios de análisis sin servidor (Serverless) como Amazon Athena (ad-hoc con SQL estándar) y Amazon QuickSight.

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

Sobre los autores

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

João Paulo Aragão Pereira es arquitecto de soluciones de AWS, enfocado en el sector de servicios financieros (LATAM) y sus principales temas: prevención y detección de fraudes, banca abierta, modernización de sistemas heredados, prueba de vida, sistemas de pago instantáneo. He estado trabajando con arquitecturas bancarias y de seguros por más de 15 años.

Revisor

Javier Cristancho es un arquitecto de soluciones de AWS basado en Colombia, ha trabajado para clientes en Suramérica y Centroamérica. En su rol actual, trabaja en ayudar a las principales compañías del sector financier en su proceso de adopción a la nube, y modernización de aplicaciones. Él es uno de los pioneros en la comunidad interna de AWS Serverless Advocate.

Blog de Amazon Web Services (AWS)