企业出海商用密码合规落地：密评自评、云密码机资质核验与国密/AES 双栈改造实战（2026版）

本文把"商用密码合规"从一句口号拆成可执行的工程：先用一张表判断业务落在密评的哪类监管场景，再给出 GB/T 39786 的四层技术要求与密评的评估流程、常见失分点；然后是密码服务网关与三层密钥的参考架构、AWS/阿里云/腾讯云云密码机的资质核验四问与能力对照、国密 TLCP 双证书与 SM4/SM3 的实操命令、信封加密把 KMS 调用量降四个数量级的算法与代码，以及"合规资质溢价 68 倍"的成本测算与三阶段割接路线。适合正在把业务从境内扩展到海外、或把海外业务数据回传境内的架构师与安全负责人阅读。

关键词： 商用密码、密评、国密 SM2/SM3/SM4、云密码机、HSM、TLCP、双栈、出海合规

一句话结论：密评不是"测评公司来打分"，而是一次密钥体系的重新设计

如果你的系统要面向境内监管（等保三级及以上、关键信息基础设施、或涉及境内个人信息出境），那么"用了 HTTPS、数据库开了透明加密"在密评里基本等于零分——评的不是你有没有加密，而是密码算法是否合规、密钥是否在合规密码模块内产生并受控、以及密码使用的全流程能否举证。 这件事的工程量八成不在算法替换：把 AES 换成 SM4 只需要改几行代码，真正贵的是密钥层级重建（根密钥必须进合规密码机）、双证书体系（国密 TLCP 需要签名证书与加密证书两张）、以及跨法域时密钥材料不能复制带来的重封装链路。

对出海企业尤其如此。海外业务侧，AWS、GCP 的密码机没有中国的商用密码产品认证，也没有 SM2/SM3/SM4；境内业务侧，国密密码机又不被海外的合规框架认可。所以出海企业真正的解法不是"选一家通吃的云"，而是"一个应用、两套密码栈、三层密钥、按数据标签路由" ——这也是本文要给的架构。

先把话说明白：国密算法不比 AES 更安全，它是合规要求。 SM4 是 128 位分组、128 位密钥，安全强度与 AES-128 同级；SM2 的 256 位曲线强度约等于 RSA 3072；SM3 输出 256 位摘要。任何把"国密"讲成"更安全"的说法，在评审现场都会被追问。你要论证的是"符合性"，不是"更强"。

本文边界：与站内五篇相邻文章怎么分工

站内安全与密钥类文章已经比较密，先把边界划清，免得读到重复内容：

• KMS 与 Secrets Manager 的选型、密钥轮换、Vault 多云统一方案：见 多云密钥管理与加密策略。那篇讲"密钥放哪、怎么轮换"，本文讲"密钥所在的那个盒子有没有资质"。
• 证书生命周期、ACME 自动化、mTLS：见 多云 PKI 证书生命周期管理。本文只讲国密双证书与 TLCP 的差异点，证书续期不展开。
• BYOK / HYOK / 外部密钥存储与数据主权：见 数据主权与主权云架构。那篇的第七节讲"密钥主权"的控制模型，本文讲"密钥主权的合规资质前提"。
• 跨境传输的合规机制（SCC、BCR、分类分级）：见 GDPR 跨境数据传输技术指南。本文不重复出境清单，只处理"加密这一段用什么算法、密钥在哪"。
• 机密计算与 TEE：见 机密计算与数据可用性。TEE 解决"运行时明文暴露"，密码机解决"密钥不被导出"，两者互补不替代。

一、先定位：四类场景里，只有两类真的需要密评

很多团队在这一步就走错——把所有海外业务都当成"要过密评"，结果预算花在根本不适用的地方；或者反过来，以为"我们数据都在新加坡"就与商用密码无关，结果境内主体一被定为等保三级，整个系统连带海外节点都要重做。

判断的依据不是"服务器在哪"，而是三个变量：运营主体的法域、数据的法域、以及系统是否被认定为关键信息基础设施（CII）或等保三级及以上。

