政务密评里随机数服务该怎么提供,答案就一句话：把随机数当成独立密码服务来建，用带商用密码产品认证证书的硬件熵源模块，按GM/T 0005-2021完成检测和复查，再配合实时监控和日志留痕。 别把它理解成“装个软件、调个接口”的小事，测评机构盯的恰恰是这套服务背后的物理来源和全流程管理。
密评随机数服务方案：从“够用”到“合规”差在哪
密评究竟在考随机数的什么
政务密评（商用密码应用安全性评估）不会单独给“随机数”设一项打分，但随机数质量差的系统，往往在密码服务合规性大项里被卡住，测评机构对随机数序列的执行标准是GM/T 0005-2021《随机数检测规范》，其中列出的频数、块内频数、游程、自相关等检测项目，本质上都在回答一个问题：从头到尾把这串数字当成“看不出规律”的序列，概率上是否说得通。
GM/T 0005把判定阈值设在α=0.01，随机数序列的P值一旦低于这条线，就会被认定为“不随机”，也就是说，过检不是“看着像随机数就行”，而是要有统计学上的证据，行业内测过一轮就会明白，序列长度、采样方式、样本数量任何一个环节不严谨，最后拿到的P值都会非常难看。
硬件熵源是硬门槛，系统自带的熵池撑不过现场审核
不少系统集成商喜欢说“我们用的是系统自带的随机源，足够安全”，放在互联网业务里，这句话或许还有争论空间，但放在政务密评的桌上，结论非常直接：GM/T 0062-2018《密码应用基本要求》明确要求，重要业务系统使用的密码产品，应当采用经过国家密码管理部门认证的密码模块。
认证密码模块的熵源普遍采用物理噪声源,也就是把硬件电路中的热噪声、时钟抖动这些不可预测的来源，转换成随机序列，你可以通过Linux的/proc/sys/kernel/random查看到系统熵值，但那只是对软件熵池的评估，跟“认证密码模块里的TRNG”是两码事，测评机构在整改意见里写得最多的就是“随机数服务未依托合规密码产品”，这一条几乎没法靠解释绕过去。
选型时先看这三件事
- 密码模块有没有《商用密码产品认证证书》，证书是否在有效期内。
- 提供的接口是否符合行业通用规范,比如PKCS#11、国密标准接口。
- 能不能输出完整日志,密评整改要求里经常涉及“审计日志完整记录”这一项。
行业共识认为,随机数服务被卡脖子，多数时候不是算法不好，而是来源不可追溯，所以选方案时优先看“证据链是否完整”，而不是看单次随机数生成速度有多快。
政务系统随机数检测标准：落地要从这三步走
第一步：把随机数从业务代码里抽出来
这不是让你把所有业务推翻重写,实操层面，先在机房或政务云专区里部署一台服务器密码机，开启随机数生成接口，再让业务系统通过标准接口去调用，而不是在应用代码里自己写一个随机函数，这样做的意义在于：随机数服务变成了独立组件，测评人员现场检查时，能顺着调用链路一路查下去。
具体操作路径一般是：密码机配置密钥和随机数生成策略，业务侧写一个对接SDK，把所有随机数请求指向密码机地址，改造完成后，代码评审、渗透测试、密评审查三个环节都会省力不少。
第二步：加上实时自检和异常告警
按密码产品认证要求里的相关条款,认证密码模块在每次上电时会自动执行已知答案测试、噪声源自检，部署时要把这些自检状态接到运维监控平台上，随机数服务一旦异常，运维人员能第一时间收到告警。
日志字段至少要包含调用时间、调用方IP、请求次数、失败原因，这些字段在密评现场检查时会被翻出来逐条核对，不要等到测评机构要数据时才临时补。
第三步：跑完离线检测并归档报告
每年或每两年,采样一段随机数序列，送到具备资质的商用密码检测机构，按GM/T 0005-2021跑完所有检测项目，流程不复杂：现场采样、实验室分析、返回带统计结论的检测报告，这份报告要放进密评档案，评审专家抽查时直接翻出来看。
这里有个容易忽略的细节：采样时的环境描述、设备标识、时间戳都要写清楚，检测报告本身只对“样本”负责，样本来源不明等于白测。
政务云和独立业务系统，随机数服务配置逻辑不一样
政务云里的随机数服务更像“水厂”：一台或多台密码机集中产生随机数，通过内部网络分发给不同租户，这个模式下，租户间隔离和配额管理是过检焦点，运维方必须把“谁调用了随机数服务”的审计记录单独存储。
独立业务系统则更像“净水器”：每个系统就近部署一台密码模块，吞吐量要求高的场景下再加一台做负载均衡，两种模式的差别很直观：
| 对比维度 | 政务云集中模式 | 独立业务系统模式 |
|---|---|---|
| 部署位置 | 密码专区或资源池 | 业务系统机柜 |
| 供给方式 | 多租户共享API | 服务进程直连 |
| 扩容能力 | 靠密码机集群横向扩容 | 受单机接口性能限制 |
| 过检难点 | 租户访问控制证据 | 模块认证证书续期 |
| 成本结构 | 前期建设高、后期均摊低 | 单点投入低、总数不低 |
政务云场景里有一个小技巧：把随机数服务的API网关单独拉出来，所有租户请求都走统一入口，这样平台侧能拿出“谁在什么时间调用了多少次”的完整记录，密评专家要查访问控制证据时，一张表就能说清楚。
密评随机数服务价格：北京和外地差在哪
先给个参考区间：单台认证服务器密码机的采购价在几万到十几万之间，国产主流品牌差距不大，如果包含密评整改咨询、检测陪同、报告答辩服务，整体项目服务费另算，多数情况下在数万元上下，市面上“密评随机数服务”的报价，本质上就是“设备价+服务费+检测费”三块拼出来的。
北京的情况比较特殊,受测评机构排期、材料准备严格程度影响，北京密评随机数服务商给出的报价普遍比外地高一些，多问几家你会发现，北京本地服务商通常把“现场支持”和“材料预审”打包进报价，外地集成商虽然设备单价低，但后续驻场调试成本一加上去，差距就被拉回来了，真正影响性价比的不是单价本身，而是服务商对你单位业务形态的理解程度。
采购时问清楚三件事：合同里是否包含驻场调试天数、是否包含整改意见的二次响应、检测费是实报实销还是打包价。
顺带说一句,政务密评随机数怎么过检，最稳妥的办法不是自己埋头研究标准，而是让服务商拿着他们给其他委办局做过的同类型案例，直接对照着改，同等条件下，案例越多，踩坑的概率越小。
关于政务密评随机数服务的三个高频疑问
政务系统能直接用软件随机数过密评吗
不能,GM/T 0062-2018要求重要业务系统使用经认证的密码产品，软件随机数生成器无法满足物理熵源和管理层面的合规要求，密评现场审核阶段基本无法通过，检测机构对随机数来源的追溯有明确流程，软件熵源给不出可信的证据链。
密评随机数检测多久做一次
随机数检测属于动态检查项,行业通常按年度或按项目周期安排，实际执行中，多数政务单位在密评整改后做一次完整检测，后续每两到三年复测一次，同时依赖密码设备的每日自检结果作为日常合规凭据。
自建随机数服务和采购服务哪个划算
业务量不大、系统数量少的单位，直接采购服务更划算，业务系统多、调用量大的政务云平台，自建集群的长期成本更低，但无论哪种方式，最终评判标准只有一个：是否基于认证密码产品，以及随机数服务是否有完整的检测证据链。
说到底,政务密评里随机数服务该怎么提供，记住一条主线就够：用真硬件、走国标检测、留全套证据，它不复杂，但也不容取巧。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/734287.html
