主题：【原创】云里雾里的云计算 [1] -- 邓侃

【6】安全性的难题，有解还是无解？

对于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机器上的数据。

振远护卫在奥运会期间负责押运运动员尿样

Courtesy http://i1.sinaimg.cn/qc/cr/2008/0828/4024560575.jpg

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. 给旧文件重新加密是负担很重的工作。

Durer's grid

Courtesy http://employees.oneonta.edu/farberas/arth/Images/ARTH_214images/Durer/durer_perspnude_large.jpg

前面花了相当长的篇幅讨论各种为托管的数据和程序加密的办法，结论是，现有技术无法保障被托管的数据和程序被偷窥。

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

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

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

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

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

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

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

• 大型企业使用云计算的实例

打算赶紧写完这篇。

然后讨论WebOS。

最近索爱搞了一个基于Flash Lite的手机平台，兄台了解吗？

公钥、私钥的加密体系是这样用的， 如果A 要发一份密文给B，那么

1、A用B的公钥对明文加密。

2、A把加密后的密文发给B。

3、B用自己的私钥解开A发来的密文。

这个体系的好处是公钥是公开的，及时第三方即使截获了B的公钥和密文，也无法解密。

公钥、私钥的加密体系不存在用私钥加密的情况。私钥只用于签名，以标明该文件是A签署的。

但这个体系设计初衷是用于点对点的通讯，如果用于多人共享，就需要管理N个公钥，会很麻烦。

1、如果与计算中存储倒排索引是加密后的，那么存在一个问题就是一个检索请求发到云之后，云需要先对加密的索引解密，然后再进行检索（我不知道有任何能在不解密的情况下，对密文进行检索的技术，如有请指正）。但是这一解密那仍然有信息暴露的问题（如DVD，BlueDVD的破解都是被直接复制了内存中的数据，导致加密方式被破解），因为Google完全可以拷贝一份解密后的明文另存出去。

2、我理解，云计算远远不是检索那么简单，Google希望是承担企业内部的更多功能但是这样一来加密就更加困难，比如数据库的操作实际上大部分的字段数据是无法用密文操作的，因为密文导致的无法检索、无法排序对大部分的ERP，SCM等应用都是灾难性的。（补充一点，密文到不是完全不能检索，但是密文只能做完全匹配，不能做部分匹配，这样导致实用性不大）。

密室这个东西，对于建立密室的人实际是毫无意义的，很简单Root权限在谁手上？就现有的计算机操作系统条件下，有Root权限实际上就能看到所有的东西。另外考虑到密文终归是要解密的那“密室”这样的东西对于有Root权限的管理者实际上是无意义的。

就算软件上能做限制，现在很多黑客用的是硬件的内存复制机，绕过任何操作系统直接在硬件上把内存数据复制一份存储到另外一台电脑上。这种情况技术Google完全可以做到。

个人观点，除非有加密体系或者监管系统方面有重大突破，否则数据的安全性问题在技术实际上无解。个人认为从第三方监管等“人”的因素入手也许是个办法。

密码学里面最后一章都是“社会工程”，说的是当年一个超牛的黑客，靠电话和接线MM聊天套磁弄到的初始密码，攻入了AT&T的电话计费系统。

关于加密的问题，着实费了一些脑筋。

过年的时候，应酬很多，剩下的时间里，有空就琢磨加密和搜索的问题。方案想了一个又一个，推翻了一个又一个。

最后积淀下来的就这么一点点。

写之前觉得满肚子的话，可是写完一看，好像也没什么惊人之语。

Hansens兄的问题问得好。这些问题，我都想过，只是限于篇幅，正文里没有展开说。

我现在要离开一会儿。稍后答复。

政府专网是物理隔离、单独光纤。

搞得我们这些做信息化的人头疼无比。

每次用U盘同步数据的不是少数。弄2道不同国家的防火墙的更是常事。

另外，加密的原则就是加密后的密文和加密前的明文是信息关联越少越好。

