> ## 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.

# Egress-IP-adressen voor integraties configureren

> Zet de uitgaande IP-adressen van Living Security op de allowlist, zodat uw provider ons integratieverkeer accepteert.

Sommige providers beperken API-toegang tot een goedgekeurde lijst met bron-IP-adressen. Als die beperking is ingeschakeld, moet uw provider zo worden geconfigureerd dat verkeer van de egress-IP-adressen van Living Security wordt geaccepteerd. Anders wordt de integratie op netwerkniveau geweigerd.

Deze pagina bevat die adressen.

## Er zijn twee sets

Living Security bereikt uw provider via twee verschillende netwerken, en die dienen elk voor een ander onderdeel van de integratie.

| Set | Wat erover verloopt | Aantal | Verschilt per regio? |
| - | - | - | - |
| **Synchronisatieverkeer van integraties** | De geplande API-aanroepen die uw gegevens importeren, en standaard uitgaande Playbook-acties | 4 adressen | Nee |
| **Platformverkeer** | Aanvragen voor toegangstokens voor de hieronder vermelde integraties, en uitgaande Playbook-acties op verbindingen die zijn overgeschakeld naar directe egress | 2 adressen per regio | **Ja** |

De meeste integraties hebben alleen de synchronisatieset nodig. Een specifieke groep heeft permanent **beide** sets nodig; zie [Integraties die beide sets nodig hebben](#integraties-die-beide-sets-nodig-hebben).

## Synchronisatieverkeer van integraties

Deze vier adressen zijn voor elke regio van Living Security hetzelfde. Klanten die in de EU worden gehost, gebruiken dezelfde vier adressen als klanten die in de VS worden gehost.

| IP-adres | 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` |

Voor providers die een door komma's gescheiden lijst accepteren:

```text theme={null}
52.34.139.153/32, 54.69.127.183/32, 44.247.133.183/32, 52.26.211.56/32
```

## Platformverkeer

In tegenstelling tot de synchronisatieadressen zijn deze adressen **wel** regiospecifiek. Gebruik alleen het paar voor de regio waar uw organisatie wordt gehost. Als u niet zeker weet om welke regio het gaat, vraag dit dan aan uw Customer Success Manager voordat u iets configureert. Als u de adressen van de verkeerde regio op de allowlist zet, blijft de integratie mislukken op een manier die geen enkel verband met de allowlist lijkt te hebben.

| Regio | IP-adressen | CIDR |
| - | - | - |
| **Verenigde Staten** | `98.91.60.249`, `13.216.91.102` | `98.91.60.249/32`, `13.216.91.102/32` |
| **Europese Unie** | `34.246.236.210`, `52.31.102.238` | `34.246.236.210/32`, `52.31.102.238/32` |

Voor providers die een door komma's gescheiden lijst accepteren:

```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
```

### Uitgaande Playbook-acties

Standaard lopen Playbook-acties die naar een gekoppeld systeem terugschrijven via hetzelfde pad als uw gegevenssynchronisaties, zodat ze via de **synchronisatieadressen** vertrekken. Er is niets extra's nodig.

Een beheerder kan een afzonderlijke verbinding overschakelen naar **directe egress**. De acties van die verbinding lopen dan via de platformadressen van uw regio. Die instelling bestaat precies voor deze situatie: een providerinstantie die API-toegang beperkt op basis van bron-IP en een kleine, stabiele set adressen van Living Security nodig heeft om op de allowlist te zetten. Een aantal providers gebruikt altijd directe egress, omdat ze helemaal niet via een proxy kunnen worden benaderd.

Als u alleen de synchronisatieadressen op de allowlist zet en iemand later een verbinding overschakelt naar directe egress, gaan de acties van die verbinding mislukken terwijl de synchronisaties blijven werken.

## Integraties die beide sets nodig hebben

Bij de meeste integraties verkrijgt en vernieuwt de integratieservice van Living Security het toegangstoken zelf, en bereikt al het verkeer uw provider alleen via de synchronisatieadressen.

Voor de onderstaande integraties kan die service het token niet vernieuwen, dus **maakt het Living Security-platform het token rechtstreeks aan**: eenmalig op het moment dat u de verbinding tot stand brengt, en daarna continu zolang de verbinding actief is. Die tokenaanvragen vertrekken vanaf de platformadressen. De geplande gegevenssynchronisaties vertrekken nog steeds vanaf de synchronisatieadressen.

* [Auth0](/nl/integrations/auth0)
* [Cofense Triage](/nl/integrations/cofense-triage)
* Code42
* Cornerstone
* [CrowdStrike Falcon](/nl/integrations/crowdstrike)
* [Microsoft Entra ID](/nl/integrations/microsoft-entra-id) — inclusief Microsoft Graph
* [OneLogin](/nl/integrations/onelogin)
* Sophos Central
* Zscaler Client Connector

<Warning>
  **Beide sets blijven op de allowlist staan zolang de verbinding bestaat.** De platformadressen zijn niet alleen tijdens de installatie nodig. Tokenvernieuwing verloopt in een korte cyclus zolang de integratie actief is. Als u de adressen na een geslaagde installatie verwijdert, werkt de integratie dus niet meer zodra het token de volgende keer verloopt.
</Warning>

Als het tokeneindpunt en de gegevens-API van uw provider dezelfde host zijn, wat vaak voorkomt, moet die ene host beide netwerken accepteren.

## Voeg alle adressen toe van de sets die u nodig hebt

Verkeer kan vanaf elk adres binnen een set vertrekken, en welk adres voor een bepaalde aanvraag wordt gebruikt, ligt niet vast. Als u slechts een deel van de adressen op de allowlist zet, ontstaan onregelmatige storingen die lastig te diagnosticeren zijn: sommige aanvragen slagen, andere mislukken, en het patroon lijkt geen verband met de configuratie te hebben.

Dit geldt evenzeer voor het platformpaar als voor de vier synchronisatieadressen. Elke regio heeft twee adressen in gebruik, en aanvragen komen via een van beide binnen.

<Warning>
  **Deze adressen zijn stabiel, maar niet permanent.** Wij streven ernaar ze ongewijzigd te houden en wijzigen ze slechts zelden en in uitzonderlijke omstandigheden, zoals een wijziging bij onze onderliggende infrastructuurprovider.

  Omdat een wijziging mogelijk is, raden wij u aan deze pagina als bladwijzer op te slaan. Als een integratie die eerder werkte, begint te mislukken, kom dan hier terug en controleer of uw allowlist overeenkomt met de bovenstaande adressen voordat u een supportticket aanmaakt.
</Warning>

## Voor welke integraties dit nodig is

Een IP-allowlist is een instelling bij *uw* provider, niet bij Living Security. Deze is alleen van toepassing als uw organisatie die beperking heeft ingeschakeld. Als u geen IP-beperkingen bij de provider hebt ingeschakeld, hoeft u niets te doen.

Bij deze providers is dit vaak vereist:

| Provider | Waar de instelling zich bevindt |
| - | - |
| [Abnormal Security](/nl/integrations/abnormal-security) | **IP Safelist** op het API-token — verplicht |
| [KnowBe4](/nl/integrations/knowbe4) | **Allowed IP Addresses** op het Reporting API-token |
| [Netskope](/nl/integrations/netskope) | **Custom IP**-lijst, als IP-allowlisting voor de tenant is ingeschakeld |
| [Duo Admin](/nl/integrations/catalog/duo-admin-custom) | **Networks for API Access** — optioneel |
| [Microsoft Entra ID](/nl/integrations/microsoft-entra-id) | **Named locations** waarnaar een Conditional Access-beleid verwijst |

Andere providers bieden mogelijk een vergelijkbare instelling. Raadpleeg de pagina van de provider in de [Catalogus](/nl/integrations/overview) en de eigen documentatie van de provider.

## Symptomen van een ontbrekende of verouderde allowlist

De twee sets falen op tegengestelde manieren. Koppel het symptoom aan de juiste set voordat u iets wijzigt.

### De verbinding slaagt, maar er komen nooit gegevens binnen

Dit is het kenmerk van een **ontbrekend synchronisatieadres**.

Inloggegevens worden bij het tot stand brengen van de verbinding gevalideerd via een pad dat vaak niet onder dezelfde beperking valt, waardoor het verbindingsdialoogvenster in Living Security een geslaagde verbinding meldt. De fout verschijnt pas later, wanneer een geplande synchronisatie wordt uitgevoerd en wordt geblokkeerd.

Let op het volgende:

* De verbinding wordt als verbonden weergegeven, maar streams melden geen records.
* Synchronisatie-uitvoeringen mislukken met `401 Unauthorized` of `403 Forbidden`.
* Een integratie die maandenlang werkte, begint te mislukken zonder dat er aan uw kant iets is gewijzigd.

### De verbinding kan helemaal niet worden aangemaakt

Dit is het kenmerk van een **ontbrekend platformadres**, en het geldt alleen voor de integraties die worden genoemd onder [Integraties die beide sets nodig hebben](#integraties-die-beide-sets-nodig-hebben).

Let op het volgende:

* De installatie mislukt bij het verkrijgen van een toegangstoken. Er wordt geen verbinding aangemaakt.
* In de foutmelding staat dat een host niet kon worden bereikt, zonder dat er een HTTP-respons is.
* In de eigen aanmeld- of Conditional Access-logboeken van de provider staat een geblokkeerde aanvraag vanaf een adres dat u niet op de allowlist hebt gezet.

<Note>
  Een verbinding die helemaal niet kan worden bereikt, is **geen** probleem met inloggegevens. Er heeft geen authenticatie plaatsgevonden, dus het roteren van het geheim of het opnieuw genereren van de clientgegevens helpt niet. Een bronadres dat niet op de allowlist staat, is de meest voorkomende oorzaak, maar een onjuiste hostnaam, een onjuiste poort of een storing aan de kant van de provider zien er vanuit ons perspectief hetzelfde uit.
</Note>

Een latere wijziging in uw allowlist waarbij de platformadressen worden verwijderd, uit zich weer anders: een integratie die weken probleemloos werkte, stopt binnen enkele minuten, omdat de eerstvolgende tokenvernieuwing wordt geblokkeerd.

## Dit geldt niet voor de bezorging van phishingsimulaties

De adressen op deze pagina gelden voor **integratieverkeer**: de API-aanroepen die Living Security naar uw gekoppelde systemen doet om gegevens te importeren en Playbook-acties uit te voeren.

Allowlisting voor de **e-mailbezorging van phishingsimulaties** is een aparte configuratie met eigen adressen, afzenderdomeinen en downloadbare allowlistpakketten. Voer deze uit via **Instellingen → Phishing-simulatie → Allowlisting**. Zie [Instellingen voor Phishing-simulatie](/nl/features/settings/phishing-simulation) voor dat proces.

Door de adressen op deze pagina op de allowlist te zetten, worden gesimuleerde phishingmails niet bezorgbaar, en door de allowlisting voor simulaties te voltooien, wordt een beperkte provider-API niet bereikbaar. Als u beide gebruikt, configureer dan beide.

## Hulp krijgen

Als integraties blijven mislukken nadat u de adressen voor uw regio op de allowlist hebt gezet, neem dan contact op met uw Customer Success Manager of met [support@livingsecurity.com](mailto:support@livingsecurity.com). Vermeld de naam van de provider, de mislukte stream of de mislukte installatiestap, en het tijdstip, zodat wij dit kunnen vergelijken met onze egress-logboeken.


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