Zscaler Deployment: Der vollständige Leitfaden für Architektur, Rollout und Migration

Das Wichtigste in Kürze

Ein Zscaler-Deployment ist kein einzelner Installationsschritt, sondern eine Abfolge von Entscheidungen, die aufeinander aufbauen. Identität steht zuerst, weil jede spätere Regel auf Benutzer und Gruppen verweist. Danach folgt die Wahl der Forwarding-Methode für jeden Standort- und Nutzertyp, die Verteilung von Zscaler Client Connector auf die Endgeräte über Intune oder Jamf, die Anbindung interner Anwendungen über App Connector in AWS oder Azure, ein stufenweiser Rollout in wachsenden Nutzergruppen und zuletzt die Messung mit Zscaler Digital Experience (ZDX). Wer von einem bestehenden Proxy umsteigt, folgt derselben Architektur und bringt zusätzlich die Migration des bestehenden Regelwerks mit. Dieser Leitfaden geht jede dieser Etappen einzeln durch, mit Quellenangaben zu Zscalers eigener Dokumentation und einer Checkliste am Ende.

Für wen dieser Leitfaden ist

Sie planen die Einführung von Zscaler in Ihrer Organisation oder bereiten den nächsten Rollout-Schritt vor: einen weiteren Standort, eine weitere Nutzergruppe, die Anbindung einer Cloud-Umgebung oder den Umzug von einem bestehenden Proxy. Dieser Leitfaden richtet sich an IT-Leitung, Netzwerk- und Security-Teams sowie Projektverantwortliche, die eine belastbare Grundlage für die eigene Planung suchen, unabhängig davon, ob die Umsetzung intern oder mit einem Partner erfolgt.

1. Die Bausteine und wie sie zusammenhängen

Ein Zscaler-Deployment besteht aus wenigen Bausteinen, die in einer bestimmten Reihenfolge aufeinander aufbauen. Wer diese Reihenfolge kennt, vermeidet den häufigsten Fehler: eine Regel, die auf eine Gruppe verweist, die es im Identitätsdienst noch nicht gibt, oder einen Client, der Verkehr sendet, bevor eine Richtlinie dafür existiert.

Identität. Der Zscaler Authentication Service (frühere Bezeichnung: ZIdentity) verbindet sich mit Ihrem externen Identity Provider (IdP) über SAML oder OIDC und automatisiert die Benutzerbereitstellung über SCIM. Jede spätere Regel in ZIA oder ZPA verweist auf Benutzer oder Gruppen aus diesem Dienst. Ohne stehende Identität greift die erste Regel ins Leere.

Endgeräte. Zscaler Client Connector läuft auf Notebooks, Smartphones und Tablets und leitet den Verkehr des Geräts an den nächstgelegenen Zscaler-Dienst weiter, unabhängig vom Netzwerk, in dem sich das Gerät gerade befindet. Die Verteilung läuft über die vorhandene Geräteverwaltung, etwa Microsoft Intune oder Jamf Pro.

Standorte. Für Büros und Rechenzentren mit fester Anbindung kommen GRE- oder IPSec-Tunnel oder eine PAC-Datei zum Einsatz, je nachdem, welche Ausrüstung vorhanden ist und ob eine statische IP-Adresse existiert.

Private Anwendungen. Der App Connector stellt die Verbindung zwischen internen Anwendungen und der Zscaler-Cloud her, ohne dass diese Anwendungen aus dem Internet erreichbar sein müssen. Er läuft im eigenen Rechenzentrum, in AWS, in Azure oder auf weiteren unterstützten Plattformen.

Durchsetzung. ZIA (Zscaler Internet Access) prüft und regelt den Internet- und SaaS-Verkehr, ZPA (Zscaler Private Access) regelt den Zugriff auf interne Anwendungen ohne klassisches VPN. Beide werten dieselben Identitäten und Richtlinien aus.

Messung. ZDX (Zscaler Digital Experience) misst, ob das, was Sie konfiguriert haben, beim Nutzer tatsächlich so ankommt wie geplant, als Gerätemetrik, als Pfadmessung und als Anwendungsmessung.

2. Die Weichenstellungen: Deployment-Modelle im Vergleich

Zscaler unterstützt mehrere Wege, Verkehr an den Dienst weiterzuleiten. Die meisten Organisationen nutzen eine Kombination, nicht nur einen einzelnen Weg, weil unterschiedliche Standort- und Nutzertypen unterschiedliche Anforderungen haben. Die folgende Tabelle ordnet jeder Situation die passende Methode zu.

Was das für Ihre Entscheidung heißt: Die Wahl ist selten binär. Ein typisches Deployment kombiniert GRE- oder IPSec-Tunnel für die festen Standorte, Zscaler Client Connector für mobile Geräte und eine PAC-Datei als Auffangnetz für Geräte, die (noch) keinen Client tragen. Zscaler selbst empfiehlt ausdrücklich eine Kombination aus Tunneling, PAC-Dateien und Client Connector statt einer einzelnen Methode für die gesamte Organisation.

