Se você gerencia infraestrutura de TI, provavelmente tem uma VPN corporativa rodando há anos. Ela foi montada num contexto em que quase todo mundo trabalhava dentro do escritório, o perímetro da rede era claro e o acesso remoto era exceção, não regra.

Então veio 2020, e de repente a VPN virou o principal ponto de entrada da empresa inteira. Centenas de conexões simultâneas em concentradores que foram dimensionados para 30 pessoas. Licenças estouradas. Latência absurda. E o pior: depois que o usuário autenticava, ele enxergava a rede toda.

Esse é o ponto que pouca gente discute com franqueza. A VPN tradicional opera no modelo de confiança implícita. Autenticou? Pronto, está dentro. Pode acessar o ERP, o file server, a impressora da diretoria e aquele servidor legado que ninguém sabe direito o que faz. Isso não é acesso remoto seguro. É uma porta aberta com crachá.

A comparação entre ZTNA vs VPN começa exatamente aqui: não é só uma questão de tecnologia mais nova contra tecnologia mais antiga. É uma mudança na lógica de como você concede acesso.

Por que a VPN tradicional virou alvo frequente

Os concentradores VPN (aqueles appliances ou servidores que terminam os túneis) se tornaram alvos prioritários para atacantes. E faz sentido: se você compromete o ponto de entrada que dá acesso amplo à rede, o trabalho de movimentação lateral fica muito mais fácil.

Nos últimos dois anos, fabricantes como Cisco, Fortinet, Palo Alto e Ivanti publicaram patches para vulnerabilidades graves em seus produtos de VPN. Algumas dessas falhas foram exploradas ativamente antes mesmo de o patch estar disponível. Não estou inventando número aqui, mas basta acompanhar os alertas da CISA (Cybersecurity and Infrastructure Security Agency) para ver que VPN aparece com frequência preocupante.

O problema não é a VPN em si ser uma tecnologia ruim. É o modelo operacional dela:

• Acesso à rede inteira (ou a segmentos grandes demais) após a autenticação
• Pouca ou nenhuma verificação contínua depois que a sessão é estabelecida
• Concentrador exposto na internet com IP público fixo, fácil de escanear
• Dificuldade de aplicar políticas granulares por aplicação

Na prática, o que vejo acontecer em muitas empresas brasileiras é o seguinte: a VPN corporativa foi configurada uma vez, funciona, e ninguém mexe. As regras de acesso são amplas porque era mais fácil assim. E quando alguém pergunta ‘quem tem acesso a quê pela VPN?’, a resposta costuma ser um silêncio constrangedor.

O que é Zero Trust (e o que não é)

Zero Trust não é um produto. Não é um appliance que você compra e instala. É um modelo arquitetural que parte de um princípio simples: nenhum acesso é confiável por padrão, independentemente de onde o usuário está ou de qual rede ele usa.

O NIST formalizou isso na publicação SP 800-207, de 2020, que define a arquitetura Zero Trust. O documento é denso (são 50 páginas), mas a essência cabe em poucas ideias:

• Todo acesso a recurso deve ser concedido por sessão, com base em política
• A autenticação e a autorização são dinâmicas e reavaliadas continuamente
• A rede local não é fator de confiança. Estar ‘dentro’ da rede não significa nada
• O acesso é concedido ao recurso específico, não à rede como um todo

Isso é bonito no papel. Na prática, implementar Zero Trust é um processo. Você não acorda numa segunda-feira e liga o ‘modo Zero Trust’. É uma migração gradual que envolve identidade, postura de dispositivo, segmentação e, sim, tecnologia.

E é aqui que entra o ZTNA.

ZTNA: acesso por aplicação, não por rede

Zero Trust Network Access é a implementação prática do conceito Zero Trust para acesso remoto. Em vez de criar um túnel para a rede corporativa, o ZTNA conecta o usuário diretamente à aplicação que ele precisa usar. Só aquela. Nada mais.

A diferença parece sutil, mas muda tudo.

