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ěl by být interpretován jako závazek společnosti Microsoft a společnost Microsoft nemůže zaručit přesnost všech informací, které jsou uvedeny po datu publikování.

Organizace, které spoléhají na jeden ovládací prvek přístupu, jako je Multi-Factor Authentication (MFA) nebo jediné síťové umístění, jsou pro zabezpečení svých systémů IT náchylné k selhání přístupu k aplikacím a prostředkům, pokud dojde k nedostupnosti nebo chybně nakonfigurovanému řízení přístupu. Přírodní havárie může například způsobit nedostupnost velkých segmentů telekomunikačních infrastruktur nebo podnikových sítí. Takové přerušení by mohlo zabránit tomu, aby se koncoví uživatelé a správci mohli přihlásit.

Tento dokument obsahuje pokyny k strategiím, které by organizace měla přijmout pro zajištění odolnosti proti riziku uzamčení během nepředvídatelného narušení, a to v následujících případech:

  1. Organizace mohou zvýšit jejich odolnost a snížit tak riziko uzamčení před přerušením implementací strategií zmírnění nebo pohotovostních plánů.
  2. Organizace můžou dál přistupovat k aplikacím a prostředkům, které si vyberou během přerušení , tím, že budou mít strategie zmírnění a pohotovostní plány na místě.
  3. Organizace by se měli ujistit, že uchovávají informace, jako jsou protokoly, po přerušení a předtím, než vrátí případné nepotřebné okolnosti.
  4. Organizace, které neimplementovaly strategie prevence nebo alternativní plány, můžou implementovat nouzové možnosti , které se zabývají přerušením.

Klíčové pokyny

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

  • Vyhněte se uzamknutí správce pomocí účtů pro nouzový přístup.
  • Implementujte MFA pomocí podmíněného přístupu, spíše než MFA pro uživatele.
  • Zmírnění uzamčení uživatelů pomocí více ovládacích prvků podmíněného přístupu.
  • Omezení uzamčení uživatelů tím, že zřizujete více metod ověřování nebo ekvivalenty pro každého uživatele.

Před přerušením

Zmírnění skutečného přerušení musí být hlavním cílem organizace při řešení problémů s řízením přístupu, ke kterým může dojít. Omezení rizik zahrnuje plánování skutečné události a implementaci strategií, aby se zajistilo, že řízení přístupu a operace nebudou při přerušení ovlivněny.

Proč potřebujete odolnější ří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, například řízení přístupu nebo požadavky na ověřování, uživatelé získají přístup k aplikacím. V případě, že jeden nebo více požadavků na ověření nebo řízení přístupu není k dispozici pro uživatele, kteří se budou moci ověřit z důvodu neočekávaných okolností, mohou organizace zaznamenat jeden nebo oba následující problémy:

  • 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 nebo prostředkům.

Záhotovost uzamčení správce

Chcete-li 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 pro objednání, umožňují přístup ke správě konfigurace služby Azure AD, když nejsou k dispozici normální přístupové procedury privilegovaného účtu. Po doporučeních pro účet pro nouzový přístupby se měly vytvořit aspoň dva účty pro nouzový přístup.

Zmírnění uzamčení uživatele

Pokud chcete zmírnit riziko uzamknutí 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 způsob, jakým budou mít přístup k aplikacím a prostředkům. Když uživateli vyberete možnost volby, například přihlašování pomocí MFA nebo přihlášení ze spravovaného zařízení nebo přihlášení z podnikové sítě, pokud je jedna z ovládacích prvků přístupu nedostupná, má uživatel další možnosti, jak pokračovat v práci.

