Jak sensownie dokumentować reguły Sophos Firewall

Reguła firewalla nie jest jedynie technicznym zezwoleniem, ale także decyzją operacyjną: kto, dokąd, za pośrednictwem jakiej usługi i z jakiego powodu może uzyskać dostęp? Bez tego kontekstu stare reguły testowe, partnerskie lub migracyjne często pozostają aktywne przez lata, ponieważ nikt nie potrafi już wiarygodnie ocenić ich celu.

Najważniejsze informacje powinny więc znaleźć się bezpośrednio w polach Rule name i Description. Szczegóły można umieścić w zgłoszeniu lub wiki, natomiast sama reguła przedstawia kontekst potrzebny w codziennej eksploatacji. Sam opis nie wystarcza jednak do bezpiecznego uporządkowania reguł. Potrzebne są również Rule ID, logowanie, dane o użyciu, potwierdzenie właściciela oraz kontrolowany okres obserwacji.

Podstawowe informacje dotyczące technicznej budowy reguł zawiera artykuł Zrozumienie i bezpieczna konfiguracja reguł Sophos Firewall. Poniższa instrukcja koncentruje się na nazewnictwie, dokumentowaniu i przeglądzie.

Gdzie wprowadza się dokumentację

Ścieżka to Rules and policies > Firewall rules. Najpierw wybierz IPv4 lub IPv6, a następnie edytuj istniejącą regułę albo utwórz nową za pomocą Add firewall rule > New firewall rule.

W ustawieniach ogólnych szczególnie istotne dla dokumentacji są:

Rule name: krótka i łatwa do rozpoznania nazwa połączenia.
Rule position: pozycja na liście reguł przetwarzanej od góry do dołu.
Rule group: organizacyjne grupowanie reguły.
Description: cel, właściciel, numer zgłoszenia, termin przeglądu i świadomy wyjątek.
Log firewall traffic: generuje logi i dane raportowe dla pasujących połączeń.

Reguła Sophos Firewall z polem Description — Pole Description przechowuje cel, właściciela, numer zgłoszenia i termin przeglądu bezpośrednio przy regule Sophos Firewall.

Rule group poprawia przejrzystość, ale nie zmienia logiki przetwarzania. Sophos Firewall sprawdza poszczególne reguły od góry do dołu i zatrzymuje się przy pierwszym dopasowaniu. Grupa nie może pozostać pusta. Aby przenieść regułę poza granice grupy, trzeba ją najpierw odłączyć za pomocą opcji Detach albo przenieść całą grupę. Dlatego po dodaniu nowej, sklonowanej lub automatycznie utworzonej reguły należy sprawdzić jej rzeczywistą Rule position.

Osoby zarządzające regułami przez API muszą uwzględnić stałe limity obowiązujące w SFOS 22. Rule name może zawierać maksymalnie 60 znaków i nie może zawierać przecinka. W przypadku Rule groups API dopuszcza 150 znaków w nazwie, 255 znaków w opisie i maksymalnie 200 odwołań do reguł. Limity te dotyczą API. Aktualna pomoc WebAdmin nie podaje limitu znaków dla pola Description. Mimo to opis powinien być krótki, aby pozostał czytelny w tabeli reguł.

Co powinno znaleźć się w Description

Source, Destination, Services, Action i Security Profiles są już widoczne w regule. Pole Description nie powinno powtarzać tych samych informacji, lecz uzupełniać te, których później mogłoby zabraknąć.

Praktyczny standard minimalny obejmuje:

Cel: Jaki proces biznesowy lub operacyjny wymaga tego zezwolenia?
Właściciel: Który zespół odpowiada za aplikację i decyzję?
Zmiana lub zgłoszenie: Gdzie znajdują się zatwierdzenie, test i szczegóły techniczne?
Przegląd lub data wygaśnięcia: Kiedy reguła zostanie ponownie sprawdzona lub usunięta?
Wyjątek: O jakim świadomym odstępstwie lub ograniczeniu musi wiedzieć administrator?

Autora reguły ani czasu jej zmiany nie trzeba wpisywać ręcznie, jeśli Configuration Audit i proces zarządzania zmianami niezawodnie dostarczają tych informacji. Imię i nazwisko w Description szybko może stać się nieaktualne. Trwały zespół lub rola są zazwyczaj lepszym wyborem jako właściciel.

Kompaktowy szablon

Dla wielu reguł wystarczy jeden uporządkowany wiersz:

Cel=Dostęp-ERP; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

W przypadku świadomego wyjątku należy dodać krótką informację:

Cel=Przesyłanie-przez-partnerów; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Wyjątek=tylko zdefiniowane sieci partnerów

Szczegółowy przykład praktyczny

Szczegółowo udokumentowana reguła DNAT może wyglądać następująco:

DNAT - Synology HTTPS
---
OWNER: NETOPS
LAST REVIEW: 2027-01-31
SOURCE: PARTNER_NETS
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined partner networks
DOC: CHG-1842

