Migracja kolektorów logów SVA do Sophos XDR Data Collectors

Podczas przejścia na rozszerzone rozwiązanie Sophos XDR Sophos przygotowuje nową konfigurację XDR Data Collector dla kwalifikujących się kolektorów logów Sophos Security Virtual Appliance (SVA). Nie oznacza to automatycznej instalacji ani aktywacji VM we własnym środowisku. Trzeba wdrożyć zamiennik, przełączyć ścieżkę Syslog i potwierdzić nowe zdarzenia. Przy tym samym adresie IP stary kolektor nie może działać, gdy uruchamiany jest nowy.

XDR Data Collector jest wirtualnym odbiornikiem Syslog działającym lokalnie lub w AWS, Azure bądź GCP. Przekazuje odebrane logi do Sophos XDR. Bezpośrednia integracja API nie potrzebuje tego odbiornika Syslog. Runbook integracji wyjaśnia Data Ingest, Response Actions i te typy połączeń.

Jeśli korzystasz już z Sophos Next-Gen SIEM, Sophos zaleca zastąpienie dotychczasowych kolektorów Syslog SVA przez XDR Data Collectors, aby móc wykorzystać pełną retencję danych obsługiwaną przez produkt SIEM. Istniejących integracji API nie trzeba konfigurować ponownie na potrzeby tej wymiany kolektora Syslog. Nie wynika z tego ani określony okres retencji, ani uprawnienie wszystkich tenantów XDR do retencji SIEM; nadal obowiązują warunki retencji właściwe dla używanego produktu SIEM.

Stan na 11 października 2026 r.: przewodnik migracji z 1 października 2026 r. uzupełnia wrześniowe wdrożenie. Dawna ścieżka dokumentacji EAP wskazuje pochodzenie wersji, ale nie gwarantuje, że każdy tenant ma już tę funkcję. Najpierw sprawdź stan aktualizacji konkretnego tenanta i faktycznie oferowany kolektor w Security Operations > Integrations > Data Collectors. Ten runbook opisuje przełączenie Syslog i konkretne wdrożenie lokalne na vSphere; objaśnia adresy chmurowe, ale tworzenie zasobów poszczególnych chmur nie jest częścią kroków vSphere.

Inwentaryzacja obciążeń i ustawień nieobjętych migracją

Dla każdego starego kolektora SVA zapisz platformę, nazwę, nazwę hosta, statyczne parametry sieci lub dzierżawę DHCP, wszystkie wysyłające źródła oraz ich cel Syslog, port i protokół. Dodatkowo zanotuj format danych, wybór typów zdarzeń, wykluczenia domen i protokołów, ustawienia Passthrough i potrzebne poświadczenia. Udokumentuj ostatni potwierdzony odbiór danych z każdego źródła; po przełączeniu pomoże to odróżnić nieaktywny strumień od błędu.

Automatycznie przejmowane są nazwa kolektora, nazwa hosta lub nazwa z niej wyprowadzona, statyczny adres IP, maska podsieci, brama i DNS albo ustawienie DHCP, a także przypisania portów i protokołów Syslog. Oryginalne porty źródeł pozostają zachowane i są mapowane na standardowe porty Syslog UDP/514 lub TCP/601. Typ platformy decyduje o nowym kolektorze chmurowym lub lokalnym.

Nie są automatycznie przejmowane:

• Integracje NDR: NDR nie używa ścieżki przekazywania Syslog. W mieszanej SVA migrowana jest tylko część Syslog; SVA obsługująca wyłącznie NDR nie otrzyma na tej podstawie XDR Data Collector.
• Filtry typów zdarzeń oraz listy wykluczeń domen i protokołów.
• Ustawienia formatu Syslog i Passthrough specyficzne dla SVA.
• Poświadczenia integracji.
• Investigation Consoles, Nessus Scanner i inne typy VM poza kolektorami logów SVA.
• Fizyczne appliance: nie są automatycznie migrowane do wirtualnych kolektorów.

Dla nowej integracji sprawdź wyraźnie, które filtry i formaty są nadal potrzebne i jaką konfigurację oferuje dla nich konektor. Brak filtrów może powodować pobieranie większej ilości danych niż planowano; niewłaściwy format może prowadzić do przetwarzania logów jedynie jako zdarzeń ogólnych. Nie kopiuj poświadczeń ze zgłoszeń ani starych zrzutów ekranu; udostępnij je ponownie przez właściwy system zarządzania sekretami.

