IO 功能： 安全性與網路 - 標準化至合理化層級

  • 發行項
本頁內容

簡介 簡介
需求： 伺服器及桌上型電腦上以原則管理的防火牆 需求： 伺服器及桌上型電腦上以原則管理的防火牆
需求： 確保遠端存取內部資源及 LOB 應用程式的安全 需求： 確保遠端存取內部資源及 LOB 應用程式的安全
需求： 伺服器之間的通訊驗證安全而有保障 需求： 伺服器之間的通訊驗證安全而有保障
需求： 伺服器的服務等級協定監視與報告 需求： 伺服器的服務等級協定監視與報告
需求： 確保安全的狀態通訊機制 需求： 確保安全的狀態通訊機制
需求： 使用 Active Directory 與 IAS/RADIUS 執行無線網路驗證與授權 需求： 使用 Active Directory 與 IAS/RADIUS 執行無線網路驗證與授權
需求： 集中化管理憑證服務 需求： 集中化管理憑證服務
需求： 主動管理分公司頻寬 需求： 主動管理分公司頻寬

簡介

安全性與網路是第三個核心基礎結構最佳化功能。下表說明在安全性與網路中移至合理化層級的高層級挑戰、適用解決方案，以及優點。

挑戰

解決方案

優點

業務挑戰

多層式安全性模型並未部署於整個網路 - 從周邊，通過防火牆、伺服器、桌上型電腦，和應用程式層級

防火牆並非桌上型電腦的標準元件

行動使用者欠缺透過公用網路所提供的路由基礎結構，對資源的安全存取

IT 挑戰

伺服器可接受來自任何主機的輸入流量，因此更容易遭受攻擊

無線用戶端的薄弱驗證

無線 LAN 的弱式加密和資料完整性

專案

對伺服器部署以原則管理的防火牆。確保遠端存取內部資源及 LOB 應用程式的安全

提供伺服器之間安全而有保障的通訊驗證

實作伺服器的 SLA 監視及報告

實作安全的狀態通訊機制

部署 Active Directory 與 IAS/RADIUS 以執行無線網路驗證與授權

實作集中化管理的憑證服務

開始主動管理分公司的頻寬

業務效益

使用者不論身在何處，都能安全地存取資源

安全性、設定與管理採取主動的原則與程序，可提高穩定度

IT 優勢

增進桌上型電腦軟硬體的資產管理

以集中化的群組原則來發佈 IPsec 原則和篩選器，提高電腦的安全性層級

IPsec 原則能限定只接受信任主機的輸入流量，可提高網路環境的安全性

IT 花在管理危機的時間減少，即有更多時間可為企業提供新的服務

基礎結構最佳化模型中的合理化層級能夠處理網路和安全性元件的重要領域，包括： 本機防火牆、IP 安全性、可用性監視、保護無線基礎結構安全性、憑證管理，和 WAN 管理。

需求： 伺服器及桌上型電腦上以原則管理的防火牆

對象

如果您並未在至少 80% 的伺服器和桌上型電腦上安裝以原則管理的防火牆，請閱讀本章節。

概觀

在《適用於實作人員的核心基礎結構最佳化資源指南： 基本至標準化層級》中，閱讀關於如何以集中化的周邊防火牆來保護網路電腦的說明。為了從標準化層級移至合理化層級，您必須補強網路的防火牆防護功能，作法是使用類別 1 的主機型防火牆，在伺服器「與」桌上型電腦上建立原則並加以強制執行。Microsoft 與其他軟體廠商提供的防火牆軟體能讓您基於原則或規則集來設定防護功能。這項需求與同樣屬於合理化層級之以集中化目錄為基礎的設定與安全性的需求密切相關。

大多數的類別 1 防火牆都能設定不同的防護層級，從極低到限制極嚴的都有。若您允許使用者自行設定電腦的防護層級，將無法確定他們所選擇的層級是否能夠保護您的整個網路。要是採用以原則管理的防火牆，您就能判定符合網路需求的安全性層級。

階段 1： 評估

「評估」階段中，您要再度評估環境中有哪些電腦已經具有某種具備原則管理功能的主機型防火牆型式。合理化層級規定，須有 80% 以上的桌上型電腦執行 Windows XP SP2 或 Windows Vista (參閱需求： 桌上型電腦上最新的兩種作業系統版本及 Service Pack)；在合理化層級並沒有明文要求伺服器必須執行最新的兩種作業系統版本。這一點很重要的原因在於，假設您的組織已經部署最新的兩種桌上型電腦作業系統版本，那麼就已經達到桌上型電腦要有主機型防火牆功能的需求，您只需要藉由群組原則把設定強制執行需求納入，確保 Windows 防火牆是依照理想的設定來執行就可以了。Windows Server 產品中的主機型防火牆自從 Windows Server 2003 SP1 發行起開始問世，所以如果組織的伺服器基礎結構中並沒有至少 80% 執行 Windows Server 2003 SP1 或更新版本，您便需要清查並且識別沒有主機型防火牆的系統。若要使伺服器基礎結構的作業系統與應用程式資訊自動化，建議使用 SMS 2003 硬體清查 (英文)。

階段 2： 識別

「識別」階段使用您在上一階段所產生的伺服器清查，所以僅需隔離需要主機型防火牆的伺服器基礎結構。到了「評估與規劃」階段，就必須決定適當的減緩策略，以啟用主機型防火牆，並且判定要用群組原則強制執行的適當防火牆設定。

階段 3： 評估與規劃

「評估與規劃」階段中，您要檢查主機型防火牆的技術，判定讓組織中 80% 的桌上型電腦和伺服器有主機型防火牆的適當行動過程。判定出如何把主機型防火牆套用到大多數桌上型電腦和伺服器的策略之後，請判定如何用群組原則來強制使用與設定主機型防火牆。這個階段僅負責評估與規劃在測試環境中主機型防火牆的部署。下列章節著重說明 Windows 防火牆，但您也可以選用類似的技術，例如 Internet Security Systems 的 BlackICE (英文) 或 Zone Labs 的 Zone Alarm (英文)。

Windows 防火牆

Windows 防火牆是內建型的主機式狀態防火牆，內含在 Windows XP Service Pack 2、Windows Server 2003 Service Pack 1、Windows Vista 和 Windows Server 代號 "Longhorn" (目前正進行 beta 測試)。Windows 防火牆會中斷未對應到回應電腦要求所傳送的流量 (請求的流量) 的輸入流量，或指定為允許 (例外流量) 的來路不明流量。

屬於主機式的 Windows 防火牆可在每一部伺服器和用戶端上執行；能防止穿透周邊網路或起源自組織內部的網路攻擊，例如，特洛伊木馬程式的攻擊、蠕蟲，或透過來路不明的輸入流量所散播的各種惡意程式。

如需 Windows 防火牆的更多資源，請到 https://www.microsoft.com/technet/network/wf/default.mspx (英文)。

80% 的桌上型電腦和伺服器要有 Windows 防火牆或類似的主機型防火牆功能，是必備的一項需求。如先前所述，您還可以評估的其他主機型防火牆產品有 Internet Security Systems 的 BlackICE (英文) 和 Zone Labs 的 Zone Alarm (英文)。

讓桌上型電腦和伺服器擁有主機型防火牆

為桌上型電腦和伺服器選定偏好的防火牆技術，也知道哪些主機需要有防火牆功能後，下一項工作就是測試、設定，和部署防火牆應用程式到測試基礎結構中。這些步驟符合本指南中針對修補程式管理、應用程式相容性測試，及應用程式部署所提出的最佳作法，說明請參閱伺服器的修補程式管理、軟體發佈的相容性測試和憑證及自動化追蹤桌上型電腦的軟硬體。如果選擇以 Windows 防火牆作為 Windows Server 2003 SP1 之前版本伺服器的單一偏好技術，您需要將目標屬意的伺服器更新到 Windows Server 2003 SP1 或更新版本。

防火牆的原則管理

主機型防火牆的原則管理也是核心基礎結構最佳化中，合理化層級所要求的部分。對 Windows 防火牆的使用者來說，重點只有確定啟用防火牆服務這一項。這項直接了當的程序是利用群組原則，以下列步驟來執行：

確認群組原則設定 [Windows 防火牆： 禁止在您的網域網路上使用網際網路連線防火牆] 設為停用或是未設定。

這項設定如果啟用，包括系統管理員在內的任何人都無法啟用或者設定 Windows 防火牆。若要變更這項原則設定，請用群組原則物件編輯器來編輯在您的組織中管理 Windows 防火牆設定所用的群組原則物件 (GPO)。

若要修改 [禁止在您的網域網路上使用網際網路連線防火牆] 設定

  1. 開啟群組原則物件編輯器，編輯在您的組織中管理 Windows 防火牆設定所用的 GPO。

  2. 依序按一下 [電腦設定]、[系統管理範本]、[網路] 和 [網路連線]。

  3. 在詳細資料窗格中，連按兩下 [Windows 防火牆： 禁止在您的網域網路上使用網際網路連線防火牆] 原則設定。

  4. 選擇 [已停用] 或 [尚未設定] 核取方塊。

若您不是使用 Windows 防火牆，請找到所選主機型防火牆的對等設定，執行對等的程序。為至少 80% 所管理的用戶端和伺服器完成佌操作之後，便已具備「伺服器及桌上型電腦上以原則管理的防火牆」這個需求屬性。如需更多群組原則的相關資訊，請參閱本指南中以集中化目錄為基礎的設定與安全性的需求。

如需更多進階 Windows 防火牆設定的相關資訊，請參閱管理 Windows 防火牆的最佳作法 (英文)。

階段 4： 部署

經過前三個階段，您現在應該已經準備好可以部署所選的主機型防火牆技術並啟用原則管理了。同樣地，部署程序也包含針對修補程式管理、應用程式相容性測試，及應用程式部署所建議的同等最佳作法，說明請參閱伺服器的修補程式管理、軟體發佈的相容性測試和憑證及自動化追蹤桌上型電腦的軟硬體。如需規劃與部署程序的相關詳細資訊，請參閱這些需求。

詳細資訊

如需更多有關防火牆的資訊，請造訪 Microsoft TechNet，然後搜尋「Windows 防火牆」。

若要瞭解 Microsoft 如何將防火牆併入網路周邊的安全性，請造訪 https://www.microsoft.com/technet/itshowcase/content/secnetwkperim.mspx (英文)。

檢查點： 伺服器及桌上型電腦上以原則管理的防火牆

需求

 

清查您的桌上型電腦及伺服器電腦，以識別目前擁有主機型防火牆技術的硬體。

 

將主機型防火牆技術部署至缺少防火牆功能的硬體，或將伺服器更新成 Windows Server 2003 SP1 或更新版本。

 

