O blog da AWS

Como conectar ambientes na AWS a Rede do Sistema Financeiro Nacional (RSFN)

Por Robert Costa e Paulo Aragão, é Arquiteto de Soluções Sênior e um Principal Solutions Architect na AWS

 

 

A indústria financeira brasileira possui uma grande variedade de participantes como bancos comerciais, fundos de investimento, investidores individuais, seguradoras, cooperativas de crédito, fintechs e câmaras, além do próprio Banco Central do Brasil (BCB). Estes participantes interagem entre si criando produtos e serviços, vendendo e comprando ativos financeiros e participando de transações bancárias e de crédito, entre outros fins.
Neste contexto, um dos papeis do BCB é garantir a estabilidade do sistema financeiro nacional. A fim de garantir uma arquitetura de comunicação de dados entre o BCB e as demais instituições financeiras, durante a realização de transações, foi projetada a Rede do Sistema Financeiro Nacional (RSFN). A RSFN foi desenvolvida inicialmente para atender às necessidades do Sistema de Pagamentos Brasileiro (SPB) e se expandiu para outras finalidades, entre elas o Sistema de Pagamentos Instantâneos (SPI/PIX).

A arquitetura da RSFN – Rede do Sistema Financeiro Nacional

A arquitetura da RSFN foi especificada tendo como premissas a alta disponibilidade, desempenho e segurança. Para isso, o Subgrupo de Redes do BCB estabelece critérios rigorosos em suas especificações como descrito no Manual de Redes do SFN. De acordo com o manual, as configurações da RSFN não permitem a comunicação indiscriminada entre participantes sendo, portanto, regulamentada e exigindo a homologação do Subgrupo de Redes.

Atualmente existem 3 maneiras homologadas pelo BCB para que um participante se conecte à RSFN:

  • Conexão Direta através de 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, aos Provedores de Serviço de Telecomunicação da Informação (PSTI) e o BCB.
  • Conexão por meio de um PSTI. É necessário escolher dentre aqueles homologados pelo BCB e celebrar contrato específico. A lista de PSTI homologados e ativos é publica está disponível no site do BCB.
  • Conexão Híbrida. O participante poderá utilizar mais de uma forma de conexão à RSFN.

Maiores informações sobre estas opções disponíveis no Manual de Redes do SFN.O PSTI é uma entidade autorizada a prestar serviços de acesso à RSFN para as instituições financeiras e demais instituições que possuem permissão de acesso concedido pelo BCB. Dentre os serviços prestados estão a resolução de nomes da RSFN, o acesso à fila de mensageria, a assinatura e validação das mensagens, entre outros.

O PSTI deve implementar os mecanismos de segurança adequados aos serviços prestados, como inspeção de tráfego, bloqueio de portas, limitadores de quantidade de conexões, e afins. No Manual de Redes do SFN é possível encontrar todas as obrigações previstas para o PSTI assim como os requerimentos de segurança.

Neste artigo explicaremos como é possível conectar o seu ambiente na nuvem AWS na RSFN. Usaremos duas abordagens, sendo uma delas a conexão através de um PSTI e a outra através da utilização de conectividade com a RSFN já existente e disponível em seu ambiente on-premisse.

Conexão à RSFN por meio de um PSTI

Para as empresas que já utilizam a AWS ou para as empresas que estejam construindo uma nova aplicação com necessidade de acesso a RSFN, o uso de um PSTI que já possua um ponto de presença dentro da AWS facilita e simplifica bastante o processo de implantação.

A comunicação entre o PSTI e seus clientes deve ser feita por meio de um canal seguro, íntegro, confiável e prevendo alta disponibilidade, ou seja, utilizando no mínimo dois acessos redundantes e independentes entre si.

Nesse cenário a comunicação entre o seu ambiente AWS e o do PSTI ocorre usando a própria rede da AWS, utilizando-se de opções de conectividade disponibilizadas pelos PSTI, trazendo maior segurança e performance no acesso.

Figura 1 – Opções de conectividade entre contas AWS do cliente e do PSTI

A seguir detalharemos as opções de conectividade descritas na imagem acima para auxiliar na escolha do melhor método para seu caso de uso.

Opção 1 – Usando o AWS PrivateLink

AWS PrivateLink é o mais recomendado pois é um serviço altamente disponível e escalável que permite que você se conecte de forma privada aos demais serviços da AWS a partir da sua Amazon VPC. Você não precisa configurar acesso através de uma rede pública (Internet Gateway, NAT Gateway, VPN, etc) para se conectar aos serviços do PSTI.

