Správa identit a přístupu cílové zóny

Po identifikaci architektury identit musíte spravovat autorizaci a přístup k prostředkům v cílových zónách aplikací a platforem. Zvažte, ke kterým prostředkům má každý ověřený objekt zabezpečení přístup a ke kterým potřebuje přístup, a jak zmírnit riziko neoprávněného přístupu k vašim prostředkům. Další informace najdete v tématu Návrh architektury identit.

Přehled

Oblast návrhu správy identit a přístupu poskytuje pokyny, které vám pomůžou implementovat model podnikového přístupu v Azure a implementovat a zabezpečit řídicí roviny. Když začleníte princip návrhu demokratizace předplatného, může tým vaší aplikace spravovat vlastní úlohy v rámci mantinely zásad, které tým platformy nastaví. Tento přístup se také řídí zásadou zásad správného řízení .

Tým platformy zodpovídá za zřizování nových cílových zón nebo předplatných aplikací. Když zřídí cílovou zónu pro vlastníka aplikace, tým platformy by ho měl nakonfigurovat pomocí příslušných řízení přístupu, aby vlastník aplikace mohl spravovat vlastní prostředky. Vlastník aplikace by měl mít možnost vytvářet a spravovat uživatele a skupiny v rámci ID Microsoft Entra a přiřazovat těmto uživatelům a skupinám role. Vlastník aplikace pak může podle potřeby spravovat přístup k vlastním prostředkům a delegovat přístup k ostatním uživatelům a skupinám. Cílová zóna by také měla mít volitelné síťové připojení ke službám Doména služby Active Directory Services (AD DS) nebo Microsoft Entra Domain Services v předplatném platformy Microsoft Identity Platform v závislosti na požadavcích aplikace.

Ke správě přístupu k prostředkům Azure použijte řízení přístupu na základě role (RBAC). Zvažte, jestli uživatelé vyžadují oprávnění pro úzký obor, například Správa istrator pro jednu aplikaci, nebo široký obor, například síťový Správa istrator napříč několika úlohami aplikace. V obou případech se řídí principem přístupu dostatečného přístupu a ujistěte se, že má uživatel pouze role požadované pro své běžné aktivity. Pokud je to potřeba k vynucení přístupu za běhu (JIT), použijte vlastní role a Microsoft Entra Privileged Identity Management (PIM). I když je tým platformy zodpovědný za základ správy identit a přístupu, týmy platforem i aplikací jsou spotřebiteli služby a měly by dodržovat stejné zásady.

Správa identit a přístupu je důležitá pro úspěšné oddělení jedné cílové zóny od druhé a izolaci úloh v rámci organizace. Jedná se o kritickou oblast návrhu pro cílové zóny platformy i aplikace.

Pokud vaše organizace používá prodejní proces předplatného, můžete automatizovat řadu konfigurací identit a přístupu pro cílové zóny aplikací. Implementujte správa předplatného, které vám pomůžou standardizovat vytváření cílových zón a aby týmy aplikací mohly spravovat vlastní prostředky.

Aspekty návrhu

Některé organizace sdílejí služby mezi více aplikacemi. Může se například jednat o centralizovanou integrační službu používanou několika nezávislými aplikacemi. V tomto scénáři zvažte, které služby se spravují centrálně a které se odvolají týmům aplikací, a zjistěte, kde je potřeba vynutit hranice zabezpečení. Poskytnutí přístupu ke sdílené službě týmům pro správu aplikací může být užitečné pro produktivitu vývojářů, ale může poskytovat více přístupu, než je potřeba.

Správu prostředků aplikace, které nepřekračují hranice zabezpečení, je možné delegovat na týmy aplikací. Zvažte delegování dalších aspektů, které jsou potřeba k zachování zabezpečení a dodržování předpisů. Umožnit uživatelům zřizovat prostředky v zabezpečeném spravovaném prostředí umožňuje organizacím využívat agilní povahu cloudu a zabránit porušení důležitých hranic zabezpečení nebo zásad správného řízení.

RBAC

Důležité

