Ład nad Microsoft Entra Conditional Access w 2026 roku

Jest wtorek, godzina 09:12, gdy Maria, dyrektor ds. bezpieczeństwa informacji w szybko rosnącej europejskiej spółce fintech, otwiera raport gotowości do DORA, który powinien być rutynowy. Jej pulpit Microsoft Entra Conditional Access wygląda solidnie. MFA jest wymuszane dla administratorów. Uwierzytelnianie starszego typu jest blokowane. Logowania wysokiego ryzyka są poddawane dodatkowemu sprawdzeniu albo odrzucane. Wrażliwe aplikacje finansowe wymagają urządzeń zgodnych z wymaganiami. Dostęp przez przeglądarkę z niezarządzanych punktów końcowych jest ograniczony.

Następnie czyta ustalenie audytora.

„Reguły Conditional Access są technicznie poprawne, ale funkcjonują w próżni. Proszę wskazać politykę zatwierdzoną przez zarząd, która wymaga tych ustawień. Proszę pokazać zapis zmiany dla reguły zmodyfikowanej w zeszłym miesiącu. Proszę wykazać, że polityka dotycząca logowań wysokiego ryzyka była aktywna w czasie podejrzewanego ataku credential stuffing. Proszę pokazać, w jaki sposób te dowody wspierają ISO 27001, DORA, NIS2 i GDPR.”

Zespół ds. tożsamości może wyeksportować konfigurację. SOC może pokazać logi logowania. Menedżer ds. zgodności może wskazać folder z politykami. Nikt jednak nie potrafi przedstawić jednej, zarządzanej narracji dowodowej, która łączy ryzyko, politykę, zatwierdzenie, konfigurację, wyjątki, monitorowanie, reagowanie na incydenty, obowiązki w zakresie prywatności i przegląd zarządzania.

To jest problem ładu nad Conditional Access w 2026 roku.

Microsoft Entra Conditional Access nie jest już tylko ustawieniem tożsamości. To system środków kontrolnych na poziomie zarządu, który decyduje, kto może uzyskać dostęp do usług chmurowych, w jakich warunkach, z jakich urządzeń, przy jakiej sile uwierzytelniania i z jakimi ograniczeniami sesji. W organizacjach regulowanych decyzje te muszą być wyjaśnialne, możliwe do obrony i zmapowane na obowiązki wynikające z ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST i COBIT 2019.

Conditional Access jest obecnie audytowalnym systemem środków kontrolnych

Conditional Access znajduje się na styku tożsamości, stanu bezpieczeństwa urządzenia, wrażliwości aplikacji, lokalizacji, ryzyka logowania, ryzyka użytkownika, zachowania sesji i rejestrowania. Jedna polityka może wymagać MFA, wymagać urządzenia zgodnego z wymaganiami, blokować dostęp z ryzykownej lokalizacji, ograniczać pobieranie z niezarządzanych przeglądarek albo wymuszać ponowne uwierzytelnianie, gdy zmienia się poziom ryzyka.

Czyni go to jednym z najsilniejszych punktów wymuszania Zero Trust w środowiskach chmurowych Microsoft. Jednocześnie sprawia, że podlega on szczególnie wnikliwej kontroli audytowej.

Zgodnie z ISO/IEC 27001:2022 środek kontrolny nie jest dojrzały tylko dlatego, że istnieje w portalu. Organizacja musi rozumieć swój kontekst, oceniać ryzyka bezpieczeństwa informacji, wybierać sposoby postępowania z ryzykiem, dokumentować Deklarację stosowania, obsługiwać środki kontrolne, monitorować ich skuteczność i doskonalić je w czasie. Istotne klauzule obejmują Clause 6.1.2 dotyczącą oceny ryzyka, Clause 6.1.3 dotyczącą postępowania z ryzykiem, Clause 7.5 dotyczącą udokumentowanych informacji, Clause 8.1 dotyczącą planowania i kontroli operacyjnej, Clause 9.1 dotyczącą monitorowania oraz Clause 9.3 dotyczącą przeglądu zarządzania.

