军工等保密评双达标产品选型:四层面密码合规产品全景
某军工单位要同时过等保三级和密评,评审组问的第一句是"你们密码产品都配在哪些层面?"——答不上来。等保和密评各有一套层面体系,军工单位做双达标,最容易懵的就是:每个层面到底要配什么密码产品、谁管哪一层、怎么不漏项。
# 现场摸底:军工单位密码能力现状(示意)
# 1) 密码库是否支持国密(有无 SM2/SM4 引擎)
openssl version -a | head -2
ls /usr/lib/ossl-modules/ 2>/dev/null | grep -E "sm2|sm4"
# → 未输出 → 无国密引擎,只剩基础口令认证
# 2) 双达标差距:按等保四层面 + 密评五层面逐层过
# 物理环境 / 通信网络 / 区域边界 / 计算环境 / 密钥管理
# → 除口令外几乎全空 → 每个层面都要补密码合规产品
军工单位的信息系统,一头要过等保(等级保护,GB/T 22239),一头要过密评(商用密码应用安全性评估,GB/T 39786)——双达标。这篇按等保的四层面技术架构给你一张密码合规产品全景:每个层面管什么、对应密评哪一类、用安当哪个产品落,选型一次看全。
- 一、军工双达标:等保与密评有什么区别
- 二、四层面密码合规产品全景:每个层面配什么
- 三、选型建议:军工场景按什么优先级配
- 四、落地验证:逐层确认没漏项
一、军工双达标:等保与密评有什么区别
等保和密评是两套体系,军工单位都要过,别混着答:
| 维度 | 等保(GB/T 22239) | 密评(GB/T 39786) |
|---|---|---|
| 管什么 | 信息系统等级保护,安全防护整体 | 密码应用的合规性,国密算法落地 |
| 层面划分 | 安全物理环境 / 通信网络 / 区域边界 / 计算环境(+安全管理中心) | 物理和环境 / 网络和通信 / 设备和计算 / 应用和数据 / 密钥管理 |
| 对密码的落点 | 要求"应采用密码技术"满足保密性/完整性 | 要求"应使用合规密码产品并合规应用" |
| 军工叠加项 | 涉及国家秘密的另按 BMB17 分级保护 | 涉密/商用密码分别管理 |
关键认知:双达标的本质是用一套密码基础设施,同时满足两套要求——你不需要为等保和密评各买一遍产品,而是把密码产品按层面配齐,让它既覆盖等保的保密性/完整性要求,又覆盖密评的合规性要求。
军工再多一条线:军工单位密码应用实际是两条线——非涉密系统走密评(商用密码,GB/T 39786);涉密系统另按国家保密标准 BMB17 分级保护,用涉密密码设备管理。两条线的产品底座(KSP 密钥管理 + HSM 密码机)可以共用,上层鉴别/加密按密级分别配——这是军工选型和普通行业最大的不同,别混成一条线答。
二、四层面密码合规产品全景:每个层面配什么
先对齐口径:等保技术要求分四个层面——安全物理环境、安全通信网络、安全区域边界、安全计算环境;另加**安全管理中心(管理域)**承担集中管理,密钥管理就落在这里。下面的全景表按"四层面 + 管理中心"展开,正好对应密评五层面:
按等保四层面技术架构 + 密评对应层面,一张表看清:
| 等保层面 | 层面要求 | 密评对应 | 推荐产品 | 落点 |
|---|---|---|---|---|
| 安全物理环境 | 物理设备、介质防护 | 物理和环境安全 | 安当 HSM 密码机 | 密码设备部署于受控机房,密钥物理隔离 |
| 安全通信网络 | 传输机密性/完整性 | 网络和通信安全 | 国密加密通道(SM4/TLS) | 网络边界间传输加密,抓包非明文 |
| 安全区域边界 | 边界认证、访问控制 | 设备和计算安全 | 安当 ASP 统一认证 + UKEY | 边界入口身份鉴别,拒绝未授权接入 |
| 安全计算环境 | 身份鉴别、数据加密 | 应用和数据安全 | 安当 ASP + UKEY + TDE | 应用登录多因素、涉密数据落盘加密 |
| 安全管理中心 | 集中管理(管理域) | 密钥管理 | 安当 KSP + HSM | 密钥全生命周期统一管理、主密钥锁密码机 |
安全物理环境(HSM 密码机 · 受控机房)
│
安全通信网络(SM4/TLS 加密通道)
│
安全区域边界(ASP 统一认证 · UKEY 接入鉴权)
│
安全计算环境(ASP 多因素 · UKEY 身份 · TDE 落盘加密)
│
安全管理中心(KSP 密钥全生命周期 · HSM 主密钥)
读法:从下往上,安全管理中心(密钥管理)是底座——上面四个层面用到的加密、签名、认证,钥匙全由 KSP 管、主密钥锁 HSM。通信层的国密加密通道(SM4/TLS)所用证书也由 KSP 统一签发,不是散装的国际证书。这就是"一套密码基础设施,同时覆盖等保四层面 + 密评五层面"的全景。
三、选型建议:军工场景按什么优先级配
军工单位选密码产品,三个现实约束排优先级:
- 内网隔离优先:涉密/敏感网常物理隔离,产品必须离线可用——UKEY(SM2 证书)、HSM、TDE 都是离线可跑的;依赖外网/云的产品直接排除
- 国密合规优先:一律国密算法(SM2/SM3/SM4),对应密评要求,别再用国际算法凑
- 密钥集中优先:先落 KSP + HSM(密钥底座),再往上配 ASP/UKEY/TDE——钥匙不先管起来,上层配再多也是散钥匙
同层产品怎么选(横向对比):
| 决策点 | 选项 | 怎么选 |
|---|---|---|
| 数据加密 | TDE vs DBG 数据库加密网关 | 库多、想零改造 → TDE;要应用侧加密/跨库网关 → DBG |
| 身份鉴别 | ASP 统一认证 vs 自建 SSO | 要 MFA、要审计、要快速上线 → ASP;有现成自研体系才自建 |
| 密钥底座 | KSP + HSM 组合 | 钥匙集中、主密钥锁硬件是底线,别用软件密钥库 |
选型样例:一个军工单位要上一套涉密 OA——身份走 ASP + UKEY(SM2 证书)双因素,涉密文档落盘走 TDE,钥匙全挂 KSP + HSM,涉密库间通信走国密加密通道。四层面 + 管理中心各落一层,等保三级和密评的"应用和数据安全 + 密钥管理"两类一起过。
落地顺序建议:第一步 HSM + KSP(密钥底座)→ 第二步 ASP + UKEY(身份鉴别)→ 第三步 TDE(数据加密)→ 第四步补通信加密。按这个顺序,每落一层,等保和密评就各过一层面。
四、落地验证:逐层确认没漏项
# 验证涉密/业务库落盘加密(以 MySQL 8.0 为例,TDE 层)
SELECT TABLESPACE_NAME, ENCRYPTION FROM information_schema.innodb_tablespaces
WHERE TABLESPACE_NAME IN ('biz_core','secret_doc');
# → ENCRYPTION = 'Y' → 计算环境数据加密已生效 ✓
# 验证通信层国密加密:边界抓包无明文(tcpdump 判空)
tcpdump -i eth0 -s0 -A port 443 | grep -ci "secret\|机密"
# → 0 → 传输已加密,抓包无明文涉密内容 ✓
# 验证身份鉴别证书链(ASP + UKEY 层,libwhsm.so 为示例驱动库,以实际为准)
pkcs11-tool --module /usr/lib/libswhsm.so -l --pin 12345678 -y cert -O
# → Issuer: CN=本单位密管中心 CA ← 统一证书体系 ✓
# 验证 KSP 审计日志(密钥管理层)
tail -5 /var/log/ksp/audit.log
# → 签发/轮换/吊销全程留痕 ✓
逐层验收清单:
| # | 层面 | 验收项 | 达标判定 |
|---|---|---|---|
| 1 | 物理环境 | 密码设备在受控机房 | 物理隔离、专人管理 |
| 2 | 通信网络 | tcpdump -i eth0 -s0 -A port 443 抓边界间传输 | 抓包内无明文涉密内容 |
| 3 | 区域边界 | 无 UKEY 接入边界 | 接入被拒绝 |
| 4 | 计算环境 | 查落盘加密 + 身份鉴别 | ENCRYPTION='Y',双因素生效 |
| 5 | 密钥管理 | 查 KSP 审计日志 | 签发/轮换/吊销全程留痕 |
| 6 | 双达标覆盖 | 对照密评五层面逐层核对 | 五层面均有合规产品落点 |
对着这张全景表,把你们军工单位的信息系统逐层过一遍:密钥管没管起来、身份是不是多因素、数据落盘加没加密。等保四层面 + 密评五层面,你单位还空在哪一层?评论区说说,一起拆。
文章作者:安当加密技术负责人

1075

被折叠的 条评论
为什么被折叠?



