NIS2 zaczyna się od pytania: kto ma dostęp do czego?

Jako Inero Software od lat dostarczamy rozwiązania IAM klientom enterprise oraz mniejszym firmom. Projektujemy i wdrażamy integracje katalogów, SSO, uwierzytelnianie wieloskładnikowe, role i mechanizmy zarządzania kontami administratorów. Z doświadczenia wiemy, że najtrudniejszą częścią wdrożenia rzadko jest samo uruchomienie mechanizmu logowania. Znacznie trudniejsze bywa uporządkowanie odpowiedzialności, wyjątków i dostępów, które przez lata narastały w kolejnych systemach.

Ma to szczególne znaczenie dla organizacji, które mogą podlegać pod NIS2. Z jednej strony widzą przepisy, wytyczne i nowe terminy. Z drugiej – własną architekturę: kilka katalogów użytkowników, lokalne konta, aplikacje SaaS, systemy legacy, dostęp dostawców i nie zawsze udokumentowane zależności. Pomiędzy tymi dwoma obrazami łatwo zgubić techniczne niuanse, które decydują o tym, czy kontrola dostępu rzeczywiście działa.

W praktyce wymagania NIS2 szybko prowadzą więc do bardzo konkretnych pytań o użytkowników, administratorów, uwierzytelnianie, cykl życia kont i logi. Odpowiedzi na nie można – i trzeba – zweryfikować nie tylko w dokumentacji, lecz także w konfiguracji rzeczywistych systemów.

Wyobraźmy sobie organizację, która deklaruje, że ma Active Directory, SSO, MFA, VPN, politykę bezpieczeństwa i centralny system logowania. Na slajdzie architektura wygląda dojrzale. Podczas przeglądu technicznego pojawiają się jednak prostsze pytania: kto rzeczywiście ma dostęp do produkcji, kto go nadał, czy administratorzy używają osobnych kont, czy byli pracownicy nadal mogą się zalogować i gdzie trafiają logi uwierzytelnienia?

Właśnie tutaj wymagania regulacyjne spotykają się z rzeczywistą infrastrukturą. NIS2 nie nakazuje wdrożenia konkretnego systemu IAM i nie mówi, że organizacja powinna korzystać z Keycloak. Wymaga jednak zarządzania ryzykiem za pomocą adekwatnych środków technicznych, operacyjnych i organizacyjnych. Wśród obszarów wymienionych w art. 21 dyrektywy znajdują się m.in. kontrola dostępu, zarządzanie aktywami, bezpieczeństwo zasobów ludzkich oraz stosowanie MFA lub ciągłego uwierzytelniania, gdy jest to właściwe. Źródłem prawnym jest dyrektywa NIS2 (UE) 2022/2555.

NIS2 to nie tylko dokumentacja

Duża część rozmów o NIS2 koncentruje się na klasyfikacji podmiotów, zgłaszaniu incydentów i przygotowaniu dokumentacji. To ważne, ale sama polityka kontroli dostępu nie odpowie na pytanie, czy konto byłego administratora nadal działa w panelu firewalla.

W Polsce nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca NIS2, weszła w życie 3 kwietnia 2026 r. Podmioty spełniające kryteria w dniu wejścia w życie przepisów mają co do zasady czas do 3 października 2026 r. na wpis do Wykazu KSC oraz do 3 kwietnia 2027 r. na wdrożenie obowiązków wynikających z nowych przepisów. Aktualny harmonogram i zakres obowiązków opisuje Ministerstwo Cyfryzacji.

Stan prawny: 22 września 2026 r. Zakres obowiązków zależy od statusu i sektora konkretnej organizacji. Ten artykuł pokazuje techniczną perspektywę IAM, a nie stanowi porady prawnej ani kompletnej mapy zgodności.

Przejście od przepisów do wdrożenia oznacza zbudowanie Systemu Zarządzania Bezpieczeństwem Informacji, dobranie zabezpieczeń do ryzyka, przypisanie odpowiedzialności i zgromadzenie dowodów, że mechanizmy działają. IAM jest jednym z miejsc, gdzie te zadania stają się bardzo konkretne.

Jedno z najprostszych pytań: kto ma dostęp do czego?

Dojrzałe zarządzanie dostępem powinno pozwalać odpowiedzieć na osiem pytań:

1. Kto posiada konto?
2. W jakich systemach może go użyć?
3. Jakie role i uprawnienia są z nim związane?
4. Kto i na jakiej podstawie nadał dostęp?
5. Dlaczego użytkownik nadal go potrzebuje?
6. Kiedy uprawnienia zostały ostatnio przejrzane?
7. Jak użytkownik jest uwierzytelniany?
8. Czy logowanie oraz zmiany administracyjne są rejestrowane?

