Conditional Access (dostęp warunkowy) w Microsoft Entra ID to silnik reguł, który na podstawie sygnałów — tożsamości użytkownika, lokalizacji, stanu urządzenia i poziomu ryzyka — automatycznie decyduje, czy przepuścić logowanie, zablokować je, czy zażądać dodatkowego uwierzytelnienia (MFA). Prawidłowo skonfigurowane polityki MFA w Conditional Access redukują ryzyko przejęcia konta o ponad 99,9% — to nie marketingowy slogan, tylko twarde dane z telemetrii Microsoftu.
W skrócie
- Conditional Access to płatna funkcja (wymaga licencji Microsoft Entra ID P1 na każdego użytkownika objętego polityką; funkcje ryzyka wymagają Entra ID P2)
- Polityki działają na zasadzie if-then: jeśli użytkownik spełnia warunek → wymuś MFA, zablokuj dostęp lub ogranicz sesję
- Wbudowane szablony (templates) w centrum administracyjnym Entra pokrywają 14 najczęstszych scenariuszy — od MFA dla adminów po blokowanie legacy auth
- Każdą politykę należy najpierw wdrożyć w trybie report-only na minimum tydzień, przeanalizować logi, a dopiero potem włączyć (
On)- Żelazna zasada: zawsze wykluczaj z polityk konta awaryjne (break-glass) i konta synchronizacji Entra Connect — inaczej ryzykujesz globalnym lockoutem
- Microsoft wycofał per-user MFA jako zalecaną metodę — od 2024 roku cała logika MFA powinna być realizowana wyłącznie przez Conditional Access
Pełna definicja — czym jest Conditional Access
Conditional Access to nie pojedyncze ustawienie, tylko silnik polityk działający w warstwie autoryzacji Microsoft Entra ID (dawniej Azure AD). Każde żądanie dostępu do zasobu w chmurze Microsoftu (Exchange Online, SharePoint, Teams, Azure Portal, aplikacje enterprise) przechodzi przez pipeline Conditional Access po poprawnej autentykacji (czyli po wpisaniu poprawnego hasła), a przed wydaniem tokenu dostępowego.
Pipeline analizuje sześć kategorii sygnałów:
| Kategoria sygnału | Przykłady |
|---|---|
| Użytkownik/grupa/rola | Członek grupy "Finance", rola Global Administrator, workload identity |
| Aplikacja docelowa | Microsoft 365, Salesforce SSO, Azure Management API, dowolna Enterprise App |
| Lokalizacja sieciowa (Named Location) | Zaufane IP biura, kraj blokady (geolokacja), anonimowe proxy/VPN |
| Platforma urządzenia | Windows, macOS, iOS, Android — można targetować polityki per OS |
| Stan urządzenia | Czy urządzenie jest compliant w Intune? Czy jest hybrydowo przyłączone do domeny (HAADJ)? |
| Ryzyko logowania/użytkownika (Entra ID P2) | Sign-in risk (nietypowa lokalizacja, token replay) i user risk (wyciekłe hasło w dark web) |
Na podstawie tych sygnałów silnik podejmuje jedną z trzech decyzji (Grant controls):
- Grant access — przepuść, ewentualnie z dodatkowymi warunkami (MFA, compliant device, approved app, zmiana hasła)
- Block access — twarda blokada; użytkownik widzi komunikat odmowy
- Session controls — przepuść, ale ogranicz sesję (np. wymuś częstsze reautentykacje, zablokuj pobieranie plików na niezarządzanym urządzeniu)
Trzy wbudowane poziomy siły uwierzytelnienia (Authentication Strengths)
Od połowy 2023 roku Microsoft Entra ID oferuje mechanizm authentication strengths, który zastąpił binarny przełącznik "wymagaj MFA". Zamiast ogólnego żądania "drugiego składnika", administrator może zażądać konkretnej klasy metod:
| Authentication Strength | Co obejmuje | Kiedy stosować |
|---|---|---|
| Multifactor authentication (najłagodniejszy) | Microsoft Authenticator (powiadomienie push + kod), SMS, połączenie głosowe, OATH Software Token, klucze FIDO2, Windows Hello | Codzienne logowania dla wszystkich użytkowników — dobry punkt startowy |
| Passwordless MFA (średni) | Microsoft Authenticator (passwordless), FIDO2, Windows Hello for Business, certyfikaty CBA | Użytkownicy z wyższym poziomem dostępu: admini, finanse, HR — eliminuje phishowalne metody (SMS) |
| Phishing-resistant MFA (najsilniejszy) | Tylko FIDO2 security keys i Windows Hello for Business z TPM 2.0 — żadnych kodów, powiadomień push ani SMS | Administratorzy z rolami privileged (Global Admin, Privileged Role Admin), infrastruktura krytyczna |
Organizacje mogą też tworzyć własne (custom) authentication strengths — np. "tylko Authenticator push + FIDO2, bez SMS".
Przykłady konfiguracji — 4 kluczowe polityki krok po kroku
Wszystkie poniższe polityki tworzy się w Microsoft Entra admin center → Conditional Access → Policies → + New policy.
1. MFA dla wszystkich użytkowników (baseline)
To najważniejsza polityka — fundament Zero Trust, zalecana przez Microsoft jako pierwsza do wdrożenia.
Konfiguracja:
| Sekcja | Ustawienie |
|---|---|
| Name | CA-01: MFA for all users — All resources |
| Users | Include: All users / Exclude: konta awaryjne + Directory Synchronization Accounts |
| Target resources | Include: All resources (formerly 'All cloud apps') |
| Network | Opcjonalnie: Exclude → All trusted networks and locations (biuro nie wymaga MFA) |
| Grant | Grant access → Require authentication strength → wybierz Multifactor authentication (wbudowany) |
| Enable policy | Najpierw Report-only (minimum 7 dni) → po weryfikacji logów → On |
Uwaga: Microsoft zaleca nie wykluczać aplikacji z baseline'owej polityki MFA — każda aplikacja bez MFA to potencjalny wektor ataku. Jeśli jakaś appka legacy nie wspiera MFA, lepiej ją wyłączyć niż osłabiać politykę.
2. MFA phishing-resistant dla administratorów
Admini to cel numer jeden ataków — przejęcie konta Global Admin daje attackerowi klucze do królestwa.
Konfiguracja:
| Sekcja | Ustawienie |
|---|---|
| Name | CA-02: Phishing-resistant MFA for privileged roles |
| Users | Include: Directory roles → zaznacz: Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Billing Administrator |
| Target resources | Include: All resources (formerly 'All cloud apps') |
| Grant | Require authentication strength → Phishing-resistant MFA (wbudowany) |
| Session | Sign-in frequency: 4 godziny (zmusza do reautentykacji co 4h dla sesji admina) |
| Enable | Report-only → On |
W praktyce oznacza to, że każdy admin logujący się do portalu Azure, Exchange Admin Center czy Microsoft 365 Defender musi użyć klucza FIDO2 (np. YubiKey) albo Windows Hello for Business z TPM — nie przejdzie na SMS ani powiadomieniu Authenticator.
3. MFA z wykluczeniem zaufanych lokalizacji + blokada dla krajów wysokiego ryzyka
Hybrydowa polityka: wymuszaj MFA poza biurem, blokuj logowania z krajów, z którymi organizacja nie ma relacji biznesowych.
Konfiguracja (polityka MFA poza biurem):
| Sekcja | Ustawienie |
|---|---|
| Name | CA-03: MFA outside trusted locations |
| Users | Include: All users / Exclude: konta awaryjne |
| Target resources | Include: All resources |
| Network | Include: Any network or location / Exclude: All trusted networks and locations (wcześniej skonfiguruj Named Location z zaufanymi IP) |
| Grant | Require authentication strength → Multifactor authentication |
Konfiguracja (blokada geograficzna):
| Sekcja | Ustawienie |
|---|---|
| Name | CA-04: Block access from high-risk countries |
| Users | Include: All users / Exclude: konta awaryjne |
| Target resources | Include: All resources |
| Network | Include: Selected locations → zaznacz kraje wysokiego ryzyka (np. Rosja, Korea Północna, Iran) |
| Grant | Block access |
Uwaga: polityka blokady geograficznej z All resources może zablokować dostęp do Microsoft Graph API — wykluczaj konta awaryjne bezwzględnie.
4. MFA dla gości (B2B) — dostęp warunkowy dla użytkowników zewnętrznych
Goście z innych tenantów Entra ID mogą już mieć MFA w swoim tenant-cie macierzystym. Polityka pozwala to honorować (lub nie).
Konfiguracja:
| Sekcja | Ustawienie |
|---|---|
| Name | CA-05: MFA for guest users |
| Users | Include: Select users and groups → All guest and external users |
| Target resources | Include: All resources |
| Grant | Require authentication strength → Multifactor authentication |
Jeśli chcesz zaufać MFA wykonanemu w home tenancie gościa, skonfiguruj to w External Identities → Cross-tenant access settings → Inbound access → sekcja "Trust settings" → zaznacz "Trust multifactor authentication from Microsoft Entra tenants".
Porównanie: Conditional Access vs Security Defaults vs Per-User MFA
| Cecha | Security Defaults | Per-User MFA (przestarzałe) | Conditional Access |
|---|---|---|---|
| Licencja | Dowolna (nawet Free) | Dowolna | Entra ID P1 (każdy użytkownik objęty polityką) |
| Granularność | Sztywne reguły — nie konfigurujesz nic poza włączeniem/wyłączeniem | Per-user on/off, brak warunków | Pełna — użytkownicy, grupy, aplikacje, lokalizacje, ryzyko, urządzenia |
| Wykluczenia | Brak możliwości wykluczenia użytkowników/aplikacji | Brak | Pełna kontrola nad wykluczeniami |
| Tryb testowy | Brak | Brak | Report-only — testuj bez przerywania logowań |
| Blokowanie legacy auth | Automatycznie | Nie | Konfigurowalne per polityka |
| MFA na podstawie ryzyka | Nie | Nie | Tak (z Entra ID P2 + Identity Protection) |
| Obsługa gości B2B | Ograniczona | Nie | Pełna |
| Zalecenie Microsoftu (2026) | Dla bardzo małych firm bez IT | NIEREKOMENDOWANE — migrate to CA | Jedyna rekomendowana metoda |
Pułapki i najczęstsze błędy przy konfiguracji
- Brak wykluczenia kont awaryjnych (break-glass) — pojedyncza błędna polityka blokująca
All usersmoże odciąć całą organizację od Entra ID. Zawsze wykluczaj dedykowane konta awaryjne (najlepiej cloud-only, bez MFA, z 50-znakowym hasłem w sejfie). - Polityka "Block access" + "All resources" — blokujesz dostęp do wszystkiego, włącznie z panelem
mysignins.microsoft.com, gdzie użytkownik mógłby zobaczyć, dlaczego został zablokowany. Stosuj blokady selektywnie. - Wykluczanie Microsoft Graph z polityk MFA — nie rób tego. To otwiera furtkę do ataków token-replay przez API.
- Polityki skonfigurowane, ale użytkownicy nie zarejestrowali metod MFA — bez polityki zabezpieczającej rejestrację MFA (template: "Securing security info registration") użytkownicy mogą ominąć wymóg MFA, nie rejestrując metod. Dodaj tę politykę w fazie 1 wdrożenia.
- Zbyt wiele polityk — limit to 240 polityk na tenant (liczą się wszystkie, łącznie z
report-onlyioff). Grupuj aplikacje o podobnych wymaganiach w jedną politykę. Single policy:All resourcesz wykluczeniami jest prostsze i bezpieczniejsze niż 30 polityk per aplikacja.
Częste pytania
Czy Conditional Access działa z darmowym Microsoft Entra ID Free?
Nie. Conditional Access wymaga licencji Microsoft Entra ID P1 na każdego użytkownika objętego polityką. Dla tenantów Free dostępne są wyłącznie Security Defaults — podstawowy zestaw sztywnych reguł (MFA dla wszystkich użytkowników 14 dni po pierwszym logowaniu, blokada legacy auth), bez możliwości wykluczeń czy targetowania per grupa. Jeśli potrzebujesz elastyczności (np. MFA tylko dla adminów lub tylko spoza biura), musisz wykupić P1 — jest zawarte m.in. w Microsoft 365 Business Premium i Microsoft 365 E3.
Czy mogę wymusić MFA tylko dla konkretnej aplikacji, np. Salesforce?
Tak. W sekcji Target resources zamiast All resources wybierz Select apps i wskaż konkretną aplikację enterprise (Salesforce, Workday, własną appkę zarejestrowaną w Entra ID). Polityka będzie dotyczyć tylko logowań SSO do tej aplikacji. Pamiętaj jednak, że Microsoft rekomenduje tworzenie baseline'owej polityki All resources dla całego tenant-u — aplikacja bez MFA to luka.
Jaka jest różnica między authentication strength "Multifactor" a "Phishing-resistant"?
Multifactor authentication akceptuje wszystkie zarejestrowane metody MFA: powiadomienie push Authenticator, kod OTP, SMS, połączenie głosowe, klucze FIDO2, Windows Hello. To najmniej restrykcyjny poziom — użytkownik może przejść weryfikację nawet przez SMS, który jest podatny na SIM-swap i phishing OTP. Phishing-resistant MFA wymaga wyłącznie metod odpornych na phishing: FIDO2 (klucze sprzętowe jak YubiKey) oraz Windows Hello for Business z TPM 2.0 — żadnych kodów przepisywanych z ekranu, żadnych SMS-ów, żadnych push-powiadomień podatnych na MFA fatigue. Microsoft zaleca phishing-resistant dla wszystkich kont uprzywilejowanych (admini, finanse).
Czy polityka Conditional Access może blokować dostęp z konkretnych krajów?
Tak — to jedna z najczęściej stosowanych konfiguracji. W sekcji Network polityki wybierasz Include → Selected locations, wskazujesz wcześniej utworzone Named Locations z krajami (np. Rosja, Chiny, Nigeria), a w Grant ustawiasz Block access. Pamiętaj o wykluczeniu kont awaryjnych — geoblokada All users + All resources zablokuje też dostęp do API Microsoft Graph, co może uniemożliwić zdalne odblokowanie tenant-u.
Co się stanie, gdy użytkownik nie przejdzie MFA — czy może zalogować się bez MFA, jeśli odrzuci prompt?
Nie. Jeśli polityka Conditional Access wymaga MFA, a użytkownik przerwie proces (kliknie "Cancel", zamknie aplikację Authenticator, nie odpowie na powiadomienie), logowanie zostanie przerwane na poziomie Entra ID — token dostępowy nie zostanie wydany, a aplikacja otrzyma odpowiedź access_denied z kodem błędu AADSTS 50076 (MFA required but not performed). Użytkownik widzi komunikat: "Twoja organizacja wymaga dodatkowego uwierzytelnienia. Spróbuj ponownie."
Czy mogę przetestować politykę przed włączeniem jej na wszystkich użytkowników?
Tak, na dwa sposoby. Po pierwsze, każdą nową politykę zapisz z przełącznikiem Report-only — polityka jest aktywna w tle, loguje zdarzenia w sign-in logs (zakładka "Report-only"), ale nie wpływa na rzeczywiste logowania. Monitoruj logi przez minimum tydzień. Po drugie, użyj narzędzia What If (dostępne w Conditional Access → What If) — symulujesz logowanie konkretnego użytkownika z konkretnymi warunkami i widzisz, które polityki by się aktywowały. Dodatkowo możesz wdrożyć politykę najpierw na grupę pilotażową zamiast All users.
Czy potrzebuję Entra ID P2 do polityk MFA?
Nie — podstawowe polityki MFA (wymuś MFA dla wszystkich, dla adminów, dla gości, z wykluczeniem lokalizacji) działają z Entra ID P1. P2 jest wymagane wyłącznie do polityk wykorzystujących sygnały ryzyka z Identity Protection (sign-in risk, user risk) — czyli np. "wymuś MFA tylko gdy logowanie jest wysokiego ryzyka" lub "wymuś zmianę hasła dla użytkownika wysokiego ryzyka". Dla 90% organizacji P1 wystarcza.
*Niezależnie od tego, czy wdrażasz pierwsze polityki Conditional Access, czy rozbudowujesz istniejącą infrastrukturę Zero Trust, potrzebujesz solidnej podstawy licencyjnej. W KluczeSoft.pl znajdziesz legalne klucze Microsoft 365 Business Premium (zawierające Entra ID P1) oraz Windows Server z dostępem do zaawansowanych funkcji bezpieczeństwa — wszystko w cenach 30–60% niższych