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

Como comentado no nosso blogpost anterior, 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 conformidades necessários para as Instituições Financeiras cumprirem 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 blogpost anterior também.

Esse blogpost (parte 2 de 3) descreve passo a passo, como as Instituições Financeiras podem utilizar o serviço de criptografia AWS CloudHSM, 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 CloudHSM:

Manter dados criptografados em repouso e em trânsito;
Assinar digitalmente as mensagens e estabelecer túnel TLS com autenticação mútua;
Cada HSM suporta 1100 TPS (transações por segundo), sendo que é possível adicionar 28 HSMs no mesmo cluster AWS CloudHSM;
Escalabilidade, disponibilidade e integração nativa com serviços AWS;
Serviço gerenciado AWS para armazenamento e uso seguro de chaves criptográficas, validados em FIPS 140-2 nível 3;
Por ser uma arquitetura sem servidor (serverless), há redução da carga operacional e diminuição de custos de operação relacionada ao gerenciamento e segurança de servidores.

Fluxo de transação entre participantes diretos

O acordo do nível de serviço estabelecido, pelo BACEN, para a experiência do usuário pagador é de 10 segundos de SLA (p99), em relação às transações. Exemplo abaixo do fluxo de transações entre participantes diretos, que pode ser encontrado no seguinte link (pág. 13), com mais detalhes. Vale ressaltar que há 2 tipos de formatos de mensagens: SPI (padrão ISO 20.022) e DICT (não usa padrão ISO 20.022).

Figura 1 – Exemplo de fluxo de transação entre participantes diretos.

Principais serviços AWS utilizados na arquitetura proposta

Aplicação

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, a Instituição Financeira 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).

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 especifica um único armazenamento de dados. Normalmente, você executa um crawler para fazer o inventário dos dados, mas há outras maneiras de adicionar tabelas de metadados ao seu Data Catalog.

Figura 2 – Exemplo de pipeline de ingestão: data lake serverless com AWS Glue e Amazon Kinesis (streaming)

Criptografia e Assinatura Digital

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.

Características do AWS CloudHSM:

Acesso dedicado.
Geração e uso de chaves de criptografia em HSMs validados pelo FIPS 140-2 nível 3.
BYOK (familiaridade com o ciclo de vida das chaves atual do cliente).
Opção configurável para nunca extrair as chaves geradas dentro do HSM.
Alta disponibilidade e durabilidade com configuração mínima.
Preço por hora, conforme o uso, para cada HSM em uso.
É possível ajustar rapidamente a escala da capacidade do HSM ao adicionar e remover HSMs do cluster, sob demanda.
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.
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 apresentada neste blogpost pode ser parte de uma solução mais completa, baseada 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 CloudHSM, AWS Fargate e Elastic Load Balancing (ELB).

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.

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.

Se você tiver uma conta separada de segurança, utilize este procedimento ou este, para compartilhar um cluster do CloudHSM com a outra conta AWS.

Proxy
Segue o diagrama da arquitetura e passo-a-passo do fluxo de transmissão seguro da mensagem para o BACEN e respectiva resposta.

Armazenar login e senha no AWS Secrets Manager, para se comunicar com o AWS CloudHSM.
Criar ou importar a chave privada no AWS CloudHSM.
Armazenar os 3 certificados no AWS Systems Manager Parameter Store: certificado da chave gerada para assinatura, certificado gerado para o mTLS e certificado do CloudHSM (CA do cliente).
O Serviço/Aplicação envia requisição de transação no formato XML.
ELB efetua o balanceamento entre os containers do AWS Fargate.
Aplicação (AWS Fargate) utiliza o AWS CloudHSM para assinatura digital do XML.
Aplicação (AWS Fargate) utiliza o AWS CloudHSM para estabelecimento do mTLS e transmissão do XML para o BACEN.
Aplicação (AWS Fargate) recebe a resposta do BACEN e, se necessário, valida a assinatura digital do XML recebido.
Aplicação (AWS Fargate) registra o log da requisição enviando diretamente para o Amazon Kinesis Data Firehose.
A mensagem de resposta é enviada para o ELB.
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 Desempenho do AWS CloudHSM

Os seguintes itens devem ser considerados para cargas de trabalho de produção, a fim de otimizar o custo:

Alavancar a elasticidade: dimensionar o cluster para up/down conforme a carga de trabalho varia. Mais informações sobre o monitoramento do CloudHSM e desempenho podem ser encontradas aqui.
Maximizar a utilização: compartilhe um cluster de HSMs, raramente usado, entre contas para aumentar a utilização do cluster.
Otimizar o armazenamento de chaves: agrupe chaves, se possível.

Agora, vamos utilizar a calculadora AWS para estimar o custo mensal, na região de São Paulo, para o AWS CloudHSM. Lembrando que não há custos iniciais para usar o AWS CloudHSM, e você paga uma taxa horária por cada HSM iniciado até encerrá-lo. Cada HSM suporta 1100 TPS (assinatura/verificação RSA de 2048 bits):

Preço por hora total por HSM = US 2,72 dólares.

Inicialmente, podemos considerar 1 cluster AWS CloudHSM com 2x HSMs, 1 em cada Zona de Disponibilidade, sendo que é possível instanciar até 28 HSMs por cluster do AWS CloudHSM.

2x 1100 = 2200 TPS para operações com chaves assimétricas.
2 HSMs x 730 horas em 1 mês x US 2,72 = US 3.971,20 dólares/mês.

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 CloudHSM, 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 lhe permite automatizar tarefas de segurança manuais 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

Você pode encontrar muitos exemplos de código e implementação no repositório oficial da AWS (aws-samples).

Para facilitar o entendimento e implantação da nossa solução, compartilhamos o código-fonte.

Todos os recursos de implementação do Proxy com AWS CloudHSM, mencionados neste blogpost estão disponíveis no repositório oficial da AWS (aws-samples-pix). Você pode clonar, alterar, executá-lo, porém não deve ser utilizado como base para construção da integração final 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 README do repositório.

Para o desenvolvimento e teste da solução, desenvolvemos 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 65ms (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 109ms (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.

Recursos futuros

Assim como as Instituições Financeiras, os arquitetos da AWS também tem o DNA de construtor. Por isso, em breve, publicaremos outro blogpost com arquitetura (parte 3 de 3), utilizando outro serviço de criptografia chamado AWS KMS.

Leitura Adicional

Nosso blogpost anterior: Como a AWS pode facilitar a transmissão segura de mensagens ao Sistema de Pagamento Instantâneo (SPI/PIX)
Como executar cargas de trabalho do AWS CloudHSM no AWS Lambda.
Como implantar o CloudHSM para compartilhar suas chaves com segurança com seu provedor SaaS.
Detecção de vida para autorização de pagamentos: no contexto do PIX, o reconhecimento biométrico, incluindo o reconhecimento facial, é permitido como uma opção para autorizar pagamentos e transações, pelo BACEN. Ao adicionar a etapa de detecção de vida, é possível melhorar a mitigação e a prevenção de fraudes.
Fórum de Pagamentos Instantâneos do BACEN.
Como homologar serviços AWS para dados altamente confidenciais em Instituições Financeira.
Assinatura de outros documentos XML, como as Notas Fiscais Eletrônicas (NF-e).

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