Segmentacja sieci firmowej: VLAN, strefy i reguły firewall

Poniższy scenariusz jest hipotetyczny — składa się z mechanizmów, które powtarzają się w publicznych opisach incydentów ransomware.

Komputer w księgowości otwiera załącznik. Kilkadziesiąt godzin później — po tym, jak z tej stacji zebrano poświadczenia i rozpoznano, co jeszcze jest z niej widoczne — zaszyfrowane są dokumenty lokalne, udziały na serwerze plików, baza magazynowa, obrazy maszyn wirtualnych i katalog na NAS-ie z nocnymi kopiami. Zabrakło miejsca, w którym ktokolwiek zapytałby, po co stacja księgowości łączy się z panelem hipernadzorcy.

Segmentacja nie zapobiega temu, że ktoś otworzy załącznik. Zmienia to, co dzieje się później. Wspólny przewodnik CISA, FBI, NSA i MS-ISAC #StopRansomware Guide opisuje jej rolę wprost: podział sieci ogranicza zasięg włamania i utrudnia ruch boczny. To realistyczny cel, a nie gwarancja. Oczekiwanym rezultatem poprawnej architektury jest ograniczenie zasięgu zdarzenia, zatrzymanie części ruchu bocznego i zwiększenie liczby punktów wykrycia; zamknięcie incydentu w jednej strefie bywa efektem, ale nie jest zapewnione. Ominąć ją potrafią błędna reguła, poświadczenia wspólne dla kilku stref, host podpięty do dwóch sieci naraz, tunel VPN, system zarządzający i dozwolony przepływ aplikacyjny.

Najważniejsze wnioski

• VLAN daje separację warstwy drugiej, a nie politykę bezpieczeństwa. O tym, czy host z jednego VLAN-u dosięgnie hosta w drugim, decyduje routing i filtrowanie w warstwie trzeciej.
• Granicą jest miejsce egzekwowania reguł — firewall albo lista kontroli dostępu w punkcie routingu, gdzie polityka jest wymuszana i rejestrowana.
• Reguły wynikają z macierzy przepływów, nie z rysunku VLAN-ów: kto inicjuje połączenie, do czego, po jakim protokole i na jakiej podstawie.
• Migracja idzie etapami, a kolejność wynika z ryzyka: inwentaryzacja, plan adresacji, pilotaż, obserwacja, przełączenie na odrzucanie domyślne — każdy etap z przygotowaną drogą powrotu.
• Obie strony polityki wymagają aktywnego testu: że wymagane połączenie działa i że niedozwolone jest blokowane — osobno dla IPv4 i IPv6.

Dlaczego płaska sieć zwiększa skalę incydentu

Ramka wychodzi ze stacji roboczej i trafia do serwera, bo oba porty należą do tej samej domeny rozgłoszeniowej. Firewall brzegowy tego nie zobaczy, bo ruch nie przekracza brzegu. Konsekwencje widać w trzech miejscach.

Błąd konfiguracyjny rozlewa się na całość. Serwer DHCP podłączony „na chwilę” rozdaje adresy w całej firmie, a urządzenie rozgłaszające Router Advertisement zmienia bramę domyślną hostom, których nikt nie konfigurował pod IPv6. Wielkość domeny rozgłoszeniowej jest wielkością obszaru awarii.

Osiągalność sieciowa nie daje uprawnień, ale otwiera drogę do ich zdobycia. To, że panel zarządzania hipernadzorcą odpowiada na pakiety ze stacji działu handlowego, samo w sobie nikomu niczego nie przyznaje — do zalogowania potrzebne są prawidłowe albo przejęte poświadczenia, przechwycona sesja lub podatność w usłudze. Płaska sieć przesądza o czym innym: o tym, że atakujący z przejętej stacji w ogóle dosięgnie panelu. Segmentacja usuwa tę zbędną ścieżkę i zawęża zbiór systemów widocznych z pojedynczej stacji, ale nie zastępuje uwierzytelniania wieloskładnikowego, oddzielnych kont administracyjnych ani poprawnej autoryzacji po stronie usługi.

Ransomware korzysta z tych samych ścieżek co administrator. Techniki ruchu bocznego opisane w bazie MITRE ATT&CK jako taktyka Lateral Movement często wykorzystują legalne narzędzia administracyjne: zdalne usługi (RDP, SMB, SSH, WinRM), systemy dystrybucji oprogramowania i współdzielone zasoby. Sama definicja taktyki mówi jednak, że atakujący instalują też własne narzędzia zdalnego dostępu, a katalog obejmuje wykorzystanie podatności usług zdalnych, skradziony materiał uwierzytelniający (skrót hasła, bilet Kerberos, token sesji), przenoszenie narzędzi między hostami, przejmowanie sesji i nośniki wymienne; osobno dochodzi tunelowanie ruchu, które ATT&CK klasyfikuje w taktyce sterowania. Do tego dokładają się błędy konfiguracyjne — we wspólnym opracowaniu NSA i CISA dziesięciu najczęstszych błędów konfiguracyjnych brak segmentacji jest czwartym punktem listy.

Zostaje pytanie, gdzie płynie ruch. Ruch north-south przechodzi przez brzeg sieci i firmy zajmują się nim od dawna, bo widać go na firewallu — to temat powierzchni ataku widocznej z Internetu. Ruch east-west płynie wewnątrz środowiska: stacja do serwera plików, serwer aplikacyjny do bazy, konsola do hipernadzorcy. W płaskiej sieci nie przechodzi przez centralną granicę międzystrefową, bo takiej granicy nie ma.

Nie znaczy to, że jest wtedy nieograniczony i niewidoczny: zawężać go mogą zapory na hostach, listy kontroli dostępu przełącznika i mechanizmy kontroli dostępu do sieci, a rejestrować EDR, sondy NDR, dane o przepływach i logi hostowe — każde we własnym miejscu i zakresie. Sensem segmentacji jest przeniesienie istotnych przepływów do wspólnych punktów, w których polityka jest egzekwowana i widoczna. Publikacja NIST SP 800-215 zwraca uwagę, że rozwiązania perymetryczne koncentrują się na ruchu north-south, przez co komunikacja między serwerami pozostaje w dużej mierze niewidoczna, a kontrola SC-7 „Boundary Protection” z katalogu NIST SP 800-53 Rev. 5 wymaga monitorowania nie tylko zewnętrznych interfejsów systemu, ale i kluczowych interfejsów wewnętrznych.

Podsieć, VLAN, strefa i mikrosegmentacja

Rozmowy o segmentacji rozjeżdżają się zwykle dlatego, że każdy używa innego słowa na inny poziom problemu.

Podsieć IP

