Łączenie Sophos Firewall z Sophos Fusion

Nie ma konieczności łączenia Sophos Firewall z Sophos Fusion (dawniej Sophos Central). Pojedyncza zapora może być w pełni zarządzana lokalnie przez WebAdmin. Jednak w wielu środowiskach warto połączyć ją z Sophos Fusion, ponieważ oferuje to dodatkowe funkcje zarządzania, kopii zapasowych, raportowania i bezpieczeństwa.

Ten artykuł pomoże podjąć decyzję, kiedy Sophos Fusion jest przydatne, a kiedy wystarczy lokalne zarządzanie.

Obecna nazwa platformy to Sophos Fusion, wcześniej Sophos Central. Menu zapory, przyciski i alert rejestracji mogą nadal używać nazwy Sophos Central; podczas wykonywania opisanych kroków należy kierować się tymi widocznymi etykietami interfejsu. Centralnie zarządzaną zaporę można również zintegrować jako bramę ZTNA, aby zapewnić dostęp do zasobów wewnętrznych. Sama rejestracja nie konfiguruje tej bramy ani nie przyznaje dostępu do tych zasobów; wdrożenie ZTNA i jego politykę dostępu należy zaplanować osobno.

Krótka odpowiedź

Jeśli zarządzasz tylko jedną lokalną zaporą Sophos Firewall i nie chcesz korzystać z funkcji Central, Sophos Fusion nie jest konieczne.

Jeśli zarządzasz wieloma zaporami, chcesz centralnie analizować dane logów, przechowywać kopie zapasowe konfiguracji w chmurze lub używasz innych produktów Sophos, takich jak Sophos Endpoint, Sophos Fusion przynosi wyraźne korzyści.

Decyzja nie powinna jednak sprowadzać się tylko do pytania: połączyć czy nie połączyć? Ważniejsze jest, które funkcje Central naprawdę chcesz aktywować. Zapora może być zarejestrowana w Sophos Fusion bez konieczności aktywnego korzystania z każdej funkcji zarządzania, raportowania czy kopii zapasowych.

Zero Touch: wdrożenie z użyciem pliku konfiguracyjnego

Oprócz zarządzania istniejącymi zaporami Sophos Fusion oferuje również Zero Touch: nowe zapory można instalować z użyciem pliku konfiguracyjnego Zero Touch. Wymaga to konta Sophos Fusion; interfejs może nadal używać nazwy Sophos Central. Ta możliwość jest istotna przy planowaniu instalacji w nowych lokalizacjach, jeśli wdrożenie ma być przygotowane przez Central. Nie jest to to samo co późniejszy zdalny dostęp do WebAdmin czy dystrybucja polityki grupowej.

Przed wyborem sposobu wdrożenia należy ustalić docelowy tenant, odpowiedzialnych administratorów i ich uprawnienia, urządzenie i numer seryjny, potrzeby licencyjne oraz połączenie z internetem. Późniejsze zarządzanie przez Central nadal wymaga działającego połączenia IPv4; wymagania licencyjne opisane w tym artykule również pozostają w mocy. Zero Touch nie jest warunkiem lokalnego działania zapory ani metodą naprawy zapory już używanej w środowisku produkcyjnym.

Należy świadomie rozróżniać poszczególne zadania:

• Nowa instalacja z użyciem Zero Touch: Plik konfiguracyjny służy do wdrożenia nowej zapory. Ten przegląd opisuje tę możliwość, ale nie stanowi pełnej instrukcji tworzenia ani stosowania pliku. Tę ścieżkę należy zaplanować przed instalacją; z poniższych kroków dotyczących OTP nie należy wywodzić procedury Zero Touch.
• Konfiguracja lokalna, claim i licencje: Artykuł Konfiguracja Sophos Firewall, claim i aktywacja licencji opisuje podstawową konfigurację lokalną, przypisanie do tenanta przez claim oraz odrębną aktywację lub synchronizację licencji. Tych zadań nie należy utożsamiać z rejestracją na potrzeby zarządzania.
• Połączenie istniejącej zapory: Opisana w dalszej części ścieżka z użyciem OTP wymaga zapory już skonfigurowanej i przypisanej przez claim do właściwego tenanta. OTP rejestruje ją w Central Management, ale nie zastępuje ani claimu, ani aktywacji subskrypcji. Przypisanie zapory do klienta przez partnera również nie zastępuje claimu.
• Wspólne zarządzanie wieloma zaporami: Artykuł Bezpieczne korzystanie z Sophos Fusion Firewall Groups wyjaśnia wspólne polityki i skutki Full Sync. Zarządzanie grupami jest odrębnym zadaniem operacyjnym, a nie ścieżką instalacji Zero Touch.

Korzyści z połączenia z Sophos Fusion

Centralny przegląd

W Sophos Fusion można zobaczyć zarejestrowane zapory w jednym miejscu. Jest to szczególnie pomocne, gdy zarządzasz wieloma lokalizacjami lub urządzeniami tej samej organizacji.

Typowe korzyści:

• Przegląd statusu zapór
• Numery seryjne i informacje o licencjach
• Status oprogramowania i bezpieczeństwa
• Centralne raporty
• Szybkie przełączanie między wieloma zaporami

Zarządzanie przez Sophos Fusion

Dzięki Manage from Sophos Central można uzyskać dostęp do zarządzania zaporą przez Sophos Fusion. Jest to często bezpieczniejsze niż udostępnianie WebAdmin Console bezpośrednio w internecie.

Dostęp do zarządzania nie zastępuje jednak solidnej strategii administracyjnej. Konta administratorów, MFA, role, Device Access i reguły ACL muszą być nadal świadomie konfigurowane. Według Sophos funkcja Central Firewall Management wymaga dodatkowo aktywnej płatnej subskrypcji innej niż Base Firewall albo aktywnej licencji wsparcia Sophos uprawniającej do tej funkcji, na przykład Enhanced Support. Sama licencja Base Firewall nie wystarcza; nie każda umowa wsparcia automatycznie daje takie uprawnienie.

Często pomija się jeden szczegół techniczny: Sophos Fusion może zarządzać zaporami tylko wtedy, gdy mają one dostęp do internetu przez IPv4. W środowiskach korzystających wyłącznie z IPv6 albo ściśle odseparowanych tę ścieżkę trzeba sprawdzić przed aktywacją.

Jeśli zmiany przez Central nie są odbierane na zaporze zgodnie z oczekiwaniami, należy dodatkowo sprawdzić Sophos Fusion Firewall Management Task Queue. Tam można zobaczyć, czy zadania grupowe lub zadania zapory oparte na API są w toku, nie powiodły się lub zostały pominięte.

