3. 设备安全基线设计与核查

在IoT Fleet中，设备类型往往横跨网关、IP摄像头、工业传感器、边缘控制器、车载终端等多类硬件，它们的操作系统、通信协议、资源约束和安全暴露面差异极大。如果对所有设备套用同一套安全配置，要么因约束过严导致业务不可用，要么因约束过松留下大量可被利用的入口。安全基线（Security Baseline）就是针对某一类设备，把“必须满足的安全配置状态”固化成可检查、可修复、可审计的规则集合。它不是一次性文档，而是设备全生命周期中持续被比对和收敛的目标状态。

一、基线设计的三个层次

一条可运营的基线通常由三层构成。第一层是设备身份与接入层，包括唯一设备标识、证书或密钥的签发与轮换、首次入网的可信引导、调试接口的关闭策略。第二层是系统与运行时层，包括固件版本下限、不必要的服务与端口、默认口令、日志与时间同步、只读文件系统或完整性校验。第三层是应用与数据层，包括本地数据加密、远程管理通道的加密与鉴权、敏感配置的访问控制、OTA升级包的签名校验。

设计基线时，先按“设备类型 + 固件大版本 + 部署场景”做分组。例如“网关类 / Linux / 现场边缘”和“摄像头类 / RTOS / 公共区域”应各自拥有独立基线。分组过粗会让规则无法落地，分组过细则维护成本急剧上升。一个实用的经验是：同一分组内的设备应能共享同一套检查脚本和同一份修复动作。

二、把安全要求写成可判定的规则

基线规则必须能被自动化工具判定为“合规”或“不合规”，而不是依赖人工理解。每条规则至少包含：规则ID、适用设备分组、检查对象、期望值、判定条件、严重级别、修复动作和例外说明。下面是一段示例规则片段，用于说明字段结构，参数为教学示例，并非真实设备实测值。

rule_id: IOT-GW-004
group: gateway/linux/edge
check: ssh_permit_root_login
expect: "no"
severity: high
remediation: set_sshd_config PermitRootLogin no && restart sshd
exception: 仅允许在隔离调试网段临时开启，需工单审批

规则中的“期望值”要尽量使用设备上可直接读取的配置项、文件内容、进程状态或接口返回值。例如检查“是否开放了23端口”，可以读取监听端口列表；检查“固件版本是否低于下限”，可以读取版本字符串并与白名单比较。对于无法直接读取的状态，应通过代理或网关侧采集间接证据，而不是把规则写成模糊描述。

三、自动化合规检查的执行链路

合规检查通常由设备侧轻量代理、网关侧采集器和管理侧规则引擎协同完成。设备侧代理负责执行本地检查脚本并上报结果；网关侧采集器负责汇总、缓存和断点续传；管理侧规则引擎负责将结果与基线比对，生成偏差事件。下图展示了这一数据流与判定关系，其中“偏差”会进入修复队列，而“合规”则进入审计记录。

四、偏差修复的三种策略

发现偏差后，并不是所有情况都适合立即自动修复。第一种是自动修复，适用于低风险、幂等、可回滚的配置项，例如关闭调试端口、修正日志级别、恢复默认拒绝策略。第二种是审批后修复，适用于可能影响业务连续性的操作，例如重启服务、更换证书、升级固件。第三种是仅告警不修复，适用于设备处于维护窗口、备件状态或已申请例外的情况。修复动作必须记录操作者、时间、原值、新值和执行结果，以便审计和回滚。

修复完成后应触发一次重检，确认偏差已消除。如果重检仍不通过，需要区分是修复动作未生效、设备离线，还是规则本身存在误判。对于批量设备，建议先在小范围灰度验证修复脚本，再逐步扩大范围，避免一次错误修复导致大面积设备失联。

五、基线运营中的常见问题

基线不是越严越好。过于严格的基线会导致大量例外申请，反而削弱规则权威性。建议按严重级别分层：高危项必须自动阻断或强制修复，中危项允许限期整改，低危项仅记录趋势。另一个常见问题是基线版本与固件版本脱节。设备升级后，原有检查项可能因路径或服务名变化而误报，因此每次固件大版本发布都应同步评审基线规则。

六、一个可复用的基线核查表示例

下表给出一个简化的基线核查表示例，字段和取值均为教学示例，用于说明如何把规则、检查方式和修复动作组织成可执行清单。

把这张表接入规则引擎后，每次巡检都会输出每台设备在每个规则上的合规状态。运营人员关注的不是单次结果，而是偏差率是否持续下降、高危偏差是否被及时清零、例外是否在有效期内关闭。当基线能够稳定收敛，设备群的整体安全水位才真正可度量、可管理。