Cloud & Infraestrutura

O que Todo Dev Deve Saber sobre Security Groups e NACLs: Diferenças e Estratégias de Uso

8 min de leitura

O que Todo Dev Deve Saber sobre Security Groups e NACLs: Diferenças e Estratégias de Uso

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

<h2>O que são Security Groups e NACLs?</h2>

<p>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 <strong>stateful</strong> 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 <strong>stateless</strong> 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.</p>

<p>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.</p>

<h2>Diferenças Técnicas Detalhadas</h2>

<h3>Stateful vs Stateless</h3>

<p>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.</p>

<pre><code class="language-python"># Exemplo: Criar um Security Group que permite HTTP de qualquer lugar

import boto3

ec2_client = boto3.client(&#039;ec2&#039;, region_name=&#039;us-east-1&#039;)

response = ec2_client.create_security_group(

GroupName=&#039;web-server-sg&#039;,

Description=&#039;Allow HTTP and HTTPS traffic&#039;,

VpcId=&#039;vpc-12345678&#039;

)

sg_id = response[&#039;GroupId&#039;]

Adicionar regra inbound para HTTP

ec2_client.authorize_security_group_ingress(

GroupId=sg_id,

IpPermissions=[

{

&#039;IpProtocol&#039;: &#039;tcp&#039;,

&#039;FromPort&#039;: 80,

&#039;ToPort&#039;: 80,

&#039;IpRanges&#039;: [{&#039;CidrIp&#039;: &#039;0.0.0.0/0&#039;, &#039;Description&#039;: &#039;Allow HTTP&#039;}]

},

{

&#039;IpProtocol&#039;: &#039;tcp&#039;,

&#039;FromPort&#039;: 443,

&#039;ToPort&#039;: 443,

&#039;IpRanges&#039;: [{&#039;CidrIp&#039;: &#039;0.0.0.0/0&#039;, &#039;Description&#039;: &#039;Allow HTTPS&#039;}]

}

]

)

print(f&quot;Security Group criado: {sg_id}&quot;)</code></pre>

<h3>Ordem de Avaliação</h3>

<p>Security Groups avaliam <strong>todas</strong> as regras e permitem tráfego se <strong>qualquer</strong> regra permite (lógica OR). NACLs, por sua vez, avaliam regras <strong>na ordem de numeração</strong> (10, 20, 30...) e <strong>param na primeira correspondência</strong>. 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 &quot;negação&quot; explícita; você remove a regra que permite. NACLs permitem explicitamente negar tráfego com regras DENY.</p>

<pre><code class="language-python"># Exemplo: Criar e configurar um NACL

nacl_response = ec2_client.create_network_acl(

VpcId=&#039;vpc-12345678&#039;

)

nacl_id = nacl_response[&#039;NetworkAcl&#039;][&#039;NetworkAclId&#039;]

Regra para permitir HTTP entrada (regra 100)

ec2_client.create_network_acl_entry(

NetworkAclId=nacl_id,

RuleNumber=100,

Protocol=&#039;6&#039;, # TCP

RuleAction=&#039;allow&#039;,

CidrBlock=&#039;0.0.0.0/0&#039;,

PortRange={&#039;From&#039;: 80, &#039;To&#039;: 80}

)

Regra para permitir respostas efêmeras (regra 110)

ec2_client.create_network_acl_entry(

NetworkAclId=nacl_id,

RuleNumber=110,

Protocol=&#039;6&#039;,

RuleAction=&#039;allow&#039;,

CidrBlock=&#039;0.0.0.0/0&#039;,

PortRange={&#039;From&#039;: 1024, &#039;To&#039;: 65535}

)

Regra para NEGAR SSH de um IP suspeito (regra 200)

ec2_client.create_network_acl_entry(

NetworkAclId=nacl_id,

RuleNumber=200,

Protocol=&#039;6&#039;,

RuleAction=&#039;deny&#039;,

CidrBlock=&#039;192.0.2.50/32&#039;,

PortRange={&#039;From&#039;: 22, &#039;To&#039;: 22}

)

print(f&quot;NACL criado: {nacl_id}&quot;)</code></pre>

<h2>Estratégias de Uso e Boas Práticas</h2>

<h3>Quando Usar Cada Um</h3>

<p>Use Security Groups como sua <strong>primeira linha de defesa</strong> 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 <strong>nível de subnet</strong> 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.</p>

<h3>Modelo de Defesa em Profundidade</h3>

<p>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 <strong>restritiva</strong> — negue tudo e permita apenas o necessário.</p>

<pre><code class="language-python"># 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=&#039;-1&#039;, # Todos os protocolos

RuleAction=&#039;allow&#039;,

CidrBlock=&#039;10.0.0.0/16&#039; # Apenas dentro do VPC

)

Security Group restritivo (nível instância)

ec2_client.authorize_security_group_ingress(

GroupId=sg_id,

IpPermissions=[

{

&#039;IpProtocol&#039;: &#039;tcp&#039;,

&#039;FromPort&#039;: 3306,

&#039;ToPort&#039;: 3306,

&#039;UserIdGroupPairs&#039;: [

{

&#039;GroupId&#039;: &#039;sg-app-servers&#039;,

&#039;Description&#039;: &#039;MySQL apenas de app servers&#039;

}

]

}

]

)</code></pre>

<h2>Diagnóstico e Troubleshooting</h2>

<p>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.</p>

<p>Lembre-se que Security Groups <strong>só permitem</strong> (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).</p>

<h2>Conclusão</h2>

<p>Security Groups e NACLs são complementares, não concorrentes. Security Groups oferecem controle <strong>stateful, flexível e granular</strong> por instância, enquanto NACLs fornecem <strong>defesa stateless em nível de subnet</strong>. 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.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html" target="_blank" rel="noopener noreferrer">AWS Security Groups Documentation</a></li>

<li><a href="https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html" target="_blank" rel="noopener noreferrer">AWS Network ACLs Documentation</a></li>

<li><a href="https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html" target="_blank" rel="noopener noreferrer">VPC Flow Logs Guide</a></li>

<li><a href="https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/" target="_blank" rel="noopener noreferrer">AWS Well-Architected Framework - Security Pillar</a></li>

<li><a href="https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html" target="_blank" rel="noopener noreferrer">Boto3 EC2 Client Reference</a></li>

</ul>

Comentários

Mais em Cloud & Infraestrutura

Snow Family e Storage Gateway: Dados On-premises e Migração: Do Básico ao Avançado
Snow Family e Storage Gateway: Dados On-premises e Migração: Do Básico ao Avançado

Snow Family: Migração de Dados em Escala A AWS Snow Family é um conjunto de s...

O que Todo Dev Deve Saber sobre CodeCommit, CodeBuild e CodeDeploy: CI/CD Nativo da AWS
O que Todo Dev Deve Saber sobre CodeCommit, CodeBuild e CodeDeploy: CI/CD Nativo da AWS

Entendendo a Tríade CI/CD da AWS A integração contínua e deployment contínuo...

IAM Avançado: SCP, Permission Boundaries e Attribute-Based Access: Do Básico ao Avançado
IAM Avançado: SCP, Permission Boundaries e Attribute-Based Access: Do Básico ao Avançado

IAM Avançado: SCP, Permission Boundaries e Attribute-Based Access O que é IAM...