建置安全的服務元件

本頁內容

	本單元內容
	目標
	適用於
	如何使用本單元
	概觀
	潛在威脅及因應對策
	設計考量
	驗證
	授權
	設定管理
	機密資料
	稽核和記錄
	建置安全服務元件
	程式碼存取安全性考量
	部署考量
	總結
	其他資源

本單元內容

服務元件為 COM+ 基礎結構服務，亦稱為 Enterprise Services。可以從 Managed 程式碼存取它們，它們包含一或多個衍生自 System.EnterpriseServices.ServicedComponent 的 Managed 類別。

本單元說明 Enterprise Services (COM+) 安全性如何依賴 Windows 安全性來驗證及授權呼叫者，以及健全的程式碼技術和適當的目錄設定如何確保服務元件的安全部署。

本單元以開發人員為主要對象，也包含一些範例來示範如何建立安全服務元件。

回到頁首

目標

透過本單元即可：

回到頁首

適用於

本單元適用於下列產品及技術：

回到頁首

如何使用本單元

若要充分瞭解本單元：

回到頁首

概觀

COM+ 基礎結構服務也稱為 Enterprise Services，可從 Managed 程式碼加以存取。Enterprise Services 應用程式是由一或多個服務元件組成，這些是 Managed 類別，衍生自 System.EnterpriseServices.ServicedComponent。

服務元件通常是用來封裝應用程式的企業及資料存取邏輯，當應用程式中間層有需要分散式交易、物件集區、佇列元件及其他等基礎結構服務時，也會使用服務元件。Enterprise Services 應用程式通常位於中間層應用程式伺服器上，如 [圖 11.1] 所示。

[圖 11.1]
中間層 Enterprise Services 應用程式的服務元件

回到頁首

潛在威脅及因應對策

在建立服務元件時，您必須對付的最大潛在威脅如下：

[圖 11.2] 指出這些最大潛在威脅與一般服務元件弱點。

[圖 11.2]
Enterprise Services 潛在威脅

網路竊聽

Enterprise Services 應用程式通常是在中間層應用程式伺服器上執行，與 Web 伺服器距離遙遠。因此，必須保護機密應用程式資料以免遭到網路竊聽者攻擊。您可以在 Web 伺服器和應用程式伺服器之間使用「網際網路通訊協定安全性」(IPSec) 加密通道。此解決方案通常用於網際網路資料中心。服務元件亦支援遠端程序呼叫 (RPC) 封包層級驗證，它提供封包型加密。這通常用來保障桌上型用戶端的通訊安全。

未授權存取

透過啟用 COM+ 角色為基礎的授權 (在預設狀況下，它在 Microsoft Windows 2000 是停用的)，您可以防止匿名存取並提供以角色為基礎的授權，以控制服務元件所暴露的受限制作業的存取。

未限制的委派

如果您在 Windows 2000 啟用委派，以允許遠端伺服器使用用戶端的模擬記號來存取網路資源，則委派不受限制。這表示可產生的網路躍點數目不受限制。Microsoft Windows Server 2003 具有受限制委派。

公開設定資料

許多應用程式使用物件建構函式將機密資料 (如資料庫連線字串) 儲存在 COM+ 目錄中。建立物件時，COM+ 會擷取這些字串並傳送到該物件。在儲存於目錄之前，應該加密機密設定資料。

否認

當使用者拒絕執行作業或交易時，而您沒有足夠證據來反制這項聲明時，就會發生否認潛在威脅。稽核作業應該在所有應用程式層執行。服務元件應該在中間層記錄使用者活動。服務元件通常可存取原始呼叫者的識別身份，因為前端 Web 應用程式通常會在 Enterprise Services 案例中啟用模擬。

回到頁首

設計考量

在開始撰寫程式碼之前，有一些重要問題在設計時期需要考量。主要考量如下：

以角色為基礎的授權

