IAM a NIS2: jak zaprojektować zarządzanie tożsamością zgodne z NIS2?

Zarządzanie tożsamością i dostępem (IAM) w kontekście NIS2 i ustawy o KSC oznacza wdrożenie kontroli, które pokazują, kto, kiedy i na jakiej podstawie uzyskuje dostęp do systemów informacyjnych podmiotu kluczowego lub ważnego. W nowelizacji ustawy o KSC IAM nie jest samodzielnym projektem zgodności. Jest jednym z technicznych środków systemu zarządzania bezpieczeństwem informacji (SZBI), obok zarządzania podatnościami, monitoringu, ciągłości działania, kryptografii i bezpieczeństwa łańcucha dostaw.

Ten artykuł wyjaśnia, kogo dotyczy zarządzanie tożsamością zgodne z NIS2, jak wymagania dyrektywy przekładają się na konkretne kontrole IAM, kiedy potrzebna jest warstwa IGA i PAM, jak zaprojektować wdrożenie w grupie kapitałowej oraz jak IAM wspiera obowiązki raportowania incydentów. Pokazuje też, dlaczego IAM — nawet dobrze zaprojektowany — jest tylko jednym z modułów technicznych pełnego wdrożenia KSC/NIS2, a nie całością zgodności.

Jak NIS2 zmienia podejście do zarządzania tożsamością?

Dyrektywa NIS2 zmienia podejście do zarządzania tożsamością, czyniąc z niego jeden z centralnych mechanizmów kontroli dostępu do sieci i systemów informatycznych. W praktyce organizacja musi wiedzieć, kto, kiedy i na jakiej podstawie otrzymuje dostęp do zasobów oraz jak szybko ten dostęp jest odbierany, gdy przestaje być potrzebny. Taki model łączy procesy techniczne, procedury operacyjne i ślad audytowy w jedną całość.

Zarządzanie tożsamością nie zastępuje jednak systemu zarządzania bezpieczeństwem informacji wymaganego przez art. 8 ustawy o KSC. IAM jest jednym ze środków technicznych SZBI, obok zarządzania podatnościami, monitoringu bezpieczeństwa, ciągłości działania, kryptografii i bezpieczeństwa łańcucha dostaw. Sam wdrożony Keycloak, SSO czy MFA nie zastąpi klasyfikacji aktywów, szacowania ryzyka i procedur organizacyjnych, których SZBI wymaga w warstwie prawnej i proceduralnej. To rozróżnienie wraca w dalszej części artykułu, przy omówieniu zakresu wdrożenia technicznego.

To prowadzi do pytania, kogo dokładnie dotyczy zarządzanie tożsamością zgodne z NIS2.

Kto musi wdrożyć zarządzanie tożsamością zgodne z NIS2?

Zarządzanie tożsamością zgodne z nowelizacją ustawy o KSC i dyrektywą NIS2 muszą wdrożyć podmioty kluczowe i podmioty ważne, a pośrednio także ich łańcuch dostaw, jeżeli dostęp dostawcy wpływa na systemy informacyjne o znaczeniu krytycznym dla świadczonej usługi.

Obowiązek dotyczy użytkowników biznesowych, administratorów, kont uprzywilejowanych, integracji API oraz tożsamości nieludzkich (non-human identities). W grupach kapitałowych każda spółka powinna oddzielnie ocenić zakres odpowiedzialności i ryzyka dostępu — status podmiotu kluczowego lub ważnego jednej spółki nie rozciąga się automatycznie na pozostałe podmioty z grupy.

W następnym kroku warto przełożyć wymagania dyrektywy NIS2 na konkretne kontrole IAM, które można zmierzyć i udokumentować.

Jak NIS2 mapuje wymagania dyrektywy na zarządzanie tożsamością?

IAM mapuje wymagania dyrektywy NIS2 na konkretne kontrole techniczne wtedy, gdy polityka jest poparta działaniem operacyjnym i dowodem z logów, a nie tylko dokumentem. Wymagania NIS2 nie kończą się na spisaniu polityki — wymagają działania, które da się odtworzyć i pokazać kontrolującemu.

Po takim mapowaniu łatwiej wyjaśnić, dlaczego MFA jest ważnym, ale nie jedynym elementem zgodności z NIS2 w warstwie tożsamości. W praktyce spójny system zarządzania tożsamością obejmuje siedem bloków technicznych:

