2. 企业密码需求分析与合规驱动
密码基础设施不是先买设备再找用途，而是从业务系统的真实安全需求和外部合规约束反推出来的。企业做密码需求分析，核心是回答三个问题：哪些业务数据需要密码保护、需要保护到什么强度、依据什么规则判定合规。等保、密评、数据安全法与行业监管分别从不同角度提出要求，最终要收敛为一份可落地的密码能力清单和约束条件。
一、四类密码需求的来源与判定
密码学提供四类基础安全能力，企业需求分析的第一步是把业务场景映射到这四类能力上：
- 机密性：数据存储和传输不被未授权读取。典型场景是数据库敏感字段加密、接口报文加密、终端文件加密。判定依据是数据分级——公开、内部、敏感、核心，不同级别对应不同加密算法和密钥强度。
- 完整性：数据未被篡改。典型场景是交易报文防篡改、日志防篡改、软件包签名校验。常用 HMAC、数字签名实现。
- 真实性：确认通信双方身份真实。典型场景是用户登录认证、设备接入认证、服务间调用认证。依赖数字证书、挑战应答、动态令牌等机制。
- 不可否认性：行为发生后无法抵赖。典型场景是电子合同签署、电子处方、电子招投标。必须使用数字签名并配合可信时间戳。
需求分析不能停留在“需要加密”这种模糊表述。以某企业OA系统为例，实际需求应写成：员工登录需支持基于数字证书的双因素认证（真实性）；公文流转附件需使用SM4加密存储（机密性）；审批意见需使用SM2签名并加盖时间戳（完整性与不可否认性）；日志需使用HMAC-SM3保护（完整性）。这样才具备可实施性。
二、合规驱动的四层约束
合规要求是密码需求的硬约束，企业必须逐条对照，不能选择性执行。四类主要来源如下：
| 合规来源 | 核心要求 | 对密码基础设施的约束 |
|---|---|---|
| 网络安全等级保护（等保2.0） | 三级及以上系统须使用密码技术保护重要数据，身份鉴别、访问控制、数据完整性、数据保密性均有密码要求 | 需部署密码机/密码卡，支持国密算法，密钥管理符合要求 |
| 商用密码应用安全性评估（密评） | 从密码算法、密码技术、密码产品、密码服务四个维度评估合规性、正确性、有效性 | 算法必须为SM2/SM3/SM4等国密；产品需有商用密码产品认证；需有完整密钥管理流程 |
| 数据安全法 | 建立数据分类分级保护制度，重要数据出境需安全评估 | 密码能力需覆盖数据全生命周期，支持分级加密策略 |
| 行业监管（金融、医疗、能源等） | 人民银行、卫健委、能源局等发布行业密码应用规范 | 需满足行业特定算法、密钥长度、证书格式、审计留存要求 |
密评是其中最具操作性的抓手。密评结论分为“符合”“基本符合”“不符合”，评估时会逐项检查：算法是否为国密、密钥是否由合规密码机产生和存储、密钥更新周期是否满足要求、是否使用了通过认证的密码产品。企业应在建设初期就按密评指标设计，而不是事后整改。
三、从需求到能力清单的转化方法
把业务需求和合规约束转化为密码能力清单，建议按“业务系统—安全需求—密码能力—技术实现—合规依据”五列展开。以下是一个示例片段：
业务系统：财务共享平台
安全需求：报销单据防篡改、审批人身份真实、电子发票不可否认
密码能力：SM3完整性校验、SM2数字签名、SM2证书认证、可信时间戳
技术实现：签名验签服务器 + 密码机 + CA证书 + TSA时间戳服务
合规依据：等保三级8.1.4.2、密评GB/T 39786-2021、会计档案管理办法
汇总所有业务系统后，能力清单会自然收敛为几类基础设施组件：密钥管理系统（KMS）、证书认证系统（CA）、密码运算服务（密码机/密码卡）、签名验签服务、时间戳服务、密码服务管理平台。这些组件就是密码基础设施的骨架。
四、约束条件的识别与记录
约束条件决定了基础设施的边界和实现方式，常见约束包括：
- 算法约束：必须使用SM2/SM3/SM4，部分场景允许SM9；不得使用MD5、SHA-1、RSA-1024等弱算法。
- 性能约束：高峰时段签名验签TPS、加密吞吐量、并发连接数。例如某支付系统要求签名验签≥5000 TPS，加密吞吐≥1 Gbps。
- 可用性约束：密码服务不可中断，需双机热备或集群，密钥需备份与恢复机制。
- 合规约束：密码产品需具备商用密码产品认证证书；密钥管理需符合GM/T 0051；审计日志留存不少于6个月。
- 集成约束：现有系统改造难度、接口协议（如PKCS#11、JCE、SDF）、是否支持云原生部署。
这些约束应形成一份《密码需求与约束说明书》，作为后续架构设计的输入。没有这份文档，架构设计就会失去判断依据，容易陷入“堆设备”或“过度设计”。
五、需求分析的实际操作要点
在实际项目中，需求分析通常按以下顺序推进。首先做业务系统梳理，列出所有涉及敏感数据或关键业务的信息系统，标注系统等级和数据类型。其次做合规差距分析，对照等保和密评要求逐项检查现状，找出未使用密码技术或使用不合规的环节。然后做需求映射，把每个差距点映射到具体的密码能力。最后做约束汇总，形成完整的需求与约束说明书。
一个容易被忽视的点是：需求分析必须区分“已有密码能力”和“缺失密码能力”。很多企业已经在某些系统中使用了SSL证书或数据库自带加密，但这些能力往往分散、不合规、无法统一管理。需求分析的输出应明确哪些能力可以复用、哪些必须新建、哪些需要改造。
最终，本节的核心产出是一份《密码需求与约束说明书》，它包含：业务系统清单、四类安全需求映射表、合规依据对照表、密码能力清单、约束条件列表。这份文档是后续密码基础设施架构设计的直接输入，也是密评整改和等保测评的基础依据。没有经过系统化需求分析就进入架构设计，往往导致设备选型偏差、合规返工和投资浪费。