Bezpieczne użycie Sophos Fusion Firewall Groups wyjaśnia, jak wiele firewalli otrzymuje wspólną politykę oraz co rzeczywiście oznaczają Full Sync i Skip full sync.

Dla wielu lokalizacji Central może również koordynować połączenia VPN oparte na trasach, interfejsy XFRM, trasy i reguły. Konfiguracja i weryfikacja grupy połączeń SD-WAN w Sophos Fusion opisuje planowanie, rozwiązywanie konfliktów i lokalną weryfikację.

Ograniczenia Central Firewall Management

Central Firewall Management jest dodatkową ścieżką administracji, ale nie zastąpi w pełni lokalnej obsługi firewalla, lokalnych logów ani przetestowanego dostępu awaryjnego. Zwłaszcza przy wielu administratorach, grupach firewalli i klastrach HA warto znać najważniejsze ograniczenia, aby normalnego zachowania platformy nie traktować jak błędu konfiguracji.

Typowe obserwacje z eksploatacji:

• Dwaj administratorzy otwierają ten sam firewall przez Central jednocześnie: Dla jednej zapory może być aktywna tylko jedna sesja Central Manager. Jeśli drugi administrator przejmie sesję, pierwszy może zobaczyć ciągłe ładowanie lub błąd połączenia. Należy uzgodnić, kto korzysta z sesji, zamknąć równoległe sesje, odczekać kilka minut i sprawdzić lokalny WebAdmin.
• Rola read-only albo helpdesk nie widzi zgrupowanych firewalli: Role w Central należy przetestować na rzeczywistych kontach przed użyciem operacyjnym. Nie wszystkie widoki i funkcje grup są widoczne dla każdej roli.
• Pary HA pojawiają się podwójnie albo na kilku stronach: Zależnie od widoku Central członkowie klastra HA mogą być pokazani osobno. Podczas wykonywania operacji decydujący pozostaje lokalny status HA.
• Reguł zapory nie da się przesuwać na poziomie grupy tak jak lokalnie: Nie wszystkie lokalne działania WebAdmin mają odpowiedniki w grupach Central. Po zmianach grupowych trzeba lokalnie zweryfikować kolejność reguł i ich działanie.
• Importowane grupy lub reguły WAF zachowują się w Central nietypowo: Po imporcie konfiguracji, Full Sync albo imporcie reguł WAF trzeba sprawdzić widok Central, docelowy firewall i Task Queue.

Sophos Fusion koordynuje zarządzanie, ale krytyczne działanie weryfikuje się na zaporze. Po zmianach grupowych, zadaniach firmware, zmianach WAF lub pracach HA sprawdź lokalnie reguły, usługi, stan HA, logi i połączenia objęte zmianą.

Kopie zapasowe konfiguracji w Sophos Fusion

Zapora może wysyłać kopie zapasowe konfiguracji do Sophos Fusion. Jest to przydatne, gdy urządzenie musi zostać wymienione lub przywrócone, a lokalne kopie zapasowe nie są dostępne.

W Sophos Fusion można ustawić zaplanowane kopie zapasowe dla zarejestrowanych zapór. Dostępne są interwały Daily, Weekly i Monthly. Dzięki temu można na przykład określić, że wybrane zapory codziennie, co tydzień lub co miesiąc wysyłają kopię zapasową konfiguracji do Sophos Fusion.

Aktualna dokumentacja Sophos dotycząca kopii zapasowych wskazuje Global Settings > Products and Services > Firewall > Schedule Backup jako miejsce konfiguracji harmonogramu. Jeśli ścieżka Firewall Management > Backup pokazana na zrzucie ekranu nie występuje w Twoim interfejsie, skorzystaj z tej drogi.

Sophos Fusion nie przechowuje wszystkich automatycznych kopii zapasowych bez ograniczeń. Domyślnie zachowywanych jest pięć najnowszych kopii, a starsze są usuwane. Jedną kopię można dodatkowo oznaczyć do trwałego przechowywania. W klastrach HA Primary i Auxiliary są widoczne w harmonogramie backupu, ale według Sophos tworzona jest tylko kopia z urządzenia Primary.

Dla operacji ważne są dwa szczegóły: Sophos Fusion próbuje wykonać backup maksymalnie pięć razy, a przy trwałym niepowodzeniu generuje alert oraz e-mail do administratora Central. Jeśli firewall zostanie usunięty z zarządzania Sophos Fusion, Sophos Fusion usuwa powiązane pliki backupu. Backupy w chmurze są więc pomocne, ale nie zastępują własnej strategii backupu i odtwarzania.

Mimo to nie należy polegać tylko na jednej metodzie tworzenia kopii zapasowych. Dla systemów produkcyjnych nadal warto regularnie tworzyć lokalne lub zewnętrzne kopie zapasowe. Ważne są również hasło do kopii zapasowej i Secure Storage Master Key.

Central Firewall Reporting

Dzięki Central Firewall Reporting zapora wysyła dane logów i raportów do Sophos Fusion. Dzięki temu można analizować raporty przez dłuższe okresy i centralnie je przeszukiwać.

W Sophos Fusion dostępne są do tego pulpity nawigacyjne, Report Hub, Report Generator, zapisane szablony i zaplanowane eksporty. Można tworzyć raporty dla pojedynczych zapór lub wielu zapór, filtrować okresy, wyszukiwać określone zdarzenia i eksportować wyniki jako PDF, CSV lub HTML. Dla regularnych analiz można dodatkowo zaplanować raporty i automatycznie je udostępniać.

Według Sophos zapisywanie szablonów, planowanie eksportów i pobieranie raportów wymaga licencji Central Firewall Reporting Advanced. W przypadku raportów obejmujących wiele zapór wszystkie wybrane zapory muszą mieć odpowiednią licencję.

Typowe szablony raportów to:

• Antivirus
• Bandwidth usage
• Cloud app risks and usage
• Firewall
• IPS
• Log viewer and search
• SD-WAN
• SD-WAN SLA trend
• SD-WAN bandwidth usage
• Security posture assessment
• Synchronize app
• Threat geo activity
• Threats and events blocked
• VPN usage
• Web usage
• Web user risks
• X-Ops
• Zero-day protection

Czas przechowywania zależy od licencji:

• Aktywna subskrypcja zapory: Do 7 dni — dla podstawowych raportów i krótkich retrospekcji
• Xstream Protection / Central Orchestration: Do 30 dni — w zależności od pakietu i uprawnień
• Central Firewall Reporting Advanced: Do 365 dni — 100 GB dodatkowej przestrzeni na licencję

