同應(yīng)用程序或企業(yè)層次的任何加密策略一樣，加密和解密基礎(chǔ)結(jié)構(gòu)遠(yuǎn)未成功。實(shí)際問題在于密鑰存儲(chǔ)和密鑰持久性。由加密數(shù)據(jù)提供的數(shù)據(jù)安全僅取決于使用的密鑰，此問題比人們最初想到的要難得多。我所介紹的系統(tǒng)已經(jīng)在各處存儲(chǔ)了加密密鑰，從直接存儲(chǔ)在源代碼中到存儲(chǔ)在巧妙命名的文本文件，以及存儲(chǔ)在難以找到的目錄中的平面文件中。

　　考慮在云環(huán)境中存儲(chǔ)和保留密鑰的位置時(shí)，密鑰持久性的重要問題浮現(xiàn)出來。某些人表示擔(dān)心通過在云中保存密鑰，您會(huì)受到來自云本身的安全威脅。也就是說，如果某人對(duì)您的數(shù)據(jù)具有物理訪問權(quán)限，默認(rèn)情況下可能不會(huì)加密磁盤中存儲(chǔ)的數(shù)據(jù)（對(duì)于 Windows Azure 也是如此）。考慮到 SQL Azure 尚未支持加密，這成為在規(guī)劃和設(shè)計(jì)解決方案時(shí)考慮的安全決策。與任何安全性實(shí)現(xiàn)一樣，必須對(duì)風(fēng)險(xiǎn)進(jìn)行度量、權(quán)衡和緩解。

　　但這并不意味著云平臺(tái)（通常情況下）和 Windows Azure（特別情況下）在本質(zhì)上不安全?？赡転槟峁┑钠渌x項(xiàng)呢？

　　現(xiàn)在需要注意的是，應(yīng)用程序始終不應(yīng)將由 Windows Azure 提供的任何密鑰用作加密數(shù)據(jù)的密鑰。示例如下：由 Windows Azure 提供用于存儲(chǔ)服務(wù)的密鑰。這些密鑰被配置為可以輕松旋轉(zhuǎn)，以提高安全性或防止某種原因遭到破壞。換句話說，以后可能不存在密鑰，并且可能分布極其廣泛。

　　在 Windows Azure Storage 服務(wù)中存儲(chǔ)您自己的密鑰庫是一個(gè)保存某些機(jī)密信息的好方法，因?yàn)槟梢允褂迷诙嘧鈶舡h(huán)境中保證安全的數(shù)據(jù)并使用您自己的存儲(chǔ)密鑰保證安全。這不同于將存儲(chǔ)密鑰用作您的加密密鑰。實(shí)際上，如同任何其他存儲(chǔ)文件一樣，可使用存儲(chǔ)服務(wù)密鑰訪問密鑰庫。實(shí)現(xiàn)非常簡單。例如，假設(shè)您想將自己的密鑰庫作為簡單文本文件來實(shí)現(xiàn)，以保留某些機(jī)密信息。相對(duì)于隊(duì)列或表存儲(chǔ)服務(wù)而言，最好作為數(shù)據(jù)存儲(chǔ)在 blob 服務(wù) API 中。存儲(chǔ)服務(wù)的 blob 區(qū)域是二進(jìn)制音頻和圖像甚至文本文件等數(shù)據(jù)的最佳位置。服務(wù)的隊(duì)列部分著重介紹了保護(hù)不會(huì)長期保留的小型數(shù)據(jù)對(duì)象的消息傳送的安全。表存儲(chǔ)系統(tǒng)非常適合于需要在特定部分保留和訪問的結(jié)構(gòu)化數(shù)據(jù)和信息，這與數(shù)據(jù)庫中的關(guān)系數(shù)據(jù)完全相同。

首先，將密鑰保存在 CSP 密鑰容器中。這是用于存儲(chǔ)公鑰的最佳選項(xiàng)，不具有對(duì)該服務(wù)器的物理訪問權(quán)限，很難對(duì)該密鑰進(jìn)行檢索。對(duì)于 Windows Azure（其中，應(yīng)用程序和數(shù)據(jù)的位置很抽象），這將使查找和檢索以這種方式存儲(chǔ)的公鑰極其困難。創(chuàng)建密鑰存儲(chǔ)容器非常簡單；下面是使用創(chuàng)建密鑰的 RSA 提供程序的一個(gè)示例。如果密鑰容器已存在，會(huì)自動(dòng)將其密鑰加載到該提供程序：

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

