确保数据的保密性和完整性

原来局限在私有网络的资源和数据现在暴露在互联网上，并且这些资源和数据放到了第三方云计算提供商所有的共享公共网络上。

与第一个风险因素相关的例子是2008 年12 月报道的亚马逊Web 服务(AWS )漏洞注1。在一篇博客文章中，作者详细说明了在数字签名算法中的一个漏洞，“通过HTTP 对亚马逊SimpleDB 数据库(Amazon SimpleDB )、亚马逊弹性计算云(Amazon Elastic Compute Cloud，EC2 )或亚马逊简单队列服务(Amazon Simple Queue Service，SQS)执行查询(Query ，又称REST )请求。”尽管采用HTTPS (代替HTTP )可能会降低完整性风险，但是不使用HTTPS (却使用HTTP )的用户却面临着越来越大的风险，他们的数据可能在传输中被莫名其妙地修改。

注1：这个问题于2008 年12 月18 日报告在Colin Percival 的博客“Daemonic Dispatches ”上，参见“AWS signature version 1 is insecure”。在亚马逊Web 服务网站上并没有公开承认这个问题，也没有对Percival 的博客文章做公开回应。

图3-1 ：私有云计算的一般拓扑图

确保适当的访问控制

由于资源的一部分(也可能是资源的全部)现在暴露在互联网上，公共云使用机构的数据将面临日益增长的风险。对云计算提供商的网络运行进行审计(更不用说基于自身网络进行实时监控)基本上是不太可能的，哪怕是事后审计也很困难。能够获取的网络层面的日志和数据不多，而且全面进行调查并收集取证数据的能力也是相当有限的。

与第二个风险因素相关的例子是IP 地址再使用(再分配)的问题。一般来说，当用户不再需要已分配的IP 地址时，云计算提供商不再保留用户的IP 地址。当地址变为可用后，地址通常再分配给其他用户使用。从云计算提供商的角度看，这么做是有道理的。IP 地址数量有限，同时也是用于收费的资产。然而从用户安全的角度出发，IP 地址再分配使用可能会带来问题。用户无法确信他们对资源的网络访问能随着IP 地址的释放一并终止，从DNS 中的IP 地址改变到DNS 缓存清理，这之间显然存在一段时间延迟。从ARP 表中改变物理地址(例如MAC )到将ARP 地址从缓存中清除也会有一定的滞后时间，因此在老的地址被清除之前，还是会一直存在于ARP 缓存中。这意味着即使地址可能已经变化，原先的地址在缓存中依旧有效，因此用户还是可以访问到那些理应不存在的资源。近期，最大的云计算提供商之一接到了许多与未失效IP 地址相关的问题报告。这极有可能是2008 年3月亚马逊网络极力宣扬其弹性IP 地址能力的一个推动因素注2。(使用弹性IP 地址，分配给用户5个可路由的IP 地址，而这些地址由用户控制分派。)此外，根据Simson Garfinkel：

现有负载均衡系统中所存在一个问题导致任何超过231 字节内容的TCP/IP 连接都会终止。这就意味着超过2GB 的目标内容必须在亚马逊简单存储服务(S3 )中分几次执行，每次执行都对应着相同目标内容的不同字节区域注3。

然而，未失效IP 地址以及对资源的未授权网络访问等问题并不仅仅出现在可路由的IP 地址上(例如那些提供互联网直接访问的资源)。这个问题也存在于提供商为用户提供的内部网络以及非可路由IP 地址的分配上注4。虽然资源可能无法通过互联网直接获得，但出于管理的目的，这些资源必须可通过专用地址在提供商网络上进行访问。(每个公共的或者面向互联网的资源都有其私有地址。)你的云计算提供商的其他用户有可能从内部通过云计算提供商的网络获得你的资源，虽然他们未必会故意这么做注5。正如在《华盛顿邮报》中报道的，亚马逊Web 服务存在着对其资源滥用的问题，危及公众及其他用户注6。

市面上的一些产品注7可以帮助减轻IP 地址再使用的问题，但除非云计算提供商把这些产品作为服务提供给用户，否则用户将不得不寻求第三方的产品并支付费用，以解决由云计算提供商所带来的问题。

确保面向互联网资源的可用性

越来越多的数据以及越来越多的机构人员都依赖外部托管以确保云计算提供的资源的可用性，人们对网络安全的依赖程度在逐渐上升。因此你的机构一定可以接受我们在之前部分列举的三个风险因素。

