Sdílet prostřednictvím

Referenční příručka k operacím správy ověřování Microsoft Entra

  • Článek

Tato část referenční příručky k operacím Microsoft Entra popisuje kontroly a akce, které byste měli provést při zabezpečení a správě přihlašovacích údajů, definování prostředí ověřování (AuthN), delegování přiřazení, měření využití a definování zásad přístupu na základě stavu zabezpečení podniku.

Poznámka:

Tato doporučení jsou aktuální k datu publikování, ale můžou se v průběhu času měnit. Organizace by měly průběžně vyhodnocovat své postupy identit při vývoji produktů a služeb Microsoftu v průběhu času.

Klíčové provozní procesy

Přiřazení vlastníků k klíčovým úkolům

Správa MICROSOFT Entra ID vyžaduje průběžné provádění klíčových provozních úkolů a procesů, které nemusí být součástí projektu uvedení. Je stále důležité nastavit tyto úlohy tak, aby optimalizovaly vaše prostředí. Mezi klíčové úkoly a jejich doporučené vlastníky patří:

Úkol Vlastník
Správa životního cyklu konfigurace jednotného přihlašování (SSO) v Microsoft Entra ID Provozní tým pro správu identit a přístupu (IAM)
Návrh zásad podmíněného přístupu pro aplikace Microsoft Entra Tým architektury InfoSec
Archivace přihlašovací aktivity v systému SIEM (Security Information and Event Management) Provozní tým InfoSec
Archivace rizikových událostí v systému SIEM Provozní tým InfoSec
Třídění a zkoumání sestav zabezpečení Provozní tým InfoSec
Třídění a zkoumání rizikových událostí Provozní tým InfoSec
Třídění a prošetřování uživatelů označených příznakem rizika a sestav ohrožení zabezpečení ze služby Microsoft Entra ID Protection Provozní tým InfoSec

Poznámka:

Microsoft Entra ID Protection vyžaduje licenci Microsoft Entra ID P2. Pokud chcete najít správnou licenci pro vaše požadavky, přečtěte si téma Porovnání obecně dostupných funkcí edice Microsoft Entra ID Free a Microsoft Entra ID P1 nebo P2.

Při kontrole seznamu možná budete muset přiřadit vlastníka k úkolům, které chybí vlastník, nebo upravit vlastnictví úkolů s vlastníky, kteří nejsou v souladu s výše uvedenými doporučeními.

Správa přihlašovacích údajů

Zásady hesel

Bezpečná správa hesel je jednou z nejdůležitějších částí správy identit a přístupu a často největšího cíle útoků. Microsoft Entra ID podporuje několik funkcí, které můžou pomoct zabránit úspěšnému útoku.

V následující tabulce najdete doporučené řešení pro zmírnění problému, který je potřeba vyřešit:

Problém Doporučení
Žádný mechanismus ochrany před slabými hesly Povolení samoobslužného resetování hesla Microsoft Entra ID (SSPR) a ochrany heslem
Žádný mechanismus pro detekci nevracených hesel Povolení synchronizace hodnot hash hesel (PHS) pro získání přehledů
Použití služby AD FS a nemožnost přejít na spravované ověřování Povolení inteligentního uzamčení extranetu služby AD FS nebo microsoft Entra Smart Lockout
Zásady hesel používají pravidla založená na složitosti, jako je délka, více znakových sad nebo vypršení platnosti. Znovu zvažte přednost doporučeným postupům společnosti Microsoft a přepněte svůj přístup ke správě hesel a nasaďte ochranu heslem Microsoft Entra.
Uživatelé nejsou zaregistrovaní k používání vícefaktorového ověřování Zaregistrujte všechny bezpečnostní údaje uživatele, aby je bylo možné použít jako mechanismus k ověření identity uživatele spolu s heslem.
Na základě rizika uživatele neexistuje žádné odvolání hesel. Nasazení zásad rizik uživatelů služby Microsoft Entra ID Protection k vynucení změn hesel při úniku přihlašovacích údajů pomocí SSPR
Neexistuje žádný mechanismus inteligentního uzamčení pro ochranu škodlivého ověřování před chybnými aktéry pocházejícími z identifikovaných IP adres. Nasazení cloudového ověřování se synchronizací hodnot hash hesel nebo předávacím ověřováním (PTA)

