 TechNet Magazine June 2007

TechNet Magazine June 2007

安全性: 深入探索 Windows Vista 使用者帳戶控制

使用者帳戶控制 (簡稱 UAC) 是 Windows Vista 中最容易令人誤解的新功能之一。但其目標是讓使用者能以標準使用者權限執行，卻可解決許多安全性問題。本文將深入探索 UAC 的設計所要解決的問題，並解說這項新功能確切的運作原理。

Mark Russinovich 安全性: 使用 BitLocker 磁碟機加密保護資料的關鍵

BitLocker 有兩個非常重要的用途：提供完整磁碟區資料加密，及提供方法於 Windows Vista 啟動前驗證早期啟動元件的完整性。概要瞭解 BitLocker 的運作原理，及其如何協助保護您的組織。

Byron Hynes 安全性: 探索 Windows 防火牆

行動性改變了電腦受威脅的型態，以及防範各種威脅的技術。經常帶著膝上型電腦外出四處奔走又再重返網路的您，需要有更完善的方法來保護您的系統。本文將探索如何利用 Windows 防火牆，保護您的電腦在網際網路和您自己內部網路上的安全。

Steve Riley 安全性: Windows Vista 全新的 ACL 改善安全性

儘管 ACL 沒有發生大變革，但有些重要變更是在 Windows Vista 環境中管理 ACL 時的須知。探索 30 個 ACL 如何改變以改善安全性、瞭解對組織的影響，並學習如何在基礎結構中管理新 ACL。

Jesper Johansson 安全性: 透過群組原則管理硬體限制

USB 隨身碟和其他卸除式裝置會讓您的私人生活更輕鬆，但專業生活更困難。為加強安全性，您需要方法來控制使用者在工作系統上安裝哪些硬體裝置。現在，您可以使用群組原則，控制哪些裝置是他們可用、哪些是無法使用的。

Jeremy Moskowitz 安全性: 每個 IT 組織必須擁有的 4 項安全性技術

大部分公司都有類似的安全性問題。在今天的網路世界，有四大類型的安全性工具是每個組織絕對必須擁有的。瞭解這些工具為何，並探索相關技術可能的合作方式，以便在未來建立理想的安全性解決方案。

Matt Clapham and Todd Thompson 安全性: 強大的憑證管理新工具

憑證是基礎結構中的主要元件，一旦過期就會導致生產力停滯。如果您仰賴 Microsoft PKI 環境，新的 Identity Lifecycle Manager 憑證管理 (ILM-CM) 方案將可協助您順利執行各項作業。瞭解此工具如何協助您改善驗證程序與降低憑證管理成本。

Kevin Dallmann 編輯的話: 安全性問題

Joshua Trupin 工具箱: 適合 IT 專家的新產品

Greg Steen SQL 問題與解答: 64 位元安裝、配置叢集記憶體等等

Edited by Nancy Michell 公用程式焦點: Script Elevation PowerToys for Windows Vista

儘管使用者帳戶控制為安全性帶來重大改進，提升權限仍是完成某些系統管理工作和功能不可或缺的要素。本文介紹的幾個 Elevation PowerToy 將可助您更健全而靈活地提升權限。

Michael Murgolo The Cable Guy: 安全通訊端通道通訊協定

Windows XP 和 Windows Server 2003 中的 VPN 通訊協定不適用於某些組態。深入瞭解各種問題現象，以及 Windows Server "Longhorn" 和 Windows Vista Service Pack 1 如何運用安全通訊端通道通訊協定來解決這些問題。

Joseph Davies Windows PowerShell: 使用 Active Directory

Windows PowerShell 未提供 Get-ADSIObject cmdlet，但不代表它未提供強大的 ADSI 支援。請參閱型別配接器的簡介，瞭解如何使用 Windows PowerShell 來處理目錄物件。

Don Jones 嗨，Scripting Guy！: 移除紅色彎曲線的指令碼

您在尋找將詞彙加入 Microsoft Word 字典更輕鬆的方法，來取代每次逐字手動加入的方式嗎？大家都是這樣吧？這個月，Scripting Guy 將說明如何在 Microsoft Word 中建立自訂字典，以及如何用程式設計方式設定 Word 以使用這些字典。

The Microsoft Scripting Guys 桌面檔案: 如何不遺失資料

重要資料經常遺失，次數之多令人驚訝。但事實是，由於人們未善盡保護之責，而遺失資訊。請探索您可以而且必須採取的重要步驟來保護組織的資料。

Wes Miller 現場筆記: 與開發人員溝通

讓開發人員建立更易於管理的應用程式的方式比您想像的更容易。一切由溝通開始。開發人員看待軟體的角度與系統管理員不同。與開發人員溝通，系統管理員可以解釋什麼是重要的，而且開發人員可以根據這些資訊設計程式碼，得到更好的成果。

David Aiken Windows 機密文件: 新使用者的開始功能表項目

試想如果有人買了新電腦，啟動 Windows 之後按 [開始] 按鈕卻看到空無一物的功能表，到時絕對會一頭霧水。[開始] 功能表之所以主動在未曾用過的系統上最常用的位置添加應用程式，無非是要提供令人愉悅的全新體驗。請看這些應用程式到底是如何挑選出來的。

Raymond Chen 回信: 解答


 安全性: 深入探索 Windows Vista 使用者帳戶控制
安全性 Mark Russinovich

深入探索 Windows Vista 使用者帳戶控制
摘要:
  • 以標準使用者身分執行
  • 檔案及登錄模擬
  • 提升帳戶狀態

使用者帳戶控制 (UAC) 是 Windows Vista 中常被誤解的一項功能。我在前三篇 TechNet Magazine 的 Windows Vista 核心變更系列文章中 (網址為 technetmagazine.com) 並未談到 UAC，因為我認為這個主題應以專文來討論。
在本文中，我將討論 UAC 所要解決的問題，並說明其元件技術的架構與實作。這些技術包括：重整原本需要系統管理權限才能執行的作業、輕量型模擬以使程式即便沒有系統管理權限也能正常執行、讓程式能夠明確要求系統管理權限，以及隔離同一個使用者桌面上執行的系統管理處理程序與非系統管理處理程序。

UAC 的目標
UAC 的用意是讓使用者能以標準使用者權限執行，而非以系統管理權限執行。系統管理權限讓使用者得以讀取及修改作業系統的任何部分，包括其他使用者的程式碼和資料，甚至 Windows® 本身。不具備系統管理權限將可避免使用者不小心 (或故意) 修改系統設定、防止惡意程式變更系統安全性設定或停用防毒軟體，並遏止使用者入侵共用電腦上其他使用者的機密資訊。因此，以標準使用者權限執行便能減少企業環境尋求支援部門緊急協助的次數、緩和惡意程式的影響程度、讓家用電腦執行更順暢，及保護共用電腦上的機密資料。
UAC 必須解決幾個問題，方能確實以標準使用者帳戶身分執行。首先，Windows Vista™ 之前的 Windows 版本均假定為系統管理權限使用模型。軟體開發人員假定其程式可以存取及修改任何檔案、登錄機碼或作業系統設定。即使 Windows NT® 引進了安全性，並已區別授與系統管理帳戶和標準使用者帳戶的存取權，使用者仍被倡導使用內建 Administrator 帳戶或 Administrators 群組成員的帳戶來逐步執行安裝程序。
其次，UAC 必須解決的問題在於，使用者有時候需要具備系統管理權限才能執行若干作業，例如安裝軟體、變更系統時間，以及開啟防火牆上的連接埠。
UAC 解決這些問題的方法是以標準使用者權限執行大部分的應用程式，而不需要總是仰賴系統管理權限，並鼓勵軟體開發人員建立以標準使用者權限執行的應用程式。為了達成這些目的，UAC 會盡量減少對系統管理權限的需求、使舊版應用程式能以標準使用者權限執行、讓標準使用者能在需要時便於存取系統管理權限，甚至讓系統管理使用者仿照標準使用者身分來執行。

以標準使用者身分執行
Windows Vista 在開發階段針對所有系統管理作業進行全面稽核時，發現許多作業皆可啟用交由標準使用者執行而不會危及系統的安全性。例如，就連 Windows XP 桌面系統採用標準使用者帳戶的企業也無法從 Administrators 群組移除出差在外的使用者，主要原因在於 Windows XP 並未區別變更時區和變更系統時間。膝上型電腦使用者出差在外時，如需設定當地時區以使行事曆正確顯示約會，則必須具備「變更系統時間」權限 (內部稱為 SeSystemTimePrivilege)，而此權限預設僅授與系統管理員。
時間通常應用在安全性通訊協定如 Kerberos，但時區只會影響時間的顯示方式，所以 Windows Vista 新增了「變更時區」權限 (SeTimeZonePrivilege)，並將此權限指派給 Users 群組，如 [圖 1] 所示。這使得多數企業能放心讓膝上型電腦使用者以標準使用者帳戶執行。
[圖 1] 「變更時區」權限
[圖 1] 「變更時區」權限
Windows Vista 也允許標準使用者在連線到無線網路時設定 WEP 設定、建立 VPN 連線、變更電源管理設定，以及安裝 Windows 重大更新。此外，它還引進了幾項群組原則設定，讓標準使用者能夠安裝 IT 系統管理員核准的印表機和其他裝置驅動程式，及從系統管理員核准的網站安裝 ActiveX® 控制項。
那麼，無法由標準使用者帳戶順利執行的家用及特定業務 (LOB) 應用程式又該如何？儘管某些軟體理應需要系統管理權限，多數程式其實無須將使用者資料儲存在系統通用位置。Microsoft 建議全域應用程式安裝程式若要以系統管理權限執行，應在 %ProgramFiles% 目錄下建立目錄來儲存應用程式可執行檔及輔助資料，並在 HKEY_LOCAL_MACHINE\Software 下建立機碼存放應用程式設定。應用程式每次執行時，都能由不同的使用者帳戶執行，繼而將使用者專屬資料儲存至每位使用者的 %AppData% 目錄，並在 HKEY_CURRENT_USER\Software 下的使用者登錄設定檔中存放每位使用者的設定。標準使用者帳戶對 %ProgramFiles% 目錄或 HKEY_LOCAL_MACHINE\Software 不具備寫入存取權，但因大部分的 Windows 系統均為單一使用者，且多數使用者及至 Windows Vista 問世前都曾是系統管理員，應用程式若未正確將使用者資料和設定儲存在這些位置仍能正常運作。
Windows Vista 藉由檔案系統及登錄命名空間模擬的輔助，使這些舊版應用程式能以標準使用者帳戶執行。應用程式如果修改檔案系統或登錄中的系統通用位置，卻因存取遭拒以致作業失敗，Windows 便將作業重新導向到每位使用者區域；當應用程式從系統通用位置讀取時，Windows 會先檢查每位使用者區域內的資料，一旦找不到則允許嘗試從通用位置讀取。
為了達到這種模擬目的，Windows Vista 將 32 位元處理程序 (相對於 64 位元) 視為舊版，無法以系統管理權限執行，且並無資訊清單檔案指出其為針對 Windows Vista 所撰寫。只有依此定義而被歸類為舊版的處理程序所要求的作業 (包含網路檔案共用存取) 才會模擬化。處理程序的模擬狀態係儲存在權杖中做為旗標，此核心資料結構會追蹤處理程序的安全性內容，包括處理程序的使用者帳戶、群組成員資格和權限。
若要查看處理程序的模擬狀態，您可以在 [工作管理員] 的 [處理程序] 頁面上加入 [模擬] 欄。如 [圖 2] 所示，大部分的 Windows Vista 元件都已停用模擬，包括桌面視窗管理員 (Dwm.exe)、用戶端伺服器執行時子系統 (Csrss.exe) 和檔案總管，因為這些元件具有 Windows Vista 資訊清單或是以系統管理權限執行，故而不允許模擬。Internet Explorer® (iexplore.exe) 則會啟用模擬，因為此元件可裝載多個 ActiveX 控制項和指令碼，而必須假定這些項目在撰寫上未必能以標準使用者權限正確運作。
[圖 2] [工作管理員] 顯示模擬狀態
[圖 2] [工作管理員] 顯示模擬狀態
舊版處理程序的模擬化檔案系統位置為 %ProgramFiles%、%ProgramData% 和 %SystemRoot% 且排除若干特定子目錄。不過，副檔名代表執行檔 (如 .exe、.bat、.scr、.vbs 等) 的任何檔案都將排除模擬。這表示由標準使用者帳戶自行更新的程式將會失效，而非建立私用版本的執行檔導致執行通用更新程式的系統管理員無法察覺。若要將其他副檔名新增至例外清單，請在下列登錄機碼中輸入後重新開機：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
使用多字串類型來分隔多個副檔名，而且副檔名開頭不要加上句號。
舊版處理程序對模擬化目錄所做的修改會重新導向到使用者的虛擬根目錄，即 %LocalAppData%\VirtualStore。例如，假設我的系統上執行的模擬化處理程序建立了 C:\Windows\Application.ini，實際建立的檔案則是 C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini。路徑中的 Local 突顯出如果帳戶有漫遊設定檔，模擬化檔案並不會跟隨設定檔的其餘部分漫遊。
如果您在檔案總管中瀏覽到包含模擬化檔案的目錄，檔案總管的工具列上就會出現 [相容性檔案] 按鈕，如 [圖 3] 所示。按下這個按鈕後，您將被導覽到對應的 VirtualStore 子目錄，這樣就能看到模擬化檔案。
[圖 3] [相容性檔案] 按鈕表示模擬化檔案就在附近
[圖 3] [相容性檔案] 按鈕表示模擬化檔案就在附近
[圖 4] 顯示 UAC 檔案模擬篩選器驅動程式 (%SystemRoot%\System32\Drivers\Luafv.sys) 如何實作檔案系統模擬。這是一個檔案系統篩選器驅動程式，因此能夠看見所有檔案系統作業，但只會針對源自舊版處理程序的作業實作功能。如您所見，對於在系統通用位置上建立檔案的舊版處理程序，驅動程式會變更其目標檔案路徑，但對於以標準使用者權限執行 Windows Vista 應用程式的處理程序卻不會這麼做。舊版處理程序真正建立檔案的地方是使用者完全可存取的位置，所以作業成功；然而 \Windows 目錄的預設權限其實是拒絕存取針對 Windows Vista 撰寫的應用程式。
[圖 4] 檔案系統模擬
[圖 4] 檔案系統模擬
登錄模擬的實作方式與檔案系統模擬稍有不同。模擬化登錄機碼包括大部分的 HKEY_LOCAL_MACHINE\Software 分支，但有許多例外，比方下列位置：
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
只有一般僅限由舊版應用程式所修改，而又不致引發相容性或交互操作性問題的機碼才會模擬化。Windows 會將舊版應用程式對模擬化機碼所做的修改重新導向到使用者在 HKEY_CURRENT_USER\Software\Classes\VirtualStore 下的登錄虛擬根目錄。此機碼位於使用者的 Classes Hive，即 %LocalAppData%\Microsoft\Windows\UsrClass.dat，而且就像任何其他的模擬化檔案資料一樣，不會跟隨漫遊使用者設定檔漫遊。
Windows 並未比照檔案系統的處理方式保存模擬化位置的固定清單，而將機碼的模擬狀態儲存為機碼本身的 REG_KEY_DONT_VIRTUALIZE 旗標。Reg.exe 公用程式可顯示此旗標及其餘兩個與模擬有關的旗標 REG_KEY_DONT_SILENT_FAIL 和 REG_KEY_RECURSE_FLAG，如 [圖 5] 所示。若已設定 REG_KEY_DONT_SILENT_FAIL 但機碼並未模擬化 (設定了 REG_KEY_DONT_VIRTUALIZE)，對機碼執行作業而存取遭拒的舊版應用程式將被授與使用者對該機碼所擁有的任何存取權，而非應用程式要求的機碼。REG_KEY_RECURSE_FLAG 表示新的子機碼是否繼承父系的模擬旗標而不單只有預設旗標。
[圖 5] Reg 公用程式顯示模擬旗標
[圖 5] Reg 公用程式顯示模擬旗標
[圖 6] 顯示 [設定管理員] 如何實作登錄模擬，此程式用於管理作業系統核心 Ntoskrnl.exe 中的登錄。和檔案系統模擬一樣，為模擬化機碼建立子機碼的舊版處理程序會被重新導向到使用者的登錄虛擬根目錄，但 Windows Vista 處理程序將依預設權限而存取遭拒。
除了檔案系統和登錄模擬外，某些應用程式仍需藉助其他功能，才能以標準使用者權限正常執行。例如，用來測試其執行身分帳戶是否具備 Administrators 群組成員資格的應用程式或許能夠運作，但若帳戶不屬於該群組則無法執行。因此，Windows Vista 定義了若干應用程式相容性修正，讓這類應用程式在任何情況下都能運作。[圖 7] 顯示以標準使用者權限執行作業的舊版應用程式最常用的修正。企業 IT 專業人員可以使用應用程式相容性工具組 (ACT，可從 technet.microsoft.com/windowsvista/aa905066.aspx 取得) 及其 Standard User Analyzer (SUA) 公用程式，或是 Aaron Margosis 的 LUA Buglight，來判斷 LOB 應用程式的相容性修正需求。使用 Compatibility Administrator (亦隨附於 ACT) 為應用程式指定相容性修正，然後透過群組原則將產生的相容性資料庫 (.sdb 檔案) 部署到桌面。請注意，必要時可以使用本機安全性原則設定，讓系統完全停用模擬。
Figure 7 一般使用者的應用程式相容性修正 (Close Figure 7)

修正 | 目的
ElevateCreateProcess | 呼叫應用程式資訊服務以提示提升權限，使 CreateProcess 改為處理 ERROR_ELEVATION_REQUIRED 錯誤。
ForceAdminAccess | 假裝查詢系統管理員群組成員資格。
VirtualizeDeleteFile | 假裝順利刪除全域檔案和目錄。
LocalMappedObject | 強制全域區段物件進入使用者的命名空間。
VirtualizeHKCRLite、VirtualizeRegisterTypeLib | 將 COM 物件的全域登錄重新導向到每位使用者位置。
模擬的效果
您可以在 [工作管理員] 中按一下滑鼠右鍵，然後從快顯功能表選取 [模擬]，來變更處理程序的模擬狀態。[圖 A] 顯示命令提示字元隨著模擬狀態變更所表現的行為。起先停用模擬是因為程式具有 Windows Vista 資訊清單。由於程式以標準使用者權限執行，而無法在 \Windows 目錄下建立檔案，但後來因為使用 [工作管理員] 啟用模擬，以致能夠順利建立檔案。程式一旦返回模擬已停用的狀態就會找不到檔案，因為檔案實際位於使用者的虛擬存放區。
[圖 A] 模擬狀態變更
[圖 A] 模擬狀態變更

系統管理員核准模式
即便使用者僅執行與標準使用者權限相容的程式，某些作業仍然需要系統管理權限。大多數的軟體安裝都需要系統管理權限，才能在系統通用位置上建立目錄和登錄機碼，或是安裝服務或裝置驅動程式。修改系統通用的 Windows 設定及應用程式設定也需要系統管理權限，就跟 Windows Vista 家長監護功能一樣。儘管切換到專用的系統管理帳戶便能執行大部分這類作業，但此作法極為不便，可能導致大多數使用者仍繼續以系統管理帳戶身分來執行日常工作。
因此，Windows Vista 包含增強的「執行身分」功能，讓標準使用者能方便地以系統管理權限啟動處理程序。要發揮這項功能，應用程式必須能夠識別哪些作業可由系統視需要代表應用程式取得系統管理權限，這點我將會在稍後說明。
此外，充當系統管理員的使用者既然能以標準使用者權限執行，為了使其免於每次都得輸入使用者名稱和密碼方可存取系統管理權限，Windows Vista 因而引進「系統管理核准模式」(AAM)。這項功能會在使用者登入時為其建立兩個識別身分：其一擁有標準使用者權限，另一者擁有系統管理權限。由於 Windows Vista 系統的每一位使用者都是標準使用者，或通常均以 AAM 認定的標準使用者身分執行，開發人員務必假定所有的 Windows 使用者都是標準使用者，這樣才會有愈來愈多的程式不需要模擬或相容性修正便能以標準使用者權限運作。
將系統管理權限授與處理程序稱為提升權限。如果是由標準使用者帳戶執行即稱為幕後 (Over the Shoulder，OTS) 提升權限，因為此時需要輸入系統管理員群組成員帳戶的認證，而這通常是由另一位使用者在標準使用者幕後輸入所完成。由 AAM 使用者執行的權限提升則稱為同意 (Consent) 提升權限，因為使用者只須同意將其系統管理權限指派給處理程序。
使用者若是 [圖 8] 所列任何一種系統管理員群組的成員，Windows Vista 便將其視為系統管理員。圖中所列的群組大多只用於加入網域的系統，且並未直接賦予使用者本機系統管理權限，但允許使用者修改網域設定。如果使用者是這其中任一群組的成員，但並非真正隸屬 Administrators 群組，使用者將透過 OTS 提升權限存取其系統管理權限，而非透過同意提升權限。
Figure 8 系統管理群組 (Close Figure 8)

內建式系統管理員
憑證系統管理員
網域系統管理員
企業系統管理員
原則系統管理員
架構系統管理員
網域控制站
企業唯讀網域控制站
唯讀網域控制站
帳戶操作員
備份操作員
密碼編譯操作員
網路設定操作員
列印操作員
系統操作員
RAS 伺服器
進階使用者
Windows 2000 Compatible Access 前版
當使用者以圖中所列群組成員的身分登入時，Windows Vista 會為該使用者的系統管理身分建立權杖以代表其標準使用者身分。除了 [圖 9] 所列預設的標準使用者權限外，新權杖將被撤銷已指派給該使用者的一切權限。此外，新權杖中會以 USE_FOR_DENY_ONLY 旗標標示所有各種系統管理員群組。[圖 10] 中的 Sysinternals Process Explorer (處理程序管理工具，可從 microsoft .com/technet/sysinternals 下載) 顯示處理程序以系統管理權限執行 (左圖) 和不具備系統管理員權限 (右圖) 時的群組成員資格和權限 (為避免使用不當，Windows 安全性模型要求已設定停用旗標的權限必須啟用後才能使用)。
Figure 9 標準使用者權限 (Close Figure 9)

好記的名稱 | 內部名稱
略過周遊檢查 | SeChangeNotifyPrivilege
關閉系統 | SeShutdownPrivilege
從銜接站移除電腦 | SeUndockPrivilege
增加處理程序工作組 | SeIncreaseWorkingSetPrivilege
變更時區 | SeTimeZonePrivilege
[圖 10] AAM 系統管理員和標準使用者權杖
[圖 10] AAM 系統管理員和標準使用者權杖
已設定 deny-only 旗標的群組只能用來拒絕使用者存取資源；千萬不要允許這類群組，以杜絕整個群組移除時可能形成的安全性漏洞。例如，假設某個檔案的存取控制清單 (ACL) 完全拒絕 Administrators 群組存取，但卻授與使用者所屬的另一個群組若干存取權，使用者便會在 Administrators 群組已從權杖中移除後仍被授與存取，導致使用者的標準使用者身分比系統管理員身分擁有更多存取權。
獨立系統 (通常是家用電腦) 與加入網域的系統以不同的方式處理遠端使用者的 AAM 存取，因為連接網域的電腦可設定網域系統管理群組的資源使用權限。當使用者存取獨立電腦的檔案共用時，Windows 會要求遠端使用者提供標準使用者身分，但若是加入網域的系統，Windows 則會要求使用者提供系統管理身分，藉以確認使用者所有的網域群組成員資格。

