Quando a API Vira a Porta da Frente
Nos últimos anos, APIs deixaram de ser detalhe técnico e viraram o ponto central de qualquer arquitetura moderna. Aplicativos mobile, integrações com parceiros, microsserviços comunicando entre si — tudo passa por API. E onde trafega dado e lógica de negócio, existe alvo para ataque.
O problema é que muitas equipes protegem a aplicação inteira mas deixam a API exposta. Têm firewall na rede, HTTPS configurado, security groups bem definidos — mas qualquer pessoa com um token válido (ou com paciência para tentar sem token) pode bombardear endpoints, tentar injeções de SQL, fazer scraping automatizado ou causar um denial of service baseado em volume de requisições.
O AWS WAF (Web Application Firewall) é a camada que senta na frente do seu API Gateway, Application Load Balancer ou CloudFront e inspeciona cada requisição antes de ela chegar na sua aplicação. Este artigo mostra como configurá-lo de forma prática nos 3 passos que realmente importam.
1. Ative os Managed Rule Groups e pare de reinventar a roda
O primeiro instinto de quem configura WAF pela primeira vez é criar regras customizadas do zero. Mas antes de qualquer customização, existe um atalho poderoso que a maioria das equipes subutiliza: os Managed Rule Groups.
São conjuntos de regras mantidos pela própria AWS (e por parceiros de segurança certificados) que cobrem as ameaças mais comuns e são atualizados automaticamente conforme novos vetores de ataque emergem. Você não precisa saber como funciona uma injeção de Log4Shell para se proteger dela — a AWS já escreveu a regra.
Os grupos essenciais para proteger APIs
AWS Managed Rules – Core Rule Set (CRS): O ponto de partida obrigatório. Cobre as vulnerabilidades do OWASP Top 10, incluindo SQL Injection, Cross-Site Scripting (XSS), inclusão de arquivos e tentativas de exploração de vulnerabilidades conhecidas. Para a maioria das APIs REST, este grupo sozinho bloqueia a grande maioria dos ataques automatizados.
AWS Managed Rules – Known Bad Inputs: Identifica padrões de requisição que nunca deveriam aparecer em tráfego legítimo, tentativas de exploração de Log4JRCE, Server-Side Request Forgery (SSRF), e outros payloads de exploração conhecidos. Não há motivo para não ativar este grupo.
AWS Managed Rules – Amazon IP Reputation List: Bloqueia IPs com histórico comprovado de atividade maliciosa — bots, scanners, servidores conhecidos por lançar ataques. Essa lista é atualizada continuamente pela equipe de inteligência de ameaças da Amazon.
AWS Managed Rules – Bot Control: Para APIs que sofrem com scraping automatizado ou tentativas de credential stuffing (ataque que testa listas de usuário/senha em massa), o Bot Control identifica e bloqueia bots com base em análise comportamental, não apenas por IP ou User-Agent.
Comece em modo Count, não Block
Uma armadilha clássica é ativar os Managed Rules direto em modo Block e descobrir que sua própria aplicação gera requisições que ativam algumas regras — resultando em falsos positivos que quebram funcionalidades.
O processo correto é:
- Ative todos os grupos em modo Count por uma semana.
- Analise os logs no CloudWatch e identifique se alguma requisição legítima está sendo sinalizada.
- Adicione exceções para os falsos positivos encontrados.
- Mude para modo Block.
2. Configure Rate Limiting por IP para bloquear força bruta e scraping
Mesmo com todos os Managed Rules ativos, um atacante com paciência pode tentar um ataque de baixo volume — testando senhas uma a uma por hora, ou raspando dados aos poucos para não disparar alertas de volume. A proteção contra isso é o Rate Limiting.
Rate Limiting no AWS WAF funciona assim: você define um limite de requisições por janela de tempo (por padrão, 5 minutos), e qualquer IP que exceder esse limite tem suas requisições bloqueadas pelo tempo que você definir.
Como calibrar os limites sem bloquear usuários legítimos
O segredo está em ter limites diferentes por endpoint, não um limite global para toda a API.
Considere estes exemplos:
- Endpoint de login (
/auth/login): Limite agressivo — 10 requisições por 5 minutos por IP. Um usuário humano nunca precisa tentar login 10 vezes em 5 minutos. Quem excede isso é um script de força bruta. - Endpoint de busca (
/api/search): Limite moderado — 100 requisições por 5 minutos. Um usuário ativo pode pesquisar bastante, mas 100 vezes em 5 minutos é claramente automatizado. - Endpoint de checkout ou pagamento: Limite conservador — 20 requisições por 5 minutos. Protege contra ataques de card testing (onde atacantes testam cartões roubados automaticamente).
- APIs públicas de dados: Limite mais permissivo — 500 requisições por 5 minutos, mas com alerta de monitoramento a partir de 200.
Rate Limiting por Header, não apenas por IP
Para APIs que usam autenticação por token (JWT, API Keys), você pode ir além do Rate Limiting por IP e criar regras baseadas no header de autorização. Isso permite criar limites por usuário autenticado, não por IP — útil quando múltiplos usuários compartilham o mesmo IP (redes corporativas, por exemplo) ou quando um atacante usa múltiplos IPs para contornar o limite por IP.
3. Monitore com CloudWatch e crie alertas antes de virar incidente
Configurar o WAF e nunca olhar os logs é como instalar câmeras de segurança sem monitorar as gravações. O ataque pode estar acontecendo agora e você só vai descobrir quando a aplicação cair ou os dados vazarem.
Ative os logs do WAF no S3 ou CloudWatch Logs
Por padrão, o AWS WAF não registra nada. Você precisa ativar explicitamente o logging em “Logging and metrics” na configuração do Web ACL. As opções são S3 (mais barato para volume alto, mas com latência de consulta), CloudWatch Logs (melhor para alertas em tempo real) ou Kinesis Data Firehose (para integração com SIEM ou análise avançada).
Para a maioria dos ambientes, CloudWatch Logs é o equilíbrio certo. O custo é administrável e você ganha a capacidade de criar métricas e alarmes diretamente.
Os alertas que você deve criar hoje
Pico de requisições bloqueadas: Se o WAF normalmente bloqueia 50 requisições por hora e de repente bloqueia 5.000, algo mudou. Pode ser um ataque em andamento, pode ser um falso positivo em massa — em ambos os casos, você precisa saber. Crie um alarme no CloudWatch que dispara quando o número de requisições bloqueadas excede 3x a média das últimas 24 horas.
Regra específica disparando muito: Se a regra de SQL Injection começa a disparar muito mais que o normal, alguém pode estar testando vulnerabilidades na sua API. Um alarme dedicado para as regras mais críticas do CRS dá visibilidade granular.
IPs repetidamente bloqueados: Com um filtro nos logs do WAF, você pode identificar IPs que são bloqueados repetidamente ao longo do dia — candidatos a serem adicionados à sua IP Deny List permanentemente, mesmo que o ataque esteja abaixo do threshold de Rate Limiting.
O Dashboard de Segurança no Console
O AWS WAF oferece um painel nativo com gráficos de requisições permitidas vs. bloqueadas, distribuição por regra ativada e top IPs. Revise esse painel semanalmente. Padrões incomuns são mais fáceis de detectar quando você tem uma referência de “semana normal” bem estabelecida.
Conclusão
Proteger APIs não é uma tarefa que se faz uma vez e esquece. Ameaças evoluem, novos endpoints são criados, padrões de tráfego mudam. O AWS WAF, configurado com Managed Rules atualizadas automaticamente, Rate Limiting calibrado por endpoint e monitoramento ativo, transforma a segurança de algo reativo (“respondemos ao ataque”) para algo proativo (“bloqueamos antes de causar dano”).
O custo do WAF é calculado por Web ACL + regras ativas + volume de requisições inspecionadas. Para a maioria das aplicações de médio porte, fica na faixa de $20 a $100 por mês — uma fração do custo de um único incidente de segurança.
