Plánování nasazení podmíněného přístupu

Plánování nasazení podmíněného přístupu je důležité pro dosažení strategie přístupu vaší organizace pro aplikace a prostředky. Zásady podmíněného přístupu poskytují významnou flexibilitu konfigurace. Tato flexibilita ale znamená, že je potřeba pečlivě naplánovat, abyste se vyhnuli nežádoucím výsledkům.

Podmíněný přístup Microsoft Entra kombinuje signály, jako je uživatel, zařízení a umístění, a automatizuje rozhodování a vynucuje zásady přístupu organizace pro prostředky. Tyto zásady podmíněného přístupu pomáhají vyvážit zabezpečení a produktivitu tím, že vynucují kontrolní mechanismy zabezpečení v případě potřeby a zůstávají mimo cestu uživatele, když nejsou.

Podmíněný přístup tvoří základ modulu zásad zabezpečení nulové důvěryhodnosti Microsoftu.

Microsoft poskytuje výchozí hodnoty zabezpečení , které zajišťují základní úroveň zabezpečení pro tenanty bez Microsoft Entra ID P1 nebo P2. Pomocí podmíněného přístupu můžete vytvořit zásady, které poskytují stejnou ochranu jako výchozí nastavení zabezpečení, ale s větší členitostí. Podmíněné nastavení přístupu a výchozích hodnot zabezpečení nejsou určené ke kombinování, protože vytváření zásad podmíněného přístupu vám brání v povolení výchozích hodnot zabezpečení.

Požadavky

• Funkční tenant Microsoft Entra s povolenou zkušební licencí Microsoft Entra ID P1, P2 nebo zkušební licencí. V případě potřeby si ho vytvořte zdarma.
  • Microsoft Entra ID P2 vyžaduje zahrnutí rizika ochrany Microsoft Entra ID Protection do zásad podmíněného přístupu.
• Správci, kteří pracují s podmíněným přístupem, potřebují v závislosti na úkolech, které provádějí, jedno z následujících přiřazení rolí. Pokud chcete dodržovat princip nulové důvěry a minimálních oprávnění, zvažte použití Privileged Identity Management (PIM) k aktivaci přiřazení privilegovaných rolí v reálném čase.
  • Přečtěte si zásady a konfigurace podmíněného přístupu.
    • Čtenář bezpečnostních nastavení
  • Vytvořte, upravte nebo obnovte měkce odstraněné politiky podmíněného přístupu.
    • Správce podmíněného přístupu
• Testovací uživatel (ne správce) zkontroluje, jestli zásady fungují podle očekávání, než je nasadíte skutečným uživatelům. Pokud potřebujete vytvořit uživatele, přečtěte si článek Rychlý start: Přidání nových uživatelů do Microsoft Entra ID.
• Skupina, která zahrnuje testovacího uživatele. Pokud potřebujete vytvořit skupinu, přečtěte si téma Vytvoření skupiny a přidání členů v Microsoft Entra ID.

Komunikace se změnou

Komunikace je důležitá pro úspěch všech nových funkcí. Dejte uživatelům vědět, jak se jejich zkušenosti mění, kdy se mění, a jak získat podporu, pokud mají problémy.

Komponenty zásad podmíněného přístupu

Zásady podmíněného přístupu určují, kdo má přístup k vašim prostředkům, k jakým prostředkům má přístup a za jakých podmínek. Zásady můžou udělit přístup, omezit přístup pomocí ovládacích prvků relace nebo blokovat přístup. Zásady podmíněného přístupu vytvoříte definováním příkazů if-then, jako jsou:

Pokud je splněné zadání	Použití řízení přístupu
Pokud jste uživatel v aplikaci Finance, který přistupuje k aplikaci Mzdy	Vyžadování vícefaktorového ověřování a vyhovujícího zařízení
Pokud nejste členem aplikace Finance, která přistupuje k aplikaci Mzdy	Blokování přístupu
Pokud je riziko uživatele vysoké	Vyžadovat vícefaktorové ověřování a zabezpečenou změnu hesla