便於存取系統管理權限
系統和應用程式可藉由幾種方法識別是否需要系統管理權限。出現在檔案總管 UI 中的 [以系統管理員身分執行] 快顯功能表項目和捷徑選項即為其一。這些項目附有彩色盾牌圖示，一旦選取其所在的按鈕或功能表項目便會提升權限。選擇 [以系統管理員身分執行] 項目將導致檔案總管使用 "runas" 動詞呼叫 ShellExecute API。
大多數的安裝程式都需要系統管理權限，因此負責初始啟動執行檔的映像載入程式附有安裝程式偵測程式碼，用以識別疑似舊版的安裝程式。載入程式所用的探索方法有些很簡單，只會偵測映像的檔名或內部版本資訊中是否有 setup、install 或 update 這些字，而較為嚴謹的則會掃描執行檔中有無常見於協力廠商安裝包裝公用程式的位元組序列。
映像載入程式也會呼叫應用程式相容性 (appcompat) 程式庫，檢查目標執行檔是否需要系統管理權限。程式庫將查詢應用程式相容性資料庫，檢查執行檔是否與 RequireAdministrator 或 RunAsInvoker 相容性旗標關聯。
執行檔要求系統管理權限最常用的方法，是在應用程式資訊清單檔案中加上 requestedElevationLevel 標記。資訊清單是 XML 檔案，包含關於映像的補充資訊。Windows XP 引進這種檔案，用來識別並行執行的 DLL 以及 Microsoft .NET Framework 組件的依存性。資訊清單中若有 trustInfo 項目 (如以下所摘錄 Firewallsettings.exe 的字串傾印結果所示)，表示執行檔是針對 Windows Vista 所撰寫，且內有巢狀 requestedElevationLevel 項目。項目的層級屬性可能是下列三個值其中之一：asInvoker、highestAvailable 和 requireAdministrator。
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
不需要系統管理權限的執行檔 (例如 Notepad.exe) 即指定 asInvoker 值。某些執行檔則要求系統管理員始終需要最高存取權，因而使用 highestAvailable 值。使用者執行設有此值的執行檔時，如果是在 AAM 模式下執行或依稍早定義的規則而視同系統管理員，才會被要求提升權限，而且必須提升權限才能存取系統管理權限。Regedit.exe、Mmc.exe 和 Eventvwr.exe 等應用程式都是使用 highestAvailable 的例子。最後，requireAdministrator 將始終引發提升權限要求，供給要是沒有系統管理權限就無法運作的執行檔使用。
協助工具應用程式將其 uiAccess 屬性指定為 "true" 藉以驅策提升權限的處理程序顯示視窗輸出，而且必須簽署並存放在幾個安全的地方 (包括 %SystemRoot% 和 %ProgramFiles%) 才可發揮此功能。
要判斷執行檔所指定的值，最簡單的方法是使用 Sysinternals Sigcheck 公用程式檢視其資訊清單，像這樣：
sigcheck –m <executable>
執行的映像若要求系統管理權限，服務主機處理程序 (%SystemRoot%\System32\Svchost.exe) 內便會執行應用程式資訊服務 (簡稱 AIS，包含在 %SystemRoot%\System32\Appinfo.dll 中)，因而啟動 Consent.exe (%SystemRoot%\System32\Consent.exe)。Consent 會擷取畫面的點陣圖、對點陣圖套用淡出效果、切換到只有本機系統帳戶才能存取的桌面、繪製點陣圖做為背景，然後顯示提升權限對話方塊列出執行檔的相關資訊。顯示在另一個桌面上是為了防止使用者的帳戶可能引入任何惡意軟體而修改對話方塊的外觀。
[圖 11] OTS 提升權限對話方塊
[圖 11] OTS 提升權限對話方塊
如果映像是經 Microsoft 數位簽署的 Windows 元件，而且映像位於 Windows 系統目錄，對話方塊頂端便會出現藍色條紋，如 [圖 11] 的第一張圖像所示。灰色條紋 (中間的對話方塊) 表示映像已經過 Microsoft 以外的其他人數位簽署，橘色條紋 (最後一個對話方塊) 則表示映像未經簽署。對於已經過數位簽署的映像，提升權限對話方塊會顯示映像的圖示、描述和發行者；但若映像未經簽署，就只會顯示通用圖示、檔案名稱以及「無法辨識的發行者」字樣。這使得惡意軟體更難模仿合法軟體的外觀。按下對話方塊底部的 [詳細資料] 按鈕可展開以顯示執行檔啟動時即將傳入的命令列文字。AAM 同意提升權限對話方塊很相似，但不會提示輸入系統管理員認證，而是僅提供 [繼續] 和 [取消] 按鈕，如 [圖 12] 所示。
[圖 12] AAM 提升權限對話方塊
[圖 12] AAM 提升權限對話方塊
如果使用者拒絕提升權限，Windows 會將拒絕存取的錯誤傳回給初始執行啟動的處理程序。當使用者輸入系統管理員認證或按 [繼續] 而同意提升權限時，AIS 將呼叫 CreateProcessAsUser 以使用適當的系統管理身分來啟動處理程序。雖然 AIS 技術上算是提升權限的處理程序的父系，AIS 會利用 CreateProcessAsUser API 的全新支援，將處理程序的父系處理程序 ID 設定為原本予以啟動的處理程序的 ID (請參閱 [圖 13])。因此，當您使用 Process Explorer 等工具顯示處理程序樹狀目錄時，提升權限的處理程序不會顯示成 AIS 服務主機處理程序的子系。
[圖 13] 提升權限的流程
[圖 13] 提升權限的流程
即便提升權限對話方塊是在另一個安全桌面上，使用者預設無法確認其檢視的對話方塊絕對合法而非惡意軟體所偽造。這對 AAM 來說不成問題，因為偽造同意提升權限對話方塊的惡意軟體無法取得系統管理權限，但惡意軟體可能會等待標準使用者以 OTS 方式提升權限再予以攔截，然後使用特洛伊木馬對話方塊來擷取系統管理員認證。有了這些認證，它們就可獲權存取系統管理員的帳戶來入侵。
基於這個原因，強烈建議企業環境禁止使用 OTS 提升權限。若要停用 OTS 提升權限 (進而減少尋求支援部門協助的次數)，請執行 [本機安全性原則] 編輯器 (Secpol.msc)，並將 [使用者帳戶控制: 標準使用者之提高權限提示的行為] 設定為 [自動拒絕提升權限要求]。
特別注重安全性的家庭用戶應將 OTS 提升權限設定為需要 Secure Attention Sequence (SAS)，讓惡意軟體無法攔截或冒充。如需設定 SAS，請執行 [群組原則編輯器] (Gpedit.msc)，瀏覽到 [電腦設定 | 系統管理範本 | Windows 元件 | 認證使用者介面]，然後啟用 [要求認證項目之信任的路徑]。這樣做以後，您將需要按 Ctrl+Alt+Delete 才能存取提升權限對話方塊。

隔離已提升權限的處理程序
Windows Vista 會在已提升權限的處理程序四周設置屏障，以防範在相同的桌面上以標準使用者權限執行的惡意軟體。如果沒有這道屏障，惡意軟體就能透過視窗訊息傳遞合成的滑鼠/視窗輸入給系統管理應用程式進而予以驅動。且儘管 Windows 標準安全性模型可防止暗藏在處理程序中以標準使用者權限執行的惡意軟體竄改到以其他使用者身分執行的較高權限處理程序，卻無法防止惡意軟體冒充系統管理使用者的標準權限身分來開啟使用者已提升權限的處理程序、植入程式碼，然後啟動處理程序中的執行緒執行植入的程式碼。
Windows Vista 防範視窗訊息的作法稱為「使用者介面權限隔離」(UIPI)。這是以新的 Windows 整合機制為基礎，Windows Vista 也利用此機制來阻隔已提升權限的處理程序。在這種新的安全性模型下，所有處理程序和物件都有整合等級，而物件的整合原則還可針對 Windows 判別存取控制 (DAC) 安全性模型授與處理程序的存取權加以限制。
整合等級 (IL) 是由安全性識別元 (SID) 所代表，後者也代表使用者和群組，等級則編碼於 SID 的相關識別元 (RID) 中。[圖 14] 顯示四個主要 IL 的顯示名稱、SID 以及 SID 的 RID 十六進位值。每個等級的十六進位數字相差 0x1000 是要空出中間等級供 UI 協助工具應用程式使用，以及因應日後成長所需。
Figure 14 主要整合等級 (Close Figure 14)

名稱 | SID | RID
低強制等級 | S-1-16-4096 | 0x1000
中強制等級 | S-1-16-8192 | 0x2000
高強制等級 | S-1-16-12288 | 0x3000
系統強制等級 | S-1-16-16384 | 0x4000
[圖 15] 列出物件的 IL 原則及其限制的存取類型，對應到針對物件所定義的一般存取權。例如，No-Write-Up 可防止 IL 較低的處理程序取得 GENERIC_WRITE 存取所代表的任何存取權。包括檔案和登錄機碼在內，大多數物件的預設原則都是 No-Write-Up，以防止處理程序取得 IL 高於其本身之物件的寫入存取權，即使物件的判別存取控制清單 (DACL) 授與使用者這類存取也一樣。只有處理程序和執行緒物件採用不同的原則。這兩種物件的原則是 No-Write-Up 加上 No-Read-Up，讓 IL 較低的處理程序無法將程式碼植入 IL 較高的處理程序，以及從中讀取密碼等資料。
Figure 15 整合等級原則 (Close Figure 15)

原則 | 效應
No-Write-Up | IL 較低的處理程序無法修改 IL 較高的物件
No-Read-Up | IL 較低的處理程序無法讀取 IL 較高的物件
No-Execute-Up | IL 較低的處理程序無法執行 IL 較高的物件
Windows 會為每個處理程序指派 IL，連同執行處理程序的使用者所屬群組的 SID 一起放在處理程序的權杖中。[圖 16] 列出已指派不同 IL 的處理程序範例。處理程序通常繼承其父系的 IL，但某些處理程序也能啟動位於另一 IL 的處理程序，就像 AIS 啟動已提升權限的處理程序那種情況。若要檢視處理程序的整合等級，可以使用內建的 Whoami 公用程式並指定 /all 選項，或者使用 Sysinternals Process Explorer 或 AccessChk。在 Process Explorer 中加入 [整合等級 (Integrity Level)] 欄就能看到處理程序的 IL。
Figure 16 處理程序整合等級指派範例 (Close Figure 16)

整合等級 | 範例處理程序
低強制等級 | 受保護模式 Internet Explorer 所啟動的受保護模式 Internet Explorer 以及處理程序
中強制等級 | 標準使用者以及未提升權限的 AAM 處理程序
高強制等級 | 以系統管理權限執行的處理程序
系統強制等級 | 本機系統、本機服務以及網路服務處理程序
每個安全物件的 IL 可能是明確或隱含指派的。處理程序、執行緒和權杖物件一律為明確指派的 IL，其值通常與儲存在對應的處理程序權杖中的 IL 相同。多數物件並無明確 IL，所以其 IL 預設為 Medium。唯有由 Low IL 處理程序所建立的物件，其 IL 方為 Medium 以外的值，也就是 Low。您可以使用內建的 iCacls 工具 (%SystemRoot%\System32\iCacls.exe) 檢視檔案的 IL，或使用 Sysinternals AccessChk 公用程式來檢視檔案、登錄機碼、服務和處理程序的 IL。[圖 17] 顯示受保護模式 Internet Explorer 需要存取的目錄為 Low IL。
[圖 17] AccessChk 顯示使用者 [我的最愛] 目錄的 IL
[圖 17] AccessChk 顯示使用者 [我的最愛] 目錄的 IL
如果物件具有明確 IL，其 IL 將儲存在 Windows Vista 新增的一種存取控制項目 (ACE) 中，即標籤 ACE，位於物件的安全性描述元的系統存取控制清單 (SACL) 上 (請參閱 [圖 18])。ACE 中的 SID 對應到物件的 IL，且 ACE 的旗標編碼物件的整合原則。在 Windows Vista 之前，SACL 僅儲存稽核 ACE，而需要「管理稽核及安全性記錄」權限 (SeSecurityPrivilege)，但讀取標籤 ACE 卻只需要「讀取權」(READ_CONTROL) 存取。處理程序若要修改物件的 IL，必須對物件具有「變更擁有者」(WRITE_OWNER) 存取權，其 IL 必須與物件相等或更高，且處理程序只能將 IL 設定為與自己相等或更低的 IL。新的「修改物件標籤」(SeRelabelPrivilege) 權限讓處理程序得以變更其具有存取權之任何物件的 IL，甚至將 IL 提升至比自己的 IL 更高，但此權限預設並未指派給任何帳戶。
[圖 18] 物件的標籤 ACE
[圖 18] 物件的標籤 ACE
當處理程序試圖開啟物件時，完整性檢查會比核心的 SeAccessCheck 函式檢查標準 Windows DACL 更早發生。在預設整合原則下，處理程序的 IL 必須與物件的 IL 相等或更高，才能開啟物件進行寫入存取，而 DACL 屆時也會授與處理程序所需的存取權。例如，Low IL 處理程序無法開啟 Medium IL 處理程序進行寫入存取，即便 DACL 授與處理程序寫入存取權也一樣。
在預設整合原則下，只要物件的 DACL 已授與處理程序讀取存取權，處理程序就能開啟任何物件 (處理程序和執行緒物件除外) 進行讀取存取。這表示 Low IL 處理程序可以開啟其執行身分使用者帳戶所能存取的任何檔案。受保護模式 Internet Explorer 使用 IL 協助防止已感染的惡意軟體修改使用者帳戶設定，但無法遏阻惡意軟體讀取使用者的文件。
處理程序和執行緒物件則屬例外，因為其整合原則還包括 No-Read-Up。這表示處理程序的 IL 必須與其所要開啟的處理程序或執行緒的 IL 相等或更高，且必須由 DACL 授與必要的存取權，開啟作業才會成功。假設 DACL 已授與必要的存取權，[圖 19] 顯示 Medium 和 Low 等級的處理程序對其他處理程序及物件所擁有的存取權。
[圖 19] 物件及處理程序存取
[圖 19] 物件及處理程序存取
Windows 訊息子系統也利用整合等級來實作 UIPI，防止處理程序將幾乎所有的資訊性視窗訊息都傳送到具有較高 IL 的處理程序所擁有的視窗。這可杜絕標準使用者處理程序將輸入灌入已提升權限處理程序的視窗中，或藉由傳送異常訊息造成內部緩衝區溢位以致毀壞已提升權限的處理程序。處理程序可以呼叫 ChangeWindowMessageFilter API，選擇允許其他訊息通過這層防護。UIPI 也會封鎖視窗勾點以免影響 IL 較高之處理程序的視窗；例如，讓標準使用者處理程序無法記錄使用者在系統管理應用程式中鍵入時的按鍵動作。

提升權限與安全性界線
請務必瞭解一點，UAC 提升權限是一項便利措施而非安全性界線。安全性界線須由安全性原則指定，究竟哪些項目才能通過該界線。使用者帳戶即為 Windows 安全性界線的範例，因為使用者如果沒有其他使用者的權限，就無法存取屬於對方的資料。
由於提升權限並非安全性界線，故無法保證系統上以標準使用者權限執行的惡意軟體不會入侵已提升權限的處理程序進而取得系統管理權限。例如，提升權限對話方塊只會識別即將提升權限的執行檔，至於執行後會如何演變則毫無所悉。執行檔將會處理命令列引數、載入 DLL、開啟資料檔，並與其他處理程序通訊。這些作業大致上均讓惡意軟體有機會入侵已提升權限的處理程序進而取得系統管理權限。
在 Low IL 沙箱中執行
受保護模式 Internet Explorer 是在 Low IL 下執行以建立一道屏障，來防堵可能感染其處理程序的惡意軟體。這可防止惡意軟體變更使用者的帳戶設定及自行安裝到自動啟動的位置。您可以使用 Sysinternals PsExec 公用程式加上 -l 選項，在 Low IL 下啟動任意處理程序來探索沙箱。[圖 B] 證實了執行於 Low IL 下的命令提示字元無法在使用者的暫存目錄 (Medium IL) 中建立檔案，卻能在 Internet Explorer 暫存目錄 (Low IL) 中建立檔案。
[圖 B]命令提示字元只可以在 IL 相近的位置上建立檔案

已提升權限的 AAM 處理程序特別容易遭入侵，因為其執行身分使用者帳戶與 AAM 使用者的標準使用者權限處理程序相同，而且共用該使用者的設定檔。多數應用程式都會從使用者的設定檔讀取設定並載入註冊的擴充功能，而讓惡意軟體有機會提升權限。例如，通用控制項對話方塊會載入使用者的登錄機碼中所設定的殼層延伸 (位於 HKEY_CURRENT_USER 下)，以致惡意軟體可能將自己新增至登錄成為某一項延伸，而被使用這些對話方塊的較高權限處理程序載入。
由於共用狀態的緣故，自標準使用者帳戶提升權限的處理程序也難免遭入侵。在登入工作階段中執行的所有處理程序共用 Windows 用於儲存事件、Mutex、信號及共用記憶體的內部命名空間。如果惡意軟體知道提升權限的處理程序將在啟動時嘗試開啟並讀取特定的共用記憶體物件，就可建立物件利用其內容造成緩衝區溢位，而將程式碼植入提升權限的處理程序中。這類攻擊雖相當複雜卻不無可能，以致 OTS 提升權限無法充當安全性界線。
引進權限提升以提供便利性基本上是鼓勵想要存取系統管理權限的使用者預設均以標準使用者權限執行。使用者若希望受到安全性界線的保障，可斟酌便利性以標準使用者帳戶執行日常工作，並利用快速切換使用者 (FUS) 切換到專用的系統管理員帳戶來執行系統管理作業。反過來說，欲捨棄安全性而就便利性的使用者，則可從 [控制台] 開啟 [使用者帳戶] 對話方塊將系統停用 UAC，但請注意這樣做也會停用 Internet Explorer 的受保護模式。

結論
以標準使用者身分執行具有許多優點，包括協助保護系統免受意外或蓄意損毀，及保護共用系統的使用者個人資料和完整性免於未經授權存取的侵害。UAC 的各項變革和技術致使 Windows 使用模型產生重大轉變。隨著 Windows Vista 的到來，Windows 使用者終於能以標準使用者權限執行大多數日常工作和大部分的軟體，而多數企業如今也都可以部署標準使用者帳戶。

Mark Russinovich 是 Microsoft 平台服務事業群 (Platform and Services Division) 的技術人員。他是 Microsoft Windows Internals (Microsoft Press，2004) 的共同執筆者，經常在 IT 和開發人員會議上發表演說。身為 Winternals Software 公司的共同創辦人，隨著 Microsoft 最近併購該公司，他也一同加入 Microsoft。他也創立了 Sysinternals，並在該公司發行 Process Explorer、Filemon 和 Regmon 等公用程式。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 安全性: 使用 BitLocker 磁碟機加密保護資料的關鍵
安全性 Byron Hynes

使用 BitLocker 磁碟機加密保護資料的關鍵
摘要:
  • 完整磁碟區加密
  • BitLocker 金鑰
  • 設定 BitLocker

Windows BitLocker 磁碟機加密無疑是 Windows Vista 中最廣受討論的一項功能。不過，多數人很難得有機會測試 BitLocker 以親身瞭解
其用途和運作原理，特別是受限於電腦並沒有可信賴平台模組 (TPM)。在本文中，我將介紹 BitLocker™ 的基本概念，讓您可以評估其潛力並考慮納入您的升級計劃。首先我將提供一些背景和概念資訊，接著討論有關啟用 BitLocker 和資料修復與管理，最後則介紹 BitLocker 如何協助處理報廢的電腦。為了更清楚瞭解本文談論的術語，請參閱「磁碟和磁碟區」資訊看板。
磁碟和磁碟區
磁碟和磁碟區這兩個術語經常令人混淆。以下摘錄簡短的名詞解釋供您參考。
磁碟分割：磁碟分割是實體硬碟的一個區段。這種邏輯結構定義於儲存在磁碟上的磁碟分割表中。
磁碟區：磁碟區是 Windows 中由一或多個磁碟分割所組成的邏輯結構，且由所謂磁碟區管理員的 Windows 元件加以定義。除了磁碟區管理員和啟動元件外，作業系統的其餘部分以及應用程式都是使用磁碟區而非磁碟分割。在 Windows 用戶端作業系統中 (包括 Windows Vista)，磁碟分割和磁碟區通常具有一對一關聯性。而在伺服器中，每個磁碟區通常由多個磁碟分割所組成，例如典型的 RAID 組態配置。
使用中的磁碟分割：一次只有一個磁碟分割可標記成使用中的磁碟分割。這種磁碟分割內有用來啟動作業系統的開機磁區。使用中的磁碟分割有時稱為系統磁碟分割或系統磁碟區，但請勿將這些用語與 Windows OS 磁碟區搞混了。
Windows OS 磁碟區：這種磁碟區內有 Windows 安裝，包括 System 和 System32 資料夾。Windows Vista 上市前的用語稱之為開機磁碟分割 (且目前仍然常用)。使用 Windows OS 磁碟區一詞更加清楚明瞭，可避免永無止盡將開機磁碟分割與系統磁碟分割搞混。在以往，講師有時會提醒學員牢記「諸位是從系統磁碟分割開機，並在開機磁碟分割上尋找系統檔案」。
在 Windows Vista 之前，Windows OS 磁碟區 (也稱為開機磁碟分割) 和使用中的磁碟分割 (也稱為系統磁碟分割) 是指同樣的東西，因為大多數用戶端電腦的硬碟都只設定成一個大型磁碟分割。如 [圖 A] 所示，您可以在 Windows Vista 的 [磁碟管理] 主控台中看到每個磁碟分割或磁碟區受指派的功能。
[圖 A] 磁碟分割的功能
[圖 A] 磁碟分割的功能

BitLocker 實際具備兩項相輔相成但截然不同的功能。首先，BitLocker 會為 Windows® OS 磁碟區提供完整磁碟區加密。其次，在具有相容 TPM 的電腦上，BitLocker 則提供方法於 Windows Vista™ 啟動前驗證早期啟動元件的完整性。
若要使用 BitLocker 的所有功能，您的電腦必須已有相容的 TPM 微晶片和 BIOS。所謂相容是指支援 TPM 以及 Trusted Computing Group (TCG) 所定義之 Static Root of Trust Measurement 的 TPM 1.2 版和 BIOS。但是，不具有相容 TPM 和 BIOS 的電腦仍可使用 BitLocker 加密。

完整磁碟區加密
BitLocker 提供完整磁碟區加密，以確保所有寫入 Windows OS 磁碟區的資料都已加密。此為組織妥善保護電腦上所儲存之機密資訊的關鍵，尤其是膝上型和攜帶型電腦。
攜帶型電腦遺失或遭竊的情形時有所聞。隨著行動運算功能逐漸普及，機動人力與日俱增，任何員工都有可能隨身攜帶數百 GB 的組織商業秘密、機密文件或客戶的個人識別資訊 (PII)。只要上網任意搜尋，就會發現充斥著遺失這類資料的新聞 (隱私權情報交換所 Privacy Rights Clearinghouse 聲稱，自 2005 年迄今已有超過一億零四百萬筆的個人資訊記錄遺失或外洩)。
多數組織已循法律途徑或行政命令的規範來保護各類私密資訊；即便您還未受到法律的約束，迫於商業利益也得委屈求全。

為何要加密整個磁碟區？
如果您是經驗豐富的 Windows 系統管理員，可能早就很熟悉 Windows 的加密選項，例如加密檔案系統 (EFS) 甚或 Rights Management Services (RMS) 所提供的加密與保護。BitLocker 最大的差別在於一經啟用後，即自動全盤包含整個磁碟區。
例如，使用 EFS 時，您必須特別指定要保護哪些檔案和資料夾。Windows Vista 提供了一些新選項使 EFS 更加靈活，且 EFS 和 RMS 可分別解決 BitLocker 能力所不及的若干問題。但 EFS 和 RMS 都重度仰賴系統管理員設定，且其設計目的並非保護整個磁碟區的所有內容。
相反地，BitLocker 會加密所有寫入已受 BitLocker 保護之磁碟區的內容，包括作業系統本身、登錄、休眠檔案和分頁檔、應用程式以及應用程式使用的資料。
有三個項目並未加密：開機磁區、標示為無法讀取的任何已損毀磁區，以及磁碟區中繼資料。磁碟區中繼資料含有用來管理 BitLocker 的三份資料複本，包括磁碟區的相關統計資訊和某些解密金鑰受保護的複本。這些項目不需要加密是因為它們並無獨特性，既不貴重也不屬於個人識別資訊。
完整磁碟區加密可以防範離線攻擊，亦即試圖略過作業系統來發動的攻擊類型。例如，常見的離線攻擊就是竊取電腦再拆下硬碟，然後裝入執行別的 Windows 版本或其他作業系統的另一台電腦做為次要磁碟機，以擺脫 NTFS 權限和使用者密碼的約束。使用這類攻擊方式無法讀取 BitLocker 保護的磁碟區。

BitLocker 如何加密資料
BitLocker 使用先進加密標準 (AES) 演算法搭配 128 位元金鑰。為了提供更妥善的保護，可使用群組原則或 BitLocker Windows Management Instrumentation (WMI) 提供者，將金鑰增強至 256 位元金鑰。
磁碟區內的每個磁區會個別加密，而其加密金鑰的某一部分是從磁區編號本身取得。這表示即使兩個磁區包含完全相同的未加密資料，寫入磁碟的已加密位元組也不同，所以很難試圖藉由建立和加密已知的資訊片段查出金鑰。
使用 AES 加密資料之前，BitLocker 還會用到一種演算法稱為 Diffuser。撇開密碼編譯的細節不談，簡單來講 Diffuser 可確保縱使純文字只有些微變動，也將導致整個磁區上的加密文字產生變化。這也讓攻擊者更難查出金鑰或資料。
如果您對 BitLocker 加密演算法的細節感興趣，可參閱 Neil Ferguson 的論文《AES-CBC + Elephant Diffuser：Windows Vista 的磁碟加密演算法》。

BitLocker 金鑰
每當處理加密問題，您都必須認識金鑰，BitLocker 也不例外。BitLocker 使用極精緻但又略顯複雜的金鑰架構。
磁區本身加密時所用的金鑰稱為完整磁碟區加密金鑰 (FVEK)。然而，使用者既無法使用也存取不到 FVEK。接著 FVEK 則以所謂的磁碟區主要金鑰 (VMK) 進行加密。用這麼抽象的方式處理自有其獨特的優點，但也讓人稍難理解整個過程。FVEK 視同機密受到嚴密保護，因為一旦洩露了這個金鑰，所有的磁區都需要重新加密。由於這是既費時又工程浩大的作業，任何人都希望能盡量避免。正因如此，系統將轉而處理 VMK。
以 VMK 加密的 FVEK 儲存在磁碟上，屬於磁碟區中繼資料的一部分。儘管 FVEK 儲存於本機，但絕對會先加密再寫入磁碟。
VMK 也經過加密、「受到保護」，然而金鑰保護裝置可能不止一種。預設的金鑰保護裝置是 TPM。有關 TPM 的使用情形，將於＜完整性檢查＞一節中討論。此外還會建立修復密碼，充當金鑰保護裝置以因應緊急情況。稍後亦將討論到資料修復。
您可以結合 TPM 與 PIN 數字，或是儲存在 USB 磁碟機上的部分金鑰來加強安全性。這些方法都屬於雙重要素驗證形式。如果您的電腦沒有相容的 TPM 晶片和 BIOS，BitLocker 仍可設定為將金鑰保護裝置完全儲存在 USB 磁碟機上。此即所謂啟動金鑰。
您無須解密資料就能停用 BitLocker；這樣一來，VMK 將只受到未經加密即儲存的新金鑰保護裝置所保護。請注意，這種清除金鑰會讓系統得以將磁碟機當成未受保護一般來存取。
系統會在啟動時查詢 TPM、檢查 USB 連接埠，或者若有必要還會提示使用者 (稱為修復)，以找出合適的金鑰保護裝置。一旦找到金鑰保護裝置，Windows 就能解密 VMK，再接著解密 FVEK，最後解密磁碟上儲存的資料。此程序如 [圖 1] 所示。
[圖 1] BitLocker 預設啟動程序
[圖 1] BitLocker 預設啟動程序

完整性檢查
由於啟動程序最早期階段中的元件必須未經加密否則無法啟動電腦，也就使得攻擊者可趁機變更這些早期啟動元件的程式碼 (回想一下 Rootkit) 進而取得電腦的存取權，屆時即使磁碟上的資料已加密亦無濟於事。
如果入侵者使用這類攻擊方式，便極有可能存取到 BitLocker 金鑰或使用者密碼等機密資訊，然後利用這些資訊破解其他的安全防護措施。
防範這類攻擊正是 BitLocker 專案小組創造該項功能的一大初衷。就某方面而言，加密意味著幾乎已經大功告成。完整磁碟區加密讓 BitLocker 既可保護系統的完整性，也能在早期啟動元件遭竄改時防止 Windows 啟動。
具有相容 TPM 的電腦一經啟動，每個早期啟動元件如 BIOS、主開機記錄 (MBR)、開機磁區和開機管理程式碼就會檢查即將執行的程式碼、計算雜湊值，並將此值儲存到 TPM 中特定的暫存器，稱為平台設定暫存器 (PCR)。雜湊值一旦儲存到 PCR 中，即無法取代或清除其值，除非重新啟動系統。BitLocker 使用 TPM 及儲存在 PCR 中的值來保護 VMK。
TPM 可建立金鑰以連結特定的 PCR 值。建立這類金鑰時，TPM 會將金鑰加密，而且只有該特定 TPM 可將其解密。此外，只有在目前的 PCR 值與建立金鑰時指定的值相符之情況下，TPM 才會將金鑰解密。這稱為密封 TPM 的金鑰。
根據預設，BitLocker 會密封 Core Root of Trust Measurement (CRTM)、BIOS 以及任何 Platform Extensions、Option ROM 碼、MBR 碼、NTFS 開機磁區和開機管理程式所測量的金鑰。如果這其中有任何項目意外變更，BitLocker 將會鎖定磁碟機以禁止存取或解密。
BitLocker 預設會尋找並使用 TPM。您可以利用群組原則或本機原則設定，將 BitLocker 改為不與 TPM 搭配運作，並將金鑰儲存到外接式 USB 快閃磁碟機；但若沒有 TPM，BitLocker 即無法驗證系統完整性。

