Konfiguracja integracji MDR i XDR w Sophos Fusion

Integracje umożliwiają Sophos Fusion (dawniej Sophos Central) gromadzenie telemetrii z produktów Sophos i rozwiązań innych producentów w Sophos Data Lake albo udostępnianie określonych Response Actions. Kluczowy jest wybór właściwego typu integracji: Data Ingest dostarcza dane do zapytań, wykrywania zagrożeń i dochodzeń, natomiast Response Action wykonuje działanie w podłączonym produkcie. Nie każdy produkt obsługuje przepływ w obu kierunkach.

Punkt wejścia zależy od stanu produktu w tenancie. Dla rozszerzonego rozwiązania XDR/MDR obowiązuje Security Operations > Integrations > Marketplace; istniejące konfiguracje Classic znajdują się w Threat Analysis Center > Integrations. Zachowane poniżej instrukcje TAC opisują ścieżkę Classic i nie są identyczną sekwencją kliknięć dla nowego interfejsu. W przyporządkowaniu pomaga sprawdzenie aktualizacji konkretnego tenanta. Same widoczne nazwy Fusion nie dowodzą zakończenia aktualizacji produktu.

W ramach ścieżki wdrażania Endpoint ten artykuł zamyka etap integracji między produktami, przypadający między konfiguracją ochrony a odbiorem operacyjnym.

Praktyczny proces wygląda następująco: sprawdź licencję i system źródłowy, wybierz właściwą kartę produktu i konfigurację w Marketplace, nawiąż połączenie z możliwie najmniejszym zakresem uprawnień, skontroluj je w obszarze Configured i zweryfikuj za pomocą oczekiwanego zdarzenia testowego. Dopiero wtedy integrację można uznać za produkcyjną.

Osobno kontrolować połączenie i rzeczywisty przepływ danych

W aktualnym interfejsie otwiera się Security Operations > Integrations > Configured Integrations. Pod Data Ingest status pokazuje konfigurację i łączność integracji API, syslog lub Sophos. Zieleń potwierdza komunikację, nie poprawnie znormalizowane zdarzenia. Ostrzeżenie może pojawić się po 20 minutach bez komunikacji albo gdy część zasobów nie raportuje; błąd po 60 minutach lub nieudanym uwierzytelnieniu. Tekst po najechaniu wskazuje przyczynę.

Dla integracji API otwiera się nazwę i API Query Logs. Domyślnie widoczny jest ostatni dzień; można wybrać do siedmiu dni. Pod Details porównuje się parametry z właściwym tenantem źródłowym. Integracje hierarchiczne mogą mieć parent z wieloma endpointami child; sprawny fragment nie potwierdza działania wszystkich dzieci.

Następnie sprawdza się Security Operations > Integrations > Configured Data Sources. Ten osobny widok pokazuje rzeczywisty napływ logów i przypisanie do schematów. Healthy oznacza aktywność w ciągu godziny, Warning od jednej do 24 godzin, a Unhealthy ponad 24 godziny bez aktywności. To inne kryteria niż progi łączności powyżej. Rzadko wysyłające źródło ocenia się według oczekiwanej aktywności, nie uznaje za zdrowe za pomocą wymyślonego zdarzenia testowego.

Kliknięcie źródła pokazuje historię wiadomości według schematu z ostatnich 24 godzin. Podczas odbioru generuje się zatwierdzone zdarzenie w systemie źródłowym i porównuje czas, źródło, wymagane pola oraz schemat normalizacji. Advanced Search w szczegółach otwiera przygotowane wyszukiwanie identyfikatora sensora za ostatnie 24 godziny. Instrukcja wyszukiwania wyjaśnia dalsze zawężanie. Przy brakujących danych sprawdza się najpierw źródło → integracja/collector → schemat; zwykłe zdarzenie audytu nie musi powodować detection.

Export All as CSV lub Export Selected as CSV zapisuje inwentarz źródeł przez Data Exports. Kosz usuwa natomiast tylko rekord źródła, nie już odebraną telemetrię. Operacji nie można cofnąć; nadal wysyłające źródło pojawi się ponownie, a usunięcie może trwać do pięciu minut. Usunięcie nie potwierdza więc skasowania telemetrii i nie jest testem naprawy.

Widoczność, uprawnienia i aktualna lista API

Zależnie od produktu Marketplace pokazuje osobne karty Ingest i Actions. EDR bez XDR nie pokazuje kart ingestion spoza endpointów; response actions mogą nadal być widoczne. Admin i Super Admin zarządzają integracjami. Help Desk i Read-only widzą tylko konfigurację i stan. Dla Custom Roles nadaje się Integration: read i tylko potrzebne prawa create, update, delete oraz download. Przed rozszerzeniem praw dla brakującej funkcji trzeba sprawdzić licencję i rolę.

Aktualną listę XDR należy oddzielić od zachowanego niżej stanu IP Classic i uplinku collectora. Właściwy region geograficzny XDR ustala się pod Profile icon > Support settings, a nie z nazwy produktu. Lista producenta z 25 września 2026 r. wskazuje dla wywołań administracyjnych/API do produktu trzeciego:

Po zatwierdzeniu zmiany dopuszcza się tylko zakres faktycznej integracji. Lista nie potwierdza dostępności każdego produktu we wszystkich regionach i nie zastępuje kontroli aktualnie potrzebnych celów API. Wychodząca ścieżka mTLS collectora używa innych celów.

Precyzyjnie kierować powiadomienia Health

Opisane niżej zasady 24 godzin ciągłego błędu, zerowania licznika i powtarzania co 30 dni dotyczą również aktualnej pomocy Fusion z 20 października 2026 r. E-mail nie jest natychmiastowym alarmem po wspomnianych 20 lub 60 minutach.

Własną regułę odbiorców otwiera się pod General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. Po roli, administratorach/listach dystrybucyjnych i zakresie urządzeń wybiera się w Alert Types filtry Medium alert, produkt Sophos Central i kategorię Central Integrations Alert. Następnie ustawia nazwę/opis i zapisuje. Przed zapisem trzeba zaplanować dystrybucję pozostałych alertów: pierwsza własna reguła wyłącza domyślne wysyłanie wszystkich e-maili z alertami do wszystkich administratorów. Innych potrzebnych odbiorców zachowuje się dodatkowymi odpowiednimi regułami; nie powoduje się testowej awarii produkcyjnego connectora tylko w celu wymuszenia e-maila.

Następne kroki według źródła

