3. 零信任架构下的MQTT Broker设计原则
这一章，我们聊聊零信任架构在MQTT Broker上的落地。说白了，就是怎么把「永不信任，始终验证」这句口号，变成Broker里实实在在的配置和代码。
我见过太多人把零信任理解成「加个认证就完事了」。嗯，这远远不够。零信任的核心是：网络默认不可信，每一次访问都要重新评估。Broker不再是那个「你连上来就随便发」的中转站，它得变成一个精明的门卫。
核心转变：从「基于位置的信任」转向「基于身份的持续验证」。设备在哪个网段不重要，它有没有合法的凭证、行为是否异常，这才重要。
3.1 Broker作为策略执行点（PEP）
在零信任模型里，Broker的角色变了。它不再只是转发消息的管道，而是策略执行点（Policy Enforcement Point, PEP）。你可以把它想象成机场的安检闸机——每个包、每个人都要过一遍。
我习惯把PEP拆成三个层次来看：
- 连接层PEP：谁可以建立TCP/TLS连接？证书对不对？IP在不在白名单？
- 认证层PEP：MQTT CONNECT报文里的用户名密码、JWT令牌、X.509证书，是否有效且未过期？
- 授权层PEP：这个客户端能不能发布/订阅某个Topic？能读还是能写？
举个例子。我在一个智慧工厂项目里，遇到过一台PLC设备被植入了恶意固件。它虽然拿着合法的证书连上了Broker，但开始疯狂往「/factory/control/shutdown」这个Topic发消息。如果Broker只是做了连接认证，没有做授权层的Topic级控制，那后果不堪设想。
我的建议：把PEP逻辑做成插件化。Eclipse Mosquitto有auth_plugin接口，EMQX有钩子（hooks）机制。这样策略变更时，不需要重启Broker，热加载就行。
PEP的决策依据来自哪里？来自策略决策点（Policy Decision Point, PDP）。PDP可以是内部的ACL文件，也可以是外部的身份与访问管理（IAM）系统。Broker作为PEP，只负责执行，不负责决策。这样职责清晰，也方便审计。
3.2 微隔离与Topic命名空间设计
微隔离，这个词在网络安全里很火。放到MQTT里，其实就是把Topic空间切碎，让每个设备、每个服务只能访问它该访问的那一小块。
你想想看，如果所有设备都共享一个Topic树，比如「/sensor/temperature」，那一个温度传感器就能订阅所有温度数据，甚至还能往里面写数据。这太危险了。
我推荐一种基于租户+设备类型+设备ID的三层命名空间：
// 标准格式
/{tenant_id}/{device_type}/{device_id}/{action}
// 实际例子
/acme_corp/temperature_sensor/sensor_001/upload
/acme_corp/temperature_sensor/sensor_001/config
/acme_corp/actuator/valve_003/command这样做的好处很明显：
- 天然隔离：不同租户的数据不会交叉。即使Broker被攻破，攻击者也很难横向移动到其他租户的Topic。
- 细粒度授权：可以针对「/acme_corp/temperature_sensor/sensor_001/upload」这个精确Topic做ACL，而不是给整个「/acme_corp」通配符权限。
- 便于审计：每条消息的路径都携带了完整的身份信息，出了问题能快速定位到具体设备和操作。
我曾经踩过的坑：一开始设计Topic时用了「/sensor/+/data」这样的通配符订阅。结果某个传感器固件bug，把设备ID写到了payload里而不是Topic路径上。导致ACL根本没法基于设备ID做隔离，所有传感器都能互相看到数据。后来重构Topic结构，花了整整两周。所以，身份信息一定要放在Topic路径里，别放payload。
微隔离的另一个维度是网络层面的隔离。如果条件允许，把不同安全等级的客户端放在不同的VLAN或Kubernetes Namespace里。Broker通过多网卡或eBPF技术，只允许特定网段的流量进入特定Topic组。这算是纵深防御。
3.3 动态信任评估模型
静态的ACL规则有个硬伤：它不会变。一个设备今天行为正常，明天被劫持了，ACL还是给它同样的权限。所以我们需要动态信任评估。
动态信任评估，说白了就是给每个客户端算一个「信任分」。分数高，权限就大；分数低，就降权甚至踢下线。
我设计过一个简单的评分模型，包含三个维度：
| 维度 | 评估指标 | 权重 |
|---|---|---|
| 身份可信度 | 证书是否由受信任CA签发、是否在吊销列表、密钥强度 | 40% |
| 行为合规度 | 发布频率是否异常、订阅Topic是否越界、消息大小是否超标 | 35% |
| 环境安全度 | 客户端IP是否在已知地理区域、TLS版本是否够新、固件版本是否最新 | 25% |
每次客户端发起操作（连接、发布、订阅），Broker都会触发一次信任评估。如果总分低于阈值，比如60分，PEP就拒绝这次操作，并记录告警。
这里有个关键点：评估是实时的，但不是每次都全量计算。我习惯用「滑动窗口+缓存」的方式。比如，身份可信度可以缓存1小时，行为合规度每5分钟重新算一次。这样既保证了实时性，又不会把Broker的CPU打满。
实现思路：在EMQX中，可以通过钩子函数在「client.authenticate」和「client.check_acl」阶段调用外部HTTP API或gRPC服务来做动态评估。评估结果可以带上一个TTL，Broker在TTL内直接使用缓存结果，过期后重新评估。
动态信任评估的最终目的是自适应权限调整。比如：
- 一个温度传感器连续10次上报数据都超出正常范围，信任分下降，Broker自动将其发布权限从「/upload」降级为「/alert_only」。
- 一个设备在非工作时间突然尝试订阅管理Topic，信任分骤降，Broker直接断开连接并加入黑名单。
这些逻辑听起来复杂，但落地时可以用规则引擎（比如Drools、Node-RED）配合Broker的Webhook来实现。我个人的经验是：先做行为基线，再设阈值。没有基线，动态评估就是瞎猜。
最后说一句。零信任不是买一个产品就能搞定的，它是一种架构思想。Broker作为PEP，Topic命名空间作为微隔离的边界，动态信任评估作为持续验证的手段——这三者缺一不可。我在多个项目里验证过这套设计，效果很稳。但记住，没有银弹。你需要根据自己业务的流量模型、设备算力、安全等级，去调整评估频率和阈值。这才是调优的精髓。