發行項
10/28/2016

本文章是由機器翻譯。

雲端安全性

Windows Azure 中加密服務和資料安全性

Jonathan Wiggs

Windows Azure 平台的許多早期採用者仍有很多的平台安全性方面的疑問和其支援加密的流程。我希望是介紹一些密碼編譯和 Windows Azure 平台內的相關的安全性的基本概念。本主題的詳細資料可能填滿整個活頁簿，所以我只準備仍要示範及檢閱的一些密碼編譯服務和 Windows Azure 的提供者。另外還有任何轉換為 Windows Azure 某些安全性含意。

與任何新的平台] 或 [服務傳遞方法中，您會面臨新的挑戰。您也會收到提醒的一些典型的問題仍然存在，而且甚至相同的解決方案的一些您過去使用還是可以使用很好。任何應用程式工程師或設計工具應該思考這個主題如它與相關的您可能會儲存，以及您需要保存的資料種類。將這結合成一個講究方法的方法，且您和客戶會 well-served。

所以為什麼會我認為這需要開發人員社群內的資訊？透過前幾個月我看到越來越多的社群網站與安全性有關的文章的一般與 Azure。 Microsoft 有建議的保全應用程式層資料與 Azure 專案一部分的加密。不過，適當了解加密與.NET 安全性模型將會需要產品設計人員和開發人員在 Windows Azure 平台上建置。

我注意到一件事是不斷增加的百分比的張貼特定密碼編譯服務與金鑰存放。這是特別指定為 True，有關，Windows Azure 存放服務。取得將要，我自己好奇心，我發現已可敬主題來討論一些深度。

在這篇文章課程，我會進行大量使用密碼編譯服務提供者 (CSP) 也就是密碼編譯標準、演算法和呈現函式在系統程式介面的實作。基於本文的目的我正在使用 Rijndael 密碼編譯類別所提供的對稱式加密演算法。

密碼編譯基本概念

Windows Azure SDK 擴充核心.NET 程式庫，讓開發人員整合，並使 Windows Azure 所提供服務的使用。尚未 Windows Azure 專案和服務中限制存取 [CSP。這表示許多方面來加密與程式開發，並解密資料會保持相同，有關以前所未有若要使用的組件。但是，有基礎架構、何時或何處加密資料的問題中的變更和位置，以及如何保存金鑰。我討論索引鍵和本文稍後的秘密資料保存性。

您也可以在 [Windows] Azure 例如 MD5 及 SHA 的存取權的密碼編譯雜湊功能完整的陣列。這些都是重要增強的項目例如偵測重複的資料、雜湊資料表的索引、訊息簽章及密碼驗證任何系統安全性。

一致的建議是永遠不會建立您自己或使用專屬的加密演算法。 .NET CSP 中所提供的演算法會證明、測試，有許多年的多個備份的曝光度。使用 XOR 來建立您自己的加密程序是不一樣的而不提供相同的資料安全性的層級。

第二個建議，是使用 RNGCryptoServiceProvider 類別產生隨機數字。如此可確保您的應用程式所產生的隨機數字永遠會有非常高的熵，讓它更難以猜測在圖樣。

下列程式碼會實作會傳回 32 位元的 int 值，隨機且符合加密式安全需求的單一靜態成員。這是由可能使用位元組產生器中在密碼編譯命名空間中找到 RNGCryptoServiceProvider：

public static int GenerateRandomNumber() {
  byte[] GeneratedBytes = new byte[4];
  RNGCryptoServiceProvider CSP = new RNGCryptoServiceProvider();
  CSP.GetBytes(GeneratedBytes);
  return BitConverter.ToInt32(GeneratedBytes, 0);
}

圖 1 顯示簡單的範例，使用 Windows Azure 平台內 CSP。三個公用成員會公開任何 Windows Azure 應用程式中使用。第一個接受一個二進位金鑰和初始化向量 (IV)，以及二進位緩衝區的未加密的資料，並傳回其加密的對等用法。第二個成員並相反順序來解密資料。第三個成員傳回計算的雜湊值為該資料。請注意此處我使用 Rijndael CSP 的受管理的存取權提供者。我也在二進位的緩衝區中儲存資料和索引鍵，並寫入到它們上面，只要我 ’m 完成與它們。我碰有關這個主題稍後當我要討論的不變性。

圖 1 的 簡易的加密

public static byte[] SampleEncrypt(byte[] dataBuffer, 
  byte[] Key, byte[] IV) {

  MemoryStream InMemory = new MemoryStream();
  Rijndael SymetricAlgorithm = Rijndael.Create();
  SymetricAlgorithm.Key = Key;
  SymetricAlgorithm.IV = IV;
  CryptoStream EncryptionStream = new CryptoStream(InMemory,
    SymetricAlgorithm.CreateEncryptor(), CryptoStreamMode.Write);
  EncryptionStream.Write(dataBuffer, 0, dataBuffer.Length);
  EncryptionStream.Close();
  byte[] ReturnBuffer = InMemory.ToArray();
  return ReturnBuffer;
}

這是加密的資料和做為位元組陣列傳回加密的結果的最簡單的範例。這是不應該用於安全的環境沒有所有適當的安全性分析，僅為範例的程式碼。

的 圖 2 中範例有幾乎完全相同的結構，以的 圖 1 中。在這種情況下，我解密資料是根據相同的金鑰和 IV，只能以做為參數的加密的位元組緩衝區。只有真正的差異是當我建立加密資料流，我指定我建立對稱的解密子和不加密子像我先前一樣。

圖 2 的 簡易解密

public static byte[] SampleDecrypt(byte[] dataBuffer, 
  byte[] Key, byte[] IV) {

  MemoryStream InMemory = new MemoryStream();
  Rijndael SymetricAlgorithm = Rijndael.Create();
  SymetricAlgorithm.Key = Key;
  SymetricAlgorithm.IV = IV;
  CryptoStream EncryptionStream = new CryptoStream(InMemory,
    SymetricAlgorithm.CreateDecryptor(), CryptoStreamMode.Write);
  EncryptionStream.Write(dataBuffer, 0, dataBuffer.Length);
  EncryptionStream.Close();
  byte[] ReturnBuffer = InMemory.ToArray();
  return ReturnBuffer;
}

金鑰存放和保存性

如同在應用程式或企業層級的任何加密] 策略加密和解密的基礎結構會是少於半場戰役。真實問題隨附的機碼儲存和索引鍵的保存性。所提供的加密資料的資料安全性只有一樣使用，金鑰安全，且這個問題會更難比人員可能認為第一次。我檢閱的系統有儲存從直接中的各處來源要命名為聰明平面儲存在硬碟尋找目錄中的檔案名稱的文字檔案程式碼的密碼編譯金鑰。

重要的問題的索引鍵的持續出現考慮儲存，並保留在定域機組的環境中的機碼的位置時。有些人擁有來表示依據定域機組中保存的索引鍵您公開自己安全性威脅從定域機組本身的考量。也就是如果其他人可以取得您資料的實體存取，則儲存在磁碟上的資料不可能被加密預設 (如是與 Windows Azure 情況)。這會變成在規劃和設計您的方案中考慮的安全性決策考慮 SQL Azure 不還支援加密是。如同任何的安全性實作風險必須是測量、權衡以及減輕。

但表示 doesn’t 定域機組中一般的平台 — 和 Windows Azure 特別 — 是原本就是不安全。何種其他選項可能會提供給您？

要立即注意一件事是沒有應用程式應該曾經使用任何 Windows Azure 作為索引鍵的按鍵來加密資料。就會由 Windows Azure 提供儲存體服務機碼。這些機碼會設定為允許的安全性目的，或如果它們入侵因任何原因而簡單的旋轉。亦即它們可能不有在未來而且可能會太廣泛散發。

儲存您自己索引鍵的媒體櫃內 Windows Azure 存放服務是好的方法，可保存一些秘密資訊，因為您可以依賴這項資料被 multi-tenant 環境中安全和存放金鑰的安全。這是不同於使用儲存金鑰作為您的密碼編譯金鑰。改，您可以使用儲存體服務機碼來存取金鑰的媒體櫃，如同任何其他預存的檔案。這是相當容易實作。比方說說出您想要實作索引鍵的媒體櫃與簡單的文字檔來保存一些秘密資訊。最佳會將這為 BLOB (二進位大型物件) 服務 API 相對於 [佇列] 或 [表格儲存體服務中的資料儲存。 BLOB (二進位大型物件) 區域的儲存體服務是最佳的地方的資料，例如二進位的音訊及影像或甚至文字檔案。服務佇列部分著重於安全的訊息，對於不做維持很長一段時間的小型資料物件。表格儲存體系統是很棒的結構化的資料以及需要保存和存取的特定部分，與關聯式資料庫中的資料相同的資訊。

您可以藉由保存 CSP 金鑰容器中的索引鍵來開始。這是很棒的選項，用於儲存很難擷取沒有實體存取伺服器的公開金鑰。與 Windows Azure 位置區隔應用程式和資料的位置，這會使甚至公用金鑰儲存在這種方式非常難尋找和擷取。金鑰存放容器建立非常簡單；以下是使用我們的索引鍵會建立 RSA 提供者範例。如果金鑰容器已經存在，它的索引鍵被載入提供者會自動：

CspParameters CspParam = new CspParameters();
CspParam.KeyContainerName = "SampleContainerName";
RSACryptoServiceProvider RSAProvider = new 
  RSACryptoServiceProvider(CspParam);

另外還有其他根據您的需求，您可以考慮的選項。比方說您可以使用特定的標幟來建立該容器對使用者金鑰的安全性。這可以與 CspParameters 旗標成員使用來完成：

CspParam.Flags = CspProviderFlags.UseUserProtectedKey;

現在建立 BLOB (二進位大型物件) 使用 Windows Azure 儲存機碼的 API 的要求。要求本身需要簽章字串以及適當的要求標頭。適當的標頭格式為：

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

在這種情況下，我想要最大化的我的永續性的  secret 資料安全性，因此我使用 SharedKey 授權方法。標頭簽章部分是所產生 SHA256 演算法，並對資料簽章中您存放金鑰的雜湊為基礎的驗證程式碼。此雜湊再編碼成 base64 字串。範例簽章可能如下所示：

"PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-Date:Fri, 12 Sep 2009 22:33:41 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/exampleaccount/storageclientcontainer/keys.txt"

如稍早所述，我會再產生 base64 編碼雜湊並使用的標頭中與所用簽章。此金鑰檔然後可能僅能存取有應用程式所執行在您的應用程式分享空間，以存取 Windows Azure 定域機組中存放金鑰的人。使用金鑰保存性，您可以讓任一個管理機碼之外，Windows Azure 架構或定域機組本身內。

索引鍵和安全性威脅

值得至少簡略涵蓋一個項目是主要的安全性。這是比保存和儲存索引鍵的方式稍有不同的主題。金鑰本身是熵的隨機性的基本上有極高的層級，這表示極高的字元的字串。這在實際上會導致常見的攻擊程序來尋找系統內的索引鍵。比方說如果您在硬碟上採取傾印] 或 [資料的區域，極高的區域會是熵的記憶體的很棒的地方開始索引鍵的採擷。

分開選擇良好的安全性作法為基礎的應用程式和保護您資料的安全需求，其他方式可以您保護自己？若要啟動，永遠假設使用以解密、加密和保護資料之處理程序是知名任何攻擊者。知道這一點之後，請確定您定期循環您的機碼，並保護其安全。讓它們只必須讓它們的使用和限制您暴露在機碼取得您控制項的外面的人。

最後，投資時間以圖表化安全和非安全您資料的流程。看看在您的資料會的地方，以及如何、儲存機密資料的地方，以及特別是在您的資料跨越界限，例如公用及私人網路的地方。這將會為您提供的位置公開您的資料是個好主意，讓您目標緩和以簡單的方式的計劃與這些風險。

我要求的相關的問題是 Windows Azure 是否支援 SSL。這個簡短的答案是肯定的！ Windows Azure 就不是 Web 服務的強大定域機組平台和應用程式，而不支援 SSL。

SQL Azure 的加密

發行的 SQL Server 2008 引進新功能：透明資料加密 (TDE)。第一次 SQL Server 可以加密其資料完全極少超出為何需要限制 SQL Server 2005 中可用的加密所需的努力。然而，初始版本的 SQL Azure 儲存空間並不還支援資料庫層級加密雖然 ’s 考慮針對未來版本的功能。應注意的是 SQL Azure 才可用透過連接埠 1433年，並只透過 TCP 連線；它目前無法公開其他連接埠上。

即使這項功能不還整合至 Windows Azure，有數個安全性功能的開發人員或設計工具應該請記住 SQL Azure。先，SQL Azure 支援表格式資料流 (TDS)。這表示您在大多數的情況下可以連接，並與資料庫互動，就像您永遠完成。利用 ADO.NET 加密及受信任的伺服器憑證是絕對值得考慮，特別是在存取您的 SQL Azure 資料庫從外部定域機組。

連線內容加密 = True 和 TrustServerCertificate = False 中適當的組合,、可確保資料傳輸是安全和可以幫助防止在中間男人攻擊。這也是用於連接至 SQL Azure 需求 — 除非連接層級加密打開，無法連線至 SQL Azure。

您應該瞭解與 SQL Azure 第二個安全性功能，就是 SQL Azure 防火牆。這個工具將會非常熟悉的使用者使用本機的軟體防火牆] 或 [偶數 SQL Server 安全性表面區域工具組。它可以讓您允許或防止來自一路向下到特定的 IP 位址或範圍的各種不同來源的連線。 SQL Azure 防火牆可透過 SQL Azure 入口網站] 或 [與所提供的預存程序如 sp_set_firewall_rule 和 sp_delete_firewall_rule master 資料庫中直接管理。

如同任何實作 SQL Server 使用者帳戶管理是必須緊密控制的另一個觀點。 SQL Azure 內防火牆的確是好用的工具，但它應該不會依賴本身。使用者帳戶使用增強式密碼，並設定特定權限應該用也來補足您資料的安全性模型。

這些新工具進入朝進行 SQL Azure 定域機組為基礎的應用程式非常緊密安全的 Managed 平台的長方式。如果您嘗試這項服務，第一次，請記住您可以連接之前您必須一開始設定 SQL Azure 防火牆。這必須先完成透過 SQL Azure Web] 入口網站，但可以稍後直接在 master 資料庫中完成稍早所述。

不變性和記憶體中的資源

Immuta-狀況？物件導向程式設計中的不變性只是表示物件 ’s 狀態不能在其初始建立後修改。 Microsoft.NET Framework 中的具體範例是字串類別。當字串的值已變更程式碼中時，只是放棄在記憶體中原來的字串，並新的字串物件建立來儲存新值。

為何如此重要從安全性觀點來看？嗯，字串可能會保持在記憶體中，只要伺服器處於連線狀態而不需重新開機。您真的有無法知道以確實方式如何長字串會保持在記憶體中。考慮如何在程式碼 (例如密碼編譯金鑰或加密和解密資料的副本中儲存資訊時，這點很重要。藉由離開背後您資料在記憶體中的軌跡，您留下公開聰明資料竊賊您機密的資訊。

因為這項弱點的總是建議這類資料儲存在例如位元組陣列的緩衝區。這樣一來，只要您完成資訊，您可以覆寫緩衝區以零或任何其他可確保資料的資料不再該記憶體。

因為 Windows Azure 是一個定域機組的環境被詢問是否這是靜止是重要的考量，而且它 ’s 這是個很好的問題。為 True，則，在 Windows Azure 系統個別應用程式是彼此隔離的應用程式。這樣 exposing 資料在記憶體很少發生問題的一般。它就會將相關聯的應用程式和定域機組中的記憶體空間非常困難。不過，我仍然建議謹慎的方法和清除後您自己。您可能無法永遠執行此段程式碼在定域機組中，且其他弱點可能在未來公開本身。在較少是重要的考量時保留這個習慣，並保存這種方法。

的 圖 3 在我修改產生隨機整數先前的範例。此處我加入錯誤處理以確保我有一點一個 finally 區塊，永遠無論如何的回合。該區塊內我正在進行透過位元組] 陣列中值的一個非常簡單反覆項目以零值覆寫每個位置。這會覆寫記憶體中的該資料，因為位元組陣列是可變動。我知道此號碼已不存在於這個成員執行所擁有的記憶體。這可以完成到任何用作項目 (例如索引鍵、初始化向量和加密或解密資料的資料緩衝區的位元組陣列。

圖 3 清除資料從記憶體

public static int GenerateRandomNumber() {
  byte[] GeneratedBytes = null;

  try {
    GeneratedBytes = new byte[4];
    RNGCryptoServiceProvider CSP = 
      new RNGCryptoServiceProvider();
    CSP.GetBytes(GeneratedBytes);
    return BitConverter.ToInt32(GeneratedBytes, 0);
  }
  finally {
    for (int x = 0; x < GeneratedBytes.Length; x++) { 
      GeneratedBytes[x] = 0;
    }
  }
}

訊息佇列

Windows Azure 佇列提供類似的功能，以對企業的 Windows 應用程式都通用的 Microsoft 訊息佇列 (MSMQ) 服務。訊息佇列服務在 Windows Azure 內第一個單元，先進先出 (FIFO) 的方式儲存文字基礎的訊息不大於 8 KB。這允許服務與不同的伺服器上執行的應用程式 — 或在本例中內定域機組 — 互動，並將採取行動的訊息傳送給彼此安全和分散式的方式。

有五種基本的功能，可讓您發送到佇列的訊息、窺視訊息、提取訊息等等。通常已經變成大部分的問題是，如何安全是這些訊息？

許多的功能目前支援由 MSMQ 不還支援 Windows Azure 傳訊 API 內。但是，有相似之處。如同 BLOB 資料服務訊息服務會讓使用的相同 REST get 和放入介面。撰寫和讀取可以完成郵件，在程式碼或使用 URI 和 Web 要求呼叫，可以加密透過 SSL 要求透過不安全的網路。這表示加密傳輸的要求。

而且，如同其他的儲存體服務內 Windows Azure，到訊息佇列的任何存取必須進行相同的儲存體服務機碼的使用。只有具有應用程式存取機碼可以檢視或新增到這些佇列的訊息。這使得這些訊息光  unless 這些訊息的主體即將被離開安全的網路或保護應用程式空間的任何額外的加密。

所有最多換行

朝服務導向的架構和解決方案今天 ’s 磁碟機中, 只有少數可以考慮做生意而定域機組的應用程式。資料和服務，例如 Windows Azure multi-tenant 環境中的隔離是一種具有朝使用私用資料眼睛人的主要考量。

如有任何新的平台安全性和加密功能會繼續發展中 Windows Azure 平台。Microsoft 已經採取絕佳 pains 不只提供一個安全、隔離的環境，但也要公開什麼這已經發生以便進行這些量值的公用憑證。這應該讓的工程師信賴 Microsoft 想要成為更接近夥伴對安全性和保持系統和應用程式鎖定。

安全性和尤其是密碼編譯的重點是要讓資訊和程序很難取得的存取權。我們可以定義「硬碟」作為超出分成這類系統生命週期的資料或處理程序期間的任何對手能力的意義。這是，但是，相對定義應用程式或資料所使用的需求為依據。這就是為什麼我續強調安全性，以及透過這份文件的密碼編譯需求的常數評估需要。這就是確保這些工具可用於有效地讓您定域機組的系統安全，並保護您的資料非常重要。

Jonathan Wiggs 正在主體工程師和開發管理人員在 Nuance 通訊 Inc.讀取他在部落格 jonwiggs.com 或直接在 Jon_Wiggs@yahoo.com。