NIS2 a infrastruktura techniczna obiektu: co realnie muszą zrobić firmy i zarządcy
Wokół NIS2 narosło sporo marketingowego szumu, w którym łatwo przeoczyć rzecz podstawową: dyrektywa nie dotyczy wyłącznie „cyberbezpieczeństwa" rozumianego jako firewalle i antywirusy. Bezpieczeństwo fizyczne infrastruktury — dostęp do serwerowni, zasilanie, chłodzenie, okablowanie — jest wprost częścią zarządzania ryzykiem, którego wymaga dyrektywa i implementująca ją w Polsce nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa.
Kogo to dotyczy
Katalog podmiotów kluczowych i ważnych jest szeroki: energetyka, transport, ochrona zdrowia, administracja, gospodarka odpadami, produkcja wybranych kategorii, usługi cyfrowe — a przez łańcuch dostaw pośrednio także ich podwykonawcy i dostawcy usług. W praktyce oznacza to, że wymagania NIS2 spływają w dół: firma objęta dyrektywą zaczyna ich wymagać od swoich dostawców, w tym od zarządców obiektów, w których działa.
Warstwa fizyczna, o której się zapomina
Analiza ryzyka wymagana przez NIS2 obejmuje także scenariusze fizyczne: nieautoryzowany dostęp do pomieszczeń technicznych, awarię zasilania, pożar w serwerowni, przegrzanie. Z perspektywy obiektu przekłada się to na konkretną listę:
Kontrola dostępu do stref technicznych — imienna, z rejestrem zdarzeń, którego nie da się nadpisać. Klucz wiszący w portierni nie spełnia tego wymagania. Monitoring środowiskowy serwerowni: temperatura, wilgotność, zalanie, dym — z alarmowaniem, a nie tylko z zapisem. Zasilanie gwarantowane z potwierdzonymi testami: UPS, którego baterii nikt nie testował od trzech lat, jest deklaracją, nie zabezpieczeniem. Redundancja tam, gdzie analiza ryzyka ją wskazuje: drugie źródło zasilania, dwa niezależne tory sieciowe, zapasowe chłodzenie.
Ciągłość działania i dokumentacja
NIS2 wymaga planów ciągłości działania i odtwarzania po incydencie. Dla infrastruktury technicznej oznacza to odpowiedź na pytania: co się dzieje po zaniku zasilania dłuższym niż wytrzymałość UPS-ów? Kto i w jakim czasie reaguje na alarm z serwerowni w sobotę o trzeciej w nocy? Gdzie jest dokumentacja pozwalająca odtworzyć konfigurację? Jeżeli odpowiedź na którekolwiek brzmi „to zależy, kto akurat jest w pracy" — plan nie istnieje.
Istotny jest też obowiązek raportowania poważnych incydentów w krótkich terminach (wczesne ostrzeżenie w ciągu 24 godzin). Bez monitoringu infrastruktury trudno w ogóle wiedzieć, że incydent się wydarzył, a co dopiero raportować go w terminie.
Od czego zacząć
Sensowna kolejność: audyt stanu obecnego z mapą ryzyk fizycznych, uzupełnienie braków krytycznych (kontrola dostępu, monitoring środowiskowy, testy zasilania), następnie procedury i umowy serwisowe z gwarantowanym czasem reakcji, na końcu dokumentacja całości. Kary przewidziane w ustawie robią wrażenie, ale prawdziwym argumentem jest co innego: te same działania, które zapewniają zgodność, po prostu zmniejszają ryzyko kosztownego przestoju.
