Doporučené osvědčené postupy pro spravované identity

Spravované identity v Azure poskytují bezpečný a pohodlný způsob správy přihlašovacích údajů pro aplikace běžící na prostředcích Azure. Tento článek popisuje doporučení osvědčených postupů pro výběr mezi spravovanými identitami přiřazenými uživatelem a systémem a pomáhá optimalizovat správu identit a snížit režijní náklady na správu.

Výběr spravovaných identit přiřazených systémem nebo uživatelem

Spravované identity přiřazené uživatelem jsou efektivnější v širším rozsahu scénářů než spravované identity přiřazené systémem. V následující tabulce naleznete některé scénáře a doporučení, zda použít přiřazení uživatelem nebo systémem.

Identity přiřazené uživatelem můžou používat více prostředků a jejich životní cykly jsou oddělené od životních cyklů prostředků, ke kterým jsou přidružené. Přečtěte si, které prostředky podporují spravované identity.

Tento životní cyklus umožňuje oddělit povinnosti spojené s vytvářením prostředků a správou identit. Identity přiřazené uživatelem a jejich přiřazení rolí je možné nakonfigurovat předem u prostředků, které je vyžadují. Uživatelé, kteří vytvářejí prostředky, vyžadují přístup pouze k přiřazení identity přiřazené uživatelem, aniž by museli vytvářet nové identity nebo přiřazení rolí.

Protože identity přiřazené systémem jsou vytvořeny a odstraněny současně s prostředkem, nelze předem vytvořit přiřazení rolí. Tato posloupnost může způsobit selhání při nasazování infrastruktury, pokud uživatel, který vytváří prostředek, nemá také přístup k vytváření přiřazení rolí.

Pokud vaše infrastruktura vyžaduje, aby více prostředků vyžadovalo přístup ke stejným prostředkům, můžete jim přiřadit jednu identitu přiřazenou uživatelem. Režijní náklady na správu se snižují, protože ke správě existuje méně jedinečných identit a přiřazení rolí.

Pokud požadujete, aby měl každý prostředek svou vlastní identitu, nebo máte prostředky, které vyžadují jedinečnou sadu oprávnění a chcete, aby se identita odstranila při odstranění prostředku, měli byste použít identitu přiřazenou systémem.

Scénář	Doporučení	Poznámky
Rychlé vytváření prostředků (například dočasné výpočetní prostředí) se spravovanými identitami	Identita přiřazená uživatelem	Pokud se pokusíte vytvořit několik spravovaných identit v krátkém časovém intervalu – například nasazení několika virtuálních počítačů s vlastní identitou přiřazenou systémem – můžete překročit limit rychlosti pro vytváření objektů Microsoft Entra a požadavek selže s chybou HTTP 429. Pokud se prostředky vytvářejí nebo odstraňují rychle, můžete také překročit limit počtu prostředků v ID Microsoft Entra, pokud používáte identity přiřazené systémem. I když odstraněná identita přiřazená systémem už není přístupná žádným prostředkem, stále se počítá do vašeho limitu, dokud nebude po 30 dnech zcela odstraněna. Nasazení prostředků přidružených k jedné identitě přiřazené uživatelem vyžaduje vytvoření pouze jednoho služebního principálu v ID Microsoft Entra, aby se předešlo překročení limitu rychlosti. Použití jedné identity vytvořené předem snižuje riziko zpoždění replikace, ke kterým může dojít v případě, že se vytvoří více prostředků s vlastní identitou. Přečtěte si další informace o limitech služby předplatného Azure.
Replikované prostředky nebo aplikace	Identita přiřazená uživatelem	Prostředky, které provádějí stejnou úlohu – například duplicitní webové servery nebo identické funkce spuštěné ve službě App Service a v aplikaci na virtuálním počítači – obvykle vyžadují stejná oprávnění. Když použijete stejnou identitu přiřazenou uživatelem, vyžaduje se méně přiřazení rolí, což snižuje režii na správu. Prostředky nemusí být stejného typu.
Kompatibilita	Identita přiřazená uživatelem	Pokud vaše organizace vyžaduje, aby všechna vytváření identit prošla procesem schvalování, vyžaduje použití jedné identity přiřazené uživatelem napříč více prostředky méně schválení než identity přiřazené systémem, které se vytvářejí při vytváření nových prostředků.
Vyžaduje se přístup před nasazením prostředku.	Identita přiřazená uživatelem	Některé prostředky můžou v rámci nasazení vyžadovat přístup k určitým prostředkům Azure. V tomto případě nemusí být vytvořená identita přiřazená systémem včas, takže by se měla použít existující identita přiřazená uživatelem.
Auditní protokolování	Systémem přiřazená identita	Pokud potřebujete protokolovat konkrétní prostředek, který provedl nějakou akci, a ne identitu, použijte identitu přiřazenou systémem.
Správa životního cyklu oprávnění	Systémem přiřazená identita	Pokud potřebujete, aby se oprávnění k prostředku odebrala spolu s prostředkem, použijte identitu přiřazenou systémem.

