Sophos Server Protection: bezpieczne zatwierdzanie platform Windows i Linux

Decyzja w skrócie: Serwer trafia do kolejnej fali instalacji lub aktualizacji tylko wtedy, gdy jego konkretny system operacyjny i agent są zgodne z aktualnymi wymaganiami Sophos, potrzebne funkcje są dostępne w danym tenancie, a reprezentatywny serwer pilotażowy działa prawidłowo. Wpis w starych informacjach o wydaniu dowodzi jedynie, że kiedyś istniały komponenty dla danej platformy — nie że jej system operacyjny jest dziś obsługiwany bez ograniczeń. Jeśli brakuje wiarygodnego potwierdzenia, serwer nie trafia do tej fali, a kwestię obsługi platformy należy wyjaśnić z pomocą techniczną Sophos.

Ten przewodnik pomaga podjąć decyzję o dopuszczeniu platformy przed nową instalacją, zmianą systemu operacyjnego lub aktualizacją agenta. Same czynności instalacyjne dla Windows Server oraz Sophos Protection for Linux (SPL) opisano w odpowiednich instrukcjach.

Oddzielnie sprawdź wersję wydania i stan wsparcia

W dniu weryfikacji, 24 września 2026 r., informacje o wydaniach Sophos podają jako najwyższą wersję agenta Server Core Agent dla Windows 2026.2.2.1 (wrzesień 2026 r.). Osobne sekcje dotyczą komponentów dla Windows Server 2016 i nowszych oraz starszych platform legacy. Aktualne informacje o wydaniach Windows Server Core Agent są właściwym źródłem zmian wersji i komponentów. Ostrzegają też, że wdrażanie oprogramowania po publikacji może potrwać kilka tygodni. Historyczna lub aktualna sekcja o komponentach nie potwierdza obsługi konkretnej edycji ani kompilacji Windows.

Według wymagań systemowych Sophos dla Windows Server (KBA-000003024, stan na 7 maja 2026 r.) generacje Windows Server 2016, 2019, 2022 i 2025 są w pełni obsługiwane. Windows Server 2008 R2 oraz 2012 i 2012 R2 to platformy legacy wymagające licencji Extended Support; niektóre funkcje mogą być niedostępne, nieobsługiwane lub nieaktualizowane. Sensor Mode nie jest obsługiwany na platformach legacy. Ta datowana lista nie oznacza automatycznej obsługi każdej edycji, architektury ani wariantu kompilacji. Dlatego przed falą zinwentaryzuj dokładną edycję, pełny numer kompilacji systemu, architekturę, wersję agenta, wybrany tryb ochrony oraz rzeczywiste uprawnienie Extended Support hostów legacy. Sprawdź konkretną kombinację w aktualnych wymaganiach systemowych Sophos dla Windows Server, informacjach o obsługiwanych wariantach Windows oraz kalendarzu wycofywania produktów. Jeśli strony wsparcia Sophos nie da się odczytać lub nie daje jednoznacznej odpowiedzi, wstrzymaj dopuszczenie i zapytaj Sophos Support. Uruchomiony agent ani wpis w informacjach o wydaniach nie dowodzi prawa do wsparcia.

Zasoby sprawdzaj według licencji i trybu: Według stanu na 7 maja 2026 r. dla Sophos Endpoint – Server wymagane są co najmniej 8 GB wolnego miejsca, 8 GB RAM i 2 rdzenie. Dla Sophos EDR, XDR i MDR – Server wymagane są co najmniej 10 GB wolnego miejsca, 8 GB RAM i 2 rdzenie; zalecane jest 10 GB wolnego miejsca, 16 GB RAM i 4 rdzenie. Wymagania te dotyczą zarówno Full Protection, jak i Sensor Mode — tabela zasobów nie znosi zakazu użycia sensora na platformach legacy. Sophos zdecydowanie zaleca dysk SSD jako dysk rozruchowy. Wartości są ogólnymi wytycznymi, a nie gwarancją wystarczającej wydajności przy każdym obciążeniu: szczególnie wykrywanie i usuwanie złośliwego oprogramowania może przejściowo zwiększyć zużycie CPU, RAM i dysku. Sprawdź rezerwę zasobów i zachowanie serwera w pilotażu.