初次啟用 BitLocker
BitLocker 內建於 Windows Vista Enterprise 和 Windows Vista Ultimate (下一版的 Windows Server®，代號 "Longhorn" 亦將隨附 BitLocker 做為選用元件)。
下面的討論假定您的電腦已有相容的 TPM 可供測試。如果您想要在沒有 TPM 的電腦上啟用 BitLocker，請依照「在不含 TPM 的情況下使用 BitLocker」資訊看板所列的步驟執行。
在不含 TPM 的情況下使用 BitLocker
BitLocker 預設會使用 TPM，因此如果您並無此配備，Windows 起先將不允許您啟用 BitLocker。不過，以下摘錄自《Windows BitLocker 磁碟機加密逐步指南》的程序將可讓您在沒有 TPM 的情況下使用 BitLocker。
若要執行這些步驟，您必須以系統管理員身分登入。即使沒有 TPM，您的電腦仍需支援在啟動程序期間讀取 USB 快閃磁碟機。此外，當您啟用 BitLocker 及每次重新啟動電腦時，都必須已接上可用的 USB 快閃磁碟機。
請遵循下列步驟，在不含相容 TPM 的電腦上開啟 BitLocker 磁碟機加密：
  1. 按一下 [開始]，在 [開始搜尋] 方塊中輸入 gpedit.msc，然後按 ENTER。
  2. 如果出現 [使用者帳戶控制] 對話方塊，請確認提議的動作是您所要求的，然後按一下 [繼續]。
  3. 在 [群組原則物件編輯器] 主控台樹狀目錄中，依序按一下 [本機電腦原則]、[系統管理範本] 和 [Windows 元件]，再按兩下 [BitLocker 磁碟機加密]。
  4. 按兩下 [控制台設定: 啟用進階啟動選項] 設定項目。[控制台設定: 啟用進階啟動選項] 對話方塊便會出現。
  5. 選取 [已啟用] 選項，然後選取 [在不含相容 TPM 的情形下允許使用 BitLocker] 核取方塊，再按一下 [確定]。如此即已變更原則設定，接著您就可以使用啟動金鑰代替 TPM。
  6. 關閉 [群組原則物件編輯器]。
  7. 若要強制立刻套用群組原則，請按一下 [開始]，在 [開始搜尋] 方塊中輸入 gpupdate.exe /force，然後按 ENTER。等候程序完成。

啟用 BitLocker 最重要的一環在於確認磁碟區已正確設定。BitLocker 必須從尚未加密的使用中磁碟分割來讀取開機磁區、開機管理程式和 Windows 載入器程式 (這些元件均受到上述的系統完整性步驟所保護)。由於其他 Windows 元件可能暫時需要用到使用中的磁碟分割，Microsoft 建議使用中的磁碟分割至少應有 1.5GB。您最好也一併設定 NTFS 權限，以免使用者意外寫入資料至該磁碟區。
Windows 本身將會安裝到另一個較大的磁碟區，而此磁碟區則可加密。若您是在全新的系統上安裝 Windows，就可以依照《Windows BitLocker 磁碟機加密逐步指南》提供的指示，手動設定各磁碟區。
您可利用 BitLocker Drive Preparation Tool (BitLocker 磁碟機準備工具)，協助您設定系統以便支援 BitLocker。此工具會幫您辦妥繁複的磁碟機設定工作，屬於 Windows Vista Ultimate Extra 所附的功能，而部署 Windows Vista Enterprise 的客戶亦可取得。如需 BitLocker Drive Preparation Tool 的詳細指示，請造訪 support.microsoft.com/kb/930063。
BitLocker Drive Preparation Tool 會自動壓縮磁碟區 (如果只有一個磁碟區)、建立第二個磁碟分割並將其指定成使用中的磁碟分割、進行所有必要的設定變更，然後將啟動檔案移至正確位置。
設定好磁碟區之後，要啟用 BitLocker 就非常簡單。請在 [控制台] 的 [安全性] 區段中，按一下 [BitLocker 磁碟機加密] 圖示。當您認可 UAC 同意提示後，便會出現如 [圖 2] 的畫面。
[圖 2] 啟用 BitLocker
[圖 2] 啟用 BitLocker
接下來的確切步驟視電腦的 TPM 晶片狀態而定。如果 TPM 晶片尚未初始化，將會執行可信賴平台模組 (TPM) 初始化精靈。請遵循指示初始化 TPM，再依提示重新啟動電腦。
一旦 TPM 已初始化，即出現如 [圖 3] 所示的 [儲存修復密碼] 頁面。您必須有修復密碼，才能在 TPM 失效或發生其他問題時修復資料。此頁面允許您將修復密碼儲存到 USB 快閃磁碟機、儲存到本機或網路磁碟，或列印密碼妥善保管。您必須至少選擇以上其中一個選項，並可選擇儲存多份複本。當修復密碼已儲存後，[下一步] 按鈕即呈現啟用狀態。請按一下該按鈕。
[圖 3] 儲存修復密碼
[圖 3] 儲存修復密碼
接著會出現 [加密選取的磁碟區 (Encrypt the selected disk volume)] 頁面，而您則可選擇是否要在開始加密前先執行系統檢查。系統檢查需要重新啟動電腦，卻是確保 TPM、BIOS 和 USB 連接埠均可搭配 BitLocker 正常運作的最佳方式。重新啟動電腦後若偵測到任何問題，將會出現錯誤訊息；反之則顯示 [加密進行中] 狀態列。
就是這樣。加密將在幕後完成，因此您可以繼續使用電腦。初步加密一旦完成，便會出現通知訊息。您也可以將游標移到螢幕下方工作列中的 [BitLocker 磁碟機加密] 圖示上，來監視磁碟區加密進行中的完成狀態。如需詳細資訊，請參閱稍早提到的逐步指南。
某些使用者可能會感到訝異，為何 BitLocker 並未在電腦啟動時提示使用者，也沒有任何其他明顯的干擾動作。這是因為 BitLocker 預設會先仰賴 TPM 確認系統完整性，再解除鎖定磁碟區的緣故。此過程將自動進行而讓使用者不致察覺。
您可以將 BitLocker 設定為要求在啟動時輸入 PIN，或出示儲存於 USB 快閃磁碟機上的金鑰。這可增強安全性，因此如果增強安全性的好處勝過輸入 PIN 所帶來的不便，則建議採用。我的主張是一直都這麼做 (換句話說，我的桌上型電腦需要 PIN 而膝上型電腦需要 USB 金鑰)。

BitLocker 修復
只要涉及到加密，尤其是商務或企業環境，必定得設法讓已獲授權的使用者都能取回自己的資料，就算正常存取途徑發生問題或手邊沒有金鑰也一樣。BitLocker 將這種情形稱為修復。
萬一早期啟動元件發生意外變更，或您遺失了 USB 啟動金鑰，還是使用者忘記自己的 PIN，BitLocker 都將無法完成正常啟動程序。BitLocker 會繼續鎖定磁碟區以致 Windows 無法啟動。相對地，開機管理程式中的 BitLocker 程式碼將顯示文字畫面。若您已在 USB 快閃磁碟機上儲存修復密碼 (有時稱為修復金鑰)，則會出現如 [圖 4] 的畫面。
[圖 4] 尋找修復金鑰
[圖 4] 尋找修復金鑰
您必須在啟動電腦時接上 USB 快閃磁碟機，這樣 BitLocker 才能讀取。因此若您已有包含修復密碼的 USB 快閃磁碟機，請將其插入然後按 ESC。如果您沒有這種磁碟機，請按 Enter 以顯示如 [圖 5] 的畫面。萬一 USB 磁碟機上沒有修復金鑰，您也會看到這個畫面。
[圖 5] 輸入 BitLocker 密碼
[圖 5] 輸入 BitLocker 密碼
現在 BitLocker 正要尋找可用來解除鎖定磁碟機的 48 位數密碼。如果您先前選擇列印修復密碼，請找出當時列印在紙上的數字；或者若您是將修復密碼儲存到資料夾，請從位在該處的檔案中找出密碼。
對企業來說，管理修復密碼最簡單的方法是讓密碼自動儲存在 Active Directory® 中。如需徹底瞭解如何設定這種方法，請參閱 go.microsoft.com/fwlink/?LinkId=87067。
在日後的文章中，我將詳述 BitLocker 的管理功能，但本篇概論想先向您預告 BitLocker 附有整套 WMI 提供者，可透過與 WMI 相容以網路為主的企業管理 (WBEM) 系統來管理 BitLocker (及 TPM)。這表示您也可以使用 VBScript 或 Windows PowerShell™ 等任何可存取 WMI 物件的指令碼語言為 BitLocker 編寫指令碼。
BitLocker 亦隨附命令列工具 manage-bde.wsf，此工具利用 WMI 提供者讓您能夠管理本機或遠端電腦上的 BitLocker。如需詳細資訊，請以較高的權限啟動命令提示字元，然後輸入 manage-bde.wsf /?。

安全地解除任務
每一台電腦終究都得解除任務 (報廢)。企業通常投入大量人力物力，以確保磁碟機卸除前均已完全清空。從磁碟機移除機密資料的過程大致都很耗時間或所費不貲，甚至造成硬體損毀而萬劫不復。BitLocker 提供了更具成本效益的其他選項。
您無須擔心移除資料這類現實問題，BitLocker 打從一開始就已確保機密資料安全無虞地儲存在磁碟上。由於寫入磁碟的內容都已加密，只要銷毀加密金鑰的所有複本便能讓資料永遠無法存取。硬碟本身則毫髮無損可重複使用。
當您需要將 BitLocker 保護的磁碟區解除任務時，有幾種處理方式可供選擇。例如，您可將金鑰封存到安全的中央站台位置，再從磁碟區中繼資料刪除金鑰的所有複本。這樣便能安心轉運電腦，或將長時間庫存不用的系統暫時解除任務。如此既可確保已獲授權的使用者仍可存取資料，又能防止未獲授權的使用者存取，比方像是設備的新主人。
您也可以選擇從磁碟區中繼資料及任何封存位置 (如 Active Directory) 刪除金鑰的所有複本，又或者只建立新的金鑰但不儲存。由於少了解密金鑰，任何人均無法修復或擷取資料。
不論您選擇哪一種處理方式，幾乎都能立即移除和銷毀磁碟區中繼資料內的金鑰，並可交由一位系統管理員同時處理多部系統。以最少的人力物力換來高水準的永久保護，何樂而不為？Windows Vista 中的格式化公用程式已有所更新，如今格式化命令會刪除磁碟區中繼資料並覆寫這些磁區，因此也會妥當地刪除 BitLocker 金鑰。

結語
BitLocker 是設計用來防範特定威脅且功能強大的工具，而確實也表現得相當優異。不過，切莫誤認為只要有 BitLocker 就能防範一切威脅。繼續採取適當的防護控制 (例如強式密碼) 仍是關鍵。
切記 BitLocker 可牽制離線攻擊。這意謂著一旦 Windows 已在執行中，即表示 BitLocker 已解除鎖定磁碟區。也就是說，BitLocker 無法為執行中的系統提供保護。諸如 EFS 和 RMS 等技術則彌補了 BitLocker 的不足，可於作業系統執行期間保護資訊。
如需 BitLocker 的詳細資訊，請造訪 Microsoft 網站，參閱 technet.microsoft.com/windowsvista/aa905065.aspx 所列的各篇文章。如需 TPM 規格及 TCG 的詳細資訊，請參閱 TCG 網站上的＜可信賴平台模組 (TPM) 規格＞一節，網址為 go.microsoft.com/fwlink/?LinkId=72757。

Byron Hynes 服務於 Microsoft 的 Windows Server 使用者協助事業群。他曾擔任過顧問和訓練師。您可以透過電子郵件地址 bhynes@microsoft.com 與他連絡。


 安全性: 探索 Windows 防火牆
安全性 Steve Riley

探索 Windows 防火牆
摘要:
  • 輸入與輸出保護
  • Windows 篩選平台
  • 進階安全性介面
  • 網路設定檔

回顧電腦剛萌芽的年代，根本不會有人想到要在個別的電腦上安裝防火牆。何需多此一舉？幾乎沒有人聽說過網際網路，TCP/IP 還沒誕生，而區域網路通訊協定線路也從未跨出社區或校區。重要資料都是放在
大型主機或檔案伺服器上；人們鮮少將事關重大的資訊留在桌上型電腦，且電腦本身的笨重至少還能相當程度地保障實體安全性。如果有機會連上網際網路，中間大概都還隔著好幾台通訊協定轉譯器，邊際上可能也有封包篩選路由器 (我是說「防火牆」) 設定了重重的規則和例外。
當今的運算環境跟以往那種年代比起來相去甚遠。連上網際網路變得司空見慣 (而且現在都用 TCP/IP 溝通)，可攜式裝置如今也成為標準配備。老闆也許會給您一台膝上型電腦，可不是因為他賞識您，而是想從您這兒多撈點利用價值；他們充其量只是希望您騰出五倍的時間用 Wi-Fi 連線隨時工作。膝上型電腦可能比桌上型電腦更貴，但以重金投資換回生產力絕對值得。瞧，可攜性就是這麼迷人，讓您自己和競爭對手都深陷其中。
想想這個問題：以您的膝上型電腦開機上網的總時數來算，連線到公司網路的時間佔了幾成？就我來說，最高比例約為兩成。這表示我的膝上型電腦只有 20% 的時間待在 Microsoft 公司網路的範圍內，安然受到網路周邊設備的保護，並防範外部攻擊。那另外 80% 的時間，當我的膝上型電腦直接連上網際網路、進行日常事務的時候呢？(何況我還經常連線到全世界最危險的網路：電腦安全性會議廳的區域網路)！還有就是當我連線到公司網路，如何防範同在那種環境下的其他電腦構成威脅？
安全性控制的發展必須迎頭趕上各種威脅 (但有時卻望塵莫及)。由於人們經手磁片而讓病毒趁機入侵用戶端，所以起先有了用戶端防毒程式。接著電子郵件愈發普及，惡意軟體變種成蠕蟲隨電子郵件發送，以致發展出防惡意軟體的程式且應用於電子郵件閘道。而隨著全球資訊網的興起，惡意軟體又變種成特洛伊木馬程式，故網際網路存取 Proxy 伺服器也開始使用防惡意軟體的程式。這段發展歷史是無庸置疑眾人皆知的過程。
現在讓我們用同樣的邏輯來看看防火牆。儘管網路邊際上的防火牆足以防護、對抗昨日的威脅，但目前情況已非如此，因為威脅早就改頭換面，不但更複雜也更猖獗。更何況裝置和工作方式也跟過去南轅北轍。許多電腦都將機密資訊儲存在本機，而且經常離開公司網路 (也就是在邊際外)。因此，防火牆必須發展成個別用戶端型態的保護機制。可別搞錯了：用戶端防火牆已經不再是選用配備。為了保護您的電腦在公司網路和網際網路上的安全，千萬一定要有用戶端防火牆。

用戶端防火牆與安全性迷思
很多人根本就不知道 Windows® XP 初版附有用戶端火牆。這其實無須大驚小怪，因為防火牆預設為關閉，而且要按好幾次滑鼠才找得到。防火牆本身還相當神秘，就算看到了也搞不懂真正的用途，而且沒有任何使用指南。但它的確能夠發揮作用。如果您啟用了這個防火牆，它就會幫您阻擋 Nimda、Slammer、Blaster、Sasser、Zotob 及其他來路不明試圖強行通過網路連接埠的流量。由於瞭解到用戶端防護的重要性，Windows XP Service Pack 2 (SP2) 預設啟用防火牆，建立兩個設定檔 (網際網路和公司網路) 並可透過群組原則啟用。
可惜的是，兩大阻礙導致 Windows XP SP2 防火牆難以廣受採納：應用程式考量和安全性迷思。很多人會擔心防火牆可能致使應用程式無法正常運作。不過由於防火牆設計上的緣故，這種情況倒很罕見。防火牆允許所有輸出流量離開您的電腦，但會封鎖不是針對先前若干輸出要求做回應的所有輸入流量。這樣的設計只會在一種情況下阻絕用戶端應用程式，亦即應用程式建立了接聽通訊端而希望接收輸入要求時。Windows XP 防火牆提供簡易方式讓您設定程式或連接埠的例外清單 (但遺憾的是無法透過群組原則設定)。
更大的阻礙在於其他用戶端防火牆製造商所促成的安全性迷思。很多人都深信 Windows XP 防火牆的設計由於允許所有輸出流量毫無限制地離開，而不足以發揮用戶端防火牆的功能。其所持的論點是，用戶端防火牆應該封鎖所有輸入和輸出流量才算勝任，除非使用者特別授與權限。
現在且讓我們仔細想想是否果真如此。請看以下這兩個案例。
  • 假設您以本機系統管理員身分執行時感染了惡意軟體，且惡意軟體只停用防火牆而已。這下子您就中招了。
  • 假設您不是以本機系統管理員身分執行時感染了惡意軟體，而惡意軟體又讓協力廠商防火牆跳出一個對話方塊，上面用外國話寫著連接埠和 IP 位址，還問了非常嚴重的問題：「您是否要允許這麼做？」您只有一個選擇，按 [是]；但是電腦可不知道您的原意是「笨蛋，別再騷擾我！」隨著對話方塊的消失，您的電腦安全也泡湯了。或者更常有的情形是，您將不會看到任何對話方塊，惡意軟體就悄悄地綁架了已獲您授權的程式現有的工作階段。這下子您又中招了。
關於安全性，有一條重要的真理請您務必瞭解：防護應將眼光擺在您想要保護的資產，而非試圖防範的威脅。正確的作法是，組織中的每一部電腦都使用精簡卻有效的 Windows 防火牆，以防範世界上所有其他電腦。若您嘗試封鎖來自已遭感染電腦的輸出連線，那麼要如何確定該電腦真的會照您的要求辦事？答案是：一籌莫展。輸出保護就是一種安全性迷思，只是讓人覺得對安全性有幫助而已的噱頭，卻無法實質改善安全性。這就是為何 Windows XP 防火牆不提供輸出保護，而 Windows Vista™ 防火牆也沒有的原因 (稍後我將深入說明 Windows Vista 中的輸出控制)。

Windows Vista 有何新功能？
Windows 篩選平台是 Windows Vista 防火牆的基礎，屬於新網路堆疊的一部分。和 Windows XP 一樣，Windows Vista 預設會封鎖輸入流量。視您的電腦所使用的設定檔而定，網路服務可能預設了一些例外 (待會我將討論設定檔)。如果要的話，您可以編寫規則來允許輸入連線。而且就像 Windows XP，Windows Vista 預設也允許所有來自互動式處理程序的輸出流量，但會限制來自已加入服務限制之服務的輸出流量。此外，您同樣可以編寫規則來封鎖其他輸出連線。
Windows XP 與 Windows Vista 最大的差別在於新的進階安全性介面，以及群組原則完整支援設定和規則 (請參閱 [圖 1])。原有的 [控制台] UI 仍然保留且幾乎毫無改變，只不過新 UI 如今已提供記錄功能和網際網路控制訊息通訊協定 (ICMP) 設定。這個新 UI 即 [進階安全性] MMC 嵌入式管理單元，提供了所有的新功能和靈活性。此外 netsh 命令也有新的用法 netsh advfirewall，可用來編寫指令碼新增與刪除規則、設定與顯示通用和每個設定檔原則，及顯示防火牆的作用狀態。開發人員還可使用 FirewallAPI.dll 和 Netfw.h 透過程式設計方式控制防火牆的一切設定。
[圖 1] 具有進階安全性的 Windows 防火牆
[圖 1] 具有進階安全性的 Windows 防火牆
[進階安全性] MMC 屬於精靈引導式介面。建立規則時，您可以選擇四種類型之一：程式、連接埠、預先定義或自訂。[圖 2] 說明這些規則類型。
Figure 2 四種規則類型 (Close Figure 2)

類型 | 目的
程式 | 用來允許或封鎖特定程式的流量。
連接埠 | 用來允許或封鎖特定 TCP 或 UDP 連接埠上的流量。
預先定義 | 使用現存的一組規則，在網路上啟用 Windows 功能 (例如檔案及列印共用或遠端協助)。
自訂 | 提供所有的選擇鈕、刻度盤、按鈕和核取方塊，讓您可自行設定所需的特定規則。
您可以參考多種元素來編寫規則，這些元素全都適用於本機規則及透過群組原則套用的規則。其中包括：Active Directory® 使用者和電腦帳戶與群組、來源和目標 IP 位址、來源和目標 TCP 與 UDP 連接埠、IP 通訊協定編號、程式和服務、介面類型 (有線、無線或遠端存取) 以及 ICMP 類型和 ICMP 碼。
設定完成後，防火牆將依下列順序處理規則：
服務限制 Windows Vista 中的某些服務會自行限制，以盡可能阻絕疾風 (Blaster) 病毒式攻擊。其中一項限制為服務所需的連接埠清單。防火牆會強制此項以防止服務使用 (或被誘導使用) 任何其他連接埠。
連線安全性規則 [進階安全性] MMC 納入了 IPsec 還有防火牆。接下來會處理的就是設有 IPsec 原則的任何規則。
已驗證的略過項目 這可讓特定已驗證的電腦略過其他規則。
封鎖規則 這可明確封鎖指定的傳入或傳出流量。
允許規則 這可明確允許指定的傳入或傳出流量。
防火牆規則儲存在登錄中，但我並不打算說出確切的位置。喔！好啦，您可以在這幾個地方找到：
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
請勿直接在登錄中編輯規則。萬一您這麼做而被我發現，小心您的寵物到時被我抓到 eBay 上拍賣！嗯，也許不至於，但唯一保險的作法是使用 [進階安全性] MMC 編輯規則。

網路設定檔
Windows Vista 定義了三個網路設定檔：網域、私用和公用。如果電腦是網域的成員並已順利登入網域，電腦就會自動套用網域設定檔；這由不得您自行選擇。如果電腦連線到沒有網域的內部網路 (例如住家或小型辦公室網路)，您自己或系統管理員即應套用私用設定檔。最後，如果電腦直接連上網路，則請套用公用設定檔。
Windows Vista 如何決定應將您的電腦放在何處？每當網路有所變更 (例如收到新的 IP 位址、發現新的預設閘道或取得新介面)，名為「網路定位知悉」(NLA) 的服務就會偵測到變更。此服務會建立網路設定檔，其中包含現有介面的相關資訊、電腦是否驗證為網域控制站、閘道的 MAC 位址等資訊，並為設定檔指派 GUID。NLA 接著將通知防火牆，而由防火牆套用對應的原則 (三個設定檔各定義了一項原則)。
如果是電腦未曾見過的全新介面，且 NLA 並非選擇網域設定檔，將會出現對話方塊要求您指定電腦連線的網路種類。奇怪的是，竟然有三種選擇：住家、工作和公用。您可能會認為「工作」意味著網域設定檔，但其實並非如此。請記住，您絕對不會看到網域設定檔，因為那是 NLA 在電腦登入網域時私下自動選取的。事實上，「住家」和「工作」都對應到私用設定檔。就功能來說，這兩者旗鼓相當，只不過圖示不同罷了 (注意：您必須是本機系統管理員或可提升權限到本機系統管理員，才能選取私用設定檔)。可想而知，「公用」對應到公用設定檔。
在 Windows Vista 中，網路設定檔套用到電腦上所有的介面。NLA 決策樹的流程大致如下：
  1. 檢查所有連線的網路。
  2. 連線到網路的介面當中是否有任一者歸類為公用？如果有，便將電腦的設定檔設為公用並結束流程。
  3. 連線到網路的介面當中是否有任一者歸類為私用？如果有，便將電腦的設定檔設為私用並結束流程。
  4. 是否所有的介面都見到網域控制站，而且電腦已經順利登入？如果是，便將電腦的設定檔設為網域並結束流程。
  5. 如果以上皆非，便將電腦的設定檔設為公用。
其目標是盡可能選取限制最嚴格的設定檔。不過，會有兩個明顯的副作用。首先，如果電腦的乙太網路連接埠連線到公司網路，而無線網卡又連線到樓下的 Starbucks，那麼電腦就會選取公用設定檔而非網域設定檔。其次，如果電腦直接連線到網際網路 (套用公用設定檔) 或連線到住家區域網路 (套用私用設定檔)，而又透過 VPN 連線到公司網路，那麼電腦就會依舊套用公用或私用設定檔。
這是什麼意思呢？防火牆套用到網域設定檔的原則包含遠端協助、遠端管理、檔案及列印共用等規則。如果您仰賴這些規則連線到遠端用戶端，則一旦該用戶端選擇了其他設定檔，您就無法連上對方。但是別沮喪！您可以編寫防火牆規則來允許任何需要的輸入連線，然後只對 VPN 連線套用這些規則。這樣一來，即使遠端用戶端並非套用網域設定檔，您仍然能夠透過 VPN 管理對方。

控制輸出連線
剛才我曾說過，用戶端防火牆典型的輸出保護型式只不過是安全性迷思。然而，有一種輸出控制型式卻非常有用：由系統管理員控制某些已確知不希望允許的流量類型。Windows Vista 防火牆在服務限制方面就做了這項管制。防火牆只允許服務透過其認為需要的連接埠進行通訊，並且封鎖服務試圖使用的任何其他連接埠。您可以配合組織的安全性原則，編寫其他規則來允許或封鎖特定流量，進而建構這類控制 (請參閱 [圖 3])。
[圖 3] 新增輸入規則精靈
[圖 3] 新增輸入規則精靈
舉例來說，假設您要禁止使用者執行特定的立即訊息用戶端。這時您即可建立規則 (當然是使用群組原則) 封鎖該用戶端對登入伺服器的連線。
不過，這種作法有一些實務上的限制。例如，Windows Live™ Messenger (您可能仍習慣稱之為 MSN® Messenger) 就有各式各樣可供登入的伺服器，而且清單總是經常變動。再說，如果預設連接埠 1863/tcp 被封鎖，它還會切換回連接埠 80/tcp。禁止 Windows Live Messenger 連線到登入伺服器的規則可能過於複雜而且需要不時修改。我之所以提到這，是要說明系統管理式輸出控制或許有用，但若您需要對使用者所能安裝和執行的軟體維持嚴格控制，則不如使用軟體限制原則。

