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.

Azure Active Directory (Azure AD) Podmíněný přístup analyzuje signály, jako je uživatel, zařízení a umístění, a automatizuje rozhodnutí a vynucuje zásady přístupu organizace pro prostředky. Zásady podmíněného přístupu umožňují vytvářet podmínky, které spravují kontrolní mechanismy zabezpečení, které můžou blokovat přístup, vyžadovat vícefaktorové ověřování nebo omezit relaci uživatele v případě potřeby a zůstat mimo cestu uživatele, pokud ne.

Díky tomuto vyhodnocení a vynucování definuje podmíněný přístup základ správy stavu zabezpečení nulová důvěra (Zero Trust) Microsoftu.

Conditional Access overview

Microsoft poskytuje výchozí hodnoty zabezpečení, které zajišťují základní úroveň zabezpečení povolenou v tenantech, kteří nemají Azure AD Premium. 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 členitostí. Výchozí nastavení podmíněného přístupu a zabezpečení nejsou určena ke kombinování jako vytváření zásad podmíněného přístupu, takže nebudete moct povolit výchozí nastavení zabezpečení.

Požadavky

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

Zásady odpovídají na otázky ohledně toho, kdo má přistupovat k vašim prostředkům, k jakým prostředkům má přistupovat, a za jakých podmínek. Zásady je možné navrhnout tak, aby udělovaly přístup, omezovaly přístup pomocí ovládacích prvků relací nebo blokovaly přístup. Zásady podmíněného přístupu vytvoříte definováním příkazů if-then: Pokud je splněno přiřazení, použijte řízení přístupu.

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

Tady jsou některé běžné otázky týkající se přiřazení a řízení přístupu. Před vytvořením zdokumentujte odpovědi na otázky jednotlivých zásad.

Identity uživatelů nebo úloh

  • Kteří uživatelé, skupiny, role adresáře a identity úloh budou zahrnuti nebo vyloučeni ze zásad?

  • Jaké účty nebo skupiny pro nouzový přístup by se měly vyloučit ze zásad?

Cloudové aplikace nebo akce

Bude tato zásada platit pro libovolnou aplikaci, akci uživatele nebo kontext ověřování? Pokud ano-

  • Na jaké aplikace se zásady vztahují?
  • Na jaké akce uživatelů se budou tyto zásady vztahovat?
  • Na jaké kontexty ověřování se tato zásada použije?

Podmínky

  • Do kterých platforem zařízení se zásady zahrnou nebo se z ní vyloučí?

  • Jaká jsou důvěryhodná umístění organizace?

  • V jakých umístěních budou zásady zahrnuté nebo vyloučené?

  • V jakých typech klientských aplikací budou zásady zahrnuty nebo vyloučeny?

  • Máte zásady, které by ze zásad vyloučily zařízení připojená k Azure AD nebo zařízení připojená k hybridní službě Azure AD?

  • Pokud používáte Službu Identity Protection, chcete začlenit ochranu před riziky přihlašování?

Udělení nebo blokování

Chcete udělit přístup k prostředkům tím, že budete potřebovat jednu nebo více následujících možností?

  • Vyžadování MFA

  • Vyžadovat, aby zařízení bylo označené jako vyhovující

  • Vyžadovat zařízení připojené k hybridní službě Azure AD

  • Vyžadování schválené klientské aplikace

  • Vyžadování zásad ochrany aplikací

  • Vyžadovat změnu hesla

  • Podmínky použití

Řízení relace

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

  • Použití omezení vynucených aplikací

  • Použití řízení podmíněného přístupu k aplikaci

  • Vynutit frekvenci přihlašování

  • Použití trvalých relací prohlížeče

  • Přizpůsobení průběžného vyhodnocování přístupu

Vystavení přístupového tokenu

Přístupové tokeny udělují nebo zamítnou přístup na základě toho, jestli byl uživatel provádějící žádost autorizovaný a ověřený. Pokud žadatel může prokázat, že je tím, o koho se jedná, může získat přístup k chráněným prostředkům nebo funkcím.

Access token issuance diagram

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

To nezabrání tomu, aby aplikace měla samostatnou autorizaci pro blokování přístupu. Představte si například zásadu, kde:

  • POKUD je uživatel ve finančním týmu, vynuťte vícefaktorové ověřování pro přístup ke své aplikaci mzdy.

  • POKUD se uživatel, který není v finančním týmu, pokusí o přístup k aplikaci mzdy, bude uživateli vystaven přístupový token.

  • Aby uživatelé mimo finanční skupinu nemohli získat přístup k aplikaci mzdy, je potřeba vytvořit samostatnou zásadu, která zablokuje všechny ostatní uživatele. Pokud všichni uživatelé s výjimkou skupiny účtů finančního týmu a tísňového přístupu přistupují k aplikaci mzdy, zablokujte přístup.