Podsieć to zakres adresacji warstwy trzeciej, na przykład 10.20.30.0/24 — sama w sobie nie jest mechanizmem bezpieczeństwa, bo dwie podsieci obsługiwane przez ten sam router bez filtrowania rozmawiają swobodnie. Adresacja prywatna z RFC 1918 i adresy lokalne IPv6 z RFC 4193 porządkują numerację, ale nie ograniczają ruchu.

VLAN

VLAN to podział fizycznej infrastruktury przełączników na wiele niezależnych domen rozgłoszeniowych, zdefiniowany w standardzie IEEE 802.1Q. Identyfikator VLAN zajmuje w znaczniku 12 bitów, więc opisuje wartości od 0 do 4095, ale skrajne są zarezerwowane: 0 oznacza ramkę znakowaną wyłącznie priorytetem, 4095 jest zastrzeżone dla implementacji. Do przypisania zostaje zakres 1–4094 i nie każdy numer jest w nim operacyjnie neutralny.

VLAN 1 jest na wielu platformach wartością domyślną i dlatego wymaga świadomej konfiguracji. Szczegóły dotyczące VLAN-u natywnego, dopuszczonych VLAN-ów oraz ruchu protokołów kontrolnych zależą od producenta, modelu i wersji oprogramowania. Nie należy przypisywać zachowania konkretnej platformy samemu standardowi IEEE 802.1Q — opisuje on format znacznika i zasady przekazywania ramek, a nie to, który numer urządzenie wybierze bez konfiguracji. Przykładowo w dokumentacji trunków VLAN dla przełączników Cisco Catalyst 9300 (IOS XE 17.16.x) VLAN 1 jest domyślnym VLAN-em wszystkich portów trunkowych i domyślnym VLAN-em natywnym, w którym port przekazuje ruch nieznakowany, a wyłączenie go z konkretnego łącza — razem z komunikatami drzewa opinającego — wymaga osobnej funkcji ograniczania VLAN-u 1. To jest opis jednej rodziny urządzeń, a nie reguła obowiązująca każdego producenta: na innej platformie domyślne wartości i zestaw protokołów kontrolnych mogą być inne, więc przed zmianą trzeba sprawdzić dokumentację użytego sprzętu i wersji. Wniosek praktyczny pozostaje niezależny od platformy: numer 1 wymaga świadomej decyzji konfiguracyjnej, a nie pozostawienia wartości domyślnej — dotyczy to zarówno stacji, jak i płaszczyzny zarządzania.

Poprawnie skonfigurowany VLAN daje rzeczywistą separację w warstwie drugiej: ramka znakowana jednym identyfikatorem nie trafia na porty przypisane do innego. Nie rozstrzyga natomiast, czy host z jednego segmentu nawiąże połączenie z hostem w drugim — to wymaga routingu, a o dopuszczeniu decyduje filtrowanie w warstwie trzeciej. Bez filtra podział zmniejsza domeny rozgłoszeniowe, ale nie wprowadza kontroli dostępu.

Strefa bezpieczeństwa

Strefa to pojęcie z poziomu polityki, nie konfiguracji. Grupuje systemy o zbliżonym profilu zaufania, funkcji i wymaganiach, a komunikacja między strefami idzie wyłącznie przez kontrolowane przejścia. VLAN jest jednym ze sposobów realizacji strefy, ale strefa może obejmować kilka VLAN-ów, a przy wysokiej krytyczności — osobną infrastrukturę fizyczną. Przewodnik NIST SP 800-82r3 dla technologii operacyjnej wskazuje, że pogrupowanie elementów w strefy poprzedza wdrożenie urządzeń izolujących: najpierw model, potem konfiguracja.

Wymóg dotyczy granicy, nie urządzenia: każda granica komunikacyjna ma podlegać jawnej, obserwowalnej polityce. Nie oznacza to ani osobnego firewalla dla każdej strefy, ani jednego fizycznego węzła wyjścia dla całej sieci. Politykę można egzekwować centralnie na firewallu, rozłożyć na kilka firewalli, oprzeć na przełącznikach warstwy trzeciej, na zaporach hostowych, na mechanizmach hipernadzorcy, na security groups w chmurze albo na politykach sieciowych platformy kontenerowej. Warunkiem jest to, żeby każda granica miała kontrolowany punkt lub punkty egzekwowania polityki, w których reguła jest wymuszana i rejestrowana — jedno urządzenie albo klaster obsługuje przy tym wiele granic naraz, tak samo jak listy kontroli dostępu na wspólnym przełączniku warstwy trzeciej.

Lista kontroli dostępu i firewall stanowy

Lista kontroli dostępu na routerze lub przełączniku warstwy trzeciej ocenia pakiety według adresów, protokołów i portów. Jest tania, szybka i zwykle bezstanowa: każdy pakiet oceniany jest niezależnie, więc w typowej ścisłej polityce administrator musi jawnie uwzględnić pakiety odpowiedzi. Jak dokładnie — zależy od kierunku, w którym lista jest przypięta do interfejsu, od platformy, od protokołu i od mechanizmów producenta; czasem jest to reguła dopuszczająca porty efemeryczne klienta, a czasem uproszczone sprawdzanie bitów nagłówka TCP oznaczane słowem established. To drugie nie jest pełnym śledzeniem stanu sesji, tylko oceną pojedynczego pakietu. Firewall stanowy śledzi sesje i sam wiąże odpowiedzi z połączeniem, co upraszcza jednokierunkową politykę inicjowania sesji, w której strefa A inicjuje połączenia do B, a B nie inicjuje ich do A.

Mikrosegmentacja

Mikrosegmentacja nie schodzi „poniżej sieci” — pozostaje kontrolą komunikacji sieciowej, tylko prowadzoną z większą szczegółowością niż podział na duże VLAN-y i podsieci. NIST SP 800-215 definiuje ją jako praktykę dzielenia sieci wewnętrznej na izolowane segmenty tak, aby ruch wchodzący i wychodzący z każdego z nich był kontrolowany i monitorowany, a celem jest ograniczenie eskalacji ataku.

Warto tu rozdzielić dwie rzeczy. Tożsamość — użytkownika, urządzenia albo usługi — jest atrybutem polityki: wchodzi do decyzji o dostępie razem ze stanem urządzenia i kontekstem. Punkt egzekwowania polityki to mechanizm, który tę decyzję wykonuje: firewall, agent hostowy, brama, proxy albo reverse proxy, sidecar, kontrola w hipernadzorcy, polityka sieciowa platformy kontenerowej — dzięki czemu regułę można związać z pojedynczym obciążeniem, kontenerem albo aplikacją, a nie z adresem. Ta sama publikacja wymienia trzy drogi realizacji: firewalle wirtualne w hipernadzorcy, agentów korzystających z zapór na hostach i polityki oparte na kryptograficznej tożsamości usług. Klasycznych stref, firewalli ani segmentacji warstwy trzeciej to nie znosi — dokłada się do nich.

