理論上講，基于云的解決方案至少應當向客戶提供與傳統IT模式相同的安全水平。在理想情況下，云服務供應商應當提供更高級的安全水平，遷移到云的根本原因之一就是從客戶方面看安全控制的低成本。

與從云服務供應商處得到的安全相比，同樣的安全控制在企業內部實現可能會更昂貴。不管云供應商提供了什么樣的安全水平，理解這個問題很重要：安全并不是“一錘子買賣”，而是一個過程，因而企業需要在云服務的兩端實施安全，即：為保障數據的安全性，終端用戶(進一步稱為云服務用戶)仍需要采取同樣的行動。

數據總在無休無止地創建過程，我們還必須考慮如何保護數據的機密性、完整性、可訪問性。在創建數據時，我們需要假設一些可能發生的最糟糕的情況，其中包括但不限于數據泄露、未授權訪問、完全喪失對數據的訪問，等等。未授權的訪問意味著喪失了對數據的控制。數據處理的一個副作用就是生成了額外的副本，例如在硬盤上的交換內存、臨時文件，或者是我們用以處理數據過程的內存。在基于云的方案中，關于數據處理的另一個必須考慮到的副作用就是元數據的創建。即使簡單的處理也能產生大量的元數據。如今，收集元數據成為一項艱巨的任務，這意味著元數據也要求某種形式的保護，特別是由于元數據包含敏感信息，所以對其保護顯得尤為重要。其次，從安全的觀點看，加密和解密的位置與時間極為重要。如果加密發生在云端，企業就必須提供安全措施，將未加密的數據發送到其中。

在談到數據泄露或未授權的訪問時，我們首先想到的是加密。由于加密是從軍事領域進入企業的，所以加密往往被誤解，并被描述為一種很有魔力的可以解決所有安全問題的方案。但這種方法從開始就是有瑕疵的。下面展開討論其中的諸多因素。

1.不安全的過程

用復雜的方案解決復雜問題并不是簡單任務，在我們試圖通過加密解決安全問題時尤其如此。安全始于信息處理過程。如果設計過程不合理，加密會安全嗎?例如，如果你要求用戶使用過長的復雜口令，用戶就會找到一種不安全的方法繞過去。此處的原則是終端用戶的體驗對安全來說至關重要：控制應當允許用戶快速完成任務而不帶來太多障礙。企業的業務人員也喜歡這種方法，因為它可以長久地使利潤最大化。

口令策略與加密有什么關系呢?雖然從安全的觀點看，口令已成“過去式”，但是口令仍在使用中，而且還很強健。用戶如何登錄到移動設備?難道不是用PIN?用戶如何登錄到社交賬戶或云中的電子郵件賬戶?問題的寓意在于：如果你使用口令來保護對數據的訪問，就需要保障口令的安全，并且經常更換。云方案并不會使口令完全消失。

2.用戶教育和安全意識

不管你是如何巧妙地設計過程和實施過程，都不能忽視人的因素。正如愛因斯坦所言，有兩件事情是永恒的,就是宇宙和人類的愚蠢,對于前者我并不太了解。如果用戶能夠在惡意軟件彈出的窗口中多次輸入口令，就不要期望加密會阻止其這樣做。如果再強調加密的作用就是在自欺欺人。用戶們必須認識到威脅，并且理解如何處理控制才能保證安全。釣魚攻擊正被一些類似惡意軟件的攻擊所利用。在惡意軟件防護問題上這尤其重要。除非云服務供應商在其云服務和客戶系統上提供惡意軟件的防護,否則，對于終端用戶的惡意軟件防護來說，可做的很少。當然，客戶必須安裝最新的安全方案。掃描上傳到云服務的文件或數據并不能阻止終端系統受到惡意軟件的感染。因而，惡意軟件不但可以感染系統，還能夠從云服務的客戶端竊取未加密的數據，并且可以竊取需要云服務訪問的信息，還能破壞云服務。

3.不安全的架構

再次談到云服務供應商。整個系統的架構(其中包括密碼系統)對于最終的安全水平都至關重要。在多數情況下，要保障數據一直處于加密狀態并不可行，因而，解密過程在應對未授權的訪問和數據泄露風險時就顯得尤為重要。企業應遵循如下的最佳實踐：

(1)部署多層防御，僅有加密這一層還遠遠不夠。

(2)盡可能在一個地方加密和解密數據，例如，這樣做會限制有些信息沒有被正確加密的風險，而且還要以使安全審計更容易。

(3)要保護好加密密鑰和IV(初始向量)。

(4)確保實施強健的隨機數字生成器。

(5)如果可行的話，不要使公眾使用全部功能，從而限制攻擊面。

很明顯，上述清單并沒有包含所有的最佳實踐。有些最佳實踐與服務類型或云服務的經營模式有緊密聯系。

4.脆弱協議和算法

從安全的觀點看，如果實施和部署不當，即使最佳的架構仍有可能成為隱患。例如，一些不安全協議和算法的使用，如SSH的老版本等。幸運的是，有些廠商開始禁止對不安全協議的支持。

另一個問題是，由于密鑰太短小或生成方式不強大，就有可能造成企業的協議很強健而其密鑰很脆弱。總之，不要使用太短小的密鑰，因為其容易被破解。如果攻擊者自身缺乏計算能力，他完全可以購買云服務，從而可以使其快速地破解短密鑰。

5.隨機數的隨機性不強

