云里雾里云计算 【6】安全性的难题，有解还是无解？
作者 邓侃 | 2010-04-01 19:23 | 类型 云计算, 互联网 | 10条用户评论 »
系列目录 云计算漫谈
【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机器上的数据。 振远护卫在奥运会期间负责押运运动员尿样 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. 根据不同的保密等级，做分级处理。 实际上一个企业的重要秘密信息是不多的，机密文件存放在企业自己的机房里。其它不需要保密的文件，托管到云计算平台。这个市场也是很大的。 | |
  (7个打分， 平均：4.29 / 5) |
雁过留声
“云里雾里云计算 【6】安全性的难题，有解还是无解？”有10个回复
如果需要高安全的数据占全球数据的大部分，那么可能安全根本无解，如果是一小部分，那么有解无解无所谓，这一小部分有一小部分的解决方法，小众的方案和大众不同
隔离度越要约安全，成本也越高
这里首先一个前提是信任这家公司，否则就不存在这个问题，然后是不能信任这家公司的所有人都是可信任的，那么这个和自己的公司有何区别吗？区别在于出问题的时候是否会为公司利益而庇护自己公司的员工，资本家庇护自己的员工，对员工的好处表面看好像是很人性，但大多数情况本质上这只是为了公司利益的行为而顺便带给个人的好处，如果反过来，不是资本家利益能占大头的话，这些员工会被立刻牺牲掉，力拓如此，Google难道要超脱资本家的控制做上帝吗？
所以从这个角度讲，这里更多的不是技术解决的问题，如果要从技术解决问题，就是让这个业务在Google那里的所有过程任何细节都能被Google的VIP客户完全监控，那么这样就和自己公司基本一致了，如果一旦出了问题，可以做到近乎100%的公平数据被拿出来检查，Google可以认为无法为自己的员工做任何可能的庇护，也就意味者Google的员工在想作恶的时候将会得到的结果和VIP客户自己的员工类似，从而赢得安全客户的信任，让他们掏腰包把银子放到Google的口袋，说得简单一点，Google把云计算的管理部分和VIP客户自己的公司管理模拟得越像，客户就越信任，打一个不好听的比喻，比如一个人发现一个和他爹越相似的人，他是不是越认为是他爹（各位抱歉，实在是没找到合适的比喻），但此时，是否又有了Google自己怕被泄密的问题，如果绕到了鸡蛋问题，就更难解了
在云里面，边界如何定义是个很基本的一个问题，有了边界，访问控制，安全策略之类的就好加载了。至于数据安全，如果数据不是永久存储的，这计算一样是有生命周期，就不会有问题。现在的问题是，在云里面，有两个管理者：
1）云提供者
2）云使用者
3）云客户
现状是1，2是同一个实体；未来是1，2是分离的。如果能从把1,2的权限完全分开，比如资源分配可以是1，而资源访问和管理是2，权限上如果没有重叠，应该可以解决这个问题。
这是技术问题：Homomorphic encryption
邓侃写的很棒!
的确，目前为止业界给出的推荐建议也是中小企业、自己的数据中心或服务器规模较小等的场合，认为自己的运维水平、安全管理水平都无法达到大型数据中心，例如Amazon, Google等的水准。说白了，就是你的环境，规模小、黑客来去自由:)、病毒不断、内部管理松散，等，这种情况下，一家有声望的云计算服务商+相对公平严格的合同 就可以给你带来商业提升、安全上升、和费用节省。
一些场合下，与宣称支持并迁移到云的CIO讨论，他们的观点和推理也大致如此。
CSA的安全指南中也在很多地方强调“透明”、取证、合同化等，目前纯技术方面的“解”的确较少、较初步。
云计算的保密性解决方案，ms是个研究（创业）的好方向
文章写得很棒。
关于加密，文中有点错误：”用私钥加密，用公钥解密”，应该是”用公钥加密，用私钥解密”。
Homomorphic encryption?终极武器，但是现在的技术还不到实用阶段。
关于加密的问题有个相对简单的处理办法，就是二次加密。也就是随机生成一个密钥，用这个密钥对所有数据加密，然后利用公钥和私钥对这个密钥进行加密。
由于在加解密的过程中，随机生成的密钥实际上是不可见的，所以不会产生泄露。而一旦需要改变密码的时候，也只需要重新加密密钥即可，不用对数据进行重复加密。
实际上由于非对称加密算法本身效率比较低，在进行VPN应用的时候，用的就是这个办法。利用公钥私钥的非对称加密传递密钥，然后利用对称算法传输加密数据。而由于巴统的限制，国外出口到国内设备的加密强度不能超过40位，绕过的方法也是这个，密文用128位或者256位甚至更高加密强度，而密钥之用40位加密强度。
ipsec部署的那点难事，不就是密钥分发吗。自动密钥分发，现在的方案，已经足够了。
其实云存储加密的真正难度，这里面没有提到，就是加密在哪一层的问题。
如果是在应用层做加密，那么每个应用程序都要自己的加密解密组件。对于只提供云存储，不提供应用的所为DAAS（尽管我认为这是IAAS的一种，姑且这么叫吧）来说，这是不现实的。那么就要在底层做加密，也就是在驱动上做文章，但是一个数据块加密以后不仅仅是内容发生了变化，长度往往也会变化，因为加密是以一定字长为基础单位的，不够字长的部分会补0或者用其他手段补齐长度，这样硬盘最终写入的数据就和原始存储的数据长度不一样，引起物理位置上的便宜。这就可能带来重复写入覆盖之前的数据，读取数据不完整等一系列的问题。