Migration Intake
Ein bestehendes Regelwerk als Export oder direkt über die Schnittstelle des bisherigen Systems einlesen. Es wird nur gelesen, am Ursprung verändert sich nichts, und der eingelesene Bestand ist nach dem Vorgang wieder gelöscht.
Kaum ein Unternehmen führt Zscaler in ein leeres Haus ein. Es gibt ein Regelwerk mit eigener Geschichte und Standorte, die nicht alle gleich aussehen. CentaurNexus macht aus der Einführung einen Weg, der für jeden Standort gleich funktioniert: Mit vollen Administratorrechten sehen Sie vorher, wen eine neue Regel betrifft und welche Regel seit Monaten eine andere verdeckt, und jede einzelne Änderung lässt sich auch wieder zurücknehmen.
Die Werkzeuge des Herstellers können jeden einzelnen Schritt: einen Standort anbinden, eine Regel schreiben, einen Zugang freigeben. Was fehlt, ist die Klammer darüber: dieselbe Reihenfolge für jeden Standort, eine Probe vor dem Schalten, und der Umgang mit dem, was schon da ist. Denn kaum jemand fängt wirklich bei null an: Es gibt ein Regelwerk mit eigener Geschichte, Ausnahmen, die einmal einen Grund hatten, Standorte, die nicht alle gleich aufgebaut sind. Die folgenden Funktionen setzen an beiden Stellen an, in der Reihenfolge, in der Sie sie brauchen.
Ob aus einem anderen System oder aus einer weiteren Zscaler-Umgebung: Ein bestehendes Regelwerk lässt sich einlesen und Regel für Regel bewerten, bevor irgendetwas übertragen wird.
Ein bestehendes Regelwerk als Export oder direkt über die Schnittstelle des bisherigen Systems einlesen. Es wird nur gelesen, am Ursprung verändert sich nichts, und der eingelesene Bestand ist nach dem Vorgang wieder gelöscht.
Regel für Regel entscheiden: übernehmen, aussortieren oder zurückstellen. Was sich sicher übertragen lässt und was eine genauere Prüfung braucht, ist von Anfang an unterschieden.
Sobald das Ziel bereitsteht, folgt die Übertragung demselben Grundsatz wie der Rest der Einführung: in nachvollziehbaren Schritten, mit Sicherung davor und Beleg danach.
Die freigegebenen Regeln ziehen wellenweise um. Vor jeder Welle steht eine Sicherung, und bei der ersten Störung hält die Übertragung an, statt mit unklarem Ausgang weiterzulaufen.
Nach der Übertragung wird zurückgelesen, nicht nur gemeldet. Jede Regel zeigt, ob sie wirklich angekommen ist, nicht nur, ob der Schreibvorgang ohne Fehler durchlief.
Was übernommen wurde, was aussortiert wurde und warum, und wer wann freigegeben hat: als Beleg, der auch nach dem Vorgang noch Bestand hat.
Ab hier ist der Weg derselbe, ob ein Regelwerk mitkommt oder alles neu entsteht: Ein Onboarding beginnt nicht mit der ersten Regel, sondern mit einem Stand, auf den Sie zurückkönnen. Beides ist eine Handlung, kein Projekt.
Der Regelstand vor dem Eingriff, als Momentaufnahme festgehalten. Wenn eine Welle schiefgeht, diskutieren Sie nicht, wie es vorher aussah, Sie sehen es.
Standorte anlegen und pflegen, ohne dass jeder Eintrag von Hand in die Konsole des Herstellers wandert. Gleiche Standorte entstehen gleich.
Die Anbindung scheitert selten an der Technik. Sie scheitert daran, dass der zweite Standort anders gemacht wird als der erste.
Einen Standort anbinden, vom Tunnel bis zur Freigabe. Der Weg ist derselbe für Standort eins und Standort vierzig.
Privilegierte Zugänge ausrollen, für Administratoren und Dienstleister. Wer worauf zugreifen darf, steht fest, bevor der Zugang existiert.
Eine Regel, die im Test greift, kann im Wirkbetrieb jemanden aussperren, an den niemand gedacht hat. Volle Administratorrechte beantworten das nicht von allein: Beide Prüfungen unten laufen lesend, sie ändern nichts, und sie geben die Antwort, bevor die Regel scharf ist.
Für den privaten Anwendungszugriff: Nutzer, Gruppe und Ziel eingeben, und sehen, welche Regel greift. Vor dem Schalten, nicht danach im Ticket.
Dasselbe für das Regelwerk im Internetzugang: Welche Regeln widersprechen einander, welche verdecken sich seit Monaten gegenseitig, welche greifen nie.
Ein Onboarding, das in einem Zug durchläuft, hat keinen Punkt, an dem jemand widersprechen kann. Drei Funktionen bilden den Weg von der Planung bis zur Aktivierung.
Wellen planen: wer zuerst, wer danach, und woran Sie erkennen, dass eine Welle tragfähig war.
Die Änderungen einer Welle als Paket, das als Ganzes freigegeben und als Ganzes ausgeführt wird.
Der Moment des Schaltens, für Internetzugang und Zweigstellen-Anbindung an einer Stelle statt in getrennten Ansichten.
Der häufigste Befund nach einem Onboarding ist nicht ein Fehler, sondern eine stille Abweichung, die niemand gemeldet hat. Und wenn doch etwas nicht passt, muss nicht die ganze Welle zurück.
Der Zustand von heute gegen den Zustand nach der Welle. Was abweicht, steht mit Namen da, nicht als Zahl in einem Balken.
Eine einzelne Änderung für sich zurückdrehen, auch wenn sie direkt in Zscaler vorgenommen wurde. Der Rest der Konfiguration bleibt unberührt.
CentaurNexus setzt eine vorhandene Zscaler-Umgebung voraus und baut darauf auf, auch beim Übernehmen eines bestehenden Regelwerks. Die Funktionen oben nehmen Ihnen die Wiederholung ab und machen den Zustand sichtbar. Die Entscheidung, welche Regel übernommen wird, welcher Standort wann umzieht und welche Regel gelten soll, bleibt bei Ihnen.
Der Weg von Migration Intake bis Migration Report gehört zum Paket Enterprise und lässt sich außerdem als eigenständiges Paket namens Migration & Onboarding buchen, für alle, die genau das brauchen und sonst nichts. Das ist keine höhere Stufe von Light, Starter oder Advance, sondern ein eigenes, schmales Paket genau für diesen Zweck. Welche Variante zu Ihrem Vorhaben passt, klären Sie über unsere Angebotsseite.
Alles oben nutzen Sie mit Ihrem eigenen Team, Schritt für Schritt, Standort für Standort. Wenn Sie die Einführung lieber übergeben, Analyse, Planung und Durchführung inklusive: SourcingBlox übernimmt das als offizieller Zscaler-Partner, mit CentaurNexus als demselben Werkzeug im Hintergrund.
In einem Gespräch von 45 Minuten gehen wir Ihren konkreten Fall durch: was Sie mitbringen, was neu aufgebaut wird und was davon in Ihrer Hand bleibt.