Postupujte podle osvědčených postupů

Podmíněný přístup poskytuje skvělou flexibilitu konfigurace. Velká flexibilita ale také znamená, že byste měli pečlivě zkontrolovat jednotlivé zásady konfigurace, než je uvolníte, abyste se vyhnuli nežádoucím výsledkům.

Nastavení účtů pro nouzový přístup

Pokud zásady chybně nakonfigurujete, můžou organizace zamknout mimo Azure Portal.

Zmírnění dopadu náhodného uzamčení správce vytvořením dvou nebo více účtů pro nouzový přístup ve vaší organizaci Vytvořte uživatelský účet vyhrazený pro správu zásad a vylučte ho ze všech svých zásad.

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

Ujistěte se, že každá aplikace používá aspoň jednu zásadu podmíněného přístupu. Z hlediska zabezpečení je lepší vytvořit zásadu, která zahrnuje všechny cloudové aplikace, a pak vyloučit aplikace, na které nechcete, aby se zásady použily. Tím zajistíte, že nebudete muset aktualizovat zásady podmíněného přístupu pokaždé, když nasadíte novou aplikaci.

Důležité

Buďte velmi opatrní při používání bloků a všech aplikací v jedné zásadě. To může správcům zamknout Azure Portal 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 vede k obtížné správě. Podmíněný přístup se použije jenom na prvních 195 zásad na uživatele. Doporučujeme analyzovat aplikace a seskupit je do aplikací, které mají stejné požadavky na prostředky pro stejné uživatele. Pokud mají například všechny Microsoft 365 aplikace nebo všechny aplikace personálního oddělení stejné požadavky pro stejné uživatele, vytvořte jednu zásadu a zahrňte všechny aplikace, na které se vztahuje.

Nastavení režimu jen pro sestavy

Může být obtížné předpovědět počet a názvy uživatelů ovlivněných běžnými iniciativami nasazení, jako jsou:

  • blokování starší verze ověřování
  • vyžadování vícefaktorového ověřování
  • implementace zásad rizik přihlašování

Režim pouze sestav umožňuje správcům vyhodnotit dopad zásad podmíněného přístupu před povolením v jejich prostředí. Nejprve nakonfigurujte zásady v režimu jen pro sestavy a nechte ho běžet po dobu intervalu, než je vynucujete ve vašem prostředí.

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

Pokud se k zabezpečení IT systémů spoléháte na jedno řízení přístupu, jako je MFA nebo síťové umístění, je náchylné k chybám přístupu, pokud se toto řízení přístupu stane nedostupným nebo nesprávně nakonfigurovaným.

Pokud chcete snížit riziko uzamčení během nepředvídaných přerušení, naplánujte strategie pro přijetí pro vaši organizaci.

Nastavení standardů pojmenování pro zásady

Standard pojmenování vám pomůže najít zásady a porozumět jejich účelu, aniž byste je otevřeli na portálu pro správu Azure. Doporučujeme pojmenovat zásadu, která se má zobrazit:

  • Pořadové číslo

  • Cloudové aplikace, na které se vztahují

  • Odpověď

  • Kdo se vztahuje na

  • Pokud se použije (pokud je k dispozici)

Screenshot that shows the naming standards for policies.

Příklad; Může se jednat o zásadu, která vyžaduje vícefaktorové ověřování pro marketingové uživatele, kteří přistupují k aplikaci Dynamics CRP z externích sítí:

Naming standard

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 v konverzaci odkazovat na zásady. Když třeba mluvíte s správcem na telefonu, můžete ho požádat o otevření zásady CA01, aby vyřešil problém.

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

Kromě aktivních zásad implementujte zakázané zásady, které fungují jako sekundární odolné řízení přístupu ve scénářích výpadku nebo tísňového volání. Váš standard pojmenování pro zásady nepředvídaných událostí by měl zahrnovat:

  • Povolit funkci IN EMERGENCY na začátku, aby název vynikl mezi ostatními zásadami.

  • Název přerušení by měl platit.

  • Pořadové číslo pořadí objednávek, 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 označuje, že tato zásada je první ze čtyř zásad, které povolí, pokud dojde k přerušení vícefaktorového ověřování:

  • EM01 – POVOLENÍ V NOUZOVÉ SITUACI: Přerušení vícefaktorového ověřování [1/4] – Exchange SharePoint: Vyžadovat hybridní připojení k Azure AD pro uživatele VIRTUÁLNÍ IP adresy.

Zablokujte země, od kterých nikdy neočekáváte přihlášení.

Azure Active Directory umožňuje vytvářet pojmenovaná umístění. Vytvořte seznam zemí, které jsou povoleny, a pak vytvořte zásadu blokování sítě s těmito "povolenými zeměmi" jako vyloučení. To je méně režijní náklady pro zákazníky, kteří jsou převážně založeni na menších geografických lokalitách. Nezapomeňte z těchto zásad vyloučit účty pro nouzový přístup.

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

