Conditional Access (dostęp warunkowy) to wbudowany w Microsoft Entra ID (dawniej Azure AD) silnik polityk Zero Trust, który na podstawie sygnałów — tożsamości użytkownika, lokalizacji, stanu urządzenia i poziomu ryzyka — automatycznie przyznaje, blokuje lub ogranicza dostęp do zasobów Microsoft 365. Prawidłowo skonfigurowany redukuje ryzyko przejęcia konta o ponad 99,9% i stanowi fundament nowoczesnego bezpieczeństwa organizacji.
W skrócie
- Conditional Access to silnik if-then: jeśli użytkownik próbuje uzyskać dostęp do zasobu, to musi spełnić warunek (np. MFA, zgodne urządzenie)
- Wymaga licencji Microsoft Entra ID P1 (zawartej m.in. w Microsoft 365 Business Premium, E3, E5)
- Polityki ryzyka (sign-in risk, user risk) wymagają Entra ID P2 (Microsoft 365 E5 lub dodatek)
- Od 2025 roku dostępne są szablony polityk (Secure Foundation, Zero Trust, Remote Work, Protect Administrator, Emerging Threats, AI Agents)
- Conditional Access Optimization Agent z Microsoft Security Copilot automatycznie sugeruje nowe polityki i optymalizuje istniejące
- Kluczowa zasada: wykluczaj konta awaryjne (break-glass) z każdej polityki, aby uniknąć blokady dostępu
- Tryb report-only pozwala przetestować każdą politykę przed wdrożeniem — zawsze zaczynaj od niego
Czym jest Conditional Access i jak działa
Conditional Access to centralny element architektury Zero Trust Microsoftu. Zamiast ufać, że użytkownik wewnątrz sieci firmowej jest bezpieczny, silnik weryfikuje każde żądanie dostępu na podstawie wielu sygnałów zbieranych w czasie rzeczywistym.
Sygnały wykorzystywane przez Conditional Access
| Sygnał | Opis | Przykład zastosowania |
|---|---|---|
| Użytkownik / grupa / rola | Tożsamość, przynależność do grupy, rola katalogowa | Wymuś MFA tylko dla administratorów Global Admin |
| Lokalizacja (Named Locations) | Kraj/region, zakresy IP, zaufane sieci | Blokuj logowania spoza Polski |
| Platforma urządzenia | Windows, macOS, iOS, Android | Wymagaj urządzenia zgodnego (compliant) przez Intune |
| Aplikacja docelowa | Aplikacje chmurowe, zasoby on-premises, agent resources | Osobna polityka dla Microsoft 365, osobna dla aplikacji HR |
| Ryzyko logowania / użytkownika | Integracja z Entra ID Protection | Blokuj logowania o wysokim ryzyku (high risk) |
| Aplikacja kliencka | Przeglądarka, aplikacja natywna, starsze protokoły | Blokuj legacy authentication (IMAP, POP3, SMTP) |
| Microsoft Defender for Cloud Apps | Monitorowanie sesji w czasie rzeczywistym | Ogranicz pobieranie plików na urządzeniach niezarządzanych |
Architektura decyzji
Każda polityka Conditional Access to instrukcja if-then:
JEŻELI (Assignments):
- Użytkownik: grupa "Finance"
- Aplikacja: Microsoft 365
- Warunki: spoza sieci firmowej
TO (Access Controls):
- Grant: wymagaj MFA + urządzenie zgodne (compliant)
- Session: wymuś częstotliwość logowania co 8 godzin
Polityki są ewaluowane po pierwszym uwierzytelnieniu (first-factor) — nie zastępują zapory ani ochrony przed DoS, ale decydują, czy już uwierzytelniony użytkownik otrzyma dostęp do konkretnego zasobu. Jeśli żadna polityka nie pasuje, dostęp jest domyślnie przyznawany — dlatego tak ważne jest pokrycie politykami wszystkich aplikacji.
Wymagania licencyjne
| Licencja | Co obejmuje |
|---|---|
| Microsoft Entra ID Free (domyślna) | ❌ Brak Conditional Access. Tylko Security Defaults (podstawowa ochrona). |
| Microsoft Entra ID P1 (Microsoft 365 Business Premium, E3) | ✅ Pełny Conditional Access (lokalizacje, urządzenia, aplikacje, MFA). Szablony polityk. |
| Microsoft Entra ID P2 (Microsoft 365 E5, dodatek) | ✅ Wszystko z P1 + polityki oparte na ryzyku (Entra ID Protection). Conditional Access Optimization Agent. |
| Microsoft Entra Workload ID | ✅ Polityki dla tożsamości obciążeń (service principals, managed identities). |
| Microsoft Intune | Wymagany do polityk "wymagaj urządzenia zgodnego" (device compliance). |
| Microsoft Purview | Wymagane do polityk insider risk. |
⚠️ Po wygaśnięciu licencji polityki NIE są automatycznie wyłączane. Pozostają w trybie read-only — można je przeglądać i usuwać, ale nie edytować. To celowe zabezpieczenie przed nagłą utratą ochrony.
Konfiguracja krok po kroku — 7 polityk, które musisz wdrożyć
Poniższe polityki pokrywają fundament bezpieczeństwa każdej organizacji korzystającej z Microsoft 365. Kolejność ma znaczenie — wdrażaj fazami.
Faza 1: Fundament (dzień 1–5)
1. Blokowanie starszych protokołów uwierzytelniania (legacy authentication)
Legacy authentication (IMAP, POP3, SMTP, ActiveSync bez Modern Auth) nie obsługuje MFA i jest najczęstszym wektorem ataków typu password spray i brute force.
- Użytkownicy: Wszyscy użytkownicy
- Aplikacje: Wszystkie zasoby (All resources)
- Warunki: Client apps → tylko "Other clients" (Exchange ActiveSync, starsze protokoły)
- Kontrola: Block access
2. Wymuszenie MFA dla administratorów
Konta administracyjne to najcenniejszy cel atakujących. Dla administratorów zaleca się phishing-resistant MFA (FIDO2, Windows Hello for Business, certificate-based authentication), a nie słabsze metody jak SMS czy kody jednorazowe.
- Użytkownicy: Role katalogowe (Global Admin, Security Admin, Conditional Access Admin itd.)
- Aplikacje: Wszystkie zasoby
- Kontrola: Grant → Require authentication strength → Phishing-resistant MFA
💡 Od 2025 roku Microsoft wprowadził trzy wbudowane poziomy siły uwierzytelniania (authentication strengths): MFA (najmniej restrykcyjny — kody, powiadomienia), Passwordless MFA (Windows Hello, Microsoft Authenticator bez hasła) oraz Phishing-resistant MFA (FIDO2, certyfikaty). Dla adminów wybieraj ten ostatni.
3. Zabezpieczenie rejestracji MFA (My Security Info)
Atakujący często przejmują konto, po czym rejestrują własne metody MFA. Ta polityka blokuje rejestrację informacji zabezpieczających spoza zaufanej sieci.
- Użytkownicy: Wszyscy użytkownicy
- Aplikacje: User actions → Register security information
- Warunki: Lokalizacja → wyklucz zaufane sieci (firmowe IP)
- Kontrola: Grant → Require MFA
Faza 2: Uwierzytelnianie podstawowe (dzień 5–10)
4. Wymuszenie MFA dla wszystkich użytkowników
To najważniejsza polityka w całym zestawie. Jak potwierdzają badania Microsoftu, samo MFA redukuje ryzyko kompromitacji konta o ponad 99,9%.
- Użytkownicy: Wszyscy użytkownicy (z wykluczeniem kont awaryjnych i kont synchronizacji Entra Connect)
- Aplikacje: Wszystkie zasoby
- Kontrola: Grant → Require authentication strength → Multifactor authentication
- Wykluczenia: Konta break-glass, Directory Synchronization Accounts
5. Ochrona urządzeń mobilnych (app protection policy)
Dla urządzeń prywatnych (BYOD) zamiast wymagać pełnego zarządzania przez Intune (MDM), zastosuj polityki ochrony aplikacji (MAM).
- Użytkownicy: Wszyscy użytkownicy
- Aplikacje: Microsoft 365
- Warunki: Platforma → iOS, Android
- Kontrola: Grant → Require approved client app OR Require app protection policy
Faza 3: Zaawansowana ochrona (dzień 10–14)
6. Polityki oparte na ryzyku (wymaga Entra ID P2)
Microsoft Entra ID Protection analizuje każde logowanie w czasie rzeczywistym i przypisuje poziom ryzyka (niski/średni/wysoki) na podstawie sygnałów takich jak nietypowa lokalizacja, wyciek danych uwierzytelniających czy logowanie z anonimowego IP.
- Polityka 6a — Sign-in risk: Jeśli ryzyko logowania = wysokie → Block access
- Polityka 6b — User risk: Jeśli ryzyko użytkownika = wysokie → Wymuś zmianę hasła + MFA
7. Wymuszenie zgodnego urządzenia (compliant device) dla dostępu do wrażliwych danych
Dla aplikacji zawierających dane poufne (SharePoint z dokumentami HR, systemy finansowe) wymagaj, aby urządzenie było zarządzane i zgodne z politykami Intune.
- Użytkownicy: Wybrane grupy (np. Finance, HR)
- Aplikacje: Microsoft 365 (lub konkretne aplikacje)
- Kontrola: Grant → Require device to be marked as compliant
Tabela podsumowująca polityki
| # | Nazwa polityki | Faza | Licencja | Tryb startowy |
|---|---|---|---|---|
| 1 | Blokada legacy authentication | Fundament | P1 | Report-only (7 dni) → On |
| 2 | Phishing-resistant MFA dla adminów | Fundament | P1 | Report-only (7 dni) → On |
| 3 | Zabezpieczenie rejestracji MFA | Fundament | P1 | Report-only (3 dni) → On |
| 4 | MFA dla wszystkich użytkowników | Core | P1 | Report-only (7 dni) → On |
| 5 | App protection dla urządzeń mobilnych | Core | P1 + Intune | Report-only (5 dni) → On |
| 6 | Blokada wysokiego ryzyka logowania | Zaawansowana | P2 | Report-only (14 dni) → On |
| 7 | Wymaganie zgodnego urządzenia | Zaawansowana | P1 + Intune | Report-only (14 dni) → On |
Najlepsze praktyki — o czym pamiętać przy wdrażaniu
1. Zawsze zaczynaj od trybu report-only
Tryb report-only to najważniejsza funkcja bezpiecznego wdrażania. Po zapisaniu polityki w tym trybie, logowania użytkowników nie są blokowane, ale w logach Entra ID pojawia się informacja, co polityka zrobiłaby w trybie produkcyjnym. Minimum tydzień testów na politykę — dłużej dla polityk blokujących.
2. Wykluczaj konta awaryjne (break-glass)
Każda polityka musi wykluczać co najmniej jedno konto awaryjne — dedykowane konto globalnego administratora, które nie podlega MFA ani innym ograniczeniom. W przypadku błędnej konfiguracji lub awarii MFA to jedyna droga powrotna do tenant. Konto break-glass powinno:
- Nie używać tej samej domeny co reszta kont (np.
*.onmicrosoft.com) - Mieć hasło zapisane fizycznie w sejfie
- Być monitorowane pod kątem logowań (alert przy każdym użyciu)
3. Nazywaj polityki według schematu
Dobry schemat nazewnictwa oszczędza godziny debugowania. Przykład:
CA01-Block-LegacyAuth-AllUsers-Global
CA02-Require-PhishResistantMFA-Admins-Global
CA03-MFA-AllUsers-Global
Używaj prefiksu CA##, opisowej nazwy, grupy docelowej i zasięgu. Dla polityk awaryjnych: EM01-ENABLE-IN-EMERGENCY-MFA-Disruption.
4. Stosuj Continuous Access Evaluation (CAE)
CAE to mechanizm, który w czasie zbliżonym do rzeczywistego unieważnia sesje użytkownika, gdy zmienią się warunki dostępu (np. zmiana lokalizacji, wyłączenie konta, wykrycie wysokiego ryzyka). Od 2025 roku CAE jest konfigurowane bezpośrednio w politykach Conditional Access jako kontrola sesji — nie trzeba już przełączać go w ustawieniach zabezpieczeń.
Obsługiwane aplikacje: Exchange Online, SharePoint Online, Teams, Microsoft Graph. Dla użytkowników CAE oznacza mniej monitów o ponowne logowanie (tokeny żyją do 28 godzin zamiast standardowej 1 godziny), przy jednocześnie wyższym poziomie bezpieczeństwa.
5. Pokryj politykami wszystkie aplikacje
Zalecenie Microsoftu: co najmniej jedna polityka Conditional Access powinna obejmować wszystkie zasoby (All resources). Unikaj tworzenia osobnych polityk dla każdej aplikacji — limit to 240 polityk na tenant (łącznie z wyłączonymi i report-only). Grupuj aplikacje o podobnych wymaganiach.
6. Komunikuj zmiany użytkownikom
Wdrożenie MFA dla wszystkich użytkowników to zmiana doświadczenia codziennej pracy. Przed przełączeniem polityki z report-only na On:
- Wyślij e-mail z datą wdrożenia i instrukcją rejestracji MFA
- Przygotuj dokumentację (jak skonfigurować Microsoft Authenticator, jak działa FIDO2)
- Upewnij się, że helpdesk zna procedurę odzyskiwania dostępu
- Udostępnij użytkownikom portal
aka.ms/mfasetupdo wcześniejszej rejestracji metod
7. Używaj narzędzia What If
Przed wdrożeniem polityki użyj narzędzia What If (Conditional Access → Policies → What If), aby zasymulować zachowanie polityki dla konkretnego użytkownika, aplikacji i warunków. Pokazuje, które polityki zostałyby zastosowane i jaka byłaby decyzja (grant/block).
Najczęstsze problemy i ich rozwiązania
"Użytkownicy są blokowani bez wyraźnego powodu — polityka nic nie mówi"
Użyj Sign-in logs w Entra ID → znajdź nieudane logowanie → zakładka "Conditional Access" pokazuje, która polityka zablokowała dostęp i dlaczego. Alternatywnie, otwórz What If i wprowadź parametry logowania użytkownika.
"Wdrożyłem MFA dla wszystkich, ale niektórzy użytkownicy nie są pytani o MFA"
Sprawdź, czy nie działają trusted locations (zaufane sieci) — polityka może wykluczać firmowe IP. Inny powód: tokeny sesji CAE mogą być wciąż ważne (do 28 godzin). Użyj Revoke-MgUserSignInSession w PowerShell, by natychmiast unieważnić sesje.
"Chcę wymagać MFA tylko dla aplikacji webowych, nie dla Outlooka desktopowego"
W polityce Conditional Access, w warunkach → Client apps, zaznacz tylko "Browser". Aplikacje natywne (Outlook, Teams) nie będą podlegać tej polityce. Pamiętaj jednak, że to zmniejsza bezpieczeństwo — atakujący może użyć klienta natywnego zamiast przeglądarki.
"Mam Microsoft 365 Business Standard — dlaczego nie widzę Conditional Access?"
Business Standard zawiera Entra ID Free, który nie obejmuje Conditional Access. Potrzebujesz co najmniej Business Premium (Entra ID P1) lub osobnej licencji Entra ID P1 jako dodatku. Do czasu uzyskania licencji możesz korzystać z Security Defaults (bezpłatne, podstawowa ochrona z MFA dla wszystkich).
"Jak przetestować politykę blokującą bez ryzyka zablokowania prawdziwych użytkowników?"
Użyj grupy testowej (np. 5–10 użytkowników IT) jako warunku Include w polityce. Przez pierwszy tydzień polityka w trybie report-only — sprawdzasz logi. Potem przełączasz na On, ale tylko dla grupy testowej. Dopiero po 2–3 dniach testów rozszerzasz na wszystkich.
Częste pytania
Czy Conditional Access zastępuje VPN?
Nie — Conditional Access chroni dostęp do aplikacji i zasobów w chmurze na poziomie tożsamości. VPN zabezpiecza połączenie sieciowe. Oba rozwiązania się uzupełniają. W architekturze Zero Trust Microsoft zaleca model dostępu bezpośredniego do aplikacji (bez VPN) z Conditional Access jako głównym mechanizmem kontroli.
Ile polityk Conditional Access potrzebuje mała firma (10–50 użytkowników)?
Minimum 3 polityki w fazie fundamentu: blokada legacy authentication, MFA dla administratorów, MFA dla wszystkich użytkowników. Z czasem warto dodać politykę ochrony urządzeń mobilnych i polityki ryzyka (jeśli licencja na to pozwala).
Czy polityki Conditional Access działają dla użytkowników-gości (B2B)?
Tak, ale z ograniczeniami. Polityki wymagające MFA są egzekwowane wobec gości. Polityki ryzyka (Entra ID Protection) i CAE nie obsługują kont gości w pełnym zakresie. Możesz też skonfigurować cross-tenant access settings, aby ufać MFA wykonanemu w tenant-cie domowym gościa.
Co się stanie, gdy usunę politykę Conditional Access przez pomyłkę?
Polityki Conditional Access podlegają 30-dniowemu soft-delete. Możesz je przywrócić z poziomu Entra admin center lub przez Microsoft Graph API. Po 30 dniach są trwale usuwane.
Czy mogę wyłączyć MFA dla zaufanej sieci firmowej?
Tak — w polityce MFA możesz skonfigurować Named Locations jako wykluczenie dla zaufanych zakresów IP. Użytkownicy w biurze nie będą pytani o MFA, ale każde logowanie spoza firmy — tak. To dobra praktyka równoważąca bezpieczeństwo i wygodę, pod warunkiem że Twoja sieć firmowa jest odpowiednio zabezpieczona fizycznie.
Jakie są nowości w Conditional Access na rok 2026?
W 2026 roku Microsoft rozwinął Conditional Access Optimization Agent w ramach Security Copilot — narzędzie automatycznie analizuje logowania, wykrywa luki w politykach i sugeruje nowe reguły zgodne z zasadami Zero Trust. Dodano kategorię szablonów AI Agents do kontroli dostępu dla autonomicznych agentów i obciążeń AI. Rozwinięto również strict location enforcement w CAE, które eliminuje wyjątki przy zmianie lokalizacji użytkownika.
Czy potrzebuję Intune do korzystania z Conditional Access?
Nie — Conditional Access działa bez Intune. Intune jest potrzebny tylko wtedy, gdy chcesz wymagać urządzenia zgodnego (compliant) lub stosować app protection policies. Same polityki MFA, lokalizacji i ryzyka działają bez Intune.
Gotowy wdrożyć Conditional Access w swojej organizacji?
Jeśli Twoja firma dopiero planuje przejście na Microsoft 365 z licencją obsługującą Conditional Access (Business Premium, E3 lub E5), KluczeSoft oferuje legalne, w pełni aktywowane klucze licencyjne w cenach niższych niż oficjalny kanał sprzedaży:
→ Microsoft 365 Business Premium — od 299 zł/rok — zawiera Entra ID P1, Intune, Defender for Business → Microsoft 365 E3 — dla średnich i dużych firm — Entra ID P1 + zaawansowane funkcje zgodności → Microsoft 365 E5 — pełna ochrona — Entra ID P2, ID Protection, Defender for Office 365
KluczeSoft jest niezależnym sprzedawcą — nie jesteśmy autoryzowanym partnerem Microsoftu. Sprzedajemy legalne licencje używane (resale) zgodnie z wyrokiem Trybunału Sprawiedliwości UE C-128/11 (UsedSoft).