若要使用 COM+ 角色達到有效的以角色為基礎授權，請確定對服務元件的呼叫有使用原始呼叫者的安全性內容。這可讓您依據呼叫者的群組成員資格，執行細微的以角色為基礎的授權。如果 ASP.NET Web 應用程式呼叫服務元件，這表示 Web 應用程式在呼叫元件之前需要模擬其呼叫者。

機密資料保護

如果服務元件處理機密資料，例如員工詳細資料、財務交易和健康狀況記錄，請考慮如何保護通過網路的資料。如果應用程式不是在安全的 Internet Data Center (IDC) 環境執行 (其中 IPSec 提供傳輸層級加密)，則替代選項是使用 RPC 加密。針對此項，您必須使用封包私密性驗證層級。如需詳細資訊，請參閱本單元後面的「機密資料」一節。

稽核需求

若要對付否認潛在威脅，應該記錄企業服務元件執行的機密交易。在設計時期，請考慮應該稽核的作業類型，以及應該記錄的詳細資料。至少，應該包括啟動交易的識別身份以及用來執行交易的識別身份，兩者不一定相同。

應用程式啟動類型

在設計時期，決定如何啟動服務元件。您可以使用 Dllhost.exe 處理序的執行個體來啟動它們，或在用戶端處理序內執行它們。在 Dllhost.exe 的執行個體中，伺服器應用程式是從處理序執行。程式庫應用程式是在用戶端的處理序位址空間內執行。程式庫應用程式更有效率，因為缺少處理序間通訊。不過，它們較少進行設定，且不受處理序層級隔離之保護。許多安全性設定如驗證和模擬層級，是從用戶端處理序繼承而來。

交易

如果您打算使用分散式交易，請考量在何處啟動交易，並考量在由防火牆隔開的元件和資源管理員之間執行交易的含意。在此案例中，防火牆必須設定為支援 Microsoft 分散式交易協調器 (DTC) 資料傳輸。

如果實體部署架構包括中間層應用程式伺服器，通常最好從應用程式伺服器上的 Enterprise Services 應用程式啟動交易，而不要從前端 Web 應用程式啟動。

程式碼存取安全性

通常，使用服務元件的應用程式是可以完全信任的，因此，程式碼存取安全性的使用僅限於授權呼叫程式碼。不過，Enterprise Services 要求呼叫程式碼要有必要的權限才能呼叫 Unmanaged 程式碼。其主要含意是您無法直接從部分信任的 Web 應用程式呼叫 Enterprise Services 應用程式。ASP.NET 部分信任等級 (高、中、低、最小) 不授與 Unmanaged 程式碼權限。如果您需要從部分信任的應用程式呼叫服務元件，則呼叫元件的特殊權限程式碼必須為沙箱式程式碼。如需詳細資訊，請參閱本單元後面的「程式碼存取安全性考量」。

回到頁首

驗證

Enterprise Services 應用程式使用 Windows 驗證。這是 NTLM 或 Kerberos 驗證，視用戶端和伺服器作業系統而定。在 Windows 2000 或 Windows Server 2003 環境中，是使用 Kerberos 驗證。

在建立服務元件時，您的主要考量是如何確定所有呼叫已通過驗證，以防止匿名使用者存取元件的功能。

使用 (至少) 呼叫層級驗證

若要拒絕匿名呼叫者，請至少使用呼叫層級驗證。藉由在服務元件組件中新增下列屬性來完成此設定：

[assembly: ApplicationAccessControl(
Authentication = AuthenticationOption.Call)]

注意 這相當於在元件服務中的應用程式 [內容] 對話方塊的 [安全性] 索引標籤上，將 [呼叫的驗證層級] 設定為 [呼叫]。

回到頁首

授權

Enterprise Services 使用 COM+ 角色進行授權。您可以控制應用程式、元件、介面和方法的授權細微性。若要防止使用者執行應用程式的服務元件所暴露的受限制作業：

啟用以角色為基礎的安全性