Povolení samoobslužného resetování hesla a ochrany heslem

Uživatelé, kteří potřebují změnit nebo resetovat svá hesla, je jedním z největších zdrojů objemu a nákladů na hovory helpdesku. Kromě nákladů představuje změna hesla jako nástroje pro zmírnění rizika uživatelů zásadní krok při vylepšování stavu zabezpečení ve vaší organizaci.

Minimálně se doporučuje nasadit samoobslužné resetování hesla Microsoft Entra ID (SSPR) a místní ochranu heslem, abyste dosáhli:

  • Odklánět volání helpdesku.
  • Nahraďte používání dočasných hesel.
  • Nahraďte všechna existující samoobslužná řešení pro správu hesel, která závisí na místním řešení.
  • Eliminujte slabá hesla ve vaší organizaci.

Poznámka:

Pro organizace s licencemi Microsoft Entra ID P2 se doporučuje nasadit SSPR a používat ho jako součást zásad podmíněného přístupu založeného na microsoft Entra ID Protection.

Silná správa přihlašovacích údajů

Hesla sama o sobě nejsou dostatečná, aby zabránila škodlivým subjektům v získání přístupu k vašemu prostředí. Pro vícefaktorové ověřování musí být povolený alespoň každý uživatel s privilegovaným účtem. V ideálním případě byste měli povolit kombinovanou registraci a vyžadovat, aby se všichni uživatelé zaregistrovali pro vícefaktorové ověřování a samoobslužné resetování hesla pomocí kombinovaného prostředí registrace. Nakonec doporučujeme přijmout strategii pro zajištění odolnosti , abyste snížili riziko uzamčení z důvodu nepředvídatelných okolností.

Kombinovaný tok uživatelského prostředí

Odolnost ověřování místního výpadku

Kromě výhod jednoduchosti a povolení detekce nevracených přihlašovacích údajů umožňuje Microsoft Entra Password Hash Sync (PHS) a Vícefaktorové ověřování Microsoft Entra umožnit uživatelům přístup k aplikacím software jako služby (SaaS) a Microsoftu 365 i přes místní výpadky kvůli kybernetickým útokům, jako je NotPetya. Je také možné povolit phS ve spojení s federací. Povolení služby PHS umožňuje náhradní ověřování, pokud federační služby nejsou k dispozici.

Pokud vaše místní organizace nemá strategii odolnosti proti výpadku nebo má některou z nich, která není integrovaná s Microsoft Entra ID, měli byste nasadit aplikaci Microsoft Entra PHS a definovat plán zotavení po havárii, který zahrnuje PHS. Povolením služby Microsoft Entra PHS umožníte uživatelům ověřovat se na základě ID Microsoft Entra, pokud vaše místní Active Directory nebudou k dispozici.

Tok synchronizace hodnot hash hesel

Pokud chcete lépe porozumět možnostem ověřování, přečtěte si téma Volba správné metody ověřování pro řešení hybridní identity Microsoft Entra.

Programové použití přihlašovacích údajů

Skripty Microsoft Entra ID pomocí PowerShellu nebo aplikací využívajících rozhraní Microsoft Graph API vyžadují zabezpečené ověřování. Špatná správa přihlašovacích údajů spouštěná těmito skripty a nástroji zvyšuje riziko krádeže přihlašovacích údajů. Pokud používáte skripty nebo aplikace, které spoléhají na pevně zakódovaná hesla nebo výzvy k zadání hesla, měli byste nejdřív zkontrolovat hesla v konfiguračních souborech nebo zdrojovém kódu, pak tyto závislosti nahraďte a kdykoli je to možné, použijte spravované identity Azure, integrované ověřování systému Windows nebo certifikáty . U aplikací, kde předchozí řešení nejsou možná, zvažte použití služby Azure Key Vault.

