Windows Azure資料安全性實施的做法

希望將應用程式部署到 Windows HTTP://www.aliyun.com/zixun/aggregation/13357.html">Azure 的企業客戶（實際上是所有客戶）最為關心的就是其資料的安全性。 釋放磁碟空間並將其重新分配給其他客戶時，要確保新的擁有者無法讀取釋放空間後磁片上原來的資料，在資料保護中這一點有時會被忽視。 一個極端的例子是，廢棄處理從資料中心移除的磁碟機或在其他任務中再次利用。 釋放之前先使用零或其他模式覆蓋釋放的空間，是確保這一點最簡單的方式。 這種覆蓋可能會大大影響性能，因此 Azure 與大多數系統一樣，會使用更為複雜但更有效的機制。

在本文中，我們將發現 Windows Azure 和 SQL Azure 軟體為達到以下目的而實施的做法：防止在刪除 Windows Azure 虛擬機器實例、Windows Azure 虛擬機器磁碟機、Windows Azure 磁碟機、Wind ows Azure 存儲、SQL Azure 資料或 SQL Azure 實例本身時造成資料洩露或將一個客戶的資料暴露給其他客戶。 這些機制的細節有所不同，但概念均類似，即：不允許任何使用者從之前未寫入資料的磁片位置讀取資料。

本文中的詳細資訊由 Windows Azure 首席軟體工程師、傑出的安全架構師 Charlie Kaufman 提供。 您可以在此處和此處找到 Charlie 的一些著作。 Charlie，謝謝你！

關於資料保護的概念

在實踐中，磁片是稀疏分配的。 這意味著在創建虛擬磁片時，不會分配全部的磁碟空間量。 而是創建一個表，將虛擬磁片上的位址映射到物理磁片上的區域，並且該表最初為空白。 客戶第一次在虛擬磁片上寫入資料時，將會分配物理磁碟空間並在表中設置標誌。 我們可以通過下面的一系列圖表來瞭解其概念：

圖 1：分配給使用者的資料塊

在上面的圖 1 中，基於兩個使用者各自的寫入請求為他們各分配兩個數據塊。

圖 2：使用者釋放資料塊

在上面的圖 2 中，一個使用者「刪除」資料以釋放資料塊。 資料塊標記為可用，其他方面不受影響。

圖 3：為使用者分配最近釋放的資料塊

在上面的圖 3 中，在新使用者請求寫入時為其分配最近釋放的資料塊以及之前未分配的資料塊。 之前釋放的資料塊仍然不受影響。 實質上，該過程是這樣的，當使用者請求寫入到磁片時，必須確定已分配給該使用者的現有磁片上是否有足夠的空間可存儲新資料。 如果有，新資料將覆蓋現有塊中的資料。 如果沒有，則將分配新的資料塊並將資料寫入到新塊。 可在下圖中查看該邏輯。

圖 4：使用者請求將資料寫入到磁片

現在的問題是某個客戶可能會讀取其他客戶已刪除的資料，Azure 管理員也可能會讀取客戶已刪除的資料。 如果任何人嘗試從虛擬磁片上其尚未寫入資料的區域進行讀取，則不會為該區域分配物理空間，因此不會返回任何資料。 我們可以在下圖中查看該邏輯和結果。 只有 Azure 管理員可以讀取標記為可用的塊，但管理員無法借助任何實用程式確定該塊之前的擁有者。

圖 5：使用者發出讀取請求

從概念上說，這適用于對讀取和寫入進行跟蹤的任何軟體。 對於 SQL Azure，由 SQL 軟體執行此操作。 對於 Azure 存儲，由 Azure 存儲軟體執行此操作。 對於 VM 的非持久磁碟機，由主機作業系統的 VHD 處理代碼執行此操作。 由於客戶軟體只能訪問虛擬磁片（從虛擬位址到物理位址的映射發生在客戶 VM 之外），因此無法對已分配給其他客戶的物理位址或閒置的物理位址發出讀取或寫入請求。

注意：在某些情況下，寫入邏輯（參見圖 4）會被修改, 第二次寫入塊時不會覆蓋磁片上的資料。 反之，會分配一個新的塊並將資料寫入該新塊中。 舊的塊將被標記為可用。 這種方法通常稱為基於日誌的檔案系統。 也許聽起來效率不高，但通過這種方法可將大部分資料寫入到物理磁片上的連續位置，可最大限度地減少尋找時間並實現更好的性能。 這些細節對客戶是透明但相關的，因為它意味著即使客戶在釋放磁片之前使用零顯式覆蓋虛擬磁片上的每一個塊，那也不能保證客戶的資料不會仍存在於物理磁片上。

