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

  • Článek

Spravované identity pro prostředky Azure jsou funkcí ID Microsoft Entra. Každá ze služeb Azure, které podporují spravované identity pro prostředky Azure, se řídí vlastní časovou osou. Než začnete, nezapomeňte zkontrolovat stav dostupnosti spravovaných identit pro váš prostředek a známé problémy.

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 najdete některé scénáře a doporučení pro 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í.

Při vytváření a odstranění identit přiřazených systémem spolu s prostředkem není možné 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 sníží, 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í Notes
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 úseku – 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. Odstraněná identita přiřazená systémem už není přístupná žádným prostředkem, ale započítá se do limitu, dokud se plně nevyprázdní po 30 dnech.

Nasazení prostředků přidružených k jedné identitě přiřazené uživatelem bude vyžadovat vytvoření pouze jednoho instančního objektu v ID Microsoft Entra, aby se zabránilo limitu rychlosti. Použití jedné identity vytvořené předem také sníží 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 schvalovacím procesem, bude použití jedné identity přiřazené uživatelem napříč několika prostředky vyžadovat méně schválení než identity přiřazené systémem, které se vytvoří 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ě se identita přiřazená systémem nemusí vytvořit včas, takže by se měla použít stávající identita přiřazená uživatelem.
Protokolování auditu 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ě.

Čtyři virtuální počítače používající identity přiřazené systémem pro přístup k účtu úložiště a trezoru klíčů.

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 počítačů vyžaduje více přiřazení rolí, udělí se všem prostředkům přidruženým k této identitě.

Čtyři virtuální počítače používající identitu přiřazenou uživatelem pro přístup k účtu úložiště a trezoru klíčů.

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 skupiny zabezpečení s přiřazením rolí přidanými do skupiny místo identit přiřazených 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.

Čtyři virtuální počítače s identitami přiřazenými systémem přidané do skupiny zabezpečení, která má přiřazení rolí.

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 mají 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í.

Čtyři virtuální počítače, dva s více identitami přiřazenými uživatelem.

V následujícím příkladu má "Virtuální počítač 4" identitu přiřazenou uživatelem a poskytuje 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č.

Čtyři virtuální počítače, jeden s identitami přiřazenými systémem i uživatelem.

Omezení

Podívejte se na limity spravovaných identit 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í potřeba povolit, aby tato oprávnění identita mohla také zapisovat data do účtu úložiště. Udělení dalších oprávnění, například vytvoření spravované identity přispěvatelem v předplatném Azure v případě, že není potřeba, zvýší poloměr výbuchu zabezpečení přidružené k identitě. Vždy je nutné minimalizovat poloměr výbuchu zabezpečení, aby ohrožení identity způsobilo minimální poškození.

Zvažte účinek přiřazování spravovaných identit k prostředkům Azure nebo udělení oprávnění k přiřazení uživateli.

Je důležité si uvědomit, že když prostředek Azure, jako je aplikace logiky Azure, funkce Azure nebo virtuální počítač atd. je přiřazená spravovaná identita, všechna oprávnění udělená spravované identitě jsou teď 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 například spravovaná identita (ClientId = 1234) má udělený přístup pro čtení a zápis k účtu StorageAccount7755 a byl přiřazen LogicApp3388, pak Alice, která nemá přímý přístup k účtu úložiště, ale má oprávnění ke spouštění kódu v LogicApp3388 může také číst a zapisovat data do/z účtu 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.

scénář zabezpečení

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 budete muset odstranit ručně, i když k ní už 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í přidružených k odstraněným spravovaným identitám se při zobrazení na portálu zobrazí s identitou nenalezena. Další informace.

Identita nebyla nalezena pro přiřazení role.

Přiřazení rolí, která již nejsou přidružená k uživateli nebo instančnímu objektu, se zobrazí s ObjectType hodnotou Unknown. 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 není pro jiné než lidské identity, jako jsou aplikace Microsoft Entra a spravované identity, přesný mechanismus, jakým jsou tyto informace o autorizaci prezentovány do aplikace, se v současné době ideálně nehodí. 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 se identita přidá do skupiny nebo role, vyjadřuje se jako deklarace identity v přístupovém tokenu vydaném ID Microsoft Entra. 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 deklaracemi identity v přístupovém tokenu, neprojeví se všechny změny autorizace, dokud se token neaktualizuje. Pro člověka, který obvykle není problém, protože uživatel může získat nový přístupový token odhlášením a opětovným přihlášením (nebo čekáním na vypršení platnosti platnosti tokenu, což je ve výchozím nastavení 1 hodina). Tokeny spravované identity jsou na druhou stranu uloženy v mezipaměti základní infrastruktury Azure pro účely výkonu a odolnosti: back-endové služby pro spravované identity uchovávají mezipaměť na identifikátor 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 použití 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 ji můžete přiřadit k jednomu nebo několika prostředkům Azure, které ho chcete použít. Operaci přiřazení je možné řídit pomocí role přispěvatele spravované identity a operátora spravované identity.