Klasické prostředky a klasické správce se 31. srpna 2024 vyřazuje z provozu. Odeberte nepotřebné spolusprávce a použijte Azure RBAC k jemně odstupňovanému řízení přístupu.

Seznamte se s rozdíly mezi rolemi Microsoft Entra ID a rolemi Azure RBAC.

• Role ID Microsoft Entra řídí oprávnění správce ke službám celého tenanta, jako je Microsoft Entra ID, a další služby Microsoft včetně Microsoft Teams, Microsoft Exchange Online a Microsoft Intune.

• Role Azure RBAC řídí oprávnění správce k prostředkům Azure, jako jsou virtuální počítače, předplatná a skupiny prostředků.

• Role vlastníka Azure RBAC a přístupu uživatelů Správa istrator můžou měnit přiřazení rolí v prostředcích Azure. Ve výchozím nastavení nemá role Globální Správa istrator Microsoftu oprávnění ke správě přístupu k prostředkům Azure. Musí být explicitně povolen. Podrobnosti najdete v tématu Zvýšení úrovně přístupu pro správu všech předplatných Azure a skupin pro správu.

Následující diagram znázorňuje vztah mezi rolemi ID Microsoft Entra a rolemi Azure RBAC:

• Pokud vlastnost nastavíte na , můžete vytvořit skupiny, které lze přiřadit role a přiřadit microsoft Entra ke skupinámisAssignableToRole .true Chráněné jsou pouze skupiny s touto sadou vlastností. Jedinými rolemi, které mohou upravovat členství ve skupině, jsou globální Správa istrátory, privilegované role Správa istrátory nebo vlastník skupiny.

• Nastavení vícefaktorového ověřování (MFA) pro jiného správce můžou resetovat jenom některé role. Toto omezení brání neoprávněným správcům v resetování přihlašovacích údajů účtu s vyššími oprávněními, aby získali více oprávnění.

• Pokud předdefinované role Azure nevyhovují konkrétním potřebám vaší organizace, můžete vytvořit vlastní role. Stejně jako předdefinované role můžete uživatelům, skupinám a instančním objektům přiřadit vlastní role v oborech tenantů, skupin pro správu, předplatného a skupin prostředků. Pokud je to možné, snažte se používat předdefinované role Azure a v případě potřeby vytvářet jenom vlastní role.

• Při návrhu strategie řízení přístupu znáte limity služeb pro role, přiřazení rolí a vlastní role.

• Některé role Azure RBAC podporují řízení přístupu na základě atributů (ABAC) nebo podmínky přiřazení rolí. Při použití podmínek můžou správci dynamicky přiřazovat role na základě atributů prostředku. Můžete například přiřadit roli Přispěvatel dat v objektech blob služby Storage, ale jenom pro objekty blob, které mají určitou značku indexu, a ne všechny objekty blob v kontejneru.

Doporučení k návrhu

Obecná doporučení

• Vynucujte vícefaktorové ověřování Microsoft Entra (MFA) pro uživatele, kteří mají práva k prostředí Azure, včetně předplatného platformy, předplatné aplikace a tenanta Microsoft Entra ID. Mnoho architektur dodržování předpisů vyžaduje vynucení vícefaktorového ověřování. Vícefaktorové ověřování pomáhá snížit riziko krádeže přihlašovacích údajů a neoprávněného přístupu. Pokud chcete zabránit neoprávněnému přístupu k citlivým informacím, ujistěte se, že do zásad vícefaktorového ověřování zahrnete uživatele s rolemi čtenáře.

• Použijte zásady podmíněného přístupu Microsoft Entra pro uživatele, kteří mají práva k prostředí Azure. Podmíněný přístup je další funkce, která pomáhá chránit řízené prostředí Azure před neoprávněným přístupem. Správci aplikací a platforem by měli mít zásady podmíněného přístupu, které odrážejí profil rizika jejich role. Můžete mít například požadavky na provádění administrativních aktivit pouze z konkrétních umístění nebo konkrétních pracovních stanic. Nebo tolerance rizik přihlašování pro uživatele s přístupem pro správu k prostředkům Azure může být nižší než u standardních uživatelů Microsoft Entra ID.

