Security Groups e Network ACLs (NACLs) são os dois mecanismos nativos de controle de tráfego dentro de uma VPC — mas operam em camadas diferentes, com modelos de avaliação de regras completamente distintos. Entender stateful vs stateless é o ponto central do tema, e é também a causa mais comum de "por que meu tráfego não está passando, mesmo com tudo parecendo configurado corretamente".

🎯 Para a certificação

Questões sobre este tema testam se você sabe que Security Groups são stateful e aplicados a nível de instância/ENI, enquanto NACLs são stateless e aplicados a nível de subnet, se entende como isso muda o que precisa ser configurado para tráfego de resposta, sabe como a ordem numérica das regras de NACL determina qual prevalece, e reconhece o padrão de defesa em profundidade combinando os dois mecanismos.

---

Resumo

Pense num Security Group como um segurança de prédio que lembra quem ele deixou entrar — se você entrou, ele automaticamente deixa você sair sem checar de novo ("stateful" = com memória do que já foi permitido). Uma NACL é como uma catraca sem memória: mesmo que ela tenha deixado o tráfego entrar, ela vai checar de novo se o tráfego de resposta (saída) tem uma regra explícita permitindo — caso contrário, bloqueia, mesmo que a entrada tenha sido permitida segundos antes.

• Security Groups: stateful, aplicados a nível de instância/ENI, sem regras de negação explícita (tudo que não está permitido é implicitamente negado), todas as regras são avaliadas em conjunto (sem prioridade numérica).
• NACLs: stateless, aplicados a nível de subnet, suportam negação explícita, regras avaliadas em ordem numérica (a de menor número que corresponder decide).
• Defesa em profundidade: usar os dois juntos — NACLs como uma barreira ampla na borda da subnet, Security Groups como controle granular por recurso — é a prática recomendada, não uma escolha entre um ou outro.

---

1. Stateful vs Stateless — o conceito central do tema

1.1 Security Groups são stateful

Quando um Security Group permite uma conexão de entrada (ex: porta 443 de um IP específico), o tráfego de resposta dessa mesma conexão é automaticamente permitido de volta, independentemente das regras de saída configuradas — o Security Group "lembra" que aquela conexão foi estabelecida e libera a resposta automaticamente.

Isso significa que, na prática, para a maioria dos cenários simples, regras de saída em Security Groups muitas vezes nem precisam ser configuradas restritivamente — o padrão de um Security Group recém-criado já permite todo tráfego de saída, e mesmo que fosse restrito, o tráfego de resposta a conexões de entrada permitidas continuaria funcionando automaticamente por causa do comportamento stateful.

1.2 NACLs são stateless

Uma NACL não lembra de nada entre entrada e saída — cada direção é avaliada de forma completamente independente. Se uma NACL permite uma conexão de entrada na porta 443, isso não garante automaticamente que o tráfego de resposta (que sai pela porta efêmera de origem do lado do cliente, tipicamente na faixa 1024-65535) seja permitido na regra de saída — essa regra de saída precisa existir explicitamente.

Explicação didática: pense na NACL como uma catraca sem memória — mesmo que ela tenha deixado o tráfego entrar, ela vai checar de novo se o tráfego de resposta (saída) tem uma regra explícita permitindo. Por isso, ao configurar NACLs, é comum esquecer a regra de retorno pelas portas efêmeras e quebrar a conexão mesmo com o Security Group correto e a regra de entrada da NACL também correta.

💡 Para a prova: o cenário clássico é "o Security Group está corretamente configurado, permitindo a conexão, mas o cliente não recebe resposta" — a causa quase sempre é uma NACL sem a regra de saída correspondente nas portas efêmeras, já que NACLs não têm o comportamento automático de retorno que Security Groups têm.

---

2. Escopo de aplicação: instância vs subnet

• Security Groups são associados diretamente a ENIs (Elastic Network Interfaces) — na prática, isso significa "por instância" (ou por recurso que tenha uma ENI, como um RDS, um ALB, uma Lambda numa VPC). Uma instância pode ter múltiplos security groups associados simultaneamente, e as regras de todos eles são combinadas (união de permissões).
• NACLs são associadas a nível de subnet inteira — toda instância dentro daquela subnet está sujeita às mesmas regras de NACL, independentemente de qual security group individual ela tenha. Cada subnet tem exatamente uma NACL associada por vez (a "default NACL" se nenhuma outra for explicitamente associada).

💡 Para a prova: se o cenário descreve "bloquear tráfego de um range de IPs maliciosos para todas as instâncias de uma subnet, de forma centralizada, sem precisar editar o security group de cada instância individualmente", isso aponta para NACL — é o mecanismo desenhado para controle amplo por subnet.

---

3. Regras, permissões e ordem de avaliação

3.1 Security Groups: sempre "allow", sem ordem

Security Groups não suportam regras de negação explícita — você só pode adicionar regras de permissão (allow). Tudo que não está explicitamente permitido é implicitamente negado. Como não existe negação explícita, também não existe conceito de "ordem" ou "prioridade" entre regras — todas as regras de um security group (e de todos os security groups associados à mesma ENI) são avaliadas em conjunto, e se qualquer uma delas permitir o tráfego, ele passa.

3.2 NACLs: allow e deny explícitos, com número de regra determinando prioridade

NACLs suportam tanto regras de permissão quanto de negação explícita, e cada regra tem um número associado (ex: 100, 110, 200). As regras são avaliadas em ordem numérica crescente, e a primeira regra que corresponder ao tráfego (seja allow ou deny) é a que decide — as demais regras, mesmo que também corresponderiam, não chegam a ser avaliadas.

Explicação didática: se a regra de número 100 nega tráfego de um IP específico, mas a regra de número 200 permite todo o resto, e o tráfego se encaixa em ambas, a regra 100 (menor número) vence, porque é avaliada primeiro — a ordem numérica funciona como uma sequência de checkpoints, e o primeiro checkpoint que "bate" com o tráfego decide o destino dele, sem continuar verificando os demais.

Toda NACL termina com uma regra implícita de número * que nega tudo que não correspondeu a nenhuma regra explícita anterior — funcionando como uma rede de segurança final.

💡 Para a prova: uma pegadinha comum é o enunciado descrever duas regras de NACL aparentemente conflitantes (uma permite, outra nega, para o mesmo tráfego) — a resposta correta depende de qual tem o menor número, não de qual "parece mais específica" ou foi criada por último.

---

4. Quando usar cada um

• Security Groups: para controle granular e específico por recurso — ex: "apenas o security group da aplicação pode acessar a porta 3306 do banco", "apenas tráfego HTTPS de um ALB específico pode alcançar as instâncias". É o mecanismo do dia a dia para governança de acesso entre camadas de uma aplicação (web → app → banco).
• NACLs: para controles amplos e centralizados por subnet — ex: bloquear um range de IPs conhecidos como maliciosos para toda uma subnet de uma vez, ou impor uma política ampla de "nenhum tráfego de entrada exceto de uma faixa específica" antes mesmo do tráfego alcançar qualquer instância individual.

💡 Para a prova: se o requisito é bloquear explicitamente algo (não apenas "não permitir"), a resposta é NACL, já que Security Groups não suportam negação explícita — só é possível "não permitir" no Security Group (ausência de regra de allow), nunca "negar ativamente" algo mesmo que outra regra permitisse.

---

5. Referenciar Security Groups entre si (e entre VPCs peered)

Um recurso frequentemente subestimado: uma regra de Security Group pode referenciar outro Security Group como origem/destino, em vez de uma faixa de CIDR — por exemplo, "permitir tráfego na porta 3306 apenas de instâncias que tenham o security group sg-app associado", independentemente de qual IP essas instâncias tenham (útil especialmente com Auto Scaling Groups, onde os IPs mudam constantemente).

