寄宿多個 ASP.NET 應用程式

asp.net|程式

本單元概要
Microsoft ® Windows ® Server 2000 和 Windows Server ™ 2003 作業系統提供了伸縮性非常好、非常可靠的 Web 宿主環境。它們可以用於在一個 Web 服務器或者 Web 服務器場上安全地寄宿成百上千個 Web 網站和 ASP.NET 應用程式。

但是，當在共用宿主情境中使用 ASP.NET 應用程式時，必須考慮如何使應用程式互相獨立，以及獨立於共用系統資源，包括檔案系統、註冊表和事件記錄。沒有足夠的獨立性，惡意或者設計不良的應用程式會對伺服器上的其他應用程式產生負面影響，或者訪問未授權的資源。這種應用程式獨立對於寄宿多家不同公司的大量應用程式的 網際網路服務提供者 (ISP) 尤其重要。

本單元闡述了在 Windows 2000 和 2003 中可以使用哪些技術隔離 ASP.NET 應用程式，以確保所寄宿的 Web 網站資料的完整性、保密性和真實性。

返回頁首
目標
通過本單元能夠：

• 理解 Windows 2000 和 2003 中 ASP.NET 的體繫結構和主要組成部分。
 
• 使用多個標識、應用程式集區和代碼訪問安全隔離 Web 應用程式。
 
• 配置匿名帳戶類比。
 
• 在使用整合 Windows 身分識別驗證或者認證對使用者進行身分識別驗證時，配置固定的帳戶類比以訪問本地或者遠端資源。
 
• 提高表單身分識別驗證的安全性。
 
• 理解在訪問 UNC 共用中儲存的資料時，如何使用憑據。 
 

返回頁首
應用範圍
本單元適用於下列產品和技術：

• Microsoft Windows Server 2000 和 2003
 
• Microsoft .NET Framework 1.1 和 ASP.NET 1.1 
 

返回頁首
如何使用本單元
本單元主要關注如何獲得共用宿主環境中的應用程式獨立。關鍵的要素是代碼訪問安全。在使用本單元的同時還應該結合以下內容：

• 閱讀單元 8“代碼訪問安全實踐”。該單元更詳細地解釋了代碼訪問安全的工作原理，以及如何使用它約束單獨的程式集，例如限制程式集訪問檔案系統、註冊表、網路和其他關鍵資源的能力。
 
• 閱讀單元 9“在 ASP.NET 中使用代碼訪問安全”。該單元解釋了如何將代碼訪問安全性原則用於 ASP.NET 應用程式，並討論了構建部分信任應用程式的注意事項和意義。
 
• 閱讀單元 16“保護 Web 服務器的安全”。該單元說明了如何保護 Windows 2000 作業系統和 Microsoft .NET Framework。安全的基礎平台是保護一個 ASP.NET Web 應用程式或者 Web 服務的前提條件。 
 

本頁內容
 本單元概要
 目標
 應用範圍
 如何使用本單元
 簡介
 Windows 2000 上的 ASP.NET 體繫結構
 Windows Server 2003 上的 ASP.NET 體繫結構
 用標識隔離應用程式
 用應用程式集區隔離應用程式
 用代碼訪問安全隔離應用程式
 表單身分識別驗證的問題
 UNC 共用寄宿
 小結

返回頁首
簡介
在共用宿主情境中，確保應用程式不會對其他應用程式的操作和安全產生負面影響，是非常重要的。

獲得應用程式獨立有許多方式。可用的選擇因 Web 服務器上啟動並執行 .NET Framework 的版本和作業系統的版本的不同而不同。

• 如果啟動並執行是 .NET Framework 的 1.1 版本，可以使用代碼訪問安全提供的資源約束模型提供一層應用程式獨立。這種應用程式獨立是通過限制應用程式訪問不同類型的資源（如檔案系統、註冊表、事件記錄、Active Directory、資料庫、網路資源等等）而實現的。
 
