Grupos de Segurança vs. ACLs de Rede: Escolhendo o Firewall da Sua VPC AWS
Navegue pelas complexidades da segurança de VPC AWS dominando as diferenças entre Grupos de Segurança (SGs) e ACLs de Rede (NACLs). Este guia especializado explica o escopo, a statefulness e a avaliação de regras de ambos os controles. Aprenda por que os SGs são ideais para proteção de instâncias stateful e granular, enquanto as NACLs são essenciais para segmentação de sub-redes stateless e políticas de negação explícita. Implemente uma estratégia de firewall robusta e em múltiplas camadas para sua infraestrutura em nuvem.
Grupos de Segurança vs. ACLs de Rede: Escolhendo o Firewall da Sua VPC AWS
Ao projetar um ambiente de Virtual Private Cloud (VPC) seguro na Amazon Web Services (AWS), os administradores dependem de múltiplas camadas de controle para gerenciar o tráfego de rede. Os dois componentes fundamentais para filtrar o tráfego no nível de rede são os Grupos de Segurança (SGs) e as Listas de Controle de Acesso à Rede (NACLs).
Eles parecem semelhantes no console, mas falham de maneiras muito diferentes. Os grupos de segurança são geralmente onde você descreve a intenção da aplicação. As ACLs de rede são onde você impõe limites amplos de sub-rede ou negações de emergência.
O Papel dos Firewalls na VPC AWS
A AWS fornece segurança de rede em dois níveis principais dentro de uma VPC:
- Nível de Instância (Grupos de Segurança): Atua como um firewall para instâncias EC2 específicas ou recursos (como bancos de dados RDS ou Elastic Load Balancers). Controla o tráfego de e para a interface de rede.
- Nível de Sub-rede (ACLs de Rede): Atua como um firewall stateless para sub-redes inteiras, controlando o fluxo de tráfego que entra ou sai do limite da sub-rede.
Aprofundamento nos Grupos de Segurança (SGs)
Os Grupos de Segurança funcionam como o firewall principal e granular para recursos individuais. Eles são stateful e filtram por protocolo, porta e origem ou destino.
Características Principais dos Grupos de Segurança
| Característica | Descrição | Implicações para Uso |
|---|---|---|
| Escopo | Aplica-se diretamente à Elastic Network Interface (ENI) de uma instância. | Controla o fluxo de tráfego para e da própria instância. |
| Statefulness | Stateful. Se uma solicitação de entrada for explicitamente permitida, o tráfego de retorno correspondente (resposta de saída) é automaticamente permitido, independentemente das regras de saída. | Simplifica a configuração; só é necessário definir a direção do tráfego iniciador. |
| Tipo de Regra | Apenas permitir. Regras de negação explícita não são possíveis. O tráfego que não corresponde a uma regra explícita de PERMITIR é implicitamente negado. |
Foca em definir o que é permitido. |
| Avaliação | Todas as regras são avaliadas antes de uma decisão ser tomada. Elas não são numeradas e nenhuma NEGAÇÃO implícita é processada até que todas as regras de PERMITIR falhem. |
A ordem não importa; todas as regras são tratadas igualmente. |
Exemplo de Configuração de Grupo de Segurança
Para permitir acesso SSH (porta 22) a uma instância EC2, você só precisa de uma regra de entrada. A regra de saída para a resposta SSH é tratada automaticamente pela natureza stateful do SG.
| Tipo | Protocolo | Faixa de Portas | Origem | Descrição |
|---|---|---|---|---|
| Entrada | TCP | 22 | 0.0.0.0/0 (ou IP de administração específico) | Permitir acesso SSH |
| Saída | Todos | Todas | 0.0.0.0/0 | (Padrão: Permite todo o tráfego, mas pode ser restrito se necessário) |
# Representação conceitual de um fluxo stateful
Usuário (IP de Origem) --> [Regra SG de Entrada: PERMITIR 22] --> Instância EC2
Instância EC2 (Resposta) --> [Rastreamento de Estado Implícito] --> Usuário (Resposta recebida)
Dica de Melhor Prática: Sempre defina as regras do Grupo de Segurança usando o princípio do menor privilégio. Sempre que possível, restrinja os intervalos de IP de origem em vez de permitir 0.0.0.0/0.
Aprofundamento nas ACLs de Rede (NACLs)
As ACLs de Rede fornecem uma segunda camada de defesa, atuando como um filtro stateless no limite da sub-rede. Elas são poderosas para segmentação de rede e políticas de negação amplas.
Características Principais das ACLs de Rede
| Característica | Descrição | Implicações para Uso |
|---|---|---|
| Escopo | Aplica-se a uma sub-rede VPC inteira. Uma sub-rede só pode ser associada a uma NACL por vez. | Controla todo o tráfego que entra ou sai da sub-rede, afetando todas as instâncias dentro dela. |
| Statefulness | Stateless. Tanto as solicitações de entrada quanto as respostas de saída correspondentes devem ser explicitamente permitidas. | Requer configuração cuidadosa para o tráfego de retorno (portas efêmeras). |
| Tipo de Regra | Permitir e Negar. Você pode definir explicitamente regras para permitir ou bloquear tráfego. | Excelente para bloquear IPs maliciosos conhecidos ou negar protocolos específicos em toda a rede. |
| Avaliação | As regras são numeradas (1 a 32766) e avaliadas sequencialmente, começando pelo número mais baixo. A primeira regra correspondente é aplicada imediatamente. | A ordenação das regras é crítica. A regra de negação implícita (a última regra processada) nega tudo que não foi explicitamente permitido. |
Gerenciando Tráfego Stateless (Portas Efêmeras)
Como as NACLs são stateless, você deve considerar as portas efêmeras usadas pelos clientes que se conectam aos seus servidores. Quando um cliente inicia uma conexão, ele usa uma porta de destino (ex.: 80 para HTTP) e uma porta de origem de número alto (faixa de porta efêmera, tipicamente 1024-65535).
Para permitir tráfego web (HTTP) em uma sub-rede, você precisa de duas regras:
- Regra de Entrada: Permite o tráfego na porta de destino (ex.: 80).
- Regra de Saída: Permite o tráfego de retorno ao cliente usando as portas de origem efêmeras.
| Regra # | Tipo | Protocolo | Faixa de Portas | Origem/Destino | Ação da Regra |
|---|---|---|---|---|---|
| 100 | Entrada | TCP | 80 | 0.0.0.0/0 | PERMITIR (Tráfego web entrando) |
| 110 | Saída | TCP | 1024-65535 | 0.0.0.0/0 | PERMITIR (Resposta web saindo - Portas efêmeras) |
| * | Negação Implícita | Todos | Todas | Todos | NEGAR (Processado por último) |
Aviso: Se você perder a regra de saída correspondente para portas efêmeras em uma NACL, o tráfego alcançará a instância (devido à regra de entrada), mas a resposta será descartada no limite da sub-rede, levando a timeouts de conexão.
Resumo da Comparação: SG vs. NACL
A tabela a seguir resume as diferenças cruciais entre os dois tipos de firewall:
| Característica | Grupo de Segurança (SG) | ACL de Rede (NACL) |
|---|---|---|
| Escopo de Aplicabilidade | Nível de Instância/ENI | Nível de Sub-rede |
| Estado | Stateful | Stateless |
| Tipos de Regra | Apenas Permitir | Permitir e Negar |
| Avaliação de Regra | Todas as regras avaliadas, sem ordem específica. | Regras avaliadas sequencialmente por número (menor primeiro); a primeira correspondência vence. |
| Comportamento Padrão | Nega toda entrada, permite toda saída (a menos que restrito). | NACL padrão permite toda entrada/saída. NACLs personalizadas negam toda entrada/saída. |
| Efeito no Tráfego | Aplica regras apenas se o tráfego for destinado a ou originado de um recurso associado. | Filtra o tráfego que passa pelo limite da sub-rede, afetando todos os recursos na sub-rede. |
Escolhendo o Firewall Certo: Cenários e Melhores Práticas
A segurança de VPC bem-sucedida depende do uso conjunto de SGs e NACLs em uma abordagem em camadas (Defesa em Profundidade).
Quando Priorizar Grupos de Segurança
Os Grupos de Segurança devem ser a ferramenta principal para filtrar o acesso à rede devido à sua natureza stateful e capacidade de referenciar outros SGs, simplificando a configuração da aplicação.
- Controle de Aplicação Granular: Use SGs para definir exatamente quais portas e protocolos são necessários para uma aplicação específica (ex.: permitir apenas tráfego na porta 3306 do SG do servidor web para o SG do banco de dados).
- Comunicação Interna: Gerencie a segurança para o tráfego entre instâncias dentro da mesma sub-rede ou entre sub-redes (ex.: garantir que um balanceador de carga possa se comunicar com seus grupos de destino).
- Facilidade de Gerenciamento: Como são stateful, os SGs exigem menos regras e são menos propensos a erros do que gerenciar portas efêmeras com NACLs.
Quando Implementar ACLs de Rede
As NACLs são melhor usadas para definir limites amplos de rede e políticas de segmentação.
- Políticas de Negação Amplas: Use regras explícitas de
NEGAR(Regra #100) para bloquear endereços IP ou intervalos IP maliciosos específicos em toda uma sub-rede antes que o tráfego chegue às instâncias. - Segmentação de Sub-rede: Imponha limites estritos entre as camadas da sua arquitetura (ex.: garantir que a NACL da sub-rede do banco de dados negue explicitamente todo o tráfego de entrada da internet, independentemente de como um SG possa ser configurado).
- Requisitos de Conformidade: Certos padrões de conformidade podem exigir filtragem no nível da sub-rede, tornando as NACLs essenciais.
- Filtragem de Protocolo Stateless: As NACLs são necessárias se você precisar filtrar protocolos stateless que os SGs não podem gerenciar efetivamente por conta própria (embora isso seja raro para tráfego TCP/UDP padrão).
Erros que causam interrupções
O erro mais comum de NACL que causa interrupção é esquecer o tráfego de retorno. Alguém permite TCP 443 de entrada em uma sub-rede pública e deixa as regras de saída muito restritivas. O balanceador de carga ou a instância recebe o SYN, mas a resposta é descartada no caminho de volta. Do lado do cliente, parece um timeout, e do lado da instância, o serviço pode parecer perfeitamente saudável.
Outro erro é usar NACLs para políticas por aplicação. Se uma sub-rede contém instâncias web, worker e admin, uma NACL se aplica a todas elas. Uma regra adicionada para uma carga de trabalho pode expor ou quebrar inesperadamente outra carga de trabalho na mesma sub-rede. Se você precisa de comportamentos de rede diferentes, use grupos de segurança diferentes e considere sub-redes separadas apenas quando houver um limite real a ser imposto.
A numeração das regras também merece cuidado. Deixe lacunas como 100, 110, 120 em vez de 1, 2, 3 para que você possa inserir regras de emergência posteriormente. Lembre-se de que a primeira correspondência vence. Uma negação na regra 90 vencerá uma permissão na regra 100, mesmo que a permissão pareça mais específica para quem lê o console rapidamente.
Para grupos de segurança, o erro comum são intervalos de origem amplos. 0.0.0.0/0 na porta 443 para um balanceador de carga público pode ser normal. A mesma origem em SSH, RDP, Redis, PostgreSQL ou uma API de administração interna geralmente é um problema. Prefira referências a grupos de segurança dentro da VPC e CIDRs estreitos para acesso do operador.
Ao herdar uma VPC existente, exporte as regras e agrupe-as por intenção: pontos de entrada públicos, tráfego app-para-app, armazenamentos de dados, administração e negações de emergência. Regras sem um proprietário ou motivo claro são onde a exposição obsoleta geralmente reside.
A Abordagem de Defesa em Profundidade
Em uma VPC típica e bem projetada, os fluxos de tráfego devem passar por uma NACL e um Grupo de Segurança. Se qualquer um dos controles de segurança negar o tráfego, o pacote é descartado.
- Fluxo de Entrada: O tráfego entra na sub-rede -> NACL verifica as regras -> O tráfego atinge a ENI da instância -> Grupo de Segurança verifica as regras -> O tráfego atinge a aplicação.
- Fluxo de Saída: A aplicação gera a resposta -> Grupo de Segurança (Verificação stateful aprovada) -> O tráfego sai da ENI da instância -> NACL verifica as regras -> O tráfego sai da sub-rede.
Ao aproveitar a NACL para segmentação grosseira e regras de negação, e o SG para permissões precisas, stateful e no nível da aplicação, você maximiza a eficácia da segurança enquanto mantém a simplicidade da configuração.
Um padrão de design prático
Para a maioria das VPCs de aplicação, comece com grupos de segurança. Dê ao balanceador de carga um grupo de segurança voltado para o público, dê às instâncias da aplicação um grupo de segurança que só aceita tráfego do grupo de segurança do balanceador de carga e dê ao banco de dados um grupo de segurança que só aceita tráfego do grupo de segurança da aplicação na porta do banco de dados. Esse modelo segue o gráfico de dependência da aplicação e sobrevive a mudanças de IP.
Use NACLs com mais moderação. Um bom caso de uso de NACL é uma negação no nível da sub-rede para um CIDR ruim conhecido, um limite rígido em torno de uma sub-rede de banco de dados ou uma regra de conformidade que deve ser aplicada antes que o tráfego atinja qualquer ENI na sub-rede. As NACLs se tornam problemáticas quando as equipes tentam espelhar todas as regras da aplicação lá. As regras de porta de retorno stateless são fáceis de errar, e uma negação de número baixo pode quebrar uma sub-rede inteira.
Quando uma conexão expira, verifique ambas as camadas no caminho do pacote. Para tráfego de internet de entrada para uma instância EC2 em uma sub-rede pública, a solicitação deve passar pela regra de NACL de entrada, pela tabela de rotas e pela regra de grupo de segurança de entrada. A resposta deve passar pelo rastreamento stateful do grupo de segurança e pela regra de NACL de saída. Se os SGs parecem corretos, mas os clientes ainda travam, a regra de porta efêmera da NACL é frequentemente a peça que falta.
O modelo mental mais limpo é este: grupos de segurança dizem quais recursos podem conversar com quais outros recursos; NACLs dizem o que a sub-rede nunca permitirá. Mantenha esses trabalhos separados e o design permanece mais fácil de auditar.