Dlaczego sam podział na VLAN-y nie wystarcza

To częste nieporozumienie w projektach segmentacji. Firma dzieli sieć na osiem VLAN-ów, konfiguruje routing na przełączniku rdzeniowym i uznaje temat za zamknięty. Efektem jest osiem mniejszych domen rozgłoszeniowych i ten sam zestaw dostępnych połączeń co wcześniej, bo na drodze nie stoi reguła filtrująca.

Przewodnik NSA Network Infrastructure Security Guide (wersja 1.2 z 2023 roku, mimo daty w adresie) formułuje to jednoznacznie: ograniczenia dostępu trzeba wymusić listami kontroli dostępu na routerach, przełącznikach lub firewallach — także na routerach rdzeniowych. Tak samo rozkłada akcenty opracowanie CISA, NSA, FBI i partnerów, Enhanced Visibility and Hardening Guidance for Communications Infrastructure z grudnia 2024: najpierw listy kontroli dostępu, inspekcja stanowa i konstrukcje DMZ, a dopiero potem VLAN-y jako dodatkowa separacja logiczna.

Poprawnie skonfigurowana granica VLAN nie jest przy tym „przechodzona” sama z siebie — znane ataki wymagają konkretnego błędu konfiguracyjnego. Pierwszy to podszycie się pod przełącznik: jeżeli port dostępowy potrafi wynegocjować tryb trunku, podłączone urządzenie może tę negocjację wymusić i odbierać ruch wielu VLAN-ów, dlatego NSA zaleca wyłączenie negocjacji dynamicznej. Drugi to podwójne znakowanie ramki, w którym przełącznik zdejmuje tylko zewnętrzny znacznik 802.1Q; wymagania DISA z biblioteki STIG wskazują jego warunki — port atakującego w nietagowanym VLAN-ie trunku i znany adres MAC ofiary. Ruch jest jednokierunkowy, więc to ślepe wstrzyknięcie ramki, a nie podsłuch; przeciwdziała mu nieużywany identyfikator VLAN dla ruchu nietagowanego.

Jak wyznaczyć i zaprojektować strefy

Częsty błąd projektowy to podział według geografii: VLAN dla pierwszego piętra, VLAN dla drugiego, VLAN dla serwerowni. Taki model odzwierciedla okablowanie, a nie ryzyko. Lepszy opiera się na trzech kryteriach naraz.

Funkcja. Co robi ten system? Stacja robocza, serwer aplikacyjny, baza danych, drukarka i kamera mają zupełnie inne profile komunikacji. Przewodnik NSA zaleca wzajemne izolowanie stacji roboczych, serwerów, drukarek i systemów telekomunikacyjnych, bo atakujący celują w systemy łatwiejsze do wykorzystania.

Profil zaufania. Ile organizacja wie o tym, kto i co znajduje się w tej strefie? Ocena wynika z tego, kto jest właścicielem urządzenia, czy jest ono zarządzane i aktualizowane oraz jakie kontrole dostępu obowiązują. Sieć gościnna, sprzęt prywatny i środowiska testowe mają inny profil niż serwery produkcyjne — ale sam fakt, że coś jest serwerem produkcyjnym, nie czyni go „zaufanym”.

Wymagane przepływy. Z czym ten system musi się komunikować, żeby działać? Jeśli dwie grupy mają identyczne wymagania i identyczny profil zaufania, rozdzielanie ich dokłada pracy bez korzyści. Każda strefa potrzebuje też właściciela zdolnego ocenić, czy przepływ jest uzasadniony — tak samo jak reguły i wyjątki.

Model oparty na funkcji rozjeżdża się z okablowaniem przy pierwszej przeprowadzce działu, więc od razu trzeba ustalić, jak urządzenie trafia na właściwy port: statyczną konfiguracją albo uwierzytelnianiem portu według IEEE 802.1X z dynamicznym przypisaniem VLAN-u. Dla sprzętu bez klienta 802.1X stosuje się dopuszczanie po adresie MAC — to jednak identyfikacja, a nie dowód tożsamości, bo adres MAC jest jawny i daje się podmienić. NSA zaznacza, że nie zastępuje ono kontroli dostępu do sieci.

Praktyczny model stref

Poniższy podział jest przykładową architekturą referencyjną dla środowisk od kilkudziesięciu do kilkuset urządzeń, a nie schematem do skopiowania. Kolumna z profilem zaufania opisuje relację strefy wobec sieci wewnętrznej w tym przykładzie: strefa zarządzająca i backupowa nie są „bezwarunkowo zaufane”, tylko mają najwyższą wartość dla atakującego i najwyższe wymagania ochronne.

Tabelę można przewijać w poziomie.

Cztery obszary z tej listy wymagają osobnego omówienia.

Sieć zarządzająca

Interfejsy zarządzania należą do najcenniejszych celów, bo ich przejęcie daje kontrolę nad wieloma systemami naraz: konsola hipernadzorcy otwiera dostęp do maszyn wirtualnych, a interfejs zarządzania serwerem fizycznym pozwala uruchomić system spoza dysku.

NSA poświęciła temu opracowanie Performing Out-of-Band Network Management: ruch zarządzający ma płynąć ścieżką odseparowaną od operacyjnej, a najmocniejszym wariantem jest fizycznie wydzielona infrastruktura. To samo mówią kontrole SC-2, SC-7(13), SC-7(15) i SC-37 z NIST SP 800-53 Rev. 5 oraz zabezpieczenie 12.8 z CIS Critical Security Controls v8.1. Komunikat NSA, CISA i FBI AA25-239A idzie dalej: usługi zarządzania mają trafić do dedykowanej sieci poza pasmem albo wydzielonej instancji routingu, a urządzenia bez list kontroli dostępu — do osobnego VLAN-u z listą na urządzeniu nadrzędnym. Segmentacja odpowiada za to, skąd można się połączyć; zarządzanie dostępami uprzywilejowanymi — kto i na jakich zasadach.

Sieć backupowa

Backup jest ostatnią linią odtworzenia i dlatego jest atakowany — #StopRansomware Guide mówi wprost, że atakujący szukają poświadczeń do systemów kopii zapasowych. Nie ma zalecenia normatywnego „umieść infrastrukturę backupu w wydzielonym segmencie”, jest natomiast mocna przesłanka: to ostrzeżenie i kontrola SC-7(13). Wynikają z niej trzy cele: ograniczenie kręgu hostów widzących repozytorium, osobne uwierzytelnianie i świadoma decyzja o kierunku inicjowania połączeń.

