免責聲明：本文檔中所述過程為 2012 年 1 月時起的情況，如有變更，恕不另行通知。

希望將應用程序部署到 Windows Azure 的企業客戶（實際上是所有客戶）最為關心的就是其數據的安全性。釋放磁盤空間并將其重新分配給其他客戶時，要確保新的所有者無法讀取釋放空間后磁盤上原來的數據，在數據保護中這一點有時會被忽視。一個極端的例子是，廢棄處理從數據中心移除的驅動器或在其他任務中再次利用。釋放之前先使用零或其他模式覆蓋釋放的空間，是確保這一點最簡單的方式。這種覆蓋可能會大大影響性能，因此 Azure 與大多數系統一樣，會使用更為復雜但更有效的機制。

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

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

關于數據保護的概念

在實踐中，磁盤是稀疏分配的。這意味著在創建虛擬磁盤時，不會分配全部的磁盤空間量。而是創建一個表，將虛擬磁盤上的地址映射到物理磁盤上的區域，并且該表最初為空白?？蛻舻谝淮卧谔摂M磁盤上寫入數據時，將會分配物理磁盤空間并在表中設置標志。我們可以通過下面的一系列圖表來了解其概念：

圖 1：分配給用戶的數據塊

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

圖 2：用戶釋放數據塊

在上面的圖 2 中，一個用戶“刪除”數據以釋放數據塊。數據塊標記為可用，其他方面不受影響。

圖 3：為用戶分配最近釋放的數據塊

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

圖 4：用戶請求將數據寫入到磁盤

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

從概念上說，這適用于對讀取和寫入進行跟蹤的任何軟件。對于 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 計算臨時磁盤，尚無此類工具。

本文翻譯自：

http://blogs.msdn.com/b/walterm/archive/2012/02/01/windows-azure-data-cleansing-and-leakage.aspx

轉載于:https://www.cnblogs.com/sesexxoo/p/6191084.html

總結

以上是生活随笔為你收集整理的Windows Azure 数据安全（清理和泄漏）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。