Zero Trust explicado: ZTNA em vez de VPN clássico
Zero Trust não significa deixar de confiar em todos. Significa que o acesso já não é concedido de forma ampla só porque um utilizador está na rede interna, na VPN ou numa localização conhecida. Cada acesso é verificado de forma consciente: quem acede? A partir de que dispositivo? A que aplicação? Em que condições?
Zero Trust Network Access, ou ZTNA, é uma implementação concreta desta ideia para remote access e aplicações privadas. Em vez de abrir uma rede inteira por VPN, um utilizador recebe acesso apenas às aplicações ou recursos previstos para a sua função.
Este artigo explica as bases de forma deliberadamente neutra em relação a fornecedores. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access e outras soluções aplicam princípios semelhantes de formas diferentes. A primeira decisão não é, portanto, o produto, mas o modelo de acesso.
Enquadrar Zero Trust e ZTNA
Zero Trust é uma arquitetura de segurança. ZTNA é um caminho técnico de acesso dentro dessa arquitetura.
Zero Trust é um princípio
Redes clássicas funcionam frequentemente com uma suposição implícita: dentro é mais confiável do que fora. Hoje, essa suposição é perigosa. Utilizadores trabalham remotamente, aplicações estão em SaaS, datacenter e cloud, dispositivos mudam constantemente de localização e credenciais comprometidas são um cenário realista.
Zero Trust desloca o foco de fronteiras de rede para identidade, dispositivo, aplicação, dados e contexto. A NIST descreve Zero Trust como uma arquitetura que reduz confiança implícita e avalia acesso por pedido. Na prática, um login bem-sucedido já não é suficiente.
ZTNA é acesso a recursos concretos
ZTNA substitui acessos amplos à rede por acesso baseado em recursos. Um utilizador não vê automaticamente uma subnet inteira, mas apenas as aplicações para as quais uma policy se aplica.
Recursos ZTNA típicos são:
- aplicações web internas,
- portais administrativos,
- acessos RDP ou SSH por caminhos controlados,
- aplicações TCP individuais,
- acessos de desenvolvimento, suporte ou parceiros,
- aplicações SaaS com controlo de acesso adicional.
Assim, o remote access torna-se mais granular. Uma conta comprometida não deve conseguir alcançar imediatamente toda a rede interna.
Porque ZTNA é diferente de VPN
VPN não é automaticamente mau. Muitos ambientes ainda precisam de site-to-site VPN, admin VPN, protocolos especiais ou acesso de emergência. A diferença está no modelo de confiança.
VPN muitas vezes abre uma rede
Um remote access VPN clássico liga um dispositivo a uma rede interna. Depois, routing, regras firewall, DNS e segmentação decidem o que é acessível. Se o ambiente estiver bem construído, isto pode funcionar. Na prática, redes VPN são frequentemente demasiado amplas, historicamente crescidas ou difíceis de rever.
Riscos típicos:
- Utilizadores recebem acesso a mais sistemas do que necessário.
- Grupos VPN antigos permanecem ativos.
- Split tunnel, DNS e rotas são pouco claros.
- Malware num cliente VPN pode alcançar destinos internos.
- Acesso admin usa o mesmo túnel que acesso de utilizadores.
ZTNA verifica mais perto da aplicação
ZTNA decide por aplicação ou recurso. Uma policy pode considerar grupo de utilizador, MFA, dispositivo, localização, risco, estado do cliente e outras condições. Só quando as condições correspondem é permitido acesso exatamente a esse recurso.
Isto reduz a superfície de ataque, mas não substitui uma aplicação segura. Uma aplicação insegura continua insegura mesmo atrás de ZTNA. ZTNA controla o acesso, não automaticamente a própria aplicação.
Componentes de um bom ambiente Zero Trust
Zero Trust é fraco quando é introduzido apenas como nova ferramenta de acesso. O valor surge quando vários componentes se encaixam.
Identidade e MFA
A identidade é o ponto de entrada mais importante. Utilizadores, grupos, funções e contas externas devem ser mantidos limpos. MFA deve ser obrigatório para acessos críticos. Em ambientes Microsoft, Microsoft Entra ID é frequentemente a fonte central de identidade; noutros ambientes, outros Identity Providers podem assumir a mesma função.
O offboarding também é importante. Quando um utilizador deixa a empresa, o acesso deve desaparecer não apenas numa aplicação, mas na identidade central e em todas as policies relevantes.
Dispositivo e contexto
ZTNA torna-se mais forte quando não só o utilizador, mas também o dispositivo é avaliado. Dependendo da solução, sistema operativo, estado do dispositivo, certificado, estado EDR, estado de gestão, localização ou risco podem influenciar a decisão.
Isto é especialmente relevante para:
- dispositivos pessoais,
- prestadores externos,
- acessos admin privilegiados,
- acesso a sistemas financeiros, HR ou produção,
- dispositivos sem estado de proteção atual.
Gateway, connector ou serviço cloud
ZTNA precisa de um caminho de dados entre utilizador e aplicação. Dependendo do fornecedor, existem gateways, connectors, túneis ou cloud PoPs. Esta parte decide onde o tráfego entra, quem opera o caminho de dados e que regras DNS, certificados e firewall são necessários.
Cloudflare trabalha frequentemente com Cloudflare Tunnel e Access Policies. Sophos ZTNA usa Sophos Central, ZTNA Gateways e policies de recursos. A arquitetura é diferente, mas a pergunta base permanece: como chega um utilizador de forma controlada à aplicação sem abrir toda a rede?
Policies, logging e operação
Uma policy ZTNA tem de continuar compreensível mais tarde. Por isso, nomes, grupos, condições e exceções devem ser documentados. Logging é obrigatório, porque sem isso não se reconhece se uma policy é demasiado ampla, se utilizadores são bloqueados ou se um acesso é usado inesperadamente muitas vezes.
Quando ZTNA faz sentido
ZTNA encaixa especialmente bem quando aplicações individuais devem ficar acessíveis de forma controlada. Não é um fim em si mesmo nem substitui automaticamente toda ligação.
Bons casos de uso
ZTNA costuma fazer sentido para:
- aplicações web internas para colaboradores,
- acessos de parceiros ou prestadores,
- portais admin que não devem estar públicos,
- RDP ou SSH por caminhos controlados,
- aplicações com grupos de utilizadores claros,
- ambientes onde o acesso VPN ficou demasiado amplo,
- substituição gradual de antigos modelos remote access.
Especialmente para prestadores externos, ZTNA é muitas vezes mais confortável que VPN. Não é preciso abrir uma rede inteira; pode publicar-se uma aplicação concreta com uma policy clara.
Onde VPN ainda encaixa
VPN continua útil quando redes inteiras precisam de ser ligadas, quando protocolos especiais não funcionam bem por ZTNA ou quando um acesso de emergência tem de ser independente de serviços cloud. Ligações site-to-site, alguns ambientes OT, aplicações legacy e cenários admin complexos podem continuar a exigir VPN.
A pergunta certa não é: “VPN ou ZTNA?” Melhor: “Que recurso precisa de que caminho de acesso?”
Avaliar fornecedores de forma neutra
Soluções ZTNA diferem bastante. Algumas são muito boas para aplicações baseadas em browser, outras para acesso com cliente e outras como parte de uma plataforma SSE ou SASE mais ampla.
Critérios importantes de escolha
Antes de escolher produto, esclarecer:
- Que aplicações devem ser acessíveis?
- É necessário acesso por browser, cliente ou ambos?
- Que Identity Provider já está definido?
- Os dispositivos devem ser verificados por posture?
- Onde está o caminho de dados: local próprio, cloud do fornecedor ou ambos?
- Como funcionam logs, exportação SIEM e audit?
- Existem processos claros de emergência e break-glass?
- Quão bem a solução encaixa com firewalls, EDR, MDM e DNS existentes?
Cloudflare é frequentemente forte quando Access, Tunnel, DNS, web security e infraestrutura edge global devem trabalhar em conjunto. Sophos ZTNA encaixa muitas vezes bem em ambientes que já usam intensamente Sophos Central, Sophos Endpoint ou Sophos Firewall. Isto não é uma questão de crença, mas de arquitetura.
Nem todo Zero Trust é automaticamente melhor
ZTNA mal mantido é apenas um risco mais moderno. Se grupos são demasiado amplos, exceções antigas permanecem, ninguém lê logs ou a verificação de dispositivos existe só no papel, não surge um ambiente Zero Trust forte.
Introduzir em ordem sensata
Uma boa introdução não começa com o clique no produto, mas com uma aplicação pequena e bem compreendida.
- Inventariar aplicações e ordenar por risco.
- Limpar grupos de utilizadores e funções externas.
- Estabilizar Identity Provider e MFA.
- Escolher uma aplicação piloto importante, mas controlável.
- Planear caminho de dados, DNS, certificado e logging.
- Testar a policy com um pequeno grupo de utilizadores.
- Rever logs, recolher casos de suporte e melhorar a experiência.
- Migrar outras aplicações passo a passo.
- Reduzir acessos VPN só quando ZTNA funciona em operação.
Para ambientes Sophos específicos, Configurar Sophos ZTNA: visão geral e sequência é o passo seguinte. Se o tema concreto for o gateway, Planear e criar Sophos ZTNA Gateway ajuda.
Erros típicos
Tratar ZTNA como simples substituição de VPN
Se apenas o túnel for substituído, mas grupos, aplicações, dispositivos e logs permanecerem iguais, o ganho de segurança é pequeno. ZTNA deve ser planeado por recurso.
Migrar demasiadas aplicações ao mesmo tempo
Um grande rollout big-bang é arriscado. Melhor é um piloto com uma aplicação real, critérios de sucesso claros e caminho de fallback limpo.
Esquecer o acesso de emergência
Identity Provider, DNS, serviço cloud ou gateway podem falhar. Admins precisam de um acesso break-glass documentado, fortemente protegido, raramente usado e revisto regularmente.
Não operar os logs
ZTNA sem logging é difícil de suportar. Deve ser visível que utilizador acede a que recurso, que policy se aplica, porque um acesso foi bloqueado e se surgem padrões incomuns.
Checklist operacional
- Documentar aplicações e owners.
- Manter grupos de utilizadores pequenos e compreensíveis.
- Impor MFA para acessos críticos.
- Usar verificação de dispositivos ativamente se a solução a suportar bem.
- Rever policies regularmente contra uso real.
- Enviar logs para SIEM ou logging central se o acesso for crítico.
- Documentar e testar acesso break-glass.
- Remover permissões VPN antigas após migração bem-sucedida.
- Atribuir aos acessos de prestadores uma data de expiração ou review.