4. 密钥存储与访问控制设计

密钥是静态数据加密体系中最关键的“根信任”对象。算法可以公开、密文可以外泄，但只要密钥仍然安全，攻击者就无法还原明文。因此，密钥存储与访问控制设计要回答四个问题：密钥以什么形态落盘、谁能以什么方式使用它、每次使用是否可追溯、以及密钥如何定期更换并在泄露时快速失效。本节围绕这四点展开，并给出可落地的设计参数与示例。

一、密钥落盘保护：分层与封装

密钥落盘的核心原则是“明文密钥不落盘，落盘密钥必封装”。实践中通常采用三层密钥体系：根密钥（Root Key / MK）驻留在硬件安全模块（HSM）或云 KMS 中，永不以明文导出；数据加密密钥（DEK）由根密钥封装后存储；信封密钥（KEK）用于批量封装 DEK，减少对 HSM 的调用压力。

落盘形态有三种常见选择：一是密文封装形式，即 DEK 以 Enc(MK, DEK) 的密文形式存入数据库或配置中心；二是密钥句柄形式，应用只持有 KMS 返回的 key-id，实际加解密在 KMS 内完成；三是本地文件加密形式，配合操作系统密钥环或 TPM 密封。选择依据是合规等级与性能要求：金融、政务场景优先 HSM/KMS 句柄模式，互联网高吞吐场景可采用“本地缓存 DEK + 定期回源解封”的折中方案。

落盘时还需注意元数据保护。密钥版本、算法、创建时间、状态等元数据应与密文一起存储，并做完整性校验（如 HMAC），防止攻击者篡改版本号诱导系统使用已撤销密钥。示例参数：AES-256-GCM 封装，KEK 有效期 12 个月，DEK 有效期 90 天，元数据 HMAC-SHA256 校验。

二、权限模型：最小权限与职责分离

密钥权限不能等同于普通数据权限。推荐采用基于角色与属性结合的模型：角色定义“能做什么”（如 encrypt、decrypt、rotate、revoke），属性约束“在什么条件下做”（如来源 IP、服务身份、时间窗口）。核心是职责分离——加密服务只持有 encrypt 权限，解密服务只持有 decrypt 权限，运维人员只能触发轮换而不能直接读取密钥明文。

一个可参考的权限矩阵如下：

权限授予应绑定服务身份而非个人账号，使用 mTLS 证书或 SPIFFE ID 作为身份凭证。临时提权需走审批流并设置 TTL，例如运维排障时申请 30 分钟 decrypt 权限，到期自动回收。

三、审计日志：可追溯与防篡改

每一次密钥操作都必须留痕，日志字段至少包含：时间戳、请求方身份、密钥 ID 与版本、操作类型、结果（成功/拒绝）、来源 IP、请求 ID。日志本身要防篡改，可采用追加写入（append-only）存储、哈希链或写入独立审计账户。

审计日志的价值在于事后追溯与实时告警。例如，同一身份在 1 分钟内对 50 个不同密钥发起 decrypt，可能是横向扫描；非工作时间的 revoke 操作应触发人工复核。日志保留周期建议不少于 180 天，金融场景可延长至 1 年。

四、密钥轮换与撤销机制

轮换解决“长期使用同一密钥导致泄露风险累积”的问题，撤销解决“密钥已泄露需立即失效”的问题。两者机制不同：轮换是计划性的、平滑的；撤销是应急性的、破坏性的。

轮换策略分为时间驱动与用量驱动。时间驱动如 DEK 每 90 天轮换一次；用量驱动如单个 DEK 加密数据超过 2^32 条记录即轮换（GCM 模式下的安全上限）。轮换时新数据用新版本密钥加密，旧数据在读取时按需重加密（lazy re-encryption），避免全量停机迁移。

撤销则要求系统能快速定位所有使用该密钥的密文。设计上应为每个密钥维护“影响范围索引”，记录哪些表、哪些对象使用了该版本。撤销后，旧密文要么无法解密（硬撤销），要么进入只读隔离区等待重加密（软撤销）。硬撤销适用于确认泄露的场景，软撤销适用于误操作或计划退役。

上图展示了从根密钥到密文数据的封装链路，以及权限模型、审计日志与轮换撤销机制在整体架构中的位置。可以看到，密钥明文始终停留在 HSM/KMS 内部，应用侧只接触句柄或密文封装；权限模型约束“谁能在什么条件下调用哪一层”；审计日志横向覆盖所有操作；轮换与撤销则作用于密钥的生命周期状态。

五、落地检查清单

• 根密钥是否存放于 HSM/KMS，且无任何明文导出路径？
• DEK 落盘是否为密文封装，元数据是否带 HMAC 完整性校验？
• 权限是否按角色+属性授予，是否绑定服务身份而非个人账号？
• 审计日志是否覆盖 encrypt/decrypt/rotate/revoke 全操作，是否防篡改？
• 轮换周期与用量阈值是否明确，旧数据重加密是否有 lazy 策略？
• 撤销时能否快速列出受影响密文范围，硬/软撤销路径是否区分？