Mitigação DDoS no Brasil: como avaliar fornecedores, ISPs e cláusulas contratuais locais

Quando um ataque DDoS atinge sua aplicação crítica, a diferença entre interrupção curta e downtime prolongado muitas vezes não é tecnologia abstrata, mas onde o tráfego é absorvido e como seu provedor articula isso com ISPs locais. Em operações corridas no Brasil, equipes de infraestrutura já viram mitigadores globais que bloqueiam tráfego na borda internacional — e ainda assim clientes brasileiros sofrerem impacto por peering fechado ou rotas domésticas saturadas. A tese prática aqui: exija presença e evidências locais, cláusulas claras de failover e testes controlados para que o contrato reflita o comportamento real da rede brasileira.

Este guia detalha o que pedir a fornecedores, que provas técnicas validar e como traduzir requisitos de arquitetura em cláusulas contratuais que você pode negociar. Há trade‑offs inevitáveis — custo, latência e complexidade de roteamento — e este texto mostra cenários aplicáveis para diferentes perfis de risco. Onde couber, há exemplos ilustrativos; não são cases, são padrões para você reproduzir e exigir no contrato.

Por que a geografia importa: peering, POPs e ISPs no Brasil

No Brasil, três elementos transformam a eficácia da mitigação: onde estão os pontos de presença (POPs) do fornecedor; como esses POPs fazem peering com operadoras locais; e quais políticas de roteamento (BGP) as ISPs implementam durante eventos de pico. Um mitigador com POPs físicos em São Paulo e boa conectividade com as grandes operadoras consegue absorver tráfego antes que ele chegue à sua rede de trânsito doméstico. Sem isso, um ataque volumétrico pode congestionar links domésticos ou forçar medidas de blackholing na borda do ISP, ocasionando indisponibilidade.

O que a presença local garante — e o que não garante

Presença local reduz latência e aumenta chance de tratamento do tráfego dentro do território. Porém, ter um POP no Brasil não substitui peering ativo com os ISPs que atendem seu público. Um POP sem acordos de peering relevantes pode continuar a encaminhar tráfego por rotas internacionais, criando gargalos. Em resumo: exija POPs e verifique o mapeamento de peering com as operadoras que importam para sua jornada de usuário.

Critérios mínimos para fornecedores: presença, capacidade e evidências

Ao avaliar fornecedores, use critérios que possam ser verificados tecnicamente e contratualmente. Não basta confiar em declarações de marketing; peça artefatos e direitos contratuais de auditoria.

• Presença física e peering: solicite a lista de POPs no Brasil e mapas de conectividade L2/L3 que indiquem peering com as principais ISPs locais. Quando possível, peça confirmações de peering (ex.: ASN e perfis de rota) ou autorização para verificar via ferramentas públicas.
• Capacidade e escopo de mitigação: exija descrições técnicas do que é mitigado (camada 3/4, camada 7, estado por sessão) e limites de inspeção. Prefira fornecedores que especifiquem os mecanismos (rate‑limiting, blacklisting por padrão, challenge‑response) e ofereçam mitigação de aplicação em tempo real.
• Evidências técnicas exigíveis: logs de borda contendo timestamps, hashes de sessão, cabeçalhos X‑Forwarded‑For e cabeçalhos específicos de mitigador; capturas de fluxo (NetFlow/sFlow) agregadas; e snapshots de métricas durante o evento. Esses artefatos devem ter assinaturas ou outras formas de validação para evitar manipulação.
• Direitos de auditoria e execução de testes: inclua no contrato a permissão para executar testes controlados (com limites e aviso às operadoras) e o direito de auditoria técnica após um incidente.

Cenários de arquitetura recomendada por risco de negócio

As decisões de arquitetura dependem do quanto uma jornada pode tolerar latência, perda de sessão ou reroteamento. Abaixo, três cenários ilustrativos para orientar escolhas — são exemplos conceituais, adaptáveis à sua realidade.

1) Aplicação de baixo tolerância a latência e alta criticidade (ex.: trading interno)

• Garantia: mitigar localmente em SP com POPs ativos e peering direto pelas ISPs que abrigam seu público.
• Arquitetura: tráfego direto para POP local com failover automático para um POP secundário, e encaminhamento apenas por rotas anunciadas aos ISPs primários.
• Contrato: cláusula de failover com SLAs por perda de sessão e obrigação de provas técnicas (headers de borda, NetFlow).

2) Aplicação pública média (site institucional, e‑commerce)

• Combinação de CDN como primeira linha para cache e mitigador gerenciado para ataques dinâmicos de camada 7.
• Arquitetura: CDN na borda + encaminhamento para mitigador com POPs no Brasil quando o tráfego efetivo ultrapassar thresholds.
• Contrato: evidências de mitigação por evento, e definições claras de thresholds que acionam mitigação ativa.

3) Serviços com tolerância a latência maior (aplicações internas não sensíveis a RTT)

• Centralizar mitigação internacional pode ser aceitável se rotas domésticas estiverem sob controle e houver redundância de ISP.
• Arquitetura: tunelamento BGP para um scrubbing center regional com acordos de trânsito claros.

Cláusulas contratuais e evidências técnicas exigíveis

