Správa identit aplikací a přístupu

Tento článek popisuje aspekty a doporučení, které můžou vlastníci a vývojáři aplikací použít k návrhu správy identit a přístupu pro aplikace nativní pro cloud.

Pokud váš tým migruje nebo vytváří aplikace nativní pro cloud, musíte zvážit požadavky na ověřování a přístup pro aplikace. Tyto požadavky určují, jak se uživatelé ověřují v aplikacích a jak se prostředky aplikací navzájem ověřují, například když webová aplikace přistupuje k databázi SQL.

V oblasti automatizace platformy a návrhu DevOps doporučujeme, aby váš tým aplikací přepísl úlohy na správa předplatného. V rámci procesu prodejního nasazení předplatného musí váš aplikační tým poskytnout požadavkům na identitu a přístup pro tým platformy, aby mohl vytvořit příslušná předplatná. Vlastníci aplikací zodpovídají za správu identit a přístupu jednotlivých aplikací. Měli by spravovat svou aplikaci pomocí centralizovaných služeb, které poskytuje tým platformy.

Aspekty návrhu

Pokud chcete snížit riziko neoprávněného přístupu k vašim aplikacím, začleníte do návrhu následující aspekty.

• Existuje několik ověřovacích a autorizačních standardů, jako jsou OAuth 2.0, OpenID Připojení, webové tokeny JSON (JWT) a SAML (Security Assertion Markup Language). Určete, které standardy ověřování a autorizace se mají použít pro vaši aplikaci.

• Když požádáte o cílovou zónu aplikace od týmu platformy, můžete jim pomoct zajistit, aby vytvořili příslušná předplatná tím, že jim položíte následující otázky:

  • Jak se koncoví uživatelé budou ověřovat a přistupovat k aplikaci?

  • Kdo potřebuje oprávnění řízení přístupu na základě role (RBAC) pro prostředky a služby, které aplikace používá?

  • Pokrývají stávající předdefinované role požadavky na přístup RBAC pro řídicí rovinu i přístup k rovině dat, nebo potřebujete vytvořit nové vlastní role?

  • Implementoval tým platformy nějaké zásady dodržování předpisů, které by mohly způsobit problémy s aplikací?

  • Které komponenty aplikace musí vzájemně komunikovat?

  • Existují nějaké požadavky pro přístup ke sdíleným prostředkům, jako je například Microsoft Entra Domain Services, které jsou nasazené v cílové zóně platformy?

Azure Key Vault a spravované identity

• Porušení zabezpečení prostředků veřejného cloudu často pocházejí z uniklých přihlašovacích údajů, které jsou vložené do kódu nebo jiného textu. Pomocí spravovaných identit a služby Key Vault můžete implementovat programový přístup a snížit riziko krádeže přihlašovacích údajů.

• Pokud vaše aplikace nebo úloha vyžaduje službu pro bezpečné ukládání přihlašovacích údajů, můžete ke správě tajných klíčů, klíčů a certifikátů použít službu Key Vault.

• Abyste se vyhnuli přihlašovacím údajům ve vašem kódu, můžete použít spravované identity s virtuálními počítači Azure k ověření ve všech službách, které podporují ověřování Microsoft Entra ID. Další informace najdete v tématu Použití spravovaných identit pro prostředky Azure na virtuálním počítači k získání přístupového tokenu.

