大数据时代，云数据隐私如何保护

大量数据背后隐藏着大量的经济与政治利益，尤其是通过数据整合、分析与挖掘，其所表现出的数据整合与控制力量已经远超以往。大数据如同一把双刃剑，社会因大数据使用而获益匪浅，但个人隐私也无处遁形。近年来侵犯个人隐私案件时有发生，如谷歌泄露个人隐私事件、盛大云数据丢失事件、2011年韩国三大门户网站之一Nate和社交网络“赛我网”遭到黑客攻击，致使3500万用户信息泄露等事件，这些严重侵犯了用户的合法权益。世界经济论坛的一份报告中强调要通过使用高科技手段保护人们的隐私，通过对云平台的隐私保护手段的多项案例研究，志欣合众公司总结以下几种技术平台的隐私保护手段：1、云平台常见的隐私保护手段（1）无菌隔离“无菌隔离”主要用于多组人、批量性数据流转与处理。此手段如同生物隔离室，可运用机械手、远程方式进行操作，但并不会直接接触到事物本身。引申至云平台，操作员在下达命令时应采用通过已测试验证、安全有效的操作工具（或管理系统）对数据进行操作与管理，数据在各系统或子系统中流转应该是“无菌隔离”的，人员无法直接接触到原数据，数据流转是系统对系统，最终数据输出至使用部门。案例：某省移动云平台，建立数据集市系统应对数据安全，数据流转采用操作人员下达指令方式推送，各子系统接收集市平台推送的数据，全程数据“无污染”。（2）黑白盒策略通过无菌隔离得到数据后，最终操作、分析数据的业务人员应是不知道实现的机制与原理，数据已按预定义的行为操作进行了剥离，通常业务人员权限不高，剥离数据的限制较高参与。案例：某电商网站在双十一活动结束后，数据无菌隔离进入分析系统，业务操作人员基于黑白盒策略只能操作剥离下来的部份数据进行数据汇总分析，结果形成汇总统计而不会泄露用户隐私信息。（3）信息域管理信息域是被管理信息的集合，它被安排满足下列组织要求：按若干个功能用途（或方针）诸如按安全、计费、故障管理等划分环境，或者按每一个用途诸如按地理、技术或组织结构划分环境。不同的信息域存储的内容不一样，不同的信息域安全级别不同，不同的信息域要求的授权不一致，不同的信息域所针对的业务也不相同。案例：某游戏系统需划分成多个信息域，用户账户信息域、游戏服务器信息域、经济系统信息域、道具信息域等，各信息域可轻耦合，也可无不关联，每信息域的进入门槛与权限系统也各不相同。（4）信息片段管理若干个信息片段组成一个信息域，这些片断基本是服务于一个业务。案例：以用户账户信息域为例，用于账户认证与账户相关资料的应保存于不同的信息域中，成为多个信息片断。隐私保护的手段与级别示意图： 2、云数据管理隐私保护具备的特征云平台的隐私保护手段保证了云数据的安全性，志欣合众公司技术总监张晓康指出，云数据管理的隐私保护具有三个特征：（1）云数据管理不允许超级管理员存在云数据管理需在制度上与技术平台上屏蔽超级管理员的存在，能力越强，责任越大，不是每个人都具备承担超级管理员的特质，且该角色的存在理论上就存在极大风险。（2）数据安全才不会泄露隐私数据安全意指通过一些技术或者非技术的方式来保证数据的访问是受到合理控制，并保证数据不被人为或者意外的损坏而泄露或更改。从非技术角度上来看，可以通过法律或者一些规章制度来保证数据的安全性；从技术的角度上来看，可以通过防火墙、入侵检测、安全配置、数据加密、访问认证、权限控制、数据备份等手段来保证数据的安全性。对于任何一个IT系统来说，在运行生命周期过程中使用的和生产的数据都是整个系统的核心部分。我们一般把这些系统数据分为公有数据和私有数据两种类型。公有数据代表可以从公共资源获得的数据信息，例如股票信息、公开的财务信息等，这类数据可以被任何一个IT系统获得并使用。而私有数据则代表这些数据是被IT系统所独占并无法和其它IT系统所共享的信息。对于公有数据，使用它们的IT系统并不需要处理安全相关的事务，然而对于私有数据特别是一些较为敏感的私有数据，在构建IT系统时需要专门考虑如何保证数据不被盗用甚至修改。传统的IT系统通常搭建在客户自身的数据中心内，数据中心的内部防火墙保证了系统数据的安全性。和传统软件相比，云计算在数据方面的最大不同便是所有的数据将由第三方而非第一方来负责维护，并且由于云计算架构的特点，这些数据可能被存储在非常分散的地方，并且都按照明文的方式进行存储。尽管防火墙能够对恶意的外来攻击提供一定程度的保护，但这种架构使得一些关键性的数据可能被泄露，无论是偶然还是恶意。例如，由于开发和维护的需要，软件提供商的员工一般都能够访问存储在云平台上的数据，一旦这些员工信息被非法获得，黑客便可以在万维网上访问部署在云平台上的程序或者得到关键性的数据。这对于对安全性有较高要求的企业应用来说是完全不能接受的。3、开发者和管理者分离程序开发者与实际管理人员分离，开发者不能掌控生产系统管理权限，管理人员不明白系统架构与运作机理，只能通过已测试并经授权的管理界面进行操作。如何保障云数据的安全性志欣合众通过对云数据安全的相关技术深入研究，总结需使用两步法来保证云数据的安全：第一步：身份认证。身份认证如同锁与钥匙的关系，有三个方面需要注意。首先是密码，每个网站都有自己的账户和密码，理想状态是每个网站中每个用户的不可逆加密密码都是唯一的，同网站中当一个账户被破解后，其它账户是安全的。不能设定相同密码，因用户密码相同而降低其它账户的安全性。接下来是双重身份认证，即需要通过两种模式登录网站，不仅需要用户名和密码，还需要一个动态口令，如通过短信形式发送到手机上，只有输入正确的用户名、密码以及动态口令才能登录，这样为账户又增加了一道锁。最后注意的是登录的终端，一般情况下我们通过自己的设备进行数据操作，但有时也会在非自己的设备上进行登录操作，其它设备通过浏览器进行信息保存时，很容易造成信息泄露，因此需要使用隐私模式操作或操作完成之后进行数据清理。第二步：平台环境。平台环境的安全如同银行的金库系统，涉及四个层次：第一：通讯安全。如同银行的金库系统，别人能不能进入银行金库。首先需有一个信息安全通道，在技术上需采用数字认证与高强度流加密算法保证通道安全，不能被截获；第二：平台系统安全。如同银行的保险柜好不好，平台系统由硬软件组成。硬件层面要确保稳定；软件平台在操作系统层面需时刻检查系统本身有没有漏洞，进行漏洞扫描，打补丁，防范风险的发生；应用软件层面需防止后门存在，加强测试；第三：加密系统安全。如同银行保险柜加密锁够不够好，加密系统够不够安全，系统中各出入口、各项敏感数据均需进行加密存储，即便被黑拿到数据也无法被破解成明文；第四：防止扩散。确保发生安全事故后损失不会扩大，即使有一部份数据泄露了，也不会对整体造成影响。

