Was NSS- und LSS-Feeds in CentaurNexus ermöglichen

OneAPI und Log-Feeds beantworten unterschiedliche Fragen

Die offizielle Zscaler OneAPI bleibt die zentrale Schnittstelle für unterstützte Konfigurations- und Statusdaten sowie kontrollierte Reads und Writes. Log-Feeds ergänzen diesen aktuellen Zustand um tatsächlich beobachtete Zugriffe, Regelaktivität und Sitzungen. Erst zusammen entsteht der Kontext für viele historische und betriebliche Auswertungen.

Drei Feedtypen mit klaren Aufgaben

Wo daraus konkreter Produktnutzen entsteht

• Helpdesk und Endnutzer: User Support Center und Unified Support Center verbinden Sitzungsstatus, Connector-Kontext und geblockte Websites mit dem vorhandenen Nutzer-, Geräte- und Policy-Bild. Anfragen aus Browser und Self-Service erreichen den Helpdesk dadurch mit besserem Ausgangskontext.
• Security: Reports zeigen blockierte Zugriffe, zeitliche Verläufe, häufige Kategorien, Page-Risk-Verteilungen, Shadow-IT-, Geo- und weitere verfügbare Risikosignale.
• Administration und 2nd Level: Bandbreite lässt sich nach Anwendung, Standort, Nutzer und Zeit einordnen. Firewall-Regelaktivität unterstützt die Bewertung ungenutzter oder auffälliger Regeln.
• Management und MSP: Verdichtete Reports und mandantengebundene Auswertungen schaffen Vergleichbarkeit, ohne Kundenkontexte zu vermischen.

Änderungen mit realer Nutzung rückblickend einordnen

Für unterstützte Änderungs- und Freigabewege kann CentaurNexus vergangene Zugriffe innerhalb der verfügbaren Historie auswerten. Die Rückschau zeigt beispielsweise, wie häufig ein Ziel oder eine Kategorie vorkam, welche Entscheidungen tatsächlich getroffen wurden und wie viele Nutzer betroffen waren. Eine Änderungsvorschau stützt sich damit nicht nur auf den aktuellen Regelbestand, sondern auch auf beobachtete Nutzung.

Quelle, Datenalter und Coverage gehören zum Ergebnis

Ein Wert ohne Quellenzustand kann leicht falsch interpretiert werden. CentaurNexus führt deshalb Quelle, Status, Datenalter und Coverage mit. Feed-Lücken und veraltete Daten bleiben sichtbar. Ein fehlender Feed wird nicht als bestätigte Null dargestellt.

Frühes Onboarding schafft früher Vergleichsbasis

Historie beginnt mit der zuverlässigen Anbindung. Zugriffe und Sitzungen aus der Zeit davor können nicht nachträglich rekonstruiert werden. Einige Auswertungen liefern unmittelbar erste Ergebnisse; wiederkehrende Muster und Regelaktivität werden mit wachsender Historie aussagekräftiger.

Das gilt immer innerhalb der tatsächlich vereinbarten Retention. Zweckgebundene Produktprojektionen folgen ihren festgelegten Datenklassen. Zusätzliche oder abweichende NSS-/LSS-Retention wird nicht pauschal versprochen und muss für den konkreten Tenant und Betriebsumfang festgelegt werden.

NSS und LSS parallel in bestehende Datenwege einbinden

Wo die Zscaler-Bereitstellung es zulässt, versorgt ein eigener Feed CentaurNexus parallel zur bestehenden SIEM-Anbindung. CentaurNexus nutzt NSS und LSS für Nutzerkontext, Reporting, Regelbewertung und Änderungsrückschau.

Feedqualität ist mehr als „verbunden“

Eine grüne Verbindung sagt noch nicht, ob ein Feed vollständig und aktuell genug für die jeweilige Auswertung ist. Entscheidend sind der letzte Eingang, erwartete und beobachtete Ereignismengen, Parserstatus, Tenantzuordnung und die Coverage des betrachteten Zeitraums. CentaurNexus führt diese Merkmale mit dem Ergebnis, damit eine unvollständige Datenlage nicht wie ein vollständiger Befund wirkt.

