三、数据保护篇
重视安全
开发人员喜欢“云计算部署后不用去管”的功能；公司希望通过云计算降低基础架构成本；用户则喜欢新的功能能够更迅速地推出。然而，负责信息安全的人员在为如何把应用程序和数据安全地转移到云中而挠头。
IT界孜孜以求的一个目标就是整合身份管理技术和流程；而云计算可能让这个目标晚十年才能实现。
许多公司可能会把目录服务验证扩展到内部环境以外，以处理云中的应用程序、甚至系统；但如果第三方系统的安全受到危及，这种做法会导致验证系统岌岌可危。公司也许可以实施一种新的解决方案，让云基础架构管理与现有的基础架构管理相互独立。但缺点是，必须集成多个身份和访问管理系统。还有一种办法是及时回去、单独管理云，但这缺乏吸引力。
幸好，有些云服务提供商正在竭力解决这个问题。谷歌提供了这项功能：把Google Apps与目前实施的单点登录技术结合起来，从而加强安全、简化管理。一家知名互联网公司部署了边缘验证服务器，让云系统通过轻型目录访问协议（LDAP）进行验证。另一家公司则扩展了基于Web的验证协议，通过Web服务来进行验证；验证通过，即可访问其内部的系统。
数据丢失与备份
数据存储在哪里？谁可以访问？数据安全吗？这些都是重大问题，因为没有几家云服务提供商在处理敏感数据方面证明一向很可靠，许多软件即服务（SaaS）提供商除外。如果数据保存在共享存储系统上，要料到可能面临风险。其实，即使我们放在自己公司内部的数据也面临风险。需要把衡量内部数据效益与风险的同一套措施用于衡量云，然后确定哪些数据可以放到云上、并如何保护。这就需要知道及核实提供商采用的标准以及改动标准的灵活性有多大。
企业使用亚马逊的弹性计算云等服务时，可以在虚拟实例中运行的操作系统、应用程序或数据库管理系统里面采用数据加密。其他服务（如应用托管服务）提供商在开发应用程序时需要更全面的考虑，确保已包括加密等安全措施。
不管自己的数据在哪里，公司都应当防范数据丢失。亚马逊知道计算机会出故障，所以它劝告公司要借助冗余和备份措施作好防范故障的规划。有些云服务提供商提供备份服务或者导出数据的方法，那样公司可以自己备份数据，另一些提供商要求客户使用自定义或第三方的应用程序。
因此，我们不妨牢记下面这些关键因素：
——备份如何进行？有些云服务提供商进行备份，不过更有可能是你想自己进行备份。亚马逊EC2的许多客户还使用亚马逊的简单存储服务（Simple Storage Service，S3）或弹性块存储（Elastic Block Storage）用于存储备份文件。
——备份经得住测试吗？如果服务无法使用，你能访问备份数据吗？
——备份数据将放在哪里？它也许放在云存储系统上、由提供商来托管，或者转到你自己的基础架构。不管怎样，你还是要知道备份数据在存储和传输中，数据得到了怎样的保护。
管理与监测
许多公司的信息安全团队平时经常监测安全漏洞邮件列表、给系统打补丁、改写代码以解决缺陷。在云中，他们相信提供商事先至少对一些方面进行了调查。很少有提供商让客户可以核实自己采取的安全做法，不过有些提供商变得更愿意配合。公司在使用Joyent或亚马逊的EC3等云系统时，可以在操作系统、数据库和应用程序等层面采取安全措施，但他们仍依赖各自的提供商确保网络、存储和虚拟基础架构的安全性。
尽管云服务用户并不控制实际的打补丁和漏洞监测工作，但他们仍有责任管理自己的风险。所以他们要评估哪些资产需要保护、如何防护这些资产，包括在云基础架构上添加安全措施。即使那样，支付卡行业（PCI）标准等行业法规仍可能会让人措手不及，因为PCI委员会方面没有明确规定如何对云服务提供商进行分类。这可能意味着，不同审计人员对待云服务提供商的标准会略有不同。
云服务客户必须要求保证自己可监测谁在访问自己的数据。如果公司要求提供详细的审计跟踪记录，应当采用数据加密；或者只把所处理数据不是特别敏感的应用程序交给云服务提供商。
这个方面可能会迅速得到改进。谷歌近期表示，Google Apps的安全流程已通过了SAS 70 Type II审计标准。预计会听到更多的提供商宣称自己的安全标准，因为安全仍是导致公司不敢把应用程序转移到云中的一大障碍因素。
当然，内部信息安全团队不应该坐等提供商来加强安全。从桌面应用程序到服务器托管的各个应用领域，云计算都会变得越来越诱人。需要更高安全级别的应用程序，比如与《健康保险可携性及责任性法案》（HIPAA）或PCI相关的应用程序，可能在云中更难得到保证，因而放在公司内部比较妥当。社区应用程序和内容网站比较适合放在云中。公司的技术团队必须确定把什么数据放在云中不会有问题，但他们也要明白：云最终会是整个基础架构的一部分；还得要自己弄清楚如何把企业系统与云基础架构安全连接起来。