強制執行原則，以確保主機型防火牆永遠啟用，並且無法停用。

如果您已經完成上列步驟，則貴組織就已達到基礎結構最佳化模型中，「伺服器及桌上型電腦上以原則管理的防火牆」功能合理化層級的最低要求。我們建議您依照本指南中針對以原則管理的主機型防火牆以及管理 Windows 防火牆的最佳作法中所概述之其他最佳作法資源的指引進行。

移至下一個自我評估問題。

需求： 確保遠端存取內部資源及 LOB 應用程式的安全

對象

如果您的員工無法從遠端安全地存取電子郵件之外的內部資源及 LOB 應用程式 - 例如，虛擬私人網路 (VPN) 或 Microsoft 終端機服務，請閱讀本章節。

概觀

現今的企業環境之下，組織普遍蒙受壓力，不得不降低成本，提高效率，並且從現有的基礎結構獲取最大的效能。網際網路的成長，加上嶄新的全球企業商機，迫使組織必須為員工和全球的據點提供安全的全天候網路存取功能。一般會使用遠端存取的兩種情形是：

  • **遠端用戶端的存取。**遠端用戶端通常是單一電腦，例如員工在家或旅途中工作，需要存取企業資源時所用的家用電腦或膝上型電腦。

  • **站台間的存取。**站台間的存取是在組織的分公司與集中化設施之間，用來存取位在不同邏輯與實體位置的資源與資料。

企業組織的這兩種主要遠端存取需求，都能用 VPN 來提供。這兩類解決方案都需要基本的撥號連線或網際網路 (共用) 租用連線。本指南除了著重在 VPN 之外，也介紹滿足這項需求的終端機服務。指引的內容是依據 Windows Server System 參考架構 (WSSRA) 遠端存取服務 (英文)。

如需 Windows Server 2003 中 VPN 的更多技術資源，請造訪 Microsoft TechNet 中的虛擬私人網路網站 (英文)。

階段 1： 評估

在「評估」階段，您要識別用戶群目前從遠端位置工作的方式。組織往往只透過例如 Microsoft Office Outlook® Web Access (OWA) 或網頁型的特定業務應用程式這類服務，提供存取電子郵件的功能。這樣的情況下，終端使用者與企業內部使用者比較之下，等於只擁有功能的子集。在「評估」階段，您要判斷企業內部使用者可用服務的高階清單，例如內部網路和共同作業服務；以及企業外部或分公司的使用者可用的項目，例如網頁型電子郵件和 LOB 應用程式。

階段 2： 識別

現在，您已經有了企業內部、企業外部或分公司的使用者服務清單，到了「識別」階段便只須判斷有哪些企業內部可用服務，若透過遠端存取，安全地提供給企業外部使用者，就能夠提高使用者的生產力與效率。一般來說，組織主要的遠端存取需求，也就是遠端用戶端存取和站台間的存取，可以利用 VPN 來提供。這兩類解決方案都需要具備網際網路連線或租用連線。

階段 3： 評估與規劃

「評估與規劃」階段中，您要檢查選定遠端存取服務的提供方式，以及用來維護安全性的控制功能。對大多數的組織來說，為了確保與企業網路的連線安全，而到每座城市開設辦事處，或是在每位員工的家中提供私有線路，都是耗費過高的成本。VPN 能讓企業合作夥伴和員工透過網際網路建立安全的加密連線，而且通常成本低廉。

虛擬私人網路

虛擬私人網路 (VPN) 是兩個端點之間的安全加密連線，這是透過共用連線，例如網際網路所建立，作為企業網路的延伸使用。VPN 讓組織只要把辦公室或使用者連線到網際網路服務提供者 (ISP)，就能夠利用現有的全球網際網路基礎結構。VPN 也是可延伸的技術；例如，可以實作 VoIP 讓遠端使用者隨時隨地在工作當中使用辦公室的電話分機 (和所有的傳訊功能)。

VPN 連線讓在家工作或旅途中的使用者能夠透過公用互連網 (例如網際網路) 所提供的基礎結構，取得對組織伺服器的遠端存取連線。從使用者的角度來看，VPN 是電腦、VPN 用戶端和組織伺服器 (VPN 伺服器) 之間的點對點連線。共用或公用網路的實際基礎結構如何並不重要，因為資料會好像是透過專屬私人連結所傳送。

VPN 連線也允許組織透過公用互連網 (例如網際網路) 與其他組織之間建立路由連線，同時維持安全的通訊，例如為了地理位置分開的辦事處所設置。透過網際網路的路由 VPN 連線，邏輯上是以專屬廣域網路 (WAN) 連結的方式來操作。

下圖所示為使用 VPN 的遠端存取服務在架構上的設計。  

圖 7. 使用 VPN 的遠端存取服務在架構上的設計

圖 7. 使用 VPN 的遠端存取服務在架構上的設計

VPN 的設計考量

設計 VPN 解決方案的時候有許多事項必須考量，包括安全性、成本、整合、未來需求，和系統管理。決定適當的 VPN 技術之前，務必先判斷 VPN 解決方案的設計目標。這些目標依照解決方案是用於遠端用戶端的存取、站台間的存取，或兩者兼具而各不相同。如需更多 VPN 設計選項的相關資訊，請參閱 WSSRA 遠端存取服務藍圖 (英文)。

規劃遠端存取服務

遠端存取的設計是以判定業務與技術需求的程序過程中，所收集的資訊作為依據。通常，遠端存取解決方案對遠端用戶端來說是有其必要的，例如員工在家或旅途當中工作時，以及具備企業站台間連線與多位使用者的分公司站台。

如需更多有關規劃對遠端用戶端設置遠端存取服務的資訊，請參閱《WSSRA 遠端存取服務規劃指南》中，企業資料中心 (CDC) 的案例 (英文)。

如需更多有關規劃對分公司設置遠端存取服務的資訊，請參閱：

終端機服務

Microsoft Windows Server 2003 的終端機服務元件讓您能遞送 Windows 應用程式，或 Windows 桌面本身到幾乎是所有的運算裝置，包括無法執行 Windows 的裝置在內。

Windows Server 2003 中的終端機服務可為安全的遠端存取提供三大重要的優勢：

  • 迅速集中部署應用程式。

  • 以低頻寬方式存取資料。

  • 隨處都能使用 Windows。

如需更多終端機服務的相關資訊，請至 http://technet2.microsoft.com/windowsserver/en/technologies/featured/termserv/default.mspx (英文)。

階段 4： 部署

評估過遠端存取服務的選項，並且規劃為遠端用戶端及分公司提供適當服務的需求之後，到了「部署」階段，即可展開設計的實作。WSSRA 遠端存取服務建置指南中提供下列兩種情形下測試與部署 VPN 服務的實作步驟：在 CDC 的情形下對遠端用戶端以及在 SBO 的情形下對分公司。

詳細資訊

若要瞭解 Microsoft 如何實作 VPN 和終端機服務，請到下列網站：

檢查點： 確保遠端存取內部資源及 LOB 應用程式的安全

需求

 

評估遠端用戶端及分公司的遠端存取需求。

 

設計安全的虛擬私人網路或類似的服務，並實作至遠端用戶端及分公司。

如果您已經完成上列步驟，則貴組織就已達到基礎結構最佳化模型中，「確保遠端存取內部資源及 LOB 應用程式的安全」功能合理化層級的最低要求。我們建議您依照 Microsoft TechNet 中的虛擬私人網路網站 (英文) 中有關 VPN 其他最佳作法資源的指引進行。

移至下一個自我評估問題。

需求： 伺服器之間的通訊驗證安全而有保障

對象

如果您沒有安全且有保障的方式可驗證關鍵伺服器 (例如網域控制站和電子郵件伺服器) 之間的通訊，請閱讀本章節。

概觀

組織在保護網路周邊安全方面上正面臨日益艱難的挑戰。隨著組織成長，業務關係發生變化，加上客戶、廠商、和顧問等基於業務上的正當理由，需要把行動裝置連線到您的網路，造成以實體方式對網路的存取變得無法控制。無線網路和無線連線技術使得網路存取比從前更簡單。連線能力的提升意味著，內部網路的網域成員除了面臨周邊安全性弱點之外，內部網路他台電腦所帶來的重大風險也提高了。

本指南提出的邏輯隔離概念包含兩種解決方案： 伺服器隔離，用以確保伺服器只接受來自信任的網域成員或特定的網域成員群組的網路連線；以及網域隔離，用來把網域成員與不信任的連線彼此隔開。這些解決方案是整個邏輯隔離解決方案的一部分，可單獨使用或共同使用。

在核心的部分，伺服器隔離和網域隔離讓 IT 系統管理員得以限制在信任的電腦上，網域成員的 TCP/IP 通訊。您可將受信任的電腦設定為只接受其他信任電腦的連入連線，或只接受信任電腦的特定群組的連入連線。群組原則會集中管理掌控網路登入權限的存取控制。幾乎所有的 TCP/IP 網路連線都無需變更應用程式，就可受到安全保護，這是因為網際網路通訊協定安全性 (IPsec) 在應用程式層下方的網路層運作，在電腦之間端對端提供驗證以及每個封包的安全性。您可使用各種自訂案例來驗證網路流量，或是驗證並加密網路流量。本指南遵循 Microsoft TechNet 上的使用 IPsec 和群組原則執行伺服器和網域隔離指南 (英文) 所提出的指引與建議。

階段 1： 評估

第一個階段與本指南中的其他需求一致，均為評估組織目前的狀態。要在組織中獲取並維護所有電腦、軟體、網路裝置的可靠記錄，一直都是 IT 領域的常見課題。為了定義目前的狀態，需要有下列項目的資訊：

  • 網路搜索

  • 記載網路分割

  • 網路基礎結構裝置

  • 分析目前網路流量模型

  • Active Directory

  • 主機探索

  • 主機資料的需求

如需更多收集這些資訊的詳細資訊，請參閱使用 IPsec 和群組原則執行伺服器和網域隔離指南的第 3 章： 確定您目前的 IT 基礎結構狀態 (英文)。本指南探討每個項目的需求，及如何使用 SMS 2003 (英文) 或類似產品透過自動化的探索功能以及手動探索選項，來收集資訊。

階段 2： 識別

「識別」階段是要判斷哪些策略適合您組織的需要。要保護現代 IT 基礎結構不受攻擊者破壞，又要讓員工能夠靈活工作並保有高生產力，實非易事。對許多人來說，單是去瞭解保護環境所需的技術已經很困難了。清楚瞭解這套解決方案如何適用於一般 IT 基礎結構，以及此解決方案如何輔助現有的網路防禦，也許會有所幫助。

