你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
应用程序标识和访问管理
本文介绍应用程序所有者和开发人员可用于设计云原生应用程序的标识和访问管理的注意事项和建议。
如果团队迁移或创建云原生应用程序，则必须考虑应用程序的身份验证和访问要求。 这些要求确定用户如何向应用程序进行身份验证，以及应用程序资源如何相互进行身份验证，例如 Web 应用程序访问 SQL 数据库时。
在平台自动化和 DevOps 设计区域中，我们建议应用程序团队将工作负荷转换为订阅自动售货。 作为订阅销售过程的一部分，应用程序团队需要向平台团队提供标识和访问要求，以便他们可以创建相应的订阅。 应用程序所有者负责各个应用程序的标识和访问管理。 他们应使用平台团队提供的集中式服务来管理其应用程序。
设计注意事项
为了帮助降低未经授权访问应用程序的风险，请将以下注意事项合并到设计中。
有多种身份验证和授权标准，例如 OAuth 2.0、OpenID Connect、JSON Web 令牌（JWT）和 SAML（安全断言标记语言）。 确定要用于应用程序的身份验证和授权标准。
从平台团队请求应用程序登陆区域时，可以通过询问以下问题来帮助确保它们创建适当的订阅：
最终用户如何对应用程序进行身份验证和访问？
谁需要应用程序使用的资源和服务的基于角色的访问控制（RBAC）权限？
现有内置角色是否涵盖控制平面和数据平面访问的 RBAC 访问要求，或者是否需要创建新的自定义角色？
平台团队是否实现了可能导致应用程序问题的任何合规性策略？
哪些应用程序组件需要相互通信？
访问在平台登陆区域中部署的共享资源（如 Microsoft Entra 域服务）是否有任何要求？
Azure 密钥库和托管标识
公有云资源的安全漏洞通常源自嵌入在代码或其他文本中的泄露凭据。 可以使用托管标识和密钥库实现编程访问，并帮助降低凭据被盗的风险。
如果应用程序或工作负荷要求服务安全地存储凭据，可以使用密钥库来管理机密、密钥和证书。
为了避免在代码中使用凭据，可以将托管标识与 Azure VM 配合使用，向支持 Microsoft Entra ID 身份验证的任何服务进行身份验证。 有关详细信息，请参阅 在 VM 上使用 Azure 资源的托管标识来获取访问令牌。
托管标识 提供应用程序和资源连接到支持Microsoft Entra ID 身份验证的资源时使用的自动托管标识主体。 应用程序可以使用托管标识来 获取Microsoft Entra ID 令牌，而无需管理任何凭据。
可以使用 系统分配的或用户分配的托管标识。
很容易混淆服务主体和托管标识访问 Azure 资源的方式。 若要了解这两者之间的差异，请参阅 “揭秘服务主体” - 托管标识。
尽可能使用托管标识来支持身份验证，而不是使用服务主体和Microsoft Entra ID 应用注册。 必须具有应用程序管理员或应用程序开发人员 RBAC 角色才能创建服务主体和应用注册。 这些特权角色通常分配给平台团队或标识团队。 使用托管标识无需平台团队为应用程序团队创建服务主体和应用注册。
可以使用托管标识向支持 Microsoft Entra 身份验证的任何服务进行身份验证。 但是，并非所有服务都支持托管标识来访问其他服务。 对于某些服务，可能需要存储凭据。 应安全地存储凭据，避免与其他服务共享凭据，并遵循最低特权原则。 有关详细信息，请参阅 可以使用托管标识访问其他服务的 Azure 服务。
可以将托管标识与 Azure 虚拟机（VM）配合使用，向支持Microsoft Entra ID 身份验证的任何服务进行身份验证。 有关详细信息，请参阅 在 VM 上使用 Azure 资源的托管标识来获取访问令牌。
在订阅和区域之间移动具有托管标识的资源存在限制。 例如，出于数据主权原因，可以在订阅或区域之间移动资源，以便合并、收购或遣返资源。
如果 Azure 资源具有用户分配的标识或系统分配的标识，则无法将资源传输到另一个 Azure 订阅或区域。 移动资源之前，必须先删除托管标识。 移动后，必须重新创建托管标识并将其分配给资源。 有关详细信息，请参阅将资源移到新资源组或订阅。
如果将订阅从一个目录移到另一个目录，则不会保留托管标识。 必须移动资源，然后 手动重新创建托管标识。
与用户 RBAC 角色分配类似，在向资源授予托管标识访问权限时， 遵循最低特权 原则。
外部用户
可以评估涉及设置外部用户、客户或合作伙伴的方案，以便他们可以访问资源。 确定这些方案是否涉及 Microsoft Entra B2B 或 Azure Active Directory B2C （Azure AD B2C） 配置。 有关详细信息，请参阅Microsoft Entra 外部 ID概述。
设计建议
设计应用程序的标识和访问管理时，请考虑以下建议。
OpenID Connect
如果应用程序团队使用持续集成和持续交付（CI/CD）管道以编程方式部署应用程序，请将 OpenID Connect 身份验证配置为 Azure 服务。 OpenID Connect 使用临时的无凭据令牌向 Azure 服务进行身份验证。 有关详细信息，请参阅 工作负荷标识联合。
如果不支持 OpenID Connect，请创建服务主体并分配必要的权限以允许部署基础结构或应用程序代码。 有关详细信息，请参阅训练模块， 使用服务主体对 Azure 部署管道进行身份验证。
基于属性的访问控制
若要进一步限制访问并防止未经授权的数据访问，请使用受支持的基于属性的访问控制（ABAC），例如使用Azure Blob 存储。
虚拟机访问
如果可能，请使用 Microsoft Entra ID 标识来控制对 Azure 虚拟机的访问。 使用 Microsoft Entra ID 而不是本地身份验证来提供对虚拟机的访问权限，并利用 Microsoft Entra 条件访问、审核日志记录和Microsoft Entra 多重身份验证（MFA）。 此配置可降低攻击者利用不安全的本地身份验证服务的风险。 有关详细信息，请参阅 使用 Microsoft Entra ID 和 OpenSSH 登录到 Azure 中的 Linux 虚拟机，并使用 Microsoft Entra ID（包括无密码）登录到 Azure 中的 Windows 虚拟机。
Microsoft 标识平台
开发人员生成云原生应用程序时，应使用适用于开发人员的 Microsoft 标识平台作为其应用程序的标识提供者。 Microsoft 标识平台提供了符合 OpenID Connect 标准的身份验证服务，开发人员可以使用该服务对多种标识类型进行身份验证，包括：
通过 Microsoft Entra ID 预配的工作或学校帐户
个人 Microsoft 帐户（Skype、Xbox、Outlook.com）
社交或本地帐户，使用 Microsoft Entra ID
Microsoft 标识平台最佳做法和建议清单提供了有关将应用程序与Microsoft 标识平台有效集成的指南。
托管标识
若要在不需要使用凭据的 Azure 资源之间启用访问，请使用托管标识。
不应在各种环境或应用程序之间共享凭据或托管标识。 例如，不要将标识用于生产资源，也不在开发/测试资源中使用，即使对于同一应用程序也是如此。 为应用程序的每个实例创建单独的凭据，以减少影响生产数据的测试实例遭到入侵的可能性。 单独的凭据还可以更轻松地在不再需要凭据时撤销凭据。
当需要大规模使用托管标识时，请为每个区域中的每个资源类型使用用户分配的托管标识。 此方法可防止更改标识。 例如，Azure Monitor 代理需要受监视的 Azure VM 上的托管标识，这可能会导致Microsoft Entra ID 创建（并删除）大量标识。 可以创建用户分配的托管标识一次，并在多个 VM 之间共享它们。 使用 Azure Policy 实现此建议。
密钥保管库
可以使用密钥库来管理应用程序使用的机密、密钥、证书。
若要 管理 对机密（数据平面）和管理访问（控制平面）的访问，请使用 RBAC。
若要控制应用程序对密钥库的访问，请使用托管标识。
应在每个区域为每个应用程序环境（开发、预生产、生产）使用单独的密钥保管库。 使用 RBAC 管理对机密、密钥和证书（数据平面操作）的访问，以及对密钥库（控制平面）的访问。 将具有应用程序机密的密钥保管库部署到应用程序登陆区域。
Microsoft Entra 应用程序代理
若要通过 Microsoft Entra ID 远程访问使用本地身份验证的应用程序，请使用 Microsoft Entra 应用程序代理。 Microsoft Entra 应用程序代理提供对本地 Web 应用程序（包括使用较旧身份验证协议的应用程序）的安全远程访问。 单一登录 Microsoft Entra ID 后，用户可以通过外部 URL 或内部应用程序门户访问云和本地应用程序。
可以将 Microsoft Entra 应用程序代理部署为单个实例，并将其部署到 Microsoft Entra ID 租户中。 配置至少需要应用程序管理员特权Microsoft Entra ID 角色。 如果你的组织使用订阅民主化作为角色分配模型，则应用程序所有者可能没有配置 Microsoft Entra 应用程序代理所需的权限。 在这种情况下，平台团队应为应用程序所有者配置 Microsoft Entra 应用程序代理。
如果使用具有足够权限的 CI/CD 部署管道，则应用程序所有者可以使用 Microsoft 图形 API 来配置 Microsoft Entra 应用程序代理。
如果应用程序使用旧协议（如 Kerberos），请确保应用程序登陆区域与Microsoft 标识平台订阅中的域控制器建立网络连接。