2. IoT供应商类型与安全边界识别

IoT项目的供应链很少由单一厂商完成。一个典型的智能门锁产品，可能由深圳的硬件模组厂提供主控板，第三方固件团队开发RTOS应用，通信模组厂提供Wi-Fi/BLE二合一模块，云平台厂提供设备接入与OTA服务，最后由系统集成商完成现场部署与调试。每一类供应商掌握的数据、代码、接口和权限都不同，安全责任边界也因此不同。准入评估的第一步，不是急着发问卷，而是先把供应商分类，再逐类画出安全边界。

五类供应商及其安全责任边界

硬件模组供应商提供主控芯片、传感器、PCB模组或整机主板。其安全责任集中在：芯片是否支持安全启动与TrustZone、调试接口（JTAG/SWD）是否可被物理关闭、Flash是否支持加密读写、模组是否预留安全芯片（SE）或TPM位置。边界风险在于：模组出厂固件可能带默认调试口令，或预留未文档化的测试引脚。评估时应要求提供模组安全能力清单，并抽样验证调试口在生产版本中是否已锁定。

固件供应商交付设备端运行代码，包括Bootloader、RTOS/Linux镜像、应用逻辑。责任边界是：固件签名与校验机制、安全启动链是否完整、是否存在硬编码密钥、OTA升级包是否验签。风险最集中的是“固件里藏了什么”——第三方SDK、开源组件版本、调试后门。评估时应要求SBOM（软件物料清单），并对固件镜像做静态扫描，检查是否含默认口令、调试命令或未声明的外联域名。

云平台供应商提供设备接入、消息路由、数据存储、OTA下发和账号体系。责任边界覆盖：设备身份认证方式（一机一密/一型一密）、传输加密（TLS版本与套件）、API鉴权与租户隔离、数据留存与跨境策略。接口风险在于：平台API若仅用静态Token且无频率限制，攻击者一旦获取Token即可批量伪造设备。评估时应核查设备接入鉴权流程、API权限模型，以及平台是否支持设备证书吊销。

通信模组供应商提供蜂窝（NB-IoT/Cat.1）、Wi-Fi、BLE、LoRa等连接能力。责任边界是：模组固件是否可升级、AT命令集是否暴露敏感操作、SIM/eSIM管理是否安全、模组是否支持安全传输（如TLS卸载）。风险点在于：部分模组AT通道可被用于读取IMEI、修改服务器地址，甚至绕过应用层直接发数据。评估时应确认AT命令白名单机制，以及模组固件升级是否验签。

集成服务供应商负责现场安装、网络配置、平台对接和运维。其安全责任最容易被忽视：施工账号权限过大、调试Wi-Fi密码长期有效、现场设备标签泄露接入信息。边界风险是“人”带来的：集成商工程师可能持有平台高权限账号，离场后未回收。评估时应要求集成商提供账号生命周期管理流程，并约定项目结束后权限回收时限。

接口风险：边界上的“接缝”最脆弱

把五类供应商放在一起看，真正的风险不在某一类内部，而在它们之间的接口上。设备侧与通信侧之间是AT命令或串口协议，通信侧与云侧之间是MQTT/HTTPS，云侧与集成侧之间是运维API和账号。每一条接缝都可能成为攻击路径。

以AT命令接口为例。某NB-IoT模组支持AT+CGDCONT修改APN、AT+QIACT激活PDP上下文。如果应用层没有对AT通道做白名单，攻击者通过串口注入即可把设备指向恶意服务器。准入评估时，应要求通信模组供应商提供AT命令安全分级表，明确哪些命令在生产固件中被禁用或需鉴权。

再看云平台API。假设平台提供GET /v1/devices/{deviceId}/shadow读取设备影子。若鉴权仅依赖一个长期有效的API Key，且无IP白名单和频率限制，那么集成商离职人员手中的Key就是一颗定时炸弹。评估时应核查：是否支持短期Token、是否绑定设备证书、是否有调用审计日志。

准入评估的落地做法

分类完成后，可以按“边界清单”逐项核查。以下是一份可直接使用的供应商安全边界核查表（示例字段，可根据项目裁剪）：