Použití identit přiřazených uživatelem ke snížení správy

Diagramy znázorňují rozdíl mezi identitami přiřazenými systémem a identitami přiřazenými uživatelem, pokud se používá k tomu, aby několik virtuálních počítačů mohlo přistupovat ke dvěma účtům úložiště.

Diagram znázorňuje čtyři virtuální počítače s identitami přiřazenými systémem. Každý virtuální počítač má stejné přiřazení rolí, které jim udělí přístup ke dvěma účtům úložiště.

Pokud je identita přiřazená uživatelem přidružená ke čtyřem virtuálním počítačům, vyžadují se v porovnání s osmi identitami přiřazenými systémem pouze dvě přiřazení rolí. Pokud identita virtuálních strojů vyžaduje více přiřazení rolí, budou přiřazeny všem prostředkům přidruženým k této identitě.

Skupiny zabezpečení lze použít také ke snížení počtu požadovaných přiřazení rolí. Tento diagram znázorňuje čtyři virtuální počítače s identitami přiřazenými systémem, které byly přidány do bezpečnostní skupiny, přičemž přiřazení rolí byla přidána do skupiny místo k identitám přiřazeným systémem. I když je výsledek podobný, tato konfigurace nenabízí stejné možnosti šablony Resource Manageru jako identity přiřazené uživatelem.

Více spravovaných identit

Prostředky, které podporují spravované identity, můžou mít identitu přiřazenou systémem i jednu nebo více identit přiřazených uživatelem.

Tento model poskytuje flexibilitu pro použití sdílené identity přiřazené uživatelem a použití podrobných oprávnění v případě potřeby.

V následujícím příkladu má virtuální počítač 3 a Virtuální počítač 4 přístup k účtům úložiště i trezorům klíčů v závislosti na tom, kterou identitu přiřazenou uživatelem používá při ověřování.

V následujícím příkladu má virtuální počítač 4 identitu přiřazenou uživatelem, která jí dává přístup k účtům úložiště i trezorům klíčů v závislosti na tom, která identita se používá při ověřování. Přiřazení rolí pro identitu přiřazenou systémem jsou specifická pro tento virtuální počítač.

Omezení

Podívejte se na limity pro spravované identity a pro vlastní role a přiřazení rolí.

Při udělování přístupu dodržujte zásadu nejnižšího oprávnění.

Při udělování jakékoli identity, včetně spravované identity, oprávnění pro přístup ke službám, vždy udělte nejnižší oprávnění potřebná k provedení požadovaných akcí. Pokud se například spravovaná identita používá ke čtení dat z účtu úložiště, není nutné, aby tato oprávnění identita umožňovala také zapisovat data do účtu úložiště. Udělení dalších oprávnění, například když se ze spravované identity udělá přispěvatel v předplatném Azure, pokud to není nutné, zvyšuje bezpečnostní riziko spojené s identitou. Vždy je nutné minimalizovat rozsah dopadu bezpečnostního ohrožení, aby ohrožení identity způsobilo minimální poškození.

Zvažte dopady přiřazení spravovaných identit k prostředkům Azure a/nebo udělení oprávnění uživateli pro přiřazení těchto identit.

Je důležité si uvědomit, že když je prostředku Azure, jako je aplikace logiky Azure nebo virtuální počítač, přiřazená spravovaná identita, jsou teď všechna oprávnění udělená spravované identitě k dispozici pro prostředek Azure. To je důležité, protože pokud má uživatel přístup k instalaci nebo spuštění kódu v tomto prostředku, má uživatel přístup ke všem identitám přiřazeným nebo přidruženým k prostředku Azure. Účelem spravované identity je poskytnout kódu běžícímu na prostředku Azure přístup k jiným prostředkům, aniž by vývojáři museli zpracovávat nebo vkládat přihlašovací údaje přímo do kódu, aby tento přístup získali.

Pokud je například spravované identitě (ClientId = 1234) udělen přístup pro čtení a zápis pro StorageAccount7755 a je přiřazena LogicApp3388, pak Alice, kdo nemá přímý přístup k účtu úložiště, ale má oprávnění ke spouštění kódu v rámci LogicApp3388 může také číst a zapisovat data do a z StorageAccount7755 spuštěním kódu, který používá spravovanou identitu.

Podobně pokud má Alice oprávnění k přiřazení spravované identity sama, může ji přiřadit jinému prostředku Azure a mít přístup ke všem oprávněním dostupným pro spravovanou identitu.