• Uwierzytelnianie pracowników — MFA i SSO: jedno logowanie z egzekwowaniem spójnych polityk dostępu do wszystkich systemów objętych SZBI.
• Tożsamości nieludzkie (NHI) — konta serwisowe i klucze API z automatyczną rotacją poświadczeń i rejestrem audytowym.
• Tożsamość klientów (CIAM) — bezpieczna rejestracja i uwierzytelnianie użytkowników zewnętrznych, skalowalne do milionów kont.
• Dostęp uprzywilejowany (PAM) — dostęp just-in-time dla administratorów, nagrywanie sesji, pełna rozliczalność działań.
• Łańcuch dostaw — federacja B2B eliminuje lokalne konta dostawców, a dostęp just-in-time zastępuje stały VPN. FAQ Ministerstwa Cyfryzacji podkreśla, że podmiot kluczowy i podmiot ważny powinien znać swój łańcuch dostaw wraz z ryzykami dostawców oraz dbać o wymagania cyberbezpieczeństwa w umowach — a przy umowach adhezyjnych z globalnymi dostawcami wybierać tych, którzy mają certyfikację cyberbezpieczeństwa własnych produktów i usług. W warstwie technicznej oznacza to rejestr dostawców z dostępem do systemów, kontrolę sesji i czasowe uprawnienia; klauzule umowne i ankiety bezpieczeństwa dostawców pozostają w gestii kancelarii.
• Cykl życia tożsamości (IGA) — automatyczny onboarding, natychmiastowy offboarding, okresowe przeglądy i certyfikacje uprawnień.
• SIEM i raportowanie — logi tożsamościowe w czasie rzeczywistym wspierają ustawowe terminy zgłoszeń: wczesne ostrzeżenie do 24h, zgłoszenie incydentu poważnego do 72h oraz sprawozdanie końcowe z obsługi incydentu w ciągu miesiąca od zgłoszenia.

Czy wdrożenie IAM wystarcza do zgodności z NIS2 i KSC?

Wdrożenie IAM nie wystarcza do pełnej zgodności z NIS2 i ustawą o KSC. Jest jednym z modułów technicznych szerszego programu wdrożenia, obok zarządzania podatnościami, monitoringu bezpieczeństwa, ciągłości działania, kryptografii i bezpieczeństwa łańcucha dostaw.

Zakres modułu IAM powinien wynikać z czterech elementów: klasyfikacji aktywów, czyli tego, które systemy i dane mają najwyższy wpływ na świadczenie usługi; mapy procesów biznesowych, czyli tego, od których systemów zależy ciągłość usługi; wyników analizy ryzyka, czyli tego, jakie zagrożenia i podatności dotyczą tych systemów; oraz modelu dostawców, czyli tego, kto z zewnątrz ma dostęp do środowiska. Bez tego punktu wyjścia wdrożenie IAM staje się projektem czysto technicznym, oderwanym od wymagań SZBI — i trudnym do obrony przed audytorem.

W technicznej ofercie Inteca IAM, MFA, IGA i PAM są częścią Etapu 2 (Wdrożenie techniczne), realizowanego po Etapie 1 (Audyt techniczny) i uzupełnianego opcjonalnym Etapem 3 (Utrzymanie). Pozostałe moduły Etapu 2 — zarządzanie podatnościami, monitoring SIEM, ciągłość działania, kryptografia i bezpieczeństwo łańcucha dostaw — są równie istotne dla zgodności i nie powinny być pomijane, gdy priorytetem staje się wyłącznie tożsamość.

Dlaczego dyrektywa NIS2 wymaga MFA i silnego uwierzytelniania?

Dyrektywa NIS2 wymaga MFA, ponieważ same hasła nie zapewniają poziomu bezpieczeństwa adekwatnego do obecnych zagrożeń. Uwierzytelnianie wieloskładnikowe ogranicza skutki phishingu i przejęcia poświadczeń, szczególnie w przypadku kont uprzywilejowanych.

W obszarach krytycznych warto stosować metody odporne na phishing, takie jak FIDO2/WebAuthn, a SMS traktować wyłącznie jako opcję zapasową niskiego ryzyka. Dobór metody MFA dla poszczególnych klas ryzyka jest odrębnym tematem technicznym w ramach modułu IAM — tutaj istotne jest to, że MFA nie działa w oderwaniu od centralnego systemu tożsamości. Gdy wiadomo już, dlaczego MFA jest ważne, kolejne pytanie dotyczy minimalizacji ryzyka nieautoryzowanego dostępu w całym cyklu życia konta.

Jak IAM zgodne z NIS2 minimalizuje ryzyko nieautoryzowanego dostępu?

Zarządzanie tożsamością zgodne z NIS2 minimalizuje ryzyko nieautoryzowanego dostępu przez zasadę najmniejszych uprawnień, cykliczną recertyfikację i szybkie cofanie dostępu do danych, gdy przestaje być potrzebny.

