Conditional Access (dostęp warunkowy) to wbudowany w Microsoft Entra ID silnik polityk bezpieczeństwa Zero Trust, który automatycznie ocenia każde żądanie logowania i — na podstawie sygnałów takich jak tożsamość użytkownika, lokalizacja, stan urządzenia czy poziom ryzyka — decyduje, czy przyznać dostęp, zażądać dodatkowego uwierzytelnienia czy całkowicie zablokować logowanie. To fundament bezpieczeństwa tożsamości w Microsoft 365: bez niego każdy, kto zna hasło, dostaje się do zasobów firmy bez żadnych dodatkowych pytań.
W skrócie
- Conditional Access to silnik „jeśli-to": jeśli użytkownik próbuje uzyskać dostęp do zasobu, to musi spełnić określony warunek (np. MFA, zgodne urządzenie)
- Wymaga licencji Microsoft Entra ID P1 (lub Microsoft 365 Business Premium); polityki oparte na ryzyku wymagają Entra ID P2
- Ocenia sygnały: użytkownik/grupa, lokalizacja IP, platforma urządzenia, aplikacja docelowa, ryzyko logowania (z Entra ID Protection), sygnały z Microsoft Defender for Cloud Apps
- Decyzje: przyznaj dostęp (opcjonalnie z MFA, zgodnym urządzeniem, zatwierdzoną aplikacją), zablokuj dostęp, ogranicz sesję (session controls)
- Polityki działają po pierwszym składniku uwierzytelnienia (first-factor), NIE zastępują obrony przed atakami DoS — ale mogą wykorzystywać z nich sygnały
- Bez Conditional Access nie ma Zero Trust w ekosystemie Microsoft — to obowiązkowy element każdego nowoczesnego wdrożenia Entra ID
- Conditional Access Optimization Agent (z Microsoft Security Copilot) od 2025 sugeruje nowe polityki i automatycznie je tworzy na podstawie najlepszych praktyk Microsoft
Czym jest Conditional Access — pełna definicja
Conditional Access to nie pojedyncza funkcja, lecz cały silnik orkiestracji polityk bezpieczeństwa w Microsoft Entra ID (dawniej Azure AD). Jego zadaniem jest podejmowanie decyzji o dostępie do zasobów organizacji na podstawie wielu sygnałów zbieranych w czasie rzeczywistym podczas każdego logowania.
W najprostszym ujęciu każda polityka Conditional Access to instrukcja warunkowa:
JEŚLI (użytkownik X z lokalizacji Y na urządzeniu Z próbuje otworzyć aplikację A) TO (zastosuj kontrolę dostępu: zażądaj MFA, zablokuj, ogranicz sesję)
Microsoft pozycjonuje Conditional Access jako centralny silnik polityk Zero Trust — to właśnie tu realizowane są trzy filozoficzne zasady Zero Trust: weryfikuj jawnie (zawsze sprawdzaj tożsamość i kontekst), używaj najmniejszych uprawnień (daj dostęp tylko do tego, co niezbędne), zakładaj naruszenie (ogranicz zasięg potencjalnego ataku).
Kluczowe pojęcia polityki Conditional Access
Każda polityka składa się z dwóch głównych bloków:
| Blok | Element | Opis |
|---|---|---|
| Przypisania (Assignments) | Użytkownicy i grupy | Kogo polityka dotyczy (lub kogo wyklucza — zawsze wykluczaj konta awaryjne break-glass) |
| Zasoby docelowe | Jakie aplikacje, akcje użytkownika lub konteksty uwierzytelniania obejmuje polityka | |
| Sieć | Lokalizacje IP, kraje/regiony, zaufane sieci (named locations) | |
| Warunki | Platforma urządzenia, ryzyko logowania, typ aplikacji klienckiej, filtr urządzeń | |
| Kontrola dostępu (Access Controls) | Przyznanie (Grant) | Blokada dostępu LUB przyznanie z warunkami: MFA, siła uwierzytelnienia, zgodne urządzenie, zatwierdzona aplikacja, zasady ochrony aplikacji |
| Sesja (Session) | Ograniczenia sesji: wymuszone restrykcje aplikacji, Conditional Access App Control (Defender for Cloud Apps), częstotliwość logowania, trwała sesja przeglądarki |
💡 Wszystkie przypisania w polityce są łączone operatorem AND — użytkownik musi spełniać wszystkie warunki jednocześnie, by polityka została wyzwolona. Jeśli masz wiele polityk obejmujących tego samego użytkownika, wszystkie aktywne polityki muszą zostać spełnione (każda dodaje swoje wymagania).
Jak działa Conditional Access krok po kroku
Proces oceny polityki przebiega w dwóch fazach:
Faza 1 — Zbieranie sygnałów (dla każdej polityki: włączonej i report-only)
- Użytkownik przechodzi uwierzytelnianie pierwszego składnika (hasło, Windows Hello, FIDO2)
- Entra ID zbiera kontekst sesji: kim jest użytkownik, z jakiego adresu IP się łączy, na jakim urządzeniu, jaką aplikację otwiera, jakie ryzyko przypisano sesji (z Entra ID Protection)
- System sprawdza dopasowanie do wszystkich polityk Conditional Access
Faza 2 — Egzekwowanie (tylko dla polityk włączonych)
- Jeśli jakakolwiek polityka ma kontrolę Block — logowanie zostaje natychmiast zablokowane
- W przeciwnym razie system zbiera wymagane kontrole przyznania (grant controls) z wszystkich pasujących polityk
- Użytkownik jest przeprowadzany przez wymagane akcje w określonej kolejności: MFA → zgodność urządzenia → Microsoft Entra hybrid join → zatwierdzona aplikacja → zasady ochrony aplikacji → zmiana hasła → akceptacja warunków użytkowania
- Po spełnieniu wszystkich kontroli przyznania stosowane są session controls (ograniczenia sesji z Defender for Cloud Apps, częstotliwość logowania, trwała sesja)
Co się dzieje, gdy żadna polityka nie pasuje?
Jeśli użytkownik nie pasuje do żadnej polityki Conditional Access, otrzymuje token dostępu bez dodatkowych wymagań. Dlatego dobrą praktyką jest tworzenie polityki bazowej obejmującej wszystkie aplikacje w chmurze i wymagającej przynajmniej MFA — to zapobiega sytuacji, w której nowa aplikacja jest domyślnie niezabezpieczona.
Najważniejsze polityki — od czego zacząć
Microsoft rekomenduje wdrożenie polityk w trzech fazach. Oto minimalny zestaw startowy:
Faza 1 — Fundament (tydzień 1–2)
| Polityka | Cel | Wymagana licencja |
|---|---|---|
| Blokada starszych protokołów uwierzytelniania | Zablokuj legacy auth (POP3, IMAP, SMTP, ActiveSync bez modern auth) dla wszystkich użytkowników | Entra ID P1 |
| Zabezpieczenie rejestracji MFA | Wymuś MFA lub zaufaną lokalizację przy rejestracji metod uwierzytelniania (strona My Security Info) | Entra ID P1 |
| Phishing-resistant MFA dla administratorów | Wymuś FIDO2 lub Windows Hello dla ról uprzywilejowanych (Global Admin, Security Admin itp.) | Entra ID P1 |
Faza 2 — Uwierzytelnianie podstawowe (tydzień 2–3)
| Polityka | Cel | Wymagana licencja |
|---|---|---|
| MFA dla wszystkich użytkowników | Każde logowanie wymaga silnego uwierzytelnienia (Uwaga: planuj komunikację — to zmienia doświadczenie użytkowników) | Entra ID P1 |
| MFA dla gości (B2B) | Wymuś silne uwierzytelnianie dla użytkowników zewnętrznych | Entra ID P1 |
| Zatwierdzone aplikacje / app protection dla urządzeń mobilnych | Wymuś korzystanie z zatwierdzonych klientów (Outlook, Teams) i zasad ochrony aplikacji (Intune MAM) na urządzeniach mobilnych | Entra ID P1 |
Faza 3 — Ochrona zaawansowana (tydzień 3–4)
| Polityka | Cel | Wymagana licencja |
|---|---|---|
| Blokada logowań wysokiego ryzyka | Zablokuj logowania ze znacznikiem high risk (niemożliwe podróże, wyciekłe hasła, anonimowe IP) | Entra ID P2 |
| Ograniczenie dostępu użytkowników wysokiego ryzyka | Wymuś zmianę hasła + MFA dla kont oznaczonych jako high user risk | Entra ID P2 |
| Token protection dla sesji | Wiąże tokeny dostępu z konkretnym urządzeniem — token skradziony z innego urządzenia jest bezużyteczny | Entra ID P1 |
⚠ Zawsze wykluczaj konta awaryjne (break-glass) z KAŻDEJ polityki. Minimum dwa konta z wyłączeniem ze wszystkich polityk Conditional Access — to Twoja polisa na wypadek błędnej konfiguracji blokującej wszystkich administratorów.
Conditional Access Optimization Agent + Security Copilot — nowość 2025/2026
Od 2025 roku administratorzy Entra ID mają do dyspozycji Conditional Access Optimization Agent zintegrowany z Microsoft Security Copilot. Agent ten:
- Skanuje istniejące polityki i porównuje je z zasadami Zero Trust oraz najlepszymi praktykami Microsoft
- Sugeruje nowe polityki i modyfikacje istniejących — z jednym kliknięciem można zaakceptować i wdrożyć rekomendację
- Wymaga licencji Entra ID P1 oraz jednostek obliczeniowych zabezpieczeń (Security Compute Units — SCU) w ramach Security Copilot
- Działa w portalu Entra admin center, w sekcji Conditional Access
Dla organizacji, które nie mają dedykowanego zespołu bezpieczeństwa, Optimization Agent znacząco obniża próg wejścia w zaawansowane polityki — zamiast analizować dokumentację, administrator klika „Zastosuj" na sprawdzonej przez Microsoft rekomendacji.
Conditional Access a licencjonowanie — szybka ściąga
| Poziom licencji | Co dostajesz | Przykładowy koszt orientacyjny |
|---|---|---|
| Bez Entra ID P1 (np. Microsoft 365 Business Basic) | Tylko security defaults — podstawowe zabezpieczenia (MFA dla wszystkich, blokada legacy auth). Brak możliwości tworzenia własnych polityk Conditional Access. | — |
| Entra ID P1 (Microsoft 365 Business Premium, E3) | Pełne polityki Conditional Access: blokada lokalizacji, wymuszanie MFA, zgodne urządzenia, zatwierdzone aplikacje, session controls. | ~6 USD/użytkownika/miesiąc (jako dodatek) lub w pakiecie Business Premium |
| Entra ID P2 (Microsoft 365 E5) | Wszystko z P1 + polityki oparte na ryzyku (sign-in risk, user risk) z Entra ID Protection + Privileged Identity Management (PIM) | ~9 USD/użytkownika/miesiąc (jako dodatek) lub w pakiecie E5 |
💡 Ważne: gdy licencja Entra ID P1/P2 wygaśnie, polityki Conditional Access NIE są automatycznie usuwane ani wyłączane. Pozostają w trybie tylko do odczytu — możesz je przeglądać i usuwać, ale nie edytować. To celowe zabezpieczenie przed nagłą utratą ochrony przy przejściu na niższy plan.
Tryb Report-Only — testuj bez ryzyka
Zanim włączysz politykę na produkcję, zawsze używaj trybu report-only. Polityka w tym trybie:
- Zbiera sygnały i ocenia, czy zostałaby wyzwolona — ale NIE egzekwuje kontroli dostępu
- Wyniki widzisz w logach logowania (zakładka Report-only dla każdego zdarzenia) oraz w skoroszycie Insights and Reporting (wymaga Azure Monitor + Log Analytics)
- Microsoft zaleca minimum tydzień testów w trybie report-only przed przełączeniem na On
Dodatkowo narzędzie What If w portalu Entra admin center pozwala zasymulować, czy konkretna polityka zadziała dla danego użytkownika, aplikacji i warunków — bez czekania na rzeczywiste logowanie.
Częste pytania
Czym różni się Conditional Access od security defaults?
Security defaults to gotowy, uproszczony zestaw zabezpieczeń dostępny za darmo dla każdego tenanta Entra ID (bez P1/P2). Obejmuje: obowiązkową rejestrację MFA dla wszystkich użytkowników, wymuszanie MFA dla administratorów, blokadę starszych protokołów uwierzytelniania. Nie daje możliwości tworzenia własnych polityk, wykluczania użytkowników ani dostosowywania warunków. Conditional Access daje pełną kontrolę nad każdym aspektem polityki — ale wymaga Entra ID P1 i zastępuje security defaults (nie można ich używać jednocześnie).
Czy Conditional Access działa dla aplikacji on-premises?
Tak — przez Application Proxy Microsoft Entra lub przez integrację z Global Secure Access. Polityki Conditional Access mogą być stosowane do aplikacji on-premises publikowanych przez Entra ID, a sygnały z Global Secure Access (compliant network) mogą być jednym z warunków polityki. Same serwery w sieci lokalnej NIE są bezpośrednio chronione — ochrona dotyczy ścieżki uwierzytelniania przez Entra ID.
Ile polityk Conditional Access mogę utworzyć?
Limit to 240 polityk na tenant, wliczając polityki w trybie report-only, włączone i wyłączone. Każda polityka to obiekt JSON o ograniczonej wielkości — jeśli używasz wielu pojedynczych identyfikatorów GUID zamiast grup, możesz napotkać limit rozmiaru pojedynczej polityki. Dlatego zaleca się stosowanie grup i filtrów aplikacji zamiast ręcznego wymieniania każdego zasobu.
Co się stanie, jeśli użytkownik spełnia kilka polityk naraz?
Wszystkie pasujące polityki są egzekwowane jednocześnie — wymagania sumują się. Na przykład: jeśli jedna polityka wymaga MFA, a druga wymaga zgodnego urządzenia, użytkownik musi przejść MFA ORAZ zalogować się ze zgodnego urządzenia. Wymagania nie są alternatywą — każda polityka dodaje swoje kontrole. Wyjątek: kontrola Block w dowolnej polityce zawsze wygrywa i natychmiast blokuje dostęp.
Dlaczego muszę wykluczać konta awaryjne (break-glass) z polityk?
Bo błąd w konfiguracji polityki — np. przypadkowe zablokowanie wszystkich logowań z danego kraju lub wymuszenie metody MFA, która przestała działać — może zablokować dostęp każdemu, łącznie z administratorami. Dedykowane konta awaryjne (co najmniej dwa), wykluczone ze wszystkich polityk Conditional Access, z bardzo długimi hasłami przechowywanymi w sejfie, to jedyna droga powrotu do tenanta w takim scenariuszu. To nie opcjonalna rekomendacja — to wymóg bezpieczeństwa.
Jak Conditional Access współpracuje z Microsoft Intune?
Intune dostarcza sygnały o stanie urządzenia: czy jest zgodne z politykami (compliant), czy jest przyłączone do Entra (hybrid join lub Entra join), czy ma włączone zasady ochrony aplikacji (app protection policies). Conditional Access może wymagać tych stanów jako warunków przyznania dostępu — np. „wymagaj urządzenia oznaczonego jako zgodne" bezpośrednio odwołuje się do oceny Intune. Bez Intune te kontrole są niedostępne.
Czy mogę używać Conditional Access bez Microsoft 365?
Conditional Access jest funkcją Microsoft Entra ID, a nie Microsoft 365. Działa z każdą aplikacją zintegrowaną z Entra ID jako dostawcą tożsamości — w tym z aplikacjami niestandardowymi, SaaS (Salesforce, ServiceNow, AWS IAM Identity Center), a także z zasobami Azure. Nie potrzebujesz subskrypcji Microsoft 365 — wystarczy Entra ID P1 i zintegrowana aplikacja.
Potrzebujesz licencji Microsoft 365 z Entra ID P1 do wdrożenia Conditional Access?
Licencja Microsoft Entra ID P1 jest wymagana do tworzenia i egzekwowania polityk Conditional Access. Jeśli Twoja organizacja korzysta z Microsoft 365, najprostszą drogą do uzyskania Entra ID P1 jest plan Microsoft 365 Business Premium — zawiera Entra ID P1, Intune (do egzekwowania zgodności urządzeń) oraz Defender for Business.
Dla mniejszych firm i użytkowników indywidualnych, którzy dopiero budują środowisko, osobne klucze licencyjne do systemu Windows (niezbędnego do korzystania z Microsoft 365 i Entra ID) oraz pakiety Microsoft 365 znajdziesz w ofercie KluczeSoft:
→ Microsoft 365 — klucze licencyjne od 49 zł
→ Klucze Windows 11 — legalne licencje od 199 zł
KluczeSoft jest niezależnym sprzedawcą kluczy licencyjnych i nie jest powiązany z Microsoft Corporation. Microsoft, Entra ID, Windows i Microsoft 365 są znakami towarowymi Microsoft Corporation.