Doporučení Microsoftu

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

  1. zřizování více metod ověřování pro každého uživatele, který spoléhá na různé komunikační kanály, například na aplikaci Microsoft Authenticator (internet), token OATH (generovaný na zařízení) a SMS (telephonic). Následující skript prostředí PowerShell vám pomůže určit předem, které další metody by měly uživatelé zaregistrovat: skript pro analýzu metody ověřování Azure AD MFA.
  2. nasaďte Windows Hello pro firmy na Windows 10 zařízeních, abyste mohli požadavky na MFA naplnit přímo z přihlašování zařízení.
  3. použijte důvěryhodná zařízení přes hybridní připojení Azure AD nebo Microsoft Intune spravovaná zařízení. Důvěryhodná zařízení vylepšit uživatelské prostředí, protože vlastní důvěryhodné zařízení může splnit požadavky zásad silného ověřování, aniž by museli uživateli vyvolávat výzvu MFA. Vícefaktorové ověřování 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í.
  4. Využijte zásady založené na riziku služby Azure AD Identity Protection, které zabraňují v přístupu, když se uživatel nebo přihlašování nejedná o riziko pevně stanovených zásad MFA.
  5. Pokud chráníte přístup k síti VPN pomocí rozšíření Azure AD MFA NPS, zvažte federování řešení VPN jako aplikaci SAML a určete kategorii aplikace podle doporučení níže.

Poznámka

zásady založené na rizikech vyžadují Azure AD Premium P2 licencí.

Následující příklad popisuje zásady, které je třeba vytvořit, aby pro uživatele poskytovaly odolné řízení přístupu pro přístup k jejich aplikacím a prostředkům. V tomto příkladu budete potřebovat skupinu zabezpečení AppUsers s cílovými uživateli, kterým chcete udělit přístup, skupině s názvem CoreAdmins s hlavními správci a skupiny s názvem EmergencyAccess s účty pro nouzový přístup. Tato ukázková sada zásad uděluje vybraným uživatelům v AppUsers, přístup k vybraným aplikacím, pokud se připojují z důvěryhodného zařízení nebo poskytuje silné ověřování, například MFA. Vyloučí účty v nouzi a základní správce.

Sada zásad pro zmírnění rizik CA:

  • Zásady 1: blokování přístupu lidem mimo cílové skupiny
    • Uživatelé a skupiny: včetně všech uživatelů. Vyloučení AppUsers, CoreAdmins a EmergencyAccess
    • Cloudové aplikace: zahrnout všechny aplikace
    • Podmínky: (žádné)
    • Udělení řízení: blok
  • Zásada 2: Udělte přístup k AppUsers vyžadujícímu MFA nebo důvěryhodnému zařízení.
    • Uživatelé a skupiny: zahrnují AppUsers. Vyloučit CoreAdmins a EmergencyAccess
    • Cloudové aplikace: zahrnout všechny aplikace
    • Podmínky: (žádné)
    • Udělit řízení: udělit přístup, vyžadovat službu Multi-Factor Authentication, vyžadovat, aby zařízení splňovalo předpisy. Pro více ovládacích prvků: vyžadovat jeden z vybraných ovládacích prvků.

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

Případně může vaše organizace také vytvářet pohotovostní zásady. Pokud chcete vytvořit pohotovostní zásady, musíte definovat kritéria kompromisů mezi provozní kontinuitou, provozními náklady, finančními náklady a bezpečnostními riziky. Můžete například aktivovat pohotovostní zásadu pouze pro podmnožinu uživatelů, pro podmnožinu aplikací, pro podmnožinu klientů nebo z podmnožiny umístění. Pohotovostní zásady 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í. Microsoft doporučuje povolit pohotovostní zásady v režimu jenom pro sestavy , pokud se nepoužívá, takže správci můžou monitorovat potenciální dopad zásad, aby je bylo potřeba zapnout.

