MQTT 安全指南
从设备身份到主题,全面保护 MQTT
生产级 MQTT 部署需要分层控制:TLS、客户端认证、明确的 ACL 授权、受保护的密钥、网络边界,以及出现问题时可供追查的证据。
从 MQTT 单独无法阻止的故障模式开始
该协议设计上是轻量级的。安全性来自于其周围的部署选择。
客户端冒充
主题访问过于宽泛
可用性滥用
| 安全边界 | 可信威胁 | 主要控制 | 剩余风险 |
|---|---|---|---|
| 设备 | 攻击者提取密钥、克隆固件或利用失窃设备冒充客户端。 | 每台设备使用一份受保护的凭据;条件允许时启用安全启动与安全存储,并支持单独吊销。 | 已被攻陷但凭据仍有效的设备,依然可以执行当前策略允许的所有操作。 |
| Broker | 凭据猜测、会话劫持、宽泛订阅与资源耗尽。 | 启用 TLS 和身份认证,校验 Client ID,采用默认拒绝的 Topic 策略,并配置配额和审计事件。 | TLS 与 ACL 无法纠正不安全的载荷处理,也无法消除可用性攻击。 |
| 控制平面 | 运维账户或自动化 Token 被利用后,可修改策略、签发凭据或压制证据。 | 加强运维人员认证,采用最小权限角色、变更评审与不可篡改的审计导出。 | 高权限账户仍是高影响目标,需要职责分离并准备恢复访问路径。 |
| 网络 | 拦截、DNS 或路由篡改、扫描与连接洪水抵达服务端点。 | 校验证书与主机名,限制入口范围,进行网络分段和速率限制。 | 加密不会隐藏端点元数据,也不能保证上游网络始终可用。 |
按正确的顺序构建控制措施
- 01
加密和验证传输层
要求 TLS 1.2 或更高版本,验证 Broker 主机名和证书链,并从生产网络中移除明文监听器访问。
- 02
为每个设备提供身份
签发独立的凭据,这样即使一个设备被攻陷,也可以在不轮换整个设备群的情况下撤销其权限。
- 03
授权每个主题操作
分别评估发布和订阅,将过滤器绑定到设备角色,并拒绝未明确需要的访问。
轮换和撤销
限制网络范围
监控控制平面
根据设备限制选择身份强度
最强的方案是设备在其整个生命周期内都能安全存储、轮换、验证和恢复的方案。
| 认证方法 | 最佳适用 | 强度 | 操作要求 |
|---|---|---|---|
| 唯一的用户名和密码 | 受限设备和简单设备群 | 配合严格的 TLS 校验与高强度独立密钥 | 安全存储、速率限制、轮换和吊销 |
| 客户端证书 (mTLS) | 受管硬件与高可信设备身份 | 在 TLS 握手阶段提供强加密身份 | PKI 签发、私钥保护、续期与吊销 |
| 短期令牌 | 具有身份提供者的网关和应用 | 正确验证时,限定范围和有时限 | 可信令牌签发、时钟处理、刷新与受众校验 |
listener 8883
allow_anonymous false
password_file /etc/mosquitto/passwords
acl_file /etc/mosquitto/acl
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/broker.crt
keyfile /etc/mosquitto/certs/broker.key
tls_version tlsv1.2mosquitto_sub \
-h mqtt.example.invalid -p 8883 \
--cafile ./ca.crt \
-u sensor-042 -P 'REPLACE_ME' \
-i sensor-042-check \
-t 'factory/shanghai/line-1/sensor-042/command' \
-d使主题策略可审查
将设备契约表达为狭窄的发布和订阅过滤器,然后在推广前测试允许和拒绝的主题。
# Mosquitto ACL: username is the unique device identity
pattern write factory/shanghai/line-1/%u/telemetry
pattern write factory/shanghai/line-1/%u/state
# It may receive only its own commands
pattern read factory/shanghai/line-1/%u/command
# Unlisted topics are denied by default轮换凭据,同时避免共享密钥导致的停机
不同 Broker 和身份提供方的 API 并不相同。请将这套厂商中立的顺序作为运维手册,再把每一步映射到你的平台。
- 01
盘点身份与影响范围
记录设备负责人、策略、最后使用时间、密钥类型、签发和到期时间,并准备经过验证的恢复路径。
- 02
签发第二份凭据,并限制重叠窗口
旧凭据只在短暂迁移窗口内保持有效。替代凭据应使用相同或更窄的 Topic 策略,绝不能扩大权限。
- 03
切换前验证新路径
使用完整 TLS 校验重新连接,确认允许的流量,执行负面 Topic 测试,并在日志中确认新身份。
- 04
吊销旧凭据并终止会话
在服务端禁用旧身份,断开现有会话,并验证重连和发布尝试均失败。
- 05
闭合证据链
从设备和密钥存储中删除旧凭据,记录完成状态,并对吊销后再次使用旧身份的行为告警。
泄露处置:先吊销,再调查
如果怀疑凭据被盗,请跳过计划轮换的重叠阶段:立即禁用身份、结束活跃会话、保全 Broker 与控制平面日志、收窄受影响策略;只向重新建立信任的设备签发替代凭据,并监控旧身份是否再次出现。
生产级 MQTT 安全基线
先使用下面的发布门槛,再下载完整的可打印清单,检查传输、身份、授权、轮换、网络、监控与事件响应。
必须启用 TLS
密钥是设备限定的
策略经过测试
事件处置可以落地
标准与实现参考
本指南中的协议事实和配置示例以标准组织与实现方资料为依据;产品能力边界在下方单独说明。
- OASIS MQTT 5.0 — 安全(非规范性)
- Eclipse Mosquitto — ACL 文件插件
- Eclipse Mosquitto — Broker 配置参考
- AWS IoT Lens — 身份与访问管理
- OWASP — 网络分段速查表
RunMQTT 当前提供的能力
RunMQTT 私有 Broker 当前提供 TLS 与安全 WebSocket 端点、自动生成的单设备用户名密码凭据、可复用的发布/订阅 Topic 策略、策略测试,以及删除设备后立即移除访问能力。Dashboard 目前不提供客户自管 mTLS 身份、外部 Token 认证、网络允许列表或原地轮换凭据;如需替换凭据,应创建并验证新的设备身份,再删除旧身份。公共 Broker 是开放测试沙盒,不属于生产安全控制。
MQTT 安全常见问题
MQTT 是否默认包含加密?
不。MQTT 定义消息行为,而 TLS 保护传输层。在 1883 端口上的明文连接可能会将凭据、主题和负载暴露给网络。
TLS 是否足以保护 MQTT 部署?
TLS 保护传输中的数据并认证 Broker,但它不决定有效客户端可以使用哪些主题。请将 TLS 与唯一的身份、主题授权、安全的凭据存储和监控结合使用。
用户名和密码认证安全吗?
是的,当每个设备都接收到唯一的强密钥时,连接会验证 TLS,密钥会安全存储,失败尝试会被限制,并且轮换和撤销在运维上是可行的。
如何设计 MQTT 主题权限?
将发布和订阅权限分开,并只授予设备角色所需的狭窄主题过滤器。避免为现场设备使用广泛的 # 访问,并针对预期和拒绝的主题测试每项策略。
相关 MQTT 资源
先把安全模型应用到真实客户端,再了解 MQTT 如何与其他实时技术协作。