下圖顯示包含多個網路防禦層的一般網路基礎結構，並說明一般環境中何處需要邏輯隔離。

圖 8. 一般的網路基礎結構

圖 8. 一般的網路基礎結構

「識別」階段的結果將用來判定伺服器和網域隔離設計的高階需求。在「評估與規劃」階段中，我們要制訂詳細的需求和執行計畫。如需更多資訊，請參閱使用 IPsec 和群組原則執行伺服器和網域隔離指南的第 4 章： 設計與規劃隔離群組 (英文)。

階段 3： 評估與規劃

「評估與規劃」階段的目標，在於確保所有的選項都已經過考量，讓伺服器之間經過驗證的通訊安全有保障。在此情況中，我們把焦點放在以 IPsec 作為機制執行；核心基礎結構最佳化模型中，合理化層級的集中化管理憑證服務則另有其他相關需求。

為了建立「部署」階段的執行計畫，我們提供了伺服器和網域隔離設計的實作指示。

評估網際網路通訊協定的安全性

IPsec 一般是用來保護兩部伺服器之間的通訊管道，並且限制能彼此通訊的電腦。舉例來說，可以建立原則，只允許所信任用戶端電腦 (例如，應用程式伺服器或 Web 伺服器) 所發出的要求，來協助保護資料庫伺服器。也可以限定只能用特定的 IP 通訊協定和 TCP/UDP 連接埠來進行通訊。

伺服器陣列的網路需求與建議之所以認為 IPsec 是個不錯的選擇，原因在於：

  • 所有的伺服器都包含在一個實體的 LAN 中 (可提高 IPsec 的效能)。

  • 會指派靜態 IP 位址給伺服器。

IPsec 也能在信任的 Windows Server 2003 或 Microsoft Windows 2000 Server 網域之間使用。例如，可以用 IPsec 來保護位在周邊網路中的 Web 伺服器或應用程式伺服器的通訊安全，以連線至內部網路中執行 Microsoft SQL Server 的電腦。如需更多資訊，請參閱 Windows Server 2003 部署指南中的選擇 IPsec 驗證方法。

如需更多針對 IPsec 所建議環境的相關資訊，請參閱 Windows Server 2003 部署指南 (英文) 中的確定您的 IPsec 需求 (英文)。

規劃伺服器和網域隔離

在「識別」階段中，我們建立了高階的需求。下個步驟是要建立實作計畫，這時運用的是使用 IPsec 和群組原則執行伺服器和網域隔離指南中的第 4 章： 設計與規劃隔離群組 (英文)。建立計畫，並且也定義出詳細需求之後，即可結合下列元素，來實作這些需求：

隔離網域和隔離群組的輸入/輸出存取需求：

  • 專為需要 IPsec 網際網路金鑰交換 (IKE) 交涉以進行輸入與輸出連線的隔離群組而設的網際網路通訊協定安全性 (IPsec) 原則。

  • 網域型安全性群組若使用受 IPSec 保護的流量，可命令網路存取群組容許或拒絕網路存取  

隔離網域和隔離群組的網路流量保護需求：

  • 專為適當識別哪些流量需要保護而設計的 IP 原則篩選器。

  • 篩選器識別出流量後，會交涉所需驗證與加密層級的 IPsec 篩選器動作。

  • 信任主機開始輸出連線後，控制是否容許純文字通訊的 IPsec 篩選器動作設定。

使用 IPsec 和群組原則執行伺服器和網域隔離指南的第 5 章： 建立隔離群組的 IPsec 原則 (英文) 內容探討應如何準備在 Windows Server 2003 的 Active Directory 中使用群組原則和 IPsec 原則的解決方案，以及如何用 Windows Server 2003 和 Microsoft Windows XP 來設定網域成員。

階段 4： 部署

「部署」階段的目標是要實作前三個階段的規劃結果。在這個階段中，您要在 Active Directory 中建立 IPsec 原則，包括建立篩選器清單、篩選器動作以及 IPsec 原則，以實作隔離群組。下圖說明 IPsec 原則的各種元件及它們彼此之間的關聯。

圖 9. IPsec 原則的元件

圖 9. IPsec 原則的元件

如需 IPsec 原則的詳細實作指引，請參閱使用 IPsec 和群組原則執行伺服器和網域隔離指南中的第 5 章： 建立隔離群組的 IPsec 原則 (英文)。

詳細資訊

如需更多 IPsec 的相關資訊，請造訪 Microsoft TechNet，然後搜尋 "IPsec"。

若要瞭解 Microsoft 如何保護伺服器之間通訊的安全，請至 https://www.microsoft.com/technet/itshowcase/content/ipsecdomisolwp.mspx (英文)。

檢查點： 伺服器之間的通訊驗證安全而有保障

需求

 

評估網際網路通訊協定安全性 (IPsec) 所影響網路基礎結構的目前狀態。

 

識別組織需求，以確保伺服器之間通訊安全而有保障，包括法規遵循的影響。

 

開發並實作整體組織運用 IPsec 以滿足所定義需求的計畫。

如果您已經完成上列步驟，則貴組織就已達到基礎結構最佳化模型中，「伺服器之間的通訊驗證安全而有保障」功能合理化層級的最低要求。我們建議您依照有關伺服器之間通訊的其他最佳作法資源的指引進行。

移至下一個自我評估問題。

需求： 伺服器的服務等級協定監視與報告

對象

如果您目前並沒有服務等級協定 (SLA) 可監視 80% 以上的伺服器並且進行服務等級報告，請閱讀本章節。

概觀

在目前的 IT 業界，以服務管理的方式來管理 IT 已經變得越來越普及。組織努力維持競爭力，迎合內外消費者的需要之際，發覺 IT 基礎結構再也不能只是個透過廣域網路 (WAN) 連接且執行應用程式的伺服器集合而已。您與所屬的組織必須把這些資源視為產生營收並為消費者提供功能的服務。您若採取這種方式，就必須瞭解組成服務的所有元件，以及每個元件對服務提供的可用等級所構成的影響。此外，您也必須成功度量出服務隨著時間所產生的成果，以便清楚瞭解系統所提供的服務品質。

在《適用於實作人員的核心基礎結構最佳化資源指南： 基本至標準化層級》指南中的內容，針對在標準化層級中，以自動化的方式監視組織內關鍵伺服器的需求，提出討論。在合理化層級，我們只須要把需求擴充到組織內的所有伺服器，把服務層級管理的需求附加成為監視需求之中就可以了。合理化層級不需要可用性的底限；這一點是依照組織內的每項 IT 服務，視情況來決定的。

階段 1： 評估

如同標準化層級一般，在「評估」階段，您的組織要清查組織基礎結構內所有的伺服器。您可以手動識別伺服器和規格，也可以利用工具將清查程序自動化，例如 Systems Management Server (SMS) 2003 (英文) 的清查收集功能。

移至合理化層級的其他交付項目有：

  • 判定組織中主要的 IT 服務 (服務類別目錄)。

  • 指派遞送這些服務所需的基礎結構元件。

  • 收集資訊，以判定基準的目前服務層級。

制定服務層級基準

基準是隨著時間所描繪出情況的「快照」的線條。在這個實例中，是指組織內服務層級管理的情況。基準可形成特定時間遞送服務所產生的圖形，並且可以在服務層級管理方面，提供達成未來目標的計畫。最佳化 IT 效能的工作需要的不僅只是對於目標具有清楚的願景，同時也需要程序開始當時所處於的基準。

如需評估服務層級基準的更多指引，請參閱 Microsoft Operations Framework (MOF) 服務層級管理指引。

階段 2： 識別

清查過所有的伺服器之後，合理化層級的「識別」階段就是對照基準，定義適當服務層級的程序。服務層級管理的主要目標在於長期提升企業可用的服務，並且解決目前存在的服務準備問題。

在 IT 部門可獲得的許多優勢當中，除了提升服務之外，也能增加對企業所懷期望的認知，改進成本管理。服務層級管理讓 IT 部門得以滿足企業期望，展開確認這些期望的對話。例如，IT 部門可能想要提供可用性 100 %、99.999 %，甚至 70 % 的服務，卻無法解釋為何是這樣的數字表現。除非這樣的期望在服務層級管理程序的早期列入正式記錄並且獲得議定，否則 IT 部門可能專注在非業務關鍵的服務 - 例如，開發員工、投資軟硬體，還有其他耗費成本的工作，對企業卻沒有什麼實質的好處。

服務層級目標

設定服務層級目標的時候，請度量企業的要求。這一點經常可以包含程序的度量 - 例如，評定客戶的滿意度、回電，和回應查詢。組織內可能有現存的技術，能用來協助進行這些度量。例如，客服中心的技術可以按照登錄個人撥出電話的服務支援部中的通話記錄，編排作成報告。

遞送服務經常導致複雜的元件鏈產生。不過，只要能從端至端的元件鏈度量此目標的服務遞送情形，仍有可能議定出服務的最終目標。

服務層級目標的常見度量

度量

範例

可用性

服務可用的天數與小時數，或以此為根據的 % 數字。

因應能力與效能

服務的速度與量 (輸送量或工作量的度量)、獲得資料所花的時間、資料傳輸速度與回應時間，以及回應的技術與人員速度。

安全性

服務的安全性。

服務層級目標的度量必須以下列準則仔細考量：

  • 是否支持企業目標？

  • 是否特定？

  • 是否能度量？

  • 即使需要 IT 大力出動，是否能夠達成？

  • 相對於可為企業帶來的優勢，是否務實？

階段 3： 評估與規劃

因為所有的服務都已經在服務類別目錄中定義完成，同時也定義了想要的服務層級，在「評估與規劃」階段中，我們要評估自動監視 IT 服務中所存在元件的技術。

監視軟體

本章節說明如何用軟體來監視關鍵伺服器的可用性。這個範例中，是以 Microsoft Operations Manager (MOM) (英文) 作為負責監視的角色。無論是否使用 MOM，監視伺服器的可用性或其他服務層級度量的軟體都必須具有下列功能：

  • 能收集伺服器的屬性資訊，並根據屬性套用特定規則，以便監視。

  • 能依照特定規則的定義，由事件記錄檔和其他提供者取得資料。

  • 能依照效能計數器收集效能資料。

  • 能依照規則中指定的準則產生警示。

依照組織的服務等級協定中所定義的度量，可以用 MOM 作為收集資料的單獨技術。大多數的情況下，MOM 的資料必須輔以其他服務的資料；例如，若您已經在變更與版本管理中定義了服務層級，就必須使用其他機制所產生的狀態報告，例如 Systems Management Server 2003 報告功能。  

