Wdrażanie Sophos Fusion Server Protection na serwerach terminalowych RDS

Sesje RDS wymagają licencji Server Protection; nie trzeba kupować osobnej licencji Endpoint Protection dla każdej sesji. Rozstrzygające pozostają jednak konkretna umowa i EULA. Polityki serwerowe przypisuje się do hosta, a nie osobno do zalogowanych użytkowników. To podstawowe ograniczenie przy planowaniu środowisk RDS, serwerów terminalowych i Citrix.

Bezpieczna kolejność działań jest zatem następująca: sprawdzić platformę i licencję, przeprowadzić pilotaż na reprezentatywnym hoście sesji, wcześniej ustalić decyzje dotyczące polityk dla całego serwera, kontrolowanie zakończyć aktywne sesje, zainstalować agenta i dopuścić kolejne hosty dopiero po odbiorze technicznym oraz funkcjonalnym. Przygotowywanie obrazów VDI i identyfikacja użytkowników na zaporze to odrębne zadania.

Zakres zastosowania i ograniczenia wsparcia

Na potrzeby tego przewodnika nie jest dostępna aktualna, wiarygodna macierz wsparcia Sophos przeznaczona konkretnie dla RDS. Starszych wykazów wersji Windows i Citrix nie wolno traktować jako aktualnej zgody na nowe instalacje. Przed wdrożeniem należy sprawdzić zakres obowiązującego wsparcia dla konkretnej kombinacji systemu Windows gościa, agenta Sophos Server i jego kompilacji, wersji RDS lub Citrix wraz z CU oraz środowiska wirtualizacji. W przypadku Citrix trzeba również wyjaśnić stan cyklu życia produktu i ewentualne rozszerzone wsparcie wynikające z umowy. Jeśli status tej kombinacji pozostaje niejasny, należy uzyskać pisemne potwierdzenie od pomocy technicznej Sophos; sam wiek lub nazwa platformy nie dowodzą, że jest obsługiwana.

W odniesieniu do agenta serwerowego działającego na zwirtualizowanym gościu RDS nie potwierdzono ani ogólnego wsparcia dla określonych hipernadzorców, ani powszechnie obowiązującego zakresu pomocy na zasadzie „reasonable efforts”. System operacyjny gościa, platformę hosta oraz warstwę Citrix/RDS należy sprawdzić osobno, a właściwe dla danego przypadku warunki wsparcia i odtwarzania problemów wyjaśnić z Sophos i producentem platformy. Wsparcie dla wirtualnego urządzenia lub hipernadzorcy nie oznacza automatycznie wsparcia dla chronionego gościa RDS.

Wynikają z tego trzy rozróżnienia:

Wieloużytkownikowy host RDS lub Citrix: po potwierdzeniu wsparcia dla konkretnej kombinacji platform zainstalować Server Protection w gościu Windows; polityka serwerowa obowiązuje na całym hoście.
Klonowane lub nietrwałe maszyny VDI: cyklem życia obrazu należy zarządzać zgodnie z osobną procedurą dotyczącą Sophos w złotych obrazach VDI. Nie należy po prostu klonować standardowo zainstalowanego agenta.
Reguły zapory oparte na tożsamości użytkownika: nie odpowiada za nie ta instalacja serwerowa. Gdy wiele sesji korzysta z tego samego adresu IP serwera, SATC dla Remote Desktop Services opisuje odrębne przypisywanie tożsamości w Sophos Firewall.

Funkcje i polityki: decyzje przed wdrożeniem

Planowany zakres ochrony dla każdej funkcji należy sprawdzić w docelowym tenancie w odniesieniu do wykupionej licencji, systemu Windows gościa i zainstalowanych komponentów agenta. Nie potwierdzono tu pełnej macierzy funkcji RDS dla poszczególnych poziomów licencji serwerowej. W szczególności samego sensora XDR nie należy utożsamiać z instalacją Server Protection zapewniającą ochronę. Licencję i warunki umowy należy wyjaśnić na podstawie informacji o licencjonowaniu Sophos Fusion (dawniej Sophos Central) oraz obowiązującej EULA.