Pokud zjistíte, že existují instanční objekty s přihlašovacími údaji hesla a nejste si jisti, jak jsou tyto přihlašovací údaje hesla zabezpečené pomocí skriptů nebo aplikací, požádejte vlastníka aplikace, aby lépe porozuměl vzorům použití.

Microsoft také doporučuje kontaktovat vlastníky aplikací, aby pochopili vzory použití, pokud existují instanční objekty s přihlašovacími údaji pro hesla.

Prostředí ověřování

Místní ověřování

Federované ověřování s integrovaným ověřováním Systému Windows (IWA) nebo bezproblémové jednotné přihlašování (SSO) spravované pomocí synchronizace hodnot hash hesel nebo předávacího ověřování je nejlepší uživatelské prostředí v podnikové síti s dohledem místních řadičů domény. Minimalizuje únavu při výzvě k zadání přihlašovacích údajů a snižuje riziko, že uživatelé přepadají na útoky phishing. Pokud už používáte cloudové ověřování s phS nebo PTA, ale uživatelé stále potřebují zadat heslo při ověřování v místním prostředí, měli byste okamžitě nasadit bezproblémové jednotné přihlašování. Pokud jste aktuálně federovali s plány na migraci na ověřování spravované v cloudu, měli byste v rámci projektu migrace implementovat bezproblémové jednotné přihlašování.

Zásady přístupu důvěryhodnosti zařízení

Stejně jako uživatel ve vaší organizaci je zařízení základní identitou, kterou chcete chránit. Identitu zařízení můžete použít k ochraně vašich prostředků kdykoli a z libovolného umístění. Ověřování zařízení a účetnický pro jeho typ důvěryhodnosti zlepšuje stav zabezpečení a použitelnost pomocí:

  • Vyhněte se tření, například s vícefaktorovým ověřováním, pokud je zařízení důvěryhodné.
  • Blokování přístupu z nedůvěryhodných zařízení
  • U zařízení s Windows 10 bez problémů připojte jednotné přihlašování k místním prostředkům.

Tento cíl můžete provést přenesením identit zařízení a jejich správou v Microsoft Entra ID pomocí jedné z následujících metod:

  • Organizace můžou pomocí Microsoft Intune spravovat zařízení a vynucovat zásady dodržování předpisů, otestovat stav zařízení a nastavovat zásady podmíněného přístupu na základě toho, jestli zařízení vyhovuje. Microsoft Intune může spravovat zařízení s iOSem, stolní počítače Mac (prostřednictvím integrace JAMF), stolní počítače s Windows (nativně pomocí mobilních Správa zařízení pro Windows 10 a spolusprávu pomocí Microsoft Configuration Manageru) a mobilních zařízení s Androidem.
  • Hybridní připojení Microsoft Entra zajišťuje správu pomocí zásad skupiny nebo nástroje Microsoft Configuration Manager v prostředí s počítači připojenými k doméně služby Active Directory. Organizace můžou nasadit spravované prostředí prostřednictvím PHS nebo PTA s bezproblémovým jednotným přihlašováním. Přenesení zařízení do Microsoft Entra ID maximalizuje produktivitu uživatelů prostřednictvím jednotného přihlašování napříč cloudovými a místními prostředky a zároveň umožňuje zabezpečit přístup ke cloudovým a místním prostředkům pomocí podmíněného přístupu .

Pokud máte zařízení s Windows připojená k doméně, která nejsou zaregistrovaná v cloudu nebo zařízení s Windows připojená k doméně, která jsou zaregistrovaná v cloudu, ale bez zásad podmíněného přístupu, měli byste zaregistrovat neregistrovaná zařízení a v obou případech použít hybridní připojení Microsoft Entra jako ovládací prvek v zásadách podmíněného přístupu.

Snímek obrazovky s udělením v zásadách podmíněného přístupu vyžadujících hybridní zařízení