Com VPN, o usuário autentica e recebe um endereço IP na rede interna. A partir daí, qualquer coisa que a rede permita, ele pode tentar acessar. Com ZTNA, o usuário autentica, o sistema verifica a identidade, checa a postura do dispositivo (antivírus atualizado? sistema operacional com patch? disco criptografado?) e só então libera acesso àquela aplicação específica.

Se o dispositivo não atende aos requisitos, o acesso é negado. Ou então se usuário tenta acessar algo fora da política, o acesso é negado.

Na prática, como funciona com FortiClient e FortiGate

Quem já usa firewall Fortinet tem meio caminho andado. O FortiGate (a partir do FortiOS 7.0) suporta ZTNA nativamente, sem precisar de um appliance separado.

O fluxo funciona assim: o FortiClient, instalado no endpoint do usuário, coleta informações de postura (versão do SO, status do antivírus, certificados, geolocalização) e as envia ao FortiGate. O FortiGate, por sua vez, aplica as regras de acesso baseadas em tags de postura e identidade. O usuário só enxerga as aplicações que a política permite.

O detalhe que me agrada nessa abordagem é que a aplicação não fica exposta na internet. O FortiGate funciona como um proxy de acesso. De fora, o atacante não consegue nem descobrir que a aplicação existe. Compare isso com um concentrador VPN que precisa ter a porta 443 ou 10443 aberta para o mundo inteiro.

Para empresas que precisam proteger aplicações web internas (ERPs, portais, sistemas de RH), o ZTNA do FortiGate cria um túnel HTTPS entre o FortiClient e o proxy de acesso, com verificação contínua. Não tem aquele momento de ‘autenticou e esqueceu’.

E o FortiSASE?

Quando a empresa tem muitos usuários remotos, filiais sem FortiGate local ou quer simplificar a arquitetura, o FortiSASE entra como opção. É o ZTNA entregue como serviço, na nuvem da Fortinet.

O usuário se conecta ao ponto de presença (PoP) mais próximo do FortiSASE, que aplica as mesmas políticas de acesso, inspeção de tráfego e verificação de postura. A vantagem é não depender de um appliance físico no data center da empresa para cada conexão.

Para empresas brasileiras com operação distribuída (escritórios em São Paulo, fábrica no interior, equipe comercial viajando), o FortiSASE resolve aquele problema clássico de rotear todo o tráfego remoto por um único ponto central. Isso reduz latência e tira pressão do link do data center.

Se sua empresa já avalia consolidar segurança e conectividade remota, vale entender como as dicas de cibersegurança se conectam com a arquitetura ZTNA na prática.

ZTNA vs VPN: comparação direta

Vou colocar lado a lado porque ajuda a visualizar, mas entenda que não é uma tabela de ‘bom contra ruim’. São modelos diferentes, com trade-offs reais.

Critério	VPN tradicional	ZTNA
Modelo de acesso	Rede inteira (ou segmento amplo)	Aplicação específica
Verificação de identidade	Na conexão inicial	Contínua, por sessão
Postura do dispositivo	Geralmente não verificada	Verificada antes e durante o acesso
Superfície de ataque	Concentrador exposto com IP público	Aplicação invisível externamente
Escalabilidade	Limitada pelo hardware do concentrador	Escalável (especialmente via SASE)
Experiência do usuário	Cliente VPN pesado, reconexões frequentes	Conexão direta à aplicação, mais leve
Granularidade de política	Baseada em IP e sub-rede	Baseada em identidade, postura e contexto

Uma coisa que a tabela não mostra: a VPN é muito mais simples de implementar. Você sobe um servidor, distribui o cliente, cria os usuários e pronto. O ZTNA exige que você tenha clareza sobre quais aplicações existem, quem precisa acessar o quê e quais são os requisitos de postura. Isso dá trabalho. Mas é exatamente esse trabalho que melhora a segurança.

Quando ainda faz sentido manter a VPN

Seria fácil (e desonesto) dizer que a VPN morreu e todo mundo deveria migrar amanhã. A realidade é mais complicada.

A VPN ainda faz sentido em alguns cenários:

Aplicações legadas que dependem de protocolos não-HTTP (SMB, RDP direto, aplicações cliente-servidor antigas) nem sempre funcionam bem com ZTNA, que foi desenhado principalmente para aplicações web e TCP/UDP específicos. Se você tem um ERP dos anos 2000 que só roda com conexão de rede local, a VPN pode ser o caminho mais pragmático enquanto essa aplicação existir.

Ambientes com poucos usuários remotos e baixa complexidade de acesso. Se são 15 pessoas que acessam tudo igual, o investimento em ZTNA pode não se justificar agora. A conta muda quando o número cresce ou quando os perfis de acesso se diferenciam.

Também há o fator equipe. Se o time de TI tem três pessoas e já está no limite, adicionar a complexidade de um projeto ZTNA sem apoio externo é receita para implementação mal feita (que é pior que não implementar).

Como fazer a migração gradual de VPN para ZTNA

Na minha experiência, as migrações que funcionam são as que não tentam trocar tudo de uma vez. O caminho mais sensato é este:

1. Mapeie as aplicações e os perfis de acesso

Antes de mexer em qualquer tecnologia, documente: quais aplicações são acessadas remotamente, por quem, com qual frequência. Parece óbvio, mas tenho visto empresas que não conseguem listar nem metade das aplicações que passam pela VPN.

2. Comece pelas aplicações web

Portais internos, ERPs com interface web, sistemas de chamados. Essas são as mais fáceis de migrar para ZTNA porque já usam HTTPS. Configure o ZTNA no FortiGate para essas aplicações primeiro, mantendo a VPN ativa para o restante.

3. Integre com MFA e Entra ID

Aqui está um ponto que faz diferença enorme. O ZTNA com verificação de identidade simples (usuário e senha) não é Zero Trust de verdade. Você precisa de MFA (autenticação multifator) e, idealmente, de integração com um provedor de identidade como o Microsoft Entra ID (o antigo Azure AD).

O FortiGate suporta SAML e pode usar o Entra ID como fonte de identidade. Isso significa que as políticas de acesso consideram o grupo do usuário no Entra ID, o status do MFA e até políticas de acesso condicional do lado da Microsoft. Para quem já usa Microsoft 365 para empresas, essa integração aproveita o investimento que já existe.

4. Aplique verificação de postura

Configure o FortiClient para verificar: sistema operacional atualizado, antivírus ativo, disco criptografado, certificado da empresa instalado. Dispositivo que não atende? Acesso negado ou restrito a aplicações de baixo risco.

Esse passo costuma gerar atrito com os usuários, especialmente aqueles que usam notebook pessoal. É um bom momento para ter uma conversa honesta sobre BYOD e definir se a empresa vai fornecer equipamento ou aceitar o risco.

5. Reduza o escopo da VPN aos poucos

Conforme as aplicações migram para ZTNA, você reduz o que a VPN permite acessar. Primeiro tira os sistemas web. Depois os acessos RDP (que podem passar por um gateway intermediário). No final, a VPN fica restrita a casos muito específicos ou é desligada.

Esse processo leva meses, não semanas. E tudo bem. A Omega Brasil tem conduzido projetos assim com firewall FortiGate em empresas de médio porte, e a abordagem faseada é a que gera menos interrupção.

O ZTNA resolve tudo?

Não. E desconfie de quem disser que sim.

O ZTNA melhora muito o controle de acesso remoto, mas ele é uma peça da arquitetura, não a arquitetura inteira. Você ainda precisa de segmentação de rede interna, proteção de endpoint, monitoramento de tráfego e, acima de tudo, processos de gestão de identidade bem feitos.

Se sua empresa não sabe quem tem acesso administrativo ao Active Directory, o ZTNA não vai resolver esse problema. Ele vai resolver o problema de dar acesso excessivo pela VPN, mas a bagunça de permissões internas continua lá.

Outro ponto: o ZTNA depende do agente no endpoint (no caso da Fortinet, o FortiClient). Se o usuário estiver num dispositivo que não tem o agente instalado (um computador de hotel, por exemplo), o acesso precisa de uma alternativa, como um portal web com autenticação reforçada. Isso funciona, mas com limitações.

ZTNA com FortiSASE ou com FortiGate on-premises?

Essa é a pergunta que aparece em quase toda conversa sobre o tema. A resposta depende de onde estão seus usuários e suas aplicações.