Vyloučení uživatelů

Zásady podmíněného přístupu jsou výkonné nástroje. Doporučujeme z vašich zásad vyloučit následující účty:

• Nouzový přístup nebo účty pro krizové situace, které zamezují uzamčení kvůli chybné konfiguraci zásad. V nepravděpodobném scénáři, kdy jsou všichni správci uzamčeni, můžete účet pro správu tísňového přístupu použít k přihlášení a obnovení přístupu.
  • Další informace najdete v článku Správa účtů pro nouzový přístup v Microsoft Entra ID.
• Účty služeb a služební principály, jako je účet synchronizace Microsoft Entra Connect. Účty služeb jsou neinteraktivní účty, které nejsou svázané s žádným konkrétním uživatelem. Obvykle je používají back-endové služby k povolení programového přístupu k aplikacím, ale používají se také k přihlášení k systémům pro účely správy. Volání instančních objektů nejsou blokovaná zásadami podmíněného přístupu vymezenými na uživatele. Pomocí podmíněného přístupu pro identity úloh definujte zásady, které cílí na instanční objekty.
  • Pokud vaše organizace používá tyto účty ve skriptech nebo kódu, nahraďte je spravovanými identitami.

Pokládání správných otázek

Tady jsou běžné otázky týkající se přiřazení a řízení přístupu. Před vytvořením si zaznamenejte odpovědi pro každou zásadu.

Uživatelé nebo identity úloh

• Kteří uživatelé, skupiny, role adresáře nebo identity úloh jsou zahrnuti nebo vyloučeni ze zásad?
• Jaké účty nebo skupiny pro nouzový přístup byste měli ze zásad vyloučit?

Cloudové aplikace nebo akce

Platí tato zásada pro aplikaci, akci uživatele nebo kontext ověřování? Pokud ano:

• Na které aplikace nebo služby se zásady vztahují?
• Na jaké akce uživatele se vztahují tyto zásady?
• Na jaké kontexty ověřování se tato zásada vztahuje?

Filtrování pro aplikace

Použití filtru pro zahrnutí nebo vyloučení aplikací místo jejich individuálního zadání pomáhá organizacím:

• Snadné škálování a cílení na libovolný počet aplikací
• Správa aplikací s podobnými požadavky zásad
• Snížení počtu jednotlivých zásad
• Omezte chyby při úpravách zásad: Není nutné přidávat nebo odebírat aplikace ručně ze zásad. Stačí spravovat atributy.
• Překonat omezení velikosti zásad

Podmínky

• Které platformy zařízení jsou součástí zásad nebo jsou z ní vyloučeny?
• Jaká jsou známá síťová umístění organizace?
  • Která umístění jsou zahrnutá nebo vyloučená ze zásad?
• Jaké typy klientských aplikací jsou zahrnuté nebo vyloučené ze zásad?
• Potřebujete cílit na konkrétní atributy zařízení?
• Pokud používáte Microsoft Entra ID Protection, chcete začlenit riziko přihlášení nebo uživatele?

Blokování nebo udělení ovládacích prvků

Chcete udělit přístup k prostředkům tím, že požadujete jednu nebo více následujících akcí?

• Vícefaktorové ověřování
• Zařízení označené jako způsobilé
• Použití zařízení připojeného k hybridní službě Microsoft Entra
• Použití schválené klientské aplikace
• Ochrana aplikací použité zásady
• Změna hesla
• Podmínky použití byly přijaty.

Blokování přístupu je výkonný ovládací prvek. Použijte ho jenom v případech, kdy rozumíte dopadu. Zásady s blokovými příkazy mohou mít nežádoucí vedlejší účinky. Před povolením ovládacího prvku ve velkém měřítku otestujte a ověřte ho. Pokud chcete pochopit potenciální dopad při provádění změn, použijte režim ovlivnění zásad nebo režim jen pro sestavy .

Řízení relací

Chcete v cloudových aplikacích vynutit některé z následujících řízení přístupu?

