3. 业务系统对接需求分析与场景建模
在量子密钥管理（QKM）系统与业务系统对接之前，最容易被低估、却最影响后期返工量的环节，是需求分析与场景建模。很多项目一上来就讨论接口协议、SDK 版本，结果做到联调阶段才发现：业务方真正需要的不是“取一把密钥”，而是“在交易报文签名时按笔获取一次性密钥，并且密钥不能离开密码机边界”。这类偏差无法靠接口文档弥补，只能靠前期的场景建模消除。本节围绕三件事展开：识别典型业务场景、从场景中提取密钥服务需求、把对接边界与约束写清楚。
一、先分清“业务场景”与“密钥使用场景”
业务场景描述的是业务系统在做什么，例如“跨行转账”“电子证照签发”“智能电表数据上报”；密钥使用场景描述的是在这个业务动作中，密钥以什么方式参与、参与几次、生命周期多长、由谁持有。需求分析必须把前者翻译成后者，否则提取出的需求会停留在“需要加密”这种无法实现的粒度。
以三类典型业务为例，它们的密钥使用特征差异极大：
- 金融交易类：单笔交易金额小、频次高（示例假设峰值 3000 TPS），要求低时延；密钥通常按“一次一密”或“短周期批量预取”使用，强调密钥不可复用、不可落盘、获取与使用在同一安全边界内完成。
- 政务数据类：以批量数据交换、证照签发为主，单次数据量大、并发不高，但对密钥的可审计性、分级授权、跨部门隔离要求高；密钥往往按“业务域 + 数据级别”划分，需要长期归档与追溯。
- 物联网类：终端数量巨大（示例假设 10 万台电表）、算力与带宽受限、网络不稳定；密钥需要支持设备级唯一标识绑定、离线缓存与断连续用，且终端侧密钥保护能力弱，必须依赖轻量协议与定期轮换。
可以看出，同样是“对接量子密钥”，金融关心时延与不复用，政务关心隔离与审计，物联网关心规模与弱终端适配。场景识别的产出不应是一句结论，而应是一张能支撑后续设计的场景特征表。
二、从场景特征推导密钥服务需求
把场景特征转成密钥服务需求，建议沿“密钥怎么来、怎么用、怎么还、怎么查”四条线展开，每条线都落到可验证的参数上，而不是形容词。
- 密钥怎么来（获取方式）：是实时按需申请，还是批量预取到本地密钥池？前者时延低但请求频繁，后者吞吐高但需考虑池容量与新鲜度。示例：金融交易采用“预取 5000 把、水位低于 20% 触发补充”的策略。
- 怎么用（使用约束）：密钥是否允许离开 QKM 边界？是否要求“密钥句柄 + 密码运算”模式（即业务只传数据、不接触密钥明文）？这直接决定接口是“取密钥”还是“调用加密服务”。
- 怎么还（生命周期）：用完即销毁、定时轮换还是按次数失效？示例：一次性密钥使用后立即标记销毁；长期密钥按 90 天轮换。
- 怎么查（审计与计量）：需要记录哪些字段——申请方身份、密钥 ID、使用时间、使用次数、销毁状态？审计粒度决定了日志接口的设计。
三、定义对接边界与约束
对接边界回答“谁负责什么、什么不能越过”。实践中至少要在三个层面画线：
信任边界：QKM 与业务系统之间通常存在一条明确的信任分界。密钥明文是否允许跨过这条线，是最关键的约束。推荐做法是业务系统只持有密钥句柄，密码运算在 QKM 侧或受控密码模块内完成，业务侧拿不到明文密钥。
网络与部署边界：QKM 一般部署在独立的安全域，业务系统通过专线或受控网关访问。需要明确：是否允许跨域、是否要求双向认证、连接是否长连复用、断连后的重试与降级策略。示例约束：业务侧到 QKM 网关采用 mTLS 双向认证，单连接最大并发 200，超时 300 ms 后重试一次。
能力与责任边界：QKM 负责密钥生成、存储、分发、轮换、销毁与审计；业务系统负责身份注册、按规范调用、异常上报。要特别写清“不做什么”，例如 QKM 不解析业务报文、不承担业务数据的完整性判断，避免职责蔓延。
四、把建模结果写成可评审的对接需求清单
场景建模的最终交付物，应当是一份能被业务方、安全方和开发方共同评审的对接需求清单。它不需要很长，但每个字段都要能追溯到具体场景。下面给出一份示例清单（参数为教学假设，非实测值），可直接作为评审底稿使用：
| 需求编号 | 来源场景 | 密钥服务需求 | 关键参数/约束 | 验收判据 |
|---|---|---|---|---|
| R-01 | 金融交易 | 按笔获取一次性密钥，句柄调用加密 | 预取池 5000 把，水位 20% 补充；密钥不出 QKM | 业务侧抓包无密钥明文；单笔获取 P99 ≤ 50 ms |
| R-02 | 金融交易 | 密钥用后立即销毁 | 销毁状态可查，重复使用返回错误码 | 同一密钥 ID 二次调用被拒绝并记审计 |
| R-03 | 政务数据 | 按业务域 + 数据级别隔离密钥 | 域 A 密钥不可被域 B 申请 | 跨域申请返回鉴权失败 |
| R-04 | 政务数据 | 全量审计留痕 | 记录身份、密钥 ID、时间、次数、状态 | 抽查 100 条记录字段完整率 100% |
| R-05 | 物联网 | 设备级密钥绑定与离线缓存 | 断连可续用缓存密钥，最长 24 h | 模拟断网 2 h，上报数据仍可解密 |
| R-06 | 物联网 | 定期轮换 | 90 天轮换，轮换期新旧密钥并存 7 天 | 轮换窗口内新旧密钥均可验证通过 |
这份清单的价值在于：它把“场景—需求—约束—验收”串成一条链。评审时若有人质疑某条约束是否必要，可以直接回到来源场景；开发时若不确定接口该设计成“取密钥”还是“调服务”，看 R-01 的“密钥不出 QKM”即可定案。
五、常见建模偏差与纠正
实践中高频出现的偏差有三类。第一类是把业务指标当密钥需求，例如写“支持 3000 TPS”，但没说明这是密钥获取的 TPS 还是加密运算的 TPS，二者对 QKM 的容量规划完全不同。纠正方法是拆成“密钥获取 QPS”和“密码运算 QPS”两个指标分别建模。
第二类是边界画得太晚，先定接口再补边界，导致后期发现业务方要求导出密钥明文做本地缓存，与信任边界冲突，只能返工。纠正方法是在场景建模阶段就把“密钥是否可离开边界”作为第一个待决问题。
第三类是忽略异常路径。正常流程的建模往往很快，但断连、密钥池耗尽、轮换窗口重叠、审计写入失败这些异常，才是对接中最容易出问题的部分。建议在清单中为每个关键需求补一行“异常与降级”，例如密钥池耗尽时是阻塞等待还是降级到备用池，必须提前约定。
完成本节建模后，后续的接口设计、密钥生命周期管理和联调测试就有了共同基准：接口字段来自需求清单，测试用例来自验收判据，边界约束则成为安全评审的检查项。需求分析做得扎实，后面的对接工作才不至于反复推倒重来。