用主题前缀划边界
消息协议本身不提供资源级权限，授权通常落在主题上：设备账号被限制为只能发布和订阅自己前缀下的主题，平台服务按角色获得更宽的订阅范围，系统的运行主题只对运维角色开放。这样即使某台设备凭据泄露，攻击者也无法读取其他设备的数据或向他人主题下发指令。
隔离维度
| 维度 | 做法 | 注意 |
|---|---|---|
| 设备侧 | 只允许发布自己的上报主题，只订阅自己的指令主题 | 避免给设备开放通配符订阅 |
| 平台服务 | 按角色分配订阅与发布范围 | 读与写应使用不同凭据 |
| 共享订阅 | 组内成员的权限范围保持一致 | 权限不一致会导致部分成员收不到消息 |
| 系统主题 | 仅运维角色可访问代理运行主题 | 设备不应能读取系统主题 |
| 多租户 | 租户标识作为最高层级并纳入授权规则 | 缺少隔离时一次越权就是跨客户泄露 |
典型使用场景
- 设备接入：设备账号权限仅覆盖自身主题前缀
- 内部分发：采集、存储与告警服务分别使用各自凭据
- 多租户平台：按租户维度隔离主题与授权规则
- 安全评审：用越权尝试验证规则有效性
权限规则的有效性靠越权用例验证：尝试订阅他人主题、尝试向他人指令主题发布，都应被拒绝；这类验证比逐条核对配置更接近真实风险。
把租户隔离建立在命名约定而不建立在授权规则上，风险很高：一次命名写错就会造成跨租户的数据读取。
评审要点
权限规则评审时建议列出三类用例：设备读写自身主题、设备尝试访问他人主题、平台服务访问全部主题，逐条确认预期结果，比通读配置更容易发现遗漏。