Większość naruszeń bezpieczeństwa w sieciach przedsiębiorstw w ostatnich latach (raporty CERT Polska, ENISA Threat Landscape, Verizon DBIR) nie zaczyna się od ataku na serwer aplikacyjny ani od phishingu na konto administratora domeny. Zaczyna się od urządzenia, którego dział IT formalnie nie obejmuje cyklem zarządzania: drukarki MFP, kamery IP, sondy klimatyzacji, kontrolera Wi-Fi, UPS-a, switcha dostępowego na piętrze.
Każde z nich ma adres IP, otwarty stos sieciowy, firmware z określonym CVE score i często panel webowy z domyślnymi poświadczeniami. Z perspektywy NIS2 (dyrektywa 2022/2555) i DORA (rozporządzenie 2022/2554) są pełnoprawnymi aktywami w łańcuchu utrzymania ciągłości usług. Z perspektywy operacyjnej — są pomijane.
Poniżej minimalna architektura, która spełnia wymogi obu regulacji w warstwie technicznej i pozwala wygenerować ewidencję dla audytora. Składa się z trzech niezależnych systemów. Brak któregokolwiek powoduje, że pozostałe dwa nie odpowiadają na pełen zakres wymagań.
Co to jest NIS2 — w dwóch zdaniach inżyniera
NIS2 (dyrektywa Parlamentu Europejskiego i Rady UE 2022/2555) to przepisy unijne nakładające na podmioty kluczowe i ważne obowiązek wdrożenia środków zarządzania ryzykiem cyberbezpieczeństwa, ciągłego monitorowania infrastruktury ICT, raportowania incydentów w 24h/72h/30 dni oraz osobistej odpowiedzialności zarządu za zgodność. W Polsce wdrażana przez nowelizację ustawy o krajowym systemie cyberbezpieczeństwa (KSC) — obowiązuje od 3 kwietnia 2026, wpisy do wykazu podmiotów do 3 października 2026.
Zakres podmiotowy: sektory IT i hosting, telekomunikacja, energetyka, transport, bankowość, ochrona zdrowia, produkcja, gospodarka odpadami, infrastruktura cyfrowa i dostawcy usług zarządzanych. Kryterium wielkości: ≥50 zatrudnionych lub ≥10 mln EUR obrotu (z wyjątkami dla dostawców infrastruktury krytycznej, gdzie wielkość nie ma znaczenia). Szczegóły zakresu, terminów i sankcji zebrane w osobnym artykule: NIS2 w Polsce 2026 — od kiedy obowiązuje i co musi zrobić Twoja firma.
Sankcje: do 10 mln EUR lub 2% obrotu globalnego dla podmiotów kluczowych, do 7 mln EUR lub 1,4% dla podmiotów ważnych. Plus odpowiedzialność osobista członków zarządu.
Co to jest DORA — w dwóch zdaniach inżyniera
DORA (rozporządzenie Parlamentu Europejskiego i Rady UE 2022/2554) — Digital Operational Resilience Act — to przepisy unijne stosowane bezpośrednio (rozporządzenie, nie dyrektywa — nie wymaga implementacji krajowej) od 17 stycznia 2025. Reguluje odporność operacyjną cyfrową sektora finansowego: banków, ubezpieczycieli, firm inwestycyjnych, kryptodostawców, agencji ratingowych oraz — co ważne — ich dostawców usług ICT (w tym chmurowych).
Wymogi DORA są bliźniaczo podobne do NIS2 w warstwie technicznej (monitoring, zarządzanie incydentami, zarządzanie ryzykiem dostawców), ale bardziej szczegółowe i z twardszymi terminami raportowania (4h dla istotnego incydentu, w przeciwieństwie do 24h w NIS2). Dodatkowo wprowadza obowiązek Threat-Led Penetration Testing (TLPT) dla największych podmiotów co 3 lata.
Jeśli pracujesz w fintech, na utrzymaniu systemu rozliczeń, w firmie ubezpieczeniowej albo dostarczasz IT do takiego klienta — DORA dotyczy Cię niezależnie od wielkości.
Krótka różnica NIS2 vs DORA
| Wymiar | NIS2 | DORA |
|---|---|---|
| Forma prawna | Dyrektywa — implementowana przez KSC | Rozporządzenie — stosowane wprost |
| Zakres podmiotowy | 18 sektorów krytycznych | Sektor finansowy + jego dostawcy ICT |
| Obowiązuje od | 03.04.2026 (Polska) | 17.01.2025 (UE) |
| Raport incydentu | 24h / 72h / 30 dni | 4h / 72h / 1 miesiąc |
| TLPT (testy penetracyjne) | nie wymaga | co 3 lata dla dużych |
| Kara maks. | 10 mln EUR / 2% obrotu | 1% średniego dziennego obrotu/dzień naruszenia |
W praktyce: jeśli firma podlega obu (np. dostawca usług IT dla banku, który jednocześnie jest podmiotem ważnym z punktu widzenia NIS2) — musi spełnić surowsze wymogi DORA, a dokumentacja zgodności pokryje też NIS2.
Trzy systemy, trzy pytania regulatora
Wymogi techniczne obu aktów sprowadzają się do trzech pytań, na które audytor oczekuje odpowiedzi popartej ewidencją z systemu, nie ze słowa kasztelana:
- Czy widzicie stan swoich aktywów? — wymaga systemu monitoringu (NMS).
- Czy widzicie zachowanie swoich aktywów? — wymaga systemu korelacji zdarzeń (SIEM/XDR).
- Czy potraficie tym zachowaniem sterować i to udowodnić? — wymaga systemu centralnego zarządzania konfiguracją i flotą.
Każdy z tych systemów jest niezależną warstwą. Wdrożenie SIEM-a bez inwentaryzacji daje SIEM, który nie wie, czego słucha. Wdrożenie zarządzania flotą bez NMS-a daje politykę, której nikt nie weryfikuje na żywo. Próba spełnienia wszystkiego jednym narzędziem (typowy błąd przy wyborze "all-in-one" platformy) kończy się zwykle wybrakowanym pokryciem przynajmniej jednej z trzech warstw.
1. System monitoringu stanu (NMS)
Funkcja: ciągła obserwacja parametrów operacyjnych urządzenia i powiadamianie o odchyleniu od stanu oczekiwanego.
Implementacje: Zabbix, Prometheus + Blackbox Exporter, Checkmk, LibreNMS, Nagios XI.
Zakres pomiarów minimum:
- ICMP reachability + RTT,
- status portów (link up/down, błędy CRC, drops, throughput),
- temperatura, stan zasilania, stan wentylatorów (przez SNMP),
- stan pamięci, CPU, dysków (jeśli urządzenie eksponuje),
- uptime — nagła zmiana to sygnał nieautoryzowanego restartu,
- data ważności i fingerprint certyfikatów,
- konfiguracja portów względem baseline'u.
Wymagania transportowe: SNMP v3 z authPriv (SHA-256 + AES-128/256). SNMP v1 i v2c przesyłają community string czystym tekstem i nie powinny być używane w segmencie produkcyjnym. Jeśli urządzenie nie obsługuje SNMP v3 — kandyduje do wymiany albo do odseparowanego VLAN-u z polityką "deny any" w stronę pozostałych segmentów. Zasady segmentacji opisaliśmy wcześniej w artykule Dlaczego segmentacja VLAN jest kluczowa.
Czego NMS nie wykrywa: ataków behawioralnych. Drukarka, która o 03:14 w niedzielę łączy się z hostem w innej strefie czasowej, dla NMS-a wygląda jak drukarka z poprawnym uptime'em i otwartym właściwym portem. Sygnał nie pojawi się.
2. System korelacji zdarzeń (SIEM/XDR)
Funkcja: zbieranie logów ze wszystkich źródeł, normalizacja, korelacja reguł, detekcja anomalii względem profilu bazowego.
Implementacje: Wazuh, Splunk Enterprise Security, Elastic Security, Graylog z regułami Sigma, Microsoft Sentinel, Google Chronicle.
Źródła logów do podpięcia:
- syslog z urządzeń sieciowych i końcowych,
- logi audytu z drukarek i MFP (job log, access log, configuration change log),
- logi z systemu uwierzytelniania (RADIUS, TACACS+, AD/LDAP),
- logi z firewalli i NAC,
- logi z hypervizorów i kontenerów.
Wymagania transportowe: syslog over TLS 1.3 zgodnie z RFC 5425, na porcie 6514. Gołe UDP/514 nie zapewnia integralności ani uwierzytelnienia źródła — logi mogą być spoofowane lub modyfikowane in-flight. Dla urządzeń bez wsparcia syslog/TLS używa się relay (rsyslog/syslog-ng) w tym samym segmencie L2.
Typowe reguły korelacyjne, których warto wymagać od dnia uruchomienia:
- N nieudanych logowań na urządzeniu sieciowym w czasie T + jedno udane = potencjalny brute-force,
- czyszczenie logów audytu = krytyczny alert (niezależnie od użytkownika, który tę operację wykonał),
- zmiana strefy czasowej, dodanie konta lokalnego, modyfikacja ACL = wysoki priorytet,
- ruch wychodzący z segmentu IoT/print do destynacji spoza listy dopuszczonych ASN,
- odchylenie wolumenu ruchu o > N% względem 30-dniowego baseline'u dla danego endpointa.
Mapowanie do regulacji: DORA Art. 10 (detekcja i reagowanie na incydenty operacyjne i ICT), NIS2 Art. 21 ust. 2 lit. b. Realny scenariusz, w którym SIEM ratuje firmę, opisaliśmy w artykule Ataki na małe firmy — jak wygląda realny scenariusz włamania.
3. System centralnego zarządzania konfiguracją i flotą
Funkcja: jednolite wdrażanie polityk konfiguracji, zarządzanie firmware'em, ewidencja aktywów, dowód zgodności.
Implementacje (zależne od warstwy):
- urządzenia sieciowe: Ansible + NetBox, Cisco DNA Center, Aruba Central, Juniper Mist,
- drukarki/MFP: HP Web Jetadmin, Canon iWEMC, Xerox CentreWare,
- urządzenia końcowe: Intune, Jamf, Workspace ONE,
- NAC: FortiNAC, Cisco ISE, PacketFence,
- warstwa nadrzędna: CMDB (ServiceNow, NetBox jako source of truth).
Wymagany zakres funkcjonalny:
- inwentaryzacja z automatycznym wykrywaniem urządzeń (DHCP, ARP, LLDP, SNMP discovery),
- profile konfiguracji wdrażane na grupy urządzeń (compliance baseline),
- zarządzanie firmware'em z rollback'iem,
- detekcja drift'u konfiguracji względem baseline'u,
- eksport raportów zgodności z timestampami i hash'ami (potrzebne dla audytora),
- integracja z systemem ticketowym dla obsługi wyjątków.
Czego nie zastępuje: NMS-a ani SIEM-a. Zarządzanie konfiguracją pokazuje jak urządzenie powinno wyglądać. Stan rzeczywisty i jego zachowanie wymagają osobnych narzędzi.
Mapowanie wymogów na systemy
| Wymóg | NIS2 | DORA | System |
|---|---|---|---|
| Inwentaryzacja aktywów | Art. 21 ust. 2 lit. a | Art. 8 | Zarządzanie flotą + CMDB |
| Zarządzanie konfiguracją | Art. 21 ust. 2 lit. f | Art. 9 | Zarządzanie flotą |
| Zarządzanie podatnościami i patchami | Art. 21 ust. 2 lit. f | Art. 9 | Zarządzanie flotą + NMS |
| Ciągły monitoring | Art. 21 ust. 2 lit. e | Art. 10 | NMS + SIEM |
| Detekcja incydentów | Art. 21 ust. 2 lit. b | Art. 10 | SIEM |
| Raportowanie incydentów | Art. 23 (24h/72h/30d) | Art. 19 (4h/72h/1m) | SIEM (ewidencja czasu wykrycia) |
| Backup i ciągłość działania | Art. 21 ust. 2 lit. c | Art. 11–12 | Wszystkie + backup 3-2-1-1-0 |
| Audytowalność | Art. 21 ust. 3 | Art. 6 ust. 8 | Wszystkie trzy |
Audytor nie pyta o deklarację. Pyta o ewidencję za ostatnie 12 miesięcy: listę aktywów z datą ostatniej aktualizacji firmware'u, log wszystkich zmian konfiguracji z autorem i timestampem, log wszystkich incydentów z czasem detekcji i czasem zamknięcia. Bez systemu centralnego zarządzania ta ewidencja nie istnieje, niezależnie od jakości pracy zespołu.
Trzy pytania kontrolne
Trzy pytania, na które trzeba mieć jednoznaczną odpowiedź przed audytem. Brak odpowiedzi na którekolwiek oznacza, że jeden z trzech systemów nie został wdrożony do końca.
1. Ile urządzeń ma adres IP w mojej sieci?
Akceptowalna odpowiedź to liczba ±0. Każdy zakres tolerancji ("około 200") oznacza, że NMS i CMDB nie są zsynchronizowane, a inwentaryzacja nie spełnia NIS2 Art. 21 ust. 2 lit. a.
2. Jaki firmware ma drukarka X i kiedy był ostatnio aktualizowany?
Akceptowalna odpowiedź to wersja + data + ścieżka audit log. Odpowiedź "musimy sprawdzić" oznacza brak zarządzania konfiguracją.
3. Co się stało w mojej sieci między 02:00 a 04:00 w nocy z soboty na niedzielę 21 dni temu?
Akceptowalna odpowiedź to wyciąg z SIEM-a w formacie CSV/JSON. Odpowiedź "logi mamy w syslogu na serwerze" oznacza brak korelacji i nie spełnia wymogu detekcji.
Sekwencja wdrożenia
Kolejność istotna. Każdy krok zakłada, że poprzedni został zakończony — odwrotna kolejność produkuje systemy z luką w pokryciu.
- Inwentaryzacja:
nmap -sn+arp-scan+ zrzut leases DHCP + import z LLDP. Konfrontacja z CMDB. Wynik: pełna lista aktywów z klasyfikacją. Punkt wyjścia dla wszystkiego, co następne. - NMS na wszystkim, co ma IP: SNMP v3 lub HTTPS API, baseline parametrów, alarmy. Bez tego nie zobaczysz, że coś przestało działać; bez tego SIEM dostanie martwy strumień logów i nie zauważy.
- Twardy syslog: TLS 1.3 (port 6514), central log server, retencja zgodna z polityką (NIS2: min. 12 miesięcy dla istotnych zdarzeń; DORA: min. 5 lat dla niektórych klas logów finansowych).
- SIEM: podpięcie źródeł, reguły korelacyjne, baseline behawioralny po 30 dniach uczenia. Pierwszy miesiąc to noise — nie wyrzucaj wczesnych alertów, tylko stroj reguły.
- Centralne zarządzanie flotą: profile zgodności, automatyzacja patchowania, eksport raportów. Ostatni krok — bo wymaga pewności, że NMS i SIEM widzą zmianę, gdy ją wprowadzisz.
- Ćwiczenie reakcji na incydent: NIS2 i DORA wymagają udokumentowanego planu obsługi incydentu i jego testowania. Symulacja (tabletop albo live-fire), pomiar czasu detekcji i czasu reakcji, korekta reguł SIEM. Powtarzane co kwartał.
Każdy z tych kroków ma narzędzia open-source, a koszt całości — przy zespole, który już ma kompetencje sieciowe i linuxowe — to kwestia kilku osobotygodni, nie kontraktu z integratorem za sześciocyfrową kwotę.
Co z tym zrobić w poniedziałek rano
Jeśli w piątek wieczorem czytasz to z myślą "audyt mam za pół roku, mamy czas" — masz pół roku na wdrożenie trzech systemów, które dla zespołu IT bez tej infrastruktury są minimum kwartałem pracy. Jeśli zaczynasz w poniedziałek — kolejność jak wyżej, a w tygodniu pierwszym wystarczą trzy decyzje:
- Wybrać narzędzia dla każdej z trzech warstw (rekomendowane minimum open-source: Zabbix + Wazuh + NetBox + Ansible).
- Zacząć od inwentaryzacji — przed wszystkim innym. Zwykle pokazuje 15–40% urządzeń, o których IT "wiedział mniej więcej".
- Wyłączyć SNMP v1/v2c i Telnet wszędzie, gdzie to jest fizycznie możliwe. To darmowy ruch zmniejszający powierzchnię ataku o kilkanaście procent w jeden dzień.
Wzorcowy szkielet sieci, na którym te trzy systemy nakładają się bez konfliktu, opisaliśmy wcześniej w artykule Jak powinna wyglądać sieć w małej firmie.
Podsumowanie
Trzy systemy. Trzy odpowiedzi na trzy pytania regulatora: jaki jest stan aktywów, jak się zachowują, czy potrafię tym sterować i udowodnić. NMS, SIEM, system zarządzania flotą. Pomijanie którejkolwiek warstwy nie powoduje, że wdrożenie jest "uproszczone". Powoduje, że jest niezgodne — i to nie z najlepszą praktyką, tylko z artykułem konkretnej dyrektywy.
NIS2 i DORA nie są opcją do przeczytania na spokojnie. Są deadlinem z konkretną sankcją i konkretnym artykułem ustawy. Trzy systemy, sześć kroków, jeden poniedziałek — żeby zacząć.
