Worin unterscheidet sich der ZTNA Connector von einer Standard Service Connection?

Der ZTNA Connector ist ein Application-Level Proxy, der keine eingehenden offenen Ports benötigt, während ein GP Gateway auf einer NGFW eine öffentlich zugängliche IP und einen offenen Listener auf Port 443/4501 erfordert. ZTNA ist sicherer, da es die Anwendungsinfrastruktur für das öffentliche Internet „unsichtbar“ macht.

Kann ich denselben GlobalProtect Agent für Prisma Access und meine On-Premise Gateways verwenden?

Ja, die GlobalProtect App (v6.x und höher) ist derselbe Client für beide. Sie ändern einfach die Portaladresse oder verwenden eine 'Multiple-Portal'-Konfiguration in den App-Einstellungen, um eine Migration zu erleichtern.

Verbessert Prisma Access ZTNA wirklich die Latenz für Remote-Benutzer?

Prisma Access nutzt die Hochgeschwindigkeits-Backbones von AWS und GCP. Durch die Terminierung der Benutzersitzung am 'Edge'-PoP, der dem Benutzer am nächsten ist, eliminieren Sie die Latenz des Backhaulings von Datenverkehr zu einer zentralen Rechenzentrums-Firewall.

Muss ich meine internen Server neu adressieren, wenn ich zu ZTNA wechsle?

Normalerweise nicht. Prisma Access verwendet typischerweise 'Service Connections' oder 'ZTNA Connectors', um über einen sicheren Tunnel interne Ressourcen zu erreichen. Eine Neugestaltung Ihres internen IP-Schemas ist nicht erforderlich, solange Sie über die Connector-VM auf die internen Subnetze routen können.

Was unterscheidet Prisma Access 'ZTNA 2.0' von Standard ZTNA?

ZTNA 2.0 bietet eine kontinuierliche Vertrauensprüfung. Wenn ein Gerät nicht konform wird (z. B. AV deaktiviert ist) oder sich das Benutzerverhalten während der Sitzung ändert, kann Prisma Access den spezifischen Anwendungsfluss sofort beenden, selbst wenn der Tunnel noch aktiv ist.

Gibt es ein Szenario, in dem ich GlobalProtect auf meiner NGFW behalten sollte?

ZTNA ist für 90 % der Anwendungsfälle überlegen. Für Legacy-Anwendungen, die feste Quell-IP-Adressen oder nicht-standardisierte Protokolle erfordern, die nicht einfach über Proxies geleitet werden können (wie bestimmte ältere Industrieprotokolle), kann ein traditioneller GlobalProtect-Tunnel jedoch weiterhin notwendig sein.

GlobalProtect vs. Prisma Access ZTNA: Der Migrations-Blueprint 2026

Die Debatte zwischen dem traditionellen GlobalProtect „On-Prem Gateway“-Modell und Prisma Access ZTNA dreht sich nicht mehr um Funktionsgleichheit – es geht um den architektonischen Tod des statischen Perimeters und den Übergang zu einem identitätsbasierten, Proxy-gestützten Sicherheitskonzept, das die Hardware-gebundene PAN-OS-Plattform im Jahr 2026 einfach nicht mehr skalieren kann.

Das architektonische Dilemma: Warum GlobalProtect auf PA-Series am Redline limitiert ist

Ein Jahrzehnt lang war der „Goldene Standard“ einfach: Eine PA-440 oder PA-1400 in einer Regionalniederlassung bereitstellen, ein SSL/IPsec Gateway konfigurieren und GlobalProtect Tunnels direkt auf der Dataplane terminieren. Das funktionierte, als Anwender 10 % der Belegschaft ausmachten. In einer hybriden Welt ist dieses Modell grundsätzlich überholt. Wenn Sie 500 GlobalProtect Tunnels auf einer PA-400 Serie terminieren, verbrauchen Sie massive Mengen an DP (Dataplane) CPU für Verschlüsselung/Entschlüsselung, was wenig Overhead für Layer 7 Content Inspection oder WildFire Analyse lässt.

Die Realität von 2026 ist, dass GlobalProtect ein VPN ist, während Prisma Access ein Fabric ist. Wenn Sie GP On-Prem betreiben, sind Sie der ISP-Bandbreite Ihres Head-Ends und der physikalischen Latenz des Backhauls unterworfen. Wenn ein Benutzer in London eine Verbindung zu einem Gateway in New York herstellt, um auf eine SaaS-Anwendung zuzugreifen, haben Sie 120 ms unnötiger Latenz eingeführt. Prisma Access verlagert die „On-Ramp“ an den nächstgelegenen AWS/GCP Edge (mehr als 100 Points of Presence weltweit) und bietet eine konsistente First-Hop-Latenz von <10 ms.

