Segurança na comunicação entre serviços na AWS: 4 níveis

Quem leva a aplicação para a nuvem costuma começar com dois servidores de IP público e o banco liberado por IP, e cada decisão seguinte herda esse erro. Aqui estão os 4 cenários pelos quais a ligação entre aplicação e banco passa na AWS, do pior ao melhor: descubra em qual você está e qual é o próximo passo.

Do localhost para a nuvem: onde o erro começa

Na máquina local, a aplicação web fala com o banco por localhost, e esse acesso é permitido por padrão. Você não precisa pensar em liberação nenhuma.

Na nuvem, o hábito é repetir esse desenho: o banco num servidor, a aplicação web em outro, e a comunicação liberada entre eles. O que muda é que agora existe uma rede no meio. Na AWS ela se chama VPC; no Azure, VNet. Como você usa essa rede define o seu nível de segurança.

Cenário 1: IP público no banco e na aplicação

Os dois servidores têm IP público. No banco, você libera o IP público da aplicação web para ela se comunicar. E, como você também precisa acessar o banco de casa, libera o seu IP público ali também.

O resultado é uma brecha de segurança enorme: o banco, que não deveria ficar acessível publicamente, está exposto. Muita gente chega aqui sem saber, porque só precisava de dois servidores e depois configurou a comunicação entre eles.

Cenário 2: dentro da VPC, com security group e o seu IP público

O segundo passo é colocar os recursos dentro de uma rede. A VPC é a representação da sua rede na AWS, numa região, e as subnets definem em qual zona de disponibilidade cada recurso roda. Na AWS, todo recurso que você lança já fica dentro de uma VPC, queira você ou não. Para ver como a rede se organiza, veja Levar a aplicação para a AWS é seguro?.

Dentro da VPC, você libera o banco para a aplicação pelo security group, não por IP:

1. A aplicação web tem um security group.
2. No banco, você cria uma regra de entrada que libera esse security group, na porta do banco (por exemplo, a do PostgreSQL).

Liberar por IP privado não funciona: se a aplicação morrer e você subir outra máquina, vai acumulando IP na regra, e a aplicação deixa de escalar. Com o security group, toda máquina nova que nascer com o mesmo security group já fala com o banco.

Só que você também precisa acessar o banco de fora. Neste cenário, o que costuma acontecer é deixar o banco público e criar uma regra de entrada para o seu IP.

O problema: numa rede corporativa, as pessoas provavelmente saem pelo mesmo IP, então quem estiver naquela rede também acessa o banco. É um problema gravíssimo, e muita gente só se dá conta dele quando acontece algo mais sério.

Cenário 3: bastion host com SSH

Aqui tudo fica dentro da rede. A aplicação web mantém o IP público, e o banco não precisa mais de IP público. A comunicação entre os dois continua por security group.

Entra o bastion host, que eu chamo de porteiro. Você acessa o bastion com uma chave SSH, pelo IP público dele. Do bastion até o banco, a comunicação é por security group. Com o bastion, você monta um túnel SSH: a porta do banco é redirecionada para a sua máquina, e você acessa o banco localmente.

Este cenário é muito melhor que os anteriores, e o porteiro tem uma vantagem: você controla o horário em que ele fica ligado. Ligue às 8 e desligue às 18, por exemplo, com uma automação em Lambda. Também dá para liberar só a faixa de IP dos seus desenvolvedores, que ainda precisam ter a chave SSH.

Mas ainda dá trabalho:

• Você continua gerenciando o IP público dos devs e do time de infra, para eles chegarem ao porteiro.
• Você precisa compartilhar a chave SSH. Se um dev sai da equipe, ele leva a chave: você vai trocar a chave do bastion toda vez que alguém sair?

O erro de liberar a porta do banco para as máquinas dos devs, e como o bastion resolve, está em Levar a aplicação para a AWS é seguro?. Para montar o cenário na prática, veja Acesso seguro ao RDS com bastion host e túnel SSH; para ligar e desligar o porteiro, Bastion host: 3 estratégias.

Cenário 4: bastion host com SSM e IAM

No quarto nível, o SSH sai de cena. O bastion passa a trabalhar com o SSM, o Session Manager, que é um serviço da AWS. Para ver o Session Manager abrindo uma sessão numa EC2, veja Conectar na EC2 pelo navegador, sem chave PEM e sem abrir SSH.

Para o usuário se comunicar com o bastion:

• você não precisa mais liberar IP público no security group;
• você não precisa mais compartilhar chave SSH;
• a segurança passa a ser no nível do IAM: o usuário acessa com o IAM.

O resto do fluxo continua igual. O banco não tem IP público, e o bastion até pode ter um, mas sem nenhuma regra de entrada.

Resultado: você não gerencia mais o IP público dos seus devs nem a chave SSH. É um nível de excelência em segurança bem maior.

Em qual cenário você deve estar

Minha regra é direta:

• Cenários 1 e 2: não recomendo de forma alguma. Descartados.
• Cenário 3: o mínimo. Se você está nos anteriores, lute para chegar pelo menos nele.
• Cenário 4: o ideal.

Se você está começando na AWS, já conheça os quatro. O problema aparece quando a pessoa lança uma EC2 e um RDS, diz "preciso que o meu cenário funcione lá" e faz as coisas sem saber como estão funcionando.

Checklist

• Descubra em qual dos 4 cenários a sua aplicação está hoje.
• Confira se o seu banco tem IP público e se alguma regra de entrada libera IP.
• Se tiver, tire o IP público do banco e libere só o security group da aplicação, não o IP dela.
• Verifique se a sua rede corporativa sai por um IP único liberado no banco.
• Coloque um bastion host (o porteiro) entre você e o banco.
• Programe o horário de ligar e desligar o bastion.
• Troque o acesso por SSH pelo SSM com IAM, para não compartilhar chave nem gerenciar IP dos devs.

Se o seu banco ainda está num dos dois primeiros cenários, esse é o primeiro ajuste: dentro da VPC, com security group e com o acesso externo passando por um bastion host.