Wdrażanie Sophos Server Protection na instancjach AWS EC2 i maszynach wirtualnych Azure

Instancję EC2 lub maszynę wirtualną Azure chroni się wewnątrz systemu operacyjnego gościa za pomocą Sophos Server Protection. Na serwerach Windows używa się instalatora Windows Server, a na obsługiwanych serwerach Linux — Sophos Protection for Linux (SPL). Lokalizacja maszyny wirtualnej nie zmienia wyboru agenta serwerowego. Sophos Firewall jako wirtualne urządzenie w AWS lub Azure chroni i kieruje ruchem sieciowym, ale nie zastępuje agenta w systemie gościa. Sophos Cloud Optix to osobny produkt do oceny stanu zabezpieczeń i inwentaryzacji zasobów chmurowych, a nie warunek instalacji ochrony serwera: zgodnie z komunikatem Sophos dotyczącym cyklu życia produktu wsparcie i dostęp zakończą się 30 września 2026 r. Nie należy więc opierać na nim nowego ani długoterminowego procesu inwentaryzacji i porządkowania zasobów chmurowych. Dostępność Server Protection i jego funkcji oraz zakres uprawnień licencyjnych we własnym tenancie trzeba sprawdzić osobno.

W skrócie: Wybierz reprezentatywną maszynę wirtualną, zatwierdź system operacyjny i tryb ochrony, sprawdź połączenie z Sophos Fusion z jej rzeczywistej sieci chmurowej, zainstaluj instalator serwerowy przypisany do tenanta, a następnie sprawdź My Products > Server > Servers oraz szczegóły serwera. Kolejną falę można uruchomić dopiero po potwierdzeniu rejestracji, grupy, zasad, stanu agenta i działania aplikacji. W przypadku instancji o krótkim czasie życia trzeba dodatkowo zaplanować osobne uzgadnianie ich z inwentarzem chmurowym.

Przed pilotażem: ustal sposób ochrony i połączenie sieciowe

1. Maszyna wirtualna i umowa: Zbierz informacje o koncie AWS lub subskrypcji Azure, regionie, roli maszyny, wersji systemu operacyjnego lub dystrybucji Linux, architekturze i cyklu życia. Sprawdź aktualne wsparcie dla konkretnego systemu gościa i wymaganych komponentów. Potwierdź licencję danego tenanta, zamówiony pakiet serwerowy (SKU) i warunki umowy dotyczące tych maszyn; widoczny przycisk pobierania nie potwierdza uprawnienia do korzystania z produktu.
2. Tryb ochrony: Wybierz pełną ochronę Sophos przed złośliwym oprogramowaniem albo XDR Sensor. Sam XDR Sensor nie zapewnia ochrony przed złośliwym oprogramowaniem i wymaga aktywnej ochrony innego dostawcy. Przed zmianą rozpoznaj konflikty z istniejącym oprogramowaniem zabezpieczającym i ustal sposób wycofania zmiany na danej maszynie.
3. Połączenie wychodzące: Z docelowej podsieci sprawdź dostępność DNS, HTTPS, punktów docelowych Sophos wymaganych przez tenanta oraz, w razie potrzeby, serwera proxy lub Message Relay podczas instalacji i działania agenta. Security Groups, Network Security Groups, trasy chmurowe, NAT, zapory i inspekcja TLS mogą wpływać na połączenie. Aktualną listę dozwolonych adresów i diagnostykę proxy opisano w artykule Wymagania dotyczące sieci i serwera proxy. Nie zakładaj, że stała lista adresów IP chmury zastąpi punkty docelowe Sophos.
4. Pilotaż i kryteria odbioru: Wybierz małą grupę maszyn reprezentującą rolę serwera, wersję systemu, segment sieci i ewentualną trasę przez proxy. Zapisz nazwy, oczekiwaną grupę serwerów, docelowe zasady, okno restartu, test obciążenia aplikacji i kryteria wstrzymania. Jeśli podsieci lub obrazy się różnią, zaplanuj co najmniej jeden odpowiedni test dla każdego odmiennego wariantu połączenia.

Przykład: Maszyna z aplikacją Windows i maszyna robocza Linux w osobnych prywatnych podsieciach to dwa przypadki pilotażowe, a nie jeden wspólny test sieci. Pomyślne uruchomienie instalatora na pierwszej maszynie nie dowodzi, że druga dotrze do punktu aktualizacji przez własną trasę NAT lub proxy.

