Koniec epoki otwartych portów. Jak architektura Zero Trust wspiera zgodność z NIS2 i DORA
Praktyczny przewodnik po segmentacji sieci, MFA, centralnym zarządzaniu tożsamością, reverse proxy i monitorowaniu incydentów.
Tradycyjny model cyberbezpieczeństwa opierał się na silnej granicy sieci i zaufaniu do użytkowników oraz urządzeń znajdujących się po jej wewnętrznej stronie. W środowisku pracy zdalnej, usług chmurowych, IoT i rozproszonych aplikacji takie podejście jest niewystarczające.
Czy środowisko realizuje podstawowe zasady Zero Trust?
Zaznacz istniejące mechanizmy. Brak zaznaczenia nie przesądza o naruszeniu prawa, ale wskazuje obszar do analizy ryzyka.
Czym jest architektura Zero Trust?
Zero Trust oznacza odejście od automatycznego zaufania wynikającego z samej lokalizacji użytkownika lub urządzenia. Połączenie z firmową siecią LAN, VPN albo Wi-Fi nie powinno samo w sobie otwierać dostępu do wszystkich zasobów.
Każda próba dostępu powinna zostać oceniona między innymi pod kątem tożsamości użytkownika, rodzaju urządzenia, sposobu uwierzytelnienia, lokalizacji, roli, wrażliwości zasobu oraz nietypowości zachowania.
Weryfikuj tożsamość
Dostęp powinien wynikać z wiarygodnego uwierzytelnienia, a nie z samego faktu obecności w sieci.
Minimalizuj uprawnienia
Użytkownik powinien posiadać wyłącznie dostęp potrzebny do wykonania konkretnego zadania.
Monitoruj zachowanie
Nietypowa lokalizacja, pora logowania albo seria błędnych prób powinna wywołać reakcję.
Dlaczego „zaufana” sieć LAN może być niebezpieczna?
Po przejęciu jednego komputera atakujący może próbować rozpoznać inne urządzenia, serwery plików, panele administracyjne, bazy danych i usługi działające na dostępnych portach. Jeżeli sieć jest płaska, pojedynczy incydent może objąć znaczną część infrastruktury.
Tak działa wiele ataków ransomware: najpierw dochodzi do przejęcia konta lub urządzenia, a następnie do przemieszczania się wewnątrz środowiska, podnoszenia uprawnień i infekowania kolejnych systemów.
Segmentacja sieci i VLAN-y: ograniczenie skutków włamania
Segmentacja polega na podzieleniu infrastruktury na odrębne strefy oraz domyślnym blokowaniu ruchu między nimi. Połączenia powinny być dopuszczane wyłącznie wtedy, gdy są rzeczywiście potrzebne.
Sieć pracowników
Komputery i urządzenia wykorzystywane do codziennej pracy.
Sieć serwerowa
Aplikacje, bazy danych, systemy dokumentowe i usługi wewnętrzne.
Sieć IoT
Urządzenia automatyki, bramki, czujniki i sprzęt o ograniczonym zaufaniu.
Sieć administracyjna
Panele hypervisorów, backupów, routerów i systemów zarządzania.
Przykładowo kamera może przesyłać obraz do rejestratora, ale nie musi łączyć się z komputerami pracowników. Panel Proxmox, system kopii zapasowych czy interfejs routera powinny być dostępne wyłącznie z sieci administracyjnej albo przez odpowiednio zabezpieczony VPN.
Zamknięte porty i jeden kontrolowany punkt wejścia
W środowiskach Docker częstym błędem jest publikowanie każdego portu aplikacji bezpośrednio na interfejsie hosta. Panel działa na porcie 8080, monitoring na 3000, baza na 5432, a interfejs administracyjny na kolejnym porcie.
Bezpieczniejszy model zakłada, że aplikacje działają w odizolowanych sieciach kontenerowych, a ich porty nie są bez potrzeby publikowane. Dostęp użytkowników odbywa się przez jeden kontrolowany punkt wejścia, którym może być reverse proxy, na przykład Traefik.
Pięć warstw dostępu w modelu Zero Trust
Wybierz warstwę, aby zobaczyć jej funkcję oraz ograniczenia.
Firewall i segmentacja
Ograniczają komunikację na poziomie sieciowym. Dopuszczają tylko wymagane kierunki ruchu i utrudniają przemieszczanie się atakującego między strefami.
Reverse proxy
Centralizuje publikację usług, TLS, nagłówki bezpieczeństwa, ograniczanie liczby żądań i integrację z systemem uwierzytelniania. Nie zastępuje firewalla.
Identity Provider i MFA
Weryfikuje tożsamość użytkownika, egzekwuje MFA i polityki dostępu oraz centralizuje cykl życia kont.
Autoryzacja w aplikacji
Aplikacja nadal powinna kontrolować role i dostęp do danych. Forward Auth nie zawsze zastępuje natywną autoryzację.
Logi, SIEM i wykrywanie incydentów
Zdarzenia powinny trafiać do centralnego systemu, który pozwala wykrywać anomalie, chronić integralność logów i tworzyć ślad audytowy.
Centralna tożsamość: Authentik jako warstwa IAM
Samo reverse proxy nie rozstrzyga, czy konkretny użytkownik powinien otrzymać dostęp do danej aplikacji. Potrzebny jest system zarządzania tożsamością i dostępem — IAM.
Rozwiązanie takie jak Authentik może centralizować konta, grupy, role, MFA, SSO, logi uwierzytelnienia oraz odbieranie dostępów po zakończeniu współpracy.
- Połączenie
Użytkownik rozpoczyna szyfrowane połączenie. - Proxy
Traefik rozpoznaje żądaną usługę. - Tożsamość
IdP weryfikuje konto i MFA. - Uprawnienie
Polityka sprawdza rolę i warunki. - Log
Zdarzenie trafia do monitoringu.
NIS2 i polska ustawa KSC: cyberbezpieczeństwo musi działać w praktyce
Dyrektywa NIS2 zobowiązuje podmioty kluczowe i ważne do stosowania odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych służących zarządzaniu ryzykiem dla bezpieczeństwa sieci i systemów informatycznych.
Zakres wymaganych działań obejmuje między innymi analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, zarządzanie podatnościami, kryptografię, kontrolę dostępu, zarządzanie aktywami oraz stosowanie MFA lub ciągłego uwierzytelniania tam, gdzie jest to właściwe.
| Wymaganie | Możliwy środek techniczny | Czego sam środek nie zapewnia |
|---|---|---|
| Kontrola dostępu | IAM, RBAC, grupy, polityki dostępu | Prawidłowego zdefiniowania ról i okresowych przeglądów |
| MFA | Klucz sprzętowy, TOTP, WebAuthn | Ochrony lokalnych kont i obejść technicznych |
| Segmentacja | VLAN, firewall, ACL | Poprawnego mapowania przepływów danych |
| Wykrywanie incydentów | SIEM, IDS/IPS, EDR, CrowdSec | Procedury reakcji i odpowiedzialności zespołu |
| Audit trail | Centralne logowanie i retencja | Integralności logów bez odpowiedniej ochrony |
Czy NIS2 zawsze nakazuje MFA?
Nie należy upraszczać regulacji do twierdzenia, że każda aplikacja bez wyjątku musi korzystać z MFA. Dobór zabezpieczeń powinien być proporcjonalny do ryzyka. W przypadku kont administratorów, zdalnego dostępu, poczty elektronicznej, systemów krytycznych i usług przetwarzających dane wrażliwe brak MFA może być jednak bardzo trudny do racjonalnego uzasadnienia.
DORA: kontrola dostępu, silne uwierzytelnianie i segmentacja
Rozporządzenie DORA obowiązuje od 17 stycznia 2025 r. i koncentruje się na cyfrowej odporności operacyjnej sektora finansowego oraz określonych relacjach z dostawcami usług ICT.
W praktyce szczególne znaczenie mają: ograniczenie logicznego i fizycznego dostępu do zasobów, stosowanie silnego uwierzytelniania, możliwość izolowania objętych incydentem elementów infrastruktury oraz ciągłe monitorowanie bezpieczeństwa systemów.
Audit trail, CrowdSec i aktywne wykrywanie incydentów
Centralizacja dostępu pozwala tworzyć spójny ślad audytowy: identyfikator użytkownika, datę, godzinę, adres IP, wynik logowania, zastosowanie MFA, próbę dostępu bez uprawnień i działania administracyjne.
Logi nie powinny jednak pozostawać wyłącznie w systemie, którego dotyczą. Po przejęciu serwera atakujący może próbować je usunąć lub zmodyfikować. Dlatego wartościowy audit trail wymaga centralnego gromadzenia, odpowiedniej retencji, synchronizacji czasu, ochrony integralności i kontroli dostępu.
CrowdSec
Analiza logów i blokowanie określonych wzorców ataku na podstawie scenariuszy.
SIEM
Korelacja zdarzeń z wielu systemów i centralne alertowanie.
EDR
Wykrywanie i ograniczanie zagrożeń na stacjach roboczych i serwerach.
IDS/IPS
Analiza ruchu sieciowego i identyfikowanie nietypowych wzorców komunikacji.
Jak chronić aplikacje legacy bez natywnego MFA?
Starsze aplikacje często nie obsługują OIDC, SAML ani nowoczesnego MFA. Warstwa reverse proxy i zewnętrzny system uwierzytelniania mogą ograniczyć ryzyko, ale nie powinny usprawiedliwiać bezterminowego utrzymywania krytycznie podatnego systemu.
Minimalny model ochrony systemu legacy
Środki kompensacyjne powinny tworzyć kilka niezależnych warstw.
- Izolacja w odrębnej strefie sieciowej
- Brak bezpośredniej publikacji portu
- Dostęp przez kontrolowaną bramę
- MFA przed aplikacją
- Ograniczenie źródeł połączeń
- Centralne logowanie i monitoring
- Aktualizacje lub wirtualne poprawki
- Plan migracji albo wycofania systemu
Czy Traefik, Authentik i CrowdSec zapewniają zgodność z NIS2 lub DORA?
Nie. Mogą być wartościowymi elementami architektury bezpieczeństwa, ale zgodność jest znacznie szerszym zagadnieniem.
Organizacja musi uwzględnić także analizę ryzyka, inwentaryzację aktywów, klasyfikację informacji, zarządzanie podatnościami, kopie zapasowe, odtwarzanie awaryjne, ciągłość działania, bezpieczeństwo dostawców, szkolenia, reagowanie na incydenty, testowanie skuteczności zabezpieczeń i dokumentowanie decyzji.
Checklista wdrożenia Zero Trust
Poniższe punkty mogą służyć jako początek przeglądu organizacyjnego i technicznego.
- Aktualna inwentaryzacja urządzeń, aplikacji i kont
- Opis przepływów danych i komunikacji między systemami
- Segmentacja sieci i domyślne blokowanie ruchu
- Oddzielna sieć administracyjna
- MFA dla kont uprzywilejowanych i dostępu zdalnego
- Centralny system IAM i polityki RBAC
- Procedura nadawania, zmiany i odbierania dostępów
- Centralne logowanie i retencja zdarzeń
- Monitoring podatności i aktualizacji
- Testy kopii zapasowych i odtwarzania
- Procedura reagowania na incydenty
- Okresowe testy skuteczności zabezpieczeń
Technologia i prawo muszą mówić jednym głosem
NIS2 i DORA nie nakazują korzystania z Traefika, Authentika, CrowdSec ani Dockera. Wymagają natomiast wdrożenia skutecznych i proporcjonalnych środków ochrony odpowiadających rozpoznanym zagrożeniom.
Najważniejsza zmiana nie polega na zamknięciu konkretnego portu. Polega na odejściu od przekonania, że użytkownikowi, urządzeniu albo aplikacji można ufać tylko dlatego, że znajdują się „wewnątrz” firmowej sieci.
Współczesne bezpieczeństwo zaczyna się od weryfikacji, minimalnych uprawnień, segmentacji i założenia, że incydent może wydarzyć się w każdej warstwie infrastruktury.
Treść ma charakter informacyjny i nie stanowi porady prawnej ani kompletnej instrukcji wdrożeniowej. Dobór środków technicznych i organizacyjnych wymaga indywidualnej analizy ryzyka, zakresu działalności oraz obowiązków konkretnego podmiotu.
Najczęstsze pytania
Czy NIS2 wymaga wdrożenia architektury Zero Trust?
Nie wprost. NIS2 nie narzuca konkretnej architektury ani producenta. Zero Trust może jednak stanowić skuteczny model realizacji części obowiązków dotyczących kontroli dostępu, uwierzytelniania, segmentacji i monitorowania.
Czy reverse proxy zastępuje firewall?
Nie. Reverse proxy kontroluje przede wszystkim ruch aplikacyjny, natomiast firewall filtruje połączenia sieciowe. Oba rozwiązania pełnią odmienne i uzupełniające się funkcje.
Czy aplikacje dostępne tylko w LAN są bezpieczne?
Nie zawsze. Po przejęciu komputera pracownika albo urządzenia IoT atakujący może uzyskać dostęp do usług osiągalnych z sieci lokalnej. Dlatego potrzebne są segmentacja, kontrola ruchu i ograniczanie uprawnień również wewnątrz LAN.
Czy Authentik może dodać MFA do starej aplikacji?
W wielu przypadkach może zapewnić dodatkową warstwę uwierzytelniania przed aplikacją. Nie naprawia jednak podatności samego systemu i nie zawsze zastępuje jego wewnętrzny mechanizm kontroli uprawnień.
Czy zamknięcie wszystkich portów jest zawsze właściwe?
Nie chodzi o literalne zamknięcie każdego portu, lecz o eliminację zbędnej ekspozycji. Usługi muszą komunikować się tam, gdzie jest to potrzebne, ale zakres połączeń powinien być minimalny, kontrolowany i udokumentowany.
Czy wdrożenie Traefika, Authentika i CrowdSec oznacza zgodność z DORA?
Nie. Są to wyłącznie narzędzia wspierające. DORA obejmuje również zarządzanie ryzykiem ICT, ciągłość działania, testowanie odporności, obsługę incydentów, zarządzanie dostawcami oraz odpowiednią dokumentację.
Potrzebujesz prawnej oceny wdrożenia NIS2, DORA lub polityk cyberbezpieczeństwa?
Analiza powinna obejmować dokumentację oraz sposób, w jaki deklarowane zabezpieczenia działają w rzeczywistej infrastrukturze organizacji.
