生成代理标识蓝图时,有两个与密钥权限相关的配置: 所需的资源访问 和 可继承的权限。 这些配置协同工作,定义代理需要的内容、管理员在同意期间查看的内容,以及权限如何流向代理标识。
了解这些配置之间的关系以及它们如何影响授权对于设计代理蓝图的开发人员和将代理加入其组织的管理员至关重要。
所需的资源访问
所需的资源访问是代理标识蓝图对 API 的初始声明,以及蓝图的子代理标识需要运行的权限。 它表现为一组目标资源应用程序,以及代理所请求的特定委托范围和应用程序角色。
所需的资源访问充当代理的静态许可权限列表。 当租户管理员审核代理以供批准时,此列表使同意决策清晰明确且可供审核。 它回答了以下问题: “此代理需要什么功能?
动态同意在显式请求权限时仍然可以授予继承的权限,前提是资源应用被配置为可继承。 但是,除非在所需的资源访问中也声明了动态请求的权限,否则不会提前显示这些权限。
所需资源访问的主要特征:
- 声明代理初始体验所需的基线权限集。
- 在同意和启用过程中,租户管理员可以看到。
- 是声明,而不是权限授予。 授权需要管理员同意。
可继承的权限
可继承权限是在代理标识蓝图上配置的资源应用列表,用于定义哪些权限可由从该蓝图创建的代理标识自动继承。 当管理员向代理标识蓝图主体授予权限并且这些权限来自列为可继承的资源应用时,组织中从该蓝图创建的所有现有和将来的代理标识都会使用令牌自动接收这些权限。
可继承的权限解决了常见的部署难题:如果跨环境或业务部门拥有同一代理的多个实例,则不希望管理员重新同意每个代理标识上的相同权限。 可继承的权限允许管理员在蓝图级别进行一次权限批准,并使该审批自动生效。
继承的两个条件
代理身份要继承权限,必须满足以下 两个 条件:
- 必须在代理标识蓝图的可继承权限配置中 列出资源范围、角色或两者 。
- 必须授予以下权限:
- 使用 必需的资源访问的静态同意,或
- 动态同意,并在同意请求中明确声明权限。
如果任一条件缺失,则不会发生继承。
可继承的权限包括
可继承的权限支持两者:
-
委派范围:显示在代理的委托应用程序权限访问令牌
scp声明中。 -
应用程序角色:出现在代理的应用程序许可令牌
roles声明中。
继承模式
每个资源应用都支持以下模式:
| 图案 | 说明 |
|---|---|
| 全部允许 | 继承指定资源应用的所有可用委派范围或应用程序角色。 蓝图主体上新授予的范围或角色会自动包含。 |
| 没有 | 不继承指定资源应用的作用域或角色。 使用此模式可以单独禁用范围或角色的继承。 |
可以在同一资源应用上独立配置范围和角色。 例如,可以选择继承所有作用域但不继承任何角色,或者反之亦然。
声明、授予和继承
所需的资源访问和可继承权限是 配置:它们不会自行授予任何授权。 请务必了解声明的内容、授予的内容和继承的内容之间的区别。
| 层 | 它是什么 | 控制它的人员 | Effect |
|---|---|---|---|
| 所需的资源访问 | 代理需要正常运行的 API 和权限列表 | 蓝图上的开发人员 | 在许可评审期间对管理员可见。 不授予访问权限。 |
| 可继承的权限 | 符合继承条件的资源应用列表 | 蓝图上的开发人员 | 定义哪些资源应用可以将权限传递到代理身份。 不授予访问权限。 |
| 对蓝图主要内容的同意 | 管理员授予租户中蓝图主体的权限 | 租户管理员 | 授予授权。 如果资源应用也列为可继承应用,则权限将流向所有代理标识。 |
| 用户或代理对代理身份的同意 | 直接授予特定代理标识的权限 | 租户管理员 | 仅向该特定代理标识授予授权。 |
| 令牌中的有效权限 | 已合并的继承权限与直接授予权限的集合 | 令牌发行时的平台 | 代理标识在运行时实际上可以执行的操作。 |
注释
继承的权限在Microsoft Entra管理中心的代理身份或通过Microsoft Graph上都不可见。 它们只能在运行时的令牌内容中观察到。 平台在令牌颁发期间合并继承的权限和直接授予的权限。
权限配置备忘单
使用以下快速规则:
- 蓝图级别的静态许可取决于该权限是否在所需的资源访问权限中。
- 即使权限不在所需的资源访问中,蓝图级别的动态同意仍然可以工作,但是必须明确请求权限。
- 代理标识的继承取决于资源应用是否配置为可继承。
- 前期可见性取决于权限是否被列为所需资源访问权限。
静态同意(蓝图主体)
| 访问所需资源时需要权限吗? | 资源应用是可继承的? | 代理身份继承? | 管理员可以看到吗? |
|---|---|---|---|
| Yes | Yes | Yes | Yes |
| Yes | No | No | Yes |
| No | Yes | No | No |
| No | No | No | No |
动态同意(蓝图原则,明确请求的权限)
| 访问所需资源时需要权限吗? | 资源应用是可继承的? | 代理身份继承? | 管理员可以看到吗? |
|---|---|---|---|
| Yes | Yes | Yes | Yes |
| Yes | No | No | Yes |
| No | Yes | Yes | No |
| No | No | No | No |
在所有情况下,对代理标识的直接同意仍然可用,但这些授权仅适用于该特定代理标识。
最佳做法
为代理蓝图配置所需的资源访问和可继承权限时,请平衡安全性、可用性和将来的可伸缩性。
最大程度地减少前期权限。 仅在必要的资源访问中包含对代理核心功能至关重要的资源。 在安装时请求不必要的权限会增加摩擦,并减少与租户管理员的信任。
预声明潜在的未来权限。 在可继承的权限列表中指定将来的代理功能可能需要的资源应用。 这种透明度使管理员能够预测未来的同意请求,并有助于跨环境进行更流畅的部署。
使用可继承的权限来提高可重用性。 使用可继承的权限让管理员在蓝图级别授予同意一次,并让审批自动应用于所有代理标识,包括跨多个部署和环境。 如果您需要一个权限,最好使其资源应用具有可继承性,这样管理员就不必单独向每个代理身份授予权限。
保持治理简单且可预测。 显式定义需要哪些权限,稍后可能会请求哪些权限可帮助组织保持明确的访问控制,并避免意外的权限升级。
审查安全影响。 确保可继承的权限不会授予过多的访问权限或公开超出必要条件的敏感资源。 定期审核权限列表,以维护合规性并最大程度地降低风险。
示例方案
以下方案说明了不同的权限配置如何满足不同的部署需求。
方案 1:代理具有稍后需要权限的可选功能
Priya 正在构建一个 IT 技术支持代理,用于回答知识库中的问题。 Priya 希望客户以后启用可选操作,例如创建事件或发布到 Teams。 Priya 将所需的访问权限设定得非常低或留为空白。 她定义代理在可继承的权限列表中使用的资源应用。 当她的公司启用操作功能时,管理员对蓝图主体授予所需的权限一次,并且该批准将重新用于所有部署。
方案 2:代理需要事先应可继承的权限
Mateo 正在构建一个新的员工加入代理,该代理需要Microsoft Graph访问权限来读取用户配置文件和创建任务。 Mateo 列出了所需的资源访问权限中的基线 Graph 权限,并将 Graph 资源应用添加到可继承的权限列表。 当他的公司向多个业务部门推出代理时,管理员评审是一致的:每次请求相同的权限,可继承的指定会减少重复审批工作量。
方案 3:代理需要不可继承的权限
Lin 正在构建由一小组管理员用来执行敏感任务的特权操作代理。 代理需要立即拥有高特权权限。 Lin 在所需的资源访问中包含这些内容,但有意不会将它们添加到可继承的权限列表中。 对于她的公司,每次安装都需要一个新的明确的管理员决策,从而减少权限扩散,确保高特权访问的安全性。
方案 4:代理需要不同组织中的不同权限
Aisha 正在构建合规证据收集代理。 某些租户需要从Microsoft 365的审核来源拉取数据,其他租户则需要从SharePoint站点拉取数据。 Aisha 在所需的资源访问中定义一个小核心集,并在可继承权限列表中列出可能资源的完整菜单。 每个组织仅授予与其体系结构匹配的权限,可继承的方法可减少推出期间的重复审批。