1. MQTT安全概述：协议面临的常见威胁与防御总纲
MQTT 这协议，说白了就是物联网世界的「信使」。设备端发一条消息，Broker 转一下，另一端就收到了。轻量、省带宽、实时性好，所以智能家居、车联网、工业传感器都在用。
但问题也出在这里——它太轻量了。很多团队一开始只图快，上线时连密码都没设，或者用默认的「public/test」就上了。我见过不止一个项目，设备数据裸奔在公网上，谁都能订阅，谁都能发消息。嗯，这跟把家门钥匙挂在门外有什么区别？
核心观点：MQTT 本身只是一个传输协议，它不负责「安全」。安全是配置出来的，不是协议自带的。你不管它，它就默认信任所有人。
1.1 MQTT 协议面临的常见安全威胁
我按实际攻击路径，把威胁分成四类。你在项目里排查时，也可以按这个顺序来。
| 威胁类别 | 具体攻击方式 | 典型后果 |
|---|---|---|
| 身份与认证 | 弱口令爆破、匿名连接、客户端伪造 | 攻击者冒充合法设备，订阅或发布任意主题 |
| 授权与访问 | 通配符订阅（+ / #）、越权发布 | 设备 A 能读到设备 B 的敏感数据 |
| 传输与数据 | 明文嗅探、中间人攻击、重放攻击 | 控制指令被篡改，传感器数据被窃听 |
| 可用性与资源 | 恶意客户端大量连接、超大 Payload 洪水 | Broker 崩溃，整个系统瘫痪 |
我印象最深的一次，是帮一家智能照明厂商做安全审计。他们的 MQTT Broker 直接暴露在公网，端口 1883 没加密。我用 Wireshark 抓了 5 分钟包，就看到了所有灯控指令的明文——包括「开锁」「关锁」这种敏感操作。你想想看，如果这是门禁系统呢？
1.2 为什么安全配置如此重要
有人可能会问：「我内网部署，不连外网，还需要配置安全吗？」
我的回答是：需要，而且非常需要。
内网不代表没有攻击者。我曾经遇到一个案例：某工厂的 MQTT 网络跑在隔离的工业内网里，结果一台摄像头被植入木马，变成跳板机，从内网向 Broker 发起了大量订阅请求。因为没有 ACL（访问控制列表），那台摄像头把整个产线的传感器数据全拉走了。数据泄露发生在内网，但损失一点没少。
安全配置的意义，说白了就是三件事：
- 你是谁 —— 认证，确保只有合法设备能连上来
- 你能干什么 —— 授权，确保设备只能读写它该读写的主题
- 你的数据安全吗 —— 加密，确保传输过程中没人能偷看或篡改
个人习惯：我每接手一个新项目，第一件事就是检查 Broker 的配置文件。如果看到 allow_anonymous true 或者 listener 1883 没有配 TLS，我会直接标红。这不是小题大做，这是底线。
1.3 安全配置的总体原则
做安全配置，最怕「一步到位」的完美主义。我建议你记住下面这四条原则，比背一百条命令都管用。
- 最小权限原则 —— 每个客户端只给它能用的最小权限。不要图省事给通配符
#，哪怕只是临时调试。我曾经因为图方便给测试设备开了全主题权限，结果上线前忘了收回，生产环境被误发了重启指令……嗯，那次事故让我记住了这个教训。 - 纵深防御 —— 不要只靠一层防护。认证 + TLS + ACL + 速率限制，四层叠起来才靠谱。单靠密码？密码泄露就全完了。
- 默认安全 —— 所有配置默认都应该是拒绝的。需要什么再开什么，而不是反过来。匿名连接默认关闭，非加密端口默认不监听。
- 可审计可追溯 —— 所有连接、订阅、发布行为都要有日志。出了事能查是谁、什么时候、干了什么。没有日志的安全配置，等于没配。
避坑指南：我曾经见过一个团队，把所有安全配置都写在 Broker 的默认配置文件里，然后直接复制到生产环境。结果因为版本升级，默认配置被覆盖，所有 ACL 规则全部丢失。我的建议是：安全配置单独管理，版本控制，与 Broker 配置分离。
1.4 MQTT 安全知识体系总览
下面这张图，是我自己梳理的 MQTT 安全知识框架。你可以把它当作整个课程的地图。后面每一章，都会对应到图里的一个模块。
从图上你能看到，MQTT 安全不是单点问题。认证、授权、加密、防护，四个支柱缺一不可。我见过太多团队只配了密码就觉得万事大吉，结果被 ACL 漏洞或者重放攻击打得措手不及。
记住一句话：安全配置不是一次性工作，而是持续迭代的过程。设备在变，攻击手法在变，你的配置也得跟着变。