Vytvoření odolné strategie správy řízení přístupu pomocí Azure Active Directory

Poznámka

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Vzhledem k tomu, že Microsoft musí reagovat na měnící se podmínky na trhu, nemělo by být interpretováno jako závazek ze strany Microsoft a Microsoft nemůže zaručit přesnost informací předložených po datu zveřejnění.

Organizace, které k zabezpečení it systémů spoléhají na jedno řízení přístupu, jako je například vícefaktorové ověřování (MFA) nebo jedno síťové umístění, jsou náchylné k selhání přístupu k aplikacím a prostředkům, pokud se toto jedno řízení přístupu stane nedostupným nebo chybně nakonfigurovaným. Například přírodní katastrofa může způsobit nedostupnost velkých segmentů telekomunikační infrastruktury nebo podnikových sítí. Takové přerušení by mohlo bránit koncovým uživatelům a správcům v přihlášení.

Tento dokument obsahuje pokyny ke strategiím, které by organizace měla přijmout, aby poskytovala odolnost, aby se snížilo riziko uzamčení při nepředvídatelných přerušeních, a to v následujících scénářích:

  • Organizace můžou zvýšit odolnost, aby snížily riziko uzamčení před přerušením tím, že implementují strategie pro zmírnění rizik nebo plány pro nepředvídané události.
  • Organizace můžou i nadále přistupovat k aplikacím a prostředkům, které si vyberou během přerušení, a to díky strategii zmírnění rizik a plánům pro nepředvídané události.
  • Organizace by se měly ujistit, že po přerušení a před vrácením veškerých případných nepředvídaných událostí, které implementovaly, uchovávají informace, jako jsou protokoly.
  • Organizace, které neimplementovaly strategie prevence nebo alternativní plány, můžou být schopny implementovat nouzové možnosti , aby se s přerušením vypořádaly.

Klíčové pokyny

V tomto dokumentu jsou čtyři klíčové poznatky:

  • Vyhněte se uzamčení správce pomocí účtů pro nouzový přístup.
  • Implementujte vícefaktorové ověřování s využitím podmíněného přístupu místo vícefaktorového ověřování pro jednotlivé uživatele.
  • Zmírnění uzamčení uživatelů pomocí několika ovládacích prvků podmíněného přístupu
  • Zmírněte uzamčení uživatelů zřízením více metod ověřování nebo ekvivalentů pro každého uživatele.

Před přerušením

Zmírnění skutečného přerušení musí být primárním cílem organizace při řešení problémů s řízením přístupu, které mohou nastat. Zmírnění rizik zahrnuje plánování skutečné události a implementaci strategií, které zajistí, že řízení přístupu a operace nebudou během přerušení ovlivněny.

Proč potřebujete odolné řízení přístupu?

Identita je řídicí rovina uživatelů, kteří přistupují k aplikacím a prostředkům. Váš systém identit řídí, kteří uživatelé a za jakých podmínek, jako jsou řízení přístupu nebo požadavky na ověřování, získají přístup k aplikacím. Pokud kvůli nepředvídatelným okolnostem není pro uživatele k dispozici jeden nebo více požadavků na ověřování nebo řízení přístupu, můžou se v organizacích vyskytnout některé z následujících problémů:

  • Uzamčení správce: Správci nemůžou spravovat tenanta ani služby.
  • Uzamčení uživatele: Uživatelé nemají přístup k aplikacím ani prostředkům.

Nepředvídané uzamčení správcem

Pokud chcete odemknout přístup správce k vašemu tenantovi, měli byste vytvořit účty pro nouzový přístup. Tyto účty pro nouzový přístup, označované také jako účty break glass, umožňují přístup ke správě konfigurace Azure AD, pokud nejsou k dispozici běžné postupy přístupu k privilegovaným účtům. Na základě doporučení k účtu pro nouzový přístup by se měly vytvořit aspoň dva účty pro nouzový přístup.

Zmírnění rizik uzamčení uživatelů

