Fortalecendo a Segurança do PIX: Como AWS Key Management Service e AWS CloudHSM Atendem aos Novos Requisitos das Resoluções BCB 494-498

Por Eduardo Rodrigues, Principal Solutions Architect na AWS; Guilherme Ricci, Arquiteto de Soluções Sênior, para startups na AWS; Lucas Lins, Gerente de arquitetos de soluções na AWS e Ruy, arquiteto sênior de segurança do setor financeiro para América Latina na AWS.

O Banco Central do Brasil (BACEN) publicou as Resoluções BCB 494-498, em 5 de setembro de 2025, introduzindo requisitos mais rígidos que nas regulamentações anteriores para gestão de chaves criptográficas, uso de certificados ICP-Brasil no padrão dos Sistemas de Pagamentos Brasileiro (SPB) e responsabilidade direta das Instituições de Pagamentos (IPs) ou Instituições Financeiras (IFs) pela assinatura digital das mensagens em seus domínios. Essas medidas surgiram após o BACEN reforçar controles de integridade, autenticidade e rastreabilidade para o PIX. As normativas estabelecem que as IPs devem manter controle exclusivo de suas chaves privadas e implementar procedimentos de segregação entre ambientes de produção e homologação.

O ecossistema de pagamentos instantâneos brasileiro envolve três atores centrais: Banco Central do Brasil (BACEN), Provedores de Serviços de Tecnologia da Informação (PSTI) e Instituições de Pagamento (IPs) ou Financeiras (IF). O BACEN regula o sistema e mantém a infraestrutura central. Os PSTIs operam links e serviços dedicados à Rede do Sistema Financeiro Nacional (RSFN). As IPs enviam e recebem mensagens do PIX utilizando o padrão ISO 20022 por meio desses links. Detalhes operacionais de conexão podem ser encontrados no blog post da AWS Brasil sobre como conectar ambientes na AWS à RSFN.

A AWS oferece serviços gerenciados que ajudam instituições financeiras a cumprir essas exigências. O AWS Key Management Service (KMS) e o AWS CloudHSM permitem criar, armazenar e usar chaves criptográficas em módulos de segurança de hardware (ou HSM – Hardware Security Module), com validação FIPS 140-3 Nível 3, integrando-se a workloads que trafegam pela RSFN. A AWS explora como facilitar a transmissão segura de mensagens ao Sistema de Pagamento Instantâneo (SPI) com exemplos práticos de implementação.

Assinatura de Mensagens entre IF e PSTI

Antes das novas resoluções, muitos PSTIs assinavam as mensagens em nome das IFs, custodiando chaves privadas fora do domínio dessas instituições. Esse modelo elevava o risco operacional e dificultava auditorias.

Com a publicação da Resolução BCB 496, o BACEN tornou a assinatura digital responsabilidade exclusiva da IF. Esse processo deve acontecer em seus domínios, e ser auditável. Cada IF deve manter controle total sobre suas chaves privadas e usar certificados ICP-Brasil SPB válidos.

O PSTI continua garantindo conectividade com a RSFN, TLS mútuo e registros de auditoria, mas não possui mais acesso e nem hospeda as chaves, ou executa o processo de assinatura de mensagens. Esse desenho reforça a separação de responsabilidades exigida pelo BACEN e reduz superfícies de ataque.

AWS Key Management Service e AWS CloudHSM

O portfólio de segurança da AWS oferece duas soluções principais para gerenciamento de chaves criptográficas e assinatura de mensagens: AWS KMS e AWS CloudHSM. Cada serviço atende diferentes requisitos de compliance, performance e controle operacional. O AWS KMS é ideal para cenários que priorizam simplicidade, integração nativa com serviços AWS e custo-benefício. Já o AWS CloudHSM é recomendado quando há necessidade de compliance rigoroso, alto volume de operações criptográficas ou controle total sobre o hardware de segurança.

Entendendo cada serviço