Dla własnych źródeł HTTP Ingest, S3 i Azure opisują odrębne ścieżki transportu. Eksploatacja collectora oraz wdrożenie w chmurze uzupełniają istniejący runbook migracji. Cloud Flow Logs, telemetria sieciowa i Windows Event Logs opisują formaty i licencyjne granice schematów. Nie każda telemetria producenta jest automatycznie źródłem wymagającym SIEM.

Po aktualizacji: przywrócenie działania Response Actions

Stan na 11 października 2026 r.: rozszerzone rozwiązanie używa innego modelu wykonywania działań i uprawnień. Nie przejmuje po prostu istniejących połączeń TAC ani ich poświadczeń. Przed zmianą udokumentuj tenanty Microsoft, połączenia, włączone działania i osoby odpowiedzialne. Prawidłowe pobieranie danych przez oddzielny konektor Audit lub Graph nie jest testem reakcji.

Ponowne połączenie Microsoft 365 lub autoryzacja poświadczeń

Te kroki wymagają roli Admin lub Super Admin w Sophos Fusion oraz Microsoft 365 administrator po stronie Microsoft. W każdym oknie zgody sprawdź faktycznie żądane uprawnienia i właściwy tenant Microsoft; nie przejmuj bez weryfikacji zestawu uprawnień starej aplikacji TAC.

Jeśli poprzedniego połączenia TAC nie skonfigurowano jeszcze w nowym interfejsie, utwórz je następująco:

1. Otwórz Security Operations > Integrations > Marketplace i kafelek Actions Microsoft Graph API.
2. Wybierz Add new connection. W obszarze Add a Connection ponownie wybierz Add new connection, wpisz Name oraz w razie potrzeby Description i Tags, a następnie przejdź dalej przez Done.
3. Przyciskiem Proceed uruchom proces autoryzacji Microsoft. Nazwa taka jak M365-Response-Produktiv jest jedynie dowolnie wybraną etykietą; decydują właściwy tenant źródłowy i zatwierdzone uprawnienia.
4. W Pick an account wybierz właściwe konto administratora. Pierwsze okno Permissions requested autoryzuje nadrzędną aplikację Sophos. Po powrocie do Sophos następuje drugi krok Microsoft, dotyczący właściwego połączenia reakcji. Po sprawdzeniu uprawnień zatwierdź oba okna przez Accept. Anulowanie któregokolwiek uniemożliwia utworzenie połączenia.
5. Po powrocie sprawdź oferowane działania i zapisz tylko zatwierdzony zakres przez Save. Nowe połączenie musi pojawić się w Configured Integrations.
6. W Microsoft Entra, w Manage > All applications, użyj Refresh i sprawdź, czy nowo utworzona aplikacja reakcji jest widoczna jako włączona.

Jeśli połączenie istnieje już w Microsoft Graph API > Configured Integrations, otwórz menu z trzema kropkami przy jego nazwie i wybierz Edit Connection. Wybierz Re-Authorize Credentials i przejdź autoryzację Microsoft. Przycisk jest widoczny tylko wtedy, gdy ponowna autoryzacja jest potrzebna, i znika po jej zakończeniu. Powtórz procedurę dla każdego właściwego połączenia; naprawa jednego nie wystarcza dla wszystkich tenantów ani konfiguracji.

Zaktualizowana instrukcja z 7 października 2026 r. wyraźnie rozróżnia nadal działającą ochronę i możliwe niepowodzenia działań reakcji Microsoft do czasu ponownej autoryzacji. Jako granicę ważności dotychczasowych poświadczeń wskazuje 1 października 2027 r. Jeśli potrzebujesz Actions, nie czekaj do tej daty: działanie trzeba potwierdzić teraz.

Odbiór obejmuje właściwą aplikację Entra, oczekiwane połączenia i włączone działania oraz zatwierdzony test na dedykowanym koncie. Użyj wyłącznie odwracalnej zmiany udokumentowanej dla aktualnej akcji. Opisana poniżej para Classic Block user sign-in / Allow user sign-in nie dowodzi, że każda nowa akcja ma tę samą nazwę lub sposób cofnięcia. Unieważnionych sesji nie można odtworzyć. W szczegółach akcji View Executions > History pokazuje historię; dodatkowo sprawdź rzeczywisty stan w Microsoft. Sama zgoda ani udany wpis wykonania nie zastępują tej kontroli.

Dodanie Sophos Firewall (Actions) tylko przy braku połączenia

Po aktualizacji produktu najpierw otwórz sprawę i sprawdź dostępność działań Sophos Firewall. Jeśli są dostępne, nie potrzeba nowego połączenia. Jeśli ich brakuje:

1. Otwórz Security Operations > Integrations > Marketplace.
2. Wyszukaj i otwórz Sophos Firewall (Actions).
3. Wybierz Add new connection i zapisz przez Save.

To połączenie nie wymaga poświadczeń. Następnie działania reakcji firewalla są dostępne ze spraw: na przykład blokowanie szkodliwych adresów IP, domen lub URL. Analitycy MDR mogą wykonywać je w ramach zatwierdzonych ustawień reakcji; użytkownicy XDR mogą uruchamiać je samodzielnie ze sprawy. Dostępność sprawdź bez blokowania celów produkcyjnych. Test skutku jest oddzielną, zatwierdzoną zmianą z wcześniej ustaloną procedurą cofnięcia właściwą dla produktu.

Celowe wyłączanie nowych Actions zamiast pochopnego usuwania połączeń

Dla Actions w rozszerzonym rozwiązaniu istnieje udokumentowany przełącznik: w Security Operations > Integrations > Marketplace, Configured > Actions, otwórz daną akcję i wyłącz ją w obszarze Enable/disable integration. Nie jest to uniwersalny przełącznik dla wszystkich konektorów Data Ingest. Wyłączenie nie cofa zmian wykonanych już w systemie źródłowym.

Delete Integration usuwa powiązane połączenia i warunki oraz przywraca początkową konfigurację akcji. Usunięcie jedynego połączenia również usuwa powiązane z nim warunki. Dlatego wcześniej zabezpiecz lub udokumentuj połączenia i warunki. Do cofnięcia działań testowych nadal służy konkretna procedura Microsoft lub firewalla, a nie usunięcie konektora.

Automatyzacje XDR: rozróżnienie Classic REST i GraphQL

Stan API to uzupełnienie z 9 października 2026 r., a nie wsteczna obietnica dotycząca wrześniowego uruchomienia. Nowe integracje XDR i procesy zapisujące dane XDR w Fusion powinny używać nowych GraphQL APIs. Trzeba je odróżnić od połączenia API w Marketplace: jego wywołania REST mogą nadal trafiać do dostawcy zewnętrznego.