Pokud spravujete zařízení pomocí MDM nebo Microsoft Intune, ale nepoužíváte ovládací prvky zařízení v zásadách podmíněného přístupu, doporučujeme v těchto zásadách označit zařízení jako vyhovující .

Snímek obrazovky s udělením v zásadách podmíněného přístupu vyžadujících dodržování předpisů zařízením

Windows Hello pro firmy

Ve Windows 10 Windows Hello pro firmy nahrazuje hesla silným dvojúrovňovým ověřováním na počítačích. Windows Hello pro firmy uživatelům umožňuje efektivnější vícefaktorové ověřování a snižuje závislost na heslech. Pokud jste nezačali zavádět zařízení s Windows 10 nebo jste je nasadili jenom částečně, doporučujeme upgradovat na Windows 10 a povolit Windows Hello pro firmy na všech zařízeních.

Pokud se chcete dozvědět více o ověřování bez hesla, přečtěte si článek Svět bez hesel s ID Microsoft Entra.

Ověřování a přiřazení aplikací

Jednotné přihlašování pro aplikace

Zajištění standardizovaného mechanismu jednotného přihlašování pro celý podnik je zásadní pro nejlepší uživatelské prostředí, snížení rizika, schopnost hlásit a zásady správného řízení. Pokud používáte aplikace, které podporují jednotné přihlašování s MICROSOFT Entra ID, ale aktuálně jsou nakonfigurované pro použití místních účtů, měli byste tyto aplikace překonfigurovat tak, aby používaly jednotné přihlašování s Microsoft Entra ID. Podobně pokud používáte jakékoli aplikace, které podporují jednotné přihlašování s ID Microsoft Entra, ale používají jiného zprostředkovatele identity, měli byste tyto aplikace překonfigurovat tak, aby používaly jednotné přihlašování i s ID Microsoft Entra. Pro aplikace, které nepodporují federační protokoly, ale podporují ověřování pomocí formulářů, doporučujeme aplikaci nakonfigurovat tak, aby používala trezor hesel s proxy aplikací Microsoft Entra.

Poznámka:

Pokud nemáte mechanismus pro zjišťování nespravovaných aplikací ve vaší organizaci, doporučujeme implementovat proces zjišťování pomocí zprostředkovatele zabezpečení cloudových aplikací (CASB), jako je Microsoft Defender for Cloud Apps.

Pokud máte galerii aplikací Microsoft Entra a používáte aplikace, které podporují jednotné přihlašování s ID Microsoft Entra, doporučujeme aplikaci zobrazit v galerii aplikací.

Migrace aplikací SLUŽBY AD FS do Microsoft Entra ID

Migrace aplikací ze služby AD FS do Microsoft Entra ID umožňuje další možnosti zabezpečení, konzistentnější možnosti správy a lepší možnosti spolupráce. Pokud máte aplikace nakonfigurované ve službě AD FS, které podporují jednotné přihlašování s ID Microsoft Entra, měli byste tyto aplikace překonfigurovat tak, aby používaly jednotné přihlašování s Id Microsoft Entra. Pokud máte aplikace nakonfigurované ve službě AD FS s neobvyklými konfiguracemi nepodporovanými id Microsoft Entra, měli byste se obrátit na vlastníky aplikací a zjistit, jestli je zvláštní konfigurace absolutním požadavkem aplikace. Pokud to není povinné, měli byste aplikaci překonfigurovat tak, aby používala jednotné přihlašování s ID Microsoft Entra.

Microsoft Entra ID jako primární zprostředkovatel identity

Poznámka:

Microsoft Entra Connect Health pro SLUŽBU AD FS lze použít ke shromažďování podrobností o konfiguraci jednotlivých aplikací, které je možné migrovat do Microsoft Entra ID.

Přiřazení uživatelů k aplikacím

