通过

Microsoft Entra ID 中应用程序属性的安全最佳做法

在 Microsoft Entra ID 中注册某个应用程序时，安全性是非常重要的概念，并且是该应用程序在组织中发挥业务作用时至关重要的考虑因素。 以任何不当方式配置应用程序都可能导致停机或机密透露。 根据添加到应用程序的权限，可能会产生组织范围的影响。

由于安全的应用程序对于组织极其重要，安全问题导致应用程序停机可能会影响业务或业务所依赖的某些关键服务。 因此，分配时间和资源来确保应用程序始终处于正常且安全的状态非常重要。 请定期对应用程序进行安全和运行状况评估，这与代码的安全威胁模型评估非常类似。 若要更广泛地了解组织的安全性，请参阅安全开发生命周期 (SDL)。

本文介绍以下应用程序属性和方案的安全最佳做法：

  • 标识类型
  • 资格证书
  • 重定向 URI
  • 隐式流配置
  • 应用程序 ID URI（也称为标识符 URI）
  • 访问令牌版本
  • 应用程序实例锁
  • 应用程序所有权

标识类型

你可能在这里了解 Microsoft Entra 应用程序 （也称为应用注册或应用对象）的安全最佳做法。 但是，有另一种标识类型可用于访问受 Entra 保护的资源，称为 Azure 资源的托管标识。

默认情况下，Azure 托管标识是安全的，无需持续维护或开销。 如果以下所有条件均为真，请考虑使用托管身份，而不是为应用标识使用 Microsoft Entra 应用程序：

  • 该服务在 Azure 云中运行
  • 应用不需要登录用户
  • 应用不需要充当令牌流中的资源（不是 Web API）
  • 应用不需要在多个租户中运行

请注意，托管标识 可用于 访问 Azure 外部的资源，包括 Microsoft Graph。

本文的其余部分介绍 Entra 应用注册属性的安全最佳做法。

凭据（包括证书和机密）

凭据是应用程序用作机密客户端时的重要部分。 在 Azure 门户中应用程序的 “证书和机密 ”页下，可以添加或删除凭据。

该屏幕截图显示了“证书和机密”所在位置。

考虑以下有关证书和机密的指导：

  • 尽可能使用 托管标识 作为凭据。 强烈建议这样做，因为托管标识既是最安全的选项，也不需要任何正在进行的凭据管理。 按照 本指南 将托管标识配置为凭据。 但是，仅当应用在 Azure 上运行的服务时，才能使用此选项。
  • 如果应用所使用的服务未在 Azure 上运行，但确实在提供自动凭据管理的另一个平台上运行，请考虑 使用该平台中的标识作为凭据。 例如，可以将 GitHub Actions 工作流配置为凭据，而无需管理和保护 GitHub Actions 操作流水线的凭据。 请谨慎使用此方法，并仅从信任的平台配置联合凭据。 应用的安全性仅与它配置为凭据的标识平台一样高。
  • 如果无法使用托管标识或其他安全的外部标识提供者，请使用 证书凭据。 不要使用密码凭据，也称为 机密。 虽然使用密码机密作为凭据很方便，但密码凭据通常管理不当，并且很容易泄露。
  • 如果必须使用证书而不是托管标识，请将该证书存储在安全密钥保管库中，例如 Azure Key Vault。
  • 如果必须使用证书而不是托管标识，请使用来自受信任的证书颁发机构（CA）而不是自签名证书的证书。 配置策略 以强制证书来自受信任的颁发者。 但是，如果无法使用受信任的 CA，则自签名证书仍优先于密码。
  • 配置 应用程序管理策略 ，通过限制机密的生存期或完全阻止其使用来控制机密的使用。
  • 如果应用程序仅用作公共或已安装的客户端（例如，在最终用户计算机上安装的移动或桌面应用），请确保应用程序对象上没有指定的凭据。
  • 查看应用程序中所用凭据的新旧程度和过期时间。 应用程序上未使用的凭据可能会导致安全漏洞。 经常变换凭据，并且不要在多个应用程序之间共享凭据。 不要在一个应用程序中使用许多凭据。
  • 监视生产管道，防止将任何类型的凭据提交到代码存储库中。 凭据扫描程序是一种静态分析工具，可用于检测源代码和生成输出中的凭据（和其他敏感内容）。

