ZTNA: o que é e como implementar com Fortinet

ZTNA (Zero Trust Network Access) é um modelo de acesso remoto que elimina a confiança implícita da rede corporativa, verificando identidade, dispositivo e contexto antes de liberar cada conexão a uma aplicação específica. Diferente da VPN tradicional, que abre acesso amplo à rede interna, o ZTNA concede permissões granulares e contínuas, reduzindo a superfície de ataque. A Fortinet entrega essa tecnologia de forma nativa em seu Security Fabric, unificando ZTNA, firewall e proteção de endpoint sem exigir appliances adicionais.

O que é Zero Trust Network Access e por que o modelo importa agora

Zero Trust Network Access (ZTNA) é um modelo de segurança que elimina a confiança implícita na rede corporativa e passa a exigir verificação contínua de identidade, dispositivo e contexto antes de conceder acesso a qualquer aplicação. Diferente do VPN tradicional, que trata a rede interna como território confiável, o ZTNA aplica o princípio "nunca confie, sempre verifique": cada requisição de acesso é autenticada, autorizada e criptografada individualmente, com base em políticas que consideram usuário, dispositivo, localização e sensibilidade do recurso solicitado.

Esse modelo ganhou tração porque o perímetro de rede tradicional deixou de fazer sentido. Com trabalho híbrido, uso de dispositivos pessoais (BYOD), aplicações em múltiplas nuvens e parceiros externos acessando sistemas corporativos, a superfície de ataque se expandiu para além do que firewalls perimetrais conseguem proteger. Um usuário autenticado uma única vez na VPN, por exemplo, historicamente ganhava acesso amplo à rede interna - um risco que o ZTNA reduz ao limitar cada sessão a um recurso específico, pelo tempo necessário.

É importante diferenciar ZTNA de Zero Trust Architecture (ZTA). ZTA é o conceito arquitetural mais amplo, descrito formalmente pelo NIST na publicação SP 800-207, que define os princípios, componentes lógicos e fluxos de decisão de um ambiente Zero Trust como um todo - incluindo identidade, segmentação, monitoramento e resposta. ZTNA é uma das tecnologias que implementam esses princípios na prática, focada especificamente em controlar o acesso remoto e granular a aplicações. Em outras palavras:

• ZTA é a estratégia e o modelo de referência de segurança.
• ZTNA é um componente tecnológico que operacionaliza parte dessa estratégia, substituindo o acesso baseado em rede pelo acesso baseado em identidade e contexto.

Entender essa diferença evita a confusão comum de tratar ZTNA como sinônimo de Zero Trust completo, quando na prática ele é uma peça - ainda que central - de uma arquitetura mais ampla.

Como o ZTNA funciona na prática: identidade, dispositivo e contexto

O ZTNA opera sob a premissa de que nenhuma conexão é confiável por padrão, nem mesmo as originadas de dentro da rede corporativa. Em vez de liberar acesso à rede inteira após um login, o modelo avalia três variáveis em conjunto - identidade do usuário, estado do dispositivo e contexto da sessão - antes de autorizar cada tentativa de acesso a uma aplicação específica.

A autenticação não termina no login inicial. O ZTNA trabalha com verificação contínua, reavaliando a sessão em intervalos ou diante de mudanças de comportamento, como troca de localização, rede ou padrão de uso. Se algo destoa do esperado, o acesso pode ser suspenso ou exigir nova validação, sem depender de o usuário permanecer conectado à VPN.

A verificação de postura do dispositivo é outro pilar central. Antes de conceder a conexão, o sistema confere itens como versão do sistema operacional, presença de antivírus ativo, criptografia de disco e conformidade com políticas de segurança definidas pela empresa. Dispositivos fora do padrão são bloqueados ou direcionados a um acesso restrito, mesmo que o usuário tenha credenciais válidas.

Diferente de uma VPN tradicional, o ZTNA aplica microssegmentação por aplicação, não por rede. Isso significa que o usuário não enxerga nem tem rota para o restante do ambiente corporativo: ele recebe caminho apenas até o sistema autorizado. Essa segmentação reduz drasticamente a superfície de movimentação lateral em caso de credencial comprometida.