Přiřazování uživatelů k aplikacím je nejlepší mapovat pomocí skupin, protože umožňují větší flexibilitu a možnosti správy ve velkém měřítku. Mezi výhody používání skupin patří skupiny založené na atributech a delegování pro vlastníky aplikací. Proto pokud už používáte a spravujete skupiny, doporučujeme provést následující akce, abyste zlepšili správu ve velkém měřítku:

  • Delegujte správu skupin a zásady správného řízení vlastníkům aplikací.
  • Povolte samoobslužný přístup k aplikaci.
  • Definujte dynamické skupiny členství, pokud atributy uživatelů můžou konzistentně určovat přístup k aplikacím.
  • Implementujte ověření identity do skupin používaných pro přístup k aplikacím pomocí kontrol přístupu Microsoft Entra.

Pokud naopak zjistíte aplikace, které mají přiřazení jednotlivým uživatelům, nezapomeňte implementovat zásady správného řízení pro tyto aplikace.

Zásady přístupu

Pojmenovaná umístění

S pojmenovanými umístěními v Microsoft Entra ID můžete označit důvěryhodné rozsahy IP adres ve vaší organizaci. Microsoft Entra ID používá pojmenovaná umístění k:

  • Zabraňte falešně pozitivním výsledkům v rizikových událostech. Přihlášení z důvěryhodného síťového umístění snižuje riziko přihlášení uživatele.
  • Nakonfigurujte podmíněný přístup založený na umístění.

Pojmenované umístění

V závislosti na prioritě vyhledejte v následující tabulce doporučené řešení, které nejlépe vyhovuje potřebám vaší organizace:

Priorita Scénář Doporučení
0 Pokud používáte PHS nebo PTA a pojmenovaná umístění nebyla definována. Definování pojmenovaných umístění pro zlepšení detekce rizikových událostí
2 Pokud jste federovaná a nepoužíváte deklaraci identity insideCorporateNetwork a pojmenovaná umístění nebyla definována. Definování pojmenovaných umístění pro zlepšení detekce rizikových událostí
3 Pokud v zásadách podmíněného přístupu nepoužíváte pojmenovaná umístění a v zásadách podmíněného přístupu neexistuje žádné riziko ani řízení zařízení Konfigurace zásad podmíněného přístupu tak, aby zahrnovala pojmenovaná umístění
4 Pokud jste federovaná a používáte deklaraci identity "insideCorporateNetwork" a pojmenovaná umístění nebyla definována. Definování pojmenovaných umístění pro zlepšení detekce rizikových událostí
5 Pokud používáte důvěryhodné IP adresy s vícefaktorovým ověřováním místo pojmenovaných umístění a označíte je jako důvěryhodné. Definujte pojmenovaná umístění a označte je jako důvěryhodné, aby se zlepšilo zjišťování rizikových událostí.

Zásady přístupu na základě rizika

Id Microsoft Entra může vypočítat riziko pro každé přihlášení a každého uživatele. Použití rizika jako kritéria v zásadách přístupu může poskytovat lepší uživatelské prostředí, například menší počet výzev k ověřování a lepší zabezpečení, například pouze výzvy uživatelů v případě potřeby, a automatizovat odpověď a nápravu.

Zásady rizik přihlašování

Pokud už vlastníte licence Microsoft Entra ID P2, které podporují používání rizik v zásadách přístupu, ale nepoužívají se, důrazně doporučujeme přidat riziko do stavu zabezpečení.

Zásady přístupu k klientským aplikacím

Správa aplikací Microsoft Intune (MAM) umožňuje odesílat ovládací prvky ochrany dat, jako je šifrování úložiště, PIN kód, vyčištění vzdáleného úložiště atd. kompatibilním klientským mobilním aplikacím, jako je Outlook Mobile. Kromě toho je možné vytvořit zásady podmíněného přístupu, které omezují přístup ke cloudovým službám, jako je Exchange Online, ze schválených nebo kompatibilních aplikací.

Pokud vaši zaměstnanci instalují aplikace podporující MAM, jako jsou mobilní aplikace Office pro přístup k podnikovým prostředkům, jako je Exchange Online nebo SharePoint v Microsoftu 365, a podporujete také byOD (přineste si vlastní zařízení), doporučujeme nasadit zásady MAM pro správu konfigurace aplikace v osobních zařízeních bez registrace MDM a pak aktualizovat zásady podmíněného přístupu tak, aby povolovaly přístup jenom klientům podporujícím MAM.

