解读

在国内金融、政企客户上云时，合规审计常追问“密钥轮换后历史数据还能不能读”。
Google Cloud SQL 的备份文件默认使用 Google-managed encryption key（GMEK） 或 Customer-managed encryption key（CMEK） 进行 两层加密：

1. 数据盘层：由 Google 基础设施用 DEK（Data Encryption Key）做块级 AES-256 加密；
2. 备份对象层：备份被切成对象存入 Cloud Storage，再次用同一区域的 KMS 密钥做信封加密。
   轮换动作只影响 KMS 密钥版本，而 DEK 本身被老版本的 KEK 加密后随备份一起存放。因此只要 KMS 老版本密钥 未被手动销毁（scheduled for destruction），旧备份就能解密。
   面试官真正想听的是：你能否区分“轮换”与“销毁”，并给出可落地的风险预案。

知识点

• KMS 密钥版本机制：轮换产生新版本，旧版本默认 仍启用 24 h～30 天（可配置），之后进入 DISABLED 状态，但对象数据不解密就不会失效。
• Cloud SQL 备份生命周期：自动备份保留期最长 365 天；手动备份可存 跨区域 且 不受实例删除影响。
• 解密链：备份对象 → KMS 老版本解密 DEK 密文 → 得到明文 DEK → 解密数据块。
• 合规要点：等保 2.0 与银保监云监管要求 密钥轮换周期 ≤ 1 年，并保留 可审计的解密能力；因此 禁止立即销毁旧版本。
• 风险场景：若项目误操作执行 gcloud kms keys versions destroy，老版本密钥物理擦除，所有依赖该版本的备份、binlog 将永久无法恢复，此时只能通过 异地长期备份（导出 SQL dump 到 GCS 并自行二次加密） 兜底。

答案

可以解密，前提是 旧版本 KMS 密钥未被销毁。
轮换操作仅生成新的主密钥版本，旧版本继续保留在 DISABLED 状态，Cloud SQL 备份里存放的 DEK 仍能用旧版本解密，因此 恢复实例或执行点时间恢复（PITR）均不受影响。
如果企业合规要求立即失效旧密钥，必须 先执行导出逻辑备份（mysqldump/pg_dump）并用新密钥二次加密，再 等待 24 小时销毁窗口期，否则将面临 历史备份永久不可读 的风险。

拓展思考

1. 如何设计 “密钥轮换 + 备份不可变” 的合规方案？
   建议 启用 Bucket Lock 的 GCS 存储桶 存放手动导出，配合 CMEK 轮换事件触发 Cloud Functions 自动重导出，实现 老密钥备份归档、新密钥备份上线 的双轨制。
2. 如果客户要求 国内多活架构，可结合 Cloud SQL 跨地域只读实例 + 上海/北京双 KMS 密钥环，通过 密钥别名漂移 实现 区域级密钥轮换零中断。
3. 面试加分项：提到 Terraform 模板中设置 deletion_protection = true 与 kms_key_version_destruction_delay = 30，把 “不可销毁” 写进 IaC，体现 DevSecOps 思维。