Office 方案的安全性最佳作法 (2003 系統)

發行項
09/10/2008

更新：2007 年 11 月

適用於
本主題中的資訊僅適用於指定的 Visual Studio Tools for Office 專案和 Microsoft Office 版本。專案類型文件層級專案應用程式層級專案 Microsoft Office 版本 Microsoft Office 2003 如需詳細資訊，請參閱依應用程式和專案類型提供的功能。

本主題中的資訊僅適用於指定的 Visual Studio Tools for Office 專案和 Microsoft Office 版本。

專案類型

文件層級專案
應用程式層級專案

Microsoft Office 版本

Microsoft Office 2003

如需詳細資訊，請參閱依應用程式和專案類型提供的功能。

當您規劃文件層級自訂和應用程式層級增益集的安全性原則時，請考量下列問題。

將條件加入至安全性原則

Microsoft .NET Framework 提供兩種主要方式讓您部署原則：

使用 .NET Framework 組態工具建置 Windows Installer (.msi) 檔案。如需詳細資訊，請參閱部署安全性原則。
藉由對程式碼存取安全性原則工具 (Caspol.exe) 編寫指令碼，來直接修改原則。如需詳細資訊，請參閱使用程式碼存取安全性原則工具 (Caspol.exe) 設定安全性原則。

使用 Windows Installer 檔案更能產生可預期的原則評估，因為整個原則層級 (通常是企業或電腦) 都會複製到使用者的電腦中。不過，如果公司的不同部門想要各自獨立發行原則，或者個別使用者需要變更其原則，這個方式可能會產生衝突。

使用 Caspol.exe 修改原則可讓不同使用者各自獨立更新原則，但是由於不同程式碼群組之間的未知互動，使得無法保證任何特定的原則變更都能達成所要的效果。例如，如果某個部門部署原則變更，對特定內部網路網站授與完全信任，則該部門會預期可信任來自該網站的所有程式碼。不過，如果另一個部門使用拒絕存取該網站的 Exclusive 屬性部署原則，則將不會執行任何程式碼。如需 Exclusive 屬性的詳細資訊，請參閱程式碼群組屬性的管理和 HOW TO：使程式碼群組成為 Exclusive 或最終層級。

系統管理員在決定如何更新原則時，需要在 Windows Installer 檔案的可預期性和 Caspol.exe 的彈性之間取得平衡。

請注意，雖然您也可以透過 Microsoft .NET Framework API 撰寫 Managed 程式碼來直接管理原則，不過這樣做很難正確建立原則，強烈建議不要採行這種作法。

檢查目前的原則

如果組件沒有執行，則可以檢閱指派給該組件的使用權限，以調查可能的原因。Microsoft .NET Framework 提供下列兩種方式，讓您檢查組件目前的原則：

使用 [評估組件] 精靈，該精靈包含在 Microsoft .NET Framework 2.0 組態工具中。如需存取這個精靈的詳細資訊，請參閱 HOW TO：使用 .NET Framework 組態工具 (Mscorcfg.msc) 執行通用安全性原則工作。
執行下列 Caspol.exe 命令：
```
caspol -all -lg
caspol -rsg path_to_assembly
```
如需 Caspol.exe 命令的詳細資訊，請參閱程式碼存取安全性原則工具 (Caspol.exe)。

這些工具會顯示套用至組件的安全性原則，以及組件的辨識項如何對應至 Common Language Runtime (CLR) 中的這些規則。這可指出原則是否設定正確，以及組件是否符合正確的程式碼群組。使用此技術可以凸顯的主要問題包括：

當某個網規則 (例如，指派完全信任給 https://server/) 應該位於 LocalIntranet 中，卻被加入至 MyComputer 區域；或是當該項網路規則應該位於 TrustedSites 時，卻被加入至 LocalIntranet。
檔名或 URL 中有錯誤。
目錄路徑中遺漏星號 (*)，此星號指出該資料夾底下的所有檔案和子資料夾應包含在原則中。

如需詳細資訊，請參閱使用 Caspol.exe 解決安全性原則問題。

設定企業的預設原則

Visual Studio 可讓企業定義自己的預設原則。通常，當您對安全性原則執行重設時，該原則會還原回安裝 Framework 後所存在的預設值。使用特定企業預設原則時，重設動作會還原由特定企業所定義的基本原則。例如，企業可能會將信任的發行者加入至企業層級，並阻擋來自網際網路區域的所有程式碼。

如需返回預設原則的詳細資訊，請參閱 HOW TO：使用 Caspol.exe 返回預設安全性原則設定和 .NET Framework 組態工具 (Mscorcfg.msc)。如需預設安全性原則的詳細資訊，請參閱預設安全性原則。

一般建議

決定 Office 方案的原則時，請考慮使用下列方針：

永遠使用具名程式碼群組，而不要仰賴其號碼 (例如，使用 MyComputer_Zone 而非 1.1)。雖然使用者可能會重新命名群組 (例如，將 Internet 重新命名為 MyComputer)，不過這個可能性會比變更號碼來得低。
盡可能嚴格約束規則將套用至的程式碼。絕不在電腦層級將規則加入至 All_Code 群組，永遠將規則加入至區域或區域底下的另一個子群組。最好不要設定管理未預期之程式碼的規則。
先使用最廣泛適用的規則，例如依序為區域、網站、發行者 (Publisher)，而非發行者、網站、區域。這樣一來，特定區域規則就可以套用至特定程式碼，而且在您確定是否需要限制以前，將不會套用至發行者的所有程式碼。
如果父群組 (例如 LocalIntranet_Zone 群組) 已不存在，應該重新建立該群組。請注意，您必須以 Nothing 使用權限集合來執行這個動作。Nothing 使用權限集合可避免套用系統管理員透過刪除程式碼群組所關閉的預設使用權限。例如，如果系統管理員刪除了 LocalIntranet_Zone，則所有的近端內部網路程式碼都會停止執行。當您重建程式碼群組並使用 Nothing 使用權限集合時，並不會加入先前不存在的任何使用權限。
關閉批次 (Batch) 檔中的原則變更警告，而且如果一開始警告是開啟的，請記得於事後重新開啟這些警告。這樣一來，您的批次檔就不會停止，並等候使用者輸入。這項設定會影響所有的使用者，而不只是目前的使用者而已。如需詳細資訊，請參閱 HOW TO：使用 Caspol.exe 隱藏原則變更警告。
使用 Caspol.exe 時，請明確地指定要修改的原則層級 (企業、電腦或使用者)，而不要依賴預設。預設對於您正在修改的原則可能不是正確的。如需詳細資訊，請參閱安全性原則層級。
除非絕對必要，否則請勿使用 Exclusive 或 Level-Final 屬性，因為它們會在加入新程式碼群組時導致未預期的行為。如需詳細資訊，請參閱程式碼群組屬性。