导读：让你在云中的数据更加安全是至关重要的。我们将会为您讲述作为一个云提供商你应该怎样保护你的数据。
数据的隐私性和安全性是许多想要迁移到公有云的人的主要顾虑。对于隔离真正的危险，和如何让他们摆脱在违反内部规定迁移数据过程中的自然的心理反应来说，这一点很重要。
我们发现，在云中的数据存储可以划分成三个不同的领域：保持数据的隐私性/安全性，提供商透明度，以及数据的可移植性。
为了搞清楚和云中的数据有关的问题，每个领域都是至关重要的。这三个方面必须都得到使用云的客户的认可才可以，这样才能形成有意义的数据处理策略来适应每个云用户的特殊需要。
在云中的数据泄露：真正的危险
从根本上来说，当迁移到公有云的时候，对于客户和他们的数据来说，有两大改变。首先，相对于客户的地理位置来说，数据会被远程存储；这可能会引起法律方面的问题（稍后，我们会进一步说明这方面的问题）。其次，数据通常是从单租户环境迁移到多租户环境的，这就是数据泄露问题发生的源头。
数据泄露只不过是一个客户到另一个客户的数据迁移而已。实际上在云中的每个客户都应该只能访问他们自己的数据，而不能访问其他客户的数据。在《Security in a Public IaaS Cloud Part 1: Networking》（关于这篇文章，具体可以参考：http://www.cloudsigma.com/en/blog/2010/09/13/10-security-in-a-public-iaas-cloud-networking）这篇文章中，我们已经看到这是如何通过流量隔离，和让客户控制他们需要使用的网络策略来安全地实现的。 对于存储来说，客户的数据存储在虚拟设备中。实际上虚拟驱动器位于更大的存储阵列上（更多信息可以参考《The Future of Cloud Storage (and what is wrong with the present)》：http://www.cloudsigma.com/en/blog/2010/11/21/13-the-future-of-cloud-storage）。那些数据是通过每个云服务器的CPU/RAM来访问的。
当一个客户删除了他们的驱动器，然后一个新的客户创建了一个新的驱动器的时候，数据泄露问题可能就会发生了。在物理磁盘中，旧的驱动器和新的驱动器使用的那个区域可能会发生重叠。因此，完全有可能那个新的客户会试图映射出其他的客户过去写在这个区域上的数据。简而言之，这是一个问题，现在许多Iaas(Infrastructure as a Service)云都暴露出了这个问题。对于使用那些平台的大多数客户来说，他们还没有真正地意识到这种危险。对于我们来说，这有点恐怖，这就是在产品发布以前，我们大费周章地让客户认识到这个问题，并且给他们提供一些防止数据泄露的工具的原因。
解决IaaS(Infrastructure as a Service)的数据泄露问题
这个问题主要有两种方法可以解决。第一种方法是设法确保任何机密的数据都是加密保存在操作系统中的，或者是设法确保整个操作系统/文件结构都是完全加密的。在大多数Linux发行版中，这个工作可以使用LVM（Logical Volume Manager，具体可以参考维基百科中的说明：http://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29）来完成。对于Windows环境来说，这个工作可以使用像Truecrypt（具体可以参考：http://www.truecrypt.org/）那样的产品来完成。一个好消息是这种方法可以发挥作用。加密不能避免数据泄露的问题，它只可以确保那些泄露的数据对于其他人来说是完全没有意义的，同时，也是完全不可用的。
用这种方法在云服务器中进行加密主要有两个弊端。首先，要进行加密，需要依靠客户的努力，在一个由多个服务器组成的动态的云环境中，频繁地进行加密和解密是行不通的。其次，如果一个使用这种方法加密的服务器崩溃了，重启它需要客户的人工干预才能输入必要的密码，访问加密的数据。在现实中，对于大多数用户来说，这样一种方法并不太可行，这会对计算造成严重的干扰。
解决这个问题的第二种方法是在提供商层面解决这个问题。保存一个经过完全加密的虚拟设备（例如：虚拟的硬盘驱动器）是完全有可能的；这可以在云服务器层面上实现。这样的话，可以把经过完全的隐式加密的驱动器保存在操作系统中，当需要访问那些经过加密的数据的时候，那些数据会被解密，然后发送到客户正在访问的云服务器上。这种方法不需要人工干预，也不需要客户进行设置，对于服务器崩溃，重启等情况，这种方法也十分“健壮”。
这就是CloudSigma帮助客户避免数据泄露的方式。当一个客户创建一个新的驱动器的时候（通过我们的API（具体可以参考：http://www.cloudsigma.com/en/platform-details/the-api）或Web控制台（具体可以参考：http://www.cloudsigma.com/en/platform-details/intuitive-web-interface）），他们可以选择是否加密保存这些数据。我们使用“256bit AES triple encryption cascade”（具体可以参考维基百科：http://en.wikipedia.org/wiki/Advanced_Encryption_Standard）来加密客户标记的所有驱动器映像。在大多数情况下，性能方面的影响被限制在10%到15%之间。
从使用的角度来看，对于那个已经解决了数据泄露问题的云服务器来说，它是透明的；那个云服务器会把那个驱动器当成是没有经过加密的，所以客户不需要对那个服务器进行修改。我们通常会建议客户把想要保密的数据存储到一个经过加密的驱动器上。你也可以使用我们的云服务器上的多个驱动器，这就是说，你可以创建一个系统驱动器和一个数据驱动器，然后只加密数据驱动器。这意味着你可以很容易地对你的机密数据进行控制，确保这些数据会被加密地存储，以免发生数据泄露的问题。我们认为这种加密方式是公有云的基本需求，所有相关的服务的费用都已经包含在我们的定价里了。打算使用公有云服务的任何一个人都应该搞清楚那个提供商是如何处理数据泄露问题，保护你的机密数据的。
#p# #e#
嗨，我的数据在哪里？
把数据迁移到云中会造成透明度的缺失——那些数据存储在哪里，更重要的是谁可以访问这些数据。和一些全球性的SaaS(Software as a service)产品（它们会被分发到不同的地方和行政区）比起来，IaaS(Infrastructure as a Service)云在这方面的问题会更少一些。
作为一个IaaS(Infrastructure as a Service)云的客户，搞清楚这些问题是十分重要的：
这个云位于什么地方，隶属于哪个行政区？
哪个公司在管理和控制云中的数据？
这个公司是在哪里成立的，它的管理和控制机构在哪里？
曾经把数据从云所在的地方传输到其他地方吗？如果有的话，是在什么情况下这样做的？
在某种程度上，这些问题的答案可以用来判断把你的数据迁移到那个云提供商的提供的云中是否存在法律方面的问题。对于我们自己来说：
我们的云位于瑞士的苏黎世，隶属于瑞士司法系统的独立行政区。
这个云是由CLOUDSIGMA公司管理的，注册号码是CH-020.3.034.422-0。
CLOUDSIGMA公司是一家瑞士的公司，是在苏黎世州成立的。它的总部和管理机构都在我们的主办公楼里，这个办公楼位于瑞士，苏黎世州的Glattbrugg。
我们从来没有把数据传输到云的外面，不久，我们会添加一些新的地点，但是，如果客户不特意地把数据传输到外面的话，所有数据还是会保存在每个云原来所在的地方。
避免数据锁定
你可能会认为这和安全性没有太大的关系，但是这种让你的数据自由进出云的能力会对数据的管理和控制造成直接的影响。把数据放到一个公有云中以前，首先要明确的是有什么合适的流程可以让你把数据迁移出去。需要关注的主要特性是：
一个定义清晰，明确的数据迁移流程
低成本或零成本的迁移
为了马上可以重用，数据可以用有意义的，可用的格式提取出来。
在做出投资决策，要迁移到我们的云中以前，要搞清楚再次迁出那些数据所必需的投资！
对于CloudSigma来说，这些问题已经解决了，我们的主要迁移路径是通过我们的驱动器映像FTP，经由SSL网关来迁移数据。这可以让我们的客户直接连接到他们在云中私有的驱动器映像库，用RAW ISO格式上传或下载驱动器映像。这还可以让客户使用一个标准的，成熟的协议（不会修改数据的结构），从我们的云中提取他们的全部数据。开源或私有的解决方案都可以使用RAW ISO格式的驱动器映像，实际上，你甚至可以把它烧录到物理硬件上。我们按照统一的标准来收费，输出每GB数据的费用是CHF0.065/ US$0.0585 /EUR0.0455。例如，一个非常大的1TB的驱动器映像可以免费上传到我们的云中，迁移的成本是59.90美金。它的最大优势是，客户可以通过FTP，快速地把驱动器映像从我们的云迁移到另外一个主机提供商或云中。
总结
客户教育和提供商的开放性都是不可或缺的，这可以让和云环境中的数据存储有关的讨论变得更加透明。虽然存在一些问题，但是有一些解决方案可以解决它们，在云中实现真正意义上的数据安全。关于数据处理/存储，客户应该问一些明智的，合理的问题，同时，提供商应该给出完整的，诚实的答案。
原文名：Securing your data in the cloud: an insider's perspective from an IaaS vendor 作者：cloudsigma
原文链接：http://cloud.51cto.com/art/201012/238220.htm
