主题：【原创】云里雾里的云计算 [1] -- 邓侃
家园 的确是个比较笨拙的办法 密钥中心可以解决我们面临的问题，但是并不是说，这是一个好办法。
所以，结论是，在目前技术能力的制约下，云计算的定位，应当以中小企业为目标用户。
家园 花一个。关于云计算给中小企业创造价值 彻底不要IT部门而又能享受IT好处算吗？
如果文档处理，发布网站，发布商品都由云端负责，只要计算机硬件正常（硬件商负责），网络没有问题（ISP负责），开了机就由云提供OS，商业软件和网站模板，修改网页和word一样简单，发布商品就是上传一张照片，输入一个价格。这样的商业模式应该有很多中小公司喜欢的。
1，不需要IT部门了
2，不需要昂贵的DDN专线和难以维护的site-to-site VPN和防火墙了
3，不存在软件开发了，不需要维护升级软件了，不存在当机时间了
4，利用云的data mining功能，中小公司的老板们也能享受超昂贵的ERP软件才有的BI和Strategic Enterprise Management(SEM)了。
如果价格不算太贵，我估计会有很多公司动心的。
家园 云还是可以很有作为的。 商榷 1. 是有解决办法的。
类似单点登录，访问多个不同安全系统。
公司为个人维护有密钥库，对应不同系统。 个人是不知道各具体密钥的。 个人只需知道自己系统登录口令即可。
2. 问题很严重，不可能想象银行的业务数据要加密处理，而同时也不能想象银行会将业务数据放给google云，最多是自己建google云。所以，此强要求不在云的有效用户范围内。
3. 单纯的云存储也是有商业意义的：减低维护成本、人员、服务器、复杂高级网络等。 同时数据的安全要求，比如容灾、黑客、拒绝服务攻击等等和银行要雇佣保安、运钞车一样，都是大费钱的。
核心就是一个：集中意味着效率、意味着费用分摊、意味着伸缩、灵活性，也意味着高级功能实现的可能。
家园 哦哟，这是个大问题 问题提的很正确。
但是这句话讲得绝对了点，
所以说，靠加密是不能解决云计算的数据安全性问题的。Politically correct的说法是，
所以说，云计算的数据安全，似乎难以完全依赖现有的加密技术解决。家园 xixi，一激动就口无遮拦了，已改正。谢谢
家园 有解乎？无解乎？ 我的意见是：在加密解密没有解决之前，或者在我所谓的下一代OS没有发明之前，云端可以关心以下部分客户和业务：
1. 对于数据内容和程序不敏感的企业，比如各种portal网站，论坛，B2C网上商店，政务和各种公共事业的网站（knowledge management）,etc。这部分用户数量还是不小的，也够云端吃一段时间了
2. 云数据库。google做一个巨型的数据库，给用户分配子数据库和一些类似于排序，索引，data mining等标准procedure。用户的程序还是在客户端，从云端取数据和data mining结果。
这种方式，用户可以选择把加密后的所有数据存在云端数据库，或者云端存不敏感数据，自己再建一个小数据库存敏感数据。
3. 云计算平台。类似于巨型计算机。客户端通过云API提供的函数，进行本地很难运行的计算作业。例如：高位密钥加密（如10240以上位数密钥加密，可以本地先进行2048位加密，再送到云端进行高位二次加密），科学计算等
对于有巨量敏感数据的客户而言（银行，交易量很大的商业公司等），似乎，在我的目前的技术理解能力范围内，云计算暂时不适合他们。或许不久之后，google能给我们一个惊喜。
家园 花一个，只是加密与搜索的三个思路都有问题啊 第一个办法是，把加密算法和构建倒排索引的算法通盘考虑，重新设计一套一体化的算法。如老邓所说目前没有有效的算法，因为加密的本质就是打乱顺序保守秘密的。而构建倒排索引之后，这篇文章里出现过的所有词及出现顺序都被google的索引程序知道了，google如果愿意就很容易还原出来。这还如何保密啊？
第二个办法是，客户自己动手建倒排索引，然后把索引加密，上传到云计算平台。这个办法似乎有门，特别是对文本数据信息。不过客户建立的索引加密后，google如何在不解密的情况下与google的索引合并呢？不合并就没法检索，而合并两个打乱了语序不可读的“乱码”文件，这个算法难度可不小啊
第三个办法是，在云计算平台中分离出一部份作为密室，供客户远程秘密操作构建倒排索引的工作。嘻嘻，这个在客户不相信google的情况下，有些掩耳盗铃的意思啦
这样看来，似乎加密与搜索是很矛盾的两件事，想把它们结合在一起不太容易啦。
不过google似乎可以放弃对企业数据需要加密的数据的索引。能够说服用户在他们的存储和运行空间里他们的程序和数据是安全的就OK了。只是困难永远都存在：
数据加密：
加密过的海量企业数据，在运行时如何解密使得用户程序可以读，而其他程序不可读？这对于google的CPU，内存，内存管理算法，以及用户体验都是相当的考验啊
程序加密：
obfuscation后的程序反编译后很难看懂。不过，很多情况下cracker不需要看懂程序，他们只需要根据某个线索找到某个函数（比如根据生成的某个序列号找到序列号生成函数），照抄下来就成了keygen了。毕竟伪机器码还不是01码，在巨大的利益驱使下，估计还是有人愿意干这种枯燥的事情的（比如分析银行数据库解密程序）。
而且无论数据加密/解密还是程序加密/解密，都需要消耗大量的CPU时间和内存。这是google所不愿意看到的。
所以，我在想，既然加密这条路走得很困难，google是不是可以走另一条路，就是：
从头构建一个操作系统！这套OS的源码要公开。如果能够从源码体系证明程序和数据在某个独立的空间存储和运行是安全的，而google又能够证明他们确实是在用这套源码所编译的OS运行云系统，那么我想客户就不会有顾虑了。这类似于证书机制：证书加密机制从算法上被证明是可靠的，那么用证书加密过的数据就是安全的，证书的客户对此不会有任何疑问。
只是，这套OS突破了目前所有OS理论和实践，将是个全新的体系结构。google是否有能力构建出来？
家园 几点澄清，补 在“几点澄清”的回帖中，回答了几个问题。剩下的问题，
不过客户建立的索引加密后，google如何在不解密的情况下与google的索引合并呢？不合并就没法检索，而合并两个打乱了语序不可读的“乱码”文件1. 不解密就无法构建索引。这是正确的。
2. 各个企业有各自的索引，Google不应该合并这些索引。
能够说服用户在他们的存储和运行空间里他们的程序和数据是安全的就OK了可以说服一部分不太担心自己数据安全的公司，但是对于其它公司，没有技术保障，说服力是不够强有力的。
3. Obfuscation
obfuscation后的程序反编译后很难看懂。。。在巨大的利益驱使下，估计还是有人愿意干这种枯燥的事情的（比如分析银行数据库解密程序）完全同意。程序加密的问题，只能是个半解。
4. VMWare
从头构建一个操作系统！这套OS的源码要公开。如果能够从源码体系证明程序和数据在某个独立的空间存储和运行是安全的，而google又能够证明他们确实是在用这套源码所编译的OS运行云系统不需要从头构建OS，可以利用VMWare的办法，让kernel可以边运行，边从一台机器转移到另一台机器。
这个办法很漂亮，但是实现起来将非常麻烦，而且容易出错。
家园 几点商榷 客户在上传数据到Google云计算平台前，先用私钥（private key）给数据加密，这样存储在Google云计算平台的数据，是加了密的数据。Google员工即便打开了文件，看到的也不过是一堆乱码。当客户授权给他的同事看数据时，给同事一份公钥（public key）。同事用这个公钥解码，然后就能读到真实的内容了。http://www.ccthere.com/topic/1986283/15公钥、私钥的加密体系是这样用的， 如果A 要发一份密文给B，那么
1、A用B的公钥对明文加密。
2、A把加密后的密文发给B。
3、B用自己的私钥解开A发来的密文。
这个体系的好处是公钥是公开的，及时第三方即使截获了B的公钥和密文，也无法解密。
公钥、私钥的加密体系不存在用私钥加密的情况。私钥只用于签名，以标明该文件是A签署的。
但这个体系设计初衷是用于点对点的通讯，如果用于多人共享，就需要管理N个公钥，会很麻烦。
第二个办法是，客户自己动手建倒排索引，然后把索引加密，上传到云计算平台。
但是构建倒排索引是一件计算量很大的工作，如果客户能够自己构建倒排索引，那么就没有必要使用云计算平台。理由是，云计算平台的卖点是方便客户处理繁重的数据计算。如果云计算平台不能帮助客户构建他们专用的倒排索引，那么云计算的卖点就大大失色。http://www.ccthere.com/topic/1986283/15
1、如果与计算中存储倒排索引是加密后的，那么存在一个问题就是一个检索请求发到云之后，云需要先对加密的索引解密，然后再进行检索（我不知道有任何能在不解密的情况下，对密文进行检索的技术，如有请指正）。但是这一解密那仍然有信息暴露的问题（如DVD，BlueDVD的破解都是被直接复制了内存中的数据，导致加密方式被破解），因为Google完全可以拷贝一份解密后的明文另存出去。
2、我理解，云计算远远不是检索那么简单，Google希望是承担企业内部的更多功能但是这样一来加密就更加困难，比如数据库的操作实际上大部分的字段数据是无法用密文操作的，因为密文导致的无法检索、无法排序对大部分的ERP，SCM等应用都是灾难性的。（补充一点，密文到不是完全不能检索，但是密文只能做完全匹配，不能做部分匹配，这样导致实用性不大）。
第三个办法是，在云计算平台中分离出一部份作为密室，供客户远程秘密操作构建倒排索引的工作。倒排索引建好了以后，加密，然后复制到密室以外的区域。Google的员工只能监控密室中的机器的CPU，RAM的使用情况，但是他们没有权限进入机器，查看没有加密的倒排索引。密室这个东西，对于建立密室的人实际是毫无意义的，很简单Root权限在谁手上？就现有的计算机操作系统条件下，有Root权限实际上就能看到所有的东西。另外考虑到密文终归是要解密的那“密室”这样的东西对于有Root权限的管理者实际上是无意义的。
就算软件上能做限制，现在很多黑客用的是硬件的内存复制机，绕过任何操作系统直接在硬件上把内存数据复制一份存储到另外一台电脑上。这种情况技术Google完全可以做到。
个人观点，除非有加密体系或者监管系统方面有重大突破，否则数据的安全性问题在技术实际上无解。个人认为从第三方监管等“人”的因素入手也许是个办法。
密码学里面最后一章都是“社会工程”，说的是当年一个超牛的黑客，靠电话和接线MM聊天套磁弄到的初始密码，攻入了AT&T的电话计费系统。
