云计算环境下如何确保数据安全性(3)

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监控(管理程序)实现逻辑隔离。(责任编辑：admin)