　　此外，還提供了您可以根據(jù)需要考慮的其他選項(xiàng)。例如，您可以使用特定標(biāo)記為創(chuàng)建該容器的用戶保證密鑰的安全。可使用 CspParameters 標(biāo)記成員完成此操作：

CspParam.Flags　=　CspProviderFlags.UseUserProtectedKey;

　　現(xiàn)在，使用 Windows Azure 存儲(chǔ)密鑰創(chuàng)建一個(gè) blob API 請(qǐng)求。該請(qǐng)求本身要求使用簽名字符串和正確的請(qǐng)求標(biāo)題。正確的標(biāo)題格式為：

Authorization="[SharedKey|SharedKeyLite]　:"

　　在本示例中，我希望最大程度地提高保留的機(jī)密數(shù)據(jù)的安全性，因此我將使用 SharedKey 授權(quán)方法。此標(biāo)題的簽名部分是一個(gè)基于哈希的身份驗(yàn)證代碼，由 SHA256 算法和您的存儲(chǔ)密鑰針對(duì)簽名中的數(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"

　如前所述，然后會(huì)生成 base64 編碼哈希并將其用作標(biāo)題中的簽名。然后，只有以下人員才能訪問該密鑰文件：其應(yīng)用程序在 Windows Azure 云中的應(yīng)用程序空間中運(yùn)行并有權(quán)訪問您的存儲(chǔ)密鑰。因此，借助密鑰持久性，您既可以管理 Windows Azure 框架外部的密鑰，還可以管理云本身內(nèi)部的密鑰。

　　密鑰和安全威脅

　　至少值得簡要介紹的一項(xiàng)是密鑰安全性。這與如何保留和存儲(chǔ)密鑰略有不同。密鑰本身實(shí)質(zhì)上是具有極高級(jí)別的平均信息量（也就是極高級(jí)別的隨機(jī)性）的字符串。實(shí)際上，這可能會(huì)導(dǎo)致查找系統(tǒng)中的密鑰的常見的攻擊進(jìn)程。例如，如果轉(zhuǎn)儲(chǔ)硬盤上的內(nèi)存或數(shù)據(jù)區(qū)域，則具有極高平均信息量的區(qū)域是您開始查找密鑰的最佳位置。

　　除了基于應(yīng)用程序的需要選擇很好的安全實(shí)踐和保護(hù)數(shù)據(jù)的安全之外，您還有其他辦法保護(hù)自身的安全嗎？首先，始終假定您解密、加密和保護(hù)數(shù)據(jù)安全所使用的過程為所有攻擊者所熟知。記住這一點(diǎn)后，確保定期交替使用您的密鑰并保證其安全。僅為必須利用這些密鑰的人員提供密鑰，并盡量減少暴露不受控制的密鑰的機(jī)會(huì)。

　　最后，花時(shí)間將您的安全和不安全數(shù)據(jù)流繪制成圖表。請(qǐng)看一下您的數(shù)據(jù)流往的位置和流去途徑、存儲(chǔ)機(jī)密的位置以及特別是數(shù)據(jù)跨越邊界（例如，公共網(wǎng)絡(luò)和專用網(wǎng)絡(luò)）的位置。這將使您很好地了解公開數(shù)據(jù)的位置并允許您通過直接遷移風(fēng)險(xiǎn)的計(jì)劃來應(yīng)對(duì)這些風(fēng)險(xiǎn)。

　　曾有人問過我一個(gè)相關(guān)問題：Windows Azure 是否支持 SSL。簡短的回答是“是”。Windows Azure 對(duì)于基于 Web 的服務(wù)和不支持 SSl 的應(yīng)用程序來說可能不是一個(gè)功能非常強(qiáng)大的云平臺(tái)。

　　使用 SQL Azure 進(jìn)行加密

　　SQL Server 2008 的發(fā)布引入了一個(gè)新功能：透明數(shù)據(jù)加密 (TDE)。SQL Server 第一次可以僅憑比 SQL Server 2005 中提供的有限加密稍多一點(diǎn)的工作完全加密其數(shù)據(jù)。但是，SQL Azure 存儲(chǔ)的初始版本尚不支持?jǐn)?shù)據(jù)庫級(jí)加密，盡管這是未來版本中考慮的功能。應(yīng)注意的是，SQL Azure 僅可通過端口 1433 和 TCP 連接使用；目前還無法對(duì)其他端口公開。

