Audyt MFA i kontroli dostępu, NIS2 art. 21(2)(j) + RODO art. 32

Microsoft w 2024 r. opublikował raport, według którego 99,9% incydentów z kompromitacją kont firmowych można było zatrzymać przez MFA. Liczba jest cytowana w setkach źródeł, i mimo to w średniej polskiej firmie MFA pokrywa typowo 20-60% kont krytycznych. Reszta to luka, której audytor szuka w pierwszej godzinie.

NIS2 art. 21 ust. 2 lit. j wymaga “stosowania uwierzytelniania wieloskładnikowego lub ciągłego uwierzytelniania, zabezpieczonych komunikacji głosowej, wideo i tekstowej oraz zabezpieczonych systemów komunikacji wewnątrz podmiotu w sytuacjach kryzysowych”. RODO art. 32 wymaga “odpowiednich środków technicznych i organizacyjnych”, MFA jest dziś standardem branżowym, a brak MFA przy danych osobowych = potencjalne naruszenie art. 32 (UODO już cytował to w decyzjach z lat 2023-2024).

Ten tekst jest pełną metodyką audytu MFA i kontroli dostępu (IAM). Obejmuje cztery obszary: pokrycie MFA, jakość metod MFA, zarządzanie tożsamością, kontrolę dostępu uprzywilejowanego.

Co dyrektywa i rozporządzenie wymagają, w detalu

NIS2 art. 21(2)(j). Standard: wszystkie wrażliwe systemy dostępne dla użytkowników wewnętrznych i zewnętrznych mają MFA. Idealnie: continuous authentication (np. ryzyko-adaptive auth, system ocenia ryzyko sesji i wymaga dodatkowych czynników gdy ryzyko rośnie).

RODO art. 32 + decyzje UODO. UODO konsekwentnie wskazuje, że dla danych osobowych dostępnych przez internet (panele administracyjne, CRM, system kadrowy, baza klientów) MFA jest minimum. Brak MFA w przypadku naruszenia (kradzież hasła, phishing skuteczny) skutkuje sankcjami.

ENISA (2024) Good Practices. Rekomenduje phishing-resistant MFA (FIDO2, WebAuthn) jako standard 2026 dla podmiotów kluczowych. SMS i hasła odzyskiwania zostają zakwalifikowane jako poniżej standardu.

Obszar 1: Pokrycie MFA, pomiar i ocena

Co audytor szuka. Lista wszystkich systemów z dostępem do danych krytycznych lub wrażliwych. Dla każdego: czy MFA wymuszone (100% kont), wymuszone dla niektórych, opcjonalne, niedostępne.

Dokumenty do zebrania.

• Polityka MFA firmy
• Lista systemów IT (asset inventory) z klasyfikacją krytyczności
• Lista użytkowników z wyjątkami od MFA (i uzasadnieniami)
• Raporty z konfiguracji MFA per system (z paneli administracyjnych)

Pytania do wywiadu z CISO/IT.

• Jaki procent kont (ogółem) ma MFA?
• Jaki procent kont uprzywilejowanych (administratorów) ma MFA?
• Jakie systemy nie mają MFA i dlaczego?
• Jak długo trwa od utworzenia nowego konta do włączenia MFA, automatycznie czy wymaga akcji?

Testy techniczne.

Test 1: weryfikacja realnego stanu w trzech systemach krytycznych. Audytor wybiera trzy systemy z danymi krytycznymi (np. system kadrowy, CRM, panel admin chmury). Dla każdego prosi o pokazanie konfiguracji MFA. Sprawdza: czy wymuszone (nie tylko dostępne), czy obejmuje wszystkie konta, jakie metody są akceptowane.

Test 2: próba zalogowania bez MFA. Audytor prosi administratora o symulację: utworzyć konto testowe, spróbować zalogować się ze stacji niezarejestrowanej. Czy MFA jest wymuszone? Jakie metody zaproponowane?

Test 3: weryfikacja wyjątków. Lista wyjątków (kont bez MFA). Audytor pyta dla każdego: dlaczego, do kiedy, jaki jest plan likwidacji wyjątku. Wyjątki bez planu = ustalenie.

Kryteria oceny dojrzałości.

