理解云计算漏洞

早些时候，IEEE的Security&Privacy杂志发表了一篇文章——Understanding Cloud Computing Vulnerabilities。最近被InfoQ翻译为了中文，现转载如下：

关于云计算安全性的讨论往往失于对一般问题和云计算特定问题未加区分。为了让关于安全漏洞的讨论更加明了，根据风险要素与云计算的可靠定义，作者制定了一些指标。

每一天，每一条刚刚出炉的新闻、博客文章或其他的一些发行物都在提醒我们云计算的安全风险和威胁。多数情况下，安全问题都被认为是采用云计算的道路 上最大的障碍。但这种关于云计算安全问题的论调反而让找到一个完善的方法来评估实际的安全后果变得更加困难，原因有如下两点：首先，在有关风险的这些讨论 中，很大一部分都对一些基本的术语词汇——包括风险，威胁和漏洞——不加区分地交替使用，而不考虑各自实际的含义；其次，并不是每一个被提出来的问题，都是特别与云计算的背景对应。

为了更好地理解云计算在安全问题上所带来的新课题，我们必须分析云计算是如何影响了既有的安全问题。这里的一个关键因素是安全漏洞：云计算使得一些大家已经耳熟能详的漏洞变得更加突出，并且贡献了一些新成员。然而，在我们仔细分析特定于云计算语境的漏洞之前，我们必须先确定到底什么才算得上是一个真正的“漏洞”。

漏洞：概述

漏洞是一个突出的风险因素。ISO 27005中把风险定义为“一种潜在的可能性，即某种特定的威胁利用一项或一组设施的漏洞来造成组织的破坏，”对其的度量应包括发生的概率以及事件的后果[1]。Open Group的风险分类法提供了一个有用的危险因素总览（见图1） 。

（点击图像放大。）

图1.在Open Group的风险分类法所总结的会造成风险的因素。风险等于造成损害的事件的发生频率（左）和可能的损失幅度（右）的乘积。而漏洞则对造成损害的事件的发生频率具有影响。

Open Group的分类法中使用了与ISO 27005一样的两条顶级风险因素：有害事件的发生概率（在这里称为造成损害的事件的发生频率）和其后果（在这里称为可能的损失幅度）。可能的损失幅度的子要素（如图1右侧所示）影响一个有害事件的最终代价。而（在图1左侧的）造成损害的事件的发生频率的子因素相对而言较为复杂。当一个威胁载体（例如说***）成功地利用了一个漏洞的时候就会发生造成损害的事件，这种情况发生的频率取决于两个因素：

• 威胁载体试图利用漏洞的频率。这个频率取决于载体的动机（他们从***中获得什么好处？他们需要付出多少努力？对于***者来说的风险是什么？），同时也取决于载体可以在多大程度上访问（“接触”）到***目标。
• 威胁载体的***能力与系统抵御***的坚固性之间的差距。

这第二个因素让我们接近得到一个有用的对于漏洞的定义。

定义漏洞

据Open Group的风险分类法，

“漏洞就是设施无法抵御威胁载体行动的可能性。当威胁载体所施展的力量与目标抵抗能力之间存在差距的时候，就会产生漏洞。

因而，在描述漏洞时必须放在防止某种特定类型的***的背景下来考虑。这里可以举一个真实世界的例子，如果一辆汽车不能够保护它的驾驶者在正面被一辆 以六十英里行驶的卡车撞击时免受伤害，这就是一个漏洞；这辆汽车的溃缩吸能区的强度相对于卡车的冲力来说太弱了。而相对于来自一辆自行车、甚或一辆中速行 驶小型轿车的***而言，这款车的抵抗力则完全足够了。

我们可以还把计算机的漏洞描述成——也就是你可以用供应商所提供的补丁来弥补的安全相关错误——某种抵抗能力的弱化或消失。比方说，一个缓冲区溢出漏洞削弱了系统的防止任意代码执行的强度，而***者是否会利用此漏洞则完全取决于他们的能力。

漏洞和云计算的风险

现在，我们将从右侧的风险因素树开始，着手探讨云计算如何影响图1中的风险因素。