断网类型一：系统故障

典型事件1：亚马逊AWS平安夜断网

故障原因：弹性负载均衡服务故障

2012年12月24日，刚刚过去的圣诞节平安夜，亚马逊并没有让他们的客户过得太平安。亚马逊AWS位于美国东部1区的数据中心发生故障，其弹性负载均衡服务(Elastic Load Balancing Service)中断，导致Netflix和Heroku等网站受到影响。其中，Heroku在之前的AWS美国东部区域服务故障中也受到过影响。不过，有些巧合的事情是Netflix的竞争对手，亚马逊自己的业务Amazon Prime Instant Video并未因为这个故障而受到影响。

12月24日，亚马逊AWS中断服务事件不是第一次，当然也绝非最后一次。

2012年10月22日，亚马逊位于北维吉尼亚的网络服务AWS也中断过一次。其原因与上次相似。事故影响了包括Reddit、Pinterest等知名大网站。中断影响了弹性魔豆服务，其后是弹性魔豆服务的控制台，关系数据库服务，弹性缓存，弹性计算云EC2，以及云搜索。这次事故让很多人认为，亚马逊是应该升级其北维尼吉亚数据中心的基础设施了。

2011年4月22日，亚马逊云数据中心服务器大面积宕机，这一事件被认为是亚马逊史上最为严重的云计算安全事件。由于亚马逊在北弗吉尼亚州的云计算中心宕机，包括回答服务Quora、新闻服务Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到了影响。亚马逊官方报告中声称，此次事件是由于其EC2系统设计存在漏洞和设计缺陷，并且在不断修复这些已知的漏洞和缺陷来提高EC2(亚马逊ElasticComputeCloud服务)的竞争力。

2010年1月，几乎6万8千名的Salesforce.com用户经历了至少1个小时的宕机。Salesforce.com由于自身数据中心的"系统性错误"，包括备份在内的全部服务发生了短暂瘫痪的情况。这也露出了Salesforce.com不愿公开的锁定策略：旗下的PaaS平台、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出现问题，Force.com同样会出现问题。所以服务发生较长时间中断，问题将变得很棘手。

断网诱因二：自然灾害

典型事件1：亚马逊北爱尔兰柏林数据中心宕机

