Wymagania techniczne NIS2 dla firm

Jakie zabezpieczenia trzeba wdrożyć?

NIS2 coraz częściej pojawia się w rozmowach o cyberbezpieczeństwie, audytach, odpowiedzialności zarządu i obowiązkach firm. Wiele organizacji zadaje bardzo konkretne pytanie: jakie zabezpieczenia techniczne trzeba wdrożyć, aby realnie przygotować się do nowych wymagań?

NIS2 nie jest listą produktów do kupienia ani gotową checklistą typu: firewall, backup, MFA i monitoring. Dyrektywa wskazuje kierunek – zarządzanie ryzykiem, ochronę systemów, ciągłość działania, wykrywanie incydentów i ograniczanie ich skutków. Konkretne środki techniczne powinny być natomiast dobrane do skali działalności firmy, rodzaju przetwarzanych danych, krytyczności systemów oraz potencjalnych konsekwencji awarii lub cyberataku.

Dla działów IT oznacza to konieczność spojrzenia na bezpieczeństwo nie przez pryzmat pojedynczych narzędzi, ale całej architektury ochrony. Liczy się zarządzanie tożsamością, bezpieczeństwo sieci, ochrona punktów końcowych, monitoring, backup odporny na ransomware, kontrola podatności, szyfrowanie danych oraz możliwość udokumentowania, że wdrożone mechanizmy rzeczywiście działają.

W tym artykule wyjaśniamy, jak rozumieć wymagania techniczne NIS2 dla firm, jakie obszary infrastruktury i cyberbezpieczeństwa warto uwzględnić oraz jak przełożyć ogólne wymagania regulacyjne na konkretne zabezpieczenia IT.

Czy NIS2 określa konkretne wymagania techniczne dla firm?

Jedno z najczęstszych pytań dotyczących NIS2 brzmi: czy dyrektywa wskazuje konkretne technologie i zabezpieczenia, które firma musi wdrożyć? NIS2 nie zawiera gotowej listy produktów ani obowiązkowego zestawu narzędzi bezpieczeństwa. Nie oznacza to jednak, że wymagania techniczne pozostają dowolne.

Organizacje objęte regulacją powinny stosować odpowiednie i proporcjonalne środki techniczne, operacyjne oraz organizacyjne służące zarządzaniu ryzykiem dla bezpieczeństwa sieci i systemów informatycznych. Ich zadaniem jest zarówno ograniczanie prawdopodobieństwa incydentów, jak i minimalizowanie ich wpływu na działalność firmy, odbiorców usług oraz inne podmioty.

NIS2 wskazuje przy tym konkretne obszary, które powinny zostać uwzględnione w zarządzaniu cyberbezpieczeństwem.

Należą do nich między innymi:

➡️ analiza ryzyka i polityki bezpieczeństwa systemów informatycznych,

➡️ obsługa incydentów,

➡️ ciągłość działania, backup i odtwarzanie po awarii,

➡️ bezpieczeństwo łańcucha dostaw,

➡️ bezpieczeństwo pozyskiwania, rozwoju i utrzymania systemów,

➡️ zarządzanie podatnościami,

➡️ ocena skuteczności stosowanych zabezpieczeń,

➡️ podstawowe praktyki cyberhigieny i szkolenia,

➡️ stosowanie kryptografii i szyfrowania,

➡️ bezpieczeństwo zasobów ludzkich oraz kontrola dostępu,

➡️ zarządzanie aktywami,

➡️ stosowanie uwierzytelniania wieloskładnikowego lub ciągłego tam, gdzie jest to uzasadnione.

Nie istnieje więc jeden uniwersalny „pakiet NIS2”, który można wdrożyć w każdej organizacji. Kluczowe znaczenie ma adekwatność zabezpieczeń do ryzyka. Firma powinna potrafić uzasadnić, dlaczego zastosowała określone mechanizmy ochronne, jakie zagrożenia mają one ograniczać oraz w jaki sposób oceniana jest ich skuteczność. Sama obecność firewalla, systemu antywirusowego czy backupu nie przesądza o właściwym poziomie bezpieczeństwa – znaczenie mają również konfiguracja, aktualność, monitoring i regularne testowanie.

Jak rozumieć „odpowiednie i proporcjonalne środki techniczne” w NIS2?

Proporcjonalność oznacza więc świadomy dobór środków odpowiadających na poziom ryzyka oraz możliwość uzasadnienia, dlaczego właśnie takie mechanizmy zostały zastosowane. Punktem wyjścia powinna być znajomość własnego środowiska i jego znaczenia dla działalności firmy.

Zarządzanie ryzykiem jako punkt wyjścia do wymagań technicznych

Dobór zabezpieczeń technicznych powinien zaczynać się od odpowiedzi na kilka podstawowych pytań: co firma musi chronić, przed jakimi zagrożeniami i jakie byłyby skutki utraty, przejęcia lub niedostępności danego zasobu?

Pierwszym krokiem jest identyfikacja systemów i usług kluczowych dla działalności organizacji. Mogą to być systemy ERP i CRM, środowiska produkcyjne, bazy danych, poczta elektroniczna, Microsoft 365, infrastruktura serwerowa, systemy magazynowe czy aplikacje branżowe. Trzeba przy tym rozumieć zależności pomiędzy nimi – awaria jednego serwera, łącza, systemu uwierzytelniania lub usługi chmurowej może zatrzymać kilka procesów biznesowych jednocześnie.

Następnie warto przeanalizować konkretne scenariusze ryzyka i przypisać do nich mechanizmy ochronne.

Przykładowo:

przejęcie konta	MFA, Conditional Access, monitoring logowań
rozprzestrzenianie się ransomware	segmentacja sieci, EDR/XDR, ograniczenie uprawnień
wykorzystanie znanych luk	Vulnerability Management i Patch Management
utrata danych	odseparowany i odporny na modyfikację backup
nadużycie kont administracyjnych	PAM i kontrola dostępu uprzywilejowanego
niewykryty incydent	centralizacja logów, SIEM, SOC lub MDR

Takie podejście pozwala uniknąć wdrażania przypadkowych narzędzi bez powiązania z rzeczywistym ryzykiem.

Bezpieczeństwo systemów informatycznych i sieci

Sieć firmowa jest jednym z podstawowych obszarów technicznych, które należy uwzględnić w kontekście NIS2. To przez nią komunikują się stacje robocze, serwery, systemy biznesowe, usługi chmurowe, urządzenia mobilne i infrastruktura IoT. Brak odpowiedniej kontroli ruchu może sprawić, że pojedynczy incydent szybko obejmie kolejne zasoby.

Jednym z najważniejszych mechanizmów ograniczania tego ryzyka jest segmentacja sieci. Zamiast utrzymywać wszystkie urządzenia w jednej, płaskiej strukturze, organizacja może rozdzielić środowisko na strefy odpowiadające różnym funkcjom i poziomom zaufania. Osobne segmenty mogą obejmować między innymi użytkowników, serwery, systemy administracyjne, urządzenia IoT, sieci gościnne, środowiska testowe czy infrastrukturę OT.

Sama segmentacja logiczna nie wystarczy jednak, jeśli ruch pomiędzy strefami pozostaje praktycznie nieograniczony. Potrzebne są odpowiednio zaprojektowane reguły komunikacji wykorzystujące między innymi VLAN, listy kontroli dostępu ACL oraz polityki firewall. Celem jest ograniczenie dostępu wyłącznie do usług i zasobów rzeczywiście potrzebnych użytkownikom oraz systemom.

Ma to szczególne znaczenie w przypadku ransomware i innych ataków wykorzystujących lateral movement, czyli przemieszczanie się napastnika pomiędzy kolejnymi urządzeniami po uzyskaniu pierwszego punktu dostępu. Jeśli przejęta stacja robocza może swobodnie komunikować się z serwerami, systemem backupu i urządzeniami administracyjnymi, skutki incydentu mogą być znacznie poważniejsze.

Istotną rolę odgrywają również rozwiązania klasy NGFW (Next-Generation Firewall), które poza podstawową kontrolą ruchu mogą zapewniać analizę aplikacji, mechanizmy IDS/IPS, filtrowanie treści, wykrywanie podejrzanej komunikacji oraz integrację z innymi warstwami ochrony.

W bardziej rozbudowanych środowiskach znaczenie zyskują systemy NAC (Network Access Control). Pozwalają one kontrolować, jakie urządzenia uzyskują dostęp do sieci i na jakich zasadach. Nieautoryzowany laptop, prywatne urządzenie lub sprzęt niespełniający wymagań bezpieczeństwa może zostać zablokowany albo skierowany do odseparowanej strefy.

Osobnym obszarem jest dostęp zdalny. Tradycyjny VPN nie powinien automatycznie oznaczać szerokiego dostępu do całej infrastruktury wewnętrznej. Coraz większe znaczenie mają mechanizmy MFA, dostęp oparty na rolach i kontekście użytkownika oraz rozwiązania ZTNA, które umożliwiają udostępnienie konkretnych aplikacji i zasobów bez otwierania pełnego dostępu do sieci.

W kontekście NIS2 bezpieczeństwo sieci powinno więc łączyć kontrolę dostępu, segmentację, ograniczanie komunikacji pomiędzy strefami oraz wykrywanie podejrzanej aktywności. Sam firewall na brzegu sieci nie zapewnia wystarczającej ochrony, jeśli wewnątrz środowiska brakuje podziału na strefy, aktualnych reguł bezpieczeństwa i kontroli nad dostępem do zasobów.

Zarządzanie podatnościami, aktualizacjami i cyklem życia urządzeń

Jednym z największych zagrożeń dla bezpieczeństwa infrastruktury IT są znane podatności, dla których istnieją już poprawki lub zalecenia producenta, ale które nadal pozostają niezaadresowane. Problem może dotyczyć nie tylko systemów operacyjnych i aplikacji, lecz także firewalli, przełączników, punktów dostępowych, hypervisorów, macierzy, systemów backupowych, urządzeń IoT oraz firmware’u.

Dlatego zarządzanie podatnościami nie powinno ograniczać się do okazjonalnego instalowania aktualizacji. To ciągły proces obejmujący identyfikację zasobów, wykrywanie luk, ocenę ich znaczenia, ustalanie priorytetów działań naprawczych oraz weryfikację, czy podatność została skutecznie usunięta lub ograniczona.

Vulnerability Management – wiedzieć, gdzie znajdują się luki

Rozwiązania klasy Vulnerability Management umożliwiają regularne skanowanie środowiska i identyfikowanie znanych podatności. Wyniki mogą być powiązane między innymi z identyfikatorami CVE, oceną CVSS, informacjami o dostępnych poprawkach oraz poziomem ekspozycji danego zasobu.

Sama liczba wykrytych luk nie powinna jednak decydować o kolejności działań. Podatność o wysokiej ocenie CVSS na odizolowanym systemie testowym może stanowić mniejsze zagrożenie niż luka o niższej punktacji występująca na publicznie dostępnej usłudze, krytycznym serwerze lub urządzeniu brzegowym.

Patch Management – aktualizacje jako kontrolowany proces

Kolejnym elementem jest Patch Management, czyli planowanie, testowanie, wdrażanie i kontrolowanie aktualizacji. Firma powinna wiedzieć nie tylko, czy aktualizacje są instalowane, ale również które systemy pozostają nieaktualne, z jakiego powodu i przez jaki czas.

Automatyzacja może znacząco usprawnić ten proces, szczególnie w środowiskach obejmujących dużą liczbę stacji roboczych i serwerów. Nie eliminuje jednak potrzeby kontroli. Aktualizacja krytycznego systemu biznesowego, hypervisora, macierzy czy urządzenia sieciowego może wymagać wcześniejszych testów, okna serwisowego, planu wycofania zmiany oraz weryfikacji kompatybilności.

EOL i EOS – gdy producent kończy wsparcie

Kontrola dostępu, MFA i zarządzanie tożsamością

