> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Einrichtung von Zscaler ZIA Cloud NSS

> Senden Sie Zscaler-Internet-Access-Weblogs über einen Cloud-NSS-Feed an Living Security.

Verbinden Sie einen Zscaler Internet Access (ZIA) Cloud Nanolog Streaming Service (NSS) Feed, um Weblogs an Living Security zu senden. Dies ist eine Push-Integration. Sie ist von der Pull-basierten Integration [Zscaler Client Connector](/de/integrations/catalog/zscaler-client-connector-custom) getrennt.

## Was diese Integration beiträgt

Der Weblog-Feed kann den Benutzer und das Gerät identifizieren, die an einer Webaktivität beteiligt sind, und kann normalisierte Aktivitäten wie blockierte Anfragen, schädliche Ziele, Blockierungen von Datenübertragungen und die Nutzung generativer KI beisteuern. Das Ergebnis hängt von den in Zscaler konfigurierten Feldern und Filtern ab.

## Vorbereitung

Sie benötigen:

* ein ZIA-Cloud-NSS-Abonnement und die Berechtigung zur Verwaltung von Cloud-NSS-Feeds
* die Berechtigung zur Verwaltung von Integrationen und Zugriffsschlüsseln in Living Security
* die Region der Ziel-Organisation in Living Security
* einen sicheren Ort zur Aufbewahrung des generierten Zugriffsschlüssels

Zscaler erfordert für ein HTTPS-Cloud-NSS-Ziel ein öffentlich vertrauenswürdiges TLS-Zertifikat. Die regionalen Endpunkte von Living Security erfüllen diese Anforderung.

## 1. Living Security vorbereiten

<Steps>
  <Step title="Quelle und Stream erstellen">
    Gehen Sie zu **Einstellungen → Integrationen → Catalog**, fügen Sie **Custom Push Source** hinzu und verwenden Sie diese exakten Routing-Schlüssel:

    | Feld | Wert |
    | - | - |
    | Data Source Name | `zscaler-nss-feed` |
    | Stream Name | `web_logs` |

    Der Unterstrich in `web_logs` ist erforderlich. Ein anderes Paar kann Daten akzeptieren, verwendet aber nicht den gepflegten Zscaler-NSS-Interpreter.
  </Step>

  <Step title="Zugriffsschlüssel erstellen">
    Gehen Sie zu **Einstellungen → Access Keys**, erstellen Sie einen Zugriffsschlüssel mit dem Geltungsbereich **Push Ingest** und kopieren Sie seinen Wert sofort.
  </Step>

  <Step title="Ziel-URL zusammenstellen">
    Verwenden Sie die URL für die Living-Security-Region:

    * USA: `https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs`
    * Europäische Union: `https://api.eu-west-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs`
  </Step>
</Steps>

## 2. Cloud-NSS-Feed erstellen