本出版品付梓時，System Center Operations Manager 2007 正在發行過程當中。這是 Microsoft 下一版本的作業管理解決方案，其中新增了服務導向的健全狀況監視、用戶端監視，和網域服務監視等功能。   

MOM 可用性管理組件

有了 MOM 可用性管理組件，您可以收集與分析伺服器的事件記錄檔中的資料，然後產生可設定的報告，以便檢視和依照組織的需求進行自訂。您可以用這些報告來識別計畫內外的停機原因，採取預防措施來減少未來的停機時間。

您可以使用可用性報告來：

  • 判斷伺服器是否達到可用性和可靠度的目標。

  • 篩選報告，檢視經過特定時間長度所收集的資訊，例如以數個月或數年為期，以追蹤趨勢。

  • 識別特定領域效能表現最佳與最差的電腦。

  • 識別問題領域，例如停止回應的特定應用程式或作業系統版本。

  • 使用關機事件追蹤器來檢視與分析所收集的資訊。

利用 MOM 可用性管理組件，可在服務層級管理中進行重要的監視度量，然後移至合理化層級，所以這是很重要的工具。如需更多 MOM 可用性管理組件的相關資訊，請至 https://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/3e1dfa65-84a5-4e3e-9403-3ef9b47c6b68.mspx?mfr=true (英文)。

規劃 Microsoft Operations Manager 的部署

若您選定以 Microsoft Operations Manager 作為伺服器的監視技術，只是還沒有部署到環境當中，請參閱 Microsoft TechNet Operations Manager TechCenter (英文) 中的 MOM 2005 部署規劃指南 (英文)。

System Center Operations Manager 2007

System Center Operations Manager 2007 可進行服務導向的監視，讓您能夠監視端對端的資訊技術服務、擴充監視整個大型環境與組織，及運用 Microsoft 應用程式和作業系統的知識來解決操作上的問題。下列是 Operations Manager 2007 所提供的部分豐富功能。

服務導向監視

合併式的 Operations 主控台能顯示環境的健全狀況，並讓您能夠處理警示。如需關於 Operations 主控台的其他資訊，請參閱 Operations Manager 2007 中的 Operations 主控台 (英文)。

報告可提供多種檢視環境健全狀況的方式。如需關於報告的其他資訊，請參閱 Operations Manager 2007 中的報告 (英文)。

內建管理組件

立即可用的管理組件可提供許多 Microsoft 應用程式的監視資訊。此外，您也可以自行建立管理封包，來監視自訂的應用程式。如需關於管理封包的其他資訊，請參閱 Operations Manager 2007 中的管理組件 (英文)。

大多數的 Microsoft 管理組件中都含有如何解決應用程式常見問題的資訊。

用戶端監視

用戶端監視讓您能把作業系統和應用程式的錯誤報告轉送到 Microsoft，並且接收這些錯誤的解決方案 (如果有的話)。如需其他資訊，請參閱 Operations Manager 2007 中的用戶端監視 (英文)。

Active Directory 網域服務

Active Directory 網域服務整合允許您指派以代理程式管理的電腦給管理群組，得以運用先前的投資。如需關於 Active Directory 網域服務的其他資訊，請參閱 Operations Manager 2007 中的 Active Directory 網域服務整合 (英文)。

安全的監視環境

安全性功能可讓您監視資訊技術服務與應用程式的健全狀況，即使部分的環境位於保護領域外部也是如此。如需關於安全性功能的其他資訊，請參閱 Operations Manager 2007 中的安全性考量 (英文) 和 Operations Manager 2007 閘道伺服器 (英文)。

角色型的授權可讓您量身打造操作人員和系統管理員所能採取的動作。如需關於角色的其他資訊，請參閱關於 Operations Manager 2007 中的使用者角色 (英文)。

稽核收集能從所管理的電腦高效收集安全性事件，提供報告以便分析。如需關於稽核收集的其他資訊，請參閱稽核收集服務 (ACS) (英文)。

詳細資訊

如需更多 System Center Operations Manager 2007 的相關資訊，請造訪 http:/www.microsoft.com/technet/opsmgr/opsmgr2007_default.mspx (英文)。

階段 4： 部署

在服務類別目錄中定義了 IT 服務，決定了基準或目前的服務層級，定義了適用組織的服務層級，也訂定了自動化服務層級監視的計畫之後，接著應該實作可用性監視解決方案。

如果您的組織已經選定以 Microsoft Operations Manager 作為執行系統可用性監視的技術，如需詳細的部署指南，可查閱 Microsoft TechNet 網站的 MOM 2005 部署指南 (英文) 和 System Center Operations Manager 2007 部署指南 (英文)。  

詳細資訊

如需更多資訊，請至 Microsoft TechNet，然後搜尋 "SLA"。

檢查點： 伺服器的服務等級協定監視與報告

需求

 

在服務類別目錄中定義組織的 IT 服務。

 

判斷適用於已定義服務的基準或目前的服務層級。

 

定義適合組織的服務層級，並決定自動化服務層級監視的計畫。

 

實作自動化的可用性監視解決方案。

如果您已經完成上列步驟，則貴組織就已達到核心基礎結構最佳化模型中，「伺服器的 SLA 監視及報告」功能合理化層級的最低要求。我們建議您依照 Microsoft Operations Framework (英文) 中建立與監視伺服器 SLA 的其他最佳作法資源的指引進行。

移至下一個自我評估問題。

需求： 確保安全的狀態通訊機制

對象

如果您目前沒有安全的狀態通訊機制，例如工作階段初始通訊協定 (SIP)，請閱讀本章節。

概觀

狀態是描述特定使用者的通訊位置與是否可通訊的即時資訊。建立整體企業的狀態可以明顯提高生產力。追蹤時間縮短，員工之間的共同作業與通訊則更有效率。

線上狀態讓個人有能力隨時識別有誰在線上並且能夠進行通訊。若啟用線上狀態功能 (並安裝所需軟體)，只要有人出現在站台集合中，名字旁邊就會新增線上狀態標記。線上狀態標記可顯示個人是離線或是在線上，能夠經由立即訊息用戶端回應查詢。當個人在線上時，您可以按一下線上狀態標記，傳送立即訊息。這樣可以直接接觸具備專門知識的人員，能協助團隊成員的工作更有效率，效益更高。

您可以採取步驟，提供狀態資訊的安全通訊。立即訊息系統可供目錄中的使用者物件彼此安全地通訊。藉由為狀態通訊提供像是工作階段初始通訊協定 (SIP) 這樣的技術，您可以從標準化層級移到合理化層級。合理化層級要求經由 SIP 的通訊也必須安全，這表示通訊會被保存、透過目錄服務操作，並且也使用憑證。

若要進一步瞭解狀態的業務價值，請下載 Live Communications Server 2005 文件： 狀態的業務價值 (英文) 文件。

階段 1： 評估

在「評估」階段，我們將會檢視組織中的使用者目前如何識別其他使用者的狀態。許多組織都使用網際網路服務提供者的立即訊息技術。雖然在共同作業佔重要地位的許多環境中，啟用線上狀態有很大的好處，但也必須在群組成員之間增加共同作業所帶來的好處，與安全性與法規遵循的要求，這兩者之間達到平衡，尤其在於立即訊息用戶端的部署方面。狀態的規劃須能確保進出立即訊息用戶端的內外通訊，都能符合全公司的安全性原則，也遵循法規準則與企業作法。在許多組織當中，立即訊息的對話必須依照電子通訊記錄保留需求加以留存。例如，必須遵循美國沙賓法案規定的組織就必須依照記錄留存的需求，保存立即訊息的對話。

「評估」階段的主要交付項目是清查組織內目前使用的軟體應用程式，以啟用狀態與立即訊息。在高度鎖定的環境中，您的使用者可能受到原則限制，無法安裝應用程式；不過，仍舊建議您清查所有系統。您可以利用例如 Systems Management Server 2003 (英文) 或 Application Compatibility Toolkit (ACT) (英文) 等工具，集中清查環境。

階段 2： 識別

在「識別」階段中，您將開始收集依照規範或組織原則啟用狀態的高階需求。如同以上說明，對許多組織而言，必須內部保存立即訊息的對話。此外，您也要調查狀態指標整合至其他生產力應用程式的程度如何，例如電子郵件和共同作業軟體。「識別」階段所產生的需求規格，會在後續階段當中，評估與規劃狀態的時候派上用場。

如需狀態如何搭配 Microsoft Office SharePoint® Server 使用的資訊，請參閱 http://technet2.microsoft.com/Office/en-us/library/3f53f3d3-85b8-42e5-8213-afb5eec7e8651033.mspx (英文)。

如需將狀態功能與 Microsoft Office Outlook 整合的資訊，請參閱 http://technet2,microsoft.com/Office/en-us/library/53c024e4-db55-4858-9ef6-5cba97c1afbd1033.mspx (英文)。

階段 3： 評估與規劃

「評估與規劃」階段中，您要檢查在環境中啟用狀態的特定技術。下列章節內容著重於通訊協定，並且列出可啟用狀態功能的部分 Microsoft 技術。

工作階段初始通訊協定 (SIP)

工作階段初始通訊協定 (SIP) 類似超文字傳輸通訊協定 (HTTP)，是文字型的應用程式層發訊與通話控制通訊協定。SIP 用來建立、修改和終止 SIP 工作階段。可支援單點傳播與多點傳送通訊。因為 SIP 屬文字型，所以實作、開發與除錯會比 H.323 更容易。若使用 SIP，使用者可以明確邀請另一位使用者加入對話或多媒體工作階段。SIP 工作階段會在第二位使用者接受邀請時開始。SIP 也可以支援邀請更多使用者加入已經建立的工作階段。

若要瞭解更多關於即時通訊的通訊協定資訊，請至 https://www.microsoft.com/technet/prodtechnol/winxppro/plan/rtcprot.mspx (英文)。

Live Communications Server

Live Communications Server 2005 在可擴充的企業級解決方案中附有立即訊息 (IM) 和狀態功能，可提供強化的安全性，能與 Microsoft 其他產品密切整合，並有可延伸的業界標準開發平台。Microsoft Office Live Communications Server 2005 可提供下列安全通訊與共同作業的工具，並以在狀態功能中運用 SIP 作為一大特色：

  • 即時訊息

  • 影音通訊

  • 資料共同作業

請造訪 Microsoft Office Live Communications Server TechCenter (英文) 查看 Microsoft Office Live Communications Server 的規劃、部署與操作相關資訊。

Office Communicator 2005 和 Office Communicator 2007

Office Communicator 2005 和 Office Communicator 2007 是安全的企業訊息用戶端，能將立即訊息與電話、視訊整合，成為整合式立即訊息。Office Communicator 2007 具有與 2007 Microsoft Office 全系統的程式相整合的功能 - 包括 Microsoft Word、Excel®、PowerPoint、OneNote、Groove 和 SharePoint Server。

