英雄难过“安全”关 盘点云计算安全事故

自古英雄难过美人关。英雄的卓越功勋在世人眼中是有目共睹的，但是惟独过不了“美人”这一关。而如今，与此类似，谷歌、亚马逊以及微软这样的国际IT巨头，一度是何等的威武，但是在面对云计算“安全”这一关，也显得有些束手无策。从云计算服务诞生的那一天起，频频爆出一些安全事件，让用户本来就有些狐疑的心更加不安了。

就在上个月，云计算服务提供商Amazon(亚马逊)公司爆出了史前最大的宕机事件。4月21日凌晨，亚马逊公司在北弗吉尼亚州的云计算中心宕机，这导致包括回答服务Quora、新闻服务Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到了影响。

这些网站都依靠亚马逊的这个云计算中心提供服务。Quora网站周四上午和下午在英国都无法访问。这个网站完全由亚马逊的EC2(弹性云计算)服务托管，就像FourSquare和许多其它网站一样。

受到影响，Hootsuite网站的响应速度很慢，而Reddit网站的搜索服务不能使用。Reddit网站称，亚马逊目前正出现服务下降的情况。亚马逊云服务中断持续将近4天，截止编者发稿时，Hootsuite、Reddit、FourSquare、Quora等网站已经基本恢复正常。

根据分析，亚马逊的云计算状态网页目前显示故障发生在北弗吉尼亚州的云计算中心。这个中心为许多Web 2.0公司提供服务。这次宕机故障发生在美国西海岸的大约凌晨1点40分，英国夏令时上午9点40分，并且从那时起一直有故障。

分析人士称，北弗吉尼亚州云计算中心是亚马逊经营的许多云计算中心之一，按照常规，系统的设计之处应用会考虑，一个中心宕机不会中断其它的云计算中心，也不会影响使用那个服务的用户。

此次，亚马逊云计算中心没有绕过北弗吉尼亚州云计算中心的故障把工作量转移到许多其它的云计算中心，令人生疑。服务器宕机，这在人们预想当中，没有那么严重。最简单的，双机热备，一台服务器宕机，另外一台服务器在短时间内可以启动，并不会影响用户的服务。但是，亚马逊的云计算中心这次不同，宕机影响了这么多用户的正常云服务，而且引起用户服务中断的，还是亚马逊引以为傲的弹性云，这对于云计算服务商刚刚建立起来的信任，绝对是一次沉重的打击。

经过一番紧急的抢救，亚马逊的云服务恢复了正常。但是，这个事件留给用户的恶劣影响有些深远，用户大呼“伤不起”。

好在亚马逊的态度还算坦诚。4月30日，亚马逊为宕机事件向用户发表了5700多字的道歉信，声称亚马逊公司已经知道漏洞和设计缺陷所在的地方，它希望通过修复那些漏洞和缺陷提高EC2(亚马逊ElasticComputeCloud服务)的竞争力。亚马逊已经对EC2做了一些修复和调整，并打算在未来几周里扩大部署，以便对所有的服务进行改善，避免类似的事件再度出现。

在赔偿方面，亚马逊表示，将向在此次故障中受到影响的用户提供10天服务的点数(Credit)，这些点数将自动充值到受影响的用户帐号当中。但是，对于以后如何避免出现类似事件，并没有提到任何法律上的保证。

据了解，亚马逊云服务中断持续了近4天，但是在法律上却没有违反亚马逊EC2服务的服务等级协议(简称SLA)。亚马逊的解释是，亚马逊出现故障的是EBS和RDS服务，而不是EC2服务，从法律上讲，它并没有违反服务等级协议。并且，对于亚马逊提出的应对宕机事件的建议——多点备份，仅仅是一个技术规范并非合同保障。这些，似乎都不能给云服务的用户带来信心。

表面看来，亚马逊宕机事件似乎有一个完美结局：厂商及时修复漏洞，书面道歉，赔偿损失。但是，用户心理上对云服务的恐惧似乎并不那么容易康复，未来，亚马逊可能不仅仅要在技术上、还需要在制度和法律上给予用户更多的保证，才能才能渐渐修复被此次宕机事件损坏的名声。

历数频频发生的云服务事件

不仅亚马逊，云计算领域充满竞争的其他公司，如谷歌和微软等，在近几年也频频发生云服务“中断”事件。

事件一：Google Gmail邮箱爆发全球性故障

Gmail是Google在2004年愚人节推出的免费邮件服务，但是自从推出这项服务以来，时有发生的“中断”事件就成为业界的广泛讨论的话题。

2009年2月24日，谷歌的Gmail电子邮箱爆发全球性故障，服务中断时间长达4小时。谷歌解释事故的原因：在位于欧洲的数据中心例行性维护之时，有些新的程序代码(会试图把地理相近的数据集中于所有人身上)有些副作用，导致欧洲另一个资料中心过载，于是连锁效应就扩及到其它数据中心接口，最终酿成全球性的断线，导致其他数据中心也无法正常工作。

事件过去数日之后，Google宣布针对这一事件，谷歌向企业、政府机构和其他付费GoogleAppsPremier Edition客户提供15天免费服务，补偿服务中断给客户造成的损失，每人合计2.05美元。

事件二：微软的云计算平台Azure停止运行。

2009年3月17日，微软的云计算平台Azure停止运行约22个小时。

虽然，微软没有给出详细的故障原因，但有业内人士分析，Azure平台的这次宕机与其中心处理和存储设备故障有关。Azure平台的宕机可能引发微软客户对该云计算机服务平台的安全担忧，也暴露了云计算的一个巨大隐患。

不过，当时的Azure尚处于“预测试”阶段，所以出现一些类似问题也是可接受。提前暴露的安全问题，似乎也给微软的Azure团队敲了一次警钟，在云计算平台上，安全是客户最看重的环节。

2010年，Azure平台正式投入商用，成为开发者喜爱的云平台之一。

事件三：Rackspace云服务中断。

2009年6月，Rackspace遭受了严重的云服务中断故障。供电设备跳闸，备份发电机失效，不少机架上服务器停机。这场事故造成了严重的后果。

为了挽回公司声誉，Rackspace更新了所有博客，并在其中详细讨论了整个经过。但用户并不乐意接受。

同年11月，Rackspace再次发生重大的服务中断后。事实上，它的用户是完全有机会在服务中断后公开指责这位供应商的，但用户却表示“该事故并不是什么大事。”看来Rackspace不是走好运，而是持续提供了充足更新并快速修复了这些错误。

在服务中断致使其业务脱机15到20分钟后，博客服务提供商Posterous的创建者之一Sachin Agarwal就发表了自己的观点。Agarwal对此并不生气，相反，他表示Rackspace在这件事上做得“很透明”，处理问题也很及时到位。

看来，如果没有严重数据的丢失，并且服务快速恢复，用户依旧保持愉快的使用体验。对于所谓的“100%正常运行”，大多数用户似乎不会因为偶尔的小事故而放弃供应商，只是不要将问题堆积起来。(责任编辑：admin)