本文概述了微軟的安全結構。NET框架，包括基於證據的安全性、基於角色的安全性、身份驗證和授權的概念，以及獨立存儲、密碼加密和可擴展性。本文還總結了。NET框架安全策略提供給開發人員、管理員和最終用戶。本文假設讀者基本上熟悉。NET Framework公共語言運行庫和管理代碼。
介紹
當前的安全問題
在當今的軟件環境中，應用程序來自許多來源，並執行許多任務。對應用程序代碼的信任是壹個主要要求，因為我們都不希望軟件或信息被破壞。授予權限的安全策略不會允許對敏感信息的不當訪問，也不會將本地計算機暴露給惡意程序，甚至帶有常見錯誤的代碼。
在過去，安全結構提供基於用戶帳戶的隔離和訪問控制——在這些限制內給予代碼完全的訪問權限，並假設特定用戶可以運行的代碼具有相同程度的信任。不幸的是，如果所有程序都代表壹個用戶運行，根據用戶隔離代碼不足以保護壹個程序不被其他用戶使用。另壹方面，不能被完全信任的代碼通常被轉移到“沙箱”模型中執行，代碼在隔離的環境中運行，不訪問大多數服務。
針對當今應用程序的成功安全解決方案必須加強這兩種安全模式之間的平衡。為了完成有用的工作，它必須提供對資源的訪問，並且它需要小心地控制應用程序的安全性，以確保代碼被識別、檢測並被賦予適當的安全級別。的。NET Framework提供了這樣壹種安全模型。
微軟。NET框架安全解決方案
的。NET Framework安全解決方案基於公共語言運行庫(CLR)強化的管理代碼和安全規則的概念。大多數管理代碼需要驗證，以確保其他預定義屬性的類型安全和行為安全。例如，在經過驗證的代碼中，聲明接收4字節值的訪問將拒絕提供8字節參數的調用，因為它不是類型安全的。驗證過程還確保執行流只被傳輸到已知的位置，比如方法入口點——這個過程消除了跳轉到任意位置執行的能力。
驗證將防止執行非類型安全的代碼，並在造成損害之前捕捉許多常見的編程錯誤。通常的弱點——如緩存溢出、讀取任意內存或未初始化的內存、隨機轉移控件——不再可能。這將使最終用戶受益，因為他們在執行代碼之前會檢查代碼。這對開發人員也是有益的，他們會發現許多常見的錯誤(過去是在開發前被捕獲的)現在可以被識別出來，並防止造成損害。
CLR也可以讓非托管代碼運行，但是非托管代碼無法從這些安全措施中受益。特殊權限與調用非管理代碼的能力相關，壹個強有力的安全策略可以確保正確地授予這些權限。時間長了，從非管理代碼遷移到管理代碼會減少調用非管理代碼的頻率。
微軟的組件。NET框架安全機制
基於證據的安全性
的。NET框架引入了“基於證據的安全性”的概念。本質上，它是安全策略所暴露的問題的答案:
組合來自哪個站點？
作文是寫作的基石。NET框架應用程序。它們構成了部署、版本控制、重用、激活範圍和安全認證的基本單元。應用程序的組合從網站下載到客戶端。
該組合是從哪個URL獲得的？
安全策略要求壹個明確的地址，組合就是從這個地址下載的。
組合來自哪個區？
區域是基於代碼位置的安全標準的描述，如Internet、intranet和本地計算機。
組合的強名稱是什麽？
強名稱是由組合的創建者提供的密碼加強的標識符。雖然它不向創建者提供任何證明，但它唯壹地標識了該組合，並確保該組合沒有被破壞。
根據這些問題的答案和其他證據，安全策略可以計算給予組合秤的適當許可。證據可以從各種來源獲得，包括CLR、瀏覽器、微軟ASP.NET和shell——這取決於代碼的來源。
策略驅動的信任模型使用代碼證據。
當組合被調用到內存中時，CLR策略系統收集該組合的證據，並在策略環境中計算該證據，以決定對該組合授予何種權限。然後，CLR策略系統根據評估的證據和組合發出的權限請求授予該組合壹組權限。只有在組合被賦予最小權限集，或者組合根本不需要權限之後，組合的創建者才能知道組合正在正確地工作。這樣的附加要求可以通過對特定許可證的壹個或多個請求被傳送到房間策略系統。
根據許可證請求的類型，策略系統可以進壹步限制授予組合的許可證(刪除不必要的許可證)，甚至拒絕將組合加載到內存中(如果運行組合所需的最低許可證不是由策略授予的)。在沒有任何權限請求的情況下，組合將永遠不會被給予比策略系統將給予的權限更多的權限，並且請求只會進壹步限制所獲得的權限。
安全策略包含許多代碼組，這些代碼組包含應根據證據授予的權限。代碼組描述的許可證可以提供給從特定安全區域獲得的組合，或者提供給由特定發行者簽名的組合，等等。盡管CLR附帶了壹組默認的代碼組(和相關的許可證),但是管理員可以自定義這些CLR安全性以滿足他們的特殊需要。請記住，通過定義與證據相關的代碼組，任何東西都可以作為證據提交，只要安全策略可以使用它。
創建許可證的過程包括評估證據，以確定代碼組適用於哪個級別:企業、計算機和用戶。該策略按上述順序評估這三個級別，然後創建三個級別交錯的權限設置。管理員可以將任何策略級別標記為最終，這將防止進壹步評估其他級別的策略。例如，管理員可以在機器級別終止組合上的策略，這將阻止對該組合應用用戶級別的策略。
策略完成後，將創建許可證的初始設置。組合可以通過在以下三個方面提出具體要求來優化這些許可證:
第壹個方面是指定壹個組合運行時必須具備的最低許可設置。如果沒有給定這些權限，組合將以不同的方式加載到內存中，並將引發異常。
其次，可以指定壹組可選的權限。盡管程序集希望這些權限存在，但如果無法獲得這些權限，它仍然可以被調用到內存中。
最後，表現特別好的群體實際上會拒絕他們不需要的有風險的許可。這三個優化選項在調用時以聲明語句的形式實現。
在運行時，許可證是根據代碼的執行來計算的。右圖總結了這壹過程的順序。組合A3將其證據和來自宿主的證據提供給策略評估器。在創建許可證“G3”時，策略評估器還應該考慮從組合中獲得的許可證請求。組合A3被組合A2調用，組合A2又被組合A1調用。當組合A3執行觸發安全檢查的操作時，A2和A1獲得的許可也應該被檢查，以確保它們具有A3請求的許可權限。在這個過程中，這個過程叫做走棧，要檢查棧中每個組合的權限，以確定給定的權限設置是否包含安全檢查所需的權限。如果堆棧中的每個組合都被賦予了安全檢查所需的權限，則調用將會成功。如果任何組合未能給出所需的權限，堆棧遍歷過程將失敗，並將引發安全異常。
圖1。宿主和組合為策略評估者提供證據，策略評估者使用安全策略和權限請求來確定組合的權限。然後，應用程序中不同運行組件的許可權被用於做出授權決定。
代碼訪問安全堆棧遍歷可以保護代碼免受攻擊。在熟練攻擊中，惡意代碼欺騙可信代碼執行它無法單獨運行的操作——有效地利用代碼的權限來達到惡意目的。開發人員很難防範這樣的攻擊——但是堆棧遍歷保證了如果涉及到信任級別低的代碼，那麽有效的許可證將被降低到信任級別最低的代碼的許可證。
因此，代碼將從源代碼獲得不同的信任級別，並在適合特定代碼執行環境的限制下運行。
免費的安全保障。NET框架調用
某些活動(如讀寫文件、顯示對話框以及讀寫環境變量)可以通過。NET Framework方法包含在框架安全框架中。這使得。NET Framework根據安全策略允許或禁止某項操作，而不需要程序員做額外的工作。雖然據透露，保護資源的管理類的創建者已經在他們的庫中制定了明確的安全要求，但是使用。NET框架類庫訪問受保護的資源，可以自由地使用代碼訪問安全系統。他們不必進行明確的安全呼叫。
管理員可以通過決定授予哪些權限來優化安全策略，然後依靠。NET框架來處理所有的安全操作。代碼訪問安全可以防止大多數惡意攻擊，代碼驗證可以減少緩存溢出和其他會導致安全攻擊的意外行為。因此，應用程序和組件在本質上不受大多數安全問題的影響，這些問題壹直受到本地代碼實現的困擾。
基於角色的安全性
有時，根據經過身份驗證的身份或與代碼執行上下文相關的角色來做出身份驗證決定是合適的。例如，財務和企業軟件可以通過評估角色信息的企業邏輯來加強策略。可以根據請求用戶的角色來限制金融交易的數據。出納員被允許處理壹定數量的請求，超過這個數量的所有工作都需要由主管來處理。
身份可以映射到登錄到系統的用戶，也可以由應用程序定義。相應的原則封裝了身份和其他相關的角色信息(例如，但不限於此，用戶的“組”由操作系統定義)。
認證和授權
身份驗證是從用戶處接收證書並確認證書授權的過程。如果證書是有效的，那麽用戶可以說他有壹個經過驗證的身份。授權的過程是確定經過身份驗證的用戶是否可以訪問給定的資源。身份驗證可以通過系統或企業邏輯來完成，它是通過API獲得的。身份驗證API是完全可擴展的，因此開發人員可以根據需要使用自己的企業邏輯。開發人員可以編寫他們的身份驗證要求或修改底層的身份驗證方法，而無需對代碼進行太多的更改。除了微軟Windows？除了操作系統身份驗證，其他身份驗證方法包括基本的HTTP、digest和Kerberos，以及Microsoft Passport和基於表單的身份驗證。這些身份驗證方法已經完全融入ASP.NET系統。
在ASP.NET表單驗證中，用戶提供證書並提交表單。如果應用程序沒有請求，系統會發送壹個cookie，其中包含壹個證書或壹個以某種形式重新獲得身份的關鍵字。接下來發送的請求在頭中包含cookie，ASP.NET處理程序通過應用程序期望的任何有效方法對這些請求進行身份驗證和授權。如果請求沒有通過身份驗證，HTTP客戶端將把請求發送到身份驗證表單，用戶可以在表單中提供信任證書。表單身份驗證有時用於為已知用戶設置個性化內容。在某些情況下，身份是問題而不是認證，因此用戶的個性化信息可以簡單地通過訪問用戶或。
授權的目的是確定發出請求的身份是否已被授予對給定資源的訪問權。ASP.NET提供兩種類型的授權服務:文件授權和URL授權。文件授權根據活動方法和發出請求的身份確定用戶使用哪個訪問控制列表。URL授權是URI名稱空間和不同用戶或角色之間的邏輯映射。
獨立存儲
的。NET Framework提供了壹個特殊的函數(獨立存儲),用於存儲數據，即使在不允許訪問文件的情況下也是如此，例如，當從Internet下載並運行管理控件時，它只有有限的權限，但沒有讀寫文件的權利。
獨立存儲是壹組新的類型和方法，用於。凈支持。本質上，每個組合都可以訪問磁盤上壹個獨立的存儲空間。它不允許訪問其他數據，並且獨立存儲僅對為其創建的組合有效。
應用程序還可以使用獨立存儲來保存活動記錄、保存設置或將狀態數據保存到磁盤以備將來使用。因為獨立存儲的位置是預先確定的，所以獨立存儲提供了壹種便捷的方式來指定唯壹的存儲空間，而無需確定文件路徑。
從本地企業局域網獲取的代碼也有類似的限制，但較少，而且可以訪問大量的隔離存儲。最後，來自受限站點區域(不受信任的站點)的代碼不能訪問獨立存儲。
加密
的。NET框架提供了壹組加密對象，支持加密算法、數字簽名、哈希和生成隨機數。它們由眾所周知的算法實現，例如RSA、DSA、Rijndael/AES、Triple DES、DES和RC2，以及MD5、SHA1、SHA-256、SHA-384和SHA-566。同時，它還支持IETF和W3C開發的XML數字簽名規範。的。NET Framework支持使用加密對象的內部服務。這些對象也作為管理代碼提供給需要加密支持的開發人員。
如何指定安全性？
如果想要修改復合運行時的行為，可以根據程序員的需要進行聲明性安全或強制性安全更改。
聲明性安全
聲明式安全使程序員能夠直接在組合代碼的元數據中指定組合的安全要求。權限請求和所有其他形式的聲明性安全在代碼中被指定為固定屬性。對類、屬性和方法的註釋用於優化權限。例如，聲明性安全可用於類的調用方，以在調用方法之前檢查調用方是否已由已知的經銷商簽名或是否具有特定的強名稱。
因為聲明的屬性是組合元數據的壹部分，所以組合的安全需求很容易識別。您可以使用工具來掃描組合，以找出哪些方法需要某些權限，哪些方法聲明了某些權限。
當所請求的活動和權限在編譯時已知時，聲明性檢查可以用作所選擇的解決方案之壹。例如，如果方法總是檢查對C:\temp的寫訪問權限，則權限檢查將受益於聲明。另壹方面，如果具有訪問權限的請求位置已經改變，那麽強制安全性可能是更好的解決方案。
強制安全
強制安全性直接在代碼中實現。程序員通過程序進行安全活動，並根據安全堆棧的狀態決定是否授予或拒絕權限。例如，當壹個方法請求訪問壹個特定的文件時，如果調用者(或該方法的任何調用者)沒有被給予必要的權限，那麽請求將失敗。因為強制安全性是通過程序實現的，所以符合動態要求。如果您需要對特定文件的訪問權限，但是該權限會根據其他信息而改變，那麽強制安全是壹個可選的解決方案。
摘要
的安全。NET Framework迎合了軟件向多樣化移動組件發展的事實，並根據這壹事實提供保護。在詳細且可擴展的策略和許可系統下，用戶可以運行強大的代碼，同時降低相關風險。當沒有運行時來為用戶做出信任決策時，管理員可以在所有級別創建強大的安全策略。策略是完全可以設定的。開發人員可以專註於應用程序邏輯，而不用擔心核心安全問題(這些問題由CLR透明地處理)。但是，開發人員可以隨時擴展安全模型。