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

# Konfigurowanie adresów IP ruchu wychodzącego integracji

> Dodaj adresy IP ruchu wychodzącego Living Security do listy dozwolonych, aby Państwa dostawca akceptował ruch integracyjny z naszej platformy.

Niektórzy dostawcy ograniczają dostęp do API do zatwierdzonej listy źródłowych adresów IP. Gdy takie ograniczenie jest włączone, dostawca musi zostać skonfigurowany tak, aby akceptował ruch z adresów IP ruchu wychodzącego Living Security. W przeciwnym razie integracja zostanie odrzucona na warstwie sieciowej.

Na tej stronie podano te adresy.

## Istnieją dwa zestawy

Living Security łączy się z Państwa dostawcą za pośrednictwem dwóch różnych sieci, które obsługują różne części integracji.

| Zestaw | Co z niego wychodzi | Liczba | Zależy od regionu? |
| - | - | - | - |
| **Ruch synchronizacji integracji** | Zaplanowane wywołania API importujące Państwa dane oraz domyślnie wychodzące działania playbooków | 4 adresy | Nie |
| **Ruch platformy** | Żądania tokenów dostępu dla wymienionych poniżej integracji oraz wychodzące działania playbooków w połączeniach przełączonych na bezpośredni ruch wychodzący | 2 adresy na region | **Tak** |