如需更多 Office Communicator 2005 的相關資訊，請參閱 Office Communicator 2005 資源中心 (英文)。

如需更多 Office Communicator 2007 相關資訊，請參閱 Microsoft Office Communicator 2007 產品概觀 (英文)。

Office Outlook 2007

如果您的組織使用的是 Microsoft Office Outlook 2007，可以在全域通訊清單上，替使用者的連絡人詳細資料中啟用狀態功能。狀態如果設定，也會顯示在所收到的電子郵件中。Office Outlook 2007 能與 Office Communicator 2005 或 Office Communicator 2007 整合。

如需更多設定 Office Outlook 2007 以啟用狀態的資訊，請參閱 http://technet2.microsoft.com/Office/en-us/library/53c024e4-db55-4858-9ef6-5cba97c1afbd1033.mspx (英文)。

Office SharePoint Server 2007

如果您的組織使用 Microsoft Office SharePoint Server 2007，對於 SharePoint 站台具有存取權的個人，只要啟用線上狀態，就能檢視有哪些其他參與者在線上，也可以傳送立即訊息給對方。線上狀態可作為強大的共同作業工具，協助站台成員迅速找到能回答問題的人員。

如需更多在 Office SharePoint Server 2007 中規劃狀態整合的相關資訊，請參閱 Office SharePoint Server 2007 的規劃與架構指南，

規劃狀態和管理的立即訊息基礎結構

在您評估過在組織中啟用狀態的技術之後，下一項工作是要規劃與設計選定的基礎結構。若要在組織內部啟用整合狀態，通常需要下列項目：

  • 目錄服務

  • 通用類別目錄

  • 部署 DNS 並且正確設定

  • 公開金鑰 (PKI) 和憑證授權 (CA) 基礎結構

  • 後端資料庫

進入合理化層級時，您的組織通常已經達成這些元件需求。下圖所示為 Live Communications Server 2005 Enterprise Edition 基礎結構的架構範例。

圖 10. Live Communications Server Enterprise Edition 的基礎結構

圖 10. Live Communications Server Enterprise Edition 的基礎結構

「評估與規劃」階段最後一個交付項目，是選定狀態基礎結構的部署計畫和架構設計。如需更多使用 Microsoft 技術規劃狀態的相關資訊，請參閱 Microsoft Office Live Communications Server 2005 Service Pack 1 規劃指南 (英文)。

階段 4： 部署

現在，先前的階段已經衍生出目前啟用立即訊息和狀態的作法清查、實作狀態與所管理立即訊息的高階需求規格、狀態與立即訊息技術的評估，和選定解決方案的部署計畫等。在「部署」階段，我們要實作選定的狀態解決方案。為了協助部署新技術，您也可以檢視管理現有或未受管理的立即訊息所用的原則；這可能包括實作原則以限制傳送或接收檔案、封鎖安裝新的應用程式，或解除安裝與適合組織的既定原則準則不符的未管理應用程式。

如果您已經選定 Live Communications Server 2005，如需詳細的部署規劃與執行資訊，請參閱 Microsoft TechNet 上的 Microsoft Office Live Communications Server 2005 Service Pack 1 規劃指南 (英文)。  

詳細資訊

如需詳細資訊，請造訪 Microsoft TechNet，然後搜尋「狀態」。

若要瞭解 Microsoft 如何使用 Microsoft Office Live Communications Server 2005，請至 https://www.microsoft.com/technet/itshowcase/content/lcs2005twp.mspx (英文)。

檢查點： 確保安全的狀態通訊機制

需求

 

評估任何狀態和立即通訊所使用的目前未受管理方法。

 

建立符合產業或當地法規及原則的狀態和立即通訊的需求規格。

 

評估狀態與立即訊息的技術，建立實作選定解決方案的計畫。

 

至少透過管理的立即通訊，或透過共同作業及電子郵件基礎結構 (選擇性) 實作狀態。

如果您已經完成上列步驟，則貴組織就已達到基礎結構最佳化模型中，「確保安全的狀態通訊機制」功能合理化層級的最低要求。  

移至下一個自我評估問題。

需求： 使用 Active Directory 與 IAS/RADIUS 執行無線網路驗證與授權

對象

如果您目前還沒有部署以 Active Directory 和 IAS/RADIUS 進行驗證和授權的安全無線網路，請閱讀本章節。

概觀

無線技術幫我們擺脫了電線的束縛。使用者只要拿著筆記型電腦、PDA、Pocket PC、Tablet PC，甚至行動電話，就能在有無線訊號的地方上網。無線技術背後的基本理論在於，由電磁波載送訊號，然後傳送到訊號接收器。但為了要讓兩個無線裝置彼此瞭解，就需要通訊協定以便進行通訊。遠端驗證撥入使用者服務 (RADIUS) 是用戶端/伺服器通訊協定，其中由 RADIUS 用戶端傳送驗證和帳戶處理要求到 RADIUS 伺服器。RADIUS 伺服器會檢查使用者帳戶的遠端存取驗證認證，並且記錄遠端存取帳戶處理的事件。

Windows Server 2003 的網際網路驗證服務 (IAS) 或未來的網路原則伺服器 (NPS) 搭配 Windows Server 代號 "Longhorn"，就是 Microsoft 實作的 RADIUS 伺服器和 Proxy。作為 RADIUS 伺服器的 IAS 可執行多種類型的網路存取集中化連線驗證、授權，和帳戶處理，包括無線、驗證切換，和遠端存取撥號與虛擬私人網路 (VPN) 連線。作為 RADIUS Proxy，IAS 會轉寄驗證和帳戶處理訊息到其他 RADIUS 伺服器。RADIUS 是網際網路工程任務推動小組 (IETF) 訂定的一套標準。

階段 1： 評估

您已經閱讀本指南先前的章節和《適用於實作人員的核心基礎結構最佳化資源指南： 基本至標準化層級》的相關內容，瞭解驗證使用者存取您 IT 環境的重要性。為了移至合理化層級，您必須採取下一個步驟，那就是無論使用者存取您網路時使用的是什麼方法，都要把驗證和授權擴大到使用者身上。

「評估」階段是要再度清查您組織內現有的無線基礎結構。許多組織已經具備無線網路功能，而無線網路技術一般有三種類型：

  • 無線區域網路 (WLAN)

  • 無線個人區域網路 (WPAN)

  • 無線廣域網路 (WWAN)

下列章節一一解說這些網路類型和可用的無線技術；核心基礎結構最佳化模型把焦點放在以 WLAN 作為您的組織能夠積極控制使用者或物件驗證的唯一無線網路類型。

無線區域網路 (WLAN)

WLAN 技術能在私人區域 (例如公司辦公室或大樓) 或公共區域 (例如機場或商店) 等進行無線網路連線。WLAN 也普遍用來輔助現有的有線 LAN 環境，為 WLAN 使用者帶來更高層級的彈性，通常是以網路速度和連線可靠度作為代價。

無線個人區域網路 (WPAN)

WPAN 技術的設計是為了允許使用者視需要在個人裝置 (例如 PDA、行動電話或膝上型電腦) 之間建立無線通訊。通常這類裝置是用來在幾公尺以內的區域進行通訊，這個區域稱為個人操作空間 (POS)。

無線廣域網路 (WWAN)

WWAN 技術是用來透過分散在大片地理區 (例如城市或國家/地區) 的公用或私人網路進行無線連線。

「評估」階段的結果將列入您組織現有的 WLAN 拓撲的文件。這份拓撲會在「評估與規劃」階段之中，用來規劃最佳化安全使用者驗證的作法。

階段 2： 識別

「識別」階段主要著重於找出一種安全的方式來驗證用 WLAN 連接的裝置，以反映您在有線 LAN 基礎結構中所用的安全性等級。本章節介紹下列可提供安全的無線網路基礎結構的技術與通訊協定：

  • 使用 IEEE 802.11 的無線驗證

  • 遠端驗證撥入使用者服務 (RADIUS)

  • 可延伸驗證通訊協定 (EAP)

  • 網際網路驗證服務 (IAS)

  • 憑證

如需無線通訊協定和驗證的詳細技術指引，請參閱無線部署技術和元件概觀 (英文)。

使用 IEEE 802.11 的無線驗證

電子電機工程師協會 (IEEE) 802.11 是共用存取 WLAN 的產業標準，定義出無線通訊所用的實體層和媒體存取控制 (MAC) 副層。原始的 IEEE 802.11 標準定義出下列驗證類型，於以下各節提出說明。

開放式系統驗證

開放式系統驗證並不提供驗證，僅使用無線轉接器的 MAC 位址加以識別。開放式系統驗證是在無需驗證時使用。開放式系統驗證是運用以下程序的預設驗證演算法：

  1. 起始驗證的無線用戶端傳送 IEEE 802.11 驗證管理框架，其中含有它的身分識別。

  2. 接收的無線節點會檢查起始站的身分，然後傳回驗證確認框架。

部分無線 AP 可以用 MAC 篩選這項功能來設定所允許無線用戶端的 MAC 位址。不過，MAC 篩選功能並未提供安全性，因為無線用戶端的 MAC 位址可以輕鬆判別和偽造。

共用金鑰驗證

共用金鑰驗證能確認驗證起始站知道共用機密。依照原始的 802.11 標準，共用機密是透過與 IEEE 802.11 無關的安全通道遞送給參與的無線用戶端。實際上，共用機密是在無線 AP 和無線用戶端上以手動方式設定的。

共用金鑰驗證運用以下程序：

  1. 起始驗證的無線用戶端傳送框架，其中有身分確認和驗證要求。

  2. 進行驗證的無線節點使用挑戰字串 (Challenge Text) 來回應起始驗證的無線節點。

  3. 起始驗證的無線節點用以 WEP 加密的挑戰字串和從共用金鑰驗證機密所衍生的加密金鑰來回答進行驗證的無線節點。

  4. 如果進行驗證的無線節點判定，解密後的挑戰字串符合起初從第二個框架所傳送的挑戰字串，驗證結果就是正面的。進行驗證的無線節點會傳送驗證結果。

因為共用金鑰驗證機密必須以手動方式分送和鍵入，所以這種驗證方式無法適當擴充為大型基礎結構的網路模式 (例如，企業園區和公共場所)。

遠端驗證撥入使用者服務 (RADIUS)

RADIUS 是廣為人所部署的通訊協定，能用來進行網路存取集中化的驗證、授權和帳戶處理。RADIUS 最初是針對撥號遠端存取所開發而成的，目前已受到下列項目的支援：無線 AP、進行驗證的乙太網路交換器、虛擬私人網路 (VPN) 伺服器、數位用戶線路 (DSL) 存取伺服器，和其他網路存取伺服器。

