2011年4月，亚马逊公司位于北弗吉尼亚州的云计算中心宕机，这导致使用亚马逊服务的回答服务Quora、新闻服务Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到了影响。此次中断持续将近4天。为此亚马逊为宕机事件向用户发表了5700多字的道歉信，并且为受到影响的用户提供10天服务的点数。

　　2011年3月，谷歌邮箱爆发大规模的用户数据泄漏事件，大约有15万Gmail用户在周日早上发现自己的所有邮件和聊天记录被删除，部分用户发现自己的帐户被重置，谷歌表示受到该问题影响的用户约为用户总数的0.08%.

　　2010年9月，微软在美国西部几周时间内出现至少三次托管服务中断事件向用户致歉，此次事件让考虑使用与Office套装软件捆绑在一起的微软主要云计算产品Office 365的那些用户深感担忧。

　　2010年6月，Intuit的在线记账和开发服务经历了大崩溃，包括Intuit自身主页在内的线上产品在内近两天内都处于瘫痪状态。

　　2010年3月，使用VMware提供公共云服务的Terremark发生了七小时的宕机事件，让许多客户开始怀疑其企业级的vCloud Express服务。

　　2010年1月，6万8千名的Salesforce.com用户经历了至少1个小时的宕机。

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

　　云计算的昨日今朝

　　这两年炒得沸沸扬扬的云计算从本质上讲并非什么新鲜事物，早在上世纪90年代就有人提出的网格计算的思想，考虑充分利用空闲的CPU资源，搭建平行分布式计算。(只是这位“先烈”现今已被做传统中间件的公司收购了。)而在1999年，一项利用全球联网的计算机共同搜寻地外文明的科学实验计划SETI@home成功的将网格计算的思想付诸实施，通过传统的IP网络构建了一个小型的云环境。当用户参与SETI@home项目，那其计算机中的相关信息比如处理器的型号、内存的大小等会被 SETI@home 记录下来，以用来决定什么样的计算任务最适合该计算机。

　　从应用角度讲，在线邮件服务、搜索引擎、即时通讯、在线电影等广受熟知的各类在线软件即服务软件都可以看作是某种形式上的云服务。

　　因此，现今众说纷纭的云计算只是将以往非核心的、个人用户使用的各类SaaS应用架构方式，来部署核心关键的、企业级用户的各种应用，以实现集中化部署的种种好处，比如提升资源利用率，节能减排等等。

　　传统IT架构向云架构的迁移和供电系统的发展非常相像。自爱迪生发明灯泡之后，其一直坚持使用直流电输送电力(由于直流电的传输距离不能超过1公里，这样就需要许多小型的供电系统，而爱迪生的电力照明公司正是提供这类供电系统的)，这种大范围，小规模的供电系统正是设备供应商所最希望看到的;而伟大的尼古拉·特斯拉所发明的交流电则可以实现大规模集中式供电，按需付费的模式所带来的巨大变革使得那些没有经济实力建立小规模供电系统的区域也能够使用电力。

　　不过任何事物所都具备的两面性在这点上也完全适用。集中式的运算(或供电)模式较会给安全性和可用性两方面带来较严重的问题：

　　安全性方面的问题：应用公共设施意味着将一扇额外的门户开放，这可能使得原本在传统架构中很易于实现的安全策略在云环境下变得具有风险性。应用公共计算和存储资源的意味着将一部分数据信息提交到自身无法掌控的位置进行计算和存储，而你无法确保这些信息是否会在未经授权的情况下被复制盗取。

　　可用性方面的问题：原本可以自身掌控的可用性等级，包括响应时间、服务在线时间等，在云服务中可能不一定能完全保证。虽然大部分云供应商会提供华丽的服务水平承诺(SLA)，但经过了上述风险事故之后，恐怕很少会有用户对其完全采信。此外，烟囱式架构(相对于云架构而言的独立系统)可以做到完全物理级别的故障隔离，而这在云环境下是无法想象的。换句话说，你的系统可能会受到其他系统故障的连带影响。

　　公有云

　　早在2010年末，笔者即在美国着名IT技术媒体TechTarget上提出，国内公有云在3年内的主要发展对象集中在个人用户以及中小型企业的非核心应用上，诸如个人邮件，在线OA、数据归档备份等。

　　向云环境迁移需要一个漫长的过程。在这一过程中，需要企业对自身的各类系统、应用和数据进行周密地分析归类。一般来说，关键业务的核心数据仍应当保留在传统的烟囱式体系架构之中，并且配以高可用的业务连续性手段确保可以接受的RTO(回复时间目标)和RPO(回复点目标)。对于归档或合规遵从类信息，可以考虑逐步向混合云的部署方式迁移，并在接口处配以安全网关作为安全防护和信息的本地缓存，利用公有云线性扩展、按需付费的模式将原本在固定IT设备上的投资转变为可以预估的运营成本。