四条判据值得单独记住：

第一条：密评跟着"系统"走，不跟着"服务器"走。 一个境内等保三级系统，即使计算节点部署在香港，只要它承载境内业务数据、由境内主体运营，通常仍被纳入评估范围。反过来，境外主体独立运营、数据与用户都在境外的系统，一般不进入中国密评。

第二条：CII 是硬约束。 被认定为关键信息基础设施运营者的，商用密码应用安全性评估是每年至少一次的例行动作，且评估结果要向保护工作部门报送。这不是"上线前做一次"的项目制工作，而是年度运维成本。

第三条："三同步"意味着改造窗口在规划阶段。 密码应用要求同步规划、同步建设、同步运行。系统已经上线两年再补密评，等于把密钥层级、证书体系、审计埋点全部返工——这也是为什么本文把架构放在实操前面。

第四条：纯海外业务不要为了"统一"而引入国密。 见过团队为了"一套代码全球跑"在法兰克福节点也开 SM4，结果既拿不到中国资质加分（境外密码机无认证），又白白损失 AES-NI 的硬件加速，吞吐掉一个数量级。统一的是接口与密钥层级，不是算法。

二、法规与标准骨架：五份文件决定你做什么

不用读完全部条文，但这五份必须知道各自管什么，否则很容易把"等保测评"和"密评"混成一件事。

再加两份工程上绕不开的技术规范：GM/T 0024《SSL VPN 技术规范》定义了国密套件与握手流程，GM/T 0005《随机性检测规范》是密码模块里随机数质量的检测依据——后者是密评里最容易被忽略、又最容易翻车的一项。

2.1 GB/T 39786 的"四加四"结构

密评不是泛泛检查"你有没有加密"，而是按八个层面逐条打分。技术四层与对应的典型证据：

这张表最实用的读法是：技术四层决定改造工作量，管理四层决定你能不能拿到"符合"。 很多项目技术层面全做了，管理层面只有一份两页纸的《密码管理制度》，最后结论停在"基本符合"。

2.2 密评 ≠ 等保测评

两个常被混为一谈的东西，区别很干脆：

• 等保测评评的是"网络安全等级保护"的整体合规，依据 GB/T 22239，覆盖面广、密码只是其中一节。
• 密评评的是"密码应用安全性"，依据 GB/T 39786，只盯密码——但盯得极细，细到"密钥在哪个模块里产生、谁能导出、销毁有没有记录"。

二者独立开展、结论各自出报告；实务上等保三级及以上的系统通常会同步做密评，用密评报告作为等保"密码部分"的举证材料。不要指望一份等保报告顶两份用。

三、密评到底怎么评：五步流程与六个高频失分点

3.1 五步流程

关于分数线：本文不给具体数字。 密评的量化规则由国家密码管理局体系下的评估规则文件规定，并随版本调整，具体阈值与高风险项扣分规则以测评机构执行的现行版本为准。任何在方案书里写死"60 分及格"的说法，评审时都可能被一句"以现行规则为准"驳回。你要做的是把每条测评点做到"符合"，而不是去猜及格线。

另外两点程序上的硬要求：评估机构必须来自国家密码管理局公布的商用密码检测机构目录（自找的安全公司出的"密评报告"不被承认）；报告要报送——CII 运营者报保护工作部门，其他按规定报密码管理部门。

3.2 六个高频失分点

失分点一：密钥在应用里生成，或者写在配置文件里。 这是最常见也最致命的一条。GB/T 39786 要求密钥在符合要求的密码模块内产生、存储和使用。openssl rand -hex 32 生成一把密钥塞进 .env，在密评里这条直接判"不符合"，而且会连带影响"密钥管理"整个层面。正确做法是密钥由 KMS/密码机产生，应用只持有密钥标识（KeyId），用的时候申请数据密钥。

失分点二：算法不在商用密码目录里。 用 AES-256-GCM 保护境内监管数据，技术上没问题，但在对应测评单元会被判为"未采用商用密码"。注意这里的逻辑：密码法没有禁止使用国外算法，密评要求的是"该用商用密码的地方必须用商用密码"。 这也是为什么"双栈"是出海企业唯一现实的路径——海外段用 AES，境内段用 SM4，代码同一套、算法由配置与数据标签决定。

