Wnioski z praktyki

OPNsense w firmie: strefy sieciowe zamiast jednej dużej sieci

Stanowiska pracy, serwery, goście i urządzenia techniczne potrzebują różnych dostępów. Jak OPNsense przekłada ten podział na zrozumiałe reguły.

FirewallBezpieczeństwoStrategia i praktyka ITSzczegóły techniczne
Pomarańczowe i niebieskie kable krosowe łączą oddzielne grupy panelu sieciowego z przełącznikiem.

Drukarka, urządzenie gościa i serwer plików nie muszą korzystać z tych samych ścieżek sieciowych. Jasno określone strefy pozwalają opisać, kto potrzebuje danej usługi. OPNsense może kontrolować przejścia między nimi; sensowny podział zaczyna się od procesów pracy w firmie.

Od spisu urządzeń do dozwolonych przepływów danych

Dobrym początkiem jest niewielka macierz dostępów. Wskazuje strefę źródłową, potrzebną usługę, cel i uzasadnienie biznesowe. Stanowisko może potrzebować aplikacji firmowej na serwerze. Urządzenie gościa potrzebuje Internetu. Zarządzanie przełącznikiem powinno być dostępne wyłącznie przez wyznaczoną ścieżkę administracyjną.

Strefy są następnie wdrażane technicznie, na przykład za pomocą VLAN i odpowiednich portów przełącznika. Sama nazwa VLAN nie tworzy pełnej granicy ochrony. Ruch między sieciami musi rzeczywiście przechodzić przez kontrolowany punkt; sprawdza się też dodatkowe routery, przeoczone mosty Wi-Fi i podwójne połączenia sieciowe.

Reguły opisują konkretny cel

OPNsense korzysta ze stanowego filtra pakietów. Reguły rozpatruje się w powiązaniu z interfejsem, kierunkiem, kolejnością i istniejącymi stanami połączeń. Wielokrotnie używane aliasy mogą zwiększyć czytelność reguł, jeśli ich zawartość jest jednoznacznie nazwana i utrzymywana. Alias „Serwery” nie zastępuje jednak udokumentowanej definicji.

Przy zezwalaniu na dostęp należy możliwie precyzyjnie wskazać konkretne cele i potrzebne usługi. Początkowo szeroka reguła testowa otrzymuje osobę odpowiedzialną i termin zakończenia. W przeciwnym razie tymczasowa diagnostyka szybko zmienia się w trwały, nieprzejrzysty dostęp. Zmiany łatwiej ocenić, gdy uzasadnienie biznesowe pozostaje czytelne bezpośrednio w komentarzu reguły.

Zebrać wymagania dostępu; przypisać strefy; wdrożyć reguły; sprawdzić dozwolone i zablokowane dostępy.Zebrać wymagania dostępu; przypisać strefy; wdrożyć reguły; sprawdzić dozwolone i zablokowane dostępy.
Uproszczona kolejność kontroli; konkretny przebieg zależy od istniejącego środowiska.

Uwzględnić NAT, rozwiązywanie nazw i IPv6

Translacja adresów i reguły dostępu pełnią różne zadania. Publiczne przekierowanie wymaga odpowiedniego zezwolenia; zmieniony adres źródłowy nie wyjaśnia, czy aplikacja ma być dostępna. DNS, DHCP, usługi czasu i ścieżki powrotne również muszą po podziale na strefy nadal pasować do środowiska.

IPv6 jest sprawdzany wprost. Macierz dostępów przygotowana tylko dla IPv4 może pominąć drugą aktywną rodzinę protokołów. Własnych ścieżek testowych wymagają także interfejsy zarządzania, połączenia VPN i ruch wychodzący z samego firewalla. Reguły powinny odzwierciedlać rzeczywiście używane połączenia.

Mały pilotaż pokazuje zależności

Na pierwszy krok nadaje się niewielka grupa urządzeń ze znanym procesem pracy. Przed podziałem i po nim testuje się te same aplikacje. Protokół obejmuje też celowo odrzucone dostępy: goście nie docierają do interfejsu zarządzania, a urządzenie techniczne nie może swobodnie przechodzić do sieci serwerów.

DAXS łączy planowanie sieci z istniejącymi przełącznikami, Wi-Fi, usługami serwerowymi i bieżącą eksploatacją. Wynikiem jest łatwa w utrzymaniu macierz dostępów ze zrozumiałymi regułami. Odpowiednia liczba stref wynika z potrzeb ochrony, zarządzania urządzeniami i możliwości utrzymania; jak największa liczba VLAN nie jest samodzielnym celem jakościowym.

Infrastruktura i platformy · Umieścić techniczne środki ochrony we właściwym kontekście · Porozmawiajmy o projekcie sieci

Źródła: OPNsense: stanowe reguły firewalla (link zewnętrzny) · OPNsense: translacja adresów sieciowych (link zewnętrzny)