Problem polega na tym, że odpowiedzi bywają rozproszone pomiędzy działem HR, Active Directory lub Entra ID, konfiguracją aplikacji, repozytorium kodu, systemem VPN, bazami danych i wiedzą pojedynczych administratorów. Lista użytkowników w jednym IdP nie jest jeszcze listą wszystkich dostępów.

Z punktu widzenia zarządu ważny jest nie tylko zakup technologii, ale też przypisanie właścicieli procesów. Kto zatwierdza rolę? Kto odpowiada za konto techniczne? Kto inicjuje odebranie dostępu? Kto sprawdza wyjątki? Bez tych decyzji nawet poprawnie skonfigurowany system IAM zaczyna odzwierciedlać organizacyjny chaos.

Identity sprawl: jedna osoba, wiele tożsamości

Typowe środowisko rozwija się organicznie. Część aplikacji korzysta z katalogu firmowego, nowsze systemy są podłączone do Keycloak, narzędzia operacyjne utrzymują lokalne konta, a usługi SaaS mają własne mechanizmy użytkowników i ról. Dostawca zewnętrzny otrzymuje jeszcze osobny dostęp VPN.

W takim układzie najważniejsze pytanie brzmi: który system jest źródłem prawdy o tym, kto powinien posiadać dostęp?

Centralne SSO zmniejsza liczbę ścieżek logowania, ale samo nie rozwiązuje cyklu życia kont. Federacja z LDAP lub Active Directory może scentralizować uwierzytelnianie, lecz trzeba jeszcze ustalić, skąd pochodzą role i grupy. SCIM, czyli standard automatycznej wymiany informacji o użytkownikach i grupach, może pomóc w provisioningu i deprovisioningu usług SaaS. Dla systemów bez takiej integracji potrzebna jest kontrolowana procedura kont lokalnych, ich właścicieli i terminów ważności.

Celem nie zawsze jest jeden katalog dla wszystkiego. Celem jest spójny model odpowiedzialności, możliwie mała liczba wyjątków i zdolność do szybkiego ustalenia pełnego dostępu konkretnej osoby lub usługi.

Jeżeli organizacja jest dopiero przed takim uporządkowaniem, dobrym uzupełnieniem będzie nasz materiał o tym, jak przygotować się do wdrożenia systemu IAM w przedsiębiorstwie.

MFA nie zamyka tematu uwierzytelniania

MFA ogranicza ryzyko przejęcia konta, ale tylko w tych przepływach, w których rzeczywiście jest egzekwowane. Podczas przeglądu warto sprawdzić również:

• czy MFA obejmuje administratorów, VPN i dostęp zdalny;
• czy lokalna ścieżka logowania nie omija centralnego IdP;
• czy reset hasła lub odzyskanie konta nie opiera się na słabszej weryfikacji;
• czy po zmianie hasła albo odebraniu uprawnień aktywne sesje i tokeny są unieważniane;
• czy okresy ważności sesji, access tokenów i refresh tokenów odpowiadają ryzyku aplikacji;
• czy dostęp awaryjny jest kontrolowany, testowany i rejestrowany.

Bezpieczne logowanie nie oznacza automatycznie bezpiecznego zarządzania kontem. Jeżeli help desk może wyłączyć drugi składnik po krótkiej rozmowie telefonicznej, to procedura odzyskiwania staje się alternatywną ścieżką ataku. Podobnie wielodniowa sesja administracyjna może osłabić korzyść z silnego uwierzytelnienia na początku sesji.

Samą konfigurację drugiego składnika opisujemy bardziej szczegółowo w przewodniku po MFA w Keycloak.

Konta uprzywilejowane wymagają osobnego modelu

Konta administratorów IAM, infrastruktury, baz danych i CI/CD mają inny profil ryzyka niż standardowe konta biurowe. To samo dotyczy kont root, service accounts, integracji maszynowych i dostępów dostawców.

W praktyce spotykamy środowiska, w których jedna osoba używa tego samego konta do poczty i administracji, konta serwisowe nie mają wskazanego właściciela, a dostęp dostawcy pozostaje aktywny po zakończeniu prac. Są też konta współdzielone, przez które nie można przypisać operacji do konkretnej osoby.

Dobra praktyka to oddzielenie kont administracyjnych od codziennej pracy, indywidualizacja kont, silne uwierzytelnianie, ograniczenie ról do potrzebnego zakresu oraz dostęp czasowy tam, gdzie jest to możliwe. Uprawnienia uprzywilejowane powinny podlegać częstszym przeglądom, a operacje administracyjne powinny zostawiać użyteczny ślad audytowy.

