Vytvoření odolné strategie správy řízení přístupu pomocí Microsoft Entra ID

  • Článek

Poznámka:

Informace obsažené v tomto dokumentu představují aktuální pohled společnosti Microsoft Corporation na otázky popsané k datu zveřejnění. Vzhledem k tomu, že Společnost Microsoft musí reagovat na měnící se tržní podmínky, neměla by být interpretována jako závazek na straně společnosti Microsoft a Společnost Microsoft nemůže zaručit přesnost jakýchkoli informací uvedených po datu zveřejnění.

Organizace, které spoléhají na jediné řízení přístupu, jako je vícefaktorové ověřování nebo jedno síťové umístění, k zabezpečení it systémů jsou náchylné k selháním přístupu k aplikacím a prostředkům, pokud se toto jednotné řízení přístupu stane nedostupným nebo chybně nakonfigurovaným. Přírodní katastrofa může například vést k nedostupnosti velkých segmentů telekomunikační infrastruktury nebo podnikových sítí. Takové přerušení může zabránit tomu, aby se koncoví uživatelé a správci mohli přihlásit.

Tento dokument obsahuje pokyny ke strategiím, které by organizace měla přijmout, aby zajistila odolnost, aby se snížilo riziko uzamčení během nepředvídatelných přerušení s využitím následujících scénářů:

  • Organizace můžou zvýšit odolnost, aby snížily riziko uzamčení před přerušením implementací strategií zmírnění rizik nebo plánů nepředvídaných událostí.
  • 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 tomu, že budou mít zavedené strategie zmírnění rizik a plány nepředvídaných událostí.
  • Organizace by se měly ujistit, že uchovávají informace, jako jsou protokoly, po přerušení a před vrácením jakýchkoliv nekonzistencí, které implementovali.
  • Organizace, které neimplementovaly strategie prevence nebo alternativní plány, můžou být schopny implementovat možnosti tísňového volání pro řešení výpadků.

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í pomocí podmíněného přístupu místo vícefaktorového ověřování pro jednotlivé uživatele.
  • Zmírnění uzamčení uživatele pomocí více ovládacích prvků podmíněného přístupu
  • Zmírnění uzamčení uživatele 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 hlavním cílem organizace při řešení problémů s řízením přístupu, ke kterým může dojít. Omezení zahrnuje plánování skutečné události a implementaci strategií, které zajistí, že během přerušení nebudou ovlivněné řízení přístupu a operace.

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 například řízení přístupu nebo požadavky na ověřování, získají přístup k aplikacím. Pokud některé požadavky na ověřování nebo řízení přístupu nejsou pro uživatele k dispozici kvůli nepředvídatelným okolnostem, můžou organizace zaznamenat jeden nebo oba následující problémy:

  • Správa istrator lockout: Správa istrátory 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é události uzamčení Správa istratoru

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 Microsoft Entra, pokud nejsou k dispozici normální postupy přístupu k privilegovaným účtům. Měly by se vytvořit alespoň dva účty pro nouzový přístup podle doporučení k účtu pro nouzový přístup.

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

Pokud chcete zmírnit riziko uzamčení uživatelů, použijte zásady podmíněného přístupu s více ovládacími prvky, které uživatelům umožňují zvolit, jak přistupují k aplikacím a prostředkům. Když například udělíte uživateli možnost mezi 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ě, pokud některý z ovládacích prvků přístupu není dostupný, 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 začleníte následující řízení přístupu:

  • Zřiďte pro každého uživatele více metod ověřování, které spoléhají na různé komunikační kanály, například aplikaci Microsoft Authenticator (internet), token OATH (vygenerovaný na zařízení) a SMS (telefonní).
  • Nasaďte Windows Hello pro firmy na zařízeních s Windows 10, abyste splnili požadavky vícefaktorového ověřování přímo z přihlášení zařízení.
  • Používejte důvěryhodná zařízení prostřednictvím hybridního připojení Microsoft Entra nebo Microsoft Intune. Důvěryhodná zařízení vylepšují uživatelské prostředí, protože samotné důvěryhodné zařízení může splňovat požadavky na silné ověřování zásad 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žívejte zásady založené na riziku microsoft Entra ID Protection, které brání přístupu, když je uživatel nebo přihlášení ohrožen místo pevných zásad vícefaktorového ověřování.
  • Pokud chráníte přístup k síti VPN pomocí rozšíření NPS s vícefaktorovým ověřováním Microsoft Entra, zvažte federaci řešení VPN jako aplikaci SAML a podle následujících doporučení určete kategorii aplikace.

