{"id":2283,"date":"2026-08-16T17:10:06","date_gmt":"2026-08-16T20:10:06","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/08\/16\/cloudflare-access-workers-zero-trust-automatico-para-workers\/"},"modified":"2026-08-16T17:10:06","modified_gmt":"2026-08-16T20:10:06","slug":"cloudflare-access-workers-zero-trust-automatico-para-workers","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/08\/16\/cloudflare-access-workers-zero-trust-automatico-para-workers\/","title":{"rendered":"Cloudflare Access Workers: Zero Trust autom\u00e1tico para Workers"},"content":{"rendered":"

A Cloudflare acaba de anunciar o Cloudflare Access Workers<\/strong>, uma mudan\u00e7a profunda na forma como desenvolvedores protegem aplica\u00e7\u00f5es serverless na borda. Antes, proteger um Worker com acesso autenticado exigia cadastrar manualmente cada dom\u00ednio, rota ou preview URL em uma pol\u00edtica do Cloudflare Access<\/strong> \u2014 um processo fr\u00e1gil, sujeito a falhas de sincroniza\u00e7\u00e3o e quase imposs\u00edvel de escalar em ambientes com dezenas de microsservi\u00e7os. Agora, a pol\u00edtica de acesso \u00e9 anexada diretamente ao pr\u00f3prio Worker e se aplica automaticamente a todos os pontos onde ele \u00e9 publicado: rotas<\/strong>, custom domains<\/strong>, workers.dev<\/strong> e previews<\/strong>. Para times de plataforma, seguran\u00e7a e engenharia, isso elimina uma camada inteira de complexidade operacional e reduz a superf\u00edcie de ataque de aplica\u00e7\u00f5es internas, dashboards e APIs que hoje rodam na borda sem nenhuma autentica\u00e7\u00e3o.<\/p>\n

O an\u00fancio chega em um momento em que a computa\u00e7\u00e3o na borda deixou de ser tend\u00eancia para se tornar infraestrutura padr\u00e3o. A rede da Cloudflare j\u00e1 est\u00e1 presente em mais de 300 cidades<\/strong> em mais de 100 pa\u00edses<\/strong>, operando o AS13335<\/strong> \u2014 um dos maiores sistemas aut\u00f4nomos do mundo \u2014 e respondendo por aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP<\/strong> da internet. Com mais de 275 pontos de presen\u00e7a<\/strong> executando o runtime de Workers, uma fun\u00e7\u00e3o pode iniciar em menos de 1 milissegundo de cold start<\/strong>, algo imposs\u00edvel de alcan\u00e7ar em arquiteturas tradicionais baseadas em VMs ou containers regionais.<\/p>\n

O contexto de 2026 tamb\u00e9m importa. O Cloudflare DDoS Threat Report H1 2026<\/strong> registrou um aumento de 519% em ataques hipervolum\u00e9tricos<\/strong>, impulsionados por vetores de reflex\u00e3o DNS<\/strong> e CLDAP<\/strong> e por tens\u00f5es geopol\u00edticas crescentes. Ao mesmo tempo, o uso de ferramentas de IA generativa para criar aplica\u00e7\u00f5es internas \u2014 o chamado vibe coding<\/strong> \u2014 explodiu, e com ele o n\u00famero de endpoints n\u00e3o protegidos expostos na internet corporativa. \u00c9 exatamente essa lacuna que o Cloudflare Access Workers pretende fechar: qualquer Worker, seja ele escrito por um engenheiro s\u00eanior ou gerado por um assistente de c\u00f3digo, pode ser colocado atr\u00e1s de autentica\u00e7\u00e3o forte em poucos cliques.<\/p>\n

Para empresas brasileiras, a relev\u00e2ncia \u00e9 direta. A lat\u00eancia at\u00e9 regi\u00f5es de nuvem concentradas nos Estados Unidos costuma girar em torno de 100 a 150 ms<\/strong> ida e volta, dependendo da rota. Com Workers executando em pontos de presen\u00e7a locais, incluindo S\u00e3o Paulo e outras capitais, esse tempo pode cair para menos de 20 ms<\/strong> na mesma regi\u00e3o \u2014 um ganho decisivo para APIs de pagamento, autentica\u00e7\u00e3o e e-commerce. Al\u00e9m disso, a capacidade de aplicar pol\u00edticas de identidade na borda facilita a conformidade com a LGPD<\/strong>, uma vez que o controle de acesso passa a ser granular e audit\u00e1vel, sem depender de t\u00faneis VPN que ampliam a superf\u00edcie de rede.<\/p>\n

Neste artigo, voc\u00ea vai entender em profundidade como o Cloudflare Access Workers<\/strong> funciona, como habilit\u00e1-lo no dashboard ou via API, quais s\u00e3o os ganhos em rela\u00e7\u00e3o 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\u00e9m com Lambda@Edge<\/strong> e Vercel Edge<\/strong>, e fechar com recomenda\u00e7\u00f5es pr\u00e1ticas da JRT Technology Solutions<\/strong> para ado\u00e7\u00e3o corporativa.<\/p>\n

O que \u00e9 Cloudflare Access Workers e por que ele muda o jogo<\/h3>\n

O Cloudflare Access Workers<\/strong> \u00e9 a integra\u00e7\u00e3o nativa entre o Cloudflare Access<\/strong> \u2014 solu\u00e7\u00e3o Zero Trust que substitui VPN por autentica\u00e7\u00e3o baseada em identidade \u2014 e o Cloudflare Workers<\/strong>, plataforma de computa\u00e7\u00e3o serverless na borda. At\u00e9 agora, proteger um Worker era um exerc\u00edcio de configura\u00e7\u00e3o manual: cada dom\u00ednio associado precisava ser adicionado individualmente como uma aplica\u00e7\u00e3o no Access, incluindo workers.dev<\/strong>, dom\u00ednios customizados e URLs de preview geradas automaticamente. Se um novo dom\u00ednio fosse adicionado ou uma rota mudasse, a lista ficava desatualizada, criando brechas silenciosas.<\/p>\n

Com o novo recurso, a pol\u00edtica do Access \u00e9 anexada ao objeto do Worker, e n\u00e3o aos seus dom\u00ednios. Isso significa que, independentemente de quantos dom\u00ednios apontem para ele, a prote\u00e7\u00e3o segue o Worker. Se voc\u00ea adicionar um novo custom domain amanh\u00e3, ele j\u00e1 nasce protegido. Se um preview for gerado para um pull request, ele tamb\u00e9m herda a pol\u00edtica automaticamente. Essa abordagem inverte a l\u00f3gica tradicional de seguran\u00e7a perimetral: em vez de proteger a entrada, protege-se a aplica\u00e7\u00e3o onde ela vive, com identidade no centro.<\/p>\n

O an\u00fancio \u00e9 duplo. Primeiro, \u00e9 poss\u00edvel proteger um Worker individual ou um grupo de Workers de uma s\u00f3 vez. Segundo, \u00e9 poss\u00edvel ativar um modo “private by default”<\/strong>, que torna todos os Workers existentes e futuros da conta privados por padr\u00e3o. Nesse modo, qualquer Worker rec\u00e9m-criado j\u00e1 exige sign-in antes de responder a qualquer requisi\u00e7\u00e3o. Se um Worker espec\u00edfico precisa permanecer p\u00fablico \u2014 por exemplo, um endpoint de health check ou um webhook \u2014 basta adicionar um bypass<\/strong> no n\u00edvel do Worker. Essa granularidade \u00e9 essencial para empresas que adotam serverless em escala e n\u00e3o querem depender de desenvolvedores lembrando de configurar seguran\u00e7a manualmente.<\/p>\n

Outro ponto importante \u00e9 a flexibilidade de escopo. A prote\u00e7\u00e3o pode ser aplicada somente aos previews<\/strong>, somente \u00e0 produ\u00e7\u00e3o<\/strong> ou a ambos<\/strong>. Isso permite que times de desenvolvimento testem livremente em previews abertos, enquanto a produ\u00e7\u00e3o permanece bloqueada \u2014 ou o contr\u00e1rio, dependendo da pol\u00edtica de seguran\u00e7a. O controle de acesso pode ser baseado em membros da conta Cloudflare<\/strong>, endere\u00e7os de e-mail espec\u00edficos<\/strong> ou dom\u00ednios de e-mail<\/strong>, o que cobre a maioria dos casos corporativos sem necessidade de configurar um IdP complexo.<\/p>\n

Para pol\u00edticas mais avan\u00e7adas, o recurso permite edi\u00e7\u00e3o direta no Cloudflare Zero Trust<\/strong>, onde \u00e9 poss\u00edvel integrar Okta<\/strong>, Google Workspace<\/strong>, Azure AD<\/strong>, Ping Identity<\/strong> e outros provedores de identidade, al\u00e9m de aplicar regras de contexto, como pa\u00eds de origem, hor\u00e1rio ou grupo do usu\u00e1rio. Isso faz do Cloudflare Access Workers uma ponte entre simplicidade e governan\u00e7a corporativa, algo raro em plataformas de borda.<\/p>\n

Cloudflare Access Workers: como funciona a prote\u00e7\u00e3o por identidade na borda<\/h3>\n

Quando o Access est\u00e1 habilitado em um Worker, o fluxo de requisi\u00e7\u00e3o muda. Em vez de a requisi\u00e7\u00e3o ir direto ao runtime do Worker, ela primeiro passa pelo Cloudflare Access<\/strong>, que valida a identidade do chamador. Se n\u00e3o houver sess\u00e3o v\u00e1lida, o usu\u00e1rio \u00e9 redirecionado para o fluxo de login configurado \u2014 geralmente um IdP corporativo. Ap\u00f3s autentica\u00e7\u00e3o, um cookie ou token de sess\u00e3o \u00e9 emitido, e a requisi\u00e7\u00e3o segue para o Worker, j\u00e1 com o contexto de identidade dispon\u00edvel.<\/p>\n

Do ponto de vista do desenvolvedor, a integra\u00e7\u00e3o \u00e9 exposta por meio do objeto ctx.access<\/code><\/strong>, presente no handler fetch<\/code> do Worker. Se o Access n\u00e3o foi executado \u2014 por exemplo, se o Worker foi invocado por uma rota n\u00e3o protegida \u2014, ctx.access<\/code> \u00e9 undefined<\/code>, e o c\u00f3digo pode responder com um erro 401<\/strong>. Se o Access rodou, o m\u00e9todo ctx.access.getIdentity()<\/code><\/strong> retorna os dados do usu\u00e1rio: email<\/strong>, nome<\/strong> e grupos<\/strong>. N\u00e3o \u00e9 mais necess\u00e1rio validar JWTs manualmente nem parsear headers de autoriza\u00e7\u00e3o, o que elimina uma classe inteira de bugs e vulnerabilidades de implementa\u00e7\u00e3o.<\/p>\n

Veja um exemplo m\u00ednimo de Worker protegido:<\/p>\n

export default {\n  async fetch(request, env, ctx) {\n    if (!ctx.access) {\n      return new Response(\"Access did not run\", { status: 401 });\n    }\n\n    const identity = await ctx.access.getIdentity();\n    return Response.json({ aud: ctx.access.aud, email: identity?.email });\n  },\n};<\/code><\/pre>\n
Nesse c\u00f3digo, ctx.access.aud<\/code><\/strong> retorna o audience<\/em> do Access, \u00fatil quando um mesmo Worker \u00e9 associado a m\u00faltiplas pol\u00edticas ou quando voc\u00ea precisa distinguir a origem da autentica\u00e7\u00e3o. O identity?.email<\/code> entrega o e-mail do usu\u00e1rio autenticado, mas o objeto tamb\u00e9m pode conter nome<\/strong> e grupos<\/strong>, permitindo autoriza\u00e7\u00e3o fina no pr\u00f3prio c\u00f3digo. Por exemplo, voc\u00ea pode permitir apenas membros do grupo eng-prod<\/strong> acessarem determinados endpoints, enquanto outros grupos recebem respostas de leitura.<\/p>\n
Um recurso que merece destaque \u00e9 o teste local com wrangler dev<\/strong>. Antes, testar fluxos autenticados localmente exigia configura\u00e7\u00f5es manuais ou deploys intermedi\u00e1rios. Agora, voc\u00ea pode adicionar um bloco access<\/code><\/strong> ao wrangler.jsonc<\/code><\/strong> com uma identidade simulada:<\/p>\n
{\n  \"access\": {\n    \"dev\": {\n      \"aud\": \"my-app\",\n      \"identity\": { \"email\": \"admin@example.com\" }\n    }\n  }\n}<\/code><\/pre>\n
Com isso, o Worker local recebe a identidade simulada por meio de ctx.access<\/code> e ctx.access.getIdentity()<\/code>, permitindo testar fluxos autenticados e n\u00e3o autenticados sem nenhum deploy. Para simular uma requisi\u00e7\u00e3o sem autentica\u00e7\u00e3o, basta remover o bloco dev<\/code> ou usar uma configura\u00e7\u00e3o alternativa. Essa capacidade \u00e9 extremamente valiosa para pipelines de CI\/CD, onde testes de seguran\u00e7a precisam rodar de forma determin\u00edstica antes do deploy.<\/p>\n
Cloudflare Access Workers vs VPNs e IAM tradicional: a evolu\u00e7\u00e3o Zero Trust<\/h3>\n
A compara\u00e7\u00e3o entre Cloudflare Access Workers<\/strong> e abordagens tradicionais de VPN ou IAM perimetral revela o quanto a seguran\u00e7a de aplica\u00e7\u00f5es mudou. Uma VPN cria um t\u00fanel entre o dispositivo do usu\u00e1rio e a rede corporativa, expondo toda a rede interna a qualquer credencial comprometida. O movimento lateral \u00e9 quase inevit\u00e1vel: uma vez dentro, o atacante pode varrer portas, descobrir servi\u00e7os e escalar privil\u00e9gios. O Cloudflare Access<\/strong> elimina esse modelo ao adotar Zero Trust<\/strong>: cada aplica\u00e7\u00e3o valida a identidade do usu\u00e1rio individualmente, sem expor a rede.<\/p>\n
Com o Cloudflare Access Workers, essa l\u00f3gica se estende \u00e0s aplica\u00e7\u00f5es serverless. O Worker n\u00e3o precisa saber qual VPN o usu\u00e1rio usou nem gerenciar tokens de aplica\u00e7\u00e3o. Ele recebe a identidade j\u00e1 validada pelo Access, com contexto rico: email<\/strong>, nome<\/strong>, grupos<\/strong> e audience<\/strong>. Isso permite pol\u00edticas de autoriza\u00e7\u00e3o baseadas no usu\u00e1rio real, e n\u00e3o em chaves de API est\u00e1ticas que podem vazar no c\u00f3digo-fonte. Para empresas que ainda usam IAM tradicional<\/strong> com credenciais embutidas em fun\u00e7\u00f5es, a diferen\u00e7a de seguran\u00e7a \u00e9 abissal.<\/p>\n
Outro aspecto \u00e9 a superf\u00edcie de ataque<\/strong>. Uma VPN exige um concentrador p\u00fablico, sujeito a ataques de for\u00e7a bruta, explora\u00e7\u00e3o de CVEs e DDoS. Um Worker protegido por Access n\u00e3o exp\u00f5e nenhum porto, n\u00e3o aceita conex\u00f5es arbitr\u00e1rias e pode ser colocado atr\u00e1s da mitiga\u00e7\u00e3o de DDoS da Cloudflare automaticamente. A rede da Cloudflare j\u00e1 mitigou ataques superiores a 2 Tbps<\/strong>, e cada Worker herda essa prote\u00e7\u00e3o sem configura\u00e7\u00e3o adicional. Para aplica\u00e7\u00f5es internas, isso significa um n\u00edvel de resili\u00eancia que seria car\u00edssimo de reproduzir com appliances tradicionais.<\/p>\n
Tamb\u00e9m vale destacar a integra\u00e7\u00e3o com o restante do Cloudflare One<\/strong>. Al\u00e9m do Access, a su\u00edte Zero Trust inclui Gateway<\/strong> para filtragem de DNS\/HTTP, WARP<\/strong> como cliente de t\u00fanel para dispositivos, CASB<\/strong> para descoberta de shadow IT e Browser Isolation<\/strong> para sandbox de navega\u00e7\u00e3o. Quando voc\u00ea protege um Worker com Access, os logs de acesso podem ser integrados a Splunk<\/strong>, Datadog<\/strong>, BigQuery<\/strong> ou R2<\/strong>, gerando trilhas de auditoria prontas para compliance. Essa visibilidade unificada \u00e9 algo que VPNs tradicionais raramente entregam sem custo adicional.<\/p>\n
Do ponto de vista de experi\u00eancia do usu\u00e1rio final, o Access Workers tamb\u00e9m vence. O login acontece uma \u00fanica vez via SSO corporativo, com sess\u00f5es curtas<\/strong> e renov\u00e1veis, sem a necessidade de instalar clientes pesados ou lidar com conflitos de rota. Para times distribu\u00eddos no Brasil, onde a qualidade da conex\u00e3o dom\u00e9stica varia muito, eliminar o t\u00fanel VPN reduz a lat\u00eancia percebida e o consumo de banda, j\u00e1 que o tr\u00e1fego n\u00e3o passa mais por um concentrador central muitas vezes localizado fora do pa\u00eds.<\/p>\n
Configurando Cloudflare Access Workers: passo a passo no dashboard e API<\/h3>\n
Habilitar o Cloudflare Access Workers<\/strong> \u00e9 surpreendentemente simples, e essa simplicidade \u00e9 parte do design do produto. No dashboard da Cloudflare, a nova aba Access<\/strong> dentro da se\u00e7\u00e3o Workers & Pages<\/strong> concentra todas as pol\u00edticas. Em vez de navegar por menus de Zero Trust, o desenvolvedor pode proteger um Worker diretamente de onde ele \u00e9 gerenciado, reduzindo o atrito entre desenvolvimento e seguran\u00e7a.<\/p>\n
O fluxo b\u00e1sico no dashboard segue estas etapas:<\/p>\n
    \n
  1. Acesse Workers & Pages<\/strong> no dashboard da Cloudflare e abra a aba Access<\/strong>.<\/li<\/ol>\n
    \n
    Sua empresa ainda n\u00e3o usa Cloudflare de forma estrat\u00e9gica?<\/p>\n
    A JRT Technology Solutions implementa Cloudflare CDN, WAF, Zero Trust e Workers para empresas que precisam de performance, seguran\u00e7a e escalabilidade.<\/p>\n
      
    \n    <\/svg>
    \n    Falar com especialista
    \n  <\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
    A Cloudflare acaba de anunciar o Cloudflare Access Workers, uma mudan\u00e7a profunda na forma como desenvolvedores protegem aplica\u00e7\u00f5es serverless na borda. Antes, proteger um Worker com acesso autenticado exigia cadastrar manualmente cada dom\u00ednio, rota ou preview URL em uma pol\u00edtica do Cloudflare Access \u2014 um processo fr\u00e1gil, sujeito a falhas de sincroniza\u00e7\u00e3o e quase imposs\u00edvel … Ler mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":2282,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"iawp_total_views":1,"footnotes":""},"categories":[1721],"tags":[3323],"class_list":["post-2283","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cdn-cloudflare","tag-cloudflare-access-workers"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t