Os pagamentos instantâneos são as transferências monetárias eletrônicas na qual o envio da ordem de pagamento e a disponibilidade de fundos para o usuário recebedor ocorre em tempo real. Diferentemente do que ocorre nos sistemas de pagamentos disponíveis no Brasil atualmente, o serviço está disponível 24×7 no ano. No Brasil, o sistema de pagamentos instantâneos se chamará PIX, criado pelo Banco Central do Brasil (BACEN).

Os pagamentos instantâneos podem ser utilizados para transferências entre:

• B2B – estabelecimentos (business to business).
• P2P – pessoas (person to person)
• P2B – pessoas e estabelecimentos (person to business)
• P2G – pessoas e governo (person to government)
• B2G – estabelecimento e governo (business to government)
• G2P – governo e pessoas (government to person)
• G2B – governo e estabelecimentos (government to business)

A Resolução nº 4.658, de 26 de abril de 2018, regulamentada pelo BACEN, estabelece requisitos de segurança cibernética para Instituições Financeiras brasileiras regulamentadas, e inclui requisitos para o uso de serviços de computação em nuvem. Essa resolução exige que as instituições financeiras regulamentadas adotem uma política que aborde uma ampla variedade de questões de segurança cibernética, incluindo o uso de provedores de serviços para processamento de dados, armazenamento de dados e computação em nuvem. Assim, por meio de inovação contínua, a AWS fornece esses requisitos de segurança mais rigorosos do mundo, a maior abrangência e profundidade de serviços, profundo conhecimento do setor financeiro e uma ampla rede de parceiros.

De fato, as Instituições Financeiras brasileiras como bancos, corretoras de investimentos, seguradoras, estão autorizadas a usar serviços em nuvem, desde que cumpram com os requisitos legais e regulamentares aplicáveis. O BACEN é a principal autoridade monetária e reguladora do setor bancário, e as Instituições Financeiras brasileiras podem estar sujeitas a vários requisitos legais e regulamentares diferentes quando usam serviços em nuvem. Para facilitar o entendimento deste panorama regulatório, a AWS oferece o AWS Compliance Center, um local central para pesquisar requisitos regulatórios relacionados à nuvem e como eles afetam seu setor, por exemplo das Instituições Financeiras brasileiras.

Mais especificamente, a Circular nº 3.985, de 18 de Fevereiro de 2020 estabelece as disposições relacionadas às modalidades e aos critérios de participação no arranjo de pagamentos instantâneos e no SPI/PIX e aos critérios de acesso direto ao Diretório de Identificadores de Contas Transacionais (DICT). A AWS provê as certificações e padrões de conformidades necessários para as Instituições Financeiras brasileiras cumprirem os requerimentos do novo Sistema de Pagamentos Instantâneos (SPI), conectado ao Sistema de Pagamento Brasileiro (SPB), requer os mesmos altos níveis de segurança como criptografia e assinatura digital de mensagens no formato XML.

Um ponto importante a ser comentado é que quando as Instituições Financeiras migram para ou utilizam serviços da Nuvem AWS, a AWS é responsável pela proteção da infraestrutura subjacente que oferece suporte à nuvem, e as Instituições Financeiras são responsáveis por tudo aquilo que implantam na nuvem ou conectam à nuvem (Modelo de Responsabilidade Compartilhada).

Figura 1 – Modelo de Responsabilidade Compartilhada

Esse blogpost descreve passo a passo, como as Instituições Financeiras brasileiras ao se conectarem no SPI podem cumprir com as diretrizes de segurança do BACEN.

Vantagens para as Instituições Financeiras com os serviços AWS

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

1. suprir os requerimentos de segurança do Sistema Financeiro Nacional (SFN) e consequentemente do BACEN.
2. manter dados criptografados em repouso e em trânsito.
3. assinar digitalmente as mensagens.
4. estabelecer túnel TLS com mútua autenticação.
5. velocidade e desempenho desejado nas transações (TPS – transações por segundo) e transferências de mensagens.
6. escalabilidade.
7. disponibilidade.
8. integração nativa com outros serviços AWS.
9. serviços gerenciados AWS para armazenamento e uso seguro de chaves criptográficas, validados pelo FIPS 140-2: AWS Key Management Service (KMS) (FIPS 140-2 nível 2) e AWS CloudHSM (FIPS 140-2 nível 3).

