WAF, CDN e proteção de borda: segurando ataques antes da aplicação

A melhor requisição maliciosa é aquela que nunca chega ao seu servidor. Essa é a ideia por trás da proteção de borda: em vez de deixar que todo o tráfego da internet bata direto na sua aplicação, você coloca uma camada de defesa distribuída na frente, que inspeciona, filtra e absorve o que é perigoso antes que ele consuma um único ciclo de CPU do seu backend. Quando um ataque de negação de serviço com terabits de tráfego ou uma onda de bots maliciosos precisa ser contido, o pior lugar para fazer isso é dentro da sua aplicação, que tem recursos finitos e não foi feita para essa briga.

A borda combina três capacidades que hoje costumam vir juntas: a CDN, que distribui e acelera o conteúdo, o WAF, que filtra requisições maliciosas, e a mitigação de DDoS, que absorve ataques volumétricos. Este guia explica como cada uma funciona, a anatomia dos ataques de negação de serviço por camada, quando usar um WAF gerenciado ou próprio, e como bot management e rate limiting na borda completam a defesa.

Por que defender na borda

Colocar a defesa na borda tem uma lógica de escala e de posição. A infraestrutura de borda de um bom provedor é globalmente distribuída e dimensionada para lidar com volumes que nenhuma aplicação individual suportaria. Ela absorve o tráfego perto de onde ele se origina, filtra o lixo e entrega ao seu servidor apenas o que é legítimo. Três ganhos diretos:

• O ataque não consome seus recursos: requisições bloqueadas na borda nunca tocam seu backend, seu banco ou sua largura de banda.
• Capacidade de absorção massiva: a borda dilui um ataque volumétrico por dezenas de pontos de presença, em vez de concentrá-lo em um alvo único.
• Menor latência para o usuário legítimo: a mesma CDN que protege também aproxima o conteúdo de quem acessa.

A CDN, aliás, é frequentemente subestimada como camada de segurança. Além de acelerar, ela esconde o IP de origem do seu servidor e serve conteúdo em cache mesmo sob picos, funcionando como uma primeira muralha natural.

Anatomia do DDoS: camadas 3, 4 e 7

Um ataque DDoS (Distributed Denial of Service) tenta tornar um serviço indisponível sobrecarregando-o a partir de muitas origens ao mesmo tempo, tipicamente uma botnet. Nem todo DDoS é igual, e a defesa muda conforme a camada atacada.

Tipo	Camada	Como funciona	Medida em	Defesa principal
Volumétrico	3 (rede)	Inunda a banda com tráfego bruto	Gbps / Tbps	Absorção distribuída na borda
Protocolo	4 (transporte)	Exaure tabelas de conexão (ex: SYN flood)	Pacotes por segundo	Filtragem de estado, SYN cookies
Aplicação	7 (HTTP)	Requisições que parecem legítimas mas esgotam o app	Requisições por segundo	WAF, rate limiting, bot management

Os ataques de camada 3 e 4 são força bruta: enchem o cano ou estouram as conexões. A defesa é ter um cano muito maior e filtros de rede rápidos, exatamente o que a borda distribuída oferece.

Os ataques de camada 7 são os mais insidiosos. Em vez de volume bruto, eles enviam requisições que parecem legítimas (uma busca cara, um login, uma página que aciona processamento pesado), mas em quantidade suficiente para derrubar a aplicação com um tráfego relativamente baixo. Distinguir esse ataque de usuários reais exige inteligência, não só capacidade, e é aí que WAF, rate limiting e bot management entram.

WAF: o filtro de requisições maliciosas

O WAF (Web Application Firewall) opera na camada 7, inspecionando cada requisição HTTP em busca de padrões de ataque antes que ela chegue à aplicação. Ele é a linha que barra tentativas de injeção, cross-site scripting, exploração de vulnerabilidades conhecidas e outras classes do OWASP. Pense nele como um porteiro que lê cada pedido e recusa os que carregam má intenção.

Um WAF trabalha com conjuntos de regras. Os mais comuns combinam:

• Regras gerenciadas: conjuntos mantidos pelo provedor (como o OWASP Core Rule Set), atualizados continuamente contra novas ameaças.
• Regras personalizadas: ajustadas ao seu contexto, para bloquear ou permitir padrões específicos do seu negócio.
• Reputação e assinatura: bloqueio de origens sabidamente maliciosas e de payloads com assinaturas conhecidas.

Vale reforçar que o WAF complementa, não substitui, o código seguro. Ele é uma camada de defesa em profundidade: reduz a exposição e ganha tempo, mas uma aplicação com falha de autorização continua vulnerável a quem burla o filtro. A defesa real da API, como controle de acesso e tratamento de entrada, continua sendo responsabilidade da aplicação.

WAF gerenciado versus próprio

Uma decisão comum é entre um WAF gerenciado (operado pelo provedor de borda) e um WAF próprio (que você hospeda e administra).

• Gerenciado: o provedor cuida da infraestrutura, das atualizações de regras e da escala. É a escolha da maioria, por reduzir o esforço operacional e já vir integrado à CDN e à mitigação de DDoS. Menos controle fino, muito menos trabalho.
• Próprio: máximo controle e customização, ao custo de operar, atualizar e escalar a solução você mesmo. Faz sentido para requisitos muito específicos ou ambientes com restrições particulares.

Para a maioria das empresas, o WAF gerenciado na borda oferece o melhor equilíbrio: proteção forte, atualizada e sem o peso de manter mais uma peça de infraestrutura crítica.

Bot management e rate limiting na borda

Boa parte do tráfego da internet não é humana. Alguns bots são bons (buscadores), muitos são ruins (raspadores de conteúdo, testadores de credenciais, ferramentas de fraude). O bot management distingue uns dos outros por comportamento, impressão digital e reputação, permitindo o tráfego legítimo e barrando o abusivo antes que ele chegue à aplicação. É a defesa contra ataques como credential stuffing (teste em massa de credenciais vazadas) e scraping agressivo.

O rate limiting na borda completa o quadro, limitando quantas requisições uma mesma origem pode fazer em um intervalo. Aplicá-lo na borda, e não só na aplicação, tem uma vantagem clara: o excesso é cortado longe do seu backend, protegendo tanto a infraestrutura quanto a lógica de negócio. Rotas sensíveis, como login e reset de senha, merecem limites bem mais rígidos. Esse controle na borda trabalha em conjunto com o rate limiting da própria API, que segue essencial para proteger a lógica de negócio de forma granular; as duas camadas se reforçam.

Uma defesa em camadas na entrada

Reunindo as peças, a borda forma uma sequência de filtros por onde toda requisição passa antes de tocar a aplicação:

• A CDN serve cache, esconde a origem e distribui a carga.
• A mitigação de DDoS absorve enchentes de camada 3 e 4.
• O WAF barra requisições maliciosas de camada 7.
• O bot management separa humanos de máquinas abusivas.
• O rate limiting contém volume anormal por origem.

Só o que sobrevive a todos esses filtros chega ao seu servidor. É a materialização do princípio de que a defesa deve começar o mais longe possível do ativo protegido.

A borda é onde a defesa começa, não onde ela termina

Proteção de borda não é uma bala de prata, e sim a primeira e mais ampla linha de uma defesa em profundidade. Ela absorve o que é volumoso, filtra o que é obviamente malicioso e distingue o robô abusivo do usuário real, tudo antes que esse tráfego consuma um recurso sequer da sua aplicação. Isso libera o backend para fazer o que deve: servir bem quem é legítimo. Mas a borda protege o que está atrás dela na medida em que o que está atrás também é seguro; ela ganha tempo e reduz ruído, não perdoa código inseguro.

Na ConstructorTI, ajudamos empresas a desenhar e operar essa camada de borda: configuração de WAF gerenciado com regras ajustadas ao negócio, estratégia de mitigação de DDoS nas camadas 3, 4 e 7, bot management contra credential stuffing e scraping, e rate limiting coordenado entre borda e aplicação. Se o seu serviço está exposto à internet e você quer parar os ataques antes que eles cheguem ao seu código, converse com o nosso time de CyberSecurity.