> ## 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.
# Konfiguration af egress-IP-adresser for integrationer
> Tillad Living Securitys udgående IP-adresser, så din udbyder accepterer vores integrationstrafik.
Nogle udbydere begrænser API-adgang til en godkendt liste over kilde-IP-adresser. Når denne begrænsning er aktiveret, skal din udbyder konfigureres til at acceptere trafik fra Living Securitys egress-IP-adresser, ellers afvises integrationen på netværkslaget.
Denne side viser disse adresser.
## Der er to sæt
Living Security kommunikerer med din udbyder via to forskellige netværk, og de understøtter hver sin del af integrationen.
| Sæt | Hvad udgår herfra | Antal | Varierer efter region? |
| - | - | - | - |
| **Synkroniseringstrafik for integrationer** | De planlagte API-kald, der importerer dine data, samt udgående Playbook-handlinger som standard | 4 adresser | Nej |
| **Platformtrafik** | Forespørgsler om adgangstokens for de integrationer, der er anført nedenfor, samt udgående Playbook-handlinger på forbindelser, der er skiftet til direkte egress | 2 adresser pr. region | **Ja** |
De fleste integrationer har kun brug for synkroniseringssættet. En bestemt gruppe har permanent brug for **begge** sæt – se [Integrationer, der kræver begge sæt](#integrationer%2C-der-kr%C3%A6ver-begge-s%C3%A6t).
## Synkroniseringstrafik for integrationer
Disse fire adresser er de samme for alle Living Security-regioner. Kunder, der hostes i EU, bruger de samme fire som kunder, der hostes i USA.
| IP-adresse | CIDR |
| - | - |
| `52.34.139.153` | `52.34.139.153/32` |
| `54.69.127.183` | `54.69.127.183/32` |
| `44.247.133.183` | `44.247.133.183/32` |
| `52.26.211.56` | `52.26.211.56/32` |
Til udbydere, der accepterer en kommasepareret liste:
```text theme={null}
52.34.139.153/32, 54.69.127.183/32, 44.247.133.183/32, 52.26.211.56/32
```
## Platformtrafik
I modsætning til synkroniseringsadresserne er disse **regionsspecifikke**. Brug kun det par, der hører til den region, som hoster din organisation. Hvis du er usikker på, hvilken region det er, bør du spørge din Customer Success Manager, inden du konfigurerer noget – hvis du tillader adresserne for den forkerte region, fejler integrationen på en måde, der ikke ser ud til at have noget med allowlisten at gøre.
| Region | IP-adresser | CIDR |
| - | - | - |
| **USA** | `98.91.60.249`, `13.216.91.102` | `98.91.60.249/32`, `13.216.91.102/32` |
| **Den Europæiske Union** | `34.246.236.210`, `52.31.102.238` | `34.246.236.210/32`, `52.31.102.238/32` |
Til udbydere, der accepterer en kommasepareret liste:
```text theme={null}
United States: 98.91.60.249/32, 13.216.91.102/32
European Union: 34.246.236.210/32, 52.31.102.238/32
```
### Udgående Playbook-handlinger
Som standard sendes Playbook-handlinger, der skriver tilbage til et tilsluttet system, via samme sti som dine datasynkroniseringer, og de udgår derfor fra **synkroniseringsadresserne**. Der kræves ikke yderligere tiltag.
En administrator kan skifte en enkelt forbindelse til **direkte egress**, hvorved den pågældende forbindelses handlinger flyttes til platformadresserne for din region. Denne indstilling findes netop til denne situation – en udbyderinstans, der begrænser API-adgang efter kilde-IP og har brug for et lille, stabilt sæt ejet af Living Security, som kan tillades. Enkelte udbydere bruger altid direkte egress, fordi de slet ikke kan proxies.
Hvis du kun tillader synkroniseringsadresserne, og nogen senere skifter en forbindelse til direkte egress, begynder den forbindelses handlinger at fejle, mens dens synkroniseringer fortsat fungerer.
## Integrationer, der kræver begge sæt
For de fleste integrationer indhenter og fornyer Living Securitys integrationstjeneste selv adgangstokenet, og al trafik når din udbyder udelukkende fra synkroniseringsadresserne.
For nedenstående integrationer kan tjenesten ikke fornye tokenet, så **Living Security-platformen udsteder det direkte** – én gang, når du opretter forbindelsen, og derefter løbende, så længe forbindelsen er aktiv. Disse tokenforespørgsler udgår fra platformadresserne. De planlagte datasynkroniseringer udgår stadig fra synkroniseringsadresserne.
* [Auth0](/da/integrations/auth0)
* [Cofense Triage](/da/integrations/cofense-triage)
* Code42
* Cornerstone
* [CrowdStrike Falcon](/da/integrations/crowdstrike)
* [Microsoft Entra ID](/da/integrations/microsoft-entra-id) – herunder Microsoft Graph
* [OneLogin](/da/integrations/onelogin)
* Sophos Central
* Zscaler Client Connector
**Begge sæt skal forblive tilladt, så længe forbindelsen eksisterer.** Platformadresserne er ikke kun et krav under opsætningen. Tokenfornyelsen kører i en kort cyklus, så længe integrationen er aktiv, og hvis adresserne fjernes efter en vellykket opsætning, holder integrationen op med at fungere, næste gang tokenet udløber.
Hvis din udbyders token-endpoint og dens data-API er den samme vært – hvilket er almindeligt – skal den ene vært acceptere begge netværk.
## Tilføj alle adresser i de sæt, du har brug for
Trafik kan udgå fra enhver adresse i et sæt, og hvilken adresse der bruges til en given forespørgsel, er ikke fastlagt. Hvis du kun tillader en delmængde, opstår der sporadiske fejl, som er vanskelige at diagnosticere: nogle forespørgsler lykkes, andre fejler, og mønsteret ser ikke ud til at hænge sammen med konfigurationen.
Dette gælder lige så meget for platformparret som for de fire synkroniseringsadresser. Hver region kører med to, og forespørgsler lander på begge.
**Disse adresser er stabile, men ikke permanente.** Vi bestræber os på at holde dem uændrede, og vi ændrer dem kun sjældent og under ekstraordinære omstændigheder – f.eks. ved en ændring hos vores underliggende infrastrukturudbyder.
Fordi en ændring er mulig, bør du bogmærke denne side. Hvis en integration, der tidligere fungerede, begynder at fejle, skal du vende tilbage hhertil og bekræfte, at din allowlist svarer til adresserne ovenfor, før du opretter en supportsag.
## Hvilke integrationer kræver dette
En IP-allowlist er en indstilling hos *din* udbyder, ikke hos Living Security. Den gælder kun, hvis din organisation har aktiveret den pågældende begrænsning. Hvis du ikke har aktiveret IP-begrænsninger hos udbyderen, er der ikke behov for handling.
Disse udbydere kræver det almindeligvis:
| Udbyder | Hvor indstillingen findes |
| - | - |
| [Abnormal Security](/da/integrations/abnormal-security) | **IP Safelist** på API-tokenet – obligatorisk |
| [KnowBe4](/da/integrations/knowbe4) | **Allowed IP Addresses** på Reporting API-tokenet |
| [Netskope](/da/integrations/netskope) | **Custom IP**-listen, hvis allowlisting af tenant-IP er aktiveret |
| [Duo Admin](/da/integrations/catalog/duo-admin-custom) | **Networks for API Access** – valgfrit |
| [Microsoft Entra ID](/da/integrations/microsoft-entra-id) | **Named locations**, der refereres til af en Conditional Access-politik |
Andre udbydere kan tilbyde en lignende indstilling. Se udbyderens side i [kataloget](/da/integrations/overview) og udbyderens egen dokumentation.
## Symptomer på en manglende eller forældet allowlist
De to sæt fejler på modsatte måder. Match symptomet med sættet, inden du ændrer noget.
### Forbindelsen lykkes, men data ankommer aldrig
Dette er kendetegnet for en **manglende synkroniseringsadresse**.
Legitimationsoplysninger valideres på forbindelsestidspunktet via en sti, der ofte ikke er underlagt den samme begrænsning, så forbindelsesdialogen i Living Security melder succes. Fejlen viser sig senere, når en planlagt synkronisering kører og bliver blokeret.
Se efter:
* Forbindelsen vises som tilsluttet, men streams rapporterer ingen poster.
* Synkroniseringskørsler fejler med `401 Unauthorized` eller `403 Forbidden`.
* En integration, der har fungeret i månedsvis, begynder at fejle uden ændringer fra din side.
### Forbindelsen kan slet ikke oprettes
Dette er kendetegnet for en **manglende platformadresse**, og det gælder kun de integrationer, der er anført under [Integrationer, der kræver begge sæt](#integrationer%2C-der-kr%C3%A6ver-begge-s%C3%A6t).
Se efter:
* Opsætningen fejler under indhentning af et adgangstoken. Der oprettes ingen forbindelse.
* Fejlen angiver, at en vært ikke kunne nås, uden at der ligger et HTTP-svar bag.
* Udbyderens egne log over logins eller Conditional Access viser en blokeret forespørgsel fra en adresse, du ikke har tilladt.
En forbindelse, der slet ikke kan nås, er **ikke** et problem med legitimationsoplysninger. Der er ikke sket nogen godkendelse, så det hjælper ikke at rotere hemmeligheden eller genskabe klientlegitimationsoplysningerne. En ikke-tilladt kildeadresse er den hyppigste årsag, selvom et forkert værtsnavn, en forkert port eller en nedbrud hos udbyderen ser ens ud fra vores side.
En senere ændring af din allowlist, der fjerner platformadresserne, viser sig igen anderledes: en integration, der har fungeret fejlfrit i ugevis, stopper inden for få minutter, fordi den næste tokenfornyelse bliver blokeret.
## Dette dækker ikke levering af Phishingsimulering
Adresserne på denne side gælder for **integrationstrafik** – de API-kald, som Living Security foretager til dine tilsluttede systemer for at importere data og udføre Playbook-handlinger.
Allowlisting til **levering af e-mails fra Phishingsimulering** er en særskilt konfiguration med egne adresser, afsenderdomæner og allowlist-pakker, der kan downloades. Gennemfør den under **Indstillinger → Phishing-simulering → Allowlisting**. Se [Indstillinger for Phishing-simulering](/da/features/settings/phishing-simulation) for den proces.
Hvis du tillader adresserne på denne side, bliver simulerede phishing-e-mails ikke leveringsdygtige, og hvis du gennemfører allowlisting til simulering, bliver en begrænset udbyders API ikke tilgængelig. Hvis du bruger begge, skal begge konfigureres.
## Få hjælp
Hvis integrationer fortsat fejler, efter du har tilladt adresserne for din region, skal du kontakte din Customer Success Manager eller [support@livingsecurity.com](mailto:support@livingsecurity.com). Oplys udbyderens navn, den stream der fejler eller det opsætningstrin der fejlede, samt tidsstemplet, så vi kan sammenholde det med vores egress-logs.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.