• Windows Server 2003 通過 Internet 資訊服務 6.0 (IIS 6) 應用程式集區提供了進程獨立，可以使多個應用程式運行在不同的 IIS 輔助進程執行個體中。進程獨立在 Windows 2000 上是不可能的，因為所有 Web 應用程式都運行在單獨的 ASP.NET 輔助進程執行個體中，而應用程式定義域提供了獨立性。 
 

表 1 總結了 Windows 2000 和 Windows Server 2003 上應用程式獨立的各種選擇。

表 1 Windows 2000 和 Windows Server 2003 上的應用程式獨立功能
獨立功能 Windows 2000 Windows Server 2003
進程獨立
 否
 是（IIS 6 應用程式集區）
 
應用程式定義域獨立
 是
 是
 
多個線程標識
 是
 是
 
代碼訪問安全資源約束
 是（.NET Framework 1.1 版）
 是（.NET Framework 1.1 版）
 

運行著 .NET Framework 1.1 版的 Windows Server 2003 是寄宿多個 ASP.NET 應用程式的推薦平台，因為它支援進程獨立，並為應用程式獨立提供了最大範圍的選擇。

返回頁首
Windows 2000 上的 ASP.NET 體繫結構
在 Windows 2000 上，多個 Web 應用程式運行在一個 ASP.NET 輔助進程 (Aspnet_wp.exe) 執行個體中。每個應用程式都駐留在自己的應用程式定義域中，為Managed 程式碼提供了一定程度的獨立性。Windows 2000/IIS 5 體繫結構如圖 1 所示。

 

圖 1. 帶有 IIS 5 的 Windows 2000 上的 ASP.NET 體繫結構

表 2 總結了圖 1 中所描述的體繫結構的組成部分

表 2 Windows 2000 ASP.NET 體繫結構組成部分
組成部分	說明
Inetinfo.exe	主 IIS 進程。運行在本地 SYSTEM 帳戶下的 Windows 服務。
Aspnet_isapi.dll	IIS 指令碼映射將 ASP.NET 檔案類型和運行在 Inetinfo.exe 內的該 ASP.NET 的 ISAPI 擴充關聯起來。 它負責將請求通過非同步具名管道轉寄給 ASP.NET 輔助進程。它還啟動了輔助進程並執行健全狀態監控。ISAPI 擴充不包含Managed 程式碼，本身也並不執行請求處理。
Aspnet_filter.dll	一個輕型的 ISAPI 篩選器，僅用於支援 ASP.NET應用程式的無 cookie 的工作階段狀態。Aspnet_filter.dll 運行在 Inetinfo.exe 內。
Aspnet_wp.exe	ASP.NET 輔助進程。在不同的應用程式定義域（用於提供獨立）中寄宿多個 Web 應用程式。通常每個伺服器一個執行個體，雖然在多處理器伺服器上，Web 園模式支援帶有給定處理器關係的多個相同的進程。不可能將多個特定 Web應用程式分隔到不同的進程中。要求用 IIS 6 和 Windows Server 2003。Aspnet_wp.exe 以本地 ASPNET 帳戶運行，雖然也可以使用自訂帳戶。
Aspnet_state.exe	可選的 Windows 服務，用於儲存 ASP.NET 應用程式的工作階段狀態。Aspnet_state.exe 可以運行在 Web 服務器或者遠程機器（Web 服務器場情況下必需）上。Aspnet_state.exe 運行在本地 ASPNET 帳戶下，雖然可以使用自訂帳戶，通過 Services 嵌入式管理單元進行配置。

返回頁首

 

Windows Server 2003 上的 ASP.NET 體繫結構

在 Windows Server 2003 上，體繫結構有所改變，因為 IIS 6 允許多個進程用於寄宿不同的 Web 應用程式。此體繫結構如圖 2 所示。

注 IIS 6 支援向後相容模式，從而能夠支援 IIS 5 ASP.NET 輔助進程模型。

圖 2. 帶有 IIS 6 的 Windows Server 2003 上的 ASP.NET 體繫結構

與 Windows 2000 下的 ASP.NET 體繫結構相比，Windows Server 2003 中的主要區別在於可以用不同的 IIS 輔助進程執行個體 (W3wp.exe) 寄宿 Web 應用程式。預設時，這些應用程式是使用 NT Authority\NetworkService 帳戶啟動並執行，這是一個最低特權本地帳戶，它用作跨網路的電腦帳戶。運行在網路服務帳戶環境下的 Web 應用程式需要給遠程伺服器提供電腦的憑據以進行身分識別驗證。