Uruchom instalator w systemie gościa i prawidłowo przygotuj obrazy

W My Environment > Installers > Server Protection wybierz Windows Server Installer lub Linux Server Installer zgodny z zatwierdzonym trybem ochrony i pochodzący z właściwego tenanta Sophos Fusion. Na pojedynczą maszynę Windows bezpiecznie przenieś SophosSetup.exe, uruchom go z lokalnymi uprawnieniami administratora, uwzględnij wyświetlone wyniki kontroli wstępnych oraz dokończ instalację i wymagany restart. Na maszynę Linux bezpiecznie przenieś SophosSetup.sh, nadaj mu uprawnienia do wykonywania i uruchom najpierw sudo ./SophosSetup.sh --test, a po pomyślnym teście sudo ./SophosSetup.sh. Następnie sprawdź rejestrację w tenancie i lokalny stan agenta; samo zakończenie pracy instalatora nie wystarcza. Tryb ochrony, zaawansowane opcje wiersza poleceń, dzienniki i rozwiązywanie problemów opisano w artykułach Instalowanie i wdrażanie Windows Server Protection oraz Instalowanie i wdrażanie SPL. Instalator przypisany do tenanta i jego adres pobierania przechowuj wyłącznie w zabezpieczonym repozytorium pakietów, nigdy w publicznym obrazie maszyny wirtualnej ani repozytorium kodu.

Nie klonuj bez zmian już zarejestrowanej maszyny wzorcowej. W przypadku SPL w obrazie wzorcowym Linux po instalacji wyrejestruj maszynę wzorcową poleceniem registerCentral --deregister zgodnie z procedurą tworzenia obrazu wzorcowego Linux, natychmiast ją wyłącz i zapisz jako obraz, gdy jest wyłączona. Późniejsze uruchomienie maszyny wzorcowej może spowodować jej ponowną rejestrację; w takim przypadku wyrejestruj ją ponownie przed zapisaniem obrazu. Uruchom dwa klony i sprawdź, czy mają odrębne tożsamości.

Windows Server wymaga innej procedury przygotowania obrazu: Przed utworzeniem obrazu sprawdź, czy dla konfiguracji obrazu wyłączono Tamper Protection oraz czy nie są aktywne Server Lockdown ani Update Cache; nie twórz obrazu wzorcowego z serwerów, na których te funkcje są aktywne. Wykluczone są także maszyny wzorcowe szyfrowane za pomocą BitLocker oraz zawierające komponenty Sophos Encryption. Uruchom jako administrator SophosSetup.exe --goldimage z instalatora Windows Server przypisanego do tenanta, postępując zgodnie z procedurą tworzenia obrazu wzorcowego Windows (również dla serwerów); sprawdź instalację i stan agenta, ponownie włącz Tamper Protection i wyłącz maszynę wzorcową przed wykonaniem migawki obrazu. Przy pierwszym uruchomieniu każdy klon musi odpowiednio wcześnie, przed wykryciem go przez Sophos, otrzymać ostateczną nazwę komputera różną od nazwy maszyny wzorcowej: Sophos rozpoznaje klony po zmianie nazwy, a nie po identyfikatorze instancji chmurowej. Jeśli nadanie nazwy następuje z opóźnieniem, sprawdź tryb Timeout Mode opisany w przewodniku; tryb Notification Mode opisano tam dla VMware Horizon Instant Clone i nie należy stosować go automatycznie do EC2/Azure. Nie zakładaj, że zwykła instalacja Windows jest gotowa do klonowania. Również w tym przypadku osobno zweryfikuj w Fusion dwa klony.

Sprawdź falę wdrożenia w chmurze i wstrzymaj ją w razie błędów

