面向密评合规的密钥管理实践：审批工作流与三员分离的工程实现

摘要：密评对"密钥管理"控制项提出人员职责分离、审批授权、操作审计与密钥分级要求。本文从工程落地视角，围绕密钥全生命周期、分级模型、三员分离、审批工作流、操作留痕与访问矩阵六个维度，拆解如何通过密钥管理系统把制度要求转化为可审计、可举证的技术控制，并提供国密、国际与后量子算法的统一管理能力。 正在上传图片...

关键词：密钥管理系统、国密密钥管理、密评合规、信封加密、GM/T 0051、后量子密码、数据加密方案

一、密评"密钥管理"控制项到底在考什么

密评不是只看"有没有加密"，而是看密码技术是否贯穿身份鉴别、访问控制、数据传输、存储、密钥管理等层面。其中"密钥管理"易被低估、却常成扣分项。核心诉求四句话：

第一，密钥不能裸奔。密钥在全生命周期里必须始终处于受控密码边界内，尤其根密钥、主密钥，绝不以明文出现在内存、配置文件或日志。

第二，密钥要有等级。不同敏感度密钥不能混为一谈，数据密钥、密钥加密密钥、主密钥应分层保护，高密级密钥泄露不应直接导致海量数据失密，这就是信封加密（密钥封装）的初衷。

第三，操作要分人。密钥创建、使用、销毁不能一人说了算，系统管理员、安全管理员、审计管理员三类职责必须分离、相互制约。

第四，行为要留痕。谁、何时、以何理由、对哪个密钥做了什么，必须被完整、不可篡改地记录，并能作为密评举证。

密评落脚点始终是技术实现——制度要被系统强制，而非靠自觉。这正是密钥管理系统根本问题：把"应该怎么做"变成"只能怎么做"。

二、密钥全生命周期：从生成到销毁的七道关口

规范的密钥管理系统应把密钥状态机清晰建模，常见状态包括：预生成、生成、存储、激活、使用中、更新、归档、注销、销毁。对应七道关口如下：

以硬件密码机为基座的密钥管理系统有天然优势：根密钥和主密钥在密码机内部生成、内部存储，永不以明文导出。即便数据库被拖库、备份被窃取，攻击者拿到的也只是被主密钥加密过的密文密钥，无密码机授权无法还原。这种"密钥不出密码机"的设计，是满足密评"密钥存储安全"的最直接技术抓手。

部署形态上还需考虑高可用与密钥备份。生产环境通常要求密码机集群部署、多节点冗余避免单点故障；容灾更高场景会配置热备与冷备。无论哪种形态，密钥明文始终在密码机边界内，备份恢复同样纳入三员审批与操作留痕，否则高可用变合规盲区。

下图给出密钥全生命周期状态机的工程视图，七个关口均有技术控制落地：

图1

三、密钥分级：信封加密为什么是必选项

很多早期系统失误在于"一把主密钥加密所有数据"。一旦主密钥泄露，全部历史数据都要重加密，代价巨大。正确做法是用三层密钥结构分级保护，这也是数据加密方案里最常见的信封加密模型：

• 主密钥（MK）：最高层级，由密码机保护、永不明文导出，用于加密密钥加密密钥。
• 密钥加密密钥（KEK）：由主密钥加密保护、用于加密数据密钥，可按租户或业务域划分。
• 数据密钥（DK）：真正加密业务数据的密钥，用完即焚或随数据存放，量大、生命周期短。

信封加密的工程流程：业务侧请求一个数据密钥，密钥管理系统在密码机内用密钥加密密钥把数据密钥封装成密文（即"数字信封"），把明文数据密钥短暂返回给业务进程用于加密数据，业务侧把密文数据密钥与密文数据一起存储。解密时反向操作。这样即便数据密钥明文短暂出现在业务内存，持久化形态始终是被封装的，主密钥则自始至终不离开密码机。

// request a wrapped data key from the key management system
public DataKeyRequestResponse requestDataKey(String kekId) {
    // wrap DEK inside HSM with KEK; plaintext key never persists
    KeyRequest req = KeyRequest.builder()
            .keyType("SM4")          // 国密 SM4 数据密钥
            .kekId(kekId)            // 由主密钥保护的密钥加密密钥
            .exportMode("WRAPPED")   // 仅返回封装后的密文密钥
            .build();
    return kmsClient.generateDataKey(req);
}

    // wipe the plaintext DEK immediately after encryption
    byte[] cipher = sm4Encrypt(plainData, response.getPlainKey());
secureWipe(response.getPlainKey());

这种分层模型的合规价值在于：密评关注的"密钥存储安全"和"密钥使用安全"被拆成不同层级分别举证。主密钥不出密码机，数据密钥受封装保护，证据链清晰可查。

四、三员分离：制度如何变成系统强制

"三员"指系统、安全、审计三类管理员。在等保与密评双重语境下，三员分离是成熟且强约束的要求，但三员具体管什么需落到更细颗粒度：