Um exemplo é quando o PSTI fornece seus serviços através de API, gerenciadas pelo Amazon API Gateway. Neste cenário, ao utilizar o PrivateLink você irá se beneficiar da comunicação privada usando o backbone de rede da AWS para acessar a API desejada. Para aumentar a segurança, ainda é possível configurar uma política de acesso e atrelá-la ao PrivateLink restringindo quais serviços podem ser acessados, quem pode acessá-los, e a partir de onde pode vir o acesso.  

Figura 2 – Comunicação com o PSTI através do AWS PrivateLink

De forma bem resumida o que ocorre quando você usa o PrivateLink é que uma ENI (Elastic Network Interface) é criada na sua rede privada, consequentemente utilizando um IP da sua VPC, para que a comunicação ocorra localmente dentro do barramento IP da sua rede privada (VPC). A ENI irá utilizar o roteador da VPC, assim como o DNS da VPC, para que a conexão seja estabelecida usando o backbone da AWS.

Opção 2 – Usando Amazon VPC Peering

Outra opção é utilizar o VPC Peering. Através de um processo simples conseguimos conectar uma VPC à outra, dentro da mesma conta, entre contas distintas, ou até mesmo entre Regiões da AWS, sem a necessidade de nenhum equipamento adicional para essa função como Firewalls ou conexões via VPN.

Além de estabelecer o pareamento entre as VPC (VPC Peering), é necessário configurar a tabela de rotas associada a VPC, ou subnet, que possui essa necessidade. A mesma atividade será efetuada na VPC do PSTI para garantir o retorno do tráfego. Vale ressaltar que o VPC Peering não é transitivo, ou seja, caso queira conectar múltiplas VPC ao ambiente do PSTI será necessário executar o mesmo processo para cada VPC. Mais detalhes e cenários possíveis podem ser encontrados na documentação do Amazon VPC Peering.

É recomendado o uso de Security Group (SG) e Network Access Control List (NACL) para melhorar a segurança do ambiente. O Security Group trabalha com o controle de acesso específico no nível do recurso (ex.: EC2) sendo stateful, ou seja, ele entende e mantêm o estado das conexões sendo necessário somente restringir o acesso do fluxo de entrada. Já o NACL é aplicado no nível de subnet, se fazendo válido para todos os recursos que estejam naquela subnet, e é stateless, ou seja, não mantêm o estado das conexões e você precisa restringir tanto o acesso do fluxo de entrada quanto o de saída.

Figura 3 – Comunicação com o PSTI através do Amazon VPC Peering

Nos casos onde há conflito de endereço de IP, ao se fazer o VPC Peering, é possível utilizarmos um NAT Gateway Privado para garantir que a comunicação com o PSTI sempre utilize um endereço IP fixo da sua VPC.

Opção 3 – Usando o AWS Transit Gateway

O AWS Transit Gateway é um serviço de concentração de conectividade e roteamento de rede que possibilita a criação e operação de topologias de rede hub and spoke, totalmente gerenciado e escalável. Ele permite a conexão de milhares de VPC, conexão com o AWS Direct Connect para criar uma nuvem híbrida entre seu ambiente AWS e datacenter on-premise, conectar VPN, escalar usando o protocolo ECMP (Equal Cost Multi Path) e também conectar com outro Transit Gateway na mesma região ou em outra região da AWS. Uma vez que as conexões foram feitas, basta criar regras de roteamento dentro do Transit Gateway controlando o tráfego de acordo com a necessidade.

Figura 4 – Comunicação com o PSTI através do AWS Transit Gateway

Na arquitetura acima, temos duas possibilidades de uso:

  1. Caso já exista um Transit Gateway criado, é possível interligar este ao Transit Gateway do PSTI. Esse fluxo está representado pela linha azul;
  2. Caso não haja um Transit Gateway criado, é possível anexar a sua VPC diretamente ao Transit Gateway do PSTI. Nessa opção o PSTI precisa dar acesso ao seu Transit Gateway através do AWS Resource Manager para seja possível efetuar o processo de configuração.

Opção 4 – Usando o Amazon Site-to-Site VPN

Utilizar uma VPN Site-to-Site também é uma opção de conectividade ao PSTI. É possível utilizar as soluções de VPN disponíveis no AWS MarketPlace, os serviços de VPN gerenciados pela AWS ou qualquer outra solução que seja instalada dentro de uma Amazon EC2.

