4、MQTT安全机制(二)：用户名/密码认证、Token认证、ACL访问控制列表、安全最佳实践
上一章我们聊了TLS和证书，那是MQTT安全的“骨架”。今天要讲的，是更贴近业务层的“血肉”——认证与授权。
说白了，TLS保证的是“通道安全”，但谁来敲门、进门后能干什么，还得靠今天这套机制。我在项目里见过不少团队，TLS配得严严实实，结果用户名密码硬编码在代码里，或者ACL全开——嗯，这就像给金库装了钛合金门，却把钥匙挂在门口。
4.1 用户名/密码认证：最基础，也最容易被滥用
MQTT协议在CONNECT报文里，预留了用户名和密码字段。这是最直接的认证方式。
它的流程很简单：客户端发CONNECT包，带上username和password。Broker收到后，去自己的用户数据库里比对。匹配就放行，不匹配就断开。
我在项目中遇到过的情况： 有个工厂的MES系统，所有设备都用同一个“admin”账号连接。我问为什么，他们说“方便管理”。结果有一次密码泄露，整个车间的数据流都被污染了。所以，我建议你至少做到“一机一密”。
用户名/密码认证的优缺点很明显：
| 维度 | 说明 |
|---|---|
| 优点 | 实现简单，兼容性好，几乎所有MQTT客户端都支持。 |
| 缺点 | 静态凭证，容易泄露；难以管理大规模设备；不支持动态轮换。 |
4.2 Token认证：更灵活，更适合IoT场景
你想想看，成百上千的传感器，每个都要配一个用户名密码，管理起来多头疼？Token认证就是来解决这个问题的。
常见的Token有JWT（JSON Web Token）。客户端连接时，在password字段里放一个Token。Broker验证Token的签名和有效期，通过就放行。
Token的好处是：可以携带额外信息（比如设备ID、权限范围），而且可以设置过期时间。我习惯用Token来做“临时授权”——比如给第三方系统一个24小时有效的Token，到期自动失效，省心。
Token认证的流程大致如下：
- 设备向认证服务器请求Token（携带设备证书或预置密钥）。
- 认证服务器验证通过，签发Token（包含设备ID、权限、有效期）。
- 设备用Token连接MQTT Broker。
- Broker验证Token签名和有效期，通过后建立连接。
4.3 ACL访问控制列表：精细化的“门禁系统”
认证通过后，设备能订阅哪些主题？能发布到哪些主题？这就是ACL（Access Control List）的活儿。
ACL说白了就是一张规则表。每条规则定义：谁（用户名/客户端ID）可以对哪个主题（Topic Filter）做什么操作（发布/订阅）。
我建议你遵循“最小权限原则”： 只给设备它需要的权限，多一个都不给。比如，温度传感器只能发布到 sensors/temperature，不能订阅其他任何主题。
下面是一个典型的ACL规则示例（以Mosquitto为例）：
# 允许用户 sensor01 发布到 sensors/temperature
user sensor01
topic write sensors/temperature
# 允许用户 dashboard 订阅所有 sensors 开头的主题
user dashboard
topic read sensors/#
# 拒绝所有其他操作
user *
topic deny #ACL的匹配顺序很重要。通常，Broker会从上到下匹配，匹配到第一条就停止。所以，要把更具体的规则放在前面，通用的放后面。
4.4 安全最佳实践：我的经验总结
讲了这么多理论，最后分享几条我在实战中沉淀下来的经验。这些不是书本上的教条，是踩过坑之后换来的。
- 强制TLS： 没有TLS，用户名密码和Token都是明文传输，等于白搭。这是底线，没得商量。
- 凭证轮换： 静态密码和长期Token是安全大忌。我建议设置合理的过期时间，并建立自动轮换机制。
- 审计日志： 记录所有连接、认证失败、ACL拒绝事件。出了问题，这是你回溯的唯一线索。
- 最小权限： 每个设备、每个用户，只给最少的权限。不要图省事用通配符“#”。
- 分层防御： 不要依赖单一安全机制。TLS + 认证 + ACL，三层叠加，才能构建纵深防御。
4.5 本章知识体系图
下面这张图，帮你理清MQTT安全机制的层次关系。从传输层到应用层，每一层都有对应的防护手段。
这张图从下往上看，就是MQTT安全的完整防线。每一层都依赖下一层，但每一层又独立解决不同的问题。我个人习惯在设计阶段就把这四层都规划好，而不是上线后再补。