Kontrola dostępu w NIS 2 na mocy artykułu 21(2)(i)+(j)
Artykuł 21(2)(i) wymienia polityki kontroli dostępu. Artykuł 21(2)(j) wymienia uwierzytelnianie wieloskładnikowe. CIR §11 obejmuje je razem w siedmiu podsekcjach. Ta strona przeprowadza przez szersze obowiązki dotyczące polityki, kont uprzywilejowanych i tożsamości. Dedykowana strona MFA obejmuje §11.7.
W skrócie
Kontrola dostępu znajduje się w punktach (i) i (j) artykułu 21(2). Punkt (i) wymienia 'bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i zarządzanie aktywami'. Punkt (j) wymienia 'stosowanie uwierzytelniania wieloskładnikowego lub rozwiązań uwierzytelniania ciągłego, zabezpieczoną komunikację głosową, wideo i tekstową'. Oba mają zastosowanie do każdego podmiotu kluczowego i ważnego w całej UE.
CIR (UE) 2024/2690 §11 obejmuje obie litery razem, pod nagłówkiem 'Kontrola dostępu (artykuł 21(2) punkty (i) i (j) dyrektywy (UE) 2022/2555)'. Dzieli obowiązek na siedem podsekcji: samą politykę, zarządzanie uprawnieniami, konta uprzywilejowane, systemy administracji systemowej, identyfikację, uwierzytelnianie oraz uwierzytelnianie wieloskładnikowe. Ta strona przeprowadza przez §11.1 do §11.6. Konkretnie dla §11.7 zobacz dedykowaną stronę MFA.
Niemcy wprowadzają obowiązek dotyczący polityki do §30(2)(9) BSIG, a obowiązek MFA do §30(2)(10) BSIG. Niemiecką podstawą wdrożenia jest IT-Grundschutz ORP.4 'Identitäts- und Berechtigungsmanagement'.
info.accessControl.legalAnchor.directiveI.label
info.accessControl.legalAnchor.directiveI.quote
info.accessControl.legalAnchor.directiveI.context
info.accessControl.legalAnchor.directiveJ.label
info.accessControl.legalAnchor.directiveJ.quote
info.accessControl.legalAnchor.directiveJ.context
CIR (UE) 2024/2690, załącznik §11
Kontrola dostępu (artykuł 21(2), punkty (i) i (j) dyrektywy (UE) 2022/2555).
CIR §11 ma siedem podsekcji: §11.1 polityka kontroli dostępu, §11.2 zarządzanie uprawnieniami dostępu, §11.3 konta uprzywilejowane i konta administracji systemowej, §11.4 systemy administracji systemowej, §11.5 identyfikacja, §11.6 uwierzytelnianie, §11.7 uwierzytelnianie wieloskładnikowe. To rozporządzenie wiąże dostawców DNS, chmurę, centra danych, dostawców usług zarządzanych oraz pozostałe sektory wymienione w załączniku bezpośrednio.
§30(2)(9) i (10) BSIG (Niemcy)
Konzepte für die Zugriffskontrolle und für das Management von Anlagen. […] Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung.
Niemcy dzielą unijny punkt (i)+(j) na dwa numery BSIG. §30(2)(9) niesie kontrolę dostępu i zarządzanie aktywami. §30(2)(10) niesie MFA i bezpieczną komunikację. Treść to ta sama zasada UE.
Polityka i zarządzanie uprawnieniami
Spisz, jak działa dostęp (logiczny i fizyczny) dla pracowników, gości, dostawców i usługodawców. Przyznawaj, zmieniaj i odbieraj uprawnienia w oparciu o potrzebę biznesową: need-to-know, need-to-use, rozdział obowiązków. Każde uprawnienie jest przypisane do imiennie wskazanej osoby. Odebranie przebiega przy zmianie zatrudnienia, a nie w cyklu tygodniowym. Dostęp stron trzecich (goście, dostawcy) jest śledzony.
Konta uprzywilejowane i administracyjne
Konta administracyjne otrzymują silną identyfikację, uwierzytelnianie i autoryzację. Wyłącznie dedykowane konta administracyjne, używane jedynie do instalacji, konfiguracji, zarządzania i utrzymania. Uprawnienia administracyjne są dopasowane indywidualnie i ograniczone. Systemy administracji systemowej znajdują się we własnej sieci logicznej, oddzielonej od sieci aplikacyjnych, dostępne poprzez uwierzytelnianie i szyfrowanie.
Tożsamość i uwierzytelnianie
Cykl życia tożsamości: unikalne identyfikatory, każdy identyfikator powiązany z jedną osobą, monitorowanie i rejestrowanie przez cały cykl życia. Procedury uwierzytelniania odpowiadają polityce kontroli dostępu: siła hasła skalowana do klasyfikacji aktywów, procedury zmiany, blokada po nieudanych próbach, limity czasu sesji, oddzielne poświadczenia dla kont uprzywilejowanych.
Need-to-know, need-to-use, rozdział obowiązków
CIR §11.2 wymienia wszystkie trzy. Need-to-know: tylko osoby, które potrzebują danych, dostają dane. Need-to-use: uprawnienia odpowiadają zadaniu, a nie tytułowi. Rozdział obowiązków: żadna pojedyncza osoba nie powinna móc przyznać, użyć i zaudytować tego samego uprawnienia. Jeśli Twoje grupy AD to 'IT' i 'cała reszta', nie wdrożyłeś żadnej z trzech.
Uprzywilejowane to nie po prostu zwykłe z większymi uprawnieniami
CIR §11.3 i §11.4 podnoszą poprzeczkę konkretnie dla kont administracyjnych. Silna identyfikacja. MFA wymienione w samym §11.3, nie tylko w §11.7. Dedykowane konta używane wyłącznie do pracy administracyjnej. Systemy administracji systemowej we własnej sieci. Chodzi o to: naruszone konto administracyjne narusza wszystko, więc konta administracyjne dostają własny reżim.
BSI / IT-Grundschutz ORP.4
Niemiecką podstawą jest moduł IT-Grundschutz ORP.4 'Identitäts- und Berechtigungsmanagement'. ORP.4 obejmuje cykl życia tożsamości, uprawnienia oparte na rolach, rozdział kont uprzywilejowanych, reguły haseł i rytm przeglądów. Na mocy §44(2) BSIG wdrożenie Grundschutz jest wyraźnie uznawane za spełnienie obowiązków NIS 2 w Niemczech.
Wytyczne techniczne wdrożeniowe ENISA
Wytyczne techniczne wdrożeniowe ENISA dla CIR (UE) 2024/2690 przeprowadzają przez każdą podsekcję §11 w języku operacyjnym i mapują ją na ISO/IEC 27001:2022 (A.5.15 do A.5.18, A.8.2 do A.8.5) oraz NIST CSF 2.0 (PR.AA). Istniejące wdrożenie kontroli dostępu w ISO 27001 pokrywa już większość §11.
Krajowe ustawy transponujące
Każde państwo członkowskie transponuje artykuł 21(2)(i) i (j) do własnego prawa (Holandia: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obowiązki są identyczne, ponieważ dyrektywa ustanawia jeden ogólnounijny standard. Różni się: na który standard bazowy wskazuje krajowy organ regulacyjny.
Mamy grupy AD, więc mamy kontrolę dostępu.
Początek, nie koniec. CIR §11.2 wymaga udokumentowanej polityki uprawnień dostępu, uprawnień przypisanych do imiennie wskazanych osób, procedury odbierania powiązanej ze zmianą zatrudnienia oraz dziennika audytowego przyznań i odebrań. Grupy AD dają Ci mechanizm. Nie dają Ci polityki, rejestru imiennie wskazanych osób ani procedury joiners-movers-leavers, o którą zapyta audytor.
Nasi administratorzy używają swojego zwykłego konta do pracy administracyjnej, z sudo lub 'uruchom jako administrator'.
Nie na mocy CIR §11.3.2. Tekst wymaga 'dedykowanych kont administracyjnych' używanych wyłącznie do instalacji, konfiguracji, zarządzania i utrzymania. Zwykłe konto administratora jest do poczty, kalendarza i Excela. Oddzielne konto administracyjne, z własnym MFA, jest do pracy uprzywilejowanej. Mieszanie obu oznacza, że e-mail phishingowy może naruszyć rolę administratora.
Synchronizujemy uprawnienia dostępu w każdy poniedziałek rano.
Blisko, ale nie tego wymaga §11.2. Obowiązek odebrania wyzwala się przy zmianie zatrudnienia, a nie w cyklu kalendarzowym. Ktoś, kto odszedł we wtorek, nie powinien mieć dostępu w środę. Dla zmian ról wewnątrz firmy, zwłaszcza uprzywilejowanych, zmiana powinna być natychmiastowa. Rytm tygodniowy jest w porządku dla przeglądu audytowego, ale nie dla samego odebrania.
Typowa konfiguracja 50-250-osobowego Mittelstandu: Active Directory lub Entra ID dla tożsamości, grupy AD dla dostępu do aplikacji, system HR wystawiający IT zgłoszenia onboardingowe. Mechanizm w większości jest na miejscu. Luki §11 żyją w trzech miejscach.
Co widzimy, że praktycy łapią najpierw: spisaną politykę uprawnień dostępu (większość ma szkic, niewielu ma aktualną podpisaną wersję), dedykowane konta administracyjne (większość administratorów wciąż używa sudo na swoim codziennym koncie) oraz procedurę joiners-movers-leavers będącą wyłącznie po stronie IT zamiast napędzaną przez HR (przez co konto kontraktora zalega, bo HR nigdy nie powiedział IT, że odszedł). Naprawienie tych trzech zamyka większość luki §11.
Nasz moduł ACC obejmuje §11.1 (przesyłasz lub redagujesz politykę kontroli dostępu, a organ zarządzający ją zatwierdza), §11.2 (rejestr uprawnień powiązany z imiennie wskazanymi użytkownikami), §11.3 (inwentaryzacja kont uprzywilejowanych z odrębnym dowodem uwierzytelniania) oraz §11.5 plus §11.6 (dziennik źródła tożsamości powiązany z Twoim IdP). Rozdział systemów administracji systemowej z §11.4 jest udokumentowany jako decyzja architektoniczna wraz z dowodem.
Konkretnie dla elementu MFA z §11.7 zobacz dedykowaną stronę MFA i jej przepływ dowodowy. Ślad audytowy, który platforma prowadzi automatycznie (zatwierdzenia, status zadań, dziennik zmian), pokrywa to, co audytor chce zobaczyć w zakresie rytmu przeglądów i decyzji organu zarządzającego.
- Dyrektywa (UE) 2022/2555 (NIS 2), artykuł 21(2)(i) i (j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 (CIR), załącznik §11 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ustawa BSI (BSIG), §30(2)(9) i §30(2)(10) w brzmieniu zmienionym ustawą o wdrożeniu NIS2 i wzmocnieniu cyberbezpieczeństwa
- IT-Grundschutz Kompendium, moduł ORP.4 'Identitäts- und Berechtigungsmanagement' — bsi.bund.de/grundschutz
- Wytyczne techniczne wdrożeniowe ENISA dla CIR (UE) 2024/2690 (stan na maj 2026)