1. Topic 授权模型概述：什么是 Topic、为什么需要授权模型、传统设备访问控制的痛点

大家好，我是你们这堂课的老朋友。咱们今天聊的这个话题，说白了就是物联网设备怎么安全地“说话”。你想想看，一个智能灯泡、一个温度传感器，它们每天在网络上发来发去的数据，到底谁该看、谁不该看？这就是 Topic 授权模型要解决的核心问题。

我最早接触物联网安全的时候，也踩过不少坑。有一次客户反馈说，他们工厂的某个传感器数据莫名其妙被隔壁产线的设备读走了。查了半天，发现就是 Topic 权限没设好。嗯，从那以后，我对授权模型就格外上心了。

1.1 什么是 Topic

Topic，中文常翻译成“主题”或“话题”。在 MQTT 这类物联网协议里，它就是消息的“地址”。设备发布消息到某个 Topic，其他设备订阅这个 Topic，就能收到消息。

举个例子：

工厂/产线A/温度传感器/001

这个 Topic 就代表“工厂里产线 A 的 001 号温度传感器”。任何设备往这个 Topic 发数据，订阅了它的设备就能收到。

Topic 的结构通常用斜杠 / 分层，支持通配符：

• +：匹配单层。比如 工厂/+/温度传感器/001 能匹配所有产线的 001 号温度传感器。
• #：匹配多层。比如 工厂/# 能匹配工厂下的所有 Topic。

我个人习惯把 Topic 想象成“消息的信箱”。每个信箱有编号，投递员（Broker）根据编号把信送到对应的人手里。但问题来了——如果谁都能往任何信箱投信，或者谁都能打开任何信箱看信，那不乱套了吗？

1.2 为什么需要授权模型

没有授权模型的物联网系统，就像一栋没有门禁的大楼。任何人都能进，任何房间都能逛。这在生产环境里是绝对不行的。

我总结了几点核心原因：

1. 数据隔离：不同租户、不同产线、不同设备的数据不能互相串。比如医院的病人数据，绝对不能泄露给无关设备。
2. 最小权限原则：每个设备只应该拥有完成它任务所需的最小权限。一个温度传感器，只需要发布温度数据，不需要订阅控制指令。
3. 防止恶意攻击：如果没有授权，攻击者可以伪造设备发布虚假数据，或者订阅敏感 Topic 窃取信息。
4. 审计与合规：很多行业（如金融、医疗）要求记录谁在什么时间访问了什么数据。授权模型是审计的基础。

说白了，授权模型就是给每个设备发一张“通行证”，明确告诉它：你能去哪、能干什么、不能干什么。

1.3 传统设备访问控制的痛点

在 Topic 授权模型出现之前，大家是怎么做设备访问控制的？说实话，方法很原始，痛点也很多。

痛点	传统做法	问题
全通配符放行	直接给设备订阅 # 通配符	设备能访问所有 Topic，毫无隔离可言
静态密码认证	设备使用固定的用户名/密码连接 Broker	密码泄露后难以撤销，且无法区分设备身份
IP 白名单	只允许特定 IP 地址的设备连接	IP 可以伪造，且动态 IP 环境下无法使用
无细粒度控制	要么全部允许，要么全部禁止	无法实现“只读”、“只写”等精细权限
权限变更困难	需要手动修改配置文件并重启 Broker	效率低，容易出错，影响在线设备

我曾经帮一家智能家居厂商排查过问题。他们的智能门锁和灯光系统用的是同一个 Broker，结果因为权限没设好，门锁的状态 Topic 被灯光系统订阅了。每次有人开门，灯就闪一下……你说这用户体验能好吗？

更严重的是，如果攻击者控制了某个弱权限设备，就能通过全通配符订阅所有 Topic，窃取整个系统的数据。这就是传统做法的最大隐患——权限边界模糊。

1.4 本章知识体系总览

为了让大家更直观地理解 Topic 授权模型在整个物联网安全中的位置，我画了一张图。它展示了从设备到 Broker，再到授权决策的完整链路。

从这张图你能看到：

• 设备 A 和 B 是合法设备，它们发布或订阅的 Topic 在授权范围内。
• 恶意设备试图用 # 通配符订阅所有 Topic，但 Broker 会先向授权引擎查询——这个设备有没有权限？没有，就拒绝。
• 授权引擎里存的就是我们后面要讲的 Topic 权限表、ACL 规则。

这就是 Topic 授权模型的核心：在消息路由之前，先做权限检查。没有这个环节，物联网就是“裸奔”。