Entra ID Conditional Access i Baseline Policies — kompletny przewodnik po politykach dostępu warunkowego (2026)

Baseline policies (polityki bazowe) w Microsoft Entra ID (dawniej Azure AD) to historyczne już, predefiniowane reguły dostępu warunkowego, które Microsoft udostępniał bezpłatnie wszystkim tenantom do 29 lutego 2020 roku. Po tej dacie zostały oficjalnie wycofane i zastąpione przez Security Defaults (dla licencji Free) oraz w pełni konfigurowalne polityki Conditional Access (wymagające licencji Entra ID P1). Jeśli nadal masz włączone baseline policies w swoim tenancie — powinieneś jak najszybciej przeprowadzić migrację, ponieważ nie są już wspierane ani aktualizowane.

W skrócie

• Baseline policies to predefiniowane reguły bezpieczeństwa w Azure AD, wycofane oficjalnie 29 lutego 2020 roku
• Zastąpiły je Security Defaults (dla wszystkich tenantów, w tym Free) oraz konfigurowalne polityki Conditional Access (dla Entra ID P1/P2)
• Security Defaults domyślnie wymuszają: MFA dla administratorów, MFA dla użytkowników (gdy Microsoft uzna to za konieczne), blokadę legacy authentication, blokadę device code flow oraz MFA przy dostępie do Azure Portal
• Conditional Access z licencją P1 daje pełną kontrolę nad politykami — lokalizacja, urządzenie, aplikacja, ryzyko logowania
• Microsoft rozwija szablony (templates) polityk Conditional Access w 6 kategoriach: Secure Foundation, Zero Trust, Remote Work, Protect Administrator, Emerging Threats i AI Agents
• Od lipca 2024 Microsoft zniósł 14-dniowy okres grace period na rejestrację MFA w nowych tenantach — rejestracja MFA jest wymagana natychmiast

Czym były Baseline Policies — pełna definicja

Baseline policies (polityki bazowe) były zestawem czterech predefiniowanych reguł Conditional Access, które Microsoft udostępnił w 2018 roku jako odpowiedź na rosnącą falę ataków na tożsamości w chmurze. Były dostępne bezpłatnie dla wszystkich tenantów Azure AD, niezależnie od posiadanej licencji, i nie wymagały subskrypcji Azure AD Premium.

Cztery oryginalne polityki bazowe obejmowały:

1. Require MFA for admins — wymuszenie uwierzytelniania wieloskładnikowego dla ról administratorskich (Global Administrator, SharePoint Administrator, Exchange Administrator, Conditional Access Administrator, Security Administrator).
2. Require MFA for users — wymuszenie MFA dla wszystkich użytkowników w organizacji przy logowaniu do aplikacji chmurowych.
3. Block legacy authentication — blokada przestarzałych protokołów uwierzytelniania (IMAP, POP3, SMTP, ActiveSync bez modern auth), które nie wspierają MFA i były głównym wektorem ataków typu password spray.
4. Require MFA for service management — wymuszenie MFA przy dostępie do Azure Portal, Azure PowerShell i Azure CLI (Azure Resource Manager API).

Polityki te miały charakter globalny (cały tenant) i oferowały minimalną konfigurację — można je było jedynie włączyć lub wyłączyć, bez możliwości wykluczania konkretnych użytkowników, grup czy lokalizacji. Właśnie ten brak granularności stał się głównym powodem ich wycofania — organizacje o złożonych środowiskach (konta awaryjne break-glass, konta serwisowe, użytkownicy B2B) nie mogły elastycznie zarządzać dostępem.

Dlaczego Microsoft wycofał Baseline Policies

Decyzja o wycofaniu polityk bazowych wynikała z trzech czynników:

1. Brak elastyczności — polityki typu "wszystko albo nic" nie sprawdzały się w średnich i dużych organizacjach, które potrzebowały wykluczeń dla kont awaryjnych, kont synchronizacji Entra Connect czy specyficznych scenariuszy testowych.
2. Wprowadzenie Security Defaults — Microsoft chciał ujednolicić podstawową ochronę oferowaną bezpłatnie wszystkim klientom. Security Defaults, uruchomione 22 października 2019 roku dla nowych tenantów, realizują te same cele co baseline policies, ale w nowocześniejszy i bezpieczniejszy sposób.
3. Rozwój Conditional Access w ramach Zero Trust — natywny, w pełni konfigurowalny Conditional Access stał się centralnym silnikiem polityk bezpieczeństwa w ekosystemie Microsoft, a sztywne polityki bazowe nie pasowały do tej ewolucji.

Security Defaults — co zastąpiło Baseline Policies dla licencji Free

Security Defaults to współczesny następca baseline policies, dostępny dla każdego tenanta Entra ID — również tych korzystających z darmowej licencji. Po włączeniu Security Defaults automatycznie egzekwowane jest pięć zabezpieczeń:

Security Defaults to rozwiązanie zero-jedynkowe — nie można go dostosować. Jeśli organizacja potrzebuje wykluczeń (np. dla kont break-glass, użytkowników korzystających z zaufanych lokalizacji biurowych lub hybrydowo dołączonych urządzeń), powinna przejść na pełny Conditional Access z licencją Entra ID P1.

Jak działa Conditional Access w praktyce — silnik Zero Trust Microsoftu

Conditional Access to centralny silnik polityk Zero Trust w ekosystemie Microsoft Entra. Działa według prostej logiki: jeśli [sygnał], to [decyzja]. Przykładowo: Jeśli użytkownik próbuje zalogować się do Microsoft 365 z nieznanej lokalizacji, to musi przejść MFA.

Sygnały (signals) brane pod uwagę

• Użytkownik, grupa, rola — politykę można przypisać do konkretnych użytkowników (lub wykluczyć np. konta break-glass), do grup zabezpieczeń, wbudowanych ról administratorskich, a od 2025 roku także do agentów AI (workload identities).
• Lokalizacja IP — nazwane lokalizacje (Named Locations) pozwalają definiować kraj, region, zakres IP jako zaufany lub niezaufany.
• Urządzenie — polityka może sprawdzać platformę (Windows, macOS, iOS, Android), stan urządzenia (compliant w Intune, hybrydowo dołączone do Entra ID), a także używać filtrów urządzeń.
• Aplikacja — politykę można kierować na konkretne aplikacje (Microsoft 365, Azure Portal, aplikacje SaaS przez SSO) lub na wszystkie zasoby.
• Ryzyko logowania i użytkownika (Entra ID Protection) — integracja z sygnałami ryzyka: anonimowe IP, nietypowa podróż (impossible travel), wyciek danych uwierzytelniających, podejrzana aktywność.

Decyzje (access controls)

• Block — całkowita blokada dostępu (najsilniejsza kontrola).
• Grant — przyznanie dostępu z warunkiem: MFA, phishing-resistant MFA (FIDO2, Windows Hello for Business, certyfikat), compliant device, hybrid joined device, zatwierdzona aplikacja kliencka, polityka ochrony aplikacji (App Protection Policy), zmiana hasła.
• Session — ograniczenia sesji: częstotliwość logowania (sign-in frequency), trwała sesja przeglądarki, application enforced restrictions (np. blokada pobierania plików na niezarządzanych urządzeniach).

Szablony Conditional Access — gotowe polityki rekomendowane przez Microsoft

Microsoft udostępnia w panelu administracyjnym Entra rozbudowaną bibliotekę szablonów (templates) podzieloną na sześć kategorii. Każdy szablon można wdrożyć jednym kliknięciem (domyślnie w trybie report-only), edytować pod własne potrzeby lub wyeksportować jako JSON do wdrożenia przez API/CLI.

Kategoria 1: Secure Foundation

