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.
IPv6 e o par oculto de regras
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. Cada regra de entrada tem, na prática, duas faces: a faixa IPv4 e a faixa IPv6. Fechar uma e esquecer a outra é comum quando a sub-rede ganha um bloco IPv6 depois que as regras já existiam. Ao revisar, trate ::/0 com o mesmo rigor que 0.0.0.0/0.
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
Prefix lists gerenciadas e Security Groups em escala
Quando várias regras repetem a mesma faixa de IP, como os blocos de uma VPN corporativa ou de um provedor de saída, mantê-las sincronizadas na mão é fonte de erro. Uma prefix list gerenciada nomeia esse conjunto de CIDRs uma vez e é referenciada em quantos Security Groups for preciso. Ao mudar a faixa, você atualiza a lista em um só lugar e todas as regras acompanham, o que evita a situação de fechar um acesso em um grupo e esquecer o mesmo acesso em outro.
Em ambientes que crescem sem padrão, os Security Groups se multiplicam e surgem grupos quase idênticos com pequenas diferenças. Essa proliferação dificulta a auditoria: a mesma regra ampla aparece em vários lugares e ninguém tem certeza de qual está em uso. Consolide grupos redundantes, defina um conjunto base por camada de aplicação e acompanhe os limites da conta, já que há um teto de regras por Security Group e de grupos associados a cada interface de rede.
- Centralize faixas reutilizadas em prefix lists gerenciadas
- Consolide Security Groups redundantes e quase duplicados
- Defina um conjunto base de grupos por camada, reutilizado entre cargas
- Acompanhe os limites de regras por grupo e de grupos por interface
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.
Encontrar exposição de forma programática
Uma varredura periódica encontra o que a revisão manual deixa passar. A CLI da AWS lista os grupos que têm alguma regra de entrada aberta para a internet, um ponto de partida para decidir o que fechar. Cruze o resultado com o inventário de recursos para separar a exposição legítima de serviço público do que ficou aberto por descuido, e repita a varredura em todas as regiões, não apenas nas que você usa de propósito.
aws ec2 describe-security-groups \
--filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
--query "SecurityGroups[].{ID:GroupId,Nome:GroupName}"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
- Usar prefix lists gerenciadas para faixas de IP reutilizadas
- Consolidar Security Groups redundantes e acompanhar os limites por grupo e por interface
- Varrer periodicamente regras abertas para 0.0.0.0/0 e ::/0 em todas as regiões
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
- Centralize faixas comuns em prefix lists para evitar regras divergentes
- Padronize um conjunto base de Security Groups por camada de aplicação
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.
Security Groups redundantes e quase duplicados
Dificultam a auditoria e fazem a mesma regra ampla se repetir sem controle.
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.
O que são prefix lists gerenciadas e quando usar?
Uma prefix list gerenciada é um conjunto nomeado de faixas de IP que você referencia dentro das regras de Security Group. Em vez de repetir os mesmos CIDRs em vários grupos, você mantém a lista em um lugar só e atualiza uma vez. Vale usar quando a mesma faixa aparece em muitas regras, como blocos de VPN corporativa ou de provedores de saída, porque reduz o risco de fechar um acesso em um grupo e esquecer o equivalente em outro.
Existe um limite de regras por Security Group?
Sim. A AWS define cotas para o número de regras por Security Group e para quantos grupos podem ser associados a cada interface de rede. Algumas cotas podem ser ajustadas mediante solicitação, mas o sinal de alerta costuma ser outro: se você está esbarrando nos limites, provavelmente há regras amplas demais ou grupos redundantes que valem uma consolidação antes de pedir aumento.
Security Group protege contra ataques de negação de serviço?
Não é o papel dele. O Security Group filtra por origem, porta e protocolo, mas não mede volume nem distingue um pico legítimo de um ataque volumétrico. Proteção contra negação de serviço vem de outras camadas, como o AWS Shield e o filtro de aplicação na borda. O Security Group contribui reduzindo a superfície exposta, o que já diminui o que pode ser alvo.
Guias relacionados
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.