• Poziom 0: MFA niewdrożone lub szczątkowo (poniżej 10% kont).
• Poziom 1: MFA na niektórych systemach (10-40% kont), brak polityki formalnej.
• Poziom 2: Polityka MFA, wymuszone dla części systemów (40-75% kont), liczne wyjątki.
• Poziom 3 (minimum NIS2): MFA wymuszone na wszystkich systemach krytycznych (95%+ kont uprzywilejowanych, 80%+ kont ogółem), wyjątki udokumentowane z planem.
• Poziom 4: Poziom 3 + phishing-resistant MFA dla administratorów, conditional access (geo-fencing, anomalia behavior detection).
• Poziom 5: Poziom 4 + continuous authentication, passwordless (FIDO2 wszędzie gdzie możliwe).

Obszar 2: Jakość metod MFA, nie wszystkie są równe

NIST SP 800-63B (Authentication Assurance Levels) klasyfikuje metody uwierzytelniania w trzech poziomach (AAL1, AAL2, AAL3). NIS2 wymaga AAL2 minimum, AAL3 dla systemów najbardziej krytycznych.

Metody MFA według siły (od najsłabszej):

1. SMS one-time password. Najsłabsza. Podatna na SIM swapping, SS7 attacks, przekierowanie wiadomości. NIST od 2017 r. odradza dla nowych wdrożeń. 2026: poniżej standardu.

2. E-mail one-time password. Słaba. Jeśli atakujący ma dostęp do skrzynki, ma też MFA. Akceptowalne tylko jako recovery.

3. TOTP (Time-Based One-Time Password), Google Authenticator, Microsoft Authenticator. Standard średni. Phishing-able (atakujący zbiera kod razem z hasłem). Akceptowalne dla większości scenariuszy.

4. Push notification (Microsoft Authenticator, Duo). Średnia siła. Podatna na MFA fatigue (atakujący wysyła zalewy próśb, użytkownik klika “approve” znudzony). Microsoft w 2022 r. wprowadził number matching jako mitygację.

5. Hardware tokens (YubiKey, Titan). Silne. FIDO2/WebAuthn = phishing-resistant. Standard dla administratorów i kont uprzywilejowanych w 2026 r.

6. Biometria + hardware (Windows Hello for Business, Apple Touch ID/Face ID). Silne, ale specyficzne urządzeniu. Dobre dla devices managed.

7. Certyfikaty + hardware (smart cards). Bardzo silne, ale wymagające infrastruktury PKI.

Co audytor sprawdza.

Test: jakie metody są dostępne dla użytkowników. W konfiguracji MFA każdego systemu, czy SMS jest dostępne jako fallback? Jeśli tak, to atakujący wybierze SMS, niezależnie od tego, że organizacja “rekomenduje” TOTP. Audytor wymaga, by SMS było wyłączone (lub akceptowane tylko jako recovery code, nie main factor).

Test: jakie metody są wymuszone dla administratorów. Cele 2026: phishing-resistant MFA (FIDO2/WebAuthn z YubiKey lub Titan) dla wszystkich kont uprzywilejowanych. Brak = ustalenie.

Test: MFA fatigue protection. Czy system push notification ma number matching (Microsoft Authenticator 2022+), location-based hints, contextual info?

Kryteria oceny dojrzałości jakości metod.

• Poziom 1: SMS jako główna metoda lub bez wymuszenia metod.
• Poziom 2: TOTP/push dla wszystkich, SMS jako fallback.
• Poziom 3 (minimum 2026): TOTP/push wymuszone, SMS wyłączone. Hardware tokens dla administratorów.
• Poziom 4: Phishing-resistant MFA (FIDO2) dla administratorów, conditional access.
• Poziom 5: Passwordless wszędzie gdzie możliwe, continuous authentication.

Obszar 3: Zarządzanie tożsamością (IAM), szerszy kontekst

MFA bez IAM jest jak zamek bez framugi. Audytor sprawdza pełen pipeline:

On-boarding. Czy nowy pracownik dostaje konta automatycznie (provisioning z HR), w jakich systemach, z jakimi uprawnieniami? Zasada least privilege (najmniej uprawnień niezbędnych).

Access review. Audyt uprawnień minimum raz na 6 miesięcy. Sprawdza: kto miał dostęp do czego, czy nadal potrzebuje, czy nie ma “zombie permissions” (uprawnienia z projektów już zamkniętych).