為網路服務配置 ACL

為網路服務帳戶配置存取控制清單 (ACL) 的過程，對於本地和遠程機器而言是不同的。如果要授予本地機器上的網路服務帳戶存取權限，需要將網路服務帳戶添加到 ACL 中。如果要授予遠程機器上的網路服務帳戶存取權限，需要將 DomainName\MachineName$ 帳戶添加到 ACL 中。

注 不要把網路服務帳戶與內建的網路組搞混淆了，後者包括的是跨網路進行身分識別驗證的使用者。

表 3 總結了圖 2 中所描述的體繫結構的主要組成部分。

表 3 Windows Server 2003 ASP.NET 體繫結構的組成部分
組成部分	說明
Aspnet_isapi.dll	請求 ASP.NET Managed 程式碼引擎處理並執行健全狀態監控的隊列。
Aspnet_filter.dll	一個輕型的 ISAPI 篩選器，僅用於支援 ASP.NET 應用程式的無 cookie 的工作階段狀態。Aspnet_filter.dll 運行在 W3wp.exe 內。
W3wp.exe	IIS 輔助進程，包含 ASP.NET Managed 程式碼處理引擎。URL 空間可以任意在使用 IIS 6 應用程式集區的不同 W3wp.exe 執行個體中分隔。還支援 Web 園模式。請求直接從運行在核心模式的 Http.sys 路由到 W3wp.exe 進程執行個體。預設時，進程運行在網路服務帳戶下，但是可以配置。
Aspnet_state.exe	一個可選的 Windows 服務，用於儲存 ASP.NET 應用程式的工作階段狀態。Aspnet_state.exe 可以運行在 Web 服務器或者遠程機器（Web 服務器場情況下必需）上。運行在網路服務帳戶下，但是可以使用 Services 嵌入式管理單元配置。

返回頁首

 

用標識隔離應用程式

從作業系統標識的觀點來看，可以通過控制用來運行每個應用程式的帳戶標識隔離 ASP.NET Web應用程式。如果每個應用程式使用不同的固定帳戶標識，就可以分別授權和審核每個應用程式。

注 如果要寄宿使用 .NET Framework 1.0 版構建的 ASP.NET Web應用程式，進程帳戶需要適當的對當前檔案系統磁碟機根的存取權限。有關更多資訊，請參閱 Microsoft 知識庫文章 317955“FIX:'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page”。

如果共用 Web 服務器上每個應用程式要想都使用不同的固定標識，可以採用兩種方式：

•	匿名帳戶類比
•	固定標識類比

匿名帳戶類比

通過匿名帳戶類比，應用程式可以類比 IIS 指定、並為應用程式的虛擬目錄配置的匿名帳戶。如果您的應用程式要獨立於 IIS 對使用者進行身分識別驗證（如，通過使用表單或者 Microsoft Passport 身分識別驗證），就可以使用此方式。在這些情況下，可以通過使用固定的匿名帳戶隔離應用程式。一旦調用方通過了身分識別驗證，角色也經過了檢查，就可以將可信伺服器模型用於下遊的資源訪問，其中已配置的匿名帳戶提供了可信的標識。

為了支援這一方式，IIS 中的應用程式虛擬目錄必須支援匿名訪問，必須為每個應用程式配置不同的匿名帳戶。應用程式然後必須配置為類比。這種方式如圖 3 所示。本地和遠端資源訪問假設使用類比的匿名帳戶的安全上下文。

圖 3. 用於每個應用程式的多個匿名帳戶

為了使用多個匿名帳戶進行資源訪問

此過程敘f20secmod03.gif述了如何使用多個匿名帳戶（每個 Web 應用程式一個）進行資源訪問，以支援單獨的應用程式授權和審核。

