解读

在国内金融、政企云等多租户场景下，企业常把**Cloud SQL 实例级加密密钥（CMEK）与组织统一要求的租户级备份加密密钥（Backup CMEK）**混用，导致“一份备份到底听谁的”这一冲突。面试官想确认两点：

1. 你是否理解 Google Cloud 密钥层级的资源继承顺序；
2. 当继承链出现“双父密钥”时，平台如何无损降级并给出可审计的决策日志，以满足国内等保、关保对密钥可追溯的要求。

知识点

1. 密钥层级：Organization/Folder → Project → Instance → Backup，每一层都可独立设置 CMEK。
2. 冲突触发条件：实例级密钥与租户级备份密钥不是同一 Key Ring或密钥策略版本不一致（如实例用软件密钥，租户要求 HSM）。
3. 解决策略：
   • 显式优先原则：Backup 创建时若指定 kmsKeyName，则以该字段为准，忽略实例级密钥；
   • 兜底继承原则：若 Backup 请求体未带 kmsKeyName，则向上追溯至 Project/Folder/Org 的 backupEncryptionKey 属性，仍找不到才回落到 Google 默认 GMEK；
   • 失败熔断：当租户级密钥权限不足（Missing cloudkms.cryptoKeyEncrypterDecrypter）或密钥已禁用，Backup 任务立即失败，事件写入Cloud Audit Logs，并同步到Security Command Center；
   • 在线重加密：对已存在的“冲突备份”，支持跨密钥重加密（Re-encrypt），流程为：先以原密钥解密 → 临时内存流 → 用新租户密钥重新加密 → 原子替换指针 → 旧密钥材料 24 h 后自动擦除，零停机、零额外存储计费；
   • 合规水印：重加密后在备份元数据里写入reencryptionReason=“TENANT_KEY_MISMATCH”，满足国内审计“密钥变更须留痕”的硬性要求。

答案

当租户级备份加密密钥与实例级密钥冲突时，Google Cloud SQL 按“显式指定优先 + 权限熔断 + 事后可重加密”的三级策略解决：

1. 在创建备份的 API 请求中，若明确给出 kmsKeyName（租户密钥），直接采用该密钥，实例级密钥被完全覆盖；
2. 若请求未指定，则沿 Organization→Folder→Project 顺序寻找 backupEncryptionKey，找不到才用实例密钥；
3. 一旦租户密钥因 IAM 或状态原因不可用，备份任务立即失败并审计留痕，防止“降级加密”带来的合规风险；
4. 对已存备份，运维可在无停机情况下发起跨密钥重加密，系统会生成带reencryptionReason标签的新备份，旧备份在 24 h 内自动清理，实现密钥归属变更零业务中断。
   整个流程通过 Cloud Audit Logs 与 SCC 输出可追溯链，满足国内等保 2.0 对“密钥全生命周期可审计”的要求。

拓展思考

1. 如果企业要求**“备份密钥必须与中国区 HSM 密钥轮换策略同步”，可结合Cloud KMS AUTOKEY** + Terraform 版本化模块，在密钥轮换当天批量触发reencrypt作业，实现千实例级一键换钥。
2. 在跨省容灾场景下，租户密钥与实例密钥可能分属不同地域的 Key Ring，此时需先授予Cross-region KMS accessor角色，再使用VPC-SC 感知型 Cloud SQL Auth Proxy，确保密钥调用流量不出省，满足数据异地备份但密钥本地留存的监管红线。