Zero Trust Network Access (ZTNA): acesso seguro baseado em identidade e contexto

Zero Trust Network Access (ZTNA) é uma arquitetura de acesso em que a autorização é concedida de forma explícita e contextual para aplicações e recursos específicos, em vez de confiar automaticamente em usuários ou dispositivos apenas por estarem conectados à rede corporativa. O princípio central é reduzir confiança implícita e verificar continuamente identidade, dispositivo, contexto e política antes de permitir uma sessão.

ZTNA não é sinônimo de VPN moderna, nem de uma única ferramenta. Ele funciona como uma camada de enforcement inserida em uma arquitetura Zero Trust mais ampla, apoiada por identidade, autenticação forte, postura do dispositivo, segmentação, telemetria e políticas de acesso. O objetivo é reduzir a superfície exposta e impedir que uma credencial válida conceda automaticamente visibilidade ampla da rede.

Em ambientes distribuídos, híbridos e cloud, essa abordagem é especialmente relevante porque usuários, terceiros, aplicações e dados já não estão concentrados dentro de um perímetro físico único. A decisão de acesso precisa considerar quem solicita, qual recurso é requerido, de qual dispositivo, sob qual condição e com qual nível de risco.

A arquitetura pode ser estruturada conforme os princípios do NIST SP 800-207, em que mecanismos de decisão e aplicação de políticas trabalham com múltiplas fontes de contexto. O desenho, porém, precisa ser proporcional ao ambiente e à capacidade operacional da organização.

Condição observada	Risco	Resposta ZTNA
VPN concede acesso amplo à rede	Credencial comprometida permite movimentação lateral	Acesso por aplicação, identidade e política contextual
Terceiros usam contas compartilhadas	Baixa rastreabilidade e privilégios excessivos	Identidade individual, MFA, validade e autorização mínima
Dispositivo comprometido mantém acesso	Persistência do risco durante a sessão	Postura, telemetria e reavaliação contínua
Aplicações ficam expostas diretamente à Internet	Aumento da superfície de ataque	Broker ou connector intermediando a sessão
Políticas são baseadas apenas em endereço IP	Baixa aderência a ambientes dinâmicos	Identidade, grupos, atributos, dispositivo e contexto

Arquitetura da solução

Uma arquitetura ZTNA normalmente possui uma camada de decisão de política e uma camada de enforcement. O policy engine avalia sinais como identidade, grupo, postura, localização, risco, aplicação e horário; o policy administrator transforma a decisão em sessão autorizada; e o policy enforcement point controla efetivamente a comunicação.

Na prática, diferentes fabricantes implementam esses componentes de formas distintas. Gateways, brokers cloud, connectors locais, agentes de endpoint e integrações com IdP podem compor a solução. O desenho deve evitar dependência desnecessária de um único ponto de falha e considerar conectividade entre usuários, brokers e aplicações.

O recurso protegido pode permanecer sem exposição direta. Em modelos com connector outbound, a aplicação não precisa aceitar conexões iniciadas diretamente da Internet; o acesso é mediado pela infraestrutura ZTNA após a decisão de política.

Identidade, autenticação e contexto

A identidade é a base da decisão. Diretórios corporativos, IdPs, IAM e provedores de MFA precisam fornecer atributos confiáveis e refletir corretamente admissão, mudança de função e desligamento. ZTNA aplicado sobre identidades desatualizadas apenas automatiza acessos incorretos.

A solução deve integrar-se a Identity and Access Management para utilizar grupos, papéis, ciclo de vida e autenticação. Dependendo do risco, métodos resistentes a phishing e políticas de Conditional Access podem ser incorporados.

Contexto pode incluir localização, horário, método de autenticação, risco do usuário, criticidade da aplicação e postura do dispositivo. Políticas devem usar apenas sinais confiáveis e compreensíveis; regras excessivamente complexas tornam troubleshooting e auditoria difíceis.

Postura do dispositivo e confiança do endpoint