Załącznik A, zgodny z ISO/IEC 27002:2022, zawiera praktyczny język środków kontrolnych rozpoznawalny dla audytorów. Conditional Access zwykle wspiera:

• 5.15 kontrola dostępu
• 5.16 zarządzanie tożsamością
• 5.17 informacje uwierzytelniające
• 5.18 prawa dostępu
• 8.1 urządzenia końcowe użytkowników
• 8.2 uprawnienia dostępu uprzywilejowanego
• 8.3 ograniczenie dostępu do informacji
• 8.5 bezpieczne uwierzytelnianie
• 8.15 rejestrowanie
• 8.16 działania monitorujące

W przypadku organizacji regulowanych w UE ciężar odpowiedzialności zarządczej jest jeszcze bardziej oczywisty. NIS2 Article 20 nakłada na organy zarządzające odpowiedzialność za zatwierdzanie i nadzorowanie środków zarządzania ryzykiem cyberbezpieczeństwa. NIS2 Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym kontroli dostępu, zarządzania aktywami, cyberhigieny, obsługi incydentów, bezpieczeństwa łańcucha dostaw, oceny skuteczności oraz uwierzytelniania wieloskładnikowego lub ciągłego uwierzytelniania tam, gdzie jest to właściwe. NIS2 Article 23 wprowadza etapowe zgłaszanie istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy w ciągu miesiąca.

DORA ustanawia podobne oczekiwania wobec podmiotów finansowych. Article 5 wymaga wewnętrznych ram ładu zarządczego i kontroli. Article 6 wymaga ram zarządzania ryzykiem ICT. Article 9 dotyczy ochrony i zapobiegania, w tym ograniczeń dostępu i praktyk zarządzania tożsamością. Articles 10, 11, 17, 18 i 19 łączą wykrywanie, reakcję, odzyskiwanie, zarządzanie incydentami ICT, klasyfikację i raportowanie. Ponieważ DORA obowiązuje od 17 stycznia 2025 r., podmioty finansowe powinny traktować Conditional Access jako część dowodów odporności operacyjnej, a nie wyłącznie jako utwardzanie tożsamości.

GDPR dodaje perspektywę prywatności. Jeżeli Conditional Access chroni systemy przetwarzające dane osobowe, wspiera zasady rozliczalności z Article 5, odpowiedzialność administratora z Article 24, ochronę danych w fazie projektowania z Article 25 oraz bezpieczeństwo przetwarzania z Article 32. Jeżeli podejrzewany jest nieuprawniony dostęp, logi Conditional Access mogą stać się częścią dowodów na potrzeby oceny naruszenia i powiadomień.

Błędem jest traktowanie tych elementów jako oddzielnych żądań audytowych. Dojrzałe podejście to jeden model ładu nad Conditional Access, który można przedstawić z perspektywy ram, regulatora, klienta albo zarządu.

Konfiguracja nie jest ładem

Większość organizacji potrafi odpowiedzieć na pytanie: „Co jest skonfigurowane?”. Mniej organizacji potrafi odpowiedzieć na trudniejsze pytania:

• Dlaczego ta polityka Conditional Access jest skonfigurowana w taki sposób?
• Który scenariusz ryzyka jest przez nią obsługiwany?
• Która klauzula polityki jej wymaga?
• Kto zatwierdził zmianę?
• Którzy użytkownicy, które aplikacje i urządzenia są wyłączone?
• Jak jest testowana?
• Jakie logi potwierdzają, że zadziałała?
• Jak często jest przeglądana?
• Co dzieje się, gdy zawiedzie?

To właśnie tutaj zwykle pojawiają się ustalenia z audytu. Polityki istnieją, ale nie są powiązane z ustawieniami Microsoft Entra. Zgodność urządzeń należy do operacji IT, ale nie jest mapowana na ryzyko kontroli dostępu. Polityki ryzyka logowania są włączone bez udokumentowanych progów ani zasad eskalacji. Ograniczenia sesji są skonfigurowane, ale nigdy nie są testowane z niezarządzanych urządzeń. Logi są przechowywane, ale nie są przygotowywane jako dowody audytowe.

