Cloudflare Access infraestrutura: Zero Trust na rede global

Na manhã desta sexta-feira, 21 de agosto de 2026, o cenário de infraestrutura de borda vive um momento decisivo. A rede da Cloudflare, operada sob o sistema autônomo AS13335, já se estende por mais de 300 cidades e mais de 100 países, respondendo por aproximadamente uma em cada cinco requisições HTTP da internet. É exatamente sobre essa malha anycast que o Cloudflare Access infraestrutura passou a operar nos últimos anos, deslocando o controle de acesso corporativo da rede privada para a borda distribuída — muito mais próxima do usuário e muito mais difícil de contornar do que uma VPN tradicional.

O que está em jogo não é apenas uma troca de ferramenta de acesso remoto. Trata-se de uma mudança arquitetural profunda: em vez de abrir túneis para um data center central e expor portas de rede a qualquer pessoa com credenciais válidas, o Zero Trust da Cloudflare autentica cada sessão, valida cada dispositivo e aplica políticas de autorização a cada requisição, diretamente no ponto de presença mais próximo do usuário. Para empresas brasileiras, isso significa reduzir latência, melhorar conformidade e eliminar a superfície de ataque clássica das VPNs corporativas.

O contexto de mercado reforça essa urgência. A computação de borda deixou de ser promessa: Workers, containers, bases vetoriais e modelos de machine learning já executam em dezenas de pontos de presença ao redor do planeta. Paralelamente, ataques de DDoS superaram a marca de 2 Tbps em 2024, e os times de segurança passaram a tratar a identidade — e não o IP de origem — como o novo perímetro. Nesse ambiente, uma infraestrutura de acesso que depende de hardware centralizado não escala, não protege e não atende aos requisitos de LGPD.

O Cloudflare Access nasceu como alternativa segura a VPNs, integrando-se a provedores de identidade como Okta, Google Workspace, Microsoft Entra ID e Azure AD. Desde então, evoluiu para uma plataforma completa de gerenciamento de acesso que pode ser acoplada a Workers, aplicações auto-hospedadas, portais internos, APIs e até conteúdo estático. O leitor que acompanha o produto sabe que a Cloudflare tem investido pesadamente em controles granulares, consentimento OAuth orientado a tarefas e detecção de tráfego de novos protocolos, como o MCP (Model Context Protocol).

Neste post, você vai entender o que mudou na infraestrutura do Cloudflare Access, como funciona a arquitetura de autenticação na borda, por que essa abordagem supera a VPN legada e como configurar políticas de acesso em poucos passos. Também comparamos a escala da rede Cloudflare com Akamai, AWS CloudFront e Fastly, e analisamos o impacto real para operações no Brasil. Na JRT Technology Solutions, implementamos e gerenciamos Cloudflare para clientes corporativos — CDN, WAF, Zero Trust e Workers — e compartilhamos ao longo do texto recomendações práticas de quem opera esse tipo de infraestrutura em produção.

O anúncio: Cloudflare Access para Workers e o novo panorama Zero Trust

O lançamento mais relevante do ciclo foi o Cloudflare Access for Workers, que permite anexar uma política de acesso diretamente a um Worker e aplicá-la automaticamente em todos os pontos onde aquele código roda: rotas, domínios personalizados, subdomínios workers.dev e ambientes de preview. Isso encerra um problema antigo dos desenvolvedores, que precisavam duplicar políticas para cada rota ou gateway. Com um único clique, qualquer aplicação interna criada — inclusive as chamadas vibe-coded applications, frequentemente desenvolvidas com auxílio de IA e sem revisão formal de segurança — passa a exigir autenticação e autorização antes de expor dados.

Ao colocar o Access como camada nativa dos Workers, a Cloudflare transforma o runtime de borda em um ambiente de aplicação corporativa seguro por padrão. O Worker continua distribuído pela rede anycast, mas agora o processo de login ocorre no ponto de presença mais próximo do usuário, e a autorização é verificada antes de qualquer execução de código. Isso é especialmente relevante para times que publicam microserviços, APIs internas e ferramentas de produtividade sem passar por um gateway central.