Porozumění vaší expozici během přerušení pomáhá snížit vaše riziko a je zásadní součástí procesu plánování. Pokud chcete vytvořit svůj pohotovostní plán, nejdřív určete následující obchodní požadavky vaší organizace:

  1. Určete nejdůležitější aplikace předem: Jaké jsou aplikace, pro které musíte poskytnout přístup, a to i s nižším rizikem a stav zabezpečení? Sestavte seznam těchto aplikací a zajistěte, aby ostatní účastníci (podnikání, zabezpečení, právní, vedoucí) souhlasili s tím, že pokud všechny řízení přístupu vzroste, musí tyto aplikace nadále běžet. Pravděpodobně budete končit kategoriemi:
    • Kategorie 1 má důležité aplikace , které nemůžou být dostupné déle než několik minut, například aplikace, které přímo ovlivňují tržby organizace.
    • Kategorie 2: důležité aplikace , ke kterým musí být podnik přístupný během pár hodin.
    • Kategorie 3 aplikace s nízkou prioritou , které můžou vydržet přerušení několika dní.
  2. Pro aplikace v kategorii 1 a 2 Společnost Microsoft doporučuje předem naplánovat, jaký typ úrovně přístupu chcete udělit:
    • Chcete povolit úplný přístup nebo jenom omezenou relaci, jako je třeba omezit stahování?
    • Chcete povolit přístup k části aplikace, ale ne k celé aplikaci?
    • Chcete povolit přístup k informačnímu pracovníkovi a zablokovat přístup správce, dokud se neobnoví řízení přístupu?
  3. Pro tyto aplikace Microsoft také doporučuje plánování, které cesty vedoucí přístupu záměrně otevřete a které budete uzavřít:
    • Chcete povolit, aby prohlížeč měl přístup jenom k blokovaným klientům, kteří můžou ukládat offline data?
    • Chcete povolit přístup jenom uživatelům v podnikové síti a zablokovat si ho i externí uživatelé?
    • Chcete povolit přístup z určitých zemí nebo oblastí pouze během přerušení?
    • Chcete zásady pro pohotovostní zásady, zejména pro kritické aplikace, neúspěšné nebo úspěšné, pokud není k dispozici alternativní řízení přístupu?

Doporučení Microsoftu

Pohotovostní zásada podmíněného přístupu je zásada zálohování , která vynechává Azure AD MFA, vícefaktorové ověřování od jiných výrobců nebo řízení na základě zařízení. Aby se minimalizovalo neočekávané přerušení v případě, že je povolená zásada pro nepředvídané účely, zásada by měla zůstat v režimu pouze pro sestavy, pokud se nepoužívá. správci mohou monitorovat potenciální dopad na své pohotovostní zásady pomocí Přehledy sešitu podmíněného přístupu. Pokud se vaše organizace rozhodne aktivovat svůj pohotovostní plán, správci můžou zásadu Povolit a zakázat běžné zásady založené na řízení.

Důležité

Zakázáním zásad, které vynutily zabezpečení pro vaše uživatele, dojde k omezení stav zabezpečení i v případě, že je plán pohotovostní.

  • Nakonfigurujte sadu záložních zásad, pokud dojde k výpadku jednoho typu přihlašovacích údajů nebo jednoho mechanismu řízení přístupu, který má vliv na přístup k vašim aplikacím. Nakonfigurujte zásady ve stavu pouze sestavy, který vyžaduje připojení k doméně jako řízení, jako zálohu aktivní zásady, která vyžaduje poskytovatele vícefaktorového ověřování od jiného výrobce.
  • Pomocí postupů uvedených v dokumentu White Paper s pokyny k heslům snížíte riziko chybných aktérů, které se týkají pokusů o hesla.
  • Nasaďte Azure ad Self-Service resetování hesla (SSPR) a ochranu heslem Azure AD , abyste se ujistili, že uživatelé nepoužívají běžné heslo a výrazy, které se rozhodnete zakázat.
  • Použijte zásady, které omezují přístup v rámci aplikací, pokud se určitá úroveň ověřování nenasáhne, ale jednoduše se vrátíte k úplnému přístupu. Příklad:
    • Nakonfigurujte zásadu zálohování, která odesílá deklaraci identity omezené relace Exchange a SharePoint.
    • Pokud vaše organizace používá Microsoft Defender for Cloud Apps, zvažte návrat k zásadám, které zapojují Defender for Cloud Apps a pak povolují přístup jen pro čtení, ale ne nahrávání.
  • Pojmete zásady, abyste se ujistili, že je během přerušení snadno najdete. Do názvu zásady zahršete následující prvky:
    • Číslo popisku pro zásadu.
    • Text, který se má zobrazit, tato zásada se týká pouze nouzových situací. Příklad: POVOLENÍ V NOUZOVÉM STAVU
    • Přerušení, na které se vztahuje. Příklad: Během přerušení více ověřování
    • Sekvenční číslo pro zobrazení pořadí, ve které je nutné 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 pro nepředvídané události bude následující:

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