BGP 注8前缀劫持(例如对网络层可达信息的篡改)为第三个风险因素提供了很好的示例。前缀劫持包括在未经他人允许的情况下通报属于他人的自治系统注9地址空间。这样的通报常常是由于配置错误而产生的，但这些错误的配置可能仍然影响你的基于云计算的资源的可用性。根据在2006 年2月提交给北美网络运营商集团(NANOG )的一份研究显示，这种配置错误每个月会发生数百次注10 。这种错误配置最出名的实例是在2008 年2 月发生的。当时巴基斯坦电信公司由于操作失误，把YouTube 假路由通报给其位于中国香港的PCCW 电信合作伙伴。由于网站上有据称亵渎的视频，YouTube 在巴基斯坦是被封锁的。这次事件的直接结果是YouTube 在全球范围内无法使用长达两个小时注11 。

除了配置错误，还有其他的蓄意攻击。虽然出于蓄意攻击的前缀劫持情况远少于配置错误，但这种问题还是会产生，并阻碍对数据的访问。根据提交给NANGO 的同份研究报告显示，这种前缀劫持攻击每月出现的次数在100 次以内。虽然这种攻击并不新颖，但无疑会随着云计算的广泛使用而增多，也有可能变得十分普遍。随着云计算使用的增长，基于云计算的资源可用性对用户的价值也在逐渐增长。这种对用户不断增长的价值也导致了不断增长的恶意行为风险，给这些资源的可用性带来了巨大的威胁。

DNS 注12 攻击也是与第三个风险因素相关的例子。事实上，与云计算相关的DNS 攻击有若干种形式。虽然DNS 攻击并不新颖也不直接与云计算相关，但是由于不断增加的外部DNS 查询(减少了“水平分割”DNS 配置的影响注13 )以及越来越多的机构人员愈加依赖网络安全以确保其使用的基于云计算的资源的可用性，导致在网络层面上DNS 和云计算的问题对于机构的风险也在逐步上升。

虽然在2008 年绝大多数网络安全的关注集中在“Kaminsky Bug”注14(CVE-2008-1447 中“DNS Insufficient Socket Entropy Vulnerability ”)上，但其他的DNS 问题也同样影响云计算。DNS 协议和DNS 的实施过程注15 中存在着漏洞，DNS 缓存中毒攻击也十分普遍，这种攻击欺骗DNS 服务器接受错误的信息。虽然很多人认为DNS 缓存中毒攻击在几年前就已经平息，但事实并非如此，这些攻击如今仍然是个大问题，尤其是在云计算领域内。基本的缓存中毒攻击的变体包括重定向目标域名服务器(NS )，将域名服务器记录重定向到其他的目标域，并在真正的域名服务器之前进行响应(称之为动态域名服务器伪造)。

与第三个风险因素相关的最后一个例子是拒绝服务(DoS )攻击和分布式拒绝服务(DDoS )攻击。同样地，虽然DoS/DDoS 攻击并不新颖并且与云计算没有直接的联系，但由于机构网络外部资源使用的增加，在网络层面上这些攻击和云计算的问题对机构的风险也在逐步上升。例如，在亚马逊Web 服务上关于持续DDoS 攻击的消息不断，使得这些服务曾一度中断几小时无法供用户使用注16 。(亚马逊并没有承认其服务中断是由DDoS 攻击所导致。)

然而，当使用基础设施即服务(IaaS )时，DDoS 攻击的风险就不仅仅存在于外部(例如面向互联网)了。通过IaaS 提供商的网络供用户(分散于IaaS 供应商的企业网络)使用的部分中也存在着内部DDoS 攻击。内部(不可路由的)网络是分享的资源，用户可以借此访问其非公众事务(例如Amazon Machine Image，AMI )，并通过提供商对其网络和资源(如物理服务器)进行管理。如果我是个不守规矩的用户，没有任何机制可以阻止我通过访问这个内部网络来查找或者攻击其他用户，抑或攻击IaaS 提供商的基础设施，而且供应商也很可能没有部署任何侦查控制手段，更不用说针对此类攻击向用户预警了。其他用户唯一能做的预防措施只有加固他们的事务(如AMI )，并使用提供商的防火墙功能(如亚马逊Web 服务)增强业务的安全性。