Jeśli NDR działa na tej samej SVA, przełączenie Syslog nie może przy okazji wyłączyć sensora. Wariant z tym samym IP wymaga wyłączenia starej SVA, a więc przerywa również jej obciążenie NDR. Zaplanuj jego eksploatację oddzielnie albo wybierz inny adres IP dla nowego kolektora Syslog, aby SVA mogła nadal obsługiwać NDR. Runbook eksploatacji NDR opisuje to obciążenie; przygotowanie zamiennika Syslog nie jest migracją NDR.

Wybór wariantu adresacji przed pobraniem

Adres docelowy decyduje, czy obie VM mogą działać jednocześnie i czy trzeba zmieniać źródła.

Przy tym samym statycznym IP zaplanuj krótką fazę przełączenia: wyłącz starą SVA, a następnie uruchom nową VM. Źródła zachowują swój cel. Nie oznacza to gwarancji bezstratnego przekazania; zachowanie zdarzeń podczas przerwy zależy również od buforowania i transportu systemu źródłowego.

Przy stopniowym przejściu nowy statyczny IP ustala się przed pobraniem ISO. Przykład: stary kolektor używa 192.0.2.10, a nowy 192.0.2.20. Nie używaj tych adresów dokumentacyjnych w produkcji. Wybierz wolny adres we właściwej własnej sieci i sprawdź podsieć, bramę, DNS oraz osiągalność z sieci źródłowych. Nowy IP ułatwia powrót i pozwala przełączać źródła pojedynczo, ale wymaga dostosowania reguł celów i firewalla.

Przy DHCP z ponownym użyciem starego IP przed przełączeniem udokumentuj adresy MAC starej i nowej VM, dotychczasową rezerwację IP i aktualny stan dzierżawy. Następnie zmień lub utwórz rezerwację starego IP dla adresu MAC nowej VM, zgodnie z udokumentowaną procedurą rezerwacji i dzierżaw używanej platformy DHCP. Potem wyłącz starą SVA i dopiero wtedy uruchom nowy kolektor. Przed odbiorem danych sprawdź jego faktyczną dzierżawę i przydzielony IP. Rezerwacja nie zapobiega używaniu tego samego adresu przez nadal działającą starą VM.

Dla kolektorów chmurowych adres zmienia się zawsze. W AWS z CloudFormation w sekcji Outputs stosu dostępna jest wartość CTPxCollectorDnsName. To nazwa DNS Network Load Balancer, którą dla źródeł Syslog należy preferować zamiast stałego wpisu IP. W Azure sprawdź adres interfejsu sieciowego VM w portalu Azure, a w GCP adres wewnętrzny w Compute Engine > VM instances. Adresy DHCP można ustalić w tabeli dzierżaw na podstawie nowego adresu MAC lub w Data Collectors. Nie myl tego celu dla źródeł z regionalnymi adresami uplinku Sophos.

Przygotowanie ścieżki sieciowej i zasobów kolektora

Przesyłanie z kolektora do Sophos XDR odbywa się przez mTLS z TLS 1.3 i wychodzący TCP/443. Nie oznacza to braku wymaganych portów wejściowych: własne źródła Syslog muszą mieć dostęp do kolektora na skonfigurowanym porcie i protokole. Standardowe cele to UDP/514 i TCP/601; dodatkowo porównaj migrowane mapowania portów z poprzednią konfiguracją. Nie twórz ogólnego dostępu z Internetu do odbiornika Syslog.

Dostęp do regionalnego uplinku, DNS i synchronizacji czasu

Poniższe cele uplinku kolektora są migawką według stanu na 11 października 2026 r. Przypisanie US1/US2/US3/EU1/EU2 pochodzi z konfiguracji kolektora XDR, a nie z domniemanego utożsamienia z regionem AWS Central. Używaj tylko faktycznie przypisanego regionu. Istniejący zestaw IP Sophos dla wejściowych wywołań API u dostawcy zewnętrznego jest inną listą dozwolonych.

Jeśli własny firewall wymaga reguł opartych na IP, do tej migawki należą poniższe adresy docelowe. Nie łącz regionów:

• US1: 18.217.45.178/32, 3.16.4.173/32, 18.224.219.97/32, 13.59.146.90/32, 3.16.16.254/32, 18.223.74.238/32.
• US2: 52.14.113.127/32, 3.141.73.137/32, 3.136.78.106/32.
• US3: 44.229.101.49, 35.166.77.47, 34.214.135.78.
• EU1: 18.158.143.139/32, 35.159.14.37/32, 52.59.37.234/32.
• EU2: 54.217.251.111/32, 54.194.78.20/32, 52.50.215.147/32.