• 系统管理员：负责日常运行维护，例如节点监控、租户开通、资源配额、拓扑配置。可"看"系统健康，但通常无权直接操作高密级密钥的创建与销毁。
• 安全管理员：负责密码策略配置与密钥操作的安全审批，例如密钥长度、算法白名单、轮转周期、关键操作的审批裁决，是安全规则的制定者和守门人。
• 审计管理员：负责查看、导出、归档审计日志，监督前两者。审计管理员不能改配置、不能做审批，只能"看"和"存证"。

三员分离在工程上的关键不是"有三个账号"，而是"三个账号的权限互斥且不可越权"。比如系统管理员发起"销毁某主密钥"的操作，本身不能直接生效，必须进入安全管理员的审批队列；审计管理员能看到完整记录，却无法阻止或放行。三者形成"操作—审批—监督"的三角制约。

// three-role matrix: operations, approvals, audits are mutually exclusive
type Role string
const (
    SysAdmin  Role = "system"   // system admin: ops only
    SecAdmin  Role = "security" // security admin: approvals only
    AudAdmin  Role = "audit"    // audit admin: read-only
)

func canApprove(r Role, op Operation) bool {
    if r != SecAdmin {
        return false // only security admin may approve
    }
    return op.requiresApproval
}

func canExecute(r Role, op Operation) bool {
    // critical ops run by a role other than the approver
    return r == SysAdmin && op.applicant != "sysadmin"
}

权限模型在后台把三员角色以独立账号体系落地，并强制"申请人≠审批人"：任何涉及主密钥、密钥加密密钥的创建、注销、销毁，必须由安全管理员二次确认，且审批动作本身也记为独立审计事件。这种把制度写进代码的方式，比流程文档更有说服力，也更易在密评现场调出证据。

五、审批工作流：把"谁同意的"写进每个关键操作

三员分离解决"职责边界"，审批工作流解决"关键动作必须被授权"。并非所有操作都需审批——频繁的数据密钥申请每次人审会让业务卡死；但主密钥创建、密钥注销与销毁、策略变更，则必须走审批。

一个可落地的审批工作流通常包含以下状态：

提交申请 ──▶ 待审批 ──▶ 审批通过 ──▶ 执行中 ──▶ 已完成
                 │
                 └──▶ 审批驳回 ──▶ 已终止

关键设计点有三个。其一是分级审批阈值：低密级数据密钥可自动放行或一级审批，高密级需双人复核甚至多级审批。其二是审批与执行分离：审批人只做"同意/驳回"，真正执行由系统侧在密码机内完成，审批人无法接触密钥明文。其三是审批上下文留痕：申请时填理由、影响范围、生效时间，审批时记意见，字段全部进入审计日志。

    # simplified state machine for approval routing
def route_approval(key_level: str, op: str) -> str:
    if key_level == "DATA" and op == "GENERATE":
        return "AUTO"          # 数据密钥自动放行
    if key_level in ("KEK", "MK"):
        return "DUAL"          # 密钥加密密钥/主密钥需二级审批
    return "SINGLE"            # 其他一级审批

def on_approve(ticket_id: str, approver: str, comment: str):
    # write audit: who/when/with what comment approved which ticket
    audit.log(
        action="KEY_OP_APPROVE",
        ticket=ticket_id,
        actor=approver,
        detail=comment,
        timestamp=now_iso()
    )

实践中容易踩的坑。比如把审批做成"橡皮图章"——前端弹确认框就当审批，后台却未区分申请人与审批人身份，这在新版密评细则下很难过关。再比如审批日志与操作日志割裂，导致"申请—审批—执行"三段无法闭合。合格的密钥管理系统应让三个环节共享同一个工单号，形成完整证据链。

六、操作留痕与审计举证：密评现场的"硬通货"

密评专家核查"密钥管理"控制项时，最看重的往往不是你说了什么，而是能否当场调出一条完整、防篡改、可追溯的操作记录。操作留痕须做到四点：

第一，全量覆盖。凡涉及密钥状态变更的操作都要留痕，不能遗漏。

第二，内容充分。一条合格审计记录至少包含：操作主体、操作客体（哪个密钥、密级）、操作类型、时间、来源地址（远程接入需标记）、结果、关联工单号（是否审批）。

第三，防篡改。审计日志应只追加不可删除，关键字段建议由密码机签名，确保日志可验证，防事后补录或删改。

第四，可导证。日志要能按"密钥/人员/时间"维度快速检索导出，密评现场常需几分钟拿出某密钥完整轨迹。

{
  "event_id": "evt_20260530_0a1b",
  "ticket_id": "TK-20260530-7781",
  "actor": "sec_admin_zhang",
  "role": "security",
  "object": "kek:tenantA:sm4-kek-03",
  "key_level": "KEK",
  "action": "KEY_DESTROY",
  "source": "remote-admin-console",
  "result": "SUCCESS",
  "approver": "sec_admin_li",
  "approve_comment": "业务下线，按归档策略注销",
  "timestamp": "2026-05-30T14:22:05+08:00",
  "signature": "MEUCIQ..."
}