失分点三：用了 SM4，但 IV 复用或 ECB 模式。 分组密码的工作模式不是"随便选一个"。ECB 模式泄露明文结构，同一密钥下 IV 复用对 CBC/CTR/GCM 都是灾难性的。要用 SM4-GCM 或 SM4-CBC + 随机 IV，并把 IV 与密文一起存（IV 不是秘密，但必须唯一）。这条在代码评审里查，比在测评现场查便宜一百倍。

失分点四：只做了签名证书，没有加密证书。 国密 TLCP 是双证书体系：签名证书用于身份鉴别与签名，加密证书用于密钥传输/密钥协商，两张证书可以来自同一 CA 但是不同的密钥对。RSA 体系里一张证书包打天下的习惯，直接搬到 TLCP 上会握手失败。

失分点五：审计只记业务操作，不记密钥操作。 "谁在什么时候用哪把密钥加密了什么"必须留痕，包括密钥的生成、启用、禁用、轮换、销毁。只记 user_id 登录日志，不记 KMS 调用日志，管理层面必然失分。

失分点六：随机数源不合规。 密钥、IV、盐值都依赖随机数。用 Math.random()、时间戳、或者"伪随机够用"的自研算法，GM/T 0005 的随机性检测过不去。用密码模块的随机源，或者操作系统 CSPRNG（/dev/urandom、getrandom(2)），别自己造。

四、参考架构：一个应用、两套密码栈、三层密钥

先把结论画出来，再逐个解释。核心思想是把"用哪个算法"从业务代码里彻底摘出去——业务只说"这是哪一类数据"，由网关决定用 SM4 还是 AES。

                      应用区（同一套代码，全球一份镜像）
      order-svc    profile-svc    report-svc    api-gateway
           |            |             |             |
           +------------+-------------+-------------+
                                |
                  统一接口 POST /crypto/{encrypt,decrypt,sign}
                  参数只有 key_alias + data_class，不含算法名
                                |
                    +-----------v---------------------------+
                    |   密码服务网关 crypto-gateway          |
                    |   算法路由器：SM4-GCM / AES-256-GCM    |
                    |   DEK 缓存（LRU + TTL，目标命中率>99.5%）|
                    |   审计流：密钥操作逐条留痕              |
                    +-----+-----------------------+----------+
                          |                       |
        data_class=CN     |                       |   data_class=EU/US
                          v                       v
              +-------------------+     +----------------------+
              | 国密密码机 (HSM)   |     | FIPS 140 L3 HSM      |
              | RootKey-CN        |     | RootKey-GLOBAL       |
              | 不可导出，双人授权 |     | 不可导出，双人授权    |
              +---------+---------+     +----------+-----------+
                        |                          |
                        +-----------+--------------+
                                    |
                     只交换"重封装后的 DEK"，密钥材料不出域

同一张图用 Mermaid 表达，方便贴进设计文档：

graph TD
    A[业务应用 order/profile/report] -->|key_alias + data_class| B[密码服务网关]
    B --> C{算法路由}
    C -->|data_class=CN| D[国密 HSM: RootKey-CN]
    C -->|data_class=EU/US| E[FIPS HSM: RootKey-GLOBAL]
    D --> F[KEK-CN]
    E --> G[KEK-GLOBAL]
    F --> H[DEK SM4-GCM]
    G --> I[DEK AES-256-GCM]
    H --> J[密文: alg 标签 + key_id + iv]
    I --> J
    H -.重封装.-> K[跨域通道: 仅 wrapepd DEK]
    I -.重封装.-> K

4.1 三层密钥，各有各的寿命

这个结构的价值不是"分层好看"，而是把密码机的调用次数压到极低。密码机的 QPS 与并发连接都是稀缺资源，把每个字段的加解密都打到密码机上，一个日活百万的应用能把密码机打爆。三层结构下，密码机每天只处理"生成 DEK"与"解封 DEK"两类请求。