盡管此功能尚未集成到 Windows Azure 中，但是開發(fā)人員或設(shè)計(jì)人員應(yīng)牢記 SQL Azure 的幾個(gè)安全功能。首先，SQL Azure 支持使用表格格式數(shù)據(jù)流 (TDS)。這表示，大多數(shù)情況下，您可以像以前一樣連接數(shù)據(jù)庫并與該數(shù)據(jù)庫進(jìn)行交互。絕對(duì)值得考慮利用 ADO.NET 加密和受信任的服務(wù)器證書，特別是當(dāng)從云外部訪問您的 SQL Azure 數(shù)據(jù)庫時(shí)。

　　正確組合中的連接屬性 Encrypt=True 和 TrustServerCertificate = False 將確保數(shù)據(jù)傳輸?shù)陌踩圆椭乐怪虚g人攻擊。這也是連接到 SQL Azure 的要求 — 您無法連接到 SQL Azure，除非已啟用連接級(jí)別的加密。

　　您應(yīng)當(dāng)熟悉的 SQL Azure 的第二個(gè)安全功能是 SQL Azure 防火墻。這將是使用過本地軟件防火墻甚至是 SQL Server 安全外圍應(yīng)用工具集的人比較熟悉的工具。它使您能夠允許或阻止從各種源一直到特定 IP 地址或范圍的連接?？赏ㄟ^ SQL Azure 門戶管理 SQL Azure 防火墻或使用提供的存儲(chǔ)進(jìn)程（如 sp_set_firewall_rule 和 sp_delete_firewall_rule）直接在主數(shù)據(jù)庫中對(duì)其進(jìn)行管理。

　　與任何 SQL Server 實(shí)現(xiàn)一樣，還必須嚴(yán)格控制用戶帳戶管理。SQL Azure 中的防火墻確實(shí)是一個(gè)很好的工具，但它不應(yīng)該依賴其本身。還應(yīng)使用具有強(qiáng)密碼和使用特定權(quán)限配置的用戶帳戶來完善您的數(shù)據(jù)安全模型。

　　這些新工具可以使 SQL Azure 成為對(duì)基于云的應(yīng)用程序非常嚴(yán)密的安全托管平臺(tái)。如果您第一次試用此服務(wù)，請(qǐng)記住，必須對(duì) SQL Azure 防火墻進(jìn)行初始化配置后，才可以進(jìn)行連接。必須首先通過 SQL Azure Web 門戶完成此操作，但是如上所述，稍后便可直接在主數(shù)據(jù)庫中進(jìn)行。

不變性和內(nèi)存資源

　　什么是不變性？不變性在面向?qū)ο蟮木幊讨袃H意味著在初始創(chuàng)建對(duì)象后無法修改其狀態(tài)。Microsoft .NET Framework 中的一個(gè)具體示例是字符串類。在代碼中更改了字符串的值后，只需棄用內(nèi)存中的原始字符串并創(chuàng)建一個(gè)用于存儲(chǔ)新值的新字符串對(duì)象。

　　為什么從安全性的角度講這很重要？只要服務(wù)器處于聯(lián)機(jī)狀態(tài)并且不重新啟動(dòng)，該字符串可以始終保留在內(nèi)存中。您真的無法確定字符串將在內(nèi)存中保留多長時(shí)間。這在考慮如何在代碼中存儲(chǔ)信息（例如，加密密鑰或加密和解密數(shù)據(jù)的副本）時(shí)非常重要。內(nèi)存中數(shù)據(jù)遺跡很可能留下將秘密透露給狡猾的數(shù)據(jù)盜賊的信息。

　　由于此不變性，強(qiáng)烈建議將此類數(shù)據(jù)存儲(chǔ)在緩沖區(qū)（如字節(jié)數(shù)組）中。這樣，當(dāng)您使用此信息完成操作后，您可以使用 0 或任何其他數(shù)據(jù)覆蓋該緩沖區(qū)來確保該數(shù)據(jù)不再位于內(nèi)存中。