Pokud chcete zmírnit riziko uzamčení uživatelů, použijte zásady podmíněného přístupu s několika ovládacími prvky, které uživatelům umožní zvolit, jak budou přistupovat k aplikacím a prostředkům. Když uživateli dáte možnost volby mezi například přihlášením pomocí vícefaktorového ověřování nebo přihlášením ze spravovaného zařízení nebo přihlášením z podnikové sítě, má uživatel v případě, že některý z ovládacích prvků přístupu není k dispozici, má další možnosti, jak dál fungovat.

Microsoft doporučení

Do stávajících zásad podmíněného přístupu pro organizaci začleníte následující řízení přístupu:

  • Pro každého uživatele zřiďte několik metod ověřování, které závisí na různých komunikačních kanálech, například aplikace Microsoft Authenticator (internetová), token OATH (vygenerovaný na zařízení) a SMS (telefonní). Následující skript PowerShellu vám pomůže předem určit, které další metody by uživatelé měli zaregistrovat: Skript pro Azure AD analýzu metody ověřování vícefaktorového ověřování.
  • Nasaďte Windows Hello pro firmy na Windows 10 zařízení, abyste splnili požadavky na vícefaktorové ověřování přímo z přihlášení zařízení.
  • Používejte důvěryhodná zařízení prostřednictvím Azure AD Hybrid Join nebo Microsoft Endpoint Manager. Důvěryhodná zařízení zlepší uživatelské prostředí, protože samotné důvěryhodné zařízení může splňovat požadavky zásad na silné ověřování bez výzvy vícefaktorového ověřování pro uživatele. MFA se pak bude vyžadovat při registraci nového zařízení a při přístupu k aplikacím nebo prostředkům z nedůvěryhodných zařízení.
  • Použijte Azure AD zásady ochrany identit založené na rizicích, které brání přístupu, když je uživatel nebo přihlášení ohrožen místo pevných zásad MFA.
  • Pokud chráníte přístup k síti VPN pomocí Azure AD rozšíření MFA NPS, zvažte federování řešení VPN jako aplikace SAML a určete kategorii aplikací, jak je doporučeno níže.

Poznámka

Zásady založené na rizicích vyžadují Azure AD Premium P2 licence.

Následující příklad popisuje zásady, které musíte vytvořit, abyste uživatelům zajistili odolné řízení přístupu pro přístup k aplikacím a prostředkům. V tomto příkladu budete vyžadovat skupinu zabezpečení AppUsers s cílovými uživateli, kterým chcete udělit přístup, skupinu s názvem CoreAdmins s hlavními správci a skupinu s názvem EmergencyAccess s účty pro nouzový přístup. Tato ukázková sada zásad udělí vybraným uživatelům ve skupině AppUsers přístup k vybraným aplikacím, pokud se připojují z důvěryhodného zařízení nebo poskytují silné ověřování, například vícefaktorové ověřování. Nezahrnuje účty tísňového volání a základní správce.

Sada zásad pro zmírnění rizik certifikační autority:

  • Zásada 1: Blokování přístupu uživatelům mimo cílové skupiny
    • Uživatelé a skupiny: Zahrnout všechny uživatele. Vyloučení uživatelů aplikací, CoreAdmins a EmergencyAccess
    • Cloud Apps: Zahrnout všechny aplikace
    • Podmínky: (Žádné)
    • Udělení ovládacího prvku: Blokovat
  • Zásada 2: Udělte přístup uživatelům aplikací, kteří vyžadují vícefaktorové ověřování nebo důvěryhodné zařízení.
    • Uživatelé a skupiny: Zahrnout uživatele aplikací. Vyloučení CoreAdmins a EmergencyAccess
    • Cloud Apps: Zahrnout všechny aplikace
    • Podmínky: (Žádné)
    • Udělení řízení: Udělte přístup, vyžadovat vícefaktorové ověřování, vyžadovat, aby zařízení splňovalo předpisy. Pro více ovládacích prvků: Vyžaduje jeden z vybraných ovládacích prvků.

Nepředvídané události při uzamčení uživatele