4.2 信封加密把调用量降四个数量级

算一笔账：1 亿条记录，每条一个字段需要加密。

• 方案 A：每条调用一次 KMS 加密接口。 AWS KMS 对称请求 $0.03/万次，1 亿次 = 10,000 万次 ÷ 1 万 × $0.03 = $300/月，还没算延迟——每次调用都是一次网络往返。
• 方案 B：每 1 万个字段共用一个 DEK，DEK 由 KMS 生成一次。 1 亿 ÷ 1 万 = 1 万次 GenerateDataKey，加上缓存后实际调用更少。同样的 1 亿次字段加密全部在进程内完成，KMS 账单从 $300 掉到 不到 1 美元。

四个数量级的差距，就是"信封加密是不是必须做"的答案。延迟侧的差距更夸张：我们在 2026 年 10 月对 AWS 各区域 KMS 端点做过建连实测（从美西节点发起），冷连接的 TCP + TLS + 总耗时分别是：us-west-1 0.052 / 0.265 / 0.289 s、ap-northeast-1 0.123 / 0.503 / 0.607 s、ap-southeast-1 0.203 / 0.698 / 0.867 s、sa-east-1 0.237 / 0.764 / 0.940 s。

这组数字有两个直接结论。第一，TLS 段远大于 TCP 段（0.21–0.66 s），说明握手本身就贵，连接必须复用，绝不能"每次加密新建客户端"。第二，密钥必须与数据同区——跨境每次解封 DEK 都要付一次跨洋往返，在双栈架构里这会变成 P99 的主要来源。如果你的 DEK 需要跨域解封，那不是架构问题，是设计错误。

4.3 跨域只搬运"重封装后的 DEK"

这是整个架构里最容易做错、也最容易被资质审核打回的一点：密钥材料不能跨法域复制。

境内国密密码机里的 RootKey-CN，其密钥材料不允许以任何形式出现在境外；反过来也一样。那跨域分析怎么做？答案是重封装（re-wrap），不是导出：

1. 境内数据在新加坡落地需要被境内系统读取时，境内侧的 DEK 由 RootKey-CN 解封后，用目标域的 KEK-GLOBAL 公钥/密钥重新封装一份；
2. 传输的是"用目标域密钥保护的 DEK"，任何一方单独持有都解不开；
3. 目标域用自己的 RootKey-GLOBAL 解封后拿到同一个 DEK，完成解密。

整个过程里，Key material 从来没有以明文形式跨越边界，RootKey 也从未离开各自的密码机。这条链路是"密钥主权"落地的技术实质，也是 10-01 那篇讲 BYOK/HYOK 时没有展开的部分——BYOK 的前提，是接收你密钥的那个盒子有资质、且密钥真的导不出来。

五、云密码机资质核验：四个问题问完就知道能不能用

选型页面上写"支持国密"和"通过商用密码产品认证"是两件事。见过产品文档写"支持 SM2/SM3/SM4"，一问认证证书编号就沉默——那多半是软件实现了国密算法，而不是拿到了认证的密码模块。

核验四问，缺一不可：

问题一：这块密码机有没有商用密码产品认证证书？ 2023 年修订的《商用密码管理条例》把商用密码产品从"型号审批"改为"认证制度"，认证证书可以在国家密码管理局公布的商用密码产品认证目录与认证机构查询。要拿到证书编号与有效期，而不是一句"已通过国密认证"。注意认证是按产品型号发的，同一厂商的不同型号不能互相引用。

问题二：支持哪几个国密算法，是硬件实现还是软件实现？ SM2（签名/密钥交换）、SM3（摘要）、SM4（对称）是基础三件套，SM9（标识密码）是加分项。更关键的是"硬件实现"——密码卡/密码机里的 SM4 是硬件流水线，软件库里的 SM4 是 CPU 跑出来的，两者在合规判定上可能都算"用了商用密码"，但在性能与密钥保护上完全不是一回事。

