角色在中间做什么？
把一组工作权限归到角色，再把角色分配给用户。NIST 的 RBAC 模型让访问经由角色发生，便于集中维护；直接给个人的例外授权不属于这个纯角色链条。[1]
067 / 身份与访问 / RBAC
拿了两串钥匙，就该同时使用吗？
RBAC 基于角色的访问控制 · RBAC
小珊既有编辑资格，也有发布资格。今天这次会话能不能两者都启用？再把目标换成海藻组的笔记：角色相同，为什么结果仍会不同？
开始探索 ↓8–12 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
上方人物分出蓝、金、绿三串钥匙，下方客服、财务和维修角色打开各自图案的柜门，其他柜门挂着红叉。钥匙串比喻角色权限；图片没有画出会话激活和职责分离，实验会补上这两道检查。
本课任务 / RBAC 基于角色的访问控制
沿用户、已分配角色、会话激活角色和权限追踪授权，再核对额外的资源边界。
- 读懂用户—角色—权限的两层关系
- 区别分配资格、激活集合与动态职责分离
- 核对角色之外的对象和组边界
亲手探索 / 不同条件，不同结果
先检查这串角色能否激活，再看钥匙能开哪扇门。
为小珊、小海或小林提出本次激活的角色集合，选择读取、修改或发布，并切换珊瑚组／海藻组笔记。未分配角色或编辑者与发布者同启会使整个激活方案失败；同组限制是额外的固定业务规则。
随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
先画两张关系表
分别列用户获分配的角色、每个角色包含的动作。本例读者只给读取，编辑者只给修改，发布者只给发布；没有隐含“高级角色自动拥有低级角色”的继承，角色名不能替代权限表。[1]
02 / 实用细节
激活集合不能超出用户的资格
服务端应从可信记录获取角色分配，拒绝未被分配的激活请求。本例先校验整个集合；若夹带了一个无资格角色，不会悄悄用其余角色继续，而是显示激活失败。[1][2]
03 / 实用细节
角色组合也需要审查
多个有效角色可能合并出更大的能力范围。这里禁止同一会话同时激活编辑者和发布者；但先编辑、换一次会话再发布仍未被排除。需要制单与复核分人时，还应记录对象历史并核对操作者关系。[1]
04 / 实用细节
角色通过后，继续检查对象范围
获得读取角色，不等于可以读取所有组的笔记。本例在角色权限之后另查用户与笔记是否同组；真实多租户、所有者或委托关系应写成明确的资源规则，不能只做一个角色名判断。[2]
05 / 实用细节
角色变更要追到实际访问结果
转岗时复查旧角色，修改角色权限时评估所有受影响成员。还需检查既有会话、缓存或令牌中的旧权限何时失效；仅更新管理表，并不证明所有请求已经采用新规则。[2][3]
06 / 实用细节
让权限矩阵成为回归用例
为每个角色、动作和资源准备允许与拒绝案例，再加入未分配角色、冲突组合和跨组请求。本实验是固定会话模型，真实系统应在接口及实际副作用上核对结果，避免只检查菜单可见性。[2]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
客服有查询角色，是否就能查询任意客户资料？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- NIST · Role Based Access Control FAQ ↗
角色分配、会话激活、层级及静态／动态职责分离
- Microsoft Entra PIM · Activate Roles ↗
特定产品中角色变化与应用权限缓存的传播边界
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。