共用方式為

Windows Server AppFabric 的資訊安全模型

  • 發行項

您必須保護由 Windows Server AppFabric 管理的 .NET Framework 應用程式，讓使用者只能存取獲得授權的服務與資料。若要這樣做，您必須識別使用者、確認身分無誤，並判斷他們是否有檢視資訊或執行所要求動作的權限。用戶端與伺服器之間的訊息交換必須在安全通道進行，以確保安全地傳輸私人資訊。支援 AppFabric 的 Microsoft 技術提供整合的服務，讓企業可以安全地連接及使用您的應用程式。AppFabric 系統管理員不需要維護多組使用者資料庫，而且從單一圖形化工具就可以管理數百部內部網路伺服器的所有服務。整合 Microsoft 安全性技術與支援 AppFabric 的產品，可以讓您授與使用者執行其應用程式所需之所有資源的權限。

AppFabric 安全性的關鍵部分

AppFabric 資訊安全模型的主要目的是為大多數的 AppFabric 使用者提供簡單但有效的機制。因為它與現有的 Windows、.NET Framework、IIS 與 SQL Server 資訊安全模型整合，使用者可以利用現有的安全性知識與技術來運用 AppFabric 資訊安全模型。具體而言，它使用 Windows、.NET Framework、IIS 與 SQL Server 安全性概念，在它所管理的 WCF 與 WF 應用程式上，強制套用不同等級的安全性。因為 AppFabric 只新增一些增強功能到已經非常強大的整合式 Microsoft 安全性架構，了解 Microsoft 安全性概念的系統管理員應該非常熟悉其安全性模型。對擁有 AppFabric 的客戶而言，這可以有較低的長期擁有權總成本。如果您已經非常熟悉這些產品與技術，只要依照安全性與保護一節的指導方針就可以輕鬆保護您的應用程式。

AppFabric 使用現有安全性概念，如下所示：

  • Windows 安全性。 AppFabric 利用 Windows 群組與檔案系統安全性。應用程式所有的元件中都一致性地使用 Windows 強大的安全性架構，而且存取 AppFabric 資源時必須通過驗證機制的驗證。如需詳細資訊，請參閱 Windows 安全性。

  • .NET Framework 安全性。 AppFabric 針對其 WCF 與 WF 服務使用 Windows Communication Foundation 安全性。WCF 是 SOAP 訊息型分散式程式設計平台，而且加密用戶端與服務之間的訊息對保護資料而言非常重要。WCF 根據現有的安全性基礎結構以及公認的 SOAP 訊息安全性標準，針對交換加密訊息提供多樣且可交互操作的平台。如果已利用現有的技術 (例如 HTTPS、Windows 整合式安全性，或使用者名稱與密碼) 來驗證使用者，以建立加密的分散式的應用程式，您應該會非常熟悉 WCF 所運用的概念。如需詳細資訊，請參閱 IIS 與 .NET Framework 安全性。

  • IIS 安全性。 AppFabric 運用 IIS 安全性功能的子集，原因是它的服務在 Windows 處理序啟用服務 (WAS) 中主控，而且它的系統管理工具會在「IIS 管理員」中顯示。IIS 緊密地與 Windows 作業系統整合，為應用程式與資料提供最高等級的安全性。IIS 整合到 Windows NT 資訊安全模型與作業系統服務 (例如，檔案系統與目錄)。當 AppFabric 工作流程服務在執行階段需要存取持續性資料庫時，AppFabric 會運用應用程式集區身分識別的概念。IIS 與其他所有 Windows 服務相同，使用 Windows NT Server 存取控制清單 (ACL)。此外，因為 IIS 使用 Windows NT Server 使用者資料庫，AppFabric 系統管理員不需要在每部 Web 伺服器建立個別的使用者帳戶，而且內部網路使用者只需要登入到其網路一次就可。如需詳細資訊，請參閱 IIS 與 .NET Framework 安全性。

  • SQL Server 安全性。 AppFabric 建立 SQL Server 資料庫角色以控制對其持續性與監控資料庫的存取。AppFabric 使用 Windows 整合式驗證來控制對其 SQL Server 資料庫的存取。整合式安全性使用在呼叫執行緒中建立的現行 Windows 身分識別來存取 SQL Server 資料庫。您可以接著將 Windows 身分識別對應到 AppFabric SQL Server 資料庫與權限。如需詳細資訊，請參閱 SQL Server 安全性。

AppFabric 概念性安全性角色