Essa referência também funciona entre VPCs peered (referenciando o security group da VPC parceira), o que simplifica a governança de segurança em comparação a depender apenas de faixas de CIDR — evita ter que atualizar regras manualmente toda vez que o CIDR de uma das VPCs mudar ou novas instâncias forem adicionadas.

💡 Para a prova: essa referência entre security groups não é possível numa NACL — regras de NACL só suportam faixas de CIDR como origem/destino, nunca uma referência a outro security group.

---

6. Defesa em profundidade — usar os dois juntos

A prática recomendada não é escolher entre Security Groups ou NACLs — é usar ambos, em camadas complementares:

• NACLs na borda da subnet, como uma primeira barreira ampla — útil especialmente para bloquear rapidamente um IP ou range conhecido como malicioso em toda a subnet de uma vez, sem precisar tocar em cada security group individual.
• Security Groups por recurso, como controle granular e específico de qual origem pode acessar qual porta em qual instância/serviço.

Mesmo que um Security Group esteja excessivamente permissivo por engano (ex: 0.0.0.0/0 numa porta sensível), uma NACL bem configurada na subnet pode servir como uma camada adicional de proteção, reduzindo o "blast radius" (o alcance do dano) de uma configuração incorreta isolada.

💡 Para a prova: se o cenário menciona "minimizar o impacto de uma regra de Security Group configurada incorretamente/excessivamente permissiva", a resposta geralmente envolve reforçar a defesa em profundidade com NACLs como camada adicional, além de corrigir o Security Group em si.

---

7. Troubleshooting — o cenário mais cobrado do tema

Esse é o tipo de questão mais recorrente sobre o assunto: um cliente reclama que uma conexão não está funcionando, e é preciso identificar onde está o bloqueio.

Checklist de diagnóstico, na ordem em que normalmente vale verificar:

1. Security Group da instância de origem: permite tráfego de saída na porta relevante?
2. NACL da subnet de origem: permite tráfego de saída na porta relevante (incluindo, se aplicável, portas efêmeras para o retorno)?
3. NACL da subnet de destino: permite tráfego de entrada na porta relevante, e permite a saída do tráfego de resposta pelas portas efêmeras?
4. Security Group da instância/recurso de destino: permite tráfego de entrada na porta relevante, da origem correta?

💡 Para a prova: o cenário clássico "Security Group permite saída, mas a resposta não chega ao cliente" quase sempre aponta para uma NACL de saída bloqueando o tráfego de retorno pelas portas efêmeras — porque, sendo stateless, a NACL não sabe que aquele tráfego de saída é "resposta" a uma conexão de entrada já permitida; ela avalia a regra de saída de forma completamente independente.

---

8. Boas práticas

• Use Security Groups para controle granular por recurso, referenciando outros security groups (não apenas CIDRs) sempre que possível, especialmente com Auto Scaling Groups.
• Use NACLs para controles amplos por subnet, principalmente para bloqueios explícitos rápidos (ex: um IP malicioso identificado), aproveitando a capacidade de negação explícita que Security Groups não têm.
• Ao configurar NACLs customizadas, sempre lembre de incluir regras de saída para portas efêmeras (tipicamente 1024-65535), ou conexões de resposta serão bloqueadas mesmo com a entrada permitida.
• Evite regras excessivamente permissivas (0.0.0.0/0) em Security Groups de recursos sensíveis, como bancos de dados — restrinja por CIDR específico ou, preferencialmente, por referência a outro security group.
• Combine as duas camadas (defesa em profundidade) em vez de depender de apenas uma — um erro de configuração isolado numa camada não deve comprometer toda a segurança do ambiente.
• Documente e audite mudanças em Security Groups e NACLs regularmente, já que ambos afetam diretamente a superfície de exposição da aplicação.

---

9. Como cai na certificação