从云客户的角度来看，右侧所描述的可能的对未来损失的幅度的处理完全没有受到云计算的影响：事件的后果和最终的代价——就假定是来自于机密的泄露 ——完全一样，不论这种数据的泄露是发生在云平台还是传统的IT基础设施。而从云服务供应商的角度来看，事情就有一点不一样了：因为云计算系统以前是相互 隔离在相同的基础设施上的，一个造成损害的事件可能带来相当大的影响。但是这个实际情况是很容易把控和纳入风险评估的：看起来不需要在概念上做出什么变化 来适应云计算环境下的影响分析。

因此，我们必须在图1的左侧——造成损害的事件的发生频率——来找找是否有些什么变化。云计算可以改变一个有害事件的发生概率。正如我们后面还会指 出的那样，云计算会导致漏洞要素发生相当大的变化。当然，移植到云基础设施可能会改变***者的访问级别和动机，以及工作量和风险——这是在以后的工作中必 须考虑的一个事实。但是，对支持特定于云计算的风险评估而言，从考察特定于云计算的漏洞的严格本质入手似乎最有效益。

云计算

真的有所谓“特定于云计算”的漏洞吗？如果是这样的话，在云计算的本质中必然存在某些因素让一个漏洞成为特定于云计算的漏洞。

从本质上讲，云计算把已知的技术（如虚拟化）用巧妙的方法结合起来，“从流水线”上提供IT服务，产生了规模经济的效果。下面我们将更加详细地讨论什么是核心技术，以及这些技术在云计算的应用中有哪些关键的特性。

核心云计算技术

云计算非常依赖于现有的几样核心技术能力：

• Web应用程序和服务：如果没有Web应用程序和Web服务技术，要发展软件即服务（SaaS）和平台即服务（PaaS） 是无法想象的：SaaS实例通常作为Web应用程序实施，而PaaS实例提供了Web应用和服务的开发和运行环境。在基础设施即服务（IaaS）实例中， 管理员通常使用Web应用程序/服务技术来实施相关服务和API，例如客户的管理访问。
• 虚拟化的IaaS实例：在这些技术中虚拟化技巧都占据了核心地位。由于PaaS和SaaS服务往往建立在支持性IaaS基础设施之上，虚拟化的重要性也就延伸到了这些服务模型中。在未来，我们希望虚拟化可以从虚拟化服务器发展到可以直接用于SaaS服务的计算资源。
• 加密：许多云计算安全的要求只有通过使用加密技术才能够得到解决。

随着云计算的发展，这份核心技术的清单很有可能扩大。

基本特征

在其基本的云特性的描述[2]中，美国国家标准与技术研究所（NIST）敏锐地指出了从流水线上提供IT服务意味着什么：

• 按需自助服务：用户可以使用——比方说一个门户网站和管理界面，来订购和管理服务，而不再需要与来自服务供应商的真实的人打交道。服务及其相关资源的上线准备和下线准备都在供应商端自动解决。
• 无处不在的网络接入：云服务是通过网络（通常是互联网）访问的，应用标准的机制和协议。
• 资源池：用于提供云服务的计算资源是通过使用一个在所有服务用户间共享的同质基础设施实现的。
• 敏捷的弹性：资源可以快速并且具备弹性的扩充或缩减。
• 可度量的服务：资源/服务的使用率随时进行测算，支持资源使用率优化、使用率用户报告以及用多少收多少的商业模式。

NIST的云计算定义框架，包括其关键特性列表，现在已经演化成为事实上的定义云计算的标准。

特定于云计算的漏洞

根据我们前面介绍的云计算的抽象视图，我们现在可以下手定义什么构成了特定于云的漏洞。我们可以说一个漏洞是特定于云的，条件是其：

• 对于某个核心云计算技术来说是不可分割的或是广泛存在的，
• 根本诱因是NIST的关键特性列表中的一项，
• 其发生可以归咎于云计算创新让尝试和测试安全控制难以、甚至根本无法实施，或者
• 在成功的最新云计算服务中很常见。

我们现在来研究这四项指标。

核心技术漏洞

云计算的核心技术——Web应用程序和服务、虚拟化和加密——存在一些漏洞，有些是固有于技术本身，而另一些则是普遍存在于该技术的流行实现方式中。这里举这些漏洞的三个例子，包括虚拟机逃逸、会话控制和劫持以及不安全或过时的加密。

