📚 课程目录第3章密钥治理核心模型

3. 密钥治理核心模型

在多云环境中，KMS 的治理难点并不在于“能不能创建密钥”，而在于密钥从产生到销毁的每一个阶段，是否都有明确的责任人、可审计的操作记录和可验证的权限边界。本节把密钥治理拆成四个相互咬合的核心模型：密钥生命周期回答“密钥在什么阶段、由谁、以什么状态存在”；职责分离回答“谁有权做决定、谁只能执行、谁负责审计”；最小权限回答“每个主体到底能碰哪些密钥、能做哪些动作”；合规要求则把这些约束固化为可检查的证据链。四者不是并列的口号，而是同一套控制体系的不同切面。

一、密钥生命周期：状态机而非线性流程

密钥生命周期常被画成“生成→使用→轮换→销毁”的直线，但在真实 KMS 中它更接近一个带分支的状态机。以主流云 KMS 的通用模型为例，密钥通常经历以下状态：待启用（Pending/Pre-active）、已启用（Enabled/Active）、已禁用（Disabled）、待删除（Pending Deletion）、已销毁（Destroyed/Scheduled Deletion 完成）。部分平台还区分“仅用于导入密钥材料的导入态”和“仅用于加密但不导出”的非对称密钥态。

关键点在于：禁用是可逆的，销毁是不可逆的。禁用通常用于临时止损，例如发现某应用异常调用后先冻结密钥；而销毁一旦执行，所有用该密钥加密的密文将永久无法解密。因此，主流 KMS 都设置了“待删除”窗口，常见为 7～30 天，期间可撤销删除。这个窗口本身就是治理设计的一部分：它把“误删”从灾难性事件降级为可恢复事件。

轮换是生命周期中最容易被误解的环节。轮换并不等于重新加密历史数据。以对称密钥为例，KMS 通常保留旧版本密钥材料用于解密，新版本用于加密，密钥 ID 不变，版本号递增。应用侧无需改动密钥引用，但必须确保解密时使用密文携带的版本信息。若应用把密钥版本硬编码，轮换就会失败。因此，轮换前必须确认：应用是否通过密钥 ID 引用、是否依赖密文中的版本元数据、是否有跨区域副本需要同步轮换。

二、职责分离：把“决定权”和“执行权”拆开

职责分离（Separation of Duties, SoD）的核心不是增加审批环节，而是确保没有任何单一主体能同时完成“申请—批准—执行—审计”中的两个以上关键动作。在多云 KMS 中，典型角色可划分为四类：

密钥管理员（Key Admin）：负责创建密钥、设置轮换策略、定义密钥用途，但不直接调用密钥加解密业务数据。
密钥使用者（Key User）：通过应用或服务身份调用 Encrypt/Decrypt，只能使用被授权的密钥，不能修改密钥属性。
安全审批人（Security Approver）：审批密钥销毁、跨区域复制、策略放宽等高危操作，不参与日常运维。
审计员（Auditor）：只读访问 CloudTrail、KMS 审计日志和配置快照，不拥有任何密钥操作权限。

一个常见的反模式是：运维团队同时拥有 kms:CreateKey、kms:ScheduleKeyDeletion 和 kms:Decrypt 权限。这意味着同一个人可以创建密钥、解密数据、再销毁密钥，事后审计只能看到“某人做了这些事”，却无法形成有效的相互制约。正确的做法是把 ScheduleKeyDeletion 单独授予安全审批角色，并在策略中要求 kms:ScheduleKeyDeletion 必须携带审批工单号作为条件键。

三、最小权限：从“能调用”到“只能这样调用”

最小权限在 KMS 场景下有三个层次。第一层是密钥级：只授予特定密钥 ARN 的权限，而不是 *。第二层是动作级：只授予 Decrypt 而不授予 Encrypt，或只授予 DescribeKey 而不授予 GetKeyPolicy。第三层是条件级：通过 kms:EncryptionContext、kms:ViaService、aws:SourceVpce 等条件键，把调用限制在特定业务上下文、特定云服务或特定 VPC 端点内。

以下是一个最小权限策略示例，允许应用角色仅通过 S3 服务、在指定加密上下文下解密指定密钥：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDecryptForS3Only",
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "arn:aws:kms:cn-north-1:123456789012:key/abcd-1234",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "s3.cn-north-1.amazonaws.com.cn",
          "kms:EncryptionContext:tenant": "finance"
        }
      }
    }
  ]
}

这段策略的关键在于：即使该角色凭证泄露，攻击者也无法直接调用 KMS 解密任意密文，因为调用必须经由 S3 服务发起，且加密上下文必须匹配 tenant=finance。这就是把“最小权限”从资源粒度推进到调用上下文粒度的实际价值。

四、合规要求：把控制点变成可检查的证据

合规不是额外负担，而是对上述三个模型的验证机制。以等保 2.0 和 PCI DSS 为例，密钥管理相关要求通常落在几个可检查项上：密钥是否定期轮换、销毁是否有审批记录、访问是否最小化、操作是否留痕且不可篡改。多云环境下，这些证据分散在不同云厂商的审计服务中，因此需要统一采集。

一个可落地的做法是：为每个密钥打上统一标签，至少包含 owner、data-classification、rotation-days、compliance-scope 四个键。然后通过定时任务拉取各云 KMS 的 DescribeKey 和 ListKeys 结果，与标签基线比对。例如，若某密钥标记 data-classification=confidential 但 rotation-days 为空或大于 365，则判定为不合规。审计日志则统一投递到独立的日志账户或日志项目，确保密钥管理员无法删除自己的操作记录。

常见误区：把“启用了 KMS 加密”等同于“满足合规”。实际上，合规检查关注的是密钥的治理过程：谁创建的、轮换策略是否生效、销毁是否经过审批、权限是否收敛。仅开启加密而不管理密钥生命周期，在审计中通常会被判定为控制缺失。

五、四个模型的咬合关系

把四个模型放在一起看：生命周期定义了“有哪些状态和转换”，职责分离定义了“谁有权触发转换”，最小权限定义了“触发时能带什么条件”，合规要求则定义了“转换后要留下什么证据”。任何一环缺失，治理都会出现缺口。例如，有生命周期但无职责分离，密钥可能被单人销毁；有最小权限但无合规留痕，权限收敛无法被证明；有合规要求但无生命周期状态机，轮换和销毁就无从执行。

在实际落地时，建议先用一张密钥清单把现有密钥按 owner 和 data-classification 归类，再逐类定义生命周期策略和角色映射，最后把策略写入各云 KMS 的密钥策略和 IAM 策略中，并通过审计日志验证实际调用是否符合预期。这个过程不需要一次性覆盖所有密钥，但必须保证每一类密钥都有明确的负责人、轮换周期和销毁审批路径。