Segurança na Borda com WAF, Shield, CloudFront e Defesa contra DDoS na AWS
_Category: Network Security_
Antes de o tráfego da internet chegar aos servidores de aplicação, ele atravessa inúmeros Edge Locations e balanceadores de carga. O princípio central da segurança é: "bloqueie os ataques o mais longe possível da sua infraestrutura". É muito mais eficiente filtrar ameaças na portaria do edifício do que tentar contê-las quando já estão nos corredores internos. AWS WAF, Shield, CloudFront e AWS Firewall Manager formam exatamente essa linha de defesa avançada — a combinação de serviços de segurança de borda que implementa esse princípio na prática.
---
O Princípio da Defesa de Borda: Bloquear o Mais Longe Possível
Quando um ataque consegue penetrar até dentro da VPC, as instâncias EC2 passam a desperdiçar CPU processando pacotes DDoS e o banco de dados RDS fica exposto a queries de SQL injection. A linha de defesa ideal é a camada Global Edge onde operam o CloudFront e o WAF.
A arquitetura de segurança de borda da AWS funciona em camadas bem definidas. Na camada mais externa, o Shield absorve ataques DDoS de Layer 3 e 4. O CloudFront recebe o tráfego em centenas de Edge Locations ao redor do mundo. Na camada seguinte, o AWS WAF analisa cada requisição HTTP/HTTPS e bloqueia padrões maliciosos. Somente as requisições que passam por essa barreira externa chegam ao Application Load Balancer ou às instâncias EC2.
Quando o WAF é associado ao CloudFront, as regras são executadas em todas as edges globais. Quando associado ao Application Load Balancer, a execução acontece em nível regional. Do ponto de vista de defesa contra DDoS, a combinação CloudFront + WAF filtra o tráfego muito antes de qualquer outro ponto da infraestrutura.
---
Componentes do AWS WAF: Web ACL, Rule, Rule Group e Managed Rules
O AWS WAF funciona como uma cabine de segurança na entrada do edifício. Toda requisição HTTP precisa passar pela inspeção e, com base nas regras configuradas, é permitida ou bloqueada.
A Web ACL é o contêiner principal do WAF. Ela pode ser associada a distribuições do CloudFront, Application Load Balancers, API Gateways e AWS AppSync. Dentro de uma Web ACL existem múltiplas Rules, cada uma com uma prioridade numérica — quanto menor o número, mais cedo a regra é avaliada.
Um Rule Group é um contêiner reutilizável que agrupa múltiplas Rules. As Managed Rules são Rule Groups pré-construídos e continuamente atualizados pela AWS e por parceiros de segurança.
| Categoria | Descrição | Rule Group de Referência | |-----------|-----------|-------------------------| | Core Rule Set (CRS) | Bloqueia ataques web genéricos baseados no OWASP Top 10 | AWSManagedRulesCommonRuleSet | | Known Bad Inputs | Bloqueia padrões de exploração de vulnerabilidades conhecidas | AWSManagedRulesKnownBadInputsRuleSet | | SQL Database | Bloqueia ataques de SQL injection | AWSManagedRulesSQLiRuleSet | | Amazon IP Reputation | Bloqueia IPs maliciosos observados pela AWS | AWSManagedRulesAmazonIpReputationList | | Bot Control | Detecta e bloqueia tráfego de bots | AWSManagedRulesBotControlRuleSet |
IP Sets são contêineres que armazenam até 10.000 IPs ou CIDRs, referenciados pelas Rules. Os logs do WAF são enviados via Kinesis Data Firehose para S3 ou CloudWatch Logs e registram o IP da requisição, a URI, os headers, a regra que foi acionada e o resultado (permitido ou bloqueado). As métricas do CloudWatch oferecem contagens agregadas por regra, mas o rastreamento individual de cada requisição só é possível pelos logs do WAF.
---
Rate-based Rule, Bot Control e Captcha: Barrando Ataques Automatizados
A Rate-based Rule bloqueia automaticamente qualquer IP que ultrapasse um limiar configurado de requisições (mínimo 100) dentro de uma janela de 5 minutos. Combinada com condições de padrão de URI, ela permite restringir seletivamente caminhos específicos sob ataque enquanto mantém o tráfego legítimo fluindo normalmente. Quando um ataque DDoS de Layer 7 está em curso e um URI específico está sendo chamado repetidamente, a combinação Rate-based Rule + condição de URI é a resposta mais rápida e imediata. O suporte DRT do Shield Advanced pode levar horas para atuar — por isso, em ataques ativos, o WAF deve ser o primeiro recurso.
A Geo Match Rule bloqueia ou permite tráfego com base no país de origem. É importante entender a diferença em relação ao Geo Restriction do CloudFront. O Geo Restriction do CloudFront é configurado diretamente nas definições da distribuição, sem necessidade de WAF, sem custo adicional e retorna HTTP 403 para tráfego bloqueado. A Geo Match Rule do WAF é usada quando é necessário combinar condições de país com padrões de URL para um controle mais granular, e incorre nos custos do WAF.
O Bot Control distingue bots legítimos de maliciosos e os trata de forma diferenciada. A ação Captcha apresenta um puzzle CAPTCHA para requisições suspeitas. As Custom Responses permitem personalizar o código HTTP e o corpo da resposta retornados quando uma requisição é bloqueada.
---
Shield Standard vs Shield Advanced: Comparativo, DRT e Cost Protection
O Shield Advanced é como ter uma equipe de segurança especializada disponível 24 horas por dia, 7 dias por semana. Não é apenas um escudo — é uma equipe de especialistas que age imediatamente quando um ataque ocorre.
| Item | Shield Standard | Shield Advanced | |------|----------------|----------------| | Custo | Gratuito (aplicado automaticamente) | US$ 3.000/mês + transferência de dados | | Camadas protegidas | Layer 3/4 | Layer 3/4 + Layer 7 | | Suporte DRT 24/7 | Não incluído | Incluído — resposta em tempo real | | Cost Protection | Não incluído | Incluído — reembolso por escalonamento causado por DDoS | | Métricas CloudWatch | Básicas | Detalhadas, incluindo DDoSDetected | | Detecção baseada em saúde | Não disponível | Baseada em Route 53 Health Checks | | Isenção de custo WAF | Não aplicável | WAF sem custo adicional durante a assinatura |
A métrica DDoSDetected do CloudWatch do Shield Advanced assume o valor 1 quando um ataque é detectado e retorna a 0 quando termina. Configurar um CloudWatch Alarm nessa métrica com um tópico SNS permite receber notificações por e-mail, SMS ou Lambda assim que o ataque começa. Esse é o padrão de arquitetura para alertas de DDoS em tempo real com Shield Advanced.
A Cost Protection cobre custos anômalos de EC2 Auto Scaling, transferência de dados no CloudFront e queries do Route 53 causados por ataques DDoS, reembolsando-os via créditos da AWS. Essa é uma das diferenças fundamentais que o Shield Standard simplesmente não oferece.
!Shield Standard vs Shield Advanced
AWS Firewall Manager: Implantação Centralizada de Políticas para toda a Organização
Quando dezenas ou centenas de contas AWS precisam ser gerenciadas, manter Web ACLs individualmente em cada conta se torna inviável para manter a padronização. O AWS Firewall Manager funciona como a matriz de uma empresa enviando um manual de segurança único para todas as filiais ao mesmo tempo.
O Firewall Manager se integra ao AWS Organizations e permite que uma conta administradora central implante políticas de WAF, proteção do Shield Advanced e políticas de Security Groups para OUs inteiras ou contas específicas de uma só vez. Quando novos recursos são criados e atendem às condições de escopo definidas, a Web ACL é associada automaticamente.
A causa mais comum para ALBs que ficam sem Web ACL associada após a implantação via Firewall Manager é a ausência de tags de escopo. As políticas do Firewall Manager filtram os recursos que entram ou saem do escopo com base em tags. Recursos sem a tag esperada ficam fora do escopo da política.
Comportamento importante: quando uma conta é removida do escopo de uma política do Firewall Manager, as Web ACLs já associadas não são desvinculadas nem excluídas automaticamente — elas permanecem. Após a exclusão do escopo, as alterações na política deixam de ser propagadas automaticamente para essa conta, que precisará gerenciar sua própria Web ACL. Os pré-requisitos para usar o Firewall Manager são: AWS Organizations ativo e uma conta administradora designada.
---
Integração de Segurança no CloudFront: OAC, Signed URL/Cookie e Field-Level Encryption
OAI e OAC são mecanismos para garantir que o S3 só seja acessado via CloudFront, bloqueando o acesso direto ao bucket. O OAC é a abordagem moderna que substitui o OAI.
| Item | OAI (legado) | OAC (atual, recomendado) | |------|-------------|-------------------------| | Tecnologia base | Identidade virtual exclusiva do CloudFront | Principal de serviço IAM (cloudfront.amazonaws.com) | | Suporte a SSE-KMS | Limitado | Completo | | Assinatura dinâmica SigV4 | Não disponível | Disponível | | Recomendação | Evitar em novas configurações | Recomendado |
A combinação OAC + WAF IP Set é o padrão para implementar simultaneamente o bloqueio de acesso direto ao S3 e a restrição de acesso por IP. O uso de aws:SourceIp na política de bucket do S3 não funciona para filtrar IPs de clientes porque o CloudFront usa seus próprios endereços IP ao encaminhar requisições para o S3.
Signed URL controla o acesso a um arquivo único. Signed Cookie controla o acesso a múltiplos arquivos ou caminhos com um único cookie. Para serviços de streaming onde apenas assinantes podem acessar o conteúdo, o Signed Cookie é a opção mais adequada.
Field-Level Encryption criptografa campos específicos de requisições POST diretamente no edge do CloudFront usando uma chave pública, antes de encaminhar ao backend. Dados sensíveis como informações de pagamento nunca ficam expostos em texto puro. A diferença em relação ao KMS é que o KMS realiza criptografia no servidor no momento do armazenamento, enquanto o Field-Level Encryption criptografa seletivamente campos específicos em trânsito, no edge. O CloudFront Origin Failover é um recurso de alta disponibilidade que redireciona automaticamente para a origem secundária de um