Warto przy tym rozdzielić pięć rzeczy zlewających się w jedno słowo „backup”: samą kopię danych, jej odporność na usunięcie, niezależność administracyjną od produkcji, niezmienność zapisu i potwierdzoną możliwość odtworzenia. Kopia, którą da się skasować kontem administratora domeny, uratuje po awarii dysku, ale nie daje separacji wystarczającej przy przejęciu domeny — potrzebne bywają niezmienność zapisu, oddzielna płaszczyzna tożsamości, kopia offline albo przerwa powietrzna. Zarządzanie repozytorium nie powinno być osiągalne ze zwykłej stacji administracyjnej bez dodatkowych kontroli; szerzej opisuje to materiał o odtwarzaniu po ransomware.

Urządzenia IoT, kamery i sieć gościnna

Problemem tej strefy rzadko jest całkowity brak możliwości utwardzenia — częściej ich nierówność. Część urządzeń przyjmuje aktualizacje oprogramowania układowego, pozwala zmienić poświadczenia i uwierzytelnia się przez 802.1X; kamera sprzed sześciu lat czy sterownik z wbudowanym hasłem nie dają żadnej z tych możliwości, a najsłabszy element wyznacza realny profil ryzyka strefy. NIST w SP 800-213 przedstawia segmentację wprost jako kontrolę kompensacyjną: zamiast rezygnować z urządzenia, można je logicznie oddzielić od reszty systemu. Niska odporność nie oznacza przy tym niskiej krytyczności — kamery i sterowniki automatyki bywają elementem bezpieczeństwa fizycznego albo ciągłości produkcji.

Dla sieci gościnnej zasada z publikacji NIST SP 800-153 pozostaje aktualna mimo wieku dokumentu: osobne sieci dla profili o różnym poziomie bezpieczeństwa i ruch gości nieprzechodzący przez sieci wewnętrzne. Warto też sprawdzić, czy kontroler blokuje komunikację między klientami tego samego SSID — ustawienie zależy od producenta i wersji.

DMZ, środowiska testowe i dostęp dostawców

DMZ to bufor między Internetem a siecią wewnętrzną, a nie grupa „serwerów wystawionych na świat”. Definiują ją trzy osobne polityki: dla ruchu z Internetu do publikowanych usług, dla ruchu wychodzącego z DMZ i dla połączeń z DMZ do środowiska wewnętrznego. Publikacja usługi nie oznacza swobody w pozostałych kierunkach — przepływy do backendów są normalne, jeżeli każdy ma opisane źródło, cel, port i protokół.

Środowiska testowe łączą słabszy reżim zmian z wysoką wartością danych, więc domyślnie ruch z testów do produkcji nie jest dopuszczony. Nie każdy proces łączący oba światy musi być jednak technicznie niemożliwy: publikacja artefaktów czy kontrolowane wdrożenie mogą istnieć, jeżeli są jednokierunkowe i przechodzą przez wyznaczony punkt.

Dostęp dostawców ma być terminowany albo kontrolowany w dedykowanym punkcie, a nie wpuszczany wprost do sieci użytkowników. Osobna strefa tranzytowa jest dobrym modelem, lecz nie jedynym możliwym — tę samą rolę pełni brama ZTNA, system zarządzania dostępem uprzywilejowanym, host przesiadkowy albo broker dostępu. Niezależnie od wariantu obowiązują te same warunki: najmniejszy uzasadniony zbiór hostów i portów, czas obowiązywania, numer zgłoszenia, uwierzytelnianie wieloskładnikowe, rejestrowanie sesji w zakresie możliwym dla użytego narzędzia i wyłączenie dostępu po pracach.

Macierz przepływów i reguły firewalla

Projekt segmentacji to nie rysunek VLAN-ów, tylko tabela odpowiadająca na pytanie: kto może zainicjować połączenie, do czego i po jakim protokole. Czego w niej nie ma, jest domyślnie odrzucane.

Tabelę można przewijać w poziomie.

Dwa wiersze łatwo skopiować bez sprawdzenia własnej architektury, a w obu kierunek zależy od narzędzia. Monitoring i logi: w modelu push host wypycha dane do kolektora (syslog, agent aktywny, metryki), w modelu pull system centralny odpytuje hosty (SNMP, agent pasywny, API, sondy), a wiele środowisk łączy oba. Backup: model inicjowany centralnie to jeden z wariantów, obok agenta wypychającego dane, snapshotów z warstwy wirtualizacji i kopii przez serwer pośredniczący. Kierunek trzeba wziąć z własnej architektury, a nie z gotowego wzorca.

Wiersz z bazami danych opisuje ten sam przykładowy model, a nie regułę bez wyjątków. Baza potrafi inicjować połączenia w drugą stronę: powiadomienia i wywołania zwrotne, replikacja, usługi połączone, zadania administracyjne. Każdy taki przepływ ma być osobno udokumentowany — ze źródłem, celem, portem, uzasadnieniem i właścicielem.

Rejestrowanie dostępu też nie jest jedną wartością: co innego logowanie uwierzytelnienia i zapis rozpoczęcia oraz zakończenia połączenia, co innego rejestrowanie poleceń, nagranie terminala lub pulpitu i logi aplikacyjne. Pełne nagranie sesji ma sens tam, gdzie pozwala na to narzędzie, uzasadnia je ryzyko i dopuszcza prawo oraz polityka firmy; wymaganie go od każdego protokołu kończy się zapisem, którego nikt nie prowadzi.

Domyślną odpowiedzią firewalla ma być odrzucenie, a dostęp ma powstawać jako świadomy wyjątek. Zasadę tę opisuje publikacja NIST SP 800-41 Rev. 1: firewalle powinny blokować cały ruch niedopuszczony jawnie przez politykę, choć dokument nie wymaga symetrycznego rygoru dla ruchu wychodzącego. W katalogu kontroli występuje jako SC-7(5) „Deny by Default — Allow by Exception”, a uzupełnia ją AC-4 „Information Flow Enforcement”.

Lista kontrolna przeglądu reguł z NIST SP 800-115 każe wskazywać wyłącznie wymagane adresy i porty. To zalecenie kierunku, a nie zakaz stosowania podsieci: reguła obejmująca poprawnie zdefiniowaną strefę nie jest błędem, jeżeli odpowiada zakresowi przepływu. Ta sama lista wymaga sprawdzania, czy każda reguła jest nadal potrzebna i czy szczegółowe wyprzedzają ogólne.

Zależności wspólne po podziale sieci