如果不使用基于硬件的方案，對計算機來說隨機數的生成并不是容易的任務。多數編程語言都提供隨機函數，但這類函數并不安全，因而不應用于密碼系統中。簡言之，脆弱的隨機數生成器可以使整個密碼系統不安全，并易于被破解，因為這可以使攻擊者正確地猜測到生成器的結果和種子的初始向量，從而使密碼分析攻擊更容易，并且使攻擊者可以破壞整個加密過程。

6.算法很強健，但實施過程有漏洞

即使從密碼術的觀點來看，所有已部署的協議和算法都很強健，也不意味著其實施就是安全的。在此存在著兩個問題：1.不正確地實施安全算法或安全協議，從而弱化其加密性能。2.軟件或硬件中的缺陷，導致可能被第三方利用其漏洞。

OpenSSL漏洞就是第二個問題的一個例子。第一類問題就需要更多解釋。每種加密算法都有一套定義其強度的屬性。前面提到的不正確實施安全算法或安全協議的一種原因就是，使用了不安全的隨機數生成器。這種問題未必是程序員有意為之。例如，程序員使用的可能是提供不安全偽隨機數生成器(被認為很安全)的外部庫。在簡單的代碼檢查過程中，這種漏洞是不可能被發現的。

7.臨時文件和Swap內存

如果交換內存和臨時文件在云服務的兩端都沒有加密，這必然成為一種泄露數據的方法。下面討論兩種情況：1.加密發生于云服務供應商，而數據是通過安全通道被傳送到云的。2.加密發生于云服務客戶端，加密的數據被發送給云服務供應商，使其可以用加密的形式存儲。

在這兩種情況下，交換內存和臨時文件都可能包含未加密數據的副本。 即使攻擊者只能訪問不完整的未加密數據，并可以獲取訪問加密數據的副本，也會使密碼分析攻擊更可行。那么，上述兩情況有什么區別呢?答案是交換內存和臨時文件的位置：在第一種情況中，交換內存位于云服務供應商的架構中，而在第二種情況下，交換內存和臨時文件位于云服務客戶的工作站或移動設備上。很明顯，對這些區域的訪問應當受到限制，但其實施過程應有所區別。在第一種情況下，實施的責任屬于云服務供應商，而且在多數情況下，云服務的客戶對于如何實施的細節知之甚少。事實上，在多數情況下，只有客戶和供應商之間的合同可以定義供應商必須采取的措施。在第二種情況下，保護交換內存和臨時文件就屬于云服務客戶的責任。不過，如今的有些操作系統默認會加密交換內存，但對于移動設備，就有很大不同。臨時文件的保護不同于此。多數操作系統通過限制文件的訪問和移除文件來保障臨時文件訪問的安全。不幸的是，現代操作系統及其支持的存儲設備，安全移除文件往往是不可能的。還有另外一種情況，其中的臨時文件并沒有被刪除。例如，這種情況可能是應用程序崩潰的結果，也有可能是被另一個過程鎖定的原因。這個問題的解決方案就是加密的文件系統，此時，即使臨時文件并沒有被完全刪除，或者沒有以一種安全的方式刪除，對其訪問仍受到限制。

為什么交換內存和臨時文件成為如此嚴重的問題?不妨設想一下用戶丟失移動設備的情況，或設想由于發生故障，云服務供應商更換存儲媒體的情形。后一種情形會帶來一個關鍵問題：云服務供應商安全地處置IT設備。這個過程應當準備好，并且在服務等級約定中進行明確定義。

8.事件處理、取證、數據發現

在考慮數據加密時，我們還必須考慮安全事件發生時出現的問題。對加密文件或文件系統或交換內存進行取證分析可能會很復雜，甚至是不可能的任務。對于云服務，問題會更復雜，因為你有可能無法訪問文件系統。事實上，在有些服務中，甚至沒有文件系統的概念，所以典型的取證分析過程從一開始就失敗了。在考慮加密和計劃事件處理過程時，也要考慮這個問題。

加密數據只有在保持其完整性時才能被解密。但是，如果由于安全事件或是由于硬件故障等隨機事件，其完整性遭到了破壞，就有可能不能成功地解密數據。在這種情況下，數據發現方法就沒有什么用處了。這就要求我們重點考慮備份策略，尤甚是在我們使用加密時。有些合規要求強制使用加密備份作為唯一的選擇。所以在我們使用云服務時，檢查云供應商的備份和加密策略是非常關鍵的。

9.依賴廠商加密

如果你的數據是由云服務供應商加密的，至少應當檢查兩方面：

(1)你有一份未加密數據的副本嗎?

(2)加密數據如何傳送給另一個云服務供應商或傳回給企業?

如果你將未加密的數據副本上傳到云中，就應考慮找一家可以提供安全通道的云服務供應商。事實上，這種情況很少發生，因為使系統和云的數據保持同步和更新是一個問題。事實上，這種方法會限制充分利用云服務的好處。

第二個問題更為典型，而且有些廠商為了自己的業務也不愿意放走客戶。由此導致的結果是，加密成為一種很好的方法。如果加密數據不是簡單地從一個云服務供應商傳送給另一個供應商，你就必須解密、上傳、加密數據。對于單個文件或小文件，這種操作不會有什么問題，但是，隨著文件的數量和大小的增大，在云服務供應商之間進行切換的復雜性和時間都會增加。在極端情況下，這種復雜性和時間會導致高成本，從而使得在云服務供應商之間的切換不再是一種可行的選擇。

如果你在本地加密數據，而僅僅將云用于存儲加密文件，就不受上述問題的影響。