Off-boarding. Czas od wypowiedzenia umowy do zablokowania wszystkich kont. Standard 2026: do 24 godzin od końca umowy. Najczęstsza luka: konta w systemach SaaS niezintegrowanych z SSO (poza centralną kontrolą).

Single Sign-On (SSO). Czy firma używa SSO (Okta, Azure AD/Entra ID, Google Workspace)? Centralizacja tożsamości umożliwia jeden punkt enforcement MFA, jeden punkt access review, jeden punkt off-boarding.

Audyt zewnętrznych dostawców. Czy konsultanci, freelancerzy, partnerzy mają konta w systemach? Z jakimi uprawnieniami? Z jakim okresem ważności?

Dokumenty do zebrania. Polityka IAM, polityka on/off-boardingu, raporty access review z ostatnich 12 miesięcy, integracje SSO, lista użytkowników zewnętrznych z aktualnymi uprawnieniami.

Testy.

• Lista 5 osób, które odeszły w ostatnich 30 dniach. Dla każdej sprawdź: data odejścia, data zablokowania kont w głównych systemach, w SaaS niezintegrowanych z SSO. Luka czasowa = ustalenie.
• Test access review: ostatni raport. Czy znalezione “zombie permissions” zostały zlikwidowane? Brak action items = poziom 1.

Obszar 4: Kontrola dostępu uprzywilejowanego (PAM)

Konta administratorów to wektory najcięższego ryzyka. Pełen incident report ataku Lapsus$ na Nvidię (2022), Microsoft (2022) i Okta (2022) pokazał: kompromitacja konta uprzywilejowanego = pełen dostęp do firmy.

Privileged Access Management (PAM) to dedykowane rozwiązania (CyberArk, BeyondTrust, Delinea, lub open-source jak Vault) do zarządzania dostępem uprzywilejowanym. Funkcje:

• Vaulting haseł kont administratorów (nikt nie zna haseł “z głowy”)
• Just-in-time access (administrator zgłasza prośbę, dostaje dostęp na X godzin)
• Session recording (nagrywanie sesji administracyjnych)
• Approval workflow (krytyczne akcje wymagają drugiej osoby)

Co audytor sprawdza.

• Lista kont administratorów (root, admin, super-user w każdym systemie krytycznym).
• Czy istnieje PAM? Jakie systemy są pokryte?
• Czy session recording jest włączone dla działań produkcyjnych?
• Czy administratorzy używają “personal admin accounts” (osobne konto dla zadań admin) zamiast osobistych?

Kryteria oceny dojrzałości PAM.

• Poziom 0: Brak PAM, hasła w plikach tekstowych lub Excel’u u kilku osób.
• Poziom 1: Hasła w password manager (np. KeePass, 1Password Team), ale dzielone bez audytu.
• Poziom 2: Wyznaczeni administratorzy mają osobne konta. SSO wymusza MFA. Brak PAM dedykowanego.
• Poziom 3 (minimum): PAM dla administratorów wszystkich systemów krytycznych. Just-in-time access. Session recording dla produkcji.
• Poziom 4: PAM zintegrowany z SIEM/SOAR. Threat detection w czasie rzeczywistym.
• Poziom 5: Zero standing privileges. Wszystkie dostępy administracyjne są just-in-time.

W audycie 2026 r. każdy podmiot kluczowy NIS2 powinien być minimum na poziomie 3. Mniejsze firmy istotne, minimum poziom 2.

Format ustaleń w raporcie audytu MFA i IAM

Przykład typowego ustalenia o wysokiej klasyfikacji:

Ustalenie MFA-04 (klasyfikacja: wysokie): Konta administratorów (12 kont z uprawnieniami “root” lub “global admin”) nie wymagają phishing-resistant MFA. Akceptowanymi metodami są TOTP i push notification.

Dowody: (1) Wywiad z dyrektorem IT; (2) Konfiguracja MFA w Azure AD/Entra ID (zweryfikowana przez audytora); (3) Polityka MFA z 2023 r., nieaktualizowana po publikacji ENISA Good Practices 2024.

Ryzyko prawne i operacyjne: Naruszenie NIS2 art. 21(2)(j) w wykładni ENISA. Wektory ataku: phishing kradnący TOTP, MFA fatigue na push. Ostatnie naruszenia w branży (Uber 2022, Cisco 2022) pokazują skuteczność tych wektorów. Konsekwencja kompromitacji konta admin: pełen dostęp do systemów krytycznych.