Minimalny zestaw polityk zalecany dla każdej organizacji:

• Require MFA for admins — MFA dla 14+ ról administratorskich
• Securing security info registration — ochrona rejestracji MFA (tylko z zaufanej lokalizacji lub po MFA)
• Block legacy authentication — blokada starych protokołów
• Require MFA for admins accessing Microsoft admin portals — dodatkowe MFA przy dostępie do portali administracyjnych
• Require MFA for all users — MFA dla wszystkich użytkowników
• Require MFA for Azure management — MFA dla ARM API
• Require compliant or hybrid joined device or MFA for all users — warstwa urządzeniowa
• Require compliant device — tylko urządzenia zgodne z Intune

Kategoria 2: Zero Trust

Rozszerza Secure Foundation o polityki ryzyka i kontroli aplikacji:

• Require MFA for risky sign-ins (wymaga P2) — MFA przy podwyższonym ryzyku logowania
• Require password change for high-risk users (P2) — wymuszenie zmiany hasła
• Block access for unknown/unsupported device platform — blokada nieznanych platform
• No persistent browser session — wymuszenie nietrwałej sesji przeglądarki
• Require approved client apps or app protection policies — kontrola aplikacji
• Block access for users with insider risk (wymaga Microsoft Purview)

Kategoria 3–6: Remote Work, Protect Administrator, Emerging Threats, AI Agents

Kolejne kategorie rozwijają scenariusze pracy zdalnej (MFA dla gości, compliant device), ochrony administratorów (phishing-resistant MFA), nowych zagrożeń oraz — od 2025 roku — agentów AI i tożsamości obciążeń (workload identities), co jest odpowiedzią na rosnącą rolę autonomicznych agentów w organizacjach.

Migracja z Baseline Policies — ścieżki działania

Jeśli w Twoim tenancie nadal widnieją stare baseline policies (co w 2026 roku jest już rzadkością, ale możliwe w tenantach utworzonych przed 2019 rokiem), masz trzy ścieżki migracji:

Ścieżka 1: Włącz Security Defaults (organizacje Free/mikro)

Dla małych firm, które nie potrzebują granularnych polityk — przejdź do Entra ID → Properties → Manage security defaults → Enabled. Pamiętaj, aby wcześniej poinformować użytkowników o konieczności rejestracji Microsoft Authenticator i zweryfikować, czy żadna krytyczna aplikacja nie korzysta z legacy authentication.

Ścieżka 2: Wdróż szablony Secure Foundation (organizacje z P1)

Dla organizacji z licencją Entra ID P1 — najlepsza ścieżka. W panelu Entra ID → Conditional Access → Create new policy from templates wdróż wszystkie 8 szablonów z kategorii Secure Foundation w trybie report-only. Monitoruj przez 1–2 tygodnie logi logowania (Sign-in logs → Conditional Access tab), a następnie przełącz na On. Nie zapomnij o wykluczeniu kont break-glass.

Ścieżka 3: Pełny Zero Trust (organizacje z P2)

Organizacje z Entra ID P2 powinny dodatkowo wdrożyć szablony z kategorii Zero Trust: polityki oparte na ryzyku logowania i użytkownika (sign-in risk, user risk), kontrolę aplikacji klienckich oraz — jeśli korzystają z Microsoft Purview — polityki insider risk. Wszystkie szablony można eksportować jako JSON i wdrażać przez Microsoft Graph API w pipeline'ach CI/CD.

Częste pytania

Czym różnią się Baseline Policies od Security Defaults?

Baseline Policies były czterema sztywnymi regułami dostępnymi w Azure AD przed 2020 rokiem — można je było tylko włączyć lub wyłączyć. Security Defaults to ich następca: zestaw pięciu nowoczesnych zabezpieczeń (MFA dla adminów i użytkowników, blokada legacy auth, blokada device code flow, MFA dla ARM API), również bezpłatny, ale oparty na bieżących mechanizmach Microsoft. Security Defaults domyślnie włączają się w nowych tenantach (od 22.10.2019), a od lipca 2024 bez 14-dniowego okresu grace period na MFA.

