Posso usar o mesmo agente GlobalProtect tanto para o Prisma Access quanto para meus Gateways on-premise?

Sim, o GlobalProtect App (v6.x e superior) é o mesmo client para ambos. Você simplesmente altera o endereço do portal ou usa uma configuração de 'múltiplos portais' nas configurações do aplicativo para facilitar a migração.

O Prisma Access ZTNA realmente melhora a latência para usuários remotos?

O Prisma Access utiliza os backbones de alta velocidade da AWS e GCP. Ao terminar a sessão do usuário no PoP 'Edge' mais próximo do usuário, você elimina a latência de fazer backhaul do tráfego para um firewall de data center central.

Precisarei reendereçar meus servidores internos se migrar para ZTNA?

Geralmente, não. O Prisma Access tipicamente usa 'Service Connections' ou 'ZTNA Connectors' para alcançar recursos internos via um túnel seguro. Não é necessário redesenhar seu esquema de IP interno, desde que você possa rotear para as subnets internas da VM do Connector.

O que torna o Prisma Access 'ZTNA 2.0' diferente do ZTNA padrão?

O ZTNA 2.0 fornece verificação contínua de confiança. Se um dispositivo se tornar não-compatível (por exemplo, o AV for desativado) ou o comportamento do usuário mudar no meio da sessão, o Prisma Access pode encerrar o fluxo de aplicação específico instantaneamente, mesmo que o túnel ainda esteja ativo.

Existe algum cenário em que eu deveria manter o GlobalProtect no meu NGFW?

O ZTNA é superior para 90% dos casos de uso. No entanto, para aplicações legadas que exigem endereços IP de origem fixos ou protocolos não-padrão que não são facilmente 'proxied' (como certos protocolos industriais mais antigos), um túnel GlobalProtect tradicional ainda pode ser necessário.

GlobalProtect vs. Prisma Access ZTNA: O Blueprint de Migração para 2026

O debate entre o modelo tradicional GlobalProtect "On-Prem Gateway" e o Prisma Access ZTNA não é mais sobre paridade de funcionalidades — é sobre a morte arquitetônica do perímetro estático e a transição para uma postura de segurança identity-aware, baseada em proxy, que o PAN-OS, atrelado ao hardware, simplesmente não consegue escalar em 2026.

O Impasse Arquitetônico: Por que GlobalProtect em PA-Series tem Limitação de Redline

Por uma década, o "Golden Standard" era simples: implementar um PA-440 ou PA-1400 em um escritório regional, configurar um gateway SSL/IPsec e terminar túneis GlobalProtect diretamente no dataplane. Isso funcionava quando os usuários representavam 10% da força de trabalho. Em um mundo pós-híbrido, este modelo está fundamentalmente obsoleto. Quando você termina 500 túneis GlobalProtect em uma série PA-400, você está consumindo uma quantidade massiva de DP (Dataplane) CPU para criptografia/descriptografia, deixando pouca sobrecarga para Layer 7 Content Inspection ou análise WildFire.

A realidade de 2026 é que GlobalProtect é uma VPN, enquanto Prisma Access é uma Fabric. Ao executar GP on-prem, você está refém da largura de banda do ISP do seu head-end e da latência física do backhaul. Se um usuário em Londres se conecta a um gateway em Nova York para acessar uma aplicação SaaS, você introduziu 120ms de latência desnecessária. O Prisma Access move o "On-Ramp" para a edge mais próxima da AWS/GCP (mais de 100 pontos de presença globalmente), fornecendo uma latência de primeiro-hop consistente de <10ms.

ZTNA 2.0: Mudando de "Conectar e Depois Inspecionar" para "Identity-First"

O GlobalProtect padrão segue o modelo "Connect then Inspect". Uma vez que um usuário autentica e o túnel é estabelecido, ele tem um IP na rede interna. Mesmo com Security Policies restritas, o dispositivo do usuário está tecnicamente "na" rede. O Prisma Access ZTNA (Versão 2.0) utiliza o ZTNA Connector, que inverte a lógica.

O ZTNA Connector reside em sua VPC ou Data Center e estabelece um túnel outbound para a nuvem do Prisma Access. Não há portas de entrada abertas (sem listener 443/VPN) em seu firewall. Isso efetivamente oculta sua infraestrutura de aplicação da internet pública, eliminando a possibilidade de exploits zero-day contra o próprio serviço VPN—uma vulnerabilidade que tem afetado recentemente fornecedores de SSL-VPN legados.


# Gateway GP Tradicional (vulnerável a descoberta)
set network interface ethernet1/1 layer3 ip 203.0.113.10/24
set network profiles global-protect-gateway GP-GW-External
set deviceconfig setting global-protect-gateway enable yes

# Lógica do ZTNA Connector (somente Outbound)
# Não é necessário NAT de entrada. O Connector faz a conexão de saída para a Prisma Cloud.
cloud-connector {
  target-fragment "Prisma-Backbone";
  redundancy-group 'Prod-West';
  egress-interface ethernet1/1;
}

O Gatilho de Migração de 2026: Quando o GlobalProtect Morre?

Você deve migrar para o Prisma Access ZTNA quando seu ambiente atingir estes três gatilhos técnicos:

O Gargalo de Largura de Banda: Seu tráfego agregado de usuários remotos excede 50% da capacidade de throughput descriptografado do seu head-end (verifique show running resource-monitor).
Proliferação de SaaS: Se 70% do seu tráfego é destinado a O365, Salesforce ou GitHub, fazer backhaul desse tráfego para um PA-3410 apenas para enviá-lo de volta à internet é um desperdício de silício caro.
O Requisito "App-Specific": Quando o negócio exige que Terceiros Contratados acessem apenas uma instância específica do Jira sem um full IP-stack tunnel.

Para mais informações sobre o dimensionamento da infraestrutura, confira nossa análise aprofundada sobre Dimensionamento de Hardware PAN-OS para 2025-2026.

Paridade de Política: Panorama vs. Prisma Access Console

Um dos maiores obstáculos na migração é o medo de perder granularidades de política. Em 2026, a Palo Alto Networks finalmente alcançou uma paridade quase total. Quer você esteja usando um GlobalProtect Gateway em um NGFW ou o Prisma Access Cloud Management, as construções de política permanecem as mesmas: User-ID, App-ID e Device-ID. No entanto, o Prisma Access introduz Dynamic User Groups (DUG) integrados com o Prisma SaaS Security, permitindo que você expulse automaticamente um usuário do túnel ZTNA se seu comportamento (monitorado via API) indicar roubo de credenciais.

O ZTNA Connector do Prisma Access vs. Service Connections

Em iterações anteriores, usávamos "Service Connections" (um túnel IPsec do seu FW para o Prisma) para alcançar aplicações internas. Em 2026, o ZTNA Connector é o método preferencial para acesso a aplicações privadas. É uma VM leve (ESXi, KVM ou Cloud Native) que atua como um proxy de aplicação. Isso permite Application Level Access Control em vez de Network Level Access Control. Você não está dando a um usuário acesso a uma Subnet; você está dando a ele acesso a https://internal-app.corp.local.

Experiência do Usuário: O Mito do "Always-On" vs. Realidade

Usuários do GlobalProtect frequentemente reclamam do "tunnel flip" - a interrupção de 3-5 segundos ao mudar de Wi-Fi para LTE. O Prisma Access resolve isso usando o Mobile Segment Termination. Como o usuário está se conectando a um backbone massivo em nuvem, o estado da sessão é mantido na SDN (Software Defined Network) do provedor de nuvem, em vez de uma única instância física de hardware DP. O resultado é uma transição contínua que é invisível para chamadas Zoom ou Teams.

A Equação de Custo: Hardware Refresh vs. OpEx Cloud

Vamos analisar os números. Um PA-3410 capaz de lidar com 2.000 usuários GlobalProtect com full SSL Inspection custa aproximadamente $35.000 MSRP mais $7.000/ano em Suporte e Assinaturas. Ao longo de 5 anos, o TCO é de aproximadamente $70.000. Para os mesmos 2.000 usuários, o Prisma Access ZTNA (edições Okyo ou Business) pode ter um custo OpEx anual mais alto, mas você elimina a necessidade de links ISP multi-homed redundantes, espaço em rack e o capital humano necessário para aplicar patches de vulnerabilidades PAN-OS todos os meses.

Frequentemente, descobrimos que para organizações com mais de 5 hubs regionais, a consolidação da stack de segurança no Prisma Access resulta em uma redução de 20% no TCO ao considerar os custos "ocultos" de MPLS de backhaul ou circuitos DIA (Dedicated Internet Access) de alta largura de banda em cada filial.

Implementando a Transição: Uma Abordagem Faseada

Você não vira uma chave e move 10.000 usuários para ZTNA. O caminho de migração de 2026 segue este blueprint:

Fase 1: Hybrid Cloud. Mantenha seus PA-series GP Gateways para aplicações "Legadas" que exigem conectividade de IP de thick-client (por exemplo, Oracle DBs antigos).
Fase 2: Use Prisma Access para "Internet-Offload". Permita que o GlobalProtect client se conecte ao Prisma para todo o tráfego SaaS/Web, utilizando o backbone de alta velocidade.
Fase 3: Implantação do ZTNA Connector. Implante ZTNA Connectors em seus principais DCs e migre as aplicações internas baseadas em Web, uma a uma.
Fase 4: Descomissionamento de Hardware. Uma vez que apenas 10% do tráfego esteja atingindo o gateway local, reduza o hardware para um footprint menor (como uma série PA-400) apenas para conectividade local site-to-site.

Para cenários de migração complexos envolvendo roteamento legado, consulte nosso guia sobre Advanced BGP Peering com Prisma Access.

Resumo: O Veredito

Se você ainda está comprando firewalls grandes e de alto throughput apenas com o propósito de terminar túneis VPN, você está construindo uma bomba de débito técnico. Até 2026, a complexidade de gerenciar a terminação de IPsec/SSL VPN global em hardware físico superará os custos do ZTNA nativo da nuvem. O Prisma Access não é apenas sobre segurança; é sobre desempenho de rede e mover o limite de segurança para onde o usuário realmente vive: o navegador e o provedor de identidade.

Pronto para modernizar sua edge e abandonar a bagagem da VPN? Nossa equipe de CCIEs e PCNSEs pode arquitetar sua transição do GlobalProtect legado para uma estrutura completa ZTNA 2.0. Explore nossos pacotes de consultoria e implementação em níveis em techleague.io.