Dotychczasowe Cases REST API i Detections REST API noszą teraz nazwę Classic XDR APIs i są wycofywane. Detections REST API jest już read-only. Cases REST API pozostaje dostępne dla istniejących integracji; również ono ma później przejść w tryb read-only. Następnie oba API mają udostępniać dane historyczne do czasu usunięcia. Ten stan dokumentacji nie podaje konkretnej daty wyłączenia. Nie usuwaj więc zbiorczo istniejących integracji ani nie zmieniaj ich hostów tylko ze względu na nazwę Fusion.

Dla każdej automatyzacji zapisz API, operacje odczytu i zapisu, okres danych, tenant, uprawnienia i obsługę błędów. W istniejących klientach osobno sprawdź, czy oczekiwane są dane bieżące czy historyczne i czy proces zapisu nadal próbuje korzystać z Classic Detections. Przejście na GraphQL wymaga implementacji mapowania pól, paginacji, uwierzytelniania, uprawnień i obsługi błędów według konkretnego nowego schematu oraz porównania w izolowanym teście. Ten artykuł celowo nie podaje wymyślonych punktów końcowych, nazw mutacji ani payloadów. Inwentaryzacja jest zakończona, gdy każdy klient ma właściciela i udokumentowaną decyzję o dalszej eksploatacji lub migracji; nie jest to jeszcze pomyślny test migracji API.

Który GraphQL API jest właściwy dla klienta?

Publikacja z 18 września 2026 r. obejmowała pięć API GraphQL o różnych zadaniach:

• Detections v2: wyszukiwanie i edytowanie Detections z endpointów, sensorów sieciowych i innych źródeł.
• Cases v2: zarządzanie Cases oraz Evidence, komentarzami, plikami i linkami.
• Threat Timeline v2: wyszukiwanie powiązań procesów dla maksymalnie 100 procesów w jednym wywołaniu.
• Events v1: pobieranie szczegółów zdarzeń na podstawie znanych identyfikatorów Event-ID.
• Live Endpoint Search v1 (LES): wykonywanie zapytań w stylu osquery na połączonych endpointach oraz pobieranie wyników i danych Telemetry.

Live Discover REST nie jest objęty wycofywaniem Classic Cases/Detections APIs. Istniejące integracje Live Discover REST mogą nadal działać; przejście na LES jest opcjonalne. Ścieżka na żywo i historyczny XDR Query API służą do różnych zadań. Rozgraniczenie API Live Discover wyjaśnia również wybór celów LES oparty na sesjach. Także Endpoint API pod /endpoint/v1 i jego Device Migration nie są przenoszone na GraphQL z powodu tego wycofywania XDR.

Od 12 października 2026 r. opublikowane jest również Search GraphQL API v1 do historycznych wyszukiwań QL. Udostępnia createSearch, getOrCreateSearch, search i searchResults; Odpytywanie Data Lake Sophos Fusion przez Search GraphQL API opisuje kontrakt żądania, status wykonania, strony wyników i weryfikację migracji SQL. Data Lake Search pozostaje ścieżką interaktywną; XDR Query API nadal jest dostępne. Nowe API nie wymusza natychmiastowego przejścia i nie jest procesem LES dla endpointów na żywo. Dla Assets i Entity Graph pozostają otwarte osobne kontrole referencji i tenanta: wzmianka w przewodniku Cases nie jest pełną zgodą na implementację.

Weryfikacja konkretnego kontraktu migracji

Zmiana nie polega na wymianie adresu URL bez modyfikacji klienta. Dla Cases, Detections i opcjonalnie LES należy porównać ich własne procesy, zamiast stosować jeden wspólny przepis przejścia z REST na GraphQL:

• GraphQL zwraca tylko wybrane pola. Klient sprawdza zarówno status HTTP, jak i tablicę errors oraz pola statusu właściwe dla operacji; HTTP 200 może zawierać błąd zapytania. Wymagane pola zagnieżdżone i dane czasowe z seconds/nanos należy świadomie wybierać i przetwarzać.
• W Detections detectionSearch zastępuje proces REST obejmujący uruchomienie zapytania, sprawdzenie statusu i pobranie wyników. Małe zbiory wyszukiwania używają offset/limit, a duże — zwróconego search_id z detectionPoll. Uzgodnij wszystkie części i łączną liczbę. Filtry należy sprawdzać pojedynczo jako predykaty QL; wyszukiwanie hosta oczekuje identyfikatora, a nie po prostu nazwy urządzenia. Dla REST type ani reputacji Intelix nie ma gwarantowanego identycznego odpowiednika.
• Detection Severity w REST i GraphQL ocenia odrębne zbiory danych według odrębnych modeli. REST używa skali liczb całkowitych do 10, a GraphQL metadata.severity — skali od 0 do 1. Nie przeliczaj przez dzielenie. Progi należy ponownie ocenić merytorycznie na podstawie odpowiednich danych. Case.severity z wartościami 2/4/6/8/10 to jeszcze inna skala.
• W Cases klient API używa UUID id, a nie czytelnego shortId w formacie CSE#####. Stare identyfikatory spraw REST nie są tłumaczone, a stare Cases nie stają się dostępne przez nowe API. Wymagane dowody dotyczące dawnych spraw należy zabezpieczyć przed przełączeniem przy użyciu potwierdzonej dotychczasowej ścieżki pobierania; nie oznacza to ani istnienia uniwersalnego przycisku eksportu, ani przejęcia historii.
• Typy spraw, statusy i Verdicts należy rozwiązywać na podstawie dynamicznych, zależnych od licencji danych referencyjnych tenanta i regularnie je aktualizować. assigneeId oczekuje Subject ID lub obsługiwanej @mention, a nie adresu e-mail. Niemożliwy do rozwiązania assigneeSubject może mieć wartość null; sposób wyświetlania wymaga wtedy świadomie dobranego zamiennika.
• caseEvidence zwraca identyfikatory powiązań, a nie gotowe payloady Evidence. Detections należy dodatkowo pobierać przez detectionRetrieveById z argumentem zapisanym dokładnie jako iDs, a Events — przez ich niezmienione Resource Names. Zależności od Asset i Entity Graph pozostają otwarte do czasu odpowiedniej weryfikacji dokumentacji referencyjnej i tenanta. Identyfikatory Detection, Event, Asset i Entity Graph nie są zamienne; wejście do Entity Graph dla sprawy używa jej UUID jako INVESTIGATION, a nie shortId.
• Paginacja Cases używa offsetu albo kursora, a nie obu w jednym żądaniu. Dla zmieniającej się listy preferuj kursor i przekazuj go bez zmian. keyFindings jest dokumentem typowanym i jest zwracany przy pobieraniu pojedynczej sprawy, a nie na liście Cases. Dotychczasowe filtry overviewContains i escalated nie mają bezpośredniego odpowiednika; przed przełączeniem podejmij wyraźną decyzję dotyczącą wymaganych funkcji.
• Nie ma deleteCase zastępującego REST DELETE. Zamknięcie, w razie potrzeby z Verdict wymaganym przez typ sprawy, i późniejsza opcjonalna archiwizacja to oddzielne kroki. W sprawach MDR zarządzanych przez dostawcę zakres faktycznie dozwolonych pól zapisu jest węższy i należy go wcześniej sprawdzić.

