副标题#e#
本文作者 夏润钊
IBM大中国区云计算解决方案架构师
夏润钊先生是 IBM 大中华区云计算解决方案架构师,主要负责 IBM 云平台解决方案的设计。支持过多家国有大型****与互联网客户,在 IT 架构设计,容量评估,安全等领域,具有丰富的 POC 与客户支持经验。精通公有云安全解决方案,对公有云平台经典架构与 VPC 架构有深刻理解。
01
云端安全,重中之重
云计算应该算是当下 IT 圈一个比较火热的领域。很多知名的云厂商所提供的品类丰富的服务和美轮美奂的 UI,以及贴心的后台的支持都让人觉得用着非常的爽。不过,如果谈到安全和保护用户的隐私,IBM 云还是走在了前列。
“什么?IBM 不是被联想收购了吗?”,IT 圈外路人甲如是说。
“IBM 的服务器还是挺厉害的,怎们,你们还做云?”。IT圈内,云圈外路人乙也是一脸蒙圈。
其实,IBM 不但有云,而且目前在全球的收益已经排到了前三。
如今,在 IaaS 层,在已经囊括了 x86 和以高性能著称的 Power 服务器之外,最近又添加新成员,这就是 z 系列服务器。
正如“路人乙“同学所说,IBM 作为老牌的服务器厂商,生产的服务器分为 x,i,p,z 四大产品序列,在价格上,x 系列最便宜,z 系列最贵。而且,就国内而言,使用 z 的客户,包括了四大行在内的多家商业****,大家都把最核心的应用运行在 z 上,足见其地位之重要。z 系列主机的高度安全性,必然能够为稳健的 IBM 公有云增光添彩。
在使用公有云的时候,相信所有企业用户,都会考虑隐私数据的安全问题,一来近年来各地的法律法规层出不穷,例如大名鼎鼎的 GDPR 就对使用和收集欧盟公民的个人信息有严格规定。这些规章一旦触犯,对企业来说,轻则鼻青脸肿,信用受损,重则骨断筋折,一命呜呼。二来,如果云供应商,监守自盗,窃取隐私数据该如何是好?虽说目前有供应商的书面承诺,可以检查日志进行审计。但是毕竟有点儿事后诸葛亮的意思。
有没有有一种服务能够从技术上真正做到只有数据的所有者可以读取数据内容,其他任何人(包括云计算供应商)都无法读取呢?还真有,这就是依托 IBM Cloud Hyper Protect Crypto Service 的 KYOK 技术(Keep Your Own Key)。与之相对的,是一种叫做 BYOK(Bring Your Own Key)的技术。二者区别如下:
KYOK 是从技术上根本解决了云供应商对客户数据非法访问的问题。至于具体是如何实现的,请继续向下看。
就硬件的安全性而言,z 主机上的加密设备: Crypto Express 6S,达到了 FIPS140-2,Level 4 的等级,为业界最高,没有之一。既然有 FIPS140-2 level 4, 自然也会有level 1,2,3,感兴趣的小伙伴可以自己找一找,不同厂商的 HSM 设备的安全级别。对于 level 2 的设备,要求是对入侵的行为有事后的证据,乃至于给设备贴上封条或易碎贴的做法也算是 level 2 的范畴。
Level 3,要求要高一些,需要能够检测到实时的入侵行为,算是事中的反馈。而 level4 的设备,除了具备 level 2,3的能力之外,还可以在检测到入侵行为的时候 (包括非法访问或物理环境聚变)会自动清零设备上的秘钥,防止秘钥落入不法分子手中。
02
感受 Hyper Protect Crypto Service
现在就让我们来感受一下 HPCS。如下图所示,IBM 公有云上的 Hyper Protect Crypto Service主要包括以下几类:
Hyper Protect Crypto Service(HPCS)
使用加密卡,向外提供数据加密的功能。例如,我们可以创建 HPCS 实例,然后调用 HPCS 对 VM 的卷进行加密。
Hyper Protect Virtual Server
简单的说是 IBM Cloud 提供的一种全新虚机。它运行在 z/LinuxONE 之上。依托 IBM z 强大的计算能力,性能表现优异,而且底层会调用 HPCS,数据天然会被加密。
Hyper Protect DBaaS
依托上述 Hyper Protect Virtual Server,提供 DBaaS 服务,与普通的 DBaaS 相比,所有数据都经过了加密,更安全。
#p#副标题#e#
下面这张图清楚的反映了上述服务之间的相互依托关系。
下面,让我们在 IBM Cloud 上面做个实验。使用 HPCS,对 VPC instance 的 boot 卷进行加密。简单的说,实验分为以下三个步骤:
1. 创建 HPCS 实例,并对它进行初始化
2. 将 HPCS 的服务开放给 VPC
3. 创建 VPC 实例,并调用 HPCS 对 boot 卷进行加密
#p#副标题#e#
创建 HPCS 实例的过程非常简单,本文不做叙述。有一点需要注意,在选择 Number of crypto units 的时候,有三个选项:1(single zone)2(multi-zone)3(multi zone),意思是,在创建 crypto units 的时候,实际创建的加密功能模块的数量。从高可用与性能角度考虑,在生产系统中推荐 2或 3。
HPCS 创建完成后长这样,由于 instance 只是创建,还没有初始化,所以没有 master key。图片上显示的 Erro. 可以暂时忽略。
HPCS 的初始化过程有点儿复杂。无数的身份和密码会把人搞的头大,所以,在真正开始之前,有必要把初始化阶段所做的事情梳理一下。跟电影里看到的场景类似,发射核弹需要两个人同时转动钥匙,要使用 HPCS,IBM 推荐多个人持有不同的密码或密钥分量。
涉及的角色如下:
签名秘钥管理员(signature key admin)
负责开启初始化过程。这个角色控制着初始化过程的入口,没有他的授权,下面的操作都无从谈起。另外,也可以通过这个角色知道是谁授权的操作。
主密钥分量1持有者(master key part1 owner)
持有秘钥分量1。(核弹发射钥匙持有者1)
主密钥分量2持有者(master key part2 owner)
持有秘钥分量2。(核弹发射钥匙持有者2)
我们还可以有更多的秘钥分量,这些不同的分量通过运算会生成真正的主密钥。三个不同角色直接的关系如下图所示。
#p#副标题#e##p#分页标题#e#
管理员控制秘钥分量持有者对 HPCS 的访问
涉及的密钥类型有:
主密钥分量1(master key part1)
核弹发射钥匙1
主密钥分量2(master key part2)
核弹发射钥匙2
主密钥(master key)
主密钥分量1与2经过运算生成主密钥
DEK(Data Encryption Key)
对隐私数据进行加密的秘钥
根密钥(root key)
由主密钥生成,是用来加密DEK的秘钥
简单解释一下,为什么会有这么多的的秘钥,对照下图对其中的关系做一个梳理。加密的对象是隐私数据。加密隐私数据的密钥叫做 DEK(Data Encryption Key),但是 DEK 不应该明文存放,否则如果从硬盘获取了 DEK,和密文,那么数据就会泄密。所以要对 DEK 再次加密,这就要用到 root key;root key 是对 DEK 加密的密钥,经过加密的 DEK 存放在磁盘上就没有问题了,经过加密的 DEK 称之为 wrapped key。Root key 是由 mater key 产生的(2.),而 master key 在初始化过程中由 master key part 运算产生(1.),并且仅仅存在于的 crypto unit 之上。
#p#副标题#e#
读取加密数据的过程是这样的:操作系统会把密文和经过加密的 DEK,发送给 HPCS(4&5)。因为 HPCS 中存储了 root key,因此它会使用 root key 对加了密的 DEK 进行解密(3),有了明文的 DEK,就可以解密密文,然后送回给系统了(6)。
注意,Root Key 和 Master Key 从来就没有离开过 Hyper Protect Crypto unit,因此从操作系统的角度来看,管理员永远不知道 DEK 是什么,IBM 管理员也无从知道。
了解更多IBM Cloud海外公有云信息请访问:
http://www.zhiding.cn/special/globalization