3、边缘AI部署安全威胁模型：常见攻击面（物理、网络、软件、供应链）、威胁建模方法与风险等级评估
边缘AI系统与云端AI系统最大的差异在于：算力下沉、环境暴露、物理可接触、网络拓扑复杂化。一台部署在工厂车间、无人零售柜、路侧机箱或医疗终端内的边缘AI设备，其攻击面远大于集中式数据中心内的GPU服务器。攻击者可能从物理接口撬开外壳、通过无线网络嗅探通信、利用固件漏洞植入后门，甚至在设备出厂前的供应链环节就完成预植入。因此，构建边缘AI安全部署体系的第一步，不是堆砌安全产品，而是建立一套完整的威胁模型——明确“谁可能攻击、从哪里攻击、用什么手段、造成什么后果”，并据此对风险进行量化分级，从而决定安全资源的投入优先级。
3.1 边缘AI四大攻击面深度拆解
3.1.1 物理攻击面：设备暴露带来的直接风险
边缘AI设备通常部署在无人值守或低监管环境中，物理接触是区别于云端安全的最大特征。攻击者一旦获得物理访问权限，可以绕过所有软件防护，直接操作硬件层。常见的物理攻击路径包括：
- 调试接口暴露：开发板上常见的JTAG/SWD调试口、UART串口如果未在量产固件中禁用，攻击者可通过调试器直接读取内存、修改寄存器、提取固件或注入代码。例如，某工业视觉检测设备在出厂时保留了UART root shell，攻击者仅需一根USB转TTL线即可获得root权限。
- 存储介质拆解：eMMC、NAND Flash、SD卡等存储芯片可被焊接下来，通过编程器读取全部数据，包括模型文件、密钥、配置信息。即使设备启用了文件系统加密，若密钥存储在同一个芯片中，攻击者仍可通过冷启动攻击或直接读取密钥分区破解。
- 侧信道攻击：通过功耗分析、电磁辐射分析、时序分析等手段，攻击者可以推测设备内部运行的算法和密钥。对于执行AES加密或模型推理的设备，侧信道攻击在实验室条件下已被证明可提取密钥或模型参数。
- 接口滥用：USB接口、SD卡槽、网口等外部接口可能被用于插入恶意设备（如BadUSB、网络分流器），实现数据窃取或中间人攻击。
3.1.2 网络攻击面：边缘节点的通信暴露
边缘AI设备通常通过有线或无线网络与云端、其他边缘节点、终端传感器通信。网络攻击面包括：
- 协议层攻击：边缘设备常用的MQTT、HTTP/HTTPS、RTSP、Modbus TCP等协议，若未正确配置TLS加密或认证机制，攻击者可通过中间人攻击（MITM）截获、篡改或重放数据。例如，某智慧园区的人脸识别闸机使用明文HTTP传输比对结果，攻击者在同一WiFi下可轻松伪造“放行”响应。
- 无线通信攻击：WiFi的WPA2漏洞、蓝牙的配对劫持、4G/5G的伪基站攻击，都可能让攻击者接入边缘设备的通信链路。对于使用LoRa、ZigBee等物联网协议的设备，其加密强度往往较弱，更容易被破解。
- 暴露的服务端口：边缘设备上运行的SSH、VNC、Web管理界面、推理服务API等，如果未限制访问来源或使用弱口令，可能被远程直接利用。Shodan等搜索引擎上存在大量暴露在公网的边缘AI设备，默认密码或空密码问题屡见不鲜。
- DDoS与资源耗尽：边缘设备算力有限，面对SYN Flood、HTTP慢速攻击等网络层攻击时，可能因资源耗尽而停止推理服务，影响业务连续性。
3.1.3 软件攻击面：系统与应用的漏洞利用
软件攻击面涵盖操作系统、容器运行时、推理框架、应用代码及模型文件本身。边缘AI设备的软件栈通常比云端更精简，但漏洞密度并不低：
- 容器与虚拟化逃逸：边缘设备常使用Docker或containerd部署推理服务。容器逃逸漏洞（如CVE-2022-0492、CVE-2023-2640）可让攻击者从容器内部突破到宿主机，进而控制整个设备。
- 推理框架漏洞：TensorFlow Lite、ONNX Runtime、OpenVINO等推理引擎在解析模型文件时，可能存在缓冲区溢出、整数溢出或反序列化漏洞。攻击者可以构造恶意模型文件，在设备加载模型时触发远程代码执行。
- 模型文件投毒与篡改：模型文件本身是“可执行代码”。攻击者若能在模型传输或存储过程中篡改权重，可导致推理结果被定向误导（后门攻击），或直接植入恶意逻辑。
- 权限提升与持久化：边缘设备上的应用通常以root或高权限运行，一旦某个低权限进程被攻破，攻击者可以快速提权并植入持久化后门（如修改systemd服务、crontab、启动脚本）。
3.1.4 供应链攻击面：从源头植入的隐蔽威胁
供应链攻击是边缘AI领域最隐蔽、最难检测的攻击面。攻击者不需要接触目标设备，而是在设备生产、软件分发或模型交付环节提前植入恶意代码：
- 硬件供应链：芯片、模组、PCB板在制造或组装过程中可能被植入硬件木马（如额外的逻辑电路、被修改的Boot ROM）。这类攻击极难发现，需要专业的硬件逆向能力。
- 固件与驱动供应链：设备厂商使用的第三方BSP（板级支持包）、WiFi/BT驱动、安全芯片固件，如果来自不可信渠道，可能包含后门。例如，某厂商使用的WiFi模块固件中被发现存在硬编码后门账号。
- 软件镜像与依赖供应链：Docker镜像、Python包、npm包、系统镜像等，若未校验来源完整性，可能被投毒。攻击者将恶意代码伪装成正常依赖，在设备构建或更新时被拉取执行。
- 模型供应链：预训练模型可能来自第三方开源社区或商业供应商，模型文件本身可能被植入后门（如特定输入触发错误输出），或包含恶意代码（利用框架解析漏洞）。
3.2 威胁建模方法：从STRIDE到攻击树
3.2.1 STRIDE威胁分类法
STRIDE是微软提出的威胁建模框架，将威胁分为六类：Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。针对边缘AI设备，STRIDE的映射如下：
| STRIDE类别 | 边缘AI典型场景 | 示例 |
|---|---|---|
| Spoofing | 设备身份伪造、模型来源伪造 | 攻击者伪造边缘节点身份接入管理平台，下发恶意模型 |
| Tampering | 模型文件篡改、配置篡改、固件篡改 | 篡改路侧摄像头AI识别模型，使特定车辆无法被识别 |
| Repudiation | 操作日志缺失、审计记录被清除 | 攻击者删除推理日志，导致无法追溯异常行为 |
| Information Disclosure | 模型参数窃取、敏感视频/图像泄露 | 通过侧信道提取模型权重，或从存储芯片读取训练数据 |
| Denial of Service | 推理服务中断、资源耗尽 | 发送大量无效推理请求，导致GPU/NPU算力耗尽 |
| Elevation of Privilege | 容器逃逸、内核提权 | 利用推理框架漏洞从普通用户提权到root |
3.2.2 攻击树建模与攻击面映射
攻击树（Attack Tree）以攻击目标为根节点，逐层分解攻击路径。对于边缘AI设备，可以建立如下攻击树分支：
目标：获取边缘设备root权限并持久化
├── 物理途径
│ ├── 拆解外壳，连接JTAG调试口
│ ├── 读取eMMC芯片，提取root密码哈希
│ └── 插入恶意USB设备，触发自动运行
├── 网络途径
│ ├── 扫描开放端口，利用SSH弱口令
│ ├── 中间人攻击，篡改OTA升级包
│ └── 利用Web管理界面命令注入
├── 软件途径
│ ├── 容器逃逸（利用CVE-2023-XXXX）
│ ├── 恶意模型文件触发缓冲区溢出
│ └── 利用未修补的内核漏洞
└── 供应链途径
├── 使用被投毒的Docker镜像
├── 第三方SDK中预置后门
└── 固件更新包被替换攻击面映射则是将攻击树中的每条路径对应到具体的系统组件（硬件接口、网络端口、软件模块、数据流），形成一张“攻击面清单”。这张清单是后续安全测试和防护措施部署的基础。
3.3 风险等级评估：量化可能性与影响
3.3.1 DREAD风险评估模型
DREAD模型从五个维度对每个威胁进行打分（1-10分），最终计算风险值：
- Damage（损害）：威胁成功造成的损失程度，如数据泄露范围、设备失控后果。
- Reproducibility（可复现性）：攻击能否稳定复现，复现难度越低分数越高。
- Exploitability（可利用性）：攻击者实施攻击的技术门槛，门槛越低分数越高。
- Affected Users（受影响用户）：受影响的设备数量或用户范围。
- Discoverability（可发现性）：漏洞被攻击者发现的难易程度，越容易被发现分数越高。
风险值 = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5。根据分值划分等级：9-10为严重（Critical），7-8为高危（High），4-6为中危（Medium），1-3为低危（Low）。
3.3.2 风险等级评估矩阵
除了DREAD，还可以使用经典的“可能性×影响”矩阵。对于边缘AI场景，建议将可能性分为五级（极低、低、中、高、极高），影响也分为五级（可忽略、轻微、中等、严重、灾难性）。例如：
| 威胁场景 | 可能性 | 影响 | 风险等级 | 优先级 |
|---|---|---|---|---|
| 物理拆解读取存储芯片 | 中（设备在公共场所） | 严重（模型与密钥泄露） | 高 | P1（立即处理） |
| 网络中间人篡改推理结果 | 高（WiFi环境） | 中等（业务误判） | 中高 | P2（尽快处理） |
| 容器逃逸获取root权限 | 低（需先攻破应用） | 灾难性（设备完全失控） | 中 | P2（尽快处理） |
| 供应链镜像投毒 | 极低（需控制镜像仓库） | 严重（批量设备被控） | 中低 | P3（计划处理） |
3.4 实战案例：某智慧零售边缘AI设备的威胁建模与风险处置
3.4.1 背景与约束
某连锁零售企业计划在500家门店部署边缘AI设备，用于实时识别货架缺货、顾客动线和异常行为。设备硬件为RK3588平台（8核CPU+6 TOPS NPU），运行Ubuntu 20.04 + Docker容器，推理框架为ONNX Runtime，模型文件通过OTA从云端下发。设备通过门店WiFi接入互联网，同时提供USB接口用于本地日志导出。安全团队需要在设备量产前完成威胁建模和风险评估，确定安全控制措施。
3.4.2 威胁建模过程
安全团队按照以下步骤执行：
- 数据流分析：绘制设备的数据流图，识别出摄像头输入、推理引擎、模型存储、OTA更新、日志上传、远程管理共6条主要数据流。
- STRIDE分类：对每条数据流应用STRIDE，共识别出23个潜在威胁点。
- 攻击树构建：针对“获取root权限”和“篡改模型”两个核心目标，构建攻击树，发现物理调试口、OTA更新通道、容器运行时是三大高风险路径。
- DREAD评分：对23个威胁点进行DREAD打分，其中8个威胁点风险值≥7，被列为高危。
3.4.3 关键风险与处置措施
| 风险项 | DREAD评分 | 处置措施 | 残余风险 |
|---|---|---|---|
| UART调试口暴露root shell | 8.2 | 量产固件中禁用UART调试口；外壳加防拆螺丝+拆机检测开关（触发后自动擦除密钥） | 低（需专业设备拆解） |
| OTA升级包被中间人篡改 | 7.8 | OTA包使用RSA-2048签名，设备端验签；升级通道使用TLS 1.3双向认证 | 低（需攻破签名私钥） |
| 容器逃逸漏洞 | 7.5 | 容器以非root用户运行；启用Seccomp和AppArmor；每月更新容器运行时版本 | 中（依赖漏洞披露速度） |
| 模型文件被篡改 | 7.1 | 模型文件使用HMAC-SHA256校验；模型存储在加密分区；加载前校验哈希 | 低（密钥与模型分离存储） |
3.4.4 实施结果与复盘
经过上述处置，高危风险从8项降至2项（容器逃逸和供应链镜像投毒），整体风险等级从“高”降至“中”。在后续的渗透测试中，测试团队尝试了物理拆解、网络嗅探、恶意模型注入等攻击方式，均未成功突破。复盘时发现两个值得改进的点：
- 供应链验证不足：最初未对Docker基础镜像进行漏洞扫描，后来引入Trivy扫描发现镜像中存在3个中危漏洞，及时修复。
- 日志审计缺失：设备本地日志未加密存储，攻击者若物理接触设备可读取敏感操作记录。后续增加了日志加密和定期上传云端。
3.5 常见误区与总结复盘
3.5.1 常见误区
- 误区一：只关注软件漏洞，忽视物理攻击。很多团队认为边缘设备“放在室内有监控”就安全，实际上物理接触是最高效的攻击路径。必须假设攻击者能接触设备，并据此设计防拆、加密、密钥隔离。
- 误区二：威胁模型“一次定终身”。设备固件更新、部署环境变化、新CVE披露都会改变威胁面。威胁模型应作为“活文档”，至少每季度或每次重大变更后更新。
- 误区三：风险评分过于主观。DREAD等模型的打分依赖评估者经验，不同团队可能给出差异很大的分数。建议由安全、运维、业务三方共同打分，并参考行业基线（如CVSS评分）校准。
- 误区四：忽略供应链环节。很多团队只关注设备运行时的安全，却忽略了设备出厂前、软件构建时的风险。供应链攻击一旦成功，影响范围往往是批量性的，且极难发现。