> ## 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.
# Oppsett av Zscaler ZIA Cloud NSS
> Send weblogger fra Zscaler Internet Access til Living Security via en Cloud NSS-feed.
Koble en Zscaler Internet Access (ZIA) Cloud Nanolog Streaming Service (NSS)-feed til Living Security for å sende weblogger. Dette er en push-integrasjon. Den er atskilt fra den pull-baserte integrasjonen [Zscaler Client Connector](/no/integrations/catalog/zscaler-client-connector-custom).
## Hva denne integrasjonen bidrar med
Webloggfeeden kan identifisere brukeren og enheten som er involvert i webaktivitet, og kan bidra med normalisert aktivitet, for eksempel blokkerte forespørsler, ondsinnede destinasjoner, blokkeringer av dataoverføring og bruk av generativ KI. Resultatet avhenger av feltene og filtrene som er konfigurert i Zscaler.
## Før du begynner
Du trenger:
* et ZIA Cloud NSS-abonnement og tillatelse til å administrere Cloud NSS-feeder
* tillatelse til å administrere integrasjoner og tilgangsnøkler i Living Security
* regionen for den aktuelle Living Security-organisasjonen
* et sikkert sted å lagre den genererte tilgangsnøkkelen
Zscaler krever et offentlig klarert TLS-sertifikat for en HTTPS-destinasjon i Cloud NSS. De regionale endepunktene til Living Security oppfyller dette kravet.
## 1. Forbered Living Security
Gå til **Innstillinger → Integrasjoner → Catalog**, legg til **Custom Push Source**, og bruk disse nøyaktige rutingnøklene:
| Felt | Verdi |
| - | - |
| Data Source Name | `zscaler-nss-feed` |
| Stream Name | `web_logs` |
Understrekingen i `web_logs` er påkrevd. Et annet par kan motta data, men vil ikke bruke den vedlikeholdte Zscaler NSS-tolkeren.
Gå til **Innstillinger → Access Keys**, opprett en tilgangsnøkkel med omfanget **Push Ingest**, og kopier verdien umiddelbart.
Bruk URL-en for Living Security-regionen:
* USA: `https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs`
* Den europeiske union: `https://api.eu-west-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs`
## 2. Opprett Cloud NSS-feeden
I den nåværende ZIA Admin Portal går du til **Logs → Log Streaming → Internet Log Streaming — Nanolog Streaming Service**, åpner **Cloud NSS Feeds** og velger **Add Cloud NSS Feed**. Menynavnene kan avvike i eldre versjoner av ZIA-portalen. Zscalers [instruksjoner for Cloud NSS-weblogger](https://help.zscaler.com/zia/adding-cloud-nss-feeds-web-logs) er autoritative for navigasjonen i portalen.
Konfigurer feeden:
| Zscaler-felt | Verdi |
| - | - |
| Feed Name | Et gjenkjennelig navn, for eksempel `Living Security web logs` |
| NSS Type | **NSS for Web** |
| Status | **Disabled** under konfigurering; aktiver etter verifisering |
| SIEM Rate | **Unlimited**, med mindre din egen policy krever en lavere rate |
| SIEM Type | **Other** |
| OAuth 2.0 Authentication | **Disabled** |
| Max Batch Size | **512 KB** |
| API URL | Den regionale Living Security-URL-en fra trinn 1 |
| HTTP Header 1 | `Authorization` = `Bearer ` |
| HTTP Header 2 | `Content-Type` = `application/json` |
| Log Type | **Web Log** |
| Feed Output Type | **JSON** |
| JSON Array Notation | **Enabled** |
| Feed Escape Character | `,\"` |
Ikke bruk `x-api-key`, og ikke kombiner en gammel API-nøkkel og hemmelighet med
et punktum. Gjeldende push-innhenting i Living Security godtar bare den
avgrensede tilgangsnøkkelen i `Authorization: Bearer …`-headeren.
Bruk dette nøyaktige, flate **Feed Output Format** på én linje:
```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}"}
```
Behold alle felt på toppnivå. Den utfasede Unify-veiledningen pakket disse
feltene inn i et `event`-objekt og la til `sourcetype`. Denne konvolutten kan godtas
som JSON, men samsvarer ikke med den gjeldende tolkeren, og gir derfor
ingen personer eller aktivitet.
Velg tidssonen som driftsteamet ditt forventer når det gjennomgår Zscaler-hendelser. Living Security tolker `datetime`-verdien som leveres av feeden.
## 3. Filtrer og aktiver feeden
Bruk Zscalers filtre **Policy Action** og **Policy Reason** for å sende webaktiviteten som trengs i programmet for menneskelig risiko. Unngå en lav innstilling for hendelser per sekund som kan føre til at logger forkastes under en trafikktopp. Hvis organisasjonen må begrense feeden, bør du overvåke både Zscaler-leveransen og Push History i Living Security mens du justerer den.
Lagre feeden, kjør Zscalers tilkoblingstest, og sett deretter **Status** til **Enabled**.
## 4. Verifiser levering og tolkning
1. Åpne **Innstillinger → Integrasjoner → tilkoblet → zscaler-nss-feed** i Living Security.
2. Under **Push History** bekrefter du at en nylig `web_logs`-kjøring viser forventet antall poster.
3. Bekreft at nylige Zscaler-brukere eller enhets-IP-er vises mot de forventede personene, og at webaktivitet er tilgjengelig i nedstrøms systemer.
4. Hvis kjøringen er akseptert, men ingen aktivitet vises, kontrollerer du den nøyaktige kilden, strømmen og det flate utdataformatet på nytt.
## Feilsøking
| Symptom | Kontroller |
| - | - |
| `401 Unauthorized` | Bruk `Authorization` med verdien `Bearer `; roter en utløpt eller tilbakekalt nøkkel |
| `403 Forbidden` | Opprett nøkkelen med omfanget **Push Ingest** |
| `404 Not Found` | Registrer `zscaler-nss-feed` og `web_logs`, og bruk deretter nøyaktig den URL-en |
| `400 Bad Request` | Aktiver JSON Array Notation og bekreft at utdataene er en matrise på toppnivå med flate objekter |
| `202` men ingen personer eller aktivitet | Fjern den eldre `sourcetype` / `event`-konvolutten og verifiser de nøyaktige rutingnøklene |
| `429` | Vent ut midlertidig struping på IP-nivå og respekter `Retry-After` når den er til stede |
| `503` | Behold batchen for nytt forsøk, vent på `Retry-After`, og send den på nytt uendret |
| Tilkoblingstesten mislykkes | Kontroller det regionale vertsnavnet, Bearer-headeren, nøkkelstatusen og policyen for offentlig TLS-inspeksjon |
API-et godtar maksimalt 10 000 poster og 10 MB per forespørsel, med 600 forespørsler per 60 sekunder per organisasjon. Se [Custom Push Source API](/no/integrations/custom-push-source) for fullstendig beskrivelse av svar og nye forsøk.
## Relatert
Gjennomgå autentisering, nyttelastgrenser, svar, nye forsøk og verifisering av kjøringer.
Koble til det separate Client Connector-API-et for enhets- og postureringsdata.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.