Przejęcie legalnego konta użytkownika lub administratora jest jednym z najgroźniejszych scenariuszy ataku, ponieważ cyberprzestępca nie zawsze musi „włamywać się” do systemu w tradycyjnym znaczeniu. Może zalogować się przy użyciu prawidłowych danych uwierzytelniających zdobytych w wyniku phishingu, wycieku haseł, ataku typu credential stuffing, infekcji urządzenia lub przejęcia aktywnej sesji.

Dlatego w kontekście NIS2 zarządzanie dostępem powinno obejmować cały cykl życia tożsamości: od nadania uprawnień, przez ich modyfikację wraz ze zmianą stanowiska lub zakresu obowiązków, aż po szybkie odebranie dostępu po zakończeniu współpracy.

MFA jako podstawowa warstwa ochrony kont

Uwierzytelnianie wieloskładnikowe (MFA) znacząco ogranicza ryzyko wykorzystania przejętego hasła. Szczególnej ochrony wymagają konta administracyjne, dostęp zdalny, poczta elektroniczna, środowiska chmurowe, systemy backupowe oraz aplikacje zawierające dane krytyczne.

Nie każda metoda MFA zapewnia jednak taki sam poziom odporności. Dlatego w środowiskach o podwyższonym ryzyku coraz większe znaczenie mają mechanizmy odporne na phishing, takie jak klucze sprzętowe FIDO2, passkeys oraz uwierzytelnianie oparte na certyfikatach.

W środowiskach chmurowych MFA warto uzupełnić o Conditional Access, które uwzględnia kontekst dostępu – na przykład lokalizację użytkownika, stan urządzenia, poziom ryzyka logowania czy typ aplikacji.

Zasada najmniejszych uprawnień i dostęp oparty na rolach

Kolejnym fundamentem jest zasada najmniejszych uprawnień (Least Privilege). Użytkownik powinien posiadać wyłącznie taki poziom dostępu, jaki jest niezbędny do wykonywania obowiązków. Ogranicza to zarówno skutki błędów pracowników, jak i możliwości napastnika, który przejmie konto.

Pomocne jest stosowanie RBAC (Role-Based Access Control), czyli nadawania uprawnień na podstawie zdefiniowanych ról. Zamiast przydzielać dostęp indywidualnie i pozostawiać go bezterminowo, organizacja może powiązać uprawnienia z funkcją użytkownika, działem, projektem lub zakresem odpowiedzialności.

Istotne są również regularne przeglądy dostępów. Użytkownicy często gromadzą kolejne uprawnienia po zmianach stanowisk, udziałach w projektach lub czasowych zastępstwach. W efekcie zakres dostępu może stać się znacznie szerszy, niż wynika to z aktualnych potrzeb biznesowych.

Konta uprzywilejowane i PAM

W kontekście NIS2 zarządzanie tożsamością powinno odpowiadać na kilka podstawowych pytań: kto ma dostęp, do czego, na jakiej podstawie, przez jaki czas i czy organizacja potrafi wykryć nadużycie tych uprawnień? Samo posiadanie kont użytkowników w katalogu firmowym nie zapewnia odpowiedniego poziomu kontroli, jeśli brakuje MFA, regularnych przeglądów uprawnień i ochrony kont administracyjnych.

Wykrywanie incydentów: monitoring, logi, EDR/XDR i SIEM

Skuteczne zabezpieczenia nie eliminują ryzyka incydentu. Firewall może nie zablokować każdej próby ataku, użytkownik może uruchomić złośliwy załącznik, legalne konto może zostać przejęte, a nowa podatność wykorzystana przed wdrożeniem poprawki. Dlatego jednym z kluczowych elementów technicznej odporności organizacji jest zdolność do szybkiego wykrycia nieprawidłowości i rozpoczęcia reakcji.

W tym kontekście warto rozróżnić dwa uzupełniające się obszary: monitoring infrastruktury IT oraz monitoring bezpieczeństwa. Pierwszy odpowiada przede wszystkim na pytanie, czy systemy działają prawidłowo. Drugi – czy w środowisku nie występuje aktywność mogąca wskazywać na atak, nadużycie lub naruszenie bezpieczeństwa.

Monitoring infrastruktury a monitoring bezpieczeństwa

Monitoring infrastruktury obejmuje między innymi dostępność serwerów, usług i urządzeń sieciowych, wykorzystanie procesora i pamięci, pojemność dysków, stan interfejsów, opóźnienia, błędy usług oraz problemy z wydajnością. Pozwala szybciej wykrywać awarie i symptomy pogarszającego się stanu środowiska.

Monitoring bezpieczeństwa koncentruje się natomiast na takich sygnałach jak:

• nietypowe próby logowania,
• wielokrotne błędy uwierzytelnienia,
• użycie konta administracyjnego w nietypowym czasie,
• uruchomienie podejrzanego procesu,
• próby wyłączenia mechanizmów ochronnych,
• komunikacja z infrastrukturą wykorzystywaną przez cyberprzestępców,
• nietypowy transfer danych,
• skanowanie sieci i próby przemieszczania się pomiędzy systemami,
• zmiany konfiguracji krytycznych urządzeń,
• modyfikacja lub usuwanie logów.

Oba rodzaje monitoringu mogą się przenikać. Nagły wzrost obciążenia serwera może wynikać z awarii aplikacji, ale również z działania złośliwego oprogramowania. Nietypowy ruch sieciowy może oznaczać błąd konfiguracji albo próbę eksfiltracji danych. Dlatego im lepsza widoczność środowiska, tym łatwiej odróżnić zwykły problem operacyjny od incydentu bezpieczeństwa.

EDR i XDR – widoczność aktywności na urządzeniach i w całym środowisku

Tradycyjny antywirus koncentruje się głównie na wykrywaniu znanych zagrożeń i blokowaniu złośliwych plików. Rozwiązania EDR (Endpoint Detection and Response) zapewniają szerszą widoczność aktywności na punktach końcowych, umożliwiając analizę procesów, połączeń, zmian w systemie i zachowań mogących wskazywać na atak.

W przypadku wykrycia zagrożenia EDR może wspierać między innymi:

• izolację urządzenia od sieci,
• zatrzymanie złośliwego procesu,
• blokowanie określonych artefaktów,
• analizę łańcucha zdarzeń,
• identyfikację innych urządzeń objętych incydentem,
• działania naprawcze i dochodzenie powłamaniowe.