Pilotaż musi odpowiedzieć na to samo pytanie merytoryczne we właściwym tenancie, z możliwymi do prześledzenia identyfikatorami, pełną paginacją i przeanalizowanymi błędami. Dodatkowe funkcje GraphQL, takie jak komentarze, pliki, linki, reguły, szablony oraz Split/Merge, są odrębnymi rozszerzeniami, a nie warunkiem każdego przełączenia. Brakujące odpowiedniki pól lub nieustalona historia pozostają otwartą decyzją dotyczącą klienta; nie wolno ich pomijać, zakładając równoważność.

Zakres: XDR, MDR i licencje

Integracja nie zastępuje licencji XDR ani MDR. XDR udostępnia funkcje analityczne, dzięki którym własny zespół bezpieczeństwa może badać dane w Threat Analysis Center i Data Lake. MDR uzupełnia je o zarządzaną usługę Sophos. Dostępność integracji w tenancie zależy od umowy z Sophos, produktu, typu integracji oraz, w stosownych przypadkach, licencji produktu innego dostawcy.

Jeśli potrzebujesz dłuższego przechowywania danych lub własnych źródeł danych, artykuł Sophos Next-Gen SIEM wyjaśnia, jak sprawdzić opcjonalny dodatek i zinwentaryzować okresy przechowywania dla każdego źródła.

Stwierdzenie, że niektóre integracje są bezpłatne, nie oznacza, że bezpłatny jest cały Marketplace. W modelu MSP Flex obowiązują oddzielne pakiety Integration License Pack dla kategorii takich jak Endpoint, Network, Email i Firewall. Dotychczasowa zasada MSP Flex wskazywała, że przy licencji XDR integracje Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security i Microsoft 365 audit appliance nie wymagały dodatkowego pakietu. Ta zasada dotyczy wyłącznie klientów MSP Flex. Cloud Optix jest już w niej tylko wpisem historycznym: jego End of Life 30 września 2026 r. wyklucza nowe planowanie produkcyjne z tą usługą. Zamiast zakładać ogólny bezpłatny zakres, sprawdź uprawnienia w tenancie i umowie.

Licencje mogą być wymagane także po stronie podłączanego systemu. Strony Sophos podają sprzeczne informacje o Microsoft 365: strona przeglądowa określa dzienniki audytowe Management Activity jako dostępne dla wszystkich klientów Microsoft 365, natomiast konkretna instrukcja konfiguracji wymaga Purview Audit (Standard lub Premium), jednej z wymienionych tam licencji użytkownika i aktywnego audytu. Podczas konfiguracji należy przyjąć te szczegółowe wymagania. Detekcje dostarczane przez Graph Security V2 zależą dodatkowo od zakresu licencji Microsoft i dostępnych funkcji Defender XDR. Dla Microsoft 365 Response Actions w ścieżce Classic/TAC Sophos nie wskazuje wymagań licencyjnych Microsoft; potrzebny jest jednak administrator Microsoft 365 oraz wymienione niżej, wyraźnie oznaczone jako Classic, uprawnienia Graph. Dla Actions w rozszerzonym rozwiązaniu obowiązują natomiast wymagania opisane powyżej i uprawnienia faktycznie żądane podczas dwuetapowej autoryzacji; lista Classic nie definiuje nowej zgody.

Cloud Optix po End of Life: oddzielne traktowanie telemetrii i CSPM

Sophos Cloud Optix osiągnął End of Life 30 września 2026 r. Po tej dacie usługa nie zbiera nowych danych, nie tworzy ustaleń ani nie przekazuje telemetrii do MDR lub XDR. Według stanu na 11 października 2026 r. wcześniejsze zalecenie eksportu i równoległego przełączenia przed EOL nie jest już wykonalnym krokiem przyszłym.

Sprawdź teraz, które środowiska AWS, Azure, GCP lub OCI były wcześniej podłączone wyłącznie przez Cloud Optix i które mają już bezpośrednie połączenie z rozszerzonym rozwiązaniem XDR/MDR. Bezpośrednie integracje chmurowe trzeba skonfigurować dla każdej platformy; aktualizacja produktu nie wykonuje tego automatycznie. Bez sprawdzonego nowego połączenia nie wolno deklarować nieprzerwanego pokrycia telemetrii po 30 września. Jeśli tenant nie przeszedł jeszcze aktualizacji albo brakuje kafelka produktu, wyjaśnij stan z zespołem opiekującym się kontem Sophos lub zespołem partnerskim.

Bezpośrednia integracja API chmury nie jest tym samym co Syslog Data Collector działający w AWS, Azure lub GCP. W Marketplace wybierz integrację dla potrzebnego strumienia danych chmurowych, sprawdź konkretne uprawnienia źródła, a następnie potwierdź dane i oczekiwane detekcje. Dowód musi wskazywać konto chmurowe, źródło danych i przedział czasu; sam zielony status połączenia nie wystarczy.

Cloud Security Posture Management (CSPM) nie jest przejmowane: ocena stanu konfiguracji chmury, raporty zgodności z benchmarkami i ustalenia dotyczące Configuration Drift nie są obiecywanymi funkcjami nowych integracji telemetrii. Udokumentuj tę potrzebę oddzielnie i uzgodnij rozwiązanie zastępcze oraz pozostałe uprawnienia umowne z zespołem konta. Do nowego systemu nie są też migrowane raporty Cloud Optix, historia ustaleń, dowody zgodności ani dane inwentaryzacyjne. Zabezpiecz istniejące eksporty i sprawdź ich kompletność; możliwość późniejszego eksportu lub odtworzenia nie jest tutaj potwierdzona.

Typy integracji i wymagane dane dostępowe

REST API

Integracja API pobiera dane z usługi chmurowej producenta albo wykonuje w niej działanie typu Response Action. W zależności od produktu kreator konfiguracji może wymagać identyfikatora tenantu lub organizacji, adresu URL API, identyfikatora klienta, klucza tajnego klienta, tokenu bądź certyfikatu. Integracje API nie wymagają urządzenia Sophos.

