Kryptografia, MFA i Zero Trust — wymagania NIS2 w praktyce

Kryptografia i kontrola dostępu to nie są tematy wybierane „do wdrożenia w przyszłym kwartale". W tekście dyrektywy NIS2 pojawiają się wprost jako obowiązkowe środki techniczne — a w praktyce są tym elementem, który najczęściej decyduje o tym, czy atak zatrzymuje się na jednym koncie, czy rozlewa się na całą organizację. Ten przewodnik pokazuje, jak podejść do tego spokojnie: co mówi regulator, co działa w terenie i jak Microsoft 365 pozwala zbudować środowisko Zero Trust bez przepisywania wszystkiego od zera.

Czego wymaga NIS2 w zakresie kryptografii i dostępu

Kluczowy fragment to Art. 21 ust. 2 dyrektywy NIS2 — katalog minimalnych środków zarządzania ryzykiem. Trzy litery są tu krytyczne:

• Lit. e) — bezpieczeństwo w nabywaniu, rozwijaniu i utrzymywaniu systemów informatycznych (w tym zarządzanie podatnościami).
• Lit. f) — polityki i procedury oceny skuteczności środków zarządzania ryzykiem.
• Lit. h) — „polityki i procedury dotyczące stosowania kryptografii oraz, w stosownych przypadkach, szyfrowania".
• Lit. i) — bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i zarządzanie zasobami.
• Lit. j) — „stosowanie uwierzytelniania wieloskładnikowego lub rozwiązań ciągłego uwierzytelniania, zabezpieczonej łączności głosowej, wideo i tekstowej oraz zabezpieczonych systemów łączności awaryjnej w ramach podmiotu, w stosownych przypadkach".

Dyrektywa celowo posługuje się sformułowaniem „odpowiednie środki techniczne, operacyjne i organizacyjne" (Art. 21 ust. 1). Nie podaje listy algorytmów ani producentów — wymaga adekwatności do ryzyka, stanu wiedzy technicznej i kosztu wdrożenia.

Jak interpretuje to regulator (ENISA, polska ustawa KSC 2.0, Rozporządzenie wykonawcze 2024/2690):

• Kryptografia ma być „zgodna z aktualnym stanem wiedzy" — w praktyce: TLS 1.3 preferowany, TLS 1.2 minimum, AES-256 dla danych w spoczynku, SHA-256+ dla haszowania.
• MFA jest wymagane przynajmniej dla dostępu administracyjnego, zdalnego i do aktywów krytycznych (Rozporządzenie wykonawcze 2024/2690 dla dostawców usług cyfrowych — użyteczny benchmark dla wszystkich).
• Kontrola dostępu ma realizować zasadę najmniejszych uprawnień i rozdziału obowiązków.
• Segmentacja sieci nie jest opcjonalna — ma ograniczać rozprzestrzenianie incydentu (lateral movement).

Po polsku: regulator nie każe kupić konkretnego produktu, ale jeśli użyjesz słabego szyfru albo dopuścisz administratora bez MFA, a zdarzy się incydent, nadzór (UKE w przypadku telekomu, sektorowe organy w innych branżach) uzna to za zaniedbanie. Kary sięgają 10 mln EUR lub 2% globalnego obrotu — zgodnie z KSC 2.0.

MFA — podstawa kontroli dostępu

Uwierzytelnianie wieloskładnikowe działa, bo odporność logowania przestaje zależeć tylko od sekretu, który można wykraść (hasła). Atakujący musi zdobyć co najmniej dwa niezależne dowody tożsamości z trzech kategorii:

• Coś wiesz — hasło, PIN.
• Coś masz — klucz sprzętowy FIDO2, telefon z aplikacją, karta smart.
• Coś jesteś — biometria (Windows Hello, Face ID, odcisk palca).

Metody MFA — od najsłabszych do najsilniejszych

Gdzie MFA jest obowiązkowe według NIS2 (i zdrowego rozsądku)