可延伸驗證通訊協定 (EAP)

可延伸驗證通訊協定 (EAP) 最初是建立作為點對點通訊協定 (PPP) 的延伸，允許開發任意網路存取的驗證方法。若採用 PPP 驗證通訊協定，例如 Challenge-Handshake 驗證通訊協定 (CHAP)，會在連結建立階段選擇特定的驗證機制。連線驗證階段當中，會用交涉的驗證通訊協定來驗證連線。驗證通訊協定本身是依照特定順序傳送的固定訊息系列。若採用 EAP，在 PPP 連線的連結建立階段不會選擇特定的驗證機制。而是在連線驗證階段，由每個對等的 PPP 進行交涉以執行 EAP。到了連線驗證階段，由對等者交涉特定的 EAP 驗證配置的使用，稱為 EAP 類型。

網際網路驗證服務 (IAS)

Windows Server 2003 和 Windows 2000 Server 中的 IAS 是 Microsoft 實作的 RADIUS 伺服器，對於 Windows Server 2003，則是 Microsoft 實作的 RADIUS Proxy。IAS 可執行多種類型網路存取的集中化連線驗證、授權，和帳戶處理，包括無線、驗證切換、撥號與虛擬私人網路 (VPN) 遠端存取，以及路由器之間連線。IAS 能使用異質組合的無線、交換器、遠端存取或 VPN 設備，適用於 Windows Server 2003 或 Windows 2000 Server 的路由及遠端存取服務。

若以 IAS 伺服器作為 Active Directory 型網域的成員，IAS 會以 Active Directory 作為它的使用者帳戶資料庫，隸屬於單一登入解決方案的部分。同樣的一組認證也可使用於網路存取控制 (驗證與授權存取網路) 以及登入 Active Directory 型的網域。

憑證

憑證是用來向無線存取點驗證無線用戶端的。執行 Windows Vista、Windows XP、Windows Server 2003、Windows Server "Longhorn" 和 Windows 2000 Server 的無線用戶端可利用憑證來驗證電腦。

識別階段摘要

這項需求的「識別」階段與眾不同之處在於其中含有用來評估無線網路技術選項的許多面向。部分原因是所有無線網路技術所用的通訊協定與標準幾乎都是一致的。為了在安全的無線驗證方面，識別您所要的結果或需求規格，必須要瞭解標準和通訊協定。如需更多資訊，請參閱 Microsoft TechNet 的無線部署技術和元件概觀 (英文) 和無線網路安全性 (英文) 這兩份指南。

階段 3： 評估與規劃

現在，您已經識別了無線網路安全性所需要的技術與通訊協定，也開發出高階的需求規格；到了「評估與規劃」階段，您要評估能用來規劃與實作無線網路部署專案的技術。

假設合理化層級的其他需求都已經滿足，實作安全無線基礎結構的許多元件則可能都已經備妥，包括 Windows XP SP2 或更新的用戶端電腦，和 Windows 2000 Server 或更新的伺服器。

Windows Server IAS

Windows Server IAS 可為需要安全網路存取功能的組織提供下列解決方案：

  • 與下列條件的伺服器和用戶端相容：任何廠商所出品，符合 IEEE 規格 RFC 2865、2866 和 2869 的 RADIUS。

  • 與 Active Directory 目錄服務整合。IAS 讓您可以把 Active Directory 的優勢善用在使用者驗證、授權與用戶端設定上，以此降低管理成本。

  • 使用標準型強式驗證方法來進行網路存取。

  • 管理委外給 ISP 的網路存取。IAS 允許您的組織與 ISP 建立協定，讓 ISP 能向漫遊使用者的部門收取該位員工的網路費用。這樣一來，不必每位員工都提交支出明細表，或建立漫遊帳戶，就能從遠端連線到企業網路。

  • 以無線存取點的動態金鑰管理作為提高網路安全性的措施。

執行 Windows 2000 Server 的網際網路驗證服務 (IAS) 元件和 Windows Server 2003 作業系統的伺服器能夠針對多種類型的網路存取執行集中驗證、授權、稽核、和帳戶處理，包括撥號、虛擬私人網路 (VPN)、無線和 802.1x 驗證交換存取。IAS 是 Microsoft 實作的遠端驗證撥入使用者服務 (RADIUS) 通訊協定。

如需更多資訊，請參閱 Windows Server 2003 安全性指南。

Active Directory

若您將 IAS 伺服器實作成為 Active Directory 網域的成員，IAS 會以 Active Directory 目錄服務作為它的使用者帳戶資料庫，隸屬於單一登入解決方案的部分。若採取單一登入方式，使用者在驗證和授權程序中只需要提供一次帳戶認證 (使用者名稱和密碼或者是憑證)；然後這些認證就會用來登入 Active Directory 網域以及進行網路存取控制 (驗證和授權存取網路)。

規劃安全的無線網路

運用 Microsoft 技術主要有兩種無線安全性架構。一種方式是用 IPsec VPN，另一種則是用 802.1x 可延伸驗證通訊協定 (EAP)。兩者的用意都是為了保證使用者的驗證和授權，以及保護資料的機密性與完整性。

IPsec VPN 驗證

IPsec VPN 的基本結構是無線用戶端連線到開放式無線存取點 (AP)，然後使用 IPsec VPN 驗證，以便存取組織所保護的內部網路。

使用 EAP 的 802.1x 驗證

使用 EAP-TLS 與機器憑證的 802.1x 可用來驗證無線用戶端與伺服器兩者。它也能管理 WEP 金鑰，作法是定期自動傳送新的金鑰，以防範一些已知的 WEP 金鑰弱點。資料保密性可受這些動態性的 WEP 金鑰所保護。

在您建立實作計畫時，可以使用其中任何一種。如需更多資訊，請參閱 Microsoft TechNet 的無線網路安全性 (英文) 指南。

另請參閱 Microsoft TechNet 的利用 PEAP 和密碼保護無線 LAN 的安全 (英文) 和以憑證服務保護無線區域網路的安全指南。

階段 4： 部署

程序的最後一個步驟，就是在您的組織部署受保護的無線存取。如果您已經選定運用 Windows 技術的 802.1x 驗證方法，如需詳細的逐步部署指引，請參閱使用 Microsoft Windows 部署受保護的 802.11 網路指南 (英文)。

詳細資訊

如需更多 Active Directory 和 IAS/RADIUS 的相關資訊，請到下列網站：

您也可以造訪 Microsoft TechNet，然後搜尋 "IAS" 或 "RADIUS"。

若要瞭解 Microsoft 如何使用 IAS，請至 https://www.microsoft.com/technet/itshowcase/content/secnetwkperim.mspx (英文)。

檢查點： 使用 Active Directory 與 IAS/RADIUS 執行無線網路驗證與授權

需求

 

識別目前的無線存取及相關拓撲。

 

評估無線技術、通訊協定及標準。

 

開發及實作安全無線驗證基礎結構的計畫。

如果您已經完成上列步驟，則貴組織就已達到核心基礎結構最佳化模型中，「使用 Active Directory 與 IAS/RADIUS 執行無線驗證與授權」功能合理化層級的最低要求。我們建議您依照 Microsoft TechNet 上 Windows XP 無線資源 (英文) 中的其他最佳作法資源的指引進行。

移至下一個自我評估問題。

需求： 集中化管理憑證服務

對象

如果您目前沒有集中管理的憑證服務基礎結構或公開金鑰基礎結構 (PKI)，請閱讀本章節。

概觀

電腦網路已不再是僅憑使用者的存在便足以證明身分的封閉系統。在這個資訊互連的年代，組織的網路可能由內部網路、網際網路站台和外部網路所組成，這些全都容易遭受惡意人士的入侵，從電子郵件到電子商務交易當中尋找各種資料檔案。為了降低這種可能性所帶來的風險，必須要有建立與維持使用者身分識別的機制。集中管理的電子式使用者身分識別具有下列功用：

  • **資訊的可存取性。**資訊資產必須可供有授權的使用者存取，並且防止未經授權者加以存取或修改。密碼有助於防範未經授權的存取，但使用者若為了存取不同的安全系統而有多組密碼，可能會選用易記的密碼，結果容易遭人破解。

  • **身分的不可否認性。**資訊必須在信任資訊的傳送者有效之下，在使用者之間傳送。也必須提供合理的信賴，相信資訊在途中未經竄改。

  • **資訊的私密性。**使用者傳送資訊給其他使用者或存取電腦系統時，應該能夠放心地相信他人無法存取或得到這些資訊。使用者或系統應該要能夠定義哪些人員可存取資訊。資訊透過公用的網際網路傳送時，私密性顯得格外重要。

這些需求可處理電子資訊資產，對大多數的組織具有直接的影響。為了處理這些需求所實作的機制，都必須具備可管理性與安全性。公開金鑰基礎結構 (PKI) 搭配數位憑證的使用，是滿足這些需求的適當技術。PKI 可用來在通過驗證的實體與信任的資源之間交換數位憑證。PKI 中的憑證可用來保護資料安全，管理組織內外的資源識別認證。顯然 PKI 本身必須受到信任，因此它是由預審通過的組織或這類組織的一部分所管理的。這樣的組織可稱為憑證授權 (CA)，但通常只要是執行憑證軟體的電腦便可稱為 CA。無論 CA 是指組織還是支援憑證的軟體，都由 CA 負責建立憑證持有人的身分與開立憑證。如果憑證失效，它也能加以撤銷，並且發佈憑證撤銷清單 (CRL) 供憑證驗證者判斷憑證是否有效。

本指南採用 Windows Server System 參考架構的憑證服務 (英文) 指南所記錄的最佳作法。

階段 1： 評估

在「評估」階段，您要檢視網路環境目前的狀態。這個「評估」階段與合理化層級中，「伺服器之間的通訊驗證安全而有保障」需求的「評估」階段相同。要在組織中獲取並維護所有電腦、軟體、網路裝置的可靠記錄，一直都是 IT 領域的常見課題。為了定義目前的狀態，需要有下列項目的資訊：

  • 網路搜索

  • 記載網路分割

  • 網路基礎結構裝置

  • 分析目前網路流量模型

  • Active Directory

  • 主機探索

  • 主機資料的需求

如需更多收集這些資訊的詳細資訊，請參閱使用 IPsec 和群組原則執行伺服器和網域隔離指南的第 3 章： 確定您目前的 IT 基礎結構狀態 (英文)。本指南探討每個項目的需求，及如何使用 SMS 2003 (英文) 或類似產品透過自動化的探索功能以及手動探索選項，來收集資訊。

