Nesse artigo quero compartilhar uma dica bem valiosa que adotamos na Convenia. Nossa stack é composta de microsserviços, e utilizamos extensamente MongoDB e RabbitMQ, esse último para comunicação entre os serviços, como mostrado neste post.

Toda infra da Convenia roda dentro da AWS, e a AWS não tem uma boa opção gerenciada de MongoDB ou RabbitMQ, então utilizamos o Mongo Atlas e o CloudAmqp para aliviar o trabalho de manutenção nesses serviços.

Problemas

Vamos tomar como exemplo a comunicação entre o serviço gerenciado do Mongo Atlas e a nossa aplicação. Após provisionar tudo da maneira mais simples devemos chegar a essa arquitetura:

Na verdade, isso funciona relativamente bem, portanto a aplicação funcionaria de maneira aceitável, no entanto, parece um caminho longo da nossa aplicação (API) até o banco de dados, o que não é o ideal. O banco de dados deve ficar o mais “perto” possível da nossa aplicação. Na arquitetura acima eu consigo pontuar alguns problemas:

1. Custo

O NAT gateway faz parte de toda arquitetura de rede que inclui uma subnet privada. A grosso modo, ele é responsável por prover acesso à internet aos componentes internos da rede.

O grande problema é que esse NAT é um elemento caro na infraestrutura, pois tem um custo apenas por existir (pois tem IP público) e também cobra um custo relativo ao tráfego que passa por ele.

No nosso caso os dados da nossa aplicação estão passando por ele para chegar ao MongoDB, mas o mesmo não aconteceria se o banco estivesse dentro da mesma subnet da aplicação. Nesse caso, a aplicação conseguiria conversar diretamente com o banco.

2. Performance

Claro, sair pelo internet gateway para internet e passar “sei lá por onde” até chegar ao nosso banco de dados vai introduzir um pouco de latência e, naturalmente, diminuir a resiliência da aplicação. Isso não aconteceria com um banco na mesma subnet da nossa aplicação.

3. Segurança

De todos os pontos, este é o item mais preocupante, principalmente no caso da Convenia que trafega dados pessoais em época de LGPD.

A conexão entre a aplicação e os serviços externos é criptografada. Isso significa que é relativamente segura, pois mesmo se o tráfego for interceptado, os dados não podem ser acessados. Mas, mesmo com a criptografia, é desconcertante ter o tráfego suscetível a um ataque, seria melhor se esses dados nem passassem pelo mundo externo.

Solução

Pensando bem, nosso cluster de MongoDB está provisionado dentro da AWS, nossa aplicação também está dentro da AWS, nossa aplicação realmente precisa fazer toda essa volta para chegar até o banco?

Para o nosso bem, a resposta para essa pergunta é “não”. Quase todos os possíveis serviços que você pode pensar em consumir oferecem uma maneira de garantir que a comunicação com eles permaneça inteiramente dentro da AWS. Sendo assim, a maneira mais comum é o VPC Peering, que tanto o Mongo Atlas quanto o CloudAmqp fornecem.

O Datadog, por exemplo, fornece um endpoint para acesso direto, dessa forma todo o tráfego permanece dentro da rede interna da AWS e nem passa pelo NAT Gateway.

Após criar o VPC Peering do Mongo Atlas, como nesse passo a passo, chegamos à arquitetura acima. Essa arquitetura é muito mais segura, performática e elimina o custo do NAT Gateway. A outra arquitetura nem deveria ser considerada, principalmente se a empresa trabalha com dados sensíveis. Perceba que no diagrama acima nem aparecem os “Internet Gateways”, isso porque a partir de agora a aplicação vai consumir a aplicação diretamente através do Peering.

Com relação aos problemas apontados anteriormente, uma vez que não precisamos mais sair para a internet para chegar até nosso banco de dados, o custo com Tráfego do Nat Gateway deve reduzir, talvez se nossa aplicação não precisar de algum outro recurso interno seria possível até remover o NAT Gateway.

O banco de dados já estava próximo à nossa aplicação, no entanto, nossa aplicação apenas não conseguia chegar até ele da maneira mais fácil. Após fazer o Peering nossa aplicação passa a conhecer o melhor caminho até o banco, ficando a poucos saltos do banco e melhorando a performance e resiliência.

Por último, devemos notar que agora é impossível um elemento desconhecido interceptar o tráfego entre nossa aplicação e o banco, isso diminui muito a superfície de ataque que um suposto Hackerzinho malvado poderia utilizar.

Últimas configurações

Agora já conseguimos atingir 90% dos nossos objetivos, mas para finalizar precisamos impedir que o Mongo Atlas seja acessível externamente. Geralmente esse tipo de serviço gerenciado relacionado à infraestrutura tem uma área de Network como a do Atlas:

A imagem acima contém as regras de acesso da Convenia para o Atlas. Temos dois peerings, logo temos 2 regras de acesso permitindo apenas acessos vindos das 2 VPCs da Convenia. Aqui o ideal é remover qualquer regra permitindo o intervalo 0.0.0.0/0, já que esse intervalo permite acesso global ao cluster.

Conclusão

A utilização de recursos como VPC Peering e VPC Endpoints podem aumentar a performance e melhorar a segurança da sua aplicação, bem como diminuir o custo com tráfego no Nat gateway. Aliás, mantenha distância do Nat gateway, saia para a internet apenas quando for realmente necessário.

 

*Este artigo foi enviado pelo autor ao iMasters e publicado originalmente neste endereço