Środek ostrożności na czas pilotażu, a nie potwierdzone ograniczenie wsparcia RDS: na razie nie przypisywać hostowi sesji roli Update Cache ani Message Relay i nie włączać starszej funkcji Server Lockdown ani Unauthorized File Protection (UFP) jako nowego środka utwardzania. Sophos zmienił nazwę Server Lockdown na Unauthorized File Protection; nie dowodzi to jednak ani wsparcia, ani braku wsparcia dla starej lub nowej funkcji konkretnie w RDS. Przed zmianą należy osobno potwierdzić warunki dotyczące uruchamiania cache lub relay na hoście oraz korzystania przez niego z takich usług, a także wymagania dla Lockdown i UFP, w tym ewentualnej migracji. Ostrożna decyzja na czas pilotażu nie oznacza ani ogólnego zakazu, ani zgody na użycie tych funkcji i nie uzasadnia zbiorczego wyłączania innych modułów ochrony.

Polityki serwerowe zamiast polityk dla poszczególnych użytkowników

Polityki serwerowe przypisuje się do hosta sesji; nie działają one jako osobna polityka serwerowa dla każdego użytkownika RDS. Za ich pomocą nie można zatem nadać użytkowniczce A innego zakresu kontroli Web, Application, Peripheral lub DLP niż użytkownikowi B na tym samym hoście. Nie jest to stwierdzenie dotyczące innych, niezależnie konfigurowanych produktów użytkownika lub zapory.

Przed pilotażem należy uzgodnić z właścicielami aplikacji i procesów biznesowych:

jakie aplikacje i skrypty działają we wszystkich sesjach;
jakich urządzeń peryferyjnych potrzebują poszczególne role, mimo że decyzja obowiązuje na całym serwerze;
jaka reguła Web lub DLP jest akceptowalna dla wszystkich użytkowników tego hosta;
jakie udziały plikowe i ścieżki profili użytkowników musi obejmować Real-Time Scanning;
które wyjątki mają techniczne uzasadnienie, wąski zakres oraz udokumentowanego właściciela i datę wygaśnięcia.

Jeżeli grupy użytkowników rzeczywiście wymagają różnych kontroli, należy przydzielić je do osobnych kolekcji hostów sesji z odpowiednimi politykami serwerowymi. Wspólna polityka z szerokimi odstępstwami nie zastępuje takiego podziału.

Komunikaty na pulpicie w wielu sesjach

Desktop Messaging informuje o zdarzeniach związanych z ochroną i jest domyślnie włączone w serwerowej polityce Threat Protection. Nie potwierdzono tu uniwersalnej zasady określającej, w których równoległych sesjach na danym serwerze terminalowym pojawi się komunikat. Nie potwierdzono też stałej listy wyjątków od możliwości wyłączenia komunikatów. Podczas pilotażu obejmującego wiele sesji należy sprawdzić, kto widzi poszczególne komunikaty i jakie powiadomienia nadal generują faktycznie używane komponenty po zmianie ustawienia.

Helpdesk i użytkownicy nie powinni bez weryfikacji przypisywać widocznego komunikatu do konkretnej sesji. Przed wdrożeniem trzeba ustalić treść komunikatów, ścieżkę kontaktu z pomocą techniczną oraz sposób korelacji według czasu, serwera, alertu Fusion i procesu, którego dotyczy zdarzenie. Nie należy zamykać alertu wyłącznie na podstawie relacji jednego użytkownika.

Planowanie pilotażu i instalacji

Wymagania wstępne

Przed instalacją na pierwszym hoście muszą być spełnione następujące warunki:

Potwierdzono wsparcie dla systemu Windows gościa, wersji RDS lub Citrix oraz platformy wirtualizacji.
Dostępna jest odpowiednia licencja serwerowa; host zaplanowano jako serwer, a nie jako cel dla zwykłego instalatora Endpoint.
Host może łączyć się z Sophos Fusion udokumentowanymi ścieżkami sieciowymi: bezpośrednio lub przez architekturę proxy bądź relay potwierdzoną dla tego gościa RDS. Korzystanie z cache i relay należy oceniać osobno od uruchamiania tych usług na hoście.
Wyznaczono reprezentatywny host pilotażowy, okno serwisowe, kryteria odbioru technicznego i funkcjonalnego oraz osobę odpowiedzialną za wycofanie zmian.
Aktywne sesje RDS można prawidłowo zakończyć, a nowe logowania zablokować na czas zmiany.
Kopia zapasowa, migawka lub inny punkt powrotu są zgodne z procedurą operatora platformy, a możliwość odtworzenia sprawdzono niezależnie od tej zmiany.
Planowaną politykę serwerową przypisano do grupy pilotażowej; rola hosta cache/relay oraz Lockdown/UFP pozostają zapobiegawczo wyłączone w pilotażu do czasu wyjaśnienia wymagań specyficznych dla RDS.