Se a maioria das aplicações ainda está no data center local e os usuários estão concentrados em poucas localidades, o FortiGate on-premises com ZTNA resolve bem. Você já tem o hardware, já conhece o FortiOS, e o custo adicional é basicamente o licenciamento do FortiClient.

Se a empresa tem aplicações em nuvem (Azure, AWS, SaaS), equipe distribuída pelo Brasil e precisa de inspeção de tráfego para internet também, o FortiSASE começa a fazer mais sentido. Ele combina ZTNA, SWG (Secure Web Gateway), CASB e FWaaS num serviço só.

Tem também o cenário híbrido, que honestamente é o mais comum: FortiGate no data center para aplicações on-premises e FortiSASE para usuários remotos que acessam aplicações em nuvem. As duas coisas se integram pelo FortiClient e pelo painel de gerenciamento do FortiManager.

Como o MFA e o Entra ID se encaixam nisso

A verificação de identidade é o alicerce do ZTNA. Sem ela, você está só trocando uma porta por outra.

O cenário que mais funciona nas empresas brasileiras que acompanho é: Entra ID como provedor de identidade (IdP), com MFA ativado para todos os usuários, integrado ao FortiGate via SAML. Quando o usuário tenta acessar uma aplicação protegida por ZTNA, o FortiGate redireciona para o Entra ID, que pede o segundo fator (push no Authenticator, código SMS, chave FIDO2).

Isso elimina aquele problema clássico da VPN em que a senha do usuário era o único fator. Senha vazou num phishing? Com MFA, o atacante ainda precisa do segundo fator. Com verificação de postura, precisa também de um dispositivo que atenda aos requisitos.

Camadas. É sobre camadas. Nenhuma sozinha resolve, mas juntas dificultam muito a vida de quem tenta entrar sem autorização.

O que considerar antes de começar

Antes de ligar para o fornecedor pedindo proposta de ZTNA, faça a lição de casa:

Inventário de aplicações remotas. Quais sistemas são acessados de fora? Por quais protocolos? Quem acessa? Se você não tem essa lista, comece por ela. Sem isso, qualquer projeto de ZTNA vai ser baseado em achismo.

Maturidade de identidade. Vocês têm um diretório centralizado (Active Directory, Entra ID)? MFA está ativado? Grupos de acesso estão organizados ou é tudo ‘Domain Users’? Se a resposta for ‘mais ou menos’, resolva isso antes do ZTNA.

Estado dos endpoints. Os notebooks da empresa estão gerenciados? Têm antivírus atualizado? Disco criptografado? Se metade da equipe usa notebook pessoal sem nenhum controle, a verificação de postura vai barrar muita gente (e gerar muita ligação para o helpdesk). Quem precisa organizar a frota pode olhar para locação de notebooks com gestão inclusa, que resolve a padronização de uma vez.

Capacidade da equipe. Sua equipe de TI tem fôlego para um projeto assim? Se não, traga ajuda externa. Uma implementação mal feita de ZTNA pode ser pior que uma VPN bem configurada.

O acesso remoto seguro não é mais opcional

A discussão sobre ZTNA vs VPN não é modismo. É uma resposta a um problema real: o modelo de acesso amplo à rede, baseado em confiança implícita, não se sustenta quando metade da empresa trabalha de fora do escritório e os ataques a concentradores VPN se multiplicam.

O ZTNA, especialmente quando integrado com MFA, verificação de postura e um provedor de identidade como o Entra ID, oferece um modelo de acesso remoto seguro que reduz a superfície de ataque de forma concreta. Não é teoria. É o que o NIST SP 800-207 descreve e o que ferramentas como FortiGate e FortiSASE implementam na prática.

Mas a migração precisa ser feita com método. Começar pelas aplicações web, integrar identidade, aplicar postura, reduzir a VPN aos poucos. Sem pressa e sem pular etapas.

A Omega Brasil ajuda sua empresa a substituir ou complementar a VPN com ZTNA Fortinet. Se você quer entender como isso se aplica ao seu ambiente, fale com um especialista em TI do nosso time de segurança.