MFA KSC i NIS2 – co muszą wdrożyć podmioty kluczowe

MFA KSC oznacza stosowanie uwierzytelniania wieloskładnikowego tam, gdzie analiza ryzyka wskazuje potrzebę silniejszej ochrony dostępu. W nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa MFA nie jest samodzielnym projektem compliance. Jest częścią bezpiecznej komunikacji elektronicznej, polityki kontroli dostępu i systemu zarządzania bezpieczeństwem informacji.

Ten artykuł wyjaśnia, kiedy MFA jest potrzebne w KSC i NIS2, które konta objąć w pierwszej kolejności, jakie metody MFA wybrać i jak udokumentować wdrożenie przed audytem lub kontrolą. Pokazuje też, dlaczego Keycloak, IAM i SSO powinny być traktowane jako moduł techniczny pełnej gotowości KSC/NIS2, a nie jako całość wdrożenia.

Co mówi ustawa KSC i dyrektywa NIS2 o MFA?

Ustawa KSC i dyrektywa NIS2 traktują MFA jako środek zarządzania ryzykiem cyberbezpieczeństwa. Dyrektywa NIS2 wskazuje uwierzytelnianie wieloskładnikowe lub ciągłe jako jeden ze środków bezpieczeństwa. Polska ustawa o KSC przekłada ten wymóg na obowiązki podmiotów kluczowych i ważnych.

FAQ Ministerstwa Cyfryzacji doprecyzowuje, że podmiot powinien stosować bezpieczne środki komunikacji elektronicznej w ramach KSC oraz wewnątrz organizacji. Środki te mają uwzględniać uwierzytelnianie wieloskładnikowe w stosownych przypadkach. Ministerstwo podaje przykłady: zdalne logowanie, dostęp do wrażliwych informacji, konta administratorów oraz wszystkie sytuacje, w których MFA wynika z szacowania ryzyka.

W praktyce MFA nie jest jedną aplikacją ani jedną metodą logowania. MFA jest mechanizmem kontroli dostępu, który chroni użytkowników, administratorów, dostawców, konta techniczne i systemy krytyczne. Dlatego wdrożenie MFA powinno obejmować polityki, rejestry dostępów, logi, wyjątki, procedury odzyskiwania dostępu oraz dowody działania zabezpieczenia.

Czym różni się MFA w KSC od MFA w NIS2?

MFA w KSC jest krajowym sposobem wdrożenia wymagań NIS2 dla organizacji działających w Polsce. NIS2 określa europejski kierunek zarządzania ryzykiem. KSC określa polskie obowiązki, system S46, nadzór, audyty, kary i praktyczne dowody zgodności.

Dla organizacji różnica jest operacyjna. Zgodność z MFA trzeba wykazać w polskim modelu nadzoru i w kontekście SZBI. Samo posiadanie funkcji MFA w jednej aplikacji nie wystarcza, jeżeli organizacja nie potrafi pokazać zakresu wdrożenia, wyjątków, logów i decyzji wynikających z analizy ryzyka.

Dlatego MFA powinno być projektowane razem z kontrolą dostępu, zarządzaniem tożsamościami i klasyfikacją aktywów. Ten kontekst prowadzi do pytania, kto musi wdrożyć MFA i od czego zacząć kwalifikację podmiotu.

Kto musi wdrożyć MFA w KSC i NIS2?

MFA w KSC muszą rozważyć i wdrożyć podmioty kluczowe oraz podmioty ważne, jeżeli MFA jest adekwatnym środkiem bezpieczeństwa dla ich ryzyka. Obowiązek nie polega na mechanicznym włączeniu MFA wszędzie. Obowiązek polega na wdrożeniu odpowiednich i proporcjonalnych środków technicznych oraz organizacyjnych w ramach SZBI.

Podmioty objęte KSC działają między innymi w sektorach energii, transportu, bankowości, infrastruktury rynków finansowych, ochrony zdrowia, wody, ścieków, infrastruktury cyfrowej, zarządzania usługami ICT, administracji publicznej i przestrzeni kosmicznej. Status zależy od sektora, rodzaju działalności, wielkości podmiotu oraz szczególnych zasad z ustawy.