• Spravované identity poskytují automaticky spravovaný objekt identity, který aplikace a prostředky používají při připojování k prostředkům, které podporují ověřování Microsoft Entra ID. Aplikace můžou používat spravované identity k získání tokenů ID Microsoft Entra bez nutnosti spravovat přihlašovací údaje.

  • Můžete použít spravované identity přiřazené systémem nebo přiřazené uživatelem.

  • Je snadné si zmást, jak instanční objekty a spravované identity přistupují k prostředkům Azure. Pokud chcete porozumět rozdílu mezi těmito dvěma objekty, přečtěte si téma Demystifikace instančních objektů – spravované identity.

  • Pokud je to možné, používejte spravované identity k podpoře ověřování místo použití instančních objektů a registrací aplikací Microsoft Entra ID. Abyste mohli vytvářet instanční objekty a registrace aplikací, musíte mít role Application Správa istrator nebo Application Developer RBAC. Tyto privilegované role se obvykle přiřazují týmu platformy nebo týmu identit. Pomocí spravovaných identit odstraňte potřebu týmu platformy vytvářet instanční objekty a registrace aplikací pro váš aplikační tým.

  • Spravované identity můžete použít k ověření ve všech službách, které podporují ověřování Microsoft Entra. Ne všechny služby však podporují spravované identity pro přístup k jiným službám. U některých služeb může být nutné uložit přihlašovací údaje. Měli byste bezpečně ukládat přihlašovací údaje, vyhnout se sdílení přihlašovacích údajů s jinými službami a dodržovat zásadu nejnižších oprávnění. Další informace najdete v tématu Služby Azure, které můžou používat spravované identity pro přístup k jiným službám.

  • Spravované identity s virtuálními počítači Azure můžete použít k ověření ve všech službách, které podporují ověřování Microsoft Entra ID. Další informace najdete v tématu Použití spravovaných identit pro prostředky Azure na virtuálním počítači k získání přístupového tokenu.

  • Existují omezení přesunu prostředků se spravovanými identitami mezi předplatnými a oblastmi. Můžete například přesunout prostředky mezi předplatnými nebo oblastmi pro sloučení, získání nebo opakování prostředků z důvodů suverenity dat.

    Pokud má prostředek Azure identity přiřazené uživatelem nebo systémem, nemůžete prostředek přenést do jiného předplatného nebo oblasti Azure. Před přesunutím prostředku je nutné odstranit spravované identity. Po přesunu je nutné znovu vytvořit spravované identity a přiřadit je k prostředku. Další informace najdete v tématu, které se zabývá přesunutím prostředků do nové skupiny prostředků nebo předplatného.

  • Pokud přesunete předplatné z jednoho adresáře do jiného, spravované identity se nezachovají. Prostředek musíte přesunout a potom ručně znovu vytvořit spravované identity.

  • Podobně jako přiřazení rolí RBAC uživatele se při udělování spravované identity k prostředku řídí principem nejnižšího oprávnění .

Externí uživatelé

Můžete vyhodnotit scénáře, které zahrnují nastavení externích uživatelů, zákazníků nebo partnerů, aby měli přístup k prostředkům. Určete, jestli tyto scénáře zahrnují konfigurace Microsoft Entra B2B nebo Azure Active Directory B2C (Azure AD B2C ). Další informace najdete v tématu Přehled Microsoft Entra Externí ID.

Doporučení k návrhu

Při návrhu správy identit a přístupu aplikací zvažte následující doporučení.

OpenID Connect

Pokud váš aplikační tým k programovému nasazování aplikací používá kanály kontinuální integrace a průběžného doručování (CI/CD), nakonfigurujte ověřování OpenID Připojení pro služby Azure. OpenID Připojení používá k ověřování ve službách Azure dočasný token bez přihlašovacích údajů. Další informace najdete v tématu Federace identit úloh.

Pokud se openID Připojení nepodporuje, vytvořte instanční objekt a přiřaďte potřebná oprávnění k povolení nasazení kódu infrastruktury nebo aplikace. Další informace najdete v modulu trénování, ověření kanálu nasazení Azure pomocí instančních objektů.

Řízení přístupu na základě atributů

Pokud chcete dále omezit přístup a zabránit neoprávněnému přístupu k datům, použijte řízení přístupu na základě atributů (ABAC), pokud je to podporované, například se službou Azure Blob Storage.

Přístup k virtuálním počítačům

Pokud je to možné, použijte identity Microsoft Entra ID k řízení přístupu k virtuálním počítačům Azure. Místo místního ověřování použijte ID Microsoft Entra, abyste mohli poskytovat přístup k virtuálním počítačům, využívat podmíněný přístup Microsoft Entra, protokolování auditu a vícefaktorové ověřování Microsoft Entra (MFA). Tato konfigurace snižuje riziko zneužití nezabezpečených místních ověřovacích služeb. Další informace najdete v tématu Přihlášení k virtuálnímu počítači s Linuxem v Azure pomocí Microsoft Entra ID a OpenSSH a přihlášení k virtuálnímu počítači s Windows v Azure pomocí Microsoft Entra ID včetně bez hesla.

Microsoft identity platform

