電子發(fā)燒友App
Windows Azure 中的加密服務(wù)和數(shù)據(jù)的云安全
概述：許多早期云用戶的云平臺都存在安全問題。我們來重溫一下 Windows Azure中的某些加密服務(wù)和提供程序，以及云中應(yīng)用程序的某些安全隱患。
Windows Azure 平臺的許多早期采用者仍對平臺安全及其加密支持存在大量疑問。在此，我將介紹 Windows Azure 平臺內(nèi)加密和相關(guān)安全的一些基本概念。詳細(xì)闡述本主題可能需要很大的篇幅，因此我只打算說明并重溫一下 Windows Azure 中的某些加密服務(wù)和提供程序。任何向 Windows Azure 的過渡也會存在一些安全隱患。
對于任何新平臺或服務(wù)交付方法，您都會面臨新的挑戰(zhàn)。另外還要提醒您，一些典型問題仍然存在，甚至您過去使用的一些相同的解決方案仍將有效。任何應(yīng)用程序工程師或設(shè)計人員都應(yīng)仔細(xì)思考本主題，因為它與您可能存儲及需要保留的數(shù)據(jù)類型有關(guān)。將此方法與系統(tǒng)化方法相結(jié)合，會為您和您的客戶提供優(yōu)質(zhì)服務(wù)。
因此，為什么我會認(rèn)為開發(fā)人員社區(qū)中需要此信息呢？在過去的幾個月中，我發(fā)現(xiàn)社區(qū)站點中有關(guān) Azure 基本安全性的文章越來越多。Microsoft 建議將加密作為保護 Azure 項目的應(yīng)用層數(shù)據(jù)的一部分。但是，構(gòu)建 Windows Azure 平臺的產(chǎn)品設(shè)計人員和開發(fā)人員需要正確理解加密和 .NET 安全模型。
我發(fā)現(xiàn)這么一件事：特定于加密服務(wù)和密鑰存儲的文章的百分比不斷增加。對于 Windows Azure Storage 服務(wù)來說，更是如此。這勾起了我的好奇心，我發(fā)現(xiàn)這是一個值得深入討論的話題。
在撰寫本文的過程中，我將大量使用加密服務(wù)提供程序 (CSP)，在該程序中可實施系統(tǒng)編程接口中的加密標(biāo)準(zhǔn)、算法和函數(shù)。出于本文的目的，我將使用由 Rijndael 加密類提供的對稱加密算法。
加密基礎(chǔ)知識
Windows Azure SDK 擴展了核心 .NET 庫，允許開發(fā)人員集成并使用由 Windows Azure 提供的服務(wù)。對 CSP 的訪問并不僅限于在 Windows Azure 項目和服務(wù)中進行。這意味著您的許多與加密和解密數(shù)據(jù)有關(guān)的開發(fā)將與您習(xí)慣使用的程序集保持一致。但是，基本體系結(jié)構(gòu)有一些更改，即加密數(shù)據(jù)的時間或位置及保存密鑰的位置和方式的問題。本文稍后將討論一些關(guān)鍵數(shù)據(jù)和機密數(shù)據(jù)持久性。 您還能夠訪問 Windows Azure 中加密哈希功能的完整陣列，例如 MD5 和 SHA。以上內(nèi)容對增強任何系統(tǒng)的安全性（如檢測重復(fù)的數(shù)據(jù)、哈希表索引、消息簽名和密碼驗證等）至關(guān)重要。
一致建議始終不創(chuàng)建您自己的加密算法或使用專有加密算法。.NET CSP 中提供的算法已得到證實并經(jīng)過測試，已公開很多年供備份。使用 XOR 創(chuàng)建您自己的加密過程并不相同，并且不提供相同級別的數(shù)據(jù)安全性。
第二個建議是使用 RNGCryptoServiceProvider 類生成隨機數(shù)字。這可以確保您的應(yīng)用程序生成的隨機數(shù)字始終具有極高級別的平均信息量，從而在模式上難以猜測。
以下代碼實現(xiàn)了單個靜態(tài)成員，該成員將返回隨機的 32 位 int 值且滿足加密學(xué)角度上的安全需要。通過使用 Cryptography 命名空間中提供的 RNGCryptoServiceProvider 中的字節(jié)生成器可以實現(xiàn)這一點：
public static int GenerateRandomNumber() {
byte[] GeneratedBytes = new byte[4];
RNGCryptoServiceProvider CSP = new RNGCryptoServiceProvider();
CSP.GetBytes(GeneratedBytes);
return BitConverter.ToInt32(GeneratedBytes, 0);
}
圖 1 顯示了在 Windows Azure 平臺內(nèi)部使用 CSP 的簡單示例。公開了三個公共成員，用于在任何 Windows Azure 應(yīng)用程序中使用。第一個成員接受二進制密鑰和初始化向量 (IV) 及未加密數(shù)據(jù)的二進制緩沖區(qū)并返回其加密的等效方法。第二個成員通過解密數(shù)據(jù)執(zhí)行相反的操作。第三個成員返回為該數(shù)據(jù)計算出的哈希值。在此請注意，我使用 Rijndael CSP 對提供程序進行托管訪問。我還在二進制緩沖區(qū)中存儲數(shù)據(jù)和密鑰并在完成后進行改寫。稍后將在討論不變性時介紹本主題。 圖 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;
}
這是加密數(shù)據(jù)并以字節(jié)數(shù)組形式返回加密結(jié)果的最簡單示例。這不是可以在未進行所有適當(dāng)?shù)陌踩苑治龅那闆r下在安全環(huán)境中使用的代碼，只是一個示例。
圖 2 中的示例幾乎與圖 1 中的示例具有相同的結(jié)構(gòu)。在本例中，我基于相同的密鑰和 IV 解密數(shù)據(jù)，僅將加密的字節(jié)緩沖區(qū)作為參數(shù)使用。這里唯一真正的差別就是當(dāng)創(chuàng)建加密流時，我指定創(chuàng)建對稱解密器而不是先前創(chuàng)建的加密器。
圖 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;
}密鑰存儲和持久性
同應(yīng)用程序或企業(yè)層次的任何加密策略一樣，加密和解密基礎(chǔ)結(jié)構(gòu)遠(yuǎn)未成功。實際問題在于密鑰存儲和密鑰持久性。由加密數(shù)據(jù)提供的數(shù)據(jù)安全僅取決于使用的密鑰，此問題比人們最初想到的要難得多。我所介紹的系統(tǒng)已經(jīng)在各處存儲了加密密鑰，從直接存儲在源代碼中到存儲在巧妙命名的文本文件，以及存儲在難以找到的目錄中的平面文件中。
考慮在云環(huán)境中存儲和保留密鑰的位置時，密鑰持久性的重要問題浮現(xiàn)出來。某些人表示擔(dān)心通過在云中保存密鑰，您會受到來自云本身的安全威脅。也就是說，如果某人對您的數(shù)據(jù)具有物理訪問權(quán)限，默認(rèn)情況下可能不會加密磁盤中存儲的數(shù)據(jù)（對于 Windows Azure 也是如此）。考慮到 SQL Azure 尚未支持加密，這成為在規(guī)劃和設(shè)計解決方案時考慮的安全決策。與任何安全性實現(xiàn)一樣，必須對風(fēng)險進行度量、權(quán)衡和緩解。
但這并不意味著云平臺（通常情況下）和 Windows Azure（特別情況下）在本質(zhì)上不安全。可能為您提供的其他選項呢？
現(xiàn)在需要注意的是，應(yīng)用程序始終不應(yīng)將由 Windows Azure 提供的任何密鑰用作加密數(shù)據(jù)的密鑰。示例如下：由 Windows Azure 提供用于存儲服務(wù)的密鑰。這些密鑰被配置為可以輕松旋轉(zhuǎn)，以提高安全性或防止某種原因遭到破壞。換句話說，以后可能不存在密鑰，并且可能分布極其廣泛。
在 Windows Azure Storage 服務(wù)中存儲您自己的密鑰庫是一個保存某些機密信息的好方法，因為您可以使用在多租戶環(huán)境中保證安全的數(shù)據(jù)并使用您自己的存儲密鑰保證安全。這不同于將存儲密鑰用作您的加密密鑰。實際上，如同任何其他存儲文件一樣，可使用存儲服務(wù)密鑰訪問密鑰庫。實現(xiàn)非常簡單。例如，假設(shè)您想將自己的密鑰庫作為簡單文本文件來實現(xiàn)，以保留某些機密信息。相對于隊列或表存儲服務(wù)而言，最好作為數(shù)據(jù)存儲在 blob 服務(wù) API 中。存儲服務(wù)的 blob 區(qū)域是二進制音頻和圖像甚至文本文件等數(shù)據(jù)的最佳位置。服務(wù)的隊列部分著重介紹了保護不會長期保留的小型數(shù)據(jù)對象的消息傳送的安全。表存儲系統(tǒng)非常適合于需要在特定部分保留和訪問的結(jié)構(gòu)化數(shù)據(jù)和信息，這與數(shù)據(jù)庫中的關(guān)系數(shù)據(jù)完全相同。
首先，將密鑰保存在 CSP 密鑰容器中。這是用于存儲公鑰的最佳選項，不具有對該服務(wù)器的物理訪問權(quán)限，很難對該密鑰進行檢索。對于 Windows Azure（其中，應(yīng)用程序和數(shù)據(jù)的位置很抽象），這將使查找和檢索以這種方式存儲的公鑰極其困難。創(chuàng)建密鑰存儲容器非常簡單；下面是使用創(chuàng)建密鑰的 RSA 提供程序的一個示例。如果密鑰容器已存在，會自動將其密鑰加載到該提供程序：
CspParameters CspParam = new CspParameters();
CspParam.KeyContainerName = "SampleContainerName";
RSACryptoServiceProvider RSAProvider = new
RSACryptoServiceProvider(CspParam);
此外，還提供了您可以根據(jù)需要考慮的其他選項。例如，您可以使用特定標(biāo)記為創(chuàng)建該容器的用戶保證密鑰的安全。可使用 CspParameters 標(biāo)記成員完成此操作：
CspParam.Flags = CspProviderFlags.UseUserProtectedKey;
現(xiàn)在，使用 Windows Azure 存儲密鑰創(chuàng)建一個 blob API 請求。該請求本身要求使用簽名字符串和正確的請求標(biāo)題。正確的標(biāo)題格式為：
Authorization="[SharedKey|SharedKeyLite]
在本示例中，我希望最大程度地提高保留的機密數(shù)據(jù)的安全性，因此我將使用 SharedKey 授權(quán)方法。此標(biāo)題的簽名部分是一個基于哈希的身份驗證代碼，由 SHA256 算法和您的存儲密鑰針對簽名中的數(shù)據(jù)生成。然后，此哈希被編碼為 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 編碼哈希并將其用作標(biāo)題中的簽名。然后，只有以下人員才能訪問該密鑰文件：其應(yīng)用程序在 Windows Azure 云中的應(yīng)用程序空間中運行并有權(quán)訪問您的存儲密鑰。因此，借助密鑰持久性，您既可以管理 Windows Azure 框架外部的密鑰，還可以管理云本身內(nèi)部的密鑰。
密鑰和安全威脅
至少值得簡要介紹的一項是密鑰安全性。這與如何保留和存儲密鑰略有不同。密鑰本身實質(zhì)上是具有極高級別的平均信息量（也就是極高級別的隨機性）的字符串。實際上，這可能會導(dǎo)致查找系統(tǒng)中的密鑰的常見的攻擊進程。例如，如果轉(zhuǎn)儲硬盤上的內(nèi)存或數(shù)據(jù)區(qū)域，則具有極高平均信息量的區(qū)域是您開始查找密鑰的最佳位置。
除了基于應(yīng)用程序的需要選擇很好的安全實踐和保護數(shù)據(jù)的安全之外，您還有其他辦法保護自身的安全嗎？首先，始終假定您解密、加密和保護數(shù)據(jù)安全所使用的過程為所有攻擊者所熟知。記住這一點后，確保定期交替使用您的密鑰并保證其安全。僅為必須利用這些密鑰的人員提供密鑰，并盡量減少暴露不受控制的密鑰的機會。
最后，花時間將您的安全和不安全數(shù)據(jù)流繪制成圖表。請看一下您的數(shù)據(jù)流往的位置和流去途徑、存儲機密的位置以及特別是數(shù)據(jù)跨越邊界（例如，公共網(wǎng)絡(luò)和專用網(wǎng)絡(luò)）的位置。這將使您很好地了解公開數(shù)據(jù)的位置并允許您通過直接遷移風(fēng)險的計劃來應(yīng)對這些風(fēng)險。
曾有人問過我一個相關(guān)問題：Windows Azure 是否支持 SSL。簡短的回答是“是”。Windows Azure 對于基于 Web 的服務(wù)和不支持 SSl 的應(yīng)用程序來說可能不是一個功能非常強大的云平臺。
使用 SQL Azure 進行加密
SQL Server 2008 的發(fā)布引入了一個新功能：透明數(shù)據(jù)加密 (TDE)。SQL Server 第一次可以僅憑比 SQL Server 2005 中提供的有限加密稍多一點的工作完全加密其數(shù)據(jù)。但是，SQL Azure 存儲的初始版本尚不支持?jǐn)?shù)據(jù)庫級加密，盡管這是未來版本中考慮的功能。應(yīng)注意的是，SQL Azure 僅可通過端口 1433 和 TCP 連接使用；目前還無法對其他端口公開。
盡管此功能尚未集成到 Windows Azure 中，但是開發(fā)人員或設(shè)計人員應(yīng)牢記 SQL Azure 的幾個安全功能。首先，SQL Azure 支持使用表格格式數(shù)據(jù)流 (TDS)。這表示，大多數(shù)情況下，您可以像以前一樣連接數(shù)據(jù)庫并與該數(shù)據(jù)庫進行交互。絕對值得考慮利用 ADO.NET 加密和受信任的服務(wù)器證書，特別是當(dāng)從云外部訪問您的 SQL Azure 數(shù)據(jù)庫時。
正確組合中的連接屬性 Encrypt=True 和 TrustServerCertificate = False 將確保數(shù)據(jù)傳輸?shù)陌踩圆椭乐怪虚g人攻擊。這也是連接到 SQL Azure 的要求 — 您無法連接到 SQL Azure，除非已啟用連接級別的加密。
您應(yīng)當(dāng)熟悉的 SQL Azure 的第二個安全功能是 SQL Azure 防火墻。這將是使用過本地軟件防火墻甚至是 SQL Server 安全外圍應(yīng)用工具集的人比較熟悉的工具。它使您能夠允許或阻止從各種源一直到特定 IP 地址或范圍的連接。可通過 SQL Azure 門戶管理 SQL Azure 防火墻或使用提供的存儲進程（如 sp_set_firewall_rule 和 sp_delete_firewall_rule）直接在主數(shù)據(jù)庫中對其進行管理。
與任何 SQL Server 實現(xiàn)一樣，還必須嚴(yán)格控制用戶帳戶管理。SQL Azure 中的防火墻確實是一個很好的工具，但它不應(yīng)該依賴其本身。還應(yīng)使用具有強密碼和使用特定權(quán)限配置的用戶帳戶來完善您的數(shù)據(jù)安全模型。
這些新工具可以使 SQL Azure 成為對基于云的應(yīng)用程序非常嚴(yán)密的安全托管平臺。如果您第一次試用此服務(wù)，請記住，必須對 SQL Azure 防火墻進行初始化配置后，才可以進行連接。必須首先通過 SQL Azure Web 門戶完成此操作，但是如上所述，稍后便可直接在主數(shù)據(jù)庫中進行。
不變性和內(nèi)存資源
什么是不變性？不變性在面向?qū)ο蟮木幊讨袃H意味著在初始創(chuàng)建對象后無法修改其狀態(tài)。Microsoft .NET Framework 中的一個具體示例是字符串類。在代碼中更改了字符串的值后，只需棄用內(nèi)存中的原始字符串并創(chuàng)建一個用于存儲新值的新字符串對象。
為什么從安全性的角度講這很重要？只要服務(wù)器處于聯(lián)機狀態(tài)并且不重新啟動，該字符串可以始終保留在內(nèi)存中。您真的無法確定字符串將在內(nèi)存中保留多長時間。這在考慮如何在代碼中存儲信息（例如，加密密鑰或加密和解密數(shù)據(jù)的副本）時非常重要。內(nèi)存中數(shù)據(jù)遺跡很可能留下將秘密透露給狡猾的數(shù)據(jù)盜賊的信息。
由于此不變性，強烈建議將此類數(shù)據(jù)存儲在緩沖區(qū)（如字節(jié)數(shù)組）中。這樣，當(dāng)您使用此信息完成操作后，您可以使用 0 或任何其他數(shù)據(jù)覆蓋該緩沖區(qū)來確保該數(shù)據(jù)不再位于內(nèi)存中。
由于 Windows Azure 是云環(huán)境，曾經(jīng)有人問我，是否仍需要考慮這些，這是一個很好的問題。仍需要考慮這些，在 Windows Azure 系統(tǒng)中，各個應(yīng)用程序之間相互獨立。這通常會使透露內(nèi)存中的數(shù)據(jù)變得異常簡單。很難將應(yīng)用程序與云中的內(nèi)存空間相關(guān)聯(lián)。但是，我仍建議使用此方法時要格外謹(jǐn)慎并在執(zhí)行操作后進行清理。您可能不會始終在云中運行此段代碼，且其他漏洞可能會在將來將自身公開。不需要太擔(dān)心，保持這個習(xí)慣并堅持按此方法執(zhí)行操作即可。
在圖 3 中，我已修改了生成隨機整數(shù)的上一示例。我在此處添加了一些錯誤處理以確保具有在任何情況下都始終運行的 finally 塊。我正在該塊中通過字節(jié)數(shù)組中的值執(zhí)行非常簡單的迭代，使用零值覆蓋各個位置。這將覆蓋內(nèi)存中的數(shù)據(jù)，因為字節(jié)數(shù)組具有可變性。我知道該數(shù)字不再包含在歸此成員執(zhí)行的操作所有的內(nèi)存中。可對用作項目（例如密鑰、初始化向量和加密或解密數(shù)據(jù)）的數(shù)據(jù)緩沖區(qū)的任何字節(jié)數(shù)組執(zhí)行此操作。
圖 3 清除內(nèi)存中的數(shù)據(jù)
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 隊列為 Microsoft 消息隊列 (MSMQ) 服務(wù)提供了一組類似的功能，這些服務(wù)對企業(yè) Windows 應(yīng)用程序通用。Windows Azure 中的此消息隊列服務(wù)以先進先出 (FIFO) 的方式存儲基于文本的、大小不超過 8KB 的消息。這允許在不同的服務(wù)器（或像本示例這樣，在云中）運行服務(wù)和應(yīng)用程序以采用安全和分發(fā)式方法進行交互并相互之間發(fā)送可操作消息。
有 5 個允許您將消息推入到隊列、查看消息、推出消息等等的基本功能。最常提出的問題是這些消息到底有多安全？
當(dāng)前受 MSMQ 支持的許多功能在 Windows Azure 消息傳送 API 中還不受支持。然而，存在相似之處。對于 blob 數(shù)據(jù)服務(wù)，消息傳送服務(wù)利用相同的 REST get 和 put 界面。可在代碼中或使用 URI 和 Web 請求調(diào)用編寫和讀取消息，可使用 SSL 針對不安全網(wǎng)絡(luò)中的請求對該調(diào)用進行加密。這表示傳送請求的過程是經(jīng)過加密的。
另外，對于 Windows Azure 中的其他存儲服務(wù)，對消息隊列的任何訪問必須利用同一存儲服務(wù)密鑰。只有有權(quán)訪問該密鑰的應(yīng)用程序才能查看這些隊列或向這些隊列中添加消息。這使對這些消息的其他加密操作有點多余，除非這些消息的主體將保留安全網(wǎng)絡(luò)或安全應(yīng)用程序空間。
總結(jié)
在目前面向服務(wù)的體系結(jié)構(gòu)和解決方案的趨勢之下，很少人會想到在云應(yīng)用程序中開展業(yè)務(wù)。多租戶環(huán)境（例如 Windows Azure）中的數(shù)據(jù)和服務(wù)的隔離是放眼于使用私有數(shù)據(jù)的人們最關(guān)注的問題之一。
與所有新平臺一樣，安全和加密功能將繼續(xù)在 Windows Azure 平臺中不斷改進。Microsoft 花費了巨大精力在以下方面：不僅提供安全、隔離環(huán)境，還要公開針對這些度量的公共證書所得成果。這應(yīng)該會使工程師堅信，Microsoft 希望成為安全性和保持系統(tǒng)和應(yīng)用程序為鎖定狀態(tài)方面的親密合作伙伴。
安全，特別是加密的關(guān)鍵之處在于使您的信息和過程很難訪問。我們可以將“很難”定義為超出了任何敵方在數(shù)據(jù)或進程的生命期內(nèi)進入該系統(tǒng)的能力。然而，這是一種基于正在使用的應(yīng)用程序或數(shù)據(jù)的要求的相對定義。這就是我為何在這篇文章中繼續(xù)強調(diào)需要不斷對安全和加密要求進行評估。這對確保可有效地使用這些工具以保護云系統(tǒng)的安全并保護數(shù)據(jù)至關(guān)重要。
工商網(wǎng)監(jiān)
評論