Szczegóły aktywacji i wyboru logów opisano w artykule Aktywacja Central Firewall Reporting.

Synchronized Security i Security Heartbeat

Jeśli Sophos Endpoint i Sophos Firewall są zarządzane wspólnie przez Sophos Fusion, można korzystać z Synchronized Security. Zapora i Endpoint wymieniają informacje o bezpieczeństwie.

Przykłady:

• Zapora widzi Security Heartbeat z Endpointów.
• Urządzenia z czerwonym Heartbeat mogą być automatycznie ograniczane.
• Widok sieci i Endpointów jest lepiej połączony.
• W przypadku incydentów szybciej widać, którego użytkownika lub urządzenia dotyczy incydent.

To jedna z najważniejszych dodatkowych korzyści, jeśli oprócz zapory używane są również Sophos Endpoint, MDR lub XDR.

Security Heartbeat może również przesyłać do firewalla tożsamość domenową Windows zarządzanego endpointu. Konfiguracja Synchronized User ID Authentication opisuje bezpieczny proces pilotażowy, reguły i HA.

Zweryfikować Security Heartbeat po rejestracji

Widoczność zapory w Sophos Fusion nie potwierdza jeszcze, że Security Heartbeat działa dla endpointów. Wymagane są konto Sophos Fusion, co najmniej jeden endpoint zarządzany przez Sophos Fusion z licencją próbną lub pełną oraz ważna subskrypcja Network Protection na zaporze. Podczas rejestracji zapory SFOS automatycznie włącza Security Heartbeat i Synchronized Application Control.

Do kontrolowanej pierwszej weryfikacji nadaje się pojedynczy zarządzany endpoint pilotażowy:

1. W System > Sophos Central sprawdzić, czy zapora jest zarejestrowana, a Security Heartbeat aktywny.

2. W Sophos Fusion, w My Products > Firewall Management > Firewalls, potwierdzić alert A new firewall has been successfully registered to Sophos Central. Alert ten potwierdza rejestrację, ale jeszcze nie działanie reguły.

3. Dla endpointu pilotażowego w Sophos Fusion sprawdzić tenant, bieżący stan zabezpieczeń oraz zdarzenia z tego samego okresu.

4. W sekcji Control Center > User & device insights > Security Heartbeat sprawdzić, czy licznik Connected w wiarygodny sposób uwzględnia oczekiwany stan endpointu pilotażowego. Według Sophos widok szczegółowy pozostaje pusty, gdy wszystkie endpointy mają stan zielony; osobno wyświetlane są tylko endpointy czerwone i żółte.

5. Sprawdzić faktycznie dopasowaną regułę zapory. Bez skonfigurowanego warunku heartbeat stan jest jedynie widoczny; na dostęp wpływają dopiero ustawienia w Configure Synchronized Security Heartbeat. Osobno sprawdzić minimalny wymagany stan heartbeat dla źródła i celu — warunek źródłowy nie oznacza automatycznie takiego samego wymagania dla celu. Dla ruchu WWW sprawdzić również Web > Exceptions: Sophos dokumentuje, że wyjątek pomijający sprawdzanie polityki może pozostawić żądania WWW niezablokowane mimo opcji Block clients with no heartbeat. Wynik należy potwierdzić dla konkretnego zatwierdzonego ruchu testowego, a nie wywnioskować go wyłącznie z etykiety Missing.

6. Dopiero po ustaleniu tej wartości odniesienia włączyć warunek heartbeat w wąsko ograniczonej regule pilotażowej, włączyć logowanie i przetestować dozwolony ruch z endpointu o zielonym stanie.

Sprzeczność w dokumentacji Sophos: Przegląd Security Heartbeat dla SFOS 22 i 23 stwierdza ogólnie w sekcji dotyczącej VPN, że przy stanie Missing cały ruch tego endpointu jest blokowany przez zaporę. Szczegółowy opis Heartbeat uzależnia natomiast wpływ na dostęp od reguł i wyraźnie wskazuje wyjątek dotyczący sprawdzania polityk w Web > Exceptions: żądania WWW nie są blokowane mimo opcji Block clients with no heartbeat. Tych stwierdzeń nie można ze sobą pogodzić jako ogólnej gwarancji izolacji. Dlatego w celu bezpiecznej weryfikacji odbiorczej należy sprawdzić faktycznie dopasowaną regułę, odrębne minimalne wymagania dla Source heartbeat i Destination heartbeat, mające zastosowanie wyjątki oraz rzeczywisty wynik dostępu. Samo wskazanie Missing nie jest dowodem pełnej izolacji.

Na potrzeby tego testu nie należy wywoływać czerwonego stanu przez wyłączenie lub manipulowanie ochroną endpointu. Jeśli Central, Control Center i działanie reguły nie są zgodne albo pojawia się Missing, systematycznie przeanalizować alerty Missing Heartbeat na podstawie strefy, ścieżki, Rule ID i logów.

Szerszy widok Control Center > User & device insights opisuje artykuł Bezpieczna ocena User & Device Insights. Wyjaśnia liczniki Heartbeat i aplikacji, wyniki analizy Zero-Day, UTQ, błędy SSL/TLS i sesje zapory, z uwzględnieniem różnych przedziałów czasu oraz różnicy między ukryciem błędu a zmianą polityki odszyfrowywania. Te lokalne wskaźniki nie są tym samym co Central Reporting i nie stanowią dowodu, że każdy endpoint lub każde połączenie jest chronione.

Określić zakres monitorowania Heartbeat i sprawdzić ścieżkę

W System > Sophos Central > Optional configurations > Missing heartbeat zones należy wybrać tylko strefy, w których oczekiwane są zarządzane endpointy Sophos. Brak sygnałów heartbeat jest wykrywany tylko w wybranych strefach; drukarki, urządzenia gości, urządzenia IoT i klienci z innym rozwiązaniem EDR nie uzyskują Sophos Heartbeat przez samą rejestrację. Lista stref i warunki heartbeat w dopasowanych regułach zapory muszą być spójne. Sophos dokumentuje przypadek szczególny: jeśli polityka heartbeat blokuje strefę, ale w tym polu nie dodano żadnej strefy, widżet Control Center może nadal pokazywać Missing. Pusta lista nie jest więc dowodem, że żadna polityka nie wpływa na ruch.

