O blog da AWS

Suportando Mutual TLS (mTLS) Utilizando Certificados do ICP-Brasil para o Open Banking no Brasil utilizando o Amazon API Gateway

Por Lucas Lins, Arquiteto de Soluções na AWS
Enrico Bergamo, Arquiteto de Soluções especialista em Serverless na AWS
Paulo Aragão, Arquiteto de Soluções Sênior na AWS
Julio Carvalho, Arquiteto Principal de Segurança para o mercado Financeiro na AWS
Amanda Quinto, Arquiteta de Soluções da AWS

 

Introdução

Como comentado no post anterior, o Open Banking, ou Sistema Financeiro Aberto, é a possibilidade de clientes de produtos e serviços financeiros permitirem o compartilhamento de suas informações entre diferentes instituições autorizadas pelo Banco Central (BACEN) e a movimentação de suas contas bancárias a partir de diferentes plataformas e não apenas pelo aplicativo ou site do banco, de forma segura, ágil e conveniente. O novo sistema trará autonomia e controle para o consumidor, é ele/ela quem decide quando e com quem quer compartilhar seus dados financeiros. Isto significa que o compartilhamento só será possível através do seu consentimento à instituição detentora dos dados – após a autorização, aplicativos de terceiros que acessam, com segurança, os dados financeiros, podem ser oferecidos aos consumidores. Todo o processo se dará de forma padronizada através de determinações específicas emitidas pelos órgãos reguladores, para o Brasil, por exemplo, é o BACEN, e ocorrerá através da conexão de APIs, que permitem uma comunicação rápida e confiável diretamente entre duas instituições.

Além disso, o BACEN publicou, no dia 23 de junho de 2020, a Circular 4.032 dispondo sobre a estrutura inicial responsável pela governança do processo de implementação do Open Banking no país. Tal estrutura é composta por três níveis, sendo:

  • I – Conselho Deliberativo: responsável por decidir sobre as questões necessárias para a implementação do novo sistema e propor ao BACEN os padrões técnicos do Open Banking;
  • II – Secretariado: responsável por organizar e coordenar os trabalhos;
  • III – Grupos Técnicos: encarregados de elaborar estudos e propostas técnicas para a implementação do ecossistema.

Essa estrutura é responsável por estabelecer e fornecer os requerimentos técnicos obrigatórios para que as instituições participantes façam parte do Open Banking. Alguns destes requerimentos tem como base as principais diretrizes definidas para PSD2 em EMEA, como a autenticação de clientes através do protocolo de segurança mTLS, utilizando um perfil de segurança de nível mais elevado para ser a primeira camada de proteção, chamado FAPI (Financial-grade API). Por outro lado, existem requerimentos que são específicos para o território brasileiro, como é o caso do certificado digital ICP-Brasil, que será utilizado para reforçar a segurança nas comunicações entre as entidades que irão compor o Open Banking.

Neste post, descrevemos o passo a passo, de como os participantes do Open Banking podem utilizar o serviço Amazon API Gateway em conjunto com certificados digitais ICP-Brasil para exporem suas APIs e cumprirem o requerimento de autenticação TLS mútua (mTLS).

 

Mutual TLS (mTLS)

A autenticação TLS mútua (mTLS) garante que o tráfego seja seguro e ambas as partes estejam fortemente autenticadas. Nas negociações de criptografia tradicional TLS, apenas o servidor se autentica usando chaves de criptografia, no entanto no mTLS ambas as partes (cliente e servidor) devem autenticar-se apresentando seus certificados e usando suas chaves privadas. A encriptação ocorre na camada de transporte durante o hand-shake do protocolo TLS.

Verifique que na figura 1, a troca inicial de mensagens é feita usando chaves assimétricas e após autenticação de ambas partes, é gerada uma chave simétrica e terminando a negociação.

 

Figura 1 – Cliente autenticado pelo lado servidor no TLS handshake.

 

Principais serviços AWS utilizados na arquitetura proposta

Exposição de APIs

O Amazon API Gateway é um serviço gerenciado que permite que desenvolvedores criem, publiquem, mantenham, monitorem e protejam APIs em qualquer escala com facilidade. APIs agem como a “porta de entrada” para aplicativos acessarem dados, lógica de negócios ou funcionalidade de seus serviços de back-end. Usando o API Gateway, você pode criar APIs do RESTful e APIs do WebSocket que habilitam aplicativos de comunicação bidirecionais em tempo real. O API Gateway dá suporte a cargas de trabalho conteinerizadas e serverless, além de aplicativos da web.

