Identitäten zuerst
Benutzer und Gruppen aus ZIdentity stehen, bevor die erste Regel in ZIA oder ZPA sie referenziert. Sonst sucht später jemand stundenlang nach einem Tippfehler, den es nie gab.
Zscaler Deployment und Migration
Sie ziehen nicht ein Produkt um, sondern eine Infrastruktur.
Internetverkehr, interne Anwendungen, Identitäten, Endgeräte und die Messung beim Nutzer hängen zusammen, und die Reihenfolge ist nicht beliebig. Wir kennen die Abhängigkeiten über die ganze Zscaler-Plattform, weil wir sie täglich betreiben. Dabei arbeiten wir mit CentaurNexus, unserem eigenen Cockpit, das alle diese Dienste an einer Stelle zeigt.
Ein Standort
Mehrere Standorte
Mit oder ohne eigenes Security-Team
Umstieg vom Altsystem
Das Gesamtbild
Die Reihenfolge ist nicht beliebig.
Daran scheitern Umstiege, nicht an einer einzelnen Regel. Eine ZPA-Regel, die auf eine Gruppe zeigt, die es in ZIdentity noch nicht gibt, greift ins Leere. Ein Regelwerk in ZIA sieht keinen Verkehr, solange die Weiterleitung nicht entschieden ist. Und ob der Umstieg beim Nutzer angekommen ist, zeigt erst ZDX.
Client vor Regelwerk
Der Zscaler Client Connector muss auf dem Gerät sein, sonst läuft der Verkehr eines mobilen Nutzers am Regelwerk vorbei, ohne dass es auffällt.
Anbindung vor Anwendung
Der App Connector läuft, bevor die erste interne Anwendung über ZPA erreichbar sein soll. Für Standorte gilt dasselbe mit dem Weg in ZIA.
Der Anfang
Zuerst schauen wir, was Ihr heutiges Regelwerk noch wert ist.
Fast niemand fängt bei null an. Ein Regelwerk, das über Jahre gewachsen ist, enthält Regeln für Projekte, die es nicht mehr gibt. Wer das unbesehen mitnimmt, baut die alte Unordnung in Zscaler neu auf.
Gemeinsam an Ihrem Bestand
Die erste Sichtung machen wir zusammen mit Ihnen, an Ihrem Bildschirm oder mit einem Export aus Ihrem heutigen System. Zugangsdaten brauchen wir dafür nicht, und CentaurNexus liest den Bestand ein, ohne beim Ziel etwas zu verändern.
Regel für Regel, nicht pauschal
Sie bekommen eine Liste: Das kommt mit, das kann zusammengelegt werden, das kann weg, darüber müssen Sie entscheiden. Mit Begründung.
Und die Zuordnung gleich dazu
Was gehört künftig in ZIA, was in ZPA, was löst sich in einer Identitätsregel auf? Diese Zuordnung entscheidet über den Aufwand, nicht die Zahl der Regeln.
Für wen das passt
Ob ein Standort oder vierzig, der Unterschied liegt woanders.
Große Umgebungen gewinnen durch Wiederholbarkeit. Kleinere gewinnen dadurch, dass sie niemanden einstellen müssen, der fünf Zscaler-Dienste und ihre Abhängigkeiten im Detail kennt.
Ein oder zwei Standorte
Die Plattform ist dieselbe, ob Sie fünfzig oder fünftausend Nutzer haben. Sie brauchen dafür keinen eigenen Spezialisten: Wir bringen das Wissen und das Werkzeug mit und bleiben danach ansprechbar.
Viele Standorte
Der erste Standort wird zur Vorlage, jeder weitere folgt ihm. Was einmal festgelegt ist, gilt für alle, und Abweichungen tragen eine Begründung.
Vorgehen
Fünf Etappen, und nach dem Pilot entscheiden Sie.
Das Gesamtbild von oben wird hier zum Ablauf. Die Gruppen planen wir im Rollout Planner, die Änderungen jeder Gruppe bündelt der Change Package Builder zu einem Paket, das als Ganzes freigegeben wird. Vor der Fläche steht ein Halt, an dem Sie weitermachen oder nachbessern.
Der Umzug
Ihre Regeln ziehen um, aber keine ungeprüft.
Internetverkehr und interne Anwendungen sind zwei verschiedene Baustellen mit zwei verschiedenen Prüfungen. Wir behandeln sie getrennt und schalten sie in getrennten Gruppen.
ZIA: Web- und Firewall-Regelwerk
Bevor eine Regel scharf wird, zeigt Policy Conflict Review, welche Regeln einander widersprechen und welche nie greifen. Rule Set Backup hält den Stand davor.
ZPA: interne Anwendungen ohne VPN
Policy What If beantwortet vorher, welche Regel bei welchem Nutzer und welcher Anwendung zieht. PRA Deploy rollt privilegierte Zugänge für Administratoren und Dienstleister aus.
Endgeräte
Der Client kommt auf die Geräte, ohne dass Ihre Nutzer etwas tun müssen.
Der Zscaler Client Connector (ZCC) ist die Voraussetzung dafür, dass ZIA und ZPA für mobile Nutzer überhaupt wirken. Wir arbeiten in Ihrer Geräteverwaltung mit: Pakete bauen, zuweisen, und hinterher zeigen, dass alles angekommen ist.
Windows über Intune
Paket, Zuweisung, Reihenfolge und der Nachweis, dass es ankam. Auch für die Geräte, die sich wochenlang nicht melden.
macOS über Jamf
Andere Verwaltung, andere Freigaben, gleicher Anspruch: Der Nutzer merkt nichts, und das Ergebnis ist belegbar.
Geräte ohne Verwaltung
Die gibt es in jedem Haus. Wir nehmen sie früh auf und klären, ob sie über den Standort laufen oder bewusst draußen bleiben.
Nachweis
Ob es angekommen ist, sagt Ihnen nicht das Protokoll, sondern der Nutzer.
Nach jeder Gruppe steht die Frage, ob die Anwendung noch so schnell ist wie vorher. Zscaler Digital Experience (ZDX) misst das vom Gerät aus, und Configuration Drift Review zeigt daneben, was sich seit der Umstellung an der Konfiguration verschoben hat.
Messung statt Rückmeldungen
Ein Ticket nach drei Wochen ist kein Messwert. ZDX zeigt je Nutzergruppe und Anwendung, wie es sich vor und nach der Umstellung verhält.
Abweichungen mit Namen
Configuration Drift Review stellt den heutigen Stand dem Stand nach der Umstellung gegenüber. Was abweicht, steht mit Namen da, nicht als Zahl in einem Balken.
Unser Werkzeug
Ein Cockpit über alle Dienste, statt fünf getrennter Ansichten.
Genau hier liegt der Unterschied. Wer ZIA, ZPA, ZCC, ZIdentity und ZDX in getrennten Ansichten bearbeitet, sieht die Abhängigkeit zwischen ihnen nicht. CentaurNexus haben wir gebaut, weil uns das im Alltag selbst gestört hat. Wir setzen es in Ihrem Projekt ein, und Sie können es danach behalten.
Vor der Welle
Policy What If für ZPA, Policy Conflict Review für ZIA. Beide lesend, beide vor der Umstellung, beide in derselben Oberfläche.
In der Welle
Rollout Planner schneidet die Gruppen, Change Package Builder bündelt die Änderungen zu einem Paket, Migration Apply schreibt das alte Regelwerk wellenweise nach Zscaler, Unified Deploy aktiviert ZIA und Standortanbindung an einer Stelle.
Nach der Welle
Migration Verify liest zurück, ob jede Regel wirklich angekommen ist, Configuration Drift Review zeigt die Konfiguration, ZDX die Nutzersicht. Drei Blickwinkel auf dieselbe Frage.
Aus dem Betrieb
Was wir im Betrieb gelernt haben, steckt schon im Plan.
Wir betreiben Zscaler-Umgebungen auch nach dem Projekt. Diese vier Dinge machen später Arbeit, deshalb erledigen wir sie vorher.
Die Gruppen stehen vor der ersten Regel
Sonst greift die erste Regel ins Leere, und niemand versteht warum.
Jede Ausnahme bekommt eine Frist
Und einen Namen dazu. Sonst stehen in zwei Jahren Ausnahmen da, die niemand mehr anzufassen traut.
Der Rückweg wird einmal geprobt
Bevor die erste Gruppe live geht. Ein Rückweg, den niemand ausprobiert hat, ist nur eine Annahme.
Die Übergabe dauert länger als einen Termin
Betrieb und Projekt arbeiten eine Weile zusammen. In einer Präsentation geht Wissen nicht über.
Arbeitsergebnis
Am Ende hat Ihr Team alles, um allein weiterzumachen.
Wir schneiden die Ergebnisse bewusst so zu, dass Sie nicht auf uns angewiesen sind.
Liste Ihrer heutigen Regeln, je Regel mit Zuordnung zu ZIA oder ZPA
Abhängigkeitsplan über Identitäten, Client, Anbindung und Regelwerk
Verteilungspakete für Ihre Geräteverwaltung
Abnahmekriterien je Gruppe, vorab festgelegt
Geprobter Rückweg und gesicherter Stand davor
Runbooks und benannte Zuständigkeiten
Zusammenarbeit
Über 100.000 Nutzer betreuen wir als offizieller Zscaler-Partner, auch lange nach dem Projekt.
Deployment, Rollout und Migration sind für uns Tagesgeschäft. Wir übernehmen Analyse, Umstieg und Betrieb aus einer Hand, über die ganze Plattform hinweg. Nach dem Umstieg können Sie uns ziehen lassen oder den Betrieb übergeben. Gerade wenn Sie kein eigenes Security-Team haben, ist das der Unterschied zwischen einem Projekt und einer Lösung.
Was wir als Ihr Zscaler-Partner übernehmen
Von der Analyse Ihres heutigen Regelwerks über Zielbild und Pilot bis zur letzten Gruppe im Rollout. Sie behalten die Entscheidung, wir die Umsetzung.
Wie ein Deployment bei uns abläuft
Aufnahme, Zielbild, Pilot, Gruppen, Übergabe: dieselbe Reihenfolge für einen Standort wie für vierzig, mit einem Halt nach dem Pilot.
Was nach dem Rollout bleibt
Runbooks, benannte Zuständigkeiten und, wenn gewünscht, der laufende Betrieb. Sie sind nicht auf uns angewiesen, können aber auf uns zählen.
Von Experten für Profis
CentaurNexus entdecken
CentaurNexus, unser souveränes Cockpit für Ihre Zscaler-Welt.
Aus unserer eigenen Projekterfahrung als Zscaler-Partner entstanden: CentaurNexus bündelt ZIA, ZPA und ZDX in einer Oberfläche. Eine Suche, ein Blick, Hosting in Deutschland. Im Projekt setzen wir es selbst ein, und Sie können es danach weiterbetreiben.
Ein Blick über ZIA, ZPA und ZDX, ohne Zscaler-Admin-Rechte
Vier-Augen-Freigaben, Rollback und volle Audit-Trails
Hosting in Deutschland, DSGVO-konform
Ein Termin, und Sie wissen, woran Sie sind.
Termin auswählen
Termin
Onboarding und Migration – 45 Minuten
Wir klären, welche Dienste bei Ihnen im Spiel sind, was Sie heute einsetzen und wie der erste Schritt aussieht.