XDR (Extended Detection and Response) rozszerza tę koncepcję, łącząc dane z wielu warstw środowiska – na przykład punktów końcowych, poczty, tożsamości, sieci i usług chmurowych. Dzięki korelacji zdarzeń łatwiej zauważyć atak, który w pojedynczym systemie wygląda jak seria niepowiązanych aktywności.

SIEM – centralizacja i korelacja zdarzeń

W rozbudowanych środowiskach duże znaczenie mają systemy SIEM (Security Information and Event Management). Ich zadaniem jest gromadzenie i analiza zdarzeń pochodzących z wielu źródeł, takich jak: firewalle i systemy IDS/IPS, serwery i systemy operacyjne, Active Directory i usługi tożsamości, rozwiązania EDR/XDR, aplikacje biznesowe, infrastruktura chmurowa, systemy backupowe, urządzenia sieciowe, narzędzia bezpieczeństwa.

SIEM pozwala korelować zdarzenia, które analizowane osobno mogłyby nie wzbudzić podejrzeń. Przykładowo pojedyncze nieudane logowanie nie musi oznaczać ataku. Jeśli jednak po serii prób uwierzytelnienia następuje skuteczne logowanie z nietypowej lokalizacji, zmiana uprawnień i dostęp do dużej liczby plików, połączenie tych informacji może wskazywać na poważny incydent.

Same alerty nie wystarczą

Jednym z częstych problemów jest wdrożenie narzędzi generujących dużą liczbę alertów bez określenia, kto ma je analizować i jak szybko powinien reagować. System bezpieczeństwa może poprawnie wykryć podejrzaną aktywność, ale jeśli powiadomienie pozostanie niezauważone przez kilka godzin lub dni, wartość technicznego mechanizmu znacząco spada.

Dlatego monitoring powinien być powiązany z procesem reakcji. Organizacja musi wiedzieć:

• kto analizuje alerty,
• które zdarzenia mają najwyższy priorytet,
• kiedy incydent wymaga eskalacji,
• jakie działania można wykonać automatycznie,
• kto podejmuje decyzję o izolacji systemu lub blokadzie konta,
• jak dokumentowany jest przebieg zdarzenia.

Jeżeli firma nie posiada własnego zespołu bezpieczeństwa pracującego w odpowiednim trybie, alternatywą mogą być usługi SOC lub MDR, zapewniające stałe monitorowanie, analizę zagrożeń i wsparcie w reagowaniu na incydenty.

W kontekście NIS2 dojrzałość techniczna nie polega więc wyłącznie na gromadzeniu logów i instalowaniu kolejnych narzędzi. Kluczowa jest zdolność do połączenia danych z różnych źródeł, wykrycia istotnego sygnału, właściwej oceny jego znaczenia i podjęcia reakcji, zanim incydent rozwinie się na większą skalę.

Backup i odporność danych na ransomware

W kontekście NIS2 samo wykonywanie kopii zapasowych nie powinno być utożsamiane z odpornością organizacji na utratę danych. Współczesne ataki ransomware coraz częściej obejmują nie tylko środowisko produkcyjne, ale również infrastrukturę backupową. Cyberprzestępcy próbują usuwać punkty przywracania, szyfrować repozytoria, przejmować konta administracyjne i wyłączać zadania backupowe, aby ograniczyć możliwość odtworzenia systemów bez zapłacenia okupu.

Dlatego architektura backupu powinna zakładać scenariusz, w którym napastnik uzyska dostęp do części infrastruktury IT. Kluczowe pytanie nie brzmi wyłącznie: czy firma posiada kopię danych?, ale również: czy kopia przetrwa przejęcie konta administratora, infekcję domeny lub atak na podstawowe środowisko produkcyjne?

Immutable Backup – kopie odporne na modyfikację

Jednym z najważniejszych mechanizmów zwiększających odporność na ransomware jest Immutable Backup, czyli przechowywanie kopii w sposób uniemożliwiający ich zmianę lub usunięcie przez określony czas. Prawidłowo zaprojektowana niezmienność ogranicza ryzyko, że napastnik po uzyskaniu dostępu administracyjnego usunie również punkty odzyskiwania.

Mechanizmy immutability mogą być realizowane na różnych warstwach – w oprogramowaniu backupowym, repozytorium, systemie obiektowym, chmurze lub pamięci masowej. Istotne jest jednak nie tylko zaznaczenie odpowiedniej opcji w konsoli, ale również właściwe zaprojektowanie całej ścieżki administracyjnej i polityki retencji.

Separacja backupu od środowiska produkcyjnego

System backupowy nie powinien być traktowany jak kolejny zwykły serwer w tej samej domenie i tej samej strefie zaufania. Jeśli administrator domeny automatycznie posiada szeroki dostęp do infrastruktury kopii zapasowych, przejęcie jednego uprzywilejowanego konta może otworzyć napastnikowi drogę zarówno do danych produkcyjnych, jak i mechanizmów ich odtworzenia.

Dlatego warto rozważyć między innymi:

• oddzielne konta administracyjne dla systemu backupu,
• separację od podstawowej domeny Active Directory,
• MFA do konsoli zarządzającej,
• ograniczenie dostępu administracyjnego do wybranych stacji i segmentów sieci,
• blokowanie bezpośredniego dostępu użytkowników do repozytoriów,
• ograniczenie komunikacji wyłącznie do wymaganych usług i portów,
• monitoring zmian konfiguracji i prób usuwania kopii.

W środowiskach o wysokiej krytyczności dodatkową warstwą ochrony może być kopia offline lub rozwiązanie wykorzystujące mechanizm air gap. Celem jest utrzymanie co najmniej jednego punktu odzyskiwania poza bezpośrednim zasięgiem ataku na środowisko produkcyjne.

Reguła 3-2-1-1-0 jako model odporności

Test odtwarzania ważniejszy niż status „backup completed”

Odporność backupu należy oceniać na podstawie rzeczywistej zdolności do odzyskania danych i usług. Testy powinny obejmować nie tylko pojedynczy plik, ale – zależnie od krytyczności środowiska – również maszyny wirtualne, bazy danych, aplikacje, usługi katalogowe oraz całe scenariusze awaryjne.