AWS Key Management Service é um serviço totalmente gerenciado que simplifica a criação, rotação e uso de chaves criptográficas. Utiliza HSMs FIPS 140-3 Nível 3 e oferece APIs RESTful que se integram diretamente com serviços AWS. O principal benefício está na facilidade: não requer configuração de infraestrutura HSM, gerenciamento de patches ou procedimentos de backup. Ideal para fintechs, bancos digitais e instituições de médio porte processando até 10.000 transações PIX por dia, permitindo que times de desenvolvimento integrem assinatura digital em poucas semanas, sem necessidade de especialistas em HSM. A integração com Java é detalhada no tutorial sobre como integrar o AWS KMS com JCE e gerar um CSR. Implementações detalhadas com AWS KMS podem ser consultadas no blog sobre AWS KMS para suportar assinatura digital e AWS Secrets Manager para transmissão segura de mensagens ao PIX.

AWS CloudHSM fornece clusters de HSMs dedicados tanto FIPS 140-2 Nível 3 quanto FIPS 140-3 Nível 3, mais atualizado e recomendado, operados exclusivamente pelo cliente dentro de uma Amazon VPC. Diferentemente do AWS KMS, o AWS CloudHSM exige pelo menos dois HSMs por cluster para garantir alta disponibilidade. Oferece versatilidade de integração através de múltiplas APIs padrão da indústria. Suporta PKCS#11 para aplicações C/C++, JCE para sistemas Java, KSP para Windows e OpenSSL para aplicações Linux.

Essa flexibilidade permite migrar sistemas legados sem reescrever código criptográfico, sendo recomendado para bancos, processadores de pagamento e instituições com mais de 50.000 transações por segundo. Além disso, o AWS CloudHSM elimina os problemas de adquirir HSMs físicos: não há depreciação de hardware, manutenção de data center, contratos de suporte ou necessidade de substituir equipamentos ao fim da vida útil.

O modelo de cobrança por hora permite escalar conforme a demanda, algo inviável com HSMs físicos que exigem investimento antecipado elevado. Uma arquitetura completa é apresentada no post Arquitetura com AWS CloudHSM para suportar assinatura digital e transmissão segura de mensagens ao PIX.

A tabela a seguir apresenta um comparativo detalhado entre as duas soluções:

Arquiteturas de Implementação com Segregação de Contas

Dado o prazo de adoção das medidas do BACEN, um movimento que observamos no mercado são alguns PSTIs visando acelerar a adoção e o cumprimento das regras, entregando pacotes de aplicações de integração com KMS ou CloudHSM prontos para que as empresas façam a implantação direto em sua infraestrutura. Esta abordagem remove a complexidade da instituição financeira construir toda integração, com o benefício desse componente da carga de trabalho estar sob seu domínio, cumprindo assim o requisito de não compartilhamento de chaves e realizando a assinatura em seu domínio. Neste modelo, a instituição financeira assume a responsabilidade pelo uso do serviço de gestão de chaves criptográficas em seu ambiente, incluindo a implantação da arquitetura, a criação e gerenciamento das chaves criptográficas, bem como a integração com os serviços fornecidos pelo PSTI. Porém, destacamos que esta não é uma opção obrigatória e que diferentes abordagens e padrões arquiteturais podem ser aplicados. As alternativas incluem desde a produção do XML e assinatura diretamente no ambiente da instituição financeira, até a comunicação com o PSTI para que este devolva o XML e a própria instituição realize a assinatura em seu domínio.

As arquiteturas apresentadas a seguir demonstram duas abordagens para implementação da segurança PIX na AWS, cada uma adequada para diferentes cenários operacionais e requisitos de conformidade. Ambas seguem o princípio fundamental de segregação de contas, separando o ambiente de implantação das aplicações, dos artefatos entregues pela PSTI e o ambiente onde residem os recursos de segurança críticos.

A definição dos componentes que integram a entrega de artefatos e integrações realizadas pelo PSTI é específica de cada fornecedor e na arquitetura sugerida a seguir, será utilizada como base para demonstrar o uso dos serviços de segurança. Considerando essa premissa, a assinatura do XML da transação será realizada diretamente pela instituição financeira, utilizando o PSTI apenas para se comunicar com a infraestrutura de comunicação do PIX (ICOM) através da RSFN.

Arquitetura com AWS KMS

