GCP Cloud KMS 自定义密钥跨项目灾备可行性及解密问题咨询

• Cloud KMS服务端加密机制限制：根据官方说明，所有通过Cloud KMS服务进行对称加密的结果（即你场景中被KEK加密后的DEK密文），都会内嵌加密时使用的CryptoKey完整资源路径元数据。默认解密逻辑下，KMS服务会强制校验请求传入的密钥路径与密文内嵌的路径完全一致，只要项目ID、位置、密钥环名称、密钥名称、版本号任意一项不匹配，就会返回Decryption failed: verify that 'name' refers to the correct CryptoKey报错，与底层密钥材料是否一致无关。
• Tink框架封装逻辑限制：KMSEnvelopeAead默认生成的信封加密密文结构中，会额外存储加密DEK时使用的KMS密钥完整资源标识符，解密时会优先读取该标识符发起KMS请求，不会主动替换为灾备环境配置的新密钥路径。

按落地成本从低到高排序：

• 方案1：跨项目密钥IAM授权（无代码改造方案）
  无需在项目B重复创建密钥，直接在项目A的keyABC密钥的IAM策略中，为项目B的业务服务账号授予roles/cloudkms.cryptoKeyDecrypter权限。灾备场景下项目B的业务可以直接调用项目A的密钥资源路径完成解密，不需要调整现有加密逻辑，适合RTO要求较低的场景，需提前验证跨项目访问的网络连通性与合规要求。
• 方案2：自定义Tink解密逻辑适配（适配自定义密钥材料场景）
  针对你当前导入自定义密钥材料的场景，仅需对解密逻辑做少量改造即可：
  1. 自定义实现Tink的Aead接口，解密时不再读取密文中内嵌的旧KEK资源路径，强制使用当前环境配置的灾备KEK路径发起KMS解密请求
  2. 调用KMS解密接口时，添加参数allowMissingCryptoKeyVersion=true（Java客户端SDK可通过DecryptRequest类设置），开启该参数后KMS会跳过密文内嵌的路径校验，仅使用当前请求传入的密钥材料执行解密，只要项目B的密钥材料与项目A完全一致即可解密成功，再用解密得到的DEK解业务密文即可。
• 方案3：预构建密钥别名抽象层
  长期方案可以在配置中心维护KEK资源路径的映射配置，加密、解密时都从配置中心读取当前生效的KEK路径，不硬编码任何固定密钥资源ID。灾备时仅需修改配置中心的路径映射即可一键切换灾备密钥，配合方案2的解密逻辑改造即可实现完全无感知的灾备切换。

内容的提问来源于stack exchange，提问作者niesfisch