Arquitetura com AWS KMS para suportar assinatura digital e AWS Secrets Manager para transmissão segura de mensagens ao PIX

Por Lucas Lins, Arquiteto de Soluções na AWS
João Paulo Aragão Pereira, Arquiteto de Soluções na AWS

Como comentado nos blogposts anteriores (primeiro e segundo), o novo Sistema de Pagamento Instantâneo (PIX) visa acelerar a transmissão da mensagem de pagamento e a disponibilidade de fundos finais para o beneficiário, reduzindo custos, aumentando a segurança e, finalmente, melhorando a experiência do cliente. A AWS provê as certificações e padrões de conformidade necessários para as Instituições Financeiras cumprirem com os requerimentos do PIX, como criptografia e assinatura digital de mensagens no formato XML.

Vale relembrar que a estrutura de segurança definida, entre os requerimentos obrigatórios e recomendados, está detalhada no nosso primeiro blogpost.

Neste último blogpost da série (parte 3 de 3), descrevemos o passo a passo, de como as Instituições Financeiras podem utilizar o serviço de criptografia AWS Key Management Service (KMS) e o AWS Secrets Manager para cumprir com as diretrizes de segurança do Banco Central Brasileiro (BACEN), ao se conectarem no PIX.

Vantagens para as Instituições Financeiras

Seguem algumas vantagens para as Instituições Financeiras brasileiras criarem e configurarem uma arquitetura para conexão ao PIX, utilizando o AWS KMS:

Manter dados criptografados em repouso e em trânsito;
Assinar digitalmente as mensagens e estabelecer túnel TLS com autenticação mútua;
O AWS KMS inicia com valor default de 500 TPS (transações por segundo) para operações criptográficas com chaves assimétricas RSA. Contudo, é um soft limit sendo possível aumentar facilmente o valor via Service Quotas;
Escalabilidade, disponibilidade e integração nativa com serviços AWS;
O AWS KMS é um serviço gerenciado da AWS para armazenamento e uso seguro de chaves criptográficas, validado no FIPS 140-2 Nível 2.
Por ser uma arquitetura sem servidor (serverless), há redução da carga operacional e redução de custos de operação relacionada ao gerenciamento e segurança de servidores.

Principais serviços AWS utilizados na arquitetura proposta

Aplicação

O Amazon API Gateway é um serviço gerenciado que permite que desenvolvedores criem, publiquem, mantenham, monitorem e protejam APIs em qualquer escala com facilidade. O API Gateway administra todas as tarefas envolvidas no recebimento e processamento de até centenas de milhares de chamadas de API simultâneas, inclusive gerenciamento de tráfego. É possível autorizar chamadas de API e limitar tráfego para garantir que as operações de back-end suportem os picos de tráfego e os sistemas de back-end não sejam chamados desnecessariamente.

Com o aplicativo sendo executado no AWS Lambda, permite a Instituição Financeira executar código sem provisionar ou gerenciar servidores. Você paga apenas pelo tempo de computação consumido. Com o AWS Lambda, você pode executar o código para praticamente qualquer tipo de aplicativo ou serviço de back-end, tudo sem precisar de administração. Basta carregar o código e o Lambda se encarrega de todos os itens necessários para executar e alterar a escala do código com alta disponibilidade. Você pode configurar seu código para que ele seja acionado automaticamente por outros serviços da AWS ou chamá-lo diretamente usando qualquer aplicação móvel ou da web.

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, a Instituição Financeira foca na entrega de valor para o negócio.

A AWS oferece várias ferramentas para monitorar e solucionar problemas de aplicativos do AWS Lambda, e responder a incidentes potenciais, como o: Amazon CloudWatch, Amazon CloudWatch Logs, AWS CloudTrail, AWS Trusted Advisor e AWS X-Ray. 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 múltipla (caso ocorra).

Registro de Logs (auditoria)

Um dos requerimentos do BACEN, para o PIX, é que a Instituição Financeira deve armazenar o registro da requisição e resposta de cada transação. O registro consistente das transações é essencial para auditoria, além de auxiliar na identificação e solução de problemas.

As arquiteturas que demonstramos neste blogpost utilizam a arquitetura baseada em eventos. Assim, utilizamos o Amazon Kinesis Data Firehose que é um serviço totalmente gerenciado para entrega de dados em streaming próximo do tempo real, como eventos, e persistência no Amazon S3.

