MQTT在设计之初主要用于低功耗、窄带宽的物联网场景，因此其协议本身只提供了基础的安全框架（如用户名/密码），更强大的安全能力需要结合其他层级和组件来实现。
整个MQTT安全架构通常被看作一个多层防御体系，主要涉及以下几个层面：
这是MQTT安全的第一道防线，通过在TCP连接上叠加TLS/SSL协议，确保数据传输的机密性和完整性。
1.协议版本与加密套件：建议仅使用TLS 1.2和TLS 1.3协议。为获得前向安全性（即使服务器私钥泄露也无法解密历史数据），应优先选择基于ECDHE密钥交换和GCM模式的加密套件。
2.认证方式：通过TLS，可以实现服务器身份验证（单向认证），确保客户端连接到正确的服务器；也可以实现客户端证书认证（双向认证/mTLS），为设备颁发X.509证书，安全性更高。
注意：使用TLS会增加握手时长和CPU开销，对于资源极度受限的设备，需要平衡安全与性能。
传输层保证通道安全，但“谁”能连接以及能“做什么”，则需要应用层来控制。
1. 身份认证：回答“你是谁？”
建立了加密通道后，Broker就需要验证客户端身份了。常见的认证方式包括：
认证方式 | 安全性 | 核心特点 | 适用场景 |
用户名/密码 | 基础 | 对安全要求不高的内部网络或测试环境。 | |
JWT (Token) | 较高 | 现代微服务架构、需要与OAuth 2.0等集成。 | |
X.509客户端证书 | 最高 | 通过TLS双向认证实现，证书成为唯一身份凭证。 | 蜂窝网络设备、以及大批量生产的物联网硬件。 |
HTTP回调 | 自定义 | 需要集成现有账户系统或自定义复杂认证逻辑的场景。 | |
增强认证 (SCRAM) | 高 | ||
PSK (预共享密钥) | 中等 | 资源极度受限、无法运行完整TLS协议栈的传感器和执行器。 |
此外，许多Broker（如EMQX）支持认证链，可灵活组合多种方式实现多因素认证。
2. 授权与ACL：回答“你能做什么？”
即使通过了认证，也需遵循最小权限原则。授权（Authorization）通过访问控制列表（ACL） 限制客户端能对哪些主题（Topic）进行发布（PUB）或订阅（SUB）操作。
l 授权粒度：从粗到细可精确控制到Client ID、IP地址、QoS等维度。
l 灵活架构：与认证链类似，主流Broker也支持授权链，可串联多个授权器（如数据库和JWT声明），实现复杂策略。
MQTT 5.0在安全上有了巨大飞跃，引入了主要机制来弥补旧版本的不足：
1. 增强认证 (Enhanced Authentication)：通过支持SASL（简单认证与安全层），引入如SCRAM和Kerberos等更安全的认证框架。它允许通过AUTH报文进行多次数据交换，实现不传输密码的安全认证和双向验证。
2.用户属性 (User Properties)：可在消息中附加键值对，携带审计ID、数字签名等元数据，为端到端安全提供基础。
3.会话过期与接管防护：通过设置会话过期间隔，可降低会话被非法接管的攻击风险。
四、常见安全陷阱与对策
除了构建防御体系，了解常见攻击并做好防范也至关重要。
安全威胁 | 描述 | 应对策略 |
拒绝服务攻击 (DoS/DDoS) | 用海量连接或消息淹没服务器，使其无法响应。MQTT共享订阅功能亦可能被利用。 | |
中间人攻击 (MITM) | ||
身份伪造 | 攻击者窃取或破解凭据（如弱密码）后，冒充合法设备进行操作。 | |
跨站脚本攻击 (XSS) | ||
漏洞利用 | 利用Broker或客户端软件的已知漏洞发起攻击。 | - 定期更新软件版本，关注安全公告。 |
在实践中，建议将以下几点作为基础要求：
1.最小权限原则：通过ACL，只为每个客户端授予其完成业务所必需的最小主题（Topic）权限。
2.使用强加密：强制使用TLS 1.2或TLS 1.3协议，并为TLS连接推荐使用安全的密码套件（Cipher Suites）。
3.严格认证：不依赖匿名认证，根据安全级别选择用户名/密码（配合TLS）、X.509证书或SCRAM增强认证。
4.杜绝硬编码：绝不在代码中硬编码密码或密钥。使用密钥管理服务（KMS）或硬件安全模块（HSM）等安全存储。
