MQTT 安全指南

从设备身份到主题，全面保护 MQTT

生产级 MQTT 部署需要分层控制：TLS、客户端认证、明确的 ACL 授权、受保护的密钥、网络边界，以及出现问题时可供追查的证据。

探索访问控制了解 MQTT 基础知识

威胁模型

从 MQTT 单独无法阻止的故障模式开始

该协议设计上是轻量级的。安全性来自于其周围的部署选择。

网络窃听

明文 MQTT 可能将凭据、主题名称和负载暴露给任何能观察到网络路径的人。

客户端冒充

共享的凭据和可预测的 Client ID 使区分真实设备和攻击者变得困难。

主题访问过于宽泛

即使是有效客户端，如果它可以在不相关的租户和设备组之间发布命令或订阅，仍然可能造成损害。

可用性滥用

连接洪水、通配符订阅、保留消息滥用和重连风暴可能会耗尽 Broker 资源。

纵深防御

按正确的顺序构建控制措施

01
加密和验证传输层
要求 TLS 1.2 或更高版本，验证 Broker 主机名和证书链，并从生产网络中移除明文监听器访问。
02
为每个设备提供身份
签发独立的凭据，这样即使一个设备被攻陷，也可以在不轮换整个设备群的情况下撤销其权限。
03
授权每个主题操作
分别评估发布和订阅，将过滤器绑定到设备角色，并拒绝未明确需要的访问。

轮换和撤销

跟踪签发情况，限制暴露范围，按计划或事件进行轮换，并使撤销足够快速以供使用。

限制网络范围

使用防火墙、私有路径、速率限制和分段，确保 Broker 访问范围不大于工作负载所需。

监控控制平面

记录认证失败、主题拒绝、凭据更改、重连突发和异常的订阅扇出。

客户端认证

根据设备限制选择身份强度

最强的方案是设备在其整个生命周期内都能安全存储、轮换、验证和恢复的方案。

认证方法
认证方法	最佳适用	强度	操作要求
唯一的用户名和密码	受限设备和简单设备群	配合严格的 TLS 校验与高强度独立密钥	安全存储、速率限制、轮换和吊销
客户端证书 (mTLS)	受管硬件与高可信设备身份	在 TLS 握手阶段提供强加密身份	PKI 签发、私钥保护、续期与吊销
短期令牌	具有身份提供者的网关和应用	正确验证时，限定范围和有时限	可信令牌签发、时钟处理、刷新与受众校验

最小权限

使主题策略可审查

将设备契约表达为狭窄的发布和订阅过滤器，然后在推广前测试允许和拒绝的主题。

传感器设备策略

# Device sensor-042 may publish its own telemetry
topic write factory/shanghai/line-1/sensor-042/telemetry
topic write factory/shanghai/line-1/sensor-042/state

# It may receive only its own commands
topic read factory/shanghai/line-1/sensor-042/command

# Do not grant broad read/write access
topic deny readwrite #

独立审查发布和订阅权限。

将主题过滤器绑定到经过身份验证的设备身份。

为同级设备、命令主题和广泛通配符添加负面测试。

为具有相同角色的设备重用已审查的模板。

审计策略编辑和凭据更改。

演练如何在不影响其他设备的情况下吊销单台设备。

发布门槛

生产级 MQTT 安全基线

必须启用 TLS

拒绝无效证书，移除不安全的后备方案，并验证设备时钟和信任存储。

密钥是设备限定的

固件、电子表格、源代码或复制的配置包中不得包含全厂密码。

策略经过测试

预期的流量成功，而跨设备、跨租户和未经授权的命令路径失败。

事件处置可以落地

运维人员可按预案识别、吊销、调查并替换已泄露的身份。

MQTT 安全常见问题

MQTT 是否默认包含加密？

不。MQTT 定义消息行为，而 TLS 保护传输层。在 1883 端口上的明文连接可能会将凭据、主题和负载暴露给网络。

TLS 是否足以保护 MQTT 部署？

TLS 保护传输中的数据并认证 Broker，但它不决定有效客户端可以使用哪些主题。请将 TLS 与唯一的身份、主题授权、安全的凭据存储和监控结合使用。

用户名和密码认证安全吗？

是的，当每个设备都接收到唯一的强密钥时，连接会验证 TLS，密钥会安全存储，失败尝试会被限制，并且轮换和撤销在运维上是可行的。

如何设计 MQTT 主题权限？

将发布和订阅权限分开，并只授予设备角色所需的狭窄主题过滤器。避免为现场设备使用广泛的 # 访问，并针对预期和拒绝的主题测试每项策略。