Clarysec traktuje to jako problem identyfikowalności. Każda decyzja Conditional Access powinna łączyć politykę, ryzyko, środek kontrolny, konfigurację, dowód i przegląd.

Polityka korzystania z chmury dla SME Polityka korzystania z chmury — SME stanowi:

Uwierzytelnianie wieloskładnikowe (MFA) dla kont administracyjnych i użytkowników

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.2.

Ta klauzula jest mandatem. Reguła Conditional Access jest mechanizmem wymuszenia. Log logowania jest dowodem. Zapis przeglądu potwierdza nadzór.

Polityka bezpieczeństwa sieci dla SME Polityka bezpieczeństwa sieci — SME dodaje wymaganie dotyczące stanu bezpieczeństwa punktu końcowego:

Systemy bez aktualnego oprogramowania antywirusowego, poprawek lub akceptowalnego stanu bezpieczeństwa urządzenia muszą być blokowane albo poddawane kwarantannie

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.3.

W terminologii Microsoft Entra może to przyjąć postać „wymagaj urządzenia zgodnego z wymaganiami”, „blokuj nieobsługiwane platformy”, „ograniczaj sesje niezarządzanych przeglądarek” albo „odmawiaj dostępu do aplikacji wysokiego ryzyka z nieznanych urządzeń”. Środek kontrolny nie jest jednak kompletny, dopóki organizacja nie potrafi wykazać zakresu, zatwierdzenia, testowania, wyjątków i monitorowania.

Zbuduj podstawy ładu przed zestawem reguł

Silny program Conditional Access zaczyna się poza portalem Entra. Zaczyna się od SZBI, rejestru ryzyk, Polityki kontroli dostępu, Polityki korzystania z chmury, SoA oraz modelu dowodowego.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint podaje praktyczną sekwencję działań. W fazie zarządzania ryzykiem, w kroku 13 „Planowanie postępowania z ryzykiem i Deklaracja stosowania”, instruuje organizacje, aby łączyły środki kontrolne z ryzykami i czynnikami regulacyjnymi:

Odwołania krzyżowe do regulacji: jeżeli określone środki kontrolne są wdrażane specjalnie w celu spełnienia wymagań GDPR, NIS2 lub DORA, można odnotować to w rejestrze ryzyk (jako część uzasadnienia wpływu ryzyka) albo w notatkach SoA.

W przypadku Conditional Access zmienia to narrację dowodową. Zamiast mówić „Włączyliśmy MFA”, organizacja może powiedzieć:

• Scenariusz ryzyka: naruszone dane uwierzytelniające użytkownika umożliwiają nieuprawniony dostęp do danych klientów w Microsoft 365 i finansowych systemach SaaS.
• Właściciel ryzyka: kierownik ds. bezpieczeństwa IT.
• Postępowanie z ryzykiem: Entra Conditional Access wymaga silnego MFA dla ról uprzywilejowanych, MFA dla użytkowników, blokowania logowań ryzykownych, urządzeń zgodnych z wymaganiami dla wrażliwych aplikacji oraz ograniczeń sesji dla niezarządzanych punktów końcowych.
• Mapowanie ISO/IEC 27002:2022: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 i 8.16.
• Mapowanie regulacyjne: NIS2 Articles 20, 21 i 23, DORA Articles 5, 6, 9, 10, 17 i 18, GDPR Articles 24, 25, 32 i 33.
• Dowody: zatwierdzenie polityki, eksport Conditional Access, zgłoszenie zmiany, wyniki testów, logi logowania, raporty zgodności urządzeń, Rejestr wyjątków, zgłoszenia SOC i protokoły z przeglądu zarządzania.

Zenith Blueprint wyjaśnia również w fazie „Środki kontrolne w działaniu”, w kroku 19, dlaczego stan bezpieczeństwa punktu końcowego powinien być częścią decyzji dostępowej:

Dostęp do informacji za pośrednictwem punktów końcowych musi uwzględniać kontekst. Na przykład: czy urządzenie spełnia minimalne standardy bezpieczeństwa przed uzyskaniem dostępu do zasobów organizacji? Czy niedawno przeszło skanowanie pod kątem złośliwego oprogramowania? Czy łączy się z nietypowej lokalizacji lub sieci? Integracja z zasadami Zero Trust pozwala, aby stan bezpieczeństwa punktu końcowego zasilał conditional access i odmawiał wejścia, dopóki urządzenie nie potwierdzi, że jest bezpieczne.

To podstawowa zasada ładu. Conditional Access powinien być oparty na ryzyku, uwzględniać kontekst i generować dowody.

Mapuj decyzje Conditional Access na cele środków kontrolnych

Dojrzały program definiuje standardowe decyzje dostępowe, a następnie mapuje każdą z nich na intencję zarządczą i dowody. Ogranicza to rozrost polityk i ułatwia rozmowy audytowe.

Polityka korzystania z chmury dla przedsiębiorstw Polityka korzystania z chmury wspiera integrację z centralną tożsamością:

Integracja Single Sign-On (SSO) z dostawcą tożsamości organizacji jest wymagana w celu zapewnienia spójności uwierzytelniania.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.4.

Polityka zarządzania kontami użytkowników i uprawnieniami dla przedsiębiorstw Polityka zarządzania kontami użytkowników i uprawnieniami wprost określa monitorowanie:

Korzystanie z systemów Single Sign-On (SSO) musi być zintegrowane z centralnymi dostawcami tożsamości (np. Active Directory (AD), Azure AD) i monitorowane pod kątem anomalii w zachowaniu logowania.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.3.4.

Łącznie te klauzule wymagają więcej niż SSO. Wymagają centralnej architektury tożsamości, spójnego uwierzytelniania, monitorowania anomalii w zachowaniu logowania oraz dowodów, że decyzje dostępowe są przeglądane.

Zgodność urządzeń: środek kontrolny, który audytorzy mogą przetestować

Zgodność urządzeń jest jednym z obszarów, których skuteczność najłatwiej przecenić. Pulpit może pokazywać 92 procent urządzeń zgodnych z wymaganiami, ale audytor zapyta, czy reguła obejmuje aplikacje, które mają znaczenie, czy urządzenia prywatne są dozwolone, czy nieobsługiwane platformy są blokowane oraz czy wyjątki są zatwierdzane.

Polityka pracy zdalnej dla przedsiębiorstw Polityka pracy zdalnej ustanawia bazowy wymóg zatwierdzenia:

Urządzenia BYOD muszą być jednoznacznie zatwierdzone oraz:

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.2.2.

To krótkie zdanie ma znaczenie. BYOD nie jest tylko stanem technicznym. Jest decyzją zarządczą. W Conditional Access powinno przekładać się na reguły własności urządzeń, minimalne wymagania zgodności, wymagania szyfrowania, kontrole poprawek i ochrony przed złośliwym oprogramowaniem, ochronę aplikacji mobilnych, obsługę wykonawców i przegląd wyjątków.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls mapuje środek kontrolny ISO/IEC 27002:2022 5.15 kontrola dostępu jako zapobiegawczy, chroniący poufność, integralność i dostępność w zdolności operacyjnej zarządzania tożsamością i dostępem. Łączy również kontrolę dostępu z urządzeniami końcowymi użytkowników, ponieważ niezarządzane laptopy, urządzenia mobilne i komputery stacjonarne mogą osłabiać scentralizowane egzekwowanie dostępu.

Praktyczny kwartalny pakiet dowodów dotyczących urządzeń dla Conditional Access powinien obejmować:

• Zatwierdzoną konfigurację bazową zgodności urządzeń.
• Polityki Conditional Access wymagające urządzeń zgodnych z wymaganiami.
• Aplikacje chronione tymi politykami.
• Eksport wyłączonych użytkowników, grup, aplikacji i platform.
• Raport trendów dla urządzeń niezgodnych z wymaganiami.
• Przykładowe logi zablokowanych logowań dla urządzeń niezgodnych z wymaganiami.
• Rejestr wyjątków z właścicielem, powodem, datą wygaśnięcia i akceptacją ryzyka.
• Zapis przeglądu zarządzania.

Ten pakiet dowodów wspiera kontrolę operacyjną ISO/IEC 27001:2022, cyberhigienę NIS2, ochronę i zapobieganie w DORA oraz rozliczalność GDPR.

Ryzyko logowania: wykrywanie musi stać się dowodem decyzji

Conditional Access oparty na ryzyku to miejsce, w którym wykrywanie związane z tożsamością staje się nadzorem nad dostępem. Microsoft Entra może oceniać sygnały takie jak nietypowe właściwości logowania, anonimowe adresy IP, niemożliwa podróż i ujawnione dane uwierzytelniające. Audytorzy nie zaakceptują jednak odpowiedzi „polityka ryzyka jest włączona” jako odpowiedzi końcowej. Zapytają, dlaczego wybrano konkretne progi, kto przegląda zdarzenia ryzykowne i kiedy logowanie wysokiego ryzyka staje się incydentem.

Polityka rejestrowania i monitorowania dla SME Polityka rejestrowania i monitorowania — SME definiuje minimalny wymóg rejestrowania:

Logi uwierzytelniania: udane i nieudane próby logowania, czas trwania sesji, użycie MFA

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4.2.

Polityka rejestrowania i monitorowania dla przedsiębiorstw Polityka rejestrowania i monitorowania rozszerza oczekiwany zestaw zdarzeń:

Typy zdarzeń do rejestrowania (np. logowania, niepowodzenia dostępu, zmiany konfiguracji, polecenia administracyjne, wykrycie złośliwego oprogramowania)

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.1.

W przypadku Conditional Access użyteczne dowody powinny obejmować udane logowania, nieudane logowania, wynik polityki Conditional Access, metodę MFA, ryzyko logowania, ryzyko użytkownika, stan zgodności urządzenia, aplikację, do której uzyskano dostęp, lokalizację, aplikację kliencką, wynik kontroli sesji, historię zmian polityki i działania administracyjne.

Zenith Controls mapuje środek kontrolny ISO/IEC 27002:2022 8.16 działania monitorujące jako detekcyjny i korygujący, powiązany z koncepcjami Detect i Respond. Łączy monitorowanie z rejestrowaniem, oceną zdarzeń, informacjami o zagrożeniach, monitorowaniem dostawców i zarządzaniem incydentami. Mapuje również działania monitorujące do GDPR Articles 32 i 33, monitorowania i raportowania incydentów NIS2, śledzenia incydentów ICT w DORA, ciągłego monitorowania NIST oraz monitorowania bezpieczeństwa COBIT.

Logowanie wysokiego ryzyka zablokowane przez Conditional Access nie jest więc tylko sukcesem bezpieczeństwa. Jest dowodem, że procesy zapobiegawcze, detekcyjne i reakcyjne są połączone.

Kontrole sesji: łącznik między dostępem a ochroną danych

Decyzje przed dostępem nie wystarczają. Po uwierzytelnieniu użytkownika kontrole sesji określają, jaka ekspozycja pozostaje. Ma to szczególne znaczenie dla urządzeń niezarządzanych, wykonawców, pracy zdalnej, współdzielonych terminali, ryzykownych lokalizacji i aplikacji przetwarzających dane osobowe.

Polityka wymagań bezpieczeństwa aplikacji dla SME Polityka wymagań bezpieczeństwa aplikacji — SME stanowi:

Zarządzanie sesją: dane sesji muszą wygasać po 15 minutach bezczynności i, w stosownych przypadkach, obejmować ostrzeżenia o przekroczeniu limitu czasu.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.3.