问题三：密钥能不能导出？ 真正的密码机（HSM）里，密钥标记为不可导出，任何管理员都无法取出明文，只能做双人授权的备份。如果厂商告诉你"密钥可以导出备份到文件"，那它在密评的"密钥管理"层面会被严重质疑。

问题四：是单租户独占还是多租户共享？ 合规场景通常要求独占的密码资源。云上"托管 KMS 的硬件密钥管理实例"与"独立密码机实例"就是两个不同档次的东西，价格差一个数量级，资质覆盖范围也不同。

5.1 三云能力对照

三条读表心得：

第一，AWS 在国密这条线上是空白，这不是缺点而是定位。 它的强项是 FIPS 140-3 Level 3、单租户、以及和 IAM/KMS 的深度集成。面向欧美客户的业务用 AWS 完全正确，只是别指望它帮你过中国密评。

第二，腾讯云的国际站与中国站是两套产品线。 国际站只有基础版/专业版，没有国密版；国密版仅中国站提供，且价格约为国际站的 1.5 倍。做全球化部署时，"同一个腾讯云账号全球一套"是不成立的，注册主体与站点必须先分开。

第三，交付周期是隐藏的项目风险。 独享版密码机需要物理发货与机房协调，官方提示至少预留两个月。如果你的密评窗口已经排到三个月后，今天不下单就来不及。 这也是本文把"资质核验"放在"实操"前面的原因——它是关键路径。

六、双栈实操：先测吞吐，再决定哪一段走国密

6.1 三种双栈形态，选第二种

推荐双端口：它的可回滚性最好——出问题只需把 8443 的流量切回 443，不涉及协议层改造。而且它天然满足"对外兼容主流浏览器、对内满足合规"的双重要求，因为主流浏览器默认并不支持国密 TLS，对外站点上纯国密等于自断流量。

6.2 国密算法的最小验证集

先确认你的 OpenSSL 认识国密算法（1.1.1 起原生支持 SM2/SM3/SM4）：

openssl version
openssl enc -ciphers | grep -i sm4   # 期望看到 -sm4-cbc -sm4-cfb -sm4-ctr -sm4-ecb -sm4-ofb

SM2 密钥对与签名验签：

openssl ecparam -name SM2 -genkey -out sm2.key
openssl pkey -in sm2.key -pubout -out sm2.pub
openssl dgst -sm3 -sign sm2.key -out sig.bin payload.json
openssl dgst -sm3 -verify sm2.pub -signature sig.bin payload.json

四行命令覆盖了密评"应用和数据安全"层面最常被抽查的两项：SM2 签名（不可否认性）与 SM3 摘要（完整性）。注意 openssl dgst -sm3 -sign 走的是 SM2 签名算法，不是"SM3 签名"——SM3 是摘要，签名算法是 SM2，这个措辞在报告里别写错。

SM4 加解密：

KEY=$(openssl rand -hex 16)      # 128 位密钥，32 个 hex 字符
IV=$(openssl rand -hex 16)       # 128 位 IV，32 个 hex 字符
openssl enc -sm4-cbc -K "$KEY" -iv "$IV" -in plain.bin -out cipher.bin
openssl enc -d -sm4-cbc -K "$KEY" -iv "$IV" -in cipher.bin -out plain.out
cmp plain.bin plain.out && echo OK

-K 与 -iv 必须是大写参数（十六进制输入），小写 -k 是口令派生，两者完全不是一回事。这条坑每年都有人踩。

6.3 TLCP 双证书：社区版 OpenSSL 说不了国密 TLS

上面四条命令用的是标准 OpenSSL，但它不支持 TLCP 协议——也就是不能做国密 TLS 握手。国内落地的方案是铜锁（Tongsuo，原 BabaSSL），编译时要显式开启 NTLS：

git clone https://github.com/Tongsuo-Project/Tongsuo.git
cd Tongsuo && ./config enable-ntls --prefix=/opt/tongsuo
make -j"$(nproc)" && make install
/opt/tongsuo/bin/openssl ciphers -ntls | head

