6.7 KiB
tags, create time
| tags | create time | ||||
|---|---|---|---|---|---|
|
2026-08-09 12:00 |
RBAC 权限模型 — 测试题
概述
本测试覆盖 RBAC 五张表设计、用户→角色→权限两层映射、超级管理员继承机制、互斥职责分离（SoD）以及动态权限加载流程。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
一、选择题（6道，由浅入深）
难度阶梯: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
Q1（基础）— 考察定义层面
RBAC 的核心思想是：
A. 直接将用户与权限绑定 B. 将用户与角色关联，而非将用户与权限直接绑定 C. 根据用户的部门自动分配所有权限 D. 基于用户的行为模式动态生成权限
Q2（基础）→
以下哪个表不是标准 RBAC 五张表中的一部分？
A. users（用户表） B. roles（角色表） C. user_roles（用户-角色关联表） D. permissions（权限表） E. role_hierarchy（角色层级表）
Q3（进阶）— 核心原理
RBAC 引入角色层相比传统 ACL（Access Control List）的最大优势是什么？
A. 权限检查更快 B. 批量授权更简单——只需改角色的权限映射不影响用户 C. 支持更多种权限码格式 D. 不需要数据库支持
Q4（进阶）— 比较/辨析
关于 RBAC 中的互斥职责分离（Separation of Duty），以下说法哪个是正确的？
A. 应该在每次鉴权时检查互斥约束 B. 应该在分配角色层校验，而不是每次鉴权时检查 C. 只在创建角色时检查一次就够了 D. SoD 只在财务系统中需要，其他系统不需要
Q5（深入）— 场景推理
某中型业务系统有约 500 个用户、20 个角色、每种角色 10~30 个权限。以下哪种部署方案最合理？
A. 简单角色 + 硬编码判断即可 B. 标准五表 RBAC + Redis 缓存（O(1) 鉴权） C. 平台型 SaaS 的每租户自定义角色 D. 只做 ACL 逐个绑定用户和权限
Q6（深入）— 源码级/边界场景
在查询某用户全部权限并展开角色继承时，如果该用户有一个 is_super = 1 的角色，函数应该返回什么？
A. 空列表表示需要进一步展开
B. 该角色的直接权限码列表
C. ["*"] 表示拥有所有权限
D. 报错"超级管理员不应直接查询权限"
二、填空题（3道）
F1 — 填空1
RBAC 五张标准表的 ER 关系是：users 多对多通过 _____ 关联到 roles；roles 多对多通过 _____ 关联到 permissions。这两个关联表是 RBAC 灵活性的关键。
提示: 回想五个表的名称。
F2 — 填空2
登录时将完整权限树缓存在_____中，鉴权接口只需 O(1) 读取缓存。权限变更时主动删除对应用户的缓存条目实现最终一致。不要每次都查库。建议 TTL 设为 _____。
提示: 第一个空填存储技术；第二个空填时间长度。
F3 — 填空3
金融类强合规系统的 RBAC 部署应包含：标准五表 RBAC + SoD 互斥约束 + 完整的_____日志。审计日志记录每次权限操作以供合规审查。
提示: 四个字的名词，描述安全相关的记录行为。
三、简答题（1道）
S1
面试官问："一个电商后台系统有以下角色需求：运营人员可以查看商品列表但不能编辑；编辑可以修改商品信息但不可删除；管理员拥有所有权限但受 SoD 限制——同一个人不能同时拥有'采购'和'审核'角色。请设计一套 RBAC 方案，包括表结构、权限码命名规范、互斥规则配置以及运行时鉴权流程。"
答题框架提示:
- 角色与权限码设计
- 互斥约束的配置方式
- 鉴权流程与缓存策略
- 异常场景处理
参考答案与解析
选择题答案
| 题号 | 正确答案 | 解析 |
|---|---|---|
| Q1 | B | RBAC 的核心是将用户与角色关联（而非直接绑定权限）。这层间接大幅降低管理复杂度——调整某个角色的权限只改一处映射，不需要遍历所有用户。 |
| Q2 | E | 标准五表是：users、roles、permissions、user_roles、role_permissions。role_hierarchy 不是独立表——原文用 parent_id 字段在 roles 表中实现层级关系。 |
| Q3 | B | ACL 的问题是批量授权需逐一修改每个用户；RBAC 只需改角色的权限映射。速度不是主要差异，灵活性才是核心价值。 |
| Q4 | B | 原文明确指出：互斥约束应在分配角色层校验，而不是每次鉴权时检查。前者是策略问题后者是执行问题——入口处挡住比到处拦击效率高得多。 |
| Q5 | B | 小型系统（<100 用户）可用硬编码；中型系统用标准五表+Redis 缓存；SaaS 需要租户隔离；ACL 不适合超过几个人的规模。500 用户属于中型。 |
| Q6 | C | 当 is_super=1 时直接返回 ["*"] 表示拥有所有权限。这是递归展开权限时的短路优化——不需要再去查每条具体的权限记录。 |
填空题答案
| 题号 | 答案 | 解析 |
|---|---|---|
| F1 | user_roles；role_permissions |
user_roles 是多对中间表（user_id + role_id 联合主键）；role_permissions 也是联合主键。没有这两个表用户和权限之间的传递关联就无法建立。 |
| F2 | Redis；2h |
登录时将完整权限树写入 Redis（TTL=2h），之后每次鉴权 O(1) 读取。权限变更时主动删除对应缓存实现最终一致。不查库是关键性能优化。 |
| F3 | 审计 |
强合规系统必须完整记录所有权限相关操作（谁在什么时候获得了什么权限），审计日志不可篡改且长期保存，用于第三方合规审查。 |
简答题参考答案
S1：参考答案要点：
- 角色与权限码设计：定义三个角色 Admin/Edit/Ops。权限码采用
{resource}:{action}格式，如product:read、product:update、product:delete、purchase:create、purchase:approve。Admin 获得 product 全量权限，Edit 只有 update，Ops 只有 read。 - 互斥约束：在 conflict_roles 表中插入
(purchase_role_id, approve_role_id)一条互斥规则。用户在分配角色时先查询冲突表，如果已持有其中一个就不能分配另一个。 - 鉴权流程：登录时查五表获取用户全部权限码（含角色继承展开），写入 Redis（TTL=2h）。后续请求通过 HTTP Middleware 从 Redis 读取做 O(1) 比对。权限变更时主动删除 Redis 缓存。
- 异常处理：SoD 冲突检测失败时返回明确错误信息告知用户哪两个角色互斥。Redis 宕机时 fallback 到查库但不作为常规路径。
评分标准：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。