• Povolte Microsoft Defender for Identity , který pomáhá chránit identity uživatelů a zabezpečit přihlašovací údaje uživatele. Defender for Identity je součástí XDR v programu Microsoft Defender. Defender for Identity můžete použít k identifikaci podezřelých aktivit uživatelů a získání časových os incidentů. Můžete ho také použít s podmíněným přístupem k odepření vysoce rizikových pokusů o ověření. Nasaďte senzory Defenderu for Identity na místní řadiče domény a řadiče domény v předplatném identity Azure.

• Využijte Microsoft Sentinel k poskytování informací o hrozbách a možnostech šetření. Sentinel používá protokoly z protokolů služby Azure Monitor, Microsoft Entra ID, Microsoft 365 a dalších služeb k zajištění proaktivní detekce, vyšetřování a reakce na hrozby.

• Oddělte přístup pro správu od nesprávných, každodenních přístupů, jako je procházení webu a přístup k e-mailu. Web a e-mail jsou běžné vektory útoku. Když dojde k ohrožení zabezpečení uživatelského účtu, je méně pravděpodobné, že dojde k narušení zabezpečení, pokud se účet nepoužívá pro přístup pro správu.

  • Pro privilegované role používejte samostatné cloudové účty. Nepoužívejte stejný účet pro každodenní použití, který děláte pro privilegovanou správu. Privilegované ID Microsoft Entra a role Azure RBAC jsou označené jako PRIVILEGED na webu Azure Portal a v dokumentaci.

  • U neprivilegovaných rolí funkcí úloh, které můžou spravovat prostředky aplikace Azure, zvažte, jestli potřebujete samostatné účty pro správu, nebo k řízení přístupu pro správu použijte Microsoft Entra PIM . PIM zajišťuje, že účet má požadovaná oprávnění pouze v případě potřeby a že se oprávnění odeberou po dokončení úkolu (označuje se také jako přístup za běhu).

• Pokud chcete lépe spravovat přiřazení rolí, nepřiřaďte role přímo uživatelům. Místo toho přiřaďte role skupinám, abyste minimalizovali počet přiřazení rolí, které mají limit pro každé předplatné.

  • Pomocí nástroje Microsoft Entra PIM můžete pro skupiny použít řízení přístupu pro správu za běhu pro privilegované uživatele. Zvažte řízení členství ve skupinách pomocí správy nároků. Pomocí funkce správy nároků můžete přidat pracovní postupy schvalování a auditování do operací členství ve skupinách a zajistit, aby členové skupiny pro správu zbytečně nepřidali nebo neodebrali.
  • Když udělíte přístup k prostředkům, použijte skupiny Microsoft Entra-only pro prostředky řídicí roviny Azure. Do skupiny jen pro entra je možné přidat uživatele a skupiny, které jsou synchronizované z místního prostředí pomocí microsoft Entra Připojení. Pokud už existuje systém pro správu skupin, přidejte do skupiny Microsoft Entra-only místní skupiny. Použití skupin jen pro entra pomáhá chránit rovinu řízení cloudu před neoprávněnou úpravou místních adresářových služeb. Upozorňujeme, že pouze Microsoft Entra-only se označuje jako pouze cloud.

• Vytvářejte účty pro nouzový přístup nebo účty se zalomeným sklem, abyste se vyhnuli náhodnému uzamčení vaší organizace Microsoft Entra ID. Účty pro nouzový přístup jsou vysoce privilegované a jsou přiřazeny pouze konkrétním jednotlivcům. Uložte přihlašovací údaje pro účty bezpečně, monitorujte jejich použití a pravidelně je otestujte, abyste je mohli použít, pokud dojde k havárii.

  Další informace naleznete v tématu Postupy zabezpečeného přístupu pro správce v Microsoft Entra ID.

Doporučení microsoft Entra ID