Rede do Sistema Financeiro Nacional (RSFN)

A RSFN é uma estrutura de comunicação de dados que tem por finalidade amparar o tráfego de informações no âmbito do SFN para serviços autorizados. A arquitetura da RSFN foi especificada tendo como premissas alta disponibilidade, desempenho e segurança. A RSFN tem como objetivo principal suportar o tráfego de dados diretamente relacionados a serviços críticos, podendo, sem interferir no seu objetivo principal, suportar o tráfego de dados de outra natureza.

As operadoras de serviço de comunicação da RSFN são as empresas que proveem a infraestrutura de conectividade de rede para os participantes diretamente conectados à RSFN, os PSTI (Provedores de Serviços de Tecnologia da Informação) e o BACEN.

Sistema de Pagamentos Instantâneos (SPI)

O ecossistema de pagamentos instantâneos brasileiro será formado pelo arranjo aberto instituído pelo BACEN (PIX), pelos prestadores de serviços de pagamento participantes do arranjo (instituições financeiras e instituições de pagamento), pela plataforma única que fará a liquidação das transações realizadas entre diferentes instituições participantes no Brasil (SPI) e pelo diretório de identificadores de contas transacionais que armazenará as informações das chaves ou apelidos que servem para identificar as contas dos usuários recebedores (DICT).

Figura 2 – Exemplo de conexão de uma Instituição Financeira com o SPI (PIX do BACEN)

Especificações técnicas de segurança do PIX

Os requisitos de segurança são implementados para garantir a integridade, a confidencialidade e a disponibilidade das informações trafegadas. A estrutura de segurança definida compreende todos os mecanismos de proteção necessários para fortalecer os sistemas de defesa contra ações indesejáveis, seguindo o Manual de Segurança da SFN. São divididos em obrigatórios e recomendados.

• Todas as mensagens enviadas à RSFN serão obrigatoriamente autenticadas por meio de criptograma (assinadas digitalmente) pela Instituição Financeira participante emissora (necessário chaves assimétricas).
• Todas as mensagens enviadas à RSFN serão obrigatoriamente criptografadas.
• Obrigatoriamente, as Instituições Financeiras brasileiras são responsáveis pela segurança física e lógica de acesso a sua chave privada.
• Recomendado que a Instituição Financeira armazene a chave privada num dispositivo especializado para o gerenciamento de chaves criptográficas, visando diminuir a exposição do sistema a falhas e outros tipos de vulnerabilidades do ambiente.
• A Instituição Financeira deve se conectar às APIs disponíveis no PIX exclusivamente por meio do protocolo HTTP versão 1.1 utilizando criptografia TLS versão 1.2 ou superior, com autenticação mútua obrigatória no estabelecimento da conexão.

Há outras diretrizes que são recomendadas e/ou obrigatórias, pelo BACEN, por exemplo, disponibilidade, redundância, backup, recuperação do ambiente. A AWS pode apoiar as Instituições Financeiras para suportar essas diretrizes, afim de executar cargas de trabalho críticas, programas, soluções e serviços.

O PIX tem pelo menos três requerimentos que podem ser suportados por serviços e pelas características da nuvem AWS:

1. Segurança: criptografia e gerenciamento de chaves (AWS CloudHSM e AWS KMS)[mais detalhes abaixo]

2. Velocidade (TPS relacionados com AWS CloudHSM e AWS KMS, além de escalabilidade de outros serviços: Amazon ECS, Amazon EKS, AWS Fargate, Elastic Load Balancing, AWS Lambda, Amazon SNS, Amazon SQS, Amazon API Gateway, etc.). Cada Instituição Financeira tem sua quantidade customizada de TPS.

a. AWS KMS – 500 TPS default para cifrar/decifrar dados usando chaves assimétricas, mas é possível solicitar um aumento de cota para o serviço AWS KMS.

b. AWS CloudHSM – 1100 operações por HSM. É possível instanciar até 28 HSMs por cluster do CloudHSM.

3. Alta Disponibilidade (Regiões e Zonas de Disponibilidade). A AWS oferece múltiplas zonas de disponibilidade independentes em uma região geográfica para implementação de redundância de componentes da aplicação.

Segurança e Criptografia