Além do Console AWS, CLI, e o AWS SAM/CloudFormation, o Amazon API Gateway também suporta a importação e exportação de APIs baseadas na especificação do OpenAPI, bem como possibilitando o uso de extensões do OpenAPI próprias do API Gateway, que serão utilizada nesta solução na definição de nossas APIs.

Embora o Amazon API Gateway suporte Mutual-TLS (mTLS) utilizando certificados gerados pelo AWS Certificate Manager (ACM), hoje ainda não é suportada a configuração do mTLS utilizando certificados importados no ACM, como é uma necessidade do Open Banking, que requer a utilização dos certificados do ICP-Brasil. Para este cenário, atualmente é necessário utilizar uma solução de proxy reverso na frente do Amazon API Gateway que faça o mTLS.

 

Proxy mTLS

O AWS Fargate é um mecanismo de computação serverless para contêineres que funciona com o Amazon Elastic Container Service (ECS) e com o Amazon Elastic Kubernetes Service (EKS). O uso de serviços com abordagem serverless tem como proposta o foco no desenvolvimento de aplicativos por conta da redução de carga operacional com gerência de servidores. Assim, o participante do Open Banking foca na entrega de valor para o negócio.

A AWS oferece várias ferramentas para monitorar os recursos do Amazon ECS e responder a incidentes potenciais, como: Amazon CloudWatch, Amazon CloudWatch Logs, AWS CloudTrail e AWS Trusted Advisor. Se quiser saber mais como implementar estratégias de log na plataforma da AWS, clique aqui.
Você deve coletar dados de monitoramento de todas as partes de sua solução da AWS para ser mais fácil realizar a depuração de uma falha de vários pontos (caso ocorra).

 

Criptografia

O AWS CloudHSM é um serviço criptografia que as Instituições Financeiras podem usar para armazenar, gerenciar suas chaves e executar funções criptográficas. Ele disponibiliza um cluster de HSMs (Hardware Security Module) dedicados FIPS 140-2 Nível 3 (validado) sob controle exclusivo da Instituição Financeira, diretamente no Amazon Virtual Private Cloud (VPC). O AWS CloudHSM permite fácil integração com aplicativos que rodam em instâncias Amazon EC2 e/ou containers. Com o AWS CloudHSM, é possível usar controles de segurança padrão da VPC para gerenciar o acesso aos HSMs. Os aplicativos conectam-se ao HSMs usando canais SSL mutuamente autenticados e estabelecidos pelo software cliente do HSM.

O AWS CloudHSM pode ser usado para oferecer suporte a diversos casos de uso, como gerenciamento de direitos digitais (DRM), infraestrutura de chaves públicas (PKI), assinatura de documentos e funções criptográficas usando interfaces PKCS#11, Java Cryptography Extensions (JCE), Microsoft CNG e OpenSSL, e fornece disponibilidade, replicação e backup automatizados dos HSMs dedicados ao cliente nas zonas de disponibilidade.

Além disso, o AWS CloudHSM pode ser utilizado para aceleração SSL (SSL/TLS Offload), onde grande quantidade de computação que o servidor Web executa no processo de SSL/TLS, pode ser descarregada aos HSMs no cluster do AWS CloudHSM. Esse descarregamento reduz a carga computacional do servidor Web e oferece segurança extra ao armazenar as chaves privadas do servidor nos HSMs.

 

Características do AWS CloudHSM:

  1. Acesso dedicado.
  2. Geração e uso de chaves de criptografia em HSMs validados pelo FIPS 140-2 nível 3.
  3. BYOK (familiaridade com o ciclo de vida das chaves atual do cliente).
  4. Opção configurável para nunca extrair as chaves geradas dentro do HSM.
  5. Alta disponibilidade e durabilidade com configuração mínima.
  6. Preço por hora, conforme o uso, para cada HSM em uso.
  7. É possível ajustar rapidamente a escala da capacidade do HSM ao adicionar e remover HSMs do cluster, sob demanda.
  8. Integrado ao AWS CloudTrail no registro de solicitações de API da AWS e ao Amazon CloudWatch para registro de ações de gerenciamento de usuários e chaves.
  9. Serviço gerenciado, onde a AWS gerencia os aspectos de manutenção de hardware do serviço e os clientes controlam totalmente os aspectos criptográficos do serviço.

 

Arquitetura

A arquitetura referência, apresentada neste blogpost, considera a utilização dos serviços Elastic Load Balancing (Network Load Balancer), AWS Fargate, AWS CloudHSM, Amazon API Gateway, AWS Secrets Manager, AWS Systems Manager Parameter Store e Amazon S3.