Až budou nové zásady připravené, nasaďte zásady podmíněného přístupu ve fázích.

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

Informace o běžných zásadách podmíněného přístupu najdete v úvodní části. Pohodlným způsobem bude použití šablony podmíněného přístupu, která se dodává s doporučeními Microsoftu. Ujistěte se, že vyloučíte účty pro nouzový přístup.

Vyhodnocení dopadu zásad

Než uvidíte dopad zásad podmíněného přístupu v produkčním prostředí, doporučujeme ke spuštění simulace použít následující dva nástroje.

Nastavení režimu jen pro sestavy

Ve výchozím nastavení se každá zásada vytváří v režimu jen pro sestavy, doporučujeme organizacím otestovat a monitorovat využití, aby se zajistil zamýšlený výsledek před zapnutím jednotlivých zásad.

Povolte zásadu v režimu jen pro sestavy. Jakmile zásadu uložíte v režimu jen pro sestavy, můžete v protokolech přihlášení vidět dopad na přihlášení v reálném čase. V protokolech přihlášení vyberte událost a přejděte na kartu Pouze sestava a zobrazte výsledek jednotlivých zásad jen pro sestavy.

Agregovaný dopad zásad podmíněného přístupu můžete zobrazit v sešitu Přehledy a vytváření sestav. Pro přístup k sešitu potřebujete předplatné služby Azure Monitor a budete muset streamovat protokoly přihlášení do pracovního prostoru služby Log Analytics .

Simulace přihlášení pomocí nástroje What If

Další způsob, jak ověřit zásady podmíněného přístupu, je pomocí nástroje Citlivostní analýza, který simuluje, které zásady se použijí pro uživatele, který se přihlásí za hypotetických okolností. Vyberte atributy přihlášení, které chcete otestovat (například uživatele, aplikaci, platformu zařízení a umístění) a zjistěte, které zásady se použijí.

Poznámka

I když simulované spuštění poskytuje dobrou představu o dopadu zásad podmíněného přístupu, nenahrazuje skutečné testovací spuštění.

Otestování zásad

Ujistěte se, že testujete kritéria vyloučení zásady. 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í.

Proveďte každý test v testovacím plánu s testovacími uživateli. Testovací plán je důležitý k porovnání očekávaných výsledků a skutečných výsledků. Následující tabulka popisuje příklady testovacích případů. Upravte scénáře a očekávané výsledky na základě konfigurace zásad podmíněného přístupu.

Zásady Scenario Očekávaný výsledek
Riziková přihlášení Uživatel se přihlásí k aplikaci pomocí neschváleného prohlížeče. Vypočítá rizikové skóre na základě pravděpodobnosti, že přihlášení neprováděl uživatel. Vyžaduje, aby uživatel sám opravil vícefaktorové ověřování.
Správa zařízení Autorizovaný uživatel se pokusí přihlásit z autorizovaného zařízení. Udělený přístup
Správa zařízení Autorizovaný uživatel se pokusí přihlásit z neoprávněného zařízení. Přístup je zablokovaný
Změna hesla pro rizikové uživatele Autorizovaný uživatel se pokusí přihlásit pomocí ohrožených přihlašovacích údajů (přihlášení s vysokým rizikem) Uživateli se zobrazí výzva ke změně hesla nebo blokování přístupu na základě zásad.

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

Po potvrzení dopadu pomocí režimu jen pro sestavy může správce přepnout přepínač Povolit zásadu jenom ze sestavy na Zapnuto.

Vrácení zásad zpět

V případě, že potřebujete vrátit zpět nově implementované zásady, použijte jednu nebo více z následujících možností:

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

enable policy image

  • Vyloučí uživatele nebo skupinu ze zásad. Pokud uživatel nemůže získat přístup k aplikaci, můžete se rozhodnout vyloučit uživatele ze zásad.

exclude users and groups

Poznámka

Tato možnost by měla být použita střídmě, pouze v situacích, kdy je uživatel důvěryhodný. Uživatel by se měl co nejdříve přidat do zásad nebo skupiny.

  • Odstraňte zásadu. Pokud už zásady nepotřebujete, odstraňte je.

Ř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 následující informace, abyste usnadnili řešení potíží.

  • Hlavní název uživatele

  • Zobrazované jméno uživatele

  • Název operačního systému

  • Časové razítko (přibližné je v pořádku)

  • Cílová aplikace

  • Typ klientské aplikace (prohlížeč a klient)

  • ID korelace (to je jedinečné pro přihlášení)

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

Can’t get to app error message

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

Další kroky

Další informace o vícefaktorovém ověřování

Další informace o službě Identity Protection

Správa zásad podmíněného přístupu pomocí Microsoftu Graph API