Poznámka:

Zásady založené na rizicích vyžadují licence Microsoft Entra ID P2 .

Následující příklad popisuje zásady, které je nutné vytvořit, aby uživatelům poskytovalo odolné řízení přístupu pro přístup k aplikacím a prostředkům. V tomto příkladu potřebujete uživatele appu skupiny zabezpečení s cílovými uživateli, kterým chcete udělit přístup, skupinu s názvem Core Správa s 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 v 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í. Vyloučí účty tísňového volání a základní správce.

Sada zásad zmírnění podmíněného přístupu:

  • Zásada 1: Blokování přístupu k lidem mimo cílové skupiny
    • Uživatelé a skupiny: Zahrňte všechny uživatele. Vyloučení uživatelů aplikací, jader Správa a tísňového volání
    • Cloud Apps: Zahrnout všechny aplikace
    • Podmínky: (Žádné)
    • Udělení ovládacího prvku: Blok
  • Zásada 2: Udělení přístupu uživatelům AppUsers vyžadujícím vícefaktorové ověřování nebo důvěryhodné zařízení
    • Uživatelé a skupiny: Zahrnout uživatele appu. Vyloučení jader Správa a nouzového přístupu
    • Cloud Apps: Zahrnout všechny aplikace
    • Podmínky: (Žádné)
    • Udělení řízení: Udělení přístupu, vyžadování vícefaktorového ověřování, vyžadování zařízení, aby vyhovovalo předpisům. Pro více ovládacích prvků: Vyžaduje 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 nepředvídané zásady. Pokud chcete vytvořit nepředvídané zásady, musíte definovat kritéria kompromisu mezi provozní kontinuitou, provozními náklady, finančními náklady a riziky zabezpečení. Můžete například aktivovat nepředvídané zásady pouze pro podmnožinu uživatelů, pro podmnožinu aplikací, podmnožinu klientů nebo z podmnožinu umístění. Zásady nepředvídaných událostí poskytují 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 nepředvídaných událostí v režimu pouze sestav, pokud se nepoužívají, aby správci mohli monitorovat potenciální dopad zásad, pokud je potřeba zapnout.

Pochopení expozice během přerušení pomáhá snížit vaše riziko a je důležitou součástí procesu plánování. Pokud chcete vytvořit plán nepředvídaných událostí, nejprve určete následující obchodní požadavky vaší organizace:

  1. Předem určete své klíčové aplikace: K jakým aplikacím musíte udělit přístup, a to i s nižším rizikem nebo stavem zabezpečení? Vytvořte seznam těchto aplikací a ujistěte se, že ostatní účastníci (obchodní, bezpečnostní, právní, vedení) souhlasí, že pokud všechny řízení přístupu zmizí, musí tyto aplikace i nadále běžet. Pravděpodobně skončíte s kategoriemi:
    • Klíčové aplikace kategorie 1, které nemůžou 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 přístupná během několika hodin.
    • Kategorie 3 aplikace s nízkou prioritou, které mohou odolat přerušení několika dnů.
  2. U aplikací v kategorii 1 a 2 doporučuje Microsoft předem určit, jaký typ 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 k pracovnímu procesu informací a blokovat přístup správce, dokud se neobnoví řízení přístupu?
  3. Pro tyto aplikace Microsoft také doporučuje naplánovat, jaké cesty přístupu budete záměrně otevírat a které z nich zavřete:
    • Chcete povolit přístup jenom 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 blokovat externí uživatele?
    • 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 důležité aplikace, selhaly nebo uspěly, pokud není k dispozici alternativní řízení přístupu?

Doporučení Microsoftu

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

Důležité

