Segurança de VPC e Isolamento de Rede com Security Group, Network ACL, Network Firewall e PrivateLink
_Category: Network Security_
Grande parte dos incidentes de segurança acontece justamente por não se conseguir rastrear "de onde para onde o tráfego fluiu". Na AWS, o isolamento de rede não se resume a algumas regras de firewall: ele é projetado como uma fronteira em múltiplas camadas que vai da conta até a VPC, passando pela sub-rede e chegando à ENI. Neste artigo, exploramos de forma estruturada os tópicos de segurança de rede em VPC que representam uma fatia significativa das questões do exame SCS-C03.
---
A Estrutura de Isolamento da VPC em Camadas: Conta → VPC → Sub-rede → ENI
Na AWS, o isolamento de rede se assemelha a uma matrioshka gigante: fronteiras aninhadas, uma dentro da outra.
A fronteira mais externa é a conta AWS. VPCs de contas diferentes são completamente isoladas, a menos que você as conecte explicitamente. Em seguida vem a VPC. Dentro de uma mesma conta, é possível criar várias VPCs para separar ambientes (desenvolvimento, homologação, produção) ou isolar cargas de trabalho por características. Dentro da VPC, as sub-redes dividem o espaço em Zona Pública e Zona Privada. A Sub-rede Pública se conecta diretamente à internet via Internet Gateway (IGW), enquanto a Sub-rede Privada só permite tráfego de saída por meio do NAT Gateway. A fronteira mais interna é a ENI (Elastic Network Interface). Cada ENI de uma instância EC2 recebe um Security Group, que controla o acesso no nível da instância.
Do ponto de vista de roteamento, a Route Table determina a direção do tráfego. A Route Table de uma Sub-rede Pública contém a rota , e a de uma Sub-rede Privada contém . Sem uma Route Table adequada, não importa quão aberto esteja o Security Group — o pacote simplesmente não chegará ao destino. É por isso que, ao analisar problemas de VPC peering, a primeira pergunta deve sempre ser: "a rota de peering está adicionada na Route Table?"
Em ambientes corporativos que exigem controle de rede centralizado, utiliza-se o padrão de Shared VPC via AWS RAM. A conta central controla o CIDR, o roteamento e as NACLs das sub-redes, enquanto as contas de carga de trabalho implantam EC2, RDS e outros recursos de forma independente nessas sub-redes.
---
A Diferença Fundamental entre Security Group e Network ACL: Stateful vs Stateless
O Security Group é como o leitor de crachá ao lado de cada mesa de trabalho. Quando alguém entra, o sistema registra; quando sai, ele reconhece automaticamente que é a mesma pessoa que entrou e libera a passagem. Isso é Stateful (com estado). Já o Network ACL funciona como a portaria do edifício: verifica as regras na entrada, verifica novamente na saída — sem memória, sempre decidindo do zero. Isso é Stateless (sem estado).
| Item | Security Group | Network ACL | |------|---------------|-------------| | Escopo de aplicação | ENI (nível de instância) | Nível de sub-rede | | Tratamento de estado | Stateful — resposta de tráfego liberada automaticamente | Stateless — regras de entrada e saída definidas separadamente | | Comportamento padrão | Bloqueia tudo (apenas permissões explícitas funcionam) | VPC padrão libera tudo; se criada do zero, bloqueia tudo | | Formato das regras | Apenas regras de permissão (sem negação) | Permissão e negação disponíveis, avaliadas em ordem numérica | | Forma de referência | Pode referenciar o ID de outro Security Group (mesma região) | Apenas IP/CIDR | | Aplicação de mudanças | Imediata | Imediata |
Um ponto crítico na prática é a característica "sem negação" do Security Group. Para bloquear explicitamente um IP específico, o Security Group não é suficiente — é preciso usar uma regra DENY no Network ACL. Além disso, como as regras do Network ACL são avaliadas em ordem numérica (número menor tem prioridade), a regra DENY precisa estar com um número menor do que a regra ALLOW para ter efeito.
No VPC peering entre regiões, a referência por ID de Security Group não é suportada. No peering na mesma região, você pode usar o ID do Security Group da VPC de destino como origem; mas em peering entre regiões, é obrigatório especificar o bloco CIDR (por exemplo, 10.0.0.0/16) como origem.
!Security Group vs Network ACL
Ganhando Visibilidade de Tráfego com VPC Flow Logs
O VPC Flow Logs registra, no nível da ENI, informações como IP de origem, IP de destino, porta, protocolo e o status ACCEPT/REJECT, enviando esses dados para o CloudWatch Logs ou para o S3. Quando um tráfego que deveria ser permitido está sendo bloqueado, o campo REJECT ajuda a identificar se o bloqueio vem do Security Group ou do Network ACL.
No entanto, como o Flow Logs opera no nível da ENI, ele tem dificuldade em detectar o comportamento interno do grupo de destino de um NLB. Num cenário de falha no PrivateLink, quando o Interface Endpoint está funcionando corretamente mas o tráfego não chega ao destino, o Flow Logs pode não revelar a causa — pois mesmo que o Security Group ou o Network ACL da instância EC2 de destino do NLB esteja bloqueando o tráfego, o Flow Logs não consegue capturar isso internamente.
Combinando com o Route 53 Resolver Query Logging, é possível também visualizar padrões de consulta DNS. Verificar quais instâncias estão enviando consultas para domínios externos desconhecidos é útil para detectar comunicações C2 (Command & Control).
---
AWS Network Firewall e Firewalls de Terceiros via GWLB
Se o Security Group e o Network ACL são a linha de defesa básica, o AWS Network Firewall é a linha avançada com inspeção profunda de pacotes (DPI).
O Network Firewall funciona criando uma Sub-rede de Firewall dedicada dentro da VPC e manipulando as Route Tables para que todo o tráfego passe obrigatoriamente por essa sub-rede. Ele suporta tanto regras Stateless (correspondência rápida baseada em 5 tuplas) quanto regras Stateful (inspeção profunda no nível IPS/IDS), com compatibilidade para regras no formato Suricata. Também oferece filtragem por URL, bloqueio baseado em domínio (como padrões ) e inspeção TLS.
O Gateway Load Balancer (GWLB) é o método para inserir de forma transparente appliances de firewall de terceiros (Palo Alto, Fortinet, entre outros) na rede AWS. O GWLB usa tunelamento GENEVE para encaminhar pacotes originais ao appliance de firewall sem modificá-los. Após a inspeção pelo appliance, o tráfego retorna pelo GWLB ao destino original.
| Item | AWS Network Firewall | GWLB + Firewall de Terceiros | |------|---------------------|------------------------------| | Gerenciamento | Serviço totalmente gerenciado pela AWS | Cliente gerencia o appliance diretamente | | Personalização | Regras Suricata, filtragem por domínio | Acesso completo aos recursos do appliance | | Escalabilidade | Scale-out automático | GWLB distribui tráfego entre pool de appliances | | Cenário ideal | Minimizar overhead operacional, solução AWS nativa | Migrar políticas de firewall on-premises para a nuvem sem alterações | | Visibilidade | Alertas do Network Firewall → CloudWatch/S3 | Logs nativos do appliance |
No exame, quando o requisito for "usar o appliance de segurança on-premises existente para inspecionar o tráfego AWS", escolha o GWLB. Quando for necessário um "IPS nativo da AWS com filtragem baseada em domínio", escolha o Network Firewall.
---
VPC Endpoint e PrivateLink: Comunicação sem Passar pela Internet
O PrivateLink funciona como uma sala de reuniões privativa: o visitante externo não precisa entrar no seu prédio para se encontrar com você. É possível consumir serviços SaaS ou serviços de outras contas sem expô-los à internet.
Existem dois tipos de VPC Endpoint.
| Item | Gateway Endpoint | Interface Endpoint (PrivateLink) | |------|-----------------|----------------------------------| | Serviços suportados | Apenas S3 e DynamoDB | Maioria dos serviços AWS + serviços personalizados | | Implementação | Adiciona rota na Route Table | Cria ENI (IP privado) dentro da VPC | | Custo | Gratuito | Cobrança por hora + tarifa de processamento de dados | | Conexão on-premises | Não suportado (apenas dentro da VPC) | Suportado (acesso via Direct Connect/VPN) | | Private DNS | Não se aplica | Quando ativado, roteia todo o domínio do serviço para o VPC Endpoint |
A configuração de Private DNS do Interface Endpoint é uma armadilha clássica nos exames. Quando o Private DNS está ativado, todo o domínio do serviço (por exemplo, ) é roteado para o IP do VPC Endpoint. Nesse caso, se a mesma VPC também precisar acessar APIs públicas, as requisições para essas APIs podem ser bloqueadas de forma não intencional. Em ambientes onde coexistem APIs públicas e privadas, desative o Private DNS e configure manualmente o DNS apenas para as APIs privadas.
A VPC Endpoint Policy limita, usando linguagem de políticas IAM, quais recursos podem ser acessados através do Endpoint. É possível vincular uma política ao Gateway Endpoint do S3 para permitir apenas buckets específicos, ou restringir o Interface Endpoint para chamar apenas determinadas APIs.
O AWS Systems Manager Session Manager permite acesso seguro a instâncias EC2 sem IP público nem Bastion, bastando ter três Interface Endpoints: , e . O EC2 Instance Connect Endpoint possibilita conexão SSH via navegador sem precisar abrir a porta SSH para a internet.
---
Opções de Segurança em Transit Gateway, Direct Connect e VPN (incluindo MACsec)
Em ambientes com múltiplas VPCs ou que precisam de conectividade on-premises, o Transit Gateway atua como hub central. Ele conecta centenas de VPCs e redes on-premises a um único ponto, e as Transit Gateway Route Tables permitem controlar com granularidade fina o escopo de comunicação entre VPCs. Padrões muito comuns no exame incluem isolar a VPC de desenvolvimento e a de produção em Route Tables diferentes, ou usar uma Security VPC como hub para forçar que todo o tráfego passe pelo firewall.
O Direct Connect conecta o ambiente on-premises à AWS por meio de um link dedicado