AWS para Iniciantes: Security Groups na prática para liberar somente o necessário

O que é um Security Group (SG) e por que ele é “stateful”

Security Group é o firewall da AWS aplicado no nível da interface de rede da instância (ou de outros recursos, como Load Balancer). Ele controla quais conexões podem entrar (inbound) e quais podem sair (outbound).

O ponto mais importante: Security Group é um firewall stateful. Isso significa que, quando você permite uma conexão de entrada (por exemplo, HTTP na porta 80), a resposta de volta para o cliente é automaticamente permitida, mesmo que você não tenha criado uma regra de saída específica para aquela resposta. O mesmo vale ao contrário: se a instância iniciar uma conexão de saída permitida, o tráfego de retorno é liberado automaticamente.

Na prática, isso reduz a quantidade de regras necessárias e evita configurações confusas típicas de firewalls stateless.

Regras fundamentais de um SG

• Permitir é explícito; o que não está permitido fica bloqueado por padrão (inbound).
• Você não cria regras de “deny” no SG; você só define o que é permitido.
• As regras podem referenciar: CIDR (ex.: 0.0.0.0/0), um IP específico (ex.: 203.0.113.10/32) ou outro SG (muito útil entre camadas).

Inbound vs Outbound: como pensar sem errar

Inbound (entrada)

Define quem pode iniciar conexão com sua instância. Para um site público, normalmente você quer permitir somente:

• HTTP (porta 80) para qualquer IP
• HTTPS (porta 443) para qualquer IP
• SSH (porta 22) apenas para o seu IP (para manutenção)

Outbound (saída)

Define para onde a instância pode iniciar conexões. Por padrão, muitos SGs vêm com outbound “liberar tudo” (0.0.0.0/0). Para iniciantes, isso costuma ser aceitável no começo, mas é importante entender o impacto:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Se um processo malicioso rodar na instância, ele pode tentar se comunicar com a internet.
• Restringir outbound pode aumentar a segurança, mas exige cuidado para não quebrar atualizações do sistema, downloads de pacotes e chamadas a APIs.

Uma abordagem prática e segura para um site simples é: manter outbound liberado inicialmente e, quando estiver confortável, restringir para o mínimo necessário (por exemplo, apenas HTTP/HTTPS de saída para updates e dependências).

Conjunto de regras recomendado (mínimo necessário para um site)

Abaixo um padrão de SG para uma instância que hospeda um site diretamente (sem Load Balancer). Ajuste conforme seu cenário.

Evite regras como “SSH de 0.0.0.0/0” ou liberar portas de banco (ex.: 3306, 5432) para a internet. Se você não usa, não abra.

Sobre IPv6

Se sua VPC/sub-rede estiver usando IPv6, lembre-se de criar regras equivalentes para ::/0 quando fizer sentido. Caso contrário, você pode achar que “fechou tudo”, mas ainda deixou acesso aberto via IPv6 (ou o inverso: o site não abre via IPv6).

Passo a passo: criar e aplicar o Security Group do site

1) Descobrir seu IP público (para restringir o SSH)

Você precisa do seu IP público atual para criar a regra SEU_IP/32. Você pode obtê-lo pesquisando “what is my ip” no navegador ou usando um serviço de IP. O formato final deve ficar assim:

203.0.113.10/32

Dica: se você estiver em rede corporativa/VPN, seu IP pode mudar com frequência. Isso impacta o acesso via SSH.

2) Criar o SG

No console da AWS:

• Vá em EC2 > Security Groups e clique em Create security group.
• Dê um nome claro, por exemplo: sg-web-minimo.
• Selecione a VPC correta (a mesma onde está sua instância).

3) Configurar regras Inbound (entrada)

• Adicione HTTP (TCP 80) com origem 0.0.0.0/0.
• Adicione HTTPS (TCP 443) com origem 0.0.0.0/0.
• Adicione SSH (TCP 22) com origem SEU_IP/32.

Checklist de segurança: confirme que não existe nenhuma regra extra (ex.: RDP 3389, portas aleatórias, “All traffic”).

4) Configurar regras Outbound (saída)

Para começar, mantenha o padrão “All traffic” para 0.0.0.0/0. Se quiser um passo além, uma alternativa comum é permitir apenas:

• TCP 80 para 0.0.0.0/0
• TCP 443 para 0.0.0.0/0

Atenção: restringir outbound pode quebrar atualizações do sistema (que podem usar repositórios em HTTP/HTTPS, mas também dependem de DNS). Se você restringir muito, garanta que DNS esteja funcionando (normalmente via VPC resolver) e que as portas necessárias estejam liberadas.

5) Associar o SG à instância

No console:

• Vá em EC2 > Instances e selecione sua instância.
• Em Security, clique no Security Group e depois em Edit inbound rules (ou edite o SG diretamente).
• Se precisar trocar o SG associado, use Actions > Security > Change security groups e selecione sg-web-minimo.

Boa prática: evite “editar o SG padrão” para tudo. Prefira SGs com propósito claro por aplicação.

Padrão seguro de manutenção: SSH temporário e mudanças rastreáveis

Regra de ouro: SSH só quando precisar