Řízení udělení podmíněného přístupu

Pokud zaměstnanci nainstalují aplikace podporující MAM pro podnikové prostředky a přístup jsou na spravovaných zařízeních Intune omezené, měli byste zvážit nasazení zásad MAM aplikací pro správu konfigurace aplikace pro osobní zařízení a aktualizaci zásad podmíněného přístupu tak, aby povolovaly přístup jenom klientům podporujícím MAM.

Implementace podmíněného přístupu

Podmíněný přístup je základním nástrojem pro zlepšení stavu zabezpečení ve vaší organizaci. Proto je důležité postupovat podle těchto osvědčených postupů:

  • Ujistěte se, že se pro všechny aplikace SaaS použila alespoň jedna zásada.
  • Vyhněte se kombinování filtru Všechny aplikace s ovládacím prvkům blokování , abyste se vyhnuli riziku uzamčení.
  • Nepoužívejte uživatele jako filtr a neúmyslně přidávat hosty.
  • Migrace všech starších zásad na web Azure Portal
  • Zachycení všech kritérií pro uživatele, zařízení a aplikace
  • Použití zásad podmíněného přístupu k implementaci vícefaktorového ověřování místo použití vícefaktorového ověřování pro jednotlivé uživatele
  • Máte malou sadu základních zásad, které se můžou vztahovat na více aplikací.
  • Definujte prázdné skupiny výjimek a přidejte je do zásad, aby měly strategii výjimek.
  • Plánování účtů se zalomeným sklem bez vícefaktorového ověřování
  • Zajistěte konzistentní prostředí v klientských aplikacích Microsoftu 365, například Teams, OneDrive, Outlook atd.) implementací stejné sady ovládacích prvků pro služby, jako je Exchange Online a SharePoint v Microsoftu 365
  • Přiřazení k zásadám by se mělo implementovat prostřednictvím skupin, nikoli jednotlivců.
  • Pravidelně kontrolujte skupiny výjimek používané v zásadách, abyste omezili dobu, po které uživatelé nejsou v stavu zabezpečení. Pokud vlastníte Microsoft Entra ID P2, můžete tento proces automatizovat pomocí kontrol přístupu.

Přístupová plocha

Starší verze ověřování

Silné přihlašovací údaje, jako je vícefaktorové ověřování, nemůžou chránit aplikace pomocí starších ověřovacích protokolů, což z něj činí upřednostňovaný vektor útoku škodlivými aktéry. Uzamčení starší verze ověřování je zásadní pro zlepšení stavu zabezpečení přístupu.

Starší verze ověřování je termín, který odkazuje na ověřovací protokoly používané aplikacemi, jako jsou:

  • Starší klienti Office, kteří nepoužívají moderní ověřování (například klient Office 2010)
  • Klienti, kteří používají poštovní protokoly, jako je protokol IMAP (Internet Message Access Protocol)/SMTP (Simple Mail Transfer Protocol)/bod přítomnosti (POP)

Útočníci důrazně dávají přednost těmto protokolům – ve skutečnosti téměř 100% útoků password spray používají starší ověřovací protokoly! Hackeři používají starší ověřovací protokoly, protože nepodporují interaktivní přihlašování, což je potřeba pro další výzvy zabezpečení, jako je vícefaktorové ověřování a ověřování zařízení.