Como peças centrais, estão:

  • AWS Fargate: onde o Proxy mTLS é executado e que possui dependência dos serviços:
    • AWS Secrets Manager: para armazenar as credenciais de acesso do AWS CloudHSM.
    • AWS CloudHSM: para aceleração SSL (SSL/TLS Offload).
    • AWS Systems Manager Parameter Store:para armazenar os certificados digitais.
    • Amazon S3: para armazenar o truststore.
  • Amazon API Gateway: para exposição das APIs definidas no Open Banking. Vale ressaltar que:

Segue o diagrama da arquitetura e passo-a-passo do fluxo de recebimento de uma requisição realizado por um participante do Open Banking.

 

 

  1. Armazenar login e senha no AWS Secrets Manager, para se comunicar com o AWS CloudHSM.
  2. Criar ou importar a chave privada no AWS CloudHSM (utilizada para a geração do certificado ICP-Brasil).
  3. Armazenar os 2 certificados no AWS Systems Manager Parameter Store: certificado gerado ICP-Brasil e certificado do CloudHSM (CA do cliente).
  4. Armazenar no Amazon S3o truststore com os certificados que serão confiáveis a sua API.
  5. O Network Load Balancer recebe requisição e redireciona a requisição ao Proxy mTLS (AWS Fargate) sem realizar TLS Termination.
  6. O Proxy mTLS (AWS Fargate) utiliza o AWS CloudHSM com SSL/TLS Offload para estabelecimento do mTLS.
  7. O Proxy mTLS (AWS Fargate) envia a requisição ao Amazon API Gateway, que está configurado de forma privada, ou seja, não acessível publicamente.
  8. O Amazon API Gateway envia a requisição ao seu serviço de Backend.

 

Conclusão

Para o ano de 2021, o Open Banking é o grande tema para a indústria brasileira de serviços financeiros. No entanto, é apenas o começo de uma transformação que poderá habilitar maior integração entre os setores bancário, de seguros, energia e telecomunicações. A democratização das APIs irá estimular a competição para um setor concentrado, permitindo a ampliação da oferta de produtos e serviços financeiros.

Usando os serviços da AWS, os participantes do Open Banking possuem o controle e a confiança necessários para executar seus negócios com segurança no ambiente de computação em nuvem mais flexível e seguro disponível. Além disso, os participantes do Open Banking pagam apenas pelos serviços que usam.

A arquitetura apresentada contempla a parte de segurança para atendimento do requerimento de estabelecimento de comunicação com autenticação TLS mútua (mTLS). Os próximos blog posts aprofundarão o nível de detalhamento técnico sobre outros requerimentos obrigatórios para a implementação do Open Banking em território nacional.

 

Artefatos

Para facilitar o entendimento e implantação da solução, compartilhamos os seguintes códigos-fonte no GitHub:

 

Leitura Adicional

 

 

Sobre os autores

Lucas Lins é Arquiteto de Soluções na AWS, com mais de 15 anos de experiência em arquitetura de software e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica. Especialista em FSI e Serverless, Lucas atua com ênfase no segmento de Startup, orientando e suportando os clientes em sua jornada na nuvem.

 

 

 

Enrico Bergamo é Arquiteto de Soluções especialista em Serverless na AWS para a América Latina, e atua auxiliando clientes de diversos segmentos em suas jornadas de modernização de aplicações na nuvem. Com mais de 10 anos de experiência em Arquitetura e Desenvolvimento de Sistemas, e DevOps, Enrico atuou diretamente com diversas empresas na definição, implementação, e implantação de diversas soluções corporativas.

 

 

 

Paulo Aragão é um Arquiteto de Soluções Sênior que trabalha há mais de 20 anos com clientes Enterprise. Ampla experiência em Computação de Alta Performance (HPC), atualmente dedica seus dias a ajudar clientes a inovarem através do uso de serviços de IA e ML na nuvem AWS. Apaixonado por música e mergulho, você pode encontra-lo em vídeos de covers musicais no Youtube ou no fundo do mar. No seu tempo livre, gosta de ler livros, jogar World of Warcraft, e cozinhar para os amigos.

 

 

 

Julio Carvalho é Principal Security Architect para o mercado financeiro da América Latina na AWS. Há 17 anos atuando com Segurança, ele ajuda clientes a criar arquiteturas seguras e a resolver desafios de proteção e de conformidade nas suas jornadas na nuvem. Já visitou 28 países, mas ainda não se decidiu sobre onde está a melhor comida.

 

 

 

Amanda Quinto é Arquiteta de Soluções da AWS no time de Public Sector com foco em Nonprofits Organization. Amanda já atuou em diversos projetos ajudando os times de desenvolvimento e sustentação em arquitetar sistemas resilientes e escaláveis. Formada pela FATEC-SP, é entusiasta de Devops, machine learning, e apaixonada por Kombis.