在預設狀況下，以角色為基礎的安全性在 Windows 2000 是停用的。在 Windows Server 2003 則相反。若要確定元件註冊時 (通常是使用 Regsvcs.exe) 會自動啟用以角色為基礎的安全性，請在服務元件組件中新增下列屬性。

[assembly: ApplicationAccessControl(true)]

注意 使用此屬性相當於在元件服務中的應用程式 [內容] 對話方塊的 [安全性] 索引標籤上，選取 [強制此應用程式的存取檢查]。

啟用元件層級存取檢查

必須啟用元件層級存取檢查，以支援元件、介面或方法層級角色檢查。若要確定元件註冊時會自動啟用元件層級存取檢查，請在服務元件組件中新增下列屬性。

[assembly: ApplicationAccessControl(AccessChecksLevel= 
AccessChecksLevelOption.ApplicationComponent)]

注意 使用此屬性相當於在元件服務中的應用程式 [內容] 對話方塊的 [安全性] 索引標籤上，選取 [執行處理序及元件層級的存取檢查]。

強制元件層級存取檢查

若要允許個別元件執行存取檢查，您必須強制元件層級存取檢查。如上所述，唯有當全應用程式安全性層級是設定為處理序及元件層級時，此設定才有效。若要確定元件註冊時會自動啟用元件層級存取檢查，請在服務元件類別中新增下列屬性。

[ComponentAccessControl(true)]
public class YourServicedComponent : ServicedComponent
{
}

注意 使用此屬性相當於在元件服務中的元件 [內容] 對話方塊的 [安全性] 索引標籤上，選取 [強制元件層級存取檢查]。

回到頁首

設定管理

除了 COM+ 透過元件服務工具提供給系統管理員的可組態設定之外，開發人員通常會在程式碼中執行與設定相關的函數。例如，函數可擷取儲存在 COM+ 目錄中的物件建構字串。當您在 Enterprise Services 中使用設定管理時，主要考量如下：

使用最小權限執行方式帳戶

在開發期間，使用最小權限本機帳戶代替互動式使用者帳戶來執行及測試服務元件。設定帳戶儘量符合系統管理員在生產環境中很可能使用的執行方式帳戶。

避免在物件建構函式字串中儲存機密

如果您在 COM+ 目錄的物件建構函式字串中儲存像資料庫連線字串或密碼之類的機密，則本機系統管理員群組的任何成員都可以檢視此純文字資料。儘量避免儲存機密。如果您必須儲存機密，請加密資料。DPAPI 是理想的實作選項，因為它可讓您避免金鑰管理的相關問題。

在執行時期，擷取物件建構字串並使用 DPAPI 解密資料。有關使用 Managed 程式碼中的 DPAPI 的詳細資訊，請參閱 MSDN 文章《建置安全的 ASP.NET 應用程式》中的＜How to create a DPAPI library＞，網址是：http://www.microsoft.com/taiwan/msdn/books/ataglance/secnetlpMSDN.htm。

[ConstructionEnabled(Default="")]
public class YourServicedComponent : ServicedComponent, ISomeInterface
{
// 先呼叫物件建構函式。
public YourServicedComponent() {}
// 然後將物件建構函式字串傳送至 Construct 方法。
protected override void Construct(string constructString)
  {
// 使用 DPAPI 解密設定資料。
  }
}

避免未限制的委派

視環境而定，服務元件用戶端是以 NTLM 或 Kerberos 驗證方式加以驗證。Windows 2000 中的 Kerberos 支援未限制的委派；這表示可對用戶端憑證產生的網路躍點數目沒有限制。

如果 ASP.NET 是用戶端，則您可以在 Machine.config 中的 <processModel> 元件上設定 comImpersonation 屬性，來設定模擬層級：

comImpersonationLevel="[Default|Anonymous|Identify|Impersonate|Delegate]"

對 Enterprise Services 伺服器應用程式定義的模擬層級可決定與服務元件進行通訊的任何遠端伺服器的模擬能力。在此案例中，服務元件是用戶端。您可以使用下列屬性指定服務元件的模擬層級，當服務元件是用戶端時可套用它：