階段 2： 識別

「識別」階段當中，我們要定義建立集中化公開金鑰基礎結構的高階需求。當組織決定實作 PKI 時，必須先識別業務問題之後再展開設計階段。設計階段的第一步是先識別對人員、程序和技術的考量事項。主導 PKI 服務需求的問題包括下列項目：

與人員相關的問題：

  • 人員處理憑證的方式？

  • 由誰管理憑證？

  • PKI 如何影響使用者的工作體驗？

  • 組織的規模多大？

與程序相關的問題：

  • PKI 應成為組織 IT 基礎結構的部分，還是要由外部來源購買憑證？

  • 憑證是否也用於外部交易？

  • 註冊憑證要套用什麼程序？

  • 組織與相關實體之間如何建立與確認信任？

  • 確認信任的間隔時間？

  • 哪些限制會影響憑證的效力？

  • 信任一旦取消，撤銷相關憑證有多迫切？

與技術相關的問題：

  • 哪些類型的實體需要憑證，以及用於何種用途？

  • 目錄服務對哪些用途有利？

  • 憑證中需要包含哪些資訊？

  • 哪些應用程式具有 PKI 功能？

  • 公開/私密金鑰有多複雜，具有 PKI 功能的應用程式是否能支援這樣的複雜性？

組織安裝第一部 CA 伺服器之前，必須先有涵蓋人員、程序與技術的完整 PKI 服務設計研究存在。長期看來，延伸實作不良的 PKI，比起先期花時間規劃可延伸的 PKI，管理上更為不易，並且成本較高。如需更多識別 PKI 高階需求的相關資訊，請參閱企業設計憑證服務的 WSSRA 藍圖 (英文)。

階段 3： 評估與規劃

「評估與規劃」階段中，我們要來檢查 PKI，並且規劃部署基礎結構所需要的步驟。

什麼是 PKI？

許多需要實作安全網路的技術都要求具備 PKI，它可用來在通過驗證的實體與信任的資源之間交換數位憑證。PKI 中的憑證可用來保護資料安全，管理組織內外的資源識別認證。設置 PKI 之後，許可的主體就能向 CA 所管理的憑證註冊服務索取憑證。CA 會判定憑證要求者的效力，再回應要求，核發有效的憑證。憑證持有者可以一直使用憑證到過期或者撤銷為止；至於憑證是否可以信任，則是依照憑證要求者與核發的 CA 之間的信任品質來決定。依照預設，由兩個不同的 CA 所核發的兩份使用者憑證，彼此之間並不具有信任的狀態。核發的 CA 之間必須共同信任，才能確保憑證相互受到信任。

具有 PKI 功能的用戶端會用憑證來判定給定資源的信任層級。為了確保這一點，PKI 需要有確認機制來檢查憑證是否有效。Windows Server 2003 PKI 會提供 CRL 作為確認機制，技術上而言，用戶端也能透過一些通訊協定來擷取 CRL。依照用戶端的功能與網路的基礎結構，可能使用某種通訊協定是較佳的作法，這樣的通訊協定例如有：

  • HTTP 和安全 HTTP (HTTPS)。 HTTP 和 HTTPS 適用在 CRL 使用 Web 伺服器發佈的情形。這些通訊協定常用來讓 CRL 可供組織網路外部的實體存取。

  • LDAP。 從目錄服務透過 LDAP 存取 CRL 時，需要的頻寬會比透過 HTTP 存取同一個 CRL 更多，因為依照預設 LDAP 會要求驗證。即使以匿名存取的方式來擷取 CRL，LDAP 仍會傳送匿名驗證的標頭。如果內外都需要有 CRL 可以使用，可能難以透過 LDAP 提供目錄存取功能給所有的用戶端。

PKI 架構

PKI 的架構要求實作各種相互依存的技術與程序，才能夠核發、驗證、更新和撤銷憑證。這些技術包括：

  • 執行憑證服務的一或多部伺服器，以提供憑證註冊、撤銷和其他憑證管理服務。

  • Active Directory 目錄服務或提供帳戶管理、原則發佈，和憑證發行服務的另一種目錄服務。

  • 使用者或電腦要求憑證時，可驗證該使用者或電腦的網域控制站。

  • 為特定目的而要求、接收和使用憑證的網域用戶端電腦。雖然服務和非網域用戶端也能使用憑證，但在大多數的 Windows PKI 環境中，還是以網域使用者和電腦為憑證的主要接收者和使用者。在部分情況下，網域用戶端可以是附屬的 CA，可要求和接收憑證‧，授權其核發本身的憑證。

下圖所示為 PKI 技術的架構。

圖 11. PKI 技術的架構

圖 11. PKI 技術的架構

這種類型的 PKI 實作可讓您集中掌控憑證服務。

規劃 CA 基礎結構和 PKI 實作

CA 基礎結構的選擇如何，須取決於組織在於安全性與憑證的需求、PKI 的用途，以及應用程式、使用者與電腦的需求。

如同前文所述，憑證的需求對於 PKI 的設計具有直接的影響。PKI 的邏輯設計可以在 PKI 服務定義完成之後隨即進行。如需為組織規劃公開金鑰基礎結構的詳細技術指引，請參閱企業設計憑證服務的 WSSRA 藍圖 (英文)。

階段 4： 部署

公開金鑰的設計經過實驗室測試與試驗計畫的改良之後，即可將 PKI 部署到您的生產環境當中。以精良的方式來部署 PKI，是為您所要啟用的應用程式奠定安全性的基礎。下圖所示為高階的 CA 基礎結構和 PKI 部署程序。

圖 12. 高階的 CA 基礎結構和 PKI 部署程序

圖 12. 高階的 CA 基礎結構和 PKI 部署程序

如需 CA 基礎結構和部署 PKI 的詳細技術資訊，請參閱：

詳細資訊

如需詳細資訊，請造訪 Microsoft TechNet，然後搜尋 "PKI"。

若要瞭解 Microsoft 如何部署 PKI，請至 https://www.microsoft.com/technet/itshowcase/content/deppkiin.mspx (英文)。

檢查點： 集中化管理憑證服務

需求

 

執行網路探索以清查所有元件。

 

識別有關憑證授權和公開金鑰基礎結構方面中對於人員、程序和技術的設計考量。

 

建立詳細的部署計畫以啟用 PKI。

 

實作 PKI 部署計畫。

如果您已經完成上列步驟，則貴組織就已達到核心基礎結構最佳化模型中，「集中化管理憑證服務」功能合理化層級的最低要求。我們建議您依照有關憑證服務的其他最佳作法資源的指引進行。

移至下一個自我評估問題。

需求： 主動管理分公司頻寬

對象

如果您目前並未主動管理分公司的頻寬，請閱讀本章節。

概觀

您若必須為組織的總部和分公司建立安全高效的通訊功能，這時就會面臨廣域網路 (WAN) 頻寬有限的問題。有許多措施可以讓您以最高效的方式運用頻寬。實體網路基礎結構的設計對於您的分公司與集線器站台基礎結構的其他服務與元件具有重大的影響。網路的效能與可用性決定了服務是否能適當地支援使用者在於透過 WAN 存取服務的需求。

本指南內容是以 Microsoft Windows Server 2003 Release 2 (BOIS R2) 分公司基礎結構解決方案 (英文) 中所發佈的指引作為依據。

階段 1： 評估

下列章節探討您在「評估」階段所要進行的活動。

記錄網路設計

判定如何最佳化組織中 WAN 頻寬的第一個步驟，就是把組織目前的分公司網路設計作成正式記錄。分公司網路設計主要有兩種： 單一集線器與多重集線器。

單一集線器網路

單一集線器網路中，集線器站台直接連線到多個遠端站台。這是組織擁有多處分公司，但分公司的業務功能幾乎完全相同，並且在同一國家或較小地區的邊界以內營運者的常見 WAN 結構。下圖所示為內有單一集線器站台的網路結構範例。

圖 13. 單一集線器網路

圖 13. 單一集線器網路

多重集線器網路

多重集線器網路一般至少提供三層的網路連線。這是分公司眾多，且業務功能分歧的大型或跨國企業所常用的結構。這種 WAN 結構通常在企業總部會具備一個中央集線器站台，而每個地理區又各一個集線器站台。下圖所示為內有一個中央集線器站台，和兩個區域性集線器站台的網路結構範例。

圖 14. 多重集線器網路

圖 14. 多重集線器網路

如果分公司連接到其他分公司，多重集線器網路可以再繼續擴充。遇到這種情形，務必要決定第二層站台可用的服務。第二層站台可用的選擇包括下列幾種：

  • 本機設置與第一層分公司相同的服務集。

  • 本機提供更多服務 (因為網路可用性、容量或效能不足)。

  • 本機提供較少服務，倚賴集線器站台提供服務。

「評估」階段的第一個步驟，是將組織針對分公司和集線器基礎結構的網路設計作成正式記錄。

將 WAN 連結作成正式記錄

「評估」階段的下一個步驟，是把所有站台之間的 WAN 連結作成正式記錄。把分公司連線到集線器站台的網路連結，是 WAN 的關鍵元件。WAN 連結對於需要透過 WAN 存取的服務可用性而言具有重大影響。在探索程序中必須判定下列資訊：

  • 連結類型。這是網路速度、網路負載支援和網路可用性的主要決定因素。連結類型包括連線是否永久 (例如租用線路) 或隨選 (例如撥號和 ISDN)，以及使用的通訊協定 (例如虛擬私人網路，或稱 VPN、框架轉接或衛星)。

  • 連結頻寬。理論上為連結的最大速度，但實際速度會受到網路延遲的限制。

  • 連結延遲。網路封包從一處到另一處所花的時間，對於交易 (來回) 所需最短時間 (延遲量) 會構成限制。

  • 連結容量。理論上為透過網路連結可以推送的彙總資料量。與連結速度密切相關。

  • 連結使用率。以連結總容量的百分比來表示。使用率內含所有網路流量，包括監視與管理網路與服務所需的背景交易、使用網路的其他個別服務與應用程式，和倚賴網路的特定功能 (例如，保全攝影機/系統和 VoIP)。

分公司的網路分割

最後一個階段是要評估分公司的網路分割，和若要以最適當的方式支援新解決方案中的服務，會有哪些需求。

分公司的內部網路傳統上會是單一分割網路，也稱為平面網路。這種類型的網路可用簡易的 IP 計畫提供單純並且實惠的基礎結構。如果您組織的分公司併用單一或多重分割網路，應該列入評估當中的正式記錄。

其他網路設計考量