• Když vývojáři vytvářejí nativní cloudovou aplikaci, měli by pro své aplikace používat Microsoft identity platform pro vývojáře jako zprostředkovatele identity. Platforma Microsoft Identity Platform poskytuje openID Připojení ověřovací službu vyhovující standardu, kterou můžou vývojáři použít k ověřování několika typů identit, mezi které patří:

  • Pracovní nebo školní účty zřízené prostřednictvím MICROSOFT Entra ID

  • Osobní účty Microsoft (Skype, Xbox, Outlook.com)

  • Sociální nebo místní účty s využitím ID Microsoft Entra

• Kontrolní seznam osvědčených postupů a doporučení platformy Microsoft Identity Platform poskytuje pokyny k efektivní integraci aplikace s platformou Microsoft Identity Platform.

Spravované identity

• Pokud chcete povolit přístup mezi prostředky Azure, které nepotřebují používat přihlašovací údaje, použijte spravované identity.

• Přihlašovací údaje ani spravované identity byste neměli sdílet mezi různými prostředími nebo aplikacemi. Nepoužívejte například identity pro produkční prostředky a také v prostředcích pro vývoj/testování, a to ani pro stejnou aplikaci. Vytvořte pro každou instanci aplikace samostatné přihlašovací údaje, abyste snížili pravděpodobnost ohrožení testovací instance ovlivňující produkční data. Samostatné přihlašovací údaje také usnadňují odvolání přihlašovacích údajů, když už nejsou potřeba.

• Pokud je potřeba používat spravované identity ve velkém měřítku, použijte spravovanou identitu přiřazenou uživatelem pro každý typ prostředku v každé oblasti. Tento přístup brání četnosti změn identit. Agent Azure Monitor například vyžaduje spravovanou identitu na monitorovaných virtuálních počítačích Azure, což může způsobit, že Microsoft Entra ID vytvoří (a odstraní) velký počet identit. Spravované identity přiřazené uživatelem můžete vytvořit jednou a sdílet je napříč několika virtuálními počítači. K implementaci tohoto doporučení použijte Azure Policy .

Key Vault

• Key Vault můžete použít ke správě tajných kódů, klíčů, certifikátů, které aplikace používají.

  • Ke správě přístupu k tajným kódům (rovina dat) a pro správu (rovina řízení) použijte RBAC.

  • Pokud chcete řídit přístup aplikace ke službě Key Vault, použijte spravované identity.

• Pro každé prostředí aplikace (vývoj, předprodukční prostředí, produkční prostředí) byste měli použít samostatné trezory klíčů. Použití RBAC ke správě přístupu k tajným klíčům, klíčům a certifikátům (operacím roviny dat) a přístupu ke službě Key Vault (rovina řízení). Nasaďte trezory klíčů, které mají tajné kódy aplikací do cílových zón aplikace.

Proxy aplikace Microsoft Entra

• Pokud chcete získat přístup k aplikacím, které používají místní ověřování vzdáleně prostřednictvím ID Microsoft Entra, použijte proxy aplikace Microsoft Entra. Proxy aplikace Microsoft Entra poskytuje zabezpečený vzdálený přístup k místním webovým aplikacím, včetně aplikací, které používají starší ověřovací protokoly. Po jednotném přihlašování k Microsoft Entra ID mají uživatelé přístup ke cloudovým i místním aplikacím prostřednictvím externí adresy URL nebo interního portálu aplikací.

  • Proxy aplikace Microsoft Entra můžete nasadit jako jednu instanci do tenanta Microsoft Entra ID. Konfigurace vyžaduje Správa istrator nebo globální Správa istrator s privilegovanými rolemi ID Microsoft Entra. Pokud vaše organizace používá demokratizaci předplatného jako model přiřazení rolí, vlastníci aplikací nemusí mít potřebná oprávnění ke konfiguraci proxy aplikací Microsoft Entra. V tomto případě by tým platformy měl nakonfigurovat proxy aplikace Microsoft Entra pro vlastníka aplikace.

  • Pokud používáte kanály nasazení CI/CD s dostatečnými oprávněními, můžou vlastníci aplikací nakonfigurovat proxy aplikace Microsoft Entra pomocí rozhraní Microsoft Graph API.

• Pokud aplikace používá starší protokoly, například Kerberos, ujistěte se, že cílová zóna aplikace má síťové připojení k řadičům domény v předplatném Microsoft Identity Platform.

Další kroky

Organizace prostředků