# Segurança na AWS: 6 erros que podem quebrar seu negócio > Seis erros de segurança que já vi em contas AWS, do SSH aberto à falta de MFA, e o que fazer no lugar de cada um. - Autor: Henrylle Maia, consultor AWS - Publicado em: 2026-10-15 - Assuntos: Segurança, Banco de dados, Rede - URL: https://pages.formacaoaws.com.br/blog/seguranca-na-aws-6-erros/ - Aula de origem: "6 ERROS DE SEGURANÇA NA AWS QUE PODEM QUEBRAR SEU NEGÓCIO" (https://www.youtube.com/watch?v=zbOBIXgTEh4) 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. ![Você, com o IP 1.2.3.4, acessa a EC2 com a chave PEM; o security group libera só 1.2.3.4/32 na porta 22](https://pages.formacaoaws.com.br/blog/assets/posts/seguranca-na-aws-6-erros/ssh.svg) 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. > **Importante:** porta 22 aberta para todo mundo é o pior caso. Mesmo liberada só para você, existem alternativas mais seguras do que SSH com chave PEM fixa. ## 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: ```bash 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. !["Publicamente acessível = yes" riscado como erro; a correção é manter o RDS em subnets privadas](https://pages.formacaoaws.com.br/blog/assets/posts/seguranca-na-aws-6-erros/rds.svg) 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. ![A página Security credentials do usuário root com MFA (1), um dispositivo Virtual, e Access keys (0) (identificador do MFA borrado)](https://pages.formacaoaws.com.br/blog/assets/posts/seguranca-na-aws-6-erros/mfa.webp) ## 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: **Fluxo:** Você (com MFA na conta) → Túnel SSM (sem regra de entrada na porta 22) → Amazon EC2 (sem Access Key, role enxuta) → Amazon RDS (em subnet privada) ## 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.