首先，虚拟化的本质就决定了存在***者从一个虚拟环境中成功逃脱的可能性。因此，我们必须把这个漏洞归类于固有于虚拟化、与云计算高度相关的那一类漏洞。

其次，Web应用技术必须克服这样一个问题，即从设计的初衷来说，HTTP协议是无状态协议，而Web应用程序则需要一些会话状态的概念。有许多技 术能够实现会话处理，而许多会话处理的实现都容易遭受会话控制和劫持，这一点随便一个具有丰富Web应用安全经验的安全专业人士都可以作证。会话控制/劫 持漏洞是Web应用技术所固有的呢，抑或“只是”常见于许多当前实现？这一点是值得商榷的。不过，在任何情况下，这样的漏洞当然和云计算有关系。

最后，密码分析学的进步可以使任何加密机制或算法变得不再安全，因为总是有新奇的破解方法被找出来。而更为普遍的情况是，加密算法实现被发现具有关 键的缺陷，可以让原本的强加密退化成弱加密（有时甚至相当于完全不加密）。在没有加密来保护云里的数据保密性和完整性的情况下，无法想象云计算能够获得广 泛的应用，因而可以说不安全或过时的加密漏洞与云计算有着非常密切的关系。

关键的云特性的漏洞

正如我们前面提到的，NIST描述了五个关键的云计算特性：按需自助服务，无处不在的网络接入，资源池，敏捷的弹性和可度量的服务。

下面是一些源自上述一种或以上特性的漏洞的例子：

• 未经授权的管理界面访问：按需自助服务云计算特性需要一个管理界面，可以向云服务的用户开放访问。这样，未经授权的管理界面访问对于云计算系统来说就算得上是一个具有特别相关性的漏洞，可能发生未经授权的访问的概率要远远高于传统的系统，在那些系统中管理功能只有少数管理员能够访问。
• 互联网协议漏洞：无处不在的网络接入云计算特性意味着云服务是通过使用标准协议的网络获得访问。在大多数情况下，这个网络即互联网，必须被看作是不可信的。这样一来，互联网协议漏洞也就和云计算发生了关系，像是导致中间人***的漏洞。
• 数据恢复漏洞：关于资源池和弹性的云特性意味着分配给一个用户的资源将有可能在稍后的时间被重新分配到不同的用户。从而，对于内存或存储资源来说，有可能恢复出前面用户写入的数据。
• 逃避计量和计费：可度量的服务云特性意味着，任何云服务都在某一个适合服务类型的抽象层次（如存储，处理能力以及活跃帐户）上具备计量能力。计量数据被用来优化服务交付以及计费。有关漏洞包括操纵计量和计费数据，以及逃避计费。

接下来我们可以利用NIST的完善的云计算定义来思考云计算问题。

已知安全控制的缺陷

如果云计算创新直接导致在实施控制上的困难，标准安全控制漏洞就应该认为是特定于云计算的。这种漏洞也被称为控制的挑战 。

在这里，我们剖析这种控制的挑战的三个例子。第一个挑战是虚拟网络提供的基于网络的控制不足。由于云服务自身的性质的限制，对IaaS的网络基础设 施的管理访问和量身定制网络基础设施的能力通常是有限的，因此无法应用标准控制，如基于IP网络的分区。此外，标准的技术，如基于网络的漏洞扫描通常被 IaaS提供商所禁止，原因之一是无法把友好的扫描从***者的活动区别开来。最后，像虚拟化这样的技术意味着网络流量同时产生在真实和虚拟的网络中，比 如，当托管在同样服务器上的两个虚拟机环境（VMEs）通信的时候。这些问题构成了一个控制的挑战，因为基于尝试和测试的网络级安全控制在一个给定的云环 境中可能无法正常工作。

第二个挑战是在差劲的密钥管理程序。正如在一项最近的欧洲网络和信息安全局的研究所表明的一样[3]，云计算基础设施需要管理和存储许多不同种类的密钥。由于虚拟机不会有一个固定的硬件基础设施，并且基于云的内容往往是地理上分散的，更难以对云计算基础设施的密钥实施标准控制——如硬件安全模块（HSM）存储。

