【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

当 DR 灾备遇到 KMS(二)

  • 2019-12-20
  • 本文字数:1420 字

    阅读完需:约 5 分钟

当 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> ![](https://s3.cn-north-1.amazonaws.com.cn/awschinablog/Author/shengbo.jpg)
### [](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/**
复制代码


2019-12-20 15:26498

评论

发布
暂无评论
发现更多内容

[ Kitex 源码解读 ] 服务注册

baiyutang

Go 微服务架构 kitex CloudWeGo

TiDB 在长银五八消费金融核心系统适配经验分享

TiDB 社区干货传送门

安装 & 部署 OLAP 场景实践

涅槃重生!字节大牛力荐大型分布式手册,凤凰架构让你浴火成神

冉然学Java

Java 华为 开源 网络协议 #Github

深圳云堡垒机厂商哪家好?很贵吗?咨询电话多少?

行云管家

云计算 网络安全 堡垒机 云堡垒机

如何用低成本方案解决室内超大场景下机器人定位与导航难题?

优必选科技

机器人 定位 导航

多商户系统的直播功能用过吗?用过的朋友扣个 666!

CRMEB

实时计算基本概念解析

五分钟学大数据

实时计算 7月月更

转转监控系统的内部原理及实践 审核中

转转技术团队

监控 Prometheus

一文理解分布式开发中的服务治理

博文视点Broadview

资源池以及资源池化是什么意思?

行云管家

资源池 IT运维 资源池化

Spring Cloud 与 K8s 的微服务设计

Damon

7月月更

一文读懂Elephant Swap的LaaS方案的优势之处

西柚子

黄东旭:TiDB的优势是什么?

TiDB 社区干货传送门

人物访谈

TiCDC 架构和数据同步链路解析

TiDB 社区干货传送门

数据库架构设计 6.x 实践

研发需求拆分的全流程详解 | 敏捷实践

LigaAI

开发者 研发管理 需求管理 需求分析 LigaAI

SeekTiger的Okaleido有大动作,生态通证STI会借此爆发?

鳄鱼视界

Ticmp - 更快的让应用从 MySQL 迁移到 TiDB

TiDB 社区干货传送门

性能测评

数字电路基础篇

贾献华

7月月更

参与开源社区还有证书拿?

胡说云原生

开源 证书

性能大规模专项评测双通过,数牍Tusita步入隐私大数据计算时代

Jessica@数牍

隐私计算性能 数牍科技 可信隐私计算评测

单点登录的三种方式

Authing

云原生 SaaS SSO 单点登录 Authing

专注B2B跨境支付的背后,XTransfer的风控基础设施是如何炼成的?

XTransfer技术

NFT是什么?如何开发NFT系统?

开源直播系统源码

数字藏品软件开发 数字藏品系统软件开发 数字藏品交易平台开发

TiDB之rawkv升级之路v5.0.4-->v6.1.0

TiDB 社区干货传送门

迁移 版本升级 集群管理

转转微服务框架的连接管理

转转技术团队

微服务 RPC 服务治理

TiKV主要内存结构和OOM排查总结

TiDB 社区干货传送门

故障排查/诊断

TiDB 在多点数字化零售场景下的应用

TiDB 社区干货传送门

实践案例 社区活动 TUG 话题探讨

MRS +Apache Zeppelin,让数据分析更便捷

华为云开发者联盟

大数据 开源 后端

万物根生,共创新时代:华为亮相第五届数字中国建设峰会

Geek_2d6073

APP常用跨端技术栈深入分析

京东科技开发者

flutter H5 Weex ReactNative

万物皆可柯里化的 Ramda.js

掘金安东尼

前端 函数式编程 7月月更

当 DR 灾备遇到 KMS(二)_语言 & 开发_亚马逊云科技 (Amazon Web Services)_InfoQ精选文章