Czy nadal mogę mieć włączone stare Baseline Policies w 2026 roku?

W praktyce — nie. Microsoft wyłączył obsługę baseline policies 29 lutego 2020 roku. Jeśli masz tenant utworzony przed tą datą i nigdy nie migrowałeś, stare polityki mogą nadal widnieć w interfejsie, ale nie są egzekwowane ani wspierane. Zalecamy natychmiastowe przejście na Security Defaults (dla Free) lub Conditional Access (dla P1/P2).

Czy Security Defaults wystarczą mojej firmie, czy potrzebuję Conditional Access?

Jeśli Twoja organizacja: (a) nie ma kont break-glass wymagających wykluczeń, (b) nie używa legacy authentication w żadnej aplikacji, (c) nie potrzebuje polityk opartych na lokalizacji (np. "nie wymagaj MFA z biura"), (d) nie zarządza urządzeniami przez Intune — Security Defaults są wystarczające. Jeśli jednak masz choć jeden z powyższych przypadków, potrzebujesz licencji Entra ID P1 i pełnego Conditional Access.

Jaka jest różnica między Entra ID P1 a P2 w kontekście Conditional Access?

Licencja P1 odblokowuje pełny Conditional Access z wszystkimi sygnałami (lokalizacja, urządzenie, aplikacja) i decyzjami (MFA, compliant device, approved app). Licencja P2 dodaje risk-based Conditional Access — polityki oparte na ryzyku logowania (sign-in risk) i ryzyku użytkownika (user risk) z Entra ID Protection, a także dostęp do Conditional Access Optimization Agent (AI Copilot sugerujący optymalizacje polityk).

Czy mogę przetestować nowe polityki Conditional Access bez wpływu na użytkowników?

Tak. Każda polityka Conditional Access ma tryb Report-only — jest ewaluowana przy każdym logowaniu, ale nie blokuje dostępu. Wyniki ewaluacji trafiają do logów logowania (Sign-in logs → Conditional Access tab), gdzie można sprawdzić, ilu użytkowników i w jakich scenariuszach zostałoby zablokowanych. To kluczowa przewaga nad starymi baseline policies, które nie oferowały trybu testowego.

Co się stanie, gdy wygaśnie mi licencja Entra ID P1?

Microsoft stosuje mechanizm graceful degradation — istniejące polityki Conditional Access nie są automatycznie usuwane ani wyłączane po wygaśnięciu licencji. Możesz je przeglądać i usuwać, ale nie możesz ich edytować ani tworzyć nowych. Organizacja nie traci nagle ochrony, co daje czas na odnowienie licencji lub migrację.

Czy Conditional Access chroni przed atakami na agentów AI i workload identities?

Od 2025 roku — tak. Microsoft rozszerzył Conditional Access o kategorię AI Agents, w której dostępne są szablony: Block high-risk agent identities, Configure policy for autonomous agent access oraz Configure policy for on-behalf-of agent access. Polityki te obejmują tożsamości obciążeń (workload identities) i autonomicznych agentów AI, co jest odpowiedzią na rosnącą powierzchnię ataku w organizacjach wykorzystujących agentów.

Bezpieczna licencja Microsoft — zacznij od właściwego klucza

Niezależnie od tego, czy wdrażasz Security Defaults, czy budujesz złożone polityki Conditional Access, fundamentem bezpiecznego środowiska Microsoft jest legalny, aktywowany system operacyjny i pakiet biurowy. W KluczeSoft.pl znajdziesz w pełni legalne klucze OEM i Retail do Windows 11, Windows Server oraz Office 2024 — z natychmiastową dostawą, polską fakturą VAT i wsparciem technicznym. Sprawdź ofertę: kluczesoft.pl/klucze-windows.