CloudFront passa a expor ISP do visitante e detalhes de TLS pós-quântico da conexão

A AWS anunciou em 30 de outubro de 2026 dois novos headers opcionais que o Amazon CloudFront pode encaminhar para a origem a cada requisição. O CloudFront-Viewer-ISP traz o nome do provedor de internet (ISP) de quem fez a requisição. O CloudFront-Viewer-TLS-Details descreve a criptografia usada naquela conexão TLS específica, incluindo se ela é pós-quântica (PQC).

Nenhum dos dois headers vem habilitado por padrão. Quem opera uma distribuição CloudFront precisa adicioná-los explicitamente a uma origin request policy e associar essa policy ao comportamento de cache (cache behavior) da distribuição. Sem essa configuração, a origem continua recebendo as requisições como antes, sem esses dados.

O que o CloudFront-Viewer-ISP entrega

O header traz o nome do provedor de internet que originou a requisição, algo como "Vivo", "Claro", "TIM" ou "Algar Telecom" no caso de tráfego móvel e fixo brasileiro. Até agora, para saber de qual rede vinha um pico de latência, erro ou tráfego suspeito, era preciso cruzar o IP do viewer com uma base de geolocalização ou ASN por fora, geralmente num serviço de terceiros.

Com o header pronto na requisição, essa correlação fica embutida no próprio log de aplicação. Isso abre casos de uso concretos para quem já roda CloudFront em produção no Brasil:

• Isolar se um aumento de erro 5xx está concentrado numa operadora específica (sintoma comum de CGNAT mal configurado ou de peering degradado entre a operadora e a AWS).
• Quebrar métricas de performance (latência, taxa de cache hit) por rede, já que a experiência de um usuário na rede móvel da TIM pode ser bem diferente da de um usuário na banda larga fixa da Claro.
• Detectar abuso ou scraping concentrado num único provedor, sem depender de lookup de IP em tempo real.

O que o CloudFront-Viewer-TLS-Details entrega

Esse header descreve três atributos da conexão TLS do viewer: o algoritmo de troca de chaves (key exchange), o esquema de assinatura e o tipo de chave pública da assinatura. É com o campo de key exchange que dá para saber se a conexão usou um esquema híbrido pós-quântico, como os baseados em ML-KEM (o algoritmo padronizado pelo NIST, sucessor do Kyber), em vez de apenas ECDHE clássico.

Na prática, isso serve para medir adoção, não para bloquear ninguém: o header só informa o que o cliente negociou. Times de segurança e arquitetura podem usar esse dado para acompanhar que fração dos navegadores e SDKs que acessam a aplicação já suporta PQC, e quais clientes (SDKs internos, apps mobile antigos, integrações de parceiros) ainda dependem só de criptografia clássica.

Por que isso importa agora: o risco de "harvest now, decrypt later" (interceptar tráfego cifrado hoje para decifrar quando computadores quânticos forem capazes) já é levado em conta por reguladores e grandes clientes corporativos. Ter visibilidade de quem ainda não migrou para troca de chaves híbrida é o primeiro passo antes de qualquer exigência de desativar cifras antigas.

Como habilitar os dois headers

O caminho é o mesmo para os dois: uma origin request policy.

1. No console do CloudFront, vá em Policies > Origin request e crie uma nova policy (ou edite uma existente).
2. Na seção de headers, escolha Include specific headers e adicione CloudFront-Viewer-ISP e/ou CloudFront-Viewer-TLS-Details à lista.
3. Associe essa origin request policy ao cache behavior da distribuição que deve encaminhar os dados.
4. Na origem, trate os dois headers como qualquer outro: logue, encaminhe para o APM ou use em lógica de aplicação.

Um detalhe que importa para quem desenha cache: esses headers são forwarded via origin request policy, não via cache policy. Isso significa que, por padrão, eles não entram na chave de cache. A origem passa a enxergar o ISP e os detalhes de TLS do viewer sem que isso fragmente o cache em milhares de variações por operadora ou por cipher suite, o que aconteceria se esses valores fossem incluídos numa cache policy por engano.

O que muda para quem opera CloudFront no Brasil

Até este anúncio, correlacionar incidente de rede com operadora dependia de enriquecer logs de aplicação com uma base de ASN externa, ou de assinar algum serviço de threat intelligence só para isso. Agora esse enriquecimento vem de graça na borda, desde que a origin request policy esteja configurada.

Para arquitetos que já têm um cache behavior dedicado para API routes (separado do comportamento que serve assets estáticos), o ajuste é pontual: basta criar ou editar a origin request policy daquele comportamento específico e reimplantar a distribuição, sem tocar no restante da configuração. Quem usa CDK ou Terraform para gerenciar a distribuição deve expor essa mudança como qualquer outra alteração de OriginRequestPolicy, versionada e revisada como o resto da infraestrutura.

A AWS não divulgou custo adicional para habilitar os dois headers; o preço segue o das requisições e das origin request policies já em uso na distribuição.

O que ainda fica em aberto

O anúncio cobre apenas o encaminhamento do header para a origem: não há menção a exibir esses campos nativamente nos logs padrão do CloudFront (standard logs) nem nos relatórios do console. Quem quiser dashboards prontos de "% de tráfego em PQC" ou "erros por ISP" ainda precisa processar o header na própria aplicação e enviar para CloudWatch, Firehose ou a stack de observabilidade já usada.

Também não há, por ora, uma forma declarada de usar esses dois campos para roteamento condicional dentro do próprio CloudFront (por exemplo, via CloudFront Functions) sem reescrever a lógica no lado da origem. Para quem já usa CloudFront Functions em edge para personalizar respostas, vale acompanhar se a AWS estende esse suporte a leitura desses headers na própria função, o que tornaria possível, por exemplo, servir conteúdo alternativo de fallback apenas para clientes sem PQC.

Mais detalhes de configuração estão no guia Adding CloudFront headers e em Controlling origin requests with a policy, no Amazon CloudFront Developer Guide.

Fonte: AWS What's New