Figura 5 – Comunicação com o PSTI através de VPN

Do lado do PSTI, a conexão pode ser finalizada no Transit Gateway facilitando bastante o trabalho de roteamento dentro do ambiente do PSTI, em um serviço gerenciado como o Amazon Site-To-Site VPN, ou em alguma appliance virtual instalado em uma EC2.

Opção 5 – Conexões originadas fora do ambiente AWS

O PSTI também pode receber conexões originadas fora da AWS. Abaixo apresentamos 2 cenários possíveis utilizando conexão através de VPN ou diretamente no API Gateway, passando antes pelo AWS WAF que inspeciona as requisições HTTPS encaminhadas para a aplicação.

Figura 6 – Comunicação com o PSTI com origem externa

Atualmente a Gokei Tecnologia é um PSTI homologado e ativo pelo BCB, e já disponibiliza algumas das opções de conectividade descritas acima para seus clientes.

Acesso à RSFN conectando o ambiente on-premise com a nuvem

Para acessarmos a RSFN através do ambiente on-premise, o primeiro passo é estabelecer uma comunicação privada, segura e escalável entre o seu ambiente na AWS e o seu datacenter on-premisse que já possui a conexão com a RSFN estabelecida. A nuvem AWS fornece diversos serviços de redes para estabelecer esta comunicação híbrida. Pelas características e importância do ambiente em questão a recomendação é o uso do AWS Direct Connect.

O AWS Direct Connect possibilita a criação de conexões de rede privadas entre seu datacenter, escritório ou ambiente de colocation e a AWS. As conexões começam na sua rede e terminam em um dos pontos de presença do Direct Connect ao redor do mundo visando aumentar a segurança, reduzir custos de rede, reduzir latência, e oferecer uma experiência mais consistente do que uma conexão baseada na Internet. O AWS Direct Connect é um serviço totalmente gerenciado com possibilidades de configuração de cenários de resiliência que atendem das necessidades mais simples até as mais complexas.

É muito importante utilizar múltiplos provedores (pontos de presença), cada um conectado a um datacenter encerrando em dois equipamentos (roteadores) em cada datacenter. Usando esse modelo de resiliência evitamos um ponto único de falha, de conexão, e até mesmo dos provedores. Também é recomendado a utilização do protocolo de roteamento dinâmico BGP que, além de garantir rápido chaveamento das rotas em um cenário de falha, também nos permite a customização do caminho de tráfego podendo dar preferência para rotas específicas e criar cenários de ambiente ativo/passivo (usando os parâmetros de AS_PATH e BGP Communities).

Figura 7 – Resiliência da conexão com o ambiente on-premisse

Ainda sobre resiliência, quando se trata de múltiplas conexões o tempo de convergência (tempo de o BGP detectar a falha e alterar a tabela de rotas) é de extrema importância. Para melhorar esse tempo recomendamos a utilização do protocolo BFD que reduz de 90 segundos, tempo padrão, para 900ms. O BFD é uma configuração habilitada por padrão no Direct Connect, sendo necessário apenas a configuração nos equipamentos do datacenter.

É importante verificar qual a largura de banda é necessária para a demanda esperada. Na região da América do Sul (São Paulo), o Direct Connect está disponível nas opções de 1Gbps, 10Gbps e 100Gbps com possibilidade de uso de Link Aggregation Group (LAG) caso seja necessário. Para largura de banda inferior a 1Gbps, é possível a utilização de parceiros que fornecem desde 50Mbps até 1Gbps compartilhados.

Para proteger e controlar a comunicação entre o datacenter on-premise e as VPC conectadas no Direct Connect podemos usar diversas estratégias, cada uma com suas vantagens e desvantagens. A primeira e mais comum é a utilização de um ou múltiplos equipamentos de firewall no datacenter. A principal vantagem dessa abordagem está relacionada a utilização de ferramentas já conhecidas pelos times de Segurança e Redes do Data Center e a possibilidade de utilização de funcionalidades avançadas, como inspeção de pacote. Porém, o custo e a escalabilidade podem não ser adequados dependendo da quantidade de tráfego inspecionada.

Uma segunda abordagem, é utilizar o AWS Network Firewall em um VPC de inspeção. Nesse cenário todo o tráfego de entrada e saída para o datacenter é enviado para a VPC de inspeção, inspecionado, e então enviado ao destino com base nas regras de firewall (statefull), filtros Web e IPS (do inglês, Intrusion Prevention System). Por se tratar de um serviço gerenciado pela AWS a principal vantagem é a escalabilidade que chega a 100Gbps de largura de banda por endpoint, podendo escalar ainda mais através da criação de endpoints adicionais em outras subnets. É recomendada a utilização de endpoints distintos nas diferentes Zonas de Disponibilidade que compõem uma Região da AWS. A utilização do AWS Network Firewall ajuda na redução de custos de um NAT Gateway e adiciona uma camada de proteção e inspeção de tráfego para a internet através de alguns modelos de implementação.

Figura 8 – Inspeção de tráfego utilizando o AWS Network Firewall

A terceira abordagem é limitar o tráfego entre a nuvem e o datacenter utilizando NACL e Security Groups. Ambos são funcionalidades da VPC e não possuem custo. Entretanto, são mais complexas de gerenciar. As NACL precisam ser criadas e controladas em cada Subnet. Os Security Groups precisam ter regras específicas para cada rede do datacenter. O AWS Network Firewall Manager pode simplificar essa operação gerenciando Security Groups em escala, mas a gestão do NACL ainda tem que ser manual.

Recomendações finais

Amazon VPC onde está a sua aplicação deve ser configurada de forma a manter as subnets que hospedam as aplicações totalmente privadas, ou seja, sem nenhum tipo de acesso de entrada proveniente da Internet. Para isso, verifique se as tabelas de rotas associadas à estas VPC não tem um Internet Gateway associado. Caso seja necessário um acesso à internet, utilize um NAT Gateway.

Configure mecanismos de segurança adicionais como Security Groups, Network ACL e Firewalls, ou da AWS ou de parceiros. Para ter uma maior resiliência destes firewalls, use o balanceamento de carga através do Gateway Load Balancer.

Utilize o AWS Config para auxiliar na conformidade do ambiente, alertando sobre desvios de configuração, criando alertas, e remediando de forma automática os problemas.

Siga um framework de segurança de mercado como Center for Internet Security (CIS) 1.2 ou 1.4, National Institute of Standards and Technology (NIST) SP 800-53, ou Payment Card Industry Data Security Standard (PCI DSS), para aderir às melhores práticas de mercado. Use o AWS Security Hub para validar os controles existentes nesses frameworks de forma automática, com um simples clique. A AWS possui um framework chamado AWS Foundational Security Best Practices (FSBP) que fornece controles de acordo as boas praticas de utilização dos serviços da nuvem AWS. Habilite-o através do Security Hub.

Conclusão

Nesse blogpost mostramos possibilidades para conectarmos ambientes criados na AWS com a Rede do Sistema Financeiro Nacional (RSFN) visando atender as mais variadas necessidades do mercado financeiro nacional. Discutimos como o uso do PSTI ajuda a reduzir o custo total, a complexidade, e o trabalho operacional, quando comparado com o modelo de conexão tradicional com a RSFN via datacenter on-premisse.

Discutimos as melhores práticas de rede, que é um dos principais pontos de uma fundação sólida na AWS, assim como a segurança e o modelo de operação. Na ilustração abaixo, demonstramos uma conexão híbrida entre o ambiente AWS e o datacenter on-premisse e apresentamos uma sugestão de arquitetura para sua Landing Zone (LZ).

Figura 9 – Landing Zone

A LZ é um conjunto de boas práticas recomendadas pela AWS para auxiliar no pilar de Operação e Governança, em temas como controle de acesso, segurança, rede, organização e provisionamento de novas contas AWS. Use o AWS Control Tower para implementar a LZ, e verifique que as contas criadas devem refletir a sua necessidade. Estas melhores práticas fazem parte do AWS Well Architected Framework.


Sobre os autores

Robert Costa é Arquiteto de Soluções Sênior que trabalha há mais de 20 anos na área de tecnologia em empresas do setor financeiro. Hoje está dedicado a aprimorar os clientes que buscam inovação pelo uso de serviços na nuvem da AWS. Também adora viajar com a família e amigos para curtir o tempo livre à beira do mar.

 

 

 

 

Paulo Aragão é um Principal Solutions Architect e apoia clientes do setor financeiro a trilhar o novo mundo de DeFi, web3.0, Blockchain, dApps, e Smart Contracts. Além disso, tem ampla experiência em Computação de Alta Performance (HPC) e Machine Learning. Apaixonado por música e mergulho, devora livros, joga World of Warcraft e New World e cozinha para os amigos.