Uporządkowane wdrożenie Sophos Fusion Endpoint
Wdrożenie Sophos Fusion Endpoint nie sprowadza się do uruchomienia instalatora. Niezawodny proces obejmuje dostęp administratorów, tożsamości urządzeń i użytkowników, właściwy zakres oprogramowania, zasady, dostęp sieciowy, reprezentatywny pilotaż oraz jasno określone monitorowanie i reagowanie.
Ten artykuł wyznacza kierunek całego projektu. Konkretne czynności instalacyjne, konfigurowanie zasad i rozwiązywanie problemów opisano w powiązanych runbookach.
Proces w skrócie
- Określ zakres, osoby odpowiedzialne i kryteria sukcesu.
- Zabezpiecz dostęp do Central oraz role administratorów.
- Sprawdź licencję, tryb agenta i obsługiwane platformy.
- Zaprojektuj model tożsamości, grup i zasad.
- Przygotuj ścieżkę sieciową i mechanizm dostarczania aktualizacji.
- Przeprowadź pilotaż Windows i macOS na reprezentatywnych urządzeniach, a systemu Linux — w oddzielnej ścieżce Server Protection.
- Zweryfikuj technicznie ochronę, komunikację, zdarzenia i sposób wycofania.
- Dopiero wtedy rozszerzaj wdrożenie kontrolowanymi falami i przekaż je do regularnej eksploatacji.
Do kolejnego etapu przechodź tylko wtedy, gdy poprzedni przyniósł udokumentowany wynik. „Instalator zakończył pracę” nie oznacza jeszcze odbioru operacyjnego.
Bezpośrednie ścieżki wdrożenia
Jeśli na początek chcesz tylko zainstalować oprogramowanie, przejdź bezpośrednio do ścieżki właściwej dla danej platformy. Pełne wdrożenie zaczyna się od wymagań systemowych i ograniczeń cyklu życia oraz wymagań sieciowych i proxy. Jeżeli zakres obejmuje macOS, trzeba także uwzględnić uprawnienia macOS. Źródłem użytkowników i grup może być Microsoft Entra ID, natomiast Active Directory może dodatkowo dostarczać urządzenia i grupy urządzeń.
Zabezpieczenie dostępu administratorów przed wdrożeniem
Zabezpieczanie dostępu administratorów zacznij od MFA, passkeys i logowania federacyjnego. Federację konfiguruje się zależnie od dostawcy tożsamości przy użyciu Microsoft Entra ID, OpenID Connect lub Okta albo AD FS. W modelu RBAC najpierw ogranicz zgodnie z zadaniem role administracyjne całego tenantu, a następnie role i uprawnienia właściwe dla Endpoint.
Instalacja według platformy i metody dystrybucji
W małym pilotażu lub na pojedynczych urządzeniach skorzystaj z instrukcji ręcznej instalacji dla Windows i macOS. Automatyczne wdrożenie w systemie Windows przygotuj zgodnie z runbookiem wdrażania z wiersza poleceń i przez system dystrybucji oprogramowania; gotowe maszyny wirtualne wymagają dodatkowo procedury dla obrazów wzorcowych VDI. W przypadku komputerów Mac ścieżka Jamf Pro i MDM opisuje centralną dystrybucję wraz z wymaganymi profilami.
Linux nie jest kolejnym wariantem instalatora Endpoint dla Windows i macOS. Sophos Fusion (dawniej Sophos Central) traktuje instalację, dystrybucję skryptem i obrazy wzorcowe jako Sophos Protection for Linux, czyli Server Protection. Oddzielną procedurę opisuje artykuł Instalacja i wdrażanie Sophos Protection for Linux.
Celowa konfiguracja funkcji ochrony
Bezładne włączanie wszystkich przełączników nie poprawia konfiguracji bazowej. Ustawienia Threat Protection wyjaśniają między innymi odszyfrowywanie HTTPS, jego konsekwencje dla prywatności i związane z nim wyjątki. Wyjątki skanowania właściwe dla produktu lub aplikacji powinny mieć możliwie wąski i przejrzysty zakres. Runbook dotyczący Scheduled Scans pomaga zdecydować, czy potrzebne są dodatkowe zaplanowane skanowania, i pokazuje, jak je skonfigurować.
Funkcje kontroli użytkowników i urządzeń mają oddzielne ścieżki decyzyjne i konfiguracyjne: Web Control dla witryn i kategorii, Application Control dla aplikacji, Peripheral Control dla podłączanych urządzeń z systemem Windows i macOS oraz Data Loss Prevention dla reguł kontroli danych. Okna serwisowe, wersje oprogramowania i infrastrukturę dystrybucji określa się oddzielnie w artykule Aktualizacje, Update Cache i Message Relay.
Opcjonalne rozszerzenie o integracje XDR i MDR
Przy odpowiedniej licencji XDR lub MDR tenant może łączyć dane z innych produktów Sophos i rozwiązań innych dostawców. Obejmujący całe Central runbook Konfiguracja i weryfikacja integracji XDR prowadzi przez wybór, ograniczenia licencyjne, podłączenie i kontrolę działania; nie jest to zasada ochrony Endpoint.
Wyjaśnienie nierozstrzygniętych kwestii MDR przed wdrożeniem
Uprawnienie do sensora MDR oraz wartość produktu mdr instalatora Windows pozostają nierozstrzygnięte. Oficjalna pomoc instalacyjna MDR nadal wymienia MDR Essentials dla XDR Sensor, podczas gdy przegląd usług wskazuje MDR i MDR Plus. Nie dowodzi to uprawnienia do sensora w każdym obecnym poziomie. Instrukcja MDR dla Windows używa też mdr, ale lista produktów CLI Windows nie zawiera tej wartości. Nie dowodzi to ani jej nieprawidłowości, ani równoważności xdr lub xdrsensor; nie należy samodzielnie zastępować tej wartości.
Przed wdrożeniem sensora MDR potwierdza się z Sophos lub odpowiedzialnym partnerem poziom/SKU objęty umową, aktywną licencję we właściwym tenancie, platformę i planowaną ścieżkę instalacji. W razie wątpliwości ten etap wdrożenia pozostaje wstrzymany; należy uzyskać pisemne potwierdzenie wartości produktu dla używanej wersji instalatora Windows i wynikowego zakresu oprogramowania. Widoczna opcja nie dowodzi uprawnienia. Już zarządzane urządzenia sprawdza się przez weryfikację Agent Mode i oprogramowania; sama instalacja Endpoint i zielony stan zdrowia nie potwierdzają działającej usługi MDR.
Stan i raporty
Po wdrożeniu Protection Overview ze zdarzeniami i raportami pokazuje, czy stan ochrony i przepływ zdarzeń są wiarygodne. Account Health Check uzupełnia ten widok o odstępstwa od zaleceń Sophos, ale nie zastępuje odbioru pilotażu ani testów funkcjonalnych. Cyklicznych odbiorców, harmonogramy i nieudane dostarczenia konfiguruje się i monitoruje za pomocą zaplanowanych raportów.
Jeżeli instalacja lub eksploatacja nie działa, Endpoint Self Help i SDU dostarczają lokalnej diagnostyki i potrzebnych dzienników. Następnie można utworzyć zgłoszenie do pomocy technicznej Sophos zawierające użyteczne informacje. Dostępu partnera nie konfiguruje się doraźnie, lecz udziela i odbiera za pomocą Partner Assistance i ograniczonej czasowo Remote Assistance.
1. Określenie zakresu i odpowiedzialności
Przed pierwszą instalacją zapisz, które urządzenia i systemy operacyjne należą do projektu, które są z niego wyraźnie wyłączone oraz kto zatwierdza zmiany. Organizacja musi wyznaczyć co najmniej osoby odpowiedzialne za:
- tenant i role,
- Endpoint i zasady,
- sieć i proxy,
- alerty i incydenty bezpieczeństwa,
- aplikacje objęte pilotażem i odbiorem,
- zastępstwo w zakresie krytycznych dostępów i decyzji.
Określ także mierzalne kryteria sukcesu: urządzenie pojawia się we właściwym tenancie i grupie, otrzymuje zaplanowany tryb agenta i oczekiwane zasady, zgłasza prawidłowy stan oraz dostarcza przewidziane zdarzenia testowe. Jeszcze przed wystąpieniem awarii wskaż sposób wycofania, ścieżkę wsparcia i osobę uprawnioną do podjęcia decyzji.
2. Zabezpieczenie tenantu i dostępu administratorów
Skonfiguruj MFA dla wszystkich administratorów. Nie używaj szerokich uprawnień do codziennej pracy; przydzielaj role według zadań i regularnie je przeglądaj. Przetestuj odzyskiwanie dostępu i zastępstwo, zamiast improwizować dopiero po utracie urządzenia uwierzytelniającego.
Szczegółowe decyzje opisują artykuły Zabezpieczanie logowania do Sophos Fusion za pomocą MFA i dostawcy tożsamości oraz Planowanie ról i uprawnień Sophos Fusion Endpoint.
3. Określenie zakresu produktu i granic platform
Przed wdrożeniem sprawdź łącznie licencję, typ urządzenia, system operacyjny i wymagany tryb agenta. Tryby i produkty dodatkowe widoczne w tenancie zależą od rzeczywistej umowy i platformy; nie wyciągaj więc wniosków o dostępności na podstawie zrzutu ekranu lub ogólnej strony produktu.
Tryb Endpoint zapewnia ochronę Sophos Endpoint, XDR dodaje przewidziane funkcje wykrywania i reagowania, a XDR Sensor nie stanowi samodzielnej ochrony przed złośliwym oprogramowaniem. Wariant z sensorem nadal wymaga oddzielnie utrzymywanego produktu ochronnego. Wybór, zmianę i kontrolę opisuje artykuł Zarządzanie trybem i oprogramowaniem agenta Sophos Endpoint, a ograniczenia handlowe i techniczne — Licencje Sophos Fusion Endpoint.
Dla systemów Windows i macOS przygotuj oddzielne ścieżki pilotażowe. Przed podjęciem decyzji o każdej platformie sprawdź aktualne wymagania systemowe i informacje o wycofaniu. Odpowiednią procedurę opisuje artykuł Planowanie wymagań systemowych i cyklu życia Sophos Endpoint.
Linux Runtime Detection Profiles służą do ochrony obciążeń Linux i środowisk cloud-native. Doboru zasad i wdrożenia sensorów nie należy mimochodem włączać do wdrożenia Endpoint dla Windows i macOS. Trzeba je zaplanować jako oddzielną ścieżkę obciążeń, zgodną z aktualnymi wymaganiami Sophos.
Cykl życia profilu zaczyna się w My Products > Global Settings > Protection and Remediation > Linux Profiles. Create Profile tworzy wersję 1, a pola Profile Name, Content Version i opcjonalne Change Description dokumentują jej stan. Następnie włączaj lub wyłączaj poszczególne reguły na kartach Detection Analytics, Smart Policy i BETA Ransomware. Nowy lub zmieniony profil przypisz najpierw do Linux Runtime Detection Policy dla serwerów pilotażowych i sprawdź oczekiwany alert testowy. Create New Version zachowuje historię. Duplicate klonuje najnowszą wersję jako niezależny profil; zmiany i przypisania kopii nie wpływają na profil źródłowy. Aktywny profil można usunąć dopiero po odłączeniu go od wszystkich zasad.
Do strojenia służą filtry Category, Enabled, Modified i Configurable. Hide filters tylko je ukrywa, a Clear All usuwa. Listy Allow/Block dotyczą wybranej reguły. Sophos Protection for Linux automatycznie pobiera nowy content SophosLabs, natomiast Sophos Linux Sensor trzeba aktualizować ręcznie. YAML z Export Latest Version zawiera wyłącznie zmiany względem ustawień domyślnych i nie jest pełnym runtimedetections.yaml. W przypadku Sophos Linux Sensor scal z istniejącym plikiem tylko te zmiany i edytuj wyłącznie pola oraz typy danych obsługiwane przez schemat wdrożonej wersji contentu. Zatrzymaj wdrożenie przed pilotażem przy konkretnych błędach: nieprawidłowej składni lub wcięciach YAML, nieznanych kluczach, błędnych typach danych, braku pól wymaganych albo niedozwolonych wartościach reguł. Dopiero po pomyślnej walidacji parsera i schematu wersjonuj plik, wdróż go na pilotażu i sprawdź alerty oraz Runtime; w razie problemów przypisz poprzednią wersję profilu lub przywróć poprzednią zweryfikowaną konfigurację sensora.
4. Projektowanie tożsamości, grup i zasad
Zasady użytkownika podążają za osobą, a zasady komputera — za urządzeniem. Najpierw określ więc autorytatywne źródło użytkowników i grup oraz sposób zapobiegania duplikatom i nieaktualnym tożsamościom. Implementację opisuje artykuł Zarządzanie użytkownikami i grupami Sophos Fusion Endpoint.
Łatwy w utrzymaniu model urządzeń zwykle zaczyna się od kilku przejrzystych grup:
- urządzenia pilotażowe z aktywnie wspieranymi użytkownikami,
- standardowe urządzenia produkcyjne,
- urządzenia krytyczne lub odmienne technicznie,
- wyjątki ograniczone czasowo,
- urządzenia testowe dla nowych wersji oprogramowania.
Dla każdego typu zasad obowiązuje pierwsza pasująca aktywna zasada. Dlatego przed masowym wdrożeniem sprawdź konfigurację bazową, kolejność i faktyczne przypisania. Usunięcia zasady w Central nie można cofnąć: wcześniej wyeksportuj lub udokumentuj ustawienia i przypisania oraz wskaż objęte urządzenia. Model ten szczegółowo opisuje artykuł Prawidłowe projektowanie zasad Sophos Fusion Endpoint.
Nie włączaj ani nie wyłączaj wszystkich funkcji ochronnych i kontrolnych jednakowo. Threat Protection, Web, Applications, Peripherals, DLP, DNS Protection, Updates, Tamper Protection, Data Collection i Response trzeba ocenić według licencji, platformy i potrzeb organizacji. Nowe funkcje kontrolne, gdy jest to możliwe i uzasadnione, uruchamiaj najpierw w małej grupie pilotażowej. Każdy wyjątek wymaga uzasadnienia, właściciela, ograniczonego zakresu i terminu przeglądu.
5. Weryfikacja sieci i aktualizacji przed instalacją
Endpoint musi mieć dostęp do wymaganych usług Sophos w rzeczywiście używanym kontekście urządzenia i usługi. Pomyślne otwarcie strony w przeglądarce administratora nie dowodzi, że instalacja, komunikacja agenta i aktualizacje działają przez proxy, TLS Inspection lub sieci segmentowane.
Przed pilotażem przetestuj więc DNS, HTTPS, uwierzytelnianie proxy, weryfikację certyfikatów i przewidziane ścieżki awaryjne. Aktualną kolejność metod połączenia i dynamiczne cele Sophos opisuje artykuł Wymagania sieciowe i proxy Sophos Endpoint.
Przepustowość aktualizacji, pakiety oprogramowania, etapy utrzymania, Update Cache i Message Relay wymagają oddzielnej decyzji operacyjnej. Globalne ustawienie przepustowości nie zastępuje ani planowania pojemności, ani pilotażu. Szczegóły i scenariusze awarii opisuje artykuł Aktualizacje Sophos Endpoint, Update Cache i Message Relay.
6. Wdrożenie reprezentatywnego pilotażu
W obszarze My Environment > Installers pobierz instalator właściwy dla zaplanowanego tenantu i celu. Traktuj instalatory jak materiały dostępowe i udostępniaj je wyłącznie kontrolowanymi kanałami dystrybucji.
W obszarze Endpoint dostępne są instalatory Protection, ZTNA i Device Encryption. Pełne instalatory dla Windows i macOS zawierają produkty Endpoint objęte licencją tenantu; opcja Choose Components pozwala przed pobraniem precyzyjnie wybrać potrzebne składniki. Ten instalator Endpoint nie jest przeznaczony dla systemu Linux, który należy do opisanej wyżej oddzielnej ścieżki Server Protection.
Jeśli DNS Protection for endpoints ma być używane w ramach Workspace Protection, to przekazanie dotyczy wyłącznie obsługiwanych endpointów Windows; nie obejmuje systemów macOS ani Windows Server. Na tych endpointach Windows zainstalowany agent Endpoint jest tylko wspólnym wymaganiem wstępnym. Następnie skonfiguruj i sprawdź komponent DNS oraz jego własną zasadę zgodnie z oddzielnym runbookiem Konfigurowanie Sophos DNS Protection dla endpointów; nie włączaj ich do tego procesu jako ogólnej zasady ochrony Endpoint.
Nie mieszaj procedur dla poszczególnych platform:
- Windows: Instalacja Sophos Fusion Intercept X
- macOS: Instalacja Sophos Fusion Endpoint
- automatyczne wdrożenie Windows: Automatyczne wdrażanie Sophos Endpoint w systemie Windows
Pilotaż nie może obejmować wyłącznie nieskomplikowanych laptopów działu IT. Powinien odzwierciedlać używane wersje systemów operacyjnych, segmenty sieci, pracę zdalną lub VPN, aplikacje krytyczne dla organizacji oraz istniejące oprogramowanie zabezpieczające, backupowe, DLP i szyfrujące. Zmiany obserwuj najpierw na kilku urządzeniach; sam odstęp czasowy między falami nie zastępuje odbioru technicznego.
7. Techniczny odbiór pilotażu
Urządzenie pilotażowe można zatwierdzić dopiero po udokumentowanym przejściu wszystkich przewidzianych kontroli:
- Lokalny agent zgłasza prawidłowy stan.
- Urządzenie pojawia się we właściwym tenancie i zaplanowanej grupie.
- Tryb agenta i zainstalowane składniki odpowiadają zatwierdzonemu planowi.
- Na stronie urządzenia widoczne są oczekiwane, faktycznie obowiązujące zasady.
- Last Active, Events i Updates mają wiarygodny przebieg.
- Zatwierdzony test ochrony generuje oczekiwane zdarzenie lub alert.
- Sprawdzono aplikacje biznesowe, zmianę sieci i wymagane ponowne uruchomienie.
- Odbiór alertów, ich triage i eskalacja działają prawidłowo.
- Na urządzeniu testowym sprawdzono odinstalowanie lub inną zdefiniowaną drogę powrotu.
Bezpieczne testy opisuje artykuł Bezpieczne testowanie funkcji ochronnych Sophos Endpoint. Jeśli urządzenie pozostaje w nieprawidłowym stanie, nie instaluj agenta ponownie na ślepo. Artykuły Obsługa alertów Sophos Endpoint i Account Health oraz Systematyczne rozwiązywanie problemów z instalacją Sophos Endpoint prowadzą do właściwej diagnostyki.
Account Health Check jest dodatkowym widokiem kontrolnym. Wykrywa określone odstępstwa od zaleceń Sophos, ale nie dowodzi ani poprawnego działania aplikacji biznesowych, ani pełnego bezpieczeństwa tenantu. Automatyczne poprawki mogą objąć wiele urządzeń lub zasad i należy traktować je jako zmianę. Szczegóły opisuje artykuł Prawidłowe korzystanie z Sophos Fusion Account Health Check.
8. Świadoma decyzja o gotowości do reagowania i analizy śledczej
Przed szerokim wdrożeniem określ, kto obsługuje alerty, kiedy izoluje się urządzenie oraz jakie dane wolno gromadzić na potrzeby dochodzenia i pomocy technicznej. Forensic Snapshots rejestrują dane o aktywności urządzenia. Ich przechowywanie, eksport, opcjonalne wysyłanie do własnego zasobnika S3 oraz dostęp do nich wymagają więc świadomej decyzji dotyczącej bezpieczeństwa i prywatności.
Tworzenie, przechowywanie i konwersja Forensic Snapshots
Migawkę utwórz przez My Environment > Computers & Servers > urządzenie > Summary > More actions > Create forensic snapshot > Create now albo Create forensic snapshot w Threat Graph. Migawki ręczne trafiają domyślnie do %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Forensic Snapshots\, a dane z detekcji do %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Saved Data\. Przy Tamper Protection potrzebny jest podwyższony wiersz poleceń. Domyślny zakres wynosi dwa tygodnie; zmień go lub wybierz All log data w Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots. Najpierw ustal wolne miejsce, dostęp, retencję i bezpieczne usuwanie.
Do analizy zachowaj dowodową kopię .tgz. W 64-bitowym Windows wybierz eksporter 64-bitowy; tylko Windows 32-bit wymaga drugiej wersji. Przed pobraniem sprawdź architekturę w PowerShell poleceniem (Get-CimInstance Win32_OperatingSystem).OSArchitecture.
Dopiero na tym etapie rozpocznij pobieranie od Sophos przez HTTPS: uzyskaj SDR Exporter 64-bit albo uzyskaj SDR Exporter 32-bit. Wypełnij formularz Sophos i przyjmij wyłącznie plik udostępniony następnie przez Sophos. Umieść go w nowym katalogu roboczym z prawem zapisu tylko dla odpowiedzialnych śledczych; nie używaj załącznika e-mail ani zewnętrznego mirrora. Przed uruchomieniem zweryfikuj podpis Authenticode i oblicz hash dowodowy. Hash identyfikuje dokładnie pobraną wersję, ale bez osobno opublikowanej wartości referencyjnej Sophos nie stanowi niezależnego dowodu pochodzenia:
$tool = '.\SDRExporterx64.exe'
$expectedSubject = $env:SDR_EXPORTER_EXPECTED_SUBJECT
$expectedThumbprint = $env:SDR_EXPORTER_EXPECTED_THUMBPRINT
if ([string]::IsNullOrWhiteSpace($expectedSubject) -or
[string]::IsNullOrWhiteSpace($expectedThumbprint)) {
throw 'Set the approved signer subject and thumbprint before validation.'
}
$expectedThumbprint = ($expectedThumbprint -replace '\s', '').ToUpperInvariant()
if ($expectedThumbprint -notmatch '\A[0-9A-F]+\z') {
throw 'The approved signer thumbprint is not hexadecimal.'
}
$sig = Get-AuthenticodeSignature -FilePath $tool
if ($sig.Status -ne 'Valid' -or $null -eq $sig.SignerCertificate) {
throw "SDR Exporter: Authenticode status is $($sig.Status)."
}
$actualThumbprint = ($sig.SignerCertificate.Thumbprint -replace '\s', '').ToUpperInvariant()
if (-not [string]::Equals($sig.SignerCertificate.Subject, $expectedSubject,
[StringComparison]::Ordinal) -or
-not [string]::Equals($actualThumbprint, $expectedThumbprint,
[StringComparison]::Ordinal)) {
throw 'SDR Exporter: signer does not exactly match the approved acquisition record.'
}
$chain = [Security.Cryptography.X509Certificates.X509Chain]::new()
$chainBuilt = $chain.Build($sig.SignerCertificate)
[pscustomobject]@{
Status = $sig.Status
StatusMessage = $sig.StatusMessage
SignerSubject = $sig.SignerCertificate.Subject
SignerThumbprint = $actualThumbprint
SignerIssuer = $sig.SignerCertificate.Issuer
SignerNotBefore = $sig.SignerCertificate.NotBefore
SignerNotAfter = $sig.SignerCertificate.NotAfter
ChainBuilt = $chainBuilt
ChainStatus = ($chain.ChainStatus.Status -join ', ')
TimestampSubject = $sig.TimeStamperCertificate.Subject
TimestampThumbprint = $sig.TimeStamperCertificate.Thumbprint
}
$chain.ChainElements | ForEach-Object {
[pscustomobject]@{
ChainSubject = $_.Certificate.Subject
ChainThumbprint = $_.Certificate.Thumbprint
ChainStatus = ($_.ChainElementStatus.Status -join ', ')
}
}
Get-FileHash -Algorithm SHA256 -Path $tool
Przed uruchomieniem bloku ustaw SDR_EXPORTER_EXPECTED_SUBJECT i SDR_EXPORTER_EXPECTED_THUMBPRINT na dokładne wartości z zatwierdzonego wewnętrznie rejestru pozyskania otrzymanego w osobnym, zaufanym procesie; nigdy nie kopiuj ich ze sprawdzanego pliku. Status Valid i dokładna zgodność obu wartości są kryteriami dopuszczenia. Zachowaj wyświetlone szczegóły łańcucha podpisującego i znacznika czasu wraz z wynikiem SHA-256 jako materiał dowodowy. Hash identyfikuje pozyskany plik, ale bez oddzielnie zaufanej wartości referencyjnej nie potwierdza jego pochodzenia. Jeśli brakuje zatwierdzonej wartości, dowolna kontrola zakończy się niepowodzeniem albo hash później się różni, nie uruchamiaj pliku: usuń go i zbadaj lub pobierz ponownie z powyższego łącza Sophos. Następnie uruchom narzędzie i przetwarzaj dane wyłącznie z chronionej lokalizacji w podwyższonym wierszu poleceń, używając różnych ścieżek wejścia i wyjścia:
SDRExporterx64.exe -i <snapshot.tgz> -o <snapshot.sqlite> -f sqlite
Dla JSON użyj -f json i odpowiedniej nazwy wyjściowej; program 32-bit to SDRExporterx86.exe. Ścieżki ze spacjami ujmij w cudzysłów. Po zakończeniu bez błędu sprawdź, czy wynik nie jest pusty i można go otworzyć i odpytywać jako SQLite albo sparsować jako JSON. W dzienniku incydentu zapisz hash wejścia, hash eksportera, polecenie, czas i ścieżkę wyjścia; skonwertowany plik chroń i przechowuj tak jak migawkę.
Po błędzie konwersji nie eksperymentuj na oryginale. Sprawdź architekturę i nazwę, podpis, cudzysłowy, prawa odczytu i zapisu, wolne miejsce oraz integralność roboczej kopii .tgz, a następnie użyj nowej ścieżki wyjścia. Częściowy wynik nie jest rezultatem. Eksporter niczego nie instaluje: wycofanie polega na zatrzymaniu procesu i bezpiecznym usunięciu niepełnych wyników, a po zakończeniu także eksportera z katalogu roboczego. Roboczą kopię .tgz usuń tylko po zweryfikowanej konwersji i zgodnie z procesem incydentu. Oryginał dowodowy i wymagane dzienniki pozostaw bez zmian do końca retencji.
Opcjonalne wysyłanie do własnego zasobnika S3
Bezpośredni upload wymaga Windows oraz licencji XDR lub MDR. W AWS ogranicz dedykowaną Managed Policy do s3:ListBucket dla arn:aws:s3:::<bucketName> i s3:PutObject dla arn:aws:s3:::<bucketName>/*. Włącz Upload forensic snapshot to an AWS S3 bucket w Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots. Użyj AWS Account ID i AWS External ID w Trust Policy osobnej IAM Role dla sts:AssumeRole, a po propagacji zapisz S3 bucket name, opcjonalny katalog i Role ARN.
Wybierz region AWS z uwzględnieniem rezydencji danych, opóźnień i kosztów transferu oraz wymagań odtwarzania awaryjnego. Przed zapisaniem w Central poczekaj na propagację roli IAM do wszystkich regionów AWS; może to potrwać do pięciu minut.
Bucket Policy i IAM Permissions Boundary ograniczają dostęp do roli i uprawnionych śledczych. Reguła Lifecycle usuwa nieukończone uploady multipart i przeterminowane dane. Zasobniki szyfrowane KMS nie są obsługiwane; AES-256 jest obsługiwany i żądany przez Sophos. Unikaj niedozwolonych znaków i dopuść S3 na firewallu. Zatwierdź pełną migawkę pilotażową możliwą do odczytu i konwersji przez uprawnioną osobę, przy odrzuconym dostępie nieuprawnionym. Potem usuń zbędne role, zasady i przypisania.
Pozostałe działania opisuje Badanie detekcji Sophos Endpoint i Threat Graphs.
Zezwalanie i blokowanie plików w całym tenancie
W Global Settings > Protection and Remediation > Allow and Block > Files karta Allowed Applications pokazuje źródło zezwolenia. Zależnie od platformy używa ono certyfikatu, SHA-256 lub ścieżki; certyfikat i ścieżka mogą objąć wiele wersji. Aplikacja może działać dla wszystkich użytkowników i jest wyłączona z kolejnych Threat Detections, lecz nadal działa ochrona przed exploitami, ransomware i złośliwym zachowaniem. Przed Allow sprawdź wydawcę, podpis lub hash, właściciela, powód, zakres i termin. Remove cofa zezwolenie; na pilotażu potwierdź powrót detekcji.
Blocked Items wymaga XDR i blokuje podejrzane aplikacje po SHA-256 na Windows, ale nie pliki o reputacji trusted ani inne obiekty. Wybierz Add, wpisz SHA-256 i Reason, potem Save. Wpisy dozwolonych i zablokowanych plików współdzielą jeden limit 5000 wpisów w całym tenancie; przed masowym dodaniem sprawdź łączną pojemność obu list. Na pilotażu potwierdź brak uruchomienia i oczekiwany Event. Remove jest drogą powrotu i także wymaga testu. Inne wyjątki opisuje Bezpieczne konfigurowanie wyjątków Sophos Fusion Endpoint.
9. Zatwierdzanie fal i przekazanie do regularnej eksploatacji
Po zatwierdzeniu pilotażu dla każdej fali określ objęte nią urządzenia, osobę monitorującą postęp i sygnały zatrzymania. Mogą nimi być na przykład liczne błędy instalacji, brak komunikacji agentów, nieoczekiwane przypisania zasad, zakłócenia działania aplikacji lub liczba alertów, której zespół nie jest w stanie obsłużyć.
Regularna eksploatacja obejmuje co najmniej:
- codzienną odpowiedzialność za alerty krytyczne i ogniska zagrożeń,
- regularny przegląd urządzeń nieaktywnych lub w nieprawidłowym stanie,
- przegląd licencji, trybów agenta i cyklu życia platform,
- kontrolowane pilotaże oprogramowania i zasad,
- kontrolę terminów ważności wyjątków,
- sprawdzanie proxy, Update Cache i Message Relay,
- udokumentowane ścieżki Response, ochrony prywatności i pomocy technicznej.
Fala kończy się dopiero wtedy, gdy jej urządzenia zostały nie tylko zainstalowane, lecz także odebrane technicznie i włączone do tych procesów operacyjnych.