Ten format pokazuje Source, Destination i Service również poza WebAdmin. Jeśli jednak ktoś zmieni regułę, musi także zaktualizować Description. W przeciwnym razie informacje będą ze sobą sprzeczne. Dlatego zalecamy kompaktowy szablon. Jeżeli Configuration Audit wiarygodnie rejestruje zmiany, w Description wystarczą cel, Owner, zgłoszenie i termin przeglądu. Szczegółowy przykład można umieścić w zgłoszeniu zmiany lub runbooku.

Description jest drogowskazem, a nie kompletną CMDB. Długie protokoły testowe, decyzje architektoniczne i instrukcje rollbacku powinny znajdować się w powiązanym zgłoszeniu lub runbooku.

Spójne nazewnictwo reguł

Dobrą nazwę można zrozumieć w widoku reguł bez otwierania samej reguły. Schemat nie musi być identyczny w każdej firmie, ale powinien pozostać spójny w obrębie danego środowiska.

Sprawdzonym przykładem jest:

PREFIX_ZRODLO_CEL_USLUGA

Przykłady:

ALLOW_VLAN12_WAN_HTTPS
ALLOW_VPNUSERS_SRVERP_HTTPS
DNAT_WAN_SRVWEB01_HTTPS
TEMP_PARTNER_SRVAPP_SFTP
DROP_VLANIOT_INTERNAL_ANY

ALLOW i DROP określają działanie, DNAT oznacza regułę firewalla związaną z publikacją, a TEMP — dostęp tymczasowy. DNAT nie oznacza tu samej reguły NAT. Źródło, cel i usługa wskazują kierunek. Skróty powinny być wyjaśnione w wewnętrznym standardzie nazewnictwa, ponieważ w przeciwnym razie kompaktowa nazwa stanie się kolejną zagadką.

Należy unikać ogólnych nazw, takich jak Rule1, Test, Allow, Internet lub Temp. Niekorzystne są również nazwy zawierające wyłącznie numer zgłoszenia. CHG-1842 można wprawdzie odszukać, ale w razie awarii nie wyjaśnia ani kierunku, ani usługi.

Dostępy tymczasowe i opublikowane

Reguły tymczasowe wymagają rzeczywistej daty wygaśnięcia i właściciela. Prefiks taki jak TEMP ułatwia wyszukiwanie, ale nie zastępuje procesu wycofania. Data powinna znaleźć się zarówno w Description, jak i w zgłoszeniu lub systemie zarządzania zmianami, aby termin przeglądu nie zależał wyłącznie od ręcznego przeglądania firewalla.

W przypadku opublikowanych serwerów sama reguła firewalla nie wystarcza do udokumentowania konfiguracji. Reguła DNAT, Firewall Rule ID, usługa publiczna, wewnętrzny host docelowy i zatwierdzenie powinny zostać wspólnie zapisane w zgłoszeniu. W Description reguły firewalla wystarczy odwołanie do zmiany i celu. Szczegółów NAT nie należy duplikować w postaci trudnej do odczytania, drugiej konfiguracji tekstowej.

W realizacji technicznej pomagają artykuły Publikowanie serwera przez DNAT na Sophos Firewall i Zrozumienie NAT na Sophos Firewall.

Czego nie należy umieszczać w Description

Opis reguły jest widoczny dla administratorów i nie służy do przechowywania danych poufnych. Nie należy w nim wpisywać:

haseł, kluczy API ani tokenów,
kluczy prywatnych ani Preshared Keys,
danych osobowych lub poufnych danych klientów bez wyraźnej konieczności,
kompletnych instrukcji dostępu dla osób zewnętrznych,
długich adresów URL zawierających parametry sesji, tokenu lub inne poufne dane.

Wystarczy wewnętrzny numer zgłoszenia, taki jak CHG-1842. Właściwy link i poufne szczegóły pozostają w przeznaczonym do tego systemie z odrębną kontrolą dostępu.

Kontrolowane sprawdzanie istniejących reguł

Brak Description jest powodem do przeprowadzenia przeglądu, ale nie uzasadnia natychmiastowego usunięcia reguły. Także status SFOS Unused jest jedynie stanem chwilowym. Aktualna pomoc Sophos podaje — zależnie od widoku — 12 lub 24 godziny bez pasującego ruchu. Zadania miesięczne, dostępy awaryjne lub aplikacje sezonowe mogą mimo to być uzasadnione.

Bezpieczny przegląd przebiega następująco:

Oznacz reguły bez Description, z ogólną nazwą, prefiksem TEMP lub przekroczoną datą przeglądu.
Zapisz Rule ID, pozycję, stan aktywacji, Source, Destination, Services, Action i Security Profiles. W razie potrzeby sprawdź używane hosty i usługi za pomocą Object Usage; widoczny tam licznik pokazuje zależności w konfiguracji, a nie ruch obsłużony przez regułę.
Przed użyciem opcji More options > Reset data transfer count zapisz w zgłoszeniu znacznik czasu i bieżący stan licznika. Zeruj licznik tylko wtedy, gdy późniejszy okres obserwacji obejmie również rzadko występujące połączenia.
W Reports > Dashboards > Traffic dashboard sprawdź ilość przesłanych danych w sekcji Allowed policies.
W Log viewer wyszukaj Rule ID, Source, Destination i Service.
Zweryfikuj właściciela i zgłoszenie pod kątem aktualnej potrzeby biznesowej.
Reguły, które nie są już potrzebne, wyłącz w uzgodnionym oknie i obserwuj. Jeśli oczekiwany ruch przestanie działać, natychmiast ponownie włącz regułę, sprawdź jej pozycję i powtórz test z oczekiwaną Rule ID.
Udokumentuj decyzję, test i wycofanie w zgłoszeniu zmiany.

Wyłączoną regułę można usunąć dopiero po bezproblemowym zakończeniu uzgodnionego okresu obserwacji i uzyskaniu zgody właściciela. Licznik wskazujący zero nie jest dowodem, jeśli okres był zbyt krótki. Brak wpisu w logu również nie wystarcza jako dowód. Funkcja Log firewall traffic mogła być wyłączona, połączenie mogło zostać przerwane bez zarejestrowanego zdarzenia Destroy albo cele logowania mogły być nieprawidłowo skonfigurowane. W System services > Log settings określa się, które logi firewalla są zapisywane lokalnie, wysyłane do Sophos Central lub przekazywane do serwerów Syslog.

Śledzenie zmian i ich skutków

Description wyjaśnia, dlaczego reguła powinna istnieć. Nie pokazuje jednak, kto faktycznie ją zmienił. W SFOS 22 funkcja Configuration Audit rejestruje poprzedni i nowy stan, znacznik czasu, administratora oraz źródłowy adres IP. Status sprawdza się w Device Console poleceniem system configuration-audit show, a nie w Advanced Shell. Funkcja jest domyślnie włączona.

W procesie operacyjnym należy połączyć trzy rodzaje dowodów:

Description i zgłoszenie: cel, właściciel, zatwierdzenie i przegląd.
Configuration Audit: kto, kiedy i jaką konfigurację zmienił.
Log Viewer i Reports: jakie połączenia reguła faktycznie przetworzyła.

Artykuł Sprawdzanie logów Audit Trail w Sophos Firewall dokładniej opisuje Configuration Audit i analizę danych. Po każdej zmianie reguły artykuł Testowanie reguły firewalla za pomocą Log Viewer, Policy Test i Packet Capture pokazuje, czy rzeczywiście używana jest oczekiwana Rule ID.

Minimalny standard dla nowych reguł

Przed zamknięciem zgłoszenia zmiany nowa reguła powinna spełniać następujące wymagania:

spójna Rule name,
świadomie sprawdzone Rule position i Rule group,
Source, Destination i Services bez niepotrzebnie szerokiego Any,
Description zawierające cel, właściciela, zmianę i termin przeglądu,
Log firewall traffic ustawione zgodnie z wymaganiami operacyjnymi i ochrony danych,
brak danych poufnych i danych osobowych w polach Rule name oraz Description,
test funkcjonalny z oczekiwaną Rule ID,
proces wygaśnięcia i wycofania dla reguł tymczasowych.

FAQ

Jakie informacje powinny znaleźć się w regule Sophos Firewall?

Rule name i Description powinny wskazywać co najmniej cel, odpowiedzialny zespół, odwołanie do zmiany oraz datę przeglądu. Szczegóły techniczne, zatwierdzenie i sposób wycofania zmiany pozostają w zgłoszeniu lub runbooku.

Czy status Unused oznacza, że regułę można usunąć?

Nie. Aktualna pomoc Sophos podaje dla statusu Unused — zależnie od widoku — 12 lub 24 godziny bez pasującego ruchu. Przed usunięciem potrzebny jest reprezentatywny okres obserwacji, logi, potwierdzenie właściciela oraz kontrolowany test z wyłączoną regułą i możliwością szybkiego wycofania zmiany.

Czy licznik danych wystarcza jako dowód użycia reguły?

Nie. Licznik pomaga w obserwacji, ale należy go oceniać razem z Log Viewer, Reports i procesem biznesowym. Rzadkie lub sezonowe połączenia mogą pozostać nieużywane podczas krótkiego testu.

Czy hasła lub dane dostępowe powinny znajdować się w Description?

Nie. Dane poufne, klucze prywatne i poufne dane dostępowe powinny znajdować się w przeznaczonym do tego systemie z odrębną kontrolą dostępu, a nie w regułach firewalla.

Jaka jest różnica między Description a Configuration Audit?

Description dokumentuje cel i odpowiedzialność. Configuration Audit rejestruje rzeczywistą zmianę wraz z poprzednim i nowym stanem, znacznikiem czasu, administratorem oraz źródłowym adresem IP. Rzetelny przegląd wymaga obu tych elementów.