握手验证（套件名以 ciphers -ntls 的实际输出为准，常见为 ECC-SM4-SM3）：

/opt/tongsuo/bin/openssl s_client -connect gm-gw.example.com:8443 \
  -ntls -servername gm-gw.example.com -cipher ECC-SM4-SM3 -brief

TLCP 与 TLS 1.3 的结构差异，就三点但都致命：

第一，双证书。 服务端要配签名证书与加密证书两张（各自的 SM2 私钥），客户端也要能提供两张。只配一张，握手直接失败。

第二，密钥交换不同。 TLCP 基于 ECC 的密钥交换与密钥传输两条路径，没有 TLS 1.3 的 (EC)DHE-only 模型，也没有 0-RTT。

第三，证书链要能验到国密根。 客户端信任库必须包含国密 CA 的根证书，否则报"unknown CA"。这在多云环境里尤其麻烦——每台机器的信任库都要刷，且不能覆盖掉原有的公有 CA 根证书（否则对外 HTTPS 全挂）。

6.4 应用层信封加密：40 行代码

网关里的核心逻辑其实很短。下面这段是骨架，alg 字段随密文存，解密时按 alg 路由——这就是"算法可演进"的全部秘密：

import os, json, base64, hashlib, hmac, boto3
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from gmssl.sm4 import CryptSM4, SM4_ENCRYPT, SM4_DECRYPT

kms = boto3.client("kms", region_name="ap-southeast-1")

def b64(b): return base64.b64encode(b).decode()

def hmac_sm3(key: bytes, msg: bytes) -> bytes:
    return hmac.new(key, msg, lambda d=b"": hashlib.new("sm3", d)).digest()

def new_dek(alias: str):
    r = kms.generate_data_key(KeyId=alias, KeySpec="AES_256")
    return r["Plaintext"], r["CiphertextBlob"]

def encrypt(alias: str, data: bytes, alg: str) -> dict:
    dek, wrapped = new_dek(alias)          # 明文 DEK 只在内存里活几微秒
    if alg == "SM4-CBC-HMAC-SM3":
        iv = os.urandom(16)
        c = CryptSM4(); c.set_key(dek[:16], SM4_ENCRYPT)
        ct = c.crypt_cbc(iv, data)
        tag = hmac_sm3(dek[16:], iv + ct)[:16]
    else:
        iv = os.urandom(12)
        sealed = AESGCM(dek).encrypt(iv, data, None)
        ct, tag = sealed[:-16], sealed[-16:]
    return {"alg": alg, "key": alias, "iv": b64(iv),
            "ct": b64(ct), "tag": b64(tag), "dek": b64(wrapped)}

三个设计点值得强调：

alg 与 dek 一起存。 密钥轮换、算法迁移、历史数据兼容，全靠这个自描述的头。没有它，两年后你无法知道一条密文该用哪把密钥、哪个算法解。

SM4 走 CBC + HMAC-SM3，而不是自己拼 GCM。 Python 的 gmssl 库不提供 SM4-GCM，而"加密后不认证"是典型漏洞。CBC + HMAC（先加密后 MAC，Encrypt-then-MAC）是标准做法，且能通过测评。若要用 SM4-GCM，用硬件密码机或支持该模式的国密库。

DEK 明文不落盘、不进日志。 这是密评现场最常查的一条：抓一次 GC dump 或者翻一遍日志文件，能出现明文密钥的，直接失分。

6.5 性能：SM4 没有 AES-NI，这是一个数量级的差距

这是双栈架构里最现实的问题。自己测，别信宣传：

openssl speed -evp aes-256-gcm -seconds 3   # 可走 AES-NI 指令
openssl speed -evp sm4-cbc -seconds 3       # 通用 x86 无专用指令，纯软件实现

在本文的测试机上跑一遍（单核 AMD EPYC，OpenSSL 3.0.2，未开多线程），差距是这样的：