W zarządzaniu Microsoft Entra może to mapować się na częstotliwość logowania, ograniczenia trwałych sesji przeglądarki, Conditional Access App Control, ograniczenia wymuszane przez aplikację, blokowanie pobierania, ponowne uwierzytelnianie po zmianach ryzyka i ograniczenia sesji oparte na wrażliwości.

Kontrole sesji wspierają środek kontrolny ISO/IEC 27002:2022 8.3 ograniczenie dostępu do informacji oraz 8.5 bezpieczne uwierzytelnianie. Wspierają również GDPR Article 32 poprzez ograniczenie nieuprawnionego przeglądania, pobierania lub utrzymywania dostępu do danych osobowych. W przypadku DORA ograniczenia sesji pomagają ograniczyć ekspozycję w systemach ICT oraz wspierają wykrywanie i reakcję. W przypadku NIS2 są proporcjonalnymi środkami kontroli dostępu i cyberhigieny.

Dowody powinny wyjaśniać, dlaczego kontrola sesji istnieje. Na przykład „blokowanie pobierania z niezarządzanych urządzeń dla aplikacji HR i finansowych” powinno mapować się na wyciek danych osobowych, naruszenie bezpieczeństwa punktu końcowego i utratę poufności. Dowody powinny obejmować konfigurację, zakres aplikacji, testowe logowania z urządzeń zarządzanych i niezarządzanych, logi pokazujące ograniczenia oraz zapisy zatwierdzeń.

Utwórz Rejestr kontroli Conditional Access

Rejestr kontroli Conditional Access jest operacyjnym pomostem między rejestrem ryzyk, Deklaracją stosowania i konfiguracją Microsoft Entra. Nie zastępuje tych dokumentów. Sprawia, że można z nich praktycznie korzystać.

Stosuj pięcioetapowy cykl przeglądu:

1. Potwierdź zakres: zidentyfikuj aplikacje chmurowe przetwarzające dane regulowane, finansowe, operacyjne lub osobowe.
2. Mapuj polityki na ryzyka: powiąż każdą politykę Conditional Access z co najmniej jednym scenariuszem ryzyka i jednym właścicielem ryzyka.
3. Zweryfikuj wyłączenia: wyeksportuj wyłączonych użytkowników, role, aplikacje, grupy, lokalizacje i urządzenia. Każde wyłączenie wymaga właściciela, powodu, zatwierdzenia i daty wygaśnięcia.
4. Przetestuj egzekwowanie: użyj kont testowych do weryfikacji MFA, zgodności urządzeń, blokowania ryzyka, blokowania uwierzytelniania starszego typu i ograniczeń sesji.
5. Przygotuj pakiet dowodowy: przechowuj eksporty, zrzuty ekranu, logi i zatwierdzenia wraz z metadanymi.

Polityka audytu i monitorowania zgodności dla SME Polityka audytu i monitorowania zgodności — SME ma krytyczne znaczenie dla integralności materiału dowodowego:

Metadane (np. kto je zebrał, kiedy i z którego systemu) muszą być udokumentowane.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.3.

Zrzuty ekranu bez źródła, daty, osoby zbierającej i kontekstu systemu są słabym dowodem. Eksporty Conditional Access, logi logowania i raporty z przeglądów należy traktować jako kontrolowane zapisy audytowe.

Mapowanie dowodów Conditional Access na wiele ram

Wartość Conditional Access polega na tym, że jeden zestaw środków kontrolnych może spełniać kilka perspektyw audytowych, jeżeli jest właściwie zarządzany.

Zenith Controls mapuje również 5.15 kontrola dostępu na GDPR Article 32, NIS2 Article 21(2)(i), koncepcje nadzoru nad dostępem w DORA, rodziny kontroli dostępu NIST SP 800-53 oraz COBIT 2019 DSS06.04. Mapuje 8.5 bezpieczne uwierzytelnianie na GDPR Articles 5, 24, 25 i 32, zarządzanie ryzykiem cyberbezpieczeństwa NIS2, zarządzanie ryzykiem ICT DORA, identyfikację i uwierzytelnianie NIST oraz tożsamość i dostęp logiczny COBIT.

