云计算的安全性的难题,有解还是无解?

云计算
安全性的难题,有解还是无解?

对于Google来说,如果希望AppEngine能够获得商业上的巨大成功,吸引更多用户,尤其是企业用户,最大的挑战在于,如何保障客户的数据和私有程序的安全。

举个例子,譬如Google想劝说某家银行,用不着银行自己建数据中心,把银行的数据存到Google的云计算平台,每月给Google一笔数据托管费即可。银行很可能会问两个问题,

1.  如何防范Google员工偷窥银行的数据?

2.  银行有投资业务,所以银行自己开发了一套软件,用于评估投资风险和收益。如何防范Google员工偷窥这些软件的代码?

Google当然会派律师去游说,指天画地地发毒誓,说如果出现Google偷窥数据及代码的情况,根据双方合同,Google必将受到法律严惩,等等。

但是银行还是不放心,作案取证本来就麻烦,如果Google再做点手脚遮掩,很可能查无实据。即便能找到实据,一个案子办下来,时间也得拖很长。

这个问题,困扰的不是Google一家,而是所有负责数据托管的公司面临的共同问题。所以,现在只有两类公司,敢把数据托管给他人。一种是中小企业,他们或许会觉得自己在竞争对手眼里不那么重要,对手不至于甘冒风险去刺探自己的机密。另一种是数据本身机密性不高的公司,譬如新浪网,天涯社区等等,他们的数据内容本来就是公开的。

所以,如果Google打算吸引重量级企业用户来使用云计算平台,最好的办法是从技术上想出路,保证做到,即便Google挖空心思想偷窥,也看不到。

1.  有人问,为何不用VPN技术呢?

VPN(Virtual Private Network)虚拟私网,解决的是在如何通过公共网络,远程访问企业内部私网的问题,譬如在家处理公司业务,需要把自家的电脑,通过公共网络,接入到公司内部网络中去。所以,VPN解决的问题主要在于,保证家里电脑和公司电脑传输数据时,数据通过公网时的安全。

经常在北京街头看到振远护卫的押运车,以及持枪的押运员,负责运输现钞,有人戏称他们是振远镖局。镖局的任务之一是,把现钞从银行押运到各个ATM 自动取钱机,中途通过公共马路。现钞安全到达目的地,镖局的任务圆满完成。但是,如果有谁把ATM取钱机撬开了,镖局不负责任。

类似的道理,客户可以通过VPN把数据安全地传输到Google云计算平台,但是VPN不能阻止Google的内部员工偷窥存放在Google机器上的数据。

[[10916]]

2.  还有人建议,可以给数据加密。

客户在上传数据到Google云计算平台前,先用私钥(private key)给数据加密,这样存储在Google云计算平台的数据,是加了密的数据。Google员工即便打开了文件,看到的也不过是一堆乱码。当客户授权给他的同事看数据时,给同事一份公钥(public key)。同事用这个公钥解码,然后就能读到真实的内容了。

德国人的钥匙很有意思,办公室的钥匙,同时可以打开大楼的门,以及公司的门,但是不能打开隔壁办公室的门。隔壁办公室的钥匙,也可以打开大楼的门,以及公司的门。所以,德国人的钥匙和锁,是有层次的。

公钥也可以这么设计,一个部门的公钥,不仅可以解密本部门的文件,而且可以解密公司内部公开的文件,但是不能解密其它部门的文件。实现这样有层次的公钥并不难,一个简单的办法是把整个公钥分成几段,第一段负责公司内部公开的文件,第二段负责某特定部门的文件等等。

这个办法猛一听起来似乎可行,但是仔细想想却不然。它有四个缺陷,a.  不能给程序加密,b.  不能搜索加了密的数据,c.  不能给数据库文件加密,d.  公司员工离职后,有可能会造成私钥和公钥的外泄。

3. 程序如何加密。

按照前一段的思路,平时给程序加密,只有当运行程序前,才解密。程序运行结束后,再度加密,同时销毁解密了的程序。但是这个办法不可行。

解密和加密,是相当耗用CPU的,同时占用时间也比较长。如果实施平时加密,用时解密的措施,用户等待时间会相当长。更严重的是,通常一段程序不能解决所有问题,一段程序往往会调用其它程序,其它程序又调用另外程序。如果平时把所有程序加密,用时再逐个解密,整个流程将占用很长时间,这将严重影响用户的体验。

现实中通行的办法是给程序变形,学名叫Obfuscation。道理很简单,把程序中的变量名称转换掉,同时切割整个程序,并且重新排序,以便混淆耳目。变了型的程序依然可以运行。

正常的编译过程,是把人类可读的源代码(譬如用Java写的程序),翻译成机器代码(譬如Java bytecode)。而反编译是把机器代码,逆向翻译成人类可读的源代码。虽然Obfuscation不能从根本上阻止反编译,但是却增加了这个工作的难度。

虽然有难度,但是重赏之下必有勇夫。譬如,如果能盗窃银行密码,肯定会有人不辞劳苦地反编译。

4. 加密与搜索。

“Greatness is never a given, it must be earned”,这句话怎么翻译?在Google或者百度里搜一搜这句话,一定会发现这是奥巴马总统就职演说中的一句。有人翻译成,“伟大不是凭空而来的,而是赢得的”。意思当然不错,但是觉得不如原句有气势,不如翻译成,“坐等等不来伟大,伟大必定来自于努力”。

