我们目前正在研究 gcp 云 kms 以及如何应对灾难恢复。这是我们当前的测试设置:
Java 使用 Spring boot + Google Tink 使用 KMSEnvelopeAead + AesGcmJce(即由 tink 生成的 DEK,将通过 kms (KEK) 加密并与密文一起存储),对称
项目“A”(灾难恢复前的初始项目)
-> KMS -> 密钥环“keyringABC” -> 密钥“keyABC” -> 通过导入作业导入的自定义密钥。我可以成功地加密/解密一些文本 - 一切都好,一切都好
resource: projects/A/locations/eur3/keyRings/keyringABC/cryptoKeys/keyABC/cryptoKeyVersions/1
项目“B”(灾难恢复项目)或具有新密钥 + 密钥环的相同项目“A”(名称可能不同)
-> KMS -> 密钥环“keyringABC” -> 密钥“keyABC” -> 通过导入作业导入自定义密钥
我重新导入了之前已导入项目“A”的自定义密钥材料,用于加密项目“A”中的数据。新创建的密钥模仿了与项目“A”中相同的结构。唯一的区别是,它位于项目“B”中
resource: projects/B/locations/eur3/keyRings/keyringABC/cryptoKeys/keyABC/cryptoKeyVersions/1
现在,当我尝试使用在项目“A”中加密的项目“B”中新创建的密钥解密数据时,我不起作用。查看云日志记录我可以看到以下错误消息
Decryption failed: verify that 'name' refers to the correct CryptoKey.
我的假设是(在阅读文档时)密文,在这种情况下,由 tink 通过云 kms 生成的 DEK,还包含指向项目“A”的密钥的确切资源标识符,因此加密的 DEK 不能被解密在项目“B”中使用新创建的密钥时不再使用。这意味着即使底层(导入的)自定义密钥材料相同,也无法恢复另一个项目中的数据。
任何人都可以对此有所了解吗?任何帮助表示赞赏。
干杯马塞尔
PS:来自 google kms 文档
当使用对称 Cloud KMS 或 Cloud HSM 密钥加密数据时,有关加密密钥版本的额外元数据将与加密数据一起保存、加密。在 Cloud KMS 之外加密的数据中不存在此元数据。
和
对称密钥总是有一个主版本。此版本默认用于加密。当 Cloud KMS 使用对称密钥执行解密时,它会自动识别执行解密所需的密钥版本。