W odpowiednim tenancie Sophos Fusion Admin pobrać instalator Windows Server z My Environment > Installers > Server Protection > Full malware protection, a nie instalator samego sensora XDR. W automatycznym wdrożeniu obowiązują te same podstawowe zasady co przy kontrolowanym wdrażaniu w Windows: chronić pakiet powiązany z tenantem, uruchamiać go jako lokalny administrator lub w kontekście SYSTEM, rejestrować rzeczywisty kod zakończenia i nie uznawać samego pomyślnego uruchomienia procesu za dowód pełnej ochrony. Produkt, grupa docelowa i licencja muszą jednak dotyczyć Server Protection.

Przeprowadzenie pilotażu

Zablokować nowe logowania na hoście pilotażowym, powiadomić użytkowników i prawidłowo zakończyć aktywne sesje. Nie wymuszać zmiany agenta podczas produkcyjnej pracy użytkowników.
Udokumentować stan początkowy: nazwę hosta, wersję systemu operacyjnego oraz RDS/Citrix, grupę Fusion, przypisane polityki, zainstalowane oprogramowanie zabezpieczające, stan ochrony i punkt powrotu.
Usunąć konkurencyjne produkty i ich sterowniki filtrujące zgodnie z zatwierdzonym planem migracji albo zastosować potwierdzoną konfigurację współistnienia. Nie uruchamiać dwóch skanerów czasu rzeczywistego równolegle bez uprzedniej weryfikacji.
Uruchomić aktualny instalator serwerowy z docelowego tenanta z uprawnieniami administratora. Przy dystrybucji oprogramowania przekazać kod zakończenia instalatora do systemu wdrożeniowego bez zmian.
Wykonać wymagane ponowne uruchomienia w oknie serwisowym. Dopiero potem dopuścić logowania na potrzeby testów technicznych.
Na kilku kontach testowych sprawdzić typowe aplikacje, profile, drukarki, udziały plikowe oraz scenariusze Web i DLP. Dopiero następnie dopuścić rzeczywistych użytkowników pilotażowych.
Obserwować host przy normalnym obciążeniu wieloma użytkownikami przez uzgodniony okres. Nie istnieje uniwersalny limit Sophos dotyczący liczby sesji ani rezerwy CPU/RAM; miarodajne są własne parametry bazowe i kryteria odbioru zespołu platformowego.

Nie należy zmieniać kilku hostów jednocześnie. Jedno udane logowanie nie potwierdza ani zgodności aplikacji w skali całego serwera, ani zachowania przy typowym obciążeniu wieloma użytkownikami.

Odbiór i eksploatacja

Pilotaż można uznać za udany dopiero po sprawdzeniu wszystkich poniższych obszarów:

Lokalnie: agent serwerowy jest w prawidłowym stanie; instalacja i wymagane ponowne uruchomienia zostały zakończone.
Fusion: host występuje dokładnie raz jako serwer we właściwym tenancie i grupie, jest aktualny oraz otrzymuje oczekiwane polityki serwerowe.
Ochrona: uzgodnione komponenty ochrony są zainstalowane; rola hosta cache/relay oraz Lockdown/UFP, wstrzymane zapobiegawczo na czas pilotażu, nie zostały włączone.
Sesje: kilku użytkowników testowych może logować się jednocześnie, uruchamiać podstawowe aplikacje, ładować profile i korzystać z potrzebnych zasobów.
Polityki: faktycznie dostępne kontrole Web, Application, Peripheral i DLP działają w sesjach testowych zgodnie z ustaleniami; sprawdzono widoczność komunikatów w innych sesjach.
Eksploatacja: obciążenie CPU, zużycie pamięci, czas logowania i czas reakcji aplikacji porównano z parametrami bazowymi platformy zebranymi przed pilotażem. Odchylenia należy zbadać, a nie maskować nieuzasadnionymi wyjątkami.

Dopiero po takim odbiorze należy zaplanować kolejną, niewielką falę hostów. Zmiany polityk nadal trzeba testować na grupie pilotażowej, ponieważ jedna polityka serwerowa dotyczy jednocześnie wielu sesji użytkowników.

Rozwiązywanie problemów i bezpieczny powrót

Użytkownik otrzymuje niewłaściwą politykę

Na hoście RDS nie ma osobnych polityk serwerowych dla poszczególnych użytkowników. Najpierw należy sprawdzić grupę Fusion, przypisanie polityki oraz priorytet dotyczący serwera. Jeżeli grupy użytkowników wymagają różnych kontroli, właściwym rozwiązaniem są osobne kolekcje hostów, a nie wyjątek dla każdego zalogowanego użytkownika.

