Há uma confusão recorrente em times que estão adotando o Cloudflare Zero Trust: tratar Access e Tunnel como partes intercambiáveis do mesmo sistema, quando na prática são produtos com responsabilidades completamente distintas. Um engenheiro que configura o Tunnel e assume que a autenticação está resolvida está publicando um serviço privado sem nenhuma gate de identidade. Entender o que cada peça faz — e quando é válido usar uma sem a outra — é o que separa uma implantação bem arquitetada de uma brecha esperando para ser explorada.
O que o Cloudflare Access faz
O Access é um proxy de identidade. Ele fica na frente de um hostname — app.empresa.com, por exemplo — e intercepta cada requisição antes que ela chegue à origem. Quando o usuário não tem sessão válida, o Access redireciona para o identity provider configurado. Após autenticação bem-sucedida, o Access avalia a política associada àquela aplicação: o usuário pertence ao grupo permitido? A autenticação usou MFA? O dispositivo está em conformidade? Se todas as condições forem satisfeitas, o Access emite um JWT de sessão e a requisição segue para a origem.
A origem pode ser qualquer coisa — um servidor com IP público, um serviço interno, um Tunnel. O Access não se importa com onde a origem está; ele se importa com quem está tentando chegar lá. Essa distinção é importante porque significa que o Access funciona em frente a aplicações que já têm IP público, sem necessidade de Tunnel. Se você tem uma aplicação com IP público que precisa de controle de acesso baseado em identidade corporativa, o Access resolve isso sem mover a aplicação ou instalar o cloudflared.
O que o Cloudflare Tunnel faz
O Tunnel resolve um problema diferente: como tornar um servidor privado alcançável pela internet sem abrir portas de entrada no firewall. O daemon cloudflared, instalado no servidor ou em um container na mesma rede, estabelece uma conexão de saída criptografada para o edge da Cloudflare. A partir daí, o Cloudflare age como intermediário — tráfego de entrada chega ao edge e desce pelo túnel já estabelecido até o serviço interno.
O resultado é que o servidor interno não tem IP público, não tem porta 80 ou 443 aberta para a internet, e não precisa de regra de entrada no security group ou firewall. O único tráfego que entra é o que vem pelo próprio processo do cloudflared rodando localmente. Um servidor completamente isolado de acesso externo direto passa a ser alcançável por usuários autorizados através do edge da Cloudflare.
O cloudflared pode ser configurado como serviço systemd, container Docker, ou deployment Kubernetes. A configuração moderna usa o dashboard da Cloudflare para gerenciar o Tunnel — sem arquivo YAML local, com configuração propagada via API. Um único processo cloudflared pode expor múltiplos serviços em hostnames diferentes: app1.empresa.com vai para a porta 3000 localmente, app2.empresa.com vai para a porta 4000, db-admin.empresa.com vai para o pgAdmin na porta 5050.
Quando usar Tunnel sem Access
Tunnel sem Access é um cenário válido e comum: você quer rotear tráfego de uma aplicação pública pelo edge da Cloudflare para proteção DDoS e CDN, sem autenticação adicional. O serviço é acessível publicamente, mas o tráfego chega ao servidor somente via Cloudflare — sem exposição direta do IP de origem. A Cloudflare protege contra ataques volumétricos e o servidor fica oculto.
Outro uso: desenvolvimento local compartilhado. Um developer quer mostrar um protótipo rodando localmente para alguém fora da rede. O cloudflared tunnel --url localhost:3000 cria um URL temporário acessível publicamente sem configuração de DNS ou firewall. Sem Access, sem autenticação — mas útil para o caso específico.
O risco é assumir que Tunnel implica proteção. Não implica. Tunnel é conectividade. Sem Access na frente, qualquer requisição que chega ao hostname configurado no Cloudflare chega ao seu serviço interno.
Quando usar Access sem Tunnel
Access sem Tunnel faz sentido quando a origem já tem IP público — um servidor em EC2 com IP elástico, uma aplicação em um PaaS, um endpoint de API com endereço público. O Access fica como proxy de identidade na frente desse endereço público, sem necessidade de cloudflared.
O detalhe operacional crítico nesse cenário: a origem precisa aceitar tráfego apenas do edge da Cloudflare. Se o servidor continua aceitando requisições de qualquer IP, o Access pode ser bypassado simplesmente acessando o IP diretamente. A prática correta é configurar o servidor para aceitar tráfego apenas dos IP ranges da Cloudflare, ou usar um header autenticado que o Access injeta e a aplicação verifica.
A combinação que entrega Zero Trust de fato
A combinação dos dois é o que implementa o modelo Zero Trust completo: o Tunnel torna o servidor privado alcançável via Cloudflare; o Access exige autenticação e avaliação de política antes de permitir que qualquer requisição desça pelo Tunnel. O servidor interno nunca tem exposição direta à internet e nunca recebe requisição não autenticada.
O fluxo: usuário acessa o hostname → Access verifica sessão, redireciona para IdP se necessário → após autenticação e policy check, Access encaminha a requisição ao edge → edge desce pelo Tunnel → cloudflared entrega ao processo local. O servidor interno vê apenas tráfego já autorizado pelo Access.
Para acesso machine-to-machine — pipelines de CI/CD, agentes de monitoramento, integrações — o Access emite service tokens: um client ID e um secret que substituem o fluxo de SSO humano. O serviço automatizado inclui esses tokens no header da requisição, e o Access os reconhece como identidade de serviço confiável, aplicando a política associada. Todo acesso via service token também gera evento de auditoria.
A visão de quem arquiteta o sistema
Um ponto que escapa na fase de projeto: Tunnel não tem custo de egress na Cloudflare. Tráfego que passa pelo cloudflared não é cobrado por largura de banda no plano Team. Isso tem implicação real de custo em comparação com alternativas que cobram por GB transferido — e influencia a decisão de usar Cloudflare Tunnel versus soluções similares de tunelamento.
A decisão arquitetural central ao adotar os dois componentes é: onde ficam as políticas de acesso? O Access permite criar políticas granulares por aplicação — um grupo tem acesso ao painel de admin, outro tem acesso somente leitura ao monitoramento, colaboradores externos chegam apenas ao portal de documentação. Essa granularidade não existe em VPN tradicional. O custo de manter essa granularidade é a gestão contínua das políticas à medida que times mudam e aplicações evoluem. Automatizar isso via Terraform ou via API da Cloudflare é o passo que transforma a gestão de acesso de tarefa manual em processo controlado.