Případně může vaše organizace vytvořit také zásady nepředvídaných událostí. Pokud chcete vytvořit zásady nepředvídaných událostí, musíte definovat kritéria kompromisu mezi provozní kontinuitou, provozními náklady, finančními náklady a bezpečnostními riziky. Zásady nepředvídaných událostí můžete například aktivovat pouze pro podmnožinu uživatelů, pro podmnožinu aplikací, podmnožinu klientů nebo z podmnožina umístění. Zásady nepředvídaných událostí poskytnou správcům a koncovým uživatelům přístup k aplikacím a prostředkům během přerušení, kdy nebyla implementována žádná metoda zmírnění rizik. Microsoft doporučuje povolit zásady pro nepředvídané události v režimu jen pro sestavy, pokud se nepoužívají, aby správci mohli monitorovat potenciální dopad těchto zásad, pokud by je bylo potřeba zapnout.

Pochopení vašeho vystavení během přerušení pomáhá snížit vaše riziko a je klíčovou součástí procesu plánování. Pokud chcete vytvořit plán pro nepředvídané události, nejprve určete následující obchodní požadavky vaší organizace:

  1. Určete si důležité aplikace předem: K jakým aplikacím musíte udělit přístup, a to i při nižším riziku nebo stavu zabezpečení? Vytvořte seznam těchto aplikací a ujistěte se, že ostatní účastníci (obchodní, bezpečnostní, právní, vedoucí) souhlasí s tím, že i když veškeré řízení přístupu zmizí, musí tyto aplikace dál běžet. Pravděpodobně skončíte s kategoriemi:
    • Klíčové aplikace kategorie 1 , které nemohou být nedostupné déle než několik minut, například Aplikace, které přímo ovlivňují výnosy organizace.
    • Důležité aplikace kategorie 2 , ke kterým musí být firma během několika hodin přístupná.
    • Aplikace kategorie 3 s nízkou prioritou , které odolají několikadennímu přerušení.
  2. Pro aplikace v kategorii 1 a 2 Microsoft doporučuje předem naplánovat, jaký typ úrovně přístupu chcete povolit:
    • Chcete povolit úplný přístup nebo omezenou relaci, jako je omezení stahování?
    • Chcete povolit přístup k části aplikace, ale ne k celé aplikaci?
    • Chcete povolit přístup informačního pracovníka a blokovat přístup správce, dokud se neobnoví řízení přístupu?
  3. U těchto aplikací Microsoft také doporučuje naplánovat, které cesty přístupu záměrně otevřete a které zavřete:
    • Chcete povolit přístup k prohlížeči a blokovat bohaté klienty, kteří můžou ukládat offline data?
    • Chcete povolit přístup jenom uživatelům v podnikové síti a ponechat uživatele mimo uživatele blokované?
    • Chcete povolit přístup z určitých zemí nebo oblastí pouze během přerušení?
    • Chcete, aby zásady pro nepředvídané zásady, zejména pro klíčové aplikace, selhaly nebo uspěly, pokud není k dispozici alternativní řízení přístupu?

Microsoft doporučení

Zásada podmíněného přístupu pro nepředvídané události je zásada zálohování, která vynechává Azure AD vícefaktorového ověřování, vícefaktorového ověřování třetích stran, řízení založené na rizicích nebo na zařízeních. Aby se minimalizovalo neočekávané přerušení, když je povolená zásada nepředvídaných událostí, měla by zásada zůstat v režimu jen pro sestavy, pokud se nepoužívá. Správci můžou monitorovat potenciální dopad svých zásad nepředvídaných událostí pomocí sešitu Přehledy podmíněného přístupu. Když se vaše organizace rozhodne aktivovat plán pro nepředvídané události, můžou správci zásadu povolit a zakázat běžné zásady založené na řízení.

Důležité