Windows Azure 虛擬機器 (VM)

刪除 VM 後，原本存儲其本地虛擬磁片內容的磁碟空間會標記為可用，但並未完全清零。 該空間最終將用於存儲其他 VM 的資料，但並未規定過期內容留在磁片上的時間上限。 但是，虛擬化機制是為了確保再次寫入資料之前其他客戶（或同一客戶）無法讀取磁片上的這些點，從而確保不會產生資料洩漏威脅。 為 VM 創建新的虛擬磁片後，虛擬磁片看似已經清零，之所以會造成這種假像是因為在讀取未寫入的虛擬磁片區域時, 我們總是返回零。 如果對 VM 實例進行重新初始化，則相當於是將其移動到新的硬體。

Windows Azure VM 磁碟機和 Windows Azure 磁碟機 (X-Drive)

在 Windows Azure 中，VM 實例可以訪問的虛擬磁碟機有兩種。 計算節點的本地磁片, 即 Web role 和 Worker role 中的 C: 盤、D: 盤和 E: 盤。 這些盤上的資料並非以冗余方式存儲，必須將其視為短暫性資料。 如果發生硬體故障，則會將 VM 實例移動到其他節點，虛擬磁片的內容將重置為初始值。 如果對 VM 實例進行重新初始化，則 C: 盤、D: 盤和 E: 盤將恢復為初始狀態，這相當於是將其移動到新的硬體。

Windows Azure 磁碟機（也稱為「X-Drive」）被存儲于 Windows Azure 存儲中的 Blob。 X-Drive 是持久性的，除非客戶採取顯式操作將其更換，否則不會被重置。 此資料以冗余方式存儲，即使發生硬體故障也不會丟失。 刪除 VM 實例不會刪除關聯的 X-Drive 中的資料。 刪除 Blob 本身（或刪除包含 Blob 的存儲帳戶）才會刪除 X-Drive。 請參閱下一節，其中說明了如何處理 Windows Azure 存儲中的資料刪除。

Windows Azure 存儲（表、Blob、佇列）

在 Windows Azure 儲存子系統中，一旦調用刪除操作，則客戶資料將不可用。 所有存儲操作（包括刪除）旨在立即實現一致。 成功執行刪除操作將刪除相關資料項目的所有引用，並且無法通過存儲 API 對其進行訪問。 刪除的資料項目的所有副本最終都將被回收。 當關聯的存儲塊重新用於存儲其他資料時，物理資訊將被覆蓋（即重新初始化），就像標準的電腦硬碟磁碟機一樣。

SQL Azure

在 SQL Azure 中，刪除的資料標記為刪除，但不會被清零。 如果刪除了整個資料庫，則相當於刪除了其全部內容。 在任何情況下，SQL Azure 實現均可通過禁止對基礎存儲的所有訪問（除非通過 SQL Azure API）來確保使用過的資料不被洩露。 該 API 允許使用者讀取、寫入和刪除資料，但絕不允許使用者讀取之前未寫入的資料。

自動備份和取證

通常情況下，客戶希望確保他們的資料不會在未經授權的情況下被訪問。 在某些情況下，他們甚至希望確保已刪除的資料不會在未經授權的情況下被訪問。 資料一旦刪除或更改，就無法再通過提供給客戶的介面進行檢索，但這些資料可能會在相當長的時期內繼續保留在磁片上，並且理論上可使用內部取證工具對其進行恢復（但已刪除的資料存在的可能性會隨著時間而降低）。 最終，從生產環境刪除的任何物理磁片都將完全清除或銷毀。

我們正在考慮在不久的將來推出一些功能，使客戶無需進行顯式備份即可恢復已刪除的資料（以及還原已更改的資料）。 使用這些工具就無法完全向客戶保證這些資料在刪除後不會被得到授權的相關方訪問。 任何此類工具都只能在有限的時間內（不超過 30 天）檢索已刪除的資料，除非客戶選擇更長的備份時間。 撰寫本文時，有一些未公開的工具，可允許在 14 到 21 天內恢復從 SQL Azure 資料庫中刪除的資料。 對於 Azure 存儲或 Azure 計算臨時磁片，尚無此類工具。