Následující příklad: Příklad A – Zásadypodmíněného přístupu pro nepředvídané události pro obnovení přístupu k důležitým aplikacím pro spolupráci je obvyklou firemní nepředvídané události. V tomto scénáři organizace obvykle vyžaduje MFA pro všechny přístupy Exchange Online a SharePoint Online a přerušení v tomto případě je poskytovatelem MFA zákazníka, u něj dojde k výpadku (Ať už je to Azure AD MFA, místní poskytovatel MFA nebo MFA třetí strany). Tato zásada tento výpadk zmírňuje tím, že konkrétním cílovým uživatelům umožňuje přístup k těmto aplikacím z důvěryhodných zařízení Windows jenom v případě, že k aplikaci přistupují ze své důvěryhodné podnikové sítě. Z těchto omezení také vyloučí nouzové účty a základní správce. Cílí uživatelé pak získají přístup k Exchange Online a SharePoint Online, zatímco ostatní uživatelé nebudou mít kvůli výpadku přístup k aplikacím. Tento příklad bude vyžadovat pojmenované síťové umístění CorpNetwork a skupinu zabezpečení ContingencyAccess s cílovými uživateli, skupinu CoreAdmins se základní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žadují nepředvídané události čtyři zásady.

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

  • Zásady 1: Vyžadování zařízení připojených k doméně Exchange a SharePoint
    • Název: EM001 – POVOLENÍ V PŘÍPADĚ NOUZE: Přerušení více ověřování [1/4] – Exchange SharePoint – Vyžadovat připojení k hybridní službě Azure AD
    • Uživatelé a skupiny: Zahrnout ContingencyAccess. Vyloučení coreadmins a EmergencyAccess
    • Cloudové aplikace: Exchange Online a SharePoint Online
    • Podmínky: Všechny
    • Udělení řízení: Vyžadovat připojení k doméně
    • Stav: Pouze pro sestavy
  • Zásady 2: Blokování jiných platforem než Windows
    • Název: EM002 – POVOLIT V PŘÍPADĚ NOUZE: Přerušení více ověřování [2/4] – Exchange SharePoint – Blokovat přístup s výjimkou Windows
    • Uživatelé a skupiny: Zahrnuje všechny uživatele. Vyloučení coreadmins a EmergencyAccess
    • Cloudové aplikace: Exchange Online a SharePoint Online
    • Podmínky: Platforma zařízení zahrnuje všechny platformy, vyloučí Windows
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze pro sestavy
  • Zásady 3: Blokování jiných sítí než CorpNetwork
    • Název: EM003 – POVOLIT V PŘÍPADĚ NOUZE: Přerušení více ověřování [3/4] – Exchange SharePoint – Blokovat přístup s výjimkou podnikové sítě
    • Uživatelé a skupiny: Zahrnuje všechny uživatele. Vyloučení coreadmins a EmergencyAccess
    • Cloudové aplikace: Exchange Online a SharePoint Online
    • Podmínky: Umístění: Sem patří libovolné umístění, vylučte CorpNetwork.
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze pro sestavy
  • Zásady 4: Explicitní blokování EAS
    • Název: EM004 – POVOLENÍ V PŘÍPADĚ NOUZE: Přerušení více ověřování [4/4] – Exchange – Blokovat EAS pro všechny uživatele
    • Uživatelé a skupiny: Zahrnout všechny uživatele
    • Cloudové aplikace: Zahrnout Exchange Online
    • Podmínky: Klientské aplikace: Exchange Aktivní synchronizace
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze pro sestavy