O Amazon Athena pode ser usado para executar consultas interativas, em arquivos de log centralizados no Amazon S3, utilizando linguagem SQL padrão. E o Catálogo de dados do AWS Glue é um índice para as métricas de localização, esquema e tempo de execução dos seus dados. Você usa as informações no Data Catalog para criar e monitorar seus trabalhos de ETL. As informações no Data Catalog são armazenadas como tabelas de metadados, em que cada tabela específica é um único armazenamento de dados. Normalmente, você executa um crawler para fazer o inventário dos dados.

Criptografia e Assinatura Digital

AWS Secrets Manager

O serviço AWS Secrets Manager permite que a Instituição Financeira rotacione, gerencie e recupere facilmente segredos como credenciais de banco de dados, chaves de APIs e entre outros durante todo o seu ciclo de vida. Os usuários e aplicativos recuperam os segredos com uma chamada às APIs do Secrets Manager, o que elimina a necessidade de codificar informações confidenciais em texto simples.

Com o Secrets Manager, você pode ajudar a proteger segredos criptografando-os com chaves que você mesmo gerencia com o AWS KMS. Um segredo no AWS Secrets Manager consiste nos dados secretos protegidos e nas informações importantes necessárias para gerenciar o segredo.

Utilizamos o AWS Secrets Manager para armazenar a chave privada que será utilizada para o estabelecimento do túnel TLS com autenticação mútua com o BACEN.

AWS KMS

O AWS KMS é um serviço gerenciado que facilita para as Instituições Financeiras a criação e o controle de chaves mestras do cliente (CMKs), e das chaves de criptografia usadas para criptografar seus dados. As CMKs do AWS KMS são protegidas por módulos de segurança de hardware (HSMs) validados pelo programa de validação de módulo criptográfico FIPS 140-2.

Figura 1 – Arquitetura do AWS KMS

Características do AWS KMS

O AWS KMS permite que você execute operações de assinatura digital usando pares de chaves assimétricas para garantir a integridade dos dados.
Usa módulos de segurança de hardware (HSMs) validados ou em processo de validação pelo FIPS 140-2 no nível 2, e com nível 3 em várias categorias, para gerar e proteger chaves.
API amigável (chaves simétricas e assimétricas) e integrado ao AWS Encryption SDK (somente chaves simétricas).
Impossibilidade de extração de chaves privadas.
Integrado ao AWS CloudTrail para registrar todas as solicitações de API, inclusive ações de gerenciamento de chave e uso de suas chaves.
Serviço de baixo custo. Não há compromisso nem cobranças iniciais para usar o AWS KMS.
Serviço gerenciado, onde a AWS gerencia os aspectos de manutenção do serviço e os clientes controlam totalmente os aspectos criptográficos do serviço.

Arquitetura

A arquitetura exemplo, apresentada neste blogpost, pode ser parte de uma solução mais completa, base ada em eventos, que pode contemplar todo o fluxo de transmissão da mensagem de pagamento, desde o core bancário. Por exemplo, a solução completa da Instituição Financeira (pagadora ou recebedora), poderia conter outras arquiteturas complementares como de Autorização, Desfazimento (baseado no modelo SAGA), Efetivação, Comunicação com ambiente on-premises (ambiente híbrido), etc. A Instituição Financeira pode utilizar outros serviços como Amazon EventBridge, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), AWS Step Functions, Amazon ElastiCache, Amazon DynamoDB.

No diagrama da nossa arquitetura, a caixa verde representa o Proxy de comunicação com o BACEN, considerando os serviços AWS KMS, AWS Lambda, Amazon API Gateway e AWS Secrets Manager.

A ideia do Proxy é ser um caminho direto e mandatório para toda transação, com os seguintes objetivos:

Assinatura de mensagens XML.
Estabelecimento do túnel TLS com autenticação mútua (mTLS).
Envio do log da requisição para o datastream.

Diferentemente da arquitetura com AWS CloudHSM, no qual utilizamos o ELB para efetuar o balanceamento entre as mensagens SPI e DICT, aqui foi utilizado APIs privadas, via AWS API Gateway, para efetuar a distinção entre os 2 tipos de mensagem.

Vale ressaltar que para utilizar o AWS KMS, para assinar documentos com os requerimentos exigidos pelo PIX, é necessário a geração de um Certificate Signing Request (CSR) e, posteriormente, obter um certificado digital válido ICP-Brasil no padrão SPB. Para saber como gerar um CSR para chaves assimétricas gerenciadas pelo AWS KMS, veja aqui.

Opcionalmente, a Instituição Financeira pode visualizar as transações que esta solução processa usando o Amazon QuickSight. A arquitetura serverless do QuickSight permite que você forneça insights a todos em sua organização, e você pode compartilhar painéis interativos e sofisticados com todos os seus usuários, permitindo que eles façam buscas detalhadas e explorem dados para responder a perguntas e obter insights relevantes.

Proxy

O diagrama abaixo representa a arquitetura, e o passo-a-passo do fluxo de transmissão seguro da mensagem para o BACEN e respectiva resposta.

Criar a chave privada (para assinatura) no AWS KMS.
Criar o segredo no AWS Secrets Manager com o conteúdo da chave privada utilizada para mTLS.
Armazenar os 2 certificados no AWS Systems Manager Parameter Store: certificado da chave gerada para assinatura, certificado gerado para o mTLS.
O Serviço/Aplicação da Instituição Financeira envia a requisição no formato XML.
Amazon API Gateway envia a mensagem XML para a aplicação sendo executada no AWS Lambda.
A aplicação (AWS Lambda) utiliza o AWS KMS para assinatura digital do XML.
A aplicação (AWS Lambda) utiliza a chave privada armazenada no AWS Secrets Manager para estabelecimento do mTLS.
A aplicação transmite o XML assinado, para o BACEN, em um túnel criptografado (mTLS).
Aplicação (AWS Lambda) recebe a resposta do BACEN e, se necessário, valida a assinatura digital do XML recebido.
Aplicação (AWS Lambda) registra o log da requisição enviando diretamente para o Amazon Kinesis Data Firehose.
A mensagem de resposta é enviada para o Amazon API Gateway.
A mensagem de resposta é recepcionada pelo Serviço/Aplicação.
Amazon Kinesis Data Firehose usa o AWS Glue Data Catalog para converter os logs para o formato parquet.
Amazon Kinesis Data Firehose envia os logs, para Amazon S3, já particionado em “pastas” (/ano/mês/dia/hora/).
Amazon Athena usa o AWS Glue Data Catalog como um local central para armazenar e recuperar metadados da tabela.
AWS Glue crawlers atualizam automaticamente as novas partições no repositório de metadados, a cada hora.
Possível consultar imediatamente os dados diretamente no Amazon S3 usando os serviços serverless de análise, como o Amazon Athena (ad hoc com SQL padrão) e Amazon QuickSight.

Custos e TPS

Cada chave mestra do cliente (CMK) que você criar no AWS KMS, custa 1 USD/mês até que seja excluída, independentemente se o material da chave subjacente foi gerado através do serviço, importado de uma fonte externa (BYOK) ou usando um armazenamento de chaves personalizado (Custom Key Store).

O AWS KMS oferece um nível gratuito de 20.000 solicitações/mês, calculadas em todas as regiões nas quais o serviço está disponível. Solicitações para as APIs GenerateDataKeyPair e GenerateDataKeyPairWithoutPlaintext, bem como solicitações para APIs como Sign, Verify, Encrypt, Decrypt e GetPublicKey que fazem referência a CMKs assimétricas estão excluídas do nível gratuito.

Cada solicitação de API para o AWS KMS (fora do nível gratuito) custa, na região América do Sul (São Paulo):

0,03 USD por 10.000 solicitações
0,03 USD por 10.000 solicitações envolvendo chaves RSA 2048
12,00 USD por 10.000 solicitações RSA GenerateDataKeyPair

Quanto aos limites, mais especificamente sobre operações utilizando chaves assimétricas, o AWS KMS possui limites de:

500 requisições/segundo (compartilhado) para CMKs RSA (soft limit).

Caso haja a necessidade, é possível solicitar o aumento para atender a necessidade do seu caso de uso.

No caso do AWS Secrets Manager, tem-se o custo de 0,40 USD por segredo por mês. No caso de segredos armazenados por menos de um mês, o preço é pro-rata (com base no número de horas). Além disso, há o custo de 0,05 USD por 10.000 chamadas de API.

Conclusão

Usando os serviços da AWS, as Instituições Financeiras tem 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.

