Przegląd reguł zapory sieciowej dla ISO 27001, NIS2, DORA i GDPR
Jest 07:42 w poniedziałek rano. CISO rosnącego dostawcy SaaS i usług fintech patrzy na trzy oddzielne wiadomości.
Pierwsza pochodzi z SOC. Skompromitowana stacja robocza programisty próbowała w nocy połączyć się z wewnętrzną podsiecią baz danych. Ruch został zablokowany, ale analityk chce potwierdzenia, że reguła zapory sieciowej jest zamierzona, aktualna i zatwierdzona.
Druga pochodzi od dużego klienta korporacyjnego. Klient oczekuje dowodów, że środowiska produkcyjne, rozwojowe, korporacyjne i wsparcia są odseparowane, reguły zapory sieciowej są przeglądane, a wyjątki wygasają.
Trzecia pochodzi od menedżera ds. zgodności. Organizacja jest objęta zakresem NIS2 jako ważny dostawca cyfrowy, ma obowiązki wynikające z GDPR jako podmiot przetwarzający, a klienci z sektora usług finansowych proszą o dowody zarządzania ryzykiem ICT zgodne z podejściem DORA. Zarząd chce wiedzieć, czy te same dowody ISO/IEC 27001:2022 mogą odpowiedzieć na wszystkie trzy potrzeby.
Następnie trafia przegląd po incydencie. Serwer rozwojowy niemal został wystawiony do Internetu podczas nocnej zmiany. Nie doszło do utraty danych klienta, ale zespół dochodzeniowo-śledczy odkrył coś gorszego niż pierwotny błąd: pięcioletnia reguła zapory sieciowej opisana jako „tymczasowy test” nadal dopuszczała szeroki ruch między środowiskiem rozwojowym a produkcyjnym. Gdyby atakujący uzyskał dostęp, sieć stawiłaby niewielki opór.
To moment, w którym wiele organizacji odkrywa bolesną prawdę. Mogą mieć zapory sieciowe, VLAN, grupy bezpieczeństwa w chmurze i diagramy, ale nie mają nadzoru nad strefami segmentacji, właścicielstwem reguł, dostępem tymczasowym, zatwierdzeniami zmian, recertyfikacją i dowodami audytowymi.
W 2026 r. odpowiedź „mamy zaporę sieciową” nie jest możliwa do obrony. Audytorzy, regulatorzy, klienci i ubezpieczyciele oczekują dowodów, że sieci są celowo separowane, ruch jest kontrolowany zgodnie z potrzebami biznesowymi, ryzykowne wyjątki podlegają nadzorowi, a logi pokazują, że środki kontrolne działają.
Dlaczego nadzór nad zaporami sieciowymi jest dziś kwestią dla zarządu
Segmentacja sieci była kiedyś traktowana jako techniczny temat inżynierski. Zespoły infrastruktury odpowiadały za VLAN, administratorzy zapór sieciowych utrzymywali zestawy reguł, zespoły chmurowe zarządzały grupami bezpieczeństwa, a zespół zgodności podczas audytów widział jedynie diagram.
Ten model operacyjny już nie działa.
Dyrektywa NIS2 wymaga od podmiotów kluczowych i ważnych wdrożenia odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych służących zarządzaniu ryzykiem dla sieci i systemów informatycznych. Article 21 obejmuje polityki analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpieczeństwa przy nabywaniu i utrzymaniu, oceny skuteczności, podstawowej cyberhigieny, kontroli dostępu oraz zarządzania aktywami. Organy zarządzające muszą zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa i nadzorować ich wdrożenie.
DORA ma zastosowanie od 17 stycznia 2025 r. do wielu podmiotów finansowych i czyni zarządzanie ryzykiem ICT dyscypliną nadzorowaną oraz udokumentowaną. Articles 5, 6 i 8 wymagają ładu, ram zarządzania ryzykiem ICT oraz identyfikacji funkcji biznesowych wspieranych przez ICT, aktywów informacyjnych, aktywów ICT, zależności, aktywów krytycznych i połączeń. Articles 9, 10 i 11 dotyczą ochrony, zapobiegania, wykrywania, reagowania i odzyskiwania. Articles 24 do 27 wymagają testowania cyfrowej odporności operacyjnej, w tym zaawansowanego testowania dla określonych podmiotów. To sprawia, że segmentacja jest kwestią odporności, a nie tylko konfiguracji zapory sieciowej.
GDPR dodaje warstwę rozliczalności prywatności. Article 32 wymaga odpowiednich środków technicznych i organizacyjnych zapewniających poziom bezpieczeństwa adekwatny do ryzyka, w tym poufność, integralność, dostępność i odporność. Article 5(1)(f) wymaga integralności i poufności, a Article 5(2) wymaga rozliczalności. Jeżeli systemy przetwarzające dane osobowe są osiągalne ze skompromitowanych punktów końcowych, sieci gościnnych lub niezarządzanych ścieżek dostępu stron trzecich, organ nadzorczy może zapytać, dlaczego te ścieżki w ogóle istniały.
ISO/IEC 27001:2022 zapewnia fundament systemu zarządzania, który łączy te obowiązki. Wymaga określenia zakresu, wymagań stron zainteresowanych, oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania, planowania i kontroli operacyjnej, odpowiedzialności kierownictwa, mierzalnych celów, udokumentowanych informacji i ciągłego doskonalenia. Załącznik A, wspierany wytycznymi ISO/IEC 27002:2022, obejmuje obszary środków kontrolnych potrzebne dla ryzyka dostawców, usług chmurowych, rejestrowania, monitorowania, bezpiecznej architektury, separacji środowisk i zarządzania zmianami.
Wniosek jest prosty: segmentacja sieci i przegląd reguł zapory sieciowej są dziś dowodem zarządzania.
Wzorzec operacyjny Clarysec: 8.20, 8.22 i 8.32
Clarysec traktuje segmentację i przegląd zapór sieciowych jako jeden wzorzec operacyjny obejmujący środki kontrolne ISO/IEC 27002:2022, a nie jako odizolowane zadania techniczne.
Trzy podstawowe środki kontrolne to:
| Obszar ISO/IEC 27002:2022 | Pytanie dotyczące nadzoru | Dowody oczekiwane przez audytorów |
|---|---|---|
| 8.20 Network security | Czy sieci są projektowane, zarządzane, monitorowane i chronione odpowiednio do ryzyka? | Diagramy architektury, standardy zapór sieciowych, procedury bezpiecznej sieci, logi monitorowania, dowody IDS/IPS, próbki konfiguracji VPN i sieci chmurowej |
| 8.22 Segregation of networks | Czy strefy są separowane według wrażliwości, funkcji i poziomu zaufania? | Model stref, macierz przepływu danych, projekt VLAN i podsieci, granice DMZ, reguły zapory sieciowej między strefami, wyniki testów segmentacji |
| 8.32 Change management | Czy zmiany reguł są oceniane, zatwierdzane, testowane, rejestrowane i przeglądane? | Zgłoszenia zmian, oceny ryzyka, zatwierdzenia, plany wycofania zmian, przeglądy powdrożeniowe, zapisy zmian awaryjnych |
W Zenith Blueprint: 30-etapowa mapa drogowa audytora [ZB] Clarysec umieszcza bezpieczeństwo sieci w fazie Controls in Action, krok 20: środki kontrolne 8.18 do 8.26. Przewodnik jasno formułuje kluczowe pytanie audytowe:
„U podstaw ten środek kontrolny wymaga od organizacji zapewnienia, że sieci są bezpieczne już na poziomie architektury, a nie tylko przez późniejsze dodanie zapór sieciowych lub oprogramowania antywirusowego. Oznacza to strategiczne podejście do segmentacji sieci, kontroli dostępu, szyfrowania danych w tranzycie, monitorowania i obrony w głąb. Zaczyna się od prostego pytania: kto i co się komunikuje oraz czy powinno?”
To pytanie — „kto i co się komunikuje oraz czy powinno?” — jest najlepszym praktycznym punktem wyjścia dla przeglądu reguł zapory sieciowej. Przenosi rozmowę z tysięcy nieczytelnych wpisów ACL na przepływy uzasadnione biznesowo.
Ten sam Zenith Blueprint wskazuje zespołom, aby oceniały architekturę sieci przez weryfikację, czy reguły zapory sieciowej, IPS/IDS oraz konfiguracje dostępu zdalnego są aktualne i utwardzone, oraz przez potwierdzenie, że grupy bezpieczeństwa w chmurze, routing i reguły VPC lub podsieci odpowiadają zamierzonej architekturze. Wskazuje także audytorom, że powinni oczekiwać Dokumentu architektury bezpieczeństwa sieci pokazującego zapory sieciowe, bramy VPN, strefy DMZ, separację VLAN i granice zaufania.
W zakresie zarządzania zmianami Zenith Blueprint umieszcza środek kontrolny ISO/IEC 27002:2022 8.32 w fazie Controls in Action, krok 21: środki kontrolne 8.27 do 8.34, i podkreśla, dlaczego nadzór nad zaporami sieciowymi zawodzi, gdy kontrola zmian jest słaba:
„Ten środek kontrolny uznaje trudną prawdę w IT: wiele incydentów nie wynika z ataków, lecz z niewłaściwie zarządzanych zmian. Reguła zapory sieciowej otwarta zbyt szeroko. Włączone ustawienie debugowania pozostawione po pracach. Zapomniana zależność po migracji.”
Właśnie w ten sposób tymczasowe otwarcia zapory sieciowej stają się stałymi ścieżkami ataku.
Jak wygląda dobra segmentacja sieci
Dojrzały program segmentacji ma cztery warstwy.
Po pierwsze, ma model stref. Strefy nie są arbitralnymi podsieciami. Są granicami zaufania powiązanymi z funkcją biznesową i wrażliwością danych, takimi jak DMZ dostępna z Internetu, warstwa aplikacyjna produkcji, warstwa baz danych produkcji, sieć użytkowników korporacyjnych, sieć zarządzania uprzywilejowanego, środowisko rozwojowe, środowisko testowe, sieć kopii zapasowych, gościnna sieć Wi‑Fi, strefa OT lub IoT oraz strefa dostępu stron trzecich.
Po drugie, ma macierz przepływów. Dla każdej pary stref organizacja dokumentuje dozwolone źródło, cel, protokół, port, aplikację, właściciela biznesowego, właściciela systemu, typ danych, uzasadnienie i wymaganie dotyczące rejestrowania.
Po trzecie, ma właścicielstwo reguł. Każda reguła zapory sieciowej, reguła grupy bezpieczeństwa w chmurze lub polityka perymetru definiowanego programowo ma właściciela, datę wygaśnięcia albo recertyfikacji, powiązane zgłoszenie zmiany oraz biznesowe uzasadnienie. Regułę typu „dowolne źródło — dowolny cel” należy traktować jako ustalenie z audytu, chyba że została formalnie zaakceptowana jako ryzyko, ograniczona czasowo i wsparta środkami kompensującymi.
Po czwarte, ma cykliczny przegląd. Przegląd oznacza więcej niż eksport bazy reguł zapory sieciowej raz w roku. Obejmuje recertyfikację przez właścicieli, porównanie z obserwowanym ruchem, wykrywanie nieużywanych reguł, walidację tymczasowych wyjątków, przegląd ekspozycji internetowej, testowanie segmentacji oraz uzgodnienie z inwentarzem aktywów.
Polityka bezpieczeństwa sieci [P-NS] Clarysec jasno określa oczekiwanie organizacji:
„Cały ruch między strefami musi być kontrolowany przez zapory sieciowe lub rozwiązania typu software-defined perimeter, z jednoznacznymi konfiguracjami domyślnej odmowy.”
Z Polityki korporacyjnej, Polityka bezpieczeństwa sieci, sekcja „Wymagania dotyczące ładu”, klauzula 5.2.
Ta sama polityka łączy zmiany zapory sieciowej bezpośrednio z zarządzaniem zmianami:
„Każda zmiana zestawów reguł zapory sieciowej, tablic routingu lub konfiguracji grup bezpieczeństwa musi być realizowana zgodnie z Polityką zarządzania zmianami organizacji (P5), w tym z planami wycofania zmian i rejestrowaniem audytowym.”
Z Polityki korporacyjnej, Polityka bezpieczeństwa sieci, sekcja „Wymagania dotyczące ładu”, klauzula 5.4.
Dla MŚP Polityka bezpieczeństwa sieci-sme [P-NS-SME] Clarysec przedstawia tę samą zasadę w ujęciu operacyjnym:
„Reguły domyślnej odmowy muszą być egzekwowane dla wszystkich połączeń przychodzących, chyba że są jednoznacznie wymagane i zatwierdzone”
Z Polityki MŚP, Polityka bezpieczeństwa sieci-sme, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula 6.1.2.
A wprost dla segmentacji:
„Ruch między segmentami musi być filtrowany, a dostęp między segmentami musi być zgodny z zasadą najmniejszych uprawnień”
Z Polityki MŚP, Polityka bezpieczeństwa sieci-sme, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula 6.2.3.
Te klauzule polityki pozwalają audytorowi prześledzić ścieżkę od ryzyka do środka kontrolnego, od środka kontrolnego do reguły, od reguły do zatwierdzenia i od zatwierdzenia do logów.
Jeden pakiet dowodowy dla ISO 27001, NIS2, DORA i GDPR
Błędem wielu zespołów jest budowanie odrębnych pakietów dowodowych: jednego dla ISO/IEC 27001:2022, jednego dla NIS2, jednego dla GDPR, jednego dla klientów wymagających DORA i jednego dla ubezpieczenia cyber.
Lepszym podejściem jest zbudowanie jednego pakietu dowodowego dla segmentacji i nadzoru nad zaporami sieciowymi, który mapuje się na różne ramy wymagań.
Zenith Controls: przewodnik po zgodności międzyramowej [ZC] mapuje środek kontrolny ISO/IEC 27002:2022 8.22 Segregation of Networks jako kontrolę zapobiegawczą wspierającą poufność, integralność i dostępność, powiązaną z koncepcją cyberbezpieczeństwa Protect oraz zdolnością operacyjną bezpieczeństwa systemów i sieci. Łączy 8.22 z 8.20 Network Security, 8.21 Security of Network Services, 8.7 Protection Against Malware, 8.27 Secure System Architecture and Engineering Principles oraz 8.31 Separation of Development, Test and Production Environments.
Przewodnik wyjaśnia znaczenie segmentacji dla NIS2 w następujący sposób:
„Segregacja sieci jest bezpośrednią odpowiedzią na te obowiązki, ponieważ ogranicza powierzchnię ataku i zapobiega ruchowi lateralnemu między systemami sieciowymi.”
To zdanie pokazuje, dlaczego programy cyberhigieny NIS2 nie powinny traktować segmentacji jako opcjonalnej. Powstrzymanie ransomware nie dotyczy wyłącznie ochrony punktów końcowych. Chodzi o ograniczenie ruchu lateralnego, gdy zapobieganie zawiedzie.
W odniesieniu do GDPR Zenith Controls mapuje 8.22 do Article 32 i Recital 49, wskazując, że diagramy sieci i polityki strefowe stają się kluczowymi dowodami zgodności. W odniesieniu do DORA Zenith Controls mapuje bezpieczeństwo sieci i segregację do zarządzania ryzykiem ICT oraz powstrzymywania incydentów. Testy segmentacji mogą wspierać dowody odporności ICT, szczególnie gdy potwierdzają, że naruszenie jednej strefy nie pozwala na swobodne przejście do krytycznych usług finansowych, repozytoriów danych osobowych ani systemów zarządzania uprzywilejowanego.
| Artefakt dowodowy | Zastosowanie w ISO/IEC 27001:2022 i ISO/IEC 27002:2022 | Zastosowanie w NIS2 | Zastosowanie w DORA | Zastosowanie w GDPR |
|---|---|---|---|---|
| Dokument architektury bezpieczeństwa sieci | Wspiera zakres SZBI, kontrolę operacyjną, 8.20 i 8.22 | Pokazuje środki techniczne dla bezpieczeństwa sieci i systemów informatycznych | Pokazuje połączenia ICT i zależności usług krytycznych | Pokazuje granice ochrony wokół systemów danych osobowych |
| Macierz stref i przepływów | Wykazuje segregację opartą na ryzyku i zasadę najmniejszych uprawnień | Wspiera cyberhigienę i ocenę skuteczności | Wspiera klasyfikację aktywów ICT i zależności | Wspiera środki techniczne i rozliczalność z Article 32 |
| Zapisy przeglądów reguł zapory sieciowej | Dowód monitorowania środków kontrolnych i ciągłego doskonalenia | Pokazuje, że środki są przeglądane, a nie statyczne | Wspiera przegląd ryzyka ICT i testowanie odporności | Wykazuje bieżące bezpieczeństwo przetwarzania |
| Zgłoszenia zmian dotyczące reguł zapory sieciowej | Wspierają 8.32 zarządzanie zmianami | Wspierają bezpieczne utrzymanie i identyfikowalność | Wspierają kontrolowaną zmianę ICT i odporność | Pokazują, że zmiany wpływające na systemy danych osobowych są oceniane pod kątem ryzyka |
| Rejestr wyjątków | Wspiera postępowanie z ryzykiem i akceptację ryzyka rezydualnego | Pokazuje nadzór kierownictwa nad odstępstwami | Wspiera tolerancję ryzyka i zarządzanie | Pokazuje rozliczalność za tymczasową ekspozycję |
| Logi zablokowanego i dozwolonego ruchu między strefami | Wspierają rejestrowanie, monitorowanie i skuteczność kontroli | Wspierają wykrywanie i reagowanie na incydenty | Wspierają klasyfikację incydentów i zgłaszanie | Wspierają ocenę naruszeń i zachowanie materiału dowodowego |
Ta tabela nie jest wyłącznie mapowaniem zgodności. Jest mapą drogową zbierania dowodów.
Przegląd reguł zapory sieciowej, który faktycznie działa
Przegląd reguł zapory sieciowej zawodzi, gdy zadaje tylko pytanie: „Czy ta reguła jest nadal potrzebna?”. Właściciele reguł często odpowiadają „tak”, ponieważ obawiają się przerwania działania usługi.
Lepszy przegląd zadaje sześć pytań:
- Jaką usługę biznesową wspiera ta reguła?
- Który właściciel aktywów i właściciel danych zatwierdzili przepływ?
- Czy cel znajduje się we właściwej strefie dla danych i funkcji?
- Czy reguła jest bardziej liberalna, niż wymaga tego obserwowany ruch?
- Czy rejestrowanie jest włączone dla przepływów wysokiego ryzyka?
- Czy reguła ma datę przeglądu, datę wygaśnięcia albo zapis wyjątku?
Polityka bezpieczeństwa sieci-sme wymaga okresowego przeglądu:
„Dostawca wsparcia IT musi przeprowadzać coroczny przegląd reguł zapory sieciowej, architektury sieci i konfiguracji bezprzewodowych”
Z Polityki MŚP, Polityka bezpieczeństwa sieci-sme, sekcja „Wymagania dotyczące ładu”, klauzula 5.6.1.
Przegląd roczny jest poziomem bazowym, a nie górną granicą. Reguły wysokiego ryzyka wymagają częstszej recertyfikacji.
| Kategoria reguły | Przykład | Częstotliwość przeglądu | Oczekiwane zatwierdzenie |
|---|---|---|---|
| Ruch przychodzący z Internetu do produkcji | Publiczne API do bramy aplikacyjnej | Kwartalnie lub po istotnym wydaniu | Właściciel usługi, bezpieczeństwo, zatwierdzający zmianę |
| Dostęp do produkcyjnej bazy danych między strefami | Warstwa aplikacyjna do warstwy baz danych | Kwartalnie | Właściciel aplikacji i właściciel danych |
| Dostęp administracyjny | Serwer przesiadkowy do portów zarządzania serwerami | Miesięcznie lub kwartalnie | Właściciel infrastruktury i delegat CISO |
| Dostęp stron trzecich | VPN dostawcy do podsieci wsparcia | Miesięcznie lub według kamienia milowego umowy | Właściciel dostawcy i bezpieczeństwo |
| Tymczasowy wyjątek | Dostęp awaryjny podczas migracji | Przed wygaśnięciem, maksymalnie 90 dni | Menedżer systemu zarządzania bezpieczeństwem informacji lub CISO |
| Standardowa reguła wewnętrzna niskiego ryzyka | Serwer monitorowania do zarządzanych punktów końcowych | Rocznie | Właściciel usługi |
Polityka bezpieczeństwa sieci jednoznacznie reguluje wyjątki:
„Wniosek musi zostać przejrzany i zatwierdzony przez Menedżera systemu zarządzania bezpieczeństwem informacji lub CISO oraz odnotowany w Rejestrze odstępstw SZBI, z maksymalnym okresem zatwierdzenia wynoszącym 90 dni, odnawialnym po ponownej ocenie.”
Z Polityki korporacyjnej, Polityka bezpieczeństwa sieci, sekcja „Postępowanie z ryzykiem i wyjątki”, klauzula 7.3.
Dla MŚP Polityka bezpieczeństwa sieci-sme wymaga, aby wnioski o wyjątek zawierały właściwe minimum informacji:
„Wniosek musi zawierać uzasadnienie, zakres, czas trwania oraz środki kompensujące (np. listy dozwolonych IP, rejestrowanie)”
Z Polityki MŚP, Polityka bezpieczeństwa sieci-sme, sekcja „Postępowanie z ryzykiem i wyjątki”, klauzula 7.3.3.
Ta klauzula zmienia obsługę wyjątków z nieformalnej rozmowy w postępowanie z ryzykiem możliwe do prześledzenia audytowo.
Praktyczny przykład: usunięcie ryzykownej reguły produkcyjnej bazy danych
Załóżmy, że firma podczas przeglądu znajduje następującą regułę:
| Pole | Obecna wartość |
|---|---|
| Źródło | VLAN użytkowników korporacyjnych |
| Cel | Podsieć produkcyjnej bazy danych |
| Port | TCP 5432 |
| Działanie | Zezwól |
| Komentarz | Tymczasowy dostęp na potrzeby migracji raportowania |
| Utworzono | 14 miesięcy temu |
| Właściciel | Nieznany |
| Rejestrowanie | Wyłączone |
To klasyczne ustalenie z audytu. Narusza zasadę najmniejszych uprawnień, nie ma jasnego właściciela, daty wygaśnięcia, aktualnego uzasadnienia ani rejestrowania. Tworzy również ekspozycję względem GDPR Article 32, jeżeli produkcyjna baza danych zawiera dane osobowe klientów.
Proces naprawczy powinien tworzyć dowody, a nie tylko usuwać złą regułę.
| Krok | Działanie | Odniesienie Clarysec | Utworzony dowód audytowy |
|---|---|---|---|
| 1. Zmapuj regułę do modelu stref | Potwierdź, czy użytkownicy korporacyjni kiedykolwiek powinni docierać do podsieci produkcyjnej bazy danych | Zenith Blueprint, Controls in Action Step 20 | Zaktualizowane notatki z przeglądu architektury i klasyfikacja strefy |
| 2. Utwórz lub zaktualizuj zapis przepływu | Udokumentuj źródło, cel, port, typ danych, właściciela, uzasadnienie i ryzyko | Zenith Controls, mapowanie 8.22 | Wpis w macierzy stref i przepływów |
| 3. Otwórz zgłoszenie zmiany | Zaproponuj usunięcie lub zastąpienie kontrolowaną ścieżką usługi raportowej | Polityka bezpieczeństwa sieci, klauzula 5.4 | Zapis zmiany z analizą ryzyka, planem testów i planem wycofania zmian |
| 4. Podejmij decyzję o postępowaniu | Usuń szeroką regułę albo zastąp ją repliką tylko do odczytu, bastionem, listą dozwolonych IP i rejestrowaniem | Polityka bezpieczeństwa sieci, klauzula 7.3 | Decyzja dotycząca postępowania z ryzykiem albo wyjątek ograniczony czasowo |
| 5. Włącz rejestrowanie dla zatwierdzonych przepływów | Przekazuj zdarzenia zapory sieciowej wysokiego ryzyka między strefami do monitorowania | Polityka logowania i monitorowania, klauzula 6.1.1.6 | Zapisy SIEM, reguły alertów i zrzuty ekranu z monitorowania |
| 6. Zweryfikuj segmentację | Przetestuj, że podsieć bazy danych jest nieosiągalna poza zatwierdzonymi ścieżkami | Zenith Blueprint, Step 20 | Wynik testu segmentacji i zamknięcie działań naprawczych |
Polityka logowania i monitorowania [P-LM] Clarysec obejmuje komunikację zewnętrzną i wyzwalacze reguł zapory sieciowej jako zdarzenia istotne dla logów:
„Komunikacja zewnętrzna i wyzwalacze reguł zapory sieciowej”
Z Polityki korporacyjnej, Polityka logowania i monitorowania, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula 6.1.1.6.
W przypadku reguł między strefami o wysokim ryzyku wyzwalacze zapory sieciowej powinny trafiać do SIEM lub platformy monitorowania, wraz z alertami dotyczącymi nietypowych hostów źródłowych, wolumenów lub okien czasowych.
Polityka MŚP wymaga również dyscypliny zmian:
„Wszystkie zmiany konfiguracji sieciowych (reguły zapory sieciowej, ACL przełączników, tablice routingu) muszą być realizowane zgodnie z udokumentowanym procesem zarządzania zmianami”
Z Polityki MŚP, Polityka bezpieczeństwa sieci-sme, sekcja „Wymagania dotyczące wdrożenia polityki”, klauzula 6.9.1.
Jednorazowe uporządkowanie tej reguły tworzy dowody dla kontroli operacyjnej ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 i 8.32, cyberhigieny NIS2, GDPR Article 32 oraz zarządzania ryzykiem ICT zgodnego z podejściem DORA.
Należy uwzględnić chmurę, SaaS i sieci hybrydowe
Współczesna segmentacja to nie tylko VLAN i fizyczne zapory sieciowe. Obejmuje grupy bezpieczeństwa AWS, sieciowe grupy bezpieczeństwa Azure, polityki sieciowe Kubernetes, tablice routingu w chmurze, listy dozwolonych administratorów SaaS, prywatne punkty końcowe, VPN, SD-WAN, serwery proxy uwzględniające tożsamość oraz kontrole typu software-defined perimeter.
Dla dostawcy SaaS lub regulowanej usługi cyfrowej przegląd reguł zapory sieciowej powinien obejmować co najmniej:
- równoważniki obciążenia i bramy aplikacyjne dostępne z Internetu
- grupy bezpieczeństwa w chmurze i sieciowe listy kontroli dostępu (ACL)
- tablice routingu prywatnych podsieci
- ścieżki peeringu i bram tranzytowych
- ścieżki VPN i zdalnej administracji
- interfejsy administracyjne i płaszczyzny zarządzania
- Ingress Kubernetes i polityki sieciowe
- dostęp runnerów CI/CD do środowiska produkcyjnego
- pokrycie rejestrowaniem dla odrzuconych i dozwolonych przepływów wysokiego ryzyka
- dostęp wsparcia stron trzecich i ścieżki awaryjne typu „break glass”
Jeżeli grupa bezpieczeństwa w chmurze zezwala na przychodzący ruch bazodanowy z szerokiego zakresu adresów IP organizacji, traktuj ją jak regułę zapory sieciowej. Wymaga właściciela, uzasadnienia, zatwierdzenia, przeglądu, rejestrowania i daty wygaśnięcia.
W tym miejscu normy wspierające ISO wzmacniają argumentację. ISO/IEC 27017 wspiera jasność odpowiedzialności za bezpieczeństwo chmury. ISO/IEC 27033 zapewnia głębsze wytyczne dotyczące architektury bezpieczeństwa sieci, DMZ, stref segmentacji, filtrowania ruchu i bezpiecznej komunikacji między sieciami. ISO/IEC 27701 wzmacnia ład prywatności tam, gdzie dane osobowe umożliwiające identyfikację osoby przemieszczają się przez sieci. ISO/IEC 27035 wspiera powstrzymywanie incydentów, a ISO/IEC 27005 wspiera wybór segmentacji jako sposobu postępowania z ryzykiem nieuprawnionego dostępu, rozprzestrzeniania się złośliwego oprogramowania i ruchu lateralnego.
Jak audytorzy różnie testują ten sam środek kontrolny
Jedną z zalet Zenith Controls jest wyjaśnienie, jak różne metodyki audytu badają ten sam środek kontrolny. Dowody można ponownie wykorzystać, ale pytania są różne.
| Perspektywa audytu | Prawdopodobne pytanie | Najlepszy dowód |
|---|---|---|
| Audytor ISO/IEC 27001:2022 | Czy segmentacja została wybrana, wdrożona i przeglądana na podstawie ryzyka? | Ocena ryzyka, SoA, polityka sieciowa, diagramy, zapisy przeglądów |
| Audytor w stylu ISO/IEC 27007 | Czy wdrożone reguły zapory sieciowej i schematy VLAN odpowiadają udokumentowanej polityce? | Próbki reguł zapory sieciowej, ACL routerów, projekt VLAN, rozmowy z administratorami |
| Podejście audytu certyfikacyjnego ISO/IEC 27006-1:2024 | Czy krytyczne granice sieciowe są audytowane z odpowiednimi kompetencjami i planowaniem opartym na ryzyku? | Plan audytów, próbkowanie techniczne, dowody grup bezpieczeństwa w chmurze, wyniki testów |
| Audytor zorientowany na NIST | Czy granice i przepływy informacji są egzekwowane i monitorowane? | Reguły zapory sieciowej, ACL, testy segmentacji, zapisy monitorowania |
| Audytor COBIT 2019 | Czy bezpieczeństwo sieci jest nadzorowane, monitorowane i raportowane? | Macierz właścicielstwa, KPI, raportowanie dla kierownictwa, rejestr ryzyk |
| Audytor ISACA ITAF | Czy ogólne kontrole IT działają spójnie? | Zgłoszenia zmian, zatwierdzenia wyjątków, logi, próbki recertyfikacji reguł |
| Organ nadzorczy GDPR | Czy systemy danych osobowych były chronione odpowiednimi środkami technicznymi? | Mapy przepływu danych, izolacja stref danych osobowych, ścieżki dostępu, logi zapory sieciowej |
| Asesor ukierunkowany na DORA | Czy segmentacja wspiera odporność ICT i powstrzymywanie incydentów? | Mapa zależności aktywów ICT, przepływy funkcji krytycznych, podręczniki postępowania incydentowego, zapisy testów |
Asesor ukierunkowany na DORA może zapytać, czy naruszenie bramy płatności pozwala na przejście do baz danych klientów. Właściwy organ NIS2 może zapytać, czy ransomware na administracyjnej stacji roboczej może dotrzeć do systemów kluczowych dla świadczenia usług. Organ GDPR może zapytać, jakie ograniczenia na poziomie sieci chroniły systemy przetwarzające dane osobowe. Audytor ISO może po prostu poprosić o ocenę ryzyka, SoA, politykę, procedurę i dowody, że przeglądy zostały wykonane.
Najlepsze programy odpowiadają na wszystkie te pytania tymi samymi artefaktami.
Metryki, które pokazują segmentację kierownictwu
NIS2 i DORA wzmacniają rozliczalność kierownictwa. ISO/IEC 27001:2022 wymaga przywództwa, celów, ról, zasobów, raportowania i ciągłego doskonalenia. Oznacza to, że segmentacja potrzebuje metryk zrozumiałych dla kierownictwa.
Przydatne metryki zarządcze obejmują:
- odsetek reguł zapory sieciowej z przypisanym właścicielem
- odsetek reguł z udokumentowanym biznesowym uzasadnieniem
- liczbę wygasłych reguł tymczasowych
- liczbę reguł z „any” jako źródłem, celem lub usługą
- liczbę usług wystawionych do Internetu według krytyczności
- odsetek przepływów między strefami o wysokim ryzyku z włączonym rejestrowaniem
- liczbę awaryjnych zmian zapory sieciowej na kwartał
- odsetek próbkowanych reguł powiązanych z zatwierdzonymi zgłoszeniami zmian
- liczbę niepowodzeń testów segmentacji
- średni czas usunięcia ryzykownych lub nieużywanych reguł
- liczbę wyjątków starszych niż 90 dni
- liczbę reguł dostępu stron trzecich poddanych przeglądowi i recertyfikacji
Polityka bezpieczeństwa sieci wskazuje „skuteczność reguł zapory sieciowej” jako aspekt zgodności i egzekwowania w sekcji „Egzekwowanie i zgodność”, klauzula 8.2.2. To sformułowanie ma znaczenie, ponieważ samo istnienie reguł nie wystarcza. Reguły muszą być skuteczne, przeglądane i dostosowane do aktualnego ryzyka.
Zbuduj pakiet dowodowy segmentacji na 2026 r.
Praktyczny pakiet dowodowy dotyczący segmentacji i przeglądu reguł zapory sieciowej powinien być gotowy, zanim audytor o niego poprosi.
Co najmniej należy utrzymywać:
- Aktualny diagram architektury sieci, w tym strefy chmurowe i hybrydowe
- Standard klasyfikacji stref, w tym wrażliwość i poziom zaufania
- Macierz przepływów dla usług krytycznych i systemów danych osobowych
- Eksport reguł zapory sieciowej i grup bezpieczeństwa w chmurze
- Rejestr właścicieli reguł i recertyfikacji
- Procedurę przeglądu zapory sieciowej i kalendarz przeglądów
- Zapisy zmian dla próbkowanych modyfikacji zapory sieciowej
- Rejestr wyjątków z zatwierdzeniami, datą wygaśnięcia i środkami kompensującymi
- Wyniki testów segmentacji i zapisy działań naprawczych
- Dowody rejestrowania i monitorowania dla przepływów wysokiego ryzyka
- Podręczniki postępowania incydentowego pokazujące powstrzymywanie według stref
- Metryki raportowania dla kierownictwa i protokoły ze spotkań
Zmapuj te dowody do klauzul ISO/IEC 27001:2022 oraz obszarów środków kontrolnych Załącznika A. Następnie odnieś je krzyżowo do NIS2 Article 21, GDPR Article 32, wymagań DORA dotyczących zarządzania ryzykiem ICT i testowania, wyników NIST CSF 2.0, takich jak GOVERN, PROTECT, DETECT i RESPOND, oraz praktyk zarządzania COBIT.
NIST CSF 2.0 jest szczególnie użyteczny jako warstwa komunikacji z zarządem. Funkcja GOVERN koncentruje się na wymaganiach prawnych, regulacyjnych i umownych, apetycie na ryzyko, rolach, politykach i nadzorze. Wyniki operacyjne odnoszą się do zarządzania konfiguracją, rejestrowania, monitorowania, ochrony danych, reagowania na incydenty i odzyskiwania. Pomaga to kierownictwu zrozumieć ryzyko bez czytania ACL zapór sieciowych.
Typowe ustalenia Clarysec w audytach segmentacji
W środowiskach SaaS, fintech, u dostawców usług zarządzanych i regulowanych MŚP stale pojawiają się te same ustalenia:
- płaska sieć między punktami końcowymi użytkowników a usługami produkcyjnymi
- produkcyjne bazy danych osiągalne ze środowisk rozwojowych lub sieci korporacyjnych
- szerokie grupy bezpieczeństwa w chmurze skopiowane ze starych szablonów
- tymczasowe reguły dostawców bez daty wygaśnięcia
- zmiany zapory sieciowej wykonywane poza procesem zmian
- reguły bez właściciela lub biznesowego uzasadnienia
- wyłączone rejestrowanie dla reguł zezwalających wysokiego ryzyka
- gościnna sieć Wi‑Fi nie w pełni odizolowana
- interfejsy administracyjne osiągalne z sieci ogólnych
- diagramy niezgodne z rzeczywistym routingiem
- brak dowodów, że przeglądy reguł zostały zakończone
- brak testów segmentacji po istotnych zmianach architektury
- brak mapowania między systemami danych osobowych a strefami sieciowymi
- brak raportowania dla kierownictwa dotyczącego ekspozycji sieciowej
Te ustalenia nie są wyłącznie słabościami technicznymi. Podważają zdolność organizacji do wykazania cyberhigieny NIS2, odporności operacyjnej DORA i rozliczalności GDPR Article 32.
Od reaktywnego porządkowania do możliwej do obrony kontroli
Segmentacja sieci i przegląd reguł zapory sieciowej to miejsce, w którym architektura bezpieczeństwa spotyka się z rzeczywistością audytu. Jeżeli możesz pokazać model stref oparty na ryzyku, kontrolowane przepływy między strefami, zatwierdzone zmiany zapory sieciowej, wyjątki ograniczone czasowo, dowody rejestrowania i okresową walidację, możesz odpowiedzieć na szeroki zakres pytań ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST i COBIT jedną spójną historią.
Clarysec może pomóc Ci ją zbudować.
Użyj Zenith Blueprint: 30-etapowa mapa drogowa audytora, aby uporządkować ścieżkę wdrożenia, szczególnie Controls in Action Step 20 dla bezpieczeństwa sieci i segmentacji oraz Step 21 dla zarządzania zmianami. Użyj Zenith Controls: przewodnik po zgodności międzyramowej, aby zmapować środki kontrolne ISO/IEC 27002:2022 8.20, 8.22 i 8.32 na oczekiwania audytowe NIS2, DORA, GDPR, NIST i COBIT. Oprzyj reguły operacyjne na dokumentach Clarysec: Polityka bezpieczeństwa sieci, Polityka bezpieczeństwa sieci-sme oraz Polityka logowania i monitorowania.
Twój następny krok jest prosty i ma wysoką wartość: wybierz jedną usługę krytyczną, taką jak produkcja klienta, przetwarzanie płatności lub zarządzanie tożsamością, i wykonaj w tym tygodniu przegląd próbki 10 reguł. Dla każdej reguły potwierdź właściciela, uzasadnienie, źródło, cel, port, rejestrowanie, zgłoszenie zmiany i datę wygaśnięcia. Jeżeli nie możesz wykazać tych siedmiu faktów, masz początek planu doskonalenia segmentacji na 2026 r.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
