向云环境迁移过程中的数据安全性问题
中关村在线 12年03月05日 16:20 【转载】 作者：TT存储 责任编辑：周晓丽
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)，但经过了上述风险事故之后，恐怕很少会有用户对其完全采信。此外，烟囱式架构(相对于云架构而言的独立系统)可以做到完全物理级别的故障隔离，而这在云环境下是无法想象的。换句话说，你的系统可能会受到其他系统故障的连带影响。
腾讯微博
新浪微博