PAC-Dateien im Detail. Eine PAC-Datei (Proxy Auto-Configuration) ist eine Textdatei mit JavaScript-Logik, die dem Browser sagt, wann und wohin er Verkehr an einen Proxy weiterleiten soll. Zscaler stellt eine Standard-PAC-Datei bereit, die per Geolokalisierung automatisch den nächstgelegenen Zscaler-Standort einträgt; eigene, angepasste PAC-Dateien lassen sich zusätzlich hochladen. Weil die PAC-Datei im Browser selbst hinterlegt ist, wirkt sie unabhängig vom Netzwerk des Nutzers, was sie zur sinnvollen Ergänzung für Nutzer außerhalb des Firmennetzes macht, auch wenn bereits ein Tunnel oder ein Client Connector im Einsatz ist.

Quelle: help.zscaler.com/zia/choosing-traffic-forwarding-methods, help.zscaler.com/zia/understanding-pac-file (beide abgerufen 30.09.2026).

3. Bevor es losgeht: Planung und Bestandsaufnahme

Der Teil eines Deployments, der am meisten Zeit spart, ist keine Konfiguration, sondern eine saubere Bestandsaufnahme vorab. Zscaler empfiehlt, vor dem ersten Rollout-Schritt strukturiert zu erfassen, welche Betriebssysteme und Versionen im Einsatz sind, welche Browser genutzt werden, welche VPN-Clients, Antivirus-Lösungen und Firewalls bereits laufen, wie Geräte verwaltet werden und welche geschäftskritischen Anwendungen betroffen sein könnten. Diese Informationen entscheiden, welche Sonderfälle in der Pilotphase auftauchen und welche Ausnahmen von Anfang an eingeplant werden sollten.

Ein zweiter, unterschätzter Planungspunkt: die Ausnahmen für die eigene Authentifizierung. Der gesamte Verkehr, der zu Ihrem Identity Provider geht, sollte direkt dorthin laufen und nicht selbst durch Zscaler inspiziert werden. Das betrifft SSL-Inspection-Ausnahmen ebenso wie Authentifizierungs-Ausnahmen, unabhängig davon, ob der Verkehr über PAC-Datei, GRE-Tunnel, IPSec-Tunnel oder Client Connector läuft. Wird das übersehen, entstehen Anmeldeprobleme, die sich erst mit Verzögerung einem einzelnen Grund zuordnen lassen.

Der dritte Punkt betrifft die Interoperabilität mit vorhandener Software. Läuft Zscaler Client Connector zusammen mit einem VPN-Client oder einer VPN-ähnlichen Anwendung, lohnt sich ein gezielter Test auf Konflikte, bevor die breite Verteilung beginnt.

Zur Richtlinien-Strategie: Ein Zscaler-Kunde, der laut eigenem, von Zscaler veröffentlichtem Erfahrungsbericht vier Zscaler-Einführungen begleitet hat, empfiehlt, zunächst mit einfachen, pragmatischen globalen Richtlinien zu starten statt mit vollständiger Sperrung. In seinem Fall stand der Internetzugriff zunächst grundsätzlich auf „nur lesend", was das Risiko von Datenverlust ausschloss, ohne die Arbeitsfähigkeit der Nutzer einzuschränken, und den Rollout beschleunigt hat. Einzelne Freigaben, etwa für bestimmte Cloud-Dienste, kamen danach gezielt dazu. Dieser Ansatz lässt sich unabhängig von der Organisationsgröße übertragen: Erst eine breite, verständliche Grundregel etablieren, dann anhand echter Nutzung nachschärfen, statt umgekehrt mit einem vollständigen Regelwerk zu beginnen, das niemand vorab vollständig testen kann.

Quelle: help.zscaler.com/zscaler-client-connector/best-practices-zscaler-client-connector-deployment, help.zscaler.com/zscaler-deployments-operations/zscaler-client-connector-deployment-and-operations-guide (beide abgerufen 30.09.2026); Erfahrungsbericht: zscaler.com/blogs/customer-stories/lessons-learned-four-zscaler-deployments-later, veröffentlicht 03.09.2024, abgerufen 30.09.2026.

4. Identität zuerst: SAML, SCIM und der Umzug des Identity Providers

Jede Regel in ZIA und ZPA verweist letztlich auf einen Benutzer oder eine Gruppe. Diese Information kommt nicht aus Zscaler selbst, sondern aus Ihrem Identity Provider, angebunden über den Zscaler Authentication Service. Deshalb steht die Identitätsanbindung am Anfang jedes Deployments, nicht als Randthema irgendwo in der Mitte.

Zwei Protokolle, eine Empfehlung. Der Authentication Service unterstützt sowohl OpenID Connect (OIDC) als auch SAML für die Authentifizierung sowie SCIM für die automatisierte Benutzerbereitstellung. Zscaler empfiehlt OIDC, insbesondere wenn Step-up-Authentifizierung (eine zusätzliche Prüfung bei risikoreicheren Aktionen) zum Einsatz kommen soll, da die meisten Identity Provider diese Funktion nur über OIDC unterstützen. SAML bleibt die richtige Wahl, wenn eine OIDC-Anbindung beim gewählten Identity Provider nicht zur Verfügung steht.