Wniosek jest prosty. Ramy używają różnych pojęć, ale oczekują tego samego wzorca zapewnienia: właściwi użytkownicy, z akceptowalnych kontekstów, przy użyciu silnego uwierzytelniania, przez zarządzane sesje, z logami potwierdzającymi, co się wydarzyło.

Jak audytorzy będą badać Conditional Access

Audytor ISO/IEC 27001:2022 zacznie od SZBI. Zapyta, czy Conditional Access jest objęty zakresem, jakie ryzyka obsługuje, jak jest ujęty w SoA, jak zatwierdzane są polityki, jak kontrolowane są zmiany oraz czy dowody potwierdzają skuteczność operacyjną. Należy spodziewać się próbkowania użytkowników uprzywilejowanych, aplikacji wrażliwych, wyłączeń i ostatnich zmian polityk.

Audytor DORA lub NIS2 skoncentruje się na odporności operacyjnej, rozliczalności kierownictwa i ryzyku. Może zapytać, jak środki kontroli dostępu chronią funkcje krytyczne lub ważne, jak zarząd nadzoruje ryzyko tożsamości, jak logowania wysokiego ryzyka są poddawane triage oraz czy niepowodzenia dostępu zasilają klasyfikację incydentów lub decyzje o raportowaniu.

Audytor skoncentrowany na GDPR będzie zainteresowany danymi osobowymi. Może zapytać, jak dane HR, finansowe lub klientów są chronione przed dostępem z niezarządzanych urządzeń, jak kontrole sesji ograniczają nieuprawnione przeglądanie, jak dostęp jest ograniczony do uprawnionych użytkowników oraz jak logi wspierają ocenę naruszenia.

Recenzent COBIT 2019 będzie szukał praktyk zarządczych, własności, metryk, powtarzalności, monitorowania wyników i doskonalenia. Asesor zorientowany na NIST porówna wyniki w zakresie tożsamości, uwierzytelniania, autoryzacji, monitorowania i reakcji z dowodami technicznymi.

Polityka kontroli dostępu dla przedsiębiorstw Polityka kontroli dostępu wyznacza kierunek dla dostępu uprzywilejowanego:

Dostęp administracyjny musi być ściśle kontrolowany poprzez:

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4.1.

Dowody Microsoft Entra muszą operacyjnie uzupełniać to zdanie. Które role są uprzywilejowane? Które wymagają MFA odpornego na phishing lub silnego MFA? Które są kwalifikowalne poprzez zarządzanie tożsamością uprzywilejowaną? Które konta są typu „break glass”? Które są wyłączone z polityk? Kto je przegląda? Dokąd wysyłane są alerty?

Metryki zarządcze dla ładu nad Conditional Access

Ponieważ NIS2 i DORA podkreślają rozliczalność kierownictwa, raportowanie Conditional Access powinno być zrozumiałe dla zarządu. Należy unikać raportowania samych nazw polityk. Raportuj profil ryzyka i skuteczność kontroli.

Użyteczne metryki obejmują:

• Odsetek kont uprzywilejowanych chronionych silnym MFA.
• Liczbę wyłączeń Conditional Access według poziomu ryzyka.
• Liczbę logowań wysokiego ryzyka zablokowanych, poddanych dodatkowemu sprawdzeniu lub dopuszczonych.
• Odsetek dostępu do aplikacji wrażliwych wymagający urządzeń zgodnych z wymaganiami.
• Liczbę sesji z urządzeń niezarządzanych do aplikacji regulowanych.
• Czas triage zdarzeń logowania wysokiego ryzyka.
• Liczbę zmian polityk Conditional Access w kwartale.
• Liczbę wyjątków wygasłych, odnowionych i przeterminowanych.
• Pokrycie rejestrowaniem uwierzytelniania, sesji i zmian polityk.
• Nieudane przypadki testowe z kwartalnej walidacji Conditional Access.

