Levar a aplicação para a AWS é seguro? Como proteger o banco

Levar a aplicação para a AWS é seguro quando só a aplicação web fica exposta e o banco aceita apenas a aplicação. O erro que desfaz isso é liberar a porta do banco para as máquinas dos devs, e dá para evitar com VPC, Security Group e bastion host.

"Minha aplicação e meu banco vão estar seguros na nuvem?" foi uma das respostas que mais apareceram quando perguntei, nas pesquisas dos meus eventos, o que impede as pessoas de começar com a AWS. Uso um cenário simples: aplicação web e banco de dados.

O ponto de partida: o que você já faz no on-premise

Imagine a sua estrutura local com uma aplicação web e um banco. Pela configuração de rede, dá para deixar só a parte web acessível para o usuário. A aplicação conversa com o banco, e o banco não fica acessível da internet: não há como falar com ele direto.

Na mesma rede, porém, estão as máquinas dos devs. Elas têm acesso à internet e, dependendo da configuração, ao banco. Sem pipeline nem automação de deploy, é normal o dev se conectar nele para rodar uma migration ou uma atualização.

Esse é o cenário de quem está pensando em migrar. A pergunta é como isso fica na AWS.

Como a AWS organiza a rede

Em cada região da AWS você tem zonas de disponibilidade: conjuntos de servidores isolados por energia, com distância mínima de 15 km entre eles. No desenho da aula usei a região da Virgínia com duas zonas, AZ1 e AZ2.

Em cada região você ganha uma VPC, a rede que você tem na nuvem naquela região. Por padrão, essa rede está acessível para a internet, e cada recurso você pode fechar ou não. Dois itens bastam para quem está começando: o Internet Gateway e o Security Group.

1Deixe só a aplicação web aberta

Para a máquina da aplicação web ser acessível, a VPC precisa do Internet Gateway, mas só ele não basta. Você também associa à máquina um Security Group.

1. Confirme que a VPC tem o Internet Gateway.
2. No Security Group da aplicação web, libere as portas 80 e 443 para o mundo.

Com isso o usuário consegue acessar a aplicação.

2Deixe o banco falar só com a aplicação

Coloque o banco, por exemplo, na outra zona (AZ2), com o seu próprio Security Group. Do mesmo jeito que você faz localmente, libere a comunicação da aplicação web com o banco: o Security Group do banco aceita o Security Group da aplicação na porta do banco, que no exemplo é a 5432.

Até aqui está certo. O erro vem do próximo pedido.

O erro que transporta o problema para a nuvem

Os devs precisam rodar uma migration ou uma manutenção no banco, e você ainda não tem pipeline de CI/CD. O que muita gente faz: vai no Security Group do banco e libera a 5432 também para o dev 1 e o dev 2.

Quando você faz isso, abre uma brecha enorme. Uma máquina sobre a qual você não tem controle passa a poder falar com o seu banco, e ela só precisa de endpoint, usuário e senha. Se essa máquina guarda as credenciais, quem estiver monitorando ou interceptando a rede consegue pegá-las e se conectar.

Esse problema também existe no on-premise. Se você fizer assim, só transportou para a nuvem um problema que já tinha. Nos dois casos é inseguro, e é essa configuração que responde "não" à pergunta do título.

3Tire o banco da internet e use um bastion host

O banco não precisa de acesso à internet: só a aplicação web precisa chegar nele. Com acesso à internet, ele permite justamente a configuração do erro acima, que é um desastre para o negócio.

E os devs, que continuam precisando do banco? Entra o bastion host: o dev não fala direto com o banco, e o bastion host faz a ponte. Você constrói um túnel SSH, e ele encaminha o tráfego do banco para a máquina do dev.

Quem não tem a chave do cofre não se comunica com o banco, e a chave do cofre não é o login nem a senha. Assim você controla todo o acesso.

Dá ainda para ligar o bastion host só na janela de trabalho dos devs. Se eles trabalham das 8h às 18h, uma automação com Lambda deixa o bastion host ligado só nesse horário. Fora dele, ele está desligado, e ninguém fala com o banco, exceto a aplicação. Para montar o bastion host e o túnel, veja Acesso seguro ao RDS: bastion host e túnel SSH e, para o horário, Ligar e desligar EC2 automaticamente.

O que entender antes de migrar

Para saber se é seguro, entenda VPC, Security Group e Internet Gateway. Existem outros itens ligados a eles, como subnet pública e privada, que eu não explorei na aula. Com esse conhecimento, você entende a comunicação e sabe que dá para colocar uma aplicação na internet de forma segura.

Este texto cobre o raciocínio de rede. Outros erros que causam acidente em conta AWS, como SSH aberto, Access Key no servidor e conta sem MFA, estão em Segurança na AWS: 6 erros que podem quebrar seu negócio.

Checklist

• A VPC tem o Internet Gateway e a aplicação web tem um Security Group com as portas 80 e 443.
• O banco tem o seu Security Group, que aceita só o Security Group da aplicação na porta do banco.
• Nenhuma regra libera a porta do banco para a máquina de dev.
• O banco não tem acesso à internet.
• O acesso dos devs ao banco passa por um bastion host, com túnel SSH.
• O bastion host fica ligado só no horário em que os devs trabalham.

Se você quer ver a sua aplicação indo para a AWS com esse desenho e não sabe por onde começar, agende uma conversa.