3、项目需求分析：如何评估设备规模与安全等级、确定证书策略（CP/CPS）、合规性要求（如GDPR、等保）
需求分析这个阶段，说白了就是回答三个问题：你是谁？你要保护什么？别人要求你怎么保护？
我见过不少项目，一上来就选加密算法、挑HSM，结果做到一半发现设备数量预估少了十倍，或者合规审查根本过不了。嗯，咱们今天就把这块地基打扎实。
3.1 设备规模与安全等级评估
先聊设备规模。这可不是简单数个数就完事了。
核心原则：设备规模直接影响CA层级设计、密钥分发策略和运维自动化程度。安全等级则决定密钥长度、算法强度和生命周期管理粒度。
3.1.1 设备规模评估维度
我个人习惯从四个维度来评估：
| 维度 | 关键问题 | 影响范围 |
|---|---|---|
| 总量 | 当前多少台？3年后预计多少？ | CA性能、证书存储、CRL大小 |
| 增长率 | 是线性增长还是爆发式增长？ | 自动化注册流程、批量签发能力 |
| 生命周期 | 设备用多久？3年？10年？ | 证书有效期策略、密钥更新机制 |
| 地理分布 | 集中部署还是全球分散？ | OCSP响应器部署、离线CA策略 |
举个例子。我之前做过一个智能电表项目，客户说「大概10万台」。结果一调研，他们计划3年内覆盖全省，实际规模是500万台。你想想看，如果按10万台的规模设计CA，到第二年就得推倒重来。
我的经验：评估设备规模时，一定要把「最坏情况」乘以1.5到2倍。尤其是物联网项目，设备增长往往超出预期。我曾经吃过这个亏，后来学乖了。
3.1.2 安全等级划分
安全等级怎么定？我一般参考两个东西：设备自身能力和业务风险等级。
设备能力这块，说白了就是看它能不能干「重活」：
- L0 - 无安全芯片：纯软件实现，密钥存文件系统。适合传感器、简单执行器。
- L1 - 有TEE/SE：密钥硬件隔离，但计算能力有限。适合智能家居、工业控制器。
- L2 - 有HSM/TPM：专用安全芯片，支持硬件加速。适合金融POS、医疗设备。
- L3 - 高性能安全环境：独立安全域，支持复杂密码运算。适合网关、服务器。
业务风险等级呢？我习惯问自己三个问题：
- 设备被仿冒会造成什么后果？
- 通信数据被窃取或篡改，损失多大？
- 设备被远程控制，有没有人身安全风险？
把这两个维度组合起来，就能得到安全等级矩阵。嗯，这里要注意：安全等级不是越高越好。L3级别的安全方案，成本可能是L1的10倍。你让一个温度传感器用HSM，老板会找你谈话的。
3.2 确定证书策略（CP/CPS）
CP和CPS这两个东西，很多人搞混。我简单解释一下：
- CP（Certificate Policy，证书策略）：说「我们要做什么」。比如证书有效期多久、密钥长度多少、怎么验证设备身份。
- CPS（Certification Practice Statement，认证业务声明）：说「我们具体怎么做」。比如CA的运维流程、密钥备份机制、审计日志格式。
说白了，CP是对外承诺，CPS是对内操作手册。
3.2.1 CP的核心内容
我个人习惯把CP分成几个关键块：
| 模块 | 关键决策点 | 常见选择 |
|---|---|---|
| 证书类型 | 设备证书、TLS证书、代码签名证书 | 按用途分，不要混用 |
| 密钥长度 | RSA 2048/4096？ECC P-256/P-384？ | ECC P-256是当前主流 |
| 证书有效期 | 1年？3年？5年？ | 设备证书建议1-3年 |
| 身份验证 | 手动审核？自动注册？ | 大规模设备必须自动化 |
| 吊销机制 | CRL？OCSP？ | 推荐OCSP，CRL做兜底 |
避坑指南：我曾经见过一个项目，CP里写「证书有效期5年」，结果第二年发现密钥算法被破解了。现在我的建议是：设备证书最长3年，并且CP里要写明「算法升级路径」。别把自己锁死。
3.2.2 CPS的实操要点
CPS是真正干活的人要看的。我写CPS时，会特别注意以下几点：
- 密钥生成：是在设备端生成，还是在CA端生成再分发？前者更安全，后者更可控。
- 密钥备份：CA私钥怎么备份？谁有权限？备份介质放哪？
- 审计日志：记录什么？存多久？谁可以查？
- 人员角色：谁可以操作CA？谁可以审核？谁可以吊销？
嗯，这里有个细节。CPS里一定要写清楚「异常处理流程」。比如CA私钥泄露了怎么办？CRL更新失败怎么办？我见过一个项目，CPS写了100多页，唯独没写「CA宕机后的恢复步骤」。结果真出问题时，一群人干瞪眼。
3.3 合规性要求（GDPR、等保等）
合规这块，说白了就是「法律让你怎么做，你就得怎么做」。别想着绕过去，绕不过去的。
3.3.1 GDPR对设备PKI的影响
如果你的设备涉及欧盟用户数据，GDPR就是绕不开的坎。主要影响点：
- 数据最小化：证书里不要放不必要的个人信息。设备ID就够了，别放用户姓名、邮箱。
- 数据保留期限：证书吊销信息、审计日志不能永久保存。GDPR要求「存储目的达成后删除」。
- 数据可移植性：用户有权要求删除与其设备相关的证书数据。你的PKI系统得支持这个操作。
- 数据泄露通知：CA私钥泄露属于数据泄露，必须在72小时内通知监管机构。
我的经验：做GDPR合规时，最容易被忽略的是「证书中的扩展字段」。有些项目为了方便，把设备序列号、MAC地址甚至用户手机号塞进证书Subject里。这在GDPR下是违规的。记住：证书里只放设备标识，其他信息通过业务系统关联。
3.3.2 等保2.0对设备PKI的要求
国内项目，等保2.0是硬指标。我整理了几个关键点：
| 等保要求 | PKI落地措施 | 检查要点 |
|---|---|---|
| 身份鉴别 | 设备证书双向认证 | 是否使用国密算法？ |
| 访问控制 | 基于证书的权限管理 | 证书是否绑定设备角色？ |
| 安全审计 | CA操作日志、证书生命周期审计 | 日志是否防篡改？ |
| 数据完整性 | 数字签名验证 | 签名算法是否符合国密？ |
| 数据保密性 | TLS加密通信 | 密钥长度是否达标？ |
等保2.0对国密算法有明确要求。如果你的项目涉及政府、金融、关键基础设施，必须使用SM2/SM3/SM4。我建议在CP里直接写明「支持国密算法」，省得后面补合规审查时手忙脚乱。
3.3.3 其他行业合规
不同行业还有自己的规矩：
- 金融行业：PCI DSS要求密钥管理有严格的访问控制和审计。
- 医疗行业：HIPAA要求设备证书必须支持患者数据加密传输。
- 车联网：WP.29 UN R155要求车辆证书必须有吊销机制和远程更新能力。
嗯，这里要注意：合规要求是动态的。GDPR在更新，等保也在升级。我建议在CPS里留一个「合规审查更新机制」，每年至少review一次。
3.4 需求分析核心流程
说了这么多，咱们用一张图把整个需求分析流程串起来：
这张图是我做项目时常用的框架。你可能会问：为什么合规审查放在最后？其实不是的。合规要求应该在设备评估阶段就介入，但正式审查和文档输出放在最后。这样既能保证方向正确，又能避免反复修改。
3.5 本章小结
需求分析这个阶段，我总结了三句话：
- 设备规模往大了估，安全等级往实了定。别拍脑袋，要有数据支撑。
- CP对外承诺，CPS对内落地。两者要对应，不能两张皮。
- 合规不是负担，是保护伞。合规做得好，项目出问题时你有据可依。
嗯，我记得有一次项目上线后，客户审计发现证书有效期超过了等保要求。还好我们在CP里写了「可根据合规要求调整有效期」，才没被判定为重大缺陷。所以，文档写得好，背锅少一半。