Warto przy tym sprawdzać:

• czy kopie są kompletne i możliwe do odczytania,
• ile rzeczywiście trwa odtworzenie,
• czy zachowane są zależności pomiędzy systemami,
• czy dostępna jest dokumentacja potrzebna do uruchomienia usług,
• czy osoby odpowiedzialne znają kolejność działań,
• czy środowisko można odtworzyć również wtedy, gdy podstawowa domena lub infrastruktura zarządzająca jest niedostępna.

W kontekście NIS2 backup powinien być więc traktowany jako element cyberodporności, a nie wyłącznie mechanizm archiwizacji danych. O jego wartości decyduje nie liczba wykonanych kopii, lecz zdolność organizacji do zachowania bezpiecznych punktów odzyskiwania i skutecznego przywrócenia kluczowych usług po realnym incydencie.

Ciągłość działania, Disaster Recovery i zdolność odtworzenia usług

Posiadanie bezpiecznych kopii zapasowych jest niezbędne, ale nie gwarantuje szybkiego powrotu do normalnej pracy po poważnym incydencie. Firma może dysponować kompletnym backupem, a mimo to przez wiele godzin lub dni nie być w stanie uruchomić kluczowych systemów. Przyczyną mogą być: brak infrastruktury zastępczej, nieznana kolejność odtwarzania, zależności pomiędzy aplikacjami, niedostępność usług katalogowych, brak aktualnej dokumentacji lub nieprzetestowane procedury.

Dlatego w kontekście NIS2 ciągłość działania należy rozpatrywać szerzej niż tylko przez pryzmat ochrony danych. Organizacja powinna wiedzieć, które procesy i usługi są krytyczne, jak długo mogą pozostawać niedostępne oraz jakie zasoby są potrzebne do ich przywrócenia.

RTO i RPO – dwa podstawowe parametry odtwarzania

Planowanie ciągłości działania wymaga określenia mierzalnych celów. Dwa najważniejsze parametry to:

• RTO (Recovery Time Objective) – maksymalny zakładany czas potrzebny na przywrócenie systemu lub usługi po awarii,
• RPO (Recovery Point Objective) – maksymalny akceptowalny zakres utraty danych wyrażony w czasie.

Jeżeli system ERP ma RTO wynoszące cztery godziny, organizacja powinna dysponować architekturą i procedurami pozwalającymi realnie uruchomić go w tym czasie. Jeśli RPO wynosi 30 minut, mechanizm ochrony danych musi umożliwiać odzyskanie informacji z odpowiednią częstotliwością.

Wartości RTO i RPO nie powinny być ustalane wyłącznie przez dział IT. Powinny wynikać z wpływu niedostępności systemu na procesy biznesowe, zobowiązania wobec klientów, wymagania umowne, bezpieczeństwo operacji oraz potencjalne straty finansowe.

Priorytety odtwarzania i zależności pomiędzy systemami

Disaster Recovery – od planu do rzeczywistej zdolności działania

Disaster Recovery (DR) obejmuje rozwiązania i procedury umożliwiające odtworzenie środowiska po poważnej awarii, cyberataku lub utracie podstawowej lokalizacji. W zależności od potrzeb może wykorzystywać replikację danych, zapasowe centrum danych, środowisko chmurowe, infrastrukturę hybrydową lub przygotowane zasoby uruchamiane dopiero w sytuacji awaryjnej.

Nie każda firma potrzebuje identycznego modelu DR. Dla części organizacji wystarczające będzie odtworzenie usług z backupu w określonym czasie. Inne, ze względu na krytyczność procesów, będą wymagały replikacji i możliwości szybkiego przełączenia do środowiska zapasowego.

Kluczowe jest, aby przyjęta architektura odpowiadała rzeczywistym wartościom RTO i RPO. Deklarowanie krótkiego czasu odtworzenia nie ma znaczenia, jeśli dostępna technologia, przepustowość łączy lub procedury operacyjne nie pozwalają go osiągnąć.

Testowanie scenariuszy, nie tylko pojedynczych systemów

Plan ciągłości działania powinien być regularnie testowany. Sam dokument opisujący procedurę nie daje pewności, że zadziała ona podczas rzeczywistego incydentu.

Test może obejmować różne scenariusze, na przykład:

Takie ćwiczenia pozwalają wykryć problemy, których nie widać w dokumentacji: nieaktualne dane kontaktowe, brakujące uprawnienia, wygasłe certyfikaty, niewystarczającą przepustowość, nieznane zależności pomiędzy aplikacjami czy procedury wymagające dostępu do systemu, który sam uległ awarii.

W kontekście NIS2 ciągłość działania oznacza więc realną, mierzalną i testowaną zdolność do utrzymania lub przywrócenia kluczowych usług. Backup jest jednym z elementów tej strategii, ale dopiero połączenie odpowiedniej architektury, jasno określonych RTO i RPO, planu Disaster Recovery oraz regularnych testów pozwala ocenić rzeczywistą odporność organizacji.

Szyfrowanie danych i bezpieczna komunikacja

Szyfrowanie jest jednym z podstawowych mechanizmów ograniczających skutki nieautoryzowanego dostępu do informacji. Ma znaczenie zarówno w przypadku cyberataku, jak i utraty laptopa, kradzieży nośnika, przejęcia transmisji czy uzyskania dostępu do infrastruktury przez osobę nieuprawnioną. W kontekście NIS2 ochrona kryptograficzna powinna być jednak traktowana jako element szerszej polityki bezpieczeństwa, a nie pojedyncza funkcja uruchomiona na wybranych urządzeniach.

Zakres stosowania szyfrowania powinien wynikać z rodzaju danych, miejsca ich przechowywania, sposobu przesyłania oraz poziomu ryzyka. Innych mechanizmów wymaga ochrona laptopów pracowników mobilnych, innych komunikacja pomiędzy aplikacjami, a jeszcze innych przechowywanie kopii zapasowych czy danych w środowisku chmurowym.

Dane przechowywane – szyfrowanie at rest