To jedna z częstych przyczyn nieudanych wdrożeń: segmentacja poprawna z punktu widzenia bezpieczeństwa bywa nieprzejezdna dla usług, które działały w jednej sieci.

DNS, DHCP i NTP. Każda strefa potrzebuje zatwierdzonego sposobu rozwiązywania nazw i synchronizacji czasu. Nadmierne odchylenie zegara powoduje błędy uwierzytelniania Kerberos — protokół odrzuca wtedy wymianę komunikatem o zbyt dużym rozjeździe, a dopuszczalna tolerancja jest ustawieniem konfiguracyjnym (w domenie Windows domyślnie pięć minut), nie stałą. Niespójny czas utrudnia też korelację logów i analizę incydentu. Źródło czasu nie musi być tym samym centralnym serwerem dla wszystkich: DMZ, sieć gościnna i strefy izolowane mogą mieć dedykowane resolvery albo osobne źródło czasu, a goście zwykle nie mają powodu odpytywać wewnętrznego DNS organizacji.

DHCP jest trudniejszy, bo opiera się na rozgłoszeniach, które nie przechodzą przez router. Rozwiązaniem jest agent przekazujący opisany w RFC 2131: wpisuje własny adres w pole giaddr, a serwer odsyła odpowiedzi na port usługi serwerowej pod ten adres. Polityka musi więc dopuścić wymianę relay–serwer wraz z odpowiedziami. Firewall stanowy przepuści ruch powrotny na podstawie wpisu w tablicy stanu, choć dla UDP wpis opiera się wyłącznie na adresach i portach i wygasa po skonfigurowanym czasie — osobna reguła symetryczna bywa potrzebna zależnie od implementacji i miejsca egzekwowania polityki. Trzeba też przewidzieć odnowienie dzierżawy, w którym klient zwraca się do serwera z pominięciem przekaźnika. Funkcja relay bywa zbiorcza dla wielu usług UDP — zgodnie z dokumentacją obsługi rozgłoszeń IPv4 w Cisco IOS XE 17.x ip helper-address przekazuje domyślnie także DNS, TFTP, Time, TACACS i obie usługi NetBIOS, wyłączane przez no ip forward-protocol udp <port>. Lista zależy od platformy i wersji, więc przed zmianą trzeba sprawdzić aktywne wartości.

Uwierzytelnianie i katalog. Środowiska z Active Directory są tu najbardziej wymagające. Poza stałymi portami Kerberos, LDAP, DNS, SMB i katalogu globalnego usługi katalogowe korzystają z portów RPC przydzielanych dynamicznie: klient pyta mapera punktów końcowych na porcie TCP 135, a ten wskazuje port usługi. Zależności opisuje dokument Configure firewall for Active Directory domains and trusts — nie wszystkie porty z jego tabel są wymagane w każdym scenariuszu.

Zamiast otwierać cały zakres portów dynamicznych, ruch RPC kontrolera domeny można przypiąć do wskazanych numerów — ale jedna wartość nie zamyka tematu. Dokument Restrict Active Directory RPC traffic to a specific port opisuje dwa niezależne ustawienia rejestru: port usługi katalogowej NTDS i osobny port Netlogon, które muszą mieć różne numery. Microsoft odradza założenie, że klientom wystarczy sam Netlogon — korzystają też z interfejsów SamRPC i LSARPC oraz z replikacji katalogu. Port 135, Kerberos, LDAP, DNS i SMB nadal wymagają własnych reguł, a macierz ruchu klient–kontroler różni się od macierzy kontroler–kontroler.

To nie jest więc recepta „otwórz dwa porty”: zestaw zależy od scenariusza i wersji Windows Server, a bieżącą listę trzeba brać z opracowania Service overview and network port requirements for Windows. Zmianę trzeba przetestować w pełnym zakresie: replikacja, logowanie, zasady grupy i dostęp do plików SYSVOL.

Repozytoria aktualizacji. Serwer aktualizacji Windows nasłuchuje domyślnie na portach 8530 i 8531, a Microsoft w dokumentacji konfiguracji WSUS wskazuje, że firewall należy otworzyć na domeny usługi, a nie na zakresy adresów IP — te stale się zmieniają.

Tej architektury nie da się jednak przenieść wprost na świat Linuksa. Repozytoria dystrybucji bywają rozproszone po mirrorach i sieciach CDN, korzystają z przekierowań i wielu domen, więc sposób filtrowania zależy od dystrybucji i mirrora — inaczej w Debianie i Ubuntu, inaczej w Red Hat Enterprise Linux. Reguła oparta wyłącznie na adresach IP bywa nietrwała, a filtrowanie po nazwie w TLS ma własne ograniczenia. Najbardziej przewidywalną kontrolę daje wewnętrzny mirror albo cache pakietów: stacje mają wtedy jeden stały cel, a ruch do Internetu inicjuje pojedynczy system.

Monitoring, logowanie i backup. Kierunek inicjowania sesji trzeba ustalić przed migracją, bo pomyłka oznacza brak danych z całej strefy, a incydent w strefie bez logów staje się niewidoczny. Przed przełączeniem reguł należy więc zapewnić działający i zweryfikowany sposób odbierania logów z migrowanej strefy — model opisuje materiał o centralizacji logów. Jeżeli wyjątkowo nie da się tego zdążyć, ryzyko ma być zapisane jawnie, okno zmiany ograniczone, a obserwacja prowadzona zastępczo: logiem lokalnym z późniejszym zebraniem, danymi o przepływach albo licznikami trafień reguł.

ICMP i IPv6. Blokowanie całego ICMP jest klasycznym błędem, a dla IPv6 szczególnie groźnym, bo protokół pełni tam funkcje niezbędne do działania sieci. Rekomendacje z RFC 4890 wskazują, że ICMPv6 nie jest funkcją pomocniczą do odrzucenia — komunikat Packet Too Big jest niezbędny do wykrywania maksymalnej jednostki transmisji na ścieżce. Dokument RFC 7123 opisuje ryzyko samego IPv6: popularne systemy mają go włączonego domyślnie, więc nawet sieć uznawana za wyłącznie IPv4 jest na niego gotowa, a firewall dostrojony do IPv4 nie wyegzekwuje tej samej polityki.

Migracja płaskiej sieci etapami

Przebudowa adresacji i wprowadzenie reguł to zmiana o wysokim ryzyku — oceniać trzeba jednak dwa ryzyka: samej zmiany i pozostawienia stanu obecnego.