Przed zmianą zakresu lub reguły pilotażowej należy zapisać pierwotną listę stref, Rule ID, opcje heartbeat oraz IP, MAC i bieżący stan endpointu pilotażowego. Wprowadzić tylko zamierzoną, wąsko ograniczoną zmianę. Następnie porównać ten sam endpoint w Central i Control Center, wygenerować zatwierdzony ruch testowy z endpointu o prawidłowym stanie zabezpieczeń i sprawdzić dopasowany Rule ID oraz wynik dostępu w Log Viewer. Jeśli dostęp zmieni się w nieoczekiwany sposób, należy przywrócić zapisaną listę stref i opcje reguły, powtórzyć ten sam ruch oraz zbadać ścieżkę, zamiast globalnie osłabiać wymagania heartbeat.

Udokumentowany kanał Heartbeat korzysta z szyfrowanego połączenia TLS do 52.5.76.173 przez TCP 8347. Central dostarcza certyfikaty, które pozwalają zaporze powiązać endpointy z właściwą organizacją; sam otwarty port nie ustanawia tego zaufania. Przed diagnozowaniem brakującego stanu należy sprawdzić następujące ograniczenia topologii:

• Połączenie VPN zestawione przed połączeniem heartbeat może skierować ten ruch poza lokalną zaporę. W przypadku Sophos Connect IPsec należy sprawdzić Remote access VPN > IPsec > Advanced settings > Send Security Heartbeat through tunnel pod kątem zamierzonej polityki połączenia.
• Za routerem pośredniczącym bez NAT endpoint może nadal przekazywać stan zabezpieczeń, ale zapora nie może wykryć braku heartbeat. Widoczny stan zabezpieczeń nie dowodzi, że monitorowanie Missing działa na tej ścieżce.
• Za bramą NAT endpointy nie mogą przekazywać zaporze swojego stanu zabezpieczeń. Jest to inne ograniczenie niż w przypadku ścieżki routowanej bez NAT.
• W trybie TAP endpointy muszą mieć dostęp do co najmniej jednego interfejsu w strefie LAN, który jest stale połączony z siecią. Sam ruch z portu lustrzanego nie wystarcza: endpointy otrzymują adresy interfejsów LAN przez Central i próbują wysłać heartbeat do jednego z nich.

Interpretować stan zabezpieczeń bez zakładania automatycznej izolacji

Connected (green) oznacza zgłoszony przez endpoint prawidłowy stan zabezpieczeń, a nie gwarancję wykluczenia wszystkich zagrożeń. Warning (yellow) może wskazywać na PUA, nieaktywne lub usunięte złośliwe oprogramowanie albo sygnatury, które nie były aktualizowane przez 24 godziny. At risk (red) wymaga zbadania, na przykład pod kątem aktywnego złośliwego oprogramowania, którego nie udało się usunąć, złośliwego ruchu sieciowego lub nieprawidłowo działającej ochrony. Missing (red) oznacza coś innego: zapora widzi ruch, ale nie otrzymuje odpowiadającego mu stanu zabezpieczeń. Przed uznaniem obu czerwonych etykiet za ten sam incydent należy porównać zdarzenia endpointu.

Widok szczegółowy dla stanów czerwonych i żółtych pokazuje nazwę hosta, IP, użytkownika i czas od zmiany stanu. Wpis Missing może pozostać w Control Center i raportach po opuszczeniu sieci przez endpoint; zmienia się, gdy endpoint ponownie połączy się z siecią. Nie należy usuwać takiego wpisu tylko po to, aby pulpit pokazywał stan zielony. Powiązany poradnik dotyczący Missing Heartbeat wyjaśnia zbieranie dowodów, kompromisy związane z ustawieniami czasu, obsługiwane zachowanie Modern Standby i porządkowanie wpisów w wąsko ograniczonym zakresie. Endpointy wysyłają heartbeat co 15 sekund; dystrybucja list endpointów czerwonych i żółtych co 30 sekund oraz domyślny limit 60 sekund do wykrycia Missing to osobne mechanizmy. Wydłużenie czasu wykrywania lub opóźnienia raportowania może również opóźnić rzeczywiste alerty.

Ochrona przed przemieszczaniem się zagrożeń w sieci jest kolejną, osobną kontrolą: inne endpointy przestają komunikować się z endpointem o czerwonym stanie tylko wtedy, gdy obowiązuje odpowiednia polityka endpointów w Central. Zapora udostępnia adresy MAC i stany zabezpieczeń jako proxy warstwy 2 w tej samej domenie rozgłoszeniowej. Nie należy zakładać, że izoluje to endpointy między sieciami routowanymi lub zastępuje warunki heartbeat dla ruchu przechodzącego przez zaporę.

Przegląd funkcji dla SFOS 22 opisuje synchronizowaną tożsamość użytkownika z nazwą domeny, nazwą użytkownika i Active Directory. Przegląd dla SFOS 23 dokumentuje dodatkowo User Principal Name (UPN) oraz weryfikację konta w Active Directory lub Microsoft Entra ID. Nie należy stosować tego opisu SFOS 23 do wdrożenia SFOS 22 ani zakładać, że sama rejestracja konfiguruje uwierzytelnianie tożsamości; przed użyciem reguł opartych na tożsamości należy sprawdzić faktyczną wersję firmware i konfigurację serwera uwierzytelniania.

Czego Sophos Fusion nie zastępuje

Sophos Fusion jest pomocne, ale nie zastępuje solidnej konfiguracji zapory.

Central nie zastępuje:

• solidnego planowania stref i interfejsów
• restrykcyjnych reguł zapory
• wzmocnienia dostępu do urządzeń
• MFA dla administratorów i portali
• lokalnego rozwiązywania problemów za pomocą Log Viewer i Packet Capture
• udokumentowanych kopii zapasowych i testów przywracania
• zewnętrznego systemu Syslog, jeśli wymagana jest zgodność lub długie przechowywanie

Sophos Fusion to dodatkowa warstwa zarządzania i raportowania, ale nie jest skrótem do bezpiecznej podstawowej konfiguracji.

Co sprawdzić przed rejestracją

Przed połączeniem z Sophos Fusion warto jasno określić cel rejestracji. Zapobiega to późniejszym niejasnościom w zakresie odpowiedzialności, tworzeniu zbędnych tenantów lub niepotrzebnemu aktywowaniu usług.

Ważne pytania przed rejestracją:

• W którym tenancie Sophos Fusion ma być zarejestrowany firewall?
• Kto ma w tenancie wymagane uprawnienia do Firewall Management, Reporting, Backup i spraw licencyjnych?
• Czy firewall jest już zarejestrowany na innym koncie Central?
• Czy firewall ma aktywną płatną subskrypcję inną niż Base Firewall albo aktywną licencję wsparcia Sophos obejmującą Central Firewall Management, na przykład Enhanced Support? Sprawdzić konkretną licencję, a nie tylko istnienie umowy wsparcia.
• Czy firewall ma działające połączenie IPv4 z internetem?
• Czy Central ma być używane tylko do przeglądu licencji i inwentaryzacji, czy także do zarządzania, raportowania i backupów?
• Czy używane są grupy firewalli i czy role Admin, Helpdesk oraz Read-only zostały praktycznie przetestowane?
• Czy logi firewalla mogą być wysyłane do Sophos Fusion z punktu widzenia ochrony danych lub zgodności?
• Czy istnieje aktualny lokalny backup i udokumentowany Secure Storage Master Key?
• Czy wiadomo, kto po rejestracji sprawdza alerty, raporty i nieudane zadania?

Jeśli zapora jest już na niewłaściwym koncie, najpierw należy sprawdzić Przenoszenie Sophos Firewall do innego konta Sophos Fusion. W zrozumieniu różnic między kontami i portalami pomocny jest artykuł Portale Sophos: SophosID, Central, Support i dostępy do zapory.

Kiedy nie trzeba łączyć zapory

Połączenie z Sophos Fusion nie jest konieczne, jeśli:

• zarządzasz tylko jedną lokalną zaporą
• nie potrzebujesz raportów Central
• nie planujesz integracji z Sophos Endpoint
• zarządzanie w chmurze nie jest pożądane z powodów organizacyjnych
• logi są już wysyłane do własnego SIEM lub serwera Syslog

W takich przypadkach można zarządzać zaporą lokalnie. Ważne jest wtedy, aby kopie zapasowe, aktualizacje oprogramowania, monitorowanie i logowanie były odpowiednio zorganizowane.

Kiedy Sophos Fusion jest zalecane

Sophos Fusion jest szczególnie zalecane, jeśli:

• zarządzasz wieloma zaporami
• administratorzy pracują z różnych lokalizacji
• zapory nie powinny być bezpośrednio dostępne przez WebAdmin z internetu
• kopie zapasowe konfiguracji mają być przechowywane centralnie
• potrzebne jest raportowanie zapory
• używane są Sophos Endpoint, MDR, XDR lub inne produkty Sophos Fusion
• chcesz korzystać z Security Heartbeat i Synchronized Security

Aktywacja połączenia

Połączenie jest konfigurowane na firewallu w System > Sophos Central.

Poniższe procedury wykorzystują angielskie etykiety interfejsu udokumentowane dla SFOS 22 i SFOS 23; lokalny interfejs może nadal używać nazwy Sophos Central. Lokalny administrator zapory musi mieć dostęp do tego menu. Central Firewall Management nadal wymaga aktywnej płatnej subskrypcji innej niż Base Firewall albo aktywnej licencji wsparcia Sophos obejmującej uprawnienie do tej funkcji, na przykład Enhanced Support. Sama licencja Base Firewall nie wystarcza, a ścieżka zarządzania przez internet działa wyłącznie przez IPv4.

Przed wygenerowaniem OTP: Firewall musi być już skonfigurowany i przypisany przez claim do właściwego tenanta Sophos Fusion. Jeśli konfiguracja lub claim nie są jeszcze zakończone, najpierw wykonać kroki opisane w Konfiguracja Sophos Firewall, claim i aktywacja licencji oraz sprawdzić przypisanie urządzenia i licencji. Późniejsza rejestracja przez OTP łączy istniejący firewall z Central Management; nie przypisuje własności ani nie aktywuje subskrypcji. Przypisanie firewalla do klienta przez partnera również nie zastępuje claimu.

Istnieją dwie typowe metody rejestracji:

• OTP z Sophos Fusion: przydatne, gdy partner, zespół projektowy lub administrator firewalla nie powinien używać na firewallu danych Super Admin tenanta Central. W Sophos Fusion istniejący firewall dodaje się przez numer seryjny pod My Products > Firewall Management > Firewalls > Add Firewall i generuje OTP.
• Dane logowania Sophos Fusion: przydatne przy bezpośredniej rejestracji na firewallu z odpowiednim kontem administratora Sophos Fusion. Sophos określa to jako Central Super Admin.

Przy parach HA trzeba pracować szczególnie dokładnie. Przy rejestracji OTP w Sophos Fusion wpisuje się oba numery seryjne; przy nowych parach HA OTP używa się na urządzeniu Primary.

Wygenerować OTP we właściwym tenancie

Dla zapory, która jest już skonfigurowana i przypisana przez claim, należy wygenerować OTP w Central przed przejściem do lokalnych kroków rejestracji:

1. Zalogować się do docelowego tenanta. Partner najpierw przypisuje zaporę do właściwego klienta w Partner Dashboard i otwiera konsolę Central Admin tego klienta. Przypisanie do klienta nie zastępuje claimu.
2. Otworzyć My Products > Firewall Management > Firewalls > Add Firewall i wybrać Join a firewall that is configured or deployed.
3. W Enter Device Serial Number wpisać właściwy numer seryjny i kliknąć Next. W przypadku HA wpisać oba numery seryjne oddzielone przecinkiem i sprawdzić ich zgodność z planowaną parą.
4. Pozostawić wybrane Register using OTP i wybrać Copy OTP and Finish. OTP jest ważny przez 14 dni. Przekazać go wyłącznie uprawnionemu administratorowi zapory przez zatwierdzony kanał udostępniania sekretów; nie umieszczać OTP, haseł ani zrzutów ekranu z niezamaskowanymi poświadczeniami w zgłoszeniu do pomocy technicznej.
5. Na zaporze wybrać Register > Use OTP, wkleić kod w Enter OTP i kliknąć Register. W przypadku nowej pary HA wprowadzić OTP tylko na urządzeniu primary. Następnie włączyć zamierzone usługi Central i uzyskać zatwierdzenie usług opisane poniżej.

Jeśli OTP wygasł lub rejestracja się nie powiedzie, należy najpierw sprawdzić docelowy tenant, claim, numery seryjne i łączność IPv4. W razie potrzeby uzyskać nowy OTP z właściwego tenanta; nie należy wielokrotnie wyrejestrowywać zapory ani zmieniać jej właściciela w celu obejścia błędu. Rejestrację można uznać za zakończoną dopiero wtedy, gdy numery seryjne i stan usług są zgodne w obu widokach.

