Architektura a zásady podmíněného přístupu
Tento článek poskytuje rámec pro implementaci architektury podmíněného přístupu založeného na personách, podobný tomu, který je popsán v architektuře nulové důvěry podmíněného přístupu. V tomto článku najdete podrobnosti o tom, jak vytvořit a pojmenovat zásady podmíněného přístupu. Existuje také výchozí bod pro vytváření zásad.
Pokud nepoužíváte rámec, jako je tento, který je zde k dispozici, včetně standardu pojmenování, bývají zásady postupem času vytvářeny různými lidmi nahodilým způsobem. To může vést k tomu, že se zásady překrývají. Pokud už osoba, která zásadu vytvořila, není dostupná, může být pro ostatní obtížné znát účel zásady.
Sledování strukturované architektury usnadňuje pochopení zásad. Usnadňuje také pokrytí všech scénářů a zabránění konfliktům zásad, které se obtížně řeší.
Konvence pojmenování
Správně definované zásady vytváření názvů pomáhají vám a vašim kolegům porozumět účelu zásady, což umožňuje snadnější správu zásad a řešení potíží. Zásady vytváření názvů by se měly vejít do architektury, kterou používáte ke strukturování zásad.
Doporučené zásady pojmenování jsou založené na osobách, typech zásad a aplikacích. Vypadá takto:
< >CANumber –<osoba>–<PolicyType>–<Aplikace>–<Platforma>–<UděleníKontroly>–<NepovinnýPopis>
Součásti tohoto názvu jsou popsány zde:
| Komponenta pojmenování | Popis/příklad |
|---|---|
| Číslo certifikační autority | Používá se k rychlé identifikaci rozsahu a pořadí typů zásad. Příklad: CA001-CA099. |
| Osobnost | Globální, Administrátoři, Interní, Externí, HostujícíUživatelé, HostujícíAdministrátoři, ÚčtySlužebMicrosoft365, ÚčtySlužebAzure, ÚčtySlužebSpolečnosti. |
| Typ zásady | Základní ochrana, Ochrana aplikací, Ochrana dat, Ochrana identity, Snížení povrchu útoku, Dodržování předpisů. |
| Aplikace | AllApps, O365 (pro všechny služby Office 365), EXO (pro Exchange Online). |
| Platforma | AnyPlatform, Unknown, WindowsPhone, macOS, iOS, Android. |
| Poskytnout ovládání | Blokovat, ADHJ, V souladu, Nespravováno (kde nespravováno je specifikováno v podmínce stavu zařízení). |
| Popis | Volitelný popis účelu zásady. |
Schéma číslování
Pro usnadnění správy doporučujeme toto schéma číslování:
| Skupina Persona | Přidělení čísel |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| Ca-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| Ca-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| Ca-Persona-M365ServiceAccounts | CA600-CA699 |
| Ca-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| Ca-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Typy zásad
Toto jsou doporučené typy zásad:
| Typ zásady | Popis/příklady |
|---|---|
| BaseProtection | Pro každou osobu existuje základní ochrana, na kterou se vztahuje tento typ zásad. Pro uživatele na spravovaných zařízeních se obvykle jedná o známého uživatele a známého zařízení. U externích hostů se může jednat o známého uživatele a vícefaktorové ověřování. Základní ochrana je výchozí zásada pro všechny aplikace pro uživatele v dané osobě. Pokud by určitá aplikace měla mít jinou zásadu, vyloučte ji ze zásad základní ochrany a přidejte explicitní zásadu, která cílí jenom na danou aplikaci. Příklad: Předpokládejme, že základní ochrana interních aplikací vyžaduje známého uživatele a známého zařízení pro všechny cloudové aplikace, ale chcete povolit Outlook na webu z libovolného zařízení. Můžete vyloučit Exchange Online ze zásad základní ochrany a přidat samostatnou zásadu pro Exchange Online, kde potřebujete známé zařízení NEBO vícefaktorové ověřování. |
| Ochrana identity | Nad základní ochranou pro každou osobu můžete mít zásady podmíněného přístupu, které se vztahují k identitě. Příklady: Blokování starší verze ověřování, vyžadování dodatečného vícefaktorového ověřování pro vysoké riziko uživatele nebo přihlášení, vyžaduje známé zařízení pro registraci vícefaktorového ověřování. |
| Ochrana dat | Tento typ zásady označuje rozdílové zásady, které chrání data jako dodatečnou vrstvu nad základní ochranou. Příklady:
|
| AppProtection | Tento typ zásady je dalším doplňkem základní ochrany. Příklady:
|
| RedukceÚtočnéhoPovrchu | Účelem tohoto typu zásad je zmírnit různé útoky. Příklady:
|
| Vyhovění | Pomocí zásad dodržování předpisů můžete vyžadovat, aby uživatel zobrazil podmínky použití pro hosty, kteří přistupují ke zákaznickým službám. |
Aplikace
Následující tabulka popisuje komponentu aplikace v názvu zásady:
| Název aplikace | Popis/příklady |
|---|---|
| AllApps | AllApps indikuje, že všechny cloudové aplikace jsou cílem zásad podmíněného přístupu. Všechny koncové body jsou pokryté, včetně těch, které podporují podmíněný přístup, a těch, které nepodporují. V některých scénářích nefunguje cílení na všechny aplikace dobře. Doporučujeme cílit na všechny aplikace v základních zásadách, aby se na všechny koncové body vztahovaly dané zásady. Nové aplikace, které se zobrazí v Microsoft Entra ID, budou také automaticky dodržovat zásady. |
| <AppName> |
<AppName> je zástupný symbol pro název aplikace, kterou zásady adresuje. Vyhněte se příliš dlouhému názvu. Příklady názvů:
|
Typ platformy
Následující tabulka popisuje komponent platformy názvu politiky:
| Typ platformy | Popis |
|---|---|
| AnyPlatform | Zásady cílí na libovolnou platformu. Obvykle ho nakonfigurujete tak, že vyberete jakékoliv zařízení. (V zásadách podmíněného přístupu se používá slovo platformu i slovo zařízení.) |
| Ios | Zásady cílí na platformy Apple iOS. |
| Android | Zásady cílí na platformy Google Android. |
| Windows | Tato zásada cílí na platformu Windows. |
| Linux | Tato zásada cílí na platformy Linux. |
| WindowsPhone | Zásady cílí na platformy Windows Phone. |
| macOS | Zásady cílí na platformy macOS. |
| iOSAndroid | Zásady cílí na platformy iOS i Android. |
| Neznámý | Zásady cílí na libovolnou platformu, která nebyla uvedená dříve. Obvykle ho nakonfigurujete tak, že zahrnete jakékoli zařízení a vyloučíte všechny jednotlivé platformy. |
Udělení typů ovládacích prvků
Následující tabulka popisuje komponentu Řízení oprávnění názvu politiky:
| Typ udělení | Popis/příklady |
|---|---|
| Blokovat | Zásady blokují přihlášení. |
| MFA | Zásady vyžadují vícefaktorové ověřování. |
| V souladu | Tato zásada vyžaduje vyhovující zařízení určené endpoint Managerem, takže zařízení musí spravovat Endpoint Manager. |
| CompliantorAADHJ | Zásady vyžadují vyhovující zařízení NEBO zařízení připojené k hybridnímu připojení Microsoft Entra. Standardní firemní počítač připojený k doméně je zároveň připojený k hybridnímu identifikátoru Microsoft Entra ID. Mobilní telefony a počítače s Windows 10, které jsou spoluspravované nebo jsou připojené k Microsoft Entra, můžou vyhovovat předpisům. |
| CompliantandAADHJ | Zásada vyžaduje zařízení, které splňuje předpisy a je hybridně připojeno přes Microsoft Entra. |
| MFAorCompliant | Zásady vyžadují kompatibilní zařízení NEBO vícefaktorové ověřování, pokud nevyhovuje předpisům. |
| MFAandCompliant | Zásady vyžadují kompatibilní zařízení A vícefaktorové ověřování. |
| MFAorAADHJ | Pokud se nejedná o počítač hybridně připojený k Microsoft Entra, tato zásada vyžaduje buď takový počítač, nebo vícefaktorové ověřování. |
| MFAandAADHJ | Tato zásada vyžaduje počítač připojený k hybridní službě Microsoft Entra A vícefaktorové ověřování. |
| VyžadovatSchválenéhoKlienta | Zásady vyžadují schválenou klientskou aplikaci. |
| AppProtection | Zásady vyžadují ochranu aplikací. |
| Neřízené | Zásady se zaměřují na zařízení, která nejsou známá v Microsoft Entra ID. Tento typ udělení můžete například použít k povolení přístupu k Exchangi Online z libovolného zařízení. |
Pojmenovaná místa
Doporučujeme definovat tato standardní umístění pro použití v zásadách podmíněného přístupu:
- Důvěryhodné IP adresy / interní sítě. Tyto podsítě PROTOKOLU IP představují umístění a sítě, které mají zavedená omezení fyzického přístupu nebo jiné ovládací prvky, jako je správa systému počítačů, ověřování na úrovni sítě nebo detekce neoprávněných vniknutí. Tato umístění jsou bezpečnější, takže vynucení podmíněného přístupu může být uvolněné. Zvažte, jestli by měla být v tomto umístění zahrnuta umístění jako Azure nebo jiná datacentra, nebo zda by měla mít vlastní pojmenovaná umístění.
- Důvěryhodné IP adresy Citrixu Pokud máte místní Citrix, může být užitečné nakonfigurovat samostatné odchozí IPv4 adresy pro farmy Citrix, pokud se potřebujete připojit ke cloudovým službám z relací Citrixu. V takovém případě můžete tato umístění vyloučit ze zásad podmíněného přístupu, pokud potřebujete.
- Umístění Zscaler, pokud je to použitelné. Počítače mají nainstalovaného agenta ZPA a přesměrovávají veškerý provoz na internet do cloudu Zscaler nebo přes cloud Zscaler. Proto je vhodné definovat zdrojové IP adresy Zscaler v podmíněném přístupu a požadovat, aby všechny žádosti od jiných než mobilních zařízení prošly Zscaler.
- Země/oblasti, se kterými je povoleno obchodovat. Může být užitečné rozdělit země nebo oblasti do dvou skupin umístění: jednu, která představuje oblasti světa, kde zaměstnanci obvykle pracují a jedna, která představuje jiná místa. To vám umožní použít další ovládací prvky na žádosti, které pocházejí z oblastí mimo místa, kde vaše organizace normálně funguje.
- Umístění, kde může být vícefaktorové ověřování obtížné nebo nemožné. V některých scénářích může vyžadování vícefaktorového ověřování ztížit práci zaměstnanců. Zaměstnanci například nemusí mít čas nebo příležitost reagovat na časté problémy s vícefaktorovým ověřováním. Nebo v některých umístěních může používání mobilních zařízení ztížit blokování RF nebo elektrické rušení. Obvykle byste v těchto umístěních používali jiné ovládací prvky nebo by mohly být důvěryhodné.
Řízení přístupu na základě polohy závisí na zdrojové IP adrese požadavku, aby bylo možné určit umístění uživatele v době požadavku. Není snadné provádět falšování identity na veřejném internetu, ale ochrana poskytovaná hranicemi sítě může být považována za méně relevantní, než kdy byla. Nedoporučujeme spoléhat se výhradně na umístění jako podmínku pro přístup. V některých scénářích ale může být nejlepší kontrolou, kterou můžete použít, například pokud zabezpečujete přístup z účtu služby z místního prostředí, který se používá v neinteraktivním scénáři.
Doporučené zásady podmíněného přístupu
Vytvořili jsme tabulku, která obsahuje doporučené zásady podmíněného přístupu. Tabulku si můžete stáhnout zde.
Použijte navrhované zásady jako výchozí bod.
Vaše zásady se pravděpodobně v průběhu času změní tak, aby vyhovovaly případům použití, které jsou pro vaši firmu důležité. Tady je několik příkladů scénářů, které můžou vyžadovat změny:
- Implementujte přístup jen pro čtení k Exchange Online pro zaměstnance, kteří používají jakékoli nespravované zařízení, využívající vícefaktorové ověřování, ochranu aplikace a schválenou klientskou aplikaci.
- Implementujte ochranu informací, abyste zajistili, že se citlivé informace nestáhnou bez vylepšené ochrany poskytované službou Azure Information Protection.
- Zajistěte ochranu před kopírováním a vkládáním hosty.
V současné době se více verzí přesouvá do veřejné zkušební fáze, takže brzy očekávejte aktualizace navrhovaných sad výchozích zásad pro podmíněný přístup (CA).
Pokyny k podmíněnému přístupu
Teď, když máte úvodní sadu zásad podmíněného přístupu, je potřeba je nasadit řízeným a fázovaným způsobem. Doporučujeme použít model nasazení.
Tady je jeden přístup:
Cílem je nejprve nasadit zásady malému počtu uživatelů v rámci jedné skupiny osob. Pro toto nasazení můžete použít přidruženou skupinu Microsoft Entra s názvem Persona Ring 0. Po ověření, že všechno funguje, změníte přiřazení na skupinu, Persona Ring 1, která má více členů atd.
Zásady pak povolíte pomocí stejného přístupu založeného na okruhu, dokud se nenasadí všechny zásady.
Členy okruhu 0 a 1 obvykle spravujete ručně. Skupinu okruhu 2 nebo 3, která obsahuje stovky nebo dokonce tisíce uživatelů, je možné spravovat prostřednictvím dynamické skupiny založené na procentech uživatelů v dané osobě.
Používání kroužků jako součásti modelu nasazení není určeno pouze pro počáteční nasazení. Můžete ho použít také v případě, že jsou vyžadovány nové zásady nebo změny stávajících zásad.
Po dokončení nasazení byste také měli navrhnout a implementovat ovládací prvky monitorování, které byly popsány v zásad podmíněného přístupu.
Kromě automatizace počátečního nasazení můžete chtít automatizovat změny zásad pomocí kanálů CI/CD. Pro tuto automatizaci můžete použít Microsoft365DSC.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Claus Jespersen | ID vedoucího konzultanta&Sec
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
- Výuková cesta : Implementace a správa identity a přístupu
- zásady podmíněného přístupu