用域替换已建立的网络区域及层面模型

在基础设施即服务(IaaS )和平台即服务(PaaS )中，已有的网络区域及层面不再存在。这些年来，网络安全往往依赖于域进行构建，例如内联网与外联网，开发与生产，为了改善安全隔离网络流量等。这种模式是基于排他性的，只有具有特定角色的个人和系统才可以访问特定的区域。类似地，特定层面内的系统往往只可以访问特定层面。例如，表示层的系统不允许直接与数据库层的系统进行通信，而只能与在应用域内授权的系统进行通信。建立在公共IaaS 和PaaS 上的软件即服务(SaaS )云计算也有类似的特征。然而，在私有IaaS 上建立的公共SaaS (例如Salesforce.com )可按照传统的隔离模式，但通常不与用户分享拓扑信息。

典型的网络区域及层面模式在公共云计算中被“安全组”、“安全域”或者“虚拟数据中心”所取代，新的模式在层与层之间有逻辑隔离，但在精确性以及提供的保护方面不如早先的模式。例如，亚马逊云计算中安全组特性允许你的虚拟机(VM )可以通过虚拟防火墙相互访问，虚拟防火墙具有基于IP 地址(特定的地址或子网)、数据包类型(TCP 、UDP 或者ICMP )以及端口(或者端口范围)进行流量过滤的功能。域名现在广泛应用于各种网络环境中，实现基于DNS 的特定应用命名和寻址的目的。例如Google 的App Engine 基于域名对应用程序进行了逻辑分组，如mytestapp.test.mydomain.com及myprodapp.prod.mydomain.com 。

在网络区域及层面的已有模式中，不仅仅开发系统逻辑上与生产系统在网络层面上相隔离，这两个系统在主机层面上也是物理隔离的(例如它们运行在逻辑分隔的网络域中，且运行于物理隔离的服务器上)。然而在云计算中，这种隔离不复存在。在基于域分割的云计算模型中，只为寻址提供了逻辑隔离。由于测试域和生产域很可能刚好在同一个物理服务器上，于是不再有任何物理隔离的“需要”。此外，早先的逻辑网络隔离也不复存在;现在的测试域和生产域在主机层面上同时运行在相同的物理服务器上，只靠VM 监控(管理程序)实现逻辑隔离。

网络层减灾

基于前面部分对风险因素的讨论，我们可以做些什么以降低这些不断增长的风险因素呢？首先要注意到，网络层面风险的存在与使用哪方面的云计算服务是无关的。因此风险等级的确定并不取决于使用哪种服务，而是取决于你的机构是否打算或者正在使用公共云、私有云还是混合云。虽然有些IaaS 云计算提供虚拟的网络域，这还是无法与内部私有云计算环境相比的，后者可以执行全面的状态监视以及其他网络安全监测。

如果你的机构足够大以至于可以承担私有云计算所需的资源开销，就可以在网络内部使用真正的私有云，那么所面临的风险会大大降低。在某些情况下，位于云计算提供商处的私有云可以帮助你满足安全需求，但这也取决于提供商的能力和成熟度。

你可以通过加密降低安全方面的风险，尤其对传输中的数据进行有效的加密。安全数字水印可以大大增加他人篡改数据的难度，这样就保证了数据的完整性。

云计算在网络层的可用性风险是很难降低的，除非机构在网络拓扑内部使用私有云。即使私有云是在云计算提供商设施内的私有(非共享的)外部网络，在网络层面上也会面临不断增加的风险，公共云则会面临更大的风险。我们在这里先保留些观点。

即使是有丰富资源的大企业在网络层面的基础设施安全上也面临着相当大的挑战。云计算相关风险实际上是不是比当前企业面临的风险要大呢？当在这方面进行比较时，需要考虑现存的私有和公共的外联网，同时也需要把合作伙伴的关系考虑进来。对那些没有丰富资源的大企业，或者是中小企业(SMB )，使用公共云的风险(假定这些企业缺乏建立私有云所需的资源)是否真的高于这些企业目前基础设施中所存在的风险呢？在很多情况下，答案也许是否定的，云计算其实并不会带来更高的风险。

表3-1 列出了在网络层面的安全控制。

表3-1 ：网络层面的安全控制

注意

由于各提供商的监测手段各有不同，用户需要对提供商已提供的功能进行评估。（编选：免费论文下载中心 来源：机械工业出版社）