Alternatywny proces z użyciem poświadczeń wymaga konta Central Super Admin. Do tej rejestracji nie można użyć konta administratora należącego do Central Enterprise sub-estate. Należy rozróżniać konto tenanta i lokalną rolę administratora zapory; OTP pozwala lokalnemu administratorowi zarejestrować zaporę bez otrzymywania hasła Super Admin tenanta.

Typowy przebieg na firewallu:

1. Zalogować się na firewallu.
2. Otworzyć System > Sophos Central.
3. Wybrać Register.
4. Wybrać Use OTP albo Use email address.
5. Wpisać OTP albo dane logowania Sophos Fusion.
6. Zakończyć rejestrację.
7. Włączyć Sophos Central services.
8. Wybrać wymagane usługi.

W zależności od potrzeb można aktywować następujące opcje:

• Use Sophos Central reporting / Send reports and logs to Sophos Central: wysyła dane logów i raportów do Sophos Fusion.
• Use Sophos Central management / Manage from Sophos Central: umożliwia dostęp do zarządzania przez Sophos Fusion.
• Send configuration backup to Sophos Central: zapisuje backupy konfiguracji w Sophos Fusion. W praktyce ta opcja jest związana z konfiguracją Central Management i musi zostać zaakceptowana w Sophos Fusion.

Należy aktywować tylko te funkcje, które są naprawdę używane. W środowiskach z wymaganiami ochrony danych lub zgodności trzeba wcześniej ustalić, które dane logów mogą być wysyłane do Sophos Fusion.

Po aktywacji usług konto z rolą Super admin we właściwym tenancie Sophos Fusion musi zaakceptować usługi w Sophos Fusion:

1. Zalogować się do Sophos Fusion.
2. Otworzyć My Products > Firewall Management > Firewalls.
3. Znaleźć firewall ze statusem Approval Pending.
4. Wybrać accept-services.
5. Na firewallu sprawdzić, czy status zmienia się z Waiting for approval from Sophos Central na Managed albo połączony.

Zmiana statusu może potrwać kilka minut. Jeśli wskazanie nie zmienia się od razu, nie należy wielokrotnie ponawiać rejestracji. Najpierw sprawdzić status Central, połączenie internetowe, DNS i czas.

Jeśli przed firewallem znajduje się filtr egress, dostępne muszą być również odpowiednie wychodzące usługi i porty Sophos dla Central, raportowania i kopii zapasowych.

Objąć parę HA zarządzaniem Central

Przed wprowadzeniem zmian należy rozróżnić dwa stany początkowe. Zapisać oba numery seryjne, wersje firmware, role primary/auxiliary, lokalny stan HA i stany usług Central. Zapewnić dostęp do aktualnych kopii zapasowych konfiguracji, ich haseł, Secure Storage Master Key oraz działającej lokalnej ścieżki administracji. Utworzenie HA jest osobną zmianą serwisową, a nie skrótem do rozwiązywania problemów z rejestracją; artykuł Planowanie i obsługa wariantów HA w Sophos Firewall opisuje odpowiedzialność za konfigurację, synchronizację i plan odtwarzania.

• Dwie samodzielne zapory są już zarządzane centralnie: przygotować HA lokalnie, korzystając z zamierzonej konfiguracji urządzenia primary. Oba urządzenia muszą działać z tą samą wersją firmware. Sophos dokumentuje zarówno Active-Active, jak i Active-Passive; po utworzeniu pary Central powinno wyświetlać jedną parę HA, a nie dwa niezależne urządzenia do zarządzania. Przed dopuszczeniem do zastąpienia konfiguracji auxiliary przez synchronizację należy wykonać kroki przygotowania HA.
• Para HA istnieje, ale nie jest zarządzana centralnie: pracować na urządzeniu primary. Dokumentacja dotycząca HA nazywa widok rejestracji Central synchronization, a działanie Register both HA devices. Po rejestracji włączyć zarządzanie Central, a następnie obok zapory primary w Central wybrać Approval Pending > accept-services, korzystając z uprawnionego konta Super Admin. W procesie OTP należy użyć obu numerów seryjnych i wprowadzić kod tylko na primary, zgodnie z opisem powyżej, zamiast rejestrować każdy węzeł niezależnie.

Odczekać kilka minut, a następnie potwierdzić, że Central pokazuje jedną parę z ikoną HA i właściwymi numerami seryjnymi. Lokalnie sprawdzić role primary/auxiliary i synchronizację, a także dostęp do zarządzania oraz zatwierdzony ruch testowy w środowisku produkcyjnym. Zmiany konfiguracji w Central dotyczą obu zapór; pojedynczy wyświetlany obiekt nie jest dowodem, że zmiana obejmuje tylko primary.

Jeśli widok nadal pokazuje osobne lub zdublowane urządzenia, przed zmianą rejestracji należy porównać lokalny stan HA, oba numery seryjne, tenant, zatwierdzenie usług i Task Queue. Aby wycofać wyłącznie zmianę dotyczącą zarządzania, należy przywrócić zapisane stany usług Central oraz sprawdzić lokalny dostęp i prawidłowy stan HA. Nie należy rozwiązywać pary HA, ponownie uruchamiać kreatora konfiguracji ani wymuszać wyrejestrowania przez CLI w celu poprawienia widoku. Cofnięcie utworzenia HA wymaga osobno zatwierdzonego planu odtwarzania HA; nierozwiązany problem rejestracji lub niejasny zakres operacji na węzłach należy przekazać Sophos Support wraz z zebranymi informacjami o stanie.

Bezpieczne zawężanie przyczyny zablokowanej rejestracji

Przy stanie Approval Pending lub Waiting for approval from Sophos Central nie należy ponawiać rejestracji ani pochopnie wyrejestrowywać firewalla. Najpierw sprawdza się właściwy tenant i numer seryjny, zatwierdzenie usług przez konto z rolą Super admin we właściwym tenancie w My Products > Firewall Management > Firewalls, dostęp do internetu przez IPv4, DNS, czas i wymagane usługi wychodzące. W HA oba numery seryjne muszą być wpisane w Central, a OTP wprowadza się na węźle primary. Jeśli po korekcie stan nadal jest zablokowany, należy zachować zrzuty obu widoków stanu, godzinę, numery seryjne i role HA dla Sophos Support.