[assembly: ApplicationAccessControl(
ImpersonationLevel=ImpersonationLevelOption.Identify)]

注意 使用此屬性相當於在元件服務內的應用程式 [內容] 對話方塊的 [安全性] 頁面上，設定 [模擬層級] 值。

下表描述每一個模擬層級的作用：

[表 11.1]：模擬層級

如需詳細資訊，請參閱單元 17＜保障應用程式伺服器的安全＞中的「模擬」一節，以及 MSDN 文章《建置安全的 ASP.NET 應用程式》的＜References＞一節中的「How to Enable Kerberos Delegation in Windows 2000」，網址是：http://www.microsoft.com/taiwan/msdn/books/ataglance/secnetlpMSDN.htm。

回到頁首

機密資料

如果應用程式透過網路在服務元件中來回傳輸機密資料，為了對付網路竊聽潛在威脅，此資料應加密，以確定資料維持私密及不變。您可以使用具有 IPSec 的傳輸層級保護，或使用應用程式層級保護，其做法是設定 Enterprise Services 應用程式使用 RPC 封包私密驗證層級。這樣會加密每一個在服務元件中來回傳送的資料封包，以提供私密性和完整性。

您可以使用元件服務工具，或在服務元件組件中新增下列屬性，來設定封包私密性驗證：

[assembly: ApplicationAccessControl(
Authentication = AuthenticationOption.Privacy)]

有關使用 IPSec 加密兩部電腦之間傳輸的所有資料的詳細資訊，請參閱《Microsoft patterns & practices Volume I, 建置安全的 ASP.NET 應用程式: 驗證、授權和安全通訊》的＜How To＞一節中的＜How To: Use IPSec to Provide Secure Communication Between Two Servers＞，網址是：http://www.microsoft.com/taiwan/msdn/books/ataglance/secnetlpMSDN.htm。

回到頁首

稽核和記錄

應該在應用程式各層執行稽核和記錄，以避免否認潛在威脅，讓使用者拒絕執行特定交易或金鑰作業。

稽核使用者交易

如果 Web 應用程式或 Web 服務已設定為模擬，則原始呼叫者的識別身份會流向 Enterprise Services 應用程式，並可使用 SecurityCallContext.OriginalCaller 加以取得。這對於在中間層稽核很有用。下列程式碼顯示如何存取此資訊：

[ComponentAccessControl]
public class YourServicedComponent : ServicedComponent
{
public void ShowCallers()
  {
SecurityCallers callers = SecurityCallContext.CurrentCall.Callers;
foreach(SecurityIdentity id in callers)
    {
LogEvent(id.AccountName);
    }
  }
private void LogEvent(string message)
  {
try
    {
if (!EventLog.SourceExists(appName))
      {
EventLog.CreateEventSource(appName, eventLog);
      }
EventLog.WriteEntry(appName, message, EventLogEntryType.Information );
    }
catch (SecurityException secex)
    {
throw new SecurityException(
"Event source does not exist and cannot be created.", secex);
    }
  }
}

若要順利寫入事件日誌，事件來源必須存在，以結合 Enterprise Services 應用程式與特定事件日誌。上述程式碼在執行時期建立事件來源，這表示服務元件處理序帳戶必須在系統登錄中已有相關權限。

HKLM\SYSTEM\CurrentControlSet\Services\Eventlog

當具有系統管理員權限時，其替代策略是在安裝時期使用 Installer 類別及建立應用程式的事件來源。有關此方法的詳細資訊，請參閱單元 10＜建置安全的 ASP.NET 網頁和控制項＞中的「稽核和記錄」。

回到頁首

建置安全服務元件

下列程式碼片段涵蓋適合服務元件和 Enterprise Services應用程式的潛在威脅及因應對策，以一個簡單的 Customer 類別實作來說明安全服務元件的主要特性。為了清楚起見，已省略方法實作詳細資料。

組件實作