保護您的電腦
如今已無周邊之分；每一部電腦都必須負責自我保護。就如同防惡意軟體的程式從用戶端移往邊際的發展一樣，防火牆也得從邊際移往用戶端。請立即採取行動，啟用您已安裝的防火牆。
無論您的系統是執行 Windows XP 或已經移轉到 Windows Vista，所有用戶端都能使用 Windows 防火牆獲得所需的保護，以增進組織內部的安全性，就算是遠在千里之外的行動工作者也沒問題。

其他相關資源
  • Windows Vista TechCenter：具有進階安全性的 Windows 防火牆入門
  • Windows Vista TechCenter：具有進階安全性的 Windows 防火牆 - 診斷及疑難排解
  • Steve Riley 歐洲行 TechEd 簡報：Windows Vista 防火牆與 IPSec 增強功能
  • The Cable Guy：Windows Vista 與 Windows Server "Longhorn" 全新的 Windows 防火牆
  • Windows Vista 防火牆虛擬實驗室

Steve Riley 是 Microsoft 高可信度電腦運算小組的資深安全性策略人員，也是 TechNet Magazine 的特約編輯，常飛到世界各地參與會議演說並幫助客戶取得並維持安全性。他最新的一本著作是 Protect Your Windows Network (Addison-Wesley，2005)。您可以透過電子郵件地址 steve.riley@microsoft.com 與他連絡。


 安全性: Windows Vista 全新的 ACL 改善安全性
安全性 Jesper Johansson

Windows Vista 全新的 ACL 改善安全性
摘要:
  • ACL 的新功能
  • 對管理員更加嚴密的控制
  • Trusted Installer 權限
  • 已修改的使用者和群組

存取控制清單 (ACL) 的基礎結構在 Windows Vista 中並沒有太大變更，但有些小而重要的變更是您必須知道的。有些變更
是必要的，因為在 Windows® XP 中，有許多問題 ACL 都在其中扮演一角。首先，大多數 Windows XP 使用者都以系統管理員身分執行。也就是說，他們使用的帳戶是內建 Administrators 群組的成員。對於家用電腦使用者，這幾乎是必然的，因為在安裝期間新增的所有帳戶都會成為系統管理員。因此，這種使用者執行的任何程式也會以系統管理權限執行，而毫無束縛地存取作業系統。如果遇到了有攻擊性或惡意的程式，這種做法當然會有問題。
第二個要處理的問題是，舊版 Windows 的預設 ACL 包含 Everyone、Power User 等的 ACL 項目 (ACE)，這可讓許多人如坐針氈。例如，在 Windows XP 中，開機磁碟區 (通常是 C:\) 根目錄的預設 ACL 授予讀取權給 Everyone，並且授予 Users 群組成員建立資料夾的權限。最後，Windows XP 會限制您操作 ACL 的方式。例如，您在 Windows XP 中無法指派權限給物件的目前擁有者。您可以授予擁有者權限，但在擁有者變更時，不會移轉權限。同樣地，不論指派給擁有者的物件權限為何，擁有者一定會有物件的隱含權限。
在 Windows Vista™，Microsoft 為此展開專案，解決許多相關問題，並且支援其他功能，例如使用者帳戶控制 (UAC)。本文將著重在與 Windows Vista 存取控制相關的重大變更。下期，我將繼續探討可用於管理存取控制的工具。

全新和修改的使用者和群組
Windows Vista 新增一些使用者和群組，並且移除 Windows XP 的一些老朋友。再者，運作方式也有些修改。每項變更都會對存取控制的管理方式有些影響。
Administrator：預設停用 內建 Administrator 帳戶，其相關識別元 (RID) 是 500，目前在大部分情況下預設會停用。Administrator 是做為緊急帳戶，在其他帳戶都無效時將成為搶救電腦的最後手段。但它卻被經常用作標準管理帳戶，因此違反數個安全性原則。其中最顯著的是責任性，您會因此失去追蹤變更系統之使用者的能力。因此，該帳戶有些部分已經過時。最終，Microsoft 可能會完全不支援該帳戶，但目前只是先將它設計成依預設停用。如果您沒有 Administrators 群組中的其他本機帳戶，RID 500 仍然可用於復原主控台和安全模式，但在其他情況下則不能也不應使用。
請注意，內建 Administrator 帳戶和 Administrators 群組其他帳戶有不同之處。大寫 "Administrator" 一般是指 RID 500 的帳戶，與系統管理員 (administrator) 有所區別，後者是內建 Administrators 群組的成員帳戶。群組名稱同樣是首字大寫。
在 Windows XP，內建 Administrator 帳戶有些特殊權限，這是其他系統管理員所沒有的。Windows Vista 已經移除大部分特殊權限，但有兩個明顯的例外：首先，如果沒有其他本機系統管理員，停用的 Administrator 帳戶可用於復原主控台。第二，Administrator 不受 UAC 限制，一定會有完整的管理權杖。這種狀況同樣適用於 Domain Administrator (網域上的 RID 500)。
Power Users 權限已移除 基於實用性，舊 Power Users 群組已經廢止。該群組仍然存在，但已移除大部分權限。身為 Power Users 成員的使用者實際上相當於系統管理員，只不過無法讓自身成為系統管理員，這幾乎已是公開的秘密。我曾經透過授予自己系統管理權限，在不到 45 分鐘內，掌控一部已完全修補、執行 Windows XP Service Pack 2 (SP2) 的電腦。方法包含偵搜資訊、以 C++ 編寫小程式，登出後重新登入，即可完成掌控電腦。因為我是 Power Users 成員，一切都成為可能。
許多組織授予 Power Users 群組複雜的權限，並且依賴其中的成員使用者，因此，從 Windows Vista 移除該群組並不可行。不過，在下一版的 Windows，Microsoft 可能會完全移除 Power Users。建議您開始規劃，別再那麼依賴 Power Users。
Trusted Installer Trusted Installer 實際上是個服務，而非使用者，雖然您會在檔案系統中看到授予給它的權限。Service Hardening 讓每個服務都被視為成熟的安全性主體，如同其他使用者般可被授予權限。如需這項功能的概觀，請參閱 TechNet Magazine 2007 年 1 月份期刊。Windows Vista Security (Grimes 和 Johansson，Wiley Press，2007) 一書詳細探討 Service Hardening，包括其他功能 (例如防火牆和 IPsec) 如何運用它。
不同於以往，服務 SID 不是從 NT AUTHORITY 或網域之類的授權單位發行。TrustedInstaller 虛擬帳戶的完整名稱為 NT SERVICE\TrustedInstaller，其 SID 為：
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
您可以透過執行 sc showsid 命令，查看任何服務 (甚至不存在的服務) 的 SID，如 [圖 1] 所示。
[圖 1] sc showsid 顯示任何服務 (包括不存在的服務) 的 SID
[圖 1] sc showsid 顯示任何服務 (包括不存在的服務) 的 SID
此 SID 開頭為 S-1-5-80。請注意，第一個子授權單位值為 80，代表 SECURITY_SERVICE_ID_BASE_RID，表示此 SID 是由 NT SERVICE 子授權單位發行給服務。這也適用於任何服務。其餘子授權單位和 RID 則是根據服務名稱本身產生。如此，開發人員可在不事先建立和安裝服務的情況下，授予服務權限，因為服務名稱具決定性，不會因電腦而異。
假使您在服務管理員中找不到 TrustedInstaller 服務，其顯示名稱為 "Windows Modules Installer"。
Help 和 Support 帳戶已移除 全新安裝 Windows Vista 時，會移除 Support_xxxxxx 和 HelpAssistant 帳戶，但從舊版 Windows 升級時則會保留它們。Support_xxxxxx 帳戶是用來從支援中心執行指令碼。有些 OEM 自行提供說明內容，也可能會提供專屬的 Support 帳戶。OEM 帳戶的未來並不明朗，但 OEM 很可能完全停止建立這些帳戶。嚴格說，它們不再是必要的。事實上，從安全性觀點，允許使用者以另一個使用者身分從說明中心執行指令碼，並不理想，因此，最好讓這些帳戶消失。Windows Vista 的新機制可完成這項工作。
HelpAssistant 帳戶是用於遠端協助。如同說明中心，遠端協助功能已經重新打造，免除 HelpAssistant 帳戶的需要，因此已將它移除。
新網路位置 SID Windows NT® 型作業系統向來都有一些網路位置型 SID，例如 NETWORK 和 INTERACTIVE，分別表示從網路登入和互動方式登入的使用者。此外，還有 REMOTE INTERACTIVE LOGON SID，指派給透過終端機服務登入的使用者 (請注意，終端機服務使用者的權杖中，實際上同時有 REMOTE INTERACTIVE LOGON 和 INTERACTIVE LOGON)。在 Windows Vista 中，新增兩個 SID：DIALUP 和 INTERNET。新增帳戶來表示撥號登入的使用者，其確切理由有點不明，特別是在只有電話線的網路連線時，越來越多的使用者寧願不上線。無論如何，還是有了這個新帳戶。很明顯地，INTERNET 表示從區域網路以外登入的任何使用者。不過，NETWORK 仍然表示從網路 (包括網際網路) 登入的任何使用者。
OWNER RIGHTS 和擁有者權限 現在也新增了 OWNER RIGHTS SID，它會套用至存取檔案時恰好也是檔案擁有者的使用者。它主要用來限制擁有者處理檔案的方式。相較於 Windows XP，擁有者權限的運作方式有兩個明顯變更。首先，如果您是物件擁有者，但物件上有適用您的 ACE，則 ACE 中的權限會取代擁有者權限。這個重大變更會大幅影響系統管理的特定層面，因為人們習慣於擁有者有隱含權限。第二，OWNER RIGHTS SID 可用來進一步限制擁有者處理物件的方式。
假設有一個資料夾，其擁有者為使用者 Jesper，且其 ACL 如 [圖 2] 所示。使用者 Jesper 只有資料夾的讀取權，儘管他是擁有者。如果他嘗試將檔案複製到其中，複製會失敗，因為 Jesper 沒有寫入資料夾的權限。不過，從錯誤訊息無法直接得知此狀況。如果您嘗試將檔案複製到您所擁有、但沒有寫入權來使用 Windows 檔案總管® 的資料夾時，會發生以下情況：首先，檔案總管會告知您必須提升權限來複製檔案，並且要求提升，但因為您沒有複製到此資料夾的權限，所以檔案複製會失敗。會出現這樣的錯誤訊息：「您須具有執行此動作的權限」，還有兩個按鈕：[重試] (好像有用，其實不成功) 和 [取消]。儘管您是擁有者，仍是這種狀況。
[圖 2] 只有 Local System 和另一個使用者可以存取這個資料夾
[圖 2] 只有 Local System 和另一個使用者可以存取這個資料夾
如果 Jesper 嘗試變更檔案的 ACL，則會提示他提升權杖，以執行這項動作。因為他是檔案擁有者，他可以執行這項動作。擁有者保留讀取和變更 ACL 的隱含權限 (READ_CONTROL 和 WRITE_DAC)，除非 OWNER RIGHTS ACE 另有指示。
為瞭解 OWNER RIGHTS SID 的作用，我將它加入以上的 ACL。現在權限如 [圖 3] 所示。
[圖 3] 將 OWNER RIGHTS 權限加入至資料夾，會變更 Jesper 的權限
[圖 3] 將 OWNER RIGHTS 權限加入至資料夾，會變更 Jesper 的權限
有了這些權限，如果 Jesper 帳戶嘗試複製到資料夾，這項動作會立即成功，因為 Jesper 是擁有者，並有適當權限。但在 Jesper 嘗試變更物件上的 ACL 時，該項動作會失敗！OWNER RIGHTS ACE 會指定擁有者只有 Modify 權限，但沒有修改判別存取控制清單 (DACL) 的能力。因此，OWNER RIGHTS 主要用來移除擁有者的 WRITE_DAC，即修改安全性描述元的能力。
如果系統管理員變更物件的擁有者，OWNER RIGHTS 權限並不會自動移轉至新擁有者。這種狀況下，OWNER RIGHTS ACE 是停用的，其標示為只有繼承，但未套用至容器或物件，換言之，未套用至任何對象。這是為確保系統管理員不致完全鎖在物件之外。若要讓 OWNER RIGHTS ACE 再次生效，Administrator 必須介入，並且手動重新啟用 ACE。若要執行這項動作，您可以視需要將它標示為套用至此資料夾、子資料夾和檔案。
在一些有趣的案例下，OWNER RIGHTS SID 會有幫助，例如當系統管理員要讓使用者能夠在檔案伺服器上建立檔案和資料夾，但不要讓他們能夠變更這些資料夾上的 ACL。另一個可能的狀況是，當使用者曾經是群組成員並建立一些物件，但由於商務原因，稍後從這個群組中移除。這時，他們應該無法修改這些物件的設定。
OWNER RIGHTS 在 Service Hardening 中很普遍地使用。當服務在執行階段建立暫時物件時，物件的建立者是服務程序的主要 SID (通常是 LocalSystem、NetworkService 或 LocalService)，而不是服務本身的 SID。這表示，在相同程序內容中執行的任何其他服務都可以修改物件，這個狀況當然是不樂見的。藉由在這種物件上設定 OWNER RIGHTS SID，OS 可以防止其他服務存取物件。

預設 ACL
Windows XP 的預設 ACL 實際上蠻不錯。除了一些小問題以外 (例如允許使用者在開機磁碟區根目錄中放置檔案)，一般而言都蠻合理的。但有些 OEM 顯然自認為更清楚所謂合理的安全性。[圖 4] 中顯示執行 Windows XP Media Center Edition 的某大 OEM 電腦上，Windows 目錄上的 ACL。OEM 基本上停用檔案系統安全性。
[圖 4] OEM 設定的 ACL
[圖 4] OEM 設定的 ACL
Microsoft 在 Windows Vista 中對 ACL 進行了一些調整。首先，如果您熟悉 Windows XP，您知道所有 OS 檔案都是由 Administrators 群組擁有的，而且系統管理員可以完全控制這些檔案。該群組的成員可以毫無束縛地存取這些檔案。Windows Vista 則不然。
Trusted Installer 在 Windows Vista 中，大部分 OS 檔案是由 TrustedInstaller SID 擁有的，而且只有該 SID 有這些檔案的完全控制權。這是 Windows Vista 系統完整性工作的一部分，特別是為防止以系統管理員或 Local System 身分執行的程序自動取代檔案。若要刪除作業系統檔案，您必須先取得檔案擁有權，接著在檔案上加入可讓您刪除它的 ACE。這會針對以 LocalSystem 執行並有系統完整性標籤的程序提供薄層防護；低完整性層級的程序應該無法提升自身權限來變更擁有權。例如，有些服務可以用中等完整性層級執行，即使執行身分為 Local System。這種服務無法取代系統檔案，掌控其中一個服務的入侵程序也無法取代作業系統檔案，因此比較不容易在系統上安裝 Rootkit 或其他惡意程式。如果系統管理員對某些系統二進位檔很感冒，要移除該二進位檔也會更加困難。
Deny ACE 您會發現檔案系統的許多物件針對 Everyone 都有 Deny ACE，這對許多系統管理員而言是有點嚇人的。如果您開啟 [顯示所有檔案和資料夾] 選項，您會看見熟悉的 Documents and Settings 目錄。但若按一下目錄，您會得到「拒絕存取」的錯誤。若要瞭解 Documents and Settings 上發生的狀況，請參閱 [圖 5] 中的目錄清單。
[圖 5] Documents and Settings 是交叉點，而非目錄
[圖 5] Documents and Settings 是交叉點，而非目錄
Documents and Settings 實際上根本不是目錄，而是交叉點！記得嗎？交叉點與符號連結類似，只是將存取重新導向其他地方。在此，交叉點會導向名為 C:\Users 的目錄。Microsoft 實際上已經大幅修改 Windows Vista 的檔案系統命名空間，使用者資料現在移至 C:\Users。在 "C:\Documents and Settings\<Username>" 舊命名空間之下的其他元素也已經移動。例如，"C:\Documents and Settings\<Username>\Application Data" 已經移至 C:\Users\<username>\appdata\roaming。在命令列使用 dir /a 命令，即可清楚看見這些改變，如 [圖 5] 所示。之所以如此大幅度改變命名空間，是為了讓它更為直覺化，並且把文件與資料更明顯地區別開來。開發人員現在可在使用者設定檔下建立資料夾，讓使用者在此看見資料夾，而不是在 My Documents 資料夾下儲存所有資料檔案。提供給所有使用者的應用程式資料現在移至名為 %systemroot%\ProgramData 的隱藏資料夾，而不是位在 Documents and Settings\All Users\Application Data。
Microsoft 並沒有移除 "C:\Documents and Settings" 命名空間，因為舊應用程式可能硬式編碼為使用該名稱，而不是慣用的環境變數，例如 %USERPROFILE%。如果 "C:\Documents and Settings" 消失，這些應用程式就會掛掉。因此，基於回溯相容性，現在它們表示為交叉點或符號連結。根據應用程式存取上述路徑內資料的方法，硬式編碼這些路徑的應用程式可能仍然會掛掉，但在非英文版的 Windows，這些應用程式已經是損毀的。這確實是關鍵點。當 Windows 更新 (例如 Windows XP SP2 或 Windows Vista) 造成協力廠商程式掛掉時，原因幾乎都是這些程式的開發人員做了無效假設或不當使用 Windows。
如果您嘗試開啟檔案，例如輸入 "C:\Documents and Settings\<Username>\My Documents\foo.txt"，只要該位置有名為 foo.txt 的檔案即可成功。不過，如果您嘗試瀏覽 "C:\Documents and Settings\<Username>\My Documents"，則會取得「拒絕存取」的錯誤訊息。若要瞭解這個狀況，請參閱 [圖 6] 中的 ACL。
[圖 6] 在 Documents and Settings 上有 Deny ACE
[圖 6] 在 Documents and Settings 上有 Deny ACE
看一下清單中的第一個 ACE。這是針對 Everyone 列出資料夾內容的 Deny ACE。程式可以周遊交叉點和開啟具絕對路徑的文件，因為 Everyone 有 [略過周遊檢查] 權限 (又稱為 SeChangeNotifyPrivilege)。由於 Deny ACE，如果使用者或程序嘗試列舉它們所代表的目錄，則會失敗。這正是為何您實際上看不到 C:\Documents and Settings 的內容，也無法刪除此「目錄」。在此放置該 Deny ACE 的主要用意，在於防止使用者刪除該交叉點，並避免舊應用程式掛掉。此外，它也可以提醒開發人員不要將應用程式硬式編碼為使用舊命名空間，而要開始使用環境變數或登錄字串，以隔絕應用程式不受任何未來變更和語言差異的影響。
請注意，根據預設所有交叉點都是隱藏的，因此大多數使用者絕不會看見它們。為避免使用者刪除它們，Microsoft 針對「列出資料夾」放置 Deny ACE。
略過周遊檢查 使用者可以在無權限的資料夾 (或交叉點) 中存取有權限的檔案，原因是 Everyone 有 [略過周遊檢查] 權限。略過周遊檢查 (或 SeChangeNotifyPrivilege) 實際上是 Windows 最基本的權限，已移除所有其他權限的程序會被授予此權限，除非該程序特別要求一併移除該權限。當您在 Windows Vista 中使用 runas /trustlevel:0x10000 < 命令時，會發生以下的情況。在 <command> 中指定的程式會以受限權杖執行，並且除了 SeChangeNotifyPrivilege 以外的所有權限都會從程序權杖中刪除。
有趣的一點是，trustlevel 0x20000 會授予一組正常但刪除權限之 SID 的權杖。0x40000 則會授予完全正常的權杖。

預設權限
在 Windows Vista 中檔案系統上的預設權限與 Windows XP 有點不同。如果您查看 %systemdrive% (通常是 C: 磁碟機，即開機磁碟區) 上的 ACL，在 Windows XP 或 Windows Server® 2003，您會看到以下內容 (在舊版 Windows XP 則是非常類似的內容)：
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
在 Windows Vista，相同目錄上的相同 ACL 則是如下：
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
有些差異值得注意。首先，現在 BA (BUILTIN\Administrators) 有兩個 ACE，而不只有一個。但最終結果是相同的。在 Windows Vista 中，其中一個 ACE 是非繼承的並會授予根目錄的完全存取權，另一個 ACE 則是 IO (僅繼承) ACE，由容器和物件所繼承，並會授予 GA (全部一般化或完全控制)。SY (LocalSystem) 的一個 ACE 在 Windows Vista 中被取代為兩個 ACE，也是相同道理。在 Windows XP 中，單一 ACE 授予完全存取，並且由物件和容器所繼承。同樣地，最終結果並未改變。ACL 之所以變更，主要原因是要釐清並分隔權限，讓 ACL 更容易管理，甚至還可能還原。
更有趣的一點是，CO (Creator/Owner) 的 ACE 已經消失。這表示，如果使用者在檔案系統根目錄中建立物件，建立者不再獲得累加的特殊權限。
您也會看見 WD (Everyone) 的 ACE 已遭移除。許多關心安全性的人們過度擔心該 ACE，儘管不十分瞭解其動作的含義。Microsoft 多年來努力解釋，Everyone 在功能上與內建 Users 雷同，但他們最後似乎還是放棄了，完全移除該 ACE。因為 BU (BUILTIN\Users) 有相同的 ACE，也是由容器和物件所繼承，所以最終結果是沒有任何變更。
此外，BU (內建 Users) 的兩個 ACE 已經取代為 AU (Authenticated Users) 的 ACE。原因是 Guest 帳戶是內建 Users 的成員 (由於 INTERACTIVE 是內建 Users 的成員)，但 Guest 不是 Authenticated Users 的成員。為了要讓 Guest 帳戶讀取和執行檔案，0x1200a9 (作用上為讀取和執行) ACE 仍然會被授予給 BU。不過，授予建立檔案和資料夾之權限的 ACE，轉而授予給 Authenticated Users。這點與 Windows XP 截然不同。在 Windows XP 中，Guest 可在根目錄中建立檔案。在 Windows Vista 中，Guest 則無法建立這種檔案。但請記得，除非 Guest 帳戶已啟用，而且訪客有辦法到達開機磁碟區根目錄，否則這一切都是無意義的。根據預設，Guest 帳戶是停用的。
好戲還在後頭，在上面的兩個清單中，有幾個非常有趣但可能很棘手的 ACE。在 Windows XP 中，有一個 ACE 是由容器所繼承，其針對內建 Users 指定 0x100004。該 ACE 會授予 Users 建立子資料夾及其子資料夾等的權限，因為它是由容器繼承的。此外，也有一個 0x100002 的僅繼承 ACE，由子資料夾所繼承。該 ACE 授予使用者權限，以便在根目錄下他們所建立的資料夾中建立檔案和子資料夾。換言之，如同先前提及的，這兩個 ACE 都允許使用者 (包括 Guests) 在根目錄中建立檔案和資料夾。
在 Windows Vista 中，對應的 ACE 是僅繼承 ACE，其由容器和檔案所繼承，並會授予 GR (一般讀取)、GX (一般執行) 和 GW (一般寫入) 連同 SD (讀取安全性描述元)，以及只套用至根目錄本身並會授予 LC 權限的 ACE。LC 實際上是隸屬於 Active Directory® ACE 的縮寫。在 Active Directory 中，它表示使用者可以列出子物件。不過，LC 的十六進位值為 0x4。對於目錄，0x4 表示 FILE_ ADD_SUBDIRECTORY，在功能上相當於 0x100004，因為我們已經有來自 0x1200a9 ACE 的 0x100000 (即使用物件進行同步的能力)。換言之，它的效果和在 Windows XP 中完全相同，即使用者可在根目錄中建立子目錄。
十六進位值從何而來？到底有哪些十六進位值呢？您一定已經注意到，存取控制充滿著十六進位 (base16) 數字，如 0x1200a9。這些實際上是存取遮罩中設為「開啟」之位元的位元遮罩表示，指出它們用於特定的 ACE。當您使用工具 (例如 icacls、sc 或 secedit) 列出 ACL 時，如果有 1:1 相符項目，位元遮罩就會由易懂的文字字串所表示。
因此，若要判斷 LC 的意義，您只需前往 MSDN® 網站、尋找 LC 字串，即可在 Access right value 欄中找到 ADS_RIGHT_ACTRL_DS_LIST。如果您接著開啟 Iads.h 標頭檔，並尋找該字串，您會發現它對應到 0x4。對於非 Active Directory 字串 (開頭不是 "ADS_RIGHT")，一般會在 AccCtrl.h 中找到十六進位值。有了十六進位值後，就很容易查閱 WinNt.h 或 AccCtrl.h 中的存取遮罩，以瞭解其意義。
如果您需要相關說明，請參閱 Protect Your Windows Network 一書 (Jesper Johansson 和 Steve Riley，Addison-Wesley，2005)。第 17 章深入探討如何分析安全性描述定義語言 (SDDL) 字串和 ACE。
授予子目錄的權限在 Windows Vista 中是單獨由 (A;OICIIO;SDGXGWGR;;;AU) ACE 控制的，這是 Windows Vista 和 Windows XP 之間最大的差異。不同於 Windows XP 授予完全控制給子目錄的建立者，Windows Vista 會授予修改權給已驗證的使用者。
此新 ACL 的最終結果是，物件的建立者不再有任何特殊權限，而且情況更為清楚。或許最大的變更是，Authenticated Users 有系統管理員所建立之子資料夾的修改權，這點與 Windows XP 大為不同。在 Windows XP 中，Users 和 Authenticated Users 對於系統管理員在根目錄中建立的物件，沒有任何權限。整體而言，這些 ACE 似乎有些麻煩，但最終結果與 Windows XP 的差異並不大。
摘要說明如下，在 Windows Vista 中，所有人 (包括 Guest 使用者) 都可以讀取和執行根目錄中的檔案。只有已驗證的使用者可以建立檔案和資料夾，當使用者這樣做時，他們會取得這些檔案和資料夾的修改權。換言之，Windows Vista 的權限比起 Windows XP 稍微嚴格，但值得注意的是，Guest 帳戶預設是停用的。

權杖變更
在 Windows XP 中，身為 Administrators 群組成員的使用者登入時，他的權杖包含 Administrators 群組 SID，而且他可以執行 Administrators 群組所能執行的任何動作。另一方面，在 Windows Vista 中，由於使用者帳戶控制，這個情況不再適用。Administrators SID 仍然出現在權杖中，但已設為 [拒絕]，如 [圖 7] 中 Process Explorer 的螢幕擷取影像所示。
[圖 7] 在 UAC 控制之下，除非提升權限，否則 Administrators SID 只用於拒絕存取
[圖 7] 在 UAC 控制之下，除非提升權限，否則 Administrators SID 只用於拒絕存取
在執行存取控制時，權杖中的這種項目只用於拒絕存取，換言之，以符合 DENY ACE。該 SID 的任何允許 ACE 都會遭忽略。這表示，即使您以系統管理員身分登入系統，也不一定總是系統管理員。

