> ## 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. # Konfigurera Zscaler ZIA Cloud NSS > Skicka webbloggar från Zscaler Internet Access till Living Security via ett Cloud NSS-flöde. Anslut ett Cloud Nanolog Streaming Service (NSS)-flöde i Zscaler Internet Access (ZIA) för att skicka webbloggar till Living Security. Det här är en push-integration. Den är separat från den pull-baserade integrationen [Zscaler Client Connector](/sv/integrations/catalog/zscaler-client-connector-custom). ## Vad den här integrationen bidrar med Webbloggflödet kan identifiera vilken användare och vilken enhet som är inblandade i webbaktivitet, och kan bidra med normaliserad aktivitet, till exempel blockerade förfrågningar, skadliga destinationer, blockerade dataöverföringar och användning av generativ AI. Resultatet beror på vilka fält och filter som har konfigurerats i Zscaler. ## Innan du börjar Du behöver: * en ZIA Cloud NSS-prenumeration och behörighet att hantera Cloud NSS-flöden * behörighet att hantera integrationer och åtkomstnycklar i Living Security * regionen för den aktuella Living Security-organisationen * en säker plats där du kan lagra den genererade åtkomstnyckeln Zscaler kräver ett offentligt betrott TLS-certifikat för en HTTPS-destination i Cloud NSS. Living Securitys regionala slutpunkter uppfyller det kravet. ## 1. Förbered Living Security Gå till **Inställningar → Integrationer → Katalog**, lägg till **Custom Push Source** och använd exakt dessa routningsnycklar: | Fält | Värde | | - | - | | Data Source Name | `zscaler-nss-feed` | | Stream Name | `web_logs` | Understrecket i `web_logs` är obligatoriskt. Ett annat par kan ta emot data men använder inte den underhållna Zscaler NSS-tolken. Gå till **Inställningar → Access Keys**, skapa en åtkomstnyckel med behörighetsomfånget **Push Ingest** och kopiera dess värde direkt. Använd URL:en för din Living Security-region: * USA: `https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs` * Europeiska unionen: `https://api.eu-west-1.livingsecurity.ai/api/v1/push-ingest/zscaler-nss-feed/web_logs` ## 2. Skapa Cloud NSS-flödet I den aktuella ZIA Admin Portal går du till **Logs → Log Streaming → Internet Log Streaming — Nanolog Streaming Service**, öppnar **Cloud NSS Feeds** och väljer **Add Cloud NSS Feed**. Menyetiketterna kan skilja sig i äldre versioner av ZIA-portalen. Zscalers [instruktioner för Cloud NSS-webbloggar](https://help.zscaler.com/zia/adding-cloud-nss-feeds-web-logs) är vägledande för navigeringen i portalen. Konfigurera flödet: | Zscaler-fält | Värde | | - | - | | Feed Name | Ett igenkännbart namn, till exempel `Living Security web logs` | | NSS Type | **NSS for Web** | | Status | **Disabled** under konfigurationen; aktivera efter verifiering | | SIEM Rate | **Unlimited**, om inte din egen policy kräver en lägre nivå | | SIEM Type | **Other** | | OAuth 2.0 Authentication | **Disabled** | | Max Batch Size | **512 KB** | | API URL | Den regionala Living Security-URL:en från steg 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 | `,\"` | Använd inte `x-api-key` och kombinera inte en gammal API-nyckel och hemlighet med en punkt. Den aktuella push-inmatningen i Living Security accepterar endast den omfångsbegränsade åtkomstnyckeln i rubriken `Authorization: Bearer …`. Använd exakt detta platta **Feed Output Format** på en enda rad: ```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}"} ``` Behåll alla fält på översta nivån. Den indragna Unify-guiden lade in dessa fält i ett `event`-objekt och lade till `sourcetype`. Det omslaget kan accepteras som JSON men matchar inte den aktuella tolken, så det ger inga personer eller någon aktivitet. Välj den tidszon som ditt driftteam förväntar sig när Zscaler-händelser granskas. Living Security tolkar värdet `datetime` som flödet tillhandahåller. ## 3. Filtrera och aktivera flödet Använd Zscalers filter **Policy Action** och **Policy Reason** för att skicka den webbaktivitet som behövs för ditt program för mänsklig risk. Undvik en låg inställning för händelser per sekund som kan göra att loggar förkastas vid trafiktoppar. Om din organisation måste begränsa flödet bör du övervaka både leveransen från Zscaler och Push History i Living Security medan du justerar inställningen. Spara flödet, kör Zscalers anslutningstest och ställ sedan in **Status** på **Enabled**. ## 4. Verifiera leverans och tolkning 1. Öppna **Inställningar → Integrationer → ansluten → zscaler-nss-feed** i Living Security. 2. I **Push History** bekräftar du att en nyligen genomförd körning av `web_logs` visar förväntat antal poster. 3. Bekräfta att nyligen förekommande Zscaler-användare eller enhets-IP-adresser visas för de förväntade personerna och att webbaktiviteten är tillgänglig i efterföljande led. 4. Om körningen har accepterats men ingen aktivitet visas, kontrollera på nytt exakt källa, ström och det platta utdataformatet. ## Felsökning | Symptom | Kontrollera | | - | - | | `401 Unauthorized` | Använd `Authorization` med värdet `Bearer `; rotera en nyckel som har gått ut eller återkallats | | `403 Forbidden` | Skapa nyckeln med behörighetsomfånget **Push Ingest** | | `404 Not Found` | Registrera `zscaler-nss-feed` och `web_logs` och använd sedan exakt den URL:en | | `400 Bad Request` | Aktivera JSON Array Notation och bekräfta att utdata är en matris på översta nivån med platta objekt | | `202` men inga personer eller någon aktivitet | Ta bort det äldre omslaget `sourcetype` / `event` och verifiera de exakta routningsnycklarna | | `429` | Vänta ut den tillfälliga begränsningen på IP-nivå och följ `Retry-After` när den finns | | `503` | Behåll batchen för nytt försök, vänta på `Retry-After` och skicka den igen oförändrad | | Anslutningstestet misslyckas | Kontrollera det regionala värdnamnet, Bearer-rubriken, nyckelstatus och policyn för offentlig TLS-inspektion | API:et accepterar högst 10 000 poster och 10 MB per förfrågan, med 600 förfrågningar per 60 sekunder per organisation. Se [Custom Push Source API](/sv/integrations/custom-push-source) för fullständig information om svar och nya försök. ## Relaterat Granska autentisering, nyttolastgränser, svar, nya försök och körningsverifiering. Anslut det separata Client Connector-API:et för enhets- och säkerhetsstatusdata. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.