下列程式碼片段來自 assemblyinfo.cs，顯示當服務元件組件是使用 regsvcs.exe 在 Enterprise Services 中登錄時，用來設定 COM+ 目錄的組件層級中繼資料。

// (1) 組件有一個增強名稱。
[assembly: AssemblyKeyFile(@"..\..\Customer.snk")]

// Enterprise Services 設定
[assembly: ApplicationName("CustomerService")]
[assembly: Description("Customer Services Application")]
// (2) 伺服器應用程式 - 在 dllhost.exe 處理序執行個體中執行。
[assembly: ApplicationActivation(ActivationOption.Server)]
// (3) 啟用元件層級存取檢查。
// (4) 指定呼叫層級驗證。
// (5) 指定下游呼叫的識別模擬層級。
[assembly: ApplicationAccessControl(
AccessChecksLevel=AccessChecksLevelOption.ApplicationComponent,
Authentication=AuthenticationOption.Call,
ImpersonationLevel=ImpersonationLevelOption.Identify)]

上述程式碼顯示下列安全性特性 (由註解行的數字指出)。

服務元件類別實作

下列程式碼片段強調部份實作的 Customer 類別的安全性設定。

namespace busCustomer
{
// (1) 明確介面定義，以支援方法層級授權
public interface ICustomerAdmin
  {
void CreditAccountBalance(string customerID, double amount);
  }
// (2) 強制執行元件層級存取檢查。
[ComponentAccessControl]
public sealed class Customer : ServicedComponent, ICustomerAdmin
  {
private string appName = "Customer";
private string eventLog = "Application";
// ICustomer 實作
// (3) 對 CreditAccountBalance 的存取限於
//     Manager 和 Senior Manager 角色的成員。
[SecurityRole("Manager")]
[SecurityRole("Senior Manager")]
public void CreditAccountBalance(string customerID, double amount)
    {
// (4) 結構化例外處理，以保護實作。
try
      {
// (5) 檢查已啟用安全性。
if (ContextUtil.IsSecurityEnabled)
        {
// 僅經理的賒帳總額可以超過
// $1,000。
if (amount > 1000) {
// (6) 程式設計角色檢查，以授權貸款作業
if (ContextUtil.IsCallerInRole("Senior Manager")) {
// 呼叫資料存取元件以更新資料庫。
              . . .
// (7) 稽核交易。
AuditTransaction(customerID, amount);
            }
else {
throw new SecurityException("Caller not authorized");
            }
          }
        } 
else {
throw new SecurityException("Security is not enabled");
        }
      }
catch( Exception ex)
      {
// 記錄例外狀況詳細資料。
throw new Exception("Failed to credit account balance for customer: " +
customerID, ex);
      }
    }
private void AuditTransaction(string customerID, double amount)
    {
// (8) 原始呼叫者識別身份是基於記錄目的而從呼叫內容取得。
//     
SecurityIdentity caller = SecurityCallContext.CurrentCall.OriginalCaller;
try
      {
if (!EventLog.SourceExists(appName))
        {
EventLog.CreateEventSource(appName,eventLog);
        }
StringBuilder logmessage = new StringBuilder();
logmessage.AppendFormat("{0}User {1} performed the following transaction" 
+ "{2} Account balance for customer {3} "
+ "credited by {4}",
Environment.NewLine, caller.AccountName, 
Environment.NewLine, customerID, amount);
EventLog.WriteEntry(appName, logmessage.ToString(), 
EventLogEntryType.Information);
      }
catch(SecurityException secex)
      {
throw new SecurityException(
"Event source does not exist and cannot be created", secex);
      }
    }
  }
}

上述程式碼顯示下列安全性特性 (由註解行的數字指出)：

回到頁首

程式碼存取安全性考量

通常，使用服務元件的應用程式是可以完全信任的，因此，程式碼存取安全性的使用僅限於授權呼叫程式碼。呼叫程式碼應考量下列要點：

<trust level="Full" />

回到頁首