了解 AppFabric 資訊安全模型有助於了解三個 AppFabric 安全性角色的屬性。這些角色完全是概念性，而且您在資訊安全模型的任何位置都不會發現具有這些名稱的實體。但是，概念性角色會在相對的對應實體 Windows 安全性群組與 SQL Server 資料庫角色中建立。在您的安全性解決方案中，您可以為這些角色指派使用者與權限，如下所示：

  • **應用程式伺服器觀察者。**這個系統管理角色可讓您檢視應用程式持續性與監控資料。應用程式伺服器觀察者可以：

    • 列舉應用程式與服務

    • 檢視應用程式與服務組態

    • 檢視監控資料

    • 檢查持續性執行個體

  • **應用程式伺服器系統管理員。**這個系統管理角色可讓您完全控制應用程式組態、監控與持續性。「應用程式伺服器系統管理員」除了可執行「應用程式伺服器觀察者」群組可執行的所有工作之外，還可以執行下列工作：

    • 暫停、繼續、終止、取消與刪除持續性執行個體

    • 建立並移除事件來源與事件收集器

    • 檢視、排清與封存監控資料

  • **應用程式伺服器使用者。**IIS 會在執行階段使用此執行階段角色，為其主控應用程式的所有應用程式集區指派識別身分。這可以讓應用程式中包含的服務共同存取持續性資料庫與系統服務。

身為 AppFabric 使用者，您只需知道當您設計安全性解決方案時，這些是三個概念性 AppFabric 角色。您只需要依照本文所述，將適當的使用者與權限指派到其對應的 Windows NT 群組與帳戶、IIS 應用程式集區，以及 SQL Server 登入與資料庫角色。如需有關使用 AppFabric 角色、其擁有的安全性權限，以及其如何對應到 Windows 安全性群組與 SQL Server 資料庫角色的詳細資訊與重要安全性指導方針，請參閱 Windows 安全性、IIS 與 .NET Framework 安全性與 SQL Server 安全性。

AppFabric 安全性的範圍

AppFabric 使用 Windows 安全性帳戶與 SQL Server 登入與資料庫角色來決定使用者或應用程式對系統資源 (例如，持續性資料庫、計時器資料、監控資料與組態檔) 的權限。存取這些資源的動作會在應用程式與管理等級中進行，這兩個等級是與 AppFabric 資訊安全模型相關的邏輯範圍區域。應用程式範圍包括以 IIS 應用程式方式主控的執行中 AppFabric 服務的處理緒。就系統管理觀點來看，管理範圍與 AppFabric 的管理有關。若要進一步了解三個 AppFabric 安全性角色的使用方式，讓我們看看在應用程式範圍與管理範圍的內容中使用這些安全性角色的方式。

應用程式範圍

應用程式範圍定義 .NET Framework 服務的實際執行狀況，這些服務在 AppFabric 中設定，並在 IIS 之下的 WAS 處理序空間中主控。它與系統管理或工具使用無關，而是落在管理範圍。應用程式領域概念適用於概念性的 AppFabric「應用程式伺服器使用者」安全性角色。此角色對應 IIS_IUSRS Windows 群組，它是用於 IIS 服務帳戶的 Windows 安全性群組。如需詳細資訊，請參閱 Windows 安全性、IIS 與 .NET Framework 安全性與 SQL Server 安全性。

每個應用程式都是在一個應用程式集區內執行。這個集區可以是預設應用程式集區，或是您可以建立及設定自己的應用程式集區 (建立及設定應用程式集區是系統管理的功能，在以下＜管理範圍＞小節中討論)。您可以使用應用程式集區將應用程式與服務分組到相同的工作者處理序空間，以便共用組態設定與其他作業系統實體。因為每個工作者處理序的運作方式都是做為工作者處理序可執行檔 (W3WP.EXE) 的個別執行個體使用，為單一應用程式集區提供服務的工作者處理序會與為另一個應用程式集區提供服務的工作者處理序區隔。如果您在應用程式自己的應用程式集區中主控應用程式，這可以達成應用程式隔離。應用程式隔離可以確保 Web 應用程式失敗時，不會影響在其他應用程式集區中執行的應用程式。

應用程式隔離的另一個優點是可以自訂安全性隔離。這可以確保當存取下游資源 (例如，SQL Server) 時，使用的是主控應用程式集區 (包含 AppFabric.NET Framework 服務) 之工作者處理序的已設定安全性主體。預設的應用程式集區身分識別是 Network_Service 帳戶。當您的應用程式集區是在 IIS 中設定時，您可以指派您自己的自訂 Windows 帳戶身分識別。在執行階段中，WAS 會使用在 IIS Metabase 中指定的 Web 應用程式繫結，將所有內送訊息從應用程式集區佇列轉送到適當的 W3WP.EXE 工作者處理序。這就是 AppFabric 允許 WCF 端點與服務使用非 HTTP 通訊協定進行啟用的方法。IIS 會動態取得其所有應用程式集區的 Windows 帳戶，然後將它們新增到本機 BUILTIN\IIS_IUSRS Windows 安全性群組。這表示如果您為您的應用程式建立自訂應用程式集區，IIS 會自動新增您應用程式集區的身分識別到 IIS_IUsers Windows 群組。

