用途：为 Azure 安全主体选择符合最小权限原则的 RBAC 角色，或审查现有分配是否权限过高。不适用于 Entra ID 目录角色、Microsoft 365 管理员角色、PIM 激活或访问评审设计，也不用于多云权限管理。
主要能力：区分控制面（管理资源：创建、删除、列出、配置）与数据面（读写资源内容：blob、密钥、队列消息、表行），并据此匹配最具体的内置角色。控制面角色不会自动授予数据面权限，例如 Reader 只能看到存储账户存在，不能读取 blob；读取 blob 内容需 Storage Blob Data Reader。仅当无内置角色可用时才创建自定义角色，限制 Actions/DataActions 与 NotActions，并固定可分配作用域。
使用方式：先以动词加资源类型精确列出所需操作，如“读取容器 X 中的 blob 内容”；用 az role definition show 核对所选内置角色的 Actions/DataActions 是否完全覆盖且无多余权限。作用域按资源 > 资源组 > 订阅 > 管理组逐级优先，能在单容器就不要放到存储账户或订阅。用户优先通过 Entra 组分配，工作负载优先使用托管标识而非带密钥的服务主体。对 Owner、User Access Administrator、宽作用域 Contributor 及订阅级写入的自定义角色，应配合 PIM 做即时激活、MFA 与时限控制；对特权作用域定期开展季度访问评审，清理未使用分配。
限制与反模式：Owner 包含授予访问权限的能力，需严格限制，很少是正确答案；等待权限不应以 Owner 解决数据面问题；不应为单个额外操作 Fork 内置角色；避免订阅级逐用户分配；避免自动化服务主体使用订阅级 Owner/Contributor；避免长期常驻特权；若无访问评审机制权限不会自动收紧。自定义角色是维护负担，Microsoft 动作目录变更可能破坏它们，因此优先使用内置角色。参考资料包括 Microsoft Learn 的 RBAC 概览、内置角色、自定义角色、最佳实践、角色分配及存储数据面授权文档。