Dla określonych kategorii podmiotów szczegółowe wymagania techniczne doprecyzowuje rozporządzenie wykonawcze Komisji (UE) 2024/2690. Wymienia ono m.in. odrębne konta do administracji, silne uwierzytelnianie, okresowe przeglądy uprawnień uprzywilejowanych oraz dokumentowanie wyników. Rozporządzenie nie obejmuje automatycznie każdego podmiotu podlegającego NIS2, ale stanowi wartościowy punkt odniesienia dla projektowania kontroli.

Joiner, Mover, Leaver: konto ma cały cykl życia

Onboarding jest zwykle najlepiej uporządkowaną częścią procesu. Więcej problemów pojawia się, gdy pracownik zmienia stanowisko, czasowo wspiera inny zespół, kończy projekt albo odchodzi z organizacji.

Model Joiner – Mover – Leaver obejmuje trzy etapy:

• Joiner: utworzenie tożsamości i nadanie minimalnego zestawu ról na podstawie zatwierdzonego wniosku;
• Mover: odebranie starych uprawnień, przyznanie nowych i kontrola kumulacji ról po zmianie stanowiska;
• Leaver: wyłączenie konta, zakończenie sesji, unieważnienie tokenów i kluczy, odebranie dostępów lokalnych oraz udokumentowanie wykonania procesu.

Proces powinien obejmować pracowników, współpracowników, dostawców i tożsamości maszynowe. Automatyzacja zmniejsza liczbę pominięć, ale wymaga wiarygodnego źródła danych oraz jasno zdefiniowanych wyjątków. Szczególnie niebezpieczne są dostępy tymczasowe bez daty wygaśnięcia i konta techniczne bez właściciela biznesowego.

NIS2 i IAM: od wymagania do mechanizmu

Poniższa tabela nie jest kompletną mapą zgodności. Pokazuje, jak obszary zarządzania ryzykiem przekładają się na pytania operacyjne i mechanizmy IAM.

Wytyczne techniczne ENISA rozróżniają wymagania, praktyczne wskazówki wdrożeniowe i przykłady dowodów. Dotyczą podmiotów objętych rozporządzeniem 2024/2690, ale ich struktura jest użyteczna szerzej: pokazuje, że konfiguracja, proces i dowód działania powinny być projektowane razem.

Keycloak jako element architektury wspierającej NIS2

Keycloak może pełnić rolę centralnej warstwy IAM. Obsługuje SSO, OpenID Connect, OAuth 2.0 i SAML, federację LDAP/Active Directory, role i grupy, konfigurowalne przepływy uwierzytelniania, TOTP, WebAuthn i passkeys, zarządzanie sesjami oraz rejestrowanie zdarzeń. Zakres funkcji opisuje aktualna dokumentacja administracyjna Keycloak.

To nie oznacza, że Keycloak jest „zgodny z NIS2” albo że jego instalacja zapewnia zgodność organizacji. Może być jednym z technicznych elementów architektury wspierającej realizację wymagań. Efekt zależy od konfiguracji, integracji, procesu aktualizacji, dostępności usługi, monitoringu i procedur organizacyjnych.

Szersze spojrzenie na punkty styku tej platformy z regulacją przedstawiliśmy wcześniej w artykule o wyzwaniach integracji Keycloak w kontekście NIS2.

Keycloak nie stanie się też automatycznie kompletnym systemem Identity Governance and Administration. Jeżeli organizacja potrzebuje rozbudowanych kampanii recertyfikacji, modelowania konfliktów uprawnień lub pełnego provisioningu wielu systemów SaaS, może potrzebować dodatkowych narzędzi i procesów. Należy również pamiętać, że standardowa federacja LDAP/AD nie jest tym samym co SCIM.

Co sprawdzilibyśmy w istniejącym Keycloak?

Przegląd warto podzielić na kilka grup.

Utrzymanie i powierzchnia administracyjna

1. Wersja Keycloak – czy jest wspierana i czy znane podatności dotyczą wdrożenia?
2. Aktualizacje i poprawki – kto monitoruje wydania, testuje upgrade i określa czas instalacji poprawek?
3. Admin Console – z jakich sieci jest dostępna i czy jest dodatkowo chroniona?
4. Administratorzy – ile jest kont, jakie mają role i czy używają osobnych tożsamości administracyjnych?

Te punkty pokazują, czy centralny element uwierzytelniania sam nie stał się niekontrolowanym zasobem uprzywilejowanym.

Uwierzytelnianie i odzyskiwanie konta

5. MFA – dla kogo jest wymagane, jak działa step-up authentication i jakie istnieją wyjątki?
6. Polityka haseł – czy jest adekwatna do źródła tożsamości i rzeczywistych ścieżek logowania?
7. Reset credentials i recovery – kto może uruchomić proces, jak weryfikowana jest osoba i czy zdarzenie jest logowane?
8. WebAuthn i passkeys – czy mogą zastąpić słabsze mechanizmy dla grup o podwyższonym ryzyku?

