Segurança na AWS: 6 erros que podem quebrar seu negócio

São seis erros de segurança que eu já vi acontecer em contas AWS e que, se você cometer algum deles, podem derrubar o seu negócio. Para cada um você vai ver o cenário em que ele aparece, o que pode acontecer e o que fazer no lugar. As dicas valem para qualquer nuvem, não só para a AWS.

O cenário dos exemplos

Desenhei uma empresa com duas máquinas na mesma rede: a sua e a de outro dev, um stakeholder. Do outro lado, a AWS, com uma instância EC2 e um banco no RDS. Os primeiros erros saem desses dois serviços. São falhas de segurança simples de resolver, mas que viram problema grave quando falta o cuidado.

Erro 1: acesso ao servidor por SSH

O jeito convencional é associar uma chave PEM ao servidor e liberar, no security group, a regra de entrada para o seu IP na porta 22. Vi o pior caso: uma lista de IPs de quem pode acessar, e como a lista mudava toda hora, alguém tirava tudo e liberava 0.0.0.0/0. Isso é pedir para quebrar o negócio.

Liberar só o seu IP público, com /32, é melhor, mas o risco continua. A chave PEM costuma ser compartilhada. Se ela fica num lugar da rede que outras pessoas alcançam, um terceiro que entre na sua rede e pegue a chave também chega ao servidor.

E se esse servidor é um bastion, o jump host que faz a ponte até o RDS, uma pessoa que você não queria chega à sua conta na AWS e entra na sua EC2.

O que fazer no lugar:

• Chave PEM temporária. Se o dev for demitido e ficar com a chave na máquina, ela já não abre mais nada depois que o prazo passa.
• Não usar SSH. O SSM é um mecanismo que não exige regra de entrada.

Erro 2: Access Key e Secret Key dentro do servidor

Você coloca a EC2 na AWS como máquina de ponte para os devs e configura nela a Access Key e a Secret Key. Quem entrar nessa máquina sabe onde procurar: a pasta .aws, no diretório do usuário, com o arquivo das credenciais.

Se as credenciais são permissivas, você acabou de entregar a conta. E ele não precisa ficar na máquina: pega as credenciais, sai e faz todo o processo de fora da AWS. Se você não perceber, o prejuízo está a caminho.

A regra é simples: não use Access Key e Secret Key em nenhum serviço dentro da AWS. Use roles.

Erro 3: role mais permissiva do que o necessário

Com a role, você associa uma permissão à EC2, e ela assume aquele papel. O erro é pôr, por preguiça, uma role de administrador ou uma com full access a algum serviço.

Veja o que acontece quando alguém chega a esse servidor. Primeiro comando:

aws s3 ls

Ele lista todos os buckets. Depois, com aws s3 cp, copia o conteúdo de um bucket para outro destino: a própria máquina ou um bucket em outra conta da AWS. De lá, criptografa e apaga os seus dados e manda um e-mail pedindo resgate.

Duas regras:

• Bastion host: se ele é só a ponte para outros serviços, não dê permissão de role a ele.
• Qualquer serviço: conceda apenas as permissões necessárias. Nunca atache uma permissão sem saber qual é a finalidade.

Erro 4: banco publicamente acessível

Esse eu vi demais. O dev acessa o banco direto da própria máquina e, para isso, vai no RDS e muda "publicamente acessível" para Yes.

É pior que o erro da chave PEM. Quem estiver monitorando a rede vê a sua senha e o endpoint do banco, conecta nele e faz o que quiser. A desculpa costuma ser "eu precisava conectar para testar". Para isso existe túnel: por SSH ou por SSM, há várias formas eficientes e seguras.

A proteção de verdade é colocar o banco em subnets privadas. Se alguém sem saber o que faz marcar "publicamente acessível" com o banco na subnet privada, não surte efeito. Pegue os seus bancos e mova para subnets privadas.

Erro 5: conta sem MFA

Na sua conta AWS, em Security Credentials, você adiciona um dispositivo de autenticação multifator. É básico, e eu já vi cliente perder a conta por não ter MFA habilitado.

O caso: a senha do usuário root era compartilhada entre várias pessoas de confiança. Mesmo assim vazou. Um hacker entrou na conta, fez o que quis, começou a usar a conta e depois chegou o rombo na fatura. Reverter o processo junto à AWS foi uma dor de cabeça enorme que dava para evitar. Bastou habilitar o MFA.

Erro 6: não ter ambiente de homologação

Esse está mais ligado ao negócio do que à AWS, e eu encontrei muito em cliente. Existe só o ambiente de produção. Sai uma nova versão do RDS com um recurso novo que você quer testar no seu projeto, ou você precisa trocar a arquitetura da aplicação do padrão para ARM. Onde testar? Só tem produção.

Você acaba limitado: não usa as tecnologias mais recentes porque tem medo de testar, e se testar em produção corre o risco de parar tudo. Dizer "testei lá porque não tinha outro" não resolve, porque o responsável é você. Se não tem homologação, monte uma.

Custa caro? Se você não souber montar, custa. Se souber, custa o mínimo possível, porque dá para automatizar a parada do ambiente e deixá-lo ligado só quando for necessário.

E ele precisa ser o mais próximo possível da produção: com tecnologia diferente, o teste não é realista e você acaba testando em produção do mesmo jeito. Não se faz teste em produção.

O caminho seguro, juntando tudo

Os erros se somam: SSH aberto leva à máquina, e a máquina que guarda credencial ou role permissiva entrega os seus buckets. Juntando o que cada dica pede (acesso sem regra de entrada, sem Access Key no servidor, role enxuta, banco em subnet privada, MFA na conta), o resultado é este fluxo. É um resumo meu das dicas, não um desenho da aula:

Antes de mexer: o ponto mais importante

Passei seis dicas, mas há uma sétima, e é a mais importante. Se você não tem segurança sobre o impacto de cada mudança (nas credenciais, na role, no banco público, no MFA, no ambiente de homologação), aplicar sem saber pode piorar o problema.

Se você não sabe resolver, muitas vezes é melhor nem mexer.

Segurança, eu diria, é mais importante até do que se preocupar com custo, e é um ponto que muitas vezes se negligencia. É melhor corrigir antes que o problema te alcance.

Checklist

• Nenhum security group com a porta 22 aberta para 0.0.0.0/0.
• Chave PEM fixa trocada por temporária, ou acesso por SSM, que não precisa de regra de entrada.
• Nenhuma Access Key e Secret Key guardadas em servidor na AWS: use roles.
• Nenhuma role de administrador ou full access por preguiça; cada role só com o necessário.
• Bastion host sem role atachada se ele é só ponte.
• Bancos em subnets privadas, sem "publicamente acessível".
• MFA habilitado na conta.
• Ambiente de homologação o mais próximo possível da produção, ligado só quando necessário.
• Se não tem segurança para mudar algo, muitas vezes é melhor nem mexer.

Se você quer ver sua conta com esse checklist na mão e não tem certeza por onde começar, agende uma conversa.