当 DR 灾备遇到 KMS(二)

阅读数:14 2019 年 12 月 20 日 15:26

当 DR 灾备遇到 KMS(二)

3. 场景三,客户端加密场景扩展,需要固定 DEK 支持密文对比

某些场景下,加密数据不会解密使用,而是用密文做对比,比如用户的密码,数据库存放的就是密文。用户在客户端输入的密码,在加密之后传输,通过密文与密文的对比来判断密码是否一致。这样的情况下,都不会涉及解密过程,但是要求不管任何时间对同样的明文,加密的密文保持不变。这样就要求 DEK 必须固定不变。在场景二介绍的 Encryption SDK 中,为了提高安全等级,DEK 是调用的时候临时生成的,每次调用,生成的 DEK 是不一样的。因此场景二的解决方案不能直接用于场景三。调整如下

为了保证 DEK 不变,需要将 DEK 从封装的方法中剥离出来,Client 端自己管理 DEK。具体如下

DEK 的生成和管理

首先,调用 Encryption SDK 中的generateDataKey 方法,生成一个 DEK ****

Java

复制代码
// generate data key, with CMK, with AES_128
GenerateDataKeyRequest dataKeyRequest = new GenerateDataKeyRequest();
//dataKeyRequest.setKeyId(KEYID);
dataKeyRequest.setKeyId(this.CMKKeyID);
dataKeyRequest.setKeySpec("AES_128");
GenerateDataKeyResult dataKeyResult = kms.generateDataKey(dataKeyRequest);
``` ****
其次,对该 DEK 进行加密保护,在加密的时候,为了保证该 DEK 能够在 DR 场景下使用,也需要使用场景二中介绍的包含多个区域的 CMK 的 Provider,对 DEK 进行加密保护,这样,我们就可以在不同的区域都可以将加密的 DEK 进行解密了。 ****
Java

// plain text data key
ByteBuffer plainTextKey = dataKeyResult.getPlaintext();
// 使用 multiple provider 加密管理 datakey,以便跨区域使用
CryptoResult<byte[], ?> result = new AwsCrypto().encryptData(this.provider, plainTextKey.array());

复制代码
经过加密的 DEK,就可以保存在数据库中备用了。当然,还可以放一份在 S3 上作为冷备保存,借助 S3 高达 119 的持久性,更为放心。因为 DEK 已经加密了,所以也不担心安全的风险。
#### 数据加解密环节
从数据库中取出加密的 DEK,调用场景二中的解密方法 **decryptData()**,得到明文的 DEK,这时候就可以使用该 DEK 对数据进行加解密了。由于 encryption SDK 中包含的方法都有自己的 DEK,因此建议使用成熟的库支持 AES 加密的 SDK,对数据做加密和解密。比如 java 中的 Cipher 库 **javax.crypto.Cipher;**
### 4. 总结
无论是使用客户端加密还是服务器端加密的方式,AWS 都提供了对应的 DR(多区域)的方案。但是从具体的操作方式来看,服务器端的加密,更加简单方便,无需修改代码;而客户端的方式,是需要在代码层面进行调整的。因此我们建议优先使用服务器端加密的方式,在服务器端加密不能满足的场景下,再考虑客户端加密的方式。
** 作者介绍:**
<footer>
!
亚马逊 AWS 解决方案架构师,负责基于 AWS 的云计算方案架构的咨询和设计,同时致力于 AWS 云服务在国内的应用和推广。现致力于网络安全和大数据分析相关领域的研究。在加入 AWS 之前,在爱立信东北亚区担任产品经理,负责产品规划和方案架构设计和实施,在用户体验管理以及大数据变现等服务方面有丰富经验。
</footer>
** 本文转载自 AWS 技术博客。**
** 原文链接:https://amazonaws-china.com/cn/blogs/china/when-the-dr-disaster-prepared-encounter-kms/**

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布