Dla Linux informacje o wydaniach SPL podają na ten sam dzień weryfikacji 2026.3 (wrzesień 2026 r.) jako najnowszą wersję. Także w tym przypadku udostępnienie jej we własnym tenancie może nastąpić dopiero po publikacji informacji o wydaniu. W sekcji System requirements podano obecnie co najmniej 2,5 GB wolnego miejsca na dysku, 2 GB dostępnej pamięci RAM, architekturę x86_64 lub ARM64, działający systemd, Bash oraz glibc w wersji co najmniej 2.17; na ARM64 wymagane są glibc co najmniej 2.18 oraz kernel co najmniej 5.3. Wartości te stanowią punkt odniesienia z określonego dnia, a nie trwałe potwierdzenie obsługi wszystkich dystrybucji i kerneli Linux.

Wskazówki Sophos dotyczące dystrybucji i kerneli SPL odsyłają po aktualną listę platform do sekcji System requirements > Supported platforms w informacjach o wydaniach; nie są drugą, niezależną tabelą dopuszczonych platform. Dystrybucja, wersja główna i podrzędna, architektura, uruchomiony kernel oraz wsparcie producenta muszą być ze sobą zgodne. Na wskazany dzień lista testowanych platform obejmuje między innymi RHEL 8–10, Debian 11–13, Ubuntu 22.04/24.04 LTS oraz 26.04. Istnieje również oddzielnie oznaczona lista platform legacy, która nie stanowi automatycznego potwierdzenia wsparcia. Sophos testuje najnowsze aktywne wydania podrzędne lub pakiety serwisowe; dla x86_64 mogą obowiązywać minimalne wersje kernela zależne od dystrybucji. Kernel 5.3 nie oznacza więc ogólnego dopuszczenia x86_64. Problem może wystąpić również powyżej minimalnej wersji kernela: aktualne informacje o wydaniach wskazują znany błąd ftrace w wersjach od 5.10.133 do 5.10.142, który może zawiesić kernel. Nie uznawaj takiej kombinacji za dopuszczoną tylko dlatego, że instalacja przebiegła bez widocznych błędów; wcześniej wyjaśnij kwestię kernela i wskazówek Sophos.

Wyjątki rozstrzygnij przed pilotażem: Jeśli obraz Linux jest immutable (niezmienialny), nie dopuszczaj tu SPL — Sophos stwierdza, że SPL nie jest przeznaczony dla niezmienialnych dystrybucji, i wskazuje dla nich osobny produkt Sophos Linux Sensor (SLS). SLS nie jest sensorem XDR w SPL; ten przewodnik nie opisuje instalacji SLS. Niewymienione dystrybucje pochodne, niestandardowe lub minimalne kernele oraz systemy utwardzone również nie stają się automatycznie przetestowanymi platformami. Sophos opisuje dla nich weryfikację na zasadzie dołożenia komercyjnie uzasadnionych starań i może wymagać odtworzenia problemu na obsługiwanej platformie lub aktualizacji.

W przypadku istniejącego hosta Linux legacy sprawdź dodatkowo rzeczywiste uprawnienie do rozszerzonego wsparcia oraz zarówno zainstalowany pakiet oprogramowania, jak i pakiet przypisany przez Update Management. Na 24 września 2026 r. Sophos wskazuje dla wersji legacy obsługiwany pakiet LTS 2026.1.0.35 i zaleca przypisanie go przez Update Management; przy problemach z nowszym pakietem powrót do obsługiwanego pakietu może być niezbędny do analizy. Przed zmianą sprawdź obowiązujące wtedy wskazówki Sophos i dostępność konkretnego pakietu: nagłówek SPL 2026.3 nie wyznacza automatycznie wersji docelowej dla hosta legacy, a 2026.1.0.35 nie jest trwałą gwarancją ani ogólną instrukcją cofania wersji.

Udokumentuj dopuszczenie do konkretnej fali

Krótki protokół weryfikacji pomaga uniknąć uznania działającej instalacji za dowód wsparcia. Dla każdej rodziny serwerów — na przykład osobno dla serwerów aplikacji Windows i baz danych Linux — zapisz:

Stan obecny i docelowy: rola serwera, edycja systemu lub dystrybucja i wersja podrzędna, pełny numer kompilacji lub wynik uname -r, architektura, zainstalowany agent wraz z komponentami oraz planowana wersja docelowa. Dla Windows sprawdź typ licencji (Endpoint – Server lub EDR/XDR/MDR – Server), Full Protection lub Sensor Mode, wolne miejsce, RAM, liczbę rdzeni i dysk rozruchowy. Dla Linux sprawdź również typ obrazu (immutable lub modyfikowalny), dostępną pamięć RAM i wolne miejsce na rzeczywistym woluminie instalacyjnym, działający systemd, Bash oraz glibc. Dla hostów Linux legacy osobno zapisz zainstalowany i przypisany pakiet oprogramowania.
Dowody: odnotuj datę i wersję wymagań systemowych Windows oraz informacji o wydaniach Windows lub SPL, aktualne wymagania systemowe i kernelowe, stan cyklu życia i rozszerzonego wsparcia wraz z rzeczywistymi uprawnieniami hostów legacy oraz potrzebną licencję i funkcje tenanta. Gdy dla Windows brakuje jednoznacznego potwierdzenia obsługi edycji, kompilacji, architektury i trybu ochrony, wpisz wyraźnie nierozstrzygnięte, a nie „zgodne”. Informacja o nowej funkcji w wydaniu — na przykład o możliwości użycia Linux jako Update Cache lub Message Relay od SPL 2026.3 — nie zastępuje potwierdzenia jej faktycznej dostępności w tenancie ani spełnienia osobnych wymagań.
Decyzja: „dopuszczony do pilotażu”, „najpierw zaktualizować system/kernel” albo „wstrzymać i wyjaśnić z pomocą techniczną”. Wskaż osobę weryfikującą, okno serwisowe, urządzenia pilotażowe i kryteria wstrzymania. Pierwsza opcja wymaga pozytywnego potwierdzenia obsługi platformy; nieprzetestowana kompilacja dystrybucji pochodnej nie zastępuje przetestowanej kombinacji. Niezmienialny Linux pozostaje poza falą SPL; w przypadku Linux legacy kontynuuj dopiero po wyjaśnieniu uprawnień, właściwego przypisania pakietu i aktualnego statusu wsparcia.

Na pilotażowym serwerze Linux uruchom te polecenia tylko do odczytu możliwie blisko okna serwisowego i zapisz ich wyniki:

cat /etc/os-release
uname -r; uname -m
free -m
df -h -- /opt
ps -p 1 -o comm=; test -d /run/systemd/system && printf 'systemd läuft\n'
command -v bash; getconf GNU_LIBC_VERSION

W wyniku free -m porównaj kolumnę available (nie total) z wymaganymi 2 GB dostępnej pamięci. df -h -- /opt ma sens dla instalacji domyślnej tylko wtedy, gdy /opt znajduje się na rzeczywistym woluminie docelowym. Jeśli jest zamontowany osobno lub użyto --install-dir, sprawdź przez df -h -- <Pfad> już istniejącą ścieżkę na rzeczywistym woluminie instalacyjnym i potwierdź 2,5 GB wolnego miejsca. Jeśli nie można jeszcze ustalić tego woluminu, nie potwierdzaj spełnienia wymagań zasobowych. ps oraz katalog /run/systemd/system pozwalają sprawdzić działający system init; Bash musi być dostępny, a zwrócona wersja glibc musi odpowiadać architekturze. Status immutable ustal dodatkowo z typu obrazu lub systemu w inwentarzu wdrożeniowym; samo os-release nie dowodzi, że host można modyfikować. Dla Windows zachowaj pełne dane systemu i agenta z zarządzanego inwentarza oraz właściwości systemu, a także wartości zasobów dla wybranej licencji i trybu ochrony. Powtórz weryfikację po zmianie systemu, kernela, agenta, licencji lub wymagań Sophos — nie opieraj się wyłącznie na dacie tego artykułu.

Pilotaż, stan ochrony i kolejna fala

Najpierw wybierz reprezentatywny serwer dla każdej istotnej kombinacji platformowej: ta sama wersja podrzędna systemu, architektura i kernel, podobna trasa sieciowa lub proxy oraz porównywalna rola i obciążenie. Przed pilotażem sprawdź kopię zapasową i sposób odtworzenia, zapewnij dostęp do konsoli lub dostęp pozapasmowy oraz zarezerwuj okno serwisowe uwzględniające możliwy restart. Baza danych o szczególnie wysokich chwilowych obciążeniach I/O wymaga odpowiedniego testu obciążeniowego; samo uruchomienie pustej testowej maszyny wirtualnej nie wystarczy.

