密钥生成与分发权限控制
咱们接着聊权限这档事。我个人觉得，密钥整个生命周期里最容易出乱子的，就是生成和分发这两个环节。为什么？因为很多公司把密钥当成“配置项”来管理，谁都能碰，最后审计的时候才发现，谁生成的、谁分发的、谁签收的，全是一笔糊涂账。
PCI DSS 第3.5、3.6、3.7节对这块其实写得挺明白——但落地的时候，我见过太多翻车的案例。今天就把我这些年踩过的坑、总结的套路，一块儿过一遍。
3.1 密钥生成权限：谁有资格“造”钥匙？
先问个问题：你公司的密钥生成功能，是不是DBA、运维、甚至开发人员都能点一下按钮就生成一个？如果是，那基本就是PCI审计的高危预警。
PCI DSS 要求很直白：密钥生成必须由角色隔离的、已授权的人员操作。说白了，就是一个萝卜一个坑——只有指定的人，才能执行生成动作。
核心原则
- 双人控制（Split Knowledge）：生成密钥时，至少两人在场，每人只能掌握一部分密钥材料。
- 职责分离：生成密钥的人，不能同时是使用密钥的人，更不能是审计密钥的人。
- 可追溯：谁在什么时间、什么设备上、生成了哪个密钥，都要有不可篡改的日志。
我记得有个项目，客户把密钥生成功能直接集成在CMDB里，每个运维都能登录进去“创建密钥对”。结果审计方一查，发现某个月生成了43个密钥，其中18个没有对应的负责人记录。整改起来那叫一个痛苦——全部重新做密钥轮换，还得补审批流程。
| 角色 | 生成密钥权限 | 审计要求 |
|---|---|---|
| 密钥管理员 | 是（需双人） | 操作日志实时上报SIEM |
| 系统管理员 | 否 | 只有查看已生成密钥列表的权限 |
| 应用开发 | 否 | 只能通过API申请，不能直接生成 |
| 安全审计员 | 否 | 只读，且不能操作任何生成动作 |
避坑指南
我曾经在集成HSM（硬件安全模块）时，遇到团队把HSM的管理员PIN写死在脚本里。结果生成密钥的API直接暴露给了所有应用——权限形同虚设。后来强制要求：生成密钥必须通过HSM的KMC（密钥管理客户端），且需要物理钥匙+数字证书双重认证。
3.2 密钥分发权限：密钥“出门”要过几道关？
生成完密钥，下一步就是分发。很多公司对生成抓得紧，对分发却松松垮垮——直接通过邮件、微信、甚至U盘拷贝。PCI DSS 明确说不行。
分发权限控制，我自己总结了三道关：
- 身份验证：接收方必须是申请单上指定的责任人，且需要双因素认证。
- 传输加密：密钥在传输过程中必须用更强的密钥（KEK）加密，或者直接走安全通道。
- 签收确认：接收方收到后，必须签名或电子确认，证明密钥已安全抵达。
你想想看，如果密钥分发没有签收机制，丢了密钥都没人知道。我之前审计一家支付处理公司，发现他们的密钥分发日志里，有30%的条目“接收人”字段是空的——系统根本不拦。后来改成了：不签收，密钥直接作废。
注意：分发过程中必须记录传递链的每一个环节。比如A发给B，B再给C，那么A→B、B→C都要有独立日志。不能只记A→C一笔带过。
举个实际例子，用HSM里的KEK加密要分发的密钥，操作大概是这样——
# 模拟通过KEK加密分发密钥（仅用于演示权限逻辑）
# 实际生产环境中应使用HSM SDK或KMS API
# 1. 用KEK加密明文密钥
openssl enc -aes-256-cbc -salt -in plain_key.bin -out encrypted_key.bin -pass file:kek.bin
# 2. 将加密后的密钥通过安全通道（如HTTPS+客户端证书）传给接收方
# 3. 接收方用自身持有的KEK解密
openssl enc -d -aes-256-cbc -in encrypted_key.bin -out recovered_key.bin -pass file:kek.bin
# 4. 接收方发送签收确认码
echo "RECEIVED $(sha256sum recovered_key.bin | cut -d' ' -f1)" | gpg --clearsign > receipt.asc这个流程里，权限的核心是：只有拥有KEK的人才能解密。而且KEK本身也要受同样的权限控制，不能随便导出。
3.3 权限审计清单：审计员会查什么？
做PCI DSS审计，人家不会只看你写了几页制度。他们直接要日志、要报表、要截图。我整理了一个常用审计点对比表，方便你自查：
| 审计项 | 合格表现 | 常见不合格 |
|---|---|---|
| 密钥生成权限矩阵 | 有矩阵文档，且与实际系统权限一致 | 文档与配置脱节，角色定义模糊 |
| 双人控制证据 | 每次生成都有两人独立的操作日志，时间戳吻合 | 没有日志，或日志只记录了一个人 |
| 分发签收记录 | 100%的密钥分发都有电子签收，且签收人可查 | 只有“已发送”记录，无“已接收”凭证 |
| 权限变更审计 | 任何权限变更都有审批工单，且日志不可修改 | 管理员直接命令行改权限，无审批 |
老工程师的经验之谈：别只在制度里写“双人控制”，你得让系统强制落地。比如HSM里的生成操作，必须插入两把不同的管理员令牌，缺一个都点不了确定按钮——这才是真正的双人控制。
3.4 核心流程总览
下面这张图我把它叫作“密钥生成与分发的权限关卡图”。从申请到签收，每个环节都有权限检查，缺一不可。
3.5 落地检查清单
嗯，最后给张自查表，你拿去对着系统一项项打勾：
- ☐ 密钥生成操作是否强制双人物理或逻辑认证？
- ☐ 是否只有密钥管理员角色可以执行生成，且该角色不能同时是密钥使用者？
- ☐ 分发时是否使用KEK加密，且KEK的存储受同等权限控制？
- ☐ 分发通道是否使用TLS 1.2+并验证服务端证书？
- ☐ 接收方是否有唯一标识，且签收记录可防抵赖？
- ☐ 所有生成/分发操作的日志是否实时同步到集中日志平台，且不可删除？
- ☐ 是否每季度审查一次密钥权限矩阵，确保与实际系统一致？
最后说个我亲眼见过的坑：某厂商的KMS系统，密钥生成API没有做速率限制。一个脚本跑了一晚上，生成了8万多个密钥——直接把HSM内存打满。事后发现是因为管理员把泄露到了GitHub上。从那以后，我所有系统都必须加生成限额和告警。
密钥生成与分发的权限控制，说到底就是“谁可以做什么，每一步都要留下脚印”。你把它当成安全基础设施来搭，后面审计就会很顺。要是当成业务系统的一个小功能来搞，那迟早要返工。好，这一章先到这儿。