Cloudflare Access Workers: Zero Trust automático para Workers
A Cloudflare acaba de anunciar o Cloudflare Access Workers, uma mudança profunda na forma como desenvolvedores protegem aplicações serverless na borda. Antes, proteger um Worker com acesso autenticado exigia cadastrar manualmente cada domínio, rota ou preview URL em uma política do Cloudflare Access — um processo frágil, sujeito a falhas de sincronização e quase impossível de escalar em ambientes com dezenas de microsserviços. Agora, a política de acesso é anexada diretamente ao próprio Worker e se aplica automaticamente a todos os pontos onde ele é publicado: rotas, custom domains, workers.dev e previews. Para times de plataforma, segurança e engenharia, isso elimina uma camada inteira de complexidade operacional e reduz a superfície de ataque de aplicações internas, dashboards e APIs que hoje rodam na borda sem nenhuma autenticação.
O anúncio chega em um momento em que a computação na borda deixou de ser tendência para se tornar infraestrutura padrão. A rede da Cloudflare já está presente em mais de 300 cidades em mais de 100 países, operando o AS13335 — um dos maiores sistemas autônomos do mundo — e respondendo por aproximadamente 1 em cada 5 requisições HTTP da internet. Com mais de 275 pontos de presença executando o runtime de Workers, uma função pode iniciar em menos de 1 milissegundo de cold start, algo impossível de alcançar em arquiteturas tradicionais baseadas em VMs ou containers regionais.
O contexto de 2026 também importa. O Cloudflare DDoS Threat Report H1 2026 registrou um aumento de 519% em ataques hipervolumétricos, impulsionados por vetores de reflexão DNS e CLDAP e por tensões geopolíticas crescentes. Ao mesmo tempo, o uso de ferramentas de IA generativa para criar aplicações internas — o chamado vibe coding — explodiu, e com ele o número de endpoints não protegidos expostos na internet corporativa. É exatamente essa lacuna que o Cloudflare Access Workers pretende fechar: qualquer Worker, seja ele escrito por um engenheiro sênior ou gerado por um assistente de código, pode ser colocado atrás de autenticação forte em poucos cliques.
Para empresas brasileiras, a relevância é direta. A latência até regiões de nuvem concentradas nos Estados Unidos costuma girar em torno de 100 a 150 ms ida e volta, dependendo da rota. Com Workers executando em pontos de presença locais, incluindo São Paulo e outras capitais, esse tempo pode cair para menos de 20 ms na mesma região — um ganho decisivo para APIs de pagamento, autenticação e e-commerce. Além disso, a capacidade de aplicar políticas de identidade na borda facilita a conformidade com a LGPD, uma vez que o controle de acesso passa a ser granular e auditável, sem depender de túneis VPN que ampliam a superfície de rede.
Neste artigo, você vai entender em profundidade como o Cloudflare Access Workers funciona, como habilitá-lo no dashboard ou via API, quais são os ganhos em relação a VPNs e IAM tradicional, como ele se encaixa no ecossistema serverless da Cloudflare e por que esse movimento importa para o mercado brasileiro. Vamos comparar também com Lambda@Edge e Vercel Edge, e fechar com recomendações práticas da JRT Technology Solutions para adoção corporativa.
O que é Cloudflare Access Workers e por que ele muda o jogo
O Cloudflare Access Workers é a integração nativa entre o Cloudflare Access — solução Zero Trust que substitui VPN por autenticação baseada em identidade — e o Cloudflare Workers, plataforma de computação serverless na borda. Até agora, proteger um Worker era um exercício de configuração manual: cada domínio associado precisava ser adicionado individualmente como uma aplicação no Access, incluindo workers.dev, domínios customizados e URLs de preview geradas automaticamente. Se um novo domínio fosse adicionado ou uma rota mudasse, a lista ficava desatualizada, criando brechas silenciosas.
Com o novo recurso, a política do Access é anexada ao objeto do Worker, e não aos seus domínios. Isso significa que, independentemente de quantos domínios apontem para ele, a proteção segue o Worker. Se você adicionar um novo custom domain amanhã, ele já nasce protegido. Se um preview for gerado para um pull request, ele também herda a política automaticamente. Essa abordagem inverte a lógica tradicional de segurança perimetral: em vez de proteger a entrada, protege-se a aplicação onde ela vive, com identidade no centro.
O anúncio é duplo. Primeiro, é possível proteger um Worker individual ou um grupo de Workers de uma só vez. Segundo, é possível ativar um modo “private by default”, que torna todos os Workers existentes e futuros da conta privados por padrão. Nesse modo, qualquer Worker recém-criado já exige sign-in antes de responder a qualquer requisição. Se um Worker específico precisa permanecer público — por exemplo, um endpoint de health check ou um webhook — basta adicionar um bypass no nível do Worker. Essa granularidade é essencial para empresas que adotam serverless em escala e não querem depender de desenvolvedores lembrando de configurar segurança manualmente.
Outro ponto importante é a flexibilidade de escopo. A proteção pode ser aplicada somente aos previews, somente à produção ou a ambos. Isso permite que times de desenvolvimento testem livremente em previews abertos, enquanto a produção permanece bloqueada — ou o contrário, dependendo da política de segurança. O controle de acesso pode ser baseado em membros da conta Cloudflare, endereços de e-mail específicos ou domínios de e-mail, o que cobre a maioria dos casos corporativos sem necessidade de configurar um IdP complexo.
Para políticas mais avançadas, o recurso permite edição direta no Cloudflare Zero Trust, onde é possível integrar Okta, Google Workspace, Azure AD, Ping Identity e outros provedores de identidade, além de aplicar regras de contexto, como país de origem, horário ou grupo do usuário. Isso faz do Cloudflare Access Workers uma ponte entre simplicidade e governança corporativa, algo raro em plataformas de borda.
Cloudflare Access Workers: como funciona a proteção por identidade na borda
Quando o Access está habilitado em um Worker, o fluxo de requisição muda. Em vez de a requisição ir direto ao runtime do Worker, ela primeiro passa pelo Cloudflare Access, que valida a identidade do chamador. Se não houver sessão válida, o usuário é redirecionado para o fluxo de login configurado — geralmente um IdP corporativo. Após autenticação, um cookie ou token de sessão é emitido, e a requisição segue para o Worker, já com o contexto de identidade disponível.
Do ponto de vista do desenvolvedor, a integração é exposta por meio do objeto ctx.access, presente no handler fetch do Worker. Se o Access não foi executado — por exemplo, se o Worker foi invocado por uma rota não protegida —, ctx.access é undefined, e o código pode responder com um erro 401. Se o Access rodou, o método ctx.access.getIdentity() retorna os dados do usuário: email, nome e grupos. Não é mais necessário validar JWTs manualmente nem parsear headers de autorização, o que elimina uma classe inteira de bugs e vulnerabilidades de implementação.
Veja um exemplo mínimo de Worker protegido:
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access did not run", { status: 401 });
}
const identity = await ctx.access.getIdentity();
return Response.json({ aud: ctx.access.aud, email: identity?.email });
},
};Nesse código, ctx.access.aud retorna o audience do Access, útil quando um mesmo Worker é associado a múltiplas políticas ou quando você precisa distinguir a origem da autenticação. O identity?.email entrega o e-mail do usuário autenticado, mas o objeto também pode conter nome e grupos, permitindo autorização fina no próprio código. Por exemplo, você pode permitir apenas membros do grupo eng-prod acessarem determinados endpoints, enquanto outros grupos recebem respostas de leitura.
Um recurso que merece destaque é o teste local com wrangler dev. Antes, testar fluxos autenticados localmente exigia configurações manuais ou deploys intermediários. Agora, você pode adicionar um bloco access ao wrangler.jsonc com uma identidade simulada:
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@example.com" }
}
}
}Com isso, o Worker local recebe a identidade simulada por meio de ctx.access e ctx.access.getIdentity(), permitindo testar fluxos autenticados e não autenticados sem nenhum deploy. Para simular uma requisição sem autenticação, basta remover o bloco dev ou usar uma configuração alternativa. Essa capacidade é extremamente valiosa para pipelines de CI/CD, onde testes de segurança precisam rodar de forma determinística antes do deploy.
Cloudflare Access Workers vs VPNs e IAM tradicional: a evolução Zero Trust
A comparação entre Cloudflare Access Workers e abordagens tradicionais de VPN ou IAM perimetral revela o quanto a segurança de aplicações mudou. Uma VPN cria um túnel entre o dispositivo do usuário e a rede corporativa, expondo toda a rede interna a qualquer credencial comprometida. O movimento lateral é quase inevitável: uma vez dentro, o atacante pode varrer portas, descobrir serviços e escalar privilégios. O Cloudflare Access elimina esse modelo ao adotar Zero Trust: cada aplicação valida a identidade do usuário individualmente, sem expor a rede.
Com o Cloudflare Access Workers, essa lógica se estende às aplicações serverless. O Worker não precisa saber qual VPN o usuário usou nem gerenciar tokens de aplicação. Ele recebe a identidade já validada pelo Access, com contexto rico: email, nome, grupos e audience. Isso permite políticas de autorização baseadas no usuário real, e não em chaves de API estáticas que podem vazar no código-fonte. Para empresas que ainda usam IAM tradicional com credenciais embutidas em funções, a diferença de segurança é abissal.
Outro aspecto é a superfície de ataque. Uma VPN exige um concentrador público, sujeito a ataques de força bruta, exploração de CVEs e DDoS. Um Worker protegido por Access não expõe nenhum porto, não aceita conexões arbitrárias e pode ser colocado atrás da mitigação de DDoS da Cloudflare automaticamente. A rede da Cloudflare já mitigou ataques superiores a 2 Tbps, e cada Worker herda essa proteção sem configuração adicional. Para aplicações internas, isso significa um nível de resiliência que seria caríssimo de reproduzir com appliances tradicionais.
Também vale destacar a integração com o restante do Cloudflare One. Além do Access, a suíte Zero Trust inclui Gateway para filtragem de DNS/HTTP, WARP como cliente de túnel para dispositivos, CASB para descoberta de shadow IT e Browser Isolation para sandbox de navegação. Quando você protege um Worker com Access, os logs de acesso podem ser integrados a Splunk, Datadog, BigQuery ou R2, gerando trilhas de auditoria prontas para compliance. Essa visibilidade unificada é algo que VPNs tradicionais raramente entregam sem custo adicional.
Do ponto de vista de experiência do usuário final, o Access Workers também vence. O login acontece uma única vez via SSO corporativo, com sessões curtas e renováveis, sem a necessidade de instalar clientes pesados ou lidar com conflitos de rota. Para times distribuídos no Brasil, onde a qualidade da conexão doméstica varia muito, eliminar o túnel VPN reduz a latência percebida e o consumo de banda, já que o tráfego não passa mais por um concentrador central muitas vezes localizado fora do país.
Configurando Cloudflare Access Workers: passo a passo no dashboard e API
Habilitar o Cloudflare Access Workers é surpreendentemente simples, e essa simplicidade é parte do design do produto. No dashboard da Cloudflare, a nova aba Access dentro da seção Workers & Pages concentra todas as políticas. Em vez de navegar por menus de Zero Trust, o desenvolvedor pode proteger um Worker diretamente de onde ele é gerenciado, reduzindo o atrito entre desenvolvimento e segurança.
O fluxo básico no dashboard segue estas etapas:
- Acesse Workers & Pages no dashboard da Cloudflare e abra a aba Access.
Sua empresa ainda não usa Cloudflare de forma estratégica?
A JRT Technology Solutions implementa Cloudflare CDN, WAF, Zero Trust e Workers para empresas que precisam de performance, segurança e escalabilidade.
