Mehr als ZIA, ZPA und ZDX: Zscaler-Betrieb über OneAPI

OneAPI ist die gemeinsame Zugriffsschicht

Zscaler beschreibt OneAPI als zentralen Zugang zu unterstützten APIs. API-Clients erhalten Scopes und Rollen. CentaurNexus baut darauf auf und ergänzt eine mandantenfähige Bedien-, Governance- und Integrationsschicht. Zscaler bleibt Kernanbieter und Quelle der Zielsystemdaten.

Domänen statt isolierter Portale betrachten

Je nach Tenant und unterstütztem Ablauf kann der Betrieb neben ZIA, ZPA und ZDX weitere Kontexte einbeziehen, darunter ZCC, ZTW, ZIdentity, EASM, Z-Insights, ZMS und weitere über die dokumentierte Schnittstelle erreichbare Domänen. Die Plattform klont diese Portale nicht.

Coverage muss sichtbar bleiben

Eine lange Domänenliste ist kein Beleg für vollständige Funktionsabdeckung. Jeder unterstützte Read zeigt Quelle, Status, Datenalter und Coverage. Eine nicht verfügbare Domäne führt zu einem abhängigen oder nicht entschiedenen Umfang, nicht automatisch zur Entfernung anderer Funktionen.

Ein Arbeitskontext für mehrere Rollen

Endnutzer, Helpdesk, Administratoren, Security, MSP, Management und Plattformbetrieb benötigen unterschiedliche Ausschnitte. CentaurNexus führt sie in rollenbezogenen Arbeitswegen zusammen. Breite Vendor-Adminrechte werden nicht zum Standardzugang für jeden Bearbeiter.

API-Client, Ressource und Scope gehören zusammen

OneAPI verwendet API-Clients und zugeordnete Ressourcen. Der Client erhält nur die Scopes, die für die verbundenen Zscaler-Dienste eingerichtet wurden. Damit ist nicht jede technisch erreichbare Schnittstelle automatisch für jeden Tenant oder jede Rolle verfügbar.

CentaurNexus übernimmt diesen Vertrag in das Onboarding. Für jeden unterstützten Arbeitsweg wird festgelegt, welche Ressource gelesen oder verändert werden muss, welche Rolle benötigt wird und wie der Zustand später per Read-back geprüft werden kann. Zu breite Scopes sind kein Ersatz für eine saubere Zuordnung.

ZIA, ZPA und ZDX bleiben wichtige, aber nicht einzige Kontexte

ZIA liefert unter anderem Internet-, SaaS-, URL-, Firewall- und DLP-bezogene Arbeitskontexte. ZPA betrifft private Anwendungen, Segmente, Connectoren, Zugriffe und PRA-nahe Abläufe. ZDX liefert digitale Erfahrungssignale zu Gerät, Anwendung und Netzwerkpfad. Diese drei Bereiche prägen viele tägliche Support- und Administrationsfälle.

Darüber hinaus können ZCC, ZTW, ZIdentity, EASM, Z-Insights und ZMS weitere Bausteine beitragen. Welche Funktionen daraus in einem Tenant verfügbar sind, hängt von Lizenz, Serviceverknüpfung, API-Rolle, technischer Quelle und dem unterstützten CentaurNexus-Ablauf ab.

Der Helpdesk braucht einen Nutzerkontext, keine Portalsammlung

Ein Supportfall kann gleichzeitig Gerät, Client Connector, Webzugriff, private Anwendung und digitale Erfahrung betreffen. Der Helpdesk sollte diese Informationen nicht in mehreren Konsolen manuell zusammensuchen. User Support Center und Unified Support Center führen den rollenbezogen erlaubten Kontext zusammen.

Rund 70 Datenpunkte im Nutzerkontext bedeuten dabei nicht, dass jeder Wert für jeden Tenant garantiert verfügbar ist. Quelle, Aktualität und Coverage zeigen, welche Bestandteile tatsächlich vorliegen. Der Bearbeiter erhält einen zusammenhängenden Befund und kann fehlende Bereiche erkennen.

Administratoren benötigen Regeln und ihre Abhängigkeiten

Für Administration und 2nd Level reicht eine reine Objektliste nicht. Regeln enthalten Includes, Excludes, Reihenfolge, Gruppen, Tunnel, Freigaben und weitere Beziehungen. CentaurNexus stellt diese Zusammenhänge für unterstützte Abläufe in einem gemeinsamen Arbeitskontext dar.

