Firewall e Security Groups

Firewalls são o controle de tráfego da rede: decidem o que entra, o que sai e o que é inspecionado no caminho, e em arquitetura de produção eles são a primeira linha de contenção quando a aplicação falha. A diferença conceitual central do tema é stateful contra stateless: um firewall com estado entende conexões e permite automaticamente o retorno do fluxo que ele autorizou, enquanto um firewall sem estado avalia cada pacote isoladamente e exige regra explícita para os dois sentidos. Na AWS, essa distinção se materializa em dois instrumentos complementares: os security groups, com estado, aplicados por instância ou interface de rede, e as network ACLs, sem estado, aplicadas por sub-rede. A relevância arquitetural está no princípio do menor privilégio aplicado à rede: o desenho deve permitir apenas o necessário, com origem identificada, e qualquer permissão ampla é dívida de segurança que se acumula silenciosa. O WAF entra como camada complementar, acima da rede, avaliando o conteúdo da requisição HTTP, e a combinação dos três níveis é o que constitui defesa em profundidade real.

Conceito: stateful versus stateless

O firewall stateful mantém tabela de conexões: quando a regra autoriza a conexão de entrada na porta 443, o pacote de retorno é aceito automaticamente, porque a conexão já existe na tabela. Isso simplifica radicalmente as regras, pois só o sentido iniciante precisa ser declarado, e habilita recursos que dependem do contexto, como identificar tráfego relacionado em FTP e rastrear tempo de vida de sessão.

O firewall stateless não guarda contexto: cada pacote é avaliado sozinho contra a lista de regras, na ordem numérica, e a primeira regra que casa define a ação. Para uma conexão de entrada funcionar, a ACL precisa permitir o pacote de entrada e o pacote de resposta de saída, o que significa regra para a porta de destino e regra para a faixa de portas efêmeras de retorno.

A consequência operacional é direta: regras stateless são mais verbosas, mais propensas a erro e mais difíceis de auditar, mas o custo por pacote é menor e o comportamento é determinístico, sem risco de estouro de tabela de sessões sob ataque. Por isso, o padrão arquitetural na AWS usa a NACL como cinto de segurança bruto na borda da sub-rede, bloqueando CIDRs maliciosos conhecidos, e os security groups como política fina por workload.

Security groups em profundidade

O security group é um firewall virtual com estado associado a instâncias EC2, interfaces elásticas, Lambda em VPC, RDS, ElastiCache e outros serviços. Ele só permite, nunca nega: tudo que não está explicitamente permitido é bloqueado, e a regra declara protocolo, faixa de porta e origem, que pode ser CIDR, prefix list ou outro security group.

A referência entre security groups é o recurso que muda a qualidade do desenho: em vez de permitir a porta 5432 a partir do CIDR da VPC inteira, a regra permite a porta 5432 a partir do security group da camada de aplicação. O resultado é que a permissão acompanha a identidade do workload, e não a topologia, e novas instâncias da aplicação herdam o acesso automaticamente sem tocar em regra nenhuma.

O grupo de saída é a metade esquecida: o default permite tudo para fora, e ambientes maduros o restringem para os destinos reais, como endpoints de serviço da AWS, DNS e ranges de integração. Restringir saída reduz a capacidade de exfiltração de dados e limita a blast radius de uma invasão, e é um dos itens de auditoria mais recorrentes em frameworks de compliance.

# Desenho de três camadas com security groups encadeados (Terraform)
resource "aws_security_group" "alb_publico" {
  name   = "sg-alb-publico"
  vpc_id = aws_vpc.principal.id

  ingress {
    description = "HTTPS do mundo, terminado no balanceador"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    description = "Saida apenas para a camada de aplicacao"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    security_groups = [aws_security_group.app.id]
  }
}

resource "aws_security_group" "app" {
  name   = "sg-camada-app"
  vpc_id = aws_vpc.principal.id

  # Aceita trafego SOMENTE do security group do balanceador,
  # e nao do CIDR da VPC: a origem e a identidade, nao a topologia
  ingress {
    description     = "API vindas apenas do ALB"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb_publico.id]
  }

  egress {
    description = "Acesso ao banco e endpoints AWS"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    security_groups = [aws_security_group.banco.id]
  }
}

resource "aws_security_group" "banco" {
  name   = "sg-camada-banco"
  vpc_id = aws_vpc.principal.id

  ingress {
    description     = "PostgreSQL apenas da camada de aplicacao"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }
}

Network ACLs em profundidade

A network ACL opera na borda da sub-rede e avalia todo pacote que entra e sai dela, sem exceção, incluindo tráfego entre instâncias da mesma sub-rede que se comunica via gateway. Cada sub-rede está associada a exatamente uma ACL, e a ACL default da VPC permite todo tráfego de entrada e saída, o que faz com que sua existência seja invisível até alguém criar regra.

As regras são numeradas de 10 em 10 por convenção, avaliadas da menor para a maior, e a primeira que casa determina a decisão, o que permite reservar números no meio para inserções futuras. A regra declara protocolo, faixa de portas, origem ou destino CIDR e ação de allow ou deny, e o deny explícito é a capacidade que o security group não tem: negar um CIDR específico antes de qualquer regra de permissão.