Po instalacji lub aktualizacji sprawdź w My Products > Server > Servers we właściwym tenancie, czy serwer pilotażowy widnieje tylko raz, komunikuje się na bieżąco, ma oczekiwane komponenty ochrony i właściwą grupę serwerów oraz nie zgłasza utrzymującego się alarmu stanu. Porównaj zainstalowane komponenty i wersje na urządzeniu oraz w Fusion; sprawdź faktycznie obowiązującą politykę serwera na hoście, nie tylko przypisanie do grupy. W Linux sprawdź ponadto sudo systemctl status sophos-spl. Tylko jeśli zainstalowano wtyczkę antywirusową, odczytaj przy domyślnej ścieżce sudo cat /opt/sophos-spl/plugins/av/VERSION.ini (dostosuj ścieżkę, jeśli zmieniono --install-dir) i porównaj jej wersję z komponentem Server Protection w Central, a nie z podstawowym komponentem SPL. Na serwerze z samym sensorem SPL XDR, bez wtyczki AV, sprawdź zamiast tego faktycznie zainstalowane komponenty, ich wersje i stan w Central; brak pliku AV nie jest wówczas błędem. Sam działający serwis nie potwierdza aktualnej ochrony przed złośliwym oprogramowaniem ani skuteczności polityki. Zaplanowany, bezpieczny test wykrywania przy dostępie wykonaj zgodnie z instrukcją instalacji Linux tylko przy zainstalowanej ochronie AV i po sprawdzeniu, że w faktycznie obowiązującej Server Threat Protection Policy włączone są zarówno Real-time scanning - Local files and network shares, jak i Enable scan for Server Protection for Linux Agent; sam sensor XDR nie nadaje się do tego testu.

Następnie porównaj działanie aplikacji biznesowej, zachowanie przy restarcie, połączenia sieciowe i typowe obciążenie ze stanem sprzed zmiany. Przy nowej funkcji agenta najpierw sprawdź, czy jest ona faktycznie oferowana serwerowi pilotażowemu w tenancie. Kolejna, ograniczona fala może ruszyć dopiero po łącznym zaliczeniu weryfikacji platformy, wersji agenta i polityki, stanu ochrony oraz testu aplikacji. Informacje o wydaniu mogą pojawić się przed udostępnieniem oprogramowania; inna wersja faktycznie oferowana w tenancie wymaga ponownego sprawdzenia, a nie wymuszenia pobrania.

Przygotuj wstrzymanie i drogę powrotu

Przed zmianą zapisz działającą wersję systemu i kernela oraz agenta, a dla Linux legacy także zainstalowany i przypisany pakiet oprogramowania, informacje o kopii zapasowej, oknie serwisowym, trybie ochrony i osobie odpowiedzialnej. Powrót do starego agenta nie jest możliwy tylko dlatego, że jego wersja widnieje w historycznych informacjach o wydaniach. Przed cofnięciem systemu lub kernela trzeba oddzielnie potwierdzić możliwość uruchomienia, spójność danych oraz wsparcie wersji docelowej. Choć Sophos może w przypadku Linux legacy wymagać powrotu do obsługiwanego pakietu na potrzeby analizy zgłoszenia, pakiety oprogramowania i polityki aktualizacji Sophos nie są uniwersalnym przełącznikiem cofania wersji; wcześniej uzgodnij z Sophos drogę powrotu dla konkretnego hosta.

Jeśli rejestracja się nie powiedzie, stan ochrony pozostaje zły, zakres ochrony jest niewłaściwy, wystąpią nieoczekiwane restarty lub zakłócenia działania aplikacji serwerowej, natychmiast wstrzymaj dystrybucję i automatyczne ponowienia, wydziel dotknięte hosty i nie zaczynaj kolejnej fali. Najpierw porównaj z protokołem tenant, łączność, faktycznie obowiązującą politykę, oferowaną wersję agenta i rozbieżności wersji systemu lub kernela. Korektę polityki ogranicz ściśle do pilotażu i ponownie zweryfikuj wynik; nie wyłączaj ochrony w całym tenancie. Jeśli konieczny jest powrót, użyj wcześniej ustalonej i przetestowanej procedury odtwarzania systemu oraz procedury pomocy technicznej Sophos właściwej dla konkretnej wersji agenta. Nie usuwaj komponentów ani sterowników na próbę. Jeśli kwestia obsługi platformy lub wspieranej drogi powrotu pozostaje nierozstrzygnięta, zabezpiecz logi i dane platformy oraz zwróć się do pomocy technicznej Sophos; do tego czasu fala wdrożenia pozostaje wstrzymana.