MFA na gruncie NIS 2 artykuł 21(2)(j)
NIS 2 czyni uwierzytelnianie wieloskładnikowe odrębnym obowiązkiem. Artykuł 21(2)(j) jest miejscem, w którym osadzony jest obowiązek, CIR (UE) 2024/2690 §11.7 określa gdzie i jak silne, a §30(2)(10) BSIG przenosi to do prawa niemieckiego.
Wersja skrócona
MFA nie jest opcjonalne i nie jest jedynie mile widziane. Artykuł 21(2)(j) umieszcza je na liście dziesięciu środków cyberbezpieczeństwa, które każdy podmiot kluczowy i ważny musi wdrożyć. To samo brzmienie obejmuje także bezpieczną komunikację głosową, wideo i tekstową oraz, tam gdzie to istotne, bezpieczną komunikację awaryjną wewnątrz twojej organizacji.
CIR (UE) 2024/2690 §11.7 uzupełnia szczegóły. Użytkownicy muszą uwierzytelniać się wieloma składnikami lub poprzez uwierzytelnianie ciągłe, gdy klasyfikacja zasobu, do którego uzyskują dostęp, tego wymaga. Siła uwierzytelniania musi odpowiadać tej klasyfikacji. Klejnoty koronne wymagają silniejszego uwierzytelniania niż portal z menu kawiarni.
CIR §11.3.2 ustanawia następnie twardy próg dla kont uprzywilejowanych. Silne procedury identyfikacji, uwierzytelniania i autoryzacji (uwierzytelnianie wieloskładnikowe jest przykładem, który CIR wymienia) muszą być domyślnie wdrożone dla kont uprzywilejowanych i kont administracji systemem. Niemcy przenoszą ten obowiązek przez §30(2)(10) BSIG niemal identycznym brzmieniem.
Artykuł 21(2)(j) dyrektywy NIS 2 (2022/2555)
stosowanie uwierzytelniania wieloskładnikowego lub rozwiązań uwierzytelniania ciągłego, zabezpieczonej komunikacji głosowej, wideo i tekstowej oraz zabezpieczonych systemów komunikacji awaryjnej w obrębie podmiotu, w stosownych przypadkach.
Punkt (j) na liście dziesięciu środków cyberbezpieczeństwa. Robi dwie rzeczy naraz: nazywa MFA (lub uwierzytelnianie ciągłe) standardem kontroli dostępu i wciąga bezpieczną wewnętrzną komunikację głosową, wideo, tekstową i awaryjną w ten sam obowiązek.
CIR (UE) 2024/2690, Załącznik §11.7 i §11.3
Podmioty objęte zakresem zapewniają, aby użytkownicy byli uwierzytelniani przy użyciu wielu czynników uwierzytelniania lub mechanizmów uwierzytelniania ciągłego w celu uzyskania dostępu do sieci i systemów informatycznych podmiotów objętych zakresem, w stosownych przypadkach, zgodnie z klasyfikacją zasobu, do którego ma być uzyskany dostęp.
§11 jest rozdziałem CIR dotyczącym kontroli dostępu i obejmuje łącznie artykuł 21(2)(i) i (j). §11.7 jest podsekcją specyficzną dla MFA. §11.3.2(a) idzie dalej dla kont uprzywilejowanych i kont administracji: silne procedury identyfikacji, uwierzytelniania (MFA wymienione jako przykład) i autoryzacji są wymagane. Ponieważ CIR jest rozporządzeniem, jest bezpośrednio wiążącym prawem UE dla sektorów wymienionych w jego Załączniku.
§30(2)(10) BSIG (Niemcy)
stosowanie uwierzytelniania wieloskładnikowego lub rozwiązań uwierzytelniania ciągłego, zabezpieczonej komunikacji głosowej, wideo i tekstowej oraz zabezpieczonych systemów komunikacji awaryjnej w obrębie podmiotu, w stosownych przypadkach.
Niemcy kopiują tekst UE niemal słowo w słowo. Praktyczna operacjonalizacja w Niemczech wskazuje na IT-Grundschutz baustein ORP.4 (zarządzanie tożsamością i dostępem), który jest referencyjnym katalogiem BSI do prawidłowego uwierzytelniania w działaniu operacyjnym.
MFA odpowiednie do klasyfikacji zasobu
Użytkownicy uwierzytelniają się wieloma składnikami lub poprzez uwierzytelnianie ciągłe w celu uzyskania dostępu do twojej sieci i systemów informatycznych, skalibrowane do klasyfikacji zasobu, który osiągają. Domniemany warunek wstępny: masz sklasyfikowane swoje zasoby. Bez klasyfikacji nie możesz spełnić tej zasady.
Konta uprzywilejowane: MFA domyślnie
Dla kont uprzywilejowanych i kont administracji systemem silna identyfikacja, uwierzytelnianie i autoryzacja są obowiązkowe. CIR wymienia uwierzytelnianie wieloskładnikowe jako wypracowany przykład. Jest to jedyne miejsce, w którym MFA przestaje być warunkowane klasyfikacją i staje się stanem domyślnym.
Siła uwierzytelniania odpowiada klasyfikacji
Siła uwierzytelniania musi być odpowiednia do klasyfikacji zasobu, do którego uzyskuje się dostęp. To jest drugi test. MFA nie jest jedną rzeczą. SMS, TOTP w aplikacji, zatwierdzenie push, klucze sprzętowe FIDO2 i uwierzytelnianie oparte na certyfikatach znajdują się na bardzo różnych szczeblach. Im wyższa klasyfikacja, tym wyższy szczebel, którego potrzebujesz.
Bezpieczna komunikacja, nie tylko MFA (artykuł 21(2)(j))
Punkt (j) jest szerszy niż uwierzytelnianie. Wymienia bezpieczną komunikację głosową, wideo i tekstową oraz systemy komunikacji awaryjnej wewnątrz podmiotu, w stosownych przypadkach. Samo wdrożenie MFA nie zamyka tego obowiązku. Wewnętrzne wideokonferencje, komunikatory i każdy pozapasmowy kanał awaryjny mieszczą się w tym samym obowiązku.
Klasyfikacja zasobu wyznacza głębokość (artykuł 21(1))
Artykuł 21(1) wymaga, aby środki były odpowiednie i proporcjonalne. CIR przekłada to na konkretny test dla MFA: klasyfikacja zasobu wyznacza siłę. Mały Stadtwerk nie potrzebuje kluczy sprzętowych FIDO2 dla każdego wewnętrznego portalu. Host przesiadkowy systemu sterowania to inna rozmowa. Klasyfikacja jest dźwignią, a nie sama wielkość firmy.
BSI / §30(2)(10) BSIG
Niemcy kopiują brzmienie UE niemal dosłownie do §30(2)(10) BSIG. Referencją wdrożeniową BSI jest IT-Grundschutz baustein ORP.4 (zarządzanie tożsamością i dostępem), który podaje konkretne wymagania dotyczące wydawania poświadczeń, MFA, rozdzielenia kont uprzywilejowanych i dostępu awaryjnego. Jeśli wdrożysz ORP.4 prawidłowo, mieścisz się w obowiązku §30(2)(10).
ENISA Technical Implementation Guidance
TIG ENISA dla CIR przechodzi przez §11 prostym językiem operacyjnym i mapuje go na ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 i CEN/TS 18026:2024. Jeśli już prowadzisz ISO 27001 (środki A.5.16, A.5.17, A.8.5), jesteś w większości na miejscu. TIG wymienia także dowody, których oczekują audytorzy: polityka MFA, klasyfikacja kont, rejestry rejestracji, rejestr wyjątków.
Krajowe ustawy transponujące
Każde państwo członkowskie ma własną transpozycję NIS 2 (Holandia: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Sam obowiązek MFA jest identyczny, ponieważ tkwi w dyrektywie i CIR. Co różni się między krajami: katalog referencyjny (Grundschutz w Niemczech, BIO w Holandii, brak formalnego katalogu gdzie indziej), kanał zgłaszania i organ nadzorczy.
Mamy MFA na VPN, więc gotowe.
MFA na VPN to jedna ścieżka dostępu. CIR §11.7 dotyczy dostępu do zasobów zgodnie z ich klasyfikacją, a nie jednego urządzenia brzegowego. Jeśli użytkownik uprzywilejowany może dotrzeć do kontrolera domeny, konsoli kopii zapasowych, konsoli administracyjnej chmury lub instancji SaaS bez MFA, obowiązek nie jest spełniony. Testem jest klasyfikacja zasobu za drzwiami, a nie drzwi, przez które wszedłeś.
MFA oparte na SMS jest dobre dla każdego.
CIR §11.7.2 mówi, że siła uwierzytelniania musi odpowiadać klasyfikacji. SMS i głosowy OTP to najsłabszy składnik: SIM swap, przechwytywanie SS7 i phishing wszystkie je pokonują. Dla zwykłego dostępu wewnętrznego audytor może to zaakceptować. Dla klejnotów koronnych (konsole administracyjne, systemy sterowania, dostawcy tożsamości) potrzebujesz uwierzytelniania odpornego na phishing (FIDO2 / WebAuthn / karta inteligentna). Siła musi skalować się z klasyfikacją.
Konta usługowe i systemowe nie potrzebują MFA.
CIR §11.3.2(a) wyraźnie obejmuje konta uprzywilejowane i konta administracji systemem. Konta usługowe są poza zakresem MFA dla ludzi tylko wtedy, gdy są właściwie sklasyfikowane i używają innego silnego środka kontroli (tożsamości zarządzane, krótkotrwałe poświadczenia, podpisane certyfikaty, sekrety wydawane przez sejf z rotacją). „Konto usługowe, nie da się zrobić MFA, zwolnione” nie jest linią obrony. Albo jest sterowane przez człowieka (wtedy MFA), albo jest sterowane maszynowo (wtedy udokumentowany model poświadczeń maszynowych).
Większość niemieckich zespołów z Mittelstand zaczyna w tym samym miejscu: najpierw MFA na każdym koncie administratora (konsole administracyjne chmury, administrator domeny, hypervisor, kopie zapasowe, sprzęt sieciowy, instancje SaaS), następnie MFA na poczcie, a potem MFA na dostawcy tożsamości dla wszystkich użytkowników będących ludźmi. To pokrywa próg §11.3.2 i wiersze o wysokiej klasyfikacji w jednym ruchu. Reszta jest wdrażana dla wszystkich użytkowników będących ludźmi na sklasyfikowanych zasobach w ciągu pierwszego roku.
Co audytorzy faktycznie otwierają: listę klasyfikacji zasobów, raport rejestracji MFA z twojego dostawcy tożsamości oraz rejestr wyjątków. Jeśli te trzy są spójne, obowiązek jest spełniony. Najgłębsza pojedyncza dziura, jaką widzimy, nie jest techniczna, lecz dokumentacyjna: brakuje klasyfikacji zasobów, więc nie ma zasady, które zasoby uzasadniają jaką siłę uwierzytelniania. Najpierw napraw klasyfikację, a wtedy wdrożenie MFA samo odczyta się z listy.
Moduł ACC (kontrola dostępu) na platformie prowadzi obowiązek §11 od początku do końca. Rejestrujesz zasoby wraz z ich klasyfikacją, wymieniasz, które grupy użytkowników potrzebują dostępu, i dokumentujesz siłę uwierzytelniania dla każdego wiersza. Ta sama tabela odpowiada zarówno na test §11.7.1 (MFA w stosownych przypadkach), jak i §11.7.2 (siła odpowiada klasyfikacji) oraz wyodrębnia osobno wiersze kont uprzywilejowanych z §11.3.2.
Zatwierdzenie inwentaryzacji kontroli dostępu odbywa się imiennie. Wyjątki (starszy system, który nie może jeszcze obsłużyć MFA, integracja, która musi używać konta usługowego) żyją w tym samym rekordzie z udokumentowanym środkiem kompensacyjnym i datą przeglądu. Ślad audytowy i eksport dowodów na platformie dają audytorowi artefakty, które wymienia ENISA TIG: polityka, klasyfikacja, rejestr rejestracji, rejestr wyjątków, wszystko w jednym miejscu.
- Dyrektywa (UE) 2022/2555 (NIS 2), artykuł 21(2)(j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 (CIR), Załącznik §11.3 i §11.7 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ustawa BSI (BSIG), §30(2)(10) w brzmieniu nadanym ustawą o wdrożeniu NIS2 i wzmocnieniu cyberbezpieczeństwa
- BSI IT-Grundschutz, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'
- ENISA Technical Implementation Guidance dla CIR (UE) 2024/2690 (stan na maj 2026)