• Integrujte ID Microsoft Entra se službou Azure Monitor , abyste mohli analyzovat svoji přihlašovací aktivitu a záznam auditu změn v rámci vašeho tenanta. Nakonfigurujte nastavení diagnostiky tak, aby v předplatném pro správu odesílaly protokoly přihlašování a protokoly auditu do pracovního prostoru protokolů centrální platformy Azure Monitoru.

• Pomocí funkce správy nároků zásad správného řízení Microsoft Entra ID můžete vytvářet přístupové balíčky, které řídí členství ve skupinách prostřednictvím automatických schvalovacích procesů a pravidelných kontrol přístupu pro členy privilegovaných skupin.

• Pomocí předdefinovaných rolí Microsoft Entra můžete spravovat následující nastavení identity z úrovně tenanta:

  Role	Popis	Poznámka:
  Globální správce	Spravuje všechny aspekty ID Microsoft Entra a služby Microsoft, které používají identity Microsoft Entra.	Nepřiřazujte k této roli víc než pět lidí.
  Hybridní identita Správa istrator	Spravuje zřizování cloudu z Active Directory do Microsoft Entra ID a také spravuje Microsoft Entra Připojení, předávací ověřování Microsoft Entra, synchronizaci hodnot hash hesel Microsoft Entra, bezproblémové jednotné přihlašování (SSO) Microsoft Entra a nastavení federace.
  Správce zabezpečení	Čte informace o zabezpečení a sestavy a spravuje konfigurace v Microsoft Entra ID a Microsoft 365.
  Správce aplikace	Vytvoří a spravuje všechny aspekty registrace aplikací a podnikových aplikací.	Nemůžete udělit souhlas správce v rámci celého tenanta.

• Nepřiřazovat vyšší privilegovanou roli k úloze, kterou může provádět role s nižšími oprávněními. Například přiřaďte roli uživatel Správa istrator ke správě uživatelů, nikoli globální Správa istrator role. Další informace naleznete v tématu Microsoft Entra předdefinovaná oprávnění rolí.

• Pomocí jednotek pro správu omezte sadu správců, aby mohli spravovat jenom konkrétní objekty ve vašem tenantovi. Jednotky pro správu můžete použít k delegování správy podmnožinu adresáře. Správu oddělení služeb můžete například delegovat na jednu organizační jednotku v rámci širší organizace.

  Správa istrativní jednotky mohou také pomoct eliminovat potřebu samostatných tenantů Microsoft Entra ID jako hranice zabezpečení, kde samostatné týmy spravují platformu Microsoft 365 a platformu Azure ve stejné organizaci. Pomocí jednotek pro správu můžete například delegovat správu objektů zabezpečení aplikací Azure na tým aplikací bez udělení oprávnění pro celého tenanta Microsoft Entra ID.

• K zajištění další ochrany použijte omezené jednotky pro správu. Zabraňte všem jiným uživatelům než konkrétní sadě správců, které určíte, aby upravoval konkrétní objekty. Například vaše oddělení zásad povinností může vyžadovat, abyste pomocí této funkce zabránili komukoli v úpravě konkrétního uživatelského účtu, a to i uživatelům s rolí Uživatel Správa istrator. Toto omezení je užitečné pro účty služeb, které aplikace používají a které by ani správci neměli upravovat. Můžete také zabránit eskalaci oprávnění, například pokud někdo upraví uživatelský účet nebo skupinu s oprávněními pro správu platformy nebo cílové zóny.

Doporučení Azure RBAC

• Pro zjednodušení správy a snížení rizika chybné konfigurace standardizujte role a přiřazení rolí napříč všemi cílovými zónami aplikace. Pokud máte například roli, která deleguje uživatele na správu virtuálních počítačů, použijte stejnou roli ve všech cílových zónách aplikace. Tento přístup také zjednodušuje proces přesouvání prostředků mezi cílovými zónami.

• Pokud je to možné, použijte Azure RBAC ke správě přístupu k prostředkům roviny dat. Mezi příklady koncových bodů roviny dat patří Azure Key Vault, účet úložiště nebo databáze SQL.