• Použití omezení vynucených aplikací
• Použití řízení podmíněného přístupu k aplikacím
• Vynucení frekvence přihlašování
• Použití trvalých relací prohlížeče
• Přizpůsobení nepřetržitého vyhodnocování přístupu

Kombinování zásad

Při vytváření a přiřazování zásad zvažte, jak fungují přístupové tokeny. Přístupové tokeny udělují nebo zakazují přístup na základě toho, jestli je uživatel provádějící žádost autorizovaný a ověřený. Pokud žadatel prokáže, že je tím, za koho tvrdí, může použít chráněné prostředky nebo funkce.

Přístupové tokeny se ve výchozím nastavení vydávají, pokud podmínka zásad podmíněného přístupu neaktivuje řízení přístupu.

Tato zásada nezabrání aplikaci v blokování přístupu sama.

Představte si například zjednodušený příklad zásad, kde:

Uživatelé: FINANCE GROUP
Přístup: PAYROLL APP
Řízení přístupu: Vícefaktorové ověřování

• Uživatel A je ve skupině FINANCE, musí pro přístup k APLIKACI PAYROLL provádět vícefaktorové ověřování.
• Uživatel B není ve skupině FINANCE, je vystaven přístupový token a má povolený přístup k APLIKACI PAYROLL bez provedení vícefaktorového ověřování.

Pokud chcete zajistit, aby uživatelé mimo finanční skupinu nemohli získat přístup k aplikaci mzdy, vytvořte samostatnou zásadu, která zablokuje všechny ostatní uživatele, například tuto zjednodušenou zásadu:

Uživatelé: Zahrnout všechny uživatele / Vyloučit FINANCE GROUP
Přístup: PAYROLL APP
Řízení přístupu: Blokování přístupu

Když se uživatel B pokusí o přístup k aplikaci PAYROLL, bude zablokovaný.

Doporučení

V závislosti na našich zkušenostech s podmíněným přístupem a podpoře jiných zákazníků zde najdete několik doporučení.

Použití zásad podmíněného přístupu pro každou aplikaci

Zajistěte, aby každá aplikace používala aspoň jednu zásadu podmíněného přístupu. Z hlediska zabezpečení je lepší vytvořit zásadu, která zahrnuje všechny prostředky (dříve Všechny cloudové aplikace). Tento postup zajišťuje, že nemusíte aktualizovat zásady podmíněného přístupu pokaždé, když nasadíte novou aplikaci.

Návod

Při použití blokování a všech zdrojů v jedné zásadě buďte opatrní. Tato kombinace může zamknout správce a vyloučení se nedají nakonfigurovat pro důležité koncové body, jako je Microsoft Graph.

Minimalizace počtu zásad podmíněného přístupu

Vytvoření zásad pro každou aplikaci není efektivní a znesnadňuje správu zásad. Podmíněný přístup má limit 195 zásad na tenanta. Tento limit zásad 195 zahrnuje zásady podmíněného přístupu v jakémkoli stavu, včetně režimu jen pro sestavy, zapnutého nebo vypnutého.

Analyzujte aplikace a seskupte je podle stejných požadavků na prostředky pro stejné uživatele. Pokud mají například všechny aplikace Microsoft 365 nebo všechny aplikace pro personální oddělení stejné požadavky pro stejné uživatele, vytvořte jednu zásadu a zahrňte všechny aplikace, na které se vztahuje.

Zásady podmíněného přístupu jsou obsaženy v souboru JSON a tento soubor má limit velikosti, který jedna zásada obvykle nepřekračuje. Pokud v zásadách používáte dlouhý seznam identifikátorů GUID, můžete tento limit omezit. Pokud narazíte na tato omezení, vyzkoušejte tyto alternativy:

• Skupiny nebo role můžete použít k zahrnutí nebo vyloučení uživatelů místo individuálního výpisu jednotlivých uživatelů.
• Použijte filtr pro aplikace k zahrnutí nebo vyloučení aplikací místo jejich individuálního zadání.

Konfigurace režimu pouze sestav