Etap pierwszy: inwentaryzacja i mapa przepływów. Zanim powstanie plan VLAN-ów, trzeba wiedzieć, co z czym rozmawia — z logów firewalla, danych o przepływach, list nasłuchujących portów i wiedzy właścicieli aplikacji. NIST SP 800-82r3 podpowiada, co zrobić, gdy nie wiadomo, jaki ruch jest niezbędny: tymczasowo dopuścić i rejestrować komunikację między segmentami, żeby udokumentować przepływy autoryzowane i ujawnić nieznane. Nie jest to jednak zgoda na szeroką regułę „dopuść i loguj” na granicy niezaufanej — okno obserwacji ma być ograniczone czasowo i zawężone do wskazanych źródeł, celów i zakresów. Sama obserwacja pokazuje, że ruch występuje, a nie że jest uzasadniony biznesowo — ruch potrzebny trzeba aktywnie odróżnić od przypadkowego i od złośliwego.

Etap drugi: plan adresacji i numeracji. Nowy plan powinien być czytelny i mieć zapas: który zakres należy do jakiej strefy, jak numerowane są VLAN-y i gdzie kończy się przestrzeń na rozbudowę. Część producentów rezerwuje własne pule numerów, więc plan trzeba skonfrontować ze sprzętem.

Etap trzeci: szybkie ograniczenia o dużym wpływie. Zanim ruszy pełna przebudowa, warto wprowadzić kilka reguł prostych technicznie, a mocno zmniejszających zasięg incydentu: odcięcie sieci użytkowników od interfejsów zarządzania i repozytorium kopii oraz zablokowanie ruchu z sieci gościnnej do zasobów wewnętrznych. Odkładanie ich na koniec projektu samo niesie ryzyko.

Etap czwarty: pilotaż. Strefę pilotażową wybiera się na podstawie wpływu biznesowego, liczby zależności, okna serwisowego i możliwości wycofania zmiany — a nie założenia, że drukarki czy kamery są mniej istotne; kontrola dostępu i terminale produkcyjne potrafią być krytyczne. Pilotaż ma być odwracalny: jedna strefa, ustalony czas i kryteria wyjścia zapisane przed startem. Kryterium akceptacyjne to wynik testu, a nie cisza: wykonane testy pozytywne dla każdego przepływu z macierzy, wykonane testy negatywne dla przepływów zabronionych, poprawne pobranie adresu z DHCP, potwierdzone raportowanie monitoringu i odbiór logów ze strefy, wykonana i zweryfikowana kopia oraz brak potwierdzonych regresji. Brak zgłoszeń użytkowników jest przy tym pomocniczym sygnałem obserwacyjnym — nikt nie zgłosi usługi, z której akurat nie korzystał.

Etap piąty: okres obserwacji. Zanim reguła zacznie blokować, trzeba zobaczyć, co przez nią przechodzi — ale nie każdy firewall uruchomi regułę blokującą w trybie „tylko loguj”. Zależnie od produktu stosuje się politykę cieniową, wbudowany tryb monitorowania, tymczasową regułę dopuszczającą z rejestrowaniem trafień albo analizę przepływów. Obserwacja powinna objąć cykle, w których ruch faktycznie występuje: dzienny, tygodniowy i miesięczny, a także zamknięcie miesiąca i pełny backup; dwa tygodnie bywają wystarczające dla prostej strefy, ale nie są uniwersalnym minimum. Najwięcej niespodzianek dają drukarki i skanery, które potrafią wysyłać skany prosto na udział SMB stacji użytkownika.

Etap szósty: przełączenie na odrzucanie domyślne. Strefa po strefie, w oknie serwisowym, z kryterium wycofania zapisanym przed zmianą i osobą uprawnioną do takiej decyzji — na przykład: jeżeli w ciągu trzydziestu minut pojawi się zgłoszenie o usłudze krytycznej, którego nie da się rozwiązać regułą w pięć minut, wracamy do poprzedniej konfiguracji.

Etap siódmy: strefy o najwyższej wartości. Pełne wydzielenie sieci zarządzającej, repozytorium backupu i baz danych wymaga dojrzałego procesu zmiany, bo dotyka narzędzi używanych do naprawiania problemów — łatwo odciąć sobie drogę powrotu. Ograniczenia z etapu trzeciego chronią te zasoby od początku.

Przez cały proces obowiązuje jedna zasada praktyczna: planowana zmiana ma mieć przygotowaną wcześniej drogę powrotu — zapisaną konfigurację sprzed zmiany i procedurę odzyskania kontroli, gdyby sieć produkcyjna przestała odpowiadać. Najlepiej działa dostęp poza pasmem, ale nie każde urządzenie ma port konsolowy; wtedy trzeba wskazać realistyczne wyjście: dostęp lokalny na miejscu, urządzenie zapasowe, konfigurację startową, do której sprzęt wróci po restarcie, albo ręczne odtworzenie z kopii.

Testowanie, monitoring i dokumentacja granic

Segmentacja, której nikt nie sprawdził, jest założeniem, a nie kontrolą. Testować trzeba obie strony polityki; zgłoszenie użytkownika nie jest testem akceptacyjnym. Lista kontrolna po każdej zmianie topologii obejmuje co najmniej:

• test pozytywny — każde połączenie wymagane przez macierz przepływów faktycznie działa,
• test negatywny — próba dosięgnięcia z każdej strefy zasobów, do których dostępu być nie powinno,
• test ruchu powrotnego — odpowiedzi wracają w ramach sesji, a strona docelowa nie inicjuje połączenia zwrotnego,
• test dla IPv4 i IPv6 osobno — luka w regule dopiętej wyłącznie dla jednego protokołu wychodzi dopiero przy sprawdzeniu obu,
• test usług wspólnych — nazwy, czas, uwierzytelnianie, logi i metryki oraz wykonanie kopii zapasowej,
• test po restarcie usług — część aplikacji negocjuje porty przy starcie,
• potwierdzenie w logach punktu egzekwowania — ruch dozwolony ma trafienie na właściwej regule, a zabroniony wpis o odrzuceniu.

Test negatywny jest ingerencją w produkcję, więc musi być autoryzowany, ograniczony zakresem adresów i portów, uzgodniony z właścicielem systemu docelowego i prowadzony z szybkością dobraną do wrażliwości urządzeń. Warto rozróżnić cztery poziomy: sprawdzenie pojedynczego połączenia do portu, skan ograniczonego zakresu, pełny test penetracyjny i pasywną analizę ruchu. Sieci technologii operacyjnej, urządzenia IoT, sprzęt medyczny i starsze appliance potrafią zawiesić się po zwykłym skanie portów, więc agresywne skanowanie wszystkich stref bez analizy wpływu bywa źródłem awarii, a nie dowodem skuteczności polityki.