Kluczowe jest powiązanie tożsamości z rolą biznesową i automatyczne wygaszanie dostępu, gdy rola się zmienia. Dodatkowo monitorowanie anomalii logowania pozwala wykryć incydent, zanim naruszenie rozszerzy się na resztę infrastruktury.

To naturalnie prowadzi do rozróżnienia, kiedy wystarczy sam IAM, a kiedy potrzebna jest dodatkowa warstwa IGA.

Kiedy IAM zgodny z NIS2 potrzebuje warstwy IGA?

System zarządzania tożsamością potrzebuje warstwy IGA (Identity Governance and Administration) wtedy, gdy organizacja musi stale wykazywać zgodność, a nie tylko technicznie logować użytkowników.

IGA dodaje kampanie certyfikacji uprawnień, model Segregation of Duties oraz formalne raportowanie uprawnień dla audytorów. Dzięki temu operacje IAM zamieniają się w powtarzalny proces nadzorczy i raportowy, a nie w jednorazową konfigurację. Gdy warstwa governance jest gotowa, można skutecznie przygotować raportowanie incydentów.

Jak zarządzanie tożsamością wspiera raportowanie incydentów i audyt NIS2?

Zarządzanie tożsamością wspiera raportowanie incydentów, ponieważ dostarcza szczegółowy ślad: kto się logował, kiedy, z jakiego systemu, z jakimi uprawnieniami i jakie działania wykonał. Taki zakres danych skraca czas analizy i ułatwia dotrzymanie ustawowych terminów zgłoszeń.

FAQ Ministerstwa Cyfryzacji doprecyzowuje trzy terminy obsługi incydentu poważnego: zgłoszenie wczesnego ostrzeżenia nie później niż w ciągu 24 godzin od momentu wykrycia, zgłoszenie incydentu poważnego niezwłocznie, nie później niż w ciągu 72 godzin od momentu wykrycia — oba do właściwego CSIRT sektorowego — oraz przekazanie właściwemu CSIRT sektorowemu sprawozdania końcowego z obsługi incydentu poważnego nie później niż w ciągu miesiąca od dnia zgłoszenia. Logi IAM, historia sesji i zapisy zdarzeń MFA są częścią materiału dowodowego, na podstawie którego powstaje sprawozdanie końcowe.

W praktyce skuteczne zarządzanie incydentami wymaga integracji IAM z SIEM, aby wykrywać korelacje między zdarzeniami tożsamościowymi a zdarzeniami infrastruktury. Aby te dane były wiarygodne, organizacja musi też uporządkować procesy Joiner-Mover-Leaver i ich automatyzację.

Jak system IAM wykorzystuje automatyzację procesów Joiner-Mover-Leaver?

Zarządzanie dostępem wykorzystuje automatyzację procesów JML, aby usuwać błędy ręczne i skrócić czas reakcji na zmianę roli pracownika. Gdy pracownik zmienia stanowisko lub odchodzi z organizacji, system IAM powinien natychmiast aktualizować role i wygaszać aktywne sesje.

Takie podejście ogranicza narastanie nadmiarowych uprawnień i poprawia kontrolę dostępu w całej organizacji. Kolejny etap to wybór architektury, która skaluje się dla większych podmiotów i grup kapitałowych.

Jak zaprojektować system IAM dla wielu spółek?

Zarządzanie tożsamością dla grupy spółek warto oprzeć o izolację domen bezpieczeństwa, tak aby każda organizacja miała własny kontekst polityk i audytu.

Praktycznym modelem są oddzielne przestrzenie tożsamości z centralnym nadzorem, co ułatwia zgodność z NIS2 i spójność wdrożeń między spółkami. W sektorze regulowanym takie podejście upraszcza zarządzanie bezpieczeństwem informacji i utrzymuje jednolity standard operacyjny. Po wyborze architektury trzeba jeszcze ustalić, jak mierzyć skuteczność wdrożenia i podejmować na tej podstawie decyzje biznesowe.

Jak mierzyć, czy wdrożony system IAM spełnia wymagania biznesowe?

Efektywność systemu zarządzania tożsamością należy mierzyć wskaźnikami, które pokazują zarówno poziom bezpieczeństwa, jak i efektywność operacyjną wdrożenia.

Najważniejsze KPI to pokrycie MFA na kontach uprzywilejowanych, liczba kont z nadmiarowymi uprawnieniami, średni czas odebrania dostępu po zmianie roli oraz liczba zdarzeń wykrytych przez monitorowanie. Dla zarządu istotny jest także trend ryzyka oraz gotowość audytowa systemów zarządzania i systemów informatycznych. Te wskaźniki ułatwiają wybór realistycznego planu wdrożenia.

