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

vms clustering technology has been existing for almost 30 years now.

你是说Exchange server不稳定吧，这个我很怀疑，我自己管理6,000人的Exchange based邮件系统三年多，最近三年全部在用gmail，不客气地说，我手里的Exchange+Outlook的down time比gmail要少。

还有什么优势可言?Google Docs的优势在于在线、共享和搜索，就是大家可以随时利用Google强大的搜索功能来搜索属于本公司的文件。你们在客户端给加密了，Google还怎么样去index，怎么样让人搜索？要是那样，直接做成网络硬盘的了，为啥还要费劲做Google Docs

邓太发言（不代表邓侃立场）：Google未来怎么做很难说，针对它目前的搜索架构，是无法支持加密的。

大概一年多前吧，Google推出Google Apps for your domain，也就是企业版的解决方案，但是刚刚推出就很不成功，原因两点：

1.它无法说服有规模的企业从MS转过来，企业机密是核心问题；

2.邓侃也提到，Google docs功能还远不及Office,即使企业用户使用Office做编辑，然后用Docs做存储和分享，也会有Office和Docs的兼容性的问题，比如，一个漂亮的PPT上传到Google Prensentation里就会七扭八歪，而且现在Google还不支持pptx上传。

扯远了，说加密问题。既然有规模的公司不愿意用Google Apps for your domain，那么Google在企业用户方面是否就没有作为了呢？也不是。

先说说商业机密，这是个信任问题。Google的确有能力看到，但是它敢不敢看？应该是不敢的吧，否则Google的信誉岂不荡然无存？那么Google公司里面的个人能否看到？也不行，这个在软件设计和云计算运营方面可以保证。

其次，世界上还有成千上万的小公司，专注于自己的商业发展，没有实力拥有自己的IT部门，也不是太在乎自己的所谓机密，Google的服务岂不正中下怀？当时，Google把Apps转向这些中小企业用户之后，注册率疯狂上升，好像还有一段时间，Google Apps for your domain (好像改名叫Google Apps for your group）不允许新的注册，因为“云”满了。上星期帮一位风投友人为某炙手可热的SNS网站做Technical DD,该网站就用Google Apps服务。

加密技术的讨论还是可以继续，相信Google也会继续努力，只是想说，这个世界不一定需要完美的解决方案才能前行。Google没有把加密作为自己最高优先级，而是把和Salesforce的整合放在最前面，原因如此。

email本来就不是公开的，只是相关人等才有权去看。

如我在前端提到：

邓太提到的：

分三个层面：个人端、公司端、google端。

个人端执行文件编辑，公司端建立检索、保存索引、执行检索或全文检索，google端执行文件分布式管理。

流程：

1. 个人A，用office编辑了一份文件a，透明加密保存在google。

2. 同时此文件为公司端获取，建立索引。

3. 个人B，要求检索，公司端直接检索，将结果返回个人B。 或者

4. 个人B，要求全文检索，公司端获取从google获取所有指定搜索范围内文件，在公司端解密、检索，将结果返回个人B。

核心： 加密策略是公司制定的，所以个人加密的部分，公司是完全可解的。

优点：没有解密内容透露给google。

缺点：公司端另安装有google search全索引引擎，全文检索时公司、google间网络开销巨大，IT投入、维护依然是公司的一项管理内容。

结论：这是个半完美的解决方案。 问题在于本应有google做的检索工作，因为保密要求，移到了设在公司内的搜索引擎。

前言：本人对加密算法不甚了解，可能有错误理解，望专业人士予以指正。

思路来源第一部分：

当登录UNIX系统时，个人设定自己的口令，系统将口令予以加密，保存在\etc\password文件下，此文件对系统管理员可见，但不知道口令明文。

举例说明：

某用户：user，设置口令明文：password，口令经系统加密后为some_char_string_1. 在\etc\password文件内可见：

user some_char_string_1，

而系统管理员无从知道用户user的口令明文就是password。

当用户user登录时，系统自动按算法对输入的口令进行加密处理，得到some_char_string_2. 系统读取\etc\password,进行比对判断，如果some_char_string_2 = some_char_string_1,则系统认为口令合法，准许用户user登录。

思路来源第二部分：

系统的加密机制就是RSA加密算法，加密系统是公开的，但密钥分两部分：密钥1、密钥2。密钥1加密钥2才是全部密钥，才能解出明文。

所以，当UNIX对用户口令加密时，实际是用用户user的口令password做密钥1，再加上系统内置的密钥2组成完成的密钥，处理后得到加密后的口令user some_char_string_1保存在\etc\password。

注：这部分主要是说加密的内容，google在不知道全部密钥的情况下，对密文不可解。

基于以上，还是分三个层面：个人端、公司端、google端。

个人端执行文件编辑，保存有密钥1，公司端保存密钥1、密钥2，google端负责建立检索、保存索引、执行索引或全文索引，并且执行文件分布式管理。

流程：

1. 个人A，用office编辑了一份文件a，透明加密保存在google。 此文件是经密码1、密码2共同处理的密文。

2. 个人B，要求检索，公司端截获检索内容，用密钥1、密钥2对进行处理，得到char_string_2，有公司端发送给google进行检索。 并将结果返回个人B。 或者

3. 个人B，要求检索，将检索内容发送公司端，获得char_sting_2，发送给google进行检索。 并将结果返回个人B。

核心：google保存加密后的密文，检索内容在google外加密处理，将处理结果交google对保存的密文进行匹配、检索。

疑问：

明文实际是有规律可循的，如通常英语句子中字母出现的频率是不同的，而密文实际上是消除了这种规律。 所以将加了密的检索内容交google对加了密的内容检索，是否还能成功呢？

或者结合密钥1、密钥2的设置，是否可以在google端既能加密、而又能检索呢？

结论：

不知，这要靠了解加密的朋友给予解答了。 呵呵

实际是“加密与检索解决方案二：分段解决方案”的一个修正：

将方案二中放在公司端的加解密、检索机器，托管到google，此机器安全级别设到军方的B2级别，保证google打不开。

就是不知道google怕不怕来的是个内鬼、倒偷它的东西。 呵呵

另请问：

google现在的检索系统是一个大系统，还是若干同质检索系统联合成的大系统。

1.GOOGLE是平台,但是大家认为OFFICE是平台吗？这就是两种完全不同的市场推广策略所造成的一般人的认知。实际上，OFFICE系列里面（word，excel ETC）有很多很好的应用完全被OFFICE的光环所掩盖，再有就是第三方不愿意花大力气推广OFFICE上的"次级杀手"应用 --- 微软太流氓了，它最后能把相应的功能吸收进来，结果是微软请客，第三方买单（市场推广费用，客户培养）。

2.OFFICE的功能过多，俺看是90%的功能是一般用户难以触及的。就是优化界面后的2007版有事也让俺着实摸不着头脑。用户为90%用不着的东西买单实在是过分。（据说，office是M$家的创利大户，与OS部难分高低，但office部的人员数量比OS部小很多）。

[FLASH]http://ca.youtube.com/v/nD19Os5oUTg[/FLASH]

Chance

你的想法是不是把机器放到Google的机房，而Googler无法以admin的身份登录？

万一机器死机了，怎么办？

企业用Google云计算，图的是个方便。

把文本和索引分离，由不同的团队运行，很容易出差错，修复很麻烦。所以，依我的看法，这个方案企业多半不会太感兴趣。

不过，不管怎么说，这是一个可行的方案。