ZTNA 2.0: Von „Verbinden und dann Prüfen“ zu „Identity-First“

Standard GlobalProtect folgt dem Modell „Connect then Inspect“. Sobald ein Benutzer authentifiziert ist und der Tunnel aufgebaut wurde, hat er eine IP im internen Netzwerk. Selbst mit strikten Security Policies ist das Gerät des Benutzers technisch „im Netzwerk“. Prisma Access ZTNA (Version 2.0) verwendet den ZTNA Connector, der die Logik umkehrt.

Der ZTNA Connector befindet sich in Ihrer VPC oder Ihrem Rechenzentrum und stellt einen Outbound-Tunnel zur Prisma Access Cloud her. Es gibt keine offenen Inbound-Ports (kein 443/VPN Listener) auf Ihrer Firewall. Dies verbirgt Ihre Anwendungsinfrastruktur effektiv vor dem öffentlichen Internet und eliminiert die Möglichkeit von Zero-Day-Exploits gegen den VPN-Dienst selbst – eine Schwachstelle, die Legacy SSL-VPN-Anbieter in letzter Zeit geplagt hat.


# Traditionelles GP Gateway (anfällig für Erkennung)
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

# ZTNA Connector Logik (nur Outbound)
# Keine Inbound NAT erforderlich. Connector wählt sich in die Prisma Cloud ein.
cloud-connector {
  target-fragment "Prisma-Backbone";
  redundancy-group 'Prod-West';
  egress-interface ethernet1/1;
}

Der Migrationsauslöser 2026: Wann stirbt GlobalProtect?

Sie sollten zu Prisma Access ZTNA migrieren, wenn Ihre Umgebung diese drei technischen Auslöser erreicht:

Der Bandbreiten-Engpass: Ihr aggregierter Remote-Benutzerverkehr überschreitet 50 % der entschlüsselten Durchsatzkapazität Ihres Head-Ends (prüfen Sie show running resource-monitor).
SaaS-Proliferation: Wenn 70 % Ihres Datenverkehrs für O365, Salesforce oder GitHub bestimmt sind, ist das Backhauling dieses Verkehrs zu einer PA-3410, nur um ihn wieder ins Internet zu leiten, eine Verschwendung teurer Siliziumchips.
Die „App-spezifische“ Anforderung: Wenn das Business verlangt, dass Drittanbieter-Auftragnehmer nur auf eine bestimmte Jira-Instanz zugreifen, ohne einen vollständigen IP-Stack-Tunnel.

Weitere Informationen zur Dimensionierung der Infrastruktur finden Sie in unserem Deep Dive über die PAN-OS Hardware-Dimensionierung für 2025-2026.

Policy Parity: Panorama vs. Prisma Access Console

Eine der größten Hürden bei der Migration ist die Angst vor dem Verlust der Policy-Granularität. Im Jahr 2026 hat Palo Alto Networks endlich eine nahezu vollständige Parität erreicht. Egal, ob Sie ein GlobalProtect Gateway auf einer NGFW oder das Prisma Access Cloud Management verwenden, die Policy-Konstrukte bleiben dieselben: User-ID, App-ID und Device-ID. Prisma Access führt jedoch Dynamic User Groups (DUG) ein, die mit Prisma SaaS Security integriert sind, um Benutzer automatisch vom ZTNA-Tunnel zu trennen, wenn ihr Verhalten (über API überwacht) auf einen Credential Theft hindeutet.

Der Prisma Access ZTNA Connector vs. Service Connections

In früheren Iterationen verwendeten wir „Service Connections“ (einen IPsec-Tunnel von Ihrer FW zu Prisma), um interne Anwendungen zu erreichen. Im Jahr 2026 ist der ZTNA Connector die bevorzugte Methode für den privaten App-Zugriff. Es ist eine leichte VM (ESXi, KVM oder Cloud Native), die als Application Proxy fungiert. Dies ermöglicht eine Zugriffskontrolle auf Anwendungsebene anstatt auf Netzwerkebene. Sie geben einem Benutzer keinen Zugriff auf ein Subnetz; Sie geben ihm Zugriff auf https://internal-app.corp.local.