Zakázáním zásad, které vynucují zabezpečení uživatelům, a to i dočasně, snížíte stav zabezpečení, když je plán pro nepředvídané události v platnosti.

  • Nakonfigurujte sadu záložních zásad, pokud narušení jednoho typu přihlašovacích údajů nebo jednoho mechanismu řízení přístupu ovlivňuje přístup k vašim aplikacím. Nakonfigurujte zásadu v pouze sestavě, která jako ovládací prvek vyžaduje připojení k doméně jako zálohu aktivních zásad, které vyžadují poskytovatele vícefaktorového ověřování třetí strany.
  • Snižte riziko hádání hesel špatnými aktéry, když se nevyžaduje vícefaktorové ověřování, a to pomocí postupů v dokumentu white paper s pokyny k hesl.
  • Nasaďte Azure AD Self-Service resetování hesla (SSPR) a Azure AD ochranu heslem, abyste měli jistotu, že uživatelé nebudou používat běžná hesla a termíny, které chcete zakázat.
  • Používejte zásady, které omezují přístup v rámci aplikací, pokud není dosaženo určité úrovně ověřování, místo abyste se jednoduše vrátili k úplnému přístupu. Příklad:
    • Nakonfigurujte zásadu zálohování, která odesílá deklaraci identity relace s omezeným přístupem do Exchange a SharePointu.
    • Pokud vaše organizace používá Microsoft Defender for Cloud Apps, zvažte návrat k zásadám, které zapojí Defender for Cloud Apps a pak povolí přístup jen pro čtení, ale ne nahrávání.
  • Pojmenujte zásady, abyste měli jistotu, že je během přerušení snadno najdete. Do názvu zásady zahrňte následující prvky:
    • Číslo popisku pro zásadu
    • Text, který se má zobrazit, tato zásada je určena pouze pro nouzové situace. Příklad: POVOLIT V NOUZOVÉM STAVU
    • Narušení , na které se vztahuje. Příklad: Během přerušení vícefaktorového ověřování
    • Pořadové číslo pro zobrazení pořadí, ve které musíte zásady aktivovat.
    • Aplikace, na které se vztahuje.
    • Ovládací prvky, které použije.
    • Podmínky, které vyžaduje.

Tento standard pojmenování pro zásady nepředvídaných událostí bude následující:

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

Následující příklad: Příklad A – Zásady podmíněného přístupu na nepředvídané události pro obnovení přístupu k důležitým aplikacím pro spolupráci, jsou typické podnikové události. V tomto scénáři organizace obvykle vyžaduje vícefaktorové ověřování pro všechny Exchange Online a přístup k SharePointu Online a přerušením je v tomto případě poskytovatel vícefaktorového ověřování pro zákazníka (bez ohledu na to, jestli Azure AD vícefaktorové ověřování, místního poskytovatele vícefaktorového ověřování nebo jiného poskytovatele vícefaktorového ověřování). Tato zásada tento výpadek zmírní tím, že konkrétním cílovým uživatelům povolí přístup k těmto aplikacím z důvěryhodných zařízení s Windows jenom v případě, že k aplikaci přistupují ze své důvěryhodné podnikové sítě. Z těchto omezení se také vyloučí účty tísňového volání a hlavní správci. Cíloví uživatelé pak získají přístup k Exchange Online a SharePointu Online, zatímco ostatní uživatelé nebudou mít přístup k aplikacím kvůli výpadku. Tento příklad bude vyžadovat pojmenované síťové umístění CorpNetwork a skupinu zabezpečení EmergencyAccess s cílovými uživateli, skupinu CoreAdmins s hlavními správci a skupinu s názvem EmergencyAccess s účty pro nouzový přístup. K zajištění požadovaného přístupu vyžaduje nepředvídaná událost čtyři zásady.

Příklad A – Zásady podmíněného přístupu pro nepředvídané obnovení přístupu k důležitým aplikacím pro spolupráci:

  • Zásada 1: Vyžadovat zařízení připojená k doméně pro Exchange a SharePoint
    • Název: EM001 – POVOLENÍ V NOUZOVÉ SITUACI: Přerušení vícefaktorového ověřování[1/4] – Exchange SharePoint – Vyžadování připojení hybrid Azure AD Join
    • Uživatelé a skupiny: Zahrnout pohotovostní přístup. Vyloučení CoreAdmins a EmergencyAccess
    • Cloud Apps: Exchange Online a SharePoint Online
    • Podmínky: Všechny
    • Udělení řízení: Vyžadovat připojení k doméně
    • Stav: Pouze sestava
  • Zásada 2: Blokování jiných platforem než Windows
    • Název: EM002 – POVOLIT V PŘÍPADĚ NOUZE: Přerušení vícefaktorového ověřování[2/4] – Exchange SharePoint – Blokování přístupu kromě Windows
    • Uživatelé a skupiny: Zahrnout všechny uživatele. Vyloučení CoreAdmins a EmergencyAccess
    • Cloud Apps: Exchange Online a SharePoint Online
    • Podmínky: Device Platform Include All Platforms, exclude Windows
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze sestava
  • Zásada 3: Blokování jiných sítí než CorpNetwork
    • Název: EM003 – POVOLENÍ V PŘÍPADĚ NOUZE: Přerušení vícefaktorového ověřování[3/4] – Exchange SharePoint – Blokování přístupu kromě podnikové sítě
    • Uživatelé a skupiny: Zahrnout všechny uživatele. Vyloučení CoreAdmins a EmergencyAccess
    • Cloud Apps: Exchange Online a SharePoint Online
    • Podmínky: Umístění zahrnují libovolné umístění, vyloučení CorpNetwork
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze sestava
  • Zásada 4: Explicitní blokování EAS
    • Název: EM004 - ENABLE IN EMERGENCY: MFA Disruption[4/4] - Exchange - Block EAS for all users
    • Uživatelé a skupiny: Zahrnout všechny uživatele
    • Cloud Apps: Zahrnout Exchange Online
    • Podmínky: Klientské aplikace: Exchange Active Sync
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze sestava