Dane przesyłane – szyfrowanie in transit

Zarządzanie kluczami i certyfikatami

Szyfrowanie musi być zarządzane

Jednym z częstych problemów jest brak centralnej widoczności. Firma może korzystać z szyfrowania dysków, ale nie wiedzieć, które urządzenia rzeczywiście są chronione. Może stosować certyfikaty TLS, ale nie posiadać pełnej informacji o ich właścicielach i terminach wygaśnięcia. Może szyfrować backup, ale nie mieć przetestowanej procedury odzyskania klucza po poważnej awarii.

Dlatego w kontekście NIS2 istotne jest nie tylko wdrożenie kryptografii, lecz również zarządzanie jej całym cyklem życia. Organizacja powinna wiedzieć, jakie dane są szyfrowane, przy użyciu jakich mechanizmów, kto kontroluje klucze oraz czy możliwe jest bezpieczne odzyskanie informacji w sytuacji awaryjnej.

Bezpieczeństwo łańcucha dostaw i dostawców IT

Dostawcy oprogramowania, integratorzy, firmy serwisowe, operatorzy usług chmurowych i podmioty świadczące outsourcing IT często posiadają dostęp do systemów, danych lub infrastruktury klienta. Z perspektywy cyberprzestępcy taki dostęp może stać się atrakcyjnym wektorem ataku.

Dlatego bezpieczeństwo łańcucha dostaw jest jednym z istotnych obszarów NIS2. Ocena ryzyka nie powinna ograniczać się do własnych urządzeń i użytkowników, ale obejmować również zależności od podmiotów zewnętrznych oraz sposób, w jaki uzyskują one dostęp do środowiska organizacji.

Dostęp serwisowy nie powinien oznaczać stałego dostępu

Jednym z najczęstszych problemów jest pozostawianie aktywnych kont dostawców przez wiele miesięcy lub lat. Konto utworzone na potrzeby wdrożenia, migracji albo pojedynczej interwencji serwisowej może nadal funkcjonować długo po zakończeniu prac. Zdarza się również, że kilku techników korzysta ze wspólnego konta, co praktycznie uniemożliwia jednoznaczne ustalenie, kto wykonał konkretną operację.

Bezpieczniejszy model powinien zakładać:

• indywidualne konta dla osób zewnętrznych,
• MFA dla dostępu zdalnego,
• nadawanie wyłącznie niezbędnych uprawnień,
• ograniczenie dostępu do konkretnych systemów,
• aktywację konta tylko na czas wykonywania prac,
• automatyczne wygaszanie uprawnień,
• rejestrowanie działań administracyjnych,
• okresowy przegląd aktywnych kont dostawców.

W środowiskach o podwyższonym poziomie ryzyka dostęp może być dodatkowo realizowany przez rozwiązania PAM lub ZTNA, z możliwością zatwierdzania sesji i pełniejszego monitorowania aktywności.

Ryzyko związane z oprogramowaniem i aktualizacjami

Dostawca jako element modelu ryzyka

Ocena partnera technologicznego powinna uwzględniać jakie realne uprawnienia posiada w środowisku klienta i jaki byłby wpływ przejęcia jego konta lub narzędzia zdalnego dostępu.

Warto przeanalizować między innymi:

• zakres dostępu do infrastruktury i danych,
• sposób uwierzytelniania personelu dostawcy,
• wykorzystanie kont uprzywilejowanych,
• możliwość dalszego powierzania usług podwykonawcom,
• sposób zgłaszania podatności i incydentów,
• zasady aktualizacji i utrzymania systemów,
• procedury odebrania dostępu po zakończeniu współpracy,
• zależność organizacji od pojedynczego dostawcy lub technologii.

Znaczenie mają również zapisy umowne określające odpowiedzialność za bezpieczeństwo, obowiązek informowania o incydentach, zasady współpracy podczas ich obsługi oraz wymagania dotyczące ochrony danych i dostępu do systemów.

W kontekście NIS2 bezpieczeństwo łańcucha dostaw oznacza więc połączenie oceny formalnej z realną kontrolą techniczną. Firma powinna wiedzieć nie tylko, komu ufa, ale również do czego dany podmiot ma dostęp, jak ten dostęp jest zabezpieczony i czy można go szybko ograniczyć w sytuacji zagrożenia.

Bezpieczeństwo Microsoft 365 i usług chmurowych w kontekście NIS2

Przeniesienie poczty, dokumentów, komunikacji i części procesów biznesowych do chmury nie przenosi całej odpowiedzialności za bezpieczeństwo na dostawcę usługi. Platforma może zapewniać zaawansowane mechanizmy ochronne, ale organizacja nadal odpowiada za sposób konfiguracji środowiska, zarządzanie tożsamością, nadawanie uprawnień, ochronę danych oraz reagowanie na incydenty.

Ma to szczególne znaczenie w przypadku Microsoft 365, który w wielu firmach stał się jednym z najważniejszych elementów środowiska IT. Przejęcie pojedynczego konta może otworzyć dostęp nie tylko do poczty, ale również dokumentów w OneDrive i SharePoint, rozmów w Teams, danych współdzielonych oraz aplikacji zintegrowanych z tożsamością użytkownika.

W kontekście NIS2 Microsoft 365 i inne usługi chmurowe powinny być traktowane jako integralna część środowiska IT, a nie obszar znajdujący się poza odpowiedzialnością organizacji. Kluczowe znaczenie mają właściwa konfiguracja, ochrona tożsamości, kontrola dostępu do danych, monitoring zdarzeń oraz zdolność do odzyskania informacji po incydencie.

Minimalny zestaw zabezpieczeń technicznych – jak przełożyć wymagania NIS2 na praktykę?

NIS2 nie definiuje jednego obowiązkowego zestawu produktów, który każda organizacja powinna wdrożyć w identycznej formie. Zakres zabezpieczeń musi wynikać z analizy ryzyka, charakteru działalności, krytyczności systemów, architektury środowiska oraz potencjalnych skutków incydentu.