Zakázání zásad, které u uživatelů vynucují zabezpečení, a to i dočasně, sníží stav zabezpečení v době, kdy je plán nepředvídaných událostí.

  • Pokud přerušení jednoho typu přihlašovacích údajů nebo jednoho mechanismu řízení přístupu ovlivňuje přístup k vašim aplikacím, nakonfigurujte sadu záložních zásad. Nakonfigurujte zásadu pouze ve stavu sestavy, která vyžaduje připojení k doméně jako ovládací prvek, jako zálohu aktivní zásady, která vyžaduje poskytovatele vícefaktorového ověřování třetí strany.
  • Snižte riziko hádání chybných herců, pokud není vícefaktorové ověřování povinné, a to pomocí postupů v dokumentu white paper s pokyny pro hesla.
  • Nasaďte samoobslužné resetování hesla Microsoft Entra (SSPR) a Ochranu heslem Microsoft Entra, abyste měli jistotu, že uživatelé nepoužívají běžné heslo a termíny, které se rozhodnete zakázat.
  • Použijte zásady, které omezují přístup v aplikacích, pokud se určitá úroveň ověřování nedosahuje, a nemusíte se jednoduše vrátit k úplnému přístupu. Příklad:
    • Nakonfigurujte zásadu zálohování, která odesílá deklarace identity relace s omezeným přístupem na 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 povolte přístup jen pro čtení, ale ne nahrá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á ukázat, je tato politika určena pouze pro mimořádné situace. Příklad: POVOLIT V NOUZOVÉM STAVU
    • Přerušení, na které se vztahuje. Příklad: Během přerušení vícefaktorového ověřování
    • Pořadové číslo , které zobrazí pořadí, ve které je nutné zásady aktivovat.
    • Aplikace, na které se vztahuje.
    • Ovládací prvky , které se použijí.
    • Podmínky, které vyžaduje.

Tento standard pojmenování pro nepředvídané zásady je následující:

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

Následující příklad: Příklad A – Nepředvídané zásady podmíněného přístupu pro obnovení přístupu k důležitým aplikacím pro spolupráci, je typická firemní nepředvídaná událost. V tomto scénáři organizace obvykle vyžaduje vícefaktorové ověřování pro veškerý přístup k Exchangi Online a SharePointu Online a přerušení v tomto případě je poskytovatelem vícefaktorového ověřování pro zákazníka (bez ohledu na to, jestli má vícefaktorové ověřování Microsoft Entra, místního poskytovatele MFA nebo vícefaktorové ověřování třetích stran). Tato zásada tento výpadek zmírní tím, že konkrétním cílovým uživatelům umožní 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 základní správci. Cíloví uživatelé pak získají přístup k Exchangi Online a SharePointu Online, zatímco ostatní uživatelé nebudou mít přístup k aplikacím kvůli výpadku. Tento příklad vyžaduje pojmenované síťové umístění CorpNetwork a skupinu zabezpečení EmergencyAccess s cílovými uživateli, skupinu s názvem Core Správa s s hlavními správci a skupinu s názvem EmergencyAccess s účty pro nouzový přístup. Nepředvídané události vyžadují, aby požadovanému přístupu poskytovaly čtyři zásady.

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

  • Zásada 1: Vyžadování zařízení připojených k doméně pro Exchange a SharePoint
    • Název: EM001 – POVOLIT V NOUZOVÉM VOLÁNÍ: Přerušení vícefaktorového ověřování[1/4] – Exchange SharePoint – Vyžadovat hybridní připojení Microsoft Entra
    • Uživatelé a skupiny: Zahrnout nepředvídané události. Vyloučení jader Správa a nouzového přístupu
    • Cloud Apps: Exchange Online a SharePoint Online
    • Podmínky: Všechny
    • Udělení ovládacího prvku: 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 NOUZOVÉM VOLÁNÍ: Přerušení vícefaktorového ověřování[2/4] – Exchange SharePoint – Blokovat přístup s výjimkou Windows
    • Uživatelé a skupiny: Zahrňte všechny uživatele. Vyloučení jader Správa a nouzového přístupu
    • Cloud Apps: Exchange Online a SharePoint Online
    • Podmínky: Device Platform Include All Platforms, exclude Windows
    • Udělení ovládacího prvku: Blok
    • Stav: Pouze sestava
  • Zásada 3: Blokování sítí jiných než CorpNetwork
    • Název: EM003 – POVOLIT V NOUZOVÉM VOLÁNÍ: Přerušení vícefaktorového ověřování[3/4] – Exchange SharePoint – Blokovat přístup s výjimkou podnikové sítě
    • Uživatelé a skupiny: Zahrňte všechny uživatele. Vyloučení jader Správa a nouzového přístupu
    • Cloud Apps: Exchange Online a SharePoint Online
    • Podmínky: Umístění zahrnují jakékoli umístění, vyloučit corpNetwork
    • Udělení ovládacího prvku: Blok
    • Stav: Pouze sestava
  • Zásada 4: Explicitní blokování EAS
    • Název: EM004 – POVOLIT V NOUZOVÉM VOLÁNÍ: Přerušení vícefaktorového ověřování[4/4] – Exchange – Blokování EAS pro všechny uživatele
    • Uživatelé a skupiny: Zahrnout všechny uživatele
    • Cloud Apps: Zahrnutí Exchange Online
    • Podmínky: Klientské aplikace: Exchange Active Sync
    • Udělení ovládacího prvku: Blok
    • Stav: Pouze sestava

