Pular para o conteúdo
AWS Security8 min de leituraAtualizado em 30 de maio de 2026

Security Groups na AWS: boas práticas para reduzir exposição pública

Portas abertas para a internet são uma das causas mais comuns de incidente em nuvem. Veja como controlar e revisar regras.

Security Groups são firewalls de instância na AWS e definem qual tráfego pode entrar e sair de um recurso. São simples de criar e, justamente por isso, acumulam regras amplas demais. Uma porta administrativa aberta para 0.0.0.0/0 é um convite para varredura e força bruta contínuas, e está entre os achados mais frequentes em qualquer revisão de ambiente.

Este guia mostra como pensar Security Groups com mentalidade de menor exposição: liberar apenas o necessário, evitar faixas abertas em portas sensíveis, cobrir IPv6 e manter as regras sob revisão. O objetivo é diminuir a superfície de ataque sem quebrar a operação.

Entrada, saída e o perigo do 0.0.0.0/0

Regras de entrada controlam quem pode acessar o recurso; regras de saída controlam para onde o recurso pode falar. A maioria das equipes cuida da entrada e ignora a saída, mas restringir a saída limita exfiltração de dados e comunicação com infraestrutura maliciosa a partir de um host comprometido.

Abrir uma porta para 0.0.0.0/0 significa expô-la para toda a internet. Isso é aceitável para portas de serviço público, como 443 atrás de um balanceador, mas é perigoso para portas administrativas como SSH e RDP, bancos de dados e painéis internos. Para acesso administrativo, prefira um bastion controlado, AWS Systems Manager Session Manager ou uma VPN, em vez de expor a porta.

Não esqueça do IPv6. Uma regra pode estar fechada em IPv4 e aberta em ::/0, deixando uma exposição que passa despercebida em revisões focadas apenas em IPv4.

Referência entre grupos e menor exposição

Em vez de liberar faixas de IP entre camadas internas, referencie Security Groups uns nos outros. Por exemplo, permita que o grupo da aplicação acesse o grupo do banco na porta do banco. Isso elimina IPs fixos frágeis e expressa a intenção arquitetural diretamente na regra.

  • Libere apenas as portas realmente necessárias para cada camada
  • Use referência entre grupos para tráfego interno
  • Evite 0.0.0.0/0 e ::/0 em portas administrativas e de banco
  • Restrinja saída quando a carga não precisa falar com a internet inteira
  • Padronize nomes e descrições para que cada regra explique sua finalidade

Revisão contínua e detecção de desvio

Regras tendem a ser adicionadas em momentos de pressa e nunca removidas. Use o AWS Config com regras gerenciadas para detectar portas sensíveis abertas para a internet e para alertar quando um Security Group é alterado. Combine isso com o CloudTrail para saber quem fez a mudança e quando.

Estabeleça uma revisão periódica que questione cada regra ampla: ainda é necessária? Poderia ser mais específica? Regras temporárias criadas para um teste costumam virar permanentes se ninguém as revisitar.

Checklist prático

  • Mapear todas as regras com 0.0.0.0/0 e ::/0
  • Fechar acesso administrativo direto da internet (SSH, RDP)
  • Usar Session Manager, bastion ou VPN para administração
  • Cobrir IPv6 nas revisões, não apenas IPv4
  • Referenciar Security Groups entre si para tráfego interno
  • Restringir regras de saída quando possível
  • Ativar regras do AWS Config para portas sensíveis expostas
  • Alertar mudanças de Security Group via CloudTrail
  • Padronizar descrições explicando a finalidade de cada regra
  • Revisar e remover regras temporárias periodicamente

Boas práticas

  • Adote menor exposição como padrão e abra apenas o necessário
  • Não exponha portas administrativas diretamente à internet
  • Controle a saída para limitar exfiltração de host comprometido
  • Use detecção automática de desvio com AWS Config
  • Documente toda exceção que precise existir
  • Trate regras temporárias com prazo de validade explícito

Erros comuns

  • SSH ou RDP aberto para 0.0.0.0/0

    Varredura e força bruta constantes e um caminho direto de comprometimento.

  • Regra fechada em IPv4 e aberta em IPv6

    Exposição invisível em revisões que olham apenas IPv4.

  • Saída totalmente liberada

    Host comprometido exfiltra dados e fala com infraestrutura maliciosa sem barreira.

  • Faixas de IP fixas entre camadas internas

    Regras frágeis e difíceis de auditar quando a infraestrutura muda.

  • Regras temporárias que nunca são removidas

    A superfície de ataque cresce de forma silenciosa ao longo do tempo.

Quando procurar apoio especializado

Revisar exposição em um ambiente com muitos Security Groups e contas exige cruzar regras, recursos e contexto de rede. A GUARDIASEC faz esse mapeamento no serviço de Segurança AWS, identificando exposições reais e priorizando o que fechar primeiro.

Perguntas frequentes

Qual a diferença entre Security Group e NACL?

O Security Group atua na instância, é com estado (a resposta de uma conexão permitida é liberada automaticamente) e só tem regras de permitir. A NACL atua na sub-rede, é sem estado e tem regras de permitir e negar. Eles trabalham em camadas: a NACL filtra na borda da sub-rede e o Security Group na instância.

É seguro deixar a porta 443 aberta para 0.0.0.0/0?

Para um serviço público atrás de um balanceador, expor 443 à internet é esperado, porque é assim que os usuários chegam. O cuidado é não expor portas administrativas e de banco da mesma forma. O risco não é a porta pública de serviço, e sim portas sensíveis abertas para o mundo.

Como administro instâncias sem expor SSH?

Use o AWS Systems Manager Session Manager, que dá acesso de shell sem abrir porta de entrada, ou um bastion restrito, ou uma VPN. Essas opções evitam expor SSH e RDP diretamente à internet, eliminando o alvo mais visado por varredura e força bruta.

Vale a pena restringir as regras de saída?

Sim, quando a carga não precisa falar com a internet inteira. Restringir a saída limita a exfiltração de dados e a comunicação com servidores de comando a partir de um host comprometido. Em ambientes sensíveis, é um controle de alto valor, embora exija mapear bem os destinos legítimos.

Próximo passo

Vamos avaliar os riscos do seu ambiente?

Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.