Można jednak wskazać zestaw mechanizmów technicznych, które stanowią praktyczny punkt wyjścia do oceny dojrzałości cyberbezpieczeństwa firmy. Poniższa tabela pokazuje, jak powiązać najczęstsze obszary ryzyka z konkretnymi klasami zabezpieczeń i przykładowymi rozwiązaniami dostępnymi na rynku.

Powyższa tabela nie stanowi zamkniętej listy zabezpieczeń wymaganych przez NIS2 ani uniwersalnej specyfikacji zakupowej. Nie każda firma potrzebuje rozbudowanego SIEM, własnego SOC, platformy PAM czy zaawansowanej mikrosegmentacji. Jednocześnie w organizacji o wysokiej krytyczności usług nawet taki zestaw może okazać się niewystarczający.

Najważniejsze jest powiązanie mechanizmu technicznego z konkretnym ryzykiem. Dla jednej firmy priorytetem będzie segmentacja sieci i odseparowanie środowiska produkcyjnego, dla innej ochrona tożsamości w Microsoft 365, uporządkowanie kont uprzywilejowanych albo zabezpieczenie backupu przed ransomware.

Warto również zwrócić uwagę na zależności pomiędzy poszczególnymi warstwami ochrony. EDR może wykryć podejrzaną aktywność na stacji roboczej, ale jego skuteczność wzrośnie, jeśli zdarzenia są korelowane z logami tożsamości i sieci. MFA ogranicza ryzyko przejęcia konta, ale nie zastępuje regularnego przeglądu uprawnień. Immutable Backup zwiększa odporność kopii, ale nie rozwiązuje problemu nieprzetestowanego procesu odtworzenia.

Dlatego dojrzałe podejście do technicznych wymagań NIS2 powinno opierać się na architekturze wielowarstwowej. Poszczególne zabezpieczenia powinny się uzupełniać, ograniczając zarówno prawdopodobieństwo skutecznego ataku, jak i jego potencjalny zasięg oraz skutki dla działalności organizacji.

NIS2 wymagania techniczne dla firm – jak udokumentować wdrożenie?

Wdrożenie firewalla, MFA, systemu EDR/XDR, backupu czy platformy SIEM nie kończy procesu. Organizacja powinna również potrafić wykazać, jakie zabezpieczenia stosuje, jakie ryzyka mają one ograniczać, kto odpowiada za ich utrzymanie oraz w jaki sposób oceniana jest ich skuteczność.

Ma to znaczenie nie tylko podczas audytu lub kontroli. Aktualna dokumentacja skraca czas reakcji na incydent, ułatwia analizę zmian w środowisku i pozwala szybciej ustalić, czy dany mechanizm ochronny rzeczywiście działa zgodnie z założeniami.

Inwentaryzacja zabezpieczeń i powiązanie ich z ryzykiem

Dobrym punktem wyjścia jest ewidencja najważniejszych mechanizmów bezpieczeństwa. Organizacja powinna wiedzieć między innymi:

➡️ jakie rozwiązania są wdrożone,

➡️ jakie systemy i zasoby chronią,

➡️ przed jakim ryzykiem mają zabezpieczać,

➡️ kto jest właścicielem danego rozwiązania,

➡️ kto odpowiada za administrację i monitoring,

➡️ jakie są najważniejsze zależności techniczne,

➡️ kiedy zabezpieczenie było ostatnio przeglądane lub testowane.

Takie podejście pozwala uniknąć sytuacji, w której firma posiada wiele narzędzi bezpieczeństwa, ale nie potrafi jednoznacznie określić ich zakresu, właścicieli i roli w całym modelu ochrony.

Konfiguracja i polityki techniczne

Dowody działania zabezpieczeń

Dokumentacja nie powinna ograniczać się do opisów i deklaracji. Warto gromadzić dowody potwierdzające, że mechanizmy są rzeczywiście stosowane i regularnie weryfikowane.

W zależności od środowiska mogą to być:

Takie materiały pomagają wykazać nie tylko istnienie zabezpieczenia, ale również jego faktyczne wykorzystanie i skuteczność.

Zarządzanie zmianą i aktualność dokumentacji

Środowisko IT nie jest statyczne. Pojawiają się nowe serwery, aplikacje, usługi chmurowe, integracje i konta użytkowników. Zmieniają się dostawcy, wersje systemów, adresacja sieciowa oraz zależności pomiędzy usługami. Dokumentacja, która nie nadąża za tymi zmianami, szybko traci wartość.

Dlatego proces zarządzania zmianą powinien uwzględniać również aktualizację informacji o bezpieczeństwie. Wdrożenie nowej aplikacji może wymagać zmiany reguł firewall, utworzenia kont serwisowych, nadania dostępu do danych i uruchomienia dodatkowego monitoringu. Każdy z tych elementów wpływa na profil ryzyka organizacji.

Dokumentacja powinna wspierać działanie, a nie istnieć wyłącznie na potrzeby audytu

Najbardziej użyteczna dokumentacja to taka, z której można skorzystać podczas rzeczywistego problemu. Powinna pomagać odpowiedzieć na pytania: kto odpowiada za system, jakie są jego zależności, gdzie znajdują się logi, jak odizolować zasób, kto może zatwierdzić zmianę i w jaki sposób przywrócić usługę.

W kontekście NIS2 udokumentowanie wymagań technicznych oznacza więc połączenie informacji o ryzyku, wdrożonych zabezpieczeniach, odpowiedzialności, konfiguracji i dowodach skuteczności. Dzięki temu organizacja może nie tylko lepiej przygotować się do audytu, ale przede wszystkim szybciej reagować na incydenty i świadomie rozwijać poziom cyberodporności.

Jak spełnić wymagania NIS2? Od czego firma powinna zacząć?

1️⃣ Zidentyfikuj kluczowe zasoby i usługi

Pierwszym krokiem jest ustalenie, które systemy mają największe znaczenie dla działalności firmy.

Warto określić:

✅ które usługi muszą działać bez przerwy,

✅ gdzie znajdują się najważniejsze dane,

✅ jakie systemy są niezbędne do obsługi klientów, produkcji, logistyki lub sprzedaży,

✅ od jakich usług zewnętrznych zależy organizacja,

