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> 
### [](https://amazonaws-china.com/cn/blogs/china/tag/%E9%99%88%E6%98%87%E6%B3%A2/)
亚马逊AWS解决方案架构师，负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内的应用和推广。现致力于网络安全和大数据分析相关领域的研究。在加入AWS之前，在爱立信东北亚区担任产品经理，负责产品规划和方案架构设计和实施，在用户体验管理以及大数据变现等服务方面有丰富经验。</footer>
**本文转载自AWS技术博客。**
**原文链接：https://amazonaws-china.com/cn/blogs/china/when-the-dr-disaster-prepared-encounter-kms/**
复制代码
评论