Pořadí aktivace:

  1. Vyloučení nepředvídaných přístupů, jader Správa a nouzových přístupů ze stávajících zásad vícefaktorového ověřování Ověřte, že uživatel v Řešení nepředvídaných událostí má přístup k SharePointu Online a Exchangi 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 Exchangi Online a SharePointu Online. Ověřte, že uživatelé ve skupině Vyloučení mají přístup k SharePointu Online a Exchangi z libovolného zařízení.
  3. Povolit zásadu 2: Ověřte, že uživatelé, kteří nejsou ve skupině vyloučení, se z mobilních zařízení nemůžou dostat do SharePointu Online a Exchange Online. 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čení mají přístup k SharePointu a Exchangi z libovolné 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 stávající zásady MFA pro SharePoint Online a Exchange Online.

V tomto dalším příkladu je příklad B – nepředvídané zásady podmíněného přístupu, které umožní mobilní přístup k Salesforce, obnoví se přístup obchodní aplikace. V tomto scénáři zákazník obvykle vyžaduje přístup svých zaměstnanců prodeje k Salesforce (nakonfigurované pro jednotné přihlašování pomocí Microsoft Entra ID) z mobilních zařízení, aby je bylo možné povolit jenom ze vyhovujících zařízení. V tomto případě dochází 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 k uzavření obchodů. Tyto zásady nepředvídaných událostí poskytují kritickým uživatelům přístup k Salesforce z mobilního zařízení, aby mohli dál uzavřít obchody a nenarušovat podnikání. V tomto příkladu salesforceContingency obsahuje všechny zaměstnance prodeje, kteří potřebují zachovat přístup a prodej Správa obsahuje nezbytné správce Salesforce.

Příklad B – nepředvídané zásady podmíněného přístupu:

  • Zásada 1: Blokování všech uživatelů, kteří nejsou v 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 s výjimkou SalesforceContingency
    • Uživatelé a skupiny: Zahrňte všechny uživatele. Vyloučit prodeje Správa a SalesforceContingency
    • Cloudové aplikace: Salesforce.
    • Podmínky: Žádné
    • Udělení ovládacího prvku: Blok
    • Stav: Pouze sestava
  • Zásada 2: Zablokujte prodejnímu týmu jakoukoli jinou platformu než mobilní zařízení (aby se snížil prostor útoku).
    • Název: EM002 – POVOLIT V NOUZOVÉM REŽIMU: Přerušení dodržování předpisů zařízením[2/2] – Salesforce – Blokování všech platforem kromě iOS a Androidu
    • Uživatelé a skupiny: Zahrnují SalesforceContingency. Vyloučit prodeje Správa
    • Cloudové aplikace: Salesforce
    • Podmínky: Device Platform Include All Platforms, exclude iOS and Android
    • Udělení ovládacího prvku: Blok
    • Stav: Pouze sestava

Pořadí aktivace:

  1. Vylučte sales Správa s a SalesforceContingency ze stávajících zásad dodržování předpisů pro zařízení 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 sales Správa s 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 sales Správa 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ů pro zařízení pro Salesforce.

Omezení uzamčení uživatelů z místních prostředků (rozšíření NPS)

Pokud chráníte přístup k síti VPN pomocí rozšíření NPS s vícefaktorovým ověřováním Microsoft Entra, zvažte federaci řešení VPN jako aplikaci SAML a podle následujících doporučení určete kategorii aplikace.