Po instalacji lub uruchomieniu klonu pilotażowego otwórz każdy oczekiwany serwer osobno w My Products > Server > Servers. Dwa jednocześnie działające klony muszą być widoczne jako dwa odrębne obiekty serwerowe. Na potrzeby odbioru zapisz zewnętrzne powiązanie konta AWS/subskrypcji Azure, regionu, identyfikatora instancji EC2/identyfikatora zasobu maszyny wirtualnej Azure, identyfikatora serwera w Fusion, właściciela i czasu utworzenia; lista serwerów nie wyświetla identyfikatorów chmurowych automatycznie. W szczegółach sprawdź Summary, Status i Policies, a także ostatnią aktywność, stan agenta, zainstalowane komponenty i obowiązujące zasady serwerowe. Pierwsza automatycznie przypisana zasada domyślna nie musi być planowaną zasadą produkcyjną. Następnie porównaj działanie usługi, dostęp do aplikacji, kopie zapasowe i wyniki reprezentatywnego testu obciążenia przed wymaganym restartem i po nim.

Jeśli maszyna nie pojawia się w Fusion, sprawdź najpierw tenanta i filtry, a potem DNS, proxy, wychodzącą trasę sieciową i dzienniki instalacji zgodnie z odpowiednią instrukcją dla Windows lub instrukcją dla Linux. Jeśli nie można odróżnić klonów, wstrzymaj wdrażanie obrazu i sprawdź etap nadawania tożsamości w procedurze obrazu wzorcowego. W razie niewłaściwych komponentów, złego stanu agenta lub zakłócenia działania aplikacji nie uruchamiaj kolejnej fali; zbadaj odizolowaną falę, zamiast wielokrotnie i na ślepo stosować instalator oraz zasady.

Osobno obsługuj zakończone instancje i nieaktywne urządzenia

Maszyny wirtualne o krótkim czasie życia mogą już nie istnieć, choć nadal są widoczne w Sophos Fusion. Dawna wartość Last Active nie dowodzi zakończenia instancji chmurowej ani nie wyznacza uniwersalnego terminu automatycznego usuwania wpisu. Regularnie uzgadniaj zewnętrzne powiązanie konta/subskrypcji, regionu, identyfikatora instancji/zasobu chmurowego i identyfikatora serwera w Fusion z zasobami AWS/Azure oraz inwentarzem urządzeń Fusion; zapisuj właściciela, daty zdarzeń cyklu życia i dowód zdarzenia EC2 Terminate lub Azure VM Delete. Ponownie użyta nazwa hosta albo zatrzymana maszyna wirtualna Azure nie dowodzi, że powiązany obiekt serwerowy został wycofany.

Podstawą pozostaje ręczne uzgadnianie i celowe użycie Delete: Dopiero po uzyskaniu potwierdzenia zakończenia instancji w chmurze i jednoznacznym dopasowaniu identyfikatorów zabezpiecz potrzebne alerty i dane z dochodzeń, sprawdź możliwe duplikaty oraz udokumentuj wycofanie lub zastępczą ochronę. Delete w Fusion nie zastępuje ani odinstalowania agenta z nadal działającej maszyny, ani procesu zarządzania cyklem życia zasobów chmurowych.

Osobno Sophos opisuje w artykule Removal of inactive devices konfigurowalną regułę Server dla nieaktywnych urządzeń: skierowaną do określonych grup albo globalną z wyłączeniami grup (wyłączenia nie dotyczą reguł skierowanych do określonych grup). Reguła reaguje na brak aktywności, nie na potwierdzone zdarzenie EC2 Terminate lub Azure Delete, i nie odinstalowuje agenta. Przed włączeniem jej we własnym tenancie sprawdź na testowych zasobach grupy, okres nieaktywności, wyłączenia, przechowywanie danych oraz skutki dla zatrzymanych lub tymczasowo niedostępnych produkcyjnych maszyn wirtualnych; nie zakładaj z góry konkretnego okresu ani wpływu na licencje. Dawna integracja z Cloud Optix oferowała odrębne usuwanie wpisów po zakończeniu instancji w istniejących środowiskach AWS/Azure połączonych z tym samym tenantem i korzystających z agentów serwerowych. Funkcja ta była domyślnie wyłączona, mógł ją włączyć tylko Super Admin i nie obejmowała instancji zakończonych przed jej włączeniem. Ze względu na koniec wsparcia i dostępu 30 września 2026 r. jest to jedynie kontekst historyczny, a nie zalecenie nowej konfiguracji ani długoterminowej automatyzacji. Nie należy obiecywać niepotwierdzonego sposobu działania hooków usuwania w autoskalowaniu, automatyzacji API ani naliczania licencji.