8.3 通信安全
8.3.1 网络传输加密技术
阅读提示：MQTT、CoAP 等协议本身的机制在第 9 章展开，设备接入侧的统一安全接入在第 4 章已有铺垫。本节聚焦安全视角——从威胁模型、证书管理和密钥轮换的角度讨论传输加密工程，而非协议本身。TLS 1.3 握手流程的完整时序见本节图8-6；下文的 Nginx 配置是 MQTT over TLS 的 TLS 终结层示例，Broker 侧的双向认证配置与端到端验证见实验卡 EXP-8-COMSEC-01。
一台部署在油田井口的压力传感器，每隔几秒就把现场油压数据通过 MQTT 上报到云端控制平台。如果这条链路没有加密，攻击者只需要在信号覆盖范围内搭建一个伪造的接收设备就能截获无线信号——油压、阀门状态、甚至控制指令一览无余。换成供水管网或化工厂，后果就不是隐私泄漏，而是安全事故。
网络传输加密解决的就是这个问题：在不可信的链路上，确保数据从发送方到接收方之间“看不见，改不了”。本小节从 TLS 和 DTLS 两个协议入手，讲清楚它们怎么工作，在 IoT 场景下怎么配置，以及那个最常被忘掉的环节——密钥管理。
TLS 握手：证书、密钥交换与会话建立
说明：本章示例场景中的数值均用于说明工程判断，非通用统计结论。
TLS（传输层安全，Transport Layer Security）是目前保护 TCP 通信最通用的标准。两个版本在广泛使用：TLS 1.2（RFC 5246，定稿于2008年）和 TLS 1.3（RFC 8446，2018年定稿）。TLS 1.3 把握手从两次往返减到一次，移除了不安全的密码套件（如 RSA 密钥交换、CBC 模式），并被主流云平台和新版 MQTT Broker 逐步采纳。但在嵌入式领域，TLS 1.2 的协议栈实现更成熟、库体积更小，不少厂商仍以 1.2 为基线，仅部分高端设备支持到 1.3。
一次完整的 TLS 1.2 握手，走以下四步：
- ClientHello：客户端（设备或应用）发送支持的 TLS 版本、密码套件列表和一个随机数（Client Random）。
- ServerHello + Certificate：服务器选定密码套件，发回自己的数字证书和另一个随机数（Server Random）。证书里包含服务器公钥，以及由证书颁发机构签发的签名。
- 密钥交换：客户端验证服务器证书有效（检查签名、有效期、域名匹配），然后生成一个预备主密钥（Pre-Master Secret），用服务器公钥加密后传回。双方各自根据三个随机数派生出一致的会话密钥。
- Finished：双方用会话密钥加密一条“握手完成”消息，确认密钥协商成功。此后所有应用数据都用这条会话密钥加密传输。
TLS 1.3 把步骤 2 和 3 合并，且默认使用 ECDHE 密钥交换，提供前向保密——即使服务器私钥后来泄漏，过去的会话记录也无法被解密。
下面的序列图展示了 TLS 1.3 握手的主要流程。
DTLS：UDP 链路怎么加密？
大量 IoT 设备用 UDP 而不是 TCP，目的是省掉 TCP 的三次握手开销，降低延迟和功耗。CoAP（受限应用协议，Constrained Application Protocol）正是为此设计的：它的最小消息头仅 4 字节，典型请求报头很小，适合低功耗、低带宽网络。但 UDP 不保证顺序和重传，直接把 TLS 搬过来行不通——TLS 的序列号机制依赖 TCP。
DTLS（数据报传输层安全，Datagram Transport Layer Security）解决了这个矛盾。它基于 TLS，但增加了一套对数据报乱序、丢包的容忍逻辑。DTLS 1.2 与 TLS 1.2 保持版本同步（RFC 6347，2012年定稿），CoAP 的安全层 CoAPS 运行在 DTLS 之上。LwM2M（轻量级 M2M，Lightweight Machine-to-Machine）为 CoAP 定义了一套完整的安全方案，核心就是 DTLS 1.2，提供与 TLS 同等级的完整性、认证和机密性服务。
DTLS 的握手大致跟 TLS 一样，但多了两步：
- epoch 计数器：每成功完成一次握手或重新协商，epoch 值加 1。接收方用 (epoch, sequence_number) 唯一标识一条消息，即使数据报乱序也能正确拼装。
- 分段与重组：握手消息长度可能超过 UDP 的 MTU（典型值 1500 字节），DTLS 把它们拆成多个数据报分别发送，接收方缓存后再收到所有分片后重组。
代价是协议栈增大——DTLS 的代码体积一般比纯 TLS 大，且握手消息本身可能被分片，在丢包率高的链路上可能反复重试。部分极低端 MCU（内存仅几十 KB 的型号）跑不起完整 DTLS，退而求其次用 PSK（Pre-Shared Key，预共享密钥）加自定义 MAC 的方案，但这会失去证书链的灵活性。
密码学算法选型
密码套件不是写得越多越好。每一组套件是加密算法、密钥交换算法和消息认证码的打包组合。IoT 平台选型时，安全性、性能、功耗要同时看。
表8-6 典型密码算法适用性对比
| 算法类别 | 典型算法 | 嵌入式设备适用性 | 说明 |
|---|---|---|---|
| 对称加密 | AES-CCM | 高（多数 MCU 内置 AES 指令） | DTLS 默认套件之一；CCM 模式同时提供加密与认证。定义于 RFC 6655（TLS）和 RFC 3610（CCM） |
| 对称加密 | ChaCha20 + Poly1305 | 高（软件实现效率高，无硬件加速时优于 AES） | 适合无 AES-NI 的终端；RFC 7905 定义了 TLS 中的使用 |
| 密钥交换 | ECDHE | 中等（ECC 点乘计算在低端 MCU 上可行） | 提供前向保密，TLS 1.3 默认使用 |
| 密钥交换 | RSA | 中等（大数模幂运算在低端 MCU 上较慢） | 无前向保密，TLS 1.3 中仅用于签名验证 |
| 消息认证 | SHA-256 | 高（多数 MCU 有硬件 SHA-256） | TLS 1.2 记录层认证；TLS 1.3 改用 AEAD |
| 消息认证 | SHA-1 | 不推荐（已证明碰撞风险） | 不应在新系统中使用 |
工程实践中，推荐套件组合为 TLS_ECDHE_ECDSA_WITH_AES_128_CCM（RFC 6655）或 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256（RFC 7905 的正式注册名；其 OpenSSL 短名为 ECDHE-ECDSA-CHACHA20-POLY1305，见下文 Nginx 配置）。证书链深度不要超过两级——设备在握手阶段每多传一级证书，就多出几百字节传输量，对 LoRaWAN 或 NB-IoT 这类极低带宽链路可能撑爆 MTU 或明显延长握手完成时间。
Nginx 配置示例
下面是一个典型的 Nginx 四层代理配置，为 MQTT Broker 提供 TLS 终结。MQTT 是二进制 TCP 协议，Nginx 必须使用 stream 模块在传输层透传流量，而不能套用 HTTP 模块的 proxy_pass。示例中的路径和密码套件需根据实际安全基线调整。ssl_verify_client on 表示双向认证在终结层强制生效：不出示可信任证书的客户端，在 TLS 握手阶段就会被拒绝。若由 Broker 直接终结 TLS，对应的证书强制与 topic 授权配置见下文实验卡 EXP-8-COMSEC-01。
# 示意配置——根据实际环境调整证书路径和密码套件
# stream 块必须位于 nginx.conf 顶层（http 块之外），对 MQTT 做四层透传
stream {
server {
listen 8883 ssl; # MQTT over TLS 默认端口
ssl_certificate /path/to/iot-server.crt;
ssl_certificate_key /path/to/iot-server.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers on;
# 双向认证：强制客户端出示证书，并由终结层用 CA 根证书验证
ssl_client_certificate /path/to/ca-cert.crt;
ssl_verify_client on;
# stream 模块的 proxy_pass 直接写后端地址，不带 http:// 协议前缀
proxy_pass 127.0.0.1:1883; # 内部 MQTT Broker 明文端口
}
}实验 EXP-8-COMSEC-01：MQTT 双向认证与 topic 授权验证
Nginx 示例把客户端证书校验放在了终结层；如果由 Broker 直接终结 TLS（Mosquitto、EMQX 都支持），同样的约束要在 Broker 配置里落地。下面的步骤以 Mosquitto 2.x 为例，用一组“正反验证”确认两条硬约束真的生效：没有证书的客户端连不上，持证书的客户端也越不了权。EMQX 的对应做法是在监听器的 TLS 选项中把 verify 设为 verify_peer、fail_if_no_peer_cert 设为 true，topic 授权改在其内置授权数据库中配置，验证思路完全一致。
第 1 步：生成根 CA、服务端与客户端证书。
# 根 CA：自签名；生产环境中私钥应交由 HSM 或签名服务保护
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
-subj "/CN=IoT Lab Root CA" -out ca.crt
# 服务端证书：CN 写 Broker 的域名
openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=broker.iot.local" -out server.csr
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -days 825 -sha256 -out server.crt
# 设备证书：以 device-001 为例，CN 将成为 Broker 侧的用户名
openssl genrsa -out device-001.key 2048
openssl req -new -key device-001.key -subj "/CN=device-001" -out device-001.csr
openssl x509 -req -in device-001.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -days 825 -sha256 -out device-001.crt
openssl verify -CAfile ca.crt server.crt device-001.crt预期结果：最后一条命令输出 server.crt: OK 与 device-001.crt: OK，两张证书都能链到根 CA。
第 2 步：配置 Mosquitto。 在 /etc/mosquitto/conf.d/mtls.conf 中：
listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/server.crt
keyfile /etc/mosquitto/server.key
require_certificate true
use_identity_as_username true
allow_anonymous false
acl_file /etc/mosquitto/aclrequire_certificate true 强制双向认证；use_identity_as_username true 把客户端证书的 CN 映射为认证后的用户名，交给 ACL 限定读写范围。/etc/mosquitto/acl 的内容如下——device-001 只能读写自己的 topic 前缀：
user device-001
topic readwrite device/001/#重启服务（systemctl restart mosquitto）。预期结果：服务正常监听 8883 端口，日志中没有证书加载错误。
第 3 步：正反验证。
# 正向：持证书客户端发布到自己的 topic
mosquitto_pub -h broker.iot.local -p 8883 \
--cafile ca.crt --cert device-001.crt --key device-001.key \
-t device/001/temperature -m "23.5"
# 反向一：无客户端证书
mosquitto_pub -h broker.iot.local -p 8883 \
--cafile ca.crt \
-t device/001/temperature -m "23.5"
# 反向二：持证书客户端发布越权 topic
mosquitto_pub -h broker.iot.local -p 8883 \
--cafile ca.crt --cert device-001.crt --key device-001.key \
-t device/002/temperature -m "99.9"预期结果：正向命令正常退出，订阅端（同样携带证书执行 mosquitto_sub -t 'device/001/#' -v）能收到这条消息；反向一在 TLS 握手阶段即被拒绝，客户端报 tlsv1 alert certificate required 一类的错误，Broker 日志记录握手失败；反向二能完成握手、发布却被拒——Broker 断开连接并在日志中记录 Denied PUBLISH（原因 not authorized），订阅端收不到这条消息。
实验卡 EXP-8-COMSEC-01
- 对象：MQTT over TLS 双向认证与 topic 级授权的端到端验证；
- 固定项：Mosquitto 2.x、OpenSSL 3.x、同一根 CA 签发的服务端/设备证书、ACL 文件版本；
- 判据：无证书客户端在握手阶段被拒（
certificate required）；持证书客户端可正常发布与订阅device/001/#；对device/002/#的发布被拒并断开；- 证据留存：三条命令的完整输出、Broker 日志截取、证书指纹（
openssl x509 -noout -fingerprint -in device-001.crt）；- 扩展项：吊销或轮换 device-001 证书后重跑正向用例，确认旧证书在轮换窗口后失效；在 EMQX 上以
verify_peer+fail_if_no_peer_cert复测同一组判据。
证书吊销与密钥轮换：最常忽略的环节
证书吊销是 IoT 安全里最容易被忘掉的环节。设备私钥泄漏或设备报废后，得及时把它的证书从可信列表中移除。传统做法是维护 CRL（证书吊销列表，Certificate Revocation List），但 CRL 文件体积较大，IoT 设备离线运行数月是常事，拉不下来。
工程替代方案有三个：
- OCSP Stapling：服务器定期从 CA 获取 OCSP（在线证书状态协议，Online Certificate Status Protocol）响应，在 TLS 握手里附带响应给客户端，客户端不需要额外请求。适合云平台对设备的认证。
- 短期证书+自动续签：平台签发的证书有效期缩短（例如 7–30 天），设备周期性地向证书管理服务请求新证书。泄漏影响窗口极短。要求设备能定期在线并跑自动轮换脚本。
- 安全芯片硬件生成密钥：部分安全芯片支持密钥内部生成、只出不进。轮换时只换证书文件，私钥本身不离开芯片。不涉及 OTA 传输私钥，安全等级更高。资源受限的设备也可以用 PSK 降级——PSK 在握手前就已由人工或带外通道预置，省掉了证书认证的计算量。
密钥轮换的工程要点：新旧密钥要平滑过渡。设备用老密钥加密新密钥包，平台收到后先用老密钥解密再写入；或者在规定的时间窗口内同时接受新旧两套密钥签名，窗口过后老密钥失效。若设备因断网没来得及切换，就要预置“离线紧急密钥”，允许设备在认证失败时回退到该密钥做一次续约。
工程检查清单
在 IoT 项目里部署传输加密，没有一刀切，但底线是明确的。下面这张列表可以在选型和上线前逐条检查：
- 最低 TLS 版本：禁止启用 TLS 1.0/1.1；推荐 TLS 1.3，至少 TLS 1.2。
- 密码套件：移除弱套件，例如包含 CBC 模式的旧套件；优先 AEAD 模式（如 CCM, GCM, ChaCha20-Poly1305）。
- 双向认证：服务端证书必须验证；客户端证书（设备侧）建议验证，至少用 Token 或 PSK 做身份绑定。
- 防火墙 UDP 端口：若用 CoAP/DTLS，确认非安全端口（5683）和安全端口（5684）在设备和平台间的所有网段都开放。
- 会话复用：允许会话 Ticket 或 Session ID 复用减少握手次数，但设置合理的过期时间（建议 6–12 小时），超过后强制重新握手。
- 证书吊销：启用 OCSP Stapling 或部署短期证书，不依赖被动拉取 CRL。
- 日志与监控：记录 TLS 握手失败、证书过期警告、密钥轮换日志，并连接到平台的告警通道。
大多数物联网平台的安全事故，根源不是加密算法被攻破，而是配置不当或密钥管理粗放。加密本身是盾，但真正的防守来自细致地运用它。
从物理安全走到传输加密，信任的传递从根部延伸到了通信链路。但加密只解决了“看不见”的问题——如果攻击者把一条合法消息抓下来，在几分钟后原样重放，加密通道不会拒绝它，因为它本身就是一个合法的密文。下一节我们会讨论消息完整性校验与防重放攻击，把通信安全的最后两条腿补全。
8.3.2 消息完整性校验与重放攻击防护
加密解决了“链路别人看不见”的问题，但它没有解决“报文在传输中是否被篡改”，也没有解决“别人录下报文稍后重放”的问题。
拿 8.3.1 开头的油田场景来说：即使压力传感器与平台之间建立了 TLS 加密通道，如果攻击者在设备上植入恶意代码，在加密前就篡改了载荷，平台最终解密出来的就是一份看似合法实为虚假的数据。更常见的操刀方式是：攻击者虽然解不开加密内容，但可以完整录制一段加密报文——比方说，录下一段“关阀”指令的加密密文，在若干小时后原封不动地重放给平台。平台解密后认为这就是一次合法的关阀请求，阀门就此关闭。加密阻止了窃听，却没有阻止重放。
所以，完整性校验和重放防护必须作为独立的安全机制，与加密配合使用。它们解决的问题不同：完整性校验回答“数据是否被改过”，重放防护回答“数据是不是此刻的合法请求”。
消息认证码（HMAC）
HMAC（基于哈希的消息认证码，Hash-based Message Authentication Code）是目前应用最广的消息完整性校验机制。发送方用共享密钥与消息一起，通过哈希函数计算出一个固定长度的认证码（MAC），然后将消息和 MAC 一并发出；接收方用同样的共享密钥重新计算，比对 MAC 是否一致。一旦 MAC 不匹配，说明消息在传输途中被改动过。其核心计算结构在 RFC 2104 中定义，广泛用于 MQTT、CoAP 的安全扩展、设备与平台间的 API 签名校验等场景。
HMAC 的安全前提有两个：共享密钥的保密性和所选哈希函数（如 SHA-256）的碰撞抵抗性。与数字签名相比，HMAC 的优势在于计算开销极小，不需要公钥基础设施（PKI），非常适合主频不过几十 MHz、内存以 KB 计的 MCU 节点。
工程上需要注意密钥分发与轮换。HMAC 的“共享密钥”意味着每个设备必须与平台事先协商一个唯一密钥。如果所有设备共用同一个密钥，一台设备被攻破，整条防线立刻瓦解。IoT DC3 的多租户平台上，设备密钥通常与租户 ID 绑定，支持定期自动轮换，确保单个设备泄露不会扩大波及范围。
数字签名的适用场景
数字签名（Digital Signature）是另一种完整性校验方案，区别在于它使用非对称密钥对：发送方用私钥签名，接收方用对应的公钥验签。公钥可以公开分发，不需要提前共享秘密，因此天然解决了密钥分发难题。
但代价也很明确：非对称签名运算比 HMAC 慢一到两个数量级，签名数据更长。以 ECDSA（椭圆曲线数字签名算法，Elliptic Curve Digital Signature Algorithm）为例，签名结果通常会比 HMAC 输出多出几十字节。对于高频率遥测数据，每帧报文都做一次签名是不现实的。
工程上的分界线很清晰：高价值、低频率、后果严重的控制指令（如远程固件更新、紧急停机），应使用数字签名——签了名就能提供可信的“不可否认性”。高频遥测用 HMAC 压低计算成本。两种机制并非互斥，可以混合使用。
防重放：时间戳、序列号与 Nonce
完整性校验能保证报文在传输后没有被改动，但无法区分“相同内容的新报文”和“被重放的旧报文”。防重放需要每一条报文携带一个“一次性标识”，接收方通过这个标识判断是否已经处理过。
三种常见方案各有侧重。时间戳方案实现简单、无需状态，但依赖时钟同步，窗口太宽容易被重放，太窄容易误拒。单调递增序列号不依赖时钟，可以精确到单条报文，但需要持久化状态，设备重启后如何续号、序号跳跃如何处理是工程难点。一次性随机数（Nonce）防重放最彻底，但需要额外的往返交互（挑战-响应），增加时延。
实际工程中，三种方案常混合使用。MQTT 5.0 规范在 CONNECT 报文中携带“会话过期时间”，配合 Broker 端维护的最大处理序号，就是一种时间戳与序列号的混合方案。需要澄清的是，会话过期本身只是清理会话状态的机制，并不等于防重放；防重放仍须依赖报文级的时间戳、序列号或 Nonce 校验。对于 CoAP（受限应用协议，Constrained Application Protocol）协议，IETF 标准化了 OSCORE（受限环境下的对象安全，Object Security for Constrained RESTful Environments），它在应用层对 CoAP 消息加密封装，并用受完整性保护的单调序列号在报文级实现防重放，机制见下文。
不要仅仅依赖传输层（TLS/DTLS）的会话有效期来实现防重放。TLS 会话可能持续几分钟甚至几小时，攻击者完全可以在会话有效期内捕获并重放报文。真正的重放防护必须在应用层或安全层（如 OSCORE）内实现。对于状态受限设备，还需要处理重启后序列号丢失的问题——通常的做法是在非易失内存（NVM，Non-Volatile Memory）中定期持久化递增序号，或采用“序列号+时间戳”的混合模式，让时间戳作为重启后的初始对齐点。
CoAP 的 OSCORE 机制
OSCORE 是专门为受限设备和受限网络设计的应用层安全协议，定义在 RFC 8613。它与 DTLS 的关键区别在于：DTLS 在传输层建立双向安全隧道，需要握手；而 OSCORE 直接在 CoAP 消息内部完成加密与认证，不依赖传输层状态。对于睡眠频繁、链路极不稳定的电池供电器件，这更合适——设备随时可以发出一条自包含的安全消息。防重放是它的内建能力：发送方把单调递增的序列号写入 CoAP 选项的 Partial IV 字段，与密文一起受 AEAD 完整性保护；接收方维护一个重放窗口，收到重复或过旧的 Partial IV 就直接丢弃。攻击者既不能篡改这个序列号（改了就过不了完整性校验），也不能把旧报文原样重放进窗口。为什么要强调这种“新鲜度”？因为加密只保护内容的不可读性，不保护时效性：一条三年前的加密报文解密后内容仍然正确，但早已作废；如果接收方不校验序列号，攻击者就可以“离线捕获、择机重放”。
在物联网系统中，完整性校验和重放防护是加密之外不可或缺的防线。HMAC 以较低的开销解决“数据是否被改过”，数字签名在关键控制场景提供不可否认性，时间戳、序列号和 Nonce 的组合则回答“数据是否来自此刻的合法请求”。OSCORE 等应用层安全协议将这些机制统一封装，让受限设备也能在无握手的情况下，发送一条自包含的、安全可验证的消息。选型时，应优先评估设备的计算能力、通信频次和网络稳定性，再决定采用哪种组合——而不是一味追求最“强”的加密方案。
8.3.3 网络分段与微隔离
前两节把重点放在了链路上：数据在传输中要加密，也要防止篡改和重放。但光守住链路仍然不够。攻击者一旦突破了某台设备，或者拿到了网络层的访问权限，就能在内网里自由横向移动，一台接一台地“跳”到关键系统上。物联网环境里这一点尤其致命——传感器、摄像头、网关混在同一个平坦网络里，一台被压制的设备就可能成为通往核心数据库的跳板。
横向移动（Lateral Movement）是攻击者从最初的突破口向高价值目标逐步渗透的手段。拿智能办公楼来假设：攻击者先通过一台未打补丁的IP摄像头进入内网，然后扫描同网段的其他设备，发现一台连接楼宇控制系统的网关，再从网关控制空调、电梯甚至门禁。如果整栋楼的所有设备都在同一个子网里，攻击者几乎不需要跨越任何防护就能把整个建筑的数字系统摸个遍。
网络分段解决的就是这个问题：把设备划分到不同的隔离区域，一个区域被突破后，攻击者无法直接访问其他区域。传统做法是用VLAN（虚拟局域网，Virtual Local Area Network）在二层网络上切分，或者用防火墙在三层做访问控制策略。但这在物联网场景下有两个短板。第一，物联网设备种类多、归属不同（有的归物业、有的归租户、有的归运营方），VLAN的静态配置跟不上动态变化。第二，即便分了VLAN，同一个VLAN内的设备之间还是默认能互相通信——VLAN只能阻挡跨子网的访问，却管不了同子网内设备间的横向移动。
所以，微分段（Micro-segmentation）的概念被带入物联网安全架构中。它的粒度比VLAN更细：不再是“哪个子网能访问哪个子网”，而是“哪个设备能访问哪个设备、哪个服务”。微分段的实现通常依赖于软件定义网络（SDN，Software-Defined Networking），由集中式的控制器下发细粒度的流量策略，两端设备之间的通信必须逐条被规则允许，否则默认阻断。流表规则可以基于五元组（源IP、目的IP、源端口、目的端口、协议）来制定，也可以叠加设备身份（设备证书序列号、物模型类型）来判断。
下面这个微隔离架构展示了一种常见的分层隔离模型。
微隔离落地的关键难题在策略编排。如果让运维人员为每一对可能的设备组合手工配置规则，一个中规模的园区就能产生数万条规则，很快变成一团乱麻。实际项目里通常将策略编排与物模型（如第3章所述）绑定——设备注册时声明自己的“类型”（温度传感器、摄像头、执行器）、“安全等级”（低、中、高）和“所属租户”，策略引擎基于这些声明自动生成规则。比如所有“低等级传感器”只允许向数据采集服务的指定端口发送数据，不允许对任何其他设备发起连接。
零信任（Zero Trust）架构在网络分段的基础上走得更远。NIST发布的零信任架构（SP 800-207）定义了核心原则：不信任任何请求的来源，无论它在网络内部还是外部；每次访问都必须经过身份验证、授权和加密验证，最小权限持续生效。SP 800-207 还把“决策”与“执行”拆开：策略决策点（PDP，Policy Decision Point）对每次访问做信任评估并给出允许或拒绝，策略执行点（PEP，Policy Enforcement Point）在数据路径上强制执行这个决定；落到物联网变体中，设备身份——证书、密钥、行为基线——就是信任评估最核心的输入之一。在物联网里实践零信任，意味着即便一台设备曾经合法入网，下一次通信时仍需重新证明自己——包括证书有效期检查、行为基线比对，或者在连续异常后自动拉入降级网络，只允许发基础遥测数据，禁止控制类命令。不过，把零信任全量部署到资源受限的设备上并不现实。完整的设备-策略引擎-控制器的三角认证循环在低功耗设备上很难跑通。一种务实的折中是只对“控制类命令”强制零信任决策，对传感器这类只读数据流保持轻量认证。
实际工程中，把物联网流量放到独立VPC（虚拟私有云，Virtual Private Cloud）或租户级网络空间里，已经是公有云IoT PaaS的标配做法。但在现场侧的设备网络里，微隔离的普及度远不如云侧。根本原因是现场网络设备（工业交换机、无线接入点）对SDN和微分段的支持参差不齐，很多老旧型号只认VLAN，不认识动态流表。一条务实的建议是：在新建项目里，优先选用支持OpenFlow或厂商私有微分段API的交换设备；已有的存量网络，至少要把设备按安全等级拆成几个VLAN，然后用防火墙在VLAN之间实施严格的白名单策略，这样虽然做不到逐设备隔离，但至少能挡住跨VLAN的大范围横向移动。
微隔离还有一个重要作用——限制蠕虫横向传播。Mirai 说明默认口令和可从互联网访问的管理面会把大量设备变成攻击资源。网络分段、东西向访问控制和出站限制可以缩小受感染设备的可达范围，但无法保证蠕虫“卡死在单台设备”：共享凭据、管理面、跳板机和错误规则仍可能形成路径。因此还要结合唯一凭据、补丁、资产发现和异常流量监测。