整合等級
Windows 現在支援以整合等級標示程序和物件。整合等級實際上也會表示為 ACE，但不是在 DACL 中。而是系統存取控制清單 (SACL) 的一部分，並且具有一些特殊旗標。例如，NW 旗標是用來表示封鎖低整合等級的程序，以免寫入高整合等級的物件 (SDDL_NO_WRITE_UP)。Mark Russinovich 在本期 TechNet Magazine 的＜深入探索 Windows Vista 使用者帳戶控制＞文章中將詳細說明這點。

總結
雖然 Windows Vista 的存取控制沒有像 Windows 2000 一樣石破天驚的修改，但有許多小幅變更。它們分開來看可能不算什麼，但整體而言則意謂著您需要重新思考管理系統的方式。而且，這些變更支援一些創新，特別是 UAC 和 Service Hardening。有些系統管理員在一開始使用 Windows Vista 時可能會非常挫折。我曾經看過「專制的作業系統」等類似評語，因某種原因，Windows Vista 限制刪除作業系統組件的能力，似乎很令人反感。但所有變更都有原因，只要您花點時間分析這些改變，即可明白。

Jesper Johansson是一家大型電子商務公司的資訊安全架構設計師，負責不同屬性和服務的應用程式安全性策略。他從事資訊安全相關工作長達 20 年，著有兩本有關資訊安全的書籍和許多文章。在工作之餘，他還教授潛水。


 安全性: 透過群組原則管理硬體限制
安全性 Jeremy Moskowitz

透過群組原則管理硬體限制
摘要:
  • 限制硬體安裝
  • 限制特定裝置
  • 限制裝置類別

您知道的：USB 隨身碟和卸除式媒體讓您的私人生活更輕鬆，但專業生活更困難。您需要方法，控制哪些
硬體裝置可安裝、哪些不可安裝。所幸，使用 Windows Vista™ 和下一版 Windows Server® (代碼 "Longhorn") 中的群組原則，您就可以選擇允許 USB 滑鼠但禁止 USB 隨身碟、允許 CD-ROM 讀取器但禁止 DVD 燒錄器，或允許藍芽但禁止 PCMCIA。
群組原則中有兩個部分可協助您保護硬體安全：[電腦設定] | [系統管理範本] | [系統] | [卸除式儲存裝置存取權] (請參閱 [圖 1])，以及 [電腦設定] | [系統管理範本] | [系統] | [裝置安裝] | [裝置安裝限制] (請參閱 [圖 2])。
[圖 1] 群組原則中預先定義的硬體限制
[圖 1] 群組原則中預先定義的硬體限制
[圖 2] 自訂您要限制的硬體類型
[圖 2] 自訂您要限制的硬體類型
第一組 ([卸除式儲存裝置存取權]) 是不解自明的：如果您為該類型的卸除式儲存裝置 (CD/DVD、軟碟機等等) 啟用原則設定，可視需要限制整個裝置類型的讀取和/或寫入。但它沒有 [裝置安裝限制] 的超強能力。
在 [卸除式儲存裝置存取權] 中，有兩個原則設定群組，名為 [自訂類別: 拒絕讀取存取權] 和 [自訂類別: 拒絕寫入存取權]。這聽起來蠻好的，但 [卸除式儲存裝置存取權] 原則實際上不會阻止安裝驅動程式，在偵測到硬體時，該類別的驅動程式已安裝。該原則只是防止讀取或寫入裝置。等到下一節探討 [裝置安裝限制] 原則設定時，我會鎖定整個驅動程式本身的使用。

瞭解類別和識別碼
首先，最重要的事：您必須知道要限制什麼。考慮的範圍可大可小。也就是說，您可以限制特定「類別」的裝置，或極為明確地限制單一硬體類型。或者，您可以反其道而行，只允許特定裝置類別，如 USB 滑鼠。但有個竅門：您必須追蹤要限制的硬體，才會有效。
如果您要禁止安裝搖桿驅動程式，只允許安裝 USB 滑鼠，則必須掌握搖桿和 USB 滑鼠。替代方案是透過網際網路來追蹤硬體識別碼、相容識別碼或裝置類別。不過，如果您眼前有實體裝置會容易得多。如此一來，您可以將它連接到電腦，並親自查看硬體識別碼、相容識別碼或裝置類別。一旦得到此資訊，您就會確切知道如何抑制或保留其可用性。
在下列範例中，我將抑制特定的音效卡系列：Creative AutoPCI ES1371/ES1373。如果您想要抑制其他項目 (如特定 USB 裝置、USB 連接埠等等)，只要在下列步驟中，換成這些特定項目即可。
在已安裝該硬體項目的電腦上，啟動 [裝置管理員]。當您找到裝置時，以滑鼠右鍵按一下它，選取 [內容]，然後選取 [詳細資料] 索引標籤。根據預設，您會看到 [裝置描述]。有趣的是，這項資訊不太實用。選取 [內容] 下拉式清單，並選擇 [硬體識別碼]，如 [圖 3] 所示。
[圖 3] 裝置的 [詳細資料] 索引標籤
[圖 3] 裝置的 [詳細資料] 索引標籤
[硬體識別碼] 頁面會從上到下顯示最明確到最籠統的裝置識別碼。如果您仔細看一下 [硬體識別碼] 值清單中的最上方項目，您會看到這個音效卡最明確的識別是 ES1371 音效卡 Rev 2。真的很明確。在清單下方，描述會變得籠統，以涵蓋整個系列。
而且，您可以將 [內容] 變更為 [相容識別碼]。相容識別碼也會描述硬體，比起 [硬體識別碼] 較不明確。您可以選擇使用 [相容識別碼] 中的資訊，嘗試將更多類似的硬體關進您的禁用清單，因為它比較籠統，可能會獲得更多結果。當然，其中取捨是您可能會限制非預期的項目。
最後，從 [內容] 下拉式清單中選取 [裝置類別] 時，會得到最籠統的類別。在這個案例中，音效卡僅僅顯示為 [媒體]。但是有許多項目都會被視為 [媒體]，因此您應該更謹慎處理籠統的類別。
一旦決定所要使用的值，請以滑鼠右鍵按一下它，選取 [複製]，然後將它貼入 [記事本] 中存放。直接複製完整顯示的值很重要，因為在下面的步驟中必須輸入完全相同的值。值的所有大小寫字元都必須精確移轉。
如果您要使用命令列，而不使用 [裝置管理員]，以擷取 [硬體識別碼] 或 [裝置類別]，請參閱下列網址的 Devcon 命令列公用程式：support.microsoft.com/kb/311272。如果您沒有實體裝置，Microsoft 有一些通用類別的識別碼可能有幫助，請參閱下列網址的資訊：go.microsoft.com/fwlink/?LinkId=52665。

透過群組原則的硬體存取控制
雖然我們將探討位在 [電腦設定] | [系統管理範本] | [系統] | [裝置安裝] | [裝置安裝限制] (如 [圖 2] 所示) 中的所有原則設定，但實際上只需要一個原則設定，即可完成第一個範例。
首先建立群組原則物件 (GPO)，將它連結到要控制的 Windows Vista 電腦所在 OU (或網域等)。現在編輯 GPO，並向下切入 [電腦設定] | [系統管理範本] | [系統] | [裝置安裝] | [裝置安裝限制] | [防止安裝符合這些裝置識別碼的裝置]。在原則設定中選取 [啟用]，按一下 [顯示] (也是在原則設定中)，接著在 [顯示內容] 對話方塊中選取 [新增]。在 [新增項目] 對話方塊中，貼上您先前儲存的裝置資訊，如 [圖 4] 所示。
[圖 4] 貼上裝置識別碼以確切擷取描述
[圖 4] 貼上裝置識別碼以確切擷取描述
不過，這裡有個奇怪的現象。如果電腦上已安裝此裝置，並不會神奇地將它解除安裝並限制存取。因此，如果您要限制硬體，最好在部署 Windows Vista 後盡早完成。不過，值得注意的是，在移除裝置後重新安裝時，Windows Vista 將會重新檢查。像是 USB 隨身碟 (移除後重新插入) 的項目便是此程序的完美候選項目。因為 Windows Vista 只在重新連接裝置時重新檢查，這時候才會限制裝置 (即使裝置驅動程式一開始已載入電腦)。比較難處理的裝置是搭載在電腦上，而且不會移除後再重新連接的裝置。對於這些裝置，目前並沒有明顯的解決方案。
如果電腦開機時偵測到新的硬體裝置，Windows 會嘗試安裝驅動程式，並在過程中提供狀態資訊。如果您已經設定原則來限制這種裝置，就會看到 [圖 5] 中的結果。
[圖 5] 被禁止的裝置安裝作業
[圖 5] 被禁止的裝置安裝作業

更多的硬體限制
在以上的範例中，我們只抑制一個裝置。如果您想要的話，可以採取相反路線，根據預設限制所有硬體，接著允許部分硬體。同樣地，您會看到 [圖 2] 中的原則設定清單，其顯示群組原則的 [電腦設定] | [系統管理範本] | [系統] | [裝置安裝] | [裝置安裝限制] 分支。您可以從數個可用設定中選擇。
首先是 [允許系統管理員覆寫裝置安裝限制]。根據預設，Windows Vista 的本機管理員必須遵循已設定的限制。如果您啟用這個設定，本機管理員就可以覆寫限制並安裝他們所要的硬體。
接下來是 [允許使用符合這些裝置安裝類別的驅動程式安裝裝置]。藉由在此原則設定中輸入裝置描述，您會明確允許在系統上安裝這些裝置。請注意，這個原則設定只接受安裝類別，而非裝置識別碼 (如範例中所使用)。
若要達成相反的效果，您可以設定 [防止使用符合這些裝置安裝類別的驅動程式安裝裝置]。
[因原則而無法安裝時顯示自訂訊息 (汽球內文)] 和 [因原則而無法安裝時顯示自訂訊息 (汽球標題)] 這兩個設定有助於自訂訊息，如 [圖 5] 所示。
如先前提及的，描述硬體最籠統的方式是基於硬體類別。值得注意的是，[允許安裝符合這些裝置識別碼的裝置] 原則設定不會接受類別識別碼描述。若要使用類別識別碼描述，請使用 [允許使用符合這些裝置安裝類別的驅動程式安裝裝置] 或 [防止使用符合這些裝置安裝類別的驅動程式安裝裝置]。後者最適合與 [防止安裝未由其他原則設定描述的裝置] 設定搭配使用。藉由防止安裝所有項目 (根據預設)，接著使用此設定，您可以精確指定要允許的裝置。
在範例中，我使用 [防止安裝符合這些裝置識別碼的裝置] 原則，根據裝置識別碼來限制特定類型的硬體。如果您要使用裝置類別來實作限制，則必須運用其他特定的原則設定，例如 [允許使用符合這些裝置安裝類別的驅動程式安裝裝置] 或 [防止使用符合這些裝置安裝類別的驅動程式安裝裝置]。
[防止安裝卸除式裝置] 是限制任何自我描述為卸除式硬體裝置 (包括 USB 裝置) 的快速、一般方法。這個設定很籠統，最好不要經常使用。請改用先前描述的技巧，亦即取得較為嚴謹的裝置識別碼，接著明確地鎖定。
最後，[防止安裝未由其他原則設定描述的裝置] 是一網打盡的原則設定，基本上它會限制所有硬體，除非您特別指示可安裝某項目。這個原則搭配各種「允許」原則 (例如 [允許安裝符合這些裝置識別碼的裝置])，會成為在環境中只允許所要硬體的強大工具。

結論
Windows Vista 的群組原則有一些新的超強功能，在環境中只允許所要硬體時極為實用。只要在初期部署時實作原則設定，您在網路中禁止的硬體絕對無法連接。
訪問 Microsoft 群組原則的部門經理 (Lead Program Manager) Michael Dennis
我最近有機會訪問 Michael Dennis，自從 Microsoft 群組原則團隊成立以來，他一直帶領此團隊。Michael 目前要離開群組原則團隊，轉調 Microsoft 內部的其他職務。我與 Michael 面對面，回想過去九年的群組原則，立足過去，放眼未來。

Jeremy Moskowitz Michael，很多人想知道您在 Microsoft 領導群組原則團隊的這幾年來，您認為最大的成就是什麼？

Michael Dennis 最大的成就要回溯至當我們關注於開發現在所謂群組原則的時候。當時已經有 Windows NT® 4.0 的系統原則，因此我們檢視它及其問題。因為當時是在 Active Directory® 開發期間，我們檢視需要更佳處理用戶端和伺服器管理性的地方。
理論上，群組原則是建立在階層中，但這個想法從未實現過，因此對我們來說是大挑戰。我們專注於核心基礎結構、用戶端處理程序和 Active Directory 整合。
最大成就的副產品也是我們的最糟成績。因為隨著 Windows 2000 提供的 GUI 有問題。人們需要群組原則的博士學位，才能有效使用它，因為管理員必須知道完整運作原理。我希望當時我們能建立「群組原則管理主控台」(GPMC) 和「原則結果組」(RSoP)，並重新交付 (這些都已在規格中)。

JM 您希望哪些項目能併入群組原則中呢？

MD 好消息是，打從 Windows 2000 版本開始，我一直想要的項目現在都已併入 Windows Vista，像是 RSoP、GPMC、增加的設定等等。我希望能早個幾年完成這些項目。
此外，我希望群組原則基礎結構更能由合作夥伴輕易延伸。我們的伺服器端/用戶端延伸模型需要開發人員投入更多心力。不過，有人認為我們的 ADM/ADMX 範本結構提供了太容易延伸的架構。但系統的這一部分若能讓人們延伸更多類型的設定，應該會更棒！
此外，我也希望 GPMC 報告對合作夥伴和協力廠商工具開發人員而言更能延伸。工具協力廠商一直很關切這個領域。

JM 哪些事是群組原則團隊不為人所知的？

MD 有時，人們不清楚群組原則團隊在整體中所扮演的角色。理論上，我們建立基礎結構、傳輸，以及伺服器和用戶端組件。單單 Windows Vista，我們就曾經與 Microsoft 的大約 120 個不同團隊合作，使新設定在此版本就位。
讀者應該注意，對於開機或登入時系統變慢的問題，不應責怪群組原則。如果變慢，應該責怪群組原則的工作內容。因為當您要求群組原則執行重量級作業時，它就真的會執行它。例如，如果您告訴它在每部電腦上安裝 Microsoft Office，這當然可以。但是您要知道它會執行所要求的作業，也就是在您看到登入提示前安裝所有 Office 應用程式。那會變慢嗎？當然，但身為部署的管理員，這正是您要系統執行的。

JM 您最喜歡使用群組原則來炫耀哪個項目呢？

MD 這些日子，我喜歡賣弄 Windows Vista 中的一些新設定。卸除式裝置設定 (限制 USB 隨身碟之類的項目) 是人們一直吵著要的項目。在 Windows Vista 中，大約有 2,400 個設定，這些帶給管理員大幅控制。我喜歡問客戶，他們想要控制什麼，接著向他們展示做法。

JM 為什麼將 ADM 變更為 ADMX 檔案呢？

MD 技術上，我們並不需要那樣做，即可搭配 Windows Vista 新的集中存放區功能。轉換為 ADMX 的推動力是為了適當支援多個語言。
先前，在多語言環境中常會發生一種情況，就是 GPO 內部 ADM 檔案的內容可能是由其他語言撰寫。從歷史角度，我們從 Windows NT 4.0 借用 ADM 格式，Windows NT 4.0 從 Windows 98 借用，Windows 98 從 Windows 95 借用。如果當時有 XML，它會是不錯的候選檔案格式。
現在有了 XML，支援多個語言變得更容易，而且也提供機會，以目前結構描述化語言來加強登錄和設定。

JM 在 GP 團隊中工作時，您必須克服的最大內部挑戰是什麼？

MD 本團隊面臨的最大、持續性問題是嘗試讓 Windows 的其他元件透過原則啟用其功能。
某個團隊可能會回應：「我們剛建立這個很棒的新功能。為什麼有人要關閉它呢？」這是可理解的。但我們繼續努力，克服許多問題。
此外，也有關於透過原則啟用某些項目的技術挑戰，例如，具有進階安全性的 Windows 防火牆 (WFAS)。WFAS 很棘手，不容易透過原則正確啟用它。WFAS 團隊為 Windows Vista 建立的介面極佳，但把它做好很棘手。
在 Windows Vista 之前的 Windows 版本中，產品團隊本身不一定會想要透過原則啟用他們的元件。但在 Windows Vista 開發期間，有不少團隊詢問我們相關做法。太棒了！
JM 您的下一步是什麼？

MD 我即將調至「行動資訊工作者」(Mobile Information Worker) 團隊，他們負責 Smartphone、Pocket PC 等等。我的角色將會是延伸 Windows Server 系統的部分管理技術至 Windows Mobile® 裝置。
我會試著將我對管理性的相同願景和熱情應用在新領域中。同時，我所離開的群組原則團隊正處在大有進展的重要地位。

JM 您還想要告訴讀者什麼事情嗎？

MD 在群組原則的整個開發期間，有一個重要步驟就是面對客戶，真正瞭解他們嘗試做什麼。如果客戶有任何想要讓群組原則涵蓋的案例，或是商務案例，請與我們連絡、交流意見。
在 WindowsServerFeedback.com，我們有良好的意見反應機制，所有人都可以使用。請在其中找出 [Group Policy] 按鈕。
如果能夠清楚說明：「我的問題如下，我的商務案例如下，而且我需要系統能夠這樣做，原因如下。」這種資訊對我們非常珍貴。群組原則發展的決策者會閱讀來自此機制的各項意見。
同樣地，如果您想要對群組原則發展有所影響，請告訴我們您的需要。但是，請不要只告訴我們：「我們需要會執行 X 的原則設定」，而不告訴我們理由。我們的工作是想出「做法」。群組原則團隊真正需要知道的是「原因」。
JM 感謝您抽出時間，告訴我們您在 Microsoft 群組原則團隊的經驗。祝一切順利！
MD 謝謝您，Jeremy。

Jeremy Moskowitz為群組原則中的 MCSE 和 MVP，他經營的 GPanswers.com 是有關群組原則的社群論壇。此外，他還舉辦一系列的群組原則密集訓練課程。他的最新著作為 Group Policy: Management, Troubleshooting and Security (Sybex, 2007)。您可以透過下列網站連絡 Jeremy：www.GPanswers.com。


 安全性: 每個 IT 組織必須擁有的 4 項安全性技術
安全性 Matt Clapham and Todd Thompson

每個 IT 組織必須擁有的 4 項安全性技術
摘要:
  • 風險管理儀表板
  • 防惡意程式
  • 網路異常偵測

談到 IT 安全性，大部分企業幾乎都面臨相同的問題。Microsoft 也不例外。我們有兩年時間待在
Microsoft® Managed Solutions (MMS) 的風險管理與規範團隊 (如需有關 MMS 的詳細資訊，請參閱 Microsoft 為 Energizer 的 IT 部門充電)。
風險管理與規範團隊負責定義、監視和修正所有 MMS 環境的風險狀況 (包括要面對客戶的服務項目和基礎結構協調)。很早我們的主管 Arjuna Shunn 認為我們需要技術解決方案，以提供所需控制項，並透過集中且一致的方式進行監控。在此討論的技術是我們早年想法的直接結果，加上在作業中使用各種 Microsoft 和協力廠商產品的兩年經驗。
首先，我們需要的安全性技術涵蓋三大控制類型：預防、偵測和修正，並會提供稽核和報告。我們將這些工具分成四大類：風險管理儀表板、防惡意程式、網路異常偵測和目標建構管理。我們嘗試在風險管理作業中至少納入每個類型的一個代表。我們發現，藉由運用這四個領域的技術，IT 安全性團隊可在成本和有效性之間達成合理的平衡。
有兩項主要風險管理作業從這個方法受益良多：安全性事件回應和規範管理，但在達成工具協調方面，我們仍有一段長路要走。一套協調一致的技術集合可以對作業效率貢獻良多，但可惜業界還沒有這種整合系統。
所幸，對於 IT 安全性團隊，這不等於完蛋，遲早這四個系統會開始合作並相互操作，以達成更大的作用。一旦這些系統共同合作，它們不僅能主動監視系統安全性狀況，在稽核或其他例行 IT 作業中還可派上用場。本文將描述每個系統的理想功能，穿插一些執行階段使用的範例。

風險管理儀表板
依我們之見，風險管理儀表板 (RMD) 絕對是必要的。它是 IT 安全性團隊作業中一個最重要的技術。企業中的機密性、完整性、可用性和責任性 (CIA2) 風險通常由不同系統和程序所監視，並沒有一個用於資料彙總、相互關聯和風險修復的整合介面。此外，法規需求也使得企業資料透明化的難度逐漸增加，目前也沒有精簡的系統可立即追蹤從建立到企業執行的原則。我們可以從資料擷取、相互關聯、評估、修復和符合規範等企業共同的難題上，得到佐證 ([圖 1] 所示的 System Center Operations Manager 2007，雖然還不足以成為前述的 RMD 解決方案，但確實提供了單一介面可監視多個資源並收集相關警訊)。
[圖 1] System Center Operations Manager 2007 提供檢視警訊和管理網路資源的單一介面
[圖 1] System Center Operations Manager 2007 提供檢視警訊和管理網路資源的單一介面
由於無法從不同來源彙總和正規化資料，資料擷取會受阻。資料彙總本身具挑戰性，因為它必須突破普遍的筒倉式資訊儲存 (Siloed) 方法來收集和報告資料。即使完成了資料彙總，正規化更具挑戰，因為建立支援資料正規化所需的通用架構極為困難。沒有正規化，就不可能以有意義的方式比較來自不同系統的安全性和狀態事件。
若要執行必要的自動化，風險管理儀表板必須能存取本文所述安全性技術之外來源的資料摘要。很多非安全性資料可用於判斷整體風險狀況。像是路由器記錄、資產追蹤、修補狀態、目前登入使用者、效能報告和變更管理資料等資訊，都會為事件調查員提供相關資訊。因此，整體系統必須能夠存取上述所有資料。我們知道，即使幾乎以 Microsoft 產品為中心的企業基礎結構都包含非 Microsoft 技術，因此 RMD 必須透過特定通用介面接受來自非 Microsoft 技術的資料摘要。
如果可擷取和正規化資料，下一步是相互關聯。目標是將一連串事件 (例如網路異常事件、防毒報告事件和目標建構變化事件) 相互關聯為一項可執行動作的風險相關資料。這需要密集的人力，以便建立相互關聯邏輯，來產生有意義、以風險為基礎的警訊。根據目前可用技術，這項相互關聯邏輯可能是難以達成的。
評估資料也需要密集的人力。在發生相互關聯時，分析師必須檢視相關聯的資料，決定其效力。相關聯資料的效力只與其依據規則之效力一樣強。因此，相關聯資料的分析也需要人力，以評估 IT 環境風險。明確、編碼化的風險管理架構有助於達成分級，並可降低所需的人力介入。如果沒有這個架構，在實作中將難以開發一組實用的相互關聯規則。
假設系統已達成評估風險，下一步是自動化修復。目前，這只在企業中使用，而且只有少數技術，例如修補管理或防毒。由 RMD 系統前導的自動化修復會提供 IT 管理員絕佳的能力，將 IT 風險維持在可接受的程度。同時識別多個風險時，相互關聯邏輯應該能根據資產分類資料來排列事件回應的優先順序。
最後，提供符合各種法規需求之證明，對 IT 部門也是大挑戰，如先前提及的，此系統應該支援此功能。結合原則的集中式風險管理系統，會成為產生報告和符合規範之證明的絕佳資產。但原則必須不僅是有關位置和原因。為促進自動化修復，原則必須轉換成儀表板可監視、強制執行和提供回應的一組標準。
因此，我們可以總結如下：理想的風險管理儀表板應該為企業狀態評估、規範和原則的符合度以及風險管理流程提供一致的介面。這是藉由將不同安全性產品、狀態相關產品和來源的資訊組合成一個協調一致的顯示方式來達成的。良好的 RMD 解決方案必須執行下列動作：
  • 從不同來源彙總、正規化和相互關聯資料
  • 提供自動化資訊收集和風險評估
  • 將法規需求對應至原則，並且支援稽核和報告
  • 提供統一、可修改以符合企業需要的架構
儀表板應該能以有意義的方式整理和顯示資料，例如依類型或來源系統依序顯示重大事件、擱置事件、已解決事件等等。它也應該讓您切入每個報告項目，以取得詳細資料。檢視事件時，使用者應該能輕鬆存取所有相關資料。這會改善並加速決策過程。
我們要指出，RMD 對安全性團隊之外的管理員也有幫助。因為儀表板涵蓋整體環境的檢視，所以 RMD 可做為所有員工檢視目前狀態的中心點。例如，儀表板可提示訊息團隊，在 SMTP 閘道發生拒絕服務攻擊。對風險管理團隊而言，這是安全性事件，但訊息團隊會將它視為可用性事件。雖然訊息團隊可能不必負責解決這種事件，但他們至少會想要知道類似事件對該團隊所管理資產的影響。

防惡意程式技術
完善的防惡意程式系統可保護基礎結構，避免隱藏在程式碼和使用者動作中的非預期威脅。目前，有兩大類型的工具可防禦惡意程式：防毒軟體和防間諜軟體 (例如，如 [圖 2] 所示的 Windows® Defender 落在第二類)。這兩種工具都會有效防止、偵測和修正不同類型的感染。不過，這兩種類型的保護遲早會整合為一個解決方案，系統上將會只有一個防惡意程式堆疊。
[圖 2] Windows Defender 有助於保護用戶端，預防間諜軟體入侵
[圖 2] Windows Defender 有助於保護用戶端，預防間諜軟體入侵
縝密的防惡意程式解決方案必須即時監視並定期掃描。它應該根據一般風險行為，以集中方式報告已知惡意程式 (包括病毒、間諜軟體和 Rootkit) 和未知的惡意程式。健全的防惡意程式技術會透過與 OS 和應用程式的緊密整合，監控所有典型的進入點 (包括檔案系統、登錄、殼層、瀏覽器、電子郵件和連接的應用程式)。
此外，防惡意程式解決方案不僅要涵蓋主機安全性，它還需要監控受感染檔案經常通過的一般訊息和協同作業服務，例如 SharePoint® 和即時訊息。它也必須提供自動化預防，藉由停止作業 (已知的和可疑的)，並且仔細掃描使用者資料，以移除隱藏在使用者文件、尚未傳染給系統的巨集病毒之類的東西。
沒有保持更新的防惡意程式當然是無用的。系統必須更新病毒碼和移除系統，以保持搶先最新威脅一步。如果出現新威脅，廠商應該在下一個零時差威脅發作之前設定其他適當保護措施。容易管理的防惡意程式解決方案應該也是可集中設定和更新的。
當然，這種保護不能犧牲效能。如果犧牲效能，生產力也會受害。使用者甚至可能嘗試停用防惡意程式解決方案，導致毫無保護。
最後，不要忽視輔助技術在協助防惡意程式系統的重要性。防火牆、限制使用者權限和其他策略都會加強保護，免於惡意程式碼和使用者動作的入侵。