Usuwanie konfiguracji Synchronized Security wyłącznie jako operacja zatwierdzona przez wsparcie. Dokumentacja Device Console dla SFOS 22 i 23 opisuje system synchronized-security central_registration deregister jako polecenie usuwające konfigurację Synchronized Security z Sophos Fusion lub Sophos Central, gdy blokuje ona rejestrację lub wyrejestrowanie. Rozpatrywany tutaj przypadek to istniejąca zapora, której rejestracja po powyższych kontrolach nadal jest blokowana przez Synchronized Security, a przyczynę tę potwierdził Sophos Support. Nie jest to ani pełne wyrejestrowanie urządzenia przez Deregister w następnej sekcji, ani czyszczenie wewnętrznej bazy danych za pomocą SQL. Polecenie zmienia stan; nie jest diagnostyką tylko do odczytu ani ogólnym rozwiązaniem dla Approval Pending.

Przed jakimkolwiek wykonaniem należy zapisać w zgłoszeniu docelowy i obecny tenant, urządzenie i numer seryjny, dokładną wersję SFOS wraz z buildem, stan rejestracji, aktywne usługi Central, Security Heartbeat, Synchronized Application Control oraz objęte zmianą reguły i ich dotychczasowe działanie. W HA uwzględnić oba numery seryjne, role primary/auxiliary, stan synchronizacji oraz wyraźnie potwierdzony zakres objętych operacją węzłów. Sprawdzić i zachować uprawniony lokalny dostęp do WebAdmin i konsoli, niezależny od ścieżki zarządzania Central. Zapewnić aktualny lokalny backup, jego hasło i Secure Storage Master Key.

Nie wykonywać bez zatwierdzenia dla konkretnego buildu. Sophos Support musi wcześniej potwierdzić zasadność usunięcia konfiguracji w tym przypadku, przewidywany wpływ na rejestrację, usługi, ruch zależny od Heartbeat i HA oraz procedurę odtwarzania, w tym konieczną rejestrację i zatwierdzanie usług. Udokumentowana składnia nie gwarantuje niezmienionych usług ani odwracalnego przywrócenia poprzedniego stanu; sam backup również nie potwierdza takiej drogi odtwarzania. Jeśli wpływ, zakres węzłów lub procedura odtwarzania pozostają niejasne, wstrzymać wykonanie i kontynuować sprawę ze wsparciem. Nie zastępować operacji zmianami SQL ani wymuszonym pełnym wyrejestrowaniem.

Po wyraźnie zatwierdzonej operacji sprawdzić zgodnie z planem wsparcia rejestrację we właściwym tenancie i oba widoki stanu, zamierzone usługi i niezależny dostęp lokalny. Sprawdzić także Security Heartbeat z zarządzanym endpointem pilotażowym, w razie potrzeby rozpoznawanie aplikacji, działanie objętych zmianą reguł, ruch produkcyjny, logi oraz w HA role i synchronizację. Ponowna widoczność zapory nie jest wystarczającym dowodem powodzenia. W razie niezgodności zebrać informacje o stanie i zastosować zatwierdzony plan odtwarzania z Sophos Support, zamiast ponownie wykonywać polecenie.

Zmiana usług Central lub wyrejestrowanie

Wyłączenie Security Heartbeat, Synchronized Application Control lub Sophos Central management nie wyrejestrowuje firewalla z Central. Usługi nie są jednak niezależne: wyłączenie Security Heartbeat wyłącza również Synchronized Application Control, a endpointy i firewall przestają wymieniać informacje o stanie zabezpieczeń. Wstrzymanie Heartbeat dotyczy więc więcej niż jednej usługi.

Przed zmianą należy zapisać w System > Sophos Central poprzednie stany włączenia lub wyłączenia zarówno Security Heartbeat, jak i Synchronized Application Control, a także stan zmienianej usługi. Następnie wyłącza się zamierzoną usługę, zapisuje i sprawdza zarówno stany usług objętych zmianą, jak i to, czy firewall nadal jest zarejestrowany.

Aby wycofać zmianę, należy przywrócić zmienianą usługę i oba zapisane stany. Jeśli Central ponownie wymaga zatwierdzenia usług, należy zlecić je administratorowi z rolą Super admin we właściwym tenancie. Trzeba sprawdzić Security Heartbeat i Synchronized Application Control osobno, zamiast zakładać, że samo włączenie Heartbeat poprawnie przywróci obie funkcje. Jeśli Heartbeat był wcześniej aktywny, należy użyć zarządzanego endpointu pilotażowego do sprawdzenia bieżącego stanu zabezpieczeń i odpowiadającego mu licznika Connected w Control Center, jak opisano powyżej. Jeśli Synchronized Application Control był wcześniej aktywny, należy również sprawdzić rozpoznawanie aplikacji w Applications > Synchronized Application Control z użyciem endpointu pilotażowego; Ukierunkowane korzystanie z Application Control opisuje odpowiedni proces weryfikacji.

Pełne wyrejestrowanie jest osobnym, zaplanowanym etapem cyklu życia:

1. Utworzyć aktualny lokalny backup konfiguracji i zachować hasło oraz Secure Storage Master Key. Udokumentować tenant, numery seryjne, aktywne usługi, grupy firewalli, oczekujące zadania, reporting i backupy Central. W HA zapisać oba węzły i role.
2. Sprawdzić lokalny dostęp WebAdmin przy użyciu uprawnionego konta. Zakończyć oczekujące zadania Central lub zapisać ich stan i wybrać okno serwisowe. Nie traktować backupów Central jako jedynej drogi powrotu, ponieważ po usunięciu firewalla z Central Management są kasowane.
3. Na firewallu otworzyć System > Sophos Central i wybrać Deregister. Nie używać jako skrótu nieudokumentowanych poleceń Device Console ani Advanced Shell.
4. Lokalnie potwierdzić, że firewall nie jest już wyświetlany jako zarządzany przez Central. W My Products > Firewall Management > Firewalls sprawdzić stan obiektu urządzenia; pozostały obiekt nie oznacza działającej rejestracji. Następnie sprawdzić lokalny dostęp, ruch produkcyjny, logowanie i, w HA, stan klastra.

Aby wycofać zmianę, należy ponownie zarejestrować zaporę standardową metodą z użyciem OTP lub poświadczeń superadministratora, zlecić zatwierdzenie wymaganych usług w Central administratorowi z rolą Super admin we właściwym tenancie i powtórzyć testy poszczególnych usług. Jeśli opcja Deregister jest niedostępna, operacja pozostaje zablokowana albo zakres operacji w HA jest niejasny, nie wolno wymuszać wyrejestrowania przez CLI. Zebrane informacje o stanie należy przekazać Sophos Support.

Kontrola po połączeniu