Uma identidade legítima pode estar utilizando um endpoint comprometido. A arquitetura pode avaliar sistema operacional, versão, agente de segurança, criptografia, estado de proteção, certificados e outros sinais antes de autorizar o acesso.

A postura pode ser reavaliada durante a sessão. Se o endpoint deixa de atender a uma política, o acesso pode ser limitado ou revogado. Essa capacidade precisa ser aplicada de forma proporcional para não causar interrupções imprevisíveis em aplicações críticas.

Dispositivos não gerenciados podem receber políticas diferentes: acesso somente a aplicações específicas, browser isolation, restrição de download ou bloqueio total conforme o risco.

Acesso por aplicação e redução da superfície exposta

O modelo tradicional de VPN frequentemente entrega conectividade de rede; ZTNA busca entregar acesso à aplicação. O usuário pode utilizar um ERP, portal ou sistema remoto sem possuir rota ampla para os demais segmentos internos.

Essa mudança reduz oportunidades de descoberta e movimentação lateral. Servidores podem permanecer inacessíveis a origens não autorizadas e aplicações internas podem deixar de depender de exposição direta ou regras amplas de firewall.

Nem toda aplicação se adapta igualmente bem. Sistemas legados que dependem de múltiplas portas, protocolos não web, descoberta em broadcast ou comunicação peer-to-peer podem exigir arquitetura específica ou permanecer temporariamente atrás de VPN ou segmentação tradicional.

Integração com segmentação, NGFW e SASE

ZTNA não substitui Segmentação e Microsegmentação. A segmentação limita comunicação dentro da infraestrutura; ZTNA controla a forma como identidades alcançam aplicações. Os dois mecanismos reduzem o raio de impacto em camadas diferentes.

NGFW continua relevante para controle de tráfego, inspeção, zonas e integrações. Em arquiteturas SASE, ZTNA pode ser entregue junto com SWG, CASB, SD-WAN e serviços de segurança em nuvem.

A solução de Secure Access Service Edge é especialmente aderente quando usuários, filiais e aplicações estão distribuídos geograficamente e a organização deseja aproximar conectividade e segurança.

Terceiros, fornecedores e acessos temporários

Terceiros são um caso de uso importante. Manutenção, suporte e fornecedores podem precisar acessar apenas um subconjunto de aplicações por período limitado. ZTNA permite associar identidade, validade, MFA e política ao acesso sem expor a rede interna completa.

A governança deve exigir owner interno, justificativa, prazo e revisão. Contas temporárias sem expiração definida tendem a sobreviver ao contrato que justificou sua criação.

Quando o fornecedor usa equipamento próprio, requisitos de postura podem ser ajustados ou complementados por controles de isolamento. O objetivo é manter acesso funcional sem assumir que o endpoint externo possui o mesmo nível de gestão de um dispositivo corporativo.

Telemetria, logs e decisão contínua

A arquitetura deve produzir logs de autenticação, política aplicada, dispositivo, recurso acessado, duração da sessão e eventos de bloqueio. Esses dados podem alimentar SIEM, UEBA e processos de resposta a incidentes.

Decisão contínua não significa reautenticar o usuário a cada segundo. Significa possuir mecanismos para reavaliar contexto quando sinais relevantes mudam: risco de identidade, postura, revogação de grupo ou detecção de comportamento anômalo.

A organização precisa equilibrar segurança e estabilidade. Sessões críticas não devem ser derrubadas por sinais pouco confiáveis ou políticas mal calibradas.

Migração de VPN para ZTNA

A migração deve ocorrer por aplicação e grupo de usuários, não como substituição cega da VPN. Primeiro são mapeadas aplicações, protocolos, autenticação, dependências e perfis de acesso. Em seguida são selecionados casos de uso compatíveis e conduzido um piloto.

Durante a transição, VPN e ZTNA podem coexistir. O objetivo é reduzir progressivamente o acesso de rede tradicional e deixar a VPN apenas para aplicações que ainda exigem conectividade ampla ou protocolos incompatíveis.