Gehen Sie im aktuellen ZIA Admin Portal zu **Logs → Log Streaming → Internet Log Streaming — Nanolog Streaming Service**, öffnen Sie **Cloud NSS Feeds** und wählen Sie **Add Cloud NSS Feed**. Die Menübezeichnungen können in älteren Versionen des ZIA-Portals abweichen; für die Navigation im Portal ist die [Cloud-NSS-Weblog-Anleitung](https://help.zscaler.com/zia/adding-cloud-nss-feeds-web-logs) von Zscaler maßgeblich.

Konfigurieren Sie den Feed:

| Zscaler-Feld | Wert |
| - | - |
| Feed Name | Ein aussagekräftiger Name, zum Beispiel `Living Security web logs` |
| NSS Type | **NSS for Web** |
| Status | **Disabled** während der Konfiguration; nach der Überprüfung aktivieren |
| SIEM Rate | **Unlimited**, sofern Ihre eigene Richtlinie keine niedrigere Rate erfordert |
| SIEM Type | **Other** |
| OAuth 2.0 Authentication | **Disabled** |
| Max Batch Size | **512 KB** |
| API URL | Die regionale Living-Security-URL aus Schritt 1 |
| HTTP Header 1 | `Authorization` = `Bearer <access-key>` |
| HTTP Header 2 | `Content-Type` = `application/json` |
| Log Type | **Web Log** |
| Feed Output Type | **JSON** |
| JSON Array Notation | **Enabled** |
| Feed Escape Character | `,\"` |

<Warning>
  Verwenden Sie nicht `x-api-key` und kombinieren Sie keinen alten API-Schlüssel und kein Secret
  mit einem Punkt. Der aktuelle Push-Ingest von Living Security akzeptiert den Zugriffsschlüssel mit Geltungsbereich ausschließlich
  im Header `Authorization: Bearer …`.
</Warning>

Verwenden Sie dieses exakte, flache **Feed Output Format** in einer Zeile:

```text theme={null}
{"datetime":"%d{yy}-%02d{mth}-%02d{dd} %02d{hh}:%02d{mm}:%02d{ss}","reason":"%s{reason}","event_id":"%d{recordid}","protocol":"%s{proto}","action":"%s{action}","transactionsize":"%d{totalsize}","responsesize":"%d{respsize}","requestsize":"%d{reqsize}","urlcategory":"%s{urlcat}","serverip":"%s{sip}","requestmethod":"%s{reqmethod}","refererURL":"%s{ereferer}","useragent":"%s{eua}","product":"NSS","location":"%s{elocation}","ClientIP":"%s{cip}","status":"%s{respcode}","user":"%s{elogin}","url":"%s{eurl}","vendor":"Zscaler","hostname":"%s{ehost}","clientpublicIP":"%s{cintip}","threatcategory":"%s{malwarecat}","threatname":"%s{threatname}","filetype":"%s{filetype}","appname":"%s{appname}","riskscore":"%d{riskscore}","department":"%s{edepartment}","urlsupercategory":"%s{urlsupercat}","appclass":"%s{appclass}","dlpengine":"%s{dlpeng}","urlclass":"%s{urlclass}","threatclass":"%s{malwareclass}","dlpdictionaries":"%s{dlpdict}","fileclass":"%s{fileclass}","bwthrottle":"%s{bwthrottle}","contenttype":"%s{contenttype}","unscannabletype":"%s{unscannabletype}","deviceowner":"%s{deviceowner}","devicehostname":"%s{devicehostname}","keyprotectiontype":"%s{keyprotectiontype}"}
```

<Warning>
  Behalten Sie jedes Feld auf der obersten Ebene bei. Die eingestellte Unify-Anleitung hat diese
  Felder in ein `event`-Objekt eingebettet und `sourcetype` hinzugefügt. Dieser Umschlag kann
  als JSON akzeptiert werden, entspricht aber nicht dem aktuellen Interpreter und erzeugt daher
  keine Personen oder Aktivitäten.
</Warning>

Wählen Sie die Zeitzone, die Ihr Betriebsteam bei der Prüfung von Zscaler-Ereignissen erwartet. Living Security verarbeitet den vom Feed gelieferten Wert `datetime`.

## 3. Feed filtern und aktivieren

Verwenden Sie die Filter **Policy Action** und **Policy Reason** von Zscaler, um die Webaktivitäten zu senden, die Ihr Human-Risk-Programm benötigt. Vermeiden Sie eine niedrige Einstellung für Ereignisse pro Sekunde, da dadurch bei einer Verkehrsspitze Logs verworfen werden könnten. Wenn Ihre Organisation den Feed begrenzen muss, überwachen Sie beim Feinabstimmen sowohl die Zscaler-Zustellung als auch den Push History in Living Security.

Speichern Sie den Feed, führen Sie den Konnektivitätstest von Zscaler aus und setzen Sie dann **Status** auf **Enabled**.

## 4. Zustellung und Interpretation überprüfen

1. Öffnen Sie in Living Security **Einstellungen → Integrationen → Verbunden → zscaler-nss-feed**.
2. Bestätigen Sie unter **Push History**, dass ein aktueller `web_logs`-Lauf die erwartete Datensatzanzahl anzeigt.
3. Bestätigen Sie, dass aktuelle Zscaler-Benutzer oder Geräte-IPs den erwarteten Personen zugeordnet sind und dass Webaktivitäten nachgelagert verfügbar sind.
4. Wenn der Lauf akzeptiert wird, aber keine Aktivität erscheint, überprüfen Sie erneut die exakte Quelle, den Stream und das flache Ausgabeformat.

## Fehlerbehebung

| Symptom | Prüfung |
| - | - |
| `401 Unauthorized` | Verwenden Sie `Authorization` mit dem Wert `Bearer <access-key>`; erneuern Sie einen abgelaufenen oder widerrufenen Schlüssel |
| `403 Forbidden` | Erstellen Sie den Schlüssel mit dem Geltungsbereich **Push Ingest** |
| `404 Not Found` | Registrieren Sie `zscaler-nss-feed` und `web_logs` und verwenden Sie dann exakt diese URL |
| `400 Bad Request` | Aktivieren Sie JSON Array Notation und bestätigen Sie, dass die Ausgabe ein Array flacher Objekte auf oberster Ebene ist |
| `202`, aber keine Personen oder Aktivitäten | Entfernen Sie den veralteten Umschlag `sourcetype` / `event` und überprüfen Sie die exakten Routing-Schlüssel |
| `429` | Warten Sie die vorübergehende Drosselung auf IP-Ebene ab und beachten Sie `Retry-After`, sofern vorhanden |
| `503` | Behalten Sie den Batch für einen erneuten Versuch, warten Sie auf `Retry-After` und senden Sie ihn unverändert erneut |
| Konnektivitätstest schlägt fehl | Prüfen Sie den regionalen Hostnamen, den Bearer-Header, den Schlüsselstatus und die Richtlinie zur öffentlichen TLS-Inspektion |

Die API akzeptiert höchstens 10,000 Datensätze und 10 MB pro Anfrage, bei 600 Anfragen pro 60 Sekunden je Organisation. Den vollständigen Vertrag zu Antworten und Wiederholungsversuchen finden Sie unter [Custom Push Source API](/de/integrations/custom-push-source).

## Weiterführende Informationen

<CardGroup cols={2}>
  <Card title="Custom Push Source API" icon="arrow-up-from-bracket" href="/de/integrations/custom-push-source">
    Hier finden Sie Informationen zu Authentifizierung, Payload-Limits, Antworten, Wiederholungsversuchen und Laufüberprüfung.
  </Card>

  <Card title="Zscaler Client Connector" icon="laptop" href="/de/integrations/catalog/zscaler-client-connector-custom">
    Verbinden Sie die separate Client Connector API für Geräte- und Posture-Daten.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.