1. Wszystkie konta administracyjne — Global Admin, Domain Admin, konta serwisowe z uprawnieniami.
2. Każdy dostęp zdalny — VPN, RDP, SSH, portale administracyjne.
3. Konta uprzywilejowane — dostęp do danych finansowych, medycznych, PII.
4. Dostęp do systemów krytycznych — systemy sterowania produkcją, SCADA, bazy klientów.
5. Konta zewnętrzne — partnerzy, dostawcy, firmy serwisowe.

Najlepsza praktyka: MFA wszędzie, dla każdego użytkownika. Koszt marginalny jest zerowy (licencje Entra ID P1/P2 w M365 E3/E5 już to zawierają), a ryzyko fizycznie nie jest proporcjonalne.

Pułapki, które trzeba znać

• MFA fatigue attack — atakujący spamuje użytkownika powiadomieniami push, licząc że kliknie „zatwierdź" przez zmęczenie. Rozwiązanie: wymuś number matching w Microsoft Authenticator.
• SIM swap — przejęcie numeru telefonu u operatora. Rozwiązanie: nie używaj SMS jako drugiego składnika dla kont krytycznych.
• Adversary-in-the-middle (AiTM) — strony phishingowe typu Evilginx proxy'ują logowanie i kradną tokeny sesji razem z MFA. Rozwiązanie: klucze FIDO2 są odporne z definicji (weryfikują domenę).
• Token replay — wykradzenie tokena sesji z przeglądarki. Rozwiązanie: Conditional Access z compliance urządzenia + krótsze sesje dla wrażliwych aplikacji.

Kryptografia — szyfrowanie w tranzycie i spoczynku

Szyfrowanie to nie „dodatek" do aplikacji — to warstwa, bez której każdy inny środek bezpieczeństwa ma dziurę.

Dane w tranzycie (data in transit)

• TLS 1.3 jako standard dla wszystkich połączeń WWW, API i aplikacji wewnętrznych. TLS 1.2 akceptowalny tylko tam, gdzie starsze systemy nie wspierają 1.3. TLS 1.0/1.1 — wyłączyć.
• HTTPS wszędzie + HSTS (HTTP Strict Transport Security) — wymuszenie przeglądarki na używanie HTTPS od pierwszego kontaktu.
• VPN: WireGuard lub IKEv2/IPsec z nowoczesnymi szyframi. PPTP, L2TP bez IPsec — wyłączyć.
• Email: TLS dla SMTP (STARTTLS), DKIM + SPF + DMARC, S/MIME lub Microsoft Purview Message Encryption dla wrażliwej korespondencji.
• Wewnętrzne API: mTLS (mutual TLS) dla komunikacji service-to-service.

Dane w spoczynku (data at rest)

• AES-256 jako minimum dla pełnego szyfrowania dysków.
• BitLocker (Windows) — wymuszony przez Intune, z kluczami w Entra ID.
• FileVault (macOS) — zarządzany przez Intune lub Jamf.
• LUKS (Linux) — dla serwerów i stacji roboczych.
• Bazy danych: Transparent Data Encryption (TDE) w SQL Server, Always Encrypted dla kolumn z PII.
• Storage chmurowy: Azure Storage Service Encryption, SharePoint/OneDrive encryption-at-rest domyślnie włączone — dodatkowo customer-managed keys (CMK) dla danych regulowanych.
• Backup: kopie zapasowe szyfrowane, klucze trzymane poza systemem głównym.

Dane w użyciu (data in use)

Najnowsza warstwa ochrony — szyfrowanie danych podczas przetwarzania.

• Confidential Computing — dane nie są widoczne nawet dla administratora hostującego chmury.
• Azure Confidential VMs (AMD SEV-SNP, Intel TDX).
• Azure Confidential Containers — dla workloadów Kubernetes przetwarzających dane medyczne, finansowe, wywiadowcze.

Dla większości organizacji NIS2 to jeszcze nie jest obowiązek. Dla sektora finansowego, zdrowia i administracji rządowej — warto już teraz mapować przypadki użycia.

Zarządzanie kluczami

Szyfrowanie jest tylko tak silne, jak zarządzanie kluczami. Podstawowe wymagania:

• HSM (Hardware Security Module) lub usługa typu Azure Key Vault Premium / AWS KMS dla kluczy krytycznych.
• Rotacja kluczy — minimum raz w roku, w razie podejrzenia kompromitacji natychmiast.
• Separacja kluczy — klucze szyfrowania danych produkcyjnych nie leżą w tym samym miejscu co klucze backupu.
• Audit log — każde użycie klucza krytycznego rejestrowane i przeglądane w SOC.
• Bring Your Own Key (BYOK) / Hold Your Own Key (HYOK) — dla danych regulowanych zostawia klientowi kontrolę nad kluczem, nawet jeśli dane leżą w chmurze dostawcy.

Zero Trust — model nowej generacji

Zero Trust to nie produkt, tylko filozofia architektury bezpieczeństwa. NIS2 nie używa tej nazwy wprost — ale wymagania Art. 21 (MFA, segmentacja, kontrola dostępu, monitoring) w praktyce prowadzą do modelu Zero Trust jako najbardziej naturalnej implementacji.

Pięć zasad Zero Trust

1. Verify explicitly — każde żądanie uwierzytelniane na podstawie wszystkich dostępnych sygnałów: tożsamość, urządzenie, lokalizacja, zachowanie, klasyfikacja danych.
2. Use least privilege access — dostęp just-in-time, just-enough, z risk-based adaptive policies.
3. Assume breach — projektuj tak, jakby atakujący już był w sieci. Minimalizuj promień rażenia przez segmentację, szyfrowanie end-to-end i analitykę.
4. Encrypt everywhere — w tranzycie, w spoczynku, w użyciu.
5. Continuous monitoring — telemetria z każdej warstwy trafia do SOC, analityka wykrywa anomalie w czasie rzeczywistym.

Microsoft Zero Trust Framework — 6 filarów

Każdy filar ma własne polityki i sygnały telemetrii, które razem trafiają do Microsoft Sentinel jako SIEM. Dopiero to daje pełną korelację — i dopiero to daje spełnienie wymagań NIS2 dotyczących wykrywania, raportowania i analizy post-incydent.

Microsoft 365 — Zero Trust out-of-the-box

Dla większości polskich firm objętych NIS2 fundament już leży w licencjach Microsoft 365 E3/E5. Problem nie w braku narzędzi — problem w konfiguracji.

Kluczowe polityki Conditional Access (Entra ID)

Minimalny zestaw, który każda organizacja NIS2 powinna wdrożyć:

1. Block legacy authentication — wyłączenie uwierzytelniania bez MFA (POP, IMAP, SMTP AUTH, starszych klientów Office).
2. MFA dla wszystkich użytkowników — baza.
3. MFA dla administratorów (wszystkie role uprzywilejowane) — z wymuszonym kluczem FIDO2 lub Windows Hello for Business.
4. Block access from high-risk countries — geofencing dla krajów, w których firma nie operuje.
5. Require compliant device — dostęp tylko z urządzeń zgodnych z politykami Intune.
6. Require hybrid Azure AD join or compliant — dla aplikacji wrażliwych.
7. Session controls — krótsze sesje dla aplikacji finansowych, HR, administracyjnych.
8. Risk-based policies (P2) — Sign-in risk + User risk jako dodatkowe sygnały Identity Protection.

Intune — compliance urządzeń

Polityki zgodności, które warunkują dostęp:

• Szyfrowanie dysku włączone (BitLocker/FileVault).
• Wersja systemu operacyjnego aktualna (Windows 11 23H2+, macOS 14+).
• Defender for Endpoint aktywny i zdrowy.
• Brak jailbreak/root (urządzenia mobilne).
• Hasło/PIN ustawione, auto-lock ≤ 15 min.

Defender for Cloud Apps (CASB)

• Shadow IT discovery — wykrywanie niezatwierdzonych aplikacji SaaS.
• Session controls dla aplikacji z Entra ID — blokowanie pobierania danych wrażliwych.
• Anomaly detection — nietypowe logowania, masowe pobieranie plików, niemożliwe podróże.

Microsoft Purview — dane pod kontrolą

