3. 工业IoT典型架构与攻击面
工业IoT系统不是一台设备，也不是一个平台，而是一条从现场物理过程一直延伸到业务决策的完整链路。面试中，当被问到“工业IoT的典型架构是什么”时，如果只回答“感知层、网络层、平台层、应用层”四层名词，通常只能拿到及格分。真正拉开差距的是：你能否说清每一层有哪些真实资产、这些资产通过什么接口暴露、攻击者会沿什么路径进入，以及你用什么方法把威胁变成可验证的结论。本节就围绕这条主线展开。
一、先建立一条可复用的架构参照
工业IoT的常见分层可以这样定义，全文保持一致：
- 边缘层：现场设备、传感器、执行器、PLC/RTU、工业网关、边缘计算节点。它直接连接物理世界，承担采集、控制、协议转换和本地预处理。
- 网络层：现场总线、工业以太网、TSN、4G/5G、NB-IoT、LoRa、VPN、防火墙、交换机和路由设备。它负责把边缘数据可靠地送到平台。
- 平台层：IoT接入网关、消息中间件（如MQTT Broker、Kafka）、设备管理、时序数据库、规则引擎、数字孪生、AI推理服务。它负责设备接入、数据汇聚与能力开放。
- 应用层：SCADA/HMI、MES、ERP、远程运维App、数据大屏、开放API。它面向操作员、工程师和业务系统。
这条链路有一个关键特征：信任是逐层传递的。边缘设备一旦被控，伪造的数据会穿过网络层进入平台，再被应用层当作真实工况展示或触发决策。因此威胁建模不能只盯一层，而要沿数据流和控制流双向追踪。
二、边缘层：物理可达性与弱协议是最大暴露面
边缘层的资产暴露通常来自三类接口：调试口（USB、串口、JTAG）、管理口（Web、Telnet、SSH）和现场总线口（Modbus、Profinet、EtherNet/IP）。很多PLC和网关出厂默认开启Modbus TCP 502端口且无认证，攻击者只要能到达网络，就可以直接读写寄存器。
一个可操作的教学示例：假设某边缘网关的Modbus TCP映射中，保持寄存器40001保存“反应釜温度设定值”，缩放系数为0.1，单位℃。正常写入值850表示85.0℃。若攻击者写入1200，即把设定值改为120.0℃，而联锁逻辑若只在上位机实现、未在PLC内做硬限幅，就可能造成超温。防御动作不是“加防火墙”一句话，而是：在PLC梯形图或安全逻辑中增加IF setpoint > 100.0 THEN setpoint := 100.0的硬限幅，并在网关上配置Modbus白名单，只允许指定主站IP访问功能码03/06，拒绝05/15等线圈写操作。
边缘层威胁建模建议用“资产—接口—能力”三列清单推进。资产填“1号网关”，接口填“502/TCP、80/TCP、USB”，能力填“可读写寄存器、可上传固件、可改网络配置”。能力列直接决定攻击后果，比单纯列漏洞更有面试说服力。
三、网络层：横向移动与协议隧道是核心风险
网络层的暴露不在“有没有防火墙”，而在区域划分是否与业务流一致。典型问题是：办公网与生产网共用一台三层交换机，仅靠VLAN隔离，而VLAN间路由ACL配置过宽，导致办公终端可直达PLC网段。
实际排查时，可以在一台办公PC上执行：
# 示例：探测生产网段常见工业端口
nmap -Pn -p 502,102,44818,1883,8883 10.10.20.0/24
若返回502/tcp open modbus，说明Modbus可达；若返回102/tcp open iso-tsap，说明西门子S7通信可达。这两个结果就足以支撑“办公网到生产网缺少有效隔离”的判断。修复方向是：在工业防火墙或交换机ACL上，只允许工程师站IP访问PLC的102端口，且限定在维护时段；同时把MQTT 1883改为8883并启用双向TLS，避免明文凭据被嗅探。
网络层威胁建模要特别关注协议隧道：攻击者可能把C2流量封装进Modbus或OPC UA的合法字段中。检测思路不是封端口，而是在工业IDS中建立“功能码—源IP—目标IP—时间”的基线，例如某工程师站平时只在9:00–18:00写PLC，若凌晨3点出现大量功能码16（写多寄存器），就应告警。
四、平台层：身份、消息与API是三条主攻击路径
平台层资产包括MQTT Broker、设备影子、规则引擎、时序库和对外开放API。常见暴露有：Broker允许匿名接入、设备凭据硬编码在固件中、规则引擎可被注入恶意SQL或脚本、API缺少对象级授权。
以MQTT为例，一个可复现的检查过程是：用mosquitto_sub尝试匿名订阅通配符主题。
mosquitto_sub -h iot.example.com -p 1883 -t '#' -v
若无需用户名密码即可收到factory/line1/temperature 78.5这类消息，说明Broker未启用认证，且主题未做ACL隔离。正确做法是：为每台设备分配独立Client ID和证书，ACL限定其只能发布factory/line1/{deviceId}/telemetry、只能订阅factory/line1/{deviceId}/cmd，禁止使用#和+通配符跨设备订阅。
平台层威胁建模的重点是信任边界：设备上报的数据在进入规则引擎前是否经过校验？如果规则引擎直接把payload.temperature拼进SQL，攻击者伪造一条temperature=1; DROP TABLE telemetry;--的消息就可能造成破坏。防御手段是参数化查询、JSON Schema校验和字段白名单。
五、应用层：越权与数据泄露往往最容易被忽视
应用层直接面向人和业务，暴露面包括Web登录、API令牌、报表导出和第三方集成。典型问题是水平越权：操作员A能通过修改URL中的deviceId查看操作员B负责的产线数据。
验证方法很直接：用A的会话令牌请求GET /api/v1/devices/1002/telemetry，若返回200且包含数据，而A本应只被授权访问1001，则存在越权。修复要在服务端做对象级授权校验，而不是只在前端隐藏按钮。
应用层威胁建模应把“角色—资源—操作”写成矩阵。例如角色“巡检员”对资源“设备遥测”只有read权限，对“控制指令”无权限；角色“工程师”对“控制指令”有write但需二次确认。矩阵中任何空白格都应是默认拒绝。
六、把四层串成一次威胁建模演练
面试中常被要求“现场给一个场景做威胁建模”。可以按以下顺序推进，不必套固定模板：
- 画数据流：从传感器→网关→Broker→规则引擎→SCADA→API。
- 标信任边界：网关到Broker、Broker到规则引擎、API到数据库。
- 对每个边界问三个问题：谁能跨过？跨过需要什么凭据？跨过后能做什么？
- 把答案写成可验证的测试用例，例如“匿名MQTT订阅是否成功”“办公网能否nmap到502”。
- 给出修复优先级：先做网络隔离和身份认证，再做协议深度检测和API授权。
下面给出一份可直接填写的威胁建模工作底稿示例，字段只保留工业IoT语境下真正必要的项：
| 层级 | 资产/接口 | 暴露方式 | 攻击能力 | 验证方法 | 修复动作 |
|---|---|---|---|---|---|
| 边缘层 | PLC 502/TCP | 无认证Modbus | 改写寄存器 | nmap + 功能码06写入 | PLC硬限幅 + 网关白名单 |
| 网络层 | 办公网到生产网 | VLAN间ACL过宽 | 横向扫描与利用 | nmap 10.10.20.0/24 | 收紧ACL，仅放行工程师站 |
| 平台层 | MQTT 1883 | 匿名订阅 | 窃取全厂遥测 | mosquitto_sub -t '#' | 双向TLS + 主题ACL |
| 应用层 | GET /devices/{id} | 水平越权 | 读取他人产线数据 | 替换id重放请求 | 服务端对象级授权 |
这张表的价值在于：每一行都能落到一个具体命令或请求上，面试官追问“你怎么证明”时，你可以直接说出验证动作和预期结果。威胁建模不是写文档，而是把“可能被攻击”变成“可被验证、可被修复”的工程结论。
最后强调一个判断依据：如果一次威胁建模结束后，你无法指出至少一个具体的IP、端口、主题或API路径，也无法给出一个可执行的验证命令，那么这次建模大概率还停留在概念层。工业IoT安全工程师的核心能力，正是把四层架构中的抽象风险，翻译成现场可检查、可复现、可闭环的具体动作。