最后，安全指标没有根据云基础设施进行调整。目前，还没有这样一种标准化的特定于云计算的安全指标，让云客户可以使用它来监视云资源的安全状态。在这样的安全指标被制定和实施之前，对安全评估、审计和问责的控制会更加困难和昂贵，甚至可能是不可能开展的。

最新的云计算实例中常见的漏洞

虽然云计算相对年轻，但在市场上已经存在无数的云计算实例。因此，我们为前述的三项特定于云计算的漏洞指标补充第四个实证指标：如果一个漏洞在最新的云计算实例中很常见，就必须认为它是特定于云计算的。这些漏洞的例子包括注入漏洞和薄弱的身份验证方案。

针对注入漏洞的***是指操纵服务或应用输入来以开发者意想之外的方式来解释或执行输入的片段。注入漏洞的例子包括：

• SQL注入：指在输入包含SQL代码，诱发错误的数据库后端执行；
• 命令注入：在输入中包含通过操作系统被错误执行的命令；
• 跨站点脚本：在输入中包含JavaScript代码，在受害者的浏览器中执行。

此外，许多广泛使用的身份验证机制是很薄弱的。例如，用于验证的用户名和密码是薄弱的，原因如下：

• 不安全的用户行为（选择弱密码，重复使用的密码，等等）；
• 单因素认证机制固有的局限性。

身份验证机制的实现也可能有弱点并导致被***，例如凭证拦截和重播。当前最新的云计算服务中的大多数都采用了用户名和密码的身份验证机制。

架构组件和漏洞

云服务模式通常分为SaaS，PaaS和IaaS，在给定云基础设施时，每一种模式都会影响暴露出来的漏洞。增加更多的结构性到服务模式堆栈会有所 帮助：图2中给出了一种云计算参考架构，明确了最重要的安全相关的云计算组件，而且为了分析安全问题提供了一个云计算的抽象概述。

图2.云计算参考架构。我们建立了特定于云计算的漏洞到这个参考架构的组件之间的映射关系，这样让我们大致了解有哪些漏洞可能会与一个给定的云计算服务相关。

这个参考架构是基于在洛杉矶的加州大学和IBM开展的工作[4]之 上的。它继承了分层的方法，因为层可以囊括一个或多??个服务组件。在这里，我们使用“服务”在广义上的概念，既可能包括物质（如建筑、电力和硬件），也 可能包括非物质（如运行时环境）。对于云计算的软件环境和云软件基础设施这两层，这个模型明确了层中的三个主要的服务组件——计算、存储以及通信。顶层服 务可以由堆栈更下层来实现，事实上跳过中间层。例如，云端的Web应用程序可以用传统的方式实施和操作——也就是说，在一个标准的操作系统上运行，而无需 使用专用的云计算软件的基础设施和环境组件。从这样的分层和组合性可以知道，在模型的任何层之间，都可能从场地内服务或功能供应转换到服务和功能外包。

除了原有的模式，我们还确定了若干层服务的相关支持功能，并将它们添加到模型中，垂直覆盖几个水平层。

我们的云计算参考架构有三个主要部分：

• 支持（IT）基础设施：这些对于任何IT服务、云计算或其他方式来说都是常见的设施和服务。我们之所以把它们包括在架构之中，是因为我们希望提供一个全景——要完整描述IT安全性就必须也照顾到云服务的非特定于云计算的组成部分。
• 特定于云计算的基础设施：这些组件构成云服务的核心，特定于云计算的漏洞和相应的控制通常映射到这些组成部分。
• 云服务的消费者：同样，我们之所以把云服务的客户包括到架构中是因为它对于全面的安全性讨论很重要。

此外，我们明确地把将云服务消费者和云计算基础设施分开的网络表示出来，因为云资源是通过（通常是不可信的）网络进行访问的这一个事实是云计算的主要特点之一。

使用云计算参考架构的结构，我们现在可以挨个讨论架构的组成部分，并给出每个组成部分特定于云计算的漏洞的例子。

云计算软件基础设施和环境