Transforme requisitos técnicos em cláusulas práticas. Abaixo estão exemplos de redação que servem como template para negociar, apresentados como ilustrações que sua equipe jurídica pode adaptar:

Cláusula de presença e conectividade

"O fornecedor declara possuir POPs operacionais em [cidade(s)] no Brasil e manterá peering técnico com os ASNs listados no Anexo A. O fornecedor permitirá, mediante aviso prévio e acordo operacional, a verificação de rotas e status de peering por ferramentas públicas e técnicas designadas pelo cliente."

Cláusula de evidência por incidente

"Por evento de mitigação que exceda os thresholds estabelecidos no Anexo B, o fornecedor entregará ao cliente: (i) logs de borda com carimbo de tempo; (ii) amostra agregada de NetFlow/sFlow; (iii) headers HTTP relevantes (incluindo X‑Forwarded‑For e campos de mitigador). Os artefatos serão assinados digitalmente e retidos por prazo definido no Anexo C."

Cláusula de failover e orquestração de roteamento

"O fornecedor manterá procedimentos documentados de failover BGP, incluindo playbooks para mudança de rota que minimizem perda de sessão. Mudanças que impliquem reroute superior a [X] minutos exigirão notificação e coordenação com os ISPs afetados. O fornecedor é responsável por coordenar a comunicação com ISPs quando sua ação for necessária para mitigar impacto na rede doméstica do cliente."

Cláusula de testes controlados

"O cliente terá direito a até [n] testes controlados por ano, definidos em plano de testes mutuamente acordado, incluindo limites de potência, alvos e janela de execução. Os testes não deverão gerar ataques reais a terceiros e seguirão legislação aplicável e regras da operadora."

Que evidências técnicas pedir durante a contratação?

Peça exemplos de artefatos já produzidos em auditorias (amostras, não dados de clientes reais) e um checklist de entrega em caso de incidente. Evidências úteis e verificáveis incluem:

• Captura de cabeçalhos HTTP com timestamp e identificação do POP.
• Fluxos NetFlow/sFlow agregados para o período do evento.
• Snapshots de métricas de borda (pps, bps por prefixo) correlacionadas com logs de aplicação.
• Relatório de ações tomadas e hashes de integridade dos artefatos entregues.

Testes aceitáveis e limites éticos/legais

Testes de mitigação devem ser controlados, notificados às operadoras e desenhados para não violar legislação ou políticas das ISPs. Nunca execute testes que provoquem tráfego real a terceiros sem autorização. Em contratos, defina escopo, metodologia e autorização formal de trabalho conjunto entre fornecedor, cliente e ISPs quando o teste envolver reroute ou anúncios BGP.

Trade‑offs: custo, latência e risco de blackhole

Mitigar localmente geralmente custa mais por exigir infraestrutura regional e acordos de peering, mas reduz latência e risco de impacto local. Mitigação apenas internacional pode reduzir custo, mas aumenta chance de congestionar links domésticos ou acionar blackholing por ISPs. Avalie o trade‑off com base no impacto de negócio do downtime e no perfil de tráfego — tráfego sensível à latência exige investimento em presença local.

Checklist prático para contratação

1. Solicitar lista de POPs no Brasil e confirmar ASNs de peering.
2. Exigir exemplos de evidências (logs, NetFlow/sFlow, headers) e direito contratual de auditoria.
3. Incluir cláusulas de failover BGP e playbooks operacionais no contrato.
4. Definir thresholds que acionam mitigação ativa e tipos de evidências por nível de evento.
5. Negociar direito a testes controlados e sua metodologia, com coordenação de ISPs.
6. Conferir custo x latência x risco de blackholing para o seu perfil de tráfego.

Perguntas frequentes

É suficiente usar um CDN global para mitigar DDoS no Brasil?

Não necessariamente. Um CDN pode atender bem a ataques de cache estático e reduzir parte da carga, mas não substitui mitigação de tráfego dinâmico ou sessão‑dependente se o CDN estiver sem peering adequado localmente. Combine CDN com mitigador que tenha presença e acordos com ISPs relevantes.

Como comprovar que um fornecedor realmente mitigou um ataque?

Exija artefatos assinados: logs de borda com timestamps, NetFlow/sFlow agregados, headers que mostrem a inserção do mitigador. Correlacione essas evidências com métricas de aplicação e com relatórios das ISPs quando aplicável.

Quais cláusulas reduzem risco sem onerar demais o orçamento?

Negocie SLAs focados em entrega de evidências e playbooks de ação ao invés de penalidades onerosas. Exigir transparência operacional, direitos de auditoria e testes controlados tende a trazer melhor garantia de comportamento sem custos excessivos.

Onde a Shield entra nessa jornada

A Shield pode ajudar a traduzir requisitos técnicos em cláusulas contratuais e conduzir avaliações arquiteturais e testes controlados que validem cobertura local no Brasil. Oferecemos suporte para mapear peering relevante, revisar playbooks de failover e definir evidências técnicas exigíveis. Para soluções de endurecimento de aplicação e operação contínua, considere também nossos produtos L7 Hardening — proteger rotas críticas, Website Security — mitigação e operação contínua e DNS & Edge gerenciado como componentes complementares da sua estratégia.

Próximo passo: Solicite avaliação arquitetural e teste controlado com especialistas da Shield.