• Sensitivity labels — ręczna i automatyczna klasyfikacja dokumentów i maili.
• Data Loss Prevention (DLP) — blokowanie wycieku PII, danych medycznych, kart kredytowych.
• Insider Risk Management — sygnały ryzyka wewnętrznego (pracownik na wypowiedzeniu, masowe pobieranie).
• eDiscovery Premium — spełnienie wymagań retencji i prawnych.

Defender XDR + Microsoft Sentinel

Warstwa wykrywania i odpowiedzi:

• Defender XDR — korelacja sygnałów z Endpoint, Office 365, Identity, Cloud Apps.
• Sentinel — SIEM zbierający logi z całego środowiska (M365, Azure, on-prem, third-party).
• Automated Response — playbooki SOAR odcinające konto, blokujące IP, kwarantannujące urządzenie.

To jest dokładnie warstwa, którą NIS2 Art. 21 lit. b) (obsługa incydentów) i lit. g) (monitorowanie) wymagają mieć operacyjnie — czyli działającą 24/7, nie tylko zainstalowaną.

Privileged Access Management (PAM)

Konta administracyjne to cel numer jeden każdego atakującego. Ransomware nie paraliżuje firmy przez konto księgowej — paraliżuje ją przez przejęcie Domain Admina. Stąd osobna dyscyplina: PAM.

Just-In-Time access (JIT)

Administrator nie ma uprawnień Global Admin cały czas. Aktywuje je na godzinę, z uzasadnieniem i zatwierdzeniem.

W Microsoft 365: Privileged Identity Management (PIM) w Entra ID P2.

• Role eligible zamiast active.
• Czas aktywacji 1–8h.
• MFA + uzasadnienie + opcjonalna zgoda drugiej osoby.
• Pełny audit log każdej aktywacji.

Just Enough Administration (JEA)

Administrator PowerShell nie ma pełnych uprawnień — tylko te, które są potrzebne do konkretnego zadania.

Implementacja: JEA endpoints w PowerShell, role-based access w Azure, Azure RBAC z custom roles.

Privileged Access Workstations (PAW)

Osobne, zahartowane stacje robocze do administracji środowiska krytycznego:

• Tylko narzędzia admin, bez przeglądarki ogólnego użytku, poczty prywatnej, Teams.
• Brak dostępu do internetu poza allowlist (portale Microsoft, Azure, on-prem).
• Szyfrowane, aktualne, monitorowane dodatkowo.
• Dostęp do PAW przez klucz FIDO2 + Windows Hello.

Rozwiązania PAM

• Microsoft Entra PIM — wbudowane w M365 E5 / Entra ID P2, pokrywa większość scenariuszy.
• CyberArk, Delinea (Thycotic), BeyondTrust — dla środowisk z dużym legacy on-prem, kontami serwisowymi, bazami danych, dostępem do serwerów.

Jak SecIQ wdraża Zero Trust

Zero Trust to nie „kup produkt, wdróż i zapomnij". To 3–6 miesięcy pracy architektonicznej, a potem ciągła operacja. Nasza procedura:

1. Audyt obecnego stanu (gap analysis) — ocena dojrzałości w 6 filarach Microsoft Zero Trust. Wynik: mapa braków, priorytet, oszacowanie kosztu i czasu.
2. Roadmap 3–6 miesięcy — kolejność wdrożenia dopasowana do ryzyka i dostępnych licencji M365. Zwykle: najpierw tożsamość (Conditional Access, MFA, PIM), potem urządzenia (Intune compliance), potem dane (Purview), potem sieć (Global Secure Access).
3. Konfiguracja M365 Zero Trust baseline — wdrożenie polityk Conditional Access, Intune, Defender XDR, Sentinel. Rollout z fazą pilotażową, żeby nie zablokować firmy.
4. Szyfrowanie danych — BitLocker, Sensitivity Labels, DLP, ochrona poczty. Rozdzielenie danych publicznych / wewnętrznych / poufnych / ściśle poufnych.
5. Monitoring w SOC 24/7 — telemetria z M365 trafia do Sentinel, analitycy reagują w minutach, nie dniach. Dedykowany zespół, który zna Twoje środowisko — nie anonimowy L1.
6. Raportowanie dla zarządu i regulatora — kwartalne podsumowania stanu zgodności NIS2, incydentów, trendów.

