云上还要不要买密码机：密评视角的四条判断线
系统迁到云上之后，"加密"这件事看起来已经被云服务商包圆了：控制台里勾选一下就开了存储加密，传输有国密 TLS，密钥托管在平台自带的密钥管理服务里。于是很自然的一个问题是——既然云上已经有加密能力，密评时还要不要自己买密码机？
答案不是简单的要或不要，而是取决于这四件事：责任怎么分、底层是不是经认证的密码产品、密钥归谁管、运算在哪里发生。下面逐条拆开讲。
一、先把责任边界划清楚
按照密评的通行口径，跑在云平台上的系统做密评，原则上要完成两部分测评：云平台自身密码应用的测评，责任主体是云平台运营者；云上应用系统密码应用的测评，责任主体是云上应用的运营者。
同时还有两条硬约束：云上应用所处的云平台要先通过密评（拿到"符合"或"基本符合"结论），云上应用才可能通过密评；云平台的安全级别应当不低于云上应用系统。
这意味着，云平台自身的合规状况只是入场券，不能替代应用侧的工作量。云服务商提供的加密能力，能不能被云上应用直接采信，才是"要不要买密码机"真正的分水岭。
二、云服务商的"加密能力"其实是三种东西
很多单位把云上的加密服务当成一回事，实际上按实现方式可以分成三类，合规待遇完全不同：
- 直接由密码产品提供：云平台在底层调用经认证的服务器密码机或云服务器密码机，把密码运算能力直接开放给应用。这类在密评里最容易被采信。
- 虚拟化后重新分配：云平台把密码机的资源做虚拟化，再分给不同租户。关键看虚拟化发生在哪里——如果虚拟化是在密码产品内部完成的，产品本身仍持有商用密码产品认证证书，风险可控；如果虚拟化是在云平台侧用软件实现的，密钥和运算就跑出了密码产品的保护边界，需要逐项论证。
- 纯软件实现：以 SDK、加密库、函数接口的形式提供算法能力，底层没有经认证的密码产品。按 GB/T 39786-2021 第三级的要求，采用的密码产品应达到 GB/T 37092 二级及以上安全要求；而对于用开源或自研代码做密码运算、又无法提供安全性证明的情形，测评中通常判定为不符合。
一句话概括：看的是底层有没有持证密码产品，不看控制台上有没有开关。
三、不用买的判断线：能拿出这四样材料
如果云服务商能完整提供下面四项，多数应用层指标可以复用平台能力，不必重复采购：
- 底层密码产品的商用密码产品认证证书，且证书标明的等级满足本系统的密码应用等级要求（等保三级对应第三级，密码产品需二级及以上）；
- 云平台自身的密评报告，结论为符合或基本符合，且安全级别不低于本系统；
- 云平台出具的密码服务支撑能力说明，写清楚为云上应用提供了哪些密码服务、底层由哪类密码产品承载;
- 密钥管理规则说明：密钥在何处产生、以何种形式存储、谁能导出、销毁流程如何。
这四样材料齐了，云上应用侧的差距分析会轻松很多。材料拿不全，就按"平台的归平台，自己的归自己"来准备。
四、仍然要自配的五个典型场景
即便云平台很合规，下面几类需求通常还是需要自建或自购：
- 物理与环境层面：机房电子门禁的身份鉴别、视频监控记录的存储完整性，用的是本单位实际所在的机房，云平台覆盖不到。
- 不可否认性：签名验签、时间戳、电子签章这类要提供数据原发与接收证据的能力，多数云平台不直接提供，需要自配签名验签服务器或时间戳服务器。
- 密钥自主可控要求：行业监管或上级单位要求密钥不得由第三方托管的，必须把密钥落到自有的密码机或密钥管理系统里。
- 密码产品等级不匹配：平台提供的产品等级低于本系统要求，只能在自采设备上补齐。
- 跨平台与混合部署：一部分业务在云上、一部分在本地机房，两边都要满足同一套指标，本地侧的密码资源无法由云平台代劳。
五、落地顺序建议
比较稳妥的做法是：先盘清单，再决定买什么。
第一步，梳理本系统的密码资源现状——哪些应用调用了哪种密码服务、底层由什么承载、密钥存在哪里。第二步，向云服务商索取上一节列的四样材料。第三步，对照 GB/T 39786 四个技术层面逐项做差距分析，标出哪些能复用平台能力、哪些必须自建。第四步，形成密码应用方案并组织评审，再进入改造实施。
整改周期通常在数周到数月不等，取决于改造面和系统数量，具体以属地要求和项目实际情况为准。
最后提醒一点：密评结论取决于现场核实与整体判定，任何设备清单都不能替代方案评审。建议在系统规划阶段就把密码应用方案做起来，避免建成后再返工。
我们提供密评辅导、差距分析、方案编制与协助对接持牌机构的服务，具体评估工作由具备资质的检测机构承担。