azure-role-selector

Azure 角色选择器（RBAC 最小权限）

Azure RBAC 通过角色分配授予访问权限 = 安全主体 + 角色定义 + 范围。目标是实现最小权限：在满足需求的前提下，使用范围最窄的最低权限角色，并分配给正确类型的主体（人类用户使用组，工作负载使用托管标识）；对于特权角色，通过 PIM 限定使用时长。

适用场景

为用户、组、服务主体或托管标识选择正确的角色，或检查现有分配是否存在过多权限。

以下情况请勿使用此技能：

• Entra ID 目录角色（全局管理员、用户管理员等）（使用 entra-id）
• Microsoft 365 管理员角色（使用 m365-govern-manage）
• 激活特权角色或设计访问评审（使用 azure-pim）
• 多云授权管理（使用 entra-permissions-management）

选择正确的角色系列

调用方需要……	查看	避免
读取存储帐户属性	控制平面：读取者 / 存储帐户参与者	所有者
读取Blob 内容	数据平面：存储 Blob 数据读取者	仅使用读取者（无法访问数据）
写入Blob 内容	数据平面：存储 Blob 数据参与者	所有者 / 参与者
读取 Key Vault 机密（RBAC 模式）	数据平面：Key Vault 机密用户	Key Vault 管理员
管理 Key Vault 本身	控制平面：Key Vault 参与者	所有者
使用托管标识运行 Azure Function	仅在目标资源上分配数据角色	订阅参与者
将角色分配权限委派给他人	在最小范围内分配用户访问管理员	所有者
读取订阅中的所有内容	在订阅范围内分配读取者	所有者 / 参与者
仅管理一个资源组	在资源组范围内分配参与者	订阅参与者

经验法则：控制平面角色不会自动授予数据平面访问权限。 读取者可以查看某个存储帐户的存在，但不能读取 Blob。请明确选择正确的平面。这是最常见的 RBAC 错误。

方法

1. 精确定义所需操作——列出主体必须执行的确切操作。区分控制平面（管理资源：创建、删除、列出、配置）和数据平面（读取或写入资源内部的数据：Blob、机密、队列消息、行）。 验证：需求应以动词和资源类型描述，例如“读取容器 X 中的 Blob 内容”，而不是“访问存储”。
2. 匹配最具体的内置角色——优先选择其 Actions 和 DataActions 涵盖所需操作的最具体内置角色。内置角色由 Microsoft 维护，并会随着服务功能的增加而演进。除非确有需要，否则避免使用宽泛的角色（Owner、Contributor）。 验证：所选内置角色的 Actions/DataActions 涵盖所有所需操作，且不包含其他权限（使用 az role definition show）。
3. 决定使用自定义角色还是内置角色——只有在没有合适的内置角色时，才创建自定义角色。定义最小化的 Actions/DataActions 和 NotActions，将 JSON 纳入源代码管理，并固定可分配的范围。 验证：确认没有内置角色满足需求后，才创建自定义角色；JSON 已存入仓库并具有变更历史。
4. 尽可能缩小范围——在满足需求的最低有效范围分配角色：资源 > 资源组 > 订阅 > 管理组。在单个容器上分配 Storage Blob Data Reader，比在存储帐户上分配更安全；在存储帐户上分配，又比在订阅上分配更安全。 验证：分配范围是满足需求的最小范围；标记针对单个资源授予的整个订阅范围权限。
5. 优先使用身份和组——为用户分配到 Entra 组（而非直接分配给用户），为工作负载使用托管标识（尽可能避免使用带机密的服务主体）。基于组的分配易于扩展；按用户分配则不然。 验证：订阅范围内没有直接分配给用户的权限；工作负载使用托管标识，而非用户帐户。
6. 将 PIM 用于特权角色——对于广泛范围内的 Owner、User Access Administrator、Contributor，以及在订阅范围内具有写入权限的任何自定义角色，要求通过 PIM 激活（即时启用、MFA、适当情况下需审批、限时）。 验证：特权角色分配状态为 Eligible，而非 Active；激活需要 MFA 并生成审计日志。
7. 持续治理——每季度对特权范围进行访问审查，移除未使用的分配（通过 Entra Permissions Management 或 PIM 活动报告发现），并在所有权变更时重新进行基线评估。 验证：已记录访问审查的频率；已审查并处理未使用分配报告。

防护措施

• Owner 包含授予访问权限的能力——严格限制此角色，并且只在确实需要委派权限时才优先考虑 User Access Administrator。Owner 很少是正确的选择。
• 控制平面角色（Reader / Contributor）不会自动授予数据平面访问权限——应明确选择数据角色。对于“查看帐户并读取 Blob”，正确的组合是 Reader + Storage Blob Data Reader。
• 审查并移除未使用的分配；将高特权角色与 PIM 和访问审查配合使用。长期保留的特权会随着时间推移不断扩大攻击面。
• 自定义角色会增加维护负担——Microsoft 对操作目录的每次更改都可能导致它们失效。除非确实没有合适的内置角色，否则应选择内置角色。
• 基于组，而非基于用户。 直接分配给用户的权限难以扩展，无法在员工入职、转岗或离职时妥善处理，还会形成无人管理的权限。
• 只要目标服务支持，就应优先使用托管标识，而非带机密的服务主体——无需轮换机密，也不会发生机密泄露。
• 将范围设为满足需求的最小单位。 因为“更简单”就把角色分配到订阅范围，是一种偷懒的做法，可能演变成明年的安全事件。

常见反模式

• “他们需要 Owner，因为 Reader 无法访问 Blob 数据。” 不对——他们需要的是 Storage Blob Data Reader（数据平面）。添加 Owner 解决的是错误的问题。
• 在内置角色的基础上只增加一个操作来创建自定义角色。 不要分叉内置角色，让自己今后永远负责维护；应针对这一个操作创建后续分配。
• 在订阅范围内为每位用户分配角色。 员工入职、调岗或离职会留下孤立分配；一次审计之后，清理就会成为一项工程。
• 为自动化服务主体分配订阅级 Owner / Contributor。 影响范围等同于整个订阅。应将范围限定为资源组，并且只在目标资源上分配数据角色。
• 长期保留 Owner 角色。 如果确实需要永久分配某个角色，通常就不该是 Owner，而应是权限范围更窄的角色。如果确实需要 Owner，就必须通过 PIM 分配。
• 没有定期访问审查。 如果没有强制触发机制，权限就永远不会减少。

示例提示词

• 哪个 Azure 内置角色可以以最小权限读取 Blob 数据？
• 在这种情况下，我应该使用内置角色还是自定义角色？
• 为托管标识选择最小权限角色，以便访问特定的 Key Vault 机密。
• 如何正确限定角色分配的范围，以遵循最小权限原则？
• 将高权限 Owner 分配迁移到 PIM。

Microsoft Learn

• RBAC 概述：https://learn.microsoft.com/azure/role-based-access-control/overview
• 内置角色：https://learn.microsoft.com/azure/role-based-access-control/built-in-roles
• 自定义角色：https://learn.microsoft.com/azure/role-based-access-control/custom-roles
• RBAC 最佳实践：https://learn.microsoft.com/azure/role-based-access-control/best-practices
• 了解角色分配：https://learn.microsoft.com/azure/role-based-access-control/role-assignments
• Storage 数据平面角色：https://learn.microsoft.com/azure/storage/blobs/authorize-access-azure-active-directory