asp.net|安全|程式|訪問 摘要：本文主要介紹了ASP.NET WEB應用程式的安全模型的種類、對比其優缺點，提出了選擇的機制。
關鍵字：安全模型 受信任子模型 類比/委託子模型 ASP.NET WEB應用
1.前言
ASP.NET WEB應用程式通常屬於多層體繫結構，一般從邏輯結構上可以分為展示層、商務邏輯層和資料訪問層；用戶端要訪問應用程式資源，其身份認證和授權必然要跨越多個層次。本文主要討論SP.NET應用程式的資源訪問安全模型
2. 資源訪問標識
WEB應用程式對外提供的給用戶端的典型資源套件括：
Web伺服器資源，如Web頁、Web服務和靜態資源（HTML頁和映像）。
資料庫資源，如針對每個使用者的資料或是應用程式級資料。
網路資源，如遠程檔案系統資源等。
系統資源，如註冊表、事件記錄和設定檔等。
用戶端跨越應用程式的層來訪問這些資源，要有一個標識流經各個層。這個用於資源訪問的標識包括：
原始調用者的標識 原始調用者的標識被擷取並且隨後流經系統的每個層。
進程標識 本地資源訪問和下遊調用是使用當前進程標識進行的。這種方式的可行性依賴於要跨越的邊界，因為進程標識必須能被目標系統識別。這需要以下面兩種方式之一進行調用：
在同一個Windows安全域中
跨Windows安全域-使用信任和域賬戶，或者在不存在信任關係的情況下使用重複的使用者名稱和密碼。
服務賬戶 這種方式使用一個（固定的）服務賬戶。例如
對於資料庫訪問，該服務賬戶可能由串連到資料庫的一個組件表示固定的SQL使用者名稱和密碼。
當需要固定的Windows標識時，應使用Enterprise Services伺服器應用程式。
自訂標識 當沒有Windows賬戶可用時，可以使用Iprincipal和Iidentity實現構造自己的標識，可以包含安全上下文有關的詳細資料。
3. 資源訪問模型
3.1 受信任子系統模型
如圖1所示，在這種模型中，原始調用者的安全上下文並不在作業系統級流經服務，而是在中間服務層使用了一個固定標識來訪問下遊的服務和資源。受信任子系統模型得名於這樣一個事實：下遊服務（可能是一個資料庫）信任上遊服務，讓其調用者進行授權。圖1中的樣本，資料庫信任中介層對調用者進行的授權，並只允許被授權的調用者使用受信任標識訪問資料庫。
3.1.1 資源訪問模式
在受信任子系統模型中，資源訪問模式如下：
對使用者進行驗證
將使用者映射為角色
根據角色成員關係進行授權
使用一個固定的受信任標識訪問下遊資源
3.1.2 固定標識
用於訪問下遊系統合資源管理員的固定標識，可以使用進程標識，也可以使用一個預先設定的Windows賬戶-服務賬戶來提供。對於SQL Server資源管理員，這意味著對SQL Server的Windows身分識別驗證。
使用進程標識時通常使用ASP.NET進程標識（預設識ASPNET賬戶）。實際應用時，經常需要將ASPNET賬戶更改為一個更為安全的密碼，並在SQL Server電腦上鏡像建立一個與ASP.NET進程帳戶相匹配的Windows賬戶。具體方法如下：
編輯位於%windr%\Microsoft.NET\Framework\v1.1.4322\CONFIG目錄下的Machine.config檔案，將<processModel>元素上的密碼屬性重新設定，將其預設值<!-UserName="machine" password="AutoGenerate" -->改為<!-UserName="machine" password="NewPassword" -->；或是通過ASPNET_setreg.exe工具，將使用者名稱和密碼儲存到註冊表，配置改為：<!-enable="true" UserName="Registry:HKLM\SOFTWARE\YourAPP\processsModel\ASPNET_SETREG,userName" password=" Registry:HKLM\SOFTWARE\YourAPP\processsModel\ASPNET_SETREG,password " -->
另外一些應用程式使用指定的SQL賬戶（在連接字串中由使用者名稱和密碼指定）來訪問SQL Server。在這種情況下，資料庫必須配置為SQL身分識別驗證。在設定檔中儲存的連接字串需要加密保護。
3.2 類比/委託模型
如圖2所示，使用類比/委託模型時，一個服務或組件（通常位於邏輯商務服務層中）在訪問下一個下遊服務前，使用作業系統類比功能來類比用戶端標識。如果該服務位於同一電腦上，則使用類比就足夠了，如果下遊服務位於遠端電腦則還需要使用委託，下遊資源訪問的安全上下文是用戶端的上下文。
3.3 選擇資源訪問模型
兩種資源訪問模型的比較如表一所示。
受信任子系統模型 類比/委託模型
審核功能 後端信任上層服務，若中介層受侵害，後端資源易受攻擊。 後端服務可以對每個調用者進行驗證、授權，安全性好。
延展性 支援串連池，伸縮性好。 不支援串連池，伸縮性差。
後端ACL管理 ACL針對單個實體進行配置，管理工作少。 每個使用者都要被授予相應的存取層級，後端資源和使用者數增大時，管理工作繁瑣。
技術問題 不用委託。 需要委託。大多數安全服務提供者不支援委託。
在大多數Internet應用程式以及大型intranet應用程式中都會使用受信任子系統模型，這主要是由於這種模型能很好的支援延展性。類比/委託模型則傾向於用於小型的系統。對於這些應用程式，延展性不是主要的考慮因素，其主要考慮的因素是審核。
3. 相關文章
《ASP.NET應用程式的安全方案（一）-身分識別驗證》。
《ASP.NET應用程式的安全方案（二）-授權》。
《ASP.NET應用程式的安全方案（二）-安全通訊》。