• Túneis criptografados são criados sob demanda, específicos para cada aplicação, e encerrados quando a sessão termina.
• O broker de acesso (controlador) atua como intermediário: recebe a solicitação, cruza identidade, postura e contexto, e só então autoriza ou nega a conexão.
• Nenhuma conexão direta é estabelecida entre o dispositivo do usuário e a rede interna - tudo passa pela camada de decisão do broker.

É esse controlador que sustenta toda a lógica do Zero Trust: ele centraliza as políticas, consulta fontes de identidade e sinais de postura em tempo real, e decide, requisição por requisição, se aquele acesso específico deve ser liberado.

ZTNA vs. VPN tradicional: diferenças que impactam a segurança

A VPN tradicional foi projetada para um mundo com perímetro definido: usuário fora, rede corporativa dentro, túnel criptografado ligando os dois pontos. O ZTNA parte de outra premissa - nenhum usuário ou dispositivo é confiável por padrão, mesmo depois de autenticado. Essa diferença de arquitetura explica por que os dois modelos se comportam de forma tão distinta em produção.

Na superfície de exposição, a VPN concentrada em um concentrador ou appliance de borda cria um alvo único e visível na internet, propenso a scans e exploração de vulnerabilidades. O ZTNA não expõe portas nem IPs de aplicações ao público: o acesso é mediado por um broker que só estabelece conexão após validar identidade, contexto e postura do dispositivo.

A granularidade também muda o jogo. Uma VPN normalmente coloca o usuário dentro do segmento de rede, com acesso amplo lateral - basta uma credencial comprometida para o invasor circular entre sistemas. O ZTNA aplica controle por aplicação: cada sessão é autorizada individualmente, reduzindo o raio de impacto de um incidente.

• Desempenho: a VPN concentra tráfego em um ponto central, gerando gargalo quando o volume de conexões remotas cresce; o ZTNA distribui o acesso mais próximo da aplicação.
• Escalabilidade para trabalho híbrido: adicionar novos usuários, filiais ou aplicações em nuvem exige reconfiguração constante de túneis e rotas na VPN.
• Experiência do usuário: a VPN depende de cliente pesado, login manual e reconexões frequentes; o ZTNA opera de forma mais transparente, com verificação contínua em segundo plano.

Em ambientes híbridos e multicloud, onde aplicações não vivem mais dentro de um único perímetro, esse modelo de confiança implícita da VPN se torna o elo mais frágil da estratégia de segurança.

Principais benefícios do ZTNA para empresas B2B

Adotar ZTNA traz ganhos concretos de segurança e operação para empresas B2B, especialmente as que lidam com múltiplas filiais, fornecedores e equipes remotas. Ao eliminar a confiança implícita de rede e validar cada solicitação de acesso individualmente, a arquitetura reduz riscos que o modelo de perímetro tradicional (VPN) não consegue endereçar.

• Redução da superfície de ataque: aplicações ficam invisíveis para quem não tem permissão explícita, ao contrário de uma VPN que expõe toda a rede interna. Um ERP ou sistema financeiro, por exemplo, só é alcançável pelos usuários e dispositivos autorizados para aquele recurso específico.
• Contenção de movimentação lateral: como o acesso é segmentado por aplicação e não por rede, um endpoint comprometido não vira porta de entrada para o restante do ambiente. Isso limita o raio de impacto de incidentes como ransomware, um cenário recorrente em ataques a empresas de médio e grande porte.
• Visibilidade granular de acessos: cada conexão é registrada com identidade do usuário, dispositivo, aplicação acessada e contexto (localização, postura de segurança), o que facilita auditorias e investigação de incidentes.
• Conformidade regulatória facilitada: o controle detalhado de quem acessa o quê, e quando, ajuda a atender exigências de normas como LGPD, PCI-DSS e ISO 27001, que cobram trilhas de auditoria e princípio de menor privilégio.
• Melhor experiência do usuário remoto: sem a necessidade de conectar a uma VPN completa, o colaborador acessa diretamente a aplicação necessária, com menos latência e menos fricção no dia a dia.
• Suporte a políticas de BYOD: dispositivos pessoais podem ser autorizados para acessos específicos mediante verificação de postura de segurança, sem exigir que o equipamento entre totalmente na rede corporativa.

Esses benefícios se combinam para dar às equipes de TI mais controle sem sacrificar a produtividade das equipes de negócio, algo especialmente relevante em ambientes híbridos e multicloud.