除了網路連結之外，每個分公司也需要能夠支援分公司內所有使用者和內部連線需求的網路基礎結構。分公司基礎結構與其他網路元件的更多相關設計考量包括下列項目：

  • 集中化服務的位置

  • 本機網際網路存取

  • 安全性的影響

  • 路由的限制

  • 網路位址轉譯 (NAT)

評估摘要

這個步驟的結果應該能夠產生詳細的試算表或者拓撲圖表，列出所有這些項目如何與第一個步驟中所正式記錄的網路設計相互關聯。如需更多資訊和評估方面的其他考量，請參閱 BOIS R2 指南中的實體設計 (英文)。

階段 2： 識別

「識別」階段的目標在於判定適合您組織需求的效能層級。大多數情況下，提高效能難免需要增加成本。在這個階段中，務必要衡量每個效能層級的成本與優勢。

WAN 的類型與特性分歧，因此關於哪些 WAN 連線對您的組織來說最為適合，無法提供具體的建議。然而，基於各種群組所收集的客戶資料，可歸納出三種網路連結的情況。高、中和低效能。下表所示為這幾種效能情況的特性，以及個別的可能應用：

  • 高效能。衛星分公司通常需要高效能的連結 (依照地點需要至少每秒 1.544 或 2 MB，或單位以 Mbps 表示)、低延遲，和高可用性。一般是在北美與許多西歐等等國家境內比較常見。比起其他情形，這種類型的網路連結可讓組織把更多的服務集中到集線器站台，單只因為集中移動服務所降低的管理成本，便足以超過提供充分可用性的成本。此外，容量與延遲的情形也好到不致於對使用者的生產力造成負面影響。在部分情況下，甚至於可能因為應用程式而提高生產力。例如，集線器站台上存取後端儲存區 (例如資料庫或大型主機電腦) 的應用程式，可能因為移到中央站台的應用程式陣列以及使用終端機服務加以存取，因此獲得益處。理由在於最密集的交易不必透過 WAN 執行，高容量的 WAN 即可用來支援使用者存取應用程式所需的效能層級。

  • 中等效能。加速分公司一般可以使用中等效能的連結 (每秒 128–512 kb，或單位以 Kbps 表示)、中等延遲，與良好的可用性。這類情形一般是分佈在沒有較為先進電信基礎結構的地理位置，或者需要大幅跨越地理邊界的情形。如果低頻寬需求的服務沒有不能集中化的設定或其他限制，這種連結可能支援具有低頻寬需求的服務集中化 (例如 DNS 和 Active Directory)。然而，網路連結的可用性可能不足以確保留在分公司的服務 (例如檔案與列印服務) 能存取進行名稱解析、驗證與授權所需要的集中化服務。此外，若使用終端機服務來存取集中式應用程式，這種連結的延遲可能會讓使用者無法接受。

  • 低效能。自發的分公司通常可利用效能較低的連結 (例如低於 128 Kbps 的連結)、高延遲和較能容忍連結不可靠的方式來運作。這種情形通常發生在電信業明顯尚未開發，或者實際取得效能較高和可用度更高的網路連結成本令人卻步 (例如連接極度偏遠地區的單一分公司) 的地區。使用這種類型的連結不容易走向服務的集中化。但這種方式確實能夠簡化分公司的設計，因為支援分公司業務關鍵功能的所有服務以及這些服務所倚賴的服務，都必須位在分公司本地。

「識別」階段的結果是針對每個連結的理想效能結果產生詳細的分析與建議，以判定每家分公司的歸類方式： 衛星、加速或自發。

階段 3： 評估與規劃

直至目前為止，您都在把分公司基礎結構的網路拓撲和理想的效能需求列入正式記錄。到了「評估與規劃」階段，您要評估將服務集中化相對於本地化的影響，建立管理 WAN 連結的計畫，以滿足效能需求。

評估實體伺服器設計

分公司的基礎結構設計一般會把焦點放在盡可能集中化多數服務的作業。雖然可能會以集中化所有服務作為長期目標，但要把它當作短期解決方案，往往並不可行。理由在於，要使分公司的用戶端電腦與具有適當可用性、容量與延遲水準的集線器站台內的服務之間建立連線功能，恐怕並不合乎成本考量。如果目前技術的狀態無法支援特定服務的集中化，精簡分公司設計的用意通常是把留在分公司的服務全部合併到單一伺服器上。這種作法可能具有挑戰性，但某些情形下是可以達成的。

並非特定為單一服務且應該套用到所有服務的設計考量類型，包括下列幾種：

  • 可用來精簡分公司基礎結構的設計選擇。

  • 分支服務位置的考量，包括服務位置對於人員與程序、以及對企業本身一般的含意。

  • 其他設計考量，尤其是關於使用者與業務功能，非屬服務位置特定者。

分公司基礎結構的設計選擇

定義分公司的基礎結構時，需要分析將集中服務與本地部署的選擇和意涵。您為每個分公司所必須作出的這兩項基本決定，都要求評估許多設計上的選擇。

服務集中化的選擇

可用於服務集中化的選擇，主要包括下列服務執行方式：

  • 只在分公司執行 (無需容錯移轉)。

  • 若有複寫功能，則在分公司執行，並且容錯移轉至集線器站台。

  • 只在集線器站台執行。

分公司伺服器的設計選擇

無法合併到一或多部分公司伺服器來加以集中化的服務，還是可以進行精簡作業。分公司伺服器的設計應當把重點放在如何使每家分公司的軟硬體與支援使用情形 (包括人力資源的運用) 達到最佳狀態。

適用於整合與移轉 LOB 應用程式的解決方案加速器 (英文) 與混合工作負載整合指南 (英文) 中有判定哪些應用程式可以合併的詳細指引。適用於整合與移轉 LOB 應用程式的解決方案加速器 (英文) 也有針對不適於整合的應用程式識別出適當的解決方案指引。

下表摘述在分公司站台執行應用程式的主要選擇：

  • 單一伺服器整合

  • 服務整合

  • 虛擬化整合

  • 專屬伺服器

您為每項服務所作的選擇，可決定所需的分公司伺服器數量。

分公司服務位置的考量

每個組織都有自己的一套優先順序來決定哪些需求最為重要，這也決定了有哪些對於分公司基礎結構解決方案的設計影響最大。在專案構思階段的早期分析過程中，您應該已經識別了影響服務位置的技術、業務與其他方面的需求和限制。

您需要用這份資訊來高效評估每家分公司服務可以有的選擇和利弊得失，包括下表所列的一般設計考量和特定服務的設計考量：

  • IT 組織

  • 政治考量

  • 法律與規範考量

  • 安全性

  • 可用性與可靠度，包括：

    • 服務的集中化

    • 分公司伺服器上服務的整合與聯合控管

    • 分公司的無備援伺服器

    • 分公司服務的備援

    • 當地服務的單一伺服器，含服務的本機備援和 Windows 叢集  

  • 備份和復原

  • 效能和容量

  • 延展性

  • 成本

規劃分公司的服務

BOIS R2 引入新的設計技術，供您以一般並且可以複製的方式來進行組織的基礎結構服務設計，無論是針對分公司或其他 IT 服務皆可適宜。這項技術使用服務設計參照 (SDR) 圖與三種基礎設計元素來表示每項服務的設計程序。這些元素是：

  • 設計階段

  • 設計考量

  • 設計選項

下圖所示為針對這種設計方式，表現出其中元素的通用版本服務設計參照。

圖 15. 通用版本的服務設計參照

圖 15. 通用版本的服務設計參照

在每一個設計階段，請運用考量與選擇來判定輸入的設計是否滿足新設計的需求，以及模型經過修改之後能否符合所要的新需求。

核心分公司服務須要加以詳細規劃，以確保 WAN 頻寬使用方式達到最佳成效。這些服務所以稱為「核心服務」，是因為能作為分公司環境的基本基礎結構，之後再加以強化或延伸，即可提升解決方案的功能。這些核心服務有：

  • 目錄服務

  • 網路定址和名稱解析服務

  • 檔案服務

  • 列印服務

  • 核心用戶端服務

  • 核心管理服務

如需更多有關設計分公司核心服務的資訊，請參閱 BOIS R2 中的核心分公司服務設計 (英文)。

分散式檔案系統

Windows Server 2003 R2 中的分散式檔案系統 (DFS) 技術能提供適合 WAN 的複製，以及簡化的容錯存取位置分散的檔案功能。DFS 中的這兩項技術是：

  • DFS 複寫。新的狀態型多主機複寫引擎，已針對 WAN 環境進行最佳化處理。DFS 複寫可支援複寫排程、頻寬節流，和新的位元組層級壓縮演算法，稱為遠端差異壓縮 (RDC)。

  • DFS 命名空間。這項技術能協助系統管理員把位在不同伺服器的共用資料夾分組，以名為命名空間的虛擬資料夾樹狀結構提供給使用者。DFS 命名空間在 Windows 2000 Server 和 Windows Server 2003 中原名為「分散式檔案系統」。

評估與規劃摘要

沒有一種單一步驟或建議可普遍適用於每個組織的 WAN 頻寬最佳化處理作業。每個組織對於管理本身的 WAN 都有獨特的考量。「評估與規劃」階段之後，接著的目標是識別有無合併服務的機會存在，並且更加瞭解您目前的網路拓撲，以便積極管理 WAN 頻寬。

階段 4： 部署

為分公司識別出適當的架構，以及集中相較於本地化服務的平衡點之後，為了最佳化 WAN 連結的限制，到了「部署」階段，就要實作從分公司規劃與架構設計所得到的建議。舉例而言，依照所得到的建議，「部署階段」可能導向服務的進一步集中化；隨著這些變化，也要適當地調整 WAN 連結。部署程序的過程當中，可以撰寫成為標準原則，依照適當的時間間隔，或對應於預設的資料、效能或員工閾值，重新檢視 WAN 連結的需求與分公司的基礎結構。   

詳細資訊

如需更多資訊，請造訪 Microsoft TechNet，然後搜尋「頻寬管理」。

若要瞭解 Microsoft 如何管理 WAN 頻寬，請至 https://www.microsoft.com/technet/itshowcase/content/optbwcs.mspx (英文)。

檢查點： 主動管理分公司頻寬

需求

 

識別及記錄分公司拓撲。

 

根據所有分公司類型的需求建立需求規格。

 

建立適用於分公司服務整合的計畫和架構，並識別重新調查分公司 WAN 需求的效能閾值。

 

實作計畫以根據 WAN 連線限制，最佳化分公司服務。

如果您已經完成上列步驟，則貴組織就已達到基礎結構最佳化模型中，「主動管理分公司頻寬」功能合理化層級的最低要求。我們建議您依照有關頻寬管理的其他最佳作法資源的指引進行。

移至下一個自我評估問題。