SCIM statt Just-in-Time. Für die Benutzerbereitstellung selbst empfiehlt Zscaler SCIM gegenüber Just-in-Time-Provisionierung (JIT). SCIM synchronisiert Identitäten proaktiv über eine API, nach Zeitplan oder auf Abruf. JIT dagegen aktualisiert Identitäten nur reaktiv, wenn sich ein Nutzer anmeldet, was bedeutet, dass Änderungen an Gruppenmitgliedschaften erst mit Verzögerung wirksam werden, etwa wenn jemand die Organisation verlässt.

Ein Punkt, der besonders für einen Wechsel des Identity Providers relevant ist: Benutzer und Gruppen aus dem primären Identity Provider bleiben im Authentication Service erhalten, selbst wenn der primäre Identity Provider entfernt wird. Diese Eigenschaft ist ausdrücklich so angelegt, um einen späteren Umzug von einem Identity-Provider-Partner zu einem anderen zu erleichtern, ohne dass die gesamte Benutzer- und Gruppenstruktur neu aufgebaut werden muss.

Unterstützte externe Identity Provider laut Zscalers eigener Dokumentation, mit dem jeweils unterstützten Protokoll: Microsoft Entra ID (OIDC über eine Gallery App, zusätzlich SAML), Okta (OIDC über eine OIN-App oder eine benutzerdefinierte App, zusätzlich SAML), Microsoft AD FS (beide Protokolle), PingOne (beide Protokolle), Auth0 (beide Protokolle), OneLogin (beide Protokolle), PingFederate (beide Protokolle). Der Authentication Service lässt sich darüber hinaus mit jedem Identity Provider verbinden, der eine Standardimplementierung von SAML, OIDC oder SCIM anbietet, und erlaubt bis zu 64 Identity Provider je Organisation, etwa um verschiedene Nutzerdomänen getrennt zu verwalten.

Ein operativer Punkt für den späteren Betrieb: Die Konsole zeigt einen Warnhinweis an, sobald ein SAML-Zertifikat innerhalb von 90 Tagen abläuft. Wer das im Kalender vermerkt, vermeidet eine unangekündigte Anmeldestörung für die gesamte Organisation.

Was das für Ihre Entscheidung heißt: Wenn Sie mehrere Nutzergruppen mit unterschiedlichen Anforderungen haben, etwa eine Gruppe mit strengeren Compliance-Vorgaben, lohnt sich eine sekundäre Identity-Provider-Anbindung für genau diese Domäne, statt Ausnahmen im Hauptregelwerk zu häufen. Wenn Sie einen Wechsel des Identity Providers ohnehin planen, etwa im Zuge einer größeren IT-Konsolidierung, ist der Zeitpunkt eines Zscaler-Deployments ein naheliegender Anlass, weil die Migrationsfähigkeit bereits eingebaut ist.

Quelle: help.zscaler.com/zidentity/about-external-identity-providers, abgerufen 30.09.2026.

5. Endgeräte: Windows über Intune, macOS über Jamf

Zscaler Client Connector selbst kostet keine zusätzliche Lizenz. Die Nutzung ist in der Lizenzierung von ZIA und ZPA bereits enthalten; die eigentliche Arbeit liegt in der Verteilung auf die Endgeräte.

Windows über Intune, SCCM oder GPO. Für Windows steht ein MSI-Installationspaket bereit, das sich direkt für eine manuelle Installation eignet oder über gängige Geräteverwaltungswerkzeuge verteilen lässt, die MSI-Dateien unterstützen, darunter Microsoft Intune, SCCM und GPO. Wer über die Standardinstallation hinaus Optionen setzen möchte, etwa eine strikte Durchsetzung des Client-Zwangs, erstellt dafür eine MST-Transformationsdatei oder ruft die MSI-Installation mit Kommandozeilenoptionen auf. Für Intune-Umgebungen mit Windows Autopilot stellt Zscaler zusätzlich eine eigene Anleitung bereit.

macOS über Jamf Pro. Für macOS lädt die IT-Administration zunächst das PKG-Installationspaket aus der Zscaler-Admin-Konsole herunter (Infrastructure, Common Resources, Deployment, Platform Releases) und lädt es anschließend in Jamf Pro hoch, wo eine Richtlinie (Policy) die Verteilung an die gewünschten Geräte übernimmt. Darüber hinaus lassen sich bis zu acht weitere, optionale Konfigurationsprofile einrichten: ein individuelles Einstellungsprofil, ein Zertifikatsprofil, die Konfiguration der Verkehrsabfangung, die Konfiguration der Tunnel-Parameter, ein eigenes VPN-Profil für Private Access VPN bei Altanwendungen, die Freigabe des vollständigen Festplattenzugriffs für Endpoint-DLP, verwaltete Anmeldeobjekte und eine prozessbasierte Anwendungsausnahme.

macOS über Intune. Wer macOS-Geräte über Microsoft Intune statt über Jamf Pro verwaltet, folgt demselben Muster: PKG-Datei aus der Admin-Konsole herunterladen, im Intune Admin Center bereitstellen, danach dieselben acht optionalen Konfigurationsprofile bei Bedarf ergänzen. Windows und macOS werden damit über unterschiedliche Verwaltungswerkzeuge verteilt, folgen aber demselben grundsätzlichen Ablauf: Paket beziehen, zuweisen, optional verfeinern, Ankunft nachweisen.

