Blog de Amazon Web Services (AWS)

Soporte de TLS mutuo (mTLS) mediante certificados ICP-Brasil para la banca abierta en Brasil mediante Amazon API Gateway

Por Lucas Lins, Arquitecto de Soluciones en AWS
Enrico Bergamo, Arquitecto de Soluciones en Serverless en AWS
Paulo Aragão, Arquitecto de Soluciones Senior en AWS
Julio Carvalho, Arquitecto Principal de seguridad para el mercado financiero en AWS
Amanda Quinto, Arquitecta de Soluciones en AWS

 

Introducción

Como se comentó en el post anterior, Open Banking o Sistema Financiero Abierto, es la posibilidad para los clientes de productos y servicios financieros de permitir el intercambio de su información entre diferentes instituciones autorizadas por el Banco Central (BACEN) y el movimiento de sus cuentas bancarias desde diferentes plataformas y no sólo a través de la aplicación o sitio web del banco, de una manera segura, ágil y conveniente. El nuevo sistema traerá autonomía y control al consumidor, es él/ella quien decide cuándo y con quién quiere compartir sus datos financieros. Esto significa que el intercambio solo será posible con su consentimiento en la institución que posea los datos. Después de la autorización, las aplicaciones de terceros que acceden de forma segura a los datos financieros se pueden ofrecer a los consumidores. Todo el proceso se llevará a cabo de forma estandarizada a través de determinaciones específicas emitidas por organismos reguladores, para Brasil, por ejemplo, es BACEN, y se producirá a través de la conexión de APIs, que permiten una comunicación rápida y confiable directamente entre dos instituciones.

Además, BACEN publicó, el 23 de junio de 2020, la Circular 4.032 , que establece la estructura inicial responsable de la gobernanza del proceso de implementación de la Banca Abierta en el país. Dicha estructura consta de tres niveles, a saber:

  • I — Consejo Deliberativo: responsable de decidir sobre las cuestiones necesarias para la aplicación del nuevo sistema y proponer a BACEN las normas técnicas de la Banca Abierta.
  • II — Secretaría: responsable de la organización y coordinación de los trabajos.
  • III — Grupos Técnicos: responsables de elaborar estudios y propuestas técnicas para la implementación del ecosistema.

Esta estructura es responsable de establecer y proporcionar los requisitos técnicos necesarios para que las instituciones participantes formen parte de Open Banking. Algunos de estos requisitos se basan en las directrices principales definidas para PSD2 en EMEA, como la autenticación de clientes a través de los MTL del protocolo de seguridad, utilizando un perfil de seguridad de nivel superior para ser la primera capa de protección, llamado FAPI (API de grado financiero). Por otro lado, existen requisitos específicos para el territorio brasileño, como el certificado digital ICP-Brasil, que se utilizará para fortalecer la seguridad de las comunicaciones entre las entidades que compondrán la Banca Abierta.

En este post, describimos el tutorial de cómo los participantes de Open Banking pueden utilizar el servicio Amazon API Gateway junto con los certificados digitales ICP-Brasil para exponer sus API y cumplir con los requisitos de autenticación TLS mutua (MTL).

 

TLS mutuos (MTL)

La autenticación TLS mutua (MTL) garantiza que el tráfico es seguro y que ambas partes estén fuertemente autenticadas. En las negociaciones tradicionales de cifrado TLS, solo el servidor se autentica mediante llaves de cifrado; sin embargo, en MTL ambas partes (cliente y servidor) deben autenticarse presentando sus certificados y utilizando sus llaves privadas. El cifrado se produce en la capa de transporte durante el enlace del protocolo TLS.

Compruebe que en la Figura 1, el intercambio inicial de mensajes se realiza utilizando llaves asimétricas y después de la autenticación de ambas partes, se genera una llave simétrica y finaliza la negociación.

 

Figura 1 — Cliente autenticado del lado del servidor en el protocolo de enlace TLS.

 

Servicios clave de AWS utilizados en la arquitectura propuesta

Exposición de API

Amazon API Gateway es un servicio gestionado que permite a los desarrolladores crear, publicar, mantener, supervisar y proteger fácilmente API a cualquier escala. Las API actúan como la «puerta de enlace» para que las aplicaciones accedan a datos, lógica empresarial o funcionalidad desde sus servicios back-end. Mediante API Gateway, puede crear API RESTful y API WebSocket que permiten aplicaciones de comunicación bidireccional en tiempo real. API Gateway admite cargas de trabajo en contenedores y sin servidor, así como aplicaciones web.