云计算软件基础设施层把作为服务提供给上层的基本IT资源抽象成为一个抽象层次，这些资源包括：计算资源（通常是VME——虚拟机环 境）、存储以及（网络）通讯。这些服务可单独使用，典型场景是用于存储服务中，但他们也经常捆绑在一起，这时服务器就会附有网络连接，（通常）还提供对存 储的访问能力。这种捆绑在一起的服务通常简称为IaaS，无论是否带有存储能力。

云计算的软件环境层在应用平台层面提供服务：

• 一个开发和运行时环境，支持用一种或多种语言所开发的服务和应用程序；
• 存储服务（是数据库接口，而不是文件共享）；
• 通信基础设施，如微软的Azure服务总线。

在基础设施和环境层存在的漏洞通常都与这两层提供的三种资源类型的某一种密切相关。然而，跨租户访问漏洞就与所有三种类型的资源都有关系。我们前面 描述的虚拟机逃逸漏洞的就是一个典型的例子。我们用它作为一个核心虚拟化技术所固有的漏洞的例子，但也可以认为它根本上是来自于资源池的本质特征：当使用 资源池时，跨资源的未经授权的访问将成为一个问题。因此对PaaS而言，就算用于隔离不同的租户（和租户服务）的技术未必基于虚拟化（不过这其实是一个越 来越流行的趋势）的时候，跨租户访问漏洞也还是会产生影响。同样，云存储容易导致交叉租户存储访问，云通信——以虚拟网络的形式——容易导致交叉租户网络 访问。

计算资源

一组高度重要的计算资源漏洞是与如何处理虚拟机映像有关：提供几乎相同的服务器映像的唯一可行的办法——从而为虚拟服务器提供按需服务——是通过克隆模板镜像来实现。

有漏洞的虚拟机模板镜像会导致许多操作系统或应用程序上的漏洞传播到更多系统。***者可能伪装成服务客户租用一个虚拟服务器以获得管理员权限，这样 就能够分析系统的构成方式、补丁版本，甚至是具体代码，从而获得在***其他客户的镜像时有用??的信息。另外一个有关的问题是，镜像有可能是来自于不可信 来源，这种现象随着IaaS服务的虚拟镜像交易市场的出现更为突出。在这种情况下会存在一些风险，比如镜像可能被动过手脚，从而为***者提供后门。

虚拟机复制造成的数据泄漏也是一个类似的漏洞，原因同样在于为了提供随需服务而进行镜像克隆。克隆会导致虚拟机机密数据的泄漏问题：一个操作系统的 某些元素——如主机密钥和加密字符串——本来应该完全属于一台主机，可是克隆却可能破坏这个关于隐私的隐含前提。这次同样是虚拟机镜像的新兴交易市场—— 比如说亚马逊EC2——会引出一个相关的问题：用户可以把运行中的镜像转换成模板，并向其他用户来提供模板镜像。根据在创建模板前该镜像被使用的情况，此 镜像有可能会包含用户并不愿意公开的内容。

这里还有一些控制上的问题，其中一些与应用加密有关。如果介于硬件与操作系统间的虚拟化抽象层在为虚拟机运行环境生成随机数的时候发生问题，这种薄 弱的随机数生成机制可能会导致加密上的漏洞，因为要生成随机数往往需要硬件级别的信息源。虚拟化可能在利用这样的信息源上存在缺陷，或者说在同一台主机上 容纳多个虚拟机运行环境可能会穷尽可用的信息源，导致薄弱的随机数生成机制。我们前面也提到了，这个抽象层还让先进的安全控制——像是硬件安全模块——的 使用更加复杂，结果就可能是蹩脚的密钥管理程序。

存储

除了由于资源池和弹性的特性所引起的数据恢复上的漏洞，还有一个与介质擦除相关的控制问题，在云计算环境中这往往是很难或不可能实现的。例如，在一个生命周期的末尾，如果一个磁盘仍被另一租客使用，就不能执行要销毁物理硬盘的数据销毁政策。

由于加密技术经常被用来克服与存储相关的漏洞，这一核心技术的漏洞——不安全或过时的加密和蹩脚的密钥管理——在云存储中有着特殊地位。

通信