Pokud se ve vašem prostředí běžně používá starší verze ověřování, měli byste naplánovat migraci starších klientů na klienty, kteří podporují moderní ověřování co nejdříve. Pokud ve stejném tokenu už někteří uživatelé používají moderní ověřování, ale jiní uživatelé, kteří stále používají starší ověřování, měli byste pomocí následujících kroků uzamknout starší klienty ověřování:

  1. Pomocí sestav aktivit přihlašování identifikujte uživatele, kteří stále používají starší ověřování a nápravu plánu:

    1. Upgradujte na moderní klienty podporující ověřování pro ovlivněné uživatele.

    2. Naplánujte časový rámec přímé migrace, abyste mohli uzamknout jednotlivé kroky níže.

    3. Zjistěte, které starší verze aplikací mají pevnou závislost na starším ověřování. Viz krok 3 níže.

  2. Zakažte starší protokoly ve zdroji (například poštovní schránka Exchange) pro uživatele, kteří nepoužívají starší ověřování, aby se zabránilo většímu vystavení.

  3. U zbývajících účtů (ideálně nelidských identit, jako jsou účty služeb), použijte podmíněný přístup k omezení starších protokolů po ověření.

V neoprávněném útoku na udělení souhlasu útočník vytvoří zaregistrovanou aplikaci Microsoft Entra, která požaduje přístup k datům, jako jsou kontaktní informace, e-mail nebo dokumenty. Uživatelé můžou udělit souhlas se škodlivými aplikacemi prostřednictvím útoků phishing při přistání na škodlivých webech.

Níže je seznam aplikací s oprávněními, které můžete chtít prověřovat pro cloudové služby Microsoftu:

  • Aplikace s aplikací nebo delegovaným *. Oprávnění readWrite
  • Aplikace s delegovanými oprávněními můžou číst, posílat nebo spravovat e-maily jménem uživatele.
  • Aplikace, kterým jsou udělena následující oprávnění:
Prostředek Oprávnění
Exchange Online EAS. AccessAsUser.All
EWS. AccessAsUser.All
Mail.Read
Microsoft Graph API Mail.Read
Mail.Read.Shared
Mail.ReadWrite
  • Aplikace udělily plnou zosobnění přihlášeného uživatele. Příklad:
Prostředek Oprávnění
Microsoft Graph API Directory.AccessAsUser.All
Azure REST API user_impersonation

Abyste se tomuto scénáři vyhnuli, měli byste v Office 365 odkazovat na zjištění a nápravu neoprávněných udělení souhlasu, abyste identifikovali a opravili všechny aplikace s neoprávněnými granty nebo aplikacemi, které mají více grantů, než je nutné. Dále zcela odeberte samoobslužné služby a vytvořte postupy zásad správného řízení. Nakonec naplánujte pravidelné kontroly oprávnění aplikace a odeberte je, když nejsou potřeba.

Nastavení uživatelů a skupin

Níže jsou uvedená nastavení uživatelů a skupin, která se dají uzamknout, pokud není potřeba explicitní obchodní potřeby:

Uživatelská nastavení

  • Externí uživatelé – externí spolupráce může probíhat přirozeně v podniku se službami, jako jsou Teams, Power BI, SharePoint v Microsoftu 365 a Azure Information Protection. Pokud máte explicitní omezení pro řízení externí spolupráce iniciované uživatelem, doporučujeme povolit externí uživatele pomocí správy nároků Microsoft Entra nebo řízené operace, jako je například prostřednictvím helpdesku. Pokud nechcete povolit organické externí spolupráci pro služby, můžete členům úplně zablokovat pozvání externích uživatelů. Alternativně můžete také povolit nebo blokovat konkrétní domény v pozvánkách externích uživatelů.
  • Registrace aplikací – když jsou povolené Registrace aplikací, můžou koncoví uživatelé připojit aplikace sami a udělit přístup ke svým datům. Typickým příkladem registrace aplikací je povolení modulů plug-in Outlooku nebo hlasových asistentů, jako je Alexa a Siri, aby si přečetli svůj e-mail a kalendář nebo jim posílali e-maily svým jménem. Pokud se zákazník rozhodne registraci aplikací vypnout, musí se týmy InfoSec a IAM podílet na správě výjimek (registrace aplikací, které jsou potřeba na základě obchodních požadavků), protože by musely zaregistrovat aplikace s účtem správce a s největší pravděpodobností vyžadují návrh procesu pro zprovoznění procesu.
  • Portál pro správu – organizace můžou okno Microsoft Entra uzamknout na webu Azure Portal, aby uživatelé, kteří nejsou správci, nemohli získat přístup ke správě Microsoft Entra na webu Azure Portal a nezmást se. Pokud chcete omezit přístup, přejděte na uživatelské nastavení na portálu pro správu Microsoft Entra:

Omezený přístup k portálu pro správu

Poznámka:

Nesprávci mají stále přístup k rozhraním pro správu Microsoft Entra prostřednictvím příkazového řádku a dalších programových rozhraní.

Nastavení skupin

Samoobslužná správa skupin / Uživatelé můžou vytvářet skupiny zabezpečení / skupiny Microsoftu 365. Pokud neexistuje žádná aktuální samoobslužná iniciativa pro skupiny v cloudu, zákazníci se můžou rozhodnout tuto možnost vypnout, dokud nebudou připravení tuto funkci použít.

Provoz z neočekávaných umístění

Útočníci pocházejí z různých částí světa. Toto riziko můžete spravovat pomocí zásad podmíněného přístupu s umístěním jako podmínkou. Podmínka umístění zásad podmíněného přístupu umožňuje blokovat přístup k umístěním, ze kterých není žádný obchodní důvod k přihlášení.

Vytvoření nového pojmenovaného umístění

Pokud je k dispozici, použijte řešení pro správu událostí a informací o zabezpečení (SIEM) k analýze a hledání vzorů přístupu napříč oblastmi. Pokud produkt SIEM nepoužíváte nebo ingestuje ověřovací informace z ID Microsoft Entra, doporučujeme použít Azure Monitor k identifikaci vzorů přístupu napříč oblastmi.

Využití přístupu

Archivované a integrované protokoly Microsoft Entra s plány reakcí na incidenty

Přístup k aktivitě přihlašování, auditům a rizikovým událostem pro ID Microsoft Entra je zásadní pro řešení potíží, analýzy využití a forenzní šetření. Microsoft Entra ID poskytuje přístup k těmto zdrojům prostřednictvím rozhraní REST API, která mají omezenou dobu uchovávání. Systém správy informací o zabezpečení a událostí (SIEM) nebo ekvivalentní archivní technologie je klíčem k dlouhodobému ukládání auditů a podpory. Pokud chcete povolit dlouhodobé ukládání protokolů Microsoft Entra, musíte je buď přidat do stávajícího řešení SIEM, nebo použít Azure Monitor. Archivujte protokoly, které je možné použít jako součást plánů reakcí na incidenty a vyšetřování.

Shrnutí

Pro zabezpečenou infrastrukturu identit existuje 12 aspektů. Tento seznam vám pomůže dále zabezpečit a spravovat přihlašovací údaje, definovat prostředí ověřování, delegovat přiřazení, měření využití a definovat zásady přístupu na základě stavu zabezpečení podniku.

  • Přiřaďte vlastníky k klíčovým úkolům.
  • Implementujte řešení pro detekci slabých nebo nevrácených hesel, zlepšení správy a ochrany hesel a dalšího zabezpečení přístupu uživatelů k prostředkům.
  • Spravujte identitu zařízení, která chrání vaše prostředky kdykoli a z libovolného umístění.
  • Implementujte ověřování bez hesla.
  • Poskytuje standardizovaný mechanismus jednotného přihlašování v celé organizaci.
  • Migrujte aplikace ze služby AD FS do Microsoft Entra ID, abyste umožnili lepší zabezpečení a konzistentnější možnosti správy.
  • Přiřaďte uživatele k aplikacím pomocí skupin, abyste umožnili větší flexibilitu a možnost spravovat ve velkém měřítku.
  • Nakonfigurujte zásady přístupu na základě rizik.
  • Uzamkněte starší ověřovací protokoly.
  • Zjištění a náprava neoprávněných udělení souhlasu.
  • Uzamkněte nastavení uživatele a skupiny.
  • Povolte dlouhodobé ukládání protokolů Microsoft Entra pro účely řešení potíží, analýzy využití a forenzních šetření.

Další kroky

Začněte s provozními kontrolami a akcemi zásad správného řízení identit.