Para as Instituições Financeiras brasileiras que armazenam dados nos serviços de armazenamento da AWS ou trafegam seus dados por nossas redes, exige-se fortemente a criptografia de dados em repouso e em trânsito. Os recursos de criptografia e controle de acesso a dados são incorporados às ofertas de serviços nativos. Esses recursos são turn-key e fornecem documentação para ajudar as Instituições Financeiras a entender como seus dados são protegidos e as opções de configuração que os clientes tem para personalizar as permissões de acesso aos sistemas e às chaves necessárias para descriptografar os dados.

A confidencialidade da informação cifrada depende de quem tem acesso aos dados e as chaves criptográficas. Se os dados são cifrados pela Instituição Financeira antes do envio à nuvem, os sistemas na AWS não poderão acessá-los sem conhecimento prévio das chaves de criptografia, e o cliente tem total controle e responsabilidade sobre elas. Por outro lado, se é crítico para o correto funcionamento de um serviço em nuvem o acesso aos dados decifrados, as chaves criptográficas precisam ser compartilhadas com estes serviços. As Instituições Financeiras brasileiras precisam de garantia de que apenas os sistemas autorizados na AWS tenham capacidade de decifrar os dados quando elas assim especificarem. Com a criptografia, a confidencialidade das chaves criptográficas é crucial.

Chaves assimétricas e assinatura digital

Em criptografia e na infraestrutura de chaves públicas (PKI), as assinaturas digitais são usadas para confirmar que os dados foram enviados por uma entidade confiável. As assinaturas também indicam que os dados não foram alterados em trânsito. Uma assinatura digital é composta por um hash (operação criptográfica similar a um resumo) das informações protegidas, criptografado com a chave privada do remetente. O destinatário pode verificar a integridade dos dados decifrando a assinatura com a chave pública do remetente e comparando-a com um hash produzido a partir do conteúdo recebido. O remetente é também responsável por emitir e fornecer um certificado digital. O certificado digital é um atestado emitido por um ente confiado por ambas as partes de que um par de chaves são de propriedade do remetente assim como inclui a chave pública necessária para decifrar dados. Desde que a chave privada esteja sob o controle exclusivo do remetente, a assinatura será confiável.

Como todas as mensagens enviadas à RSFN devem ser obrigatoriamente autenticadas por meio de criptograma (assinadas digitalmente), torna-se necessário a geração e uso de chaves assimétricas (um par de chaves pública e privada relacionadas matematicamente).

Qualquer pessoa com posse da chave pública pode usá-la para verificar se a mensagem foi assinada com a chave privada e se ela não foi alterada em relação ao conteúdo original. A figura 3 mostra o que ocorre, no AWS KMS e AWS CloudHSM, no processo de uso da chave privada na assinatura de uma mensagem.

Figura 3 – Como usar a chave privada para assinar uma mensagem.

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.

No nosso caso, pode ser delegado também para o AWS KMS e o AWS CloudHSM a tarefa de estabelecer o túnel mTLS com BACEN, via RSFN. Verifique que na figura 4, 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 4 – Cliente autenticado pelo lado servidor no TLS handshake.

Mensagens DICT e SPI

No contexto do Sistema de Pagamento Instantâneo, é importante destacar que cada mensagem tem um padrão diferente para SPI e DICT. O padrão de assinatura digital a ser utilizado no PIX é o XMLDSig. No SPI, as mensagens seguem o padrão ISO 20.022, portanto a assinatura digital deve constar no elemento do Business Application Header (BAH), conforme descrito no Catálogo de Mensagens do SPI. No DICT, por sua vez, as requisições e respostas não são realizadas por meio de mensagens ISO 20.022, então o cabeçalho (BAH) não existe. Nesse caso, o elemento contendo a assinatura deve constar na raiz do XML.

No SPI, as informações a serem assinadas são:

• Mensagem ISO 20.022 (elemento <Document>).
• Cabeçalho – BAH (elemento <AppHdr>).
• Elemento <KeyInfo>.
• A tag <Reference>, sem o atributo URI, deve ser interpretada pela aplicação de forma a referenciar a mensagem ISO 20.022 propriamente dita (elemento <Document>).

No DICT, é necessário assinar o conteúdo do elemento raiz do XML e do <KeyInfo>, o que resulta na utilização de apenas 2 tags <Reference>. Ressalta-se que, no caso do DICT, a tag <Reference URI =””> aponta para a raiz do XML, diferentemente do que ocorre no SPI.