云通信服务最突出的例子是为IaaS环境中的虚拟机运行环境提供网络支持。由于资源池，几个客户可能拥有同样的网络基础设施组件：共享网络基础设施 组件的漏洞——像是DNS服务器或动态主机配置协议中的漏洞，或IP协议的漏洞——可能在IaaS的基础设施中引发基于网络的跨租户的***。

虚拟化网络还提出了一个控制上的问题：在云服务中，与上面其他问题一样，IaaS的网络基础设施的管理权限访问和剪裁网络基础设施的可能性通常是受 限的。此外，诸如虚拟化等技术的使用会导致网络流量不仅发生在“真正的”网络上，同时也发生在虚拟网络中（如在同一服务器上托管的两个虚拟机运行环境之间 的通信），大多数虚拟网络的实现只提供了集成基于网络安全的有限可能性。总而言之，这形成了一个控制上的问题，即不充分的基于网络的控制，因为基于尝试与 测试的网络级别安全控制可能在某些云计算环境下无法工作。

云计算Web应用程序

Web应用使用浏览器技术来在前段执行用户交互。随着基于浏览器的技术如JavaScript、Java、Flash和Silverlight被更多地采用，Web云计算应用可以被分为两种：

• 被维护在云端的应用程序组件；
• 在用户的浏览器内运行的浏览器组件。

今后，对于一些不需要频繁访问远端数据的情况，开发商将越来越多地使用一些技术，像是谷歌Gears等，来允许脱机使用Web应用的浏览器组件。我们已经描述了两个典型的Web应用程序技术漏洞：会话控制和劫持漏洞，以及注入漏洞。

其他特定于Web应用程序的漏洞与浏览器的前端组件有关。其中包括客户端的数据操作的漏洞，用户可利用其操纵应用程序组件发送到服务器的应用程序组 件的数据，从而***Web应用。换句话说，服务器组件收到的输入是不是“预期”的客户端组件发送的输入，而是变更过的或是完全由用户生成的输入。此 外，Web应用程序还依赖于浏览器的机制以隔离嵌入到应用程序（如广告、Mashup组件等）的第三方内容。因此，浏览器的隔离漏洞可能允许第三方内容来 操作的Web应用程序。

服务和API

虽说云计算基础设施的所有层次看起来都明显提供服务，但要讨论云计算基础设施的安全性，还是值得特别地考虑所有基础设施的服务和应用的编程接口。大 多数服务都可能是Web服务，从而也具有许多Web应用程序漏洞。事实上，Web应用程序层可能完全由一个或多个Web服务实现，这样应用的URL只会把 浏览器组件暴露给用户。因此，配套服务和API函数也具有Web应用程序层的许多漏洞。

管理访问

NIST的云计算定义指出云服务的核心特征之一是：可以快速准备并发布，只需要最小的管理工作或服务提供商的配合。因此，每个云服务的一个共同点是 管理接口，这会直接导致非法访问管理接口的漏洞。此外，因为经常使用Web应用或服务实现管理访问，它通常也会带来与Web应用层和服务/API组件同样 的漏洞。

标识、身份验证、授权和审计机制

所有的云服务（以及每个云服务的管理界面）都需要身份管理、认证、授权和审计（IAAA）的机制。在一定程度上，这些机制的某些部分可能被分离出 来，作为一个独立的IAAA服务以供其他服务使用。足够的授权检查（这必然会用到身份验证和/或从IAA服务收到的授权信息）和云基础设施的审计这两个 IAAA要素是每个服务实现的不可分割的部分。

IAAA组件相关联的大部分漏洞必须被视为特定于云计算，因为它们在当前最新的云计算实例中很常见。前面我们已经举了薄弱的用户认证机制的例子，其他的例子还包括：