Te metryki przekształcają konfigurację tożsamości w dowody nadzoru. Pomagają również organom zarządzającym wykazać zatwierdzenie, przegląd, zapewnienie zasobów i ciągłe doskonalenie.

Typowe ustalenia do wyeliminowania przed audytem

Ustalenia dotyczące Conditional Access zwykle wynikają ze słabości ładu, a nie z awarii technologii. Najczęstsze problemy obejmują:

• Konta typu „break glass” są wyłączone, ale nie są monitorowane.
• Polityki są nazywane niespójnie i nie mają właścicieli.
• Wrażliwe aplikacje nie są objęte regułami zgodności urządzeń.
• Użytkownicy gościnni i zewnętrzni współpracownicy omijają standardowe środki kontrolne.
• Konta serwisowe i tożsamości obciążeń nie są odrębnie zarządzane.
• Wykrycia ryzyka logowania nie są poddawane triage ani powiązane z incydentami.
• Kontrole sesji nigdy nie są testowane z niezarządzanych urządzeń.
• Zmiany polityk są wprowadzane bezpośrednio w środowisku produkcyjnym bez zapisów zmian.
• Wyłączenia są stałe, nieudokumentowane lub zatwierdzane ustnie.
• Logi są przechowywane, ale nie są przeglądane.
• Dowody nie zawierają metadanych, kontekstu źródłowego ani łańcucha nadzoru.

Docelowy stan gotowy na 2026 rok obejmuje zatwierdzony przez kierownictwo nadzór nad dostępem, projekt Conditional Access oparty na ryzyku, jednoznaczne mapowanie ISO/IEC 27001:2022 i ISO/IEC 27002:2022, udokumentowane wsparcie dla NIS2, DORA i GDPR, silne MFA według roli i ryzyka, zgodność urządzeń dla dostępu wrażliwego, ograniczenia sesji dla kontekstów niezarządzanych, monitorowane uwierzytelnianie i zmiany polityk, cykl życia wyjątków, kwartalne testowanie i raportowanie zarządcze.

Przekształć Microsoft Entra w dowody gotowe do audytu

Twoje polityki Conditional Access już podejmują decyzje bezpieczeństwa w każdej minucie. Pytanie brzmi, czy te decyzje są zarządzane, oparte na ryzyku, monitorowane i zmapowane na obowiązki istotne dla audytorów i regulatorów.

Zacznij od Zenith Blueprint Zenith Blueprint, szczególnie od kroku 13, aby powiązać polityki Conditional Access z ryzykami, działaniami w ramach postępowania z ryzykiem, Deklaracją stosowania i notami regulacyjnymi. Użyj Zenith Controls Zenith Controls, aby zmapować kontrolę dostępu, bezpieczne uwierzytelnianie, stan bezpieczeństwa punktów końcowych, rejestrowanie i monitorowanie w ramach ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST i COBIT 2019.

Następnie dostosuj swoje wymagania wewnętrzne do polityk Clarysec, w tym Polityki korzystania z chmury — SME, Polityki bezpieczeństwa sieci — SME, Polityki rejestrowania i monitorowania — SME, Polityki audytu i monitorowania zgodności — SME, Polityki wymagań bezpieczeństwa aplikacji — SME, Polityki korzystania z chmury, Polityki zarządzania kontami użytkowników i uprawnieniami, Polityki pracy zdalnej, Polityki kontroli dostępu oraz Polityki rejestrowania i monitorowania.

Clarysec pomaga przekształcić Microsoft Entra Conditional Access ze zbioru ustawień w egzekwowalny, mierzalny i gotowy do audytu system środków kontrolnych. Pobierz odpowiednie zestawy narzędzi Clarysec, zamów przegląd mapowania polityk albo zarezerwuj ocenę, aby sprawdzić, czy Twoje dowody Conditional Access wytrzymają analizę ISO 27001, NIS2, DORA i GDPR.