故障原因：闪电击中柏林数据中心的变压器

2011年8月6日，在北爱尔兰都柏林出现的闪电引起亚马逊和微软在欧洲的云计算网络因为数据中心停电而出现大规模宕机。闪电击中都柏林数据中心附近的变压器，导致其爆炸。爆炸引发火灾，使所有公用服务机构的工作暂时陷入中断，导致整个数据中心出现宕机。

这个数据中心是亚马逊在欧洲唯一的数据存储地，也就是说，EC2云计算平台客户在事故期间没有其他数据中心可供临时使用。宕机事件使得采用亚马逊EC2云服务平台的多家网站长中断达两天时间之久。

典型事件2：卡尔加里数据中心火灾事故

故障原因：数据中心发生火灾

2012年7月11日卡尔加里数据中心火灾事故：加拿大通信服务供应商ShawCommunicationsInc位于卡尔加里阿尔伯塔的数据中心发生了一场火灾，造成当地医院的数百个手术延迟。由于该数据中心提供管理应急服务，此次火灾事件影响了支持关键公共服务主要的备份系统。此次事件为一系列政府机构敲响了警钟，必须确保及时的恢复和拥有故障转移系统，同时结合出台灾害管理计划。

典型事件3：超级飓风桑迪袭击数据中心

故障原因：风暴和洪水导致数据中心停止运行

2012年10月29日，超级飓风桑迪：纽约和新泽西州的数据中心都受到了此次飓风的影响，所带来的恶劣影响包括为曼哈顿下城地区的洪水和一些设施的停机，周围地区数据中心发电机运行失常。飓风桑迪所带来的影响超出了一般单一的中断事故，为受灾地区数据中心产业带来了规模空前的灾难。事实上，柴油已然成为了数据中心恢复工作的生命线，作为备用电源系统接管了整个地区的负荷，促使特别措施，保持发电机的燃料。随着眼前的工作重点逐步转移到灾后重建，我们有必要长期就数据中心的选址、工程和灾难恢复进行探讨，这一话题可能将持续几个月，甚至几年。

断网诱因三：人为因素

典型事件1：Hosting.com服务中断事故

故障原因：服务供应商执行断路器操作顺序不正确造成的UPS关闭

2012年7月28日Hosting.com停运事件：人为错误通常被认为是数据中心停机的主导因素之一。7月Hosting.com中断事件造成 1100名客户服务中断就是一个例子。停机事故的发生是由于该公司位于特拉华州纽瓦克的数据中心正进行UPS系统预防性维护，"服务供应商执行断路器操作顺序不正确造成的UPS关闭是造成数据中心套房内的设施损失的关键因素之一。"Hosting.com首席执行官ArtZeile说。"没有任何重要的电力系统或备用电源系统出现故障，完全是一种人为的错误造成的。"

典型事件2：微软爆发BPOS服务中断事件

故障原因：微软在美国、欧洲和亚洲的数据中心的一个没有确定的设置错误造成的

2010年9月，微软在美国西部几周时间内出现至少三次托管服务中断事件向用户致歉。这是微软首次爆出重大的云计算事件。

事故当时，用户访问BPOS(Business Productivity Online Suite)服务的时候，如果使用微软北美设施访问服务的客户可能遇到了问题，这个故障持续了两个小时。虽然，后来微软工程师声称解决了这一问题，但是没有解决根本问题，因而又产生了9月3日和9月7日服务再次中断。

微软的Clint Patterson说，这次数据突破事件是由于微软在美国、欧洲和亚洲的数据中心的一个没有确定的设置错误造成的。BPOS软件中的离线地址簿在"非常特别的情况下"提供给了非授权用户。这个地址簿包含企业的联络人信息。

微软称，这个错误在发现之后两个小时就修复了。微软称，它拥有跟踪设施，使它能够与那些错误地下载这些数据的人取得联系以便清除这些数据。

断网诱因四：系统故障

典型事件1：GoDaddy网站DNS服务器中断

故障原因：系统内一系列路由器的数据表造成的网络中断

2012年9月10日GoDaddy网站DNS服务器中断：域名巨头GoDaddy是一家最重要的DNS服务器供应商，其拥有500万个网站，管理超过5000万的域名。这就是为什么九月10日中断事故会是一个2012年最具破坏性的事件。

一些炒作甚至认为，此次长达6个小时的中断事件是由于拒绝服务攻击的结果，但GoDaddy后来表示，这是路由器表的损坏数据造成的。"服务中断不是由外部影响造成的。"GoDaddy的临时首席执行官史葛瓦格纳说。"这不是黑客攻击也不是一个拒绝服务攻击(DDoS)。我们已经确定了服务中断是由于内部的一系列路由器的数据表造成的网络事件损坏。"

