Blog de Amazon Web Services (AWS)

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 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 requisitosPIX , como el cifrado y la firma digital de mensajes en formato XML. 

Vale la pena recordar que la estructura de seguridad definida, entre los requisitosobligatorios 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 administración de claves de AWS (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

  1. 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:
  2. Mantener los datos cifrados en reposo y en tránsito
  3. Firmar digitalmente mensajes y establecer el túnel TLS con autenticación mutua;
  4. AWS KMS comienza con un valor predeterminado de 500 TPS (transacciones por segundo) para operaciones criptográficas con claves asimétricas RSA. Sin embargo, es un límite suave y es posible aumentar fácilmente el valor a través de cuotas de servicio;
  5. Escalabilidad, disponibilidad e integración nativa con los servicios de AWS;
  6. AWS KMS es un servicio gestionado de AWS para el almacenamiento seguro y el uso de claves criptográficas, validado en FIPS 140-2 Nivel 2.
  7. Debido a que es una arquitectura sin servidor se reduce la carga operativa y se reducen los costos operativos relacionados con la administración y la seguridad del servidor.

 

Servicios clave de AWS utilizados en la arquitectura propuesta

Aplicación

Amazon API Gateway es un servicio gestionado que permite a los desarrolladores crear, publicar, mantener, supervisar y proteger API 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 se llamen innecesariamente.

Con la aplicación que se ejecuta en AWS Lambda, permite a la institución financiera ejecutar código sin aprovisionar ni administrar servidores. Sólo paga por el tiempo de cálculo 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.

Seproponeel uso de servicios con unenfoque sin servidor para centrarse en el desarrollo de aplicaciones debido a la reducción de la carga operativa con 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 CloudWatchAmazon CloudWatch LogsAWS CloudTrail, AWS Trusted Advisor y AWS X-Ray. Si desea obtener más información sobre cómo implementar estrategias de registro en la plataforma de AWS, haga clic aquí. Debe recopilar datos de supervisión de todas las partes de la solución de AWS para facilitar la depuración de un error múltiple (si ocurre).

Registro de registro (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 coherente de transacciones es esencial para la auditoría y ayuda a identificar y resolver problemas.

Las arquitecturas que demostramos en este blog utilizan arquitecturabasada en eventos . Por lo tanto, utilizamos Amazon Kinesis Data Firehose que es un servicio totalmente gestionado para entregardatos de streamingcasi 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 de 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 supervisar 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 rastreador para hacer inventario de los datos.

Cifrado y firma digital

Administrador de secretos de AWS 

El servicio AWS Secrets Manager permite a la institución financiera rotar, administrar y recuperar secretos con facilidad, como credenciales de base de datos, claves 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 las API de Secrets Manager, eliminando la necesidad de codificar información confidencial en texto sin formato.

Con Secrets Manager, puede ayudar a proteger los secretos encriptándolos con claves que gestiona usted mismo con AWS KMS. Un secreto en AWS Secrets Manager son los datos secretos protegidos y la información importante necesaria para gestionar el secreto.

Utilizamos AWS Secrets Manager para almacenar la clave 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 lacreación y el control declaves maestras de clientes (CMK) y las claves de cifrado utilizadas para cifrar los datos. LosCMK 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 claves 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 claves.
  • API amigable (claves simétricas y asimétricas) e integrada con AWS Encryption SDK (sólo claves simétricas).
  • Imposibilidad de extraer claves privadas.
  • Integrado con AWS CloudTrail para registrar todas las solicitudes de API, incluidas las acciones de administración de claves y el uso de sus claves.
  • 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), Eficaz, 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 FunctionsAmazon ElastiCache, Amazon DynamoDB.

En el diagrama de nuestra arquitectura, el cuadro verde representa el  Proxyde comunicación con BACEN, teniendo en cuentaAWS 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:

  1. Firma de mensajes XML.
  2. Establecimiento del túnel TLS con autenticación mutua (mTLS).
  3. Envíe el registro de solicitudes al datastream.

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

Cabe destacar que para poder utilizar AWS KMS, para firmar documentos con los requisitos 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 claves 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 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.

 

 

  1. Cree la clave privada (para la firma) en AWS KMS.
  2. Cree el secreto en AWS Secrets Manager con el contenido de la clave privada utilizada para mTLS.
  3. Almacene los 2 certificados en el almacén de parámetros de AWS Systems Manager: certificado clave generado para la firma y certificado generado para mTLS.
  4. El Servicio de Institución Financiera envía la solicitud en formato XML.
  5. Amazon API Gateway envía el mensaje XML a la aplicación que se ejecuta en AWS Lambda.
  6. La aplicación (AWS Lambda) utiliza AWS KMS para la firma digital de XML.
  7. La aplicación (AWS Lambda) utiliza la clave privada almacenada en AWS Secrets Manager para establecer mTLS.
  8. La aplicación transmite el XML firmado, a BACEN, en un túnel cifrado (mTLS).
  9. La aplicación (AWS Lambda) recibe la respuesta de BACEN y, si es necesario, valida la firma digital del XML recibido.
  10. La aplicación (AWS Lambda) registra el registro de solicitudes enviando directamente a Amazon Kinesis Data Firehose.
  11. El mensaje de respuesta se envía a Amazon API Gateway.
  12. El mensaje de respuesta lo recibe el servicio/aplicación.
  13. Amazon Kinesis Data Firehose utiliza AWS Glue Data Catalog para convertir los registros al formato de parquet.
  14. Amazon Kinesis Data Firehose envía registros, a Amazon S3, ya particionados en «carpetas» (/año/mes/day/time/).
  15. Amazon Athena utiliza AWS Glue Data Catalog como ubicación central para almacenar y recuperar metadatos de tabla.
  16. Los rastreadores de AWS Glue actualizan automáticamente las nuevas particiones en el repositorio de metadatos cada hora.
  17. Puede consultar datos inmediatamente directamente en Amazon S3 mediante servicios deanálisis sinservidor como Amazon Athena (ad hoc con SQL estándar) y Amazon QuickSight.

 

Costes y TPS

Cada clave maestra del cliente (CMK) que cree en AWS KMS cuesta 1 USD por mes hasta que se elimine, independientemente de si el material clave subyacente se generó a través del servicio, se importó de una fuente externa (BYOK) o se utiliza un almacén de claves personalizado de almacén de claves.

AWS KMS ofrece una capa gratuita de 20.000 solicitudes al mes, calculada en todas las regiones en las que el servicio está disponible. Las solicitudes a las API GenerateDataKeyPair y GenerateDataKeyPairWithOutPlainText, así como las solicitudes de API como Sign, Verify, Encrypt, Deccrypt y GetPublicKey que hacen referencia CMK asimétricos se excluyen de la capa gratuita.

Cada solicitud de API para AWS KMS (fuera de la capa gratuita) cuesta en la región Sudamérica (Sao Paulo):

  • 0,03 USD por 10.000 solicitudes
  • 0,03 USD por cada 10.000 solicitudes que involucran claves RSA 2048
  • $12.00 por 10.000 solicitudes de RSA GenerateDataKeypair

En cuanto a los umbrales, más específicamente en operaciones que utilizan claves asimétricas, AWS KMS tiene límites de:

  • 500 solicitas/segundo (compartido) para CMK RSA (límite suave).

Si es necesario, puede solicitar el aumento para satisfacer la necesidad de su caso de uso.

Para AWS Secrets Manager, hay un coste de 0,40 USD por secreto al mes. En el caso de secretos almacenados durante menos de un mes, el precio es proporcional (basado en el número de horas). Además, hay un costo de $0.05 por cada 10.000 llamadas API.

 

Conclusión

Al utilizarlos servicios de AWS ,  las instituciones financieras tienen el control y la confianza que necesitan para ejecutar su negocio de forma segura en el entorno de computación en la nube, además de flexibilidad y seguridad disponible.

Los requisitos de seguridad de BACEN (SFN) regulan el sistema bancario brasileño. Por lo tanto, conlos servicios deAWS, incluido el servicio de cifrado de AWS KMS, la institución financiera puede mejorar su capacidad para cumplir con los requisitos de seguridad y el cumplimiento, como la configuración regional, protección de datos y confidencialidad, con el fin de cumplir con los requisitos para conectarse al PIX.

AWS permitea las instituciones financieras automatizar las tareas de seguridad para que pueda centrarse en la escalabilidad y la innovación de su empresa. Además, las instituciones financieras pagan solo por los servicios que utilizan. La arquitectura presentada no solo cubre la parte de seguridad para lafirma digital y la transmisión (MTL) de mensajes, sino que también incluye la parte obligatoria de registro de solicitudes.

 

Artefactos

Para facilitar la comprensión e implementación de nuestra solución, compartimos el código fuente en el repositorioaws-samples/pix-proxy-samples  en GitHub.

  • Puede clonar, cambiar, ejecutarlo, pero se proporciona sólo como ejemplo y no debe utilizarse parcial o completamente en 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, creamos un Simulador para representar el entorno BACEN. En este simulador, necesitamos autenticación de cliente (Proxy) para garantizar el requisito de MTL. Además, validamos la firma digital de las solicitudes entrantes y firmamos digitalmente la respuesta que se enviará al Proxy.

En promedio, las solicitudes de obtención de reclamaciones obtienen un tiempo de respuesta de 78 ms (depende de la cantidad de recursos computacionales del contenedor y del tamaño del mensaje de respuesta), medido desde el servicio/aplicación. Flujo:

  • Servicio/Aplicación → Proxy (mTLS) → Simulador (Signs Response) (mTLS) → Proxy (Valida la firma de respuesta) (almacena el registro de solicitud) → Servicio/Aplicación.

En promedio, las solicitudes de inserción de reclamación obtienen un tiempo de respuesta de 122 ms (depende de la cantidad de recursos computacionales del contenedor y del tamaño de los mensajes de solicitud y respuesta), medido desde el servicio/aplicación. Flujo:

  • Servicio/Aplicación → Proxy (solicitud de signos) (mTLS) → Simulador (valida la firma de solicitud) (respuesta de firma) (mTLS) → Proxy (valida la firma de respuesta) (almacena el registro de solicitud) → Servicio/Aplicación.

 

Lectura adicional

  1. Serie AWS PIX 1: Arquitectura con AWS CloudHSM para admitir la firma digital y la transmisión segura de mensajes al PIX. (blog)
  2. Cómo integrar AWS KMS con JCE y generar un CSR (blogpost)
  3. Cómo aprobar los servicios de AWS para datos altamente confidenciales en instituciones financieras (blogpost)
  4. Mejorar la prevención del fraude en las instituciones financieras mediante la creación de una solución de detección de vida.(blog)
  5. Firma digital con la nueva función de claves asimétricas de AWS KMS (blogpost).
  6. Gestor de las tarifas de solicitudes de API de AWS KMS utilizando las cuotas de servicio y Amazon CloudWatch (blogpost).
  7. Cómo verificar las firmas de clave asimétricas de AWS KMS localmente con OpenSSL (blogpost).
  8. La importancia del cifrado y la forma en que AWS puede ayudar (blogpost).
  9. TLS post-Quantum ahora es compatible con AWS KMS (blogpost)
  10. Cómo utilizar las políticas basadas en recursos en la consola de AWS Secrets Manager para acceder de forma segura a los secretos en las cuentas de AWS (blogpost).
  11. Ajuste de AWS Java SDK 2.x para reducir el tiempo de inicio (blogpost).
  12. Programación de la concurrencia aprovisionada de AWS Lambda para el uso pico recurrente (blogpost).
  13. Simplificación de las mejores prácticas sin servidor con Lambda Powertools (blogpost).

 

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.

 

 

 

Si tiene preguntas sobre AWS o cualquier proyecto que desee discutir, complete este formulario y un representante se pondrá en contacto con usted.