O fluxo de retorno é a pegadinha clássica da NACL: um cliente na sub-rede A conecta em um servidor na porta 443 e o sistema operacional escolhe uma porta efêmera de retorno, geralmente na faixa 1024 a 65535. A ACL da sub-rede do cliente precisa permitir entrada na 443 e saída na faixa efêmera, e a ACL da sub-rede do servidor o espelho, e restringir demais essa faixa quebra conexões de forma intermitente, conforme a porta sorteada.

O uso produtivo recomendado é contido: bloquear na borda os CIDRs conhecidos como maliciosos, fechar protocolos proibidos por política corporativa, como SMB saindo para a internet, e deixar a política fina para os security groups. Replicar em NACL a política completa por aplicação cria manutenção dupla e erros sutis de retorno.

Firewall de appliance e WAF

Entre os dois extremos existe a terceira camada: firewalls de inspeção, como os appliances virtuais atrás do Gateway Load Balancer, que analisam o conteúdo do pacote, detectam intrusão e aplicam política de rede corporativa em tráfego criptografado com TLS inspection. Esse nível é exigência em ambientes regulados de alta criticidade e tem custo de latência e de licença que precisa entrar na arquitetura.

O WAF opera acima de tudo isso: ele não vê pacote, ele vê requisição HTTP. Regras do AWS WAF no ALB, no CloudFront ou no API Gateway filtram SQL injection, cross-site scripting, padrões de user-agent, limites de taxa por IP e geo-bloqueio, e o bot control distingue tráfego humano de automação. O WAF também é stateful por requisição e cobra por regra e por requisição, o que incentiva conjuntos de regras enxutos e bem testados.

A divisão de responsabilidades correta é: NACL bloqueia endereço na borda, security group define quem alcança qual porta, WAF decide se a requisição HTTP é legítima, e o appliance de inspeção cobre os casos de conteúdo no pacote. Cada camada falha de forma independente, e é essa sobreposição que caracteriza defesa em profundidade, não a quantidade de ferramentas.

Diagnóstico de conexão recusada

O sintoma mais comum de erro de firewall é o timeout de conexão, e a ordem de investigação economiza horas. O timeout em nível de TCP indica pacote descartado silenciosamente, comportamento típico de security group bloqueando, enquanto connection refused indica resposta ativa de que a porta está fechada, o que normalmente significa processo parado no destino e não regra de rede. Nomes de erro diferentes apontam para camadas diferentes, e essa distinção é o primeiro passo.

# Testa a porta do destino a partir de uma maquina na mesma posicao de rede
nc -zv 10.0.2.15 8080

# Timeout com regra certa no SG indica processo parado; refused indica porta fechada
curl -v --connect-timeout 5 http://app-interna.exemplo.com.br:8080/healthz

# Rastreia onde o pacote morre na cadeia de roteamento
traceroute -T -p 8080 10.0.2.15

# No destino, confirma se o processo escuta na interface e porta esperadas
ss -tlnp | grep 8080

A sequência estruturada parte do destino para a borda: confirmar que o processo escuta na porta, confirmar o security group do destino com a origem correta, confirmar a NACL da sub-rede nos dois sentidos, inclusive a faixa efêmera, e confirmar a tabela de rotas da origem. Ferramentas de análise de alcance, como Reachability Analyzer na AWS, automatizam esse raciocínio e mostram qual componente rejeita o caminho, incluindo qual regra específica bloqueou o pacote.

Erros comuns e boas práticas

• Regra de origem em CIDR largo: permitir o CIDR da VPC inteira destrói o isolamento entre camadas; referencie security groups, e não topologia.
• Grupo de saída sempre 0.0.0.0/0: saída irrestrita facilita exfiltração e viola benchmarks de segurança; declare os destinos reais.
• Replicar política completa na NACL: duplicidade com security group gera manutenção dupla e intermitência difícil de diagnosticar na faixa efêmera.
• Números de regra NACL sem espaçamento: regras de 1 em 1 impedem inserção futura; numere de 10 em 10 e documente o esquema.
• Auditoria sem automação: revisão manual de security group envelhece em semanas; use ferramentas de análise de configuração e alerta de regra em 0.0.0.0/0.
• WAF sem modo de contagem antes do bloqueio: ativar regra em modo de bloqueio de imediato bloqueia cliente legítimo; conte primeiro, analise falso positivo e bloqueie depois.
• Exceção permanente virando permanente: regra aberta para debug sem data de validade é a origem recorrente de incidente; toda exceção leva vencimento e dono.

A boa prática estrutural é tratar regra de rede como código revisado: security groups e ACLs declarados em IaC, com pull request, validação automatizada de regra perigosa e etiqueta de dono. A meta arquitetural é que o desenho da rede declare a intenção do negócio em termos de fluxo permitido, e que qualquer tráfego fora do desenho seja exceção visível, rastreável e temporária.