雲計算環境下如何確保資料安全性

原來局限在私有網路的資源和資料現在暴露在互聯網上，並且這些資源和資料放到了協力廠商雲計算供應商所有的共用公共網路上。

與第一個風險因素相關的例子是2008 年12 月報導的亞馬遜Web 服務(AWS )漏洞注1。 在一篇博客文章中，作者詳細說明了在數位簽章演算法中的一個漏洞，「通過HTTP 對亞馬遜SimpleDB 資料庫(Amazon SimpleDB )、亞馬遜彈性計算雲(Amazon Elastic Compute Cloud，EC2 ) 或亞馬遜簡單佇列服務(Amazon Simple Queue Service，SQS)執行查詢(Query ，又稱REST )請求。 」儘管採用HTTPS (代替HTTP )可能會降低完整性風險，但是不使用HTTPS (卻使用HTTP )的使用者卻面臨著越來越大的風險，他們的資料可能在傳輸中被莫名其妙地修改。

注1：這個問題于2008 年12 月18 日報告在Colin Percival 的博客「Daemonic Dispatches 」上，參見「AWS signature version 1 is insecure」(HTTP://www.daem onology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html )。 在亞馬遜Web 服務網站上並沒有公開承認這個問題，也沒有對Percival 的博客文章做公開回應。

圖3-1 ：私有雲計算的一般拓撲圖

確保適當的存取控制

由於資源的一部分(也可能是資源的全部)現在暴露在互聯網上，公共雲使用機構的資料將面臨日益增長的風險。 對雲計算供應商的網路運行進行審計(更不用說基於自身網路進行即時監控)基本上是不太可能的，哪怕是事後審計也很困難。 能夠獲取的網路層面的日誌和資料不多，而且全面進行調查並收集取證資料的能力也是相當有限的。

與第二個風險因素相關的例子是IP 位址再使用(再分配)的問題。 一般來說，當使用者不再需要已分配的IP 位址時，雲計算供應商不再保留使用者的IP 位址。 當地址變為可用後，位址通常再分配給其他使用者使用。 從雲計算供應商的角度看，這麼做是有道理的。 IP 位址數量有限，同時也是用於收費的資產。 然而從使用者安全的角度出發，IP 位址再分配使用可能會帶來問題。 使用者無法確信他們對資源的網路訪問能隨著IP 位址的釋放一併終止，從DNS 中的IP 位址改變到DNS 緩存清理，這之間顯然存在一段時間延遲。 從ARP 表中改變物理位址(例如MAC )到將ARP 位址從緩存中清除也會有一定的延隔時間，因此在老的位址被清除之前，還是會一直存在於ARP 快取中。 這意味著即使位址可能已經變化，原先的位址在緩存中依舊有效，因此使用者還是可以訪問到那些理應不存在的資源。 近期，最大的雲計算供應商之一接到了許多與未失效IP 位址相關的問題報告。 這極有可能是2008 年3月亞馬遜網路極力宣揚其彈性IP 位址能力的一個推動因素注2。 (使用彈性IP 位址，分配給使用者5個可路由的IP 位址，而這些位址由使用者控制分派。 )此外，根據Simson Garfinkel：

現有負載均衡系統中所存在一個問題導致任何超過231 位元組內容的TCP/IP 連接都會終止。 這就意味著超過2GB 的目標內容必須在亞馬遜簡單存儲服務(S3 )中分幾次執行，每次執行都對應著相同目標內容的不同位元組區域注3。

然而，未失效IP 位址以及對資源的未授權網路訪問等問題並不僅僅出現在可路由的IP 位址上(例如那些提供互聯網直接存取的資源)。 這個問題也存在於供應商為使用者提供的內部網路以及非可路由IP 位址的分配上注4。 雖然資源可能無法通過互聯網直接獲得，但出於管理的目的，這些資源必須可通過專用位址在供應商網路上進行訪問。 (每個公共的或者面向互聯網的資源都有其私有位址。 )你的雲計算供應商的其他使用者有可能從內部通過雲計算供應商的網路獲得你的資源，雖然他們未必會故意這麼做注5。 正如在《華盛頓郵報》中報導的，亞馬遜Web 服務存在著對其資源濫用的問題，危及公眾及其他使用者注6。

市面上的一些產品注7可以説明減輕IP 位址再使用的問題，但除非雲計算供應商把這些產品作為服務提供給使用者，否則使用者將不得不尋求協力廠商的產品並支付費用，以解決由雲計算供應商所帶來的問題。