Como a Fortinet entrega ZTNA dentro do Security Fabric

A Fortinet não trata ZTNA como um produto isolado, mas como uma capacidade nativa do Security Fabric, a plataforma que já integra firewall, VPN, autenticação e visibilidade de endpoints. Isso significa que a arquitetura Zero Trust é composta por peças que a maioria das empresas já opera no dia a dia - FortiClient, FortiGate e FortiAuthenticator/FortiToken -, cada uma com um papel bem definido no fluxo de verificação contínua.

O FortiClient atua como agente de postura instalado no dispositivo do usuário. Ele coleta informações como versão do sistema operacional, presença de antivírus ativo, patches de segurança aplicados e conformidade com políticas corporativas, gerando um "ZTNA tag" que descreve a saúde daquele endpoint em tempo real. Esse tag é reavaliado a cada tentativa de acesso, não apenas no login inicial.

O FortiGate funciona como ponto de aplicação de políticas (policy enforcement point). É ele quem recebe a solicitação de acesso a uma aplicação, cruza a identidade do usuário com a postura reportada pelo FortiClient e decide, sessão a sessão, se libera, restringe ou bloqueia o tráfego. Diferente de uma VPN tradicional, o FortiGate não abre acesso à rede inteira: cria um túnel criptografado direto até a aplicação especificada.

A camada de identidade fica a cargo do FortiAuthenticator e do FortiToken, responsáveis por autenticação multifator, gestão de certificados e integração com diretórios corporativos (LDAP, Active Directory, SAML). Essa combinação garante que a decisão de acesso considere quem é o usuário e não apenas onde ele está.

A principal vantagem competitiva dessa abordagem é a ausência de infraestrutura paralela. Empresas que já usam FortiGate como firewall de borda podem habilitar ZTNA via licenciamento e configuração, sem novos appliances, sem gateways adicionais e sem duplicar a stack de segurança. Isso reduz custo de implementação, tempo de deploy e superfície de gestão.

• FortiClient: agente de postura e telemetria do endpoint
• FortiGate: aplicação de políticas e microssegmentação de acesso
• FortiAuthenticator/FortiToken: identidade, MFA e diretórios corporativos
• Security Fabric: integração nativa, sem infraestrutura paralela

Como implementar ZTNA com Fortinet: etapas e requisitos práticos

A implementação de ZTNA com Fortinet segue um caminho estruturado que começa antes de qualquer configuração técnica: o mapeamento do ambiente. Sem entender quais aplicações são críticas, quem as acessa e a partir de onde, qualquer política de acesso fica genérica demais para ser segura.

O primeiro passo é o levantamento de aplicações críticas: identificar sistemas internos, SaaS e workloads em nuvem que exigem controle de acesso granular, classificando-os por sensibilidade e por perfil de usuário que precisa alcançá-los. Esse inventário orienta a etapa seguinte, a definição de políticas de acesso por identidade e grupo, em que o acesso deixa de ser baseado em rede (quem está na VPN entra) e passa a ser baseado em quem é o usuário, qual dispositivo utiliza e em que contexto a requisição acontece.

Do ponto de vista técnico, a arquitetura ZTNA da Fortinet depende de peças específicas trabalhando em conjunto:

• FortiGate como ponto de aplicação de política (proxy ZTNA) e gateway de acesso;
• FortiClient como agente endpoint, responsável por avaliar a postura do dispositivo antes de liberar a conexão;
• FortiAuthenticator ou integração com provedor de identidade para autenticação e definição de grupos;
• Licenciamento ZTNA habilitado no FortiGate e nos endpoints, além de firmware compatível com os recursos de tag-based access.

Com a base pronta, a recomendação é rodar um piloto restrito a um grupo de usuários e a um conjunto pequeno de aplicações, validando políticas, latência e experiência do usuário antes do rollout mais amplo. A partir daí, a expansão deve ser feita por ondas, priorizando aplicações de maior risco.

Por fim, a migração desde uma VPN legada exige governança: manter os dois modelos coexistindo durante a transição, documentar exceções, revisar periodicamente os grupos de acesso e só descontinuar a VPN depois que todas as aplicações relevantes estiverem cobertas pelas políticas ZTNA.