3、用户权限模型：RBAC模型详解、ABAC模型详解、权限最小化原则、权限分级策略
权限管理，说白了就是决定「谁能干什么」的问题。
我在智能家居安全领域摸爬滚打这些年，见过太多因为权限没管好而翻车的案例。有的用户把门锁权限给了保姆，结果离职后忘了收回；有的智能摄像头被第三方APP偷偷调用了视频流。嗯，这些问题的根源，都在于权限模型没选对。
3.1 RBAC模型详解
RBAC，全称是Role-Based Access Control，基于角色的访问控制。这是目前最成熟、应用最广的权限模型。
核心思想：用户不直接拥有权限，而是通过角色来获得权限。
举个例子：你家有「家庭成员」「访客」「管理员」三个角色。每个角色对应不同的权限集合。你只需要把用户分配到某个角色，他就自动拥有了该角色的所有权限。
RBAC三要素：
- 用户（User）： 使用系统的人，比如你、你老婆、你家保姆
- 角色（Role）： 权限的集合，比如「管理员」「普通成员」「访客」
- 权限（Permission）： 对资源的操作，比如「开锁」「查看摄像头」「调整温度」
我在项目中遇到过这样一个场景：一个智能公寓项目，有业主、租客、保洁、维修工四种角色。用RBAC模型，我只需要定义好这四种角色的权限模板，然后批量分配用户即可。管理起来非常方便。
RBAC的优缺点：
| 优点 | 缺点 |
|---|---|
| 管理简单，角色定义清晰 | 角色粒度较粗，不够灵活 |
| 权限变更只需修改角色 | 角色爆炸问题（角色太多时难以维护） |
| 符合直觉，容易理解 | 无法处理「临时权限」等动态场景 |
我的建议：如果你的智能家居系统用户类型不超过10种，且权限需求相对固定，RBAC是最稳妥的选择。别一上来就搞复杂的模型，简单够用才是王道。
3.2 ABAC模型详解
ABAC，Attribute-Based Access Control，基于属性的访问控制。这玩意儿比RBAC灵活得多，但也复杂得多。
核心思想：权限判断不再依赖「角色」，而是根据一组「属性」来动态计算。
属性通常分为四类：
- 用户属性： 年龄、位置、信用等级、是否是VIP
- 资源属性： 设备类型、设备位置、敏感等级
- 环境属性： 当前时间、网络状态、是否在家
- 操作属性： 操作类型（读/写/执行）、操作频率
举个例子：你设置了一条规则——「只有晚上10点前，且用户在家时，才能通过智能门锁开门」。这条规则用RBAC很难表达，但用ABAC就很简单：
// ABAC策略示例（伪代码）
策略：允许开门
条件：
用户.位置 == "在家" AND
当前时间 <= "22:00" AND
资源.类型 == "门锁" AND
操作.类型 == "解锁"我曾经帮一个高端别墅项目做权限设计。业主要求：保姆只能在工作日9:00-18:00进入主卧，且不能操作保险柜。这种细粒度的控制，用RBAC得定义一堆角色，用ABAC一条策略就搞定了。
ABAC的优缺点：
| 优点 | 缺点 |
|---|---|
| 极其灵活，能处理复杂场景 | 策略管理复杂，容易出错 |
| 支持动态权限判断 | 性能开销大，每次访问都要计算 |
| 细粒度控制，安全性更高 | 调试困难，策略冲突难以排查 |
注意：ABAC不是银弹。我见过有人把简单场景搞成ABAC，结果策略写了上百条，最后自己都理不清。记住：能用RBAC解决的，就别上ABAC。
3.3 权限最小化原则
这个原则听起来简单，做起来真不容易。
核心思想：每个用户只拥有完成其任务所必需的最小权限集合。不多给一分，也不少给一毫。
你想想看：你家智能门锁的临时密码，给访客只开放「开门」权限就够了，没必要让他能修改密码或查看开锁记录。这就是最小化原则。
我在实际项目中总结了几条落地经验：
- 默认拒绝： 所有权限默认关闭，只有明确授权才开放
- 按需授权： 用户需要什么权限，就给什么权限，不要批量给
- 临时权限： 给临时权限设置有效期，到期自动回收
- 定期审计： 每季度检查一次权限分配，清理冗余权限
避坑指南：我曾经给一个智能家居APP做安全审计，发现有个第三方插件居然拥有「删除所有设备」的权限。一问才知道，开发人员图省事，直接给了最高权限。嗯，这种「图省事」的做法，往往是安全漏洞的源头。
3.4 权限分级策略
权限分级，说白了就是把权限分成不同等级，不同等级对应不同的安全要求。
常见的分级方式：
| 等级 | 描述 | 示例 |
|---|---|---|
| L1 - 公开 | 无需认证即可访问 | 设备名称、固件版本 |
| L2 - 普通 | 需要用户登录 | 查看设备状态、查看历史记录 |
| L3 - 敏感 | 需要二次验证 | 开锁、修改密码、查看摄像头 |
| L4 - 管理 | 需要管理员权限 | 添加/删除用户、修改系统配置 |
为什么要分级？因为不同操作的风险等级不一样。你想想看，查看设备温度和远程开锁，能是一个安全级别吗？显然不能。
我建议这样设计分级策略：
- L1权限： 不需要登录，但要做频率限制，防止被恶意扫描
- L2权限： 标准登录即可，建议开启登录日志
- L3权限： 必须二次验证（短信验证码或生物识别），操作记录要保存至少90天
- L4权限： 需要管理员审批，操作要双人复核，日志永久保存
我的习惯：在代码里，我会给每个API接口打上权限等级标签。比如 @PermissionLevel(level = 3)，这样一目了然，审计的时候也方便。
3.5 知识体系总览
下面这张图，是我梳理的本章知识结构。你可以把它当作一个快速索引：
最后说一句：权限模型没有绝对的好坏，只有合不合适。我个人的经验是——先用RBAC搭骨架，遇到特殊需求再用ABAC打补丁。别一上来就追求「完美模型」，先跑起来再说。
可可精品资料库