W przypadku części integracji poświadczenia wpisuje się bezpośrednio w kreatorze. Inne wymagają poświadczenia Integration Credential wielokrotnego użytku. Obsługę tej funkcji rozpoznasz po opcji wyboru istniejącego lub utworzenia nowego poświadczenia w kreatorze konektora. Integration Credential Manager obsługuje tylko ograniczoną część integracji API, więc nie każdy sekret można wykorzystać centralnie.

Log collector

Poniższy opis appliance dotyczy ścieżki Classic SVA. W rozszerzonym rozwiązaniu XDR dane Syslog zbierają XDR Data Collectors z własnymi wymaganiami dotyczącymi zasobów i sieci. Nie wolno przenosić starych minimów SVA na nową VM. Migracja przygotowuje konfiguracje, ale nie uruchamia gotowego zamiennika. Artykuł Przełączenie Syslog SVA i eksploatacja XDR Data Collector wyjaśnia warianty adresacji, wyłączone ustawienia i bezpieczne przełączenie. NDR nie jest przy tym migrowany automatycznie.

W integracji Log Collector system źródłowy eksportuje zdarzenia przez Syslog do Sophos appliance. Log Collector przetwarza dane i przesyła je do Sophos Data Lake. Appliance działa na ESXi, Hyper-V, AWS lub Nutanix albo na odpowiednim sprzęcie Dell, NUC lub OnLogic. Dla ESXi lub Hyper-V przydziel co najmniej 4 CPU, 16 GB RAM i 160 GB miejsca na dysku; obsługiwane są ESXi 6.7 Update 3 z wirtualnym sprzętem VM w wersji 11 lub nowszej oraz Hyper-V na Windows Server 2016 lub nowszym. Sophos zarządza aktualizacjami systemu i zabezpieczeń; nie instaluj dodatkowego agenta Sophos ani antimalware. Zwiększ zasoby przy dużym wolumenie lub wielu integracjach i przed akceptacją sprawdź DNS, proxy oraz wymagane wyjątki portów i domen. Skonfiguruj produkt zewnętrzny tak, aby wysyłał dane do tej appliance, a nie do dowolnego serwera Syslog.

Jedno urządzenie może obsługiwać wiele integracji. Mimo to dla każdego produktu należy skonfigurować protokół, port, format i źródło zgodnie z jego instrukcją integracji. Sam zielony status urządzenia nie dowodzi jeszcze, że dociera właściwy typ zdarzeń.

Produkty Sophos

Produkty takie jak Sophos Firewall i Sophos NDR mają własne procedury konfiguracji. Sophos NDR i integracje Log Collector wymagają Integration Appliance, ale niekoniecznie klasycznej VM. Sama integracja REST API nie wymaga appliance. Dostępność sprawdzaj w Marketplace właściwej dzierżawy: kafelek produktu pokazuje oferowane metody i otwiera odpowiedni kreator.

Bezpieczne rozgraniczenie obciążenia NDR i współdzielonej appliance

Poniższa topologia współdzielonej appliance dotyczy Classic SVA/TAC, a nie nowego XDR Data Collector. Nowy kolektor zastępuje część Syslog; NDR pozostaje oddzielnie eksploatowanym obciążeniem appliance i nie jest przenoszony na nowy kolektor.

Na jednej appliance dozwolona jest tylko jedna integracja Sophos NDR. Ta sama appliance może dodatkowo obsługiwać wiele integracji innych producentów opartych na appliance jako Log Collectors. Dlatego przed każdą zmianą rozwiń wpis appliance w Configured > Integration Appliances i sprawdź wszystkie przypisane integracje. Ani wartość Integrations, ani zielony status appliance nie zastępują tej kontroli.

Ukierunkowany restart NDR przerywa działanie sensora NDR, podczas gdy Log Collectors nadal pracują. Restart lub Shutdown całej VM przerywa natomiast działanie NDR i wszystkich Log Collectors na tej appliance. Zaplanuj takie działania w oknie serwisowym, wcześniej udokumentuj stan wszystkich obciążeń, a po zmianie sprawdź każde z osobna. Procedurę opisuje artykuł Bezpieczna obsługa Sophos NDR Appliance i sensora.

Opcja Delete w menu appliance nie usuwa wyłącznie pojedynczej integracji. Nie usuwaj appliance, dopóki jest do niej przypisany NDR lub Log Collector. Pozycja menu nie oznacza również, że wdrożona VM zostanie usunięta ani że dane już zapisane w Data Lake zostaną skasowane. Przed wycofaniem uzgodnij przypisania, retencję danych, usunięcie zasobów platformy, ścieżkę odtworzenia i kontrolę końcową. Do tego czasu appliance pozostaje zachowana.

Przed konfiguracją

1. Zaloguj się do Sophos Fusion jako Admin lub Super Admin. Sophos wskazuje te role jako wymaganie ogólnej konfiguracji.
2. Sprawdź w produkcie innego dostawcy wymaganą licencję, rolę administratora, funkcję API lub eksport Syslog.
3. Zdecyduj, czy potrzebujesz Data Ingest, Response Action, czy obu typów. Integracja typu Response Action nie dostarcza automatycznie telemetrii potrzebnej do dochodzenia.
4. Jeśli to możliwe, utwórz dla dostępu API dedykowaną aplikację lub konto usługi. Nadaj wyłącznie uprawnienia wymagane w instrukcji produktu oraz udokumentuj właściciela, termin ważności i sposób rotacji sekretu.
5. Jeśli produkt zewnętrzny wymaga listy dozwolonych źródłowych adresów IP dla administracyjnych wywołań API, najpierw ustal region Central w My Environment > Installers: wskaż łącze pobierania w Endpoint Protection lub Server Protection i odczytaj region z wyświetlonego adresu URL, na przykład eu-central-1. Następnie dopuść tylko adresy tego regionu z poniższej tabeli. Są to źródła wywołań API Sophos, a nie cele ruchu wychodzącego Integration Appliance.
6. Dla urządzenia integracyjnego sprawdź jego własną trasę ruchu wychodzącego, DNS i ewentualny serwer proxy zgodnie z wymaganiami urządzenia.
7. Zaplanuj powtarzalne i bezpieczne zdarzenie testowe. Logowanie lub zdarzenie audytowe nadaje się lepiej niż rzeczywista próba użycia złośliwego oprogramowania.

Źródłowe adresy IP do listy dozwolonych API

Ta tabela przedstawia zestaw adresów IP Classic sprawdzony 14 września 2026 r. Należy go odróżnić od aktualnej listy dozwolonych XDR powyżej; sam w sobie nie jest wystarczającą podstawą do zmiany produkcyjnej listy dozwolonych.