Rekomendacja korygująca: Wprowadzenie phishing-resistant MFA (FIDO2/WebAuthn), YubiKey lub Titan dla 12 administratorów (koszt ~600 zł × 24 sztuki = 14 400 zł + czas wdrożenia 3 tygodnie). Wyłączenie TOTP/push jako metod uwierzytelniania administratorów, pozostają jako fallback dla użytkowników regularnych. Aktualizacja polityki MFA. Termin: 60 dni. Odpowiedzialny: CISO + IT.

Trzy pytania kontrolne dla CISO przed audytem MFA

Pierwsze. Czy mam pełną listę systemów krytycznych z aktualnym stanem MFA? Bez mapy systemów audyt jest słaby. Lista wymaga współpracy z IT, security, biznesem (niektóre systemy są “shadow IT”, kupione przez działy bez wiedzy IT).

Drugie. Czy administratorzy mają phishing-resistant MFA? Jeśli nie, to obszar #1 do interwencji w 2026 r. Koszt sprzętu jest niski (kilka tysięcy zł), korzyść, eliminacja głównego wektora ataków targeted.

Trzecie. Czy mam process access review i czy działa? “Mamy w polityce” to nie odpowiedź. “Ostatnie review było 4 tygodnie temu, znaleziono X zombie permissions, zlikwidowano w Y dni”, to odpowiedź.

Esencja

Audyt MFA i kontroli dostępu pokrywa cztery obszary: pokrycie MFA, jakość metod MFA, zarządzanie tożsamością (IAM), kontrola dostępu uprzywilejowanego (PAM). Każdy obszar wymaga osobnej metodologii dowodów i testów technicznych.

Pokrycie MFA mierzymy ilościowo: jaki procent kont krytycznych, jaki procent kont uprzywilejowanych. Standard 2026: 95%+ administratorów, 80%+ użytkowników ogółem. Wyjątki muszą być udokumentowane z planem likwidacji.

Jakość metod MFA nie jest binarna. SMS to obecnie standard poniżej akceptowalnego, odradzany przez NIST od 2017 r. TOTP/push to średni standard, akceptowalny dla użytkowników regularnych. Phishing-resistant MFA (FIDO2/WebAuthn z hardware tokens) to standard dla administratorów w 2026 r.

IAM jest framugą dla MFA. Off-boarding w czasie poniżej 24 godzin, regularne access review, integracja z SSO, to fundamenty bez których MFA jest dziurawym sitem. Najczęstsza luka: konta w SaaS niezintegrowanych z SSO, których off-boarding wymaga akcji ręcznej, której nikt nie wykonuje.

PAM to ostatnia linia obrony przed atakiem na konto uprzywilejowane. Just-in-time access, session recording, vaulting haseł, to minimum dla podmiotu kluczowego NIS2 w 2026 r.

Phishing-resistant MFA dla administratorów to inwestycja na poziomie kilku tysięcy złotych z drastyczną redukcją ryzyka. Każdy audyt 2026 r. powinien sprawdzić ten obszar w pierwszych dwóch godzinach. Brak = ustalenie wysokie, niezależnie od pozostałych zabezpieczeń.

---

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. (j). https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 32. https://eur-lex.europa.eu/eli/reg/2016/679/oj
• NIST Special Publication 800-63B (2017, revision 4, draft 2024). Digital Identity Guidelines: Authentication and Lifecycle Management. https://doi.org/10.6028/NIST.SP.800-63b
• NIST Special Publication 800-207 (2020). Zero Trust Architecture. https://doi.org/10.6028/NIST.SP.800-207
• ENISA (2024). Good Practices for Multi-Factor Authentication. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications
• FIDO Alliance. FIDO2 / WebAuthn specifications. https://fidoalliance.org/fido2/
• Microsoft Security (2024). Digital Defense Report 2024. https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2024
• CISA (2023). Implementing Phishing-Resistant MFA. Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa
• UODO. Decyzje Prezesa UODO dotyczące art. 32 RODO i uwierzytelniania (2020-2024). https://uodo.gov.pl/pl/138
• Verizon (2024). Data Breach Investigations Report 2024, Authentication chapter. https://www.verizon.com/business/resources/reports/dbir/