1. 零信任模型概述：从边界安全到零信任的演进
大家好，我是你们这期课程的老朋友。今天咱们聊聊零信任——这个在安全圈里被说烂了、但在物联网场景下又不得不重新审视的话题。
说实话，我最早接触零信任的时候，也觉得这不过是厂商炒出来的概念。直到有一次，我在一个智慧工厂项目里，亲眼看到攻击者通过一个被攻破的温湿度传感器，横向移动到了核心PLC网络……嗯，从那以后，我再也不敢小看“信任”这两个字了。
1.1 边界安全的困境：为什么“城堡+护城河”失效了？
传统安全模型，说白了就是“城堡+护城河”。你在企业网络边界上堆防火墙、IPS、VPN，认为内部网络是安全的，外部网络是危险的。这种模型在十年前还行得通，但现在呢？
- 物联网设备数量爆炸：一个工厂可能有几千个传感器、摄像头、执行器，边界根本守不住。
- 设备身份模糊：谁在连接？是合法的温度传感器，还是被篡改的恶意节点？边界防火墙看不出来。
- 移动办公与远程运维：工程师从家里VPN接入，攻击者也可能从同一个VPN入口进来。
你想想看，当攻击者已经进入“城堡”内部，你还在加固外墙，有什么用？这就是边界安全的根本困境——信任一旦被授予，就无法撤销。
1.2 零信任的三大核心原则
零信任模型彻底推翻了“内网可信”的假设。它的核心思想就三句话，我建议你背下来：
永不信任，始终验证，最小权限。
这三个原则，是我在每一个物联网安全项目中反复强调的底线。
原则一：永不信任（Never Trust）
默认情况下，不信任任何实体——无论是来自内网还是外网。每个请求、每个设备、每个用户，在获得访问权限之前都必须经过验证。
我个人习惯在MQTT Broker上配置：即使是来自内网IP的PUBLISH请求，也必须携带有效的客户端证书和JWT令牌。别觉得麻烦，这是第一道防线。
原则二：始终验证（Always Verify）
验证不是一次性的。连接建立后，还要持续检查设备的行为是否异常。比如：一个温度传感器突然每秒发布1000条消息，这正常吗？显然不正常。
我记得在某个项目中，我们通过持续验证发现了一个被植入挖矿脚本的摄像头——它每隔5分钟就尝试连接一个陌生IP的MQTT Broker。要不是持续验证机制，这个后门可能一直潜伏下去。
原则三：最小权限（Least Privilege）
只授予完成任务所需的最小权限。一个只读的温度传感器，就不应该拥有写入Topic的权限；一个只负责上报数据的网关，就不应该能订阅其他设备的控制Topic。
| 设备类型 | 传统权限 | 零信任最小权限 |
|---|---|---|
| 温度传感器 | 可发布/订阅所有Topic | 仅允许发布 sensor/temperature/+/data |
| 执行器（阀门） | 可发布/订阅所有Topic | 仅允许订阅 actuator/valve/+/cmd，并发布 actuator/valve/+/status |
| 远程运维终端 | VPN接入后拥有全部权限 | 仅允许通过特定客户端ID连接，且只能订阅 admin/monitor/# |
1.3 零信任在物联网场景中的价值
你可能会问：零信任在传统IT里都推行得磕磕绊绊，在物联网这种资源受限、设备海量的场景里，真的有用吗？
我的回答是：正因为物联网场景更脆弱，零信任才更有价值。原因有三：
- 设备身份不可伪造：通过零信任的“始终验证”原则，每个MQTT客户端都必须携带唯一身份凭证（如X.509证书）。攻击者即使物理接触了设备，也无法伪造合法身份。
- 横向移动被阻断：最小权限原则让每个设备只能访问自己的Topic。攻击者攻破一个传感器后，无法通过它去订阅控制系统的Topic——因为权限根本不存在。
- 行为异常可感知：持续验证机制能实时检测设备行为偏差。比如一个平时每小时上报一次数据的电表，突然每分钟上报一次，系统可以立即断开连接并告警。
💡 我的实战建议： 在物联网场景中落地零信任，不要一上来就追求完美。先从“最小权限”做起——梳理每个设备的Topic访问需求，配置严格的ACL。这一步做好了，80%的安全问题就解决了。
下面这张图，是我在多个项目中反复使用的零信任MQTT架构逻辑。它清晰地展示了从设备身份验证到持续授权的完整链路：