保护 Microsoft Entra ID 中的服务主体
Microsoft Entra 服务主体是租户或目录中应用程序对象的本地表示形式。 它是应用程序实例的标识。 服务主体定义应用程序访问权限，以及应用程序访问的资源。 在使用应用程序的每个租户中创建服务主体，并引用全局唯一的应用程序对象。 租户确保服务主体可登录并访问资源。
详细了解：Microsoft Entra ID 中的应用程序和服务主体对象
租户-服务主体关系
单租户应用程序在其宿主租户中只有一个服务主体。 多租户 Web 应用程序或 API 需要每个租户的服务主体。 当该租户的用户同意使用应用程序或 API 时，将创建服务主体。 此同意在多租户应用程序与其相关服务主体之间建立了一对多关系。
多租户应用程序位于一个租户中，并在其他租户中具有实例。 大多数软件即服务 (SaaS) 应用程序都支持多租户。 使用服务主体，确保在单租户和多租户方案中为应用程序及其用户提供所需的安全状况。
ApplicationID 和 ObjectID
应用程序实例具有两个属性：ApplicationID（或 ClientID）和 ObjectID。
注意
在身份验证任务中指代应用程序时，术语“应用程序”和“服务主体”可互换使用。 但是，在 Microsoft Entra ID 中，它们是应用程序的两种不同表示形式。
ApplicationID 代表全局应用程序，对于各个租户中该应用程序的实例都是一样的。 ObjectID 是应用程序对象的唯一值。 与用户、组和其他资源一样，ObjectID 有助于在 Microsoft Entra ID 中独一无二地标识应用程序实例。
若要了解详细信息，请参阅 Microsoft Entra ID 中的应用程序和服务主体关系
创建应用程序及其服务主体对象
你可以使用以下方法在租户中创建应用程序及其服务主体对象 (ObjectID)：
- Azure PowerShell
- Microsoft Graph PowerShell
- Azure 命令行接口 (Azure CLI)
- Microsoft Graph API
- Azure 门户
- 其他工具
服务主体身份验证
使用服务主体时，有两种身份验证机制：客户端证书和客户端机密。
由于证书更安全，建议尽可能使用它们。 与客户端机密不同，客户端证书不能被意外嵌入代码中。 如果可能，请使用 Azure Key Vault 进行证书和机密管理，以使用由硬件安全模块保护的密钥来加密资产：
- 身份验证密钥
- 存储帐户密钥
- 数据加密密钥
- .pfx 文件
- 密码
若要详细了解 Azure Key Vault 以及如何使用它来管理证书和机密，请参阅：
挑战和缓解措施
使用服务主体时，请使用下表来匹配挑战和缓解措施。
| 挑战 | 缓解措施 |
|---|---|
| 针对分配给特权角色的服务主体的访问评审 | 此功能处于预览阶段 |
| 服务主体访问评审 | 使用 Azure 门户手动检查资源访问控制列表 |
| 过度授权的服务主体 | 创建自动化服务帐户或服务主体时，授予对任务的权限。 评估服务主体以减少特权。 |
| 识别对服务主体凭据或身份验证方法的修改 | - 请参阅敏感操作报告工作簿 - 请参阅技术社区博客文章使用 Microsoft Entra 工作簿来帮助你评估 Solorigate 风险 |
使用服务主体查找帐户
若要查找帐户，请在 Azure CLI 或 PowerShell 中使用服务主体运行以下命令。
- Azure CLI -
az ad sp list - PowerShell -
Get-MgServicePrincipal -All:$true
有关详细信息，请参阅 Get-MgServicePrincipal
评估服务主体安全性
要评估安全性，请评估权限和凭据存储。 使用下表来帮助缓解挑战：
| 挑战 | 缓解措施 |
|---|---|
| 检测同意多租户应用的用户，并检测对多租户应用的非法同意授权 | - 运行以下 PowerShell 来查找多租户应用 Get-MgServicePrincipal -All:$true | ? {$_.Tags -eq "WindowsAzureActiveDirectoryIntegratedApp"}- 禁用用户同意 - 允许经验证的发布者提供用户同意功能，仅针对所选权限（推荐） - 在用户上下文中配置它们 - 使用其令牌触发服务主体 |
| 使用服务主体在脚本中使用硬编码共享机密 | 使用证书 |
| 跟踪使用证书或机密的用户 | 使用 Microsoft Entra 登录日志监视服务主体的登录 |
| 无法通过条件访问管理服务主体登录 | 使用 Microsoft Entra 登录日志监视登录 |
| 参与者是默认的 Azure 基于角色的访问控制 (Azure RBAC) 角色 | 评估需求，并应用尽可能少的权限 |
详细了解：什么是条件访问？
从用户帐户移动到服务主体
如果使用 Azure 用户帐户作为服务主体，请评估是否可以转为使用托管标识或服务主体。 如果不能使用托管标识，请授予某个服务主体足够的权限和作用域以便运行所需的任务。 可以通过注册应用程序或 PowerShell 来创建服务主体。
使用 Microsoft Graph 时，请查看 API 文档。 确保支持应用程序的权限类型。
请参阅创建服务主体
了解详细信息：
后续步骤
详细了解服务主体：
保护服务帐户：
条件访问：
使用条件访问来阻止来自不受信任位置的服务主体。