Pořadí aktivace:

  1. Ze stávajících zásad vícefaktorového ověřování vylučte EmergencyAccess, CoreAdmins a EmergencyAccess. Ověřte, že uživatel v aplikaci ContingencyAccess má přístup k SharePointu Online a Exchange Online.
  2. Povolit zásadu 1: Ověřte, že uživatelé na zařízeních připojených k doméně, kteří nejsou ve skupinách vyloučení, mají přístup k Exchange Online a SharePointu Online. Ověřte, že uživatelé ve skupině Vyloučit mají přístup k SharePointu Online a Exchangi z libovolného zařízení.
  3. Povolit zásadu 2: Ověřte, že se uživatelé, kteří nejsou ve skupině vyloučení, nemůžou dostat do SharePointu Online a Exchange Online ze svých mobilních zařízení. Ověřte, že uživatelé ve skupině Vyloučení mají přístup k SharePointu a Exchangi z libovolného zařízení (Windows/iOS/Android).
  4. Povolit zásadu 3: Ověřte, že uživatelé, kteří nejsou ve skupinách vyloučení, nemají přístup k SharePointu a Exchangi z podnikové sítě, a to ani s počítačem připojeným k doméně. Ověřte, že uživatelé ve skupině Vyloučit mají přístup k SharePointu a Exchangi z jakékoli sítě.
  5. Povolit zásadu 4: Ověřte, že všichni uživatelé nemůžou získat Exchange Online z nativních poštovních aplikací na mobilních zařízeních.
  6. Zakažte existující zásady vícefaktorového ověřování pro SharePoint Online a Exchange Online.

V tomto dalším příkladu, Příklad B – Zásady podmíněného přístupu pro nepředvídané události, které umožňují mobilní přístup k Salesforce, se obnoví přístup obchodní aplikace. V tomto scénáři zákazník obvykle vyžaduje, aby přístup svých prodejních zaměstnanců k Salesforce (nakonfigurovaný pro jednotné přihlašování pomocí Azure AD) z mobilních zařízení byl povolený jenom ze vyhovujících zařízení. Přerušení v tomto případě spočívá v tom, že došlo k problému s vyhodnocením dodržování předpisů zařízením a k výpadku dochází v citlivé době, kdy prodejní tým potřebuje přístup k Salesforce, aby uzavřel obchody. Tyto zásady pro nepředvídané události udělují kritickým uživatelům přístup k Salesforce z mobilního zařízení, aby mohli dál zavírat obchody a nenarušovat podnikání. V tomto příkladu SalesforceContingency obsahuje všechny zaměstnance sales, kteří potřebují zachovat přístup, a SalesAdmins obsahuje nezbytné správce Salesforce.

