4、需求来源分析：法律法规（GDPR、CCPA）、行业标准（ISO 26262、IEC 62443）、客户要求
做嵌入式安全，最怕什么？
怕产品做完了，法务说「这不合规」。怕客户验收时，甩出一份几百页的安全需求清单。更怕出了安全事故，才发现当初根本没考虑某个标准。
我个人习惯，在项目启动的第一周，就把所有需求来源梳理清楚。说白了，安全需求不是工程师拍脑袋想出来的，它有三个明确的源头：法律法规、行业标准、客户要求。今天我们就一个一个拆开看。
4.1 法律法规：躲不开的红线
法律法规是强制性的。你不遵守，就不能卖，卖了就罚款。这不是选择题，是必答题。
4.1.1 GDPR（通用数据保护条例）
如果你做的是物联网设备，尤其是面向欧洲市场的，GDPR 是你绕不过去的大山。它主要管的是「个人数据」——用户的名字、位置、设备ID、生物特征，统统算。
嵌入式设备怎么体现 GDPR？我举几个实际例子：
- 数据最小化原则：你的传感器只需要温度数据，就别偷偷采集用户的活动轨迹。我在一个智能家居项目里见过，固件里居然埋了麦克风录音功能，说是「为了优化体验」——这要是被查到，罚金是年营收的4%。
- 存储加密：用户数据在设备本地存储时，必须加密。不能明文写在 Flash 里。我记得有个客户的产品，用 SPI Flash 存 Wi-Fi 密码，直接明文——我看了直摇头。
- 删除权（被遗忘权）：用户要求删除数据时，你的设备必须能安全擦除。不是简单标记删除，是物理级别的覆写或密钥销毁。
关键点：GDPR 要求「设计即隐私」（Privacy by Design）。这意味着安全需求必须在架构阶段就嵌入，而不是事后打补丁。
4.1.2 CCPA（加州消费者隐私法案）
CCPA 是美国加州的法规，影响力不亚于 GDPR。它给了用户更多控制权，比如：
- 用户有权知道企业收集了哪些个人信息
- 用户有权拒绝出售其个人信息
- 企业必须提供明确的「退出」机制
对嵌入式设备来说，CCPA 意味着你的设备必须支持「数据分类」和「审计日志」。我曾经帮一个客户整改过他们的智能音箱固件——为了满足 CCPA，我们不得不加了一个硬件开关，物理断开麦克风。嗯，这招虽然粗暴，但合规。
| 法规 | 核心要求 | 嵌入式影响 |
|---|---|---|
| GDPR | 数据最小化、加密、删除权 | 存储加密、安全擦除、隐私设计 |
| CCPA | 数据知情权、退出机制 | 审计日志、物理开关、数据分类 |
注意：不要以为你的设备不联网就没事。很多嵌入式设备通过网关上传数据，网关一旦接入互联网，GDPR/CCPA 就适用。我曾经见过一个工业传感器项目，设备本身不联网，但数据通过 4G 网关上传——结果网关固件里没有任何隐私保护措施，被客户直接打回。
4.2 行业标准：安全基线
行业标准不是法律，但它是行业共识。你不遵守，客户不买账，出了事保险公司不赔。我个人觉得，标准其实是帮你省事的——它告诉你「别人踩过的坑，你别再踩了」。
4.2.1 ISO 26262（功能安全）
ISO 26262 是汽车行业的功能安全标准。它关注的是「系统故障会不会导致人身伤害」。比如刹车系统、转向系统、安全气囊——这些出了错是要命的。
安全需求怎么从 ISO 26262 里提取？我习惯从 ASIL 等级入手：
- ASIL A：轻微伤害，比如车窗控制
- ASIL B：中等伤害，比如车灯控制
- ASIL C：严重伤害，比如刹车辅助
- ASIL D：致命伤害，比如转向、制动
每个 ASIL 等级对应不同的安全机制要求。举个例子，ASIL D 要求硬件冗余（比如双核锁步），而 ASIL A 可能只需要软件自检就够了。
我曾经参与过一个 ADAS（高级驾驶辅助系统）项目，摄像头模块的 ASIL 等级是 B。我们当时在需求文档里明确写了：
// 安全需求示例：ISO 26262 ASIL B
// 1. 每帧图像必须进行 CRC 校验
// 2. 检测到 CRC 错误时，必须在 10ms 内进入安全状态
// 3. 安全状态：输出默认值（0x00），并触发故障指示灯我的经验：ISO 26262 的需求一定要可测试。不要写「系统应足够安全」这种废话。要写「当主处理器故障时，备份处理器在 5ms 内接管控制」。这样测试工程师才知道怎么测。
4.2.2 IEC 62443（工业通信网络安全）
IEC 62443 是工业自动化和控制系统的安全标准。它关注的是「网络攻击会不会导致生产停摆或设备损坏」。
这个标准把安全等级分为 SL 1 到 SL 4：
- SL 1：防止随意攻击
- SL 2：防止简单工具攻击
- SL 3：防止复杂工具攻击
- SL 4：防止国家级攻击
对嵌入式工程师来说，IEC 62443 最直接的影响是：
- 安全启动：固件必须签名验证，防止被篡改
- 安全更新：OTA 更新必须加密传输，且回滚保护
- 访问控制：设备必须支持用户认证和权限分级
我记得有个 PLC（可编程逻辑控制器）项目，客户要求达到 SL 2。我们当时在需求里写了：
// IEC 62443 SL 2 安全需求
// 1. 所有固件更新包必须使用 RSA-2048 签名
// 2. 设备只接受签名有效的更新包
// 3. 更新失败时，必须回滚到上一个可用版本
// 4. 本地调试接口（JTAG/SWD）必须在量产时禁用避坑指南：我曾经见过一个团队，为了赶进度，把安全启动的签名验证跳过了，想着「后期再补」。结果产品部署后，被攻击者注入了恶意固件，整个产线停了三天。嗯，从那以后，我再也不敢把安全需求排到「后期」了。
4.3 客户要求：最直接的输入
法律法规和行业标准是「通用要求」，而客户要求是「定制要求」。客户可能不懂技术，但他知道自己要什么。
客户要求通常来自：
- 招标书（RFP）：里面会明确写「设备必须支持 TPM 2.0」「必须通过 FIPS 140-2 认证」
- 安全问卷：大客户会发一份几十页的安全问卷，逐条确认你的安全能力
- 历史问题：客户之前被攻击过，就会特别强调某个安全点
我举个例子。有个做医疗设备的客户，要求我们的嵌入式模块必须支持「防篡改检测」。为什么？因为他们之前的产品被人在现场拆开，替换了传感器芯片，导致数据造假。
于是我们在需求里加了：
// 客户定制需求：防篡改检测
// 1. 外壳打开时，触发物理开关中断
// 2. MCU 检测到中断后，立即擦除密钥存储区
// 3. 设备进入锁定状态，需管理员解锁才能恢复你看，这个需求既不是 GDPR 要求的，也不是 ISO 26262 规定的，但客户就是需要。你不做，单子就丢了。
我的建议：客户要求一定要写进安全需求规格书，并且标注来源。我习惯用表格来管理：
| 需求编号 | 需求描述 | 来源 | 优先级 |
|---|---|---|---|
| SEC-001 | 固件更新包必须签名验证 | IEC 62443 SL 2 | 高 |
| SEC-002 | 用户数据存储必须 AES-256 加密 | GDPR | 高 |
| SEC-003 | 外壳打开时触发密钥擦除 | 客户要求（医疗设备） | 中 |
| SEC-004 | 系统故障时 10ms 内进入安全状态 | ISO 26262 ASIL B | 高 |
4.4 三者如何融合？
你可能会问：这三个来源有冲突怎么办？
我遇到过。GDPR 要求数据可删除，但 ISO 26262 要求故障日志不可篡改。这两个需求放在一起，怎么解？
我的做法是：
- 优先级排序：法律法规 > 行业标准 > 客户要求。法律是红线，不能碰。
- 需求分解：把冲突的需求拆到不同模块。比如故障日志用硬件安全模块（HSM）存储，用户数据用加密 Flash 存储。删除用户数据时，只擦除加密密钥，不影响日志。
- 和客户沟通：如果客户要求与法规冲突，一定要书面告知客户风险。我曾经有个项目，客户要求「所有数据永久保留」，但 GDPR 不允许。我们发了正式的风险评估报告，客户最终妥协了。
最后说一句：安全需求分析不是一次性的工作。法规会更新，标准会修订，客户要求会变。我习惯在每个迭代开始前，重新审视一遍需求来源。嗯，这习惯帮我避免了好几次合规事故。