O processo deve medir experiência, latência, disponibilidade e falhas de autorização. Uma política tecnicamente restritiva, mas que força usuários a contornar o sistema, não melhora segurança.

Alta disponibilidade, performance e experiência

Broker, connector e IdP podem se tornar dependências críticas. A arquitetura precisa prever redundância, distribuição geográfica, capacidade e comportamento durante indisponibilidade parcial.

O caminho de dados também importa. Se o tráfego precisar atravessar pontos remotos antes de chegar à aplicação, latência pode aumentar. A seleção de pontos de presença e connectors deve considerar localização de usuários e workloads.

A experiência de acesso precisa ser simples: autenticação previsível, descoberta adequada das aplicações e mensagens de erro que permitam diferenciar falha de identidade, postura ou disponibilidade do serviço.

Ciclo de vida, testes e critérios de aceite

A implantação começa pelo inventário de aplicações, usuários, dispositivos e dependências. Em seguida são definidos políticas, grupos, integrações com IdP, requisitos de postura, arquitetura de brokers e modelo de logs.

Os testes devem cobrir acesso permitido e negado, MFA, mudança de grupo, dispositivo não conforme, revogação, acesso de terceiro, indisponibilidade de connector e failover. Critérios de aceite precisam incluir rastreabilidade da decisão e impacto percebido pelo usuário.

Entregáveis podem incluir arquitetura ZTNA, matriz de aplicações, perfis de acesso, políticas, integrações IAM, plano de migração de VPN, procedimentos de contingência, testes e documentação operacional.

O ciclo de política precisa acompanhar o ciclo das aplicações. Quando um novo sistema entra em produção, deve existir um processo para definir owner, grupos autorizados, método de autenticação, requisitos de postura e condições de acesso. Sem essa governança, o ZTNA tende a acumular políticas excepcionais difíceis de interpretar.

Da mesma forma, aplicações desativadas ou migradas precisam ter connectors, regras e grupos removidos. A plataforma deve permitir identificar políticas sem uso, acessos temporários vencidos e dependências que deixaram de existir.

DNS e resolução de nomes também precisam ser considerados. Aplicações privadas podem depender de zonas internas e nomes não publicados externamente. O desenho deve garantir que o usuário resolva somente os recursos necessários, sem expor desnecessariamente a estrutura de nomes do ambiente.

Em cenários com múltiplos sites ou cloud, connectors devem ser posicionados próximos às aplicações para evitar hairpinning e reduzir latência. A distribuição também precisa considerar capacidade de cada connector e comportamento durante manutenção.

Indicadores úteis incluem aplicações migradas da VPN, acessos negados por política, tempo de revogação, cobertura de MFA, dispositivos não conformes e volume de exceções. O objetivo é demonstrar redução de confiança ampla e identificar onde o modelo ainda depende de permissões excessivas.

Considerações de Engenharia

ZTNA não é uma solução isolada

Sem identidade confiável, postura, segmentação e monitoramento, o broker de acesso resolve apenas parte do problema.

Menor privilégio precisa ser operacionalmente sustentável

Políticas excessivamente granulares sem automação e ownership podem gerar grande volume de exceções.

VPN pode continuar existindo

Aplicações legadas ou cenários de contingência podem exigir conectividade tradicional durante a transição.

Contexto de baixa qualidade piora a decisão

Postura e risco precisam ser baseados em sinais confiáveis; caso contrário, políticas dinâmicas se tornam imprevisíveis.

Aplicações, serviços e modelo de contratação

A solução se aplica a trabalho remoto, terceiros, ambientes híbridos, cloud, infraestruturas críticas, filiais e organizações que desejam reduzir exposição de aplicações internas.

O Projeto de Rede Lógica pode estruturar segmentação e conectividade; a Consultoria Cisco apoia ambientes desse ecossistema; e Parametrização e Configuração pode apoiar implantação e validação.

O trabalho pode começar por assessment, piloto de aplicações e desenho de política, avançando por ondas. O resultado esperado é reduzir confiança implícita e entregar acesso específico, verificável e revogável.