Bezpieczne Projektowanie Sieci

Bezpieczne projektowanie sieci

Bezpieczne projektowanie zaczyna się od wymagań bezpieczeństwa, oceny ryzyka i architektury systemu. Zabezpieczenia obejmują sieć, urządzenia, aplikacje, dane i procesy operacyjne. Wymagania dotyczą między innymi granic zaufania, kontroli dostępu, rejestrowania zdarzeń, odtwarzania oraz weryfikacji konfiguracji.

Bezpieczne projektowanie sieci obejmuje decyzje od architektury po konfigurację pojedynczego przełącznika. Zapora sieciowa jest jednym z elementów, lecz projekt obejmuje także strefy, tożsamość, aktualizacje, logi, urządzenia końcowe i procedury reagowania. NIST SP 800-160 Vol. 1 Rev. 1 opisuje te działania jako część inżynierii systemów godnych zaufania.

Przed wyborem technologii projekt opisuje aktywa, przepływy danych, zależności i granice zaufania. Analiza zagrożeń pomaga ustalić wymagania dla poufności, integralności i dostępności, a także kryteria akceptacji ryzyka. Wymagania powinny mieć właściciela oraz sposób sprawdzenia podczas wdrożenia i eksploatacji.

Obrona w głąb

Obrona w głąb (Defense-in-Depth) rozdziela funkcje ochronne między kilka kontroli. Pojedyncza kontrola może zawieść, zostać ominięta lub zawierać podatność, dlatego architektura powinna ograniczać skutki takiego zdarzenia i dostarczać sygnałów do wykrycia.

Warstwy mogą obejmować granicę sieci, zapory, segmentację, systemy wykrywania, ochronę hostów i ochronę danych. Każda warstwa ma określony zakres, właściciela oraz sposób testowania:

• Bezpieczeństwo obwodowe: Router graniczny i podstawowe listy kontroli dostępu ograniczają ruch przy granicy sieci zgodnie z regułami organizacji.
• Zapora sieciowa: Zapora filtruje ruch wchodzący i wychodzący według adresów, portów, protokołów, stanu połączenia lub innych cech obsługiwanych przez urządzenie.
• Segmentacja wewnętrzna: VLAN-y, podsieci i zapory ograniczają komunikację między strefami. Naruszenie jednej strefy nie powinno otwierać dostępu do pozostałych zasobów.
• IDS/IPS: Systemy wykrywania i zapobiegania włamaniom analizują ruch lub zdarzenia i mogą wygenerować alert albo zablokować działanie według skonfigurowanej reguły.
• Ochrona hostów i danych: Serwery i stacje robocze korzystają z zapór hostowych, ochrony punktów końcowych i zarządzania konfiguracją. Dane są klasyfikowane, szyfrowane zgodnie z wymaganiami i objęte kontrolą dostępu.

Obrona w głąb ogranicza ścieżki dostępu, zakres szkód i czas potrzebny do wykrycia zdarzenia. Skuteczność wynika z połączenia kontroli z monitorowaniem i procedurą reagowania.

Warstwy powinny mieć możliwie niezależne mechanizmy awarii i sygnały pozwalające ocenić ich działanie. Przeglądy reguł, testy odtwarzania, skany konfiguracji i ćwiczenia reagowania sprawdzają, czy założenia architektury odpowiadają rzeczywistym przepływom.

Zasady bezpiecznego projektowania

Projekt obejmuje zasady ograniczania uprawnień, ochrony w razie awarii, redukcji złożoności i oceny słabych punktów. NIST SP 800-160 Vol. 1 Rev. 1 wymienia między innymi least privilege, defense in depth, protective failure i reduced complexity.

Wymagania bezpieczeństwa powinny być powiązane z funkcjami systemu i scenariuszami zagrożeń. Dla każdego wymagania można określić kryterium akceptacji, dowód testu oraz właściciela ryzyka. Powiązanie wymagania z dowodem ułatwia przejście od analizy do konfiguracji, odbioru i późniejszej eksploatacji.