• Ujistěte se, že jsou pracovní prostory protokolů služby Azure Monitor nakonfigurované s odpovídajícím modelem oprávnění. Pokud používáte centralizovaný pracovní prostor protokolů služby Azure Monitor, použijte oprávnění k prostředkům, abyste zajistili, že aplikační týmy mají přístup k vlastním protokolům, ale ne k protokolům z jiných týmů.

Předdefinované role

• Zvažte, jestli jsou předdefinované role vhodné pro vaše požadavky. V mnoha případech můžete skupině zabezpečení přiřadit více předdefinovaných rolí, abyste uživatelům poskytli odpovídající přístup. Někdy ale nemůžete používat předdefinované role a zároveň dodržovat přístup s nejnižšími oprávněními, protože tyto role můžou zahrnovat oprávnění, která překračují to, co vaši uživatelé vyžadují. Pokud chcete podrobnější řízení, zvažte vytvoření vlastní role, která odráží konkrétní oprávnění potřebná k provedení funkce úlohy. Další informace naleznete v tématu Poskytnutí autorizace na základě role.

• Mnoho předdefinovaných rolí Azure poskytuje předdefinovaná přiřazení rolí na úrovni platformy a prostředků. Když zkombinujete několik přiřazení rolí, zvažte celkové účinky.