Więcej o naszym podejściu w usługach: Zero Trust, Ochrona tożsamości, Szyfrowanie danych.

Checklist — ocena dojrzałości kryptografii i dostępu

Odpowiedz TAK/NIE na poniższe pytania. Każde TAK = 1 punkt.

MFA (5 punktów)

1. Czy wszyscy administratorzy (Global Admin, Domain Admin, serwisowi) mają wymuszone MFA?
2. Czy dostęp zdalny (VPN, RDP) wymaga MFA?
3. Czy MFA jest włączone dla wszystkich użytkowników końcowych?
4. Czy używacie phishing-resistant MFA (FIDO2/passkeys) dla kont uprzywilejowanych?
5. Czy legacy authentication (POP, IMAP, SMTP AUTH) jest zablokowane?

Szyfrowanie (5 punktów) 6. Czy wszystkie dyski laptopów i stacji roboczych są szyfrowane (BitLocker/FileVault/LUKS)? 7. Czy wszystkie aplikacje webowe używają TLS 1.2+ (optymalnie 1.3) z HSTS? 8. Czy bazy danych z PII mają włączone szyfrowanie (TDE lub column-level)? 9. Czy klucze kryptograficzne są w HSM lub usłudze typu Azure Key Vault? 10. Czy klucze są rotowane minimum raz w roku?

Zero Trust / Access Control (5 punktów) 11. Czy macie wdrożone polityki Conditional Access (lub odpowiednik) z sygnałami urządzenia i lokalizacji? 12. Czy urządzenia mają wymuszony compliance (Intune lub odpowiednik) zanim dostaną dostęp? 13. Czy konta uprzywilejowane używają JIT (Privileged Identity Management)? 14. Czy sieć jest segmentowana, a dostęp do systemów krytycznych ograniczony z bastionów/PAW? 15. Czy telemetria z tożsamości, urządzeń i aplikacji trafia do SIEM/SOC 24/7?

Interpretacja wyniku

• 13–15 punktów — dojrzałe Zero Trust. NIS2 Art. 21 lit. h/i/j spełnione. Skup się na ciągłym doskonaleniu: threat hunting, red team, Confidential Computing.
• 9–12 punktów — dobra baza, ale są luki. Najczęściej: brak JIT, brak phishing-resistant MFA dla adminów, niepełna klasyfikacja danych. 3–6 miesięcy pracy.
• 5–8 punktów — częściowe wdrożenie. Masz MFA i BitLocker, ale brakuje Conditional Access, PIM, DLP. Wymagane wdrożenie pełnej architektury — 6–12 miesięcy.
• 0–4 punkty — wysokie ryzyko regulacyjne i operacyjne. Audyt + roadmap + sponsor projektu po stronie zarządu. Nie da się tego zrobić w tle.

Kryptografia i kontrola dostępu nie są w NIS2 po to, żeby uprzykrzyć życie. Są tam, bo bez nich cała reszta — monitoring, raportowanie incydentów, ciągłość działania — traci sens. Ktoś z kluczem od frontowych drzwi i tak wejdzie, niezależnie od tego, ile kamer powiesisz w salonie.

Jeśli chcesz zrobić audyt swojej dojrzałości Zero Trust i ułożyć realistyczny plan na najbliższe 6 miesięcy — umów rozmowę z naszym zespołem. Zaczynamy od gap analysis, kończymy monitoringiem 24/7 w SOC.

Źródła

• Dyrektywa NIS2 (UE 2022/2555), Art. 21 — katalog minimalnych środków zarządzania ryzykiem.
• Rozporządzenie wykonawcze Komisji (UE) 2024/2690 — techniczne wymagania NIS2 dla dostawców usług cyfrowych.
• NIST SP 800-63B — Digital Identity Guidelines — standard dla uwierzytelniania i MFA.
• Microsoft Zero Trust Documentation — referencyjna architektura Zero Trust dla M365 i Azure.
• ENISA — Cryptographic Guidelines — europejskie rekomendacje dotyczące algorytmów i protokołów kryptograficznych.
• CISA — Zero Trust Maturity Model v2.0 — model dojrzałości Zero Trust z pięcioma filarami.