導讀：讓你在云中的數據更加安全是至關重要的。我們將會為您講述作為一個云提供商你應該怎樣保護你的數據。
數據的隱私性和安全性是許多想要遷移到公有云的人的主要顧慮。對于隔離真正的危險，和如何讓他們擺脫在違反內部規定遷移數據過程中的自然的心理反應來說，這一點很重要。
我們發現，在云中的數據存儲可以劃分成三個不同的領域：保持數據的隱私性/安全性，提供商透明度，以及數據的可移植性。
為了搞清楚和云中的數據有關的問題，每個領域都是至關重要的。這三個方面必須都得到使用云的客戶的認可才可以，這樣才能形成有意義的數據處理策略來適應每個云用戶的特殊需要。
在云中的數據泄露：真正的危險
從根本上來說，當遷移到公有云的時候，對于客戶和他們的數據來說，有兩大改變。首先，相對于客戶的地理位置來說，數據會被遠程存儲；這可能會引起法律方面的問題（稍后，我們會進一步說明這方面的問題）。其次，數據通常是從單租戶環境遷移到多租戶環境的，這就是數據泄露問題發生的源頭。
數據泄露只不過是一個客戶到另一個客戶的數據遷移而已。實際上在云中的每個客戶都應該只能訪問他們自己的數據，而不能訪問其他客戶的數據。在《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