Además de AWS Console, CLI y AWS SAM/CloudFormation, Amazon API Gateway también admite la importación y exportación de API basadas en la especificación OpenAPI, además de permitir el uso de las propias extensiones OpenAPI de API Gateway, que se utilizarán en la definición de nuestras API.

Aunque Amazon API Gateway admite mutual-TLS (MTL) mediante certificados generados por AWS Certificate Manager (ACM), hoy en día todavía no se admite la configuración de MTL utilizando certificados importados en ACM, al igual que una necesidad de Open Banking, que requiere el uso de certificados ICP-Brasil. Para este escenario, actualmente necesita utilizar una solución proxy inversa delante de Amazon API Gateway que haga MTL.

 

Proxy MTLs

AWS Fargate es un motor informático sin servidor para contenedores que funciona con Amazon Elastic Container Service (ECS) y Amazon Elastic Kubernetes Service (EKS). Se propone el uso de servicios con un enfoque 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, el participante de Banca Abierta se centra en entregar 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í.
Debe recopilar datos de supervisión de todas las partes de la solución de AWS para facilitar la depuración de un error de varios puntos (si se produce).

 

Criptografía

AWS CloudHSM es un servicio criptográfico que las instituciones financieras pueden utilizar para almacenar, administrar sus claves y realizar funciones criptográficas. Proporciona un clúster de HSM (módulo de seguridad de hardware) FIPS 140-2 de nivel 3 (validado) bajo el control exclusivo de la institución financiera, directamente en Amazon Virtual Private Cloud (VPC). AWS CloudHSM permite una integración sencilla con aplicaciones que se ejecutan en instancias o contenedores de Amazon EC2. Con AWS CloudHSM, puede utilizar controles de seguridad de VPC estándar para administrar el acceso a los HSM. Las aplicaciones se conectan a HSM mediante canales SSL mutuamente autenticados y establecidos por el software cliente HSM.

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

Además, AWS CloudHSM se puede utilizar para la aceleración SSL (descarga SSL/TLS), donde una gran cantidad de procesamiento que ejecuta el servidor web en el proceso SSL/TLS se puede descargar a HSM en el clúster de AWS CloudHSM. Esta descarga reduce la carga computacional del servidor Web y proporciona seguridad adicional cuando se almacenan las claves privadas del servidor en HSM.

Características de AWS CloudHSM:

  1. Acceso dedicado.
  2. Generación y uso de claves de cifrado en HSM validados FIPS 140-2 nivel 3.
  3. BYOK (familiaridad con el ciclo de vida clave actual del cliente).
  4. Opción configurable para no extraer nunca las claves generadas dentro del HSM.
  5. Alta disponibilidad y durabilidad con una configuración mínima.
  6. Precio por hora, según el uso, por cada HSM en uso.
  7. Puede escalar rápidamente la capacidad de HSM agregando y eliminando HSM del clúster, a petición.
  8. Integrado con AWS CloudTrail en el registro de solicitudes de API de AWS y Amazon CloudWatch para registrar acciones de administración de usuarios y claves.
  9. Servicio administrado, donde AWS gestiona los aspectos de mantenimiento del hardware del servicio y los clientes controlan completamente los aspectos criptográficos del servicio.

 

Arquitectura

La arquitectura de referencia, presentada en este blog, considera el uso de Elastic Load Balancing (Network Load Balancer), AWS Fargate, AWS CloudHSM, Amazon API Gateway, AWS Secrets Manager, AWS Systems Manager Parameter Store y Amazon S3.

Como partes centrales:

  • AWS Fargate: dónde se ejecutan los MTL proxy y depende de los servicios:
    • AWS Secrets Manager: para almacenar las credenciales de acceso de AWS CloudHSM.
    • AWS CloudHSM: para aceleración SSL (descarga SSL/TLS).
    • AWS Systems Manager Parameter Store:para almacenar certificados digitales.
    • Amazon S3: Para almacenar el truststore.
  • Amazon API Gateway: para la exposición de las API definidas en Open Banking. Vale la pena mencionar:

A continuación se presenta el diagrama de la arquitectura y el flujo de recepción paso a paso de una solicitud realizada por un participante de Banca Abierta.

 

  1. Almacene el inicio de sesión y la contraseña en AWS Secrets Manager para comunicarse con AWS CloudHSM.
  2. Cree o importe la llave privada en AWS CloudHSM (utilizada para la generación de certificados ICP-Brasil).
  3. Almacene los 2 certificados en el AWS Systems Manager Parameter Store: certificado generado por ICP-Brasil y certificado CloudHSM (CA del cliente).
  4. Almacene en Amazon S3 el Truststore con los certificados en los que confía su API.
  5. El balanceador de carga de red recibe una solicitud y redirige la solicitud a los MTL proxy (AWS Fargate) sin realizar la terminación TLS.
  6. El proxy MTLs (AWS Fargate) utiliza AWS CloudHSM con descarga SSL/TLS para establecer MTL.
  7. Los MTL proxy (AWS Fargate) envía la solicitud a Amazon API Gateway, que está configurada de forma privada, es decir, no accesible públicamente.
  8. Amazon API Gateway envía la solicitud a su servicio Backend.

 

Conclusión

Para el año 2021, la Banca Abierta es el tema principal de la industria brasileña de servicios financieros. Sin embargo, es sólo el comienzo de una transformación que puede permitir una mayor integración entre los sectores bancario, de seguros, de energía y de telecomunicaciones. La democratización de las APIs estimulará la competencia por un sector concentrado, permitiendo la expansión de la oferta de productos y servicios financieros.

Mediante los servicios de AWS, los participantes en Open Banking, tienen el control y la confianza que necesitan para ejecutar su negocio de forma segura en el entorno de computación en la nube de forma más flexible y segura. Además, los participantes de Open Banking pagan solo por los servicios que utilizan.

La arquitectura presentada incluye la parte de seguridad para el cumplimiento del requisito de establecer comunicación con autenticación TLS mutua (MTL). Las próximas publicaciones del blog profundizarán en el nivel de detalle técnico sobre otros requisitos obligatorios para la implementación de la Banca Abierta en territorio nacional.

 

Artefactos

Para facilitar la comprensión e implementación de la solución, compartimos las siguientes fuentes en GitHub:

 

Lectura adicional

 

 

Sobre los autores

Lucas Lins es arquitecto de soluciones de AWS con más de 15 años de experiencia en arquitectura de software y desarrollo de soluciones que involucran sistemas empresariales y de misión crítica. Especialista en FSI y Serverless, Lucas trabaja con énfasis en el segmento Startup, guiando y apoyando a los clientes en su viaje a la nube.

 

 

 

Enrico Bergamo es arquitecto de soluciones especializado en Servidorless en AWS para América Latina y trabaja para ayudar a clientes de diversos segmentos en sus viajes de modernización de aplicaciones en la nube. Con más de 10 años de experiencia en Arquitectura y Desarrollo de Sistemas, y DevOps, Enrico ha trabajado directamente con varias empresas en la definición, implementación e implementación de diversas soluciones empresariales.

 

 

 

Paulo Aragão es un Arquitecto Senior Solutions que ha trabajado con clientes empresariales durante más de 20 años. Una amplia experiencia en informática de alto rendimiento (HPC), actualmente dedica sus días a ayudar a los clientes a innovar mediante el uso de servicios de IA y ML en la nube de AWS. Apasionado por la música y el buceo, se puede encontrar en portadas musicales videos en Youtube o en el fondo del mar. En su tiempo libre, le gusta leer libros, jugar a World of Warcraft y cocinar para amigos.

 

 

 

Julio Carvalho es arquitecto principal de seguridad para el mercado financiero latinoamericano en AWS. Durante 17 años de trabajo con Security, ha ayudado a los clientes a crear arquitecturas seguras y resolver desafíos de protección y cumplimiento normativo en sus viajes a la nube. Ha visitado 28 países, pero no ha decidido cuál es el mejor comida.

 

 

 

Amanda Quinto es arquitecta de soluciones de AWS en el equipo de sector público con un enfoque en la organización sin fines de lucro. Amanda ha trabajado en varios proyectos ayudando a los equipos de desarrollo y soporte a diseñar sistemas resilientes y escalables. Graduada de FATEC-SP, es entusiasta de Devops, aprendizaje automático y apasionada por Kombis.