Was das für Ihre Entscheidung heißt: Die Wahl zwischen Jamf Pro und Intune für macOS richtet sich in aller Regel nach Ihrer bestehenden Geräteverwaltung, nicht nach Zscaler-spezifischen Vorteilen einer der beiden Optionen. Wer bereits Jamf für macOS und Intune für Windows im Einsatz hat, nutzt schlicht beide parallel und muss keine neue Verwaltungsschicht einführen. Die acht optionalen Konfigurationsprofile sind es wert, einmal systematisch durchzugehen, weil gerade der volle Festplattenzugriff für Endpoint-DLP und die prozessbasierte Anwendungsausnahme in der Praxis leicht übersehen werden und später zu Support-Tickets führen, die sich mit einer sauberen Erstkonfiguration vermeiden lassen.

Vor der Verteilung nicht vergessen: Zscaler Client Connector sollte auf Firewall und Antivirus-Lösung der Endgeräte als vertrauenswürdiger Prozess hinterlegt werden, und die Kommunikation zur Zscaler-Cloud muss durch die eigene Firewall hindurch erlaubt sein. Beides gehört in die Vorbereitung, nicht in die Fehlersuche danach.

Quelle: help.zscaler.com/zscaler-client-connector/customizing-zscaler-client-connector-install-options-msi, help.zscaler.com/zscaler-client-connector/deploying-zscaler-client-connector-jamf-pro-macos, help.zscaler.com/zscaler-client-connector/deploying-zscaler-client-connector-microsoft-intune-macos, help.zscaler.com/zscaler-deployments-operations/zscaler-client-connector-deployment-and-operations-guide (alle abgerufen 30.09.2026).

6. Private Anwendungen anbinden: App Connector in AWS und Azure

Interne Anwendungen, die nicht aus dem Internet erreichbar sein sollen, werden über den App Connector an ZPA angebunden. Der App Connector läuft als virtuelle Instanz möglichst nahe an der Anwendung selbst, in Ihrem eigenen Rechenzentrum, in AWS, in Azure oder auf weiteren unterstützten Plattformen, und baut eine ausgehende, authentifizierte Verbindung zur Zscaler-Cloud auf. Ein Netzwerk muss dafür nicht von außen erreichbar gemacht werden.

Der Ablauf ist für AWS und Azure identisch aufgebaut, laut Zscalers eigenen Bereitstellungsanleitungen für beide Plattformen: Zunächst die Voraussetzungen prüfen, dann den App Connector auf der jeweiligen Plattform bereitstellen, anschließend die Netzwerkeinstellungen für den bereitgestellten App Connector konfigurieren und zuletzt verifizieren, dass der App Connector läuft, fehlerfrei ist und die eigenen Dimensionierungsanforderungen erfüllt. Zscaler und AWS sind eigenständige Technologiepartner; für AWS existieren zusätzliche, spezifische Anleitungen etwa zur Traffic-Weiterleitung und zur Integration mit Amazon CloudWatch.

Dimensionierung: wie viele App Connector braucht es? Ein App Connector mit der empfohlenen Standardausstattung erreicht rund 500 Mbit/s Durchsatz. Mit mehr Ressourcen, etwa 8 virtuellen CPU-Kernen (beziehungsweise 4 physischen Kernen) und 8 GB Arbeitsspeicher, lässt sich der Durchsatz je App Connector auf bis zu 1 Gbit/s steigern. Als Faustregel für eine Standortanbindung mit 1 Gbit/s aggregierter Bandbreite empfiehlt Zscaler 2 bis 3 App Connector, wenn keine doppelte Verschlüsselung verwendet wird, beziehungsweise 4 bis 6 App Connector, wenn doppelte Verschlüsselung aktiv ist. Grundsätzlich gilt: mehrere kleiner dimensionierte App Connector sind einigen wenigen, größer dimensionierten vorzuziehen, weil der Ausfall eines einzelnen App Connector dann weniger Nutzersitzungen betrifft. Für Redundanz gilt außerdem das N+1-Prinzip, also mindestens ein zusätzlicher App Connector über die reine Kapazitätsanforderung hinaus.

Zwei praktische Punkte, die häufig übersehen werden. Erstens benötigt ein App-Connector-Deployment eine gültige ZPA-Lizenz (Professional, Business oder Transformation Edition). Zweitens bleibt der Betrieb des zugrunde liegenden Betriebssystems in Ihrer eigenen Verantwortung: Zscaler pflegt die App-Connector-Anwendung selbst, nicht das darunterliegende Betriebssystem der virtuellen Instanz. Wer den App Connector in AWS oder Azure betreibt, plant Patching und Systempflege der Instanz also als eigene, wiederkehrende Aufgabe ein, getrennt von den Zscaler-seitigen Software-Updates des App Connector.

Nach der Bereitstellung. Sobald der App Connector läuft, folgen zwei weitere Schritte: Anwendungssegmente und Zugriffsrichtlinien einrichten, damit tatsächlich Anwendungsverkehr fließen kann (ein einfaches Testsegment, etwa für SSH-Zugriff auf den App Connector selbst, eignet sich gut für einen ersten Funktionsnachweis), und optional einen Log-Empfänger konfigurieren, um Informationen über App Connector und Nutzer über den Log Streaming Service zu erhalten.