1.	建立新的匿名使用者帳戶，每個應用程式一個。 有關建立匿名使用者帳戶的更多資訊，請參閱“保護 Web 服務器的安全”單元中的“帳戶”部分。 如果需要使用匿名帳戶訪問遠端資源，要麼使用一個最低特權域帳戶，要麼使用本地帳戶，在遠程伺服器上使用匹配的使用者名稱和密碼建立一個重複的本地帳戶。
2.	使用 <location> 標記在 Machine.config 中配置每個 Web 應用程式為類比。 <location path="Web Site Name/VDirName" allowOverride="false" > <system.web> <identity impersonate="true" /> <system.web><location> allowOverride="false" 設定防止了單個的應用程式改寫 Web.config 檔案中的這一設定。有關 <location> 元素的更多資訊，請參閱“保護 ASP.NET 應用程式的安全”單元中的“Machine.config 和 Web.config 詳解”部分。
3.	使用 網際網路服務管理員配置每個應用程式的虛擬目錄，以使用不同的匿名使用者帳戶。 1. 從管理工具程式組啟動 網際網路服務管理員。 2. 選擇應用程式的應用程式目錄，滑鼠右鍵單擊，然後單擊 Properties。 3. 單擊 Security 選項卡，然後單擊 Edit 按鈕。 4. 確保選擇了 Anonymous access，然後單擊 Edit。 5. 輸入已建立的匿名帳戶的使用者名稱，或者單擊 Browse，從列表中選擇使用者名稱。 6. 如果想使用帳戶訪問遠端資源，請清除匿名帳戶的 Allow IIS to Control Password 複選框。 如果選擇了 Allow IIS to Control Password，使用指定匿名帳戶建立的登入工作階段的網路憑據將為 NULL，而且不能用於訪問必需進行身分識別驗證的網路資源。如果清除了這一複選框，登入工作階段將是一個需要網路憑據的互動式登入會話。但是，如果帳戶是機器本地帳戶，則網路上其他機器都無法對此帳戶進行身分識別驗證。在此情況下，應該在目標遠程伺服器上建立一個重複帳戶。 注 所建立的登入工作階段的類型是由 LogonMethod IIS 中繼資料庫設定控制的。預設時是互動式登入會話，需要具有“Allow Log on Locally”使用者特權的帳戶。 IIS 6 上沒有 Allow IIS to Control Password 選項。IIS 6 將預設的 LogonMethod 設定為 Network Cleartext，這要求帳戶有“Access this computer from the network”使用者特權。這使帳戶由網路伺服器進行身分識別驗證。
4.	為每個帳戶配置 NTFS 許可權，以確保每個帳戶都有只訪問適當的檔案系統檔案和檔案夾的許可權，而不能訪問關鍵的資源（如作業系統工具）。 有關為匿名帳戶配置 NTFS 許可權的更多資訊，請參閱單元“保護 Web 服務器的安全”。 注 如果運行 IISLockdown 嚮導，它將建立一個 Web 匿名使用者組。該組的成員將被拒絕訪問系統目錄和工具。

固定標識類比

如果需要 IIS 為應用程式對使用者進行身分識別驗證（例如，通過使用整合 Windows 身分識別驗證或者憑證驗證），可以使用一個固定類比標識來執行 ASP.NET 應用程式。此情境如圖 4 所示。

圖 4. 應用程式類比一個固定帳戶，並使用它訪問資源

可以配置單獨的 ASP.NET 應用程式類比一個固定帳戶。這種配置的好處在於，它可以用於任何 IIS 驗證方法，而且無需 IIS 匿名驗證。

為了使用多個固定類比帳戶進行資源訪問

此過程敘述了如何使用多個固定類比帳戶（每個 Web 應用程式一個）進行資源訪問，以支援單獨的應用程式授權和審核。

1.	建立新的匿名使用者帳戶，每個應用程式一個。 有關建立匿名使用者帳戶的更多資訊，請參閱“保護 Web 服務器的安全”單元中的“帳戶”部分。 如果需要使用匿名帳戶訪問遠端資源，要麼使用一個最低特權域帳戶，要麼使用一個本地帳戶，在遠程伺服器上使用匹配的使用者名稱和密碼建立一個重複的本地帳戶。
2.	在註冊表中儲存加密的帳戶憑據。 運行 Aspnet_setreg.exe 在註冊表中儲存新帳戶的加密憑據。有關更多資訊，請參閱 Microsoft 知識庫文章 329290“如何：使用 ASP.NET 工具 + 生產力加密憑據和工作階段狀態連接字串”。
3.	配置 Web 應用程式為類比。 可以在 Machine.config 或者 Web.config 中實現。為了配置帶有不同標識的多個應用程式，可使用 Machine.config 中的 <location> 標記。按以上步驟運行 Aspnet_setreg.exe 的輸出將顯示 <identity> 元素的 userName 和 password 屬性值所必需的格式。有些例子如下所示。 <location path="Web Site Name/appvDir1" allowOverride="false" > <system.web> <identity impersonate="true" userName= "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,userName" password= "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,password"/> </system.web></location><location path="Web Site Name/appvDir2" allowOverride="false" > <system.web> <identity impersonate="true" userName= "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,userName" password= "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,password"/> </system.web></location> 為了配置應用程式級的類比，在應用程式的 Web.config 檔案中使用一個<identity>元素，如下所示。 <identity impersonate="true" userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password
4.	為每個帳戶配置 NTFS 許可權，以確保每個帳戶只有訪問適當的檔案系統檔案和檔案夾的許可權，而不能訪問關鍵的資源（如作業系統工具）。 有關為匿名帳戶配置 NTFS 許可權的更多資訊，請參閱單元“保護 Web 服務器的安全”。

注 在 Windows 2000 和 .NET Framework 1.0 版上，如果通過使用以上配置類比一個固定標識，必須給用來運行 Web 應用程式的 ASP.NET 進程帳戶授予“Act as part of the operating system”特權。這與最低特權的原則相反。建議您升級到 .NET Framework 1.1 版，這種要求就不再需要了。

返回頁首

 

用應用程式集區隔離應用程式

如果您的應用程式運行在 Windows Server 2003 上，可以使用應用程式集區，並配置每個應用程式運行在自己的輔助進程（這可以提供進程級獨立）中。預設時，所有應用程式都運行在一個預設的應用程式集區中。通過應用程式集區，可以配置每個進程使用不同的標識運行，因此，就無需使用類比了。

為了提供進程級獨立

1.	建立一組新的 Windows 帳戶，每個應用程式一個，以運行每個輔助進程執行個體。
2.	為每個帳戶配置 NTFS 許可權，以確保每個帳戶只有訪問只訪問適當的檔案系統檔案和檔案夾的許可權，而不能訪問關鍵的資源（如作業系統工具）。 有關為匿名帳戶配置 NTFS 許可權的更多資訊，請參閱單元“保護 Web 服務器的安全”。
3.	禁用 Web 應用程式類比。 這可以在 Machine.config 或者 Web.config 中實現。為了在 Machine.config 中禁用多個應用程式的類比，將 <identity> 元素放入 <location> 元素中，如下所示。 使用以下配置。此配置將不進行類比。 <location path="Web Site Name/appvDir1" allowOverride="false" > <system.web> <identity impersonate="false" </system.web></location> 注 ASP.NET應用程式預設時不進行類比。
4.	建立新的應用程式集區，並配置它們運行在新的帳戶下。 使用 IIS 6 以預設設定建立新的應用程式集區，使用步驟 1 中建立的帳戶配置每個池的標識，這樣每個池都使用不同的標識運行。
5.	配置每個應用程式運行在自己的應用程式集區。 在每個 IIS 應用程式的 Directory 選項卡中，為應用程式選擇啟動並執行應用程式集區。

返回頁首

 

用代碼訪問安全隔離應用程式

在 .NET Framework 的 1.1 版中，可以使用 <trust> 元素配置應用程式運行在部分信任級。以下配置說明了如何從 Machine.config 配置一個應用程式的信任級。在此例中，使用了 Medium 信任級。

<location path="Web Site Name/appvDir1" allowOverride="false">  <system.web>    <trust level="Medium" originUrl="" />  </system.web></location>