網路異常偵測
防惡意程式會注意系統，網路異常偵測 (NAD) 則會監視一般路徑，監控可疑行為的已知指標，並會向 RMD 報告此資訊以進行修復 (例如，如 [圖 3] 所示的防火牆即屬於此類別)。可疑行為可能是透過電子郵件傳送的已知攻擊流量 (例如蠕蟲或拒絕服務攻擊) 或是符合特定模式的資料 (例如美國社會福利編號)。
[圖 3] 防火牆是網路異常偵測解決方案的重要部分
[圖 3] 防火牆是網路異常偵測解決方案的重要部分
儘管 IT 管理單位已盡力而為，任何大型企業網路仍難免遇到偶發的惡意程式事件。NAD 可以提供初期警告系統，有助於加速修復。而且，NAD 資料監視功能，以及識別和停止機密資訊外洩的能力，對於關心資料外洩和法規符合的環境，是保護資訊的有用工具。
如同反惡意程式技術，NAD 也必須經常根據最新威脅和機密資料類型進行更新，否則價值會大為降低。此外，良好的 NAD 系統應該瞭解哪些情形才是屬於實際異常，以將誤報數目降至最低。否則，管理員可能認為每個 NAD 報告都是誤報，開始忽略報告。
在微調或訓練之後，NAD 系統應該知道並監視一般流量使用模式。這點很重要，因為新類型的惡意程式和其他攻擊可能會變更使用模式而暴露自身。網路設備在整體 NAD 系統中扮演重要角色，因為解決方案必須處理來自路由器、交換機和防火牆的資料。接著 NAD 警訊會由 RMD 的相互關聯引擎處理。
一個有趣的可能性是將網路異常偵測器建置在主機的防惡意程式軟體或防火牆，形成一個保護網，使範圍內的電腦都會協助監視，並可能會在攻擊散佈之前停止攻擊。

目標建構管理
在大型企業中，IT 部門面對的最大挑戰之一是保持系統適當設定。有很多動機想要維護系統設定，包括容易管理、簡化延展性、確保符合規範、鎖定各種形式的入侵、提高生產力等等。許多原因都是安全性的重要因素。
由於複雜性和開創成本，目標建構管理在大部分企業中多為未開發的領域。但研究顯示，長期來看，維護系統可節省成本並改善可靠性。目標建構監控 (DCM) 解決方案會有幫助。
良好的 DCM 系統應該自動掃描網路，確定新系統適當部署，並驗證已建立的系統保持符合規範。不論是確保最新修補程式已部署，還是減少具有網域權限的使用者數目，完整的 DCM 解決方案必須設定系統、分析系統，並且報告每個設定與理想的接近程度。修正可以是很簡單的動作 (例如修補網路上已部署的新系統) 也可以是強制的 (例如為使用者強制執行電子郵件用戶端設定)。關鍵是將它們與組織的原則和法規立場相結合 (DCM 也有助於識別惡意程式的感染並加以移除，因為從掃描結果即可直接辨識出簡單的惡意程式)。
DCM 是 RMD 相互關聯引擎的主要資料報告器之一，而且會提供有關主機偏離正常值的程度。資料即時性可區別零到五等級警報安全性事件，根據資產的價值決定掃描的頻率，例如低安全性資產可以每月掃描一次、中度安全性資產每週掃描一次，高安全性資產至少每天檢查一次。
DCM 設定也是良好網路存取保護 (NAP) 機制的一部分。如此，系統會驗證所有連接的系統是否都已適當設定，並會在新的、未知系統通過驗證前先加以封鎖。此外，DCM 應該檢查設定漏洞 (例如，某共用項目上不夠紥實的存取控制清單)，讓管理員採取適當動作。
請不要認為 DCM 只適合套用於用戶端或伺服器等主機。網路裝置和核心目錄本身也適合加入 DCM。如果有熟知的網路設計，理想的 DCM 系統要執行相關裝置標準，應該是微不足道。想像可能性！DCM 可以控制實作，而不需要手動調整路由器設定。或者，假設一組標準群組原則設定與一組特定伺服器或用戶端相關聯。DCM 應該監視它們，並在網域設定變更時傳送警訊。
DCM 收集的資料應該夠健全，可用於 IT 稽核。良好的 DCM 也應該成為變更管理和法規符合性控制的一部分，以便即時、近乎不間斷地處理稽核問題。例如，我們例行的控制檢查工作之一，就是驗證 MMS 伺服器上的本機系統管理員成員資格有無變更。強制執行此規則正是 DCM 的設計目的！
即使 IT 部門尚未準備好部署自我修正的 DCM 系統，仍然可以部署另一種型式的目標建構監控，從而得到不錯的結果。它也會提供有關設定問題的報告和警訊，但未必達成相同的規模經濟，因為修復多為手動的。不過，重要的是，RMD 需要的通知和資料將可用於相互關聯。
不過，有一點要請您注意：DCM (不論是先前描述的任一形式) 必須符合最小的重要設定項目範圍，加上標準資產收集資料。否則，可能會影響 IT 團隊需要的彈性。如果 DCM 設定手冊過時，DCM 很快便會被視為作業負擔，而非有用的工具。因此，隨時瞭解如何最佳設定資產的最新想法很重要。此外，我們也建議 DCM 系統根據相關資產或應用程式最佳作法，將設定手冊的更新定期納入。

結論
不論您在公司內部建立或向知名廠商購買，儀表板是很重要的，它可以擔任團隊中用於事件回應的主要工具。防惡意程式也是重要的，有助於防止每日倍增的威脅。網路異常偵測正在變化之際，從單單只是偵測惡意程式的簽章和主機入侵前進到探查資料外洩，而後者有助於預防新的網路漏洞再次成為頭條新聞。目標建構管理雖然還很新，但不久將會成為監控和維護設定的支柱。不論由誰提供這些工具，這四種類型的工具，您應該至少各有一個！
根據我們目前所見，沒有廠商 (包括 Microsoft) 提供一個會處理全部四個領域的全面解決方案。如何選擇適合您特定需求的產品，由您作主。我們只希望本文提供的見解能幫助您思考目標並瞭解理想的解決方案應具備的功能。

Matt Clapham是 Microsoft IT 部門基礎結構和安全性群組的安全性工程師。之前，他曾在 Microsoft Managed Solutions 風險管理與規範團隊工作兩年。
Todd Thompson是 Microsoft IT 部門基礎結構和安全性群組的安全性工程師。之前，他曾在 Microsoft Managed Solutions 風險管理與規範團隊工作兩年。


 安全性: 強大的憑證管理新工具
安全性 Kevin Dallmann

強大的憑證管理新工具
摘要:
  • ILM-CM 架構
  • 系統管理與範本
  • 建立工作流程

在某個平靜的上班日子裡，您突然接到一通服務台支援小組打來的電話，說有個生產系統的憑證過期了。如今系統已經停擺，您的公司也因而喪失生產力 (和金錢)，得等到更新憑證後才能恢復正常。
如果您是負責管理公開金鑰基礎結構 (PKI) 環境，我敢擔保您一定曾遭遇憑證始料未及地過期的窘境。唉，平靜的日子只待夢裡追尋！
當初 Microsoft 在 Windows® 2000 和 Windows Server® 2003 中新增 PKI 服務時，的確曾讓企業能以極低成本實作完善的內部 PKI 環境。遺憾的是，Microsoft® PKI 服務並無能力管理其所產生憑證的生命週期。不過，Microsoft 最近剛研發出憑證管理產品，旋即發行 Identity Lifecycle Manager (ILM)，結合了憑證管理以及 Microsoft® Identity Integration Server (MIIS) 的識別提供與控制功能。本文將討論 ILM 如何協助您的組織管理憑證和智慧卡。

ILM-CM 架構
ILM 憑證管理 (ILM-CM) 架構的核心是 ILM-CM 伺服器及其相關元件 (請參閱 [圖 1])。ILM-CM 伺服器可安裝於一部伺服器，設定做為聯繫一或多個憑證授權單位 (CA) 的介面。ILM-CM 需要 SQL Server™ 用來儲存憑證資訊、原則及用於管理憑證環境的其他相關資料。為了管理使用者和安全性權限，ILM-CM 伺服器也需要 Active Directory®。[圖 2] 摘列其必要元件與版本。
Figure 2 支援 ILM-CM 基礎結構 (Close Figure 2)

元件 | 版本
Active Directory | Windows Server 2003
資料庫伺服器 | SQL Server 2000 SP3 (含) 以上或 SQL Server 2005
憑證授權單位 | Windows Server 2003 Enterprise Edition 或 Data Center Edition
SMTP | SMTP 伺服器
[圖 1] ILM-CM 架構
[圖 1] ILM-CM 架構
ILM-CM 環境一旦安置完成，所有的憑證要求都將與 ILM-CM 伺服器通訊。ILM-CM 伺服器負責將所有與憑證有關的資訊儲存至 SQL Server 資料庫，而這些資訊則可後續用於憑證報告、警示及維護工作流程環境。
ILM-CM 軟體架構基本上包含三個高階部分：ILM-CM 伺服器、CA 外掛程式和用戶端元件。伺服器軟體可安裝並執行於 CA 或專責 ILM-CM 作業的伺服器上。接著 ILM-CM 伺服器將與 CA、SQL Server 資料庫及 Active Directory 通訊。伺服器也提供入口網站，讓憑證管理員設定憑證原則和工作流程，以及供憑證訂閱者要求和更新軟體憑證。
為使 CA 能與 ILM-CM 伺服器通訊，您必須在每個所要管理的 CA 上安裝並設定 ILM-CM 原則和結束模組。這兩個模組係用於在資料庫中記錄憑證資訊。每當 CA 發行憑證，結束模組即負責傳送該項資訊給 ILM-CM 伺服器，伺服器再將憑證資訊記錄到資料庫。
如果您打算管理環境中的智慧卡，就需要安裝 ILM-CM 智慧卡用戶端軟體。每一部須與 ILM-CM 伺服器互動的用戶端電腦都得安裝此軟體。

ILM-CM 安裝
安裝 ILM-CM 伺服器其實很簡單；精靈會引導您完成整個過程。但在實際執行精靈前，您務必注意幾項功能先決條件需求。
第一個條件就是 ILM-CM 需要 Active Directory 和 ILM-CM 架構延伸。架構延伸會新增 ILM-CM 實作設定檔範本所需的若干附加 Microsoft .NET Framework 安全性屬性。
您也必須安裝 .NET Framework 2.0 並備妥前述各項元件，包括 SQL Server、CA 和 SMTP 伺服器。如果 ILM-CM 將與 CA 安裝於不同的伺服器，您就必須在 CA 上執行 ILM-CM 安裝精靈，為 CA 安裝 ILM-CM 模組。安裝完成後，只要將瀏覽器指向 http://hostname/CLM 即可連線到 ILM-CM 入口網站。
若要啟用憑證過期/更新通知，您必須在 ILM-CM 伺服器上設定 ILM-CM 服務。首先請在 Active Directory 中建立適當帳戶，然後新增該帳戶做為 ILM-CM 服務的登入帳戶。接著，將該使用者新增至 ILM-CM 伺服器的本機系統管理員群組和 IIS_WPG 群組，並使用群組原則將其新增至「作為作業系統的一部分」、「產生安全稽核」及「取代處理程序等級權杖」原則。設定好 ILM-CM 服務後，ILM-CM 伺服器就能掃描 SQL Server 資料庫搜尋過期的憑證，並以電子郵件通知憑證擁有者或管理員。

ILM-CM 系統管理
ILM-CM 是透過網頁介面來管理，此介面係依使用者、憑證和智慧卡管理工作分成數個功能區。當您以適當的系統管理權限連線到 ILM-CM 入口網站時，網頁會顯示若干系統管理工作讓您管理 ILM-CM 環境 (請參閱 [圖 3])。[Common Tasks] 區提供系統管理選項，包括為一組新的憑證或新的智慧卡註冊使用者。您也可以管理和核准要求。
[圖 3] ILM-CM 管理入口網站工作
[圖 3] ILM-CM 管理入口網站工作
若您需要尋找使用者或憑證，請使用 [Manage Users and Certificates] 工作區。執行此區的工作可搜尋、修復、撤銷或更新憑證。您甚至還能尋找撤銷清單。
如果您的組織使用智慧卡，那麼 [Manage User Smart Cards] 區就很方便。例如，倘若使用者鎖定了智慧卡，憑證管理員便可從此處解除鎖定智慧卡。您也可以搜尋和檢視本機智慧卡讀取裝置內的智慧卡。
介面上的 [Requests] 區讓憑證管理員得以審閱和核准使用者的憑證要求。例如，您可以檢視所有處於擱置狀態要求下的憑證。[Administration] 區則可供您建立和管理設定檔範本。最後，[Reports] 區正如其名，可用來設計和建立與使用者及憑證相關的報告。
如果您不是使用具有系統管理權限的帳戶登入 ILM-CM 入口網站，就會看到為憑證使用者提供自助管理功能的訂閱者頁面 (請參閱 [圖 4])。透過這個入口網站，使用者可依特定的原則設定來檢視和管理自己的憑證和智慧卡。一般工作 (Common Tasks) 的例子包括：要求憑證或智慧卡、檢閱現有的憑證、變更智慧卡 PIN 等。
[圖 4] 訂閱者 入口網站頁面，供使用者 自助管理
[圖 4] 訂閱者 入口網站頁面，供使用者 自助管理
提供高品質的委派工作流程負責發行、更新、替換及撤銷憑證和智慧卡對任何組織來說都是一大挑戰。如今有了 ILM-CM，您即可委派這些工作以提供更高程度的安全保證。例如，假設有位使用者忘了他的智慧卡 PIN。循著委派工作流程模式，該使用者可以撥電話給服務台支援人員，然後支援人員會向他問些問題進行身分確認。如果使用者沒答錯問題，支援人員就可將其智慧卡解除封鎖。委派工作流程的另一個例子是，萬一使用者意外刪除加密檔案系統 (EFS) 憑證或遺失膝上型電腦，屆時也能修復憑證。

設定檔範本
設定檔範本是 ILM-CM 整體工作流程管理程序不可或缺的基本元件。設定檔範本就像是含有一或多個憑證範本的一個系統管理物件。設定檔範本的建立與設定是為了管理憑證環境的工作流程處理作業方式。設定檔範本最關鍵的一環在於，可納入多個憑證範本並視同單一項目來管理；這意謂著只要一份範本就能追蹤管理使用者的憑證在整個生命週期間的各項處理事宜。
設定檔範本可設定將憑證存放到電腦 (軟體式) 或智慧卡 (硬體式)。您可以從 ILM-CM 系統管理入口網站複製範例，進而建立這些範本。在設定檔範本中，可定義數種不同的管理原則元件 (請參閱 [圖 5])。
[圖 5] 設定檔範本
[圖 5] 設定檔範本
原則元件大多同時適用於軟體和智慧卡設定檔 (請參閱 [圖 6])。其中某些元件倒很值得一提。在憑證註冊處理期間，您可以使用註冊原則元件定義若干條件，來控制註冊處理流程的動向。例如，您可以設定資料收集條件，規定使用者必須輸入部門代號、電子郵件地址和經理姓名等資訊。您也能建立定義，以便在使用者註冊憑證後自動列印官方文件。
Figure 6 軟體設定檔原則 (Close Figure 6)

元件 | 描述
設定檔詳細資料 | 提供設定檔範本的一般詳細資料。您可以從此處將一或多個憑證範本新增至設定檔範本。
複製原則 | 定義現有憑證的工作流程項目。
註冊原則 | 定義註冊處理工作流程。
線上更新原則 | 類似於憑證更新原則，但能更新即將過期的憑證、憑證內容、範本和智慧卡小程式。
委託修復原則 | 修復使用者的私密金鑰或憑證。
憑證更新原則 | 定義已過期憑證的更新工作流程。
恢復原則 | 定義恢復憑證的處理流程。
修復原則 | 定義修復電腦上儲存之使用者憑證的工作流程，以因應遭刪除、重新組裝或失竊情事。
撤銷原則 | 定義撤銷設定檔內所有憑證的工作流程。
線上更新原則對您的組織來說可能非常有用。此原則類似於憑證更新原則，但能更新憑證內容、憑證範本、智慧卡內的小程式，而且會在憑證即將過期時更新憑證本身。為了充分利用此原則，必須啟用 ILM-CM 服務和 web.config 檔案以允許存取 Active Directory 中的多重值屬性。用戶端電腦也需要安裝線上更新服務。
如果您的公司使用 EFS 加密，請善加利用委託修復原則。假設有人意外刪除了加密憑證，您即可使用這個原則元件，設定工作流程由服務台安全小組請求使用者的私密金鑰。隨後使用者就會收到電子郵件，內有 ILM-CM 伺服器產生的通關密語，而藉此取回其私密金鑰。最後，使用者必須前往 ILM-CM 伺服器上的一個秘密網頁連結，使用關聯的私密金鑰取回憑證。委託修復原則特別有用的情況還包括，員工離職但其資料必須歸檔管理或另有其他用途時。
為了提供更安全的憑證更新程序，您可以利用憑證更新原則，設定一次有效密碼秘密金鑰並以電子郵件傳送給需要更新憑證的使用者。如果您撤銷了憑證後又想將其恢復並從憑證撤銷清單 (CRL) 中移除，恢復原則便可協助您定義這類工作流程處理。
有兩個獨特的原則元件僅與軟體憑證原則有關而與智慧卡無關，亦即修復原則和撤銷原則。萬一電腦上存放的使用者憑證遭刪除，或是電腦重新組裝或失竊，修復原則可以定義處理方式，從封存於 CA 上的憑證或金鑰進行還原。撤銷原則能讓系統管理員設定靜態的撤銷原因，或讓執行撤銷要求的人員於撤銷時指定原因。
另外還有五項管理原則適用於智慧卡設定檔範本，如 [圖 7] 所示。
Figure 7 智慧卡設定檔原則 (Close Figure 7)

元件 | 描述
替換原則 | 定義設定檔以因應使用者的智慧卡遺失或遭竊情事。
停用原則 | 定義停用智慧卡內尚未過期憑證的處理流程。
淘汰原則 | 定義撤銷智慧卡內所有憑證的處理流程。
解除封鎖原則 | 定義何人可將智慧卡的使用者 PIN 解除封鎖。
臨時智慧卡原則 | 定義短期間替換的智慧卡。使用者會收到新的簽署憑證，但只要取得既有的設定檔加密憑證就能將資料解密。
淘汰原則可以定義數種不同的操作，例如清除使用者放在智慧卡內的資料、封鎖使用者 PIN 和系統管理 PIN，以及重設系統管理 PIN。解除封鎖原則通常應用於使用者忘記其 PIN 或取得了由 ILM-CM 指定 PIN 的新卡等情況。屆時使用者可要求將智慧卡解除封鎖。
對任何的系統管理產品來說，報告都是非常有用的功能。組織能否擷取憑證或智慧卡環境的快照極為重要。ILM-CM 隨附數種內建報告，包括智慧卡清點、要求摘要、憑證使用與過期狀況等。和其他的報告系統一樣，如果您還需要別種報告，則可撰寫自訂查詢，因為資料全都儲存在 SQL Server 資料庫。

開發工作流程
接著我們就來看看 ILM-CM 如何協助您定義高效率的工作流程處理。假設您有幾位系統管理員負責管理和維護其系統的 SSL 憑證。首先要問的問題是：整個流程最關鍵的環節為何？
依系統類型而定，處理上可能需要用不同的方法建立憑證要求檔案。因此，首要任務即是開發內部網路網頁，詳細指示如何為所有系統建立憑證要求。
系統管理員建立了要求檔案後，可將其提交至 ILM-CM 使用者入口網站請示核准憑證。利用 ILM-CM 工作流程處理，系統管理員可以定義幾位核准者負責查證和核准憑證要求。憑證一經核准，使用者即可從 ILM-CM 擷取憑證。由於 ILM-CM 將憑證資訊放入 SQL Server 資料庫，系統管理員便能擷取歷史資訊。
一年過後，當憑證的有效期限即將屆滿，ILM-CM 會傳送電子郵件通知給要求者，提醒憑證快要過期必須更新。只要讓這樣的工作流程處理步上軌道，您就能免於憑證始料未及地過期的窘境，喚回平靜的日子。

結論
如果您的公司採用 Microsoft PKI 環境，ILM-CM 可以協助您管理這樣的環境。ILM-CM 讓組織得以改良安全性驗證程序，同時降低數位憑證與智慧卡管理的成本和複雜度。ILM-CM 還能讓您賴以開發現今多數公司所欠缺的憑證與智慧卡工作流程處理。
Microsoft 也針對 ILM-CM 實作了外部 API 支援。如果您的組織使用自訂的應用程式，或許可以善加利用 ILM-CM API 支援，設計這些應用程式做為聯繫介面。
如需 ILM-CM 的詳細資訊，請參閱 microsoft.com/technet/clm。您也可以在 go.microsoft.com/fwlink/?LinkId=87336 找到快速入門指南。

Kevin Dallmann是 Accenture 公司的資深系統工程師顧問，主要職掌為支援大型企業環境的 Active Directory 及 PKI 環境。Kevin 具有 MCSE 與 MCT 雙重認證的資格，同時也是 Microsoft 訓練課程講師。


 編輯的話: 安全性問題
編輯的話
安全性問題
Joshua Trupin

您注意到 最近安全性問題變得比較容易處理嗎？當然，我們也想說是 TechNet Magazine 的功勞，但另有其他因素。兩大因素是認知和穩固性。
認知只是更加認識潛在威脅、社交工程的誘騙手法，加上保持定期更新可保護已安裝軟體的修補程式和更新。另一方面是穩固性，即更安全地建立軟體，並且根據預設關閉公開的功能以減少攻擊面。
啊！還有一個因素，定期閱讀 TechNet Magazine。別忘了！本期是小有名氣的安全性期刊，其中七篇文章有助於您成為公司中令人生畏的安全性分析師/從業員。由 Mark Russinovich 首先上場討論 UAC 內部資訊、Steve Riley 切入 Windows 防火牆、Jesper Johansson 探索 Windows Vista 中的 ACL 變更。我們也邀請 Jeremy Moskowitz 談論群組原則和硬體鎖定、Michael Murgolo 貢獻指令碼提升權限 PowerToy 等等。認真地說，本期可能是所有發行雜誌中最棒的一期。
當您保持警戒時，您也應該知道 Microsoft 的最新安全性產品方案。Microsoft Forefront 代表「穩固性」因素，它是提供下列三方面保護的特定業務安全性產品：用戶端作業系統、應用程式伺服器和網路邊際。它包含適用於 Exchange Server 和 SharePoint 的安全性工具，也針對網路流量加入 ISA Server 和 Intelligent Application Gateway。Microsoft System Center 具體實現「認知」面向，因為它讓您收集系統資訊、簡化作業和管理、產生報告，並且會加強服務傳遞。它包含新一代設定管理和作業監視技術等工具。
若要更加瞭解 Forefront 和 System Center，請造訪 Microsoft 基礎結構網站，網址為 Microsoft.com/infrastructure。若要取得安全性難題的一流解決方案，TechNet Magazine 助您保持頭好壯壯。
—Joshua Trupin

感謝下列 Microsoft 技術專家：Conrad Bayer、David Cross、Michael Dennis、Shon Eizenhoefer、Jason Garms、Russ Humphries、Jesper Johansson、John Lambert、Eric Perlin、Mark Russinovich、Jon Schwartz、David Solomon、Greg Stemp、John Stephens、Kevin Sullivan、Jim Truher 和 Buck Woody。


 工具箱: 適合 IT 專家的新產品
工具箱 適合 IT 專家的新產品 and Greg Steen
myLittleAdmin 附有可更換外觀的介面
其網頁式 UI 支援大部分的資料庫操作，包括建立新資料庫、管理現有資料庫及其內容，以及處理快照集和結構描述。要編輯現有資料庫物件的屬性也很簡單，因為 myLittleAdmin 好意提供了可編輯的資料格，讓您能夠修改資料表中個別的資料列。樹狀檢視介面則與 SQL Server Management Studio 中的樹狀檢視非常相像，所以幾乎不再需要學習應用程式的用法。唯一有所不便的是，原先習以為常按滑鼠右鍵的動作未必會蹦現應有的快顯功能表。
您也可以使用 myLittleAdmin 來編輯 SQL 執行個體的登入、伺服器角色和憑證。甚至還能建立和編輯備份裝置及連結的伺服器，因而得以從遠端位置執行這些實用的工作。
myLittleAdmin 也能讓您執行其他工作，像是臨機操作查詢、附加與卸離資料庫、備份與還原、匯入 CSV 資料，以及壓縮資料庫。您甚至還能瀏覽錯誤記錄檔和活動監視器以便進行疑難排解。
售價：單一伺服器授權為 $590 美元起。若隨網站主機代管工具組一併供應客戶，單一伺服器授權為 $990 美元起。


 SQL 問題與解答: 64 位元安裝、配置叢集記憶體等等
SQL 問題與解答 64 位元安裝、配置叢集記憶體等等 and 編輯：Nancy Michell
[圖 1]Windows Live 的《SQL Server 線上叢書》搜尋
但假設 SQL Server 佔有伺服器上的所有 RAM，然後啟動 SQL Server 的新執行個體。原來的 SQL Server 執行個體的記憶體會發生什麼狀況呢？我似乎應該為最壞狀況做準備，即只有一個節點保持啟動，並且 SQL Server 的所有執行個體都在該節點上執行。
答：我們都同意，最好將最大伺服器記憶體值設為小於電腦上的可用記憶體總數。不過，我們懷疑總記憶體值的三分之一會是您環境的最好設定。
您擔心在叢集中四個伺服器的其中三個會同時當機，而這三個 SQL Server 執行個體後來都會在第四個節點上執行。但這個狀況是不可能的。
在大多數案例中，最好將每個執行個體設定為使用每個節點上的大部分可用記憶體。假設每個節點有 32GB 的 RAM。為每個執行個體設定最大伺服器記憶體 28GB，是合理的。
現在，如果發生節點失敗，該節點上執行的執行個體會容錯移轉至被動節點，可能會存取 28GB 的記憶體。其他兩個執行個體不受影響，它們仍然會在叢集中其他兩個節點上執行。
您指出具有五個 SQL Server 執行個體和一個 Analysis Services 執行個體的四節點容錯移轉叢集。如果您是執行具有 Address Windowing Extensions (AWE) 的 SQL Server 2000，您必須為關聯式引擎執行個體仔細設定記憶體上限，因為它們不會放棄已取得的記憶體。在使用 SQL Server 2005 和存取大型位址空間的 64 位元執行個體 (不論是否使用 AWE) 的情況比較有彈性，即使您在此使用 AWE，它是動態，會根據要求釋放記憶體。因此，對於您的問題：新執行個體在電腦上啟動的容錯移轉狀況下，原始 SQL Server 執行個體和它已取得的記憶體會發生什麼狀況？答案將取決於您是執行 SQL Server 2000 或 SQL Server 2005，以及您是否使用 AWE。
為最壞狀況做準備，原則上是好主意，但實際上除非您真的過度工程化系統，在執行五個 SQL Server 關聯式引擎執行個體和一個 Analysis Services 執行個體的叢集中，如果四個節點中已有三個當機，要想整個系統仍能運作是不可能的。最後的那個節點沒有足夠的 CPU 資源，繼續以相當的效能等級來服務原始執行個體。因此，最好重新設計您的解決方案，以便在失去一個節點時仍能維持最佳效能，但在失去一個以上的節點時可能需要一點人力介入。這應該可以提供高可用性 (HA) 支援，同時讓您的昂貴資源發揮不錯的使用率。
最後，使用 SQL Server 2005，使用者實際上可將叢集向外擴充至八個節點。在 SQL Server 2000 中，四節點叢集是最大極限。