　　由于 Windows Azure 是云環(huán)境，曾經(jīng)有人問我，是否仍需要考慮這些，這是一個(gè)很好的問題。仍需要考慮這些，在 Windows Azure 系統(tǒng)中，各個(gè)應(yīng)用程序之間相互獨(dú)立。這通常會(huì)使透露內(nèi)存中的數(shù)據(jù)變得異常簡單。很難將應(yīng)用程序與云中的內(nèi)存空間相關(guān)聯(lián)。但是，我仍建議使用此方法時(shí)要格外謹(jǐn)慎并在執(zhí)行操作后進(jìn)行清理。您可能不會(huì)始終在云中運(yùn)行此段代碼，且其他漏洞可能會(huì)在將來將自身公開。不需要太擔(dān)心，保持這個(gè)習(xí)慣并堅(jiān)持按此方法執(zhí)行操作即可。

　　在圖 3 中，我已修改了生成隨機(jī)整數(shù)的上一示例。我在此處添加了一些錯(cuò)誤處理以確保具有在任何情況下都始終運(yùn)行的 finally 塊。我正在該塊中通過字節(jié)數(shù)組中的值執(zhí)行非常簡單的迭代，使用零值覆蓋各個(gè)位置。這將覆蓋內(nèi)存中的數(shù)據(jù)，因?yàn)樽止?jié)數(shù)組具有可變性。我知道該數(shù)字不再包含在歸此成員執(zhí)行的操作所有的內(nèi)存中?？蓪?duì)用作項(xiàng)目（例如密鑰、初始化向量和加密或解密數(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;　
　　}　
　}　
}

　　消息隊(duì)列

　　Windows Azure 隊(duì)列為 Microsoft 消息隊(duì)列 (MSMQ) 服務(wù)提供了一組類似的功能，這些服務(wù)對(duì)企業(yè) Windows 應(yīng)用程序通用。Windows Azure 中的此消息隊(duì)列服務(wù)以先進(jìn)先出 (FIFO) 的方式存儲(chǔ)基于文本的、大小不超過 8KB 的消息。這允許在不同的服務(wù)器（或像本示例這樣，在云中）運(yùn)行服務(wù)和應(yīng)用程序以采用安全和分發(fā)式方法進(jìn)行交互并相互之間發(fā)送可操作消息。

　　有 5 個(gè)允許您將消息推入到隊(duì)列、查看消息、推出消息等等的基本功能。最常提出的問題是這些消息到底有多安全？

　　當(dāng)前受 MSMQ 支持的許多功能在 Windows Azure 消息傳送 API 中還不受支持。然而，存在相似之處。對(duì)于 blob 數(shù)據(jù)服務(wù)，消息傳送服務(wù)利用相同的 REST get 和 put 界面?？稍诖a中或使用 URI 和 Web 請(qǐng)求調(diào)用編寫和讀取消息，可使用 SSL 針對(duì)不安全網(wǎng)絡(luò)中的請(qǐng)求對(duì)該調(diào)用進(jìn)行加密。這表示傳送請(qǐng)求的過程是經(jīng)過加密的。

　　另外，對(duì)于 Windows Azure 中的其他存儲(chǔ)服務(wù)，對(duì)消息隊(duì)列的任何訪問必須利用同一存儲(chǔ)服務(wù)密鑰。只有有權(quán)訪問該密鑰的應(yīng)用程序才能查看這些隊(duì)列或向這些隊(duì)列中添加消息。這使對(duì)這些消息的其他加密操作有點(diǎn)多余，除非這些消息的主體將保留安全網(wǎng)絡(luò)或安全應(yīng)用程序空間。

　　總結(jié)

　　在目前面向服務(wù)的體系結(jié)構(gòu)和解決方案的趨勢之下，很少人會(huì)想到在云應(yīng)用程序中開展業(yè)務(wù)。多租戶環(huán)境（例如 Windows Azure）中的數(shù)據(jù)和服務(wù)的隔離是放眼于使用私有數(shù)據(jù)的人們最關(guān)注的問題之一。

　　與所有新平臺(tái)一樣，安全和加密功能將繼續(xù)在 Windows Azure 平臺(tái)中不斷改進(jìn)。Microsoft 花費(fèi)了巨大精力在以下方面：不僅提供安全、隔離環(huán)境，還要公開針對(duì)這些度量的公共證書所得成果。這應(yīng)該會(huì)使工程師堅(jiān)信，Microsoft 希望成為安全性和保持系統(tǒng)和應(yīng)用程序?yàn)殒i定狀態(tài)方面的親密合作伙伴。