当 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 高达 11 个 9 的持久性，更为放心。因为 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/**