重定向 URI

将应用程序重定向 URI 保持在最新状态很重要。 在 Azure 门户中应用程序的“身份验证”下，必须为应用程序选择一个平台，然后才能定义“重定向 URI”属性。

该屏幕截图显示了“重定向 URI”属性所在位置。

考虑以下有关重定向 URI 的指导：

  • 保留所有 URI 的所有权。 一个重定向 URI 的所有权失误就可能导致应用程序泄露。
  • 确保定期更新所有 DNS 记录并监视其是否有更改。
  • 不要使用通配符回复 URL 或不安全的 URI 方案，例如 http 或 URN。
  • 使列表保持较小。 剪裁任何不必要的 URI。 如果可能，请将 URL 从 Http 更新为 Https。

隐式流配置

需要隐式流的方案现可使用身份验证代码流，以降低与隐式流滥用相关的泄露风险。 在 Azure 门户中应用程序的“身份验证”下，必须为应用程序选择一个平台，然后才能设置“访问令牌（用于隐式流）”属性。

该屏幕截图显示了“隐式流属性”所在位置。

考虑以下有关隐式流的指导：

  • 了解是否需要隐式流。 除非明确要求，否则不要使用隐式流。
  • 如果应用程序已配置为使用隐式流接收访问令牌，但未主动使用它们，请关闭该设置以防止误用。
  • 对有效的隐式流方案使用单独的应用程序。

应用程序 ID URI（也称为标识符 URI）

应用程序的“应用程序 ID URI”属性指定用于标识 Web API 的全局唯一 URI。 它是向 Microsoft Entra 发出请求时范围值的前缀。 它也是 v1.0 访问令牌中受众 (aud) 声明的值。 对于多租户应用程序，该值也必须全局唯一。 它也称为标识符 URI。 在 Azure 门户中为应用程序“公开 API”下，可以定义“应用程序 ID URI”属性。

该屏幕截图显示了“应用程序 ID URI”所在位置。

定义应用程序 ID URI 更改的最佳做法，具体取决于应用是否颁发了 v1.0 或 v2.0 访问令牌。 如果不确定应用是否颁发 v1.0 访问令牌，请检查应用清单的 requestedAccessTokenVersion。 值 null 或 1 指示应用接收 v1.0 访问令牌。 2 值指示应用接收 v2.0 访问令牌。

对于颁发 v1.0 访问令牌的应用程序，应仅使用默认 URI。 默认 URI 为 api://<appId> 和 api://<tenantId>/<appId>。 - 配置nonDefaultUriAddition应用程序管理策略中的限制，以强制实施此最佳做法，以便将来对组织中的应用程序进行更新。

对于颁发 v2.0 访问令牌的应用程序，在定义应用 ID URI 时使用以下准则：

  • 建议使用 api 或 https URI 方案。 用支持的格式设置该属性，以避免组织中发生 URI 冲突。 不要使用通配符。
  • 使用组织的已验证域。
  • 在组织中保留 URI 的清单以帮助维持安全性。

支持以下基于 API 和 HTTP 方案的应用程序 ID URI 格式。 替换表后列表中描述的占位符值。

支持的应用程序 ID
URI 格式		 示例应用 ID URI
api://<appId> api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId> api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string> https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string> https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain> https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string> https://product.contoso.com/productsapi
api://<string>.<verifiedCustomDomainOrInitialDomain>/<string> api://contoso.com/productsapi
  • <appId> - 应用程序对象的应用程序标识符 (appId) 属性。
  • <string> - 主机或 api 路径段的字符串值。
  • <tenantId> - Azure 生成的 GUID，用于表示 Azure 中的租户。
  • <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com，其中 <tenantInitialDomain> 是租户创建者在创建租户时指定的初始域名。
  • <verifiedCustomDomain> - 为 Microsoft Entra 租户配置的已验证自定义域。