Pořadí aktivace:

  1. Vylučte ContingencyAccess, CoreAdmins a EmergencyAccess ze stávajících zásad MFA. Ověřte, že uživatel v ContingencyAccess má přístup SharePoint 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 pro vyloučení, mají přístup k Exchange Online a SharePoint Online. Ověřte, že uživatelé ve skupině Vyloučit mají přístup SharePoint Online a Exchange z libovolného zařízení.
  3. Povolit zásadu 2: Ověřte, že uživatelé, kteří nejsou ve skupině pro vyloučení, se SharePoint online a Exchange Online ze svých mobilních zařízení. Ověřte, že uživatelé ve skupině Vyloučit mají přístup SharePoint a Exchange z libovolného zařízení (Windows/iOS/Android).
  4. Povolit zásady 3: Ověřte, že uživatelé, kteří nejsou ve skupinách pro vyloučení, nemají přístup k SharePoint a Exchange z podnikové sítě, a to ani pomocí počítače připojeného k doméně. Ověřte, že uživatelé ve skupině Vyloučit mají přístup SharePoint a Exchange z jakékoli sítě.
  5. Povolit zásady 4: Ověřte, že všichni uživatelé Exchange Online z nativních poštovních aplikací na mobilních zařízeních.
  6. Zakažte existující zásady MFA 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é povolí mobilní přístup k Salesforce,se obnoví přístup obchodní aplikace. V tomto scénáři zákazník obvykle vyžaduje, aby zaměstnanci prodeje přistupovaly k Salesforce (nakonfigurované pro jednotné přihlašování pomocí Azure AD) z mobilních zařízení, aby byla povolena pouze ze vyhovujících zařízení. V tomto případě 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 bylo možné uzavřít obchody. Tyto zásady pro nepředvídané události udělují důležitým uživatelům přístup k Salesforce z mobilního zařízení, aby mohli pokračovat v zavírání obchodů a nenarušovat podnikání. V tomto příkladu salesforceContingency obsahuje všechny zaměstnance prodeje, 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: Blokování všech členů týmu SalesContingency
    • Název: EM001 – POVOLIT V NOUZOVÉM STAVU: Přerušení dodržování předpisů zařízením[1/2] – Salesforce – Blokovat všechny uživatele kromě SalesforceContingency
    • Uživatelé a skupiny: Zahrnuje všechny uživatele. Vyloučení SalesAdmins a SalesforceContingency
    • Cloudové aplikace: Salesforce.
    • Podmínky: Žádné
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze pro sestavy
  • Zásady 2: Zablokujte prodejní tým od jakékoli jiné platformy než mobilní platformy (aby se snížil prostor pro útok).
    • Název: EM002 – POVOLIT V NOUZOVÉM PŘÍPADĚ: 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čení salesAdmins
    • Cloudové aplikace: Salesforce
    • Podmínky: Platforma zařízení zahrnuje všechny platformy, vyloučí iOS a Android.
    • Udělení ovládacího prvku: Blokovat
    • Stav: Pouze pro sestavy

Pořadí aktivace:

  1. Vylučte ze stávajících zásad dodržování předpisů zařízení pro Salesforce salesadmins a SalesforceContingency. 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 nemohou získat 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 nemohou přistupovat k Salesforce ze svých 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 existující zásady dodržování předpisů pro zařízení pro Salesforce.

Předpoklady pro uzamčení uživatele z prostředků v okolí (rozšíření NPS)

Pokud chráníte přístup k síti VPN pomocí rozšíření AZURE AD MFA NPS, zvažte federaci řešení VPN jako aplikace SAML a podle doporučení níže určete kategorii aplikace.

Pokud jste nasadili rozšíření AZURE AD MFA NPS pro ochranu aktivně dostupných prostředků, jako jsou sítě VPN a Brána vzdálené plochy, pomocí MFA, měli byste zvážit dopředu, pokud jste připraveni V případě nouze zakázat více ověřování.

V takovém případě můžete rozšíření NPS zakázat, protože server NPS ověří pouze primární ověřování a nebude u uživatelů vynucovat MFA.

Zakázat rozšíření serveru NPS:

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