保密上还有一个间接推论原则，也就是如果你的正文是加密的，但是我通过你公开的几个索引能猜到你这个文章大概是什么意思。或者另外一个例子，当年英国认为他们可以通过德国硝石的进口量数据来确定德国是否进入备战状态以及炸药的产量。

当然英国的例子失败了，因为德国的科学家搞出了氨氧法制备硝酸，造炸药不受硝石的限制。

这段话的意思是，如果是真的需要保密的数据，即使只泄露部分索引信息也是不可接受的。

索引中透露了正文中出现过那些词，以及这些词出现的位置。

通过这些信息，理论上是可以反过来，通过索引，复制原文的。即便不能一字不漏的全文复制，也能复制得八九不离十。

如老邓所说目前没有有效的算法，因为加密的本质就是打乱顺序保守秘密的。而构建倒排索引之后，这篇文章里出现过的所有词及出现顺序都被google的索引程序知道了，google如果愿意就很容易还原出来。这还如何保密啊？

这个办法似乎有门，特别是对文本数据信息。不过客户建立的索引加密后，google如何在不解密的情况下与google的索引合并呢？不合并就没法检索，而合并两个打乱了语序不可读的“乱码”文件，这个算法难度可不小啊

嘻嘻，这个在客户不相信google的情况下，有些掩耳盗铃的意思啦

这样看来，似乎加密与搜索是很矛盾的两件事，想把它们结合在一起不太容易啦。

不过google似乎可以放弃对企业数据需要加密的数据的索引。能够说服用户在他们的存储和运行空间里他们的程序和数据是安全的就OK了。只是困难永远都存在：

数据加密：

加密过的海量企业数据，在运行时如何解密使得用户程序可以读，而其他程序不可读？这对于google的CPU，内存，内存管理算法，以及用户体验都是相当的考验啊

程序加密：

obfuscation后的程序反编译后很难看懂。不过，很多情况下cracker不需要看懂程序，他们只需要根据某个线索找到某个函数（比如根据生成的某个序列号找到序列号生成函数），照抄下来就成了keygen了。毕竟伪机器码还不是01码，在巨大的利益驱使下，估计还是有人愿意干这种枯燥的事情的（比如分析银行数据库解密程序）。

而且无论数据加密/解密还是程序加密/解密，都需要消耗大量的CPU时间和内存。这是google所不愿意看到的。

所以，我在想，既然加密这条路走得很困难，google是不是可以走另一条路，就是：

从头构建一个操作系统！这套OS的源码要公开。如果能够从源码体系证明程序和数据在某个独立的空间存储和运行是安全的，而google又能够证明他们确实是在用这套源码所编译的OS运行云系统，那么我想客户就不会有顾虑了。这类似于证书机制：证书加密机制从算法上被证明是可靠的，那么用证书加密过的数据就是安全的，证书的客户对此不会有任何疑问。

只是，这套OS突破了目前所有OS理论和实践，将是个全新的体系结构。google是否有能力构建出来？

就现阶段的技术条件，我觉得要解决大企业重要数据的保密问题很困难，并且商业意义不大（大企业有钱就自己建了）

相对而言，解决对保密程度要求不高的小企业需求可能更为现实和迫切。

就小企业来说

1、如果有一个较为可信的第三方提供的服务，可能即使不加密也是可以接受的。比如淘宝上的店主、阿里巴巴上的外贸小企业，他们的几乎所有信息都被淘宝、阿里巴巴掌握了，也不见他们哭着喊着要加密。

这方面和政府联合建立一个云计算服务中心也许是一个办法，政府的第三方和权威性+云计算的低成本+服务小企业的政治需求，也许是个三结合的好办法。