注意

如果使用 api:// 方案，则直接在“api://”之后添加一个字符串值。 例如，api://<string>。 该字符串值可以是 GUID 或任意字符串。 如果添加 GUID 值，值必须与应用 ID 或租户 ID 匹配。 如果使用字符串值，则必须使用已验证的自定义域或租户的初始域。 建议使用 api://< appId>。

重要说明

应用程序 ID URI 值不能以斜杠“/”字符结尾。

重要说明

应用程序 ID URI 值在租户中必须是唯一的。

访问令牌版本

本部分仅适用于资源应用程序 - 即充当访问令牌中受众的应用程序。 资源应用程序通常是 Web API。 如果应用程序仅充当客户端（这意味着它获取令牌以发送到 Microsoft Graph 等资源），则本部分不适用。

配置自定义 标识符 URI 的资源应用程序应使用 v2.0 访问令牌格式。 若要检查应用是否应使用 v2.0 访问令牌，请查看 identifierUris 应用 的应用注册清单页 中的属性。

清单编辑器中标识符 URI 修改体验的屏幕截图。

如果配置有任何不是api://{appId}或api://{tenantId}/{appId}格式的值，那么应用应该使用v2.0访问令牌。

若要升级到 v2.0 访问令牌，请先确保应用可以处理 v2.0 令牌声明。 然后，使用清单编辑器更新应用程序颁发的访问令牌版本。

更新令牌版本体验的屏幕截图。

将应用程序配置更新为使用 v2.0 令牌后，确保修改应用程序的受众验证逻辑以仅接受其 appId。

应用程序实例属性锁

当应用程序将服务主体预配到租户中时，租户管理员可以自定义该服务主体。无论该租户是应用程序的主租户还是外国租户，都是如此。 这些自定义功能可以允许应用所有者不需要的修改，从而导致安全风险。 例如，可以将凭据添加到服务主体，即使凭据通常应由应用程序开发人员和所有者拥有和控制。

为了降低此风险，应用程序应 配置应用实例锁。 配置应用实例锁时，请始终锁定可用的每个敏感属性。 配置此属性对于多租户应用程序（这意味着在多个租户或组织中使用的应用程序）尤其重要，但可以且应该由所有应用程序设置。

权限

可能需要向应用程序授予访问受保护资源或 API 的权限。 请求权限时，请始终确保以下内容：

  • 遵循 最低特权 原则。 仅请求授予应用程序执行操作所需的最低限度权限。 如果调用 Microsoft Graph，请使用 API 文档 标识给定 API 调用的最低宽松权限。 定期查看应用的权限，以检查是否可用权限较低的选项。 如果应用不再需要权限，请将其删除。
  • 尽可能使用 委派访问 ，而不是 仅应用访问。
  • 查看 权限和许可 文档，确保了解权限基础知识。

应用所有权配置

所有者可以管理已注册的应用程序的各个方面。 定期评审组织中所有应用程序的所有权非常重要。 有关详细信息，请参阅 Microsoft Entra 访问评审。 在 Azure 门户中应用程序的“所有者”下，可以管理应用程序的所有者。

该屏幕截图显示了应用程序“所有者”管理位置。

考虑以下与指定应用程序所有者相关的指导：

  • 应用程序所有权应保留给组织中的极少数人。
  • 管理员应每隔几个月评审一次所有者列表，以确保所有者仍在组织中任职，并且仍然应该拥有某个应用程序。

检查 Entra 建议

Microsoft Entra 建议功能可帮助监控租户的状态，而无需你自己执行。 这些建议有助于确保租户处于安全和正常运行状态，同时有助于最大限度地发挥 Microsoft Entra ID 中可用功能的价值。 定期检查与应用属性或应用配置相关的任何活动 Microsoft Entra 建议，以保持您的应用生态系统的健康状态。