为何有些云比其他云更可信

（本文原文为英文“Why and how some cloud can be more trustworthy than the other”，作者于2010年10月29日发表于EMC Community Network: https://community.emc.com/community/labs/blog/2010/10/29/why-and-how-a-cloud-can-be-more-trustworthy-than-the-other ）

 

下图描绘了一个云上信息处理的典型场景（该图构造结合了两个云计算标准：“开放云计算界面OCCI”与“云数据管理界面CDMI”）：

 

这个典型云计算场景不失一般性地同时使用了两个云数据中心：一个用来提供计算资源，客户（Client）通过OCCI技术规范提供的机制来控制计算进程；另一个用来提供数据存储资源，用户通过CDMI技术规范提供的机制来控制数据的使用与处理。在客户与这两个数据中心之间的控制机制都可采用RESTful或者web服务命令。几乎无须解释具体技术细节，从客户看来这两个数据中心所要用到的所有东西，无论是虚拟机或者存储对象或者其他一些什么更具体的细节，每一样东西都可以由一个URI（“统一资源描述符”，就像网页一样）来描述从而使所被描述的对象可以受到由客户端发起的RESTful命令来控制。我们可以想象这个计算场景为：一个学者使用EC2虚拟机中的分析算法来分析纽约时报档案中的一些非结构化数据信息，研究金融海啸为什么发生。这个学者用OCCI技术规范编制的RESTful指令来控制EC2虚拟机中的分析算法，用CDMI技术规范编制的RESTful的命令来处理纽约时报档案中的有关数据。这样分布式的信息处理方法之所以可行是因为各个相关的URI可以正确无误地通过互联网连接上。

从这个在云上信息处理的典型场景中我们可以看到客户端几乎没有什么资源与数据。它依赖URI，RESTful命令，以及其他一些元数据信息例如身份和证书来使用EC2和纽约时报所提供的计算与数据资源。当然客户端还有其他一些信息也可以通过RESTful的通讯来传递到数据中心：例如某些击键和鼠标位置的信息等等。说实话，可能仅有用户身份和证书信息才是在客户端需要做安全保护的敏感信息。我相信在客户端对这些东西的保护技术应当是属于传统的网络安全话题，应该和云安全技术基本无关。我曾听到过这样的演讲： 在客户端对数据进行加密，然后把密文放到云数据中心，期望以此作为一种云存储的安全方案。显然这是一个客户端计算解决方案，和云计算没有任何关系。一个真正的云存储安全问题必须考虑用户数据在服务器上以明文状态存在，因而诸如重复数据删除等计算问题才能够被服务器执行完成，所以云存储安全问题的关键是如何保护服务器上明文计算的安全。我还听到过另外一些演讲，基本上的意思是一些云数据中心可以提供“安全作为服务”（Security as a Service），例如，验证用户存放在一个云数据中心的数据的完整性和可下载性（Retrievability）。这些验证的过程使用一些相当复杂的密码协议。我不仅对这样故事背后的逻辑要感到困惑，这就是为什么我在这篇文章的标题中要问这样的问题：为什么有些云要比其他云更值得信赖呢？在这些故事中的加密协议本身似乎并没有给出某种特别有意义的说明。经过仔细研究这些加密协议，我开始看到了一点原因了。这些密码协议都有一些浓厚的历史渊源，协议的两个执行方一端是本地计算，另外一端是假想敌。毫无疑问，本地一端的计算的确是更可信的。那么这些故事背后的逻辑其实是重新回到本地计算这一模型。IT行业正在飞速前进，像这样的“本地计算更多资源，更聪明，更安全”的思路显然和云计算背道而驰，必将会被逐渐遗忘。云安全的一个关键思路就是避免这种“本地和远端”的思想：将来本地计算将越来越少，最终将不复存在。本地计算将会变得无资源，不聪明，安全需求大为降低，因而传统的“中间人”攻击（man-in-the-middle attacks）也将会发展成为相对应的“服务器上存在恶意攻击”（man-in-the-cloud-server attacks）的版本。

 

现在讨论为什么有些云比另一些云更可信，因而更适合提供安全服务。在我看来，之所以有些数据中心比其他数据中心更值得信赖，是因为这些数据中心投入更多资源实现更强的安全保护。例如，它们做充分的病毒和恶意软件扫描，欺诈检测，有力的数据丢失防护，隔离，沙盒，身份保护，入侵检测等，最为重要的是，它们会采用一些机制来防止内部攻击。对付内部攻击（可以由某个恶意系统操作员发起）的技术机制也许是使一个云数据中心更值得信任的最为相关的要素。因为所有其他上述的安全保护机制都是在云计算时代之前就存在的常规安全机制。我还认为，可信计算技术才是阻止数据中心内部攻击的最为相关和实用的技术方法。

原文链接： http://blog.csdn.net/wenbomao/article/details/5977598