Pokud jste nasadili rozšíření NPS s vícefaktorovým ověřováním Microsoft Entra pro ochranu místních prostředků, jako jsou VPN a Brána vzdálené plochy, pomocí vícefaktorového ověřování , měli byste zvážit předem, pokud jste připraveni vícefaktorové ověřování zakázat v případě tísňového volání.

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íč registruj HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters registry key as a backup.
  • Odstraňte hodnoty registru pro "AuthorizationDLLs" a "ExtensionDLLs", nikoli klíč Parameters.
  • Aby se změny projevily, restartujte službu Služby síťových zásad (IAS).
  • Zjistěte, jestli je primární ověřování pro síť VPN úspěšné.

Jakmile se služba obnoví a budete připraveni vynutit vícefaktorové ověřování u uživatelů znovu, povolte rozšíření NPS:

  • Import klíče registru ze záložního HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters
  • Aby se změny projevily, restartujte službu Služby síťových zásad (IAS).
  • Zjistěte, jestli je úspěšné primární ověřování a sekundární ověřování sítě VPN.
  • Zkontrolujte server NPS a protokol VPN a zjistěte, kteří uživatelé se přihlásili během tísňového volání.

Nasazení synchronizace 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ěny 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 umožňuje přepnout na synchronizaci hodnot hash hesel, pokud jsou vaše místní systémy identit mimo provoz.

Doporučení Microsoftu

Pomocí průvodce Microsoft Entra Připojení povolte synchronizaci hodnot hash hesel bez ohledu na to, jestli vaše organizace používá federaci nebo předávací ověřování.

Důležité

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

Během přerušení

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

  1. Povolte zásady nepředvídaných událostí, které umožňují 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í.

Doporučení Microsoftu

V závislosti na tom, která omezení rizik nebo nepředvídané události se používají během přerušení, může vaše organizace udělit 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 všechny změny a předchozí stav, abyste mohli vrátit zpět všechny nepředvídané události, 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 útoku password spray nebo phishing, zatímco jste zakázali vícefaktorové ověřování. Špatní aktéři už můžou mít hesla, která dříve neudělila přístup k žádnému prostředku, který se dá během tohoto okna pokusit. U kritických uživatelů, jako jsou vedoucí pracovníci, můžete toto riziko částečně zmírnit resetováním hesel před zakázáním vícefaktorového ověřování.
  3. Archivujte všechny přihlašovací aktivity, abyste zjistili, kdo během doby, kdy bylo vícefaktorové ověřování zakázané.
  4. Třídění všech detekcí rizik hlášených během tohoto okna

Po přerušení

Vrácení změn, které jste provedli v rámci aktivovaného náhradního plánu po obnovení služby, které způsobily přerušení.

  1. Povolení běžných zásad
  2. Zakažte své nepředvídané zásady zpět do režimu jen pro sestavy.
  3. Vraťte všechny ostatní změny, které jste provedli a zdokumentovali 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 jako součást postupů účtu pro nouzový přístup.
  5. Pokračujte ve třídění všech detekcí rizik hlášených po přerušení podezřelé aktivity.
  6. Odvolá všechny obnovovací tokeny vydané 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 tím je vynutí opětovné ověření a splnění kontroly obnovených zásad.

Možnosti tísňového volání

V nouzovém stavu a vaše organizace dříve neimplementovala plán zmírnění rizik nebo nepředvídaných událostí, postupujte podle doporučení v části Nedodržování 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 je přidat jako důvěryhodné IP adresy a povolit ověřování jenom do podnikové sítě.
  • Pokud nemáte inventář odchozích IP adres nebo potřebujete povolit přístup uvnitř a mimo podnikovou síť, můžete celý adresní prostor IPv4 přidat jako důvěryhodné IP adresy zadáním 0.0.0.0/1 a 128.0.0.0.0/1.

Důležité

Pokud rozšíříte důvěryhodné IP adresy tak, aby odblokovaly přístup, nebudou generovány detekce rizik spojené s IP adresami (například neuskutečněná cesta nebo neznámé umístění).

Poznámka:

Konfigurace důvěryhodných IP adres pro vícefaktorové ověřování Microsoft Entra je k dispozici pouze s licencemi Microsoft Entra ID P1 nebo P2.

Další informace