审计模块把上述字段结构化落库，提供按密钥、按人员、按时间三种检索视图，关键事件带密码机签名。密评准备阶段，运维可直接导出某把主密钥从生成到销毁的轨迹，作为"密钥管理"控制项举证附件，无需临时拼凑。

实际运维中，远程接入控制台的来源地址标识尤为重要。管理员通过远程接入登录执行审批或变更时，审计记录须标记接入来源、时间与身份，并与堡垒机或统一身份系统日志交叉印证。跨地域集群还应在日志保留节点标识，确保轨迹可按拓扑回溯。

七、访问矩阵：把"谁能对什么密钥做什么"画成一张表

权限管理的最终落点是一张清晰的访问矩阵。很多系统权限混乱的根源在于"按人授权"而非"按角色与资源授权"。推荐以"角色 × 密钥域 × 操作"三维建模：

下图给出访问矩阵的约束示意，便于在密评现场演示"系统管理员无法销毁主密钥"等强制点：

图2

这张表的价值在于把抽象制度翻译成可校验配置。密评时专家常要求演示："请证明系统管理员无法销毁主密钥""请证明业务应用无法读取主密钥明文"。若访问矩阵在系统强制生效，这类演示点几下即可；若文档写写、系统随便配，现场就会露馅。

此外，多租户隔离也是访问矩阵的延伸。云平台或集团化部署场景下，不同租户、不同业务域的密钥必须逻辑隔离、互不越权。密钥管理系统应支持租户级密钥命名空间、独立审批流与独立审计视图，确保一个租户操作不污染另一租户证据链。

八、算法与组件：国密、国际与后量子算法的统一支撑

满足密评，算法合规是前提。当前政务、金融、关基行业普遍要求支持国密 SM1、SM2、SM3、SM4，同时保留对国际算法 AES、RSA、ECC、SHA 兼容，应对历史系统和国密改造过渡期并存需求。更前瞻的布局是把后量子密码（PQC）纳入统一密钥管理体系——例如 Kyber 用于密钥封装、Dilithium 用于签名，为"现在加密、未来被量子破解"的存储型数据提供长期保护。

组件层面，完整密钥管理基础设施通常不止"管密钥"本身，还会联动若干加密能力组件，让业务以最小改造成本获得合规加密：透明数据加密用于数据库落盘保护，密钥应用交付用于把密钥安全下发，密钥传输管理用于跨域同步，数据库加密网关、防勒索数据保护、证书签发、短消息安全、统一密钥服务等分别面向不同业务需要。这些组件共享同一套基座与同一套审计体系，保证"管"与"用"证据一致。

需要特别说明，密钥管理系统是否通过 GM/T 0051 等标准认证，是密评举证加分项。选经过认证的密码模块作基座，相当于把"产品本身合规"最难自证部分交给权威第三方。

九、密评举证材料清单：把技术控制翻译成评分项

最后，把所有工程实践收敛成一份举证清单，方便密评前自检。针对"密钥管理"控制项建议准备以下材料：

1. 密钥全生命周期状态机说明，配截图证明七个关口均有技术控制。
2. 密钥分级与信封加密设计文档，说明主密钥不出密码机、数据密钥受封装。
3. 三员角色定义与权限矩阵，配后台配置截图，证明三者互斥。
4. 审批工作流说明，配典型工单轨迹截图，证明申请—审批—执行闭合。
5. 审计日志样例，证明全量覆盖、字段充分、防篡改、可导证。
6. 算法支持清单，证明国密与国际算法并存，并有后量子扩展规划。
7. 密码模块认证证书或相关合规证明，作为第三方合规证据。
8. 多租户隔离说明，证明不同租户密钥命名空间与审计视图隔离。

把这些材料按"制度—技术—证据"三层组织，密评时就能做到"专家问到哪、证据点到哪"。

方案参考

从通用落地角度，建议做密评或等保合规的单位在密钥管理建设上遵循以下原则。若需对照商业化实现，可参考以安当KSP为例的密钥管理系统形态，但以下原则不依赖特定产品，可在任意合规基础设施上落地：

一是优先选择以硬件密码机为基座的密钥管理系统，确保高密级密钥永不明文导出，把"密钥存储安全"建立在物理与逻辑双重边界之上。

二是务必把三员分离和审批工作流作为系统上线前的强制配置，而不是事后补流程。权限矩阵要角色化、资源化，避免按人散配。

三是建立密钥分级与信封加密模型，按数据敏感度划分主密钥、密钥加密密钥、数据密钥三层，降低单点泄露的连锁风险。

四是审计日志要做到全量、结构化、防篡改、可导证，并确保申请、审批、执行共享同一工单号，形成闭合证据链。

五是算法层面以国密 SM1/SM2/SM3/SM4 为基线，保留国际算法兼容，并把后量子密码纳入中长期演进路线，应对长期存储数据的量子威胁。

六是若采用多租户或集团化部署，必须实现租户级密钥命名空间与独立审计视图的隔离，防止证据链相互污染。

七是优先选用通过 GM/T 0051 等标准认证的密码模块作为底座，用第三方测评结论降低自证难度。