Przed zmianą sprawdź generację integracji, region tenantu i pełny zestaw wymaganych adresów IP względem aktualnych informacji Sophos. W razie rozbieżności nie używaj starych wartości ani nie łącz regionów. Zleć sprawdzenie przypisania regionu i zmiany zgodnie z własnym procesem zatwierdzania, zezwól tylko na wymagany zakres, a następnie zweryfikuj właściwą integrację za pomocą bezpiecznej synchronizacji API lub zdarzenia testowego. W zmianie zapisz stan początkowy, zatwierdzenie, wyniki i sposób przywrócenia.

Sophos oznacza obecnie zarówno wiersz São Paulo, jak i Dubaj jako sa-east-1. Rozróżniaj je według lokalizacji dzierżawy i zestawu IP; nie łącz regionów. Zapisz zatwierdzoną listę w zmianie.

Dodawanie integracji w Marketplace

1. Otwórz Threat Analysis Center > Integrations > Marketplace.
2. Wyszukaj producenta lub produkt. Jeśli widzisz podobne pozycje, otwórz stronę produktu i sprawdź kategorię, nazwę produktu, typ integracji oraz przeznaczenie. Na przykład Cisco Meraki i Fortinet FortiAnalyzer są dostępne zarówno w wariancie API, jak i Log Collector.
3. Otwórz wybraną integrację.
4. Wybierz potrzebny typ, na przykład Data Ingest, i kliknij Add Configuration.
5. Wykonaj kroki Integration setup. W integracjach API wpisuje się dane z systemu źródłowego lub udziela zgody OAuth. W integracjach Log Collector tworzy się albo wybiera urządzenie, a następnie kieruje na nie eksport Syslog z systemu źródłowego.
6. Jeśli podczas dodawania pierwszej integracji Sophos poprosi o domeny wewnętrzne i zakresy adresów IP, podaj wyłącznie własne zakresy wewnętrzne. Dane te oznaczają własne adresy, grupują powiązane alerty i zapobiegają wyszukiwaniu informacji u podmiotów trzecich; nie są listą dozwolonych adresów źródłowych Sophos.
7. Zapisz konfigurację i w pełni dokończ zewnętrzne okno zgody. Zanotuj nazwę integracji, tenant źródłowy, osobę odpowiedzialną i datę następnej rotacji poświadczeń.
8. Otwórz Threat Analysis Center > Integrations > Configured. Nowa konfiguracja musi być tam widoczna. W tym miejscu można ją później monitorować lub edytować. Pole Connection Method wskazuje też, czy podczas diagnostyki należy badać ścieżkę API, czy Log Collector.

FortiAnalyzer: alerty API nie obejmują wszystkich odebranych zdarzeń Syslog

W przypadku Fortinet FortiAnalyzer konektor API obsługuje Appliance i VM Subscription, ale nie FortiAnalyzer Cloud. Odczytuje wyłącznie alerty wygenerowane przez FortiAnalyzer z /eventmgmt/adom/<ADOM>/alerts; <ADOM> oznacza odpowiednią domenę administracyjną systemu źródłowego. Zdarzenie Syslog jedynie odebrane przez FortiAnalyzer nie staje się automatycznie takim alertem. Jeśli mają być pobierane zdarzenia Syslog, należy zamiast tego sprawdzić integrację FortiAnalyzer Log Collector lub integrację Fortinet Fortigate dla konkretnego źródła. Decyzję podejmuje się przed konfiguracją konektora, a nie dopiero przy pozornej luce w danych.

Konektor API usuwa dane niezgodne z formatem, a następnie odrzuca określone typy alertów: komunikaty o tunelach VPN (vpntunnel), zablokowane żądania WWW do nieocenionych celów, komunikaty o skanowaniu adresów IP lub portów, połączenia wyłączone z inspekcji SSL na podstawie listy dozwolonych lub adresu, komunikaty Link Monitor o wyłączonych lub włączonych interfejsach, ostrzeżenia o pełnym Memory Log oraz Disk Quota Alert/Warning i zablokowane niebezpieczne połączenia SSL. Brak takiego alertu nie oznacza więc automatycznie błędu uwierzytelniania lub transportu. Przypisanie typu wykorzystuje dopasowanie wzorca, gdy message jest niepuste, a w przeciwnym razie pola FTNTFGTattack, ad.subtype i cat; przy braku dopasowania pole message jest oczyszczane. Odebrany tytuł alertu nie stanowi automatycznie pełnego mapowania MITRE.

Na potrzeby odbioru wybierz nieszkodliwe, zatwierdzone zdarzenie, które w sposób potwierdzony generuje alert FortiAnalyzer, na przykład zmianę konfiguracji przewidzianą do tego we własnym Event Handler. Najpierw potwierdź alert, ADOM i czas w FortiAnalyzer oraz upewnij się, że format i typ alertu nie są odrzucane. Następnie potwierdź ten sam alert we właściwym tenancie za pomocą ścieżki wyszukiwania Sophos potwierdzonej dla tego konektora. Dowolne testowe logowanie lub wysłany wiersz Syslog bez alertu FortiAnalyzer nie jest prawidłowym testem pobierania przez API. Jeśli oczekiwanego alertu brakuje, najpierw sprawdź generowanie alertów, ADOM, format i filtry typów, a następnie poświadczenia i połączenie; nawet pomyślne pobranie nie gwarantuje powstania detekcji Sophos ani sprawy.

Kontrola działania i testowanie

Zapisana konfiguracja nie jest jeszcze dowodem działania. Sprawdź kolejno połączenie, przepływ danych i ich zawartość:

1. Stan połączenia: otwórz pozycję w obszarze Configured, a w przypadku urządzenia — jego status. Dla Log Collector kolor czerwony oznacza, że integracja nie działa, żółty — że działa z błędami, a zielony — że zdarzenia są odbierane i przetwarzane bez widocznych problemów.
2. Zdefiniowane zdarzenie testowe: wygeneruj w systemie źródłowym nieszkodliwe zdarzenie, które na pewno rejestruje dana kategoria API lub Syslog, na przykład zmianę administracyjną albo testowe logowanie. Zapisz czas, użytkownika i źródło.
3. Potwierdzenie w Data Lake: po upływie opóźnienia właściwego dla produktu wyszukaj zdarzenie w Threat Analysis Center > Live Discover. Użyj kategorii lub zapytania Live Discover wskazanego w instrukcji konkretnego produktu; jeśli Sophos nie dokumentuje takiego zapytania dla konektora, ten ogólny proces nie może obiecywać uniwersalnego testu za pomocą zapytania. Runbook Live Discover wyjaśnia sposób wykonywania zapytań, granice Data Lake i kontrolę wyników. Sprawdź znacznik czasu, tenant, użytkownika i typ zdarzenia. Jeden rekord potwierdza połączenie, a wiele aktualnych rekordów z odpowiedniego okresu — ciągły przepływ danych.
4. Granica detekcji: nie każde pobrane zdarzenie tworzy detekcję lub sprawę. Data Ingest udostępnia dane do analizy, ale detekcje powstają tylko wtedy, gdy zadziała odpowiednia logika wykrywania. Najpierw przetestuj więc pobieranie danych w Data Lake i nie oczekuj automatycznie alertu.
5. Response Action: użyj zatwierdzonego konta testowego i udokumentuj stan początkowy. Dla Microsoft 365 odwracalnym testem jest użycie Block user sign-in, a następnie Allow user sign-in; operacji Revoke all current sessions nie można cofnąć. Pamiętaj również, że Entra Connect Sync może później ponownie włączyć zablokowane konto hybrydowe, ustawienie reakcji MDR ogranicza działania analityków Sophos, a nazwy poszczególnych Inbox Rules w Response Actions rozróżniają wielkość liter.

