O relatório ThreatLabz VPN Risk Report, publicado em 2025 pela Cybersecurity Insiders, trouxe um dado que resume a velocidade da transição que está ocorrendo agora das VPNs tradicionais para ZTNA: ao menos 65% das empresas globais planejam substituir suas VPNs dentro de um ano, um aumento de 23 pontos percentuais em relação ao período anterior. Ao mesmo tempo, 56% das empresas entrevistadas sofreram violações exploradas por meio de vulnerabilidades de VPN, e 92% expressaram preocupação com ataques de ransomware originados por falhas não corrigidas nessa tecnologia.
O número de CVEs relacionadas a VPN cresceu 82,5% entre 2020 e 2024, com cerca de 60% classificadas como severidade alta ou crítica. A VPN, que por duas décadas foi sinônimo de acesso remoto seguro, tornou-se um dos vetores de entrada mais explorados por atacantes. É nesse contexto que o ZTNA, ou Zero Trust Network Access, se consolida como a alternativa arquitetural que não apenas corrige as limitações da VPN, mas redefine a lógica de como o acesso a aplicações corporativas é concedido e controlado.
O que é ZTNA e como ele funciona
ZTNA é a sigla para Zero Trust Network Access, ou Acesso de Rede de Confiança Zero. Trata-se de uma categoria de tecnologias que fornece acesso remoto seguro a aplicações e serviços com base em políticas de controle de acesso definidas por identidade, contexto e postura do dispositivo. Diferentemente da VPN, que conecta o usuário à rede inteira após uma autenticação inicial, o ZTNA concede acesso apenas à aplicação específica solicitada e nega tudo o mais por padrão. O princípio é direto: nunca confie, sempre verifique. Cada requisição de acesso é avaliada individualmente, levando em conta quem está pedindo, de qual dispositivo, em qual localização, a que horas e sob quais condições de segurança.
Do ponto de vista técnico, o ZTNA opera por meio de três componentes centrais: um agente ou cliente no endpoint do usuário, um broker ou controlador de políticas, geralmente baseado em nuvem, e um conector na rede na qual reside o recurso protegido. Quando o usuário solicita acesso a uma aplicação, o broker verifica sua identidade via autenticação multifator, avalia a postura do dispositivo (patches atualizados, firewall ativo, ausência de malware) e aplica as políticas de acesso definidas pela organização.
Somente após essa validação completa o acesso é concedido, por meio de um túnel criptografado ponto a ponto entre o usuário e a aplicação específica. Os recursos protegidos ficam invisíveis para qualquer entidade que não tenha sido explicitamente autorizada, eliminando a superfície de ataque que a VPN tradicionalmente expõe.
Outro diferencial importante do ZTNA é a verificação contínua. Enquanto a VPN autentica o usuário uma única vez, no momento da conexão, e depois concede acesso irrestrito pelo tempo da sessão, o ZTNA monitora comportamento, contexto e postura do dispositivo durante toda a sessão. Se algo muda, como uma anomalia comportamental, uma alteração de geolocalização ou uma queda na conformidade do dispositivo, o acesso pode ser restringido ou revogado automaticamente. Essa abordagem reduz drasticamente o risco de movimento lateral: mesmo que um atacante comprometa uma credencial, ele não consegue se mover para outros recursos porque cada aplicação exige verificação independente.
Por que a VPN se tornou um risco
A VPN foi desenhada para um mundo na qual todos trabalhavam no escritório e os servidores ficavam dentro de um data center controlado. Nesse cenário, criar um túnel seguro entre o colaborador remoto e a rede corporativa fazia sentido. O problema é que esse modelo não evoluiu junto com a infraestrutura de TI. Hoje, aplicações rodam em múltiplas nuvens, colaboradores trabalham de qualquer lugar, fornecedores acessam sistemas internos por integrações automatizadas e dispositivos pessoais se conectam à rede corporativa diariamente. A VPN continua oferecendo um túnel para dentro da rede inteira, quando o que o usuário precisa é acessar uma aplicação específica.
O relatório ThreatLabz quantificou essa deterioração. Mais da metade das organizações pesquisadas sofreu ataques explorados diretamente por vulnerabilidades de VPN no ano anterior. As CVEs relacionadas a VPN não apenas cresceram em volume, com alta de 82,5% no período analisado, mas se tornaram mais graves: a maioria das vulnerabilidades registradas permite execução remota de código, o que significa que um atacante pode assumir o controle completo do sistema afetado. Criminosos já utilizam inteligência artificial para automatizar a descoberta dessas falhas, consultando modelos generativos para listar CVEs ativas em produtos de VPN específicos e escaneando a internet em busca de infraestruturas vulneráveis. Tarefas que antes demandavam semanas agora levam minutos.
Além da vulnerabilidade técnica, a VPN cria um problema estrutural de segurança: o acesso excessivo. Quando um usuário se conecta, ele ganha visibilidade e acesso a toda a rede, não apenas ao recurso de que precisa. Isso transforma um único endpoint comprometido em uma porta de entrada para movimento lateral irrestrito. O mesmo relatório aponta que 71% dos profissionais de segurança classificam o movimento lateral como uma das maiores preocupações atuais, e 93% se preocupam com vulnerabilidades de backdoor originadas por conexões de terceiros via VPN. A confiança implícita que a VPN deposita no usuário após a autenticação inicial é exatamente o oposto do que o cenário de ameaças exige.
ZTNA versus VPN: as diferenças que importam para o negócio
A diferença mais evidente entre ZTNA e VPN está no modelo de acesso. A VPN opera na camada de rede, utilizando protocolos como IPSec ou SSL/TLS para encapsular todo o tráfego e conceder acesso amplo ao ambiente interno. O ZTNA opera na camada de aplicação, estabelecendo conexões ponto a ponto entre o usuário e cada recurso específico, sem expor a rede subjacente. Na prática, isso significa que com VPN um colaborador do departamento financeiro, ao se conectar remotamente, pode tecnicamente enxergar servidores do time de desenvolvimento. Com ZTNA, ele acessa exclusivamente os sistemas autorizados para sua função, e nada mais.
A performance é outro ponto de divergência relevante. VPNs tradicionais roteiam todo o tráfego por um concentrador central, geralmente um appliance físico ou virtual no data center da organização. Em cenários de trabalho distribuído, isso cria gargalos de capacidade, aumenta a latência e degrada a experiência do usuário. O ZTNA, por ser tipicamente entregue em nuvem, permite que o tráfego siga caminhos mais diretos e otimizados entre o usuário e a aplicação, sem o desvio obrigatório pelo data center. Para organizações com operações distribuídas ou equipes híbridas, essa diferença se traduz em produtividade mensurável.
Do ponto de vista de observabilidade e auditoria, o ZTNA também oferece vantagens significativas. Como cada conexão é intermediada por um controlador de políticas, a organização possui logs detalhados de cada requisição, incluindo identidade, localização, horário, recurso acessado e duração da sessão. Essa granularidade é indispensável para a resposta a incidentes e para o cumprimento de exigências regulatórias como a LGPD e a Resolução CD/ANPD nº 15/2024, que exigem registros rastreáveis de acesso a dados pessoais. A VPN, por operar na camada de rede, oferece visibilidade limitada sobre quais aplicações foram efetivamente acessadas dentro do túnel, dificultando investigações e auditorias.
Como o ZTNA se integra à estratégia de segurança corporativa
O ZTNA não opera isoladamente. Sua eficácia aumenta significativamente quando integrado ao ecossistema de segurança da organização. A convergência mais relevante é com o SASE (Secure Access Service Edge), que unifica ZTNA, SD-WAN, SWG (Secure Web Gateway), CASB (Cloud Access Security Broker), FWaaS (Firewall as a Service) e DLP em uma plataforma cloud-native. Essa convergência permite que a organização aplique políticas consistentes de acesso e proteção independentemente de onde o usuário esteja ou de qual recurso acesse, eliminando a fragmentação de ferramentas que é um dos maiores problemas em operações de segurança atuais.
A integração com o SOC e o SIEM é igualmente importante. Quando o ZTNA alimenta o SIEM com logs detalhados de acesso, a equipe do SOC ganha visibilidade sobre padrões de comportamento que seriam invisíveis em uma arquitetura baseada em VPN. Um acesso legítimo fora do horário comercial, seguido de download atípico de arquivos e tentativa de acesso a uma aplicação fora do escopo da função, pode ser correlacionado automaticamente e gerar um alerta de alta prioridade. Sem essa integração, cada um desses eventos seria tratado isoladamente e provavelmente ignorado. A micro-segmentação proporcionada pelo ZTNA complementa a proteção de borda ao garantir que, mesmo dentro do ambiente corporativo, o acesso seja granular e controlado.
Para organizações brasileiras, o ZTNA também responde a desafios regulatórios específicos. A LGPD exige controle de acesso a dados pessoais com base no princípio de necessidade, registro de operações de tratamento e medidas técnicas para prevenir acessos não autorizados. O ZTNA entrega nativamente cada uma dessas exigências: acesso por privilégio mínimo, logs completos de cada sessão e verificação contínua que impede acessos indevidos mesmo quando credenciais são comprometidas. A Resolução CD/ANPD nº 15/2024 reforça a necessidade de registros detalhados de incidentes, e a granularidade dos logs do ZTNA facilita tanto a investigação quanto a comunicação obrigatória em caso de violação.
O caminho prático para a migração de VPN para ZTNA
A substituição da VPN por ZTNA não precisa ser um projeto de ruptura. A abordagem mais pragmática é a migração progressiva, começando pelas aplicações mais críticas ou pelos grupos de usuários com maior risco, como terceiros, fornecedores e equipes com acesso a dados sensíveis. O primeiro passo é mapear todas as aplicações acessadas via VPN, classificá-las por criticidade e identificar quais podem ser migradas imediatamente para ZTNA e quais exigem ajustes de arquitetura. Paralelamente, é necessário avaliar a postura de identidade da organização: o ZTNA depende de um provedor de identidade robusto, com MFA implementado e políticas de acesso condicional bem definidas.
O segundo movimento é a implementação gradual, operando VPN e ZTNA em paralelo durante o período de transição. Usuários são migrados em ondas, com monitoramento intensivo para identificar problemas de acesso, ajustar políticas e refinar a experiência. A maioria das plataformas de ZTNA modernas oferece integração com os principais provedores de identidade e sistemas de endpoint protection, o que facilita a coexistência com a infraestrutura existente. À medida que a confiança no modelo cresce e as aplicações são migradas, a VPN pode ser desativada progressivamente, reduzindo a superfície de ataque sem interromper a operação.
O maior desafio da migração raramente é técnico. É cultural. Equipes habituadas a conectar a VPN e acessar “tudo” podem estranhar o modelo de acesso granular. Gestores podem questionar a necessidade de definir permissões por aplicação. E times de TI acostumados a gerenciar appliances físicos precisam adaptar-se à lógica de políticas em nuvem. Investir em comunicação interna e treinamento desde o início do projeto é tão importante quanto a configuração técnica. Organizações que tratam a migração para ZTNA como um projeto puramente de infraestrutura tendem a enfrentar resistência. As que a tratam como evolução da postura de segurança, com apoio da liderança e envolvimento das áreas de negócio, aceleram a adoção e colhem resultados mais rápido.
O acesso seguro como vantagem estratégica
O ZTNA não é apenas uma evolução técnica da VPN. É uma mudança de paradigma na forma como as organizações pensam acesso. Em vez de confiar no usuário e abrir a rede, o modelo parte da desconfiança e concede apenas o mínimo necessário, verificando continuamente. Com 81% das organizações globais planejando implementar estratégias de confiança zero nos próximos meses, segundo o relatório ThreatLabz de 2025, e com o cenário de ameaças no Brasil exigindo respostas cada vez mais rápidas e granulares, a pergunta para o decisor não é mais se deve migrar da VPN para ZTNA – é quando isso vai acontecer.