Obecně platí, že při udělování přístupu správce uživatele k prostředku, který může spouštět kód (například aplikaci logiky) a má spravovanou identitu, zvažte, jestli role přiřazená uživateli může nainstalovat nebo spustit kód na prostředku, a pokud ano, přiřaďte tuto roli pouze v případě, že ji uživatel skutečně potřebuje.

Údržba

Identity přiřazené systémem se automaticky odstraní při odstranění prostředku, zatímco životní cyklus identity přiřazené uživatelem je nezávislý na všech prostředcích, ke kterým je přidružen.

Identitu přiřazenou uživatelem je potřeba odstranit ručně, i když už není potřeba, i když k ní nejsou přidružené žádné prostředky.

Přiřazení rolí se při odstranění spravovaných identit přiřazených systémem nebo přiřazených uživatelem automaticky neodstraní. Tato přiřazení rolí by se měla ručně odstranit, aby se nepřekročil limit přiřazení rolí na předplatné.

Přiřazení rolí, která jsou přidružená k odstraněným spravovaným identitám, se při zobrazení na portálu zobrazí s hláškou "Identita nenalezena". Další informace.

Přiřazení rolí, která již nejsou přidružená k uživateli nebo principálu služby, se zobrazí s hodnotou ObjectTypeUnknown. Abyste je mohli odebrat, můžete řadit několik příkazů Azure PowerShellu, abyste nejprve získali všechna přiřazení rolí, vyfiltrovali je jenom na ty s ObjectType hodnotou Unknown a pak je z Azure odebrali.

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

Omezení používání spravovaných identit pro autorizaci

Použití skupin ID Microsoft Entra pro udělení přístupu ke službám je skvělým způsobem, jak zjednodušit proces autorizace. Myšlenka je jednoduchá – udělte skupině oprávnění a přidejte do ní identity tak, aby dědily stejná oprávnění. Jedná se o dobře zavedený model z různých místních systémů a funguje dobře, když identity představují uživatele. Další možností řízení autorizace v MICROSOFT Entra ID je použití rolí aplikací, které umožňují deklarovat role specifické pro aplikaci (nikoli skupiny, což je globální koncept v adresáři). Potom můžete přiřadit role aplikací spravovaným identitám (i uživatelům nebo skupinám).

V obou případech, u identit, které nejsou lidského původu, jako jsou aplikace Microsoft Entra a spravované identity, není současný mechanismus prezentace těchto informací o autorizaci aplikaci ideálně uzpůsoben. Dnešní implementace s Microsoft Entra ID a Řízením přístupu na základě role Azure (Azure RBAC) používá pro ověřování každé identity přístupové tokeny vydané microsoftem Entra ID. Pokud je identita přidána do skupiny nebo role, je to vyjádřeno jako nároky v přístupovém tokenu vydaném Microsoft Entra ID. Azure RBAC tyto deklarace identity používá k dalšímu vyhodnocení autorizačních pravidel pro povolení nebo odepření přístupu.

Vzhledem k tomu, že skupiny a role identity jsou tvrzeními v přístupovém tokenu, žádné změny autorizace se neprojeví, dokud se token neaktualizuje. Pro běžného uživatele to obvykle není problém, protože si může získat nový přístupový token odhlášením a opětovným přihlášením (nebo počkáním, až vyprší platnost tokenu, což je ve výchozím nastavení 1 hodina). Tokeny spravované identity jsou naopak ukládány v mezipaměti základní infrastruktury Azure pro účely výkonu a odolnosti: služby na pozadí pro spravované identity udržují mezipaměť pro URI prostředků po dobu přibližně 24 hodin. To znamená, že může trvat několik hodin, než se změny ve skupině nebo členství role spravované identity projeví. Dnes není možné vynutit aktualizaci tokenu spravované identity před vypršením jeho platnosti. Pokud změníte členství ve skupině nebo roli spravované identity a přidáte nebo odeberete oprávnění, budete proto muset několik hodin počkat, než prostředek Azure pomocí identity bude mít správný přístup.

Pokud toto zpoždění není pro vaše požadavky přijatelné, zvažte alternativy k používání skupin nebo rolí v tokenu. Pokud chcete zajistit, aby se změny oprávnění pro spravované identity projevily rychle, doporučujeme seskupit prostředky Azure pomocí spravované identity přiřazené uživatelem s oprávněními použitými přímo na identitu, místo abyste přidávali nebo odebírali spravované identity ze skupiny Microsoft Entra, která má oprávnění. Spravovanou identitu přiřazenou uživatelem je možné použít jako skupinu, protože může být přiřazena k jednomu nebo více prostředkům Azure pro její použití. Operaci přiřazení je možné řídit pomocí role přispěvatele spravované identity a operátora spravované identity.