Po rejestracji należy nie tylko sprawdzić, czy zapora jest widoczna w Sophos Fusion. Kluczowe jest, czy aktywowane usługi naprawdę działają i czy odpowiedzialności są jasne.

Sensowna kontrola po rejestracji:

1. W Sophos Fusion sprawdź, czy model, numer seryjny i status licencji są poprawnie wyświetlane.
2. Na zaporze w System > Sophos Central sprawdź, czy pożądane usługi są aktywne i połączone.
3. Jeśli używasz Manage from Sophos Central, otwórz My Products > Firewall Management > Firewalls w Central i kliknij nazwę zapory, aby otworzyć jej konsolę WebAdmin. Odczekaj kilka sekund i sprawdź dostęp z przewidzianą rolą administratora; podczas testu zachowaj działającą lokalną ścieżkę administracji.
4. Jeśli raportowanie jest aktywne, sprawdź w Log Viewer i w Sophos Fusion, czy aktualne zdarzenia są odbierane.
5. Jeśli kopie zapasowe w chmurze są aktywne, skonfiguruj zaplanowaną kopię zapasową i udokumentuj czas ostatniego pomyślnego utworzenia kopii zapasowej.
6. Sprawdź alerty, role i odpowiedzialności w Sophos Fusion.
7. Jeśli zmiany są dystrybuowane przez Central, sprawdź Central Firewall Management Task Queue.

Zwłaszcza przy wielu zaporach rejestracja powinna znaleźć się w wewnętrznej dokumentacji: tenant, numer seryjny, lokalizacja, aktywna usługa Central, przechowywanie raportów, interwał kopii zapasowych i odpowiedzialna osoba.

Osobna weryfikacja usług Central

Po rejestracji nie należy sprawdzać tylko ogólnego statusu Central. Poszczególne usługi mają różne objawy błędów i dlatego wymagają osobnych testów odbiorczych.

• Rejestracja i inwentarz: zapora pojawia się we właściwym tenancie, a numer seryjny, model, licencja i lokalizacja są poprawne.
• Manage from Sophos Central: dostęp przez Central działa z przewidzianą rolą administratora, bez zbędnego otwierania WebAdmin z WAN.
• Central Reporting: celowo wywołane zdarzenie pojawia się w Report Hub z poprawną zaporą, czasem, ID reguły lub typem logu.
• Kopie zapasowe Central: zaplanowana lub ręczna kopia zapasowa kończy się powodzeniem, a interwał, hasło i Secure Storage Master Key są udokumentowane.
• Przechowywanie kopii zapasowych: znane są najnowsze kopie w Central (pięć) oraz ewentualna kopia przechowywana bezterminowo. W środowisku HA wiadomo, że kopię tworzy Primary.
• Alerty kopii zapasowych: nieudane kopie Central generują alerty i wiadomości e-mail, które sprawdza odpowiedzialna osoba.
• Central Tasks: po zmianie w Central sprawdzana jest Task Queue, aż zadanie zakończy się powodzeniem lub zostanie poprawnie eskalowane.
• Security Heartbeat: Sophos Fusion pokazuje oczekiwany stan endpointu pilotażowego, a odpowiadający mu licznik w Control Center jest wiarygodny. Ograniczenia oparte na regułach są testowane stopniowo dopiero po ustaleniu tej wartości odniesienia.
• Alerty i odpowiedzialność: wiadomo, kto regularnie sprawdza nieudane zadania, problemy z kopiami zapasowymi, braki w raportowaniu i ostrzeżenia licencyjne.

Takie rozdzielenie zapobiega typowemu błędowi operacyjnemu: zapora może być widoczna w Sophos Fusion, a raportowanie, kopie zapasowe lub zadania Central nadal mogą nie działać poprawnie.

Typowe błędy

Zapora jest zarejestrowana na niewłaściwym koncie Central

To często zdarza się przy zmianach dostawców, kontach testowych lub wielu historycznych kontach SophosID. W takim przypadku nie należy po prostu próbować drugiej rejestracji. Najpierw ustal, gdzie obecnie znajduje się zapora, kto ma dostęp do tenanta i czy potrzebny jest transfer konta.

Central Management jest mylone z lokalnym WebAdmin

Manage from Sophos Central to dodatkowa ścieżka dostępu. Lokalna WebAdmin Console, lokalne konta administratorów, MFA, Device Access i SSH nadal pozostają niezależnymi mechanizmami kontroli bezpieczeństwa. Szczególnie ważne jest, aby WebAdmin nie pozostawał dostępny z WAN tylko dlatego, że nie przetestowano jeszcze zarządzania przez Central Management.

Widok Central nie jest weryfikowany lokalnie

Przy politykach grupowych, klastrach HA, regułach WAF i zadaniach firmware nie należy traktować Central jako jedynego źródła prawdy. Central może pokazywać, że zmiana jest zaplanowana, zastosowana lub widoczna. Decydujące jest jednak, czy dana zapora przetworzyła zmianę i czy rzeczywisty ruch lub usługa po niej działa.

W praktyce: po zmianach w Central należy sprawdzić Task Queue, lokalny widok WebAdmin, Log Viewer oraz w razie potrzeby Audit Trail. Jeśli interfejs Central tylko się ładuje, para HA wygląda na zdublowaną albo reguły grupowej nie można przesunąć, nie oznacza to automatycznie problemu z regułą zapory.

Raportowanie jest aktywowane, ale nie docierają żadne użyteczne dane

W takim przypadku najpierw sprawdź, czy opcja Send reports and logs to Sophos Central jest aktywna, czy odpowiednie typy logów są włączone i czy zapora może połączyć się z Central. Następnie w artykule Aktywacja Central Firewall Reporting sprawdź szczegóły dotyczące wyboru logów, przechowywania i raportów.

Kopia zapasowa w chmurze jest rozumiana jako jedyna kopia zapasowa

Kopie zapasowe w Central są praktyczne, ale nie zastępują pełnego planowania odzyskiwania. Dla krytycznych lokalizacji powinno być również jasne, gdzie znajdują się lokalne kopie zapasowe, kto zna hasło do kopii zapasowej, czy Secure Storage Master Key jest udokumentowany i jak przebiegałoby przywracanie lub ponowne wgrywanie obrazu systemu.

Nikt nie sprawdza zadań i alertów Central

Central pomaga tylko wtedy, gdy komunikaty i nieudane zadania są również przetwarzane. Szczególnie przy politykach grupowych, zadaniach oprogramowania, raportowaniu i kopiach zapasowych powinno być jasne, kto sprawdza ostrzeżenia i jak błędy są eskalowane wewnętrznie.

Często zadawane pytania