Windows Azure 安全最佳實踐 - 第 7 部分：提示、工具和編碼最佳實踐

在撰寫這一系列文章的過程當中，我總結出了不少最佳實踐。在這篇文章中，我介紹了在保護您的WindowsAzure應用程序時須要考慮的更多事項。

下面是一些工具和編碼提示與最佳實踐：

· 在操做系統上運行

o   獲取最新的安全補丁

o   儘可能以部分信任模式運行

·  錯誤處理

o   如何實施重試邏輯

o   記錄 Windows Azure中的錯誤

·  Azure存儲的訪問權限

o   Blob的訪問權限

o   存儲鏈接字符串

o   門衛模式

o   旋轉存儲密鑰

o   用於確保數據安全的加密服務

在操做系統上運行

獲取最新的安全補丁

當使用 Visual Studio建立新的應用程序時，默認行爲是按以下方式在 ServiceConfiguration.cscfg文件中設置來賓操做系統版本：

osFamily="1"osVersion="*"

這很好，由於您將自動得到更新，這也是 PaaS的主要優勢之一。但這並不是最佳作法，由於您使用的操做系統不是最新版本。爲了使用最新的操做系統版本 (Windows Server 2012 R2)，應按以下方式進行設置：

osFamily="4" osVersion="*"

遺憾的是，許多客戶決定固定使用某個特定的操做系統版本，但願經過避免來賓操做系統更新來增長正常運行時間。這種作法僅適用於企業客戶：他們系統地測試staging部署中的每次更新，而後計劃對在生產部署中運行的關鍵業務應用程序進行 VIP交換。對於其餘不會測試每一個來賓操做系統更新的客戶來講，不配置自動更新會將 Windows Azure 應用程序置於危險的處境。

-- 來源：開發Windows Azure 應用程序的故障排除最佳實踐

儘可能以部分信任模式運行

Cloud Service默認狀況下，部署到 Windows Azure的角色將以徹底信任模式運行。若是要調用非 .NET代碼或使用須要徹底信任的 .NET庫，或任何須要管理員權限的代碼或庫，則須要徹底信任。將您的代碼限制爲以部分信任模式運行意味着，任何有權訪問您代碼的人可執行的操做更加有限。

使用部分信任能夠在您的 Web應用程序受到威脅時，限制攻擊者的破壞範圍內。例如，默認狀況下，惡意的攻擊者沒法修改磁盤上的任何 ASP.NET頁面，也沒法更改任何系統二進制文件。

因爲用戶賬戶不是虛擬機上的管理員，使用部分信任會增長更多的限制，多於 Windows 自動施加的限制。此信任級別經過 .NET的代碼訪問安全性(CAS)支持強制執行。

部分信任與 .NET中的「中等信任」級別相似。僅授予對某些資源和操做的訪問權限。一般，您的代碼僅能經過 TCP鏈接到外部 IP 地址，而且僅能訪問其「本地存儲」中的文件和文件夾（而非系統上的任何位置）。您的代碼使用的任何庫必須以部分信任模式運行，或特別標記爲「容許部分信任的調用方」屬性。

您能夠在服務定義文件中明確配置角色的信任級別。服務定義架構提供了WebRole元素和WorkerRole元素的enableNativeCodeExecution屬性。要以部分信任模式運行您的角色，必須在WebRole或WorkerRole元素上添加enableNativeCodeExecution屬性，並將其設置爲false。

可是，部分信任限制了應用程序的功能。因爲一些微不足道的緣由，一些有用的庫（如用於訪問註冊表或訪問衆所周知的文件位置的庫）沒法在此類環境中運行。即便 Microsoft本身的一些框架也不會在此環境中運行，由於它們沒有設置「partially trustedcaller」屬性。

有關以部分信任模式運行的限制，請參閱Windows Azure部分信任策略參考。

處理錯誤

Windows Azure 可以自我修復，您的應用程序能夠嗎？

重試邏輯

瞬態故障錯誤是因爲一些臨時狀況（如網絡鏈接或服務不可用等問題）致使的。一般，若是您很快重試致使瞬態錯誤的操做，將會發現錯誤已消失。

不一樣的服務可能會有不一樣的瞬態故障，而且不一樣的應用程序所需的故障處理策略也不一樣。

雖然它看上去彷佛與安全無關，但將重試邏輯嵌入應用程序是一個最佳作法。

Azure 存儲

使用隨附 SDK的 Windows Azure Storage Client Library已經具有所需的重試行爲。您能夠經過設置RetryPolicy屬性在任何存儲客戶端上設置重試行爲。

SQL、Service Bus、緩存和 Azure存儲

可是 SQL Azure不會提供現成的默認重試機制，由於它使用的是 SQL Server客戶端庫。Service Bus也不會提供重試機制。

所以，Microsoft模式與實踐團隊和Windows Azure客戶諮詢團隊開發了瞬態故障處理應用程序塊。該塊提供處理特定 SQL Azure、存儲、Service Bus和緩存狀況的多種方式。

瞬態故障處理應用程序塊中包含有關當您使用應用程序中的如下 Windows Azure服務時可能出現的瞬態故障的信息：

·SQL Azure

·Windows Azure ServiceBus

·Windows Azure存儲

·Windows Azure緩存服務

目前，該塊包括加強的配置支持、對包裝異步調用的加強支持，實現了塊的重試策略與 Windows Azure存儲重試機制的集成，適用於企業庫依賴注入容器。

捕捉錯誤

很遺憾，任何系統都不可避免地會出現故障，Windows Azure也確定會出現故障。即便使用重試邏輯，您偶爾也會遇到故障。您能夠將自定義的錯誤處理添加到 ASP.NET Web應用程序。自定義錯誤處理能夠簡化調試並提升客戶滿意度。

Eli Robillard 是 Microsoft MVP 計劃的一員，他的文章ASP.NET的豐富自定義處理介紹瞭如何建立錯誤處理機制，該機制對用戶很是友好而且仍提供了開發人員須要的詳細技術信息。

若是顯示錯誤頁面，它應該在不犧牲美感的前提下爲開發人員和最終用戶提供服務。理想的錯誤頁面會保持站點的外觀和感受，具有爲內部開發人員（經過 IP地址識別）提供詳細錯誤信息的能力，同時確保不向最終用戶提供任何詳細信息。相反，它讓用戶輕鬆返回本身尋找的站點，而不會形成混亂。網站管理員應該可以經過電子郵件或在服務器日誌中檢查遇到的錯誤，（可選）而且可以接收來自遇到故障的用戶的反饋。

記錄 Windows Azure中的錯誤

ELMAH（錯誤記錄模塊和處理程序）自己很是有用，只需進行簡單修改便可提供很是有效的方式，用來處理整個 ASP.NET Web應用程序的錯誤記錄。個人同事Wade Wegner在他的文章在 WindowsAzure 中將 ELMAH與表存儲結合使用中介紹了他建議的步驟。

當 ELMAH開始運行 Web 應用程序並正確配置後，您便可得到如下功能，而無需更改任一代碼行：

· 記錄幾乎全部未處理的異常。

· 可遠程查看已記錄異常完整記錄的網頁。

· 有一個網頁能夠用來遠程查看任何記錄的異常的完整詳細信息，包括色彩斑斕的 stack trace。

· 在不少狀況下，您能夠檢查 ASP.NET爲給定異常生成的原始黃屏死機，即便在關閉customErrors模式的狀況下也是如此。

· 在出現每一個錯誤時會發出電子郵件通知。

· 記錄中最後 15個錯誤的 RSS 訂閱。

要了解有關 ELMAH的更多信息，請參閱 MSDN文章使用 HTTP模塊和處理程序建立可插入的ASP.NET組件，由Scott Mitchell和Atif Aziz共同撰寫。另請參閱ELMAH項目頁面。

遠程訪問錯誤

有許多可用於遠程管理 Windows Azure存儲賬戶的方案。例如，在開發和測試期間，您可能要可以檢查表、隊列和 Blob的內容，以驗證您的應用程序是否如預期同樣運行。您可能還須要將測試數據直接插入到存儲中。

在生產環境中，您可能須要在故障排除期間檢查應用程序存儲的內容，或查看您保留的診斷數據。您可能還但願下載診斷數據進行離線分析，並可以刪除存儲的日誌文件以下降存儲成本。

經過Web搜索能夠發現愈來愈多可充當這些角色的第三方工具。請參閱Windows Azure存儲管理工具獲取一些有用的工具。

存儲的訪問權限

密鑰

一個緊急注意事項是，任何應用程序都不該將 Windows Azure提供的任何密鑰用做加密數據的密鑰。例如 Windows Azure爲存儲服務提供的密鑰。這些密鑰已配置爲容許出於安全性目的，或者當因爲任何緣由受到威脅時輕鬆旋轉。換言之，它們未來可能不存在，而且可能分發範圍太普遍。

旋轉密鑰

當您建立存儲賬戶時，您的賬戶已分配兩個 256位賬戶密鑰。其中一個密鑰必須做爲 HTTP(S)請求的一部分在頭中指定。提供兩個密鑰，是爲了進行密鑰旋轉，以保持數據的良好安全性。一般，您的應用程序會使用其中一個密鑰來訪問數據。而後在一段時間後（取決於您），您將應用程序切換爲使用另一個密鑰。若是您知道您的所有應用程序都已經使用另外一個密鑰，您能夠生成一個新祕鑰,這將自動做廢第一個密鑰。以這種方式使用兩個密鑰，您的應用程序就能夠訪問數據，而不會產生任何停機時間。

請參閱如何查看、複製和從新生成Windows Azure存儲賬戶的訪問密鑰，瞭解如何查看和複製 Windows Azure存儲賬戶的訪問密鑰並執行主要和輔助訪問密鑰的滾動從新生成。

限制對 Blob的訪問

默認狀況下，僅存儲賬戶的全部者可訪問存儲容器和其中的任何 Blob。若是要給匿名用戶提供容器及其 Blob的讀取權限，您能夠設置容器權限以容許公共訪問。匿名用戶可在可供公衆訪問的容器中讀取 Blob，而無需對請求進行身份驗證。請參閱限制對容器和Blob的訪問。

共享訪問簽名是授予容器和 Blob的訪問權限的 URL。共享訪問簽名授予 URL已授予權限指定的 Blob服務資源的訪問權限。當在某些具備 HTTP請求的狀況下使用共享訪問簽名時須要當心，由於 HTTP請求會在互聯網上以明文形式公開完整的 URL。

經過指定共享訪問簽名，您能夠向用戶授予權限，容許其在指定時間段內訪問特定 Blob或某個指定容器中任何 Blob的 URL。您還能夠指定可在經過共享訪問簽名訪問的 Blob上執行的操做。支持的操做包括：

·  讀取和寫入 Blob內容、塊列表、屬性和元數據

·  刪除 Blob

·  Leasing Blob

·  建立 Blob快照

·  列出容器中的 Blob

塊 Blob和頁面 Blob 都支持共享訪問簽名。

若是共享訪問簽名的某些權限不許備向公衆開放，那麼它的訪問策略應使用所需的最小權限進行構建。此外，共享訪問簽名應經過 HTTPS通訊安全地分配給指定用戶，應與容器級別的訪問策略相關聯以進行吊銷，而且應爲簽名指定儘量短的有效期。

請參閱建立共享訪問簽名和使用共享訪問簽名(REST API)。

存儲鏈接字符串

若是您有某個託管服務使用 Windows Azure Storage Client Library訪問 Windows Azure存儲賬戶，建議您將鏈接字符串存儲在服務配置文件中。經過將鏈接字符串存儲在服務配置文件中，已部署服務能夠響應配置更改，而無需從新部署應用程序。

在如下狀況下，這樣作會頗有利：

· 測試 –在將應用程序部署到staging環境時使用測試賬戶，而且當您將應用程序移到生產環境時必須將其切換爲 Live賬戶。

· 安全性 –若是因爲正在使用的密鑰受到威脅致使您必須旋轉存儲賬戶的密鑰。

有關配置鏈接字符串的更多信息，請參閱配置鏈接字符串。

有關使用鏈接字符串的更多信息，請參閱讀取存儲客戶端庫的配置設置和處理已更改的設置。

門衛設計模式

門衛是一種設計模式，其中存儲的訪問權限需進行協商，以便經過限制特權角色在專用內部渠道上的通訊交互並僅與其餘 Web role/workerrole進行交互，以儘可能減少特權角色的攻擊面。

該模式在 Microsoft下載中的文章開發WindowsAzure 應用程序的最佳安全作法中進行了說明。

這些角色應部署在單獨的 VM上。

 

即便 Web role被成功攻擊，也不會泄漏特權密鑰材料。使用兩個角色的如下示例是對該模式的最好詮釋：

·門衛 –爲來自 Internet的請求提供服務的 Web role。因爲這些請求多是惡意的，門衛不被信任用於任何其餘職責，除非驗證了其收到的輸入。門衛在託管代碼中實施並以 Windows Azure部分信任模式運行。此角色的服務配置設置不包含用於 Windows Azure存儲的任何共享密鑰信息。

·KeyMaster –特權後端 worker role，僅接收來自門衛的輸入，並經過安全渠道進行接收（即，可經過 HTTPS確保安全性的內部端點或隊列存儲）。KeyMaster經過門衛處理其訂閱的存儲請求，並假設請求已進行某種程度的淨化。顧名思義，KeyMaster是使用服務配置中的 Windows Azure存儲賬戶信息進行配置的，可從 Blob或表存儲中檢索數據。而後數據能夠反饋回請求客戶端。此設計不須要徹底信任或本機代碼，但它可提供在須要時以較高權限級別運行 KeyMaster的靈活性。

多密鑰

若是沒法將部分信任門衛放置在徹底信任角色以前，則可以使用多密鑰設計模式保護受信任的存儲數據。例如，當 PHP Web role做爲前端 Web role並將部分信任門衛放置在 PHP Web role前面時，可能會使性能下降得沒法接受。

與門衛/KeyMaster模式相比，多密鑰設計模式具備如下優勢：

· 將存儲賬戶的職責分離出來。若是 Web role A泄露了，僅會丟失不受信任的存儲賬戶及關聯密鑰。

· 無需指定任何內部服務端點。相反，會使用多個存儲賬戶。

· 面向外部的不受信任的 Web role無需 Windows Azure部分信任。因爲 PHP不支持部分信任，PHP託管不可進行門衛配置。

請參閱 Microsoft下載中的開發 WindowsAzure 應用程序的最佳安全作法。

加密服務

您可使用加密來確保應用程序層數據的安全。加密服務提供程序 (CSP)是系統程序接口中顯示的加密標準、算法和函數的實施。

Jonathan Wiggs 在 MSDN 雜誌中發表了一篇文章Windows Azure 中的加密服務和數據安全，這篇文章生動地說明了如何在應用程序中提供這類服務。他解釋說：「一致的建議是永遠不要建立您本身的加密算法或使用專有加密算法。.NET CSP 中提供的算法已通過證實和測試並具備多年的公衆支持。」

您能夠選擇下面的多種選項。Microsoft提供了：

Microsoft Base Cryptographic Provider。一組可導出到其餘國家或地區的普遍的基本加密功能。

Microsoft Strong Cryptographic Provider。Microsoft Base Cryptographic Provider 的擴展，在 Windows 2000及更高版本中提供。

Microsoft Enhanced Cryptographic Provider。Microsoft Base Cryptographic Provider 經過更長的密鑰和其餘算法得出的結果。

Microsoft AES Cryptographic Provider。Microsoft Enhanced Cryptographic Provider 支持 AES加密算法。

Microsoft DSS Cryptographic Provider。經過安全哈希算法 (SHA)和數字簽名標準 (DSS) 算法提供哈希、數據簽名和簽名驗證功能。

Microsoft Base DSS and Diffie-Hellman Cryptographic Provider。DSS Cryptographic Provider 的超集，同時支持使用安全哈希算法 (SHA)和數字簽名標準 (DSS)算法進行 Diffie-Hellman密鑰交換、哈希、數據簽名和簽名驗證。

Microsoft Enhanced DSS and Diffie-Hellman CryptographicProvider。支持 Diffie-Hellman 密鑰交換（40位的 DES 衍生品）、SHA哈希、DSS數據簽名和 DSS 簽名驗證。

Microsoft DSS and Diffie-Hellman/Schannel CryptographicProvider。支持哈希、使用 DSS 進行數據簽名、生成 Diffie-Hellman (D-H)密鑰、交換 D-H 密鑰以及導出 D-H 密鑰。此 CSP 支持 SSL3和 TLS1 協議的密鑰派生。

Microsoft RSA/Schannel Cryptographic Provider。支持哈希、數據簽名和簽名驗證。算法標識符 CALG_SSL3_SHAMD5 用於 SSL 3.0和 TLS 1.0 客戶端身份驗證。此 CSP 支持 SSL2、PCT1、SSL3和 TLS1 協議的密鑰派生。

Microsoft RSA Signature Cryptographic Provider。提供數據簽名和簽名驗證。

密鑰存儲

經過加密數據提供的數據安全性僅與使用的密鑰的安全性相同，而且此問題要比人們起初預想的難度要高得多。您不該該使用 Azure存儲密鑰，而可使用上一節中的提供程序建立您本身的密鑰。

在 Windows Azure存儲服務內部存儲您本身的密鑰庫是保存一些機密信息的不錯選擇，由於您能夠相信這些數據在多租戶環境中的安全性並經過您本身的存儲密鑰確保其安全性。這與將存儲密鑰用做加密密鑰有所不一樣。相反，您可使用存儲服務密鑰隨意訪問密鑰庫,就像任何其餘存儲文件同樣。

密鑰管理

首先，要始終假設您用來解密、加密和保護數據的流程爲任何攻擊者所熟知。請牢記這一點，確保按期循環您的密鑰以保證其安全性。僅將密鑰提供給須要的用戶，避免將密鑰暴露得過於普遍而不受您控制。

清理

當您使用密鑰時應進行清理，建議將此類數據存儲在緩衝區，如字節數組。這樣一來，清理完信息後，您就能夠用零或任何其餘數據（確保該數據已不在該內存中）覆蓋緩衝區。

您仍然能夠從 Jonathan的文章Windows Azure 中的加密服務和數據安全中研究和學習如何組合全部的組件。

總結

安全性絕非開發流程的最後一步。偏偏相反，它應該始終是開發流程的一部分，您應該根據您本身的應用程序的需求制定安全性決策。

您所使用的方法應確保您的應用程序開發週期中的每一個環節都考慮到安全性。檢查您的體系結構和代碼中可能容許其餘用戶訪問您的數據的地方。

Windows Azure 使安全性成爲成爲一項共同責任。經過平臺即服務，您能夠更加專一於您的應用程序和您本身的安全性需求。

在這一系列博客文章中，我介紹了在 Windows Azure中如何確保應用程序的安全。這一系列文章分爲七個部分，介紹了威脅、如何響應、在應用程序生命週期中可採起哪些流程，並規定了根據應用程序的需求實施最佳實踐的方式。

我還介紹了一些集成用戶標識的方法，以及 Azure提供的一些使用戶可以以新方式訪問雲應用程序的服務。

如下是本系列中的文章的連接：

·  Windows Azure 安全最佳實踐 - 第 1 部分：深度解析挑戰防護對策 。

·  Windows Azure 安全最佳實踐 - 第 2 部分：Azure 提供哪些現成可用的安全機制。

· Windows Azure 安全最佳實踐 - 第 3 部分：肯定安全框架。

· Windows Azure 安全最佳實踐 - 第 4 部分：須要採起的其餘措施。

· Windows Azure 安全最佳實踐 - 第 5 部分：基於Claims的標識，單點登陸。

· Windows Azure 安全最佳實踐 - 第 6 部分：Azure 服務如何擴展應用程序安全性。

· Windows Azure 安全最佳實踐 - 第 7 部分：提示、工具和編碼最佳實踐。

本文翻譯自：

http://blogs.msdn.com/b/usisvde/archive/2012/03/15/windows-azure-security-best-practices-part-7-tips-tools-coding-best-practices.aspx