Outro avanço significativo veio da evolução do OAuth: a Cloudflare agora suporta consentimento baseado em tarefas e escopos opcionais. Isso significa que uma aplicação pode solicitar apenas as permissões necessárias para a ação em curso, em vez de pedir acesso amplo à identidade do usuário. Para administradores, esse modelo reduz o risco de concessões excessivas e facilita auditorias de conformidade — um ponto sensível em ambientes regulados e em políticas de LGPD.

No campo da visibilidade, a Cloudflare passou a retornar respostas 403 enriquecidas na API, incluindo o campo documentation_url que aponta diretamente para a documentação do endpoint negado. Esse pequeno ajuste tem grande impacto operacional: agentes automatizados, ferramentas de terceiros e desenvolvedores podem identificar imediatamente quais papéis ou permissões estão ausentes, em vez de perder horas tentando adivinhar a causa de uma negação de acesso. Em ambientes com dezenas de tokens e funções, essa contextualização acelera dramaticamente a resolução de incidentes.

Por fim, a detecção de tráfego MCP pelo Cloudflare Gateway merece atenção. O Gateway agora identifica requisições de Model Context Protocol por heurísticas de protocolo, permitindo que equipes de segurança encontrem tráfego shadow de MCP, forcem o uso de portais aprovados e bloqueiem conexões diretas a servidores não gerenciados. Para organizações que já usam IA com acesso a dados internos, esse controle é crítico: sem ele, um agente de IA pode exfiltrar informações corporativas por canais fora da supervisão do time de segurança.

O que é o Cloudflare Access e como ele usa a infraestrutura global

O Cloudflare Access é um serviço de gerenciamento de acesso baseado em identidade que substitui a VPN tradicional. Em vez de conectar o dispositivo do usuário a uma rede privada, o Access funciona como um proxy de autenticação na borda: cada requisição a uma aplicação protegida passa primeiro por um ponto de presença da Cloudflare, que valida a identidade do usuário, verifica o contexto do dispositivo e só então permite ou nega o acesso. A aplicação de origem nunca fica exposta à internet pública.

A infraestrutura por trás desse modelo é a mesma rede anycast que serve CDN e DNS para milhões de domínios. Com anycast, o mesmo endereço IP é anunciado a partir de centenas de locais distintos ao redor do mundo, e o tráfego é roteado automaticamente pelo caminho mais curto até o PoP da Cloudflare. Isso significa que o processo de autenticação acontece a poucos milissegundos do usuário, e não em um data center central em outro continente. A rede é operada sob o AS13335, um dos maiores sistemas autônomos do planeta, com peering direto em dezenas de Internet Exchanges e milhares de redes de acesso.

O Access usa essa malha para aplicar políticas de segurança no nível da borda, antes que o tráfego chegue à origem. Esse modelo contrasta com a VPN, na qual o usuário estabelece um túnel criptografado para um concentrador central e, a partir dali, pode acessar qualquer recurso da rede. No Zero Trust da Cloudflare, não existe rota de rede implícita: cada aplicação é independente, e a autorização é avaliada individualmente. Mesmo que um invasor comprometa uma credencial, ele não ganha acesso lateral à rede — precisa passar por uma nova autorização para cada recurso.

Essa integração entre Access e Workers ilustra a vantagem de uma plataforma unificada. A alternativa convencional exigiria combinar um CDN, um proxy de autenticação, um gerenciador de políticas e um runtime de borda de fornecedores diferentes, multiplicando pontos de falha. Com a Cloudflare, todos esses componentes compartilham a mesma infraestrutura e o mesmo plano de controle, o que simplifica a operação e aumenta a previsibilidade do desempenho.

Além do Access for Workers, o ecossistema Cloudflare One inclui Gateway, WARP, CASB e Browser Isolation. Juntos, esses serviços formam uma arquitetura SASE completa, na qual a segurança é aplicada na borda e na nuvem, não no perímetro físico. O Access é a peça central dessa arquitetura para o controle de acesso corporativo: ele decide quem pode falar com o quê, independentemente de onde o usuário esteja.

Cloudflare Access infraestrutura: arquitetura de autenticação na edge

A autenticação no Cloudflare Access infraestrutura segue um fluxo de OIDC ou SAML com a emissão de cookies de sessão assinados. Quando um usuário tenta acessar uma aplicação protegida, o PoP da Cloudflare intercepta a requisição e verifica se existe um cookie de sessão válido. Se não houver, o usuário é redirecionado para o provedor de identidade configurado. Após o login