Jakmile se služba obnoví a jste připraveni znovu vymáhat MFA pro uživatele, povolte rozšíření serveru NPS:

  • Importujte klíč registru ze zálohy HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters
  • Restartujte službu NPS (Network Policy Service), aby se změny projevily.
  • Určete, zda je primární ověřování a také sekundární ověřování pro síť VPN úspěšné.
  • Zkontrolujte servery NPS a protokol VPN a určete, kteří uživatelé se přihlásili během nouzového okna.

Nasadit synchronizaci hodnot hash hesel i v případě, že 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 federaci.
  • Vaše místní systémy identit (například služba Active Directory, AD FS nebo závislá součást) nejsou k dispozici.

Aby byla vaše organizace pružnější, měla by Povolit synchronizaci hodnot hash hesel, protože umožňuje Přepnout na použití synchronizace hodnot hash hesel v případě, že vaše místní systémy identity nejsou funkční.

Doporučení Microsoftu

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

Důležité

Pro použití synchronizace hodnot hash hesel není nutné převádět uživatele ze federovaného na spravované ověřování.

Při přerušení

Pokud jste se rozhodli pro implementaci plánu zmírnění rizik, budete moct automaticky přerušit jednotlivé přerušení řízení přístupu. Pokud jste se ale rozhodli vytvořit plán pro nepředvídané řešení, budete moci aktivovat své pohotovostní zásady během přerušení řízení přístupu:

  1. Povolte své pohotovostní zásady, které udělí cílovým uživatelům přístup ke konkrétním aplikacím z konkrétních sítí.
  2. Zakážete své běžné zásady založené na ovládacím prvku.

Doporučení Microsoftu

V závislosti na tom, jaké zmírnění nebo nečinnosti se při přerušení používají, může vaše organizace udělit přístup jenom s heslem. Žá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 zpět všechny nedokončené okolnosti, jakmile jsou ovládací prvky přístupu plně funkční.
  2. Předpokládá se, že se zlomyslné aktéry pokusí o vybírání hesel prostřednictvím útoků pomocí postřiku hesel nebo útoků phishing při zakázání MFA Chybné objekty actor mohou již mít hesla, která dříve neudělila přístup k jakémukoli prostředku, který lze během tohoto okna provést. U kritických uživatelů, jako jsou například vedoucí pracovníci, můžete toto riziko částečně zmírnit tím, že si resetujete jejich hesla, než je pro ně zakážete MFA.
  3. Archivujte veškerou přihlašovací aktivitu a určete, kdo má přístup k čemu v době zakázání MFA.
  4. Třídění všech zjištění rizik hlášených v rámci tohoto okna.

Po přerušení

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

  1. Povolit běžné zásady
  2. Deaktivujte své pohotovostní zásady zpátky do režimu pouze pro sestavy.
  3. Vraťte všechny další změny, které jste provedli a popsali během přerušení.
  4. Pokud jste použili účet pro nouzový přístup, nezapomeňte znovu vygenerovat přihlašovací údaje a fyzicky zabezpečit nové přihlašovací údaje v rámci postupů vašeho účtu pro nouzový přístup.
  5. Pokračujte v třídění všech zjištění rizik hlášených po přerušení podezřelé aktivity.
  6. Odvolat všechny obnovovací tokeny, které byly vydány pomocí prostředí PowerShell pro cílení na skupinu uživatelů. Odvolání všech aktualizačních tokenů je důležité pro privilegované účty používané při přerušení a v důsledku toho vynutí opětovné ověření a splnění kontroly nad obnovenými zásadami.

Nouzové možnosti

V případě nouze a vaše organizace předtím neimplementovala plán zmírňování nebo řešení nepředvídaných událostí, pokud už používají zásady podmíněného přístupu k vymáhání MFA, postupujte podle doporučení v části neškodné volání uživatele . Pokud vaše organizace používá starší zásady vícefaktorového ověřování pro uživatele, můžete zvážit následující alternativy:

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

Důležité

Pokud rozpoznáváte důvěryhodné IP adresy na přístup odblokování, negenerují se detekce rizik přidružená k IP adresám (například nemožná cesta nebo neznámá umístění).

Poznámka

konfigurace důvěryhodných ip adres pro Azure AD MFA je dostupná jenom u licencí Azure AD Premium.

Další informace