MFA należy oceniać jako cały przepływ, łącznie z rejestracją składnika, odzyskiwaniem dostępu i obsługą utraconego urządzenia.

Klienci, tokeny i sesje

9. Klienci OIDC – czy typ klienta i dozwolone granty odpowiadają architekturze aplikacji?
10. Redirect URIs – czy są precyzyjne, bez nadmiernie szerokich wildcardów?
11. PKCE – czy publiczne klienty używają Proof Key for Code Exchange do ochrony kodu autoryzacyjnego?
12. Sesje – czy limity bezczynności i maksymalnego czasu są proporcjonalne do ryzyka?
13. Access token lifetime – czy krótki czas życia ogranicza skutki wycieku bez destabilizowania aplikacji?
14. Refresh token lifetime i rotacja – jak długo możliwe jest odnawianie dostępu i jak wygląda unieważnianie?

Nie istnieje jedna bezpieczna wartość czasu dla wszystkich aplikacji. Panel administratora, aplikacja pracownicza i portal publiczny wymagają różnych decyzji.

Tożsamości maszynowe, zdarzenia i federacja

15. Service accounts – czy każde konto ma właściciela, minimalne role i kontrolowany sekret lub klucz?
16. User events – czy logowane są udane i nieudane logowania, reset danych uwierzytelniających oraz wylogowania?
17. Admin events – czy rejestrowane są zmiany klientów, ról, grup i przepływów uwierzytelniania?
18. Integracja z SIEM – czy zdarzenia trafiają do centralnego systemu, mają właściwy kontekst i uzgodniony okres retencji?
19. LDAP/AD – jaki jest tryb synchronizacji, zachowanie przy awarii i sposób obsługi usuniętych lub wyłączonych użytkowników?
20. Role i grupy – kto jest właścicielem modelu, jak często odbywa się przegląd i jak dokumentowane są zmiany?

Ta checklista nie jest testem „zgodny/niezgodny”. Jej celem jest ujawnienie decyzji, wyjątków i zależności, które powinny wynikać z oceny ryzyka.

Praktyczne aspekty centralizacji i analizy zdarzeń rozwijamy w materiale o integracji Keycloak z systemami SIEM.

Audytowalność: pokaż, że mechanizm działa

W cyberbezpieczeństwie coraz rzadziej wystarcza deklaracja, że kontrola istnieje. Organizacja powinna potrafić wykazać, że jest stosowana. Dla IAM dowodami mogą być:

• zatwierdzona polityka kontroli dostępu;
• aktualna lista kont uprzywilejowanych i ich właścicieli;
• konfiguracja MFA wraz z listą wyjątków;
• historia przyznania i odebrania ról;
• logi udanych i nieudanych logowań;
• admin events z Keycloak;
• raport z okresowego przeglądu uprawnień;
• zrealizowany przypadek odebrania dostępów po odejściu pracownika;
• zapis testu reakcji na przejęcie konta, łącznie z unieważnieniem sesji.

Dowód powinien być możliwy do odtworzenia, mieć właściciela i uzgodniony okres przechowywania. Log, którego nikt nie analizuje, nie jest jeszcze monitoringiem. Raport wygenerowany raz przed audytem nie zastępuje działającego procesu przeglądu dostępów.

10 pytań, które warto zadać przed audytem IAM

1. Ile systemów nadal przechowuje lokalne konta?
2. Ilu użytkowników posiada uprawnienia administracyjne?
3. Czy wszyscy administratorzy korzystają z MFA i osobnych kont?
4. Czy istnieją konta współdzielone, a jeśli tak, dlaczego?
5. Czy potrafimy wskazać konta byłych pracowników i dostawców?
6. Jak długo pozostają aktywne sesje i tokeny odświeżania?
7. Czy logujemy oraz przeglądamy zmiany administracyjne?
8. Czy logi uwierzytelnienia trafiają do centralnego systemu?
9. Jak często właściciele biznesowi potwierdzają potrzebę dostępu?
10. Czy odebranie wszystkich dostępów jednej osobie można uruchomić centralnie i zweryfikować?

NIS2 nie sprowadza się do wdrożenia IAM, MFA ani Keycloak. Zarządzanie tożsamością jest jednak jednym z obszarów, w których wymagania regulacyjne bardzo szybko spotykają się z rzeczywistą architekturą IT.

Dobrym pierwszym krokiem nie jest więc pytanie „czy mamy system IAM?”, ale znacznie prostsze: czy potrafimy powiedzieć, kto ma dziś dostęp do naszych systemów, dlaczego go ma i czy nadal go potrzebuje?

W Inero zajmujemy się projektowaniem, przeglądami i integracją systemów IAM, w szczególności rozwiązań opartych na Keycloak.