Przed zmianą produkcyjną porównaj region i wartości docelowe z aktualną konfiguracją tenanta oraz listą dozwolonych kolektora utrzymywaną przez osobę odpowiedzialną za eksploatację. Rozbieżności wymagają sprawdzonej zmiany, a nie zapobiegawczego poszerzenia dostępu. Techniczna pisownia punktów końcowych secureworks.com pozostaje niezmieniona.

Kolektor potrzebuje również UDP i TCP/53 do serwerów DNS wpisanych przy przygotowaniu konfiguracji. Synchronizacja czasu wymaga UDP/123 do wybranych serwerów NTP. Bez własnego ustawienia NTP kolektory poza AWS używają 0.pool.ntp.org do 3.pool.ntp.org; dla AWS domyślnym celem jest 169.254.169.123. Przy lokalnym NTP ruch między kolektorem a serwerem czasu musi być dozwolony w obu kierunkach. W kolektorze lokalnym te wartości NTP służą do uruchomienia początkowego; po połączeniu synchronizację czasu przejmuje kanał backendu XDR. Według instrukcji platformy kontrolery domeny Windows nie są celem NTP dla tego hosta nienależącego do domeny.

Forward Web Proxy można wpisać przez Host Proxy. Przegląd kolektorów wyklucza skonfigurowane na stałe proxy z uwierzytelnianiem, podczas gdy instrukcja lokalna pokazuje również składnię URL z użytkownikiem i hasłem. Te informacje nie są zgodne. Nie planuj więc produkcyjnej ścieżki przez uwierzytelniane proxy bez wyjaśnienia i zatwierdzenia przez Sophos; nie obchodź sprzeczności przez osadzenie poświadczeń w ISO. Przy TLS Inspection konkretny uplink mTLS musi działać bez ingerencji MITM. Wyjątek ogranicz do wymaganych połączeń kolektora.

Wymiarowanie lokalnej VM niezależnie od starych wartości SVA

Nowa lokalna VM wymaga 4 vCPU o częstotliwości co najmniej 2 GHz, 8 GB RAM, dysku systemowego 20 GB i dysku danych 200 GB. Instrukcja platformy wskazuje vSphere ESXi 6.7 lub nowszy, Hyper-V 8.0 w Windows Server 2016 lub nowszym oraz Nutanix 6.8.x lub nowszy jako zalecane środowiska. VM musi widzieć funkcje CPU x86-64-v2; niewłaściwa maska zgodności CPU może uniemożliwić uruchomienie.

Wartość do 200'000 EPS jest górną granicą dla odpowiednio skonfigurowanych kolektorów chmurowych i lokalnych, a nie gwarancją przepustowości przy tych zasobach minimalnych. Dobieraj zasoby według liczby, wielkości i szczytowego obciążenia zdarzeń oraz kontroluj rzeczywisty przepływ danych. Na kolektorze nie wolno instalować narzędzi innych dostawców ani dodatkowych aplikacji. Aktualizacje są automatyczne, zwykle co 24 godziny, jeśli połączenie działa prawidłowo.

Wdrożenie przygotowanego kolektora lokalnego na vSphere

Dla istniejącej migracji użyj właściwej konfiguracji w Security Operations > Integrations > Data Collectors. Porównaj nazwę, parametry sieci i mapowania Syslog ze starą SVA. Pobierz ISO z konfiguracją kolektora i OVA dla VM. Te pliki tworzą parę; ISO innego kolektora przygotowałoby niewłaściwy stan. Przechowuj pliki konfiguracji z ograniczonym dostępem.

Jeśli brakuje konfiguracji, najpierw sprawdź wyłączenia i błędy sieci w następnej sekcji. Dla świadomie tworzonego ręcznie zamiennika interfejs oferuje Actions > Add Collector > On-Premises > Next. Wpisz tam nazwę i nazwę hosta, ewentualnie opis, Host Proxy i NTP oraz DHCP albo pełne statyczne parametry sieci, a następnie utwórz przez Create Collector. Nie jest to powód do tworzenia niekontrolowanego drugiego kolektora obok istniejącej migracji.

Wdrożenie na vSphere przebiega następująco:

1. W vSphere Web Console otwórz Virtual Machines > Create / Register VM i wybierz Deploy a virtual machine from an OVF or OVA file.
2. Nadaj jednoznaczną nazwę VM, na przykład sophos-xdr-collector, i wybierz pobraną OVA. Nazwa jest dowolna; powinna odróżniać VM od starej SVA w hypervisorze.
3. Wybierz datastore z co najmniej 220 GB wolnego miejsca na dwa dyski. Sprawdź mapowanie sieci i konfigurację dysków, przejrzyj podsumowanie i zakończ przez Finish. Na razie pozostaw VM wyłączoną.
4. W Storage > Datastore Browser prześlij właściwą konfigurację ISO.
5. Otwórz Edit Settings VM. Zmień CD-ROM z Client Device na Datastore ISO File, wybierz przesłane ISO i zapisz. Przed pierwszym uruchomieniem sprawdź, czy ISO rzeczywiście jest podłączone i czy VM ma dostęp do właściwej sieci źródłowej.
6. Przy tym samym IP teraz wyłącz starą SVA. Dopiero potem uruchom nową VM. Przy nowym IP stara SVA może nadal działać; źródła przełączysz następnie pojedynczo.
7. W Security Operations > Integrations > Data Collectors poczekaj, aż nowy kolektor pokaże Ready. Dopiero wtedy można odłączyć ISO. Ready nie potwierdza jeszcze prawidłowego pobierania z każdego źródła.

Dla Hyper-V Sophos udostępnia pakiet VHD zamiast OVA, a dla Nutanix pliki QCOW2; drugi dysk danych i ISO podłączone podczas pierwszego startu nadal są wymagane. Nie przenoś sekwencji kliknięć vSphere na te platformy. Kolektory chmurowe również wdraża się z zasobami właściwej platformy, a nie jako OVA w vSphere.

Przełączenie źródeł i odbiór przepływu danych

Przy zmianie adresu docelowego przestaw wszystkie właściwe urządzenia i aplikacje na nowy IP kolektora lub nową nazwę DNS. Zmieniaj tylko cel, a nie bez weryfikacji port, protokół czy format logów: te mapowania powinny zostać przejęte z SVA. Jeśli źródło wcześniej wysyłało przez UDP/514, w tej migracji pozostaje przy UDP/514. Zmiana transportu na TCP jest oddzielną zmianą wymagającą kontroli systemu źródłowego.

Przy różnych IP najpierw przełącz jedno źródło o możliwym do opanowania zakresie. Wygeneruj w nim nieszkodliwe zdarzenie rejestrowane przez konektor i zapisz źródło, typ zdarzenia oraz czas ze strefą czasową. Wyszukaj je w XDR przez ścieżkę danych lub zapytań oferowaną dla tej integracji. Dowód musi wskazywać właściwy tenant, źródło, znacznik czasu i odpowiedni format zdarzenia. Uwzględnij oczekiwane opóźnienia konektora; zdarzenie testowe nie musi tworzyć sprawy ani detekcji.

Dopiero po tej kontroli przełącz pozostałe źródła. Dla każdego porównaj ostatnie zdarzenia przed przełączeniem i pierwsze po nim. Nie należy oczekiwać identycznego czasu ani tempa zdarzeń dla każdego źródła; liczy się faktyczna aktywność i brak niewyjaśnionych luk czasowych. Unikaj nieplanowanego wysyłania tego samego strumienia jednocześnie do obu kolektorów, ponieważ może to tworzyć duplikaty.

Dotychczasowa SVA może pracować podczas planowania. Historyczne dane SVA już pobrane pozostają dostępne do zapytań w XDR; zamiennik nie musi wysyłać ich ponownie. Nie oznacza to nowej obietnicy nieograniczonej retencji. Bufor dyskowy 200 GB nowego kolektora przechowuje logi przy wolnym lub chwilowo przerwanym uplinku. Nie zastępuje kontroli źródła ani nie gwarantuje obsługi dowolnie długiej awarii.

Odbiór operacyjny następuje dopiero wtedy, gdy wszystkie oczekiwane źródła dostarczają aktualne, prawidłowo przypisane dane, filtry i wykluczenia zostały świadomie sprawdzone, DNS, synchronizacja czasu i uplink działają, a NDR w razie potrzeby nadal działa oddzielnie. Udokumentuj moment przełączenia i okres obserwacji. Do tego czasu zachowaj starą SVA i jej konfigurację na potrzeby powrotu; dopiero potem podejmij decyzję o pozostałych obciążeniach i bezpiecznym wycofaniu.

Diagnostyka i powrót bez konfliktu IP