注意两点，否则这组数字会误导你。第一，SM4-CBC 是串行模式（后一块依赖前一块），本来就吃亏；换成可并行的 SM4-GCM 差距会缩小，但仍不会有 AES-NI 那种数量级的加速。第二，SM4-GCM 在很多发行版里根本不可用——本文测试机上 openssl speed -evp sm4-gcm 直接报 unsupported，因为 OpenSSL 3.0 的默认 provider 没有这个算法。要上 SM4-GCM，得靠硬件密码机、支持它的国密库，或者自己实现（极不推荐）。

判据很简单：如果 SM4 的吞吐低于 AES 的三分之一，而你的加密点又在业务主链路上，就必须做三件事之一——卸载到密码机、换支持 SM4 指令集的 CPU（ARMv8.4 的 SM3/SM4 扩展、部分国产 CPU 都有）、或者把加密从同步链路挪到异步批量。

一条常被忽略的事实：不是所有国密都慢。SM2 的签名运算在同等安全强度下比 RSA-2048 快一个量级（SM2 的 256 位曲线对标 RSA 3072），而它的密钥交换相比 X25519 并没有优势。所以代价几乎全部落在数据面的 SM4 上：握手不慢，传数据才慢。

七、成本：合规资质的溢价是 68 倍

把前面的事实代入同一场景，差距一目了然。场景：20 把自定义密钥 + 每月 500 万次对称加解密。

同样是"加密 500 万次"，$35 与 $2,371 差了 68 倍。 这 68 倍买的不是性能，是"密钥在独占的、通过认证的硬件里，任何人都导不出来"这个事实。如果你的密评范围里包含这套系统，这笔钱省不掉；如果系统纯海外、不需要中国资质，那这 68 倍就是纯浪费。

还有三个容易漏算的成本项：

第一，QPS 费比密钥数贵。 阿里云国际的按量口径里，QPS 是 $0.5/QPS/天——20 QPS 跑满一天就是 $10，一个月 $300，而 20 把密钥的月费才 $0.9 × 20 ≈ $18。先估峰值 QPS，再谈密钥数量。

第二，轮换会放大账单。 GCP 按"活跃密钥版本"计费，同一把密钥轮换 5 次就是 5 个版本收 5 份钱；AWS 是第 1、2 次轮换各加 $1/月后封顶。跨云统一轮换策略时，这两个口径必须分开算。

第三，密评本身是一次性 + 年度的双重支出。 首次评估含方案评估、系统评估、整改复测；此后 CII 每年一次。评估费用按测评点数量与系统规模报价，不同机构差异可达两三倍，且整改工时通常大于测评费——把密钥层级重建一遍的工程量，不是一个测评项目组能覆盖的。预算里要给整改留出至少与开发同等量级的人力。

八、三阶段割接：把一次大改造拆成三个可回滚的动作

不要试图"一次性切到国密"，那等于同时改算法、改证书、改密钥来源、改审计，任何一个环节出错都无法定位。按风险从低到高切三段：

阶段一（2–4 周）：盘清与打地基。

• 清点密码调用点：grep -rn "AES\|RSA\|SHA256\|Cipher.getInstance" --include=.java --include=.py --include=*.go，输出一份"算法资产清单"（哪个服务、哪个字段、用什么算法、密钥从哪来）；
• 给所有密文加上自描述头（alg + key_id + iv），这是后面所有迁移的前提；
• 建密钥层级：RootKey 进密码机、KEK 按租户、DEK 即用即弃；
• 这一阶段不改任何现有数据的加密方式，只加壳，风险接近零。

阶段二（4–8 周）：新数据走新栈。

• 密码服务网关上线，业务侧从"直接调算法"改为"调网关"；
• 新写入的数据按 data_class 决定用 SM4 还是 AES，老数据原样不动；
• 双端口就位：443 保持 TLS、8443 提供 TLCP，先只让内部服务与合规审计流走 8443；
• 回滚手段：网关配置里把 data_class=CN 临时指向 AES 路径，密文头里的 alg 保证历史数据仍可解。

阶段三（8–12 周）：存量重加密 + 密评。

