3. 授权模型设计原则：最小权限、职责分离、默认拒绝
好，我们进入第三讲。前面聊了 Topic 授权模型的基础概念，今天要讲的这三个原则，才是真正决定你系统安全下限的东西。
我见过太多物联网平台，功能做得花里胡哨，结果授权模型一塌糊涂。说白了，就是这三个原则没吃透。咱们一个一个来拆。
3.1 最小权限原则
这个原则听起来简单——只给刚刚好的权限，不多给一分。但实际落地的时候，坑特别多。
核心思想： 每个主体（设备、用户、服务）只拥有完成其任务所必需的最小权限集合。
我个人的经验法则： 如果你在写授权策略时，觉得“这个权限可能以后用得上”，那就先别给。以后用得上，以后再加。
3.1.1 为什么容易违反？
你想想看，开发的时候图省事，直接把“管理员”角色甩给设备。结果呢？一个温度传感器居然有固件升级权限。这不是给自己埋雷吗？
我在一个智能楼宇项目里就遇到过这种事。一个门禁控制器，因为绑了“超级设备”角色，居然能修改其他楼层的空调策略。后来排查了三天才发现是权限过大导致的。
3.1.2 在 Topic 模型中的落地
在 MQTT 或类似的 Topic 授权模型里，最小权限原则具体表现为：
- Topic 路径精确匹配： 能写
device/001/temp，就别用device/001/# - 操作类型限制： 只读设备就别给 publish 权限
- 时间窗口约束： 某些设备只在特定时段需要权限
| 场景 | 错误做法 | 正确做法 |
|---|---|---|
| 温度传感器上报 | 允许 publish 所有 topic | 只允许 publish sensor/temperature/+/data |
| 手机 App 查看设备 | 赋予设备管理权限 | 只赋予订阅设备状态 topic 的权限 |
| OTA 升级服务 | 允许读写所有设备 topic | 只允许向指定设备 topic 发布升级指令 |
小技巧： 我习惯在授权策略里加一个“权限清单”注释块，每次新增权限都写清楚理由。三个月后回头看，能砍掉至少 30% 的多余权限。
3.2 职责分离
这个原则说白了就是：不能让一个人（或一个设备）既当运动员又当裁判员。
核心思想： 将敏感操作拆分成多个步骤，由不同主体分别执行，避免单点滥用。
3.2.1 为什么需要职责分离？
我记得有个客户，他们的智能门锁系统里，同一个设备既能开锁又能记录开锁日志。结果出了安全事故后，日志被删得干干净净。这就是典型的职责未分离。
你想想看，如果开锁和记日志是两个不同的服务，一个被攻破，另一个还能留下证据。
3.2.2 在 Topic 授权中的典型场景
- 设备注册 vs 设备激活： 注册服务只能写入注册 topic，激活服务只能读取并处理激活请求
- 命令下发 vs 状态确认： 控制服务能 publish 命令，但只有设备自身能 publish 状态确认
- 策略配置 vs 策略审计： 配置人员能修改授权策略，审计人员只能读取
注意： 职责分离不是简单的“多设几个角色”。它要求你在流程设计上就拆开。我曾经见过一个系统，虽然分了三个角色，但三个角色用的是同一个 API Key——那跟没分有什么区别？
3.3 默认拒绝策略
这个原则最容易被忽视。很多人的思路是“先开放，再收紧”。但安全设计恰恰相反——先全部拒绝，再逐个放行。
核心思想： 任何未明确授权的访问，默认都是拒绝的。
3.3.1 默认拒绝 vs 默认允许
| 对比维度 | 默认拒绝 | 默认允许 |
|---|---|---|
| 安全基线 | 高，遗漏即保护 | 低，遗漏即漏洞 |
| 配置复杂度 | 初期稍高，需逐条添加 | 初期低，但后期难维护 |
| 审计难度 | 容易，所有权限都有记录 | 困难，不知道谁开了什么 |
| 典型风险 | 可能误拒正常请求 | 可能遗漏恶意访问 |
3.3.2 在 Topic 模型中的实现
在 Topic 授权模型里，默认拒绝策略通常通过以下方式实现：
- ACL 默认规则： 在访问控制列表末尾添加一条“deny all”规则
- 通配符黑名单： 先拒绝所有
#通配符，再开放具体路径 - 空角色策略： 新设备默认分配空角色，无任何权限
# 一个典型的默认拒绝 ACL 配置示例
# 注意：最后一条规则是拒绝所有
# 允许温度传感器上报数据
allow publish sensor/temperature/+/data from device:temp_sensor
# 允许手机 App 查看设备状态
allow subscribe device/+/status from user:app_user
# 默认拒绝所有其他操作
deny all
我的习惯： 在写 ACL 时，我会先把 deny all 写上去，然后再往上加 allow 规则。这样就不会漏掉。你试试看，这个顺序能帮你发现很多“我以为有权限但实际上没有”的情况。
3.4 三个原则的关系
这三个原则不是孤立的。它们互相支撑，形成一个完整的授权设计框架。
3.5 避坑指南
最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路。
我曾经犯过的错：
- 给设备配了
#通配符权限，想着“以后扩展方便”。结果一个被攻破的灯泡，差点控制了整个楼宇系统。 - 把“查看设备日志”和“删除设备日志”放在同一个角色里。审计的时候发现日志被人为清空过，但查不出是谁干的。
- 默认允许了所有内网设备的访问。后来一个内部测试设备被暴露到公网，直接成了后门。
嗯，这三个原则说起来简单，但真正做好不容易。我建议你在设计授权模型时，先把这三个原则写在白板上，每加一条权限就问自己一遍：符合最小权限吗？有没有职责分离？默认拒绝了没有？
养成这个习惯，你的系统安全基线至少能提升一个档次。