安全与认证

MQTT 规范本身把安全留给传输层与实现；工程上必须主动设计
底线：生产环境不要裸奔 1883 对公网

---

1. 传输层加密

端口（惯例）	含义
1883	明文 MQTT
8883	MQTT over TLS
80/443	常用于 WebSocket / WSS（以实现为准）

实践：

• 启用 TLS 1.2+
• 校验证书主机名
• 需要时做双向 TLS（mTLS）：设备持客户端证书

---

2. 应用层身份

常见方式：

1. Username / Password（CONNECT）
2. 客户端证书（TLS）
3. Token（密码字段塞 JWT，或 MQTT5 增强认证）
4. MQTT 5 AUTH 多步认证

原则：身份与设备身份生命周期（签发、轮换、吊销）要有流程。

---

3. 授权（ACL）

认证解决“你是谁”；授权解决“你能碰哪些 Topic”。

典型 ACL：

用户 agv07:
  可发布：siteA/agv07/cmd/#
  可订阅：siteA/agv07/state/#
  禁止：  $SYS/# 、别人的命名空间

Broker 侧（Mosquitto acl_file、EMQX ACL 规则、HiveMQ 扩展等）配置。
最小权限：设备不能订阅全网 #。

---

4. 载荷安全

TLS 保护通道，不自动保证：

• 应用层完整业务授权
• 端到端对 Broker 不可见的保密（若需要，对 Payload 再加密）
• 防重放（加时间戳/nonce + 服务端校验）

---

5. 网络安全分层

设备 --TLS--> Broker(DMZ) --TLS/内网--> 后端服务
                 │
                 ├─ ACL
                 ├─ 速率限制
                 └─ 审计日志

机器人场景补充：

• 车载/产线 MQTT 与办公室 IT 网隔离
• 仅桥接必要 Topic 到云
• 急停等安全功能不要只靠 MQTT（需独立安全通道）

---

6. 常见误区

误区	正确做法
内网就不用 TLS	内网也会被横移攻击；至少要认证+ACL
强密码就够	还需 Topic 级授权与证书轮换
Retain 命令	危险：后来者可能执行旧命令；命令慎用 Retain
共享账号	审计困难；一人一证/一设备一身份

下一篇：06-开源Broker与客户端对比.md