A VPN corporativa não falhou porque foi mal implementada. Ela falhou porque foi construída sobre uma premissa que deixou de ser verdadeira: que estar dentro da rede da empresa é suficiente para confiar em alguém. Quando um colaborador conecta de casa, de uma rede de hotel ou de um café com a mesma VPN da equipe do escritório, o perímetro de rede como conceito de segurança deixa de existir. O que resta é uma ilusão de controle sustentada por inércia operacional.
O Cloudflare Zero Trust parte de uma premissa diferente: identidade, dispositivo e contexto da requisição determinam acesso — não o endereço IP de origem. A implementação concreta disso envolve três componentes que têm papéis distintos e são frequentemente confundidos mesmo por quem já os colocou em produção.
Access, Tunnel e WARP: o que cada um faz
O Cloudflare Access é um gateway de identidade para aplicações. Quando uma requisição chega ao domínio interno publicado via Cloudflare, o Access intercepta antes de a requisição atingir a origem. O usuário autentica com o identity provider configurado — Okta, Azure AD, Google Workspace, ou qualquer provedor SAML 2.0 e OIDC. Somente após autenticação e avaliação da política o tráfego segue para a origem. A aplicação nunca recebe requisição não autenticada.
O Cloudflare Tunnel, executado pelo daemon cloudflared, opera no lado do servidor. Ele cria uma conexão de saída criptografada do servidor para o edge da Cloudflare, sem abrir portas de entrada no firewall. O fluxo completo: usuário autentica pelo Access → Cloudflare edge valida → tráfego chega pelo Tunnel ao serviço interno. O servidor interno não precisa de IP público, não precisa de regra de entrada no security group, não fica exposto à internet diretamente.
O WARP é o cliente de dispositivo. Em modo Zero Trust, ele roteia o tráfego do dispositivo pelo edge da Cloudflare via protocolo WireGuard. Isso habilita verificações de postura — criptografia de disco, versão de SO, agente de segurança instalado — e permite que políticas do Access incluam estado do dispositivo como condição. Para aplicações web acessadas pelo navegador, o WARP frequentemente não é necessário. Para protocolos não-HTTP como SSH e RDP roteados pelo Tunnel, ele é obrigatório.
Como o fluxo de autenticação funciona
A sequência concreta para um desenvolvedor acessando um serviço interno: o usuário acessa app.empresa.com. O Access detecta que não há sessão válida e redireciona para o identity provider. O usuário autentica — com MFA se a política exigir. O IdP retorna ao Access com identidade confirmada e atributos de grupo. O Access avalia a política: este usuário pertence ao grupo com permissão para este app? Se aprovado, emite um JWT de sessão e a requisição vai ao edge, descendo pelo Tunnel ao serviço na rede interna.
Para protocolos não-HTTP — SSH, por exemplo — o fluxo passa pelo WARP. O cliente estabelece o túnel WireGuard, a política de postura é verificada, e o tráfego SSH roteia pelo Cloudflare até o destino via Tunnel.
Identidade e provedores suportados
O Access aceita múltiplos identity providers simultaneamente na mesma organização. Uma aplicação pode permitir autenticação via Google Workspace para funcionários e via GitHub para colaboradores externos. Outra pode exigir exclusivamente Okta com MFA obrigatório. Os grupos sincronizados do IdP — times de engenharia, squads específicos, departamentos — alimentam as políticas do Access diretamente, sem sincronização manual de listas.
Além de humanos, o Access gerencia acesso machine-to-machine via service tokens. Um pipeline de CI/CD que precisa atingir um endpoint interno autenticado recebe um client ID e secret, que substituem o fluxo de SSO humano. Todo acesso, humano ou automatizado, gera evento de auditoria com identidade, timestamp, IP, dispositivo e decisão tomada — exportável via Logpush para SIEM, Splunk ou Datadog.
O que o Zero Trust não faz
O Cloudflare Zero Trust controla quem chega ao quê, mas não é solução de criptografia de dados em trânsito dentro da aplicação — isso continua sendo responsabilidade da própria aplicação via HTTPS. O Access também não substitui firewall para tráfego east-west entre serviços dentro do datacenter ou VPC. Para comunicação interna entre microserviços, mTLS ou service mesh continuam sendo o mecanismo adequado.
Um ponto que escapa em implementações iniciais: o Tunnel protege o caminho entre o edge da Cloudflare e o servidor de origem, mas o servidor ainda precisa confiar apenas em conexões vindas pelo cloudflared. Se a porta 443 estiver aberta para a internet fora do Tunnel, o Access pode ser bypassado. A prática correta é bloquear todo tráfego de entrada no servidor exceto o gerado pelo daemon local do Tunnel.
O que a adoção muda operacionalmente
A mudança mais significativa não é técnica — é o modelo mental de quem gerencia acesso. Com VPN, o time de rede configura rotas e split tunnels; com Zero Trust, o time de identidade configura políticas por aplicação. A gestão de acesso sai do nível de rede e entra no nível de identidade. Para organizações com times de rede e segurança separados, isso envolve negociação de responsabilidade.
O tier gratuito — até 50 usuários com Access, Tunnel, WARP e Gateway básico — é suficiente para validação em produção. O plano Team custa $7 por usuário por mês e adiciona logs de auditoria e Gateway com filtragem HTTP. Enterprise adiciona Browser Isolation, DLP e segurança de email, com precificação negociada. Para times com mais de 50 usuários que já têm Okta ou Azure AD consolidados, o esforço de implantação raramente ultrapassa quatro semanas de trabalho real.
O que avaliar antes de migrar
A decisão de migrar para Zero Trust não é sobre tecnologia — é sobre onde o maior risco de segurança está hoje. Se a VPN atual concede acesso de rede amplo após autenticação, uma credencial comprometida expõe toda a rede interna. Zero Trust limita o raio de explosão: o acesso comprometido alcança apenas o conjunto de aplicações explicitamente permitidas para aquela identidade, com postura de dispositivo como controle adicional.
Comece pela aplicação com maior risco de exposição e maior custo em caso de vazamento. Migrá-la primeiro, com política restrita por grupo e device posture obrigatório, valida o modelo completo em produção com impacto controlável. O padrão testado nela é replicado para o restante do portfólio.