Na manhã de 18 de novembro de 2025, uma falha na infraestrutura da Cloudflare transformou a internet em um mosaico de erros 500 e páginas em branco. X, ChatGPT, Spotify, plataformas educacionais, serviços de pagamento e até sistemas internos de empresas ficaram indisponíveis ou altamente instáveis ao mesmo tempo, em vários países.
O curioso é que os servidores de muitos desses serviços continuaram “vivos” no back-end. O que desabou foi uma camada intermediária: a nuvem de um provedor que hoje está entre os principais pontos de passagem da web mundial, cuidando de desempenho, DNS, CDN e proteção contra ataques para algo em torno de um quinto do tráfego global.
A imagem que melhor explica o que vimos é a do “castelo de um pilar”. A internet foi pensada como uma rede distribuída, capaz de encontrar novas rotas quando uma falha acontece. Na prática, porém, empilhamos serviços críticos (pagamentos, login, notícias, APIs) sobre um único pilar de infraestrutura. Quando esse pilar cai, o castelo inteiro desaba junto. É isso que o Cloudflare outage de hoje escancarou, com implicações diretas em Cloudflare outage segurança e resiliência digital.
O que aconteceu no Cloudflare outage de 18 de novembro
Do ponto de vista técnico, a Cloudflare atua como uma espécie de “centrão” da internet: resolve nomes de domínio com DNS, entrega conteúdo em alta velocidade com CDN e filtra tráfego malicioso antes que ele chegue ao servidor de origem.
Na queda de hoje, uma combinação infeliz de lógica de software e configuração automatizada saiu do controle. A empresa informou que um arquivo de configuração, usado para gerenciar ameaças de segurança, cresceu demais e derrubou o sistema responsável por roteamento de tráfego em vários serviços, gerando uma onda de erros e timeouts em escala global. Ao mesmo tempo, houve um “spike” incomum de tráfego para um dos serviços da Cloudflare, agravando o cenário.
A boa notícia, pelo menos nesta dimensão, é que não há evidências de ciberataque. A própria Cloudflare e executivos de segurança reforçaram que se trata de uma falha interna, disparada por mudanças de rotina, não por um invasor externo.
Mas é aqui que entra o ponto mais incômodo: se uma mudança “normal” de configuração em um único provedor é capaz de derrubar, em efeito cascata, partes importantes da economia digital, o problema deixa de ser técnico e passa a ser estrutural.
O risco sistêmico da centralização
Fernando de Falchi, gerente de Engenharia de Segurança da Check Point Software Brasil, resume bem o dilema. De um lado, plataformas gigantes como Cloudflare, AWS e Azure entregam escala, baixo custo e ferramentas de segurança que democratizaram recursos antes exclusivos de grandes empresas. De outro, concentram tanto tráfego e tanta lógica de negócio que qualquer instabilidade vira terremoto mundial.
O outage de hoje repete o roteiro que já vimos recentemente em grandes interrupções da AWS e da Azure. Em todos esses casos, não foi cada banco, cada e-commerce ou cada portal de notícias que “quebrou” isoladamente, e sim uma única camada compartilhada da nuvem que deixou de responder. O resultado é um risco de risco sistêmico: uma falha localizada em um backbone vira instabilidade global.
O Guardian já havia descrito esse cenário como uma “cadeia de dependência”: poucos provedores, mesma base de serviços críticos, mesma lógica de concentração. Cloudflare para aceleração e proteção, hyperscalers para computação e dados. Juntos, esses gigantes respondem por boa parte da infraestrutura que sustenta bancos, e-commerces, mídia, governos e startups do mundo todo.
Falchi alerta que muitas organizações ainda tratam toda a sua presença digital como se houvesse “uma única rota para tudo”, sem um plano B significativo. A frase dele que deveria virar pôster em qualquer sala de TI é simples: enquanto não houver diversidade e redundância reais no sistema, “cada interrupção afetará as organizações e as pessoas mais do que deveria”.
Em outras palavras, a internet que deveria ser distribuída está se comportando como um monolito com poucos pontos de falha.
O que fazer no pânico: alerta de segurança
Quando um incidente desse porte acontece, o instinto natural é “deixa tudo passar, só volta o site”. É justamente nesse momento que a segurança corre mais risco.
Oded Vanunu, gerente de Pesquisa de Vulnerabilidades da Check Point, faz um alerta importante: na pressa para fazer o serviço voltar, times acabam mudando DNS às cegas, removendo políticas de cache, abrindo portas extras no origin ou desligando proteções da borda. Ele lembra que mudanças apressadas de configuração podem “remover camadas de proteção como WAF ou mitigação de DDoS e ampliar a superfície de ataque”, deixando servidores expostos em pleno caos operacional.
Em termos práticos, isso significa que um Cloudflare outage segurança mal gerenciado pode transformar uma falha acidental em um incidente de segurança real, com vazamento de dados, exploração de APIs expostas e compromissos de SLA estourados. Atacantes adoram esse tipo de ruído: logs cheios, equipes sob pressão, várias mudanças simultâneas e poucas pessoas olhando para o impacto de segurança de cada ajuste.
Por isso, um dos elementos-chave de resiliência é ter runbooks claros: o que pode ser temporariamente flexibilizado, o que jamais deve ser desligado e quais etapas de rollback precisam estar ensaiadas antes da crise.
Diversidade como estratégia de segurança, não luxo
Qual é, então, o caminho para reduzir esse risco sistêmico sem abrir mão dos benefícios da nuvem? A palavra-chave, aqui, é diversidade. Não apenas como conceito bonito, mas como arquitetura concreta.
Alguns princípios que emergem desse incidente:
- Multi-DNS de verdade
Domínios críticos não deveriam depender de um único provedor de DNS. Ter ao menos dois provedores autoritativos, com sincronização de registros e TTLs pensados para failover, é hoje uma necessidade básica para quem depende da internet para faturar. - Multi-CDN e caminhos alternativos
Um desenho de CDN em que tudo passa por um único player cria o “pilar único” do castelo. Estratégias de multi-CDN, ou ao menos rotas de escape bem definidas para acesso direto ao origin com degradação controlada de performance, reduzem o impacto quando um provedor tem problemas. - Separar entrega de conteúdo de segurança
Se todo o seu WAF e sua proteção de DDoS residem apenas na borda de um único serviço, qualquer queda desse serviço obriga você a escolher entre ficar fora do ar ou expor o origin nu. Ter camadas adicionais, como WAF no próprio cloud provider, regras de firewall em nível de aplicação e acordos com ISPs para filtragem volumétrica, dá margem para decisões menos desesperadas. - Runbooks e simulações de crise
Não basta ter arquitetura bonita no diagrama. É preciso treinar o time para usá-la sob pressão. Simular outages de provedor (incluindo algo como o de hoje) ajuda a encontrar pontos cegos: registros DNS que ninguém sabe onde estão, integrações que não têm fallback, segredos que só uma pessoa conhece. - Rever SLAs e métricas de resiliência
Em vez de olhar só para o SLA de cada fornecedor isoladamente, vale criar indicadores que reflitam o risco agregado. O que acontece se Cloudflare, AWS ou Azure tiverem uma indisponibilidade regional? Qual é o RTO real em um cenário desses? Existe dashboard que mostre essa visão de forma integrada?
No fim, o episódio de hoje não é apenas mais um “apagão da internet”. Ele é um lembrete de que perseguir eficiência absoluta concentrando tudo em poucos provedores tem um preço em fragilidade. Construir com diversidade, redundância e rotas alternativas não é luxo arquitetural, é política de sobrevivência digital.