部署考量

Enterprise Services 應用程式通常是安裝在 Web 伺服器上或遠端應用程式伺服器上。[圖 11.3] 顯示 Enterprise Services 的兩個典型部署案例。從安全性角度來看，遠端部署案例的明顯差別，是當服務元件在網路上來回傳送時，通常是透過用來隔開內部網路和周邊網路的內部防火牆。

[圖 11.3]
Enterprise Services 典型部署設定

開發人員和系統管理員需要知道下列部署相關議題：

有關在部署時期套用安全設定的詳細資訊，請參閱單元 17＜保障應用程式伺服器的安全＞。

防火牆限制

如果用戶端和 Enterprise Services 應用程式由內部防火牆隔開，則支援 DCOM 及可能的 DTC (如果應用程式使用分散式交易的話) 的相關埠必須開啟。

DCOM 使用 RPC 動態埠配置，在預設狀況下，此配置會隨機選取 1024 以上的埠號。此外，埠 135 是由 RPC 端點對應程式所使用。您可以在內部防火牆上以兩種方式來限制支援 DCOM 所需要的埠：

有關定義埠範圍和靜態端點對應的詳細資訊，請參閱單元 17＜保障應用程式伺服器的安全＞中的「防火牆考量」。

使用 Web 服務

如果不能選擇在內部防火牆開啟埠，那麼您可以在應用程式伺服器上的服務元件前面採用 Web 服務外貌層。這表示您只需要開啟埠 80，讓 HTTP 資料傳輸及特別針對的「簡易物件存取通訊協定」(SOAP) 訊息雙向流入，如 [圖 11.4] 所顯示。

[圖 11.4]
使用 Web 服務外貌層與使用 HTTP 的 Enterprise Services 通訊

此方法禁止您從用戶端傳送交易內容至伺服器，雖然在許多情況下，部署結構包括中間層應用程式伺服器，但在應用程式伺服器上的遠端服務元件中啟動交易是可行的。

有關服務代理程式及服務介面 (如 Web 服務外貌層) 的實體部署需求之資訊，請參閱 MSDN 文章《Application Architecture for .NET: Designing Applications and Services (英文)》的＜Reference＞一節的「Physical Deployment and Operational Requirements」。

DTC 需求

如果這些應用程式使用 COM+ 分散式交易，而且都跨越以內部防火牆隔開的遠端伺服器使用，則此防火牆必須開啟必要的連接埠以支援 DTC 資料傳輸。

如果部署架構包括遠端應用程式層，則通常是在 Enterprise Services 應用程式內啟動交易，然後傳入資料伺服器。在缺乏應用程式伺服器的狀況下，Web 伺服器上的 Enterprise Services 應用程式會啟動交易，並將它傳播給 SQL Server 資源管理員。

有關設定防火牆以支援 DTC 資料傳輸的資訊，請參閱單元 18＜保障資料庫伺服器的安全＞。

回到頁首

總結

Enterprise Services (COM+) 安全性依賴 Windows 安全性來驗證和授權呼叫者。授權是以 COM+ 角色設定及控制，角色包含 Windows 群組或使用者帳戶。與 Enterprise Services 應用程式和服務元件相關的大部份潛在威脅，可利用健全的編碼技術和適當的目錄設定來對付。

開發人員應該使用宣告式屬性來設定服務元件安全性設定。這些屬性決定一開始在 Enterprise Services 中註冊應用程式時 (通常是使用 Regsvcs.exe) 會如何設定應用程式。

並非每一個安全性設定都可以用屬性來設定。系統管理員必須對伺服器應用程式指定執行方式識別身份。系統管理員也必須在部署時期將 Windows 群組或使用者帳戶填入角色。

當您開發服務元件或評估企業安全性解決方案的安全性時，請使用本指南的＜檢查清單＞一節的＜檢查清單：保障 Enterprise Services 的安全＞。

回到頁首

其他資源

有關其他詳細資訊，請參閱下列資源：

回到頁首