Alerty o stanie nie służą do natychmiastowych testów. Okres 24 godzin zaczyna się przy pierwszym komunikacie o błędzie i prowadzi do alertu o średnim poziomie ważności tylko wtedy, gdy błąd utrzymuje się nieprzerwanie. Zielony stan albo potwierdzenie alertu zeruje odliczanie. Jeżeli problem nadal występuje, alert pojawia się później ponownie raz na 30 dni.

Microsoft 365: trzy oddzielne integracje

„Podłączenie Microsoft 365” nie jest pojedynczym przełącznikiem. Poniższa tabela opisuje oddzielne zadania w Classic/TAC-Marketplace, w tym ograniczenie tamtejszych Response Actions. Dla rozszerzonego rozwiązania obowiązuje opisany powyżej proces Microsoft Graph API Actions z własnymi połączeniami i nową zgodą; ograniczenie Classic do jednego środowiska nie jest ograniczeniem nowego procesu:

Dla Response Actions w ścieżce Classic/TAC Sophos wymienia następujące uprawnienia Microsoft Graph: User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite i User.Read. W przypadku MDR wybrana opcja reakcji MDR nadal określa, czy analitycy mogą działać bez zatwierdzenia. W hybrydowym środowisku Entra ID usługa Microsoft Entra Connect Sync może później ponownie włączyć logowanie zablokowane w Central.

Przykład: bezpieczne podłączenie Management Activity

1. Upewnij się, że audyt w Microsoft 365 jest aktywny. Połączenie musi zatwierdzić administrator Microsoft 365.
2. Otwórz Threat Analysis Center > Integrations > Marketplace i wybierz Microsoft - Office 365 Management Activity API.
3. W sekcji Data Ingest (Security Alerts) kliknij Add Configuration.
4. Sprawdź informację o audycie, kliknij Save and continue, a następnie Proceed w obszarze Connect to Microsoft 365.
5. Zaloguj się na przeznaczone do tego konto administratora Microsoft, sprawdź wymagane uprawnienia i zatwierdź je przyciskiem Accept. Zamknij potwierdzenie przyciskiem Close.
6. Skontroluj pozycję w Sophos Fusion. W obszarze Live Discover > Query musi być widoczna kategoria Microsoft 365 audit data. Następnie wygeneruj możliwe do prześledzenia zdarzenie audytowe i wyszukaj je za pomocą udostępnionego zapytania.

Microsoft nie gwarantuje stałego czasu pojawienia się poszczególnych zdarzeń w dzienniku audytowym. Opóźniony wpis nie oznacza więc automatycznie błędu integracji. Po pierwszym włączeniu audytu dane mogą pojawić się dopiero po maksymalnie 12 godzinach.

W przypadku Graph Security V2 pierwsza synchronizacja następuje około pięciu minut po udostępnieniu danych w Microsoft Defender Security Center. Jeśli usługa Alerts and Incidents musi najpierw zostać przygotowana, sam ten krok po stronie Microsoft może potrwać około godziny.

Wyłączanie lub wycofywanie integracji

Nie istnieje jeden przełącznik Disable dla wszystkich typów integracji. Dostępne działania różnią się zależnie od produktu i Connection Method. Nie zakładaj więc istnienia uniwersalnego przycisku:

1. Otwórz Threat Analysis Center > Integrations > Configured, wybierz konfigurację i udokumentuj stan, nazwę, tenant źródłowy, urządzenie oraz poświadczenie.
2. W przypadku integracji API najpierw kontrolowanie zatrzymaj pobieranie danych albo użyj opcji Disable lub Delete, jeżeli udostępnia ją konkretna strona produktu. Następnie w systemie źródłowym wycofaj zgodę OAuth albo wyłącz dedykowaną aplikację bądź token. W przypadku Response Actions uniemożliwi to wykonywanie kolejnych działań z Central.
3. W przypadku integracji Log Collector usuń konfigurację celu Syslog w systemie źródłowym. Nie usuwaj współdzielonego urządzenia Sophos, dopóki korzystają z niego inne integracje.
4. Usuń konfigurację w Central tylko wtedy, gdy spełnione są wymagania dotyczące retencji, audytu i zarządzania zmianą. Usunięcie konfiguracji nie gwarantuje skasowania danych już pobranych do Data Lake. Dlatego wcześniej wyjaśnij zasady retencji i usuwania na podstawie wymagań Data Lake i zgodności obowiązujących w tenancie.
5. Sprawdź, czy nie napływają nowe zdarzenia i nie można wykonywać nieoczekiwanych Response Actions. Następnie usuń niepotrzebne już sekrety, certyfikaty, konta usług i wpisy na listach dozwolonych.

Podczas krótkiej przerwy serwisowej w integracji Log Collector zatrzymaj eksport Syslog, ale nie usuwaj współdzielonego urządzenia. W integracjach API i Response poświadczenie można zablokować na czas prac tylko wtedy, gdy wcześniej zweryfikowano możliwość ponownego aktywowania tej samej konfiguracji. W przeciwnym razie użyj wyłącznie procedury dostępnej dla konektora Disable, Delete lub Reconnect. Zablokowane albo wygasłe poświadczenie nie jest uniwersalnym sposobem wycofania i powoduje błędy synchronizacji.

Systematyczne zawężanie typowych błędów

Integracja API nie synchronizuje danych