鏡像限制
問：在閱讀 SQL Server 2005 資料庫鏡像的相關資訊時，我發現資料庫鏡像在每個伺服器執行個體最多只支援 10 個資料庫的限制。我的需求是有兩個不同的 SQL Server 執行個體，各具有不同的儲存體、兩者間能自動容錯移轉，以及資料重複性。
我的計劃是使用點對點 (P2P) SQL Server 2005 交易複寫，結合 Microsoft® Cluster Server (MSCS)，其中的叢集 IP 來自兩個節點之一，因此，所有插入、更新、刪除和讀取流量都將前往叢集中的一個節點。我將第二個節點視為被動，但會複寫交易給它。如果發生失敗，MSCS 會將該 IP 容錯移轉至另一個節點，因為設定為 P2P 和雙向，所以不需要手動起始將交易發行至另一個節點 (在它備份後) 的程序。我會使用 MSCS 的 Majority Node Set (MNS) 設定，以減輕仲裁共用磁碟資源的需求。
我仍在勘酌是否採用鏡像選項。我們已將每個 SQL Server 叢集的資料庫從 1000 降至 100。我還可以將該類型的資源負載放在系統上嗎？
答：如需 SQL Server 鏡像的詳細資訊或指引，請參閱 BOL 或 SQL Server Tech Center (網址為 microsoft.com/technet/prodtechnol/sql) 以及 msdn2.microsoft.com/sql。
您的問題引起許多討論。在吵嘴辯論講笑話後，以下是有關您案例的最佳回應：
第一個回應是，在給定執行個體中，可鏡像的資料庫數目並沒有強制性限制。我想，您是指某文章中提及每個執行個體鏡像的資料庫最好在 10 個以內的最佳作法，但這只是估計值，並非強制性限制，一切都是取決於給定系統上的可用資源。
鏡像可以是個選項，但 1,000 個資料庫肯定會很吃力，除非您真的有相當高等級的伺服器。如果您不要使用共用儲存體，並且要使用內建 SQL Server 技術，您可以嘗試鏡像、記錄傳送或複寫。不同的方法各有利弊。
第二個回應是，如果您有大量資料庫但不使用共用儲存體，而且您想要使用 Microsoft 的嚴重損壞修復解決方案，您應該調查記錄傳送，並使用一組自訂的小型 Helper 程式以減輕管理負擔。程式可以依序備份和還原每個資料庫，因此您不必執行多個記錄傳送代理程式。請注意，資料可能流失。內建解決方案都需要共用儲存體或 DBMS，才可確保不會流失資料。
當然，MSCS 如何偵測和容錯移轉確實是個問題。叢集中的 MNS 設定一般不會完全免除共用儲存體的需要，它們只是免除仲裁專用共用 LUN 的必要性。使計劃可行的唯一方法是，叢集是設定為只管理 IP 和網路名稱。SQL Server 若沒有共用儲存體便無法叢集化，因此您無法叢集化 SQL 服務，這表示在一般設定中叢集無法偵測和監視 SQL Server 服務。
您可以將 SQL Server 服務新增為要監視的一般服務，藉此叢集化，但在容錯移轉時會發生問題：假定服務會叢集化，MSCS 會在容錯移轉時嘗試讓服務於被動節點恢復上線，但那裡有些 SQL 服務已經在執行中。當然，您可以只用它來叢集化 IP 和網路名稱，在必要時手動將它們容錯移轉。您可以使用網路負載平衡 (NLB) 執行相同的動作 (在其他地方完成的)。如需詳細資訊，請參閱 microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx 的文件。
有鑑於您嘗試支援的資料庫數目，記錄傳送解決方案可能較合適。當然，您需要使用 Data Transformation Services/SQL Server Integration Services (DTS/SSIS) 封裝來自動化程序，否則在失敗時可能得花太多時間來手動備份、移動和套用使用中記錄。

感謝下列 Microsoft IT 專家提供其技術專業知識：Boris Baryshnikov、Chad Boyd、Alan Doby、Patrick Gallucci、Cindy Gross、Chuck Ladd、Pat Martin、Vipul Shah、Nelson Taggart、Kartik Tamhane、Ken Tanner、Chuck Timon、George Walters、Kevin Warren，並特別感謝 Buck Woody。


 公用程式焦點: Script Elevation PowerToys for Windows Vista
公用程式焦點 Script Elevation PowerToys for Windows Vista and Michael Murgolo
下載本文程式碼: Utility2007_06.exe (159KB)
儘管使用者帳戶控制為安全性帶來重大改進，提升權限仍是完成某些系統管理工作和功能不可或缺的要素。本文介紹的幾個 Elevation PowerToy 將可助您更健全而靈活地提升權限。
在 Windows Vista 基於解決安全問題而引進的各項功能當中，最具象徵性的莫過於使用者帳戶控制 (UAC)。有了使用者帳戶控制，即便使用者身為系統管理員也是以標準權限來執行大部分的應用程式，但還擁有「提升權限的潛力」可執行特定的系統管理工作和
應用程式功能。用了幾個月的 Windows Vista™ 之後，每有必要就提升工作和應用程式的權限竟成為我改不掉的習慣。不過，我在 Windows Vista 中試著提升某些工作類型的權限時也曾遭受若干缺點所苦，讓我略有挫折感。
就因為這樣，基於延續前幾版 Windows® PowerToy 的精神，我建立了幾個 Script Elevation PowerToy 努力克服這些限制。本文將要討論的各個 PowerToy 均可在 technetmagazine .com/code07.aspx 的程式碼下載中找到。此外，您還可閱讀 2006 年 11 月份由 Alex Heaton 所撰的《利用「使用者帳戶控制」實現非系統管理夢想》文章來瞭解 UAC 的運作原理 (請參閱「其他資源」資訊看板)。

提升命令權限 PowerToy
首先令人懊惱的，就是沒有辦法從命令列或從 [執行] 對話方塊來提升應用程式的權限。所以我到 Microsoft 那兒遍尋名師，受到 Microsoft 軟體設計工程師 John Stephens 的啟發而終於想了一個範例指令碼。情況大致如此：只要傳遞動詞 "runas" 給 ShellExecute API 或其對等的 COM 函式 (即 Shell.Application 的 ShellExecute 方法)，應用程式啟動時將會提示提升權限 (細節請參閱資訊看板)。這讓我得以完成第一個 Elevation PowerToy：提升命令權限 PowerToy。
此工具 (由 ElevateCommand.inf、elevate.cmd 和 elevate.vbs 檔案組成) 會將 elevate 命令新增至您的系統。這樣您就能從命令列、指令碼或 [執行] 對話方塊來啟動提示提升權限的應用程式。例如，下列命令將會使用記事本開啟 Win.ini (在提示提升權限後)：
elevate notepad c:\Windows\Win.ini
若要在 Windows Script Host (WSH)、Windows PowerShell™ 或其他指令碼中使用 elevate 命令，必須指定指令碼主機的執行檔 (如 wscript、cscript 或 powershell) 當作應用程式。例如，使用下列語法即可執行 vbs 檔案：
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
[圖 2]以較高權限開啟命令提示

安裝與實作
若要安裝這些 PowerToy，請以滑鼠右鍵按一下 INF 檔案並選取 [安裝]，然後認可提升權限。使用 [控制台] 中的 [程式和功能] 選項即可解除安裝。
要是您查看 INF 檔案內容而感到納悶，為何其中三個 PowerToy 將 elevate.cmd 和 elevate.vbs 安裝到不同的位置，請看以下說明。這些 PowerToy 的實作方式，幾乎都是為物件類型的 HKEY_CLASSES_ROOT\objecttype\Shell 登錄機碼新增 runas 子機碼。
然而，其中某些 PowerToy 的物件類型需要由兩個快顯功能表項目引發提升權限 (磁碟機和目錄物件類型需要 "CMD Prompt Here as Administrator" 和 "PowerShell Prompt Here as Administrator"，所有 WSH 物件類型需要 "Run as Administrator" 和 "Run as Administrator with Command Prompt")。由於每種物件類型只能有一個 runas 機碼，我必須呼叫 elevate 命令來執行第二個動作。但是我又希望能夠單獨安裝和解除安裝每個 INF，所以必須將相關的 elevate.cmd 和 elevate.vbs 複本放在不同的地方 (您無法從原始 INF 檔案遞增檔案使用次數。當然，改用 MSI 安裝程式可能更好，不過我希望能用文字編輯器來建立和修改安裝程式)。這樣做的副作用是，只有使用 runas 機碼實作的快顯功能表項目才會在功能表上顯示盾牌圖示。

結論
但願您會認為這些工具還算實用，有助於改善 UAC 使用效率；或許還能激發您自己建立 PowerToy 的興趣 (在 Windows Vista 上使用其他指令碼語言像是 Perl 或 Python 的人，要用這些語言建立「提升指令碼權限」的 PowerToy 應該也不會太難)。就像所有的 PowerToy 一樣，這些都是「無支援責任」工具，使用後果請自行承擔。無論如何，祝您提升權限愉快！
其他資源
  • 利用「使用者帳戶控制」實現非系統管理夢想
  • 使用者帳戶控制概觀
  • 透過 ShellExecute 提升權限
  • ShellExecute 方法
  • 動詞與檔案關聯
  • 賦予舊版 PowerToy 新生命


 The Cable Guy: 安全通訊端通道通訊協定
The Cable Guy 安全通訊端通道通訊協定 and Joseph Davies
本專欄是根據 Windows Server 的搶鮮版 (Prerelease Version，代號 "Longhorn") 而寫成。本文包含的所有資訊均有可能變更。
Windows XP 和 Windows Server 2003 中的 VPN 通訊協定不適用於某些組態。深入瞭解各種問題現象，以及 Windows Server "Longhorn" 和 Windows Vista Service Pack 1 如何運用安全通訊端通道通訊協定來解決這些問題。
Windows XP 和 Windows Server 2003 中的虛擬私人網路 (VPN) 支援讓您得以透過網際網路連線到私人內部網路，就好像您的電腦插入了本機 Ethernet 連接埠。但是，Windows XP 和 Windows Server 2003 中的 VPN 通訊協定不適用於某些防火牆組態
和間接組態，例如電腦位於網路位址轉譯器 (NAT) 或 Web Proxy 伺服器背後以致封鎖 VPN 連線的流量。為了解決這些難題，下一版的 Windows Server® (代號 "Longhorn") 以及 Windows Vista™ Service Pack 1 將提供新的安全通訊端通道通訊協定 (SSTP) 支援 (兩者現正處於 Beta 測試階段)。

VPN 存取問題
在 Windows® XP 和 Windows Server 2003 中，讓您可從遠端透過網際網路連線存取內部網路的 VPN 通訊協定是點對點通道通訊協定 (PPTP)，以及 Layer Two 通道通訊協定加上網際網路通訊協定安全性 (L2TP/IPsec)。這些通訊協定會封裝遠端存取用戶端與其所連線的內部網路之間傳送的封包。
以 PPTP 為基礎的 VPN 流量包含了通往 VPN 伺服器 TCP 連接埠 1723 負責執行通道維護的 TCP 連線，及由 Generic Routing Encapsulation (GRE) 所封裝的 VPN 資料封包。但若 PPTP 流量遇到防火牆、NAT 和 Web Proxy 就有可能發生問題。為了避免問題發生，防火牆必須設定成同時允許 TCP 連線和 GRE 封裝的資料。雖然 GRE 是封裝 IP 封包的標準方法，多數的網際網路服務提供者 (ISP) 都會卸除這些封包，因而導致資料遺失。此外，旅館和咖啡店內的連線通常都是針對一般 Web 流量和電子郵件流量來設定，可能並不允許 PPTP 流量。再者，如果您的電腦位於 NAT 背後，則 NAT 必須能夠轉譯 GRE 流量。要不然，您就只能建立 TCP 連線卻無法傳送或接收任何 GRE 封裝的封包。最後一點，PPTP 流量無法通過 Web Proxy。
Windows XP 和 Windows Server 2003 中的另一種 VPN 通訊協定 L2TP/IPsec 使用網際網路金鑰交換 (IKE) 來交涉 VPN 流量的 IPsec 封裝安全承載 (ESP) 保護，如果遇到防火牆、NAT 和 Web Proxy 也可能發生問題。
在這種配置下，防火牆必須設定成同時允許 IKE 流量和 ESP 封裝的資料。如果您的 VPN 用戶端電腦位於 NAT 背後，則 VPN 用戶端和 VPN 伺服器都必須支援 IPsec NAT 周遊 (NAT-T)。但是請注意，VPN 伺服器不能位於 NAT 背後，且 L2TP/IPsec 流量無法通過 Web Proxy。

新的 VPN 解決方案
如您所見，Windows XP 和 Windows Server 2003 中的 VPN 通訊協定作業存有不少問題。好消息是 Windows Vista Service Pack 1 和 Windows Server "Longhorn" 中的 SSTP 利用 HTTP 取代 SSL (安全通訊端層) 解決了這些 VPN 連線問題。SSL 也稱為傳輸層安全性 (TLS)。Web 在 TCP 連接埠 443 上使用 HTTP over SSL 通訊協定已有一段時間，用途多為收集信用卡號碼及其他私人資料。每當您連線到以 https: 開頭的網址，使用的就是 HTTP over SSL。
使用 HTTP over SSL 可以解決許多 VPN 通訊協定連線問題；正因為其如此普及，防火牆、NAT 和 Web Proxy 通常都允許這類流量。
SSTP 利用 HTTP over SSL 工作階段，在 VPN 用戶端和伺服器之間交換封裝的 IPv4 或 IPv6 封包。請注意，以 HTTP over SSL 為基礎的遠端存取 VPN 連線不同於使用 HTTP over SSL 的應用程式所進行的連線。例如，Outlook® Web Access (OWA) 讓您得以透過網際網路存取企業端的 Microsoft Exchange 電子郵件。OWA 使用 HTTP over SSL 加密工作階段，但這和遠端存取連線並不相同。您雖然可以使用 OWA 檢視電子郵件，卻無法連線到內嵌於 Exchange 電子郵件訊息中的內部網路 URL 位置。
(SSTP 不支援驗證式 Web Proxy 組態，即 Proxy 在 HTTP 連線要求期間需要進行某種形式的驗證)。
Windows 中的 HTTP over SSL 實作能大幅降低遠端存取方案的維護成本。例如，HTTP over SSL 既可減少尋求支援部門協助解惑的次數，也能消弭位於 NAT 背後的 VPN 伺服器所涉相關問題。此外，由於 SSTP 幾乎隨處可用，員工將可毫無罣礙地工作進而提高生產力。
由於 Windows 內建 SSTP，您無須擔心用戶端電腦還得安裝與管理協力廠商 VPN 用戶端軟體，而 VPN 伺服器也不必再安裝其他軟體。此外，SSTP 還可透過現成的 SSL 負載平衡器，為 VPN 連線提供更妥善的負載平衡。
SSTP 新功能
  • SSTP 包含了對網路存取保護 (NAP) 的整合支援，可藉由強制遵守系統健康狀態需求更完善保護網路資產。如需 NAP 的詳細資訊，請參閱 microsoft.com/nap。
  • 其次，SSTP 支援 IPv6 網際網路透過 SSTP 通道內部及 IPv6 架構的 SSTP 連線傳送原始 IPv6 流量。
  • 再者，SSTP 會建立從 SSTP 用戶端到 SSTP 伺服器的單一 HTTP over SSL 工作階段。其他協力廠商的 SSL 架構 VPN 方案都是使用兩個 HTTP over SSL 工作階段。使用單一 HTTP over SSL 工作階段可降低網路使用率，並且提供更妥善的負載平衡。
  • 最後，SSTP 已完全整合至 Windows Vista Service Pack 1 和 Windows Server &quot;Longhorn&quot; 的 VPN 用戶端元件，以及 Windows Server &quot;Longhorn.&quot; 中的路由及遠端存取。SSTP 是另一種 VPN 通訊協定，可以使用原有 PPTP 或 L2TP/IPsec 架構連線既已使用的各種驗證通訊協定與設定方法，例如 [網路連線] 資料夾和連線管理員。
與 Windows XP 和 Windows Server 2003 中的 PPTP 及 L2TP/IPsec 通訊協定不同的是，SSTP 不支援站台間 VPN 連線。

Windows 中的 SSTP
執行 Windows Server "Longhorn" 加上路由及遠端存取的電腦即為 SSTP 架構的 VPN 伺服器。您不需要安裝 IIS，因為路由及遠端存取會接聽特定的統一資源識別元 (URI) /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ 上的連入連線。不過，路由及遠端存取和 IIS 可以並存於同一部伺服器。
執行 Windows Vista (含即將問世的 Service Pack 1 計畫增強的功能，目前預定在今年底發行) 或 Windows Server "Longhorn" 的電腦則是 SSTP 架構的 VPN 用戶端，可起始 SSTP 連線到 SSTP 架構的 VPN 伺服器。SSTP 伺服器必須安裝含有「伺服器驗證」或「全方位增強金鑰使用方法 (EKU)」屬性的電腦憑證。此電腦憑證係供 SSTP 用戶端於建立 SSL 工作階段時，用來驗證 SSTP 伺服器。SSTP 用戶端會驗證 SSTP 伺服器的電腦憑證。為了信任此電腦憑證，發行電腦憑證給 SSTP 伺服器之憑證授權單位 (CA) 的根 CA 必須安裝於 SSTP 用戶端。
[圖 1] 列出 Windows Server "Longhorn" 和 Windows Vista Service Pack 1 中各種 VPN 通訊協定的屬性比較。「SSTP 新功能」資訊看板說明 SSTP 功能。
Figure 1 各種 VPN 通訊協定的比較 (Close Figure 1)
[圖 2]SSTP 封包的結構
IPv4 或 IPv6 封包首先使用 PPP 標頭和 SSTP 標頭進行封裝。接著再由 SSL 工作階段加密 IPv4 或 IPv6 封包、PPP 標頭加上 SSTP 標頭的組合。最後加入 TCP 標頭以及 IPv4 標頭 (SSTP 連線透過 IPv4 網際網路) 或 IPv6 標頭 (SSTP 連線透過 IPv6 網際網路) 而完成整個封包。
如需 SSTP 的詳細資訊，請參閱「路由及遠端存取部落格」，網址為 blogs.technet.com/rrasblog。


 Windows PowerShell: 使用 Active Directory
Windows PowerShell 使用 Active Directory and Don Jones Windows PowerShell 未提供 Get-ADSIObject cmdlet，但不代表它未提供強大的 ADSI 支援。請參閱型別配接器的簡介，瞭解如何使用 Windows PowerShell 來處理目錄物件。
如果您曾經玩過 Windows PowerShell，您可能已經嘗試過 Get-WMIObject cmdlet，又稱為 gwmi。我在上期專欄中說過，這個 cmdlet 突顯 Windows PowerShell 對先前指令碼語言和命令列殼層的重大改進
(請參閱 technetmagazine.com/issues/2007/05/PowerShell)。Gwmi 能快速輕鬆地存取 Windows® Management Instrumentation (WMI)，讓您不需要撰寫複雜指令碼，即可完成不可思議多的事。
Get-WMIObject 是 Windows PowerShell™ 好用的絕佳例子，每次我在課堂上說明時，學生總會猜測其功能是否延伸至其他 Windows 管理區域。我常被問到的第一個問題類似「是否有 Get-ADSIObject cmdlet？」

Windows PowerShell 的 ADSI 支援
ADSI 全名為 Active Directory® 服務介面。儘管其名稱如此，ADSI 其實不是 Active Directory 專用的。比較正確的解讀名稱方式是「主動 (形容詞) 目錄服務介面」，因為 ADSI 可以連接到各種目錄服務，包括 Windows NT® 型目錄，不僅包括 Windows NT 網域，還包括獨立和成員電腦上的本機安全性帳戶管理員 (SAM)。具備如此彈性，Get-ADSIObject cmdlet 應該極為實用。可惜，在第一版中 Windows PowerShell 團隊無法產生此 cmdlet。
這不表示 Windows PowerShell 缺少 ADSI 支援。事實上，Windows PowerShell 有不錯的 ADSI 支援，您可能不會在意少了 Get-ADSIObject cmdlet！
一切由 [ADSI] 型別配接器開始。型別配接器需要一點說明。請記住 Windows PowerShell 是奠基於 Microsoft® .NET Framework (2.0 或更高版本)。因此，Windows PowerShell 中幾乎所有的一切，從 WMI 物件到檔案和資料夾，都表示為 Framework 物件。不過，Windows PowerShell 團隊對於公開原始 Framework 物件給 Windows 系統管理員感到彆扭。例如，很多 Framework 物件的運作方式不甚一致，但一致性是 Windows PowerShell 的主要設計目標。另一個原因是，有些 Framework 物件對於 Windows 系統管理來說威力太強，而簡單也是 Windows PowerShell 的主要設計考慮因素。因此，型別配接器誕生。
如其名稱，型別配接器會將 .NET Framework 物件型別改寫為更一致、有時更簡單的格式。例如，假設您建立新字串變數，如下：
[string]$var = “Hello”
您已經使用由 .NET 配接器處理的 System.String 型別執行個體。[ADSI] 型別配接器會連接到 .NET Framework DirectoryServices 類別，包括 DirectoryEntry 型別。

從目錄擷取物件
連接到目錄物件相當簡單。例如，若要連接到位在 Contoso.com 網域 IT 組織單位 (OU)、名為 Don 的使用者，您使用類似下列的程式碼：
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
如果您曾經在 VBScript 或其他語言中使用過 ADSI，這應該很熟悉。它是標準的輕量型目錄存取協定 (LDAP) 查詢字串，是存取 Active Directory 的原生方式。您不需要指定網域控制站 (DC) 名稱或其他詳細資料，這個完整網域名稱 (FQDN) 有足夠資訊，找得到 DC 並擷取物件 (當然您必須有執行此動作的權限)。
處理本機安全性帳戶幾乎是雷同的程序，除了使用 WinNT 提供者，而非 LDAP 提供者：
$user = [ADSI]”WinNT://don-pc/don”
[圖 1]擷取物件的屬性清單
擷取物件主要是瞭解如何建構查詢字串。使用 WinNT 提供者很簡單。只要指定電腦或網域名稱、斜線，接著物件名稱。此技巧亦適用於 Active Directory 網域 (它畢竟是與 Windows NT 網域回溯相容的)。事實上，使用 WinNT 提供者從 Active Directory 擷取物件有時是最簡便的途徑，因為 WinNT 提供者會提供平面的網域檢視。這表示，您不需要知道物件所在的 OU，因為 WinNT 提供者看不到 OU。
擷取 LDAP 物件需要更多的精確性。以最明確的資訊為開頭，例如物件的正式名稱 (cn) 或 OU 名稱。接著提供物件的完整路徑，以父容器為開頭，接著網域本身。例如，使用者 Don 位在 Contoso.com 網域 West OU 的 Sales OU，則如下：
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
此格式需要一點練習，而且您必須知道物件的位置。[圖 2] 摘要說明 FQDN 的各個元件。
Figure 2 FQDN 元件 (Close Figure 2)

元件 | 目的 | 範例
cn | 物件的正式名稱。也使用於非 OU 容器，例如使用者和電腦。 | cn=Don
ou | 組織單位。 | ou=Sales
dc | 網域名稱元件。DNS 網域名稱的每個元件都有專屬的 "dc=" 元件。 | dc=domain、dc=com

好友相助
若要建立和刪除物件，您通常必須先連接到物件的容器，例如 OU，接著要求容器建立或刪除物件。我總是忘記正確的語法，但幸好 Microsoft Scripting Guy 伸出援手，提供了 ADSI Scriptomatic 工具。
雖然原本是針對 VBScript 而建立的，ADSI Scriptomatic 仍然是 Windows PowerShell 的實用指引，因為實際的 ADSI 語法相同。例如，在下載工具之後，我選取建立新使用者的選項。我忽略工具產生的所有指令碼直到 "End connect to a container" 程式碼，如下所示：
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
轉換為 Windows PowerShell 很簡單。首先，我連接到要建立使用者的容器。為了保持與 Scriptomatic 程式碼一致，我會使用變數 $objContainer 代表 OU。我也會建立變數 $strName 以保留新使用者的名稱：
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
接下來，我將 Scriptomatic 程式碼複製過來，移除任何 VBScript Set 陳述式，並且將 $ 加入變數名稱：
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
轉換就是這麼簡單！新使用者已經在 Contoso .com 網域的 Test OU 中建立。

修改目錄物件
一旦連接到物件 (例如使用者或群組)，您可以修改它。使用 WinNT 提供者，您能夠直接修改許多屬性，如 [圖 1] 所示。例如，若要顯示使用者的 Description 屬性，接著修改它，您可以這樣做：
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
重要的是，屬性變更只發生在本機屬性快取，這是 ADSI 在電腦上維護的暫存區。呼叫 SetInfo 方法會將快取寫回從中擷取物件的網域或電腦，基本上會將變更寫回目錄。
Active Directory 物件不會提供大部分物件屬性 (Attribute) 的直接屬性 (Property)。您必須改用 Get 和 Put 方法：
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
WinNT 物件傾向於簡化，因為 Windows NT 目錄服務不會儲存物件 (如使用者和群組) 的許多資訊。相反地，Active Directory 儲存豐富的資訊，要查出正確的屬性名稱可能很困難。例如，如果您要變更使用者的姓氏，必須變更 Sn 屬性。為什麼是 Sn 呢？它代表姓氏 (Surname)。
所幸，Microsoft 在線上提供不錯的交互參照，網址為 msdn2.microsoft.com/ms677286.aspx。此參照顯示 [Active Directory 使用者和電腦] 主控台各大區域的屬性名稱，因此，如果您知道主控台中所要的變更，就可以查出基礎的屬性名稱。如需更完整的主控台至屬性的交互參照，請參閱 Cade Fassett 所著的 ADSI Scripting: TFM (SAPIEN Press，2007)。