Standard PCI DSS v4.0.1 formułuje wymóg cykliczny w punkcie 11.4.5: jeżeli segmentacja izoluje środowisko danych kart od innych sieci, testy penetracyjne jej mechanizmów wykonuje się co najmniej raz na dwanaście miesięcy oraz po każdej ich zmianie. Wymaganie 11.4.6 obowiązuje dostawców usług dodatkowo, obok 11.4.5, i skraca ich cykl do sześciu miesięcy. Oba są warunkowe — uruchamia je dopiero użycie segmentacji do izolacji tego środowiska, więc dotyczą firm przetwarzających dane kart, a nie każdego, kto dzieli sieć na strefy. Samej segmentacji standard nie nakazuje: nazywa ją metodą spoza listy wymagań, choć mocno zalecaną, bo zmniejsza zakres oceny; bez niej w zakresie jest cała sieć.

Granica bez obserwacji daje ochronę, ale nie daje wiedzy: pojawia się nowa klasa sygnałów — próby ruchu, które wcześniej po prostu się udawały. Podstawą są dane o przepływach z urządzeń brzegowych i międzystrefowych, czego wymaga zabezpieczenie 13.6 z CIS Controls v8.1. Kolektor logów w tej samej strefie i pod tą samą płaszczyzną administracyjną co monitorowane systemy zwiększa ryzyko, że przejęcie obejmie jednym ruchem także dowody; zmniejszają je osobne poświadczenia, własna retencja, niezmienność zapisu i ograniczony dostęp. Sama różnica VLAN-u nie chroni tu niczego. Co obserwować:

• nagły wzrost odrzuceń z jednej strefy w kierunku innej, zwłaszcza do zarządzania lub backupu,
• nowy host inicjujący ruch międzystrefowy, który wcześniej nie występował,
• próby połączeń do interfejsów zarządzania spoza strefy zarządzania oraz ruch z sieci gościnnej lub IoT do zasobów wewnętrznych,
• reguły z zerową liczbą trafień i wyjątki po dacie wygaśnięcia,
• zmiany w zestawie reguł bez powiązanego zgłoszenia.

Rejestrowanie każdego odrzuconego pakietu nie jest przy tym zaleceniem uniwersalnym: NIST SP 800-41 Rev. 1 zostawia tę decyzję środowisku, bo część administratorów świadomie nie rejestruje odrzuconego ruchu przychodzącego ze względu na wolumen skanów. Kompromisem są odrzucenia na granicach wewnętrznych, gdzie zapis jest zwykle bardziej zawężony i semantycznie wartościowy niż na styku z Internetem — objętość zależy jednak od architektury i miejsca, w którym stoi punkt kontroli. Sygnały nabierają wartości dopiero w tym samym procesie, co reszta zdarzeń operacyjnych — opisuje to materiał o łączeniu monitoringu, Wazuh i firewalla, a dostrajanie progów tekst o ograniczaniu szumu w monitoringu.

Druga połowa utrzymania to zapis. Rejestr powinien opisywać dla każdej strefy: numery VLAN i adresację, właściciela, dozwolone przepływy z uzasadnieniem i osobą zatwierdzającą, zależności od usług wspólnych z kierunkiem inicjowania sesji, wyjątki z datami wygaśnięcia i datę ostatniego testu — model opisuje materiał o CMDB i dokumentacji infrastruktury IT. Aktualne diagramy #StopRansomware Guide każe trzymać też w kopii offline, a zabezpieczenie 12.4 z CIS Controls v8.1 wymaga przeglądu raz w roku albo po istotnych zmianach.

Najczęstsze błędy w segmentacji

Poniższe wzorce spotyka się tam, gdzie podział sieci nie dał spodziewanego efektu. Kolejność nie jest rankingiem, a każdą pozycję da się wykryć przeglądem reguł albo testem.

• Reguła any-any między strefami wpisana „na czas wdrożenia” i zostawiona na lata.
• Routing między VLAN-ami bez filtrowania, w tym między interfejsami wirtualnymi przełącznika.
• Wspólna sieć użytkowników i zarządzania — przejęta stacja widzi konsole, IPMI i panele wirtualizacji.
• Dostęp stacji roboczych do repozytorium kopii, przez który ransomware szyfruje backup razem z produkcją.
• Brak polityki dla IPv6 — reguły dopięte wyłącznie dla IPv4 nie obejmują ruchu, który systemy i tak obsługują.
• Trunki dynamiczne oraz native VLAN używany przez hosty — warunki znanych ataków na granicę VLAN.
• Wyjątki bez właściciela i bez daty wygaśnięcia — dostęp na jedno zgłoszenie zostaje na stałe.
• Brak monitoringu odrzuceń oraz testów pozytywnych i negatywnych.
• Dokumentacja niezgodna z konfiguracją: diagram pokazuje strefy, których nie ma, albo reguły złagodzone przy awarii i nigdy nieprzywrócone.

VLAN i firewall czy mikrosegmentacja

W wielu środowiskach o stabilnej topologii i przewidywalnych przepływach klasyczny podział na strefy, połączony z kontrolą firewalla, daje odpowiedni poziom ograniczenia ruchu bez kosztu pełnej mikrosegmentacji. O tym, czy tak jest w konkretnej firmie, rozstrzygają: dynamika obciążeń, obecność kontenerów, liczba przepływów, stabilność adresacji, zdolność zespołu do utrzymywania polityk i wymagania regulacyjne. Im więcej z nich wskazuje na zmienność, tym słabszym identyfikatorem staje się adres IP.

NIST SP 800-215 nazywa to jedną z głównych trudności podejścia segmentowego: statyczne odwzorowanie aplikacji na adresy trzeba stale utrzymywać w zgodzie z rzeczywistością, w której lokalizacja aplikacji się zmienia. Publikacja NIST SP 800-207A wskazuje, że polityki oparte na adresach wymagają uzupełnienia o warstwę tożsamościową — ale formułuje też drugą stronę argumentu: polityk sieciowych nie da się dziś wyeliminować, a egzekwowanie oparte wyłącznie na tożsamości wymaga innych czynników, w tym lokalizacji sieciowej. Ostrzeżenie z NIST SP 800-207 „Zero Trust Architecture” jest praktyczne: część efektów da się osiągnąć firewallami bezstanowymi, ale koszt administracyjny czyni z tego słaby wybór.

Mikrosegmentacja nie zastępuje więc segmentacji sieciowej, tylko ją zagęszcza, a kolejność wdrożenia zależy od architektury. Program NIST NCCoE opisany w SP 1800-35 „Implementing a Zero Trust Architecture” prowadził budowy fazowo, realizując mikrosegmentację po kontrolach opartych na tożsamości — to jednak opis wdrożeń laboratoryjnych, a nie obowiązkowa sekwencja. Wydzielenie płaszczyzny zarządzającej często jest krokiem o wysokiej wartości i w wielu środowiskach opartych na maszynach wirtualnych szybko ogranicza dostęp do zasobów uprzywilejowanych. W środowisku cloud-native, gdzie większość komunikacji odbywa się między usługami w Kubernetesie, kontrola na poziomie obciążeń bywa pilniejsza niż osobny VLAN dla konsol.

