共用方式為

IIS 6.0 與 IIS 7 及更新版本之間的安全性變更

  • 發行項

由 IIS 小組

簡介

IIS 7 和更新版本從 IIS 6.0 帶來許多新的安全性改進。 本檔概觀這些有關驗證、授權、SSL、Web 服務延伸模組限制清單和IP限制的改善。

驗證

對於 ASP.NET 應用程式開發人員來說，在 IIS 7 之前，您需要針對兩個驗證模型進行程序設計。 這些模型是 IIS 和 ASP.NET 管線。 首先，IIS 會檢查要求並執行其驗證例程，然後傳遞至 ASP.NET，以便執行類似的工作。

在 IIS 7 和更新版本中，我們已統一這兩個模型，以產生新的健全管線，以達到兩個較舊模型執行的最佳效果。 IIS 仍然支援所有舊的驗證通訊協定，但現在也支援窗體驗證，可防範所有內容類型，且不依賴 Windows 帳戶。 除了支援您了解和熱愛的所有舊功能之外，我們也加強了其中一些功能，例如匿名驗證功能。

這些變更將在後續章節中討論。

匿名驗證變更

在 IIS 7 和更新版本中，匿名驗證的行為與舊版中只有一個變更相同-能夠在背景工作進程身分識別的內容下執行。 每個應用程式集區都會設定為在用戶帳戶的內容下執行，而此帳戶的預設值為NETWORKSERVICE。

ASP.NET 應用程式在 web.config 檔案中使用下列程式代碼來關閉模擬，並在應用程式集區身分識別下執行是很常見的：

<identity impersonate="false"/>

在某些情況下，應用程式必須在進程身分識別的內容下執行：

  • 進程身分識別是低許可權帳戶，系統管理員已鎖定該帳戶的系統
  • 進程身分識別已獲得網路存取權，並用來存取後端資源，例如資料庫

為了重新設計 IIS 7 和更新版本，我們想要讓此案例安全且容易完成。 若要實作此案例，在 IIS 中需要：

  • 安裝和啟用匿名驗證模組
  • 將匿名使用者名稱和密碼設定為空字串

若要這樣做，請修改匿名驗證的組態，使其如下所示：

<anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" />

此設定會告知 IIS 一律在背景工作進程識別的內容下執行。

根據預設，IIS 7.0 和更新版本中的匿名驗證身分識別是 IUSR 帳戶。 此帳戶是最低許可權和許可權的低許可權身分識別。 若要深入瞭解新的內建帳戶，請參閱 瞭解 IIS 7 和更新 版本中的內建帳戶和群組一文。

Passport 變更

舊版 Passport 驗證的支持內建於 IIS 5/6 和 Windows Server 2000 和 2003 中。 IIS 5 和 6 中的 Passport 支援已公開為 IIS 服務管理員中 [目錄安全性] 索引標籤中的複選框，用於「啟用 Passport 驗證」。 此複選框提供 IIS 傳送舊版 Tweener 通訊協定挑戰的能力。 除此之外，仍然需要向 Passport 服務佈建入口網站註冊網站、取得加密密鑰，以及在 IIS 整合正常運作之前，在伺服器上設定舊版 Passport Manager。

在 Windows Server 2008 和更新版本中，已移除舊版 Passport 二進位檔與 IIS 的整合。

Passport 服務此後已變更為 Windows Live ID。 雖然新的 Live ID 服務當然從舊版 Passport 服務中成長出來，但有重大變化。 其中一項最大的變更是合作夥伴網站如何與 Live ID 整合。 您可以使用公開提供的 Windows Live ID Web 驗證 SDK 來新增 Live ID 驗證。 雖然 Windows Live ID 服務也支援身分識別同盟和 ADFS，但該功能是特定案例的新功能，而不是「Passport」的取代專案。

窗體驗證

窗體驗證是 ASP.NET 的一部分，可讓 Windows 和非 Windows 身分識別自行驗證，並取得應用程式稍後可以使用的用戶物件。 IIS 7 和更新版本現在完全支援窗體驗證，並可設定為保護所有內容類型的存取。

IIS 7 和更新版本如何判斷已驗證的身分識別

在 IIS 7 和更新版本中，核心引擎會以類似方式處理驗證規則，因為它們在舊版 IIS 中只有一些次要變更。 為了進一步瞭解處理順序，以下是根據 IIS 評估順序的規則：

  • 首先，IIS 會判斷是否已在虛擬目錄中設定使用者名稱和密碼。 如果已定義一組認證，則會使用這些認證。 對於 IIS 7 前系統管理員，這些認證是 UNC 認證
  • 如果未在虛擬目錄中設定任何認證，IIS 將會使用驗證期間提供的認證。 當啟用基本、摘要或 Windows 驗證 時，這些認證可以屬於針對匿名驗證設定的身分識別，或是在驗證交握期間由使用者提供的認證
  • 如果未建立任何已驗證的使用者（例如，已啟用窗體驗證），我們將判斷是否應該使用進程身分識別
  • 如果我們目前沒有身分識別，IIS 會傳回拒絕存取權

授權

AzMan 支援

在 IIS 6.0 中，我們引進了以 AZMan 規則為基礎的新授權模型。 在 IIS 7 和更新版本中，我們已淘汰這項功能，以支援與 ASP.NET 授權模型非常類似的新模型（請參閱下面的 URL 授權主題）。

URL 授權

在 IIS 7 和更新版本中，您有兩個授權解決方案。 第一個是使用 ASP.NET 授權模型。 此方法需要定義 system.web> 組態中的所有<授權規則，而且對於已經針對 ASP.NET 撰寫規則的應用程式，需要零個變更。 第二個模型是移至新的 IIS 授權架構。 此模型與 ASP 非常類似。具有一些次要變更的 NET 模型：

  • 規則與順序無關
  • 拒絕規則會排序到清單頂端
  • 規則會以相反的方式處理 ASP.NET，主要以下列順序處理：祖父母、父母、子女：ASP.NET 授權會以相反的順序處理規則：child、parent、then grandparent

若要進一步瞭解 ASP.NET 授權模型與 IIS 授權模型之間的差異，讓我們先看看 ASP.NET 授權組態：

<authorization>
    <allow users="Vik_Malhotra" />
    <deny roles="administrators" />
    <deny users="*" />
</authorization>

在此範例中，我們允許Vik_Malhotra，但我們拒絕其他人。 在 IIS 中，組態非常類似：

<authorization>
    <add accessType="allow" users="Vik_Malhotra" />
    <add accessType="deny" roles="administrators" />
    <add accessType="deny" users="*" />
</authorization>

語法變更的原因是我們想要確保應用程式開發人員知道這兩個模型其實不同，但同時，他們可以以最少的努力將規則從一個實作移到另一個。

SSL

在 IIS 6.0 中，IIS 已將 SSL 相關信息儲存在中繼基底中，並與 HTTP.SYS 一起管理了大部分的 SSL 交涉程式。 在 IIS 7 和更新版本中，我們已將大部分的此組態移至 HTTP。SYS 的存放區。

為了說明每個 IIS 6.0 組態設定如何傳遞到 IIS 7 和更新版本的組態（或HTTP.SYS組態），下列圖表已建構如下。

IIS 6.0 Metabase 組態 屬性描述 IIS 7.0 和更新版本架構
AccessSSLFlags AccessSSLFlags 是 AccessSSL AccessSSSL128 AccessSSLNegotiateCert AccessSSLRequireCert AccessSSLMapCert 0 值的位掩碼，表示 沒有 SSL。 存取>區段中 IIS 7.0 和更新版本組態仍<支援屬性
CertCheckMode 啟用或停用CRL（證書吊銷清單）檢查。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。
RevocationFreshnessTime 如果 RevocationFreshnessTime 屬性設定為 1（true），則憑證用戶端上的證書吊銷清單 （CRL） 會由 CRL 從遠端位置更新，即使憑證用戶端上快取的 CRL 有效也一樣。 除非您使用 RevocationURLRetrievalTimeout 來指定不同的逾時間隔（以分鐘為單位），否則預設逾時間隔為一天。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。
SecureBindings SecureBindings 屬性會指定 IIS 用來判斷伺服器實例所使用的安全網路端點的字串。 月臺系<結>區段<>下的 IIS 7.0 和更新版本組態仍支援這個屬性。 所使用的通訊協定需要由 「HTTPs」 使用。
SSLAlwaysNegoClientCert SSLAlwaysNegoClientCert 屬性會控制 SSL 用戶端連線交涉。 如果此屬性設定為 true，則每當交涉 SSL 連線時，伺服器就會立即交涉客戶端憑證，以避免進行昂貴的重新談判。 設定 SSLAlwaysNegoClientCert 也有助於消除客戶端憑證重新談判死結，當收到重新談判要求時，用戶端可能會在傳送大型要求本文時遭到封鎖。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。
SSLCertHash SSLCertHash 屬性是用來儲存所使用 SSL 憑證的哈希。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。
SslCtlIdentifier SslCtlIdentifier 屬性包含可識別特定憑證信任清單 （CTL） 的唯一值。 它必須與 SslCtlStoreName 搭配使用，才能正確參考 CTL。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。
SslCtlStoreName SslCtlStoreName 屬性包含包含憑證信任清單 （CTL） 的 CryptoAPI 存放區名稱。 它必須與 SslCtlIdentifier 搭配使用，才能正確參考 CTL。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。
SSLStoreName SSLStoreName 屬性可用來儲存憑證密鑰組所在的存放區名稱。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。
SslUseDsMapper SslUseDsMapper 屬性會指定 IIS 是使用 Windows Directory 服務憑證對應程式還是 IIS 憑證對應程式。 如果 SSLUseDSMapper 設定為 false，IIS 會使用 IIS 憑證對應程式。 此值現在會儲存在 PHTTP_SERVICE_CONFIG_SSL_PARAM 物件中的 http.sys。

如需HTTP.SYS PHTTP_SERVICE_CONFIG_SSL_PARAM對象的詳細資訊，請參閱下列 檔。

所有這些變更都會在封面下以透明方式處理，因此作為伺服器 管理員 管理員，您不需要特別執行任何動作--IIS 會為您執行所有動作。 如果您有正在存取舊 IIS 6.0 屬性的應用程式現在位於 HTTP 中。SYS 的組態存放區，我們的 ABO 對應程式介面可確保正確值已讀取/寫入，因此您的應用程式不會失敗，而是會繼續運作。

Web 服務延伸模組限制清單

在 IIS 7 和更新版本中，這項功能已稍微修改，使其名稱現在會讀取 「isapiCgiRestrictionList」 ，但否則它會在 IIS 6.0 中的行為和行為。

這項變更的原因是強調其真正的使用方式。 在 IIS 6.0 中，已新增這項功能，以確保 Rogue ISAPI 或 CGI 二進位檔無法複製到 IIS 伺服器，然後允許執行。 透過重新設計 IIS 7 和更新版本，我們有兩個支援的模型：

  • “classic” ISAPI 管線
  • 新的整合管線

如果我們位於「傳統」ISAPI 管線中，一切都會繼續運作，如同您在使用 IIS 6.0 時所預期的那樣運作。 為了說明這一點，請考慮在 ISAPI 模式中執行時 ASP.NET 的運作方式。 首先，您必須新增aspnet_isapi.dll的完整路徑，並將其設定為allowed=“true”，如下所示：

<isapiCgiRestriction>
    <add path="F:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
    allowed="true" groupId="ASP.NET v2.0.50727" description="ASP.NET v2.0.50727" />
</isapiCgiRestriction>

現在和現在才允許執行此程式碼（aspnet_isapi.dll）。 如果我們將管線模式切換為整合和變更allowed=“false”，仍然會執行 ASP.NET 程式代碼。

為什麼？ 原因是 isapiCgiRestrictionList 僅適用於 ISAPI 和 CGI 程式代碼。 在整合模式中，ASP.NET 現在是新架構的一部分，因此不會受到 isapiCgiRestrictionList 的影響。 如果您不想在新整合管線中執行 ASP.NET 程式代碼，您只需要從模塊清單中移除 managedEngine 即可。

IP 限制

IP 限制的運作方式與過去完全相同，但我們現在支援名為 「allowUnlisted」 的新屬性。 已新增此屬性，可讓您更輕鬆地在全域層級設定系統的安全策略。 例如，如果您的原則只要求允許特定IP位址，但拒絕未列出的所有其他地址，過去並不容易。 同樣地，只拒絕一組指定的IP位址，並允許所有未列出的IP位址現在都很容易完成。 身為伺服器管理員，您可以設定全域原則，然後鎖定此值，讓應用程式或網站管理員無法變更伺服器上的此值。

為了說明，請考慮您只想讓使用者在本機存取的開發計算機。 下列設定會藉由設定allowUnlisted=“false” 來實作該原則，然後明確允許localhost （127.0.0.1） 存取：

<system.webServer>
    <security>
        <ipSecurity allowUnlisted="false">
            <add ipAddress="127.0.0.1" allowed="true" />
        </ipSecurity>
    </security>
</system.webServer>