A primeira arquitetura utiliza o AWS KMS como núcleo da solução criptográfica, voltada para empresas que dão preferência a um ambiente com serviços nativos da nuvem e com menor carga operacional de gerenciamento. Nesta implementação, observamos uma separação entre as contas AWS gerenciadas pela instituição financeira e pelo PSTI. Uma delas é a conta que pode receber os artefatos gerados pela PSTI, hospeda as aplicações que podem, entre outras responsabilidades fazer a transformação de uma mensageria no formato JSON, comumente usada entre IF e PSTIs, para XML, padrão esperado pelo BACEN, além da parte responsável pela assinatura digital do XML. Do lado da conta de aplicação da Instituição Financeira, temos os componentes comuns, sendo representados por opções de serviços AWS que se adequam ao contexto, que é a parte da aplicação responsável por capturar a transação. Além disso, também estão representados outros sistemas que comumente compõe a solução de pagamentos instantâneos das IFs.

A conta de segurança, mantida sob controle da instituição financeira, centraliza os recursos criptográficos críticos através do AWS KMS e AWS Secrets Manager. Esta separação garante que mesmo com acesso total ao ambiente de aplicação, o PSTI não pode comprometer diretamente as chaves de assinatura, atendendo plenamente ao requisito de não compartilhamento estabelecido pela Resolução BACEN 496. Isso garante uma flexibilidade caso a IF tenha interesse em trocar o PSTI utilizado, sem dependências nesse quesito.

A comunicação entre as contas ocorre através de políticas de acesso cross-account cuidadosamente configuradas. O AWS KMS permite que contas externas utilizem chaves através de políticas de chaves específicas, enquanto o AWS Secrets Manager oferece mecanismos similares para compartilhamento seguro de certificados e credenciais. Esta configuração permite que as aplicações do PSTI utilizem os recursos criptográficos sem ter acesso direto às chaves, mantendo a propriedade e controle sob domínio da instituição financeira.

Arquitetura com AWS CloudHSM

A segunda arquitetura emprega o AWS CloudHSM para cenários que exigem controle total sobre o ambiente criptográfico e taxa de requisição elevada. Nesta configuração, o CloudHSM cluster reside na conta de segurança da instituição financeira, fornecendo um ambiente de hardware dedicado para operações criptográficas distribuído em múltiplas zonas de disponibilidade para garantir alta disponibilidade.

O CloudHSM oferece integração com bibliotecas padrão da indústria como PKCS#11 e JCE, facilitando a migração de aplicações existentes. A arquitetura mantém o princípio de segregação, com as aplicações na conta de implantação do PSTI acessando o cluster HSM através de conexões seguras e autenticadas via Elastic Network Interface, permitindo comunicação direta entre as VPCs através de VPC Peering, além de ter Security Groups para permitir maior controle de proteção.

Esta abordagem é particularmente adequada para instituições que necessitam de taxa de transferência elevada e têm requisitos específicos de conformidade que demandam um serviço de entrega de hardware dedicado e controle total das chaves, mantendo sempre a propriedade das chaves sob domínio da instituição financeira.

Benefícios da Segregação de Contas

A separação entre contas de implantação e segurança oferece múltiplas vantagens operacionais e de conformidade. Esta arquitetura permite que diferentes fornecedores gerenciem cada ambiente de forma independente, uma flexibilidade particularmente valiosa para PSTIs que atendem múltiplas instituições financeiras, facilitando a padronização de soluções enquanto mantém a individualidade dos recursos de segurança. Esta abordagem está alinhada com as práticas recomendadas pela AWS Security Reference Architecture (AWS SRA), que fornece orientações holísticas para implantação de serviços de segurança em ambientes multi-conta.

Do ponto de vista de segurança, a segregação cria camadas adicionais de proteção, onde o comprometimento de uma conta não resulta automaticamente no acesso aos recursos críticos da outra. Para auditoria e conformidade, esta separação facilita a demonstração de controles adequados e a implementação de políticas de acesso granulares, essenciais para atender aos requisitos regulamentares.

A flexibilidade operacional também se estende à escolha de provedores, permitindo que uma instituição mantenha seus recursos de segurança em uma conta gerenciada internamente enquanto utiliza serviços de terceiros para o deployment e operação das aplicações. Esta abordagem oferece ainda a possibilidade de troca de PSTIs sem impacto nos recursos criptográficos, garantindo continuidade operacional e flexibilidade comercial.

