Jak prawidłowo korzystać z Sophos Firewall Health Check
Sophos Firewall Health Check to zintegrowana kontrola konfiguracji zapory. Pokazuje w Control Center, czy ważne ustawienia odpowiadają zalecanym standardom bezpieczeństwa i najlepszym praktykom. Jest to szczególnie przydatne dla administratorów, ponieważ pozwala na wykrycie ryzykownych konfiguracji, zanim staną się one problemem bezpieczeństwa lub operacyjnym.
Health Check został wprowadzony w Sophos Firewall v22. Funkcja ocenia konfiguracje w odniesieniu do najlepszych praktyk i standardów, takich jak CIS-Benchmarks. Wraz z SFOS 22.0 MR1 zaktualizowano również kontekst CIS.
Przewodnik wideo
Jaki artykuł o bezpieczeństwie jest odpowiedni?
Health Check to dobry punkt wyjścia, ale nie każde ustalenie zostanie w pełni rozwiązane w artykule o Health Check. Do praktycznej realizacji pomocne są te wprowadzenia:
| Sytuacja | Lepsze wprowadzenie |
|---|---|
| Zbieranie, priorytetyzacja i dokumentowanie ustaleń | Ten artykuł |
| WebAdmin, SSH, User Portal, VPN Portal, DNS lub Ping są zbyt szeroko dostępne | Zabezpieczanie dostępu do Sophos Firewall: prawidłowa konfiguracja Device Access |
| Brak MFA dla administratorów, VPN Portal lub Remote Access | Aktywacja MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access |
| XML API lub dostęp do automatyzacji jest zbyt otwarty | Zabezpieczanie dostępu do Sophos Firewall XML API |
| Reguły zapory są zbyt szerokie lub niejasne | Zrozumienie i prawidłowa konfiguracja reguł Sophos Firewall |
| IPS powinien być aktywowany lub sprawdzony | Konfiguracja i bezpieczne testowanie Sophos Firewall IPS |
| Inspekcja TLS powinna być wprowadzona | Prawidłowe wprowadzenie inspekcji TLS w Sophos Firewall |
| Ochrona sieci Web, kategorie lub natychmiastowe alerty są istotne | Wykorzystanie kategorii sieci Web i natychmiastowych alertów w Sophos Firewall |
| Ochrona DNS powinna być zarządzana przez Sophos Central | Konfiguracja Sophos DNS Protection z Sophos Firewall |
| Threat Feeds, NDR lub Active Threat Response powinny dostarczać ustaleń | Zarządzanie Sophos Firewall NDR i Active Threat Response |
| Zmiany konfiguracji muszą być śledzone | Sprawdzanie dzienników ścieżki audytu Sophos Firewall |
Ten podział zapobiega dwóm typowym błędom: ustalenia są traktowane jedynie jako komunikaty na pulpicie, bez ich technicznego rozwiązania, lub funkcje ochronne są aktywowane ogólnie, bez wyjaśnienia logowania, wyjątków i odpowiedzialności.
Do czego służy Health Check
Health Check nie jest klasycznym statusem systemu ani czujnikiem sprzętowym. Nie sprawdza, czy zasilacz jest uszkodzony lub czy SSD wkrótce się zepsuje. Do tego pasują inne kontrole operacyjne, na przykład sprawdzanie stanu zdrowia SSD lub monitorowanie HA i sprzętu.
Health Check odpowiada raczej na te pytania:
- Czy dostęp administracyjny jest zbyt szeroko otwarty?
- Czy MFA jest aktywowane dla krytycznych logowań?
- Czy reguły zapory są zbyt otwarte?
- Czy kopie zapasowe, poprawki, logowanie lub funkcje Central są odpowiednio przygotowane?
- Czy konfiguracja odbiega od zalecanych standardów bezpieczeństwa?
- Czy istnieją ustalenia, które powinny zostać rozwiązane przed audytem lub uruchomieniem?
Jest to zatem dobre narzędzie do wzmocnienia, przeglądu i kontroli zmian. Nie zastępuje jednak czystej architektury, dokumentacji reguł ani ręcznej oceny.
⚠️ Zielony Health Check nie oznacza automatycznie, że zapora jest bezpiecznie zaplanowana. Pokazuje, czy określone sprawdzalne ustawienia są odpowiednie. Projekt sieci, logika biznesowa, wyjątki, grupy użytkowników i procesy operacyjne muszą być nadal oceniane fachowo.
Nie myl wyniku z celem
Health Check jest pomocny, ale wynik nie powinien stać się celem samym w sobie. Niektóre punkty to podstawy bezpieczeństwa, na przykład MFA, poprawki, zasady haseł, ograniczony dostęp do WebAdmin, kopie zapasowe lub IPS. Inne punkty są bardziej zależne od ekosystemu Sophos, licencjonowania lub modelu operacyjnego.
Dlatego nie należy aktywować każdej rekomendacji tylko po to, aby wyświetlacz był zielony. Przykładem jest Login disclaimer: w środowiskach audytowych lub zgodności może być wymagane ostrzeżenie przy logowaniu. W wielu normalnych środowiskach operacyjnych generuje on jednak głównie dodatkowe kliknięcie przy każdym logowaniu i nie przynosi praktycznie żadnego technicznego zysku bezpieczeństwa. Jeśli tylko zwiększa wynik Health Check, jego wartość jest ograniczona.
Podobnie jest z funkcjami takimi jak DNS Protection, MDR threat feeds, NDR Essentials, Sophos X-Ops, Synchronized Application Control lub Sophos Central Reporting. Te funkcje mogą być sensowne, jeśli są licencjonowane, zrozumiane, monitorowane i rzeczywiście wykorzystywane w operacjach. Nie należy ich jednak włączać na ślepo tylko dlatego, że Health Check je zaleca. Kluczowe jest zawsze: czy działanie zmniejsza rzeczywiste ryzyko w tym środowisku i czy istnieje właściciel odpowiedzialny za operacje, wyjątki i fałszywe alarmy?
Jako zasada:
| Kategoria | Ocena |
|---|---|
| Zarządzanie dostępem z Internetu, MFA, poprawki, kopie zapasowe, zasady haseł, IPS | Zazwyczaj prawdziwe podstawy bezpieczeństwa lub operacji. Te punkty powinny być traktowane bardzo poważnie. |
| Logowanie, raportowanie, powiadomienia, NTP | Ważne dla operacji i śledzenia. Konkretna ścieżka zależy jednak od modelu operacyjnego. |
| DNS Protection, NDR, MDR threat feeds, X-Ops, Synchronized Security | Sensowne, jeśli funkcja jest używana, licencjonowana, monitorowana i zintegrowana z procesami. Nie automatycznie lepsze tylko ze względu na wynik. |
| Login disclaimer | Zazwyczaj bardziej funkcja zgodności/ostrzeżenia niż techniczna środek ochronny. Aktywować tylko, jeśli jest naprawdę wymagane lub pożądane. |
Otwieranie Health Check
Status Health Check pojawia się w Control center. Widok szczegółowy można znaleźć dodatkowo w menu głównym:
Firewall health check
Tam widoczna jest liczba sprawdzonych konfiguracji, zgodne punkty i niezgodne punkty. Sophos pokazuje niezgodne wpisy według stopnia ważności. Dane są aktualizowane, gdy zmienia się monitorowana konfiguracja. Dzięki temu Health Check nadaje się również do bezpośredniej kontroli po zmianach.
Podczas przeglądu nie należy notować tylko ogólnego statusu. Ważniejsze są konkretne ustalenia, kontekst ryzyka i planowane działanie. Pojedyncze krytyczne ustalenie dotyczące dostępności WebAdmin z WAN jest w operacjach ważniejsze niż kilka niskich ustaleń bez ekspozycji na Internet.
Przegląd 31 kontroli Health Check
Poniższa lista opiera się na angielskim widoku Health Check. Status nie jest celowo wymieniony, ponieważ różni się w zależności od zapory. Ważniejsze jest, która kontrola jest zamierzona i jak ją fachowo ocenić.
| Nr | Kontrola | Moduł | Standard | Stopień ważności | Ocena |
|---|---|---|---|---|---|
| 1 | Synchronized Application Control powinno być aktywowane. | Active threat response | Recommended | Medium | Sensowne w środowiskach Sophos Endpoint. W mieszanych lub Microsoft-Defender środowiskach najpierw sprawdzić, czy funkcja rzeczywiście dostarcza danych. |
| 2 | NDR Essentials powinno być aktywowane i monitorować co najmniej jeden interfejs. | Active threat response | Recommended | Medium | Tylko wartościowe, jeśli monitorowane interfejsy są sensownie wybrane i ustalenia są później analizowane. |
| 3 | Sophos X-Ops powinno być aktywowane, Action Log and drop. | Active threat response | CIS | High | Istotne dla bezpieczeństwa, jeśli Threat Feeds są aktywnie wykorzystywane. Fałszywe alarmy i logowanie muszą być sprawdzone. |
| 4 | MDR threat feeds powinny być aktywowane, Action Log and drop. | Active threat response | Recommended | High | Tylko sensowne, jeśli MDR lub odpowiednie funkcje Threat-Feed są licencjonowane i operacyjnie zintegrowane. |
| 5 | Reguła zapory powinna używać Synchronized Security Heartbeat. | Active threat response and Advanced security | CIS | Medium | Duża wartość dodana z Sophos Endpoint. Bez Sophos Endpoint nie traktować jako temat wyniku. |
| 6 | Security Heartbeat powinno być aktywowane. | Active threat response and Advanced security | CIS | High | Ważne, jeśli używany jest Sophos Endpoint. W przeciwnym razie najpierw należy wyjaśnić projekt Endpoint. |
| 7 | Login disclaimer powinno być aktywowane. | Admin settings | CIS | Medium | Temat zgodności. Technicznie mała ochrona, ale generuje dodatkowe kliknięcie przy logowaniu. |
| 8 | Hotfix setting powinno być aktywowane. | Admin settings | CIS | High | Bardzo ważne. Poprawki powinny być aktywne w środowiskach produkcyjnych, o ile proces zmian na to pozwala. |
| 9 | Nieaktywne sesje powinny być zakończone, a logowania po nieudanych próbach zablokowane. | Admin settings | CIS | High | Jasne wzmocnienie logowania. Szczególnie ważne przy eksponowanych portalach i dostępie administracyjnym. |
| 10 | Złożoność haseł powinna być skonfigurowana dla użytkowników. | Admin settings | CIS | High | Sensowne, szczególnie dla lokalnych użytkowników i portali. Przy zewnętrznym IdP dodatkowo sprawdzić jego politykę haseł i MFA. |
| 11 | Złożoność haseł powinna być skonfigurowana dla administratorów. | Admin settings | CIS | High | Podstawowe wzmocnienie. Jeszcze ważniejsze są indywidualni administratorzy, MFA i ograniczony dostęp. |
| 12 | DNS Protection powinno być skonfigurowane i aktywne. | Advanced security | Recommended | Medium | Nie aktywować ogólnie. DNS Protection jest sensowne, jeśli polityki Central-DNS i raportowanie są rzeczywiście wykorzystywane. |
| 13 | MFA powinno być aktywne dla logowań Remote Access VPN. | Authentication | CIS | High | Bardzo ważne dla SSL VPN i IPsec Remote Access. Planować wdrożenie z administratorem zapasowym i użytkownikami testowymi. |
| 14 | MFA powinno być aktywne dla WebAdmin Console i VPN Portal. | Authentication | CIS | High | Bardzo ważne, szczególnie jeśli portale są dostępne z mniej kontrolowanych sieci. |
| 15 | Połączenia z serwerami uwierzytelniania powinny być szyfrowane. | Authentication servers | CIS | Medium | Ważne przy połączeniach AD/LDAP/RADIUS. Unikać nieszyfrowanego uwierzytelniania. |
| 16 | Kopie zapasowe powinny być planowane na zaporze lub w Sophos Central. | Backup & restore | CIS | Low | Niski stopień ważności, ale w razie potrzeby niezwykle ważne. Proces przywracania również należy przetestować. |
| 17 | Uwierzytelnianie kluczem publicznym powinno być aktywowane dla SSH. | Device access | Recommended | High | Bardzo sensowne. Dodatkowo SSH powinno być dozwolone tylko z zaufanych sieci. |
| 18 | User Portal nie powinien być dostępny z WAN. | Device access | Recommended | High | W wielu środowiskach to właściwe. Jeśli dostęp z WAN jest konieczny, należy go mocno ograniczyć i używać MFA. |
| 19 | WebAdmin Console nie powinno być dostępne z WAN. | Device access | CIS | High | Jeden z najważniejszych punktów. WebAdmin nigdy nie powinno być szeroko otwarte na Internet. |
| 20 | MFA powinno być skonfigurowane dla domyślnego administratora. | Device access | CIS | High | Ważne, ale lepszy jest dodatkowo czysty proces administracyjny z osobistymi kontami administratorów. |
| 21 | Powiadomienia e-mail powinny być skonfigurowane dla zdarzeń systemowych i bezpieczeństwa. | Notification settings | CIS | Low | Ważne operacyjnie. Alternatywnie lub dodatkowo można zintegrować monitorowanie, Syslog, SIEM lub Central Alerts. |
| 22 | Automatyczne aktualizacje wzorców powinny być aktywowane. | Pattern updates | CIS | High | Podstawowa operacja. Bez aktualnych wzorców wiele funkcji ochronnych traci na wartości. W środowiskach Air-Gap potrzebny jest zamiast tego ręczny proces aktualizacji wzorców i licencji. |
| 23 | Polityka sieci Web powinna być wybrana w regule zapory. | Rules and Policies | Recommended | Medium | Sensowne dla ruchu sieciowego użytkowników. Nie stosować ślepo do ruchu serwer-serwer lub specjalnego ruchu. |
| 24 | Ochrona przed zerowym dniem powinna być wybrana w regule zapory. | Rules and Policies | CIS | High | Sensowne dla odpowiednich ścieżek sieci Web i pobierania. Należy uwzględnić licencję, wydajność i fałszywe alarmy. |
| 25 | IPS powinno być aktywowane, a polityka IPS powinna być wybrana w regule zapory. | Rules and Policies | CIS | High | Bardzo ważny punkt ochrony. IPS musi być jednak odpowiednio wybrany i logowany dla każdej ścieżki ruchu. |
| 26 | Polityka kontroli aplikacji powinna być wybrana w regule zapory. | Rules and Policies | CIS | Medium | Sensowne dla reguł internetowych klientów. Przy krytycznym ruchu najpierw przetestować. |
| 27 | Reguła inspekcji SSL/TLS powinna używać akcji Decrypt. | Rules and Policies | CIS | High | Nie aktywować ślepo. Inspekcja TLS wymaga dystrybucji CA, wyjątków, fazy pilotażowej i procesu rozwiązywania problemów. |
| 28 | Reguła Allow nie powinna wszędzie używać Any w polach sieci i usług. | Rules and Policies | CIS | Medium | Bardzo ważne dla higieny reguł. Any może być świadomie potrzebne, ale musi być wtedy uzasadnione i logowane. |
| 29 | Raportowanie Sophos Central powinno być aktywowane. | Sophos central | Recommended | Medium | Przydatne dla raportowania i dłuższych analiz. Nie jest konieczne, jeśli Syslog/SIEM jest prawidłowo obsługiwany. |
| 30 | Zapora powinna być zarejestrowana do zarządzania Sophos Central i zarządzanie Central powinno być aktywowane. | Sophos central | Recommended | Medium | Praktyczne dla centralnego zarządzania, kopii zapasowych i raportowania. Nie każda okolica chce lub potrzebuje zarządzania w chmurze. |
| 31 | Serwer NTP powinien być skonfigurowany. | Time | CIS | Low | Podstawowe wymaganie. Bez poprawnego czasu cierpią dzienniki, certyfikaty, uwierzytelnianie i rozwiązywanie problemów. |
Prawidłowe priorytetyzowanie ustaleń
Nie każde ustalenie ma w każdej okolicy takie samo znaczenie. Dobry przegląd sortuje wpisy nie tylko według technicznej ważności, ale także według ekspozycji i ryzyka operacyjnego.
Sprawdzona kolejność to:
- Sprawdzenie dostępu do zarządzania i portali eksponowanych na Internet.
- Sprawdzenie bezpieczeństwa MFA i logowania dla administratorów, VPN Portal, User Portal i Remote Access.
- Oczyszczenie reguł zapory zbyt szerokich źródeł, celów lub usług.
- Kontrola logowania, kopii zapasowych i poprawek.
- Sprawdzenie funkcji ochronnych dla każdej reguły, na przykład IPS, Web Policy, Application Control, TLS Inspection lub Zero-Day Protection.
- Ocena ustaleń Central, Reporting lub NDR pod kątem tego, czy funkcja jest rzeczywiście używana i obsługiwana w okolicy.
Kolejność jest pragmatyczna: najpierw rzeczy, które są bezpośrednio widoczne w Internecie lub pozwalają na dostęp do zapory. Następnie higiena reguł i funkcje ochronne. Następnie tematy operacyjne i ekosystemowe.
Typowe ustalenia i odpowiednie działania
WebAdmin, User Portal lub VPN Portal jest zbyt szeroko dostępny
Jeśli portale administracyjne lub użytkownika są dostępne zbyt szeroko z wielu stref, ryzyko związane ze skanami, próbami siłowymi i wypełnianiem poświadczeń wzrasta. Najważniejszy artykuł na ten temat to Zabezpieczanie dostępu do Sophos Firewall: prawidłowa konfiguracja Device Access.
Dla środowisk produkcyjnych należy sprawdzić:
- Czy WebAdmin jest naprawdę potrzebny z WAN?
- Czy istnieje Local Service ACL Exception Rule dla IP zarządzania lub sieci administratora?
- Czy SSH jest dozwolone tylko z zaufanych sieci?
- Czy User Portal i VPN Portal są dostępne tylko tam, gdzie są potrzebne?
Brak MFA lub nie jest konsekwentnie aktywowane
MFA powinno być co najmniej na dostępach administracyjnych i Remote Access. Jeśli Health Check pokazuje ustalenia MFA, nie należy ślepo przełączać wszystkich użytkowników jednocześnie. Lepsze jest kontrolowane wdrożenie z użytkownikiem testowym, administratorem zapasowym i czystym procesem tokenów.
Praktyczna instrukcja znajduje się w Aktywacja MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.
Reguły zapory są zbyt otwarte
Bardzo szerokie reguły z Any przy źródle, celu lub usłudze często są historycznie rozwinięte. Nie każda szeroka reguła jest automatycznie błędna, ale każda powinna być uzasadniona.
Do oczyszczenia pomocne są te pytania:
- Która strefa naprawdę może uzyskać dostęp do której strefy?
- Czy sieci docelowe lub usługi można ograniczyć?
- Czy logowanie jest aktywne, aby widoczne były trafienia?
- Czy istnieją stare reguły testowe lub tymczasowe wyjątki?
- Czy reguła może być podzielona na kilka bardziej zrozumiałych reguł?
Podstawy znajdują się w Zrozumienie i prawidłowa konfiguracja reguł Sophos Firewall. Jeśli nie jest jasne, która reguła obowiązuje, pomocne jest Testowanie reguł zapory za pomocą Log Viewer, Policy Test i Packet Capture.
Brak kopii zapasowych, poprawek i procesu aktualizacji
Health Check może wskazywać na brakujące kopie zapasowe lub tematy związane z aktualizacjami/poprawkami. Te punkty wydają się mniej spektakularne niż ekspozycja portalu, ale w razie potrzeby są kluczowe.
Przed większymi zmianami należy utworzyć kopię zapasową i wiedzieć, jak działa proces przywracania. Procedura jest opisana w Tworzenie lub przywracanie kopii zapasowej Sophos Firewall. Dla tematów związanych z oprogramowaniem układowym pasuje Aktualizacja oprogramowania układowego Sophos Firewall - przygotowanie i najlepsze praktyki.
Logowanie i raportowanie są niekompletne
Jeśli brakuje dzienników, operacje są ślepe. Health Check może dawać wskazówki dotyczące tematów związanych z logowaniem lub raportowaniem, ale ostateczna decyzja zależy od modelu operacyjnego.
Do lokalnej analizy są istotne Log Viewer, dzienniki usług i Packet Capture. Do dłuższego przechowywania potrzebne jest Central Firewall Reporting lub Syslog/SIEM. Jeśli nie chodzi o pojedyncze zdarzenia logowania, ale o przepływy ruchu, szczyty przepustowości lub podejrzane relacje komunikacyjne, dodatkowo pasuje Monitorowanie sFlow. Lokalne podstawy znajdują się w Rozwiązywanie problemów z Sophos Firewall: Usługi i dzienniki.
Funkcje ochronne nie są aktywne w regułach
Częstym punktem są reguły bez IPS, Web Policy, Application Control, TLS Inspection lub Zero-Day Protection. Nie należy aktywować wszystkiego ogólnie, ale zrozumieć ścieżkę ruchu.
Przykłady:
- Ruch sieciowy użytkowników wymaga innych kontroli niż ruch serwer-serwer.
- Inspekcja TLS musi być planowana, ponieważ może zakłócać aplikacje.
- IPS i Application Control wymagają logowania i rutyny przeglądu.
- Funkcje NDR lub Threat-Feed pomagają tylko wtedy, gdy ustalenia są później analizowane.
Dla inspekcji TLS pasuje Prawidłowe wprowadzenie inspekcji TLS w Sophos Firewall. Dla Threat Feeds pasuje Sophos Firewall Threat Feeds.
Świadome dokumentowanie nadpisów
Sophos Firewall pozwala na ręczne nadpisanie statusu poszczególnych kontroli. Może to być sensowne, jeśli rekomendacja w danym środowisku jest świadomie nie wdrażana.
Nadpisy nie powinny być jednak traktowane jako funkcja porządkowa. Jeśli punkt jest nadpisany, powinno być udokumentowane:
- Dlaczego rekomendacja nie jest odpowiednia?
- Kto zatwierdził decyzję?
- Czy wyjątek jest trwały czy tylko tymczasowy?
- Kiedy zostanie ponownie sprawdzony?
- Czy istnieje środek kompensacyjny?
⚠️ Nadpisanie nie jest naprawą. Jest to świadoma akceptacja ryzyka lub udokumentowany wyjątek. Bez uzasadnienia Health Check staje się mniej wartościowy.
Czysta dokumentacja wyników
Przegląd Health Check powinien generować zrozumiały wynik. W przeciwnym razie widzi się tylko krótko pulpit, ale później nie wiadomo, jaka decyzja została podjęta i które punkty są jeszcze otwarte.
Dla małych środowisk często wystarcza prosta tabela:
| Pole | Cel |
|---|---|
| Data | Kiedy sprawdzono Health Check? |
| Oprogramowanie układowe | Na której wersji SFOS oceniano? |
| Ustalenie | Jaki niezgodny punkt został zgłoszony? |
| Ryzyko | Dlaczego punkt jest w tym środowisku istotny lub mniej istotny? |
| Działanie | Co zostanie zmienione, przetestowane lub świadomie zaakceptowane? |
| Odpowiedzialny | Kto rozwiązuje punkt fachowo lub technicznie? |
| Termin | Do kiedy działanie ma być wykonane lub ponownie ocenione? |
| Dowód | Zrzut ekranu, bilet, ID zmiany lub wskazówka w dzienniku audytu |
Dla produkcyjnych zapór dowód nie powinien składać się tylko z zrzutu ekranu. Jeśli konfiguracja została zmieniona, należy połączyć bilet zmiany, ścieżkę audytu, dotkniętą regułę zapory i wynik ponownej kontroli. Dla zmian w regułach, interfejsach, hostach i usługach szczególnie przydatne jest Sprawdzanie dzienników ścieżki audytu Sophos Firewall.
Ponowne sprawdzenie po zmianach
Po naprawie należy ponownie otworzyć Health Check i sprawdzić, czy ustalenie rzeczywiście zniknęło. Dodatkowo potrzebna jest techniczna kontrola funkcji, ponieważ sam zielony status nie dowodzi, że produkcyjny ruch nadal działa poprawnie.
Przykłady:
- Po zmianie w Device access sprawdzić, czy dostęp administracyjny z przewidzianej sieci zarządzania nadal działa i nie jest już dostępny z niepożądanych sieci.
- Po zmianach MFA zalogować się z użytkownikiem testowym i oddzielnie sprawdzić administratora zapasowego.
- Po zmianach w regułach przetestować Log Viewer, Policy Test i dotknięte aplikacje.
- Po zmianach w logowaniu lub raportowaniu sprawdzić, czy nowe zdarzenia są rzeczywiście widoczne lokalnie, w Sophos Central lub w Syslog.
- Po nadpisaniu ustawić przypomnienie, aby wyjątek nie został trwale zapomniany.
Jeśli kilka ustaleń jest jednocześnie rozwiązywanych, należy podzielić zmiany na małe bloki. W przeciwnym razie przy późniejszym problemie nie będzie jasne, czy przyczyną była zmiana Device Access, MFA, reguł zapory, inspekcji TLS czy inna zmiana.
Wykorzystanie Health Check jako procesu operacyjnego
Health Check jest najskuteczniejszy, gdy jest regularnie i po ważnych zmianach wykonywany.
Sensowne momenty:
- po pierwszej konfiguracji lub uruchomieniu,
- przed i po większych zmianach w regułach,
- przed aktualizacjami oprogramowania układowego,
- po przywróceniu lub wymianie sprzętu,
- po migracjach lub większych zmianach architektonicznych,
- przed audytami,
- kwartalnie jako przegląd bezpieczeństwa.
Dla samych zmian należy dodatkowo wykorzystać ścieżkę audytu. Artykuł Sprawdzanie dzienników ścieżki audytu Sophos Firewall wyjaśnia, jak analizować configuration-audit.log i śledzić zmiany konfiguracji.
Praktyczny przebieg przeglądu
Pragmatyczny przegląd Health Check przebiega w ten sposób:
- Otwórz Health Check w Control Center.
- Posortuj niezgodne ustalenia według stopnia ważności.
- Najpierw sprawdź usługi i dostępy administracyjne eksponowane na Internet.
- Rozwiąż tematy związane z MFA, hasłami i sesjami.
- Zidentyfikuj szerokie reguły zapory i zweryfikuj je za pomocą Log Viewer.
- Sprawdź kopie zapasowe, poprawki, logowanie i raportowanie.
- Oceń funkcje ochronne dla każdej reguły.
- Dokumentuj uzasadnione wyjątki zamiast nadpisywać je bez komentarza.
- Po zmianach ponownie sprawdź.
- Dokumentuj wynik z datą, osobą odpowiedzialną i otwartymi punktami.
Dla powtarzających się przeglądów często wystarcza prosta tabela z ustaleniem, ryzykiem, działaniem, odpowiedzialnym, statusem i przypomnieniem. Ważne jest, aby ustalenia nie były tylko oglądane, ale rozwiązywane lub świadomie akceptowane.
Ograniczenia
Health Check jest pomocny, ale ma wyraźne ograniczenia.
- Nie zna pełnej logiki biznesowej środowiska.
- Nie ocenia, czy reguła jest fachowo potrzebna.
- Nie zastępuje segmentacji sieci i modelu stref.
- Nie rozpoznaje automatycznie każdego ryzykownego przypadku specjalnego.
- Nie zastępuje zewnętrznego audytu i ręcznej analizy reguł.
- Nie mówi, czy alerty będą później również przetwarzane.
Dlatego należy traktować Health Check jako punkt wyjścia. Umożliwia on uchwycenie widocznych odchyleń, ale rzeczywista jakość bezpieczeństwa powstaje dzięki dobrej architekturze, czystym procesom i konsekwentnej pielęgnacji.
Lista kontrolna operacji
- Wykonaj Health Check po uruchomieniu i po dużych zmianach.
- Priorytetyzuj ustalenia według stopnia ważności i ekspozycji.
- Sprawdź dostępność z WAN do WebAdmin, SSH, User Portal i VPN Portal.
- Aktywuj MFA dla administratorów, portali i Remote Access.
- Oczyść lub uzasadnij szerokie reguły zapory.
- Włącz logowanie w ważnych regułach.
- Sprawdź kopie zapasowe i proces przywracania.
- Dokumentuj proces poprawek i oprogramowania układowego.
- Ustaw nadpisy tylko z uzasadnieniem.
- Regularnie dokumentuj wynik Health Check.