Um padrão simples e seguro para iniciantes:

• Mantenha a regra de SSH removida no dia a dia, se você não precisa acessar.
• Quando precisar, adicione SSH restrito ao seu IP (/32), faça a manutenção e remova novamente.

Como “liberar SSH temporariamente” na prática

• Antes: confirme seu IP atual.
• Adicione a regra SSH (22) para SEU_IP/32.
• Faça a tarefa (deploy, ajuste de config, verificação).
• Remova a regra SSH.

Registrar mudanças (para não se perder)

Mesmo em um laboratório, crie disciplina de registro. Sugestões:

• Use a descrição da regra no SG (ex.: “SSH temporário - manutenção Nginx - 2026-01-25”).
• Mantenha um changelog simples em um arquivo local (ex.: mudancas-sg.md) com data, motivo e o que foi alterado.

Exemplo de registro:

2026-01-25 - Liberei SSH 22 para 203.0.113.10/32 (manutenção). Removi após concluir.

Erros comuns (e como evitar abrir portas desnecessárias)

• “Vou liberar tudo só para testar”: isso vira esquecimento e exposição. Prefira diagnosticar com checklist.
• SSH aberto para 0.0.0.0/0: é um dos erros mais frequentes e perigosos.
• Portas de aplicação abertas sem necessidade: se o site usa só 80/443, não abra 8080, 3000, 5000 etc.
• Confundir SG com NACL: SG é stateful e ligado ao recurso; NACL é stateless e ligado à sub-rede. Aqui o foco é SG.

Laboratório de diagnóstico: “Meu site não abre” (checklist prático)

Objetivo: identificar rapidamente se o problema está no Security Group, na instância ou na rede ao redor.

Passo 1: confirmar o endereço que você está acessando

• Você está usando o Public IPv4 correto da instância?
• Se a instância foi parada e iniciada, o IP público pode ter mudado (se não houver Elastic IP).
• Se você usa DNS, ele aponta para o IP atual?

Passo 2: verificar o estado da instância

• No EC2, confirme que está running.
• Verifique os Status checks: System status checks e Instance status checks devem estar “passed”.

Passo 3: validar o Security Group (o mais comum)

No SG associado à instância, confirme:

• Inbound tem HTTP 80 liberado para 0.0.0.0/0 (e IPv6 se aplicável).
• Se você está testando HTTPS, existe regra de 443 liberada.
• Não há regra conflitante (SG não tem deny, mas você pode simplesmente não ter criado a regra certa).

Teste mental rápido:

• Se o site é HTTP e você só liberou 443, não abre.
• Se você está acessando por HTTPS mas não há serviço/certificado configurado, pode dar erro mesmo com 443 aberto.

Passo 4: checar rotas e acesso público (sem entrar em detalhes de VPC)

Mesmo com SG correto, a instância precisa ter caminho para a internet:

• A instância está em uma sub-rede com acesso público?
• A tabela de rotas associada tem rota para internet (ex.: para Internet Gateway) quando o objetivo é acesso público?

Se isso estiver errado, o SG pode estar perfeito e ainda assim ninguém consegue chegar na instância.

Passo 5: confirmar que o serviço web está rodando e ouvindo na porta certa

Se você consegue acessar via SSH (temporariamente) ou via SSM (se configurado), verifique:

• O servidor web está ativo (ex.: Nginx/Apache)?
• Ele está ouvindo em 0.0.0.0:80 (ou 0.0.0.0:443) e não apenas em 127.0.0.1?

Exemplos de comandos úteis (Linux):

# Ver portas em escuta (varia por distro; tente um dos dois) sudo ss -tulpen | grep -E ':80|:443' sudo netstat -tulpen | grep -E ':80|:443' # Ver status do serviço (exemplos) sudo systemctl status nginx sudo systemctl status httpd

Se o serviço estiver ouvindo apenas em 127.0.0.1:80, ele funciona localmente, mas não responde externamente.

Passo 6: testar de fora e de dentro

• De fora: tente acessar pelo navegador e também testar conectividade (ex.: curl http://IP).
• De dentro (na instância): curl -I http://localhost para confirmar que o servidor responde localmente.

Interpretação rápida:

• Funciona no localhost, mas não fora: geralmente SG, rota pública, ou serviço ouvindo apenas em loopback.
• Não funciona nem no localhost: problema no serviço/configuração do servidor web.

Passo 7: cuidado com o “meu IP mudou” no SSH

Se você não consegue mais acessar via SSH e antes conseguia:

• Seu IP público pode ter mudado. Atualize a regra SEU_IP/32.
• Confirme que você está usando o usuário correto (ex.: ec2-user, ubuntu) e a chave correta.

Modelo pronto: SG mínimo para site (para você copiar como referência)

Use este modelo como padrão mental para qualquer instância web pública:

• Inbound: 80/TCP de 0.0.0.0/0; 443/TCP de 0.0.0.0/0; 22/TCP de SEU_IP/32 (temporário)
• Outbound: All traffic para 0.0.0.0/0 (inicial) ou somente 80/443 (avançando com cautela)
• Sem portas extras “por garantia”
• SSH removido após manutenção
• Mudanças registradas com data e motivo