Ministerstwo Cyfryzacji wskazuje, że przedsiębiorca powinien najpierw ustalić swoją wielkość i działalność. Należy sprawdzić sprawozdanie finansowe, liczbę personelu, prawidłowe kody PKD, koncesje, zezwolenia i wpisy do rejestrów działalności regulowanej. Następnie trzeba przeanalizować art. 5 ustawy oraz załączniki nr 1 i nr 2 do ustawy o KSC

Jak sprawdzić, czy firma podlega pod KSC i NIS2?

Firmę należy sprawdzić przez analizę sektora, rodzaju usług, wielkości przedsiębiorstwa i zależności od systemów informacyjnych. Pierwszym krokiem jest lista usług świadczonych przez organizację. Drugim krokiem jest przypisanie tych usług do sektorów KSC i NIS2.

Trzecim krokiem jest sprawdzenie progów zatrudnienia, obrotu i sumy bilansowej. Czwartym krokiem jest ocena systemów, bez których usługa nie może być świadczona. Jeżeli usługa zależy od IAM, VPN, chmury, aplikacji biznesowych, systemów OT lub dostawców ICT, MFA może stać się jednym z kluczowych środków ograniczania ryzyka.

Organizacja nie powinna czekać na decyzję administracyjną, aby rozpocząć analizę. FAQ ministerstwa wskazuje, że każdy podmiot prowadzący działalność z załączników do ustawy musi sam przeanalizować, czy jest podmiotem kluczowym lub ważnym. Wynik tej analizy wpływa na terminy, zakres SZBI i priorytety MFA.

Kiedy trzeba wdrożyć MFA w harmonogramie KSC?

MFA trzeba wdrożyć w czasie realizacji obowiązków SZBI, jeżeli analiza ryzyka wskazuje MFA jako wymagany środek techniczny. FAQ ministerstwa wskazuje trzy praktyczne daty dla podmiotów, które spełniały przesłanki w dniu wejścia w życie ustawy. Wpis do Wykazu KSC powinien nastąpić do 3 października 2026 r. Podłączenie do S46 i wdrożenie obowiązków SZBI po raz pierwszy powinno nastąpić do 3 kwietnia 2027 r. Pierwszy audyt podmiotu kluczowego powinien nastąpić do 3 kwietnia 2028 r.

Termin wpisu do Wykazu KSC nie oznacza dodatkowego czasu na wdrożenie bezpieczeństwa. Ministerstwo wyjaśnia, że termin do 3 października 2026 r. dotyczy wyłącznie wpisu do wykazu. Terminy realizacji obowiązków liczy się co do zasady od momentu spełnienia przesłanek uznania za podmiot kluczowy lub ważny, a nie od dnia wpisu.

Z perspektywy MFA oznacza to potrzebę szybkiego rozpoczęcia inwentaryzacji kont i systemów. Wdrożenie MFA bez mapy dostępów często kończy się wyjątkami, przerwami operacyjnymi i brakiem dowodów dla audytu. Dlatego harmonogram MFA powinien być częścią szerszej roadmapy SZBI.

Które konta i systemy muszą być objęte MFA KSC?

MFA KSC powinno w pierwszej kolejności objąć konta i systemy o najwyższym wpływie na bezpieczeństwo oraz ciągłość działania. Priorytet mają konta administratorów, zdalny dostęp, konsole chmurowe, systemy krytyczne, konta dostawców i konta techniczne z wysokimi uprawnieniami.

FAQ ministerstwa wyjaśnia, że organizacja powinna ustalić politykę kontroli dostępu. Polityka powinna określać, kto może uzyskać dostęp fizyczny i logiczny do zasobów. Organizacja powinna zarządzać prawami dostępu, anulować dostęp osobom, które już go nie potrzebują, prowadzić rejestr dostępów oraz zarządzać tożsamościami użytkowników i systemów.

Zakres MFA powinien wynikać z klasyfikacji aktywów. Inne ryzyko ma zwykłe konto biurowe, inne konto administratora domeny, a jeszcze inne dostęp serwisowy dostawcy do systemu produkcyjnego. Dlatego MFA KSC musi być połączone z IAM, IGA, PAM, SSO i rejestrem dostępów.

Jaka jest praktyczna checklista MFA KSC dla kont i systemów?

Checklista MFA KSC powinna pokazywać konta, systemy, właścicieli, metody MFA, wyjątki, daty wdrożenia i status monitoringu. Taki rejestr jest potrzebny zespołowi technicznemu, kierownictwu i audytorowi. Rejestr pomaga też wykazać, że MFA jest stosowane zgodnie z ryzykiem.