Was das für Ihre Entscheidung heißt: Die Frage ist selten „AWS oder Azure", sondern „wo läuft die Anwendung, die angebunden werden soll". Der App Connector folgt der Anwendung, nicht umgekehrt. Für eine hybride Landschaft mit Anwendungen in beiden Cloud-Umgebungen und im eigenen Rechenzentrum ist eine gemischte Bereitstellung der Normalfall, nicht die Ausnahme, weil jede Plattform ihre eigene, dicht an der Anwendung liegende App-Connector-Gruppe bekommt.

Quelle: help.zscaler.com/zpa/connector-deployment-guide-amazon-web-services, help.zscaler.com/zpa/connector-deployment-guide-microsoft-azure, help.zscaler.com/zpa/connector-deployment-prerequisites, help.zscaler.com/zscaler-deployments-operations/app-connector-deployment-and-operations-guide, help.zscaler.com/zsdk/understanding-app-connector-throughput (alle abgerufen 30.09.2026).

7. Stufenweise statt auf einen Schlag: der Phased Rollout

Der größte Fehler in einem Zscaler-Deployment ist selten eine falsche Konfiguration. Es ist der Versuch, alle Nutzer gleichzeitig umzustellen, bevor plattform- und infrastrukturspezifische Probleme überhaupt sichtbar werden konnten.

Zscalers eigene Empfehlung folgt vier Phasen:

In jeder Phase empfiehlt Zscaler ausdrücklich, so viele unterschiedliche Rechnerkonfigurationen wie möglich einzubeziehen, um Probleme auf verschiedenen Geräteabbildern und in verschiedenen Infrastrukturen zu entdecken und zu lösen, bevor die vollständige Verteilung beginnt. Wer stattdessen nur eine homogene Testgruppe wählt, etwa ausschließlich neue Notebooks mit einheitlichem Image, verschiebt die eigentlichen Probleme lediglich auf einen späteren, teureren Zeitpunkt.

Diese vier Phasen sind die feinkörnige Mechanik innerhalb eines größeren Projektrahmens. Auf Projektebene bleibt die Grundlogik gleich, unabhängig davon, ob ein Standort oder vierzig betroffen sind: Aufnahme des Bestands, Zielbild, ein einzelner, messbarer Pilot, danach die eigentlichen Wellen und zuletzt die Übergabe in den Betrieb, mit einem bewussten Entscheidungspunkt zwischen Pilot und Wellen. Die vier oben genannten Zscaler-Phasen laufen innerhalb der „Wellen"-Etappe dieses Rahmens ab, wenn die Entscheidung für den weiteren Rollout bereits gefallen ist.

Was das für Ihre Entscheidung heißt: Die konkrete Gruppengröße darf sich an der Reife Ihres Teams orientieren, nicht nur an der Zscaler-Vorlage. Eine Organisation mit eingespieltem Deployment-Team kann größere Wellen fahren; ein Team, das zum ersten Mal ein Zero-Trust-Deployment durchführt, ist mit kleineren Gruppen und mehr Zeit zwischen den Phasen besser bedient. Entscheidend ist weniger die exakte Zahl als das Prinzip dahinter: erst eine kleine, beherrschbare Gruppe, dann eine größere, dann der Rest, mit einer echten Prüfung nach jeder Stufe statt einer reinen Formsache.

Quelle: help.zscaler.com/zscaler-client-connector/best-practices-zscaler-client-connector-deployment, abgerufen 30.09.2026.

8. Nachweis statt Bauchgefühl: Messung mit ZDX

Eine Konfiguration, die auf dem Papier korrekt aussieht, ist kein Nachweis dafür, dass sie beim Nutzer auch so ankommt. Genau diese Lücke schließt Zscaler Digital Experience (ZDX).

Wie ZDX aufgebaut ist. Zscaler Client Connector, ohnehin bereits auf den Endgeräten installiert, liefert bei aktivierter ZDX-Funktion zusätzliche Gerätemetriken bei vernachlässigbarem zusätzlichem Ressourcenverbrauch. Diese Metriken laufen über ein sogenanntes Telemetry and Policy Gateway an die ZDX-Cloud, die sich zusätzlich mit ZIA und ZPA verbindet, um Nutzer, Abteilungen und Standorte aufzulösen. Die Auswertung selbst erfolgt über eine eigene ZDX-Administrationsoberfläche mit rollenbasierter Zugriffskontrolle und Single Sign-on.

Was ZDX misst. Neben frei definierbaren eigenen Anwendungen deckt ZDX eine Reihe vordefinierter Anwendungen bereits ab, darunter Zoom, Box, Salesforce, ServiceNow sowie mehrere Microsoft-365-Dienste wie Teams, SharePoint Online, OneDrive for Business und Outlook. Für die Auswertung von Anrufqualität, etwa bei Microsoft Teams oder Zoom, ist eine zusätzliche, kundenspezifische Einrichtung nötig, weil ZDX dafür auf die jeweilige Anbieter-Schnittstelle zugreifen muss.

Warum das in einen Rollout-Leitfaden gehört und nicht erst in den späteren Betrieb. ZDX beantwortet während der Rollout-Phasen aus Abschnitt 7 eine Frage, die sonst nur über Support-Tickets sichtbar wird: Ist eine gemeldete Verlangsamung tatsächlich auf die neue Konfiguration zurückzuführen, auf das WLAN am jeweiligen Standort, auf die Internetanbindung des Nutzers oder auf die Zielanwendung selbst? Wer diese Messung erst aktiviert, nachdem der Rollout bereits abgeschlossen ist, verzichtet auf genau die Daten, die während der kritischsten Phase am meisten wert gewesen wären.

Was das für Ihre Entscheidung heißt: ZDX lohnt sich am meisten, wenn die Aktivierung parallel zum eigentlichen Rollout erfolgt, nicht als nachgelagerter Schritt. Für Organisationen mit vielen Microsoft-365- oder Videokonferenz-Nutzern liefert allein die vordefinierte Abdeckung dieser Dienste bereits einen konkreten, messbaren Nutzen ohne größeren Konfigurationsaufwand.

Quelle: help.zscaler.com/zdx/understanding-zdx-cloud-architecture, abgerufen 30.09.2026.

9. Vom bestehenden Proxy zu Zscaler

Viele Organisationen kommen zu diesem Deployment nicht auf der grünen Wiese, sondern mit einer gewachsenen Proxy-Infrastruktur im Rücken, etwa einer klassischen Secure-Web-Gateway-Appliance. Technisch ändert sich dadurch wenig an der in den Abschnitten 1 bis 8 beschriebenen Architektur: Identität, Forwarding-Methoden, Client Connector und App Connector funktionieren unabhängig davon, was vorher im Einsatz war. Was neu hinzukommt, ist die Migration des bestehenden Regelwerks selbst.

Zscaler bietet für Organisationen, die von einer Legacy-Appliance umsteigen, eigenes Migrationsmaterial an und positioniert sich als cloudbasierte Alternative zu appliance-basierten Secure-Web-Gateway-Lösungen, etwa für Kunden, die von Symantec- beziehungsweise Blue-Coat-Produkten wechseln. Dieser Leitfaden übernimmt daraus bewusst keine wertenden Aussagen über den bisherigen Anbieter, sondern hält sich an die technische Substanz: Der bisherige Anbieter hat seine Berechtigung gehabt, und ein Wechsel ist zunächst einmal ein technisches Projekt wie jedes andere.

Drei praktische Empfehlungen für die Regelwerk-Migration, die sich unabhängig vom bisherigen Anbieter anwenden lassen:

1. Bestand vor Übernahme prüfen. Ein über Jahre gewachsenes Regelwerk enthält in aller Regel Einträge für Projekte, die es nicht mehr gibt, und Ausnahmen, deren ursprünglicher Grund niemand mehr kennt. Wer das unbesehen in die neue Umgebung überträgt, baut die alte Unordnung an neuer Stelle wieder auf, nur mit neuer Syntax.
2. Mit einer einfachen Grundregel beginnen, nicht mit der vollständigen Nachbildung. Wie in Abschnitt 3 beschrieben, hat sich in der Praxis bewährt, zunächst mit wenigen, klar verständlichen globalen Richtlinien zu starten und von dort aus gezielt nachzuschärfen, statt zu versuchen, jede Einzelregel des alten Systems von Anfang an eins zu eins nachzubilden.
3. Authentifizierung zuerst klären, dann Kategorien, dann Ausnahmen. Diese Reihenfolge folgt derselben Logik wie die Identitäts-zuerst-Regel aus Abschnitt 4: Eine funktionierende Anmeldung ist die Voraussetzung dafür, dass sich alles Weitere überhaupt sauber testen lässt.

Ein Sonderfall: die Identität selbst wechselt mit. Wenn der Wechsel des Proxys mit einem Wechsel oder einer Konsolidierung des Identity Providers zusammenfällt, gilt zusätzlich die Migrationsfähigkeit aus Abschnitt 4: Benutzer und Gruppen bleiben im Authentication Service erhalten, auch wenn der ursprüngliche Identity Provider später abgeschaltet wird.

Was das für Ihre Entscheidung heißt: Planen Sie die Migration des Regelwerks als eigenen Meilenstein mit eigener Zeitschätzung, getrennt von der reinen Infrastrukturumstellung. Die Erfahrung aus vergleichbaren Projekten zeigt durchgängig: Der Tunnel steht meist schneller, als das Regelwerk sauber überführt ist.

Quelle: zscaler.com/resources/solution-briefs/replace-symantec-with-a-cloud-based-solution.pdf (Positionierung Zscalers als Alternative zu appliance-basierten Secure-Web-Gateways, 2021, abgerufen 30.09.2026); Abschnitte 3 und 4 dieses Leitfadens für die übertragenen Prinzipien.

10. Häufige Stolperstellen

Aus den vorherigen Abschnitten lassen sich einige Punkte herausziehen, die in der Praxis regelmäßig Zeit kosten, wenn sie erst nach dem Auftreten behoben werden, statt vorab eingeplant zu sein:

• Identitäten, die zu spät stehen. Eine Regel, die auf eine Gruppe verweist, die im Authentication Service noch nicht existiert, greift ins Leere, ohne eine offensichtliche Fehlermeldung zu liefern.
• Authentifizierungsverkehr, der versehentlich inspiziert wird. Fehlt die SSL- und Authentifizierungs-Ausnahme für den Identity Provider, äußert sich das als sporadisches Anmeldeproblem, das sich nur schwer auf eine einzelne Ursache zurückführen lässt.
• Eine zu homogene Testgruppe. Wer die IT-Testphase ausschließlich mit einheitlichen, neuen Geräten durchführt, entdeckt Probleme mit älteren Betriebssystemversionen, ungewöhnlichen VPN-Kombinationen oder abweichenden Antivirus-Konfigurationen erst in der breiten Verteilung.
• Unterschätzte App-Connector-Redundanz. Ein einzelner, groß dimensionierter App Connector wirkt auf den ersten Blick effizient, konzentriert im Ausfall aber deutlich mehr Nutzersitzungen auf einen einzigen Fehlerpunkt als mehrere kleinere.
• Betriebssystempflege der App-Connector-Instanz vergessen. Weil Zscaler nur die App-Connector-Anwendung selbst pflegt, bleibt das Patching der zugrunde liegenden Instanz in AWS oder Azure eine eigene, oft übersehene Aufgabe.
• ZDX erst nach dem Rollout aktiviert. Damit fehlen ausgerechnet für die Phase mit den meisten Support-Anfragen belastbare Messdaten.
• Das alte Regelwerk unbesehen übernommen. Eine funktionierende Migration ist keine Kopie, sondern eine bewusste Entscheidung je Regel.

11. Nach dem Go-live: Betrieb

Mit dem letzten Rollout-Schritt endet die Projektarbeit, aber nicht die Aufgabe. Identität, Endgeräte, Standorte, private Anwendungen und Messung mit ZDX laufen jetzt im Alltag weiter, mit denselben Fragen, die vorher das Projekt geprägt haben: Ist eine gemeldete Störung wirklich Zscaler, oder liegt sie am WLAN? Sind die Richtlinien in ZIA und ZPA noch aktuell, oder haben sich seit dem Rollout Ausnahmen angesammelt, die niemand mehr zurückgenommen hat? Läuft jeder App Connector noch mit der erwarteten Kapazität?

Für genau diesen Alltag hat SourcingBlox CentaurNexus gebaut, ein eigenes Cockpit, das ZIA, ZPA und ZDX in einer Oberfläche zusammenführt. Wer nach dem Go-live weiterhin zwischen mehreren Zscaler-Konsolen wechseln muss, um eine einzige Nutzerfrage zu beantworten, verliert genau die Geschwindigkeit wieder, die ein sauberer Rollout eigentlich bringen sollte. CentaurNexus ist die optimale Ergänzung zu Ihrem Zscaler Security Stack: eine durchsuchbare Übersicht über Regeländerungen mit Vier-Augen-Freigabe, ein Werkzeug, das ungenutzte oder sich widersprechende Regeln aufspürt, eine Möglichkeit, einzelne Konfigurationsänderungen gezielt zurückzunehmen, und eine laufende Statusübersicht der eigenen App Connector. Gehostet in Deutschland, DSGVO-konform.

Dieser Abschnitt bleibt bewusst kurz. Wenn Sie mehr über den Betrieb nach dem Rollout erfahren möchten, unabhängig davon, ob mit oder ohne CentaurNexus, sprechen Sie uns an.

12. Checkliste

Vor dem Start

• Bestandsaufnahme der Endgeräte abgeschlossen: Betriebssystemversionen, Browser, VPN-Clients, Antivirus, Firewalls, Geräteverwaltung
• Identity Provider und Protokoll festgelegt (OIDC bevorzugt, SAML als Alternative)
• SCIM-Provisionierung statt Just-in-Time eingeplant
• SSL- und Authentifizierungs-Ausnahmen für den Identity Provider definiert
• Forwarding-Methode je Standort- und Nutzertyp festgelegt (GRE, IPSec, PAC-Datei, Client Connector, Cloud Connector, Branch Connector)
• Bei Umstieg von einem bestehenden Proxy: Regelwerk gesichtet, nicht unbesehen übernommen

Für die Endgeräte

• Verteilungsweg für Windows festgelegt (Intune, SCCM oder GPO über MSI)
• Verteilungsweg für macOS festgelegt (Jamf Pro oder Intune über PKG)
• Relevante der acht optionalen macOS-Konfigurationsprofile geprüft, insbesondere Festplattenzugriff für Endpoint-DLP
• Client Connector auf Firewall und Antivirus als vertrauenswürdiger Prozess hinterlegt

Für private Anwendungen

• Zielplattform je Anwendung geklärt (eigenes Rechenzentrum, AWS, Azure, weitere)
• ZPA-Lizenz (Professional, Business oder Transformation Edition) vorhanden
• App-Connector-Dimensionierung anhand der erwarteten Bandbreite berechnet, inklusive N+1-Redundanz
• Zuständigkeit für die Betriebssystempflege der App-Connector-Instanz geklärt

Für den Rollout

• Vier Phasen geplant: IT-Test, erweiterter IT-Test, Endnutzer-Pilotgruppe, verbleibende Nutzer in Wellen
• Testgruppe bewusst heterogen zusammengestellt, nicht nur einheitliche Geräte
• Entscheidungspunkt nach dem Pilot definiert: weiterrollen oder nachsteuern
• ZDX parallel zum Rollout aktiviert, nicht erst danach

Für den Betrieb danach