Os requerimentos de segurança do BACEN (SFN) regulam o sistema bancário brasileiro. Assim, com os serviços da AWS, incluindo o serviço de criptografia AWS KMS, a Instituição Financeira pode melhorar sua capacidade de atender aos principais requisitos de segurança e conformidade, como localidade, proteção e confidencialidade de dados, a fim de suprir os requerimentos para se conectar ao PIX.

A AWS permite que as Instituições Financeiras automatizem tarefas de segurança, de forma que você pode passar a se concentrar na escalabilidade e na inovação de seu negócio. Além disso, as Instituições Financeiras pagam apenas pelos serviços que usam. A arquitetura apresentada não só contempla a parte de segurança para assinatura digital e transmissão (mTLS) de mensagens, mas também contemplam a parte de registro obrigatório de log das requisições.

Artefatos

Para facilitar o entendimento e implantação da nossa solução, nós compartilhamos o código-fonte no repositório aws-samples/pix-proxy-samples no GitHub.

Você pode clonar, alterar, executá-lo, porém ele é fornecido a titulo de exemplo apenas e não deve ser utilizado de forma parcial ou completa na integração definitiva da Instituição Financeira com o BACEN (SPI e DICT).
Todas as informações necessárias para implantação e teste do exemplo encontram-se diretamente no arquivo README do repositório.

Para o desenvolvimento e teste da solução, criamos um Simulador para representar o ambiente do BACEN. Neste Simulador, exigimos a autenticação do cliente (Proxy) para garantir o requerimento de mTLS. Além disso, realizamos a validação da assinatura digital das requisições recebidas, e assinamos digitalmente a resposta a ser enviada ao Proxy.

Em média, as requisições Get Claims obtém um tempo de resposta de 78ms (depende da quantidade de recursos computacionais do container e tamanho da mensagem de resposta), medido a partir do Serviço/Aplicação. Fluxo:

Serviço/Aplicação → Proxy (mTLS) → Simulador (assina resposta) (mTLS) → Proxy (valida assinatura da resposta) (armazena log da requisição) → Serviço/Aplicação.

Em média, as requisições Insert Claim obtém um tempo de resposta de 122ms (depende da quantidade de recursos computacionais do container e tamanho das mensagens de requisição e resposta), medido a partir do Serviço/Aplicação. Fluxo:

Serviço/Aplicação → Proxy (assina a requisição) (mTLS) → Simulador (valida a assinatura da requisição) (assina resposta) (mTLS) → Proxy (valida assinatura da resposta) (armazena log da requisição) → Serviço/Aplicação.

Leitura Adicional

Série AWS PIX 1: Como a AWS pode facilitar a transmissão segura de mensagens ao Sistema de Pagamento Instantâneo (SPI/PIX). (blogpost)
Série AWS PIX 2: Arquitetura com AWS CloudHSM para suportar assinatura digital e transmissão segura de mensagens ao PIX. (blogpost)
Como integrar o AWS KMS com JCE e gerar um CSR (blogpost)
Como homologar serviços AWS para dados altamente confidenciais em Instituições Financeira. (blogpost)
Melhore a prevenção de fraudes em Instituições Financeiras, criando uma solução de detecção de vida. (blogpost)
Digital signing with the new asymmetric keys feature of AWS KMS (blogpost).
Manager your AWS KMS API request rates using Service Quotas and Amazon CloudWatch (blogpost).
How to verify AWS KMS asymmetric key signatures locally with OpenSSL (blogpost).
The importance of encryption and how AWS can help (blogpost).
Post-quantum TLS now supported in AWS KMS (blogpost)
How to use resource-based policies in the AWS Secrets Manager console to securely access secrets across AWS accounts (blogpost).
Tuning the AWS Java SDK 2.x to reduce startup time (blogpost).
Scheduling AWS Lambda Provisioned Concurrency for recurring peak usage (blogpost).
Simplifying serverless best practices with Lambda Powertools (blogpost).

Sobre os autores

Lucas Lins é arquiteto de soluções na AWS, com mais de 10 anos de experiência em arquitetura de software e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica. Atua com ênfase no segmento Enterprise, orientando e suportando os clientes em sua jornada para a nuvem.

João Paulo Aragão Pereira é arquiteto de soluções da AWS, focado no setor de serviços financeiros (LATAM) e seus principais tópicos: prevenção e detecção de fraudes, Open Banking, modernização de sistemas legados, Prova de Vida, Sistemas de Pagamentos Instantâneos. Trabalho com arquiteturas de bancos e seguradoras há mais de 15 anos.

O blog da AWS