> ## 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.
# Configuration des adresses IP de sortie des intégrations
> Autorisez les adresses IP sortantes de Living Security afin que votre fournisseur accepte le trafic de nos intégrations.
Certains fournisseurs limitent l'accès à leur API à une liste approuvée d'adresses IP sources. Lorsque cette restriction est activée, votre fournisseur doit être configuré pour accepter le trafic provenant des adresses IP de sortie de Living Security ; dans le cas contraire, l'intégration sera rejetée au niveau de la couche réseau.
Cette page répertorie ces adresses.
## Il existe deux ensembles
Living Security accède à votre fournisseur via deux réseaux distincts, qui servent des parties différentes de l'intégration.
| Ensemble | Trafic concerné | Nombre | Varie selon la région ? |
| - | - | - | - |
| **Trafic de synchronisation des intégrations** | Les appels d'API planifiés qui importent vos données, ainsi que les Actions de Playbook sortantes par défaut | 4 adresses | Non |
| **Trafic de la plateforme** | Les demandes de jeton d'accès pour les intégrations listées ci-dessous, ainsi que les Actions de Playbook sortantes sur les connexions basculées en sortie directe | 2 adresses par région | **Oui** |
La plupart des intégrations n'ont besoin que de l'ensemble de synchronisation. Un groupe spécifique a besoin des **deux** ensembles, de façon permanente ; consultez la section [Intégrations nécessitant les deux ensembles](#int%C3%A9grations-n%C3%A9cessitant-les-deux-ensembles).
## Trafic de synchronisation des intégrations
Ces quatre adresses sont identiques pour toutes les régions de Living Security. Les clients hébergés dans l'Union européenne utilisent les mêmes quatre adresses que ceux hébergés aux États-Unis.
| Adresse IP | 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` |
Pour les fournisseurs qui acceptent une liste séparée par des virgules :
```text theme={null}
52.34.139.153/32, 54.69.127.183/32, 44.247.133.183/32, 52.26.211.56/32
```
## Trafic de la plateforme
Contrairement aux adresses de synchronisation, celles-ci **sont** propres à chaque région. Utilisez uniquement la paire correspondant à la région qui héberge votre organisation. Si vous ne savez pas de quelle région il s'agit, demandez à votre Customer Success Manager avant de configurer quoi que ce soit : autoriser les adresses de la mauvaise région entraîne un échec de l'intégration dont les symptômes ne semblent avoir aucun rapport avec la liste d'autorisation.
| Région | Adresses IP | CIDR |
| - | - | - |
| **États-Unis** | `98.91.60.249`, `13.216.91.102` | `98.91.60.249/32`, `13.216.91.102/32` |
| **Union européenne** | `34.246.236.210`, `52.31.102.238` | `34.246.236.210/32`, `52.31.102.238/32` |
Pour les fournisseurs qui acceptent une liste séparée par des virgules :
```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
```
### Actions de Playbook sortantes
Par défaut, les Actions de Playbook qui écrivent dans un système connecté empruntent le même chemin que vos synchronisations de données ; elles partent donc des adresses de **synchronisation**. Aucune configuration supplémentaire n'est nécessaire.
Un administrateur peut basculer une connexion individuelle en **sortie directe**, ce qui déplace les Actions de cette connexion vers les adresses de la plateforme correspondant à votre région. Ce paramètre existe précisément pour la situation suivante : une instance de fournisseur qui restreint l'accès à l'API par adresse IP source et qui nécessite un petit ensemble stable d'adresses appartenant à Living Security à autoriser. Quelques fournisseurs utilisent toujours la sortie directe, car ils ne peuvent pas du tout passer par un proxy.
Si vous n'autorisez que les adresses de synchronisation et que quelqu'un bascule ensuite une connexion en sortie directe, les Actions de cette connexion commenceront à échouer alors que ses synchronisations continueront de fonctionner.
## Intégrations nécessitant les deux ensembles
Pour la plupart des intégrations, le service d'intégration de Living Security obtient et renouvelle lui-même le jeton d'accès, et tout le trafic atteint votre fournisseur depuis les seules adresses de synchronisation.
Pour les intégrations ci-dessous, ce service ne peut pas renouveler le jeton ; c'est donc **la plateforme Living Security qui le génère directement**, une première fois lors de la connexion, puis en continu tant que la connexion est active. Ces demandes de jeton partent des adresses de la plateforme. Les synchronisations de données planifiées continuent, quant à elles, de partir des adresses de synchronisation.
* [Auth0](/fr/integrations/auth0)
* [Cofense Triage](/fr/integrations/cofense-triage)
* Code42
* Cornerstone
* [CrowdStrike Falcon](/fr/integrations/crowdstrike)
* [Microsoft Entra ID](/fr/integrations/microsoft-entra-id) — y compris Microsoft Graph
* [OneLogin](/fr/integrations/onelogin)
* Sophos Central
* Zscaler Client Connector
**Les deux ensembles doivent rester autorisés pendant toute la durée de vie de la connexion.** Les adresses de la plateforme ne sont pas une exigence limitée à la configuration initiale. Le renouvellement du jeton s'exécute selon un cycle court tant que l'intégration est active ; les supprimer après une configuration réussie interrompt donc l'intégration à la prochaine expiration du jeton.
Si le point de terminaison de jeton de votre fournisseur et son API de données se trouvent sur le même hôte, ce qui est fréquent, cet hôte unique doit accepter les deux réseaux.
## Ajoutez toutes les adresses des ensembles dont vous avez besoin
Le trafic peut partir de n'importe quelle adresse d'un ensemble, et l'adresse utilisée pour une requête donnée n'est pas fixe. N'autoriser qu'une partie des adresses provoque des échecs intermittents difficiles à diagnostiquer : certaines requêtes aboutissent, d'autres échouent, et le schéma semble sans rapport avec la configuration.
Cela s'applique aussi bien à la paire d'adresses de la plateforme qu'aux quatre adresses de synchronisation. Chaque région en exploite deux, et les requêtes peuvent provenir de l'une ou de l'autre.
**Ces adresses sont stables, mais elles ne sont pas permanentes.** Nous nous efforçons de les conserver inchangées et ne les modifions que rarement, dans des circonstances exceptionnelles, par exemple lors d'un changement de notre fournisseur d'infrastructure sous-jacent.
Comme une modification est possible, ajoutez cette page à vos favoris. Si une intégration qui fonctionnait auparavant se met à échouer, revenez ici et vérifiez que votre liste d'autorisation correspond aux adresses ci-dessus avant d'ouvrir un ticket d'assistance.
## Intégrations concernées
Une liste d'autorisation d'adresses IP est un paramètre de *votre* fournisseur, et non de Living Security. Elle ne s'applique que si votre organisation a activé cette restriction. Si vous n'avez pas activé de restrictions IP chez le fournisseur, aucune action n'est nécessaire.
Ces fournisseurs l'exigent couramment :
| Fournisseur | Emplacement du paramètre |
| - | - |
| [Abnormal Security](/fr/integrations/abnormal-security) | **IP Safelist** sur le jeton d'API — obligatoire |
| [KnowBe4](/fr/integrations/knowbe4) | **Allowed IP Addresses** sur le jeton de l'API Reporting |
| [Netskope](/fr/integrations/netskope) | Liste **Custom IP**, si l'autorisation d'adresses IP du tenant est activée |
| [Duo Admin](/fr/integrations/catalog/duo-admin-custom) | **Networks for API Access** — facultatif |
| [Microsoft Entra ID](/fr/integrations/microsoft-entra-id) | **Named locations** référencées par une stratégie d'accès conditionnel |
D'autres fournisseurs peuvent proposer un paramètre similaire. Consultez la page du fournisseur dans le [Catalogue](/fr/integrations/overview) ainsi que la documentation propre au fournisseur.
## Symptômes d'une liste d'autorisation manquante ou obsolète
Les deux ensembles échouent de manières opposées. Associez le symptôme à l'ensemble concerné avant de modifier quoi que ce soit.
### La connexion aboutit, mais aucune donnée n'arrive
C'est la signature d'une **adresse de synchronisation manquante**.
Les identifiants sont validés lors de la connexion par un chemin qui n'est souvent pas soumis à la même restriction ; la boîte de dialogue de connexion de Living Security indique donc une réussite. L'échec apparaît plus tard, lorsqu'une synchronisation planifiée s'exécute et est bloquée.
Signes à rechercher :
* La connexion apparaît comme établie, mais les flux ne signalent aucun enregistrement.
* Les exécutions de synchronisation échouent avec `401 Unauthorized` ou `403 Forbidden`.
* Une intégration qui fonctionnait depuis des mois se met à échouer sans aucune modification de votre côté.
### La connexion ne peut pas être créée du tout
C'est la signature d'une **adresse de la plateforme manquante**, et cela ne concerne que les intégrations listées dans [Intégrations nécessitant les deux ensembles](#int%C3%A9grations-n%C3%A9cessitant-les-deux-ensembles).
Signes à rechercher :
* La configuration échoue lors de l'obtention d'un jeton d'accès. Aucune connexion n'est créée.
* L'erreur indique qu'un hôte n'a pas pu être joint, sans aucune réponse HTTP.
* Les journaux de connexion ou d'accès conditionnel du fournisseur montrent une requête bloquée provenant d'une adresse que vous n'avez pas autorisée.
Une connexion qui ne peut pas être atteinte n'est **pas** un problème d'identifiants. Aucune authentification n'a eu lieu ; renouveler le secret ou régénérer les identifiants du client n'y changera donc rien. Une adresse source non autorisée en est la cause la plus fréquente, mais un nom d'hôte incorrect, un port incorrect ou une panne côté fournisseur se présentent de la même manière de notre côté.
Une modification ultérieure de votre liste d'autorisation qui supprime les adresses de la plateforme se manifeste encore différemment : une intégration qui fonctionnait correctement depuis des semaines s'arrête en quelques minutes, car le prochain renouvellement de jeton est bloqué.
## Ceci ne couvre pas la remise des Simulation d'hameçonnage
Les adresses de cette page s'appliquent au **trafic des intégrations**, c'est-à-dire aux appels d'API que Living Security effectue vers vos systèmes connectés pour importer des données et exécuter des Actions de Playbook.
L'autorisation pour la **remise des e-mails de Simulation d'hameçonnage** est une configuration distincte, avec ses propres adresses, domaines d'expédition et packages d'autorisation téléchargeables. Effectuez-la dans **Paramètres → Simulation de phishing → Allowlisting**. Consultez [Paramètres de Simulation de phishing](/fr/features/settings/phishing-simulation) pour cette procédure.
Autoriser les adresses de cette page ne rendra pas les e-mails d'hameçonnage simulé remis, et effectuer l'autorisation pour la simulation ne rendra pas accessible l'API d'un fournisseur restreint. Si vous utilisez les deux, configurez les deux.
## Obtenir de l'aide
Si les intégrations continuent d'échouer après que vous avez autorisé les adresses de votre région, contactez votre Customer Success Manager ou [support@livingsecurity.com](mailto:support@livingsecurity.com). Indiquez le nom du fournisseur, le flux en échec ou l'étape de configuration qui a échoué, ainsi que l'horodatage, afin que nous puissions les corréler avec nos journaux de sortie.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.