運用具有不同安全性身分識別的多重應用程式集區，可以在執行階段個別存取 AppFabric 持續性與監控資料庫，以達成應用程式隔離。根據預設值，這些資料庫可完全由所有已驗證的 AppFabric 身分識別 (由主控的應用程式集區所使用) 共用。使用隔離功能時若需要更高的安全性等級，您可以更細部地將存取特定資料庫資源的權限指派給特定 IIS 應用程式集區所使用的特定身分識別。您也可以建立您自己的特定應用程式資料庫，並確保特定身分識別可以連線到這些自訂資料庫，來控制執行階段的安全性。或者您可以針對個別應用程式設定，將應用程式與監控資料庫隔離，讓它只能存取持續性資料庫。

應用程式範圍也適用於 AppFabric 安裝並使用的系統服務：

  • **「事件收集」服務。**收集 AppFabric 與主控的應用程式所產生的事件。

  • **「工作流程管理」服務。**處理工作流程控制命令、使用到期計時器啟用工作流程執行個體，以及重新啟動已放棄的工作流程服務。

這兩個服務都是以 NTAuthority\LocalService 帳戶執行。LocalService 帳戶具有發出追蹤事件的權限，也可以操控持續性執行個體 (終止、暫停與繼續)。

增加安全性控制通常會造成效能降低。雖然應用程式隔離可提高安全性，但因為多重處理序的存在，它也需要使用更多的記憶體與處理序資源。為了保存資源，您必須使用 .NET Framework appDomain 模型 (而非個別的處理序) 來隔離應用程式。兩個以上的應用程式可以透過相同處理序中的不同 appDomains 來共存，彼此的虛擬記憶體及資料值互不影響。

管理範圍

管理範圍定義與應用程式系統管理相關的系統管理及工具使用。它跟 AppFabric 中所設定之 .NET Framework 服務的實際執行無關，這屬於應用程式範圍。管理範圍概念適用於概念性的 AppFabric「應用程式伺服器系統管理員」與「應用程式伺服器觀察者」安全性角色。

就系統管理與系統服務觀點來看，管理範圍與 AppFabric 及其支援技術的管理有關。您可以在應用程式執行前執行管理作業 (例如，將 .NET Framework 應用程式部署到 AppFabric 並進行設定)。當工作流程狀態已經寫入持續性資料庫而且它的下一步必須透過 AppFabric 使用者介面處理時，您也可以在執行期間執行管理作業。例如，暫停的工作流程可能需要繼續。管理在 AppFabric 中設定之 .NET Framework 服務的組態與執行的安全性權限，是以特定 Windows 安全性群組的成員資格為基礎。管理範圍也適用於「事件收集」服務與「「工作流程管理」服務」，但在此案例中是就管理與控制觀點 (而非應用程式觀點) 而論。

概念性的「應用程式伺服器系統管理員」與「應用程式伺服器觀察者」安全性角色分別對應到本機 AS_Administrators 與 AS_Observers Windows NT 安全性群組。AS_Administrators 群組包含「「工作流程管理」服務」與「事件收集」服務的服務識別碼 (SID)。在服務向「服務控制管理員」註冊之後，它們的 SID 就保持固定。這表示「事件收集」服務與「「工作流程管理」服務」將會成為 AS_Administrators 的成員，無論它們是用哪個身分識別執行。這個身分識別通常是 NTAuthority\LocalService。所以使用 SID (而非服務身分識別) 能確保以 NTAuthority\LocalService 身分識別執行的其他處理序或服務不會成為 AS_Administrators 的成員。如需有關 AppFabric 概念性安全性角色與這些角色之使用方式的詳細資訊，請參閱 Windows 安全性、IIS 與 .NET Framework 安全性與 SQL Server 安全性。

AppFabric 會在安裝期間確立管理範圍。當 Windows PowerShell Cmdlet 在安裝期間建立監控與持續性資料庫時，會根據對應的概念性 AppFabric 安全性角色建立適當的 SQL Server 資料庫。例如，在 SQL Server 中針對 AS_Observers 角色建立的所有角色都是讀者角色 (MonitoringDbReader 角色用於監控資料庫，而 System.Activities.DurableInstancing.InstanceStoreObservers 角色用於持續性資料庫)。就系統管理觀點來看，為 AS_Administrators 登入帳戶所定義的 SQL Server 資料庫角色包含所有連結到 AS_Observers 登入帳戶的資料庫角色以及額外角色，可用來建立及修改資料庫實體。