Warto też pamiętać, czego segmentacja nie załatwia. Nie chroni przed samym wejściem: nie zastąpi aktualizacji, uwierzytelniania wieloskładnikowego, porządku w kontach uprzywilejowanych ani kopii zapasowych. #StopRansomware Guide zwraca uwagę, że może zostać unieważniona przez błąd użytkownika, a granica sieciowa nie kontroluje nośnika przenoszonego między strefami. To jedna z warstw, obok hardeningu serwerów i usług.

Zawęża natomiast jeden precyzyjnie określony obszar ryzyka: to, ile środowiska widzi atakujący, który przejął pojedynczy system — bez gwarancji, że zamknie go w jednej strefie. Priorytety są trzy: sieć zarządzająca i zasoby backupu poza zasięgiem zwykłej stacji roboczej, odrzucanie jako zachowanie domyślne oraz test potwierdzający, że to, co ma być zablokowane, faktycznie jest zablokowane.

Projekt segmentacji warto połączyć z audytem bezpieczeństwa środowiska IT, obserwacją granic w ramach monitoringu infrastruktury i bieżącym utrzymaniem w modelu administracji serwerami Linux — wtedy podział na strefy pozostaje działającym mechanizmem, a nie diagramem sprzed kilku wdrożeń.

Najczęstsze pytania

Czy segmentacja spowolni sieć?

Ruch, który wcześniej przechodził przez przełącznik warstwy drugiej, po podziale trafia do urządzenia warstwy trzeciej — przy routingu sprzętowym różnica jest zwykle pomijalna. Wąskim gardłem bywa firewall, jeżeli cały ruch międzystrefowy skieruje się przez urządzenie dobrane do przepustowości łącza internetowego, a nie do ruchu wewnętrznego.

Czy trzeba kupić nowy firewall?

Nie zawsze. Wiele środowisk zaczyna od list kontroli dostępu na przełączniku rdzeniowym dla najprostszych granic — sieć gościnna, drukarki, urządzenia techniczne — a po firewall stanowy sięga przy strefach wymagających kontroli sesji.

Ile stref powinna mieć firma na start?

Nie ma liczby docelowej. Dla małego środowiska punktem startowym bywa cztery lub pięć stref: użytkownicy, serwery, zarządzanie, goście i urządzenia niezarządzane. Kolejne — backup, bazy danych, DMZ, testy — dokłada się, gdy poprzednie działają i są udokumentowane. Model z dwudziestoma strefami, którego nikt nie utrzymuje, jest gorszy od czterech opisanych.

Jak często testować segmentację?

Po każdej zmianie topologii oraz cyklicznie. Firmy objęte PCI DSS i stosujące segmentację do izolacji środowiska danych kart mają na to termin: raz na dwanaście miesięcy dla podmiotów, a dla dostawców usług dodatkowo raz na sześć miesięcy — zawsze też po zmianie mechanizmów segmentacji. Poza tym reżimem przegląd kwartalny jest praktyczną rekomendacją, a nie obowiązkiem.

Od czego zacząć, jeżeli sieć jest płaska, a zasobów mało?

Od dwóch pierwszych działań o wysokiej wartości: odcięcia sieci użytkowników od interfejsów zarządzania i od repozytorium kopii zapasowych. Obie ograniczają szczególnie niebezpieczne ścieżki — do zasobów, których przejęcie daje kontrolę nad wieloma systemami naraz albo odbiera możliwość odtworzenia. Bez przebudowy adresacji da się to zrobić wtedy, gdy ruch już przechodzi przez kontrolowany punkt warstwy trzeciej albo gdy wystarczy polityka po stronie hostów. W części środowisk potrzebne będą jednak nowe VLAN-y, podsieci, trasy albo migracja adresów — rozstrzyga o tym aktualna topologia, a nie sama waga celu.

Źródła i standardy

Dokumenty wykorzystane przy przygotowaniu artykułu.

Standardy i architektura bezpieczeństwa

• NIST SP 800-215: Guide to a Secure Enterprise Network Landscape
• NIST SP 800-53 Rev. 5: katalog kontroli (SC-7)
• NIST SP 800-207: Zero Trust Architecture
• NIST SP 800-207A: dostęp oparty na tożsamości
• NIST SP 1800-35: Implementing a Zero Trust Architecture
• NIST SP 800-82r3: bezpieczeństwo technologii operacyjnej
• CIS Critical Security Controls v8.1

Konfiguracja sieci i urządzeń

• NSA: Network Infrastructure Security Guide 1.2
• NSA: Performing Out-of-Band Network Management
• DISA: biblioteka STIG
• IEEE 802.1Q: znakowanie VLAN
• IEEE 802.1X: uwierzytelnianie portu
• Cisco: trunki VLAN w Catalyst 9300, IOS XE 17.16.x
• Cisco: obsługa rozgłoszeń IPv4 w IOS XE 17.x
• RFC 1918: adresacja prywatna IPv4
• RFC 4193: unikatowe adresy lokalne IPv6
• RFC 2131: DHCP
• RFC 4890: filtrowanie ICMPv6
• RFC 7123: IPv6 w sieciach IPv4

Active Directory i usługi Microsoft

• Microsoft: firewall dla domen Active Directory
• Microsoft: ruch RPC Active Directory na wskazanym porcie
• Microsoft: wymagania portów sieciowych Windows
• Microsoft: konfiguracja WSUS

Reagowanie na incydenty, polityki firewalla i testowanie

• CISA, FBI, NSA i MS-ISAC: #StopRansomware Guide
• NSA i CISA: dziesięć najczęstszych błędów konfiguracyjnych (AA23-278A)
• CISA, NSA i FBI: hardening infrastruktury telekomunikacyjnej
• NSA, CISA i FBI: izolacja płaszczyzny zarządzania (AA25-239A)
• NIST SP 800-41 Rev. 1: polityki firewalla
• NIST SP 800-115: testowanie bezpieczeństwa
• MITRE ATT&CK: taktyka Lateral Movement (TA0008)

Wymagania branżowe i urządzenia specjalizowane

• PCI DSS v4.0.1: wymagania i procedury testowe (PCI Security Standards Council)
• PCI SSC: wytyczne dotyczące zakresu oceny i segmentacji
• NIST SP 800-213: bezpieczeństwo urządzeń IoT
• NIST SP 800-153: bezpieczeństwo sieci bezprzewodowych