Google和百度是如何搜索到这话出自奥巴马的演讲呢?道理说穿了并不复杂。

首先,Google和百度建一个索引,学名叫倒排索引(inverted index)。倒排索引中记录了每个单词出现在哪些文章中,而且记录了在这些文章中的什么位置出现过。

其次,当用户搜索“Greatness is never a given”,搜索引擎通过倒排索引,查找“greatness”在哪些文章中出现过,查找“never”在哪些文章中出现过,等等。然后把众多的搜索结果合并起来,看看哪些文章中不仅出现过“greatness”,还出现过“never”,“given”等等。

如果把奥巴马原文加了密,不仅每个词都变成了乱码,而且词与词之间的空格消失了,甚至连词序也可能被打乱。这样一来,就没有办法按照通常的做法构建倒排索引。

怎么办?思路有三条。

a.  把加密算法和构建倒排索引的算法通盘考虑,重新设计一套一体化的算法。

这个思路能够一揽子解决我们面临的所有问题,但是设计这套算法的难度很高。目前还没有人能够想出有效的算法。

b.  客户自己动手建倒排索引,然后把索引加密,上传到云计算平台。

但是构建倒排索引是一件计算量很大的工作,如果客户能够自己构建倒排索引,那么就没有必要使用云计算平台。理由是,云计算平台的卖点是方便客户处理繁重的数据计算。如果云计算平台不能帮助客户构建他们专用的倒排索引,那么云计算的卖点就大大失色。

更严重的问题是,在使用索引的时候,必须先解密。如果解密了的索引被Google员工偷看了,那么加密就失去意义了。原因是,索引中透露了正文中出现过那些词,以及这些词出现的位置。通过索引中的这些信息,可以复制原文的。即便不能一字不漏的全文复制,也能复制得八九不离十。

所以,这个思路不可行。

c. 在云计算平台中分离出一部份作为密室,专供企业用户存放保密级别很高的数据,以及运行保密级别很高的程序。

信息安全的法则是分离分离再分离。给每个企业用户分配一部份机器作为密室。这些机器的Root权限掌握在企业用户手里。Google的员工只能监控密室中的机器的CPU,RAM和IO的使用情况,但是他们没有权限进入机器,查看文件,运行程序。

这个办法虽然技术含量不高,但是比较容易实现。缺点是容易造成资源浪费。因为如果给每个客户单独开密室,即使密室里的机器空闲,别人也没法用。

5. 加密与数据库。

数据库最多只能对字段逐个加密,譬如“greatness”变成“@#¥%”。但是不能整句整段地加密,否则数据库的索引,B+ tree,就没法构建。

所以,对数据库的系统管理员,无法实施高级别的加密。

6. 私钥和公钥的外泄。

公司员工离职后,很可能复制一份公司的公钥和在职期间自己使用的私钥带走。如果沿用前面所述,用私钥加密,用公钥解密的办法,员工离开公司后,仍然能阅读公司的文件,甚至篡改当年自己在职期间起草的文件。

所以,最妥善的办法是不让员工直接接触公司密钥。从这个原则出发,作者也好,读者也好,都没有密钥。作者要加密,读者要解密,让他们把文件发给密钥中心,由密钥中心统一负责加密和解密。

另外,即便由密钥中心负责保管密钥,如果长期使用同一套密钥,还是不安全。所以,密钥中心定期更换密钥,分批给文件重新加密。

这个办法可行,但是比较笨拙,因为,a.  密钥中心成为瓶颈,b.  给旧文件重新加密是负担很重的工作。

为Google计,目前能做的,似乎是明确云计算的定位。

1.  锁定目标客户,这些客户有一个共性,就是对内容和程序的安全性不敏感。

比如各种门户网站,论坛,B2C网上商店,政务和各种公共事业的网站,以及中小型企业等等。这部分用户数量不少,市场相当广阔。

2.  提供特色服务,尤其是海量数据处理。

云计算平台类似于巨型计算机。客户利用云计算平台,处理自己的计算中心很难完成的海量数据处理。例如:电脑动画制作,天气预报等等。

3.  根据不同的保密等级,做分级处理。

实际上一个企业的重要秘密信息是不多的,机密文件存放在企业自己的机房里。其它不需要保密的文件,托管到云计算平台。这个市场也是很大的。
 

责任编辑:王勇 来源: 博客
相关推荐

2011-03-22 13:50:57

云计算

2012-05-10 09:50:53

云计算安全

2010-05-19 10:14:29

2018-11-19 05:34:31

云计算云安全IT

2021-10-31 16:10:50

公有云安全性IT

2013-01-11 14:00:18

云存储云计算云安全

2012-08-20 10:28:01

云模型NIST云计算

2013-01-15 10:12:39

云存储云安全

2013-10-14 09:54:24

云服务安全性云安全

2012-05-09 09:36:42

PaaS云计算云安全

2020-06-01 10:55:45

云计算人工智能IT安全

2023-03-21 17:50:07

2017-07-03 10:20:37

云计算安全性合规性

2018-10-09 13:20:02

2015-06-29 16:16:58

云计算PaaS云安全

2012-10-22 10:02:34

2019-10-28 13:44:10

安全边缘计算数据

2016-07-21 10:25:54

2012-10-22 09:42:40

2012-10-17 09:40:35

DLP工具云计算安全性云安全
点赞
收藏

51CTO技术栈公众号