　　当然，安全仍是公有云在接受过程中最大的挑战，在一项针对IT专业人士进行的云计算跟踪民意调查中显示，妨碍云计算应用的技术难点在于如何确保云端数据的安全性，并降低数据传输过程中的延迟问题。即使放在公司内部的数据也面临风险，在共享存储中面临最大的风险是数据丢失/泄漏，在虚拟存储环境中面临最大的风险是存取权限、数据备份和销毁。需要从数据隔离、数据加密、第三方实名认证、灵活转移、安全清除、完整备份、时限恢复、行为审计、外围防护等方面综合考虑解决云存储安全问题。

　　目前数据安全性的问题通过存储虚拟网关实现，(亦称远程备份装置，Remote Backup Appliance)提供加密的备份服务，以及实现故障切换、动态扩容、负载均衡、自动精简配置等高级功能，此外存储虚拟网关还可以作为数据缓冲池，将生产环境中频繁使用到的数据保存在其中，减少从云端站点存取数据所造成的延迟。目前这类产品的主流厂商有CommVault、Symantec、EMC、ETIM,以及Brocade等。

　　此外，针对法规安全，目前所有的云服务供应商都没有一致的解决方案。因为在电子证据发现方面，用户和云提供商必须对对方的角色和责任有共同的认识，包括诉讼保留、发现搜索、专家证词提供方等。云服务供应商现阶段很难提供真实可靠的数据，以保证他们的信息安全系统可以响应客户的要求，比如类似元数据和日志文件的主要信息。云服务供应商保存的数据需要接受与在数据所有者处保存时同样级别的监管。提前计划好相关意料内和意料外关系终止后的合同协商事宜，并有序地恢复或处置资产的安全。

      私有云

　　许多人认为私有云是解决云技术落地过程中解决安全等各类问题的有效途径。私有云和公有云类似，但是是将企业传统的IT资源集中起来统一管理和备份;私有云的核心是虚拟化技术，将所有物理机和物理存储的资源打散，从而提升整体系统的使用效率。

　　私有云从整体架构上来说和传统的IT环境并没有实质性的区别，所以从安全的角度来看，私有云同样面临着传统IT环境中面临的各类安全问题，以往的数据安全、网络安全和应用安全在私有云环境中同样存在。不过由于其资源是集中部署的，在管理和部署安全策略方面有一定的优势，比以往分散管控要容易许多。

　　但是私有云也由于其体系架构的特殊性，会造成的额外的风险。如何保护私有云中集中式数据的安全性就是一个问题。对于希望非法获取企业数据的“窃取者”,集中式的数据存放方式让其只要攻破一点就能获取到全部数据，而且集中式的数据存放使得企业系统管理员具备超常的权限，只要愿意，管理员可以很轻易地检索并获取到想要的任何数据。

　　索性的是目前已经有一些领先的国内外厂商致力于该领域的解决方案。这类产品通过加密存储(且加密算法可以替代为第三方算法)，加密传输--确保数据在存储过程中的安全性，多级授权认证--防止系统管理员可以获取全部数据，日志审计--记录所有的登陆，操作日志，对集中存放的信息数据进行全方位的加密保护。

　　此类解决方案在部署过程中还需考虑到云环境下，对整体系统性能和稳定性的要求。一般至少要能够支持Scale Out(横向扩展)的扩展模式，并且在高并发环境下表现出稳定的性能曲线。

　　较之于传统的烟囱式架构，私有云中虚拟计算资源的同样面临着更大的安全性风险。在传统IT体系架构中，一台服务器或一个集群中只会运行有限的数个系统，换句话说，即便是整台服务器或整个集群同时断电宕机，所影响的也是有限的数个应用，而企业IT系统中的其它应用仍可以正常运行。但在云环境下则完全不同，一台服务器的物理故障可能会引起其上加载的诸多应用的故障迁移，而如果相应的迁移策略出现问题，引起“脑分裂”现象，很容易大面积地影响整个云环境上的应用。

　　在云环境下，一般从以下几个角度考虑云计算环境下虚拟机的安全问题：

　　各虚拟主机的安全策略

　　在虚拟基础设施中运行虚拟安全网关

　　加强对非法及恶意的虚拟机流量监视

　　向云环境迁移需要一个漫长的过程

　　从上文中我们可以得出这样的结论，向云环境迁移需要一个漫长的过程。要对整个IT系统和业务环境进行分级，从重要性和可用性两方面依次考虑是否采用私有云、混合云或公有云。并通过部署安全策略确保主机端和数据端的安全性，这种安全性级别要求远超过以往传统的IT架构。对用户来说，抱着那种希望通过采用部署某种系统，然后在第二天看到一个全新的基于云架构的IT环境的想法无异于天方夜谭。

　　同时，无论是采用公有云、私有云或者是混合云的部署方式。如何对计算、存储和安全策略进行统一监控，并通过灵活的调度方式对各类资源进行统一管理可以大大降低向云环境迁移过程中可能存在的风险。目前部分国内外一线厂商已经开始提供这种统一化的用户界面。