Schreibende Änderungen bleiben kontrollierte Einzeländerungen. Ein Write ist erst nach tatsächlicher Zielsystemwirkung und Read-back erfolgreich. Die Plattform verbindet damit die gemeinsame Bedienoberfläche mit der Autorität des Zscaler-Zielsystems.

Security, MSP und Management sehen andere Ausschnitte

Security benötigt Reports, URL-Bewertungen, Freigabestatus und sichtbare Datenquellen. MSPs brauchen einen klaren Kunden- und Tenantkontext für wiederholbare Abläufe. Management benötigt verdichtete Trends, Zuständigkeiten und Coverage, ohne operative Detailrechte zu erhalten.

Die gemeinsame Plattform bedeutet deshalb nicht eine identische Oberfläche für alle. Rollenpfade nutzen denselben zugrunde liegenden Vorgang, zeigen aber nur die Informationen und Aktionen, die für ihre Aufgabe vorgesehen sind.

OneAPI und Feedquellen ergänzen sich

OneAPI beantwortet vor allem Fragen zum aktuellen Konfigurations- und Statuszustand. NSS- und LSS-Feeds ergänzen beobachtete Zugriffe, Sitzungen und Regelaktivität über die verfügbare Zeit. Viele aussagekräftige Auswertungen benötigen beide Ebenen.

Eine Quelle wird nicht durch eine andere ersetzt. CentaurNexus kennzeichnet, welche Aussage aus OneAPI stammt, welche auf Feedhistorie beruht und wo eine Quelle fehlt. Das verhindert, dass ein nicht vorhandenes Signal als bestätigte Null interpretiert wird.

Onboarding mit einer Coverage-Matrix

Die Coverage-Matrix macht aus einer abstrakten Domänenliste einen überprüfbaren Betriebsvertrag. Sie zeigt, welcher Arbeitsweg auf welcher Quelle basiert und welche Tenantvoraussetzung erfüllt sein muss.

Die Multi-Vendor-Vertragsnaht bleibt vorbereitet

Die 1.0-Verträge trennen fachlichen Vorgang, Provideradapter und bestätigten Zielzustand. Dadurch kann eine weitere Providerquelle später über einen eigenen, belegten Vertrag angebunden werden, ohne OneAPI oder Zscaler-Fachlogik umzudeuten.

Welche zweite Providerintegration konkret folgt, ist nicht entschieden. Die vorbereitete Naht ist deshalb kein Claim für eine heute benannte Fremdplattform. Zscaler bleibt Kernanbieter des beschriebenen Produktzustands.

Coverage im laufenden Betrieb pflegen

Tenantlizenzen, Scopes und verknüpfte Dienste können sich ändern. Eine einmal erstellte Matrix ist daher kein statisches Onboardingdokument. CentaurNexus überwacht Quellenstatus und macht sichtbar, wenn ein zuvor verfügbarer Bereich eingeschränkt oder eine neue Domäne nutzbar wird.

Änderungen an der Coverage werden mit den betroffenen Rollenpfaden geprüft. Ein fehlender Scope darf nicht unbemerkt leere Ergebnisse erzeugen. Gleichzeitig bleibt ein unabhängiger, funktionierender Arbeitsweg verfügbar, wenn seine Quelle weiterhin gültig ist.

Plattformbetrieb als eigene Persona

Der Plattformbetrieb überwacht nicht die fachliche Entscheidung jedes Kunden. Er stellt sicher, dass Adapter, Quellenverträge, Tenant-Isolation und technische Zustände zuverlässig arbeiten. Dafür benötigt er Health-, Fehler- und Versionsinformationen, aber keinen pauschalen Zugriff auf alle fachlichen Kundendaten.

Diese Trennung ist besonders im MSP- und Regionalbetrieb wichtig. Technische Wartung bleibt möglich, während Kundenverantwortung und tenantgebundene Entscheidungen bei den dafür vorgesehenen Rollen liegen.

Ein Arbeitskontext für Zscaler-Domänen

Zscaler bleibt Kernanbieter und Zielsystem. CentaurNexus verbindet unterstützte Abläufe, Rollen, Freigaben, Audit, ITSM und Read-back zu einem täglichen Arbeitskontext.

Das Single Pane of Glass vereinheitlicht unterstützte Zscaler-Arbeitsabläufe. Die verbundenen Dienste bleiben dabei maßgebliche Quelle und Zielsystem.