Segurança para Provedores de CDN e Edge: contendo envenenamento de cache e blindando a infraestrutura multi-tenant
Provedores de CDN e edge servem tráfego de centenas de clientes a partir da mesma malha. Um único erro de configuração multi-tenant pode envenenar cache, vazar segredos ou transformar a sua borda em arma de DDoS. Veja como a Decripte audita, contém e implanta detecção de manipulação.
Direct answer
Para proteger um provedor de CDN e edge é preciso tratar a plataforma como um ambiente multi-tenant de altíssimo valor: normalize e valide chaves de cache (host, path, query e cabeçalhos relevantes) para impedir envenenamento e web cache deception; isole a configuração de cada cliente com escopo e least privilege no plano de controle; aplique controles anti-DDoS na borda e rate limiting por origem para impedir que sua infraestrutura seja abusada como amplificador; proteja segredos de origem (certificados, tokens de purge, chaves de API) em cofres com rotação; e instrumente detecção contínua de manipulação de cache e drift de configuração com um SOC 24x7. A Decripte faz pentest da plataforma e da configuração, estrutura a segurança de borda e responde a incidentes com SLA de contenção de até 1 hora. Comece pelo diagnóstico gratuito de Gestão de Ameaças em decripte.com.br/intelligence-center.
24/7
SOC monitorando a borda e o plano de controle
<=1h
SLA de contenção em resposta a incidentes
SOC 2
Evidência de controles para clientes enterprise
OWASP
Pentest alinhado a web cache deception e injeção
In summary
- ›Envenenamento de cache e web cache deception exploram divergência entre a chave de cache do CDN e a interpretação do servidor de origem; a defesa começa por normalizar e validar a cache key.
- ›Em CDN multi-tenant, o maior risco não é o tráfego de um cliente, e sim o vazamento de configuração, segredos ou cache entre tenants por isolamento fraco no plano de controle.
- ›Sua própria malha de edge é um alvo para ser abusada como refletor/amplificador de DDoS; rate limiting por origem e egress controlado são tão importantes quanto o anti-DDoS de entrada.
- ›A Decripte combina pentest de plataforma e configuração, segurança de borda anti-DDoS, SOC 24x7 com base para SOC 2 e resposta a incidentes com contenção em até 1 hora.
- ›O caminho de adoção é self-service: começa grátis em decripte.com.br/intelligence-center com a Gestão de Ameaças e evolui para os planos pagos em /planos.
Cibersegurança para CDN e Provedores de Edge
Provedores de CDN e edge servem tráfego de centenas de clientes a partir da mesma malha. Um único erro de configuração multi-tenant pode envenenar cache, vazar segredos ou transformar a sua borda em arma de DDoS. Veja como a Decripte audita, contém e implanta detecção de manipulação.
Por que provedores de CDN e edge são alvo de altíssimo valor
Um provedor de CDN (Content Delivery Network) e de edge computing ocupa uma posição arquitetural singular: ele fica no caminho do tráfego de muitos clientes ao mesmo tempo, termina TLS em nome deles, guarda cópias de seus conteúdos em cache e, cada vez mais, executa lógica de aplicação na borda. Essa concentração é exatamente o que torna o serviço valioso para o cliente final, mas também o que o transforma em um dos alvos de maior valor para um atacante. Comprometer um único provedor não significa comprometer um único site; significa potencialmente influenciar o que milhares de usuários recebem como resposta de centenas de domínios distintos.
A lógica do atacante é de alavancagem. Em vez de atacar diretamente um banco, uma fintech ou um e-commerce bem defendido, ele busca o ponto onde o tráfego desses alvos converge. Se conseguir envenenar uma entrada de cache, injetar conteúdo malicioso que será servido em escala, ou abusar do plano de controle para alterar a configuração de um tenant, ele transforma a vantagem operacional da CDN em uma superfície de ataque massiva. É a diferença entre comprometer uma casa e comprometer a portaria de um condomínio inteiro.
O risco multi-tenant é o risco dominante
Em uma CDN, a maior parte do perímetro de risco não está no tráfego de um cliente isolado, mas nas fronteiras compartilhadas: a mesma malha de POPs, o mesmo plano de controle, o mesmo storage de cache e, muitas vezes, os mesmos certificados gerenciados. Uma falha de isolamento entre tenants pode permitir que a configuração de um cliente vaze, que o cache de um domínio contamine outro ou que um segredo de origem seja exposto fora do seu escopo.
Some-se a isso a pressão de disponibilidade. Provedores de CDN e edge vendem justamente resiliência e baixa latência, então qualquer parada para resposta a incidente compete com o SLA prometido aos clientes. Isso muda a natureza da segurança exigida: não basta detectar e bloquear; é preciso conter sem derrubar tráfego legítimo, erradicar sem invalidar o cache do planeta inteiro e recuperar com evidência suficiente para responder aos clientes afetados. É um ambiente onde segurança e engenharia de confiabilidade precisam operar juntas.
O mapa de ameaças específico de CDN e edge
Envenenamento de cache e injeção em escala
O envenenamento de cache (cache poisoning) explora a divergência entre como o CDN constrói a chave de cache e como o servidor de origem interpreta a requisição. Se a chave de cache ignora um cabeçalho que a origem usa para gerar a resposta — por exemplo, X-Forwarded-Host, X-Forwarded-Scheme ou um cabeçalho custom não keyed —, um atacante pode forçar a origem a produzir uma resposta envenenada e fazer com que ela seja armazenada e servida a todos os usuários subsequentes que pedem o mesmo recurso. O resultado vai de redirecionamento e desfiguração até a injeção de JavaScript malicioso servido com a autoridade do domínio da vítima. Há ainda a variante de web cache deception, em que o atacante engana a vítima a acessar uma URL que parece um recurso estático cacheável (por exemplo, /conta/perfil/teste.css) mas que a origem resolve como conteúdo dinâmico autenticado; o CDN, vendo a extensão estática, cacheia a resposta — que pode conter dados sensíveis da vítima — e a entrega a quem pedir aquela URL. Ambos os vetores nascem da mesma raiz: cache key mal definida e ausência de validação entre o que é keyed e o que a origem realmente usa.
A chave de cache é o controle de segurança central
A maior parte das classes de envenenamento se neutraliza por uma definição rigorosa de cache key: incluir na chave todos os componentes que afetam a resposta (host, path, query relevante, cabeçalhos que a origem consulta), normalizar antes de cachear, e nunca cachear respostas a partir de entrada controlada pelo cliente sem validação. Tratada como controle de segurança, e não só de performance, a cache key fecha a maior superfície de ataque da plataforma.
Configuração de clientes, abuso de infraestrutura e vazamento de segredos
O plano de controle de uma CDN — APIs e painéis onde os clientes definem regras de roteamento, cache, WAF, certificados e funções de edge — é um alvo de alto retorno. Um token de API vazado, uma falha de autorização que permite operar sobre o tenant errado, ou um function de edge com injeção podem dar a um atacante controle sobre como o tráfego de um cliente é tratado: redirecionar tráfego, desabilitar regras de proteção, alterar origens ou exfiltrar configuração. Paralelamente, a capacidade de banda e a distribuição global que tornam a CDN útil também a tornam atraente como plataforma de abuso: funções de edge ou recursos de prefetch mal limitados podem ser instigados a fazer requisições de saída em massa, transformando a malha em motor de DDoS contra terceiros. Sem rate limiting por origem e controle de egress, o provedor vira amplificador involuntário.
Vazamento de tráfego e segredos
CDNs terminam TLS e guardam certificados, tokens de purge, chaves de API de origem e, em edge computing, segredos de aplicação dos clientes. Um isolamento fraco, um log que captura cabeçalhos de autorização ou um cache que retém resposta sensível pode vazar tráfego e credenciais entre tenants. Cada segredo de origem comprometido é uma porta direta para a infraestrutura do cliente, fora do alcance dos controles dele.
Is cdn e provedores de edge data already exposed or up for sale? Find out now — for free.
Sem cartão, sem compromisso. Descubra em minutos o que já vazou da sua empresa e qual é o seu risco real.
Pentest de plataforma e configuração: encontrar a falha antes do atacante
O pentest de uma CDN não é um pentest de aplicação convencional. Ele precisa cobrir duas dimensões simultaneamente: a plataforma (o software que constrói chaves de cache, encaminha tráfego, executa funções de edge e expõe o plano de controle) e a configuração (como cada tenant está realmente configurado, onde os defaults inseguros sobraram e onde o isolamento entre clientes pode ser furado). A Decripte aborda ambas com um Red Team que pensa como um adversário interessado em alavancagem, não apenas em uma URL vulnerável.
O que o pentest de CDN e edge cobre
- ✓Análise de cache key: identificação de cabeçalhos não keyed que a origem consome, testes de cache poisoning e web cache deception
- ✓Isolamento multi-tenant: tentativa de cruzar fronteiras de tenant no cache, na configuração e nos segredos
- ✓Plano de controle: falhas de autorização (IDOR/BOLA), escopo de tokens de API, fluxos de purge e gestão de certificados
- ✓Funções de edge: injeção, SSRF a partir da borda, limites de egress e consumo de recursos
- ✓Abuso de infraestrutura: capacidade de instigar requisições de saída em massa e ausência de rate limiting por origem
- ✓Cabeçalhos e roteamento: request smuggling entre camadas (front-end CDN vs origem), normalização de host e path
O diferencial está em testar as fronteiras, e não os componentes isolados. Uma CDN pode ter um servidor de cache impecável e um plano de controle robusto e, ainda assim, ser comprometida porque a forma como esses dois conversam permite request smuggling, ou porque a normalização de host difere entre a borda e a origem. O pentest da Decripte segue referências como o OWASP Top 10 e o OWASP Web Security Testing Guide, mas estende para os padrões específicos de cache, edge e multi-tenancy que não aparecem em uma checklist genérica.
Resultado acionável, não relatório de prateleira
Cada achado vem com prova de conceito reproduzível, classificação de severidade, e uma recomendação concreta de configuração — por exemplo, exatamente quais componentes adicionar à cache key, qual regra de roteamento normalizar ou qual escopo restringir no token de API. O objetivo é fechar a lacuna, não apenas documentá-la.
Segurança de borda e anti-DDoS: defender a entrada e a saída
Para um provedor de CDN, a segurança de borda tem uma dupla face que outros setores não enfrentam. De um lado, ele precisa absorver e mitigar DDoS dirigido aos seus clientes — afinal, é parte do que vende. De outro, precisa garantir que sua própria infraestrutura não seja abusada como amplificador de ataques contra terceiros. A Decripte estrutura ambos os lados: proteção de entrada com WAF e mitigação volumétrica e comportamental, e proteção de saída com rate limiting por origem, controle de egress e detecção de padrões de abuso interno.
Anti-DDoS em camadas
A mitigação eficaz combina filtragem volumétrica (camada 3/4) com defesa contra ataques de aplicação (camada 7), incluindo floods de requisições legítimas em aparência, slow-loris e abuso de endpoints caros. Em CDN, isso se soma à proteção das próprias funções de edge, que precisam ter limites rígidos de CPU, memória, conexões de saída e taxa de invocação para não se tornarem o elo abusado.
Sobre a camada de aplicação, o WAF na borda precisa ser calibrado para o contexto multi-tenant: regras agressivas demais geram falsos positivos que afetam clientes legítimos e corroem o SLA; regras frouxas demais deixam passar injeção e manipulação de cache. A Decripte segue uma filosofia de hardening que prioriza precisão sobre volume — em vez de bloquear faixas inteiras de ASN ou IP, foca em assinaturas comportamentais e em proteger os pontos exatos onde a manipulação de cache e a injeção acontecem, reduzindo o ruído que prejudica o tráfego legítimo.
Controles de borda recomendados
- ✓WAF calibrado por tenant, com regras de injeção e de proteção contra manipulação de cabeçalhos de cache
- ✓Rate limiting por origem e por endpoint, com tetos para funções de edge e para purge de cache
- ✓Controle de egress nas funções de borda para impedir SSRF e abuso de saída
- ✓Mitigação volumétrica L3/L4 e defesa comportamental L7 contra floods de aplicação
- ✓Normalização de host, path e query na borda, consistente com a origem, para fechar smuggling e poisoning
SOC 24x7 e SOC 2: detecção contínua e evidência de controles
Envenenamento de cache e drift de configuração são, por natureza, silenciosos. Uma entrada de cache envenenada pode servir conteúdo malicioso por horas antes que alguém perceba, porque para o sistema ela é apenas mais um hit de cache. Por isso a defesa de uma CDN depende menos de um único bloqueio e mais de detecção contínua: monitorar a integridade do cache, observar respostas anômalas, correlacionar mudanças no plano de controle com comportamento de tráfego e alertar sobre desvios. É o papel do SOC 24x7 da Decripte.
Detecção de manipulação de cache
A Decripte implanta detecção específica para o setor: comparação de respostas servidas contra baselines esperados, alertas sobre cabeçalhos inesperados em respostas cacheadas, monitoramento de mudanças de configuração por tenant (drift detection) e correlação entre eventos do plano de controle e anomalias de tráfego. O objetivo é reduzir o tempo entre o envenenamento e a detecção de horas para minutos.
A operação 24x7 também é o que torna o SLA de contenção de até 1 hora factível. Não há contenção rápida sem detecção rápida, e não há detecção rápida sem alguém — ou algo automatizado e supervisionado — observando os sinais certos o tempo todo. O SOC concentra telemetria da borda, do plano de controle e das funções de edge, transformando ruído em alertas priorizados e em incidentes acionáveis.
Base para SOC 2 e LGPD
Clientes enterprise de uma CDN frequentemente exigem evidência de controles na forma de SOC 2. O SOC 24x7 da Decripte produz a telemetria, o registro de incidentes e a trilha de auditoria que sustentam os critérios de Segurança e Disponibilidade, ajudando o provedor a apresentar aos seus próprios clientes a maturidade que eles cobram. A LGPD, por sua vez, exige medidas técnicas e administrativas de proteção e comunicação à ANPD em caso de incidente com risco aos titulares — algo que só é possível atender com detecção e registro adequados.
What would an incident in cdn e provedores de edge cost? See your real risk before it happens.
Sem cartão, sem compromisso. Descubra em minutos o que já vazou da sua empresa e qual é o seu risco real.
Como tudo se conecta: da auditoria à detecção contínua
Os quatro serviços — pentest, segurança de borda, SOC e resposta a incidentes — não são produtos avulsos; são fases de um mesmo ciclo. O pentest revela onde estão as falhas de cache key, de isolamento e de plano de controle. A segurança de borda fecha essas falhas com controles calibrados. O SOC detecta o que escapou e o que muda ao longo do tempo. E a resposta a incidentes está pronta para conter quando algo passa. Cada fase alimenta a próxima: os achados do pentest viram regras de detecção, os incidentes viram novos casos de teste para o próximo pentest.
O ciclo em prática
Um envenenamento de cache detectado pelo SOC dispara a resposta a incidentes, que contém purgando e bloqueando o vetor. A análise pós-incidente identifica o cabeçalho não keyed responsável, que é corrigido na configuração de borda. No próximo pentest, esse exato cenário vira um caso de regressão. Assim, a plataforma fica progressivamente mais difícil de atacar, em vez de apenas reagir ao mesmo problema repetidamente.
Essa integração é especialmente valiosa em CDN porque a velocidade de propagação é alta: uma resposta envenenada se espalha pelo cache global em segundos, e uma configuração errada afeta todos os tenants que a compartilham. Quanto mais curto o laço entre detectar, conter e corrigir, menor o raio de impacto. A Decripte projeta esse laço explicitamente, com runbooks específicos para os incidentes típicos do setor.
Começando: diagnóstico gratuito e evolução self-service
A adoção é desenhada para começar sem atrito. O ponto de partida é a Gestão de Ameaças gratuita em decripte.com.br/intelligence-center, com o CTA 'Comece grátis agora'. Ela dá ao provedor uma visão inicial e real de risco — exposição da plataforma, sinais de configuração frágil e ameaças observáveis — antes de qualquer compromisso. É a forma de provar valor com dados, não com promessas.
Caminho de adoção
- ✓Comece grátis com a Gestão de Ameaças em decripte.com.br/intelligence-center para um diagnóstico inicial de exposição
- ✓Avance para o Pentest de plataforma e configuração para mapear cache key, isolamento e plano de controle
- ✓Estruture a borda com Segurança de Borda anti-DDoS e WAF calibrado por tenant
- ✓Coloque o SOC 24x7 para detecção contínua de manipulação de cache e drift, com base para SOC 2
- ✓Mantenha a Resposta a Incidentes ativa para contenção em até 1 hora quando algo passar
- ✓Veja os planos pagos em /planos com o CTA 'Ver planos pagos' para combinar os serviços
A partir do diagnóstico, a evolução para os planos pagos em /planos é self-service e modular. O provedor escolhe os serviços conforme a maturidade que precisa demonstrar e o risco que precisa cobrir, sem depender de um ciclo de vendas longo para começar a se proteger. A premissa é simples: a segurança de uma plataforma que serve o tráfego de muitos não pode esperar.
Envenenamento de cache em provedor de CDN multi-tenant (exemplo real descaracterizado)
Real, de-identified example
Exemplo real descaracterizado (sem identificar o cliente). Um provedor de CDN de médio porte serve dezenas de clientes a partir de uma malha global de POPs. Um cliente — um e-commerce — começa a receber reclamações de que páginas de produto exibem brevemente um banner com redirecionamento para um domínio externo. O provedor inicialmente trata como problema do cliente, até que o mesmo sintoma aparece em outro tenant que compartilha a mesma região de cache. A investigação revela que a chave de cache não incluía um cabeçalho que a origem do cliente usava para montar parte do HTML, permitindo que um atacante envenenasse a entrada de cache de um recurso compartilhado e o servisse a todos os visitantes subsequentes.
Detecção
O SOC 24x7 correlaciona reclamações de dois tenants distintos com um pico de respostas cacheadas contendo um cabeçalho inesperado. A detecção de manipulação de cache dispara um alerta de alta severidade ao identificar que respostas servidas divergem do baseline esperado para aqueles recursos, indicando envenenamento ativo e não um problema de aplicação isolado.
Triagem e escopo
A equipe de resposta da Decripte determina o raio de impacto: quais URLs, quais POPs e quais tenants têm entradas de cache potencialmente envenenadas. Identifica o vetor como um cabeçalho não keyed consumido pela origem, e confirma que o mesmo padrão de cache key afeta múltiplos clientes, não só o e-commerce que reclamou primeiro.
Contenção
Dentro do SLA de até 1 hora, a Decripte executa a contenção: purge cirúrgico das entradas de cache envenenadas nos POPs afetados, bloqueio do vetor de injeção na borda via WAF e regra temporária que impede o cache de respostas que carreguem o cabeçalho suspeito. O tráfego legítimo continua sendo servido; apenas as entradas comprometidas são invalidadas, evitando uma derrubada global de cache.
Erradicação
A causa raiz é eliminada: a definição de cache key é corrigida para incluir todos os componentes que a origem consome, e a normalização de cabeçalhos passa a ser consistente entre a borda e a origem, fechando a divergência que permitia o poisoning. A correção é aplicada de forma controlada por tenant, evitando regressão de performance.
Recuperação
As entradas de cache são repovoadas com respostas validadas a partir da origem corrigida. O SOC monitora ativamente as respostas servidas contra o baseline para confirmar que nenhuma entrada envenenada residual permaneceu em qualquer POP. Os tenants afetados recebem um relatório do raio de impacto, do período e das URLs envolvidas.
Notificação e conformidade
Com a trilha de evidências do SOC, o provedor consegue comunicar aos clientes afetados o que ocorreu e em que janela, e avaliar com base na LGPD se houve risco a titulares que demande comunicação à ANPD. A documentação do incidente sustenta os critérios de SOC 2 que os clientes enterprise cobram.
Lições aprendidas
O cenário de poisoning por cabeçalho não keyed vira caso de regressão para o próximo pentest. A detecção de manipulação de cache é ampliada para cobrir mais classes de cabeçalho, e o processo de revisão de cache key passa a ser obrigatório para cada nova configuração de tenant, transformando o incidente em melhoria permanente da plataforma.
Outcome with Decripte
O envenenamento foi contido em menos de uma hora a partir da detecção, sem derrubar o tráfego legítimo dos demais clientes. A causa raiz — uma cache key incompleta replicada entre tenants — foi corrigida na plataforma, e não apenas no cliente que reclamou. Com a Decripte, o provedor passou a ter detecção contínua de manipulação de cache, pentest periódico cobrindo o cenário como regressão e evidência de controles para os clientes enterprise. O que começou como uma reclamação isolada de um tenant terminou como um endurecimento estrutural da malha inteira.
Don’t wait for the incident. Start hardening cdn e provedores de edge today.
Comece pelo diagnóstico gratuito agora e veja em minutos o que já vazou. SOC 24x7 e contenção em até 1h nos planos pagos.
Como a Decripte responde a incidentes em provedores de CDN e edge
A resposta a incidentes em CDN exige conter sem derrubar tráfego legítimo e erradicar sem invalidar o cache global inteiro. A Decripte segue um processo desenhado para a velocidade de propagação e a sensibilidade ao SLA do setor, com contenção em até 1 hora.
- Detecção e validação: o SOC 24x7 correlaciona sinais de manipulação de cache, drift de configuração e anomalias de tráfego, separando incidente real de problema de aplicação isolado e classificando a severidade.
- Definição de escopo e raio de impacto: identificar quais URLs, POPs, tenants e segredos estão potencialmente afetados antes de agir, para que a contenção seja cirúrgica e não destrutiva.
- Contenção cirúrgica em até 1 hora: purge dirigido das entradas de cache comprometidas, bloqueio do vetor na borda via WAF e regras temporárias que impedem o recache do conteúdo malicioso, preservando o tráfego legítimo.
- Erradicação da causa raiz: corrigir a cache key, a normalização de cabeçalhos, a falha de autorização no plano de controle ou o limite ausente na função de edge que permitiu o incidente — na plataforma, não só no tenant que reclamou.
- Recuperação verificada: repovoar o cache com respostas validadas e monitorar ativamente as respostas servidas contra baseline para garantir que nenhuma entrada envenenada residual permaneça em qualquer POP.
- Evidência e notificação: consolidar a trilha de auditoria do SOC para comunicar clientes afetados, avaliar obrigações de notificação à ANPD sob a LGPD e sustentar os critérios de SOC 2.
- Hardening e regressão: transformar o incidente em caso de teste para o próximo pentest e em novas regras de detecção, fechando o laço para que o mesmo vetor não retorne.
- Comunicação contínua: manter o provedor e, quando aplicável, os tenants informados em cada fase, com linguagem técnica e executiva, equilibrando transparência e responsabilidade.
Como a Decripte estrutura a segurança de um provedor de CDN e edge
Estruturar a segurança de uma CDN é tratar a plataforma como um ambiente multi-tenant de alto valor, onde o isolamento entre clientes, a integridade do cache e a proteção de segredos são controles de primeira ordem. A Decripte organiza isso em pilares que se reforçam.
Integridade do cache como controle de segurança
Definição rigorosa de cache key (host, path, query e cabeçalhos relevantes), normalização consistente entre borda e origem, e detecção contínua de manipulação. A chave de cache deixa de ser apenas uma decisão de performance e passa a ser o principal controle contra envenenamento e web cache deception.
Isolamento multi-tenant no plano de controle
Escopo e least privilege em tokens de API, autorização robusta contra IDOR/BOLA, e separação clara de configuração, segredos e cache entre tenants. O objetivo é garantir que a falha em um cliente nunca se propague para outro pela infraestrutura compartilhada.
Borda defensiva e não abusável
WAF calibrado por tenant, mitigação anti-DDoS em camadas L3/L4 e L7, e — igualmente importante — rate limiting por origem e controle de egress para impedir que a própria malha seja abusada como amplificador de ataques contra terceiros.
Proteção de segredos de origem
Certificados, tokens de purge e chaves de API guardados em cofres com rotação, com logs que não capturam material sensível e cache que nunca retém respostas autenticadas. Cada segredo protegido fecha uma porta direta para a infraestrutura dos clientes.
Detecção contínua e prontidão de resposta
SOC 24x7 com baselines de resposta, drift detection de configuração e runbooks específicos do setor, conectados à resposta a incidentes com contenção em até 1 hora. Detecção rápida é o que torna a contenção rápida possível.
Evidência e melhoria contínua
Trilha de auditoria para sustentar SOC 2 e obrigações da LGPD, e um laço fechado em que incidentes viram casos de regressão no pentest e novas regras de detecção. A plataforma fica progressivamente mais difícil de atacar.
Recommended plans for CDN e Provedores de Edge
Pentest
Audita a plataforma e a configuração multi-tenant: cache key, isolamento entre tenants, plano de controle e funções de edge, encontrando os vetores de envenenamento e abuso antes do atacante.
See plan →Seguranca de Borda
Defende a entrada com WAF e anti-DDoS calibrados por tenant e protege a saída com rate limiting por origem e controle de egress, impedindo que a malha seja abusada como amplificador.
See plan →SOC 24x7
Detecta manipulação de cache e drift de configuração de forma contínua, com base para SOC 2 que os clientes enterprise cobram, e habilita a contenção rápida que o setor exige.
See plan →Resposta a Incidentes
Contém envenenamento de cache e comprometimento de configuração em até 1 hora, com purge cirúrgico que preserva o tráfego legítimo e erradicação da causa raiz na plataforma.
See plan →Frequently asked questions
O que é envenenamento de cache e por que ele é tão perigoso em uma CDN?
Envenenamento de cache (cache poisoning) ocorre quando um atacante faz com que uma resposta maliciosa seja armazenada no cache do CDN e servida a todos os usuários que pedem o mesmo recurso. Em uma CDN é especialmente perigoso porque a propagação é global e instantânea: uma única entrada envenenada pode afetar todos os visitantes de um domínio em segundos. A raiz quase sempre é uma chave de cache que ignora cabeçalhos que o servidor de origem usa para montar a resposta. A defesa começa por normalizar e validar rigorosamente a cache key.
Como vocês contêm um incidente sem invalidar o cache global e prejudicar todos os clientes?
A contenção da Decripte é cirúrgica. Primeiro definimos o raio de impacto — quais URLs, POPs e tenants estão afetados — e só então executamos purge dirigido apenas das entradas comprometidas, somado a um bloqueio do vetor na borda. O tráfego legítimo continua sendo servido normalmente. Evitamos a derrubada global de cache justamente porque ela competiria com o SLA prometido aos seus clientes. Tudo dentro do SLA de contenção de até 1 hora.
Como a auditoria lida com o isolamento entre tenants?
O pentest da Decripte testa explicitamente as fronteiras entre clientes: tenta cruzar o isolamento no cache, na configuração e nos segredos; verifica falhas de autorização no plano de controle (como acessar ou operar sobre o tenant errado); e avalia o escopo de tokens de API. Em CDN, o maior risco não é o tráfego de um cliente isolado, e sim o vazamento entre tenants pela infraestrutura compartilhada — por isso esse é o foco central.
Vocês ajudam a evitar que nossa infraestrutura seja abusada para DDoS contra terceiros?
Sim. Além do anti-DDoS de entrada, a Segurança de Borda da Decripte implanta rate limiting por origem e controle de egress nas funções de edge, justamente para impedir que recursos de prefetch, optimization ou funções mal limitadas sejam instigados a fazer requisições de saída em massa. O objetivo é garantir que sua malha defenda os clientes sem nunca se tornar um amplificador involuntário de ataques.
Como o SOC 24x7 detecta um envenenamento de cache que, para o sistema, parece só mais um hit?
Implantamos detecção específica de manipulação de cache: comparamos as respostas servidas contra baselines esperados, alertamos sobre cabeçalhos inesperados em respostas cacheadas e fazemos drift detection das configurações por tenant, correlacionando mudanças no plano de controle com anomalias de tráfego. É isso que reduz o tempo entre o envenenamento e a detecção de horas para minutos.
Isso ajuda a atender SOC 2 e a LGPD?
Sim. O SOC 24x7 produz telemetria, registro de incidentes e trilha de auditoria que sustentam os critérios de Segurança e Disponibilidade do SOC 2 que seus clientes enterprise cobram. Para a LGPD, esses mesmos registros permitem avaliar se um incidente gerou risco a titulares e cumprir a obrigação de comunicação à ANPD, além de evidenciar as medidas técnicas e administrativas de proteção exigidas pela lei.
Como começo sem um processo de compra longo?
O ponto de partida é o diagnóstico gratuito de Gestão de Ameaças em decripte.com.br/intelligence-center, com o CTA 'Comece grátis agora'. Ele dá uma visão inicial e real da sua exposição antes de qualquer compromisso. A partir daí, a evolução para os planos pagos é self-service e modular em /planos, com o CTA 'Ver planos pagos' — você escolhe os serviços conforme o risco e a maturidade que precisa cobrir.
O pentest cobre request smuggling entre a borda do CDN e a origem?
Sim. Testamos as fronteiras entre camadas, incluindo request smuggling entre o front-end do CDN e o servidor de origem, divergências de normalização de host e path entre as duas camadas, e o encadeamento desses problemas com cache poisoning. São exatamente os vetores que uma checklist genérica de aplicação não cobre, mas que são críticos em uma arquitetura de CDN e edge.
Sector terms
- Envenenamento de cache (cache poisoning)
- Ataque em que uma resposta maliciosa é armazenada no cache do CDN e servida a todos os usuários subsequentes que pedem o mesmo recurso, geralmente explorando uma chave de cache que ignora cabeçalhos usados pela origem.
- Web cache deception
- Variante em que o atacante engana a vítima a acessar uma URL que aparenta ser um recurso estático cacheável, mas que a origem resolve como conteúdo dinâmico autenticado, fazendo o CDN cachear e expor dados sensíveis.
- Cache key (chave de cache)
- Conjunto de componentes da requisição (host, path, query e cabeçalhos relevantes) que o CDN usa para identificar uma entrada de cache. Quando incompleta, abre espaço para envenenamento; tratada como controle de segurança, é a principal defesa.
- Multi-tenant
- Arquitetura em que muitos clientes (tenants) compartilham a mesma infraestrutura. Em CDN, exige isolamento rigoroso de cache, configuração e segredos para impedir que a falha em um cliente se propague para outro.
- Plano de controle
- Conjunto de APIs e painéis onde os clientes configuram roteamento, cache, WAF, certificados e funções de edge. É um alvo de alto valor: tokens vazados ou falhas de autorização permitem alterar como o tráfego de um cliente é tratado.
- Edge computing
- Execução de lógica de aplicação nos POPs do provedor, próximos ao usuário. Reduz latência, mas adiciona superfície de ataque (injeção, SSRF, abuso de egress) que precisa de limites rígidos de recurso e controle de saída.
Decripte protects and responds to incidents in cdn e provedores de edge.
Pentest, 24x7 SOC, incident response with a 1-hour containment SLA and compliance — without building an internal team. Or start free by seeing what has already leaked from your company.