Brak nowego kolektora: sprzętowa appliance, SVA obsługująca wyłącznie NDR lub VM inna niż SVA nie są migrowane automatycznie. Dla aktywnie używanej SVA Syslog sprawdź konfigurację portu i protokołu oraz kompletność statycznych parametrów sieci. Brak bramy lub DNS może uniemożliwić migrację. Popraw nieprawidłową konfigurację sieci w Fusion i uzgodnij ponowną migrację z Support albo utwórz wyraźnie zaplanowany ręczny kolektor. Nie wpisuj adresów zastępczych tylko po to, aby formularz został zaakceptowany.

Nowa VM nie uruchamia się: sprawdź przypisanie ISO, drugi dysk, RAM, vCPU i funkcje x86-64-v2 widoczne dla VM. Nie instaluj na kolektorze oprogramowania naprawczego ani monitorującego.

Kolektor pozostaje offline: najpierw sprawdź faktycznie przydzielony IP lub dzierżawę, bramę, DNS i początkową synchronizację czasu. Następnie skontroluj logi firewalla i proxy dla regionalnego uplinku TCP/443. Sam otwarty port wychodzący nie dowodzi skutecznego kanału mTLS. Przy tym samym IP dodatkowo upewnij się, że stara SVA naprawdę jest wyłączona.

Kolektor ma status Ready, ale brakuje źródła: sprawdź adres docelowy źródła, trasę i wejściowy port Syslog. Porównaj mapowanie portów i format ze starą integracją. Pośredniczący forwarder logów musi zachować oczekiwany format integracji; inaczej dane mogą dotrzeć jako zdarzenia ogólne zamiast w oczekiwanym schemacie. Najpierw potwierdź ścieżkę danych, a dopiero potem szukaj detekcji.

Podczas powrotu trzeba oddzielnie traktować adresy statyczne i rezerwacje DHCP:

• Ten sam statyczny IP: wyłącz nową VM, a dopiero potem uruchom starą SVA z zachowaną konfiguracją statyczną. Źródła zachowują dotychczasowy cel. Sprawdź, czy stara SVA faktycznie używa tego IP oraz odbiera i przekazuje nowe zdarzenia Syslog. Nigdy nie uruchamiaj obu VM z tym adresem.
• Rezerwacja DHCP tego samego IP: najpierw wyłącz nową VM. Następnie ponownie przypisz rezerwację starego IP do udokumentowanego starego adresu MAC SVA i obsłuż stan dzierżawy zgodnie z udokumentowaną procedurą własnej platformy DHCP. Nie zakłada się tutaj uniwersalnego polecenia usuwania dzierżawy. Dopiero potem uruchom starą SVA, sprawdź jej faktyczną dzierżawę i IP oraz potwierdź odbiór i przekazywanie nowym zdarzeniem Syslog. Źródła zachowują dotychczasowy cel; samo uruchomienie SVA nie dowodzi więc działającej drogi powrotu. Nigdy nie uruchamiaj obu VM z tym adresem.
• Inny IP lub cel DNS: przywróć udokumentowane cele źródeł i ewentualne powiązane reguły sieciowe na stary kolektor. Nowym zdarzeniem sprawdź, czy stara SVA znów odbiera i przekazuje dane. Wycofaj nowy kolektor dopiero po sprawdzeniu wszystkich przypisań.

Powrót jest odebrany dopiero wtedy, gdy potwierdzono, że stara SVA ma planowany adres docelowy oraz ponownie pobiera i przekazuje świeże zdarzenia Syslog.

Powrót działa tylko, dopóki stara SVA jest dostępna i jej konfiguracja zachowana. Nie cofa aktualizacji produktu po stronie producenta ani nie gwarantuje odtworzenia niedostarczonych zdarzeń. Sophos zapowiada późniejszy koniec wsparcia dla kolektorów logów SVA, ale w sprawdzonym tutaj stanie migracji nie wskazuje konkretnej daty. Nowe instancje kolektorów logów po migracji należy tworzyć jako XDR Data Collectors; stara SVA jest więc ograniczoną drogą powrotu dla istniejącego środowiska, a nie długoterminową strategią nowych instalacji.

Jeśli przyczyna pozostaje niejasna, zbierz identyfikatory kolektora i tenanta, platformę, zanonimizowane parametry sieci, właściwe źródło, dokładne przedziały czasu, status i komunikat błędu. Do eskalacji służy artykuł Otwieranie zgłoszenia Sophos Support. Sekrety, ISO konfiguracji i nieoczyszczone logi nie powinny trafiać do ogólnodostępnych zgłoszeń ani zrzutów ekranu.