Otwórz Configured, sprawdź Connection Method i przeczytaj dokładny błąd. Najpierw usuń w produkcie zewnętrznym Invalid credentials, insufficient permission i expired credentials: sprawdź identyfikatory, sekrety, ważność tokenów, certyfikaty i uprawnienia API. Network not reachable i invalid domain wymagają też kontroli DNS, proxy, zapory i stanu usługi. Przy request throttling dostawca ograniczył API; wielokrotne natychmiastowe zapisywanie może pogorszyć problem. W Microsoft HTTP 401 oznacza nieprawidłowe uwierzytelnienie, a 429 i 509 — ograniczanie.

Log Collector pozostaje czerwony lub żółty

Kolor czerwony oznacza awarię, a żółty — działanie z błędami. Sprawdź zasoby maszyny wirtualnej, sieć i DNS, dostęp wychodzący oraz ścieżkę Syslog od systemu źródłowego do urządzenia. Komunikat no events received since last container restart wskazuje, że od restartu kontenera nie odebrano zdarzeń Syslog. no received events in last 10 mins może oznaczać przerwany eksport albo po prostu źródło, które wysyła zdarzenia rzadko. W przypadku błędów przesyłania urządzenie buforuje dane na dysku. Jeśli przesyłanie pozostaje zablokowane, a dysk się zapełni, starsze dane mogą zostać odrzucone.

Microsoft 365 nie dostarcza danych

Dla Management Activity musi być aktywny audyt Microsoft 365, a w obszarze Office 365 Management APIs właściwość Enabled for users to sign-in? = Yes musi być aktywna. Uwzględnij czas rozruchu do 12 godzin po włączeniu audytu. W przypadku Graph Security V2 sprawdź dostęp do Defender XDR, zgodę, przygotowanie usługi alertów i dostępny zakres licencji Microsoft. Stary interfejs Graph Security API nie jest już rozwiązaniem awaryjnym.

Brak alertu o stanie pomimo awarii

Najpierw sprawdź, czy jest to integracja Data Ingest i czy od pierwszego komunikatu o błędzie problem trwa nieprzerwanie co najmniej 24 godziny. Przejściowy zielony stan lub potwierdzenie alertu zeruje odliczanie. Domyślnie wiadomość e-mail otrzymują wszyscy administratorzy Central; własne Notification Rules mogą zmienić ten sposób dystrybucji.

Zasady bezpieczeństwa i eksploatacji

• Używaj dedykowanych aplikacji i sekretów zamiast osobistych kont administratorów.
• Nadawaj tylko uprawnienia API wymagane przez konkretną integrację. Integracje reakcji z natury wymagają uprawnień do zapisu i powinny być zatwierdzane bardziej rygorystycznie niż samo pobieranie danych.
• Nie zapisuj sekretów w zgłoszeniach, zrzutach ekranu ani artykułach KB. Właściciela i termin ważności przechowuj w systemie zarządzania hasłami lub sekretami.
• Zaplanuj rotację poświadczeń przed upływem ich ważności. Sophos zgłasza wygasłe poświadczenia jako błąd synchronizacji.
• Zezwalaj na adresy IP Sophos tylko wtedy, gdy dostawca wymaga listy dozwolonych źródeł, i użyj listy dla rzeczywistego regionu Central.
• Włącz powiadomienia o stanie dla odpowiedzialnego zespołu. Pamiętaj, że utworzenie Custom Notification Rule wyłącza domyślną wysyłkę wszystkich alertów e-mail do wszystkich administratorów, dlatego wymagane reguły trzeba odtworzyć oddzielnie.
• Dla każdej integracji udokumentuj źródło danych, cel, klasyfikację danych, retencję, uprawnienia, test, właściciela i sposób wycofania.

Kryteria odbioru

Integracja jest ukończona dopiero wtedy, gdy pojawia się w obszarze Configured z oczekiwaną metodą, zdefiniowane zdarzenie testowe jest widoczne w zakładanym miejscu, znacznik czasu i tenant źródłowy są prawidłowe, a właściciel przejmuje odpowiedzialność za rotację poświadczeń i alerty o stanie. W przypadku Response Actions odbiór obejmuje dodatkowo zatwierdzony i udokumentowany test; stan początkowy przywraca się wyłącznie po działaniach odwracalnych, a operacji nieodwracalnych, takich jak unieważnienie sesji, nie wolno używać jako testu wycofania. Nieuniknione opóźnienia, na przykład w audycie Microsoft 365, zapisz w protokole eksploatacyjnym.

Często zadawane pytania

Czy każda integracja wysyła dane do Sophos Data Lake?

Nie. Data Ingest wysyła dane do Data Lake. Response Action pozwala wykonać działanie w produkcie innego dostawcy. Niektóre produkty oferują tylko jeden typ, a inne — oddzielne konfiguracje dla obu kierunków.

Czy integracje produktów innych dostawców są bezpłatne z XDR?

Nie zawsze. Sophos wskazuje dla MSP Flex określone integracje w kategorii Sophos XDR, które można używać z XDR bez dodatkowego Integration License Pack. Inne kategorie w modelu Flex wymagają odpowiednich pakietów. Dodatkowo mogą być potrzebne licencje dostawcy zewnętrznego.

Dlaczego widzę dane, ale nie ma detekcji?

Pobieranie i wykrywanie to dwa różne etapy. Łącznik Data Ingest może prawidłowo zapisywać zdarzenia w Data Lake, choć nie każde zdarzenie tworzy detekcję Sophos lub sprawę. Najpierw sprawdź przepływ danych źródłowych za pomocą przewidzianego zapytania Live Discover.

Czy jedno urządzenie może obsługiwać wiele integracji Syslog?

Tak, w ścieżce Classic SVA Sophos dopuszcza wiele integracji produktów innych dostawców oraz jedną integrację Sophos NDR na tej samej appliance. Każde źródło trzeba jednak skonfigurować z właściwymi parametrami połączenia i formatu. Nowy XDR Data Collector zastępuje natomiast Syslog i nie przejmuje ani nie hostuje tego obciążenia NDR. Podczas przejścia obowiązuje wskazany powyżej proces migracji kolektora; NDR jest eksploatowany oddzielnie zgodnie z runbookiem NDR.

Dlaczego sama integracja Microsoft 365 Response nie wystarcza?

Udostępnia działania, ale nie pobiera automatycznie danych audytowych ani alertów Defender. Dodaj także Microsoft 365 Management Activity i Microsoft Graph Security API V2, aby zapewnić detekcje oraz kontekst do dochodzenia.

Czy usunięcie integracji kasuje historyczne dane w Data Lake?

Usunięcie nie gwarantuje natychmiastowego skasowania wcześniej pobranych danych. Traktuj więc usunięcie jako zatrzymanie przyszłego przepływu danych, a wymagania retencji i usuwania wyjaśnij oddzielnie, zanim zadeklarujesz wiążący termin skasowania danych.