NIS2, czyli jak regulacja unijna zamieniła się w Twój codzienny sprint
Jeśli pracujesz w IT dłużej niż tydzień, prędzej czy później ktoś rzuci na spotkaniu hasło NIS2 tonem, jakby mówił o czymś między audytem podatkowym a wizytą u dentysty. I szczerze? Trochę tak to wygląda z zewnątrz.
Ale spokojnie, nie jest to kolejny dokument, który przeczyta prawnik, podpisze zarząd, a Ty dowiesz się o nim dopiero wtedy, gdy ktoś każe Ci "coś tam" doklikać w firewallu. NIS2 realnie wchodzi w Twój pipeline, Twoje sekrety w repo i Twój sposób wdrażania. Rozbijmy to na czynniki pierwsze.
Czym właściwie jest to całe NIS2?
NIS2 (Network and Information Security Directive 2) to unijna dyrektywa, która ma jeden cel: przestać traktować cyberbezpieczeństwo jako "coś, co dział IT ogarnie, na świętego Dygdy". Następczyni pierwszego NIS-a, tylko poważniejsza, szersza i ciernista.
W skrócie, jeśli Twoja firma działa w sektorze uznanym za istotny dla funkcjonowania państwa lub gospodarki (energetyka, transport, zdrowie, usługi cyfrowe, IT, produkcja i kilkanaście innych), to dyrektywa prawdopodobnie już o Tobie myśli, nawet jeśli Ty jeszcze o niej nie. Podmioty dzielą się na dwie kategorie:
- Kluczowe - duże firmy z sektorów strategicznych, największa odpowiedzialność, największe kary
- Ważne - mniejsze, ale wciąż objęte obowiązkami, tylko z nieco łagodniejszym nadzorem
Brzmi znajomo? To trochę jak ticket od klienta z opisem "ma działać szybciej". Dyrektywa działa na tej samej zasadzie. Daje ogólny cel, a konkrety trzeba sobie dopowiedzieć samemu. Różnica jest taka, że tym razem zamiast product ownera, czeka na Ciebie audytor
Co NIS2 mówi wprost, a czego nie mówi wcale
Tu leży największa pułapka tej dyrektywy. NIS2 mówi co trzeba osiągnąć. Prawie nigdy nie mówi jak.
Nie znajdziesz w niej zdania "skonfiguruj firewall w ten sposób" ani "testuj backup co kwartał". Znajdziesz za to sformułowanie "wdrożenie odpowiednich środków technicznych i organizacyjnych", czyli dokładnie ten sam zwrot, który zna każdy, kto kiedykolwiek czytał RODO. Widocznie w Brukseli ktoś się zakochał w tym sformułowaniu i wkleja je do każdej kolejnej regulacji.
To ten sam trik, co w normie ISO 27001. Ona też nie mówi "zainstaluj to konkretne narzędzie", tylko definiuje cel kontrolny i zostawia Ci wybór drogi. Różnica jest taka, że ISO robisz dobrowolnie, żeby dostać certyfikat na ścianę. NIS2 robisz, bo każe Ci ustawa, a alternatywą jest kara finansowa, nie brak plakietki na LinkedIn.
To oznacza jedno: interpretacja i wdrożenie spadają na dział IT i DevOps. I właśnie dlatego warto rozłożyć to na konkrety, zamiast czekać, aż ktoś przyniesie gotową checklistę (spoiler: nie przyniesie).
Wymagania techniczne, czyli co realnie musi się zmienić w infrastrukturze
Poniżej lista rzeczy, które w praktyce budują zgodność z NIS2 i które prędzej czy później wylądują na Twoim backlogu:
| Obszar | Co to oznacza w praktyce |
|---|---|
| Segmentacja sieci | Koniec z "cała podsieć gada z wszystkim". Reguły host => host:port, nie podsieć => serwer |
| Zarządzanie tożsamością | MFA wszędzie, SSO, zero kont współdzielonych, natychmiastowa dezaktywacja po odejściu z firmy |
| Backup i ciągłość działania | Offsite, immutable, testowany regularnie, a nie "działa, bo nie pokazuje błędów" |
| Monitoring i logi | Centralny SIEM albo coś równoważnego. Logi rozrzucone po serwerach to nie monitoring, to archeologia |
| Zarządzanie podatnościami | Regularne skanowanie, patch management, testy penetracyjne - nie raz w roku "przy okazji" |
| Łańcuch dostaw | Ocena bezpieczeństwa dostawców i podwykonawców, bo Twoje bezpieczeństwo jest tylko tak dobre, jak najsłabsze ogniwo u partnera |
| Zgłaszanie incydentów | 24h na wstępne zgłoszenie, 72h na raport, miesiąc na raport końcowy. Bez centralnego monitoringu ten zegar Cię zje |
Żadna z tych rzeczy osobno nie jest rewolucyjna. Problem w tym, że rzadko która firma ma wdrożone wszystkie naraz, a NIS2 wymaga właśnie kompletu, nie wybranych trzech punktów z listy.
A teraz najważniejsze, co to zmienia z perspektywy DevOps?
To jest część, która na tym blogu nas powinna interesować najbardziej, a o której większość artykułów o NIS2 milczy, bo są pisane z perspektywy administratora sieci sprzed dekady. A DevOps to nie firewall i backup taśmowy, to pipeline, kontenery i kod, który sam siebie wdraża. Więc jak dyrektywa unijna wchodzi w Twój gitlab-ci?
- Shift-left w bezpieczeństwie - skanowanie podatności (SAST, dependency scanning) w CI/CD zamiast na końcu, tuż przed produkcją, kiedy jest już za późno i za drogo, żeby coś naprawić
- Zarządzanie sekretami - jeśli masz jeszcze hasła w zmiennych środowiskowych albo, nie daj Boże, w repo, NIS2 to dobry moment, żeby wreszcie wdrożyć Vault, AWS Secrets Manager czy cokolwiek podobnego
- SBOM (Software Bill of Materials) - dokumentacja tego, z czego dokładnie zbudowana jest Twoja aplikacja. Bo jak wybuchnie, chcesz wiedzieć w 5 minut, a nie w 5 dni
- Infrastructure as Code jako audytowalność - jeśli infrastruktura jest w Terraformie czy Pulumi, a nie w czyjejś głowie i historii kliknięć w konsoli AWS, to review zmian infrastrukturalnych staje się tak samo naturalny jak code review
- Bezpieczeństwo samego pipeline'u - kto ma dostęp do CI/CD? Czy artefakty są podpisywane? Atak na łańcuch dostaw to dokładnie ten scenariusz, przed którym NIS2 chce Cię uchronić
- Policy-as-code - narzędzia typu OPA/Gatekeeper pozwalają wymusić zgodność automatycznie, zamiast liczyć na to, że ktoś pamięta o regułach z dokumentu PDF
- Immutable infrastructure - kontenery i orkiestracja (Kubernetes) naturalnie wspierają szybkie odtwarzanie po incydencie, czyli dokładnie to, czego wymaga NIS2 w zakresie ciągłości działania
Krótko mówiąc: dobre praktyki DevOps, które i tak powinieneś stosować, nagle stają się wymogiem prawnym. To trochę jak odkrycie, że mycie rąk przed jedzeniem jest teraz zapisane w ustawie. Powinieneś to robić i tak, ale teraz masz dodatkowy powód.
Od czego zacząć, żeby nie zwariować
- Sprawdź, czy Twoja firma w ogóle podlega NIS2 (sektor + wielkość), zanim zaczniesz panikować
- Zrób inwentaryzację: jakie systemy, dane i procesy są krytyczne
- Porównaj to, co masz, z listą wymagań technicznych (patrz tabela wyżej)
- W zespole DevOps: zacznij od najniższej gałęzi (sekrety poza kodem, skanowanie w CI/CD, IaC), zamiast klikania w konsoli
- Ustal, kto i w jakim czasie zgłasza incydent i przetestuj to na sucho, zanim zrobi się gorąco naprawdę
Podsumowanie
NIS2 nie jest wrogiem DevOpsów. Jest raczej lustrem, które pokazuje, ile z "dobrych praktyk", o których czytaliśmy w artykułach i konferencyjnych slajdach, faktycznie wdrożyliśmy, a ile zostało w fazie "zrobimy to później". Dyrektywa tylko ustawia termin na to "później".
A jeśli wolisz poczekać, aż ktoś rozłoży to na jeszcze drobniejsze kawałki, zostań z nami. Kolejne wpisy zejdą głębiej w konkretne wdrożenia: od SBOM-a, przez policy-as-code, aż po to, jak wygląda audyt NIS2 z perspektywy zespołu, który żyje w terminalu, a nie w Excelu.