Auch Formatänderungen müssen sichtbar behandelt werden. Wenn Felder fehlen oder ihre Bedeutung nicht mehr zum erwarteten Vertrag passt, darf die Plattform daraus keine scheinbar präzise Aussage ableiten. Der betroffene Teil der Auswertung erhält einen nachvollziehbaren Quellenstatus, während unabhängig verfügbare Funktionen weiterarbeiten können.

Ein Beispiel aus dem Helpdesk

Ein Nutzer meldet, dass eine interne Anwendung am Vormittag erreichbar war und später nicht mehr funktioniert. OneAPI kann den aktuellen Konfigurations- und Statuskontext liefern. ZPA LSS ergänzt die tatsächlich beobachteten Sitzungen und den verfügbaren Connector-Kontext. NSS Web oder NSS Firewall können weitere Hinweise beisteuern, wenn der Ablauf auch Web- oder Firewall-Pfade berührt.

Der Helpdesk sieht dadurch nicht nur eine Momentaufnahme. Er kann den Zeitpunkt des Problems mit vorhandener Historie einordnen und den Fall mit einem verständlichen Befund an den 2nd Level übergeben. Die Aussage bleibt dabei an die tatsächlich vorhandene Coverage gebunden.

Ein Beispiel aus Administration und Security

Bei der Bewertung einer älteren Firewall-Regel reicht ihr Name nicht aus. NSS Firewall kann zeigen, ob und wann sie innerhalb der verfügbaren Historie verwendet wurde, welche Services betroffen waren und ob erlaubte oder blockierte Sessions beobachtet wurden. Diese Informationen unterstützen eine menschliche Entscheidung über den nächsten Prüfschritt.

Security-Teams können zugleich Webzugriffe, Kategorien, Blockentscheidungen und vorhandene Risikosignale zeitlich verdichten. Der Bericht bleibt von einer Rohlog-Suche getrennt: Er beantwortet eine konkrete betriebliche Frage und nennt die verwendete Quelle.

Onboarding als Startpunkt der Datenkurve

Für jeden gewünschten Anwendungsfall sollte vorab feststehen, welcher Feed benötigt wird, welche Felder tatsächlich ankommen und wie lange die vereinbarte Historie verfügbar bleibt. Ein früher Start baut diese Vergleichsbasis früher auf. Er vergrößert aber nicht rückwirkend die Datenmenge vor dem Onboarding und ändert keine vertraglich festgelegte Retention.

Praktisch bedeutet das: Wer CentaurNexus früh anbindet, kann wiederkehrende Nutzung, saisonale Muster und Regelaktivität früher über einen längeren Zeitraum beurteilen. Genau deshalb gehört die Feedplanung an den Anfang des Onboardings und nicht erst an das Ende einer späteren Analyse.

Welche Fragen sich mit wachsender Historie besser beantworten lassen

Mit einer längeren, konsistenten Datenbasis werden Vergleiche belastbarer. Teams können prüfen, ob ein auffälliger Zugriff einmalig war, ob eine Anwendung regelmäßig zu bestimmten Zeiten genutzt wird oder ob eine Regel über mehrere Betriebszyklen hinweg keine beobachtete Aktivität zeigt. Die Historie liefert Kontext, aber keine automatische Entscheidung.

Für Management und MSPs entstehen daraus nachvollziehbare Trendberichte. Ein Vergleich darf nur Tenants, Zeiträume und Datenquellen gegenüberstellen, deren Coverage bekannt ist. Unterschiedliche Feedqualität wird nicht durch eine scheinbar einheitliche Kennzahl verdeckt.

Datensparsamkeit bleibt Teil des Produktvertrags

Dass ein Feed viele Felder liefern kann, bedeutet nicht, dass jede Rohinformation dauerhaft für jede Funktion gespeichert werden muss. CentaurNexus verwendet zweckgebundene Projektionen für die unterstützten Auswertungen. Datenklasse, Tenantzuordnung und vereinbarte Retention bestimmen den Lebenszyklus.

Diese Trennung erleichtert die fachliche Prüfung. Ein Kunde kann nachvollziehen, welche Auswertung welche Quelle benötigt und wie lange der dafür relevante Kontext verfügbar ist. Zusätzliche Anforderungen werden ausdrücklich vereinbart, statt stillschweigend aus einer technischen Feedmöglichkeit abgeleitet zu werden.