Povolte zásady v režimu jen pro sestavy. Po uložení zásady v režimu jen pro sestavy se v protokolech přihlašování zobrazí účinek na přihlášení v reálném čase. V protokolech přihlašování vyberte událost a přejděte na kartu Pouze sestava , abyste viděli výsledek jednotlivých zásad jen pro sestavy.

Podívejte se na agregované účinky zásad podmíněného přístupu v sešitu Přehledy a vytváření sestav. Pokud chcete získat přístup k sešitu, potřebujete předplatné služby Azure Monitor a potřebujete streamovat přihlašovací protokoly do pracovního prostoru služby Log Analytics.

Plánování přerušení

Snižte riziko uzamčení během nepředvídatelných přerušení plánováním strategií odolnosti pro vaši organizaci.

Povolení chráněných akcí

Povolte chráněné akce , abyste přidali další vrstvu zabezpečení a pokusili se vytvořit, změnit nebo odstranit zásady podmíněného přístupu. Organizace můžou před změnou zásad vyžadovat nové vícefaktorové ověřování nebo jiné řízení udělení.

Konfigurace nastavení hostujícího uživatele

U externích organizací, které znáte a máte s nimi vztah, můžete chtít důvěřovat vícefaktorovému ověřování, souladu zařízení s předpisy nebo hybridním deklaracím zařízení, které hosté předloží vašim zásadám podmíněného přístupu. Další informace najdete v tématu Správa nastavení přístupu mezi tenanty pro spolupráci B2B. Existují určité upozornění týkající se toho, jak uživatelé B2B pracují s Microsoft Entra ID Protection, další informace naleznete v tématu Microsoft Entra ID Protection pro uživatele B2B.

Nastavení standardů pojmenování pro vaše zásady

Standard pojmenování vám pomůže najít zásady a porozumět jejich účelu bez jejich otevření. Pojmenujte zásadu, která se má zobrazit:

• Pořadové číslo
• Cloudové aplikace, na které se vztahuje
• Odpověď
• Na koho se vztahuje
• Kdy se použije

Příklad: Zásada, která vyžaduje vícefaktorové ověřování pro marketingové uživatele přistupující k aplikaci Dynamics CRP z externích sítí, může být:

Popisný název vám pomůže udržet přehled implementace podmíněného přístupu. Pořadové číslo je užitečné, pokud potřebujete odkazovat na zásady v konverzaci. Když třeba mluvíte s správcem na telefonu, můžete požádat ho, aby otevřeli zásadu CA01 a vyřešili problém.

Standardy pojmenování pro řízení tísňového přístupu

Kroměaktivních Váš standard pojmenování pro zásady nepředvídaných událostí by měl zahrnovat:

• POVOLENÍ IN EMERGENCY na začátku, aby název vynikl mezi dalšími zásadami.
• Název přerušení by měl platit pro.
• Pořadové číslo objednávky, které správci pomůžou zjistit, ve kterých zásadách objednávek by se měly povolit.

Příklad: Následující název ukazuje, že tato zásada je první ze čtyř zásad, která se povolí, pokud dojde k přerušení vícefaktorového ověřování:

• EM01 – POVOLIT V NOUZOVÉM VOLÁNÍ: Přerušení vícefaktorového ověřování [1/4] – Exchange SharePoint: Vyžaduje hybridní připojení Microsoft Entra pro uživatele VIRTUÁLNÍ IP adresy.

Blokování zemí nebo oblastí, ze kterých nikdy neočekáváte přihlášení

Id Microsoft Entra umožňuje vytvářet pojmenovaná umístění. Vytvořte seznam povolených zemí nebo oblastí a pak vytvořte zásadu blokování sítě s těmito povolenými zeměmi nebo oblastmi jako vyloučením. Tato možnost pro zákazníky na základě menších geografických umístění vytváří menší režii. Nezapomeňte z této zásady vyloučit účty pro nouzový přístup.

Nasazení zásad podmíněného přístupu

Až budete připraveni, nasaďte zásady podmíněného přístupu ve fázích. Začněte několika základními zásadami podmíněného přístupu, jako jsou ty, které následují. Mnoho zásad je k dispozici jako šablony zásad podmíněného přístupu. Ve výchozím nastavení jsou všechny zásady vytvořené ze šablony v režimu jen pro sestavy. Před zapnutím jednotlivých zásad otestujte a monitorujte využití, abyste zajistili zamýšlený výsledek.

Rozmístěte zásady ve třech následujících fázích tak, aby byla zajištěna rovnováha mezi zlepšením zabezpečení a minimálním narušením pro uživatele. Organizace můžou upravit časové osy na základě jejich velikosti, složitosti a možností správy změn.

Důležité

Před nasazením jakékoli zásady:

• Ověřte, že účty pro nouzový přístup jsou vyloučeny ze všech zásad
• Testování zásad s pilotní skupinou před zavedením v rámci celé organizace
• Ujistěte se, že uživatelé zaregistrovali požadované metody ověřování.
• Informujte o změnách ovlivněných uživatelů a poskytněte podpůrnou dokumentaci.

Fáze 1: Nadace (týden 1–2)

Vytvořte základní kontrolní mechanismy zabezpečení a připravte se na vynucování vícefaktorového ověřování. Požadavky: Než povolíte zásady prosazování, ujistěte se, že se uživatelé mohou zaregistrovat pro vícefaktorové ověřování.

Zásady podmíněného přístupu	Scenario	Požadavek na licenci
Blokování starší verze ověřování	Všichni uživatelé	Microsoft Entra ID P1
Stránka Zabezpečení registrace vícefaktorového ověřování (Moje bezpečnostní údaje)	Všichni uživatelé	Microsoft Entra ID P1
Privilegované předdefinované role Microsoft Entra vynucuje metody odolné proti útokům phishing	Privilegovaní uživatelé	Microsoft Entra ID P1

Fáze 2: Základní ověřování (týden 2–3)

Vynucujte vícefaktorové ověřování pro všechny uživatele a hosty a chraňte mobilní zařízení pomocí zásad ochrany aplikací. Klíčový dopad: Uživatelé budou muset používat vícefaktorové ověřování pro všechna přihlášení a používat schválené aplikace s ochranou aplikací na mobilních zařízeních. Ujistěte se, že je plán komunikace spuštěný a jsou k dispozici prostředky podpory.

Zásady podmíněného přístupu	Scenario	Požadavek na licenci
Všechny přihlašovací aktivity uživatelů používají silné metody ověřování.	Všichni uživatelé	Microsoft Entra ID P1
Přístup hostů je chráněný silnými metodami ověřování.	Přístup pro hosty	Microsoft Entra ID P1
Vyžadování schválených klientských aplikací nebo zásad ochrany aplikací	Mobilní uživatelé	Microsoft Entra ID P1
Vyžadovat vícefaktorové ověřování pro připojení zařízení a registraci zařízení pomocí akce uživatele	Všichni uživatelé	Microsoft Entra ID P1

Fáze 3: Rozšířená ochrana (týden 3–4)

Přidání zásad založených na rizicích a pokročilých kontrolních mechanismů ochrany před útoky Požadavek na licenci: Zásady založené na rizicích vyžadují licence Microsoft Entra ID P2.

Zásady podmíněného přístupu	Scenario	Požadavek na licenci
Omezení vysoce rizikových přihlášení	Všichni uživatelé	Microsoft Entra ID P2
Omezení přístupu k vysoce rizikovým uživatelům	Všichni uživatelé	Microsoft Entra ID P2
Přihlašovací aktivita uživatele používá ochranu tokenů.	Všichni uživatelé	Microsoft Entra ID P1
Omezení toku kódu zařízení	Všichni uživatelé	Microsoft Entra ID P1
Přenos ověřování je zablokovaný.	Všichni uživatelé	Microsoft Entra ID P1
Konfigurují se zásady podmíněného přístupu pro pracovní stanice s privilegovaným přístupem (PAW).	Privilegovaní uživatelé	Microsoft Entra ID P1

Návod

Povolte každou zásadu v režimu jen pro sestavy alespoň jeden týden před vynucováním. Před přechodem na další fázi zkontrolujte protokoly přihlašování a komunikujte s uživateli.

Poznámka:

Pracovní stanice s privilegovaným přístupem vyžadují významné plánování infrastruktury. Organizace by měly tuto zásadu implementovat až po vytvoření strategie nasazení pracovních stanic s privilegovaným přístupem a zřízení zabezpečených zařízení pro privilegované uživatele.

Vyhodnocení dopadu zásad

Pomocí dostupných nástrojů zkontrolujte účinek zásad před a po provedení změn. Simulované spuštění vám poskytne dobrou představu o tom, jak zásady podmíněného přístupu ovlivňují přihlášení, ale nenahrazuje skutečné testovací spuštění v správně nakonfigurovaném vývojovém prostředí.

Správci můžou potvrdit nastavení zásad pomocí dopadu zásad nebo režimu jen pro sestavy.

Testování zásad

Ujistěte se, že testujete vylučovací kritéria politiky. Můžete například vyloučit uživatele nebo skupinu ze zásad, které vyžadují vícefaktorové ověřování. Otestujte, jestli jsou vyloučení uživatelé vyzváni k vícefaktorové ověřování, protože kombinace dalších zásad může pro tyto uživatele vyžadovat vícefaktorové ověřování.

Spusťte každý test v testovacím plánu s testovacími uživateli. Testovací plán vám pomůže porovnat očekávané a skutečné výsledky.

Nasazení v produkčním prostředí

Po potvrzení nastavení pomocí režimu dopadu zásad nebo režimu jen pro sestavupřesuňte přepínač Povolit zásady z možnosti Pouze sestava na Zapnuto.

Vrácení zásad zpět

Pokud potřebujete vrátit zpět nově implementované zásady, použijte jednu nebo více z těchto možností:

• Zakažte zásadu. Zakázání zásady zajistí, že se nepoužije, když se uživatel pokusí přihlásit. Zásady můžete kdykoli vrátit a povolit, když je chcete použít.

• Vylučte uživatele nebo skupinu ze zásad. Pokud uživatel nemá přístup k aplikaci, vylučte ho ze zásad.

  Upozornění

  Vyloučení používejte střídmě, pouze v situacích, kdy je uživatel důvěryhodný. Uživatele přidejte co nejdříve zpět do politiky nebo skupiny.

• Pokud je zásada zakázaná a už ji nepotřebujete, odstraňte ji.

Obnovení odstraněných zásad

Pokud je podmíněný přístup nebo umístění odstraněno, můžete jej obnovit během 30denního období dočasného odstranění. Další informace o obnovení zásad podmíněného přístupu a pojmenovaných umístění najdete v článku Obnovení po odstranění.

Řešení potíží se zásadami podmíněného přístupu

Pokud má uživatel problém se zásadami podmíněného přístupu, shromážděte tyto informace, které vám pomůžou s řešením potíží.

• Hlavní název uživatele
• Zobrazované jméno uživatele
• Název operačního systému
• Časové razítko (přibližný čas je v pořádku)
• Cílová aplikace
• Typ klientské aplikace (prohlížeč nebo klient)
• ID korelace (toto ID je jedinečné pro přihlášení)

Pokud uživatel dostane zprávu s odkazem Další podrobnosti , může za vás shromažďovat většinu těchto informací.

Jakmile tyto informace shromáždíte, projděte si tyto zdroje informací:

• Problémy s přihlášením pomocí podmíněného přístupu – Přečtěte si o neočekávaných výsledcích přihlašování souvisejících s podmíněným přístupem pomocí chybových zpráv a protokolu přihlášení Microsoft Entra.
• Použití nástroje What-If – Zjistěte, proč se zásada používá nebo nepoužívá pro uživatele v konkrétní situaci nebo jestli se zásada vztahuje ve známém stavu.

Související obsah

• Další informace o vícefaktorové ověřování
• Další informace o službě Microsoft Entra ID Protection
• Správa zásad podmíněného přístupu pomocí rozhraní Microsoft Graph API