Nesse caso, podemos usar tanto o AWS KMS quanto o AWS CloudHSM para assinatura digital de ambas as mensagens: SPI e DICT, antes de enviar para o SPI/PIX (BACEN).

AWS Key Management Service (KMS)

O AWS Key Management Service (KMS) é um serviço de escopo regional totalmente gerenciado e altamente disponível. O AWS KMS permite que você crie e controle as chaves de criptografia usadas pelos aplicativos e serviços da AWS compatíveis em várias regiões em todo o mundo usando um único console.

Os módulos de segurança de hardware multi-locatário (HSMs) usados no armazenamento de chaves KMS padrão são validados por um laboratório de terceiros sob o padrão FIPS 140-2 no nível 2, e com nível 3 em várias categorias.

O AWS KMS pode lidar com milhares de solicitações de API por segundo dos aplicativos de Instituições Financeiras para atender, de maneira personalizada, às necessidades de dimensionamento. Fornece a capacidade de executar gerenciamento de chaves e funções criptográficas de uma maneira profundamente integrada a outros serviços da AWS.

O gerenciamento centralizado de todas as suas chaves no AWS KMS permite que você decida quem pode usá-las, em que condições elas são usadas, quando elas são rotacionadas e quem pode gerenciá-las. A integração do AWS KMS com o AWS CloudTrail oferece a capacidade de auditar o uso das chaves para apoiar suas atividades regulatórias e de conformidade. Você pode interagir com o AWS KMS nas aplicações usando o AWS SDK para chamar diretamente as APIs de serviço, via outros serviços da AWS integrados ao AWS KMS, ou usando o AWS Encryption SDK se quiser realizar criptografia do lado do cliente.

O AWS KMS foi projetado para que ninguém, incluindo os funcionários da AWS, possa recuperar chaves de clientes descriptogravadas e usá-las fora do serviço. O AWS KMS também permite que você execute operações de assinatura digital usando pares de chaves assimétricas para garantir integridade de dados.

Vantagens do AWS KMS

• 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, integrado ao AWS Encryption SDK.
• 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.
• Menor custo, quando comparado com o AWS CloudHSM.
• Serviço gerenciado.

AWS CloudHSM

As Instituições Financeiras brasileiras também podem usar outro serviço, o AWS CloudHSM, que disponibiliza um cluster de HSMs dedicados FIPS 140-2 Nível 3 (geral) sob controle exclusivo da Instituição Financeira, diretamente no Amazon Virtual Private Cloud (VPC), para armazenar e usar suas chaves. Este serviço permite usar de modo fácil os HSMs com aplicativos que rodam em instâncias Amazon EC2 e/ou Containers. Com o 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 JCE, Microsoft CNG ou OpenSSL, e fornece disponibilidade, replicação e backup automatizados dos HSMs dedicados ao cliente nas zonas de disponibilidade.

Vantagens 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 de nunca extrair a chave.
• Integração com o uso de bibliotecas como Microsoft CryptoNG (CNG), PKCS#11, Java Cryptography Extensions (JCE) e OpenSSL.
• É 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 AWS CloudWatch para registro de ações de gerenciamento de usuários e chaves.
• Serviço gerenciado.

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 de 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 você pode melhorar sua capacidade de atender aos principais requisitos de segurança e conformidade, como localidade, proteção e confidencialidade de dados por meio de nossos abrangentes serviços e recursos, afim de suprir os requerimentos para se conectar ao SPI/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. Todos os nossos clientes se beneficiam pela AWS ser a única nuvem comercial que possui ofertas de serviços e cadeias de suprimentos associadas verificadas e aceitas como seguras o bastante para as cargas de trabalho mais sensíveis.

Recursos

Assim como as Instituições Financeiras brasileiras, os arquitetos da AWS também tem o DNA de construtor. Por isso, publicamos outros blog posts com arquiteturas escaláveis, utilizando os modos síncrono e assíncrono, com os serviços AWS KMS e AWS CloudHSM. Também é possível encontrar as respectivas aplicações de exemplo e respectivos templates do Amazon CloudFormation no repositório GitHub oficial da AWS (aws-samples).

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. Trabalho com arquitetura em bancos e seguradoras há mais de 15 anos.

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.

Se você tem perguntas sobre a AWS ou algum projeto que queira discutir, preencha este formulário e um representante entrará em contato com você.