本章提供有關如何擷取必要資訊來規劃與部署伺服器和域隔離解決方案的資訊。 成功的部署要求準确地了解最新的資訊技術 (IT) 基礎結構。 閱讀本章後，您将對完成伺服器和域隔離解決方案設計所需的資訊有很好的了解。
本章最後讨論有關了解并記錄辨別的哪些計算機很可能可以充當解決方案中“受信任”的計算機的過程。 設計小組在制定解決方案的規劃時，将需要這些資訊。
本頁内容
 | 本章先決條件 |
| | 本章的目标讀者 |
| | 确定目前狀态 |
| | 容量事項 |
| | 部署前的考慮事項 |
| | 信任确定 |
| | 預計目前主機的更新成本 |
| | 總結 |
本章先決條件
在使用本章中的資訊之前，應確定您和您的組織符合以下先決條件。 本章提供的指導專門用于滿足基本符合這些先決條件的組織的需求。 無法滿足所有這些先決條件不一定會對您的項目産生負面影響，但如果滿足這些先決條件，将可以最大程度地實作本指南的價值。
預備知識
應熟悉 IPsec 的概念，同時充分了解以下各項：
| • | Microsoft® Windows® 身份驗證（特别是 Kerberos V5 身份驗證協定） |
| • | Active Directory® 目錄服務概念，包括 Active Directory 結構和工具；操縱使用者、組和其他 Active Directory 對象；以及組政策的使用 |
| • | Windows 系統安全，包括安全概念，如使用者、組、稽核和通路控制表 (ACL) |
| • | 組織的系統命名約定 |
| • | 組織的地理位置和邏輯位置 |
| • | 組織中使用的風險管理實踐 |
| • | 核心網絡概念，包括使用防火牆實作端口篩選 |
在繼續本章之前，還應閱讀本指南的前面各章并充分了解本解決方案的體系結構和設計概念。
組織先決條件
為組織規劃隔離組這一任務通常涉及許多不同的人。 确定确切的要求所需的資訊通常來自整個組織中的許多來源。 應咨詢組織中的其他成員的意見，他們可能需要參與規劃這些組，包括以下人員：
| • | 行政負責人 |
| • | 安全和稽核人員 |
| • | Active Directory 工程、管理和操作人員 |
| • | DNS（域名系統）、Web 伺服器和應用程式所有者 |
| • | 網絡管理和操作人員 |
| • | 内部教育和咨詢台人員 注： 根據 IT 組織結構的不同，這些角色可能由許多人擔任，也可能由較少的人擔任多個角色。 |
除了需要列出的小組提供的資訊外，了解以下一點也很重要：将 IPsec 引入環境後，将需要更新目前的操作實踐。 也可能需要更新軟體和硬體，如網絡裝置的 BIOS 和固件更新。 最後，還可能需要使用其他網絡工具來幫助支援 IPsec 環境和對 IPsec 環境進行疑難解答。
IT 基礎結構的先決條件
本章還假定存在以下 IT 基礎結構：
| • | 以混合模式或純模式運作的 Microsoft Windows Server™ 2003 Active Directory 域。 本解決方案使用通用組應用組政策對象 (GPO)。 如果組織不是以混合模式或純模式運作，仍然可以通過使用标準全局和本地組配置來應用 GPO。 但是，由于這種方法管理起來很複雜，本解決方案未予采用。 注 ：Windows Server 2003 引入了許多影響 IPsec 政策的改進。 本解決方案沒有任何特别之處會妨礙它與 Windows 2000 一起工作。 但是，隻使用 Windows Server 2003 Active Directory 對本解決方案進行了測試。 有關 Windows Server 2003 中對 IPsec 所做的增強的詳細資訊，請參閱 Microsoft 網站上的“New features for IPsec”頁面，網址為 www.microsoft.com/resources/documentation/ WindowsServ/2003/standard/ proddocs/en-us/ipsec_whatsnew.asp。 |
| • | 具備執行網絡監控、分析監控資料以及根據該資料制定容量規劃決策的能力和專業知識。 注 ：在許多組織中，網絡監控工具的使用受到限制，是以使用這些工具時應注意確定遵循正确的操作過程。 |
| • | 具備可以捕獲網絡上的主機的網絡配置資料的工具。 例如，可使用現有的資産管理系統來收集這些資訊。 有關詳細資訊，請參見本章的“主機發現”一節。 |
傳回頁首
本章的目标讀者
本章的目标讀者是負責建立 IT 基礎結構清單的 IT 專業人員，他們建立的清單将供解決方案架構師和設計人員使用。 這些 IT 專業人員通常是組織的支援成員或操作人員。 要從本章獲得最大益處，需要在技術上對資訊收信過程中采用的工具和技術以及組織的目前基礎結構有很好的了解。
傳回頁首
确定目前狀态
擷取和維護組織的計算機、軟體和網絡裝置的可靠記錄這一過程是 IT 長久以來面臨的挑戰。 項目的成功依賴于從這一過程中擷取的資訊。 在開始伺服器和域隔離項目的規劃過程之前，需要收集和分析組織中已部署的計算機、網絡和目錄服務的最新資訊。 這些資訊使您建立的設計可以考慮到現有基礎結構所有可能的要素。 如果收集的資訊不準确，當在實施期間遇到在規劃階段未考慮的裝置和計算機時，則可能會出現問題。 以下各節将概述每個方面的必需資訊，并提供為 Woodgrove Bank 伺服器和域隔離解決方案收集的資訊示例。
網絡探測
因為 IPsec 分層在 Internet 協定本身之上，是以規劃伺服器和域隔離最重要的方面可能是網絡體系結構。 如果對網絡的了解不完整或不準确，将無法成功實施任何隔離解決方案。 了解子網布局、IP 尋址方案和通信模式是此工作的一部分，但以下兩個部分對于完成此項目的規劃階段尤為重要：
| • | 記錄網絡分段 |
| • | 記錄目前網絡通信模型 |
目的是為了擁有足夠的資訊，以便除了按實體位置辨別某項資産外，還可按網絡位置辨別。
最好以這樣的網絡體系結構作為起始點：經過精心設計，位址範圍易于辨識，并且重疊或不連續的範圍盡可能少。 可能有特定業務要求或環境（如兼并或收購）不允許使用“簡化的”網絡，但如果記錄了目前狀态并了解它，辨別網絡及其管理的資産的任務就簡單多了。 不要使用複雜而且記錄拙劣的網絡作為設計的起始點，因為這種網絡的未辨別區域太多，在實施期間很可能帶來問題。
本指南幫助擷取與規劃伺服器和域隔離最相關的資訊，而不嘗試解決其他問題，如 TCP/IP 尋址和可變長度子網屏蔽、虛拟區域網路 (VLAN) 分段或其他網絡優化方法和技巧。 擷取的資訊将用于闡述伺服器和域隔離解決方案的實施和操作部分。
記錄網絡分段
如果您的組織未記錄目前的網絡體系結構而沒有記錄文檔可用來參考，則在繼續此解決方案之前，應盡快獲得這樣的文檔。 如果記錄的資訊不是最新的或最近未驗證過，您有兩種基本選擇：
| • | 接受會給項目帶來不必要的風險的資訊。 |
| • | 通過手動過程或使用網絡分析工具執行探測項目，網絡分析工具可提供記錄目前網絡拓撲所需的資訊。 |
雖然可以用多種不同的方式表示所需的資訊，但是一系列示意圖通常是說明和了解目前網絡配置的最有效方法。 在建立網絡圖時，應試圖避免加入過多資訊。 如有必要，可使用多個圖來顯示不同的詳細層次。
例如，在 Woodgrove Bank 方案中，小組建立了下圖來說明其現有廣域網 (WAN) 和站點環境的進階視圖。
檢視大圖
小組建立此圖後，繼續對每個站點、最終對每個站點内的每個子網建立更詳細的圖。
在記錄網絡時，可能會發現某些網絡應用程式和服務與 IPsec 不相容。 目前這種不相容情況的示例包括：
| • | 路由器上的 Cisco NetFlow 無法根據協定和端口分析 IPsec 成員之間的資料包。 |
| • | 基于路由器的服務品質 (QoS) 無法使用端口和協定來确定通信流的優先級。 但是，使用特定的 IP 位址來确定通信流的優先級并不受影響。 例如，“從任何人到使用端口 80 的任何人優先”規則無法正常工作，而“從任何人到 10.0.1.10 優先”規則卻不受影響。 |
| • | 裝置不支援或不允許封裝式安全措施負載 (ESP) 使用的 IP 協定端口 50。 |
| • | 權重公平隊列和其他基于流量的路由器通信流優先方法可能失效。 |
| • | 網絡螢幕可能無法分析未加密的 ESP 資料包 (ESP-Null)。 注： Microsoft 網絡螢幕版本 2.1 添加了 ESP 分析器，幫助解決未加密的 IPsec 資料包的問題。 網絡螢幕随 Microsoft Systems Management Server (SMS) 附帶。 有關詳細資訊，請參閱“Microsoft Systems Management Server”頁面，網址為 www.microsoft.com/smserver/。 |
| • | 如果裝置無法分析 ESP，将不會對 ESP 資料包處理指定端口或協定規則的任何 ACL。 |
| • | 如果裝置有 ESP 分析器并且使用了加密，将不會對 ESP 資料包處理指定端口或協定規則的 ACL。 |
當使用端口和協定時，IPsec 會打破基于網絡的優先級設定和基于端口/協定的通信流管理。 遺憾的是，沒有适用于加密資料包的變通辦法。 如果通信流管理或優先級設定必須基于端口或協定，則主機本身必須能夠勝任所有通信流管理或優先級設定功能。
其次，準确地記錄網絡中的各種裝置所需的資訊也很重要。
網絡基礎結構裝置
在實施本解決方案後，組成網絡基礎結構的裝置（路由器、交換機、負載平衡器和防火牆）将使用 IPsec 進行通信。 是以，要檢查網絡上這些裝置的以下特征，以確定它們能夠處理本設計的技術和實體要求，這一點很重要：
| • | 品牌/型号 。 可以使用此資訊來确定裝置支援的功能。 此外，還應檢查裝置上運作的 BIOS 或軟體，以確定該裝置支援 IPsec。 |
| • | RAM 量 。 在确定 IPsec 的容量或它對裝置的影響時，此資訊很有用。 |
| • | 通信量分析 。 掌握此資訊（除顯示裝置日常使用的每日/每周趨勢外，還包括其峰值使用率）始終很有用。 就 IPsec 而言，此資訊可幫助提供裝置的快照以及它在一段時間内的使用情況。 如果在實施 IPsec 後出現問題，此資訊可幫助确定根本原因是否與裝置的高使用率有關。 |
| • | 直接影響 IPsec 的 ACL 。 ACL 會直接影響某些協定工作的能力。 例如，如果不允許 Kerberos 協定（使用者資料報協定 [UDP] 和 TCP 端口 88）或 IP 協定（不是端口，而是協定）50 或 51，IPsec 将無法工作。 如果使用網絡位址轉換周遊 (NAT-T)，還必須将裝置配置為傳遞 Internet 密鑰交換 (IKE) 通信流（UDP 500 和 4500）。 |
| • | 與裝置接口連接配接的網絡/子網 。 此資訊可幫助提供對内部網絡狀況的最佳可能分析。 根據位址範圍定義網絡邊界非常直接，有助于确定其他位址是不受管理位址還是與内部網絡無關的位址（如 Internet 位址）。 此資訊是本指南後續各章中所作的 IPsec 政策決策的必要資訊。 |
| • | 裝置是否執行網絡位址轉換 (NAT) 。 網絡位址轉換通常用來對連接配接的網絡或 Internet 将整個位址範圍表示為單個 IP 位址。 解決方案規劃人員應該清楚網絡上是否發生此過程。 注： Microsoft 知識庫 (KB) 文章 818043“用于 Windows XP 和 Windows 2000 的 L2TP/IPSec NAT-T 更新”以 Windows XP Service Pack (SP) 1 和 Windows 2000 SP4 的可下載下傳修複程式的形式提供了 NAT-T 功能，網址為：http://support.microsoft.com/kb/818043。 但是，除非安裝了 Windows XP SP2 或 Windows Server 2003 SP1，否則 IPsec 響應方無法正常工作。 |
| • | VLAN 分段 。 确定目前網絡上如何實作 VLAN 将有助于了解目前存在的通信流模式或安全要求，同時确定 IPsec 将如何加強或可能影響這些要求。 |
| • | 裝置所連接配接的鍊路 。 此資訊有助于确定裝置維持的連接配接在哪些網絡之間。 還有助于辨別特定接口上各個位置的邏輯網絡和連接配接。 |
| • | 裝置接口的最大傳輸機關 (MTU) 大小 。 MTU 定義可在特定接口上傳輸的未拆分為多段（這一過程也稱為“分段”）的最大資料報。 在 IPsec 通信中，需要使用 MTU 來确定是否分段。 為符合 Internet 安全關聯和密鑰管理協定 (ISAKMP)，必須由路由器跟蹤資料包分段。 IPsec 将沿使用的通信路徑把會話的 MTU 大小配置為最低發現 MTU，并将“不分段”位（DF 位）設定為 1。 注： 如果啟用了路徑 MTU (PMTU) 發現并且工作正常，則不必收集裝置接口的 MTU 大小。 一些資訊來源（如“Windows Server 2003 強化指南”）建議禁用 PMTU 發現。 但是，要使 IPsec 正常工作，必須啟用 PMTU 發現。 |
另外請注意，由于解釋資料包中的資料需要特定的分析器，IPsec 可能會影響入侵檢測系統 (IDS)。 如果 IDS 沒有分析器，它将無法檢查這些資料包中的資料，進而無法确定特定會話是否存在潛在威脅。 這種情況下，決定使用 IPsec 就表示您的組織對 IPsec 的需求更甚于對 IDS 的需求。
本節列出的資訊對于項目的成功至關重要。因為這些資訊可幫助您先了解網絡基礎結構的目前配置和“健康”狀況，再使用 IPsec 來配置這些裝置或對這些裝置配置設定額外的負載（如果已将這些裝置配置為傳遞 IPsec 通信流）。 通過研究峰值使用率資訊，可以确定裝置是否能在目前狀态下使用 IPsec，或者是否需要更新記憶體或固件以支援期望的負載。 在擷取用來更新裝置的硬體（如有必要）時，品牌和型号資訊将很有用。 該品牌或型号特有的其他配置參數或功能的資訊也可能會有所幫助。 裝置上配置的 ACL 數可用來估計配置這些裝置以支援 IPsec 所需的工作量。 如果網絡上的裝置均未配置為允許 IPsec 通信流，而網絡上有許多路由器，那麼裝置配置可能是一項繁重的工作。
獲得此資訊後，您可以迅速确定是否有必要更新裝置以支援項目的要求、是否有必要更改 ACL 或采取其他措施以確定裝置能夠處理期望的負載。
目前網絡通信流模型的分析
收集尋址和網絡基礎結構資訊後，下一邏輯步驟就是仔細檢查通信流向。 例如，如果某個部門（如人力資源部 (HR)）分布在幾棟建築物中，而您希望在該部門使用 IPsec 來加密資訊，那麼就需要了解這些建築物如何連接配接，以确定在連接配接中使用的“信任”級别。 如果使用銅線電纜将某棟高度安全的建築物與另一未受保護的建築物連接配接，那麼這棟高度安全的建築物可能受到竊聽或資訊重播攻擊。 如果這種攻擊會帶來威脅，IPsec 可為受信任主機提供強的雙向身份驗證和通信流加密。 但是，該解決辦法不能消除這樣的事實：受信任主機缺乏實體安全仍将是一個威脅。
當您檢查通信流時，仔細觀察所有被管理和未被管理的裝置如何互動操作，包括 Windows 2000 SP4 之前的 Windows 版本以外的非基于 Windows 的裝置，如 Linux、UNIX 和 Mac。 思考一些類似問題：某些通信是否在端口/協定層發生？相同主機之間是否存在許多跨越各種協定的會話？ 伺服器與用戶端之間如何通信？ 目前實施或規劃的某些安全裝置或項目是否可能影響隔離項目？ 例如，使用 Windows XP SP2 和 Windows 防火牆“鎖定”某些端口（如 UDP 500）可能會導緻 IKE 協商失敗。
當使用第 2 章“了解伺服器和域隔離”中執行的威脅模組化過程來檢查各種類型的網絡通信流時，将很容易發現，應從不受信任或未被管理的裝置來保護生成通信流的協定和應用程式的安全。 一些較為常見的應用程式和協定包括：
| • | TCP/IP 上的 NetBIOS (NetBT) 和伺服器消息塊 (SMB) 。 在 LAN 中，通常會為 NetBT 啟用端口 137、138 和 139 并為 SMB 啟用端口 445。 這些端口提供 NetBIOS 名稱解析服務及其他功能。 遺憾的是，它們也為建立空會話提供機會。 “空會話”是在不使用已知使用者或實體的安全上下文的主機上建立的會話。 這些會話一般是匿名的。 |
| • | 遠端過程調用 (RPC) 。 通常，RPC 的操作方式如下：為應用程式提供一個偵聽端口（也稱為終結點映射程式，TCP 端口 135），接着該端口通知“調用者”（通常是另一應用程式）在短暫的時間範圍内開始在另一端口通信。 在使用防火牆分段的網絡中，這種 RPC 通信會帶來一個配置難題，因為它意味着要打開 PRC 偵聽端口和 1024 以上的所有端口。 打開如此多的視窗将增加整個網絡的受攻擊面，降低防火牆的效用。 但是，RPC 的優勢在于它對使用它的應用程式抽象地表示了開放式系統互連 (OSI) 模型 1 至 4 層的功能，是以開發者不必為他們的分布式應用程式提供低級網絡調用。 因為許多應用程式都依賴 PRC 執行基本功能，IPsec 政策也需要依賴 RPC。 有關建立 IPsec 政策的詳細資訊，請參閱第 5 章“為隔離組建立隔離政策”。 |
| • | 其他通信流 。 通過對資料包中所包含的資料加密并提供資料包身份驗證，IPsec 可幫助確定主機之間的傳輸安全。 重要的是要确定需要保護的内容和必須減緩的威脅。 應檢查需要安全保護的其他通信流或通信流類型并适當地模組化。 例如，僅允許少數用戶端通路的特殊用途的資料庫，或僅供 HR 管理人員使用的 HR 小組專用應用程式。 |
記錄實體網絡和邏輯網絡後，下一步就是檢查目前的通信流模式并回答下列問題：
| • | 目前是否存在專用于特定通信流類型的子網（如 Mac 工作站和 UNIX 工作站，或大型機至終端連接配接）？ |
| • | 是否需要将不同類型的通信流或不同位置之間的通信流分開？ |
Active Directory
Active Directory 是在網絡之後最重要的項，用來從中收集資訊。 您應該了解林結構，包括域布局、組織機關 (OU) 體系結構和站點拓撲。 此資訊便于您了解計算機的目前位置、它們的配置以及因實施 IPsec 而對 Active Directory 進行更改将産生的影響。 下面列出了完成此部分發現工作必需的資訊。
| • | 林的數量 。 由于林是 Active Directory 實施中的安全邊界，有必要了解目前的 Active Directory 體系結構，以确定應隔離哪些主機以及如何隔離。 |
| • | 域的名稱和數目 。 IPsec 身份驗證是 IKE 協商過程的結果。 本解決方案中的身份驗證方法是 Kerberos 協定。 此協定假定計算機加入了域，并且滿足作業系統版本先決條件（Windows 2000、Windows XP 或 Windows Server 2003）。 |
| • | 信任的數目和類型 。 獲得信任的數目和類型非常重要，因為信任不但影響隔離的邏輯邊界，而且還定義在本解決方案中可以（或應該）如何進行 IKE 身份驗證。 |
| • | 站點的名稱和數目 。 站點體系結構通常與網絡拓撲一緻。 了解站點在 Active Directory 中的定義将有助于深入了解複制及其他詳細資訊。 在本解決方案中，站點體系結構提供了對 Active Directory 實施（如果目前存在）的進一步了解。 |
| • | OU 結構 。 在建立 OU 結構時稍作規劃，便能取得很高的運作效率。 OU 是邏輯構造，是以可以對它們模組化以适合許多不同的要求和目的。 OU 結構是檢查目前如何使用組政策以及如何布局 OU 的理想場所。 本解決方案的第 4 章和第 5 章将讨論 OU 的體系結構并提供有關如何使用此體系結構來應用 IPsec 政策的詳細說明。 |
| • | 現有 IPsec 政策使用 。 因為 IPsec 政策的實施是本項目最重要的任務，是以了解您的網絡目前如何使用 IPsec（如果使用了）非常重要。 無論是使用簡單的 IPsec 篩選器（如強化指南中規定的篩選器），還是實施完整的政策，了解目前的用法和要求都可確定與此解決方案更順利地內建。 |
Woodgrove Bank 方案使用一個林 (corp.woodgrovebank.com)，該林包含跨越五個站點的四個域。 每個站點都可能包含域控制器 (DC)、主域控制器 (PDC) 或全局目錄 (GC) 伺服器，如下表所示：
表 3.1：Woodgrove Bank Active Directory 資訊| 站點地理位置 | 域 | 使用者數 | 域控制器類型 |
| 紐約州紐約市 | corp.woodgrovebank.com americas.corp.woodgrovebank.com | 5,000 | 林根全局目錄 PDC 美國地區區域 GC 歐洲區域 DC 亞洲區域 DC |
| 伊利諾斯州芝加哥 | americas.corp.woodgrovebank.com | 750 | 美國地區區域 GC |
| 喬治亞州亞特蘭大 | americas.corp.woodgrovebank.com | 1,450 | 美國地區區域 GC |
| 麻薩諸塞州波士頓 | americas.corp.woodgrovebank.com | 480 | 美國地區區域 GC |
| 加利福尼亞州舊金山 | americas.corp.woodgrovebank.com | 250 | 美國地區區域 GC |
| 賓夕法尼亞州匹茲堡 | americas.corp.woodgrovebank.com | 50 | 美國地區區域 GC |
| 亞利桑那州菲尼克斯 | americas.corp.woodgrovebank.com | 50 | 美國地區區域 GC |
| 佛羅裡達州邁阿密 | americas.corp.woodgrovebank.com | 50 | 美國地區區域 GC |
| 華盛頓特區 | americas.corp.woodgrovebank.com | 75 | 美國地區區域 GC |
| 麻薩諸塞州劍橋鎮 | americas.corp.woodgrovebank.com | 36 | 美國地區區域 GC |
| 加拿大多倫多 | americas.corp.woodgrovebank.com | 25 | 美國地區區域 GC |
| 英國倫敦 | europe.corp.woodgrovebank.com corp.woodgrovebank.com | 5,200 | 林根 GC PDC 仿真器 歐洲區域 GC 美國地區區域 DC 亞洲區域 DC |
| 瑞士日内瓦 | europe.corp.woodgrovebank.com | 350 | 歐洲區域 GC |
| 荷蘭阿姆斯特丹 | europe.corp.woodgrovebank.com | 295 | 歐洲區域 GC |
| 德國慕尼黑 | europe.corp.woodgrovebank.com | 149 | 歐洲區域 GC |
| 意大利羅馬 | europe.corp.woodgrovebank.com | 80 | 歐洲區域 GC |
| 愛爾蘭都柏林 | europe.corp.woodgrovebank.com | 79 | 歐洲區域 GC |
| 蘇格蘭愛丁堡 | europe.corp.woodgrovebank.com | 40 | 歐洲區域 GC |
| 南非約翰内斯堡 | europe.corp.woodgrovebank.com | 37 | 歐洲區域 GC |
| 日本東京 | asia.corp.woodgrovebank.com corp.woodgrovebank.com | 500 | 林根 GC PDC 仿真器 亞洲區域 GC 歐洲區域 DC 美國地區區域 DC |
| 中國香港 | asia.corp.woodgrovebank.com | 100 | 亞洲區域 GC |
| 泰國曼谷 | asia.corp.woodgrovebank.com | 150 | 亞洲區域 GC |
| 新加坡 | asia.corp.woodgrovebank.com | 210 | 亞洲區域 GC |
| 澳洲悉尼 | asia.corp.woodgrovebank.com | 45 | 亞洲區域 GC |
| 印度班加羅爾 | asia.corp.woodgrovebank.com | 35 | 亞洲區域 GC |
| 台灣台北 | asia.corp.woodgrovebank.com | 65 | 亞洲區域 GC |
Woodgrove Bank 的 Active Directory 設計使用了林自動建立的雙向信任關系。 沒有其他跨林信任或外部信任。
下圖顯示了 Woodgrove Bank 使用的高層 OU 結構的示例。 美國地區、歐洲和亞洲三個主要區域的域都一緻地使用了此結構。
檢視大圖
因為伺服器和域隔離項目是 Woodgrove Bank 的第一次 IPsec 實施，是以沒有現有活動 IPsec 政策。
主機發現
進行資産發現項目的最大好處是能獲得有關網絡上的主機（工作站和伺服器）的大量資料。 在第 4 章“設計和規劃隔離組”中，決策的制定需要有關所有主機狀态的準确資訊，以確定這些主機能夠參與該設計的 IPsec 通信。
主機資料要求
本節描述所需的主機資訊，并讨論如何以實體形式和邏輯形式表示這些資訊。
| • | 計算機名稱 。 此名稱是計算機的 NetBIOS 或 DNS 名稱，用于在網絡上辨別計算機。 因為計算機可以有多個媒體通路控制 (MAC) 和/或 IP 位址，計算機的名稱是可用來确定它在網絡上的唯一性的标準之一。 在某些情況下，計算機名稱可以重複。是以，這種唯一性不是絕對的。 |
| • | 每個網絡接口卡 (NIC) 的 IP 位址 。 IP 位址是與子網路遮罩一起用來辨別網絡上的主機的位址。 應注意，因為 IP 位址經常更改，是以不是辨別資産的有效方式。 |
| • | 每個 NIC 的 MAC 位址 。 MAC 位址是用來辨別網絡接口的唯一的 48 位位址。 可用它來幫助區分同一裝置上的不同網絡接口。 |
| • | 作業系統、Service Pack 和修補程式版本 。 作業系統版本是決定主機能否使用 IPsec 通信的關鍵因素。 跟蹤可能安裝的 Service Pack 和修補程式的目前狀态也很重要，因為經常會使用這些 Service Pack 和修補程式來确定是否已達到最低安全标準。 |
| • | 域成員身份 。 此資訊用來确定計算機能否從 Active Directory 獲得 IPsec 政策，或是否需要使用本地 IPsec 政策。 |
| • | 地理位置 。 此資訊僅為組織中裝置的位置。 可用來确定某個裝置是否應根據其位置或與之通信頻繁的裝置的位置加入特定隔離組。 |
| • | 硬體類型/角色 。 不太可能從自動化過程收集此資訊。 一些執行主機發現的工具可提供此資訊，它們通過查詢硬體資訊并運作應用程式來确定其類型，如伺服器、工作站或 tablet PC。 可使用此資訊來确定特定計算機是否可以參與隔離以及将計算機放入哪一隔離組。 注： 硬體類型資訊通過資料插值法獲得，或通過執行查詢的軟體産品提供此資訊。 例如，HP Evo n800 是大家熟知的移動計算機，如果可以查詢硬體級别（或具有辨別硬體級别的資産标簽），那麼就能更迅速地确定指派給裝置的适當 IPsec 政策。 |
收集所有這些資訊并合并到資料庫中後，要定期執行正常性發現工作，以保持資訊最新。 要建立符合組織需要的設計，您将需要有關網絡上的被管理的主機的最完整且最新的資訊。
您可以使用各種方法從網絡上的主機收集資料。 這些方法既包括高端、完全自動化的系統，也包括完全手動的資料收集。 一般地，從速度和準确性方面考慮，使用自動化方法來收集資料要優于手動方法。 但是，無論使用哪種方法，需要的資訊是相同的；隻是獲得資訊所花的時間不同。 手動過程遇到的常見問題包括：資訊重複、需要確定資訊收集範圍的準确性（例如，是掃描了所有網絡來捕獲主機資訊，還是僅掃描了用戶端子網）、以及需要及時地獲得資訊以使它對項目有用。 有關完整 IT 系統稽核的所有因素的讨論不屬于本項目的範疇。 但是，了解這一點很重要：不僅本解決方案需要，組織還有其他許多方面也需要使用此稽核資訊。 資産跟蹤和安全風險管理就是要求最新而準确的系統清單的兩個重要過程示例。
自動發現
使用自動稽核網絡管理系統（如 SMS）可提供有關 IT 基礎結構目前狀态的許多寶貴資訊。 但是，自動化的系統有一個問題：脫機、未連接配接或實體上（或邏輯上）無法響應資訊查詢的主機不會顯示在最後的資料庫中。 即使最自動化的系統也要求存在手動管理因素，以確定正确通路和記錄主機。
許多供應商提供了各種産品和工具。 有的方法使用集中式掃描機制，有的使用安裝在用戶端計算機上的代理。 比較或推薦要購買的産品不屬于本指南的範疇，但是，本解決方案要求具備本章重點講述的發現資料，以供第 4 章和第 5 章中所作的設計考慮使用。
在關 SMS 2003 如何幫助執行資産管理（或幫助收集此項目所需的資訊）的詳細資訊，請參閱“SMS 2003 資産管理”頁面上的示範和資産管理資料表，網址為 www.microsoft.com/smserver/evaluation/capabilities/
asset.asp。
手動發現
手動發現方法和自動方法之間的最大差别是時間。 手動收集此項目所需的資訊可能需要花幾十個人幾天甚至幾周的時間，而大企業可能需要更長時間。 如果打算使用手動方法稽核基礎結構的目前狀态，則必須以電子格式提供所擷取的資訊（如電子表格或資料庫），這一點很重要。 如果不能快速而準确地生成傳回所需資訊的特定查詢，所生成的龐大資料可能會使篩選和分析過程非常困難。 此外，您可以使用本地 IT 管理者來擷取資訊或驗證任何先前收集的資訊。
即使您的組織沒有自動稽核工具，通過使用 Windows 平台提供的标準遠端管理和腳本界面，仍然可以在一定程度上進行自動收集。 使用這些工具的主要問題是，要確定用戶端不會因為與管理工具或腳本不相容而被遺漏。
您可以使用 Windows Scripting Host (WSH)、Microsoft Visual Basic® Scripting Edition (VBScript) 和 Windows Management Instrumentation (WMI) 來建立可收集系統配置資訊的腳本檔案。 下表按平台分别顯示了 VBScript 和 WMI 的可用性。
表3.2：按平台列出的 VBScript 和 WMI 的可用性| 平台 | VBScript | Wmi |
| Windows 95 | 安裝 WSH 5.6 | 安裝 WMI CORE 1.5 |
| Windows 98 | 内置 | 安裝 WMI CORE 1.5 |
| Windows Millennium | 内置 | 内置 |
| Microsoft Windows NT® 版本 4.0 | 安裝 WSH 5.6 | 安裝 WMI CORE 1.5 |
| Windows 2000 | 内置 | 内置 |
| Windows XP | 内置 | 内置 |
| Windows Server 2003 | 内置 | 内置 |
您可以從“Microsoft Windows Script Downloads”頁面下載下傳 Microsoft Windows Script 5.6 更新，網址為 http://msdn.microsoft.com/library/default.asp?url=/
downloads/list/webdev.asp。
可從 Microsoft 下載下傳中心下載下傳“Windows Management Instrumentation (WMI) CORE 1.5 ”安裝檔案，網址為 www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplayLang=en。
本解決方案中的“工具和模闆”檔案夾中提供了一個名為
Discovery.vbs的 VBScript 示例。 此腳本使用 WMI 檢索本章的“主機資料要求”一節中列出的所有資訊，但角色和地理位置除外。 收集的資訊儲存在本地計算機的文本檔案
C:/Discovery/< systemname >_info.txt中。 您可以修改腳本以收集其他資訊或将收集的資訊放在遠端檔案共享位置。
如果主機上沒有 WMI 或 VBScript 可用，可以使用批處理腳本和外部工具來收集資訊。 困難在于批處理語言在功能上非常有限，無法友善地從較早 Windows 版本的指令行獲得配置資訊。
要執行主機發現，必須查詢主機并提供存儲查詢結果的位置。
無論是使用自動、手動方法還是混合兩種方法來收集資訊，都有一些大問題可能會給設計帶來麻煩，其中之一就是捕獲從原始清單掃描至實施準備就緒這段時間内的更改。 第一次掃描完成後，應讓支援人員清楚，以後的所有變更和更新都要記錄在清單中。
此清單對于規劃和實施 IPsec 政策至關重要，這一點将在後面的章節中讨論。
傳回頁首
容量事項
資訊收集完成後，IPsec 的影響（包括一些容量規劃）将是下一個重點。 本節描述在您的環境中正确規劃 IPsec 的一些基本事項。
IPsec 的影響
由于 IPsec 使用各種加密技術，會消耗計算機上的大量開銷。 對于需要加密的方案，将需要進行更仔細的分析。 例如，某種方案可能使用三重資料加密标準 (3DES) 和安全雜湊演算法 (SHA-1) 來檢查要求最強可用加密和密鑰交換保護 情況下的完整性。 而另一種方案涉及安全關聯 (SA) 協商。 您可以對主模式 SA 使用較短的生存期（例如，三小時），但是由于許多安全方面的原因，不可避免要作一些讓步。 每個主模式 SA 大約占用 5 KB RAM。 在伺服器要代理數以萬計的并發連接配接的情況下，可能會導緻過度使用。 其他因素包括網絡基礎結構伺服器上的 CPU 使用率、運作 IPsec 的伺服器和工作站開銷的增加（特别是伺服器，因為大多數情況下它們包含的主模式 SA 要比用戶端多）以及因 IPsec 協商而導緻網絡滞後時間的加長。
注：在 Microsoft 本身對此解決方案的部署中，因使用 IPsec 而直接導緻網絡使用率增加 1% 至 3% 是正常現象。
另一個需要考慮的主要問題是使用 NAT 裝置連接配接的網絡。 問題在于 NAT 不允許主機之間進行驗證頭 (AH) 會話，原因是 NAT 正好違反了 AH 旨在提供的原則：對未更改的資料包（包括标頭）進行身份驗證。 如果内部網絡中存在 NAT 裝置，則需要選擇 ESP 代替 AH。 ESP 提供資料加密功能，但不要求加密。 這一點從容量角度來說很重要，因為加密會産生消耗，在項目的規劃和設計階段就必須将這些消耗考慮在内。 ESP 還可以在空加密的情況下實施，這樣可以在提供最可能強的 IPsec 點對點通信的同時不中斷與 NAT 的通信。 因為不使用加密，是以比加密的 ESP 的影響小。
政策的影響
IPsec 政策群組政策都會影響計算機的啟動時間以及使用者登入的時間。 在資訊收集階段，記下實施解決方案之前計算機啟動的時間和使用者登入時間會很有用。 在此階段記錄這些時間将為試行期間比較測試系統提供基準，以确定對使用者登入所需的總時間的影響。
傳回頁首
部署前的考慮事項
上述各節描述了為使隔離成功而應從網絡、Active Directory 和主機收集的資訊。 本節将列出應在部署 IPsec 前仔細檢查的相關事項。
網絡基礎結構
資訊收集使您能夠規劃在網絡中實施 IPsec 隔離。 收集這些資訊後，對資料進行仔細分析，可發現将在測試和部署期間面臨的大多數問題。 雖然下面列出的各項并不完整，但在測試和部署之前開始分析收集到的資訊時，考慮這些事項是很重要的。
過度使用的裝置
您可能需要更新或重新配置目前使用率超過 75% 的交換機或路由器，以增加裝置上的通信流，同時在通信流劇增時提供額外的使用率。 為實施 IPsec 進行适當的容量規劃更側重于測試和預計的通信流負載，而非準确的計算。 因為對于任意兩個客戶，其方案、通信流模式、使用者集中度和應用程式都極不可能完全相同，是以必須适當地規劃和考慮網絡裝置會受到什麼影響。 例如，IPsec 的某些方面是完全可以預測的。 每個使用 IPsec 的 ESP 資料包剛好比不使用 IPsec 的同一資料包大 36 位元組。 因為建立一個主模式 SA 需要六條消息，這樣便很容易估算特定裝置上的使用率可能受到的影響。 您可以使用工具（如 Quallaby 網站 www.quallaby.com 上的 PROVISO 應用程式）或其他網絡分析器解決方案來幫助在您的 IT 環境中規劃 IPsec。
不相容的裝置
與 IPsec 不相容的裝置不能參與 IPsec 通信。 如果這種裝置需要與被管理的裝置通信，必須将這些裝置加入 IPsec 免除清單。 有一種替代方法是更新裝置硬體或軟體以支援 IPsec。 還有一種方法是，當未受管理的裝置回退到使用明文方式進行出站通信時，允許它們與邊界計算機通信。
裝置配置不正确
裝置配置不正确會增加通信失敗的可能性，并增加裝置上的負載，甚至導緻裝置損壞。 以下有關裝置的配置、管理和安全性方面的最佳做法将有助于減輕這些問題。
IP 尋址
由于 IP 位址是 IPsec 解決方案的基本構造塊，是以尋址方法越“簡潔”越好。 位址空間重疊、位址重複、子網路遮罩錯誤以及其他問題都可能使正常的網絡操作變複雜。 在這種網絡上使用 IPsec 隻會增加解決問題的複雜程度，并使人們懷疑 IPsec 是問題的根源。 組織的增長、兼并與收購以及其他因素可能會迅速導緻網絡上的 IP 尋址資訊過時和不準确。 要消除 IPsec 的最大問題，請確定将網絡劃分為不重疊的子網，清晰地整理了路由表，且位址聚合易于确定。
Active Directory 資訊
如果目前的 Active Directory 實施工作正常（即名稱解析、動态主機配置協定 [DHCP]、組政策的應用、信任關系等），則沒有任何問題會影響 IPsec。 應仔細檢查從檢查 Active Directory 到開始隔離項目這段時間内所作的任何更改，以確定不會遇到任何相容性問題。
主機資訊
上一節已幫助您收集了有關網絡上的主機的足夠資訊。 确定哪些用戶端和伺服器能夠使用 IPsec 後，應注意需要如何隔離它們以及哪些應用程式需要仔細檢查，以了解隔離解決方案可能會對這些應用程式産生的影響。
确定用戶端/伺服器參與
收集了主機的資訊後，确定哪些主機可以內建到隔離方案中就相對簡單了。 例如，隻有基于 Windows 2000、Windows Server 2003 和 Windows XP 的計算機才能使用 IPsec 通信。 但是，也許并不是所有可以參與的用戶端都要這樣做。 設計過程一個重要部分是根據本章收集的資訊确定哪些計算機和裝置将包括在解決方案中以及屬于哪一組。
确定需要隔離的服務
對伺服器和域隔離項目而言，服務就是在網絡上向用戶端提供服務的應用程式，如 Microsoft Exchange Server、Microsoft SQL Server™ 或 Internet 資訊服務 (IIS)。 您應該逐項評估這些服務，以确定它們是否适合伺服器和域隔離。 要将這些服務包括在解決方案中的原因有很多，如組織政策、政府法規或其他業務要求。 例如，可能有的組織政策規定郵件伺服器之間的所有通信都必須使用 IPsec 進行安全保護，但用戶端與伺服器之間的通信并不需要以這種方式進行安全保護。 第 4 章“設計和規劃隔離組”将詳細讨論隔離過程。 當嘗試隔離服務時，應慎重考慮那些運作多項服務的伺服器，例如，提供 Web 服務和檔案傳輸協定 (FTP) 的伺服器同時也是郵件伺服器。
網絡負載平衡和群集
使用伺服器和域隔離的組織可以選擇免除那些使用網絡負載平衡 (NLB) 和群集的計算機。 IPsec 與“無相似性”模式下的 NLB 不相容，原因是 IPsec 會阻止不同的計算機使用同一用戶端連接配接。 由于這種不相容性，是以不要嘗試同時使用“無關聯”模式下的 NLB 和 IPsec。
例外管理
例外管理是 IPsec 規劃的重要部分。 确定在什麼情況下使用允許不受信任主機通路的計算機，以及控制被管理和未受管理的計算機之間的通路，是隔離的關鍵任務。 最佳做法是将例外次數盡可能保持最低。 技術需要可能規定對某些計算機或服務免除 IPsec 處理，如域控制器和 DHCP、DNS 及 WINS 伺服器。 由于這些計算機仍然被管理，潛在的風險要比允許未受管理的計算機與被管理的、受信任計算機進行通信的風險小一些。
不基于 Windows 的裝置
大多數企業網絡都不是同源的。 在規劃 IPsec 部署時，必須考慮因素的多樣性，如作業系統、網絡基礎結構以及硬體平台。 如果您的組織具有不基于 Windows 的計算機，那麼應當了解，目前還不可能在 Windows 以外的領域使用 IPsec 政策。 有的組織可能會決定通過将一些平台當作受信任的平台來解除此限制，但是因為這些平台不能使用 IPsec 政策，是以伺服器和域隔離解決方案不會保護它們。 下一節将介紹如何确定信任。
管理和監視裝置
在初始規劃階段，IPsec 有一個方面經常被忽略，就是它對網絡通信流管理和監視的影響。 因為 IPsec 要求身份驗證并允許加密，有些裝置就無法繼續監視和管理支援 IPsec 的計算機。 如果要求加密，表明組織的安全性比監視網絡上傳輸的資料的操作需求更重要。 在其他情況下，将有必要評估可對應用程式或裝置進行哪些更改，以便啟用 IPsec 監視（例如可以檢視 SSP 通信流的 ESP 分析器）。 如果不可能更新監視或管理裝置以支援 IPsec，則應記錄此資訊，這非常重要。 解決方案架構師或體系結構設計小組将在第 4 章“設計和規劃隔離組”中需要使用這些資訊。
傳回頁首
信任确定
獲得有關主機裝置（IT 基礎結構的目前組成部分）的資訊後，必須作一個基本判斷，此判斷将直接影響主機參與解決方案的能力。 此判斷就是确定達到什麼條件的主機可被視為受信任主機。 對于“受信任”一詞，不同的人可能有不同的了解，是以要向項目的所有負責人傳達該詞的明确定義，這非常重要。 如果未做到，可能會導緻受信任環境的安全出現問題，因為整體安全性無法超過允許達到受信任狀态的最不安全用戶端設定的安全級别。
為了解此概念，可以考慮适合典型的 IT 基礎結構中的主機的四種基本狀态。 這些狀态包括（按風險從小到大的順序）：
| 1. | 受信任 |
| 2. | 可信 |
| 3. | 已知，不受信任 |
| 4. | 未知，不受信任 |
本節的其餘部分将定義這些狀态，并說明如何确定組織中的哪些主機屬于哪種狀态。
受信任狀态
将某個主機歸類為受信任主機并不意味着該主機絕對安全或無懈可擊。 基本上，受信任意味着主機的風險受到管理。 這種受管狀态由負責配置主機的 IT 管理者和使用者負責。 如果受信任主機管理不當，很可能成為整個解決方案的弱點。
當主機被視為受信任主機時，其他受信任主機應該可以合理地假定該主機不會發起惡意操作。 例如，受信任主機應期望其他受信任主機不會執行攻擊它們的病毒，因為所有受信任主機都要求使用一些用來緩解病毒威脅的機制（如防病毒軟體）。
受信任主機之間的通信不應受到網絡基礎結構的阻礙。 例如，由于受信任主機可以假定其他受信任主機沒有惡意内容，是以，通常不要求阻止 IP 級資料包以限制其他受信任主機的通路。 您應當使用計算機本身基于主機的防火牆、通過端口或協定來實施控制主機通信所需的任何限制，而不是使用 IPsec 實施這些限制。
在 Woodgrove Bank 方案中，安全小組定義了以下五個主要目标，用來規劃主機達到受信任狀态所需的技術：
| • | 計算機或使用者的身份未被盜用。 | ||||||
| • | 所需的資源不論駐留在受管環境中的什麼位置，都安全而且可用。
| ||||||
| • | 資料和通信是專用的，這意味着隻能由期望的接收人閱讀和使用資訊。 | ||||||
| • | 裝置所有者/操作員了解并将遵守政策，確定環境保持可信度。 | ||||||
| • | 對風險和威脅能及時響應。 |
Woodgrove Bank 的支援小組使用這些目标來定義一系列技術要求，以确定主機可被視為受信任主機。
在定義受信任狀态時，要確定資産所有者能夠使用其他安全要求，以滿足特定資産的業務需要。 例如，人力資源部可能對特定伺服器要求額外的生物鑒定登入機制。 在本解決方案中，此要求不會對伺服器達到受信任狀态的能力産生任何負擔。 但是，應注意確定特定資産的要求不會與達到受信任狀态的要求相沖突。
花一些時間來确定目标和技術要求，這是您的組織認為适合主機獲得受信任狀态的最低配置。
例如，在 Woodgrove Bank 方案中，設計小組使用了下列技術要求：
| • | 作業系統 。 受信任主機應運作 Windows XP SP2 或 Windows Server 2003 或至少運作 Windows 2000 SP4。 |
| • | 域成員身份 。 受信任主機屬于受管理的域，這意味着 IT 部門需要安全管理權限。 |
| • | 管理用戶端 。 所有受信任主機都必須運作特定的網絡管理用戶端，以便對安全政策、配置和軟體進行集中式管理和控制。 |
| • | 防病毒軟體 。 所有受信任的用戶端都運作防病毒軟體，該軟體配置為每天進行病毒檢查并自動更新最新的病毒簽名檔案。 |
| • | 檔案系統 。 所有受信任主機都配置為 NTFS 檔案系統。 |
| • | BIOS 設定 。 所有受信任的移動計算機都配置 BIOS 級别的密碼，由 IT 支援小組管理。 |
| • | 密碼要求 。 受信任用戶端必須使用強密碼。 |
受信任狀态不是不變的，了解這一點很重要；它是一個過渡狀态，随安全标準更改而更改，并且要符合那些标準。 新的威脅和新的防禦措施不斷出現。 是以，組織的管理系統必須經常檢查受信任主機，以保持與标準相符。 此外，在需要時，這些系統必須能夠釋出更新或配置更改，以幫助維持受信任狀态。
持續符合所有這些安全要求的主機可被視為受信任主機。 但是，本章前面所讨論的發現過程中辨別的大多數主機目前很可能都不符合這些要求。 是以，确定哪些主機可成為受信任主機以及哪些不能（進而必須視為不受信任主機）很重要。 為進行此過程，可以定義一個中間的可信狀态。 本節剩餘部分将讨論不同的狀态和它們的含義。
可信狀态
如有必要，應盡快辨別目前基礎結構中能夠達到受信任狀态的主機，這會很有用。 可将主機指定為可信狀态，表示目前主機經過必要的軟體和配置更改後，确實能夠達到受信任狀态。
對于每台指定為可信狀态的計算機，應相應地記錄要使主機達到受信任狀态所需的配置。 這些資訊對于項目設計小組（用來估計将主機添加到解決方案的成本）和支援人員（使他們能夠應用所需的配置）都尤其重要。 通常，可信主機分為以下兩組：
| • | 所需的配置 。 目前的硬體、作業系統和軟體使主機能夠達到可信狀态。 但是，還需要作一些配置更改才能達到必備的安全級别。 例如，如果組織要求主機具有安全的檔案系統才能被視為受信任的主機，那麼硬碟格式為 FAT32 的主機就無法滿足此要求。 | ||||||||
| • | 所需的更新 。 這組計算機必須經過系統更新後才能成為受信任主機。 下面列出了這組計算機可能需要的一些更新類型：
|
可使用這些組來配置設定在需要更新的計算機上實施解決方案的成本。
已知，不受信任狀态
在對組織的主機分類的過程中，由于某些已充分了解且明确定義的原因，将确定一些不能達到受信任狀态的主機。 這些原因可能包含下列類型：
| • | 财務 。 沒有為此主機更新硬體或軟體的資金可用。 |
| • | 政治 。 因政治或商業形勢使主機不能符合組織既定的最低安全要求，主機不得不保持不受信任狀态。 強烈建議您與公司所有者或主機獨立軟體供應商 (ISV) 聯系，讨論伺服器和域隔離可帶來的增值。 |
| • | 功能 。 主機需要運作不安全的作業系統或需要以不安全的方式運作才能執行其任務。 例如，由于某一特定業務的應用程式隻能在較舊的作業系統上運作，而可能要求主機運作該作業系統。 |
主機保持已知不受信任狀态的功能性的原因有很多。 下面列出了可能導緻将主機歸類為此狀态的一些功能性原因：
| • | 運作 Windows 9 x 或 Windows Millennium Edition 的計算機。 運作這些 Windows 作業系統特定版本的計算機不能歸類為可信主機，原因是這些作業系統不支援基本的安全基礎結構。 實際上，這些作業系統在設計上就沒有安全基礎結構。 此外，這些作業系統對于特定于使用者的計算機配置隻有基本的集中管理功能（通過系統政策和使用者登入腳本）。 最後，這些作業系統未提供所需的安全管理功能中的任何一項。 |
| • | 運作 Windows NT 的計算機 。 在伺服器和域隔離中，運作 Windows NT 的計算機不能歸類為可信主機，原因是此作業系統不完全支援基本的安全基礎結構。 例如，Windows NT 不支援本地資源上的“拒絕”ACL、確定網絡通信機密性和完整性的任何方式、用于強身份驗證的智能卡或計算機配置的集中管理（盡管支援對使用者配置的有限的集中管理）。 Windows NT 也不提供任何方式來保護資料的機密性并確定其完整性（如 Windows 2000 加密檔案系統）。 此外，Windows NT 不支援必需的所有安全功能。 例如，它不支援組政策或 IPsec 政策，也不提供某種機制來確定在需要時可以獲得本地管理者級别的通路權限。 同時，它不會定期重新應用安全配置以確定保持有效狀态。 注： 有關 Windows NT 不可信的讨論嚴格限于與伺服器和域隔離的實施相關的領域，并不反映它作為作業系統的使用。 對于本項目中的伺服器，更新至 Windows Server 2003 平台就可以提供最安全且易于管理的解決方案。 |
| • | 獨立計算機 。 配置為獨立計算機或工作組成員的運作任何 Windows 版本的計算機通常都無法達到可信狀态。 雖然這些作業系統可能完全支援必需的最低基本安全基礎結構，但是，如果計算機不是受信任域的一部分，很可能無法具備所需的安全管理功能。 |
| • | 不受信任域中的計算機 。 不受組織 IT 部門信任的域的成員計算機不能歸類為受信任主機。 不受信任的域不能向其成員提供所需的安全功能。 雖然此不受信任域的成員計算機的作業系統可能完全支援必需的最低基本安全基礎結構，但是如果計算機不是在受信任的域中，所需的安全管理功能就得不到完全保證。 例如，在不受信任域中，沒有機制可用來確定受信任使用者在需要時可獲得本地管理者級别的通路權限。 而且，安全配置（即使是可以集中管理的配置）很容易被不受信任域的管理者改寫。 此外，對安全配置、軟體、政策和标準的遵循得不到保證，也沒有措施來有效地進行監視。 |
| • | Windows NT 域中的計算機 。 基于 Windows NT 的域的成員計算機不能歸類為受信任主機。 雖然它們的作業系統可能完全支援必需的最低基本安全基礎結構，但是，如果計算機在 Windows NT 域中，就不完全支援所需的安全管理功能。 不過，如果因為該主機為組織提供必需的角色而必須将它納入設計當中，則應将它的狀态指定為“已知，不受信任”。 這表示已識别某種該解決方案無法緩解的風險。 您必須使用其他技術來緩解這一已知威脅。 由于這類主機的性質各異，是以無法提供有關這些技術的具體指導。 但是，這些風險緩解技術的目的應當是盡可能降低這種主機帶來的風險。 |
未知，不受信任狀态
應将“未知，不受信任”狀态視為所有主機的預設狀态。 因為這種狀态的主機的配置未知，是以不能信任它們。 對這種狀态的主機的所有規劃都假定該主機的安全已受到威脅或存在受到威脅的可能性，因而對組織來說是不可接受的風險。 解決方案的設計者應努力降低這種狀态的計算機可能對組織産生的影響。
傳回頁首
預計目前主機的更新成本
本章的最後步驟是記錄計算機更新到能夠參與解決方案的程度所需的大緻成本。 在本項目的設計階段，您必須作幾個關鍵決策，作這些決策要求回答下列問題：
| • | 計算機是否滿足隔離必需的最低硬體要求？ |
| • | 計算機是否滿足隔離必需的最低軟體要求？ |
| • | 若要将此計算機內建到隔離解決方案中，需要作哪些配置更改？ |
| • | 為使計算機達到受信任狀态而進行提議的更改會有哪些預計成本和影響？ |
回答這些問題後，您就能夠迅速确定将特定主機或主機組加入項目範圍的所需的工作和大緻成本。 收集所有這些資料很可能不是一個人 — 甚至同一角色中的幾個人 — 能夠完成的。 有些資料可能由咨詢台人員收集，而有些則可能需要架構師或公司所有者級别的人員提供。 計算機的狀态是過渡性的，通過列出的補救措施，可以将計算機的狀态從不受信任更改為受信任，記住這一點很重要。 決定是否将計算機指定為受信任狀态後，就可以開始規劃和設計隔離組了。本指南的第 4 章“設計和規劃隔離組”将對此進行讨論。
下表是一個資料表的示例，您可以用來幫助了解主機的目前狀态以及主機要達到受信任狀态所需的更改。
表 3.3：主機收集資料示例| 主機名稱 | 滿足硬體要求 | 滿足軟體要求 | 配置。 必需 | 詳細資料 | 預計成本 |
| HOST-NYC-001 | 否 | 否 | 更新硬體和軟體。 | 目前作業系統為 Windows NT 4.0。 舊硬體與 Windows XP SP2 不相容。 | $XXX。 |
| SERVER-LON-001 | 是 | 否 | 加入受信任的域，從 Windows NT 4.0 更新到 Windows 2000 SP4 或更高版本。 | 沒有防病毒軟體。 | $XXX。 |
下面對表 3.3 的各欄進行了解釋：
主機名稱。 網絡上的主機裝置的名稱。
| • | 滿足硬體要求 。 反映計算機是否滿足參與解決方案的最低硬體要求。 |
| • | 滿足軟體要求 。 反映計算機是否滿足參與解決方案的最低軟體要求。 在 Woodgrove Bank 中，最低要求是 Windows 2000 SP4、Windows XP SP2 或 Windows Server 2003，以及每個作業系統都安裝所有重要的安全修補程式。 此外，計算機還必須屬于受信任域（即由 Woodgrove Bank IT 人員集中管理的域），并且必須專門提供對計算機具有通路權限的 IT 管理者。 |
| • | 所需的配置 。 表示為使計算機達到受信任狀态必須采取的措施。 |
| • | 詳細資料 。 說明計算機目前不處于受信任狀态的原因。 |
| • | 預計成本 。 表示為使裝置達到受信任狀态所需的預計成本。 此成本應包括軟體、硬體、生産力損失和支援的估計成本。 這些資訊将有助于從公司角度确定将特定計算機作為受信任計算機加入解決方案是否可行或值得。 |
在上面的表中，主機 HOST-NYC-001 的狀态目前是“已知，不受信任”。但是，如果可進行所需的更新，可以将它視為可信主機。 不過，如果大量計算機需要同樣的更新，該解決方案的成本将高很多。
主機 SERVER-LON-001 滿足硬體要求，但需要更新到能夠使用 IPsec 政策且加入域的作業系統。 該主機還需要防病毒軟體。 預計成本是更新作業系統和安裝防病毒軟體所需的工作加上作業系統和防病毒軟體許可證的成本。
獲得表 3.3 中列出的資訊後，将這些資訊與本章中收集的其他資訊一起儲存，以供架構師或體系結構設計小組使用。 第 4 章重點介紹如何設計隔離組，而這些資訊将是這一章要做的工作的基礎。
應當注意，本節中确定的成本隻是主機更新的預計成本。 與此項目相關的還有許多額外的設計、支援、測試和教育訓練成本。 如果需要确立準确的項目成本，将需要把這些額外成本計入整體項目。
傳回頁首
總結
本章概述了執行伺服器和域隔離項目所需的資訊，也包括影響方面的注意事項。 您可以使用本章中的指導執行下列任務：
| • | 辨別網絡上的資産 |
| • | 收集網絡資訊 |
| • | 收集主機資訊 |
| • | 确定目前通信流資訊 |
| • | 檢查目前的 Active Directory 體系結構并從中擷取相關資訊 |
| • | 檢查 IPsec 容量事項 |
| • | 檢視 IPsec 的預部署事項 |
| • | 說明什麼是可信裝置和不可信裝置，以及它們在 Woodgrove Bank 方案中如何歸類 |
完成這些任務将可以收集到在下一章中開始隔離組設計需要的資訊。
更多資訊
本節提供指向其他各方面資訊的連結，這些資訊在實施本解決方案過程中可能會有所幫助：
| • | 有關為 Windows Server 2003 配置防火牆以支援 IPsec 的詳細資訊，請參閱 Windows Server 2003 文檔的“Configuring Firewalls”頁面，網址為 www.microsoft.com/resources/documentation/ WindowsServ/2003/all/deployguide/en-us/ dnsbj_ips_schx.asp。 | ||
| • | 可從 Microsoft 下載下傳中心下載下傳“Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0)”安裝包，網址為 www.microsoft.com/downloads/details.aspx? FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplaylistBullet">• | 有關 WMI 的詳細資訊，請參閱 MSDN® 上的“Windows Management Instrumentation ”文檔，網址為 http://msdn.microsoft.com/library/en-us/wmisdk/ wmi/wmi_start_page.asp。 | |
| • | 可從 Microsoft 下載下傳中心下載下傳“用于 Windows 2000 和 XP 的 Windows Script 5.6”，網址為 www.microsoft.com/downloads/details.aspx? FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylistBullet">• | 可從 Microsoft 下載下傳中心下載下傳“用于 Windows 98、Windows Millennium Edition 和 Windows NT 4.0 的 Windows Script 5.6”，網址為 www.microsoft.com/downloads/details.aspx? FamilyId=0A8A18F6-249C-4A72-BFCF-FC6AF26DC390&displaylistBullet">• | 可從 Microsoft 下載下傳中心下載下傳“Windows Script 5.6 Documentation”，網址為 www.microsoft.com/downloads/details.aspx? FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9&displaylang=en。 |