Większość integracji wymaga wyłącznie zestawu synchronizacji. Określona grupa wymaga **obu** zestawów, na stałe — zobacz [Integracje wymagające obu zestawów](#integracje-wymagaj%C4%85ce-obu-zestaw%C3%B3w).

## Ruch synchronizacji integracji

Te cztery adresy są takie same dla każdego regionu Living Security. Klienci hostowani w Unii Europejskiej używają tych samych czterech adresów co klienci hostowani w Stanach Zjednoczonych.

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

Dla dostawców, którzy akceptują listę rozdzieloną przecinkami:

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

## Ruch platformy

W przeciwieństwie do adresów synchronizacji te adresy **są** specyficzne dla regionu. Należy użyć wyłącznie pary przypisanej do regionu, w którym hostowana jest Państwa organizacja. Jeśli nie są Państwo pewni, co to za region, przed rozpoczęciem konfiguracji proszę zapytać swojego opiekuna ds. sukcesu klienta (Customer Success Manager) — dodanie do listy dozwolonych adresów niewłaściwego regionu powoduje błędy integracji, które wyglądają na niezwiązane z listą dozwolonych.

| Region | Adresy IP | CIDR |
| - | - | - |
| **Stany Zjednoczone** | `98.91.60.249`, `13.216.91.102` | `98.91.60.249/32`, `13.216.91.102/32` |
| **Unia Europejska** | `34.246.236.210`, `52.31.102.238` | `34.246.236.210/32`, `52.31.102.238/32` |

Dla dostawców, którzy akceptują listę rozdzieloną przecinkami:

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

### Wychodzące działania playbooków

Domyślnie działania playbooków, które zapisują dane z powrotem w połączonym systemie, są kierowane tą samą ścieżką co synchronizacje danych, dlatego wychodzą z adresów **synchronizacji**. Nie jest potrzebne nic dodatkowego.

Administrator może przełączyć dane połączenie na **bezpośredni ruch wychodzący (direct egress)**, co przenosi działania tego połączenia na adresy platformy dla Państwa regionu. To ustawienie istnieje właśnie na taką sytuację — gdy instancja dostawcy ogranicza dostęp do API według źródłowego adresu IP i wymaga niewielkiego, stabilnego zestawu należącego do Living Security, który można dodać do listy dozwolonych. Niektórzy dostawcy zawsze używają bezpośredniego ruchu wychodzącego, ponieważ w ogóle nie można ich obsługiwać przez serwer proxy.

Jeśli dodadzą Państwo do listy dozwolonych tylko adresy synchronizacji, a ktoś później przełączy połączenie na bezpośredni ruch wychodzący, działania tego połączenia zaczną kończyć się błędem, podczas gdy jego synchronizacje będą nadal działać.

## Integracje wymagające obu zestawów

W przypadku większości integracji usługa integracji Living Security samodzielnie uzyskuje i odnawia token dostępu, a cały ruch do Państwa dostawcy pochodzi wyłącznie z adresów synchronizacji.

W przypadku poniższych integracji usługa ta nie może odnawiać tokenu, więc **platforma Living Security generuje go bezpośrednio** — jednorazowo podczas nawiązywania połączenia, a następnie w sposób ciągły, dopóki połączenie jest aktywne. Te żądania tokenów wychodzą z adresów platformy. Zaplanowane synchronizacje danych nadal wychodzą z adresów synchronizacji.

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

<Warning>
  **Oba zestawy muszą pozostać na liście dozwolonych przez cały czas istnienia połączenia.** Adresy platformy nie są wymagane wyłącznie podczas konfiguracji. Odnawianie tokenu odbywa się w krótkim cyklu, dopóki integracja jest aktywna, więc usunięcie tych adresów po udanej konfiguracji spowoduje awarię integracji przy najbliższym wygaśnięciu tokenu.
</Warning>

Jeśli punkt końcowy tokenu dostawcy i jego API danych znajdują się na tym samym hoście — co jest częste — ten jeden host musi akceptować obie sieci.

## Dodaj każdy adres z potrzebnych zestawów

Ruch może wychodzić z dowolnego adresu w zestawie, a adres używany dla danego żądania nie jest stały. Dodanie do listy dozwolonych tylko części adresów powoduje sporadyczne błędy, które trudno zdiagnozować: niektóre żądania kończą się powodzeniem, inne niepowodzeniem, a wzorzec wygląda na niezwiązany z konfiguracją.

Dotyczy to zarówno pary adresów platformy, jak i czterech adresów synchronizacji. Każdy region korzysta z dwóch adresów, a żądania trafiają na każdy z nich.

<Warning>
  **Te adresy są stabilne, ale nie są stałe.** Dokładamy starań, aby pozostały niezmienione, i zmieniamy je bardzo rzadko oraz wyłącznie w wyjątkowych okolicznościach — takich jak zmiana naszego dostawcy infrastruktury.

  Ponieważ zmiana jest możliwa, zalecamy dodanie tej strony do zakładek. Jeśli integracja, która wcześniej działała, zaczyna kończyć się błędami, proszę wrócić tutaj i potwierdzić, że Państwa lista dozwolonych odpowiada powyższym adresom, zanim zgłoszą Państwo zgłoszenie do pomocy technicznej.
</Warning>

## Których integracji to dotyczy

Lista dozwolonych adresów IP to ustawienie w *Państwa* dostawcy, a nie w Living Security. Ma zastosowanie tylko wtedy, gdy Państwa organizacja włączyła takie ograniczenie. Jeśli nie włączyli Państwo ograniczeń IP u dostawcy, nie są wymagane żadne działania.

Ci dostawcy często tego wymagają:

| Dostawca | Gdzie znajduje się ustawienie |
| - | - |
| [Abnormal Security](/pl/integrations/abnormal-security) | **IP Safelist** w tokenie API — obowiązkowe |
| [KnowBe4](/pl/integrations/knowbe4) | **Allowed IP Addresses** w tokenie Reporting API |
| [Netskope](/pl/integrations/netskope) | Lista **Custom IP**, jeśli włączono listę dozwolonych adresów IP dla tenanta |
| [Duo Admin](/pl/integrations/catalog/duo-admin-custom) | **Networks for API Access** — opcjonalne |
| [Microsoft Entra ID](/pl/integrations/microsoft-entra-id) | **Named locations** przywoływane przez politykę dostępu warunkowego (Conditional Access) |

Inni dostawcy mogą oferować podobne ustawienie. Proszę sprawdzić stronę dostawcy w [Katalogu](/pl/integrations/overview) oraz dokumentację samego dostawcy.

## Objawy brakującej lub nieaktualnej listy dozwolonych

Oba zestawy zawodzą w przeciwny sposób. Przed wprowadzeniem jakichkolwiek zmian należy dopasować objaw do zestawu.

### Połączenie się udaje, ale dane nigdy nie docierają

To charakterystyczny objaw **brakującego adresu synchronizacji**.

Poświadczenia są weryfikowane podczas nawiązywania połączenia ścieżką, która często nie podlega temu samemu ograniczeniu, więc okno połączenia w Living Security zgłasza sukces. Błąd pojawia się później, gdy uruchamia się zaplanowana synchronizacja i zostaje zablokowana.

Należy zwrócić uwagę na następujące objawy:

* Połączenie jest wyświetlane jako nawiązane, ale strumienie nie zgłaszają żadnych rekordów.
* Uruchomienia synchronizacji kończą się błędem `401 Unauthorized` lub `403 Forbidden`.
* Integracja, która działała przez miesiące, zaczyna zawodzić bez żadnej zmiany po Państwa stronie.

### Nie można w ogóle utworzyć połączenia

To charakterystyczny objaw **brakującego adresu platformy**; dotyczy on wyłącznie integracji wymienionych w sekcji [Integracje wymagające obu zestawów](#integracje-wymagaj%C4%85ce-obu-zestaw%C3%B3w).

Należy zwrócić uwagę na następujące objawy:

* Konfiguracja kończy się błędem podczas uzyskiwania tokenu dostępu. Połączenie nie zostaje utworzone.
* Błąd informuje, że nie można nawiązać połączenia z hostem, bez żadnej odpowiedzi HTTP.
* Własne dzienniki logowania lub dostępu warunkowego dostawcy pokazują zablokowane żądanie z adresu, którego nie dodano do listy dozwolonych.

<Note>
  Połączenie, z którym w ogóle nie można się skomunikować, **nie** jest problemem z poświadczeniami. Uwierzytelnianie nie miało miejsca, więc rotacja sekretu ani ponowne wygenerowanie poświadczeń klienta nie pomoże. Najczęstszą przyczyną jest źródłowy adres spoza listy dozwolonych, choć błędna nazwa hosta, błędny port lub awaria po stronie dostawcy wyglądają z naszej strony tak samo.
</Note>

Późniejsza zmiana listy dozwolonych, która usuwa adresy platformy, objawia się jeszcze inaczej: integracja, która przez tygodnie działała prawidłowo, przestaje działać w ciągu kilku minut, ponieważ kolejne odnowienie tokenu zostaje zablokowane.

## Ta strona nie dotyczy dostarczania symulacji phishingu

Adresy na tej stronie dotyczą **ruchu integracyjnego** — wywołań API, które Living Security wykonuje do Państwa połączonych systemów w celu importu danych i uruchamiania działań playbooków.

Dodanie do listy dozwolonych na potrzeby **dostarczania wiadomości e-mail z symulacji phishingu** to odrębna konfiguracja z własnymi adresami, domenami nadawcy i pakietami listy dozwolonych do pobrania. Proszę ją wykonać w **Ustawienia → Symulacja phishingu → Allowlisting**. Ten proces opisano w sekcji [Ustawienia symulacji phishingu](/pl/features/settings/phishing-simulation).

Dodanie adresów z tej strony do listy dozwolonych nie sprawi, że symulowane wiadomości phishingowe będą dostarczane, a wykonanie konfiguracji listy dozwolonych dla symulacji nie sprawi, że API dostawcy z ograniczeniami stanie się dostępne. Jeśli korzystają Państwo z obu rozwiązań, należy skonfigurować oba.

## Uzyskiwanie pomocy

Jeśli integracje nadal zawodzą po dodaniu do listy dozwolonych adresów dla Państwa regionu, proszę skontaktować się ze swoim opiekunem ds. sukcesu klienta (Customer Success Manager) lub pod adresem [support@livingsecurity.com](mailto:support@livingsecurity.com). Proszę podać nazwę dostawcy, strumień, który zawodzi, lub krok konfiguracji zakończony błędem oraz znacznik czasu, abyśmy mogli skorelować te dane z naszymi dziennikami ruchu wychodzącego.


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