Jaki plan wdrożenia modułu IAM przyjąć w ramach Etapu 2 oferty Inteca?

Najskuteczniejszy plan wdrożenia modułu IAM w ramach Etapu 2 (Wdrożenie techniczne) zakłada wdrażanie rozwiązania etapowo, zaczynając od obszarów o najwyższym ryzyku i największym wpływie na ciągłość usługi, a nie od razu od całego katalogu systemów.

Taki plan jest możliwy dopiero po Etapie 1 (Audyt techniczny), w którym powstaje inwentaryzacja aktywów, tożsamości i uprawnień oraz raport luk technicznych na podstawie self-assessment klienta. Etap 1 daje wsad do priorytetów modułu IAM — bez niego harmonogram wdrożenia opierałby się na założeniach, a nie na faktycznym stanie środowiska.

Harmonogram jest przykładowym planem technicznym modułu IAM w Etapie 2 — rzeczywisty zakres i tempo wdrożenia Inteca ustala indywidualnie po zakończeniu Etapu 1. Po wdrożeniu etapowym warto regularnie weryfikować zakres modułu IAM wraz ze zmianami ryzyka i wynikami audytów, co w praktyce wiąże się z opcjonalnym Etapem 3 (Utrzymanie), obejmującym coroczne przeglądy uprawnień i gotowość audytową on-demand.

Jak Inteca może pomóc we wdrożeniu zarządzania tożsamością zgodnego z NIS2 i KSC?

Inteca pomaga wdrożyć zarządzanie tożsamością jako moduł IAM w ramach Etapu 2 (Wdrożenie techniczne) szerszego, trzyetapowego programu gotowości technicznej KSC/NIS2 — a nie jako samodzielny projekt oderwany od pozostałych wymagań ustawy.

1. Etap 1 — Audyt techniczny (5 900 PLN netto, ok. 2 tygodnie): inwentaryzacja aktywów, systemów i tożsamości na podstawie self-assessment klienta, raport luk technicznych wobec art. 8 uKSC i wstępny skan podatności.
2. Etap 2 — Wdrożenie techniczne (od 15 000 PLN netto, zakres ustalany po Etapie 1): moduł IAM — SSO, RBAC, MFA FIDO2/WebAuthn, automatyzacja on/offboardingu, kontrola dostępu uprzywilejowanego — wdrażany razem z zarządzaniem podatnościami, monitoringiem SIEM, ciągłością działania (DRP), bezpieczeństwem łańcucha dostaw, kryptografią i dokumentacją techniczną gotową na audyt.
3. Etap 3 — Utrzymanie, opcjonalne (od 2 900 PLN netto/mc): Managed Keycloak 24/7 z SLA Red Hat, ciągłe zarządzanie podatnościami, wsparcie incydentowe zgodne z terminami 24h/72h, coroczne przeglądy uprawnień i gotowość audytowa on-demand.

Inteca odpowiada wyłącznie za warstwę techniczną projektu i nie jest podwykonawcą kancelarii. Kwalifikację prawną podmiotu (kluczowy czy ważny), dokumentację SZBI w warstwie prawnej, klauzule umowne wobec dostawców oraz treść procedur zgłoszeń do organu przygotowuje kancelaria — we współpracy z Inteką, ale w odrębnej umowie i wycenie.

W praktyce oznacza to, że Inteca wspiera organizacje w technicznym przygotowaniu do KSC/NIS2: od audytu technicznego, przez wdrożenie środków technicznych i dokumentacji technicznej, po monitoring, obsługę incydentów i utrzymanie gotowości audytowej. IAM, MFA i Keycloak są jednym z modułów tego wdrożenia, a nie jego jedynym zakresem.

Zespół Inteca liczy ponad 50 inżynierów IAM i cyberbezpieczeństwa, zrealizował ponad 250 projektów dla ponad 10 milionów użytkowników końcowych, między innymi dla Tauron, PGE, PGNiG, LuxMed, BNP Paribas i Santander. Inteca jest oficjalnym partnerem Red Hat, co daje dostęp do certyfikowanych wersji Keycloak i wsparcia produkcyjnego klasy enterprise.

Źródła – IAM a NIS2

Dowiedz się więcej o nowelizacji ustawy KSC

Krajowy System Cyberbezpieczeństwa – kogo dotyczy KSC i co trzeba wdrożyć?

Posted on 2026-04-09

Analiza ryzyka w cyberbezpieczeństwie – metody i wymagania KSC / NIS2

Posted on 2026-04-08

System zarządzania bezpieczeństwem informacji (SZBI) a KSC – wymagania i wdrożenie

Posted on 2026-04-08