✅ które elementy infrastruktury stanowią pojedynczy punkt awarii.

2️⃣ Oceń ryzyko i realne scenariusze incydentów

Kolejnym etapem jest określenie, co może zagrozić kluczowym zasobom. Zamiast ograniczać się do ogólnego stwierdzenia „ryzyko cyberataku”, warto analizować konkretne scenariusze:

⚠️ przejęcie konta administratora,

⚠️ ransomware w sieci firmowej,

⚠️ wykorzystanie niezałatanej podatności,

⚠️ utrata dostępu do Microsoft 365,

⚠️ awaria macierzy lub platformy wirtualizacyjnej,

⚠️ usunięcie danych przez użytkownika,

⚠️ przejęcie konta dostawcy zewnętrznego,

⚠️ niedostępność podstawowej lokalizacji.

Im bardziej konkretny scenariusz, tym łatwiej przypisać do niego właściwe mechanizmy ochronne.

3️⃣ Zidentyfikuj luki pomiędzy ryzykiem a obecnymi zabezpieczeniami

Firma powinna porównać realne zagrożenia z aktualnym poziomem ochrony. Może się okazać, że część zabezpieczeń już istnieje, ale nie obejmuje całego środowiska albo nie jest właściwie skonfigurowana.

Przykładowo:

➡️ MFA działa dla użytkowników, ale nie obejmuje administratorów,

➡️ EDR chroni stacje robocze, ale nie wszystkie serwery,

➡️ backup jest wykonywany, ale repozytorium można usunąć z konta domenowego,

➡️ logi są zbierane, ale nikt ich regularnie nie analizuje,

➡️ sieć posiada VLAN-y, ale ruch pomiędzy nimi nie jest ograniczony,

➡️ aktualizacje są wdrażane na komputerach, ale nie na urządzeniach sieciowych i firmware.

To właśnie na tym etapie najczęściej ujawniają się luki, których nie widać w prostej inwentaryzacji produktów.

4️⃣ Ustal priorytety według ryzyka, a nie popularności technologii

5️⃣ Wdrażaj zabezpieczenia jako spójną architekturę

Poszczególne technologie powinny się uzupełniać. MFA ogranicza ryzyko przejęcia konta, ale nie zastępuje kontroli uprawnień. EDR wykrywa aktywność na urządzeniach, ale jego wartość rośnie, gdy zdarzenia są korelowane z logami sieci i tożsamości. Segmentacja ogranicza rozprzestrzenianie się ataku, ale wymaga właściwych reguł komunikacji i monitoringu.

Dlatego wdrożenia warto planować jako element architektury wielowarstwowej, a nie zbiór niezależnych produktów.

6️⃣ Monitoruj skuteczność i testuj scenariusze

Po wdrożeniu zabezpieczenia należy sprawdzić, czy rzeczywiście działa zgodnie z założeniami. Oznacza to między innymi testy odtwarzania, przeglądy uprawnień, kontrolę aktualizacji, analizę alertów, weryfikację reguł firewall oraz ćwiczenia scenariuszy incydentów.

Bez regularnych testów organizacja może przez długi czas zakładać, że jest chroniona przez mechanizm, który w rzeczywistości jest niekompletny, błędnie skonfigurowany lub nie obejmuje nowych elementów środowiska.

7️⃣ Dokumentuj decyzje i regularnie aktualizuj plan

Ostatnim elementem jest utrzymanie informacji o zidentyfikowanych ryzykach, wdrożonych zabezpieczeniach, wyjątkach i planowanych działaniach. Wraz ze zmianą infrastruktury, pojawieniem się nowych usług i zagrożeń plan powinien być aktualizowany.

Przygotowanie do NIS2 nie jest więc jednorazowym projektem zakończonym wdrożeniem kilku technologii. To cykl obejmujący identyfikację zasobów → analizę ryzyka → ocenę luk → ustalenie priorytetów → wdrożenie → monitoring → testowanie → dokumentowanie i ponowną ocenę.

Takie podejście pozwala rozwijać bezpieczeństwo w sposób uporządkowany i uzasadniony biznesowo, zamiast reagować wyłącznie na pojedyncze incydenty, wyniki audytów lub aktualne trendy technologiczne.

NIS2 dla firm – jak Nomacom może pomóc?

Podsumowanie: NIS2 wymagania techniczne dla firm

Wymagania techniczne NIS2 nie sprowadzają się do wdrożenia pojedynczego narzędzia czy technologii. NIS2 podnosi wymagania dotyczące zarządzania ryzykiem cyberbezpieczeństwa, ale nie sprowadza ich do jednej listy obowiązkowych produktów czy technologii. To organizacja powinna dobrać środki techniczne adekwatne do skali działalności, architektury środowiska, krytyczności usług oraz potencjalnych skutków incydentu.

W praktyce oznacza to konieczność spojrzenia na bezpieczeństwo całościowo. Skuteczna ochrona powstaje z połączenia wielu warstw: zarządzania tożsamością i dostępem, bezpieczeństwa sieci, ochrony punktów końcowych, kontroli podatności, monitoringu, odpornego backupu, ciągłości działania, szyfrowania oraz nadzoru nad dostawcami i usługami chmurowymi.

Najważniejsze jest jednak powiązanie technologii z konkretnym ryzykiem. Sam zakup firewalla, EDR czy rozwiązania backupowego nie przesądza o poziomie cyberodporności. Znaczenie mają również właściwa konfiguracja, aktualność, integracja z innymi mechanizmami ochrony, regularne testowanie oraz zdolność do wykazania, że wdrożone zabezpieczenia rzeczywiście działają.

Dlatego przygotowanie do technicznych wymagań NIS2 warto traktować jako proces ciągły: od identyfikacji kluczowych zasobów i analizy ryzyka, przez ocenę luk i ustalenie priorytetów, po wdrożenie zabezpieczeń, monitoring, testowanie i dokumentowanie ich skuteczności. Takie podejście pozwala nie tylko lepiej odpowiadać na wymagania regulacyjne, ale przede wszystkim budować środowisko IT bardziej odporne na rzeczywiste awarie, cyberataki i incydenty bezpieczeństwa.

• Tagi: