Architektura a zásady podmíněného přístupu
Tento článek poskytuje architekturu pro implementaci architektury podmíněného přístupu založené na osobě, jako je architektura popsaná v architektuře podmíněného přístupu nulová důvěra (Zero Trust). 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 architekturu, jako je architektura, která je zde k dispozici, včetně standardu pojmenování, bývají zásady postupem času vytvářeny různými lidmi ad hoc způsobem. To může vést k překrývání zásad. 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ší.
Zásady vytváření názvů
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-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>
Součásti tohoto názvu jsou popsány zde:
| Komponenta názvu | Popis/příklad |
|---|---|
| Číslo certifikační autority | Používá se k rychlé identifikaci rozsahu a pořadí typů zásad. Příklad: CA001-CA099. |
| Osoba | Global, Správa s, Internals, Externals, GuestUsers, Guest Správa s, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Typ zásad | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| Aplikace | AllApps, O365 (pro všechny služby Office 365), EXO (pro Exchange Online). |
| Platforma | AnyPlatform, Unknown, Windows Telefon, macOS, iOS, Android. |
| Udělení ovládacího prvku | Block, ADHJ, Compliant, Unmanaged (where unmanaged is specified in the device state condition). |
| 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-Správa s | CA100-CA199 |
| Interní osobě certifikační autority | CA200-CA299 |
| Externí osobě certifikační autority | CA300-CA399 |
| Ca-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-Guest Správa s | 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 zařízení 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í. |
| IdentityProtection | 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 další vrstvu nad základní ochranou. Příklady:
|
| AppProtection | Tento typ zásady je dalším doplňkem základní ochrany. Příklady:
|
| AttackSurfaceReduction | Účelem tohoto typu zásad je zmírnit různé útoky. Příklady:
|
| Splnění předpisů | 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 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 komponentu platformy názvu zásady:
| Typ platformy | Popis |
|---|---|
| AnyPlatform | Zásady cílí na libovolnou platformu. Obvykle ho nakonfigurujete výběrem libovolného zařízení. (Vzásadách |
| 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. |
| Windows Telefon | Zásady cílí na platformy Windows Telefon. |
| 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 to 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í udělení oprávnění názvu zásady:
| Typ udělení | Popis/příklady |
|---|---|
| Blokovat | Zásady blokují přihlášení. |
| MFA | Zásady vyžadují vícefaktorové ověřování. |
| Kompatibilní | 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 také připojený k hybridnímu ID Microsoft Entra. 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 | Tato zásada vyžaduje zařízení, které splňuje předpisy A hybridní připojení 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č připojený k hybridnímu připojení microsoftu Entra, vyžaduje tato zásada vícefaktorové ověřování 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í. |
| RequireApprovedClient | Zásady vyžadují schválenou klientskou aplikaci. |
| AppProtection | Zásady vyžadují ochranu aplikací. |
| Nespravovaná | Zásady cílí na zařízení, která nejsou známá id Microsoft Entra. Tento typ udělení můžete například použít k povolení přístupu k Exchangi Online z libovolného zařízení. |
Pojmenovaná umístění
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 mají být v tomto umístění zahrnutá jiná umístění datacenter nebo jiná umístění datacentra nebo jestli mají vlastní pojmenovaná umístění.
- Ip adresy důvěryhodných citrixů 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 možné. Počítače mají nainstalovaného agenta ZPA a přesměrovávat veškerý provoz do internetu 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 mají být firmy povoleny. 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í, 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 tady.
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 k Exchangi Online jen pro čtení pro zaměstnance, kteří používají jakékoli nespravované zařízení na základě vícefaktorového ověřování, ochrany aplikací a schválené klientské aplikace.
- 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 do veřejné verze Preview přechází více verzí Preview, takže brzy můžete očekávat aktualizace navrhovaných sad počátečních zásad podmíněného přístupu (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žití okruhů v rámci modelu nasazení není jen 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 měli také navrhnout a implementovat ovládací prvky monitorování, které byly popsány v zásadách 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 hlavního konzultanta
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Související prostředky
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro