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 Tickecie 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, logging, dane o użyciu, potwierdzenie Ownera 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 Review.

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, Owner, Ticket, Review 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, Ownera, Ticket i informację o Review 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. Dlatego po dodaniu nowej, sklonowanej lub automatycznie utworzonej reguły należy sprawdzić jej rzeczywistą Rule position.

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?
Owner: Który zespół odpowiada za aplikację i decyzję?
Change lub Ticket: Gdzie znajdują się zatwierdzenie, test i szczegóły techniczne?
Review 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 Change 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 Owner.

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-partnerskie; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Wyjątek=tylko zdefiniowane sieci partnerów

Szczegółowy przykład praktyczny

W zespołach stosujących bardziej szczegółową konwencję udokumentowana reguła DNAT może wyglądać na przykład tak:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

Pola AUTHOR i LAST MODIFIED mają sens tylko wtedy, gdy zespół konsekwentnie je aktualizuje. Jeśli Configuration Audit zapewnia wiarygodną historię zmian, w Description wystarczą cel, Owner, ticket i Review, a szczegółowy przykład może pozostać 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:

TYP_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, DNAT, TEMP lub DROP ułatwiają skanowanie listy. Source, Destination i Service pokazują 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 Ticketu. 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 Ownera. Prefiks taki jak TEMP ułatwia wyszukiwanie, ale nie zastępuje procesu wycofania. Data powinna znaleźć się zarówno w Description, jak i w Tickecie lub systemie Change, aby termin Review 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 Tickecie. W Description reguły firewalla wystarczy odwołanie do Change 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 jest magazynem sekretów (Secret Store). 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 Session, Token lub inne poufne dane.

Wystarczy wewnętrzny identyfikator Ticketu, 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 Review, ale nie uzasadnia natychmiastowego usunięcia reguły. Także status SFOS Unused jest jedynie sygnałem krótkoterminowym: oznacza, że w ciągu ostatnich 24 godzin reguła nie dopasowała żadnego ruchu. Zadania miesięczne, dostępy awaryjne lub aplikacje sezonowe mogą mimo to być uzasadnione.

Bezpieczny Review przebiega następująco:

Oznacz reguły bez Description, z ogólną nazwą, prefiksem TEMP lub przekroczoną datą Review.
Zapisz Rule ID, Position, Source, Destination, Services, Action i Security Profiles.
W razie potrzeby wybierz Reset data transfer count w sekcji More options i obserwuj regułę przez okres reprezentatywny dla aplikacji.
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 Ownera i Ticket pod kątem aktualnej potrzeby biznesowej.
Niepotrzebne reguły najpierw wyłącz, obserwuj przez uzgodniony okres i dopiero potem usuń.
Udokumentuj decyzję, test i wycofanie w Change.

Licznik wskazujący zero nie jest dowodem, jeśli okres obserwacji był zbyt krótki. Podobnie brak wpisu w logu niczego nie dowodzi, jeśli Log firewall traffic było wcześniej wyłączone albo lokalne lub zewnętrzne cele logowania nie zostały odpowiednio 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 dowodzi jednak, kto faktycznie ją zmienił. SFOS 22 może rejestrować zmiany reguł firewalla za pomocą Configuration Audit wraz z poprzednią i nową konfiguracją, znacznikiem czasu, administratorem oraz Source IP. Status sprawdza się poleceniem system configuration-audit show; funkcja jest domyślnie włączona.

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

Description i Ticket: cel, Owner, zatwierdzenie i Review.
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 Change 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, Ownera, Change i Review,
Log firewall traffic ustawione zgodnie z wymaganiami operacyjnymi i ochrony danych,
brak Secrets i danych osobowych w 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 Change oraz datę Review. Szczegóły techniczne, zatwierdzenie i Rollback pozostają w Tickecie lub Runbooku.

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

Nie. Unused oznacza jedynie, że w ciągu ostatnich 24 godzin reguła nie dopasowała żadnego ruchu. Przed usunięciem potrzebny jest reprezentatywny okres obserwacji, logi, potwierdzenie Ownera oraz kontrolowany test z wyłączoną regułą.

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. Secrets, 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 Source IP. Rzetelny Review wymaga obu tych elementów.