Najważniejsze elementy checklisty to:

1. Objęcie MFA dla wszystkich kont uprzywilejowanych.
2. Objęcie MFA dla zdalnego dostępu, w tym VPN, SSH, RDP i narzędzi wsparcia.
3. Objęcie MFA dla konsol chmurowych, paneli administracyjnych i systemów SaaS.
4. Objęcie MFA dla aplikacji krytycznych, repozytoriów kodu, systemów finansowych i systemów HR.
5. Objęcie MFA dla dostawców z dostępem administracyjnym lub serwisowym.
6. Udokumentowanie wyjątków, kont awaryjnych i procedur odzyskiwania dostępu.
7. Włączenie logów, alertów i raportów potrzebnych do dowodów SZBI.

Checklista nie powinna być jednorazowym arkuszem. Powinna być utrzymywana razem z procesem nadawania, zmiany i odbierania dostępów. To łączy MFA z zarządzaniem tożsamością i doborem właściwych metod uwierzytelniania.

Jakie metody MFA spełniają wymogi KSC i NIS2?

Metody MFA spełniają wymagania KSC i NIS2 wtedy, gdy są adekwatne do ryzyka systemu i używają co najmniej dwóch niezależnych składników uwierzytelniania. Typowe metody to FIDO2/WebAuthn, passkeys, TOTP, certyfikaty PKI, smart cards i powiadomienia push z dodatkowymi zabezpieczeniami.

Dla systemów krytycznych należy preferować metody odporne na phishing. FIDO2/WebAuthn i klucze sprzętowe dobrze chronią konta administratorów, dostęp zdalny i konsole chmurowe. TOTP może być dobrym etapem przejściowym, ale wymaga monitoringu, kontroli resetu i procedur odzyskiwania.

SMS OTP powinien być traktowany ostrożnie. SMS może być przydatny w scenariuszach awaryjnych niskiego ryzyka, ale jest podatny na SIM swapping, phishing i przejęcie kanału komunikacji. Dla kont uprzywilejowanych i systemów krytycznych lepszym standardem jest phishing-resistant MFA.

Którą metodę MFA wybrać dla kont uprzywilejowanych?

Dla kont uprzywilejowanych najlepszym wyborem jest FIDO2/WebAuthn, certyfikat sprzętowy lub smart card. Te metody ograniczają ryzyko phishingu i przejęcia jednorazowego kodu. Są też łatwiejsze do powiązania z polityką dostępu uprzywilejowanego.

TOTP może być użyty jako rozwiązanie przejściowe, jeżeli organizacja nie jest gotowa na pełne wdrożenie kluczy sprzętowych. Push MFA powinien zawierać numer matching, ograniczenie liczby prób i alerty. Bez tych zabezpieczeń push MFA może być podatne na MFA fatigue.

Jak wdrożyć MFA KSC krok po kroku?

MFA KSC należy wdrożyć jako część programu SZBI, a nie jako izolowaną konfigurację logowania. Pierwszym etapem jest diagnoza statusu podmiotu, systemów informacyjnych, aktywów, kont, dostawców i ryzyk. Drugim etapem jest roadmapa techniczna i organizacyjna.

FAQ ministerstwa wskazuje, że podstawowym obowiązkiem podmiotów kluczowych i ważnych jest wdrożenie SZBI w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi. SZBI obejmuje systematyczne szacowanie ryzyka oraz wdrożenie odpowiednich i proporcjonalnych środków technicznych i organizacyjnych. MFA jest jednym z takich środków.

Praktyczny proces wdrożenia MFA powinien wyglądać następująco:

1. Ustal, czy organizacja jest podmiotem kluczowym lub ważnym.
2. Zidentyfikuj usługi, procesy i systemy informacyjne objęte SZBI.
3. Zrób inwentaryzację użytkowników, ról, kont technicznych i kont dostawców.
4. Określ klasy ryzyka dla systemów i kont.
5. Wybierz metody MFA dla każdej klasy ryzyka.
6. Zaprojektuj politykę wyjątków i kont awaryjnych.
7. Wdroż MFA w IAM, SSO, VPN, chmurze i aplikacjach krytycznych.
8. Włącz logowanie zdarzeń, alerty i raporty zgodności.
9. Przetestuj scenariusze odzyskiwania dostępu.
10. Przygotuj dowody SZBI dla audytu i kontroli.