• 存量数据按优先级分批重加密（先个人敏感信息，再业务数据），单批可中断、可断点续跑；
• 双人授权的密钥管理员流程、审计留存、应急预案补齐——这些是管理层面的分数；
• 提交方案评估 → 系统评估 → 整改 → 复测。

判断要不要走完全程的标准只有一条：系统是否在密评范围内。 不在范围内的存量数据，不要为了"技术洁癖"重加密 1 亿条记录——那是纯成本，且会引入新的故障面。

九、七个工程坑，每一个都真实发生过

坑一：在业务代码里写死算法名。 Cipher.getInstance("SM4/CBC/PKCS5Padding") 散落在几百个文件里，双栈就变成双份代码。正确做法是业务只传 data_class，算法决策收敛到网关一个地方。这条决定你未来能不能在半年内换算法（后量子迁移时你会感谢自己）。

坑二：拿 KMS 的"软件密钥管理实例"当密码机用。 两者在计费上差十倍，在资质上差一个体系。软件实例的密钥保护在云厂商的软件层，密评对"密钥在符合要求的密码模块内"这一条会追问硬件边界。

坑三：双证书只配了一张。 TLCP 握手时服务端要出示签名证书与加密证书，客户端校验两张。只配签名证书的典型症状是"握手到 Certificate 阶段就断，抓包看不出原因"。

坑四：把 BYOK 理解成"把密钥复制到另一个云"。 BYOK 是把密钥材料导入目标云的密码机，材料一旦导入，就受目标云的物理边界约束——这不等于密钥主权。真正的跨域方案是重封装（见 4.3 节），密钥材料始终不出域。

坑五：SM4 不压测就上线。 一个日请求 5,000 万的接口，把 AES-GCM 换成 SM4-CBC，如果没有硬件加速，CPU 会先于数据库成为瓶颈。上线前用 openssl speed 压一遍，再在预发环境跑一次全链路压测。

坑六：把密评整体外包给安全团队，架构团队不参与。 密评的整改 80% 是架构改动（密钥层级、证书体系、审计埋点），安全团队只能出报告和制度，改不动代码。这件事必须由架构负责人牵头，安全团队做判据解读与材料准备。

坑七：独享版密码机的交付周期没排进计划。 前面提过，官方提示至少预留两个月。项目计划里把它当成"下单即到"，结果测评窗口只能往后推一个季度。

总结

商用密码合规这件事，难点从来不在"把 AES 换成 SM4"，而在三件事上：定位要准（先判断系统是否落在密评范围内，纯海外业务不要自找麻烦，CII 与等保三级系统不要心存侥幸）、架构要对（RootKey 进密码机、三层密钥、信封加密把调用量降四个数量级、跨域只搬重封装后的 DEK）、顺序要稳（盘清 → 新数据走新栈 → 存量重加密，每步都能回滚）。

最后给一个务实的判断：如果你的系统在密评范围内，那么现在最该做的不是选云，而是把"自描述密文头"（alg + key_id + iv）加到所有加密点上去。 这个改动两周能做完、零风险，却是后面所有算法迁移、密钥轮换、跨域重封装的前提。没有它，你两年后面对一亿条无法判断用哪把密钥加密的数据，只能全部重来。

而如果你的业务纯在海外、客户也不要求中国合规，那就别引入国密——把预算花在 FIPS 140-3、单租户 HSM 与密钥轮换自动化上，那才是对的方向。合规是法域的函数，不是技术的偏好。

相关阅读

• 多云密钥管理与加密策略 — KMS 选型、Secrets Manager 与轮换自动化
• 多云 PKI 证书生命周期管理 — 证书状态机、ACME 与 mTLS
• 数据主权与主权云架构 — BYOK/HYOK 与数据边界控制
• GDPR 跨境数据传输技术指南 — SCC、分类分级与出境台账
• 后量子密码迁移路线 — 算法敏捷性与混合 KEM
• 机密计算与 TEE 数据可用性 — 运行时明文的最后一道防线
• 海外服务器安全加固清单 — 主机侧 24 项检查

本文由 7.chengzicloud.cloud 提供，点击访问首页了解更多