1. Zasada minimalnych uprawnień

Użytkownik, urządzenie lub aplikacja otrzymuje uprawnienia potrzebne do wykonania określonej funkcji. Pracownik działu kadr otrzymuje dostęp do systemów kadrowych, a repozytorium kodu pozostaje przypisane do zespołu inżynierii. Serwer WWW przyjmuje tylko połączenia wymagane przez aplikację. Ograniczenie zakresu uprawnień zmniejsza skutki przejęcia konta lub systemu.

2. Ocena wszystkich słabych punktów

Ocena ryzyka obejmuje technologię, ludzi i procesy. Przykładowy wydatek miliona złotych na zaawansowaną zaporę nie kompensuje braku szkoleń z rozpoznawania phishingu ani niezałatanej podatności publicznego serwera. Projekt powinien wskazywać słabe punkty, właścicieli kontroli, termin usunięcia i sposób weryfikacji.

3. Ochrona podczas awarii (protective failure)

Projekt określa zachowanie kontroli po utracie zasilania, łączności lub usługi zależności. Zasada protective failure ogranicza skutki awarii i zapobiega jej propagacji. Dla zapory chroniącej strefę wrażliwą stan domyślny może blokować ruch. System kontroli dostępu może wymagać potwierdzenia uprawnień z centralnej bazy przed udzieleniem dostępu. Wymagania dostępności i bezpieczeństwa należy rozstrzygnąć dla konkretnej usługi, udokumentować oraz przetestować.

Test awarii powinien sprawdzić wpływ na bezpieczeństwo i ciągłość działania. Wynik powinien wskazywać, które przepływy pozostają zablokowane, które funkcje przechodzą w tryb ograniczony oraz jak administrator przywraca usługę. Procedura powrotu do normalnego stanu wymaga kontroli uprawnień i rejestru zmian.

4. Redukcja złożoności

Złożona architektura zwiększa liczbę zależności, reguł i miejsc wymagających przeglądu. Niejasne reguły zapory oraz rozbudowany routing utrudniają audyt i sprzyjają błędom konfiguracji. Projekt powinien ograniczać liczbę funkcji, interfejsów i wyjątków do zakresu potrzebnego do realizacji wymagań biznesowych. Prostsza konfiguracja ułatwia testowanie i zmniejsza powierzchnię ataku.

Dokumentacja powinna przedstawiać zależności między komponentami, przepływy administracyjne i wymagane usługi wspólne. Każda granica zaufania wymaga opisanej kontroli, procedury testowej oraz planu odtworzenia po awarii.

Odbiór architektury obejmuje testy pozytywne i negatywne, przegląd uprawnień oraz sprawdzenie alertów. Wyniki stanowią punkt odniesienia dla późniejszych zmian i analizy incydentów.

Zmiana projektowa wymaga ponownej oceny zagrożeń, zależności i założeń odtwarzania. Przegląd rejestruje dotknięte kontrole i tymczasowe wyjątki, które wymagają właściciela oraz terminu wygaśnięcia. Obejmuje także usługi wspólne i ścieżki administracyjne systemu.

Strefy bezpieczeństwa w architekturze sieci

Strefa bezpieczeństwa to segment obejmujący zasoby o podobnych wymaganiach ochrony i sposobie dostępu. Ruch przepływający między strefami przechodzi przez punkt kontroli, na przykład zaporę lub router z ACL. Położenie urządzenia w strefie nie zastępuje uwierzytelnienia i autoryzacji użytkownika lub usługi.

Podział stref powinien wynikać z rzeczywistych przepływów, klasy danych i wymagań administracyjnych. Płaszczyzna zarządzania może wymagać osobnej strefy, ograniczonych adresów źródłowych, uwierzytelniania wieloskładnikowego i rejestrowania operacji administracyjnych.

Typowe strefy bezpieczeństwa