• 由于帐户锁定而拒绝服务：一个经常使用的安全控制——尤其是对于用户名和密码验证方式来说——就是锁定那些在很短时间内连续发生失败验证请求的帐号。***者可以利用这样的方法来发动针对某个用户的DoS***。
• 薄弱的凭证重置机制：当云计算供应商自己来管理用户凭证，而不是使用联邦式身份验证，他们必须提供一个机制来重置凭证，以防凭证被忘记或丢失的情况。在过去，密码恢复机制已被证明非常薄弱。
• 不足或错误的授权检查：最新的Web应用程序和服务的云计算实例往往容易受困于不足或错误的授权检查，会暴露未经授权的信息或行为给用户。比方说缺少授权检查就是URL猜测***的根源。在这种***中，用户可以修改URL来显示其他用户帐户的信息。
• 粗粒度的授权控制：云服务的管理界面特别倾向于提供过粗粒度的授权控制模型。因此，像职责分离这样的标准安全措施得不到实施，因为没办法只提供给用户那些仅够他们展开工作的权限。
• 日志和监控不足的可能性：目前，还没有一个标准或机制来让云计算的客户来记录和监测云计算资源内的设施。这就产生了一个尖 锐的问题，即日志文件记录所有租户事件，无法容易地把单个租户的信息剪裁出来。此外，监测能力的不足往往阻碍了供应商进行安全监控。直到我们制定出可用的 关于记录和监测的标准并实施成为工具之前，是很难——甚至说是不可能——实现需要记录和监测的安全控制的。

以云服务提供商的经验而言，在所有这些IAAA漏洞中，目前验证问题是主要的漏洞，因为它让用户放在云服务里的数据蒙受风险[5] 。

提供商

所有云计算组件的漏洞，或者更确切地说，无法让用户像控制自己的基础设施一样控制云计算基础设施，通常都让提供商感到担心。控制方面的课题有：安全 审计不足的可能，以及认证方式和安全度量在云计算中没有得到采用这样一个事实。此外，审计、认证与持续安全检测这样的标准安全控制没有被有效地实施。

云计算还处于不断发展的阶段，随着该领域的成熟，更多的特定于云的漏洞肯定还会出现，而旧的威胁也会减弱。从Open Group的风险分类，加上我们在此识别出的特定于云计算的漏洞的四项指标，我们得到了精确的关于漏洞的定义，提高了准确度和清晰度，而这正是目前为止的 对云计算安全性的讨论中所缺乏的。

一些本来成功的安全控制在云计算的背景下变得无效，这些情况在安全控制的问题中往往很突出。因此，这些问题对于进一步的云计算安全研究具有特殊的意 义。事实上，目前有许多努力——如安全度量和认证方式的开发，以及全功能虚拟网络组件发展——都试图直接解决这些控制方面的问题，方法是在云计算中使用基 于尝试和测试的控制。

作者简介

Bernd Grobauer是在信息安全方面的高级顾问，领导着西门子计算机紧急响应小组（CERT）的研究活动，包括安全事件检测和处理、恶意软件防御和云计算安全。Grobauer拥有丹麦奥胡斯大学的计算机科学博士学位。他是国际信息完整性机构的资格咨询委员会成员。要想联络他请发邮件至[email protected] 。

Tobias Walloschek是西门子IT解决方案和服务公司的高级管理顾问。他的研究兴趣是云计算安全性和业务导入战略。Walloschek拥有德国因戈尔施塔特应用科学大学的工商管理学士学位。他是信息系统安全认证专家。要想联络他请发邮件至[email protected]。

Elmar Stocker是西门子IT解决方案和服务公司的一位经理，在那里他负责投资组合策略和专业服务组合监管。他还领导云计算的安全性和PaaS活动。Elmar Stocker拥有德国亚琛工业大学的计算机科学硕士学位。要想联络他请发邮件至[email protected]。

 

---

[1] ISO/IEC 27005:2007 Information Technology—Security Techniques—Information Security Risk Management, Int’l Org. Standardization, 2007.

 

[2] P. Mell and T. Grance, “Effectively and Securely Using the Cloud Computing Paradigm (v0.25),” presentation, US Nat’l Inst. Standards and Technology, 2009;

 

[3] European Network and Information Security Agency (ENISA), Cloud Computing: Benefits, Risks and Recom-mendations for Information Security, Nov. 2009;

 

[4] L. Youseff, M. Butrico, and D. Da Silva, “Towards a Unified Ontology of Cloud Computing,” Proc. Grid Computing Environments Workshop (GCE), IEEE Press, 2008; doi: 10.1109/GCE.2008.4738443.

[5] E. Grosse, “Security at Scale,” invited talk, ACM Cloud Security Workshop (CCSW), 2010;