• Akcelerátor cílové zóny Azure obsahuje několik vlastních rolí pro běžné funkce správy. Tyto role můžete použít společně s předdefinovanými rolemi Azure. Následující tabulka popisuje vlastní role nebo oblasti pro akcelerátor cílových zón Azure:

  Správa istrativní role nebo oblast	Popis	Akce	NotActions
  Vlastník platformy Azure (například předdefinovaná role vlastníka)	Spravuje skupiny pro správu a životní cyklus předplatného.	*
  Vlastník předplatného	Delegovaná role vlastníka předplatného	*	Microsoft.Authorization/*/write, , Microsoft.Network/vpnGateways/* Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/routeTables/write, Microsoft.Network/vpnSites/*
  Vlastník aplikace (DevOps, operace aplikací)	Role přispěvatele pro aplikační nebo provozní tým v oboru předplatného	*	Microsoft.Authorization/*/write, , Microsoft.Network/publicIPAddresses/write Microsoft.Network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action
  Správa sítě (NetOps)	Spravuje globální připojení pro celou platformu, jako jsou virtuální sítě, trasy definované uživatelem, skupiny zabezpečení sítě, síťová virtuální zařízení, sítě VPN, Azure ExpressRoute a další.	*/read, Microsoft.Network/*, Microsoft.Resources/deployments/*, Microsoft.Support/*
  Operace zabezpečení (SecOps)	Role Správa istrator zabezpečení s horizontálním zobrazením napříč všemi aktivy Azure a zásadami vymazání služby Key Vault	*/read, */register/action, Microsoft.KeyVault/locations/deletedVaults/purge/action, Microsoft.PolicyInsights/*, Microsoft.Authorization/policyAssignments/*, Microsoft.Authorization/policyDefinitions/*, Microsoft.Authorization/policyExemptions/*, Microsoft.Authorization/policySetDefinitions/*, Microsoft.Insights/alertRules/*, Microsoft.Resources/deployments/*, Microsoft.Security/*, Microsoft.Support/*

  Tyto role můžou v závislosti na modelu odpovědnosti potřebovat další práva. Například v některých organizacích může role NetOps vyžadovat jenom správu a konfiguraci globálního připojení. V organizacích, které potřebují centralizovanější přístup, můžete rozšířit roli NetOps o více povolených akcí, jako je vytvoření partnerského vztahu mezi rozbočovači a jejich paprsky.

Přiřazení rolí a skupiny

• Když tým platformy zřídí cílovou zónu aplikace, měl by zajistit, aby se vytvořily všechny požadované objekty správy identit a přístupu, jako jsou skupiny zabezpečení, standardní přiřazení rolí a spravované identity přiřazené uživatelem.

• Vytvořte přiřazení rolí cílové zóny v oboru předplatného nebo skupiny prostředků. Přiřazení azure Policy probíhají v oboru skupiny pro správu, takže byste měli zřídit přiřazení rolí cílové zóny v nižším rozsahu. Pomocí tohoto přístupu zajistíte, aby správci cílové zóny měli plnou autonomii nad svými prostředky, ale nemůžou upravovat přiřazení azure Policy, která řídí cílovou zónu.

• Každá cílová zóna aplikace by měla mít vlastní skupiny a přiřazení rolí. Nevytvádejte obecné skupiny a přiřaďte je k více cílovým zónám. Tento přístup může vést k chybné konfiguraci a narušení zabezpečení a je obtížné ho spravovat ve velkém měřítku. Pokud jeden uživatel vyžaduje přístup k více cílovým zónám, přiřaďte je příslušným skupinám v každé cílové zóně. Ke správě členství ve skupině použijte zásady správného řízení ID.

• Přiřaďte role skupinám, ne uživatelům. Tento přístup pomáhá zajistit, aby uživatelé měli správná oprávnění, když se připojí nebo opustí vaši organizaci. Pomáhá také zajistit, aby uživatelé měli správná oprávnění při přechodu mezi týmy. Pokud se například uživatel přesune ze síťového týmu do týmu zabezpečení, měli byste je odebrat ze skupiny sítě a přidat je do skupiny zabezpečení. Pokud roli přiřadíte přímo uživateli, po přesunu do jiného týmu ji zachovají. Pomocí zásad správného řízení ID můžete místo ručního přidávání a odebírání členů skupiny spravovat členství ve skupinách.

• Udržujte samostatné konfigurace zabezpečení pro různá prostředí stejné aplikace, jako je vývoj/testování a produkce. Vytvořte samostatné skupiny a přiřazení rolí pro každé prostředí. Nesdílejte spravované identity ani instanční objekty napříč prostředími. Zacházet s každým prostředím jako s samostatnou cílovou zónou. Tento přístup pomáhá zajistit izolaci mezi vývojem/testováním a produkčním prostředím a standardizuje proces přesunu nasazení aplikací mezi prostředími. Pokud stejný jednotlivec vyžaduje přístup k několika cílovým zónám, měli byste je přiřadit příslušným skupinám v každé cílové zóně.

• Zvažte, jestli správci platformy vyžadují oprávnění pro cílové zóny aplikací. Pokud ano, použijte Microsoft Entra PIM k řízení přístupu k těmto prostředkům a přiřaďte požadovaná nejméně privilegovaná oprávnění. Správce platformy může například vyžadovat přístup ke konkrétní cílové zóně aplikace k řešení potíží, ale neměl by mít rutinní přístup k datům nebo kódu aplikace. V takovém případě může správce platformy požádat o přístup k aplikaci. Správce privilegovaných rolí žádost schválí a správce platformy má udělená požadovaná oprávnění pro zadané časové období. Tento přístup pomáhá vynucovat oddělení povinností a chrání cílové zóny aplikací před náhodnou nebo škodlivou chybnou konfigurací.

• Když delegujete administrativní odpovědnost ostatním, jako jsou aplikační týmy, zvažte, jestli vyžadují úplnou sadu oprávnění nebo jenom podmnožinu. Dodržujte princip nejnižší úrovně oprávnění. Můžete například přiřadit role user Accessu Správa istrator nebo RBAC Správa istratoru uživateli, který potřebuje spravovat přístup k prostředkům Azure, ale ne spravovat samotné prostředky. Pokud chcete omezit identity, typy identit a role, ke kterým můžou delegovat a přiřazovat přiřazení Azure RBAC, použijte delegovaná přiřazení rolí s podmínkami. Podmínky umožňují týmům aplikací spravovat vlastní objekty zabezpečení v rámci omezení, která tým platformy nastaví. Vyšší přiřazení privilegovaných rolí vyžadují eskalaci týmu platformy.

• Následující tabulka ukazuje ukázkovou strukturu přiřazení rolí pro prostředí cílové zóny Azure. Poskytuje rovnováhu mezi zabezpečením a snadnou správou. Strukturu můžete přizpůsobit požadavkům vaší organizace. Stejný jednotlivec můžete přiřadit více skupinám v závislosti na jejich roli v organizaci. Přiřazení RBAC byste ale měli použít u konkrétní skupiny v rámci konkrétní cílové zóny.

  Prostředek	Uživatelská	Přiřazení role	Cíl přiřazení	Obor přiřazení
  Cílová zóna X aplikace	Vlastníci X aplikací	Vlastník aplikace (vlastní, zahrnutý v akcelerátoru cílových zón Azure)	Application X Admins skupina zabezpečení	Produkční a vývojová a testovací předplatná aplikace X
  Cílová zóna X aplikace	Vlastníci X aplikací	Application Access Správa istrator (vlastní, s podmínkami přiřazení role pro správu přístupu k vlastní aplikaci)	Application X Admins skupina zabezpečení	Produkční a vývojová a testovací předplatná aplikace X
  Cílová zóna X aplikace	Správce dat X aplikace	Data Správa istrator (vlastní, s oprávněními k požadovaným datovým prostředkům)	Application X Data Team skupina zabezpečení	Produkční a vývojová a testovací předplatná aplikace X
  Cílová zóna Y aplikace	Vlastníci aplikací Y	Vlastník aplikace (vlastní, zahrnutý v akcelerátoru cílových zón Azure)	Application Y Admins skupina zabezpečení	Produkční a testovací předplatná Y aplikací
  Cílová zóna Y aplikace	Tým pro testování aplikací Y	Přispěvatel testů (vlastní s oprávněními vyžadovanými pro testování aplikací)	Application Y Test Team skupina zabezpečení	Předplatné pro vývoj/testování aplikace Y
  Sandbox	Vývojový tým application Z	Vlastník (integrovaný)	Application Z developers skupina zabezpečení	Skupiny prostředků Z aplikace v předplatném sandboxu
  Prostředky platformy	Tým pro správu platformy	Přispěvatel (integrovaný)	Platform Admins Skupina PIM	Platform skupina pro správu
  Cílové zóny platformy	Tým pro správu platformy	Čtenář (integrovaný)	Platform Team skupina zabezpečení	Organizační skupina pro správu nejvyšší úrovně
  Pro celého tenanta	Bezpečnostní tým	Operace zabezpečení (vlastní, zahrnuté v akcelerátoru cílových zón Azure)	Security Ops skupina zabezpečení	Organizační skupina pro správu nejvyšší úrovně
  Pro celého tenanta	Bezpečnostní tým	Podmíněný přístup Správa istrator (integrovaný s povolenými chráněnými akcemi)	Security administrators skupina zabezpečení	Tenant Microsoft Entra ID
  Pro celého tenanta	Síťový tým	Síťové operace (vlastní, zahrnuté v akcelerátoru cílových zón Azure)	Network Ops skupina zabezpečení	Všechna předplatná
  Pro celého tenanta	Tým FinOps	Čtenář fakturace (integrovaný)	FinOps Team skupina zabezpečení	Organizační skupina pro správu nejvyšší úrovně

• Přiřazení azure Policy s tímto účinkem DeployIfNotExistsvyžadují spravovanou identitu k nápravě nekompatibilních prostředků. Pokud používáte spravovanou identitu přiřazenou systémem jako součást procesu přiřazení azure Policy, Azure automaticky udělí požadovaná oprávnění. Pokud používáte spravovanou identitu přiřazenou uživatelem, musí být oprávnění udělena ručně. Přiřazení rolí spravované identity musí dodržovat zásadu nejnižší úrovně oprávnění a umožňovat pouze oprávnění požadovaná k provedení nápravy zásad v cílovém oboru. Spravované identity pro nápravu zásad nepodporují vlastní definice rolí. Přiřazení rolí použijte přímo u spravovaných identit, ne pro skupiny.

Doporučení Microsoft Entra PIM

• Použijte Microsoft Entra PIM k zajištění souladu s modelem nulová důvěra (Zero Trust) a přístupem s nejnižšími oprávněními. Korelujte role vaší organizace s minimálními potřebnými úrovněmi přístupu. V Microsoft Entra PIM můžete použít nativní nástroje Azure, rozšířit stávající nástroje a procesy nebo podle potřeby používat existující i nativní nástroje.

• Pomocí kontrol přístupu Microsoft Entra PIM pravidelně ověřte nároky na prostředky. Kontroly přístupu jsou součástí mnoha architektur dodržování předpisů, takže mnoho organizací už má zavedený proces kontroly přístupu.

• Používejte privilegované identity pro runbooky automatizace, které vyžadují zvýšená přístupová oprávnění nebo pro kanály privilegovaného nasazení. Pomocí stejných nástrojů a zásad můžete řídit automatizované pracovní postupy, které přistupují k důležitým hranicím zabezpečení, které používáte k řízení uživatelů s ekvivalentními oprávněními. Kanály automatizace a nasazení pro aplikační týmy by měly mít přiřazení rolí, které brání vlastníkovi aplikace v eskalaci vlastních oprávnění.

• Řízení vysoce privilegovaných rolí Azure RBAC, jako jsou role Vlastník nebo Uživatelský přístup Správa istrátory přiřazené členům týmu cílové zóny platformy nebo aplikace v předplatném nebo skupině pro správu. Ke konfiguraci rolí Azure RBAC použijte Nástroj Microsoft Entra PIM pro skupiny , aby vyžadoval stejný proces zvýšení oprávnění jako role ID Microsoft Entra.

  Uživatel může například rutinně vyžadovat omezený přístup správce k prostředkům v cílové zóně aplikace. Někdy můžou vyžadovat roli Vlastník. Můžete vytvořit dvě skupiny zabezpečení: aplikační Správa istrátory a vlastníky aplikací. Přiřaďte role s nejnižšími oprávněními ke skupině Správa istrators aplikace a přiřaďte roli vlastníka k roli Vlastníci aplikace. Použijte skupiny PIM, aby uživatel mohl v případě potřeby požádat o roli Vlastník. V ostatních případech má uživatel jenom oprávnění potřebná k provádění obvyklých aktivit.

• Pomocí chráněných akcí s Microsoft Entra PIM můžete přidat další vrstvy ochrany. V Microsoft Entra ID jsou chráněné akce oprávnění přiřazené zásadami podmíněného přístupu. Když se uživatel pokusí provést chráněnou akci, musí nejprve splňovat zásady podmíněného přístupu, které jsou přiřazeny k požadovaným oprávněním. Pokud například chcete správcům povolit aktualizaci nastavení přístupu mezi tenanty, můžete vyžadovat, aby nejprve splňovali zásady vícefaktorového ověřování odolné proti útokům phishing.

Správa identit a přístupu v akcelerátoru cílových zón Azure

Správa identit a přístupu jsou základními funkcemi implementace akcelerátoru cílových zón Azure. Nasazení zahrnuje předplatné vyhrazené pro identitu, ve kterém mohou organizace nasazovat řadiče domény SLUŽBY AD DS nebo jiné služby identit, jako jsou servery Microsoft Entra Připojení, které jsou pro jejich prostředí potřeba. Ne všechny organizace vyžadují služby v předplatném. Některé organizace můžou mít například aplikace, které jsou již plně integrované s Microsoft Entra ID.

Předplatné identity má virtuální síť, která je v předplatném platformy v partnerském vztahu s virtuální sítí centra. Díky této konfiguraci může tým platformy spravovat předplatné identity a vlastníci aplikací mají podle potřeby přístup ke službám identit. Abyste ochránili služby identit před neoprávněným přístupem, musíte zabezpečit předplatné identity a virtuální síť.

Implementace akcelerátoru cílových zón Azure zahrnuje také možnosti:

• Přiřaďte doporučené zásady pro řízení identit a řadičů domény.
• Vytvořte virtuální síť a připojte se k centru prostřednictvím partnerského vztahu virtuálních sítí.

Další kroky

Správa identit aplikací a přístupu