• Zuständigkeiten für Regelpflege, Ausnahmen und Zertifikatserneuerung benannt
• Erinnerung für die 90-Tage-Vorwarnung bei SAML-Zertifikaten eingerichtet
• Entscheidung getroffen, wie die tägliche Übersicht über ZIA, ZPA und ZDX organisiert wird

FAQ

Was ist der Unterschied zwischen GRE-Tunnel, IPSec-Tunnel und PAC-Datei? GRE und IPSec verbinden einen festen Standort mit dem Zscaler-Dienst auf Netzwerkebene. GRE braucht eine statische IP-Adresse und ein GRE-fähiges Gerät und verursacht dafür den geringsten Verarbeitungsaufwand. IPSec funktioniert auch ohne statische IP-Adresse, benötigt aber mehr Verarbeitungsleistung. Eine PAC-Datei wirkt dagegen im Browser des einzelnen Geräts und damit unabhängig vom Netzwerk, in dem sich der Nutzer gerade befindet.

Muss die Identitätsanbindung vor dem Rollout vollständig stehen? Ja, zumindest für den Teil der Organisation, der in der jeweiligen Phase ausgerollt wird. Jede Regel in ZIA und ZPA verweist auf Benutzer oder Gruppen aus dem angebundenen Identity Provider. Ohne stehende Identität lässt sich keine Regel sinnvoll testen.

Wie viele App Connector brauchen wir in AWS oder Azure? Das hängt von der benötigten Bandbreite und der gewünschten Redundanz ab. Ein App Connector mit Standardausstattung liefert rund 500 Mbit/s, mit mehr Ressourcen bis zu 1 Gbit/s. Für eine Anbindung mit 1 Gbit/s aggregierter Bandbreite empfiehlt Zscaler 2 bis 3 App Connector ohne doppelte Verschlüsselung beziehungsweise 4 bis 6 mit doppelter Verschlüsselung, jeweils zuzüglich mindestens eines weiteren für Redundanz.

Können wir von einem bestehenden Proxy, etwa einer Legacy-Appliance, direkt zu Zscaler wechseln? Ja. Die Architektur ändert sich dadurch nicht, unabhängig vom bisherigen Anbieter. Zusätzlich zur eigentlichen Infrastrukturumstellung kommt die Migration des bestehenden Regelwerks hinzu, für die sich eine bewusste Prüfung und ein schrittweiser Aufbau mit einer einfachen Grundregel bewährt haben.

Was ist der Unterschied bei der Client-Connector-Verteilung zwischen Windows und macOS? Windows nutzt eine MSI-Installationsdatei, die sich über Intune, SCCM oder GPO verteilen lässt, mit einer optionalen MST-Datei für zusätzliche Installationsoptionen. macOS nutzt eine PKG-Installationsdatei, verteilt über Jamf Pro oder Intune, mit bis zu acht optionalen Konfigurationsprofilen für Zertifikate, Verkehrsabfangung, Tunnel-Parameter und weitere Feinheiten.

Kostet Zscaler Client Connector eine eigene Lizenz? Nein. Die Nutzung von Zscaler Client Connector ist in der Lizenzierung von ZIA und ZPA bereits enthalten.

Wie lange dauert ein Zscaler-Deployment insgesamt? Das hängt stark von der Organisationsgröße, der Zahl der Standorte und dem Umfang der zu migrierenden Regeln ab, weshalb sich hier keine seriöse allgemeine Zahl nennen lässt. Der stufenweise Rollout selbst folgt den vier in diesem Leitfaden beschriebenen Phasen, deren Tempo Sie an die Reife Ihres eigenen Teams anpassen.

Was macht Zscaler Digital Experience (ZDX) während des Rollouts? ZDX misst, ob die Konfiguration beim Nutzer tatsächlich so ankommt wie geplant, über Gerätemetriken, Pfadmessung und Anwendungsmessung. Aktiviert parallel zum Rollout, hilft ZDX dabei, gemeldete Probleme schnell einer Ursache zuzuordnen, statt sie erst im Nachhinein zu untersuchen.

SourcingBlox als Ihr Zscaler-Partner

SourcingBlox ist offizieller Zscaler-Partner und betreut mehr als 100.000 Nutzer in Zscaler-Umgebungen. Dieser Leitfaden fasst zusammen, was in Zscalers eigener Dokumentation zu Architektur, Rollout und Migration öffentlich dokumentiert ist. Wenn Sie Ihr eigenes Deployment planen und dabei Unterstützung suchen, von der ersten Bestandsaufnahme bis zur Übergabe in den Betrieb, sprechen Sie uns an.

Zscaler, ZIA, ZPA, ZDX und Zscaler Client Connector sind Marken der Zscaler, Inc. Microsoft, Intune und Azure sind Marken der Microsoft Corporation. Jamf ist eine Marke der Jamf Software, LLC. Apple und macOS sind Marken der Apple Inc. Amazon Web Services und AWS sind Marken der Amazon.com, Inc. Symantec und Blue Coat sind Marken der Broadcom Inc. SourcingBlox steht in keiner Verbindung zu diesen Unternehmen und wird von ihnen weder unterstützt noch gesponsert. Alle Marken sind Eigentum ihrer jeweiligen Inhaber.