典型事件2：盛大云存储断网

故障原因：数据中心一台物理服务器磁盘损坏

2012年8月6日晚上8：10，盛大云在其官方微博上发布一则因云主机故障致用户数据丢失事件的公开声明。声明说到：8月6日，盛大云在无锡的数据中心因为一台物理服务器磁盘发生损坏，导致"个别用户"数据的丢失。盛大云已经在尽全力协助用户恢复数据。

对于因为一台"物理服务器磁盘发生损坏"，导致"个别用户"数据的丢失的情况，盛大云技术人员给出自己的解释：虚拟机的磁盘有两种生产方式，一种是直接使用宿主机的物理磁盘。这种情况下，如果宿主机的物理磁盘发生故障，云主机不可避免会造成数据丢失，这也是本次事件产生的原因另外一种是使用远程存储，也就是盛大硬盘产品，这种方式实际上是把用户的数据存到了远程的一个集群里，并同时做了多份备份，即使宿主机出故障也不会影响到云主机的数据。因为物理机的损坏很难避免，为了避免您遇到意外损失，我们建议您在云主机之外，也做好数据备份。

典型事件3：Google App Engine中断服务

故障原因：网络延迟

Google App Engine：GAE是用于开发和托管WEB应用程序的平台，数据中心由google管理，中断时间是10月26日，持续4小时，因为突然变得反应缓慢，而且出错。受此影响，50%的GAE请求均失败。

谷歌表示没有数据丢失，应用程序行为也有备份可以还原。为表歉意，google宣布11月份用户可以google表示他们正在加强其网络服务以应对网络延迟问题，"我们已经增强了流量路由能力，并调整了配置，这些将会有效防止此类问题再次发生"。

断网诱因五：系统Bug

典型事件1：Azure全球中断服务

事故原因：软件Bug导致闰年时间计算不正确

2012年2月28日，由于"闰年bug"导致微软Azure在全球范围内大面积服务中断，中断时间超过24小时。虽然微软表示该软件BUG是由于闰年时间计算不正确导致，但这一事件激起了许多用户的强烈反应，许多人要求微软为此做出更合理详细的解释。

典型事件2：Gmail电子邮箱爆发全球性故障

事故原因：数据中心例行性维护时，新程序代码的副作用

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

典型事件3：“5.19断网事件”

事故原因：客户端软件Bug，上网终端频繁发起域名解析请求，引发DNS拥塞

2009年5月19日的21：50，江苏、安徽、广西、海南、甘肃、浙江等六省用户申告访问网站速度变慢或无法访问。经过工信部相关单位调查通报称，此次全国六省网络中断事故，原因是国内某公司推出的客户端软件存在缺陷，在该公司域名授权服务器工作异常的情况下，导致安装该软件的上网终端频繁发起域名解析请求，引发DNS拥塞，造成大量用户访问网站慢或网页打不开。

其中，DN SPod是国内知名的域名解析服务商之一的N SPod公司，服务数家知名网站的域名解析服务。此次攻击导致DN SPod公司所属的6台dns域名解析服务器瘫痪，直接造成包括暴风影音在内的多家网络服务商的域名解析系统瘫痪，由此引发网络拥塞，造成大量用户不能正常上网。 工信部指出，此次事件暴露出域名解析服务成为目前网络安全的薄弱环节，指示各单位要加强对域名解析服务的安全保护。

小结

启用云服务的公司，很大程度是考虑这种服务可以更加编辑，性价比高。但是，这样的考虑如果是以降低安全性作为代价，估计很多公司老大不会同意。层出不穷的云服务断网事件引起了云端安全性的担忧。

目前来看，解决的办法可以从几个角度出发，对于企业级客户来说，务必在采用云服务的同时定期备份云端的数据，拥有第二套解决方案按，以备不时之需。而对于云服务提供商来说，既然各种断网事件是在所难免的，那就必须思考一个对策，将自己用户的损失降到最低，对断网事件的响应效率要提高。

政府部门则具有监督和提醒的职责，云服务相关的法律法律要相继出台和不断完善，并且提醒用户百分之百可靠的云计算服务目前还不存在。

在这里说不清楚，简要说就是 万网、阿里云、盛大云这些是国内目前技术比较成熟价格和系统稳定性也不好说（容易被人攻击）。 linkcloud只是小公司，不足以称道。

万网仅支持按年付费，阿里支持按月/年付费，盛大云和太平洋电信臻云支持按小时/月/年付费，相对之下，太平洋电信臻云和盛大云较灵活。

我用的是太平洋电信臻云主机

简单易用、节约成本、安全快速，南北互联BGP机房，

保证全国各地可直接访问，千兆骨干，10M独享，拥有正版的操作系统。

真正是为游戏用户度身定做的。

---