• Cenário "Security Group permite a conexão, mas a resposta não chega ao cliente" → verificar a NACL de saída, faltando regra para as portas efêmeras (comportamento stateless).
• Cenário "bloquear um range de IPs maliciosos para toda uma subnet de uma vez, de forma centralizada" → NACL, aproveitando negação explícita.
• Cenário "apenas instâncias com um security group específico podem acessar a porta do banco, independentemente do IP (útil com Auto Scaling)" → referenciar security group como origem na regra, não CIDR.
• Cenário "duas regras de NACL parecem conflitantes para o mesmo tráfego" → a regra com o menor número decide, não a mais específica nem a mais recente.
• Cenário "minimizar o impacto de um security group configurado incorretamente" → reforçar com NACL como camada adicional de defesa em profundidade.
• Cenário "regras de saída em Security Group parecem desnecessárias para conexões de entrada simples" → comportamento esperado do modelo stateful; o tráfego de resposta é automaticamente permitido.
• Cenário "negar explicitamente um tipo de tráfego, não apenas deixar de permitir" → NACL, já que Security Groups não suportam negação explícita.

---

10. Exercícios práticos

1. Modele as regras de NACL e Security Group necessárias para uma subnet pública com servidores web (porta 443 pública) e uma subnet privada com bancos de dados (porta 3306, acessível apenas dos servidores web).
2. Explique por que uma regra de NACL de saída bloqueando portas efêmeras pode quebrar uma conexão mesmo com o Security Group corretamente configurado.
3. Compare um cenário onde bloquear um IP específico via NACL é mais adequado do que tentar fazer o mesmo apenas com Security Groups.
4. Proponha uma estratégia para auditar Security Groups excessivamente permissivos (0.0.0.0/0) em múltiplas contas de uma organização.
5. Explique por que referenciar um security group como origem de outra regra é mais robusto que usar um CIDR fixo, num cenário com Auto Scaling Group.

---

11. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Laboratório Prático

Objetivo: configurar uma NACL customizada numa subnet, observar o comportamento stateless na prática (incluindo o esquecimento comum da regra de portas efêmeras), e comparar com o comportamento stateful de um Security Group.

Pré-requisitos: conta AWS com permissão para VPC e EC2; uma instância EC2 numa subnet de teste.

Tempo estimado: 30 minutos

Possíveis custos: baixo, apenas o custo normal da instância EC2 durante o teste.

Passos:

1. Crie uma NACL customizada e associe-a à subnet onde a instância de teste está localizada, substituindo a NACL padrão (que por padrão permite todo o tráfego).
2. Adicione uma regra de entrada permitindo tráfego HTTP (porta 80) de qualquer origem, com um número de regra baixo (ex: 100).
3. Não adicione, propositalmente, uma regra de saída para portas efêmeras — deixe apenas a regra implícita de negação (*) e, se necessário, uma regra explícita de saída negando tudo.
4. Confirme que o Security Group da instância permite entrada na porta 80 de qualquer origem (comportamento padrão comum).
5. Tente acessar a instância via HTTP a partir de outra máquina — observe que a conexão de entrada é aceita, mas a resposta não chega ao cliente, demonstrando o comportamento stateless da NACL bloqueando o retorno pelas portas efêmeras.
6. Corrija adicionando uma regra de saída na NACL permitindo tráfego nas portas efêmeras (ex: 1024-65535) para o CIDR de origem, e repita o teste — confirme que a resposta agora chega corretamente.
7. Como comparação, remova a regra de saída da NACL novamente, mas desta vez teste uma conexão de saída iniciada pela própria instância (ex: a instância acessando um servidor web externo) — observe como o comportamento stateless também afeta conexões iniciadas de dentro para fora, exigindo regras de entrada correspondentes para a resposta.

Resultado esperado: você confirma na prática a causa mais comum de troubleshooting do tema — uma NACL sem a regra de retorno nas portas efêmeras bloqueando silenciosamente respostas, mesmo com o Security Group corretamente configurado.

Limpeza dos recursos: reverta a subnet para a NACL padrão (ou ajuste a NACL customizada para permitir todo o tráfego), e delete a NACL customizada de teste, se não for mais necessária.

---

Referências:

• Security Groups: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
• Network ACLs: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
• Comparação entre Security Groups e NACLs: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html
• Referenciar Security Groups entre si: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#vpc-security-group-referencing