O que são Security Groups e NACLs?
Security Groups (SGs) e Network Access Control Lists (NACLs) são os dois pilares de segurança de rede na AWS. O Security Group funciona como um firewall stateful no nível da instância EC2, permitindo ou bloqueando tráfego de entrada e saída com base em regras que você define. Já o NACL é um firewall stateless que opera no nível da subnet, aplicando-se a todos os recursos dentro dela. A diferença fundamental está na statefulness: Security Groups lembram do estado de uma conexão (se você permite entrada, a saída correspondente é automaticamente permitida), enquanto NACLs tratam cada pacote individualmente, exigindo regras explícitas para entrada e saída.
Na prática, Security Groups são mais flexíveis e fáceis de gerenciar para controle granular por instância. NACLs oferecem uma camada adicional de defesa em profundidade, ideal para arquiteturas que exigem isolamento strict entre subnets. Todo desenvolvedor deve dominar essas duas tecnologias porque juntas formam uma defesa em camadas que protege sua infraestrutura contra acessos não autorizados.
Diferenças Técnicas Detalhadas
Stateful vs Stateless
O Security Group é stateful, o que significa que se você permite uma requisição de entrada (inbound), a resposta de saída (outbound) é automaticamente permitida sem precisar de regra explícita. Um NACL é stateless: ele avalia cada direção de tráfego independentemente. Você precisará de duas regras — uma inbound e outra outbound — para completar uma comunicação bidirecional. Isso torna NACLs mais verbosos, mas também mais previsíveis para auditoria.
# Exemplo: Criar um Security Group que permite HTTP de qualquer lugar
import boto3
ec2_client = boto3.client('ec2', region_name='us-east-1')
response = ec2_client.create_security_group(
GroupName='web-server-sg',
Description='Allow HTTP and HTTPS traffic',
VpcId='vpc-12345678'
)
sg_id = response['GroupId']
# Adicionar regra inbound para HTTP
ec2_client.authorize_security_group_ingress(
GroupId=sg_id,
IpPermissions=[
{
'IpProtocol': 'tcp',
'FromPort': 80,
'ToPort': 80,
'IpRanges': [{'CidrIp': '0.0.0.0/0', 'Description': 'Allow HTTP'}]
},
{
'IpProtocol': 'tcp',
'FromPort': 443,
'ToPort': 443,
'IpRanges': [{'CidrIp': '0.0.0.0/0', 'Description': 'Allow HTTPS'}]
}
]
)
print(f"Security Group criado: {sg_id}")
Ordem de Avaliação
Security Groups avaliam todas as regras e permitem tráfego se qualquer regra permite (lógica OR). NACLs, por sua vez, avaliam regras na ordem de numeração (10, 20, 30...) e param na primeira correspondência. Isso significa que a ordem importa em NACLs — regras mais específicas devem ter números menores. Security Groups não têm conceito de "negação" explícita; você remove a regra que permite. NACLs permitem explicitamente negar tráfego com regras DENY.
# Exemplo: Criar e configurar um NACL
nacl_response = ec2_client.create_network_acl(
VpcId='vpc-12345678'
)
nacl_id = nacl_response['NetworkAcl']['NetworkAclId']
# Regra para permitir HTTP entrada (regra 100)
ec2_client.create_network_acl_entry(
NetworkAclId=nacl_id,
RuleNumber=100,
Protocol='6', # TCP
RuleAction='allow',
CidrBlock='0.0.0.0/0',
PortRange={'From': 80, 'To': 80}
)
# Regra para permitir respostas efêmeras (regra 110)
ec2_client.create_network_acl_entry(
NetworkAclId=nacl_id,
RuleNumber=110,
Protocol='6',
RuleAction='allow',
CidrBlock='0.0.0.0/0',
PortRange={'From': 1024, 'To': 65535}
)
# Regra para NEGAR SSH de um IP suspeito (regra 200)
ec2_client.create_network_acl_entry(
NetworkAclId=nacl_id,
RuleNumber=200,
Protocol='6',
RuleAction='deny',
CidrBlock='192.0.2.50/32',
PortRange={'From': 22, 'To': 22}
)
print(f"NACL criado: {nacl_id}")
Estratégias de Uso e Boas Práticas
Quando Usar Cada Um
Use Security Groups como sua primeira linha de defesa em praticamente todas as situações. Eles são suficientes para 95% dos casos: controlar acesso a instâncias EC2, RDS, ALB, etc. NACLs devem ser usados quando você precisa bloquear tráfego em nível de subnet ou quando exigências de compliance demandam controle granular de negação explícita. Um exemplo clássico é isolar uma subnet de desenvolvimento de produção, ou bloquear portas específicas para toda uma subnet que contém instâncias comprometidas durante um incidente de segurança.
Modelo de Defesa em Profundidade
A melhor estratégia é combinar ambas as camadas. Seu NACL pode ter regras básicas e permissivas (permitindo o tráfego necessário), enquanto Security Groups aplicam controle fino por instância. Isso oferece defesa em profundidade: mesmo se uma instância tiver seu SG configurado incorretamente, o NACL da subnet ainda pode bloquear tráfego malicioso. Além disso, configure seu Security Group padrão (default) de forma restritiva — negue tudo e permita apenas o necessário.
# Exemplo: Implementar princípio do menor privilégio
# NACL permissivo (nível subnet)
ec2_client.create_network_acl_entry(
NetworkAclId=nacl_id,
RuleNumber=100,
Protocol='-1', # Todos os protocolos
RuleAction='allow',
CidrBlock='10.0.0.0/16' # Apenas dentro do VPC
)
# Security Group restritivo (nível instância)
ec2_client.authorize_security_group_ingress(
GroupId=sg_id,
IpPermissions=[
{
'IpProtocol': 'tcp',
'FromPort': 3306,
'ToPort': 3306,
'UserIdGroupPairs': [
{
'GroupId': 'sg-app-servers',
'Description': 'MySQL apenas de app servers'
}
]
}
]
)
Diagnóstico e Troubleshooting
Quando conexões não funcionam como esperado, comece verificando o Security Group da instância — é o lugar mais comum para erros. Use o VPC Flow Logs para investigar rejeições no nível de NACL. A AWS oferece ferramentas como EC2 Instance Connect para testar conexões sem SSH tradicional, ajudando a isolar problemas de rede de problemas de credenciais.
Lembre-se que Security Groups só permitem (não há regra DENY), então se uma conexão está bloqueada, o culpado provavelmente é uma regra faltante. NACLs, por outro lado, podem bloquear explicitamente, então procure por regras DENY inesperadas. Use documentação como guia ao debugar — às vezes a solução é simplesmente adicionar uma regra que permite tráfego efêmero de resposta (portas 1024-65535 para TCP/UDP).
Conclusão
Security Groups e NACLs são complementares, não concorrentes. Security Groups oferecem controle stateful, flexível e granular por instância, enquanto NACLs fornecem defesa stateless em nível de subnet. O caminho para dominar segurança em nuvem passa por entender que essa defesa em camadas é essencial: configure SGs restritivos como padrão, permita apenas o tráfego necessário, e use NACLs para políticas em nível de subnet quando compliance ou isolamento exigir. Por fim, automatize essas configurações com Infrastructure-as-Code — configurar regras manualmente não escala e introduz erros humanos.