• Strefa zewnętrzna (Internet): Ruch z Internetu podlega regułom dostępu i nie otrzymuje zaufania wyłącznie na podstawie źródłowego adresu.
• Strefa zdemilitaryzowana (DMZ): Segment dla publicznie dostępnych usług, takich jak serwer WWW, poczta i DNS, oddzielony od pozostałych zasobów przez kontrole dostępu. Hosty w DMZ wymagają wzmocnienia, aktualizacji i monitorowania.
• Wewnętrzna strefa użytkownika (LAN): Segment obejmujący stacje robocze, drukarki i zasoby organizacji. Współczesny projekt dzieli go na mniejsze segmenty według funkcji, danych i wymagań dostępu.
• Strefa ograniczona lub wysokiego bezpieczeństwa: Segment dla krytycznych zasobów, takich jak bazy danych z danymi klientów, systemy finansowe i kontrolery domeny. Dostęp wymaga odrębnych reguł, monitorowania i przeglądu uprawnień.

Kontrola granic za pomocą zapory sieciowej

Zapora sieciowa kontroluje granice między strefami za pomocą Listy Kontroli Dostępu (ACL). Reguły powinny określać źródło, cel, usługę, port, kierunek, akcję i sposób rejestrowania decyzji.

Projekt może stosować zasadę domyślnego odrzucania: zezwalać jawnie na ruch wymagany przez usługę, rejestrować decyzje i utrzymywać blokadę dla pozostałych przepływów.

Uproszczony przykład ACL dla architektury strefowej może wyglądać następująco:

Reguły ACL powinny uwzględniać kolejność dopasowania, stan połączenia i ruch powrotny obsługiwany przez zaporę. Logowanie decyzji wymaga ustalenia poziomu szczegółowości, retencji i ochrony wpisów. Przegląd reguł usuwa wyjątki po zakończeniu uzasadniającej je usługi.

Kontrole warstwowe

Architektura strefowa łączy kontrole sieciowe, hostowe, aplikacyjne, danych oraz zarządzania. Każda kontrola ma określony zakres, właściciela i procedurę sprawdzenia.

• Kontrole warstwy sieciowej: Zapory, VLAN-y, mikrosegmentacja, Systemy Zapobiegania Włamaniom (IPS) i Kontrola Dostępu do Sieci (NAC) ograniczają przepływy oraz rejestrują decyzje. IPsec może chronić VPN, a TLS połączenia aplikacyjne. Szyfrowanie dobiera się do danych, trasy i wymagań ryzyka, obejmując ruch między strefami, gdy wymaga tego projekt.
• Kontrole warstwy hosta: Serwery i stacje robocze są regularnie aktualizowane, objęte ochroną EDR lub antywirusową oraz wyposażone w zapory hostowe ograniczające usługi nasłuchujące. Zarządzanie konfiguracją utrzymuje uzgodniony standard i rejestruje odstępstwa.
• Kontrole warstwy aplikacji: Zapory Aplikacji Internetowych (WAF) filtrują wybrane żądania, na przykład próby SQL injection i cross-site scripting. Proces wytwarzania obejmuje bezpieczne kodowanie, statyczną i dynamiczną analizę kodu oraz przeglądy bezpieczeństwa.
• Kontrole warstwy danych: Klasyfikacja wskazuje dane wymagające ochrony. Szyfrowanie danych w spoczynku obejmuje dyski i bazy danych zgodnie z wymaganiami kluczy i dostępu. Systemy Zapobiegania Utracie Danych (DLP) mogą monitorować oraz blokować przesyłanie danych przez pocztę, napędy USB i usługi chmurowe.
• Zarządzanie i monitorowanie: SIEM centralizuje logi i koreluje zdarzenia. Skanowanie podatności, audyty i testy penetracyjne dostarczają informacji o nowych słabościach oraz działaniu kontroli. Wyniki są przypisywane właścicielom i obsługiwane w procesie usuwania ryzyka.

Kontrole muszą współdziałać z procesem zarządzania podatnościami i zmianą konfiguracji. Każda zmiana reguły, wersji oprogramowania lub trasy powinna mieć właściciela, uzasadnienie i wynik weryfikacji, aby można było odtworzyć stan zabezpieczeń podczas audytu.