3、安全需求分类：功能安全需求、信息安全需求、隐私保护需求、可靠性需求

做嵌入式安全这么多年，我见过不少团队一上来就埋头写代码，结果到测试阶段才发现需求漏了一大片。为什么会这样？说白了，就是没把安全需求分清楚。

我个人习惯把安全需求分成四大类：功能安全、信息安全、隐私保护、可靠性。这四类不是孤立的，它们经常交织在一起。但分清楚，你才能写出靠谱的规格文档。

3.1 功能安全需求

功能安全，说白了就是「系统出故障时，不能伤人」。它关注的是随机硬件失效和系统失效带来的风险。

我在项目中遇到过最典型的例子：汽车刹车系统的电子控制单元。如果芯片突然死机，刹车不能失效，必须进入安全状态。

写功能安全需求时，我建议你关注以下几点：

• 安全目标：系统在什么故障下必须做什么。比如「当主电源掉电时，备份电源必须在5ms内接管」。
• 故障检测机制：怎么发现故障？比如看门狗定时器、ECC校验、双核锁步。
• 故障响应时间：从故障发生到系统进入安全状态，允许的最大时间。
• 安全状态定义：什么是安全状态？比如电机停止、阀门关闭、输出置为高阻。

3.2 信息安全需求

信息安全，关注的是「坏人进不来、数据拿不走」。它对抗的是恶意攻击。

你想想看，现在的嵌入式设备联网后，攻击面有多大？从物理接口到无线通信，从固件升级到云端交互，处处都是风险点。

信息安全需求通常包括：

• 身份认证：谁可以访问设备？怎么证明身份？比如要求使用证书双向认证。
• 数据加密：敏感数据在传输和存储时，必须加密。比如AES-256加密存储密钥。
• 安全启动：固件启动时，必须验证签名，防止被篡改的固件运行。
• 安全更新：固件升级包必须签名，且要防回滚攻击。
• 访问控制：不同角色有不同的权限。比如调试接口在生产后必须锁死。

写信息安全需求时，我建议你参考STRIDE威胁建模的结果。每个威胁都要对应一条或几条安全需求。

3.3 隐私保护需求

隐私保护，关注的是「用户的个人信息不被滥用」。它和信息安全有重叠，但侧重点不同。

信息安全防的是外部攻击，隐私保护防的是「合法收集后的滥用」。你想想看，设备收集了用户的心率数据，即使加密存储了，但如果你把数据卖给第三方，那就是隐私问题。

隐私保护需求包括：

• 数据最小化：只收集业务必需的数据。比如智能灯泡不需要知道用户的位置。
• 数据匿名化：存储或传输时，去除个人标识信息。比如用哈希后的ID代替真实用户名。
• 用户知情同意：收集数据前必须明确告知用户，并获得同意。
• 数据删除机制：用户有权要求删除自己的数据。设备必须支持「恢复出厂设置并擦除所有用户数据」。
• 本地处理优先：尽量在设备本地处理数据，不上传云端。

3.4 可靠性需求

可靠性，关注的是「系统长时间稳定运行，不出错」。它和安全的关系很密切——一个不可靠的系统，迟早会变成不安全系统。

我见过太多案例：因为内存泄漏导致系统崩溃，然后安全机制没来得及触发，直接出事故。

可靠性需求包括：

• 平均无故障时间（MTBF）：系统应该能连续运行多少小时不出故障。
• 故障恢复时间：系统崩溃后，多久能自动恢复。比如要求看门狗复位后3秒内恢复正常工作。
• 冗余设计：关键模块要有备份。比如双电源供电、双传感器冗余。
• 降级运行：部分模块故障时，系统不能完全瘫痪，要能降级运行。比如显示屏坏了，但核心控制功能还能用。
• 环境适应性：在规定的温度、湿度、振动范围内，系统必须正常工作。

需求类型	关注点	典型例子
功能安全	故障时的安全行为	刹车失效时自动进入紧急制动
信息安全	防止恶意攻击	固件升级必须签名验证
隐私保护	防止数据滥用	用户数据默认不上传云端
可靠性	长时间稳定运行	MTBF ≥ 100,000小时

3.5 四类需求的交叉与整合

实际项目中，这四类需求经常交织在一起。举个例子：

一个医疗输液泵：

• 功能安全：输液速度异常时，必须立即停止并报警。
• 信息安全：处方数据必须加密传输，防止被篡改。
• 隐私保护：患者的姓名、病历数据不能明文存储。
• 可靠性：电池供电下必须连续工作至少8小时，不能死机。

你看，少写哪一条，这个产品都可能有致命问题。

嗯，分类不是目的，目的是把需求写全、写准。下一章我会讲怎么把这些需求写成可验证的规格条目。