Příklad B – Zásady podmíněného přístupu pro nepředvídané události:

  • Zásada 1: Blokovat všechny uživatele, kteří nejsou v týmu SalesContingency
    • Název: EM001 – ENABLE IN EMERGENCY: Device Compliance Disruption[1/2] - Salesforce - Block All users except SalesforceContingency
    • Uživatelé a skupiny: Zahrnout všechny uživatele. Vyloučení salesadmins a SalesforceContingency
    • Cloud Apps: Salesforce.
    • Podmínky: Žádné
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze sestava
  • Zásada 2: Blokování prodejního týmu z jakékoli jiné platformy než mobilní (kvůli omezení plochy útoku)
    • Název: EM002 – POVOLENÍ V NOUZOVÉ SITUACI: Přerušení dodržování předpisů zařízením[2/2] – Salesforce – Blokovat všechny platformy kromě iOS a Androidu
    • Uživatelé a skupiny: Zahrnout SalesforceContingency. Vyloučit správce prodeje
    • Cloud Apps: Salesforce
    • Podmínky: Device Platform Include All Platforms (Včetně všech platforem) s výjimkou iOS a Androidu
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze sestava

Pořadí aktivace:

  1. Vylučte SalesAdmins a SalesforceContingency ze stávajících zásad dodržování předpisů zařízením pro Salesforce. Ověřte, že uživatel ve skupině SalesforceContingency má přístup k Salesforce.
  2. Povolit zásadu 1: Ověřte, že uživatelé mimo SalesContingency nemají přístup k Salesforce. Ověřte, že uživatelé v salesadmins a SalesforceContingency mají přístup k Salesforce.
  3. Povolit zásadu 2: Ověřte, že uživatelé ve skupině SalesContingency nemají přístup k Salesforce ze svých přenosných počítačů s Windows nebo Mac, ale stále mají přístup ze svých mobilních zařízení. Ověřte, že SalesAdmin má stále přístup k Salesforce z libovolného zařízení.
  4. Zakažte stávající zásady dodržování předpisů zařízením pro Salesforce.

Předpoklady uzamčení uživatele z místních prostředků (rozšíření NPS)

Pokud chráníte přístup k síti VPN pomocí Azure AD rozšíření MFA NPS, zvažte federování řešení VPN jako aplikace SAML a určete kategorii aplikací, jak je doporučeno níže.

Pokud jste nasadili Azure AD rozšíření MFA NPS pro ochranu místních prostředků, jako je vpn a brána vzdálené plochy, pomocí vícefaktorového ověřování, měli byste zvážit, jestli jste v případě nouze připravení vícefaktorové ověřování zakázat.

V takovém případě můžete rozšíření NPS zakázat. V důsledku toho server NPS ověří pouze primární ověřování a nebude u uživatelů vynucovat vícefaktorové ověřování.

Zakázání rozšíření NPS:

  • Exportujte klíč registru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters jako zálohu.
  • Odstraňte hodnoty registru pro "AuthorizationDLLs" a "ExtensionDLLs", nikoli klíč Parameters.
  • Restartujte službu IAS (Network Policy Service), aby se změny projevily.
  • Zjistěte, jestli primární ověřování pro síť VPN proběhlo úspěšně.

Po obnovení služby a opětovném vynucení vícefaktorového ověřování u uživatelů povolte rozšíření NPS:

  • Import klíče registru ze zálohovací HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters
  • Restartujte službu IAS (Network Policy Service), aby se změny projevily.
  • Zjistěte, jestli je primární i sekundární ověřování sítě VPN úspěšné.
  • Zkontrolujte server NPS a protokol VPN a zjistěte, kteří uživatelé se během nouzového okna přihlásili.

Nasaďte synchronizaci hodnot hash hesel, i když jste federovaná nebo používáte předávací ověřování.

K uzamčení uživatele může dojít také v případě, že jsou splněné následující podmínky:

  • Vaše organizace používá řešení hybridní identity s předávacím ověřováním nebo federací.
  • Vaše místní systémy identit (například Active Directory, AD FS nebo závislá komponenta) nejsou k dispozici.

Aby byla vaše organizace odolnější, měla by povolit synchronizaci hodnot hash hesel, protože vám umožní přepnout na používání synchronizace hodnot hash hesel , pokud jsou místní systémy identit mimo provoz.

Microsoft doporučení

Povolte synchronizaci hodnot hash hesel pomocí průvodce Azure AD Connect bez ohledu na to, jestli vaše organizace používá federační nebo předávací ověřování.

Důležité

Aby bylo možné používat synchronizaci hodnot hash hesel, není nutné převádět uživatele z federovaného ověřování na spravované ověřování.