根據預設值，AppFabric 安裝程式會在其程序中執行某些 AppFabric Cmdlet。針對 AppFabric 的單一伺服器安裝，AppFabric 會建立所有必要的本機 Windows 安全性群組與帳戶。若要在一或多部伺服器中使用 AppFabric，您將必須手動建立 Windows 網域群組並將它們指派到適當的 Windows 安全性群組，才能讓該伺服器遠端管理 AppFabric 安裝。身為系統管理員，您應該將網域群組建立為「應用程式伺服器系統管理員」與「應用程式伺服器觀察者」概念性安全性角色 (也就是 DOMAIN\MyAppFabricAdmins 及 DOMAIN\MyAppFabricObservers) 的實體顯示。然後您可以在網域中的所有 AppFabric 電腦上，指派這些網域帳戶到 LOCAL\AS_Administrators 與 LOCAL\AS_Observers 群組。

自訂 Windows PowerShell 指令碼與 AppFabric Cmdlet 的資訊安全模型

對於自訂 Windows PowerShell 指令碼，或是 AppFabric 版本包含的許多 Windows PowerShell Cmdlet，AppFabric 不提供新的資訊安全模型。至於其資訊安全模型的其他層面，AppFabric 在其支援技術中採用現有的資訊安全模型。在此案例中，AppFabric 使用 Windows PowerShell 資訊安全模型以強制套用安全性到自訂指令碼與預先封裝的 AppFabric Cmdlet。

當 AppFabric Windows PowerShell 指令碼執行時，它會使用其主控處理序的身分識別來完成這個動作。這表示執行 Cmdlet 的使用者安全性主體透過處理序識別碼方式傳遞。在資訊安全內容下，除了執行主控處理序的使用者身分識別外，無法使用模擬身分識別的方式來執行 Cmdlet。

根據預設，雖然您能以互動方式執行 Windows PowerShell 命令，但基於安全性考量，預設會停用執行 Windows PowerShell 指令碼的功能。您必須透過「Windows PowerShell 指令碼執行」群組原則啟用這個設定，才能執行指令碼。

AppFabric 隨附的 Windows PowerShell 指令碼利用從憑證授權單位 (CA) 取得的憑證加以數位簽署。使用從 CA 取得的數位憑證簽署實體可以保護套件的完整性。透過使用單向雜湊處理與公開金鑰加密演算法，簽署程序可以確保在製作者簽署套件之後，任何對套件所作的變更可以被偵測，而且後續的指令碼執行動作將被封鎖。您也可以使用數位簽章來驗證簽署的實體的確是由聲稱建立實體的組織所建立。使用本機 CA 及 Microsoft Certificate Server 產生自我簽署憑證是一個簡單又低成本的 CA 使用替代方案。您可以使用私密金鑰加密來進一步保護憑證。

security安全性 注意
使用本機 CA 來簽署 Windows PowerShell 指令碼套件在它的信任原則中具有最低位階。雖然本機簽署的套件受到本機系統的信任，但如果在外部系統執行則不受到信任。

同盟識別身分管理與單一登入 (SSO)

同盟驗證系統也稱為網頁單一登入 (SSO) 系統。同盟系統可以跨越組織界限運作，並連接使用不同技術、身分識別儲存區、安全性方法與程式設計模型的處理序。使用 Active Directory Federation Service (ADFS)，某公司的使用者可以使用其現有 Active Directory 帳戶來存取其他公司主控的伺服器。ADFS 也會在兩家公司之間建立信任關係，並為使用者提供順暢的單一登入 (SSO) 體驗。它也可以讓組織安全地共用使用者的身分識別資訊。

在許多方面而言，AppFabric 所管理的 HTTP 型應用程式其實就是 IIS 應用程式。若要將同盟識別身分別管理與網頁 SSO 驗證整合到您的應用程式中，您可以使用 ADFS，如同您為 IIS 應用程式使用它一般。ADFS 會將存取應用程式的登入帳戶對應到網域帳戶，然後使用該網域帳戶向 IIS 驗證。 

因為 .NET Framework 4 針對其管理之服務與其用戶端之間的通訊使用 WCF 及其資訊安全模型，僅支援 HTTP 型應用程式的傳統 IIS 模型現在已經可以支援非 HTTP 型應用程式。如果您使用 HTTP 但未使用傳輸驗證，或使用 HTTP 結合非 HTTP 應用程式，請在您的服務內以程式設計介面實作宣告身分識別處理。宣告感知 (Claims-Aware) 應用程式會使用 ADFS 安全性權杖中的宣告來執行授權決策，並提供額外的應用程式個人化。如同 ADFS，您應該了解宣告身分識別處理如何與 IIS 應用程式共同運作，以便在您的應用程式中整合宣告處理。

本節內容

另請參閱

其他資源

WF 安全性封裝 CTP

  2011-12-05