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

　　与第一个风险因素相关的例子是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”(http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html )。在亚马逊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 地址再使用的问题，但除非云计算提供商把这些产品作为服务提供给用户，否则用户将不得不寻求第三方的产品并支付费用，以解决由云计算提供商所带来的问题。