Během přerušení provozu

Pokud jste se rozhodli implementovat plán pro zmírnění rizik, budete moct automaticky přežít jedno přerušení řízení přístupu. Pokud jste se ale rozhodli vytvořit plán nepředvídaných událostí, budete moct aktivovat zásady nepředvídaných událostí během přerušení řízení přístupu:

  1. Povolte zásady nepředvídaných událostí, které udělí cílovým uživatelům přístup ke konkrétním aplikacím z konkrétních sítí.
  2. Zakažte běžné zásady založené na řízení.

Microsoft doporučení

V závislosti na tom, která omezení rizik nebo nepředvídané události se během přerušení použijí, může vaše organizace udělovat přístup jenom pomocí hesel. Žádná ochrana není značným bezpečnostním rizikem, které je třeba pečlivě zvážit. Organizace musí:

  1. V rámci strategie řízení změn zdokumentujte každou změnu a předchozí stav, abyste mohli vrátit změny, které jste implementovali, jakmile budou řízení přístupu plně funkční.
  2. Předpokládejme, že se aktéři se zlými úmysly pokusí získat hesla prostřednictvím útoků password spray nebo phishing, když zakážete vícefaktorové ověřování. Aktéři se zlými chybami už také můžou mít hesla, která dříve neudělila přístup k žádnému prostředku, o který se během tohoto okna můžete pokusit. V případě důležitých uživatelů, jako jsou vedoucí pracovníci, můžete toto riziko částečně zmírnit resetováním jejich hesel, než pro ně vícefaktorové ověřování zakážete.
  3. Archivujte všechny přihlašovací aktivity, abyste zjistili, kdo k čemu přistupuje během doby, kdy bylo vícefaktorové ověřování zakázané.
  4. Rozsadí všechny detekce rizik hlášené během tohoto časového období.

Po přerušení provozu

Po obnovení služby, která způsobila přerušení, vraťte změny, které jste provedli v rámci aktivovaného plánu nepředvídaných událostí.

  1. Povolení běžných zásad
  2. Zakažte zásady nepředvídaných událostí zpět do režimu jen pro sestavy.
  3. Vraťte zpět všechny ostatní změny, které jste během přerušení provedli a zdokumentovali.
  4. Pokud jste použili účet pro nouzový přístup, nezapomeňte znovu vygenerovat přihlašovací údaje a fyzicky zabezpečit podrobnosti o nových přihlašovacích údajích v rámci postupů účtu pro nouzový přístup.
  5. Pokračujte v třídění všech detekcí rizik nahlášených po přerušení pro podezřelé aktivity.
  6. Odvolá všechny obnovovací tokeny vydané pomocí PowerShellu pro cílení na sadu uživatelů. Odvolání všech obnovovacích tokenů je důležité pro privilegované účty používané během přerušení a jejich provedením se vynutí opětovné ověřování a splnění kontroly nad obnovenou zásadou.

Nouzové možnosti

V případě tísňové situace a vaše organizace dříve neimplementovala plán pro zmírnění rizik nebo nepředvídané události, postupujte podle doporučení v části Nepředvídané uzamčení uživatelů , pokud už k vynucení vícefaktorového ověřování používají zásady podmíněného přístupu. Pokud vaše organizace používá starší zásady vícefaktorového ověřování pro jednotlivé uživatele, můžete zvážit následující alternativu:

  • Pokud máte odchozí IP adresu podnikové sítě, můžete ji přidat jako důvěryhodné IP adresy a povolit ověřování jenom pro podnikovou síť.
  • Pokud nemáte inventář odchozích IP adres nebo pokud potřebujete povolit přístup uvnitř i mimo podnikovou síť, můžete celý adresní prostor IPv4 přidat jako důvěryhodné IP adresy zadáním adres 0.0.0.0/1 a 128.0.0.0/1.

Důležité

Pokud rozšíříte důvěryhodné IP adresy, aby se odblokoval přístup, nebudou se generovat detekce rizik spojených s IP adresami (například neuskutečené cesty nebo neznámá umístění).

Poznámka

Konfigurace důvěryhodných IP adres pro vícefaktorové ověřování Azure AD je dostupná jenom u licencí Azure AD Premium.

Další informace