Benutzererfahrung: Der Mythos „Always-On“ vs. Realität

GlobalProtect-Benutzer beklagen sich oft über den „Tunnel Flip“ – den 3-5 Sekunden langen Abbruch beim Wechsel von Wi-Fi zu LTE. Prisma Access löst dieses Problem mithilfe der Mobile Segment Termination. Da der Benutzer sich mit einem massiven Cloud-Backbone verbindet, wird der Session-State im SDN (Software Defined Network) des Cloud-Anbieters aufrechterhalten, anstatt in einer einzelnen physikalischen DP-Hardware-Instanz. Das Ergebnis ist ein nahtloser Übergang, der für Zoom- oder Teams-Telefonate unsichtbar ist.

Die Kosten-Gleichung: Hardware-Austausch vs. OpEx Cloud

Betrachten wir die Zahlen. Eine PA-3410, die 2.000 GlobalProtect-Benutzer mit vollständiger SSL-Inspektion verarbeiten kann, kostet ca. 35.000 USD (MSRP) zuzüglich 7.000 USD/Jahr für Support und Subscriptions. Über 5 Jahre beträgt die TCO etwa 70.000 USD. Für dieselben 2.000 Benutzer könnte Prisma Access ZTNA (Okyo- oder Business-Editionen) jährlich höhere OpEx-Kosten verursachen, aber Sie eliminieren die Notwendigkeit redundanter, Multi-Homed-ISP-Links, Rack Space und des Humankapitals, das für die monatliche Behebung von PAN-OS-Schwachstellen erforderlich ist.

Wir stellen oft fest, dass für Organisationen mit mehr als fünf regionalen Hubs die Konsolidierung des Security Stacks in Prisma Access zu einer Reduzierung der TCO um 20 % führt, wenn man die „versteckten“ Kosten von Backhaul MPLS oder hochbandbreitigen DIA (Dedicated Internet Access)-Leitungen in jeder Zweigstelle berücksichtigt.

Implementierung des Übergangs: Ein gestufter Ansatz

Man schaltet nicht einfach einen Schalter um und verschiebt 10.000 Benutzer zu ZTNA. Der Migrationspfad 2026 folgt diesem Blueprint:

Phase 1: Hybrid Cloud. Behalten Sie Ihre PA-Serie GP Gateways für „Legacy“-Apps, die eine Thick-Client IP-Konnektivität erfordern (z. B. alte Oracle DBs).
Phase 2: Nutzen Sie Prisma Access für „Internet-Offload“. Lassen Sie den GlobalProtect-Client für den gesamten SaaS/Web-Verkehr eine Verbindung zu Prisma herstellen, um das Hochgeschwindigkeits-Backbone zu nutzen.
Phase 3: ZTNA Connector Bereitstellung. Implementieren Sie ZTNA Connectors in Ihren primären Rechenzentren und migrieren Sie Web-basierte interne Apps Zug um Zug.
Phase 4: Hardware-Außerbetriebnahme. Sobald nur noch 10 % des Datenverkehrs das lokale Gateway erreichen, skalieren Sie die Hardware auf einen kleineren Footprint (wie eine PA-400 Serie) nur für die lokale Site-to-Site-Konnektivität.

Für komplexe Migrationsszenarien, die Legacy Routing umfassen, konsultieren Sie unseren Leitfaden zu Advanced BGP Peering mit Prisma Access.

Zusammenfassung: Das Urteil

Wenn Sie immer noch große, hochdurchsatzfähige Firewalls ausschließlich zur Terminierung von VPN-Tunnels kaufen, bauen Sie eine technische Schuld-Bombe. Bis 2026 wird die Komplexität der Verwaltung globaler IPsec/SSL VPN-Terminierung auf physischer Hardware die Kosten von Cloud-nativem ZTNA übersteigen. Prisma Access geht nicht nur um Sicherheit; es geht um Netzwerkleistung und die Verlagerung der Sicherheitsgrenze dorthin, wo der Benutzer tatsächlich existiert: der Browser und der Identity Provider.

Bereit, Ihren Edge zu modernisieren und das VPN-Gepäck abzulegen? Unser Team aus CCIEs und PCNSEs kann Ihren Übergang von traditionellem GlobalProtect zu einem vollständigen ZTNA 2.0 Framework planen. Entdecken Sie unsere gestuften Beratungs- und Bereitstellungspakete unter techleague.io.