如果配置一個應用程式以“Full”之外的信任級運行，應用程式訪問特定資源類型的代碼訪問安全許可權將是受限制的。通過這種方式，可以約束應用程式，防止它們互相互動，以及獲得訪問系統級資源（如檔案系統、註冊表、事件記錄等等的受限地區）的許可權。

有關 ASP.NET 信任級、和如何使用它們提供應用程式獨立以及應用程式特定的設計與開發的注意事項方面的更多資訊，請參閱“在 ASP.NET 中使用代碼訪問安全”單元。

注 如果使用代碼訪問安全提供應用程式獨立，應該還考慮到應用程式的作業系統標識。推薦的獨立模型是結合使用代碼訪問安全和 Windows Server 2003 上的進程級獨立。

返回頁首

 

表單身分識別驗證的問題

如果在 .NET Framework 的 1.0 版中使用表單身分識別驗證，應該使用不同的 cookie 路徑和名稱。如果不這樣的話，一個應用程式中身分識別驗證過的某個使用者有可能請求另一個應用程式，而不會重新導向到該應用程式的登入頁。第二個應用程式中的 URL 授權規則可能連使用登入表單提供登入憑據的機會都不給，就拒絕此使用者的訪問。

為了避免出現這一問題，每個應用程式的 <forms> 元素都使用唯一的 cookie 路徑和名稱屬性，每個應用程式都使用不同的機器密鑰。

.NET Framework 的 1.1 版支援如下所示的 IsolateApps 設定。

<machineKey validationKey="AutoGenerate,IsolateApps"            decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

這確保了機器上的每個應用程式使用不同的密鑰進行表單身分識別驗證 cookie 和檢視狀態的加密以及驗證。

在 .NET Framework 的 1.0 版中，不能使用 IsolateApps，而且必須手工產生 <machineKey> 元素。有關這一問題的更多資訊，請參閱 Microsoft 知識庫中的以下文章。

•	313116“ PRB:Forms Authentication Requests Are Not Directed to loginUrl Page”
•	312906“How To:Create Keys by Using Visual C# .NET for Use in Forms Authentication”

返回頁首

 

UNC 共用寄宿

如果您要運行一個內容位於通用命名慣例 (UNC) 共用中的應用程式，用來訪問共用的憑據要麼是應用程式的憑據，要麼是已通過身分識別驗證的用戶端的憑據。這是由管理員在 IIS 中配置的。

當應用程式如此配置時，ASP.NET 類比它從 IIS 接收到的標記的安全上下文。這不能通過 <identity> 標記配置，除非提供了顯式的憑據。

在 .NET Framework 的 1.0 版中，使用 Mscorcfg.msc 根據 URL 建立一個程式碼群組，並授予它完全信任。

當使用一個指向遠程共用的虛擬目錄寄宿一個 ASP.NET 應用程式時，可能收到一個安全異常。有關更多資訊，請參閱 Microsoft 知識庫文章 320268“PRB: System.Security.SecurityException:Security error" Error Message when the Virtual Directory Points to a Remote Share in ASP.NET。”

返回頁首

 

小結

如果要在一個 Web 服務器上寄宿多個 ASP.NET 應用程式，需要考慮應用程式之間以及應用程式和共用的系統資源（如檔案系統、註冊表和事件記錄）之間的獨立。沒有足夠的獨立性，惡意或者設計不良的應用程式可能對伺服器上的其他應用程式產生負面影響。

在 Windows Server 2003 上，使用 IIS 6 支援的多輔助進程模型為應用程式提供作業系統進程獨立。在 Windows 2000 上，進程獨立是不可能的，雖然可以配置多個應用程式使用不同的匿名使用者帳戶。這提供了單獨的應用程式審核，還支援獨立的應用程式授權。

在兩個平台上，都可以使用代碼訪問安全提供的資源約束模型作為附加的控制手段，以對哪些應用程式有對哪些資源類型進行訪問的許可權加以限制。在 ASP.NET應用程式中使用代碼訪問安全需要 .NET Framework 1.1 版。

有關保護 ASP.NET 應用程式安全的更多資訊，請參閱“保護 ASP.NET 應用程式的安全”單元。