2、如果是对保密要求更高一些的，可以做分级储存，多层次权限管理，部分加密等技术辅助措施。实际上一个企业的重要秘密信息是不多的，这部分完全可以不放在云里面，或者仅仅是存储在云里面但云不需要对其解密。比如一个企业的客户名单多数是可以公开的，但是与客户的合同就是不可以公开的，那合同加密就可以了。对于检索和一般应用，有客户名单实际上能应付99%的需求，对于想看合同的，想看也不能给。对于客户通讯录这样介于公开和保密之间的信息，就可以用分级权限管理等方法处理。总之，根据实际业务在公开和保密之间平衡，不一定追求一个完美的解决办法。

企业把大部分数据放在云端，少数核心数据放在本地。

不过问题又来了——软件还是在云端运行啊，无论你数据放哪儿，云端总归要得到明文数据才能够分析啊。——所以本地也必须运行一些程序，得到中间数据后传给云端，出最终结果。不过这样软件流程定义就非常复杂了，哪些本地哪些远端。。。晕了。。。

1. 公钥和私钥

Hansens的表述是正确的。问题是如何实现1-N的通讯加密，即，1人写，多人读。我的想法是，

a. 公钥和私钥，在加密解密方面，其实是没有区别的。可以用公钥加密，私钥解密，反过来也行。公钥和私钥的差别在于公钥有公开的分发渠道和鉴权机制，而私钥归个人保管。

b. 用私钥加密，同事们想读，可以用公钥，公钥由公司统一代管。这样，读者不需要麻烦作者发放公钥。

c. 德国人的钥匙很有意思，办公室的钥匙，同时可以打开大楼的门，以及公司的门，但是不能打开隔壁办公室的门。隔壁办公室的钥匙，也可以打开大楼的门，以及公司的门。所以，德国人的钥匙和锁，是有层次的。公钥也可以这么设计，一个部门的公钥，不仅可以解密本部门的文件，而且可以解密公司内部公开的文件，但是不能解密其它部门的文件。实现这样有层次的公钥并不难，一个简单的办法是把整个公钥分成几段，第一段负责公司内部公开的文件，第二段负责某特定部门的文件等等。

2. 索引能否解密

索引不能解密，否则Googler可以根据索引里的信息，复原原文的内容，即便不能一字不漏地全文复原，但是至少能做到八九不离十。

所以，我原文里的话是有漏洞的。正确的说法是，索引不能加密，所以只能留在密室内，而不能上传到云计算公用平台。

3. 数据库的加密

数据库最多只能对字段逐个加密，譬如“greatness”变成“@#￥%”。但是不能整句整段地加密，否则B-tree就建不起来了。

4. 密室

密室的Root权限必须掌握在客户手里。Googler能知道的，是机器的heartbeat，用来监控机器运转的情况。需要时，和客户方的IT人员交流，指挥他们恢复密室机器的正常运转。

• 有没有可能这么办？

在“几点澄清”的回帖中，回答了几个问题。剩下的问题，

1. 不解密就无法构建索引。这是正确的。

2. 各个企业有各自的索引，Google不应该合并这些索引。

可以说服一部分不太担心自己数据安全的公司，但是对于其它公司，没有技术保障，说服力是不够强有力的。

3. Obfuscation

完全同意。程序加密的问题，只能是个半解。

4. VMWare

不需要从头构建OS，可以利用VMWare的办法，让kernel可以边运行，边从一台机器转移到另一台机器。

这个办法很漂亮，但是实现起来将非常麻烦，而且容易出错。

加密数据进，加密数据出。AI内部独立模拟OS. google要破binary就很难。

这是最现实的做法。

大家的讨论很好，尤其是Hansens兄指出我原文中的关于索引是否能加密的硬伤。

稍后我去修改原文。

我原文的结论是，

现在又犹豫了，似乎更合理的表述是，

总之，云计算平台加密的难题，现在没有完美的解决方案。或许目前云计算平台能做的，是代管那些不太机密的内容和程序。

变成一个先进一些的IDC，仅此而已。好像和现在的服务器托管的差距不大啊。

真正的云，应该是把应用程序也托管了。用户只需要“用”，或者说处理数据就可以，如果还需要管理虚拟机上的N个应用程序那和现在的虚拟主机啥的没有拉开差距。