®
01
依赖关系决定先后顺序
一个核心库或证书平台的变更，可能会影响许多应用。反过来，一台旧设备也可能限制整条链路的迁移进度。我们会梳理这些依赖关系，核实厂商提供的信息，并将可以短期落地的措施与前期准备工作区分开来。每个试点都会被赋予明确的问题，例如某个网关链路的兼容性，或对某种密钥类型的支持情况。路线图中包含若干决策节点，测量结果和新信息可能会在这些节点上改变后续规划。
您对 OTOKO® 的委托
我们为您承接的工作。
某些信息必须保密很多年。因此，如今被截获记录的加密流量，也可能对长期风险评估产生影响。与此同时，采购、软件调整和对接系统的更换都需要时间。我们会将这些因素与您的保护需求结合起来考量，而不会把对高性能量子计算机出现时间的推测当作可靠的规划依据。签名会被单独考虑，因为要保证其长期可验证性，所需采取的措施可能与保障一条连接的机密性并不相同。
可能的服务范围
- 统筹评估数据和签名的保护需求
- 梳理密码学依赖关系和迁移工作量
- 掌握厂商依赖关系和采购周期
- 规划试点项目和迁移波次
- 记录残余风险和尚未决定的事项
具体范围、您的参与方式以及验收标准，我们会在项目开始前明确约定。
把技术讲清楚
我们是这样落实任务的。
02
让路线图变成可委托实施的阶段
每个阶段都会明确涉及的系统、预期成果、所需配合以及审批标准。例外情况会指定负责人和复查时间。验收环节考察的不仅是一份时间表，还包括工作量、依赖关系和风险是否有清楚合理的依据。启动阶段，我们需要一份初步资产清单、保护需求信息，以及您基础设施即将进行的更新计划。
一个可验证的成果
这将成为您后续工作的基础。
- 有充分依据的优先级排序
- 包含依赖关系的迁移计划
- 面向业务部门和 IT 的决策材料
移交环节将实施成果与文档记录结合在一起。我们会共同检查约定的场景，并记录尚待完成的任务。
您的项目详情
根据保护期限和可迁移性确定实施顺序。
我们会将密码资产清单转化为一份切实可行的 PQC 路线图。并非所有系统都需要在同一时间采取相同的措施；优先级取决于数据价值、保护期限以及技术依赖关系。
将机密性与长期可验证性分开考虑
对于机密数据而言，关键在于它们需要被保护多长时间，以及当前的加密通信是否可能被记录下来。对于签名和归档数据而言，还需要考虑长期可验证性以及证明材料的更新问题。我们会与业务负责人一起梳理这些需求，而不是仅仅按照服务器的新旧程度来排序。
这里所说的风险，并不是要预测高性能量子计算机出现的具体日期。规划工作着眼于合理可信的场景，以及您的组织在采购、集成和审批方面所需的时间。准备周期特别长的情况，可以作为提前启动的理由。
将优先级转化为可执行的工作包
路线图包含前提条件、负责人、依赖关系和决策节点。有些任务需要先向厂商求证，有些则需要先做实验室测试，或先对过时的程序库进行现代化改造。我们会区分前期准备措施与生产环境的正式切换，并标注出仍需依赖具体产品支持才能做出的决策。
工作量和时间安排会以有理有据的规划方式呈现，并标明尚待验证的假设。每次试点之后，都会重新审视既定的顺序。笼统的一次性全面迁移很少是合理的第一步；往往仅消除对特定算法的硬绑定，就已为日后的切换打下基础。
示例项目场景
该服务在日常工作中如何发挥作用。
示例：生命周期短暂的公开内容，与需要长期保密的研发数据，分别使用不同的系统。我们不会笼统地把所有面向互联网的服务都排在最优先，而是会综合考虑保护期限和迁移所需的准备时间。对于难以替换的归档系统，准备工作会更早启动。
该示例说明的是一种可能的流程，并非客户案例。
在迈出第一步之前
您关于 PQC 路线图 的问题。
我们是否需要等待一个具有约束力的截止日期？
不需要。资产盘点、依赖关系梳理和兼容性测试都可以独立于此提前展开。具体的迁移工作则依据风险和技术成熟度来安排。
该计划能否取代我们的安全战略？
不能。它是对安全战略的补充，专门应对密码学层面的变化，并与现有的风险管理、采购和运维流程相衔接。