Para aprofundar seu conhecimento sobre estratégias de estruturação e governança de contas AWS em ambientes operacionais distribuídos, consulte o whitepaper oficial da AWS sobre organização de ambientes multi-conta e o blog post sobre critérios de decisão entre contas pequenas e grandes. Estes recursos oferecem diretrizes fundamentadas para determinar a estratégia de contas mais alinhada às necessidades da sua organização.

Padrões arquiteturais e escolhas

É importante destacar que, em ambas as arquiteturas apresentadas, os componentes de rede foram abstraídos para simplificar a visualização e manter o foco no aspecto central: a custódia segura de chaves criptográficas para o PIX.

Entretanto, diversas topologias e padrões arquiteturais podem ser aplicados neste contexto, tais como:

• Hub-and-Spoke: comunicação centralizada através de um ponto concentrador
• Full-Mesh: conectividade direta entre todos os componentes
• Outros padrões conforme necessidades específicas

A AWS oferece múltiplas opções para comunicação entre contas e serviços, incluindo:

• VPC Endpoints
• PrivateLink
• Transit Gateway
• Peering connections

Recomendação: Avalie o contexto específico da sua instituição, considerando requisitos de segurança, conformidade, latência e custos para determinar qual padrão arquitetural melhor atende às suas necessidades operacionais e estratégicas.

Conclusão

As Resoluções BCB 494-498 representam uma evolução necessária na segurança do ecossistema PIX, transferindo a responsabilidade pela assinatura digital exclusivamente para as instituições de pagamento. Essa mudança elimina pontos únicos de falha e fortalece a rastreabilidade das transações, mas também exige que as IFs implementem soluções criptográficas robustas e conformes.

A AWS oferece dois caminhos complementares para atender essas demandas. O AWS KMS simplifica a jornada para instituições que priorizam facilidade de implementação e custos controlados, eliminando a complexidade operacional de gerenciar HSMs enquanto mantém conformidade regulatória. Para organizações com maior volume transacional ou requisitos específicos de controle de hardware, o AWS CloudHSM oferece flexibilidade de integração através de múltiplas APIs padrão da indústria, eliminando os desafios de adquirir e manter HSMs físicos.

Ambos os serviços se integram naturalmente ao ecossistema AWS, permitindo que instituições financeiras construam arquiteturas seguras, escaláveis e compatíveis com as novas exigências do BACEN. A escolha entre eles depende fundamentalmente do perfil de transações, requisitos de compliance e capacidade técnica da organização, mas em ambos os casos, a AWS fornece os blocos fundamentais para uma implementação bem-sucedida e duradoura.

Autores

	Eduardo Rodrigues é Principal Solutions Architect na AWS, liderando estratégias de arquitetura em nuvem para as maiores instituições financeiras do Brasil e impulsionando iniciativas de transformação digital em escala regional. Com foco em excelência técnica e inovação, Eduardo arquiteta soluções de missão crítica para clientes de banking e serviços financeiros de primeira linha, oferecendo orientação estratégica em adoção, modernização e inovação em nuvem. Sua expertise abrange o design de arquiteturas escaláveis, seguras e em conformidade com os rigorosos requisitos do setor financeiro.
	Guilherme Ricci é Arquiteto de Soluções Sênior, para startups na Amazon Web Services, especializado no Setor Financeiro, ajudando startups a modernizar e criar arquiteturas escaláveis resilientes e de baixo custo, além de modernizar suas aplicações. Com mais de 15 anos de experiência em empresas do setor financeiro, atualmente trabalha com a equipe de especialistas em AI.
	Lucas Lins é Gerente de arquitetos 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.
	Ruy é arquiteto sênior de segurança do setor financeiro para América Latina na AWS. Ele trabalha em TI e segurança há mais de 19 anos, ajudando clientes a criar arquiteturas seguras e solucionar desafios de conformidade e proteção de dados. Quando não está arquitetando soluções seguras, ele gosta de tocar guitarra, fazer churrasco e passar tempo com sua família e amigos.