不能做什麼
可惜 Windows PowerShell 的 ADSI 支援不如對其他技術 (例如 WMI) 的支援。例如，要列舉本機電腦的群組成員有點困難。在處理 Active Directory 時，也會發生一些困難的狀況。我的經驗是基本的物件擷取、建立和刪除蠻好用的。修改物件屬性也很不錯，雖然無法存取一些屬性。透過 WinNT 提供者使用本機物件和群組時遇到最大困難。
這不代表完全不能做事。只是有些事比較困難或比較不直覺化。請參考下列範例：
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
這會將名為 User1 的使用者加入 Techs 群組。一開始夠簡單。它使用 FQDN 擷取群組。接著，使用群組的 Member 集合 (更明確的是，集合的 Add 方法)，以加入所需使用者的 FQDN。不過，最後一個步驟一點也不直覺化。它呼叫隱藏之 PSBase 類別的 CommitChanges 方法，以儲存變更。
PSBase 是直接表示基底 .NET Framework 物件的特殊類別。在此案例中，CommitChanges 不會在 Windows PowerShell 中直接公開 (實際上，ADSI 配接器未公開任何方法)，因此您必須移至基礎類別。這並非不可能發生，但當然也不直覺化。此外，它也說明在 Windows PowerShell 中尚未完全改寫目錄服務功能。
有幾個原因。首先，Windows PowerShell 團隊在末期的開發週期中，才將目前的 ADSI 支援加入殼層。殼層的架構設計人員 Jeffrey Snover 經常說：「交付即選擇」。該團隊必須在固定時間內開發和交付殼層，而且必須決定哪些保留至下一版。否則，他們很容易花數年新增功能，而永遠無法實際發行支援的產品。
不過，另一個原因是基礎 .NET Framework。它的 DirectoryServices 類別很複雜，在 Windows PowerShell 中改寫此複雜性會花許多時間並且需要縝密計劃。依我之見，Framework 類別也偏向 Active Directory，並未提供相媲美的支援給 WinNT 提供者，當然 Windows PowerShell 會繼承 Framework 所有這些限制。
我預期 Windows PowerShell 最終會有大為擴充的目錄服務支援，可能不是透過 ADSI 層，而是透過 .NET Framework 中的基本改進。同時，Windows PowerShell 中目前的 ADSI 支援可讓您執行大部分的系統管理工作，例如建立使用者、修改一般使用者屬性等等。
不要忘記，許多目錄服務工作都可透過 WMI 完成。如需使用 WMI 以提供比 ADSI 更多本機群組資訊的一些最佳範例，請參閱 microsoft.com/technet/scriptcenter/scripts 的指令碼。


 嗨，Scripting Guy！: 移除紅色彎曲線的指令碼
嗨，Scripting Guy！ 移除紅色彎曲線的指令碼 and Microsoft Scripting Guys
下載本文程式碼: HeyScriptingGuy2007_06.exe (151KB)
您在尋找將詞彙加入 Microsoft Word 字典更輕鬆的方法，來取代每次逐字手動加入的方式嗎？大家都是這樣吧？這個月，Scripting Guy 將說明如何在 Microsoft Word 中建立自訂字典，以及如何用程式設計方式設定 Word 以使用這些字典。
[圖 1]Word 文件顯示拼字錯誤
有特別注意到什麼嗎？沒錯：Word 在 Msgbox 等指令碼詞彙底下畫了條曲線。為什麼呢？因為 Word 無法辨識這些詞彙。無法辨識這些詞彙？拜託，Word；畢竟過去幾年來，Scripting Guy 已經輸入 Msgbox 這個詞好幾百萬次了。他們已經作過好幾百萬次的拼字檢查，而且告訴你說 Msgbox 拼法正確。結果你還是把 Msgbox、StrReverse 和 LTrim 標示為拼錯的字？發生了什麼事？
現在，在您急著為 Word 辯解之前，我們知道可以手動將這些詞彙加入 Microsoft Word 字典。但算了吧，我們可是 Scripting Guy，天啊，我們哪裡知道手工這檔事？再者，手動新增 VBScript 函數、Windows® Management Instrumentation (WMI) 類別名稱和 Active Directory® 安全性介面 (ADSI) 物件屬性這檔字事，老實說真的有點乏味。假如我們想要在所有電腦上這樣做呢？假如我們想要與忠實讀者分享這些正確的拼字呢？假如...嗯，您能夠意會就好。
重點是：肯定有更輕鬆的方法可以將指令碼詞彙 (或任何詞彙) 加入字典，而不需要每次逐字地手動加入。
結果是沒辦法。下個月見了！
沒有啦，開玩笑的。當然有更輕鬆地將詞彙加入字典的方法。我們馬上就會說明怎麼做。不過，先讓我們花一分鐘聊一聊字典。
說到字典，以下是字典的趣事。為什麼美國人將顏色這個字拼成 color，不含 u (color 而非 colour)？為什麼美國人將中心拼成 center 而不是 centre？答案是：因為編纂第一部美國字典的 Noah Webster 不喜歡英式拼法，因此有點武斷地變更了很多字的拼法。
好吧，不夠有趣。不然換您來說說字典的趣事嘛！
除了應用程式內建的標準字典，Microsoft Word 也讓您建立任意數目的自訂字典。根據預設，Word 隨附一個名為 Custom.dic 的自訂字典，通常可在使用者設定檔資料夾 (在 Windows XP 中，預設為 \Documents and Settings\username) 的 Application Data\Microsoft\Proof 資料夾中找到它。如果您以滑鼠右鍵按一下拼錯的字，並選取 [新增至字典]，該字就會加入 Custom.dic。
結果是，Custom.dic 只是純文字檔。在記事本中開啟它，您會看到類似以下的文字清單：
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
這就是我們以程式設計方式將指令碼詞彙加入 Microsoft Word 字典的方法。我們只需要建立包含這些詞彙的文字檔，接著設定 Word 使用該檔案做為自訂字典。到底這有多難呢？試想 Scripting Guy 願意親自這樣做，顯然一點也不難。
但請等一下：在開始做之前，我們必須很快地進行另一個附帶行程。在 Microsoft Word 物件模型中，自訂字典的相關資訊是儲存在 CustomDictionaries 集合中。該集合可用程式設計方式參照 Word.Application 物件和 CustomDictionaries 屬性，加以存取。例如，[圖 2] 顯示的指令碼會傳回與 Microsoft Word 所有自訂字典有關的資訊。
Figure 2 擷取自訂字典資訊的指令碼 (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
執行 [圖 2] 的指令碼，會得到類似下列的資訊：
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
很精明，對吧！
當然，取得現有字典的資訊與建立新的自訂字典不完全相同，有點像讀百萬富翁的故事和身為百萬富翁間的差異。因此，我們來看能否想出建立 Word 新自訂字典的方法。
我們先將所有 VBScript 函數加入一個名為 Scripting.dic 的新字典。以 VBScript 函數開始，因為我們必須在此加點工。不過，之後，我們會說明如何將 WMI 類別、ADSI 屬性和 Windows PowerShell™ cmdlet 加入字典，而且幾乎不需要任何加工 (不用說，對於幾乎不需要任何加工這話，Scripting Guy 都心知肚明)。
首先，建立 Microsoft Word 自訂字典就像下列一樣簡單：
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
如您所見，我們一開始會建立 Word.Application 物件的執行個體。您可能注意到，我們從未將 Visible 屬性設為 True，因此絕不會在螢幕上顯示 Word。為什麼？因為此指令碼只需要一秒左右的執行時間。因此，沒道理讓 Word 在螢幕上快閃，隨即消失。如果您喜歡 Word 的閃爍執行個體 (只為了知道指令碼確實有執行)，那麼只要將下列程式碼加到指令碼的第二行：
objWord.Visible = True
在建立 Word.Application 物件之後，接著使用下面這行程式碼來建立 CustomDictionaries 集合的物件參照：
Set colDictionaries = _
  objWord.CustomDictionaries
接著要呼叫 Add 方法來加入自訂字典。請注意，這個檔案不一定要存在，如果 Word 找不到名為 Scripting.dic 的檔案，它就會建立同名的空白新檔案。以下是加入自訂字典的程式碼：
colDictionaries.Add “Scripting.dic”
您可能也注意到，我們在加入新字典時沒有指定路徑，只將檔案名稱 (Scripting.dic) 傳給 Add 方法。沒關係。在此案例中，會在字典和其他校對工具的預設資料夾 (例如，C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof) 中建立 Scripting.dic。
假如我們想要字典位在不同位置呢？沒問題。下列命令會在 C:\Scripts 資料夾中建立 Scripting.dic：
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
假如我們稍後決定要除去自訂字典呢？還是沒問題。在此案例中，只要繫結至相關字典，接著使用 Delete 方法除去它：
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
[圖 3]在加入自訂字典之後的 Word 文件
老王賣瓜自賣自誇，這真的很方便使用，特別是您可以將 Scripting.dic 和建立自訂字典的指令碼與任何人分享。如此，他們的 Word 版本馬上就會將 Msgbox 視為拼法正確的字。如果 Scripting Guy 懶惰，我們大可在此結束本期專欄，而且您仍然有些收穫。但好戲在後頭。
請注意：其實我們很懶。但由於必須填滿專欄的剩餘空間，我們決定附贈一兩個指令碼。
您可能知道，VBScript 和 Windows Script Host 有點害羞，它們不太喜歡談論自己。不過，這不適用於 WMI、ADSI 或 Windows PowerShell。您只要開口問，這些技術就會提供類別、屬性、方法的資訊，差不多涵蓋您想要知道的一切。
以 ADSI 為例子。[圖 4] 顯示的指令碼會繫結至 Active Directory 架構，並會擷取使用者帳戶物件的所有屬性。接著將這些屬性寫入檔案 C:\Scripts\Scripting.dic。
Figure 4 將 ADSI 屬性名稱加入自訂字典 (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
很酷吧？只要少數幾行程式碼，我們已經建立包含 Active Directory 使用者物件所有屬性的字典。與您的指令碼設計師同事分享此程式碼，就不必再煩惱 streetAddress 或 givenName 這些屬性名稱標示為拼錯的字。當然，這可以無限延伸。想要加入 computer 類別的屬性嗎？那麼，以下面這行程式碼取代：
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
WMI 類別如何呢？[圖 5] 顯示的指令碼會擷取 root\cimV2 命名空間中的所有 WMI 類別，並會將此資訊寫入 C:\Scripts\Scripting.dic。
Figure 5 將 WMI 類別名稱加入自訂字典 (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
忘記 Windows PowerShell 使用者嗎？Scripting Guy 絕不會做那種事。好吧，我們確實忘了。但我們記得寫下這一行指令碼，它會傳回所有 cmdlet 名稱，接著將它們寫入 C:\Scripts\Scripting.dic：
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
本期專欄的美事是大家都學到新知。您學到如何建立 Microsoft Word 自訂字典，以及如何用程式設計方式設定 Word 以使用自訂字典。Scripting Guy 學到如果您要達成某件事，還是讓別人幫忙做比較好。如果行不通，永遠可以自己做。


 桌面檔案: 如何不遺失資料
桌面檔案 如何不遺失資料 and Wes Miller 重要資料經常遺失，次數之多令人驚訝。但事實是，由於人們未善盡保護之責，而遺失資訊。請探索您可以而且必須採取的重要步驟來保護組織的資料。
資訊渴望自由。不論託付的對象為何，或者您多努力鎖定這些零與壹，它們一定會找到堆疊中的漏洞。每天新聞都有大大小小有關資料遺失的報導。重要資料遺失次數如此頻繁，
[圖 2]我們都知道您很敬愛令堂，但這真的是很糟的密碼
密碼完整性和本機驗證很重要，但是除非本機系統上的資料經過實體保護或加密，否則仍有可能洩漏。單單密碼並不是解決方案。使用者密碼只是工具，讓想要破解互動式直接存取之系統，且沒有準備工具的攻擊者難以破解。

實體安全性
重要資料不應放在可實體破解或從辦公室移開的系統上。當某人開機到 Windows PE 並擷取資料時，如果您害怕系統遭破解，Windows PE 並不是嫌疑犯，而是您有其他問題。也就是，下列一或多項成立時。您的系統沒有適當的實體安全保護。它們已經受到保護，但您不信任存取系統的使用者。資料位在實體不安全的系統上，或者無法確保系統實體的安全，而且您並未使用磁碟區加密工具 (例如 Windows Vista 的 BitLocker™ 功能)，以減輕實體本身的弱點 (如需 BitLocker 的詳細資訊，請參閱本期 TechNet Magazine 中 Byron Hynes 的文章)。
想想看哪些系統可能有風險。是否可以實體保護它們？為什麼不將它們放在資料中心或其他限制存取的區域中？如果不可行，或者它是行動系統，您可以使用磁碟區加密軟體嗎？如果您無法採取以上的步驟，則將資料移至可施加保全或加密的系統。在先前提及的膝上型電腦遭竊的案例中，如果已透過安全磁碟區加密工具來加密磁碟區，資料大致很安全，不會被破解。
系統位在資料中心，不代表它很安全，如果您有一串連線到網際網路的 T1，仍然有風險。網際網路存取讓壞人進一步接近實體存取，因此請謹慎考慮對系統的威脅。請考慮將系統移至網路的不同區段，並在網際網路和相關系統之間至少再加上一層網路保護。

資料風險緩和
另一個可用的安全性措施是，透過將資料隔離至實體安全伺服器的應用程式或精簡型用戶端 (Thin Client) 工具，提供使用者存取。這表示可以透過 VPN 提供存取，以便離站使用者可存取。絕不能讓使用者的實體限制來支配資料處理方式。使用者需要存取，而且他的所在位置沒有寬頻或其他高速存取，並不代表您應該將資料移至使用者電腦上的本機執行個體。如果您完全無法移動系統，而且必須將它放在不安全的位置，則請使用磁碟區加密來保護資料。

系統內安全性
儘管您已盡力，但還是該為這個可能性做準備：某人可能藉由移除您的系統硬碟，並將它放在可重設 NTFS ACL 的另一個 Windows 系統，從而闖入您的系統。
您可以使用 Windows Vista 隨附的磁碟區加密。對於其他版本的 Windows，也有許多協力廠商工具可選擇。這些工具的使用複雜性各有不同，執行完整磁碟區加密和/或加密個別檔案或目錄 (由加密檔案系統 (EFS) 所許可) 的能力也不同。如果磁碟區經過加密，資料將受到完整保護 (除非遇到技術高超的小偷)。

封存的安全性
備份資料也必須經過保護。多數人因兩個原因而不安全地備份系統：在備份時加密會耗費太多時間和/或備份軟體不支援加密。
但如果您是要備份系統，特別是遵循離站備份的最佳作法時，您必須保護備份資料。使用 EFS (如果有的話) 或其他磁碟區加密軟體 (例如 Windows Vista 的 BitLocker 功能或其他協力廠商軟體) 進行加密，或購買包含加密功能且執行效能可接受的備份軟體。如果備份磁帶上的資料有些散亂，或在磁碟型備份解決方案中切碎資料，不代表資料就是安全的。設想傳輸機制本身遭破解。

傳輸安全性
您必須保護透過網路傳輸的任何資料。只使用安全通訊協定來存取遠端系統。使用加密版本的通訊協定，並且一定設想攔截式 (MITM) 攻擊是可能的。不要使用弱式加密或未加密的通訊協定，如果使用加密，不要使用弱式加密長度或演算法。您或組織中的其他人必須瞭解在基礎結構中系統間使用的所有通訊協定和加密演算法。

安全的刪除
我們都聽過從 eBay 或當地跳蚤市場買來的硬碟或儲存裝置，遭鑑識軟體或一般還原公用程式破解，而洩漏不可告人之秘密的故事。在轉售磁碟機之前，應該完全刪除資料。
如果組織有 UFD，請考慮強制使用加密公用程式。包含高風險資料的磁碟應該加密。但與大家認知不同的是，我不同意棄置前加密磁碟區就是棄置磁碟的安全方法。記得先前提及的醫療廢棄物比喻嗎？將系統上的資料視為危險廢棄物，並且將安全資料刪除公用程式視為處理方式。使用實作 DoD 5220.22-M 規格的資料刪除工具，例如 Mark Russinovich 的 SDelete，然後再將磁碟和系統釋出到二手市場轉售，或在組織內部重複使用。否則，下一個使用者就會知道前一個使用者的所有資料。

稽核
最後也很重要的一點是，資料安全性的另一項關鍵要素是稽核，甚至還可以加上威脅模型、組織的資料週期。瞭解可能外洩資料的弱點，並謹慎監控這些弱點。Windows 提供數個內建稽核工具。不過，使用稽核時，您很容易遇到資料溢位。確定您監控的是正確的區域，而且不致資料氾濫。監控弱點，用緩和措施適當補強，不要挖東牆補西牆。此外，確保使用者有處理資料的正確知識。他們是組織中許多層面的重要環節。您可以在＜其他資源＞資訊看板中找到更多指引。不要忘記遵循以上列出的所有建議，如果照做，您會睡得更安穩。
其他資源
＜核心基礎結構最佳化執行者資源指南 - 基本到標準化＞說明如何將 IT 基礎結構從高度手動和反應性的基本層級移至更具自動化、強制設定標準和改進作業的標準化層級。您可以從 go.microsoft.com/?linkid=5795711 下載該指南。可從 microsoft.com/io 下載＜其他基礎結構最佳化執行者資源指南＞。此外，如需更多安全性提示，請參閱網路安全十大定律。


 現場筆記: 與開發人員溝通
現場筆記 與開發人員溝通 and David Aiken 讓開發人員建立更易於管理的應用程式的方式比您想像的更容易。一切由溝通開始。開發人員看待軟體的角度與系統管理員不同。與開發人員溝通，系統管理員可以解釋什麼是重要的，而且開發人員可以根據這些資訊設計程式碼，得到更好的成果。
奇怪的是，開發人員看待軟體的角度確實與系統管理員不同。開發人員處理程式碼、追蹤、XML 設定檔、GUID 和組件。系統管理員則處理指令碼和 Microsoft® Management Console (MMC) 嵌入式管理單元 (至少他們想要這麼做)。
其實讓我們退後一步來看。在我看來，有些日子，整個軟體開發程序全亂了套。我們花許多資源來理解使用者的需求。我們建立原型、進行可用性研究、訪談，諸如此類，但在提供簡單一致的管理體驗方面，我們不及格。不及格太多了。
我過去認為 Xcopy、Regedit 和記事本是安裝軟體的最好方式。現在，我知道 Microsoft Installer (MSI) 才會自訂、安裝和解除安裝。我知道，期待系統管理員使用記事本編輯 XML 以設定 Web 服務，可能不是最聰明的主意，MMC 嵌入式管理單元 (或 Windows PowerShell™ 指令碼) 顯然是更好的選擇。我知道，堆疊追蹤對使用者或系統管理員在傳達問題根源和可能的解決方案時並沒有幫助，應用程式記錄中清楚記載的事件會更好。我知道，為了建立可由系統管理員管理和操作的軟體，我必須將他們視為使用者。
將系統管理員視為使用者，我可以定義使用案例、建立原型、進行可用性研究等等。如此，我就可以為系統管理員提供最佳體驗。換言之，這會協助他們安裝、設定、監視、疑難排解和修正我的軟體，而不需要打電話給我。如果我使用他們所熟悉的作業系統內建管理功能，我就可以大幅降低執行應用程式的成本 (問題不容易擴大)、改善客戶滿意度 (應用程式不常當機，而且他們可以很快地修正問題)，提高購買我的軟體 (而不是別人) 的可能性 (結果就是我可以買艘船在加勒比海上快樂地航行)。
好吧，開船那段是我在幻想。但讓開發人員建立更易於管理的應用程式可不是幻想，而是可達成的目標。而且您也可以幫忙。下次有問題發生時，不要只是轉寄電子郵件，低聲罵幾句。您可以建議他們撰寫應用程式記錄的事件、提供效能計數器或其他問題指標。更好的是，建議可能的原因和解決方案。要求他們為您建立 Windows PowerShell 指令碼或 MMC 主控台，以設定應用程式。重點是，開發人員不一定知道您存在，更甭提您的需求了。您得大聲說出來。


 Windows 機密文件: 新使用者的開始功能表項目
Windows 機密文件 新使用者的開始功能表項目 and Raymond Chen 試想如果有人買了新電腦，啟動 Windows 之後按 [開始] 按鈕卻看到空無一物的功能表，到時絕對會一頭霧水。[開始] 功能表之所以主動在未曾用過的系統上最常用的位置添加應用程式，無非是要提供令人愉悅的全新體驗。請看這些應用程式到底是如何挑選出來的。
我們曾想過要在這個原本空白的 [開始] 功能表上填入文字；比方像是「嘿，這地方現在雖然空白，將來必定會顯示您執行過的每個程式，相信我」。這樣做看似夠聰明，其實不但愚蠢且既無聊又難看。
我們陸續做了一些實驗，幾經思索最後決定沿用 Windows XP 的作法。誠如上個月的專欄所述，常用程式清單是以計分系統為基礎，即該份動態清單會顯示得分最多的程式。基於考量初次啟動系統的新使用者，我們給了幾種程式一些人為分數。因此，[開始] 功能表起初會抽樣顯示趣味性的程式，讓使用者大致瞭解接下來能夠做什麼。
人為分數的多寡都經過慎選，讓我們所中意的程式能得到高分而有資格列入常用程式清單，又不至於得分太高把使用者啟動的應用程式實際所得的分數完全比下去。
但若使用者是從 Windows 2000 升級，就不會頒發這些人為分數。屆時將使用 Windows 2000 [開始] 功能表的 Intellimenus 功能所用的分數來催生 Windows XP 計分系統。這樣一來，升級至 Windows XP 安裝的 [開始] 功能表便能立刻反映出使用者在 Windows 2000 上最常執行的程式。
在 Windows XP 初版中，頒發人為分數的考量是讓總共有六項最常用程式的清單上，前三項由 Windows 選定且後三項由電腦製造商選定。如果您是購買零售版而非預先安裝版的 Windows XP，Windows 便會填入後三項的其中兩項且最後一項留空。因此，您所執行的第一個程式將立刻出現在 [開始] 功能表上。
自 Windows XP Service Pack 1 起，這六個項目已略有改變。前兩項由 Windows 選定且第三項由美國司法部選定，最後三項則由電腦製造商選定。同樣地，若您購買了零售版的 Windows XP，即由 Windows 指定其中兩個電腦製造商項目，且最後一項仍將留空。
[開始] 功能表是 Windows 使用者介面中最顯而易見的部分，且誠如您所見到的，其既自然又直觀的外表乃是集結眾多心血的結晶。


 回信: 解答
回信 解答
Windows PE 入門
在拜讀 2006 年 9 月份 TechNet Magazine 期刊中 Wes Miller 的文章＜Windows PE 入門＞之後，我用 HTML for Applications (HTA) 架構精靈建立了功能表。我有多個與使用 Windows® PE 2.0 讓功能表運作的相關問題。
—Andy

以下是您的問題，以及 Wes 對每個問題的解答：

我如何知道選擇性軟體元件 HTA 和 Windows Script Host (WSH) 是從我的 ISO 檔案中執行呢？
如果您依照文件提供的指示，在 ISO 檔案中安裝選擇性元件，它們就應該會運作。我聽過它們在兩個狀況中不會運作：如果您未執行 peimg /prep 以準備映像，或者您未搭配 ImageX 使用 /commit 參數，以便在卸下 Windows PE 映像時，確實認可其變更。

我必須安裝 Windows Management Instrumentation (WMI) 嗎？文章中的精靈檔案顯示 Internet Explorer® 錯誤。
只要安裝 HTA，精靈檔案就應該會運作；它們非常原始。不僅不需要 WMI，實際上在您可以將 WMI 加入 Windows PE 之前，我已經寫好這些精靈了。

如何將 OC.bat 包含在我的 startnet.cmd 檔案中呢？
如果您是使用 Windows PE 2.0，則根本不需要使用 OC.bat，只有 1.x 才需要它。不同於 OC.bat，Windows PE 2.0 可讓您在不使用修正程式的情況下新增元件。

在我的功能表完全運作之後，我可以在其中使用 Wes 的一些程式碼嗎？
歡迎您採用任何程式碼範例，請隨意重複使用它們，但您不得將其做為範例程式碼套件的一部分而轉售或重新散佈。如需詳細資料，請參閱 TechNet Magazine 網站上的授權合約。

什麼是 Windows PE？
從哪裡可以找到 Windows PE 建置工具？我可以下載它們嗎？或者必須花錢購買？
—Franklin
Windows PE Build Tools for Windows Vista™ 是 Windows 自動化安裝套件 (WAIK) 的一部分。您可以從 go.microsoft.com/fwlink/?LinkId=85377 下載此套件。
WAIK 只適用於 Windows Vista 系列作業系統。對於 Windows XP 部署，在 Business Desktop Deployment Solution Accelerator 有很多類似工具。不過，在 Windows Vista 中，Windows PE 的授權方式已變更。之前 (Windows XP)，只透過「軟體保證」授權提供 Windows PE (如需詳細資料，請參閱 microsoft.com/licensing/sa/benefits/winpe.mspx)。

檔案伺服器資源管理員
檔案伺服器資源管理員套件是否可公開下載，以便用於原始版本的 Windows Server® 2003？或者，此套件只與 R2 版本相容？
—Dan
檔案伺服器資源管理員是 Windows Server 2003 R2 的功能。由於該版本的相依性，目前沒有計劃提供適用於先前版本的檔案伺服器資源管理員。

深入探索核心
在拜讀 Mark Russinovich 的文章 深入探索 Windows Vista 核心：第三篇之後，我有兩個問題。首先，我注意到 Process Explorer 會顯示每個開機工作階段中 exe 或 DLL 檔案的隨機所在位置。惡意程式有可能使用相同的機制，來判斷它要入侵之程式碼的位置嗎？第二，如果有 256 個可啟動隨機化的位置 (如果我對文章的理解正確)，在工作階段的目標程式碼保持靜態時，應該如何預防惡意程式的「暴力」探查呢？
—Joe

對您的所有問題，Mark 的解答如下：

Process Explorer 展現雞生蛋還是蛋生雞的問題：惡意程式無法查出 DLL 所在位置，因為它無法查出傳回此資訊之 API 的所在位置。惡意程式的「暴力」探查不是可靠的插入法，因為如果惡意程式猜錯，它很可能會讓它想要感染的應用程式當機。最起碼，隨機化會讓病毒擴散變慢。在最佳狀況中，它會防止惡意程式傳染給系統。

與我們連絡
有話要說嗎？不要害羞！我們很樂意聽見讀者的聲音。您可以透過電子郵件地址 tnmag@microsoft.com 與我們連絡。