Komunikat pojawia się w kilku sesjach

Taką obserwację należy udokumentować we własnym pilotażu, a nie traktować jako ogólną gwarancję zachowania wszystkich instalacji RDS. Trzeba skorelować czas i serwer z alertami oraz zdarzeniami w Fusion i ustalić proces wywołujący zdarzenie. Należy przetestować ustawienie Desktop Messaging w obowiązującej polityce serwerowej oraz komunikaty, które poszczególne komponenty nadal wyświetlają w danym tenancie. Sam komunikat nie dowodzi, że zdarzenie dotyczyło każdej sesji, w której był widoczny.

Nieprawidłowe działanie aplikacji lub logowania po pilotażu

Zatrzymać kolejne fale wdrożenia. Najpierw zebrać zdarzenia Fusion, stan agenta, zdarzenia Windows oraz informacje o procesie, którego dotyczy problem. Następnie przywrócić ostatnio zmienioną politykę pilotażową do wcześniej udokumentowanego stanu i ponowić test. Wyjątki tworzyć wyłącznie dla potwierdzonego procesu lub ścieżki i w wąskim zakresie; nie wprowadzać ogólnych wyjątków dla dysków, profili czy procesów pod pozorem poprawy wydajności.

Jeśli problem nie ustępuje, wyłączyć host z obsługi użytkowników oraz zabezpieczyć dzienniki i dane z Sophos Diagnostic Utility dla pomocy technicznej. W przypadku błędu występującego tylko pod Citrix lub na innej platformie wirtualnej należy wyjaśnić z pomocą techniczną Sophos i producentem platformy wymagane kroki odtworzenia problemu oraz zakres ich odpowiedzialności.

Podejrzenie problemu z SSPService na niestabilnym hoście

Jeśli usługa uruchamia się ponownie, host działa niestabilnie lub pojawiają się komunikaty dotyczące SSPService, przed wprowadzeniem zmian należy zabezpieczyć dokładne numery kompilacji agenta i komponentów, dane systemu operacyjnego, znaczniki czasu, zdarzenia Windows i dzienniki diagnostyczne. Również wpisy takie jak Process registration over the secure quota w sed.log są jedynie wskazówką diagnostyczną: nie potwierdzono tu specyficznej dla RDS usterki o określonym zakresie wersji, przebiegu zdarzeń w dziennikach ani sposobie naprawy. Nie należy utożsamiać innych problemów tylko dlatego, że pojawia się w nich podobna nazwa usługi.

Zatrzymać kolejne fale wdrożenia i wyłączyć dotknięty host z obsługi użytkowników zgodnie z procedurą serwisową i obsługi incydentów. Poprosić pomoc techniczną Sophos o identyfikator incydentu, informację o oczekiwanej obecności usługi po ponownym uruchomieniu, listę dotkniętych kompilacji, wersję zawierającą poprawkę i rozwiązanie zatwierdzone dla tego hosta. Nie zmieniać ustawienia Tamper Protection wyłącznie na podstawie tej wskazówki ani nie przedstawiać ponownego uruchomienia jako potwierdzonej naprawy.

Wycofanie zmian

Plan wycofania ustala się przed pilotażem, a jego wykonanie zależy od rodzaju błędu:

Zatrzymać kolejne przypisania i fale wdrożenia; zablokować nowe logowania na dotkniętym hoście.
W przypadku błędu polityki przywrócić wcześniej udokumentowane przypisanie polityki i ponownie przetestować po synchronizacji z Fusion.
W przypadku błędu platformy lub agenta prawidłowo zakończyć sesje, zabezpieczyć diagnostykę i przywrócić host zgodnie z zatwierdzoną procedurą odinstalowania agenta serwerowego lub odtworzenia platformy. Samo usunięcie obiektu urządzenia w Fusion nie odinstalowuje agenta.
Przywrócić host do puli brokera dopiero po sprawdzeniu aplikacji, równoległych sesji, stanu Fusion oraz ochrony albo potwierdzonej ochrony zastępczej.

Nie należy bezrefleksyjnie odtwarzać migawki na aktywnym hoście zarejestrowanym w Fusion. O tym, czy bezpieczniejszy jest powrót z kopii czy ponowne zbudowanie hosta, decyduje przetestowana procedura platformy RDS/Citrix i wirtualizacji. Po wycofaniu zmian należy ustalić przyczynę i przeprowadzić nowy pilotaż; nie wolno po prostu kontynuować nieudanej fali.