June 2008 June 2008
安全性: 世紀大爭論：透過隱匿來實現安全
透過隱匿來實現安全 (Security by obscurity) 所採取的措施，並非移除攻擊標的，而是隱藏攻擊標的。有人抗議這是不良作法，但也有人聲稱為了成就較大規模的策略，每個小環節都不容忽視。爭論的情況相當熱烈，有些頂尖的安全性專家便分成兩派，分別站在各自的立場解釋透過隱匿來實現安全，雙方爭論僵持不下。 Jesper M. Johansson and Roger Grimes
安全性: 全新的 Elevation PowerToys for Windows Vista
Michael Murgolo 再次談論 Elevation PowerToy 的最新動態。您會看到「以系統管理員身分執行」增強功能與協力廠商指令碼工具搭配使用，透過這種方法可取代在 Windows Vista 中被移除的一項便利的 Windows XP 功能，另外還有許多更加實用的工具。 Michael Murgolo
安全性: BitLocker 磁碟機加密的進展
Windows Vista SP1 和 Windows Server 2008 針對 BitLocker 引進了重大改變，包括支援資料磁碟區，以及提升防護功能以對抗密碼編譯攻擊。Byron Hynes 將探討新功能，說明如何在伺服器上使用 BitLocker，並討論最近與 BitLocker 相關的一些媒體報導。 Byron Hynes
安全性: 透過軟體限制原則鎖定應用程式
若您想要降低組織內桌上型電腦的擁有權總成本，應用程式鎖定應該能幫上大忙，它可讓您限制與不受支援應用程式相關的 IT 問題。一同來了解您要如何運用軟體限制原則和群組原則，來控制在整個 IT 基礎結構當中執行的應用程式。 Chris Corio and Durga Prasad Sayana
安全性: 管理 Windows Vista 防火牆
最新版的 Windows Vista 防火牆提供了令人眼睛一亮的新功能，使它一躍成為企業環境無法抗拒的首選。Jesper Johansson 將概略敘述 Windows 防火牆的進化歷程，並且深入探討讓系統管理員想要仔細一探究竟的加強功能 (例如，新規則和設定檔、網域隔離以及加密)。 Jesper M. Johansson
安全性: 使用數位憑證保護電子郵件的安全
「安全多用途網際網路郵件延伸」可讓您隱藏正在傳輸的資訊、驗證寄件者，以及驗證訊息。一同來了解如何使用數位憑證保護電子郵件的安全，以及如何疑難排解您可能在 S/MIME 系統上遇到的問題。 Matt Clapham and Blake Hutchinson
Columns
編輯的話: 世紀大爭論: | 讀者來信: 讀者有話直說: | 工具箱: 適合 IT 專家的新產品:
SQL 問答集: I/O 錯誤、資料庫鏡像及其他主題: Paul Randal 將解答您的 SQL Server 疑問，向您說明如何在測試資料庫內製造損毀，幫助您預防壓縮-成長-壓縮-成長的循環，並解釋您要如何判斷能在不折損效能的情況下鏡像多少資料庫。Paul S. Randal | 公用程式焦點: Windows Vista Upgrade Advisor: 您準備好把公司系統升級到 Windows Vista 了嗎？本文將帶您探討 Windows Vista Upgrade Advisor 如何協助您判斷系統是否已經準備好安裝 Windows Vista，以及系統支援哪些版本。Lance Whitney | Sharepoint 內幕: 分散網站管理: 一同探討將 SharePoint 網站的系統管理控制委派給個別部門，同時在 SharePoint 基礎架構上保持集中式系統管理控制的作法有什麼好處及影響。Pav Cherny
Windows PowerShell: 美觀大方: 一同來探索 Windows PowerShell 的物件導向本質如何讓您套用格式到它的輸出。Don Jones | 嗨，Scripting Guy！: 不太辛苦的工作照樣也有回報: Scripting Guy 仔細思量辛苦工作、幸福真諦和輸出資料，並以容易閱讀的表格格式在命令視窗中顯示結論。The Microsoft Scripting Guys | 桌面檔案: 安全性和循規: IT 專家常發現自己要面對目標相互抵觸的困境。一同來了解一下常伴隨循規而發生的安全性折損情況。Wes Miller
IT 產業: 成為環境領導者的 10 大關鍵因素: 隨著 IT 部門在企業環境研究計劃中的重要性逐漸提升，IT 專家開始有機會策動改革，成為公司與業界的實踐先驅。下面我們將概略說明，如何成為一位有效主導公司在環境與永續方案的實踐先驅。Michael Walsh and Eliza Walsh | 現場筆記: 共用分割畫面: 分割畫面是由 Microsoft Research India 所開發，可讓兩個使用者共用同一個監視器，分別執行不同的 OS 執行個體。Kentaro Toyama | Windows 機密文件: 史上最糟的兩款電腦: Raymond Chen 輕鬆地追憶使用史上最糟電腦的經驗。Raymond Chen


安全性
世紀大爭論：透過隱匿來實現安全
Jesper M. Johansson and Roger Grimes
簡介:
  • 定義透過隱匿來實現安全
  • 評估透過隱匿來實現安全的措施
  • 評量重新命名系統管理員帳戶的價值
  • 訂定明智的風險管理決策

「透過隱匿來實現安全」一詞常受到安全性人員 (特別是那些喜歡自稱專家的人) 的譏諷。那些譏諷幾乎與某些圈子所用的四個字母的字沒什麼兩樣，
根據 Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity) 的描述，「透過隱匿來實現安全」所表現的，正是安全性真正引起爭論的一面。您常常會看到有些人的努力，因為被戲稱為「只不過是透過隱匿來實現安全」而遭到漠視。
簡而言之，透過隱匿來實現安全違反了科克霍夫法則 (Kerckhoffs' Principle)，這項法則認為系統應該是因為它本身的設計而受到保護，而不是因為攻擊者不知道它的設計而得到保護。科克霍夫法則的基本前提是，保密的時間根本維持不了多久。
其中一個非常貼切的例子就是 Windows NT® LAN Manager (NTLM) 驗證通訊協定，它最初是被視為設計秘密。為了針對 UNIX 作業系統實作 Samba 交互操作性產品，Samba 小組不得不對通訊協定進行反向工程。此舉不但產生出最完備的 NTLM 說明文件 (monyo.com/technical/samba/translation/ntlm.en.html)，同時也發現了許多問題。由於密碼編譯引發了這麼多的安全性考量，加上揭露了這麼多秘密設計，因此許多從事安全性的人深信，所有的資訊安全性都應該遵守科克霍夫法則。
但是透過隱匿來實現安全真的只是有害無益嗎？本文將解釋何謂透過隱匿來實現安全，嘗試點出為什麼許多人都認為它是浪費時間 (而其他人則不以為然) 的作法，並且向您說明為什麼答案總是比當初看起來的複雜得多。

透過隱匿來實現安全的簡介
Steve Riley 提出的「不要變更預設值」論點
對於重新命名的問題，我是站在「不要變更」這邊。因為這根本不是安全性的問題 — 而是系統管理的問題。我越是花時間思考系統管理空間 (因為管理和安全性已渾然一體)，越是贊同不做一些有可能增加系統脆弱度的作法。而變更預設值，肯定會增加脆弱度。人們變更預設設定的理由有二 (喔，好啦，有三)。
  • 對於變更所提供的功能有所需求。
  • 假定變更會提高安全性。
  • (警告：純屬愚蠢)。有人在雜誌報導上讀到。
如果您是因為第一個理由而需要變更預設名稱的話，儘管放手去做。這類變更不太會造成系統的不穩定，因為它們通常已經經過測試了。
如果您是因為第二個理由而變更預設值的話，請務必三思而後行。這類變更大多未經軟體製造商的測試，因此製造商無法預測在您進行變更之後，系統會出現什麼反應。而且，通常還有更好的替代方案能夠提供真正的安全性。
如果不肖份子剛好知道帳戶名稱，那又怎麼樣？將不肖份子擋在系統之外的是密碼，以及密碼的強度。極力想把 Administrators 和 Guest 之類的預設帳戶名稱，改成不好猜測的名稱，往往只是不想使用強式密碼或通關密語的一種逃避作法。唯有直搗真正問題 (差勁的密碼) 所在，才能防止弱點 (變更預設名稱) 暴露。

透過隱匿來實現安全，並不是對問題視若無睹的措施。比方說，如果公司在邊緣路由器封鎖網路新聞傳輸通訊協定 (NNTP) 以防止員工閱讀新聞群組，但卻允許輸出安全殼層 (SSH) 的話，就不算是透過隱匿來實現安全。因為 SSH 可以接通每個通訊協定，所以問題很明顯；實作愚蠢的緩和措施，除了阻礙合法使用者在不違反安全性原則下完成合法的工作之外，其他什麼事都不能做。這類措施並不是透過隱匿來實現安全，而是愚蠢且毫無意義的行為。
如同「透過隱匿來實現安全」一詞中的「安全」一字所暗示，您確實可以從這種措施中獲得一些保護。不過，這也暗示您實際上並未採取任何行動來停止一或多個攻擊標的，而這也是問題所在 (攻擊標的基本上是攻擊者可以存取系統的管道)。
比方說，假設您的網頁伺服器相當脆弱，只要在 TCP 連接埠 80 公開入侵，就可以將它輕鬆攻陷。如果要關閉那個標的，可以修補網頁伺服器，或者把它關閉起來，兩者都可以徹底停止這個標的。您可以使用防火牆或 IPsec，來關閉除了幾部選定電腦以外所有電腦的連接埠 80，藉此停止部分攻擊。此舉雖然無法完全封鎖攻擊標的，卻可以明顯緩和問題。
另一方面，透過隱匿來實現安全還包括採取一些並非停止攻擊標的，而是隱藏攻擊標的作法。舉例來說，您可以把網頁伺服器移到連接埠 81 (而不是連接埠 80)，只讓那些知道網頁伺服器在哪裡的人存取。這就是爭論所在。在現實情況下，把網頁伺服器移到連接埠 81 只會阻止部分攻擊，而且多半只會造成使用者的不便。厲害的入侵者會直接對大量的連接埠執行連接埠掃描器和網路橫幅抓取器，來探索非標準連接埠上的網頁伺服器。只要他一找到網頁伺服器，就會對伺服器發動入侵，因為您實際上並沒有移除攻擊標的，只是 (暫時) 隱藏攻擊標的而已。
難道這就表示您連試都不該試嗎？答案要看情況而定。這與 [資訊安全性] 欄位裡面的所有一切一樣，全都與風險管理息息相關。為了瞭解值得考量的關鍵要素，我們將迅速查訪其他幾項透過隱匿來實現安全的措施，然後詳細討論其中一項 — 重新命名系統管理員帳戶。

評量安全性措施
透過隱匿來實現安全的範例有很多，它們可能是由系統和網路管理員採取的動作，也可能是由軟體開發人員發動的動作。但是兩者共通點都是將它隱藏起來，不讓潛在的攻擊者發現，企圖藉此減輕弱點。
難道在這些程序當中，真的找不到一絲有利的效果嗎？難道一口咬定所有透過隱匿來實現安全都是有害無益的作法，真的就公平嗎？其實，當中至少有部分措施還是有人支持的。例如，您可以在 Windows® 的 Windows 檔案總管隱藏磁碟機代號。許多環境 (尤其是學校電腦室) 都是利用這個方法，防止使用者將資料存到硬碟中。當然啦，大部分的應用程式還是能夠把資料存到硬碟當中，所以它也不能算是最佳的安全性措施。不過，實作這種措施的機構常常宣稱它硬碟上的資料的確因此變少了。
Windows 上另外一種經常實作的透過隱匿來實現安全作法，是關閉系統管理網路共用 (例如 C$、Admin$ 等等)。據說此舉可以防止攻擊者從遠端連接到電腦。其實這不僅不屬實，而且擁有可使用系統管理共用的帳戶的攻擊者，還可以從遠端重新啟用那些相同的共用。但是許多組織卻發誓停用這些共用，確實可以降低它們網路上發生惡意程式碼的頻率。
對於這種錯放精力的情況，我們最津津樂道的一個範例，就是 Windows 中 [允許卸除而不須登入] 設定。如果將它設為停用，登入畫面就會隱藏 [退出電腦] 按鈕，而讓攻擊者無法正常退出電腦。當然啦，不管那個按鈕看不看得見，入侵者大可把電腦跟基座一同塞到袋子裡面走人。這種可能性連透過隱匿來實現安全都搭不上邊。
另外一個明顯的範例是 [允許伺服器操作者排程工作] 設定，這個設定正如其名，它允許屬於 Server Operators 群組成員的使用者排定工作的時程。這種問題很敏感，因為這類工作可能會以本機系統身分執行，而且應該只有系統管理員能夠排定以本機系統身分執行的工作。當然啦，伺服器操作員有可能透過各種不同的標的讓他們成為系統管理員，因此預防他們透過這種方式排定工作，實際上所獲得的成效也是微乎其微。
但是有許多組織卻很喜歡這個設定，因為它容許工程師採用伺服器操作員而不是系統管理員的身分，也就是說，他們比較不可能意外摧毀伺服器。這本身多少有些好處。
那麼結論呢？很明顯地，這些問題有的可能非常複雜。我們花了不少時間痛快地爭論這類措施。Roger 堅持這類作法有其價值，而 Jesper 則認為這多半只是浪費時間而已。那麼就讓我們探索一下透過隱匿來實現安全其中一個最常引用 — 和爭論 — 的案例：重新命名系統管理員帳戶。Roger 代表這項措施的正方，而 Jesper 代表反方。安全性名人 Aaron Margosis 和 Steve Riley 也分別在「重新命名系統管理員帳戶」和「不要變更預設值」資訊看板中加入討論。

隱藏系統管理員帳戶
安全性專家常常建議將系統管理員帳戶 (相關識別元 (RID) 500) 改成一般大眾所不知道的名稱，有幾份 Microsoft 強化指南中也提及了這種作法。群組原則甚至還包含了一個用於重新命名系統管理員帳戶的設定，如 [圖 1] 所示。其構想是，要是重新命名系統管理員帳戶的話，攻擊者就比較不容易以真正的系統管理員身分登入了。當然囉，使用群組原則進行這項作業的問題很明顯，那就是經過重新命名的系統管理員帳戶，在套用這個群組原則物件的每一部電腦上，都是採用相同的名稱。此舉無疑就降低這個安全性措施的隱匿價值了。
[圖 1] 重新命名系統管理員帳戶
[圖 1] 重新命名系統管理員帳戶 (按一下影像可放大檢視)
另外還有很重要的一點是，只要使用者具有合法的帳戶，無論系統管理員帳戶是否經過重新命名，都可以擷取到該帳戶的名稱。凡是系統管理員帳戶都有一個 RID ─ 500。只要簡單詢問一下含有 RID 500 的帳戶名稱，任何擁有帳戶的使用者都可以查看它的實際名稱，如 [圖 2] 所示。
[圖 2] 尋找重新命名的系統管理員帳戶
[圖 2] 尋找重新命名的系統管理員帳戶 (按一下影像可放大檢視)

Roger 的申論
就我聽到反對重新命名系統管理員的主要論點是，要將任何安全性主體帳戶名稱轉換成其相關安全性識別元 (SID) 並找出它的 RID，根本就是易如反掌。而且只要是真正的系統管理員帳戶，都有一個 RID ─ 500。所以，若是攻擊者輕易就可以將使用者帳戶名稱轉換成 SID/RID 組合，並找出 RID 500，那又何苦來哉呢？
但是事情並沒那麼簡單。若要將使用者帳戶名稱轉譯成 SID/RID，必須能夠存取 NetBIOS 或 LDAP 連接埠才行。而大多數周邊防火牆都不允許在網際網路上進行這類存取，因此除非攻擊者完全略過防火牆，否則根本無法進行轉譯。再者，除了網域控制站 (DC) 以外，Windows XP 及之後的 Windows 版本並不能進行匿名 SID 轉譯。以大多數對外的電腦 (也就是風險最高的電腦) 來說，攻擊者必須具備驗證過的憑證，才能把名稱轉譯成 SID。
因此，若要發動轉譯攻擊，得繞過不少真正的深度防禦障礙才行。即便攻擊者克服了這些障礙，最後還是會陷入跟沒有改變帳戶名稱一樣的情況。所以重新命名系統管理員帳戶只會提高安全性，不會有任何害處。
另外一個秘密 假如攻擊者不知道系統管理員帳戶名稱，它就變成了另一個「秘密」標籤，跟密碼類似，攻擊者必須要知道才行。不可否認的，使用者帳戶名稱明顯不如系統管理密碼複雜，但它仍舊可以多建一道屏障，以指數方式將猜測/破解密碼的問題複雜化。如果您曾經做過密碼滲透測試，一定知道要猜中使用者名稱和密碼，需要下多少功夫。它結合了一項原本就很困難的工作，讓它難上加難。
阻撓自動化惡意程式碼和指令碼小子 我投入 Windows 安全性防禦至今已有 22 個年頭，過去 5 年來也執行了八個公開在網際網路上的 Windows 誘餌 (honeypot)。這段時間內，我從來沒看過自動化惡意程式碼 (絕大多數的攻擊都是由此構成) 使用除系統管理員 (或者在 *NIX 系統的情況下，稱為根) 以外的任何使用者帳戶標籤。如果您將系統管理員帳戶重新命名，等於是馬上殺了仰賴系統管理員名稱的所有惡意程式碼。換句話說，等於降低了安全性風險。
指令碼小子的情況也是一樣。就我所知，每本「暢銷」的 Windows 入侵手冊，都有提到將名稱轉譯成 SID 的方法，但是基於某些原因，要是我同時有個「假」的系統管理員帳戶來分散注意力的話，在誘餌上就完全看不到這種情況。只要是精明的駭客，就應該隨時確認他們找到的系統管理員帳戶是不是真正的系統管理員 (RID 500)，但他們經常不這麼做。我也不知道為什麼，要怪就怪駭客懶惰和人的本性吧。
連大多數高手也裹足不前 這實在讓大部分的人感到訝異。其實只要執行誘餌幾年的時間，很快就能區別自動化攻擊、指令碼小子和高手之間的差異。過去五年以來，我的誘餌報告了上百萬次的攻擊，卻從來沒看過高手在有假系統管理員帳戶的情況下進行 SID 轉譯。
我很肯定確實有犯罪高手在進行 SID 轉譯，但是我敢打賭那只佔少數，而且我從來不隨便記錄。為什麼高手不這麼做呢？我猜是他們覺得絕大部分的人都不這麼做，所以他們也沒有理由這麼做。
簡化警示 現在另一方爭議，若是重新命名系統管理員帳戶開始盛行的話，可能會失去它作為隱匿措施的價值。爭論點在於惡意程式碼、指令碼小子和高手會改變他們的預設戰術，改找系統管理員以外的名稱。而這樣的顧慮是有根據的。所幸，它並不會改變基本的情況。首先，若是 Windows 具備超級權限的帳戶並不是取名為 Administrator 的話，惡意駭客就必須多下點功夫。事實就是如此。而且若是惡意駭客必須多費心思的話，他就更不可能採取攻擊的途徑，也許因而讓其他彌補深度防禦的手段趁機更快速的偵測出惡意活動。
這也將主題帶到我贊同重新命名的最後一個觀點。如果您的系統管理員帳戶從來就不叫 Administrator，而且您也使用那個名稱建立了另外一個帳戶 (如 [圖 3] 所示)，那麼這個帳戶就是一個良好的警示機制。如果事件監視偵測到有登入嘗試使用預設名稱的話，就得馬上探究這個事件。
[圖 3] 以名為 Administrator 的誘餌帳戶嘗試登入，可視為早期的警告
[圖 3] 以名為 Administrator 的誘餌帳戶嘗試登入，可視為早期的警告 (按一下影像可放大檢視)
我們的事件日誌充斥著一堆沒有任何意義的「不良」登入，這充其量不過代表使用者 (或 Windows) 是使用錯誤密碼或諸如此類的東西進行登入。如果您的系統管理員帳戶就叫做 Administrator 的話，您該如何輕易分辨這到底是正常登入還是惡意登入呢？如果您從來沒有一個登入帳戶叫做 Administrator，卻偵測到有人以該帳戶名稱登入，那麼大概就知道這不是善意的登入了。早期意義不大的警告，在如今的防禦環境下卻具有相當的價值。

Jesper 的反駁
Aaron Margosis 對重新命名系統管理員帳戶的論點
Jesper，在理想的世界中，您絕對沒有錯。密碼永遠固若金湯，暴力猜測根本別想得逞，而 -500 本機系統管理員帳戶也只有在緊急修復之時才會使用。但在真實的世界裡，情況並非如此。
不管您多麼宣揚安全性，尤其是您自編自導的絕妙通關密語 (《世紀大爭論：通關密語與密碼比較》，第 1、2 和 3 部，網址是 go.microsoft.com/fwlink/?LinkId=113157、go.microsoft.com/fwlink/?LinkId=113159 和 go.microsoft.com/fwlink/?LinkId=113160)，許多系統管理員對於什麼才算是強式密碼，多半沒有適當的了解。
才沒多久以前，從多字元集挑出八個隨機字元構成的密碼還被視為強式密碼呢，摩爾定律卻證明這種情況維持不了多久。其罪魁禍首不外乎就是欠缺使用者 (和系統管理員) 教育，而且這種情況未來很有可能持續下去，至少持續到密碼強度成為有線電視新聞頻道的熱門話題才會改變吧。
所以現在要猜中真實世界的密碼，不必花上 600 年時間，通常一頓午餐就夠了，只要加個 x1000 倍率器就可以得到真正的值。面對許多想要大力攻擊名叫 Administrator 的帳戶的自動化攻擊，只要將帳戶重新命名，即可使它刀槍不入。
要重新命名系統管理帳戶，一般所需投入的時間和精力通常不多，大概跟您注意到的一樣，只是個簡單的 GPO 設定而已。事實上，美國政府的聯邦桌上型電腦核心設定 (Federal Desktop Core Configuration，csrc.nist.gov/fdcc) 還規定必須重新命名 -500 帳戶呢。重新命名不過是許多必要的設定之一，而且並不會花太多時間或精神。也沒有人對於重新命名的價值因此產生錯誤的安全感 — 我還沒聽過有人這麼說：「我們不需要補充程式管理，因為我們已經把系統管理員帳戶重新命名了」。
如果整個組織把帳戶全部改成一樣的名稱時，重新命名還有什麼價值嗎？價值不大，但多少還是有：第一，它會封鎖料想系統管理員的自動化攻擊。第二，潛在攻擊者集合不見得隸屬於知道新名稱的「任何人」集合 (最大風險可能是發生在本機系統管理員帳戶 — 無論經過重新命名與否 — 在組織內共用共同密碼時。管理這些密碼一直都是很大而且很重要的問題。停用 -500 帳戶的確是解決這種問題的辦法之一，但是萬一無法使用網域帳戶時，這個做法反而會封鎖重要的修復管道)。在此我也要指出，長久以來我們的安全性指南就建議我們將預設帳戶重新命名，因此這種作法不僅已經經過測試，而且完全受到支援。
到目前為止，我想我們應該都知道，隱匿措施本身所構成的防禦能力並不充足，但是它們可以強化其他安全性措施，而 Roger 的資料也清楚闡明了這點。只要實作的成本不高，組織就不應該把它們排除在外。

至於我的論點是，反對重新命名系統管理員帳戶是有其根據的。不過，在繼續討論之前，我必須承認 Roger 最後一個論點是蠻有效的。但是在高度管理的環境當中，任何使用系統管理員帳戶進行的登入都應該接受調查，因為這個帳戶應該只用於緊急修復的情況。
多此一舉 重新命名系統管理員帳戶原本要減輕的主要風險，是預防有人從遠端猜測其密碼。但重新命名系統管理員帳戶只會阻撓在電腦上沒有其他授權帳戶的使用者。這類攻擊者通常會嘗試一連串隨機的密碼登入系統管理員帳戶。不過無論攻擊者是否猜錯帳戶名稱或密碼，他都會收到相同的錯誤訊息。
這就表示重新命名系統管理員帳戶的主要爭議 — 指令碼小子會消失 — 是有瑕疵的。他們並不會因為系統管理員帳戶有經過重新命名，而比在原始名稱時更快消失，因為他們根本無法分辨！無論如何，他們猜測的都是同一組隨機密碼，然後再移往下一個潛在的受害者。
這表示只要系統管理員帳戶的密碼強到足以擊退攻擊，那麼將帳戶重新命名就沒有多大意義了。假設我們的系統管理員帳戶密是 15 個字元，由整個鍵盤挑選出的大小寫字母、數字和符號所組成。在網路上要猜中那個密碼大概需要花上 591,310,404,907 年的時間，相較之下，大約是宇宙存在時間的 43 倍長。
現在，假設我們把系統管理員帳戶重新命名，然後改成 1,000 個可能的值之一。這麼一來，就可以把猜中密碼的時間延長到 591,310,404,906,787 年，或是宇宙存在時間的 43,161 倍長。這樣有比較安全嗎？當然啦，後者的安全度比起前者來說，是十的三次方倍。我們有降低攻擊者猜中密碼的可能性嗎？嗯，無論哪種情況都微乎其微。換句話說，用白話一點講，與原始系統管理員帳戶名稱比起來，我們得到的結果肯定沒有好到哪裡去。因為將帳戶重新命名會刪除嘗試使用它的惡意程式碼，並不表示您沒有將帳戶重新命名，就會讓惡意程式碼得逞。事實上，假如您使用強式密碼 (您是該這麼做) 的話，無論帳戶名稱為何，都可以確保惡意程式碼無法得逞。
重新命名系統管理員帳戶顯然是出於安全性指引的需求，但那並不表示它就是有用，甚或是有效的安全性措施，反而只會奪取您對安全性作出適當風險管理決策的能力。安全性指南時常要求您做出一些根本沒什麼差別的設定，而且在許多情況下，那些設定甚至根本不存在。最後，要在安全性領域裡面穩定前進，必須探視需求，並且實際分析問題，然後評估緩和措施是否合理。有一點必須特別注意 — 那就是攻擊者以功能作為目標這一點，並不足以構成修改該功能的充分理由。您只有在能夠合理預期不修改功能就會讓攻擊得逞的情況下，才能夠修改功能。
如果您設有強式密碼，那麼無論帳戶是否重新命名，攻擊成功的可能性實際上是零。因此，只要您設定強式密碼，就沒有特定的安全性理由需要把帳戶重新命名。再者，如果您像我一樣稟持這樣的原則操作：沒有東改西改的電腦上可能還比較穩定 (順帶一提，這是不爭的事實)，那麼就更沒有理由重新命名系統管理員帳戶了。
將焦點轉移到低價值緩和措施 低價值的透過隱匿來實現安全的緩和措施，其問題出在它們可能會轉移公司高價值緩和措施的焦點。比方說，投入重新命名系統管理員帳戶的時間和精力，並不能用於其他作業上。因此如果其他作業比重新命名系統管理員帳戶的價值還高的話，公司便錯失一個良機了。雖然聽起來不足以構成像樣的成本，但如果重新命名的系統管理員帳戶多達 50,000 個的話，您應該就可以意會了。
更糟的是，一旦實施低價值緩和措施之後，公司的領導階層可能就不管事了。管理階層不見得都能了解透過隱匿來實現安全的緩和措施，其最低價值在哪裡，因此可能不會採取其他行動。這麼一來可能會為公司帶來不小的風險，但是只要管理階層願意投入時間和精力來了解所實施的緩和措施的價值，就可以輕鬆避免這種風險。
高昂的管理成本 最後一點，管理成本可能相當高昂 (這要看緩和措施實作的好壞而定)。如果您是直接設定群組原則物件 (GPO)，來重新命名系統管理員帳戶的話，倒是可以把成本降得很低。因為每個人都知道名稱，而且部署的成本也幾近於零。不過，就像我之前所說的，只要擁有帳戶，都會知道改成什麼名稱，所以它也沒什麼價值就是了。因此，若要充分發揮這項緩和措施的價值，必須在不同的主機上使用不同的名稱，但是這類系統的管理成本就非常高昂了。
所以您最好還是使用像 passgen (protectyourwindowsnetwork.com/tools.htm) 這樣的工具，在網路上對所有系統管理員帳戶設定 100 個字元完全隨機的密碼，然後對日常管理工作改用不同的帳戶。由於系統管理員帳戶是專門用來修復嚴重損毀 (在 Windows Small Business Server 2003 上除外)，因此對您的網路管理系統應該不會有任何影響。再者，攻擊者要正確猜出任何一個系統管理員帳戶的密碼，可能比大海撈針還難。所以建議您還是專心構思獨特的強式密碼吧，至於指令碼小子要怎麼猜，就隨他們去猜嘍。

重點就是風險管理
實際上任何透過隱匿來實現安全的措施，都可以利用我們在本文所述的方法加以分析。每一種計畫都各有其優缺點，適合這家公司的策略，不見得就適合另一家。最後，這就變成了風險管理的問題。風險比實作解決方案的成本還重要嗎？您為保護資訊資產所作的每項決策都必須是明智的風險管理決策，抉擇很少是黑或白。
沒錯，您的確是有現成的決策可用。比方說，雖然您可以選擇不要加密信用卡資訊，或是儲存信用卡確認碼，但這兩種作法都可能使您無法接受信用卡付款。這項決策對您業務可能產生的負面影響是，您其實沒有其他選擇。換句話說，雖然這是風險管理的決策，但卻是很容易作出的決策。
同樣地，一般正常人也不會把開放式無線網路，連接到商店內部網路的後端。不過這並不表示這樣的決策不是風險管理的決策。它其實就是風險管理的決策。也許有人還是會選擇這麼做，但他就必須自行承擔這麼做的後果 (討厭的是，這種情況好像從來沒真正發生過)。
此處所要採取的重要步驟是，清楚表達您要解決的問題、針對該問題所提出的解決方案，以及各種方案的優缺點。這麼一來，您就擁有制定明智風險管理決策所需的資訊了。如果沒有這項資訊的話，只能根據直覺做決定，而在這種情況之下做出的決策多半不怎麼樣。

Jesper M. Johansson 是負責安全性軟體的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有管理資訊系統 (MIS) 的博士學位，研究安全性長達 20 多年，是企業安全性領域的 Microsoft MVP。Jesper 最新著述為《Windows Server 2008 Security Resource Kit》。
Roger Grimes (CPA、CISSP、MCSE：安全性)，Microsoft ACE 小組的資深安全性顧問，著作或合著了八本關於電腦安全性的書籍，並且撰寫超過 200 篇雜誌文章。他經常發表安全性研討會的演說，並且是 InfoWorld 安全性專欄作家。
© 2008 Microsoft Corporation 和 CMP Media, LLC.保留所有權利；未經允許，嚴禁部分或全部複製.


安全性
全新的 Elevation PowerToys for Windows Vista
Michael Murgolo
簡介:
  • 協力廠商指令碼工具的「以系統管理員身分執行」功能
  • 以其他使用者身分執行
  • 從此處以系統身份開啟 CMD 和 Windows PowerShell 提示
  • 拖放式提高權限小工具
下載本文程式碼: Elevation2008_06.exe (197KB)

歡迎閱讀另一期的 Elevation PowerToys for Windows Vista。我在 2007 年 6 月份的《TechNet Magazine》曾深入探討這個主題。一年後，我們再次聚首。這次，我想要說明如何將「以系統管理員身分執行」功能擴展到
我最愛的一些協力廠商指令碼工具，示範要如何取代 Windows Vista® 中已移除的一項不錯的 Windows ® XP 功能，並討論 Elevation PowerToy 內含的一些實用工具。

其他指令碼工具的「以系統管理員身分執行」功能
我在前一篇文章中討論的一個主題 (請參閱 technet.microsoft.com/magazine/cc162321.aspx) 是啟用原生 Windows 指令碼工具的 [以系統管理員身分執行] 選項。針對本文，我為一些協力廠商指令碼工具建立了「以系統管理員身分執行」PowerToy：
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
上述各項的程式碼都包含在本文所附的下載中，您可以在 technetmagazine.com 上找到。實際的檔案名稱分別是 ElevateAutoIt3.inf、ElevateAutoHotKey.inf、ElevatePerlScript.inf 和 ElevateKiXtart.inf。AutoIt v3、AutoHotkey 和 ActivePerl 的設定作業都非常簡單。只要下載相對應的應用程式，然後將它安裝在預設位置就行了。安裝好您感興趣的應用程式之後，您接下來只須為各項工具安裝適當的「以系統管理員身分執行」PowerToy。
可惜，KiXtart 2010 並沒有提供安裝程式。因此，為了確保 KiXtart 安裝在標準的位置，以便讓 PowerToy 正常運作，我提供了一個 INF 檔案，它會把 installKiXtart 2010 (v 4.60) 安裝到 Program Files\KiXtart，並註冊 .kix 副檔名。
請前往 www.kixtart.org/?p=downloads 下載 KiX2010_460.zip，然後把它解壓縮到資料夾。將 Install_KiXtart.inf 檔案 (內含在本文附隨的程式碼下載中) 複製到相同的資料夾。然後在 Install_KiXtart.inf 上按一下滑鼠右鍵，再選取 [安裝]。之後，您只要安裝 ElevateKiXtart.inf PowerToy 就行了。

「以其他使用者身份執行」PowerToy
使用者存取控制 (UAC) 的建立是為了讓使用者，甚至是那些系統管理員，以標準的使用者權限執行大多數的應用程式，藉此讓作業系統不易受到惡意程式碼的侵害。UAC 提供了提高權限可能性以進行系統管理工作和其他應用程式功能。這項提高權限可能性是透過 [以系統管理員身分執行] 選項提供，用滑鼠右鍵按一下可執行檔就會出現這個選項。我在 2007 年 6 月份期刊中討論的 Elevation PowerToy 擴充了這項功能，以利在其他檔案和物件類型上運作。
Windows Vista 內建的功能與許多系統管理工作都能密切的搭配運作。然而，Windows Vista 遺漏了一個重要的案例。那就是許多 IT 部門都設有原則，規定網路系統管理員使用一個使用者帳戶進行日常工作 (使用電子郵件、建立文件之類的作業)，然後使用另外一個帳戶專門進行網路系統管理 (或是本機電腦系統管理)。
這麼做是為了協助降低風險，以免網路系統管理員在進行日常工作時不小心執行惡意程式碼而危及整個系統 — 或是他所在的網域。這在 Windows XP 上是使用按滑鼠右鍵的 [...身分執行] 選項完成的。但這個選項在 Windows Vista 中已經移掉，因為它已由 [以系統管理員身分執行] 選項所取代。
不過，runas 命令列工具仍存在 Windows Vista 中。不幸的是，您不能使用它來進行大多數常見的雙重帳戶工作 — 執行 Microsoft® Management Console (MMC) 嵌入式管理單元。譬如說，假設您已在 Active Directory® 中委派一些帳戶管理工作。您是以標準使用者的身分執行日常工作，而且您的網路系統管理員帳戶在啟用 UAC 的 Windows Vista 電腦上，同樣是本機 Administrators 群組的成員 (以便在必要時能夠安裝網路管理工具)。現在您想要以 Active Directory 系統管理帳戶啟動 Active Directory 使用者和電腦 (ADU&C)，所以您試著使用 runas 命令，如下所示：
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
不幸的是，ADU&C 並不會因此而啟動。您反而會收到一個 runas 錯誤，指出「要求的作業需要提高的權限」。發生這種情況的原因是，MMC 可執行檔被標示為要以 highestAvailable 特殊權限等級執行。既然網路系統管理員帳戶的 highestAvailable 層級是系統管理員，那麼透過這種方式啟動 ADU&C 想必就需要提高權限。而 runas 並不會提示要求提高權限，錯誤於焉產生。
Windows Vista 使得這種案例處理起來更為棘手，因為它並不為 [...身分執行] 提供快顯功能表項目，而且也不提供任何內建方式讓您以需要提高權限的其他使用者身份執行處理程序。
如果沒有辦法解決這種困境，那麼本文讀起來一定很沮喪，碰巧，我有一個原始的 Elevation PowerToy 提供了解決第二個問題的門路，而我迅速地找出另一個 PowerToy 來解決第一個問題 (我倒是希望自己能夠聲稱是我想出了解決提高權限問題的辦法，但這是由 Windows AppCompat 小組的 Gov Maharaj 想到的)。
結果是「提升命令權限」PowerToy 可與 runas 命令搭配使用。之前的命令無法提供提高權限提示，而下面的程式碼可產生提示：
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
這會使 runas 將 elevate.cmd 啟動為其他使用者 (技術上來說，被啟動的處理程序是 cmd.exe)，而 elevate 命令會負責啟動 mmc.exe，並提供提高權限提示。
最後，我把這項竅門與 .exe 和 .msc 檔案的檔案關聯相結合，並給它一個 HTML 應用程式 UI 來建立 PowerToy，這個 PowerToy 會建立一個可透過按右鍵功能表取得的 [以其他使用者身分執行] 選項。選取 [以其他使用者身分執行] 時，會出現一個像 [圖 1] 所示的 HTML 應用程式。
[圖 1] 以其他使用者身分執行工具
[圖 1] 以其他使用者身分執行工具 (按一下影像可放大檢視)
在此處，直接輸入使用者名稱和網域 — 對於本機電腦上的帳戶，請勾選 [使用本機帳戶] 核取方塊。您接下來可以按一下 [執行] 按鈕以標準使用者身分啟動應用程式，或者您可以按一下 [以系統管理員身分執行] 按鈕以提高的權限來啟動應用程式。按下其中一個按鈕之後，runas.exe 便會執行並提示輸入密碼或智慧卡 PIN。
由於這個 PowerToy 使用的是「提升命令權限」PowerToy，因此您必須先安裝該 PowerToy。接下來在 RunAs.inf 檔案上按一下滑鼠右鍵，選取 [安裝]，然後許可提高權限。若要解除安裝該工具，使用 [程式和功能] 控制台即可。
您會發現 [系統管理工具] 中有些 .msc 檔案的捷徑 (例如 [電腦管理]) 可與這個 PowerToy 搭配使用。但要注意的是，假如您使用 adminpack.msi 來安裝 Windows Server® 2003 系統管理工具的話，建立的捷徑並不會是 .msc 檔案的標準捷徑，而是 Windows Installer 捷徑，也就是說 Windows 檔案總管不會為這些捷徑顯示 [以其他使用者身分執行] 選項。
對於這些捷徑，您必須找出實際的 .msc 檔案，然後在它們上面按右鍵，或是建立 .msc 檔案的新捷徑。此外，因為 Windows Vista 中針對保護模式而重新設計 Internet Explorer® 的關係，runas 無法與 Internet Explorer 搭配運作 (您可以在 support.microsoft.com/?id=922980 找到與此議題相關的其他資訊)。
備註：在我完成這些 PowerToy 和出版這篇文章期間，Windows Sysinternals 也發行了一項新工具，功能與我的「以其他使用者身份執行」PowerToy 相比擬。它叫做 ShellRunas，可在 Windows Sysinternals 網站上找到：technet.microsoft.com/sysinternals/cc300361。
既然 Sysinternals 的同仁實際上是以寫程式碼維生，您可能比較偏好使用他們的工具。我決定把我的工具留在本文中，示範如何使用 HTML 應用程式搭配指令碼，來完成這項特定的工作和一般的殼層延伸。

從此處以系統身分開啟 CMD 和 PowerShell 提示
有時候在本機系統內容中執行程式是免不了的。比方說，許多軟體散佈工具，像是 System Center Configuration Manager (SCCM)，都是使用用戶端代理程式以本機系統身分執行來完成它的工作。
為了在嘗試散佈像是 SCCM 的產品之前先測試以本機系統身分執行的軟體安裝程式行為，使用以本機系統身分執行的命令提示來啟動安裝程式可能蠻有用的。因此，我決定建立「從此處以系統身分開啟 CMD 和 PowerShell 提示」PowerToy。
使用 Windows XP 時，我都是藉著命令殼層指令碼來完成這類的差事：
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
然而，如果您嘗試在 Windows Vista 從提高權限的命令提示執行這個動作的話，會收到下列的錯誤訊息，而且也不會顯示以系統身分執行的命令提示：
<Code>警告：此 CmdAsSystem 服務是設定為互動式，其支援正被淘汰。此服務也許無法正常運作。</Code>
[圖 4] 拖放式提高權限小工具
假如您已安裝了我之前的 Elevation PowerToy，那麼這個小工具將適用於 Windows Script Host 指令碼、Windows PowerShell 指令碼、HTML 應用程式，以及 Windows Installer 套件與修補程式 (還有 Windows Vista 中預設有定義 runas 動作的可執行檔與命令殼層指令碼)。您一次還可以拖曳一個以上的項目 (不妨試試拖曳資料夾到小工具，然後看看有什麼結果)。
若要安裝小工具，按兩下 Elevation.gadget (可在程式碼下載中取得)。如果您想要查看小工具的程式碼，只要在檔名加上 .cab 副檔名就行了。您接著可以從 Cab 檔案擷取內容。

總結
在本文的下載中，同時包含了全新的 PowerToy 和原文的 PowerToy。我對幾個舊的 PowerToy 做了一些微幅的變更。例如，原始版的「從此處以系統管理員身分開啟 Windows PowerShell 提示」和 Elevate WSH Script 兩者都會安裝自己的 elevate.cmd 和 elevate.vbs 複本。由於有幾個新的 PowerToy 也仰賴這些檔案，因此我將這些工具變更為要求安裝「提升命令權限」PowerToy (然後由它們共用該複本)。若要確定 PowerToy 是否要求安裝「提升命令權限」PowerToy，請檢查 INF 檔案的標頭：
其他某些原始的 PowerToy 也有非功能性的微幅變動。在安裝最新的 PowerToy 之前，請一律先解除安裝舊版的 PowerToy。由於這項集合現在已擴展成 17 項工具，我也包含了命令殼層指令碼，讓您安裝和解除安裝整個集合 (分別是 InstallAllPowerToys.cmd 和 UninstallAllPowerToys.cmd)。您可以進行自訂，只安裝和解除安裝您需要使用的工具。
您應該牢記在心，在預設的情況下，InstallAllPowerToys.cmd 並不會為協力廠商指令碼工具安裝「以系統管理員身分執行」PowerToy。您可以修改這個指令碼，只安裝您已安裝軟體的那些 PowerToy。當執行其中一個 PowerToy 時，它本身就會以提高權限重新啟動。UninstallAllPowerToys.cmd 應該也會移除所有這些舊版的工具。
就像我所有的 PowerToy 一樣，這些都是「無支援責任」工具，使用後果請自行承擔。它們並非 Microsoft 官方產品 — 而是我個人的創作。這些只經過我自己和其他志願者在預設語言為美國英文的 32 位元 Windows Vista 上的測試。最後，任何或所有這些 PowerToy 都有可能無法與 Windows 未來的更新、Service Pack 或作業系統版本搭配運作。

Michael Murgolo 是微軟諮詢服務 (Microsoft Consulting Services) 的資深基礎結構顧問。他專精的領域包括作業系統、部署、網路服務、Active Directory、系統管理、自動化及修補程式管理，同時也是桌面部署及移轉領域方面的主題專家。


安全性
BitLocker 磁碟機加密的進展
Byron Hynes
簡介:
  • BitLocker 的增強功能
  • 取得和安裝 BitLocker
  • 在伺服器上使用 BitLocker
  • 完整資料保護的考量要點

在去年的《TechNet Magazine》的安全性期刊中，我簡單地介紹了 Windows BitLocker 磁碟機加密的一部份功能，好讓您能了解它是如何在初版的 Windows Vista 中實作的。現在，隨著
Windows Vista® Service Pack 1 以及全新的 Windows Server® 2008 作業系統的發行，我們應該要再次回顧一下 BitLocker®。
在本文中，我會討論最新版本中的一些改變，概述如何在伺服器上安裝和使用 BitLocker，並提到一些值得注意的近期要點報告 (對了，如需閱讀去年的文章＜使用 BitLocker 磁碟機加密保護資料的關鍵＞，請至 technet.microsoft.com/magazine/cc138009.aspx)。

新功能
此 BitLocker 版本所引進的一些變更帶來嶄新的彈性，而且不會更改任何基本操作。我所介紹的變更具有資料磁碟區支援；允許機器存取進行三重要素驗證；具有統一可延伸韌體介面 (Unified Extensible Firmware Interface，UEFI) 支援，這是一種適用於 64 位元系統的新業界標準韌體；更能有效防護磁碟區中繼資料上的密碼編譯攻擊；而且可提高可信賴平台模組 (TPM) 的使用率。

資料磁碟區
當 Windows Vista 第一次發行時，BitLocker 控制台只允許您開啟 Windows® 作業系統磁碟區 (通常為 C:磁碟區) 的加密。對於許多消費者來說，這樣就已綽綽有餘，因為一般家用電腦的設定通常是將所有使用者資料及程式存放在與作業系統相同的磁碟區上。但是在企業環境中，尤其是在伺服器上，卻不然。因此，客戶最常提出的要求之一就是希望能夠加密資料磁碟區 — 安裝在電腦中除了 OS 磁碟區以外的磁碟區 (請注意，BitLocker 不是為了加密卸除式媒體而設計)。
如 [圖 1] 所示，我在本電腦上有三個可用磁碟區 (如果把用來開機的小型使用中磁碟分割也算在內，實際上是有四個)。我的作業系統是安裝在磁碟機 C:(這實際上是以圖示的 Windows「旗標」顯示)，另外還有兩個資料磁碟區分別是 E:和 P:。P:磁碟區已經使用 BitLocker 加密，目前是鎖定的。E:磁碟區尚未加密。在 Windows Vista SP1 和 Windows Server 2008 中，我可以從 BitLocker 控制台小程式加密及解除鎖定這些資料磁碟區。
[圖 1] Bitlocker 介面
[圖 1] Bitlocker 介面 (按一下影像可放大檢視)
如果您的作業系統磁碟區已使用 BitLocker 加密，預設行為是加密的資料磁碟區會在作業系統解除鎖定時一起解除鎖定。如果使用控制台來解除鎖定資料磁碟區，您會看到這個選項顯示為核取方塊，如 [圖 2] 所示。
[圖 2] 儲存自訂鎖定的金鑰
[圖 2] 儲存自訂鎖定的金鑰 (按一下影像可放大檢視)
若要開啟或關閉資料磁碟區的「自動鎖定」，請使用 manage-bde.wsf 命令列工具。Manage-bde.wsf 是 Windows 隨附的一個功能強大的指令碼，這個工具使用與 BitLocker 一同安裝的基礎 Windows Management Instrumentation (WMI) 提供者。
比方說，若要標示資料磁碟區 P:，使它必須以手動方式解除鎖定，請使用下列命令：
manage-bde.wsf –autounlock –disable P:
若要再次開啟 P: 的自動鎖定，請使用：
manage-bde.wsf –autounlock –enable P:
BitLocker 控制台並未顯示可以使用 BitLocker 與資料磁碟區執行的所有作業，因此您應該使用 -?選項來研究 manage-bde.wsf 命令。manage-bde.wsf 語法也涵蓋在《Windows BitLocker 磁碟機加密設計指南》和《Windows BitLocker 部署指南》中，您可從 Microsoft 下載中心取得，網址是：go.microsoft.com/fwlink/?LinkId=115215。

TPM+USB+PIN
客戶也希望能夠使用 BitLocker 提供的其他驗證要素。BitLocker 在您的電腦中使用 TPM 晶片以便驗證平台的完整性 — 換句話說，這是為了確定早期啟動元件 (包括 BIOS) 未遭到竄改或損壞。不過，自從 Windows Vista 發行以後，您現在也可以要求輸入 PIN 或出示包含在啟用 BitLocker 時所建立之金鑰的 USB 快閃磁碟機。
藉由 Windows Server 2008 和 Windows Vista SP1，您現在可以結合這三項功能。TPM 會繼續確認平台完整性，USB 金鑰代表「您有的東西」，而 PIN 則代表「您知道的東西」。這項設定提供非常強大的防護功能，可避免未獲授權的使用者啟動電腦和解除鎖定受 BitLocker 保護的磁碟機。
不過就像在安全性中常見的情況一樣，這也代表著取捨。以這種方式設定 BitLocker 的話，電腦顯然無法自動重新啟動。以伺服器的情況為例，您必須判斷哪一邊比較重要：順暢地重新啟動或是更高的保護層級。

UEFI 支援
在 Windows Server 2008 和 Windows Vista SP1 中，已經針對裝有統一可延伸韌體介面 (Unified Extensible Firmware Interface，UEFI) 的電腦加入支援。UEFI 是一種規格，代表大部分電腦在啟動時所使用的傳統 BIOS 現代化。如需 UEFI 規格的詳細資訊，請造訪 www.uefi.org。

增強保護
當 BitLocker 偵測到系統有所變更時，或是在開機時未提供必要的 PIN 或 USB 金鑰的話，BitLocker 便會進入修復模式。在修復模式中，啟用 BitLocker 的磁碟區會繼續保持鎖定狀態，並且會向使用者顯示稱為修復主控台的文字模式對話方塊。
若要解除鎖定磁碟機，使用者必須從鍵盤或 USB 快閃磁碟機輸入修復密碼 (48 位數的數字) (儲存在 USB 快閃磁碟機中的密碼有時稱為修復金鑰，因為它是二進位格式而非文字格式)。
BitLocker 使用修復密碼來解密儲存在磁碟區中繼資料 — 磁碟區主要金鑰 (VMK)，隨後是完整磁碟區加密金鑰 (FVEK) — 中的金鑰來解除鎖定磁碟機。若要修復順利進行，必須要有修復密碼。
因此，除了由使用者儲存 (例如儲存在 USB 快閃磁碟機上)，強烈建議您也在中央儲存修復密碼。作業系統包含將修復密碼儲存在 Active Directory® 網域服務 (ADDS) 中的功能。
儲存在磁碟區中繼資料 (例如 VMK) 中的秘密會經過加密，而且整個磁碟區中繼資料的完整性會以密碼編譯的方式加以保護。如果 BitLocker 偵測到磁碟區中繼資料遭到竄改，便會拒絕中繼資料的使用，也不會解除鎖定受保護的磁碟區。要注意的是，單靠修復密碼將無法解除鎖定這種情況下的磁碟機。
我必須強調，這種情況只有在電腦遭到蓄意的安全性攻擊時才會發生。如果發生這種情況，電腦很可能已經落入惡人之手，而超出您的控制範圍了。如果只是對平台進行非計劃的簡單變更或是您忘記 PIN，並不會發生這種情形。
若要解除鎖定磁碟區，您需要下列三個項目：
  • 修復密碼 (可以是輸入的文字，或位於 USB 快閃磁碟機上)
  • 包含加密版本的 FVEK 和 VMK 的二進位金鑰封裝
  • BitLocker 修復工具
簡言之，您必須確保您的企業隨時都能存取以上所有項目。
修復密碼可以手動或自動備份。建議您使用群組原則設定將修復密碼自動備份到 Active Directory 網域服務。
當您進行此設定時，如 [圖 3] 所示，包含備份二進位金鑰封裝的選項。二進位金鑰封裝包括加密版本的 VMK 和 FVEK，可讓您視需要使用 BitLocker 修復工具。
[圖 3] 設定群組原則以便將金鑰封裝放入修復資訊中
[圖 3] 設定群組原則以便將金鑰封裝放入修復資訊中 (按一下影像可放大檢視)
BitLocker Repair Tool 的設計可協助您從啟用 BitLocker 的受損磁碟中復原資料。請注意，這是專門提供給有經驗的系統管理員使用的進階工具。如需 BitLocker 修復工具的詳細資訊，請閱讀微軟知識庫文章 (support.microsoft.com/kb/928201)，或觀賞我的網路廣播「企業中的 Microsoft BitLocker：讓生活更輕鬆的 BitLocker 工具」(即時展示影片)，網址是 go.microsoft.com/fwlink/?LinkId=114985。
這裡清楚地指出 BitLocker 並不能取代備份資料的需求。如果您的磁碟受損或遭到蓄意攻擊，BitLocker 修復工具並不保證能夠復原任何 (更別說全部) 資料。

更廣泛的 TPM 用途
技術上來說，這不算是 BitLocker 變更，但還是值得一提。在 SP1 之前，Windows OS 唯一使用 TPM 的部分就是 BitLocker，不過現在 TPM 也應用於其他一些功能。舉例來說，當 Windows 看到 TPM 可用時，便會在產生亂數時使用 TPM 當作增加 Entropy 的來源。如此可提高各種加密的品質 (甚至可能讓遊戲玩得更順暢)。
但是，這也表示顯示在事件檢視器中的 TPM 相關事件不一定都與 BitLocker 有關係。身為 IT 專業人員，您必須注意其他系統元件 — 可能是來自其他廠商的軟體 — 可以也將會使用 TPM，因此會產生其他記錄事件。

Windows Server 2008 中的 BitLocker
由於 Windows Vista 與 Windows Server 2008 共用程式碼基底，因此出現在 SP1 中的 BitLocker 變更也是 Windows Server 2008 不可或缺的部分。但是 BitLocker 在伺服器上有何重要性？畢竟，BitLocker 的設計目的就是要保護電腦防範離線攻擊。換句話說，BitLocker 無法保護執行中的系統，而伺服器通常都是一直保持執行狀態。
但其實伺服器或伺服器的硬碟有時還是冒著離線攻擊的風險。即使這種情形從未發生，解除委任伺服器或硬碟時，BitLocker 仍然大有幫助，我們接下來就會提到。首先，我們來看一下如何在伺服器上安裝和執行 BitLocker。

取得和安裝 BitLocker
Windows Server 2008 的所有版本中都有包含 BitLocker，但這是選用元件或功能，必須從伺服器管理員或命令列安裝。BitLocker 會實作為 NTFS 篩選器驅動程式的一部份。安裝此篩選器驅動程式必須重新啟動電腦，因此要注意，在伺服器上啟動 BitLocker 將需要重新開機。此外，就跟 Windows Vista 一樣，BitLocker 也需要有分割載入設定，其中用來啟動電腦的使用中磁碟分割會保持未加密狀態。如果製造商的伺服器並未預先設定，那麼 BitLocker Drive Preparation 工具可用來輔助您正確設定硬碟以支援 BitLocker。不過，如果您熟悉硬碟磁碟分割，當然可以手動設定硬碟。
若要將 BitLocker 安裝到 Windows Server 2008，您可以使用伺服器管理員圖形化介面，從功能清單中選取 BitLocker，如 [圖 4] 所示，或者您也可以使用伺服器管理員命令列介面發出以下命令：
[圖 4] 在伺服器管理員中選取 BitLocker
[圖 4] 在伺服器管理員中選取 BitLocker (按一下影像可放大檢視)
ServerManagerCmd –install BitLocker –restart
使用伺服器管理員時，它會安裝 BitLocker 和 BitLocker 的管理工具。您也可以不安裝 BitLocker，只安裝管理元件。這麼做就無須重新開機，因為篩選器驅動程式未包含在內。此元件名稱是「RSAT-BitLocker」。
BitLocker 在執行 Server Core 安裝選項的電腦上也能正常運作，但是您無法使用伺服器管理員將 BitLocker 安裝在 Server Core 上，也無法使用圖形化使用者介面來管理 Server Core 上的 BitLocker。因此，若要安裝元件，請改用命令列工具 pkgmgr 或 ocsetup。
一旦安裝 BitLocker 二進位檔且在必要的分割載入設定中設定磁碟之後，您就可以啟用 OS 磁碟區上的 BitLocker。BitLocker 控制台小程式在 Windows Server 2008 與 Windows Vista SP1 都提供相同的圖示與選項。為了啟用 BitLocker 的進階模式，您必須調整預設設定，這些設定會使用套用到伺服器的本機原則編輯器或群組原則物件。
在 Server Core 上，或著您只是不想使用控制台時，可以使用 manage-bde.wsf 來啟用 BitLocker。若要在磁碟機 C: 上啟用，請輸入
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
這裡的 C:是要加密的磁碟區，F:\ 則是 USB 金鑰或存放修復金鑰複本的另一個磁碟區 (使用二進位格式)。您也可以使用 UNC 路徑，將修復金鑰儲存在網路磁碟機上。另外也會產生並顯示修復密碼 (使用數字文字格式)。若您確定硬體平台符合所有 BitLocker 需求，可加入 –skiphardwaretest 參數。這樣可免去一次重新開機。

伺服器案例
現在，我們來討論一下 BitLocker 應用在伺服器中的幾個特殊案例。別忘了我之前提過，BitLocker 的設計用意是為了協助您防範離線攻擊 — 這種攻擊會在 Windows 未執行的時候發動。
分公司 BitLocker 在伺服器上最重要和最顯著的用途之一就是作為 Windows Server 2008 分公司策略的一部份。有四分之一到三分之一的伺服器是安裝在分公司 — 也就是實體安全性較低、IT 支援的存取能力較低，而且資料中心的連線力較差的辦公室。分公司也是易受攻擊的目標。結合使用唯讀網域控制站 (RODC) 之後，BitLocker 能有效保護必須存放在分公司使用，但是無法提供與資料中心同等實體安全性的機密資料。
此時正好可以思考一下適當的保護等級。究竟哪一邊比較重要 — 防止未經授權的資料存取，或是要求伺服器立即備份而不中斷？我的建議是，在許多分公司中，要求輸入 PIN 來重新啟動伺服器是可接受的，但是各家公司必須自行決定。
運送磁碟 我們常需要將硬碟中的資料運送到遠方位置。其中包括運送單一磁碟，或是預先設定並運送整部伺服器。在運送過程中，您無法掌握這些磁碟上的資料，它們可能會被複製、遺失或遭竊。
若要減輕風險，運送之前請先啟用電腦磁碟區上的 BitLocker，然後移除除了修復金鑰或修復密碼之外的所有金鑰保護裝置。此金鑰或密碼可以與伺服器分開保管和攜帶，甚至可以透過電話或加密的電子郵件來告知接收方員工。一旦收到電腦或磁碟之後，便可以使用修復密碼來解除鎖定磁碟機。磁碟機可以保持加密 (再次加入其他金鑰保護裝置)，如果想要的話，磁碟可以在遞送之後完全解密。
這個方法可以有效地為分公司預先分段準備網域控制站或伺服器。
伺服器的竊盜風險 正如上一節所述，伺服器 (尤其是網域控制站) 要面對被偷竊的真實風險。竊賊可能會藉機偷取膝上型電腦，但是伺服器的竊盜事件往往是精心設計的。如果將 BitLocker 設定為只需要 TPM 完整性檢查，那麼遭竊的伺服器可能會輕易地被啟動和開機。相對地，如果伺服器中的磁碟機都使用 BitLocker 加以保護，而且以進階模式設定 BitLocker — 需要 USB 金鑰、PIN 或兩者皆要 — 竊賊就很難在合理的時間內取得有用的資訊。
磁碟的竊盜風險 但是反過來說，如果只有磁碟遭竊，TPM 仍然提供高度的保護機制。只有來自原始伺服器的 TPM 可用來解除鎖定受 BitLocker 保護的磁碟機，因此無法直接將磁碟插入另一台電腦進行讀取。
降低風險 藉由訂購包含 TPM 晶片的伺服器硬體，並使用 BitLocker 平台完整性檢查，即可增加對某些惡意程式碼形式的防禦能力。尤其，BitLocker 會偵測在 Windows 離線時所做的變更或對早期啟動元件的變更，特別是當惡意程式碼 (例如 Rootkit) 需要重新開機才能安裝時。這並不是全面的解決方案，但是一旦結合 Windows 程式碼完整性等功能和 Microsoft® ForefrontTM Client Security 等產品，就能有效提供另一層深度防禦能力。
安全地解除委任 BitLocker 最實用的其中一項案例，是發生在伺服器或磁碟的生命週期結尾時。您是否常聽說伺服器或伺服器上的磁碟尚未妥善解除委任就被棄置？您是否知道在拍賣場上，使用過的硬碟有時售價比新硬碟還高，因為不肖買家希望從這些舊電腦中汲取有用的資訊？
幸好，BitLocker 提供了另一種方法，而無須採取昂貴又耗時的程序來清除磁碟上的有用資訊。基本上，沒有任何資訊會以有用的格式寫入磁碟。既然加密資料已經無法使用，因此移除所有金鑰資訊的步驟是既快速又簡單。這麼一來，無論磁碟硬體被如何處置 — 可能被賣出、回收、另作他用等等，都不必擔心資料被不當使用。
在 Windows Vista 與 Windows Server 2008 中，格式命令會更新以清除 BitLocker 金鑰，包括多次覆寫。現在您已找到簡單有效的方法來解除委任磁碟機。

最新消息
當我撰寫本篇專欄時，也就是您讀到本出版品的數週前，有一些最新的文章、論文及新聞報告討論了幾項有趣的硬碟特性，還有這些特性如何影響 BitLocker、其他 Windows 安全性功能，以及來自不同廠商的加密產品。我想要花點時間來討論其中一些新發現。
當中一項發現是由普林斯頓大學的研究人員所發表的，展示了 (令人印象深刻地！)現代電腦記憶體的一個特性，有時稱為「DRAM 殘磁」(請參閱 citp.princeton.edu/pub/coldboot.pdf)。簡單來說，電腦記憶體內容可以在記憶體電源移走後的一段時間內存取。BitLocker 當然也是在 Windows 執行時將解密資料的金鑰保存在記憶體中，問題在於金鑰有可能被未獲授權的使用者取得。
Adam Boileau 的另一項示範 (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) 顯示 IEEE 1394 (常稱為 FireWire) 如何允許直接記憶體存取 (DMA)，這種行為可用來擷取 Windows 上的秘密，例如密碼或解密金鑰。有趣之處在於 DMA 幾乎等於點 1394；這不算是錯誤，而是 Firewire 原本的設計。
不過這兩種攻擊的共通點都是需要存取執行中的 (或至少是剛剛執行過的) 實體電腦。BitLocker 並非針對線上攻擊的防護而設計，而且也不能免除一定程度的實體安全性需求。正確的深度防禦需要運用多項工具和功能，建立實體安全性的環境，擬定基本的企業原則並持續教育使用者。
當然，這些都不是新發現。這些方法已經流傳好一陣子，而且實際上就記錄在 Microsoft® Data Encryption Toolkit (DET) 中。DET 中提供的風險分析是為了協助客戶在安全性與使用性以及實作和管理成本之間取得平衡。這可不能等閒視之。我們相信唯有正確教育客戶，他們才最能夠權衡安全性、使用性與成本以做出決策。
除了 DET，我的幾位同事也提供一些絕佳的評論及指導。首先是 Russ Humphries 在他的部落格文章中討論了 DRAM 殘磁環境中的安全性取捨：go.microsoft.com/fwlink/?LinkId=115217。此外，Douglas MacIver 也在系統整合性 (System Integrity，SI) 小組部落格上撰寫了其他特殊設定步驟和對策，可供您參考應用：go.microsoft.com/fwlink/?LinkId=115218。強烈建議您抽點時間閱讀這兩篇實用的部落格文章。您也應該閱讀 DET。
這些建議事項的重點是要使用進階模式 (也就是需要 USB 金鑰或 PIN 的模式)，而且別讓電腦在無人看管的情況下進入睡眠模式 (請改用休眠)。

結論
BitLocker 仍然是 Windows Vista 最好用的功能之一。隨著 SP1 發行，增強過的 BitLocker 不但可直接回應客戶的意見，可用於更多案例，而且符合更廣泛的需求以提供資料保護。將靜止資料保護機制延伸擴充到 Windows Server 2008，提供您更多方法來保護資料和保持循規，無論這些資料是存放在伺服器或用戶端工作站、資料中心、分公司或由行動工作者保管。

Byron Hynes 是 Microsoft 企業和合作夥伴小組 (Enterprise and Partner Group，EPG) 的企業技術策略專家，專攻安全性功能與產品。在加入 EPG 之前，他從 2005 年開始就在 Windows Server 部門處理與 BitLocker (System Integrity) 密切相關的工作。歡迎您的寶貴意見或問題，您可以在 Tech•Ed 2008 提出，或傳送電子郵件到 bhynes@microsoft.com。


安全性
透過軟體限制原則鎖定應用程式
Chris Corio and Durga Prasad Sayana
簡介:
  • 軟體限制原則的運作方式
  • 清查環境內的應用程式
  • 建立及強制原則

當 IT 專業人員期望降低桌上型電腦的擁有權總成本 (即 TCO) 時，通常會聯想到兩大策略。第一個策略是將桌上型電腦的使用者帳戶
從 Administrators 群組中移除。而第二個策略是限制使用者可以執行的應用程式。在企業環境中處理這些問題可能頗具挑戰性，但是 Windows Vista® 提供了一些技術可以幫助您達成這些目標。
Windows Vista 及它的使用者帳戶控制 (UAC) 功能在幫助 IT 專業人員以 Users 群組 (標準使用者) 成員來執行企業使用者方面，可說是向前躍進了一大步。UAC 將所有應用程式的預設安全性內容變更為使用者而非系統管理員的預設安全性內容。移轉到 Users 群組的工作依舊令人畏怯，但是隨著產業開始適應這種新模型，這項工作也會隨著時間而越來越輕鬆。
分析過將使用者移到 Users 群組的挑戰之後，或是在這個過程當中，許多系統管理員都會將使用者需要執行的應用程式加以分類，並考慮只允許執行這些應用程式所需的步驟。軟體限制原則功能就是為了協助 IT 專業人員達到這個目的而設計的。
您只需指定要允許執行的應用程式，然後使用群組原則部署原則就行了。在整個企業內強制這類原則可降低 TCO，因為這種鎖定可限制有關不受支援應用程式的問題 (而且您也可以透過一些有趣且非常極端的方式來應用軟體限制原則，我們在「極簡軟體限制原則」資訊看板裡面會討論到)。

軟體限制原則的運作方式
軟體限制原則的目的是要控制使用者在 Windows Vista 電腦上到底可以執行哪些程式碼。您身為系統管理員，要建立一個原則來定義什麼可以 (或不可以) 在您的環境內執行。無論何時何處有可能執行程式碼時，便會評估這項原則。這包括在處理序建立期間、呼叫 ShellExecute 時，以及指令碼執行時 (我們稍後會詳細說明)。
如果應用程式被判定可以執行，該應用程式就會啟動。然而，若是應用程式被判定不可執行，便會封鎖該應用程式，並通知使用者。比方說，假如您嘗試從 [開始] 功能表執行 [接龍]，但它不被允許，您就會收到一個類似於 [圖 1] 的對話方塊。
[圖 1] 當應用程式被封鎖時出現的對話方塊
[圖 1] 當應用程式被封鎖時出現的對話方塊 (按一下影像可放大檢視)
定義軟體限制原則的 UI 是公開在群組原則物件編輯器 (GPOE) 中，這也是編寫鎖定原則的地方。定義哪些程式碼可以執行，而哪些不行的方法有很多。原則一經完成並測試後，您就可以部署它。

定義軟體限制原則
第一個您要做的重大決定，是選擇預設的規則類型，這個決定對於軟體限制原則在您的環境內如何運作有著深遠的影響。您可以採用兩種模式之一來部署軟體限制原則：[允許清單] 或 [拒絕清單]。基本上，您是選擇要建立一個原則來描述允許在環境內執行的各個應用程式，還是要建立一個原則來定義不能執行的各個應用程式。
在 [允許清單] 模式下，您的原則中的預設規則是 [受限制的]，而且會封鎖所有您沒有明確允許執行的所有應用程式。而在 [拒絕清單] 模式下，預設的規則是 [沒有限制]，而且只會限制您明確列出的應用程式。
跟您猜的一樣，如果您想要透過應用程式鎖定大幅降低 TCO 並獲得安全性效益，[拒絕清單] 模式是不切實際的方法。要建立和維護龐大的清單來封鎖所有惡意程式碼和其他有問題的應用程式，幾乎是不可能的；因此，我們建議以 [允許清單] 模式 (也就是 [受限制的] 預設規則) 來實作軟體限制原則。

清查環境內的應用程式
如果您要設計一個原則來指定可以執行的應用程式，您必須判斷您的使用者到底需要哪些應用程式。軟體限制原則功能提供進階的記錄功能，以一個非常簡單的原則來了解您的環境內到底執行了哪些應用程式。
在您的環境裡面的樣本電腦組上，部署軟體限制原則，把預設規則設為 [沒有限制]，並確定移除所有其他規則。目的是要啟用軟體限制原則，但不允許它限制應用程式，反而只是使用它來監視正在執行的項目。
接下來，建立下列登錄值，以便啟用進階記錄功能，並將路徑設定成應該寫入記錄檔的位置：
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
現在，當應用程式開始執行，軟體限制原則也評估之後 (即使它允許什麼都可以執行還是會進行評估)，就會在記錄檔中寫入一個項目。
每個記錄項目都包含軟體限制原則的呼叫者及呼叫程序的處理序識別碼 (PID)、要評估的目標、找到的軟體限制原則規則類型，以及規則的識別碼。以下是當使用者按兩下 notepad.exe 時寫入的範例項目：
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
這個記錄檔會顯示在啟用軟體限制原則並設為封鎖應用程式時，它將檢查的每段可執行程式碼。也就是說，您必須為記錄檔中的每個項目決定是否應將它列入您的 [允許清單] 中。請注意，您會看到幾個被檢查的二進位檔是屬於 Windows® 的一部分，而且系統必須有它們才能運作。
我們在此說明的記錄方法能夠讓您清楚了解軟體限制規則在您的環境中到底會碰到哪些應用程式。但要完成這樣的工作，它並不是唯一的途徑。
內含在 Microsoft® Application Compatibility Toolkit 5.0 中的 Inventory Collector 可讓您清查環境內所使用的應用程式。這項工具提供各種不同的方法讓您探索您的環境裡面安裝了哪些應用程式，它也會將結果合併到中央資料庫中。

編寫其他規則
有了一份必須在環境內允許執行的應用程式清單，您就可以開始建立實際的規則，允許這些應用程式執行。軟體限制原則功能使用兩種方法來識別原則 — 其中之一是以應用程式的密碼編譯屬性 (例如它的雜湊) 為基礎，而另外一個則會定義信任的應用程式應該放置的信任路徑或資料夾。
[圖 2] 顯示您在 GPOE (gpedit.msc) 的 [軟體限制原則] 節點中，新增允許應用程式執行的規則的位置。在您的環境內定義應用程式最直接了當的方法，就是為您在記錄階段期間遇到的每一個二進位檔建立雜湊規則。
[圖 2] 使用 gpedit.msc 來編寫軟體限制原則
[圖 2] 使用 gpedit.msc 來編寫軟體限制原則 (按一下影像可放大檢視)
由於雜湊是針對特定的位元組集合傳回的唯一值，因此原則中的每個二進位檔都會有不同的雜湊。這種方法特別安全，而且只允許原則當中特定的二進位檔執行。
當然啦，這個方法還是有些缺點。比如說，您的環境可能很容易就會有好幾千個二進位檔。要在軟體限制原則 UI 裡面編寫所有這些規則可能不容易，而且隨著規則的數目變得特別大時，效能可能會受到影響。此外，環境內的每次應用程式更新都需要在環境中部署一或多個新的雜湊規則。在更新應用程式時更新規模這麼大的規則，負荷可能不小。
所幸，這種負荷是可以避免的，因為另外還有兩種識別規則的方法，方便在您的環境中使用軟體限制規則。若要冒險採取密碼編譯安全性一途，您可以建立一個規則來允許執行由特定憑證所簽署的二進位檔。
此舉有助於簡化原則清單的維護工作，因為當更新應用程式時，新的二進位檔通常也是由與前一個二進位檔相同的憑證進行簽署。不過，若是您不想要舊版的二進位檔在環境內執行，則必須新增 [受限制的] 雜湊規則，才能防止檔案被允許執行。
根據預設，軟體限制原則會停用憑證規則評估。必須這麼做的理由有二。
其一，軟體限制原則當中的憑證規則是由系統的 [信任的發行者] 存放區的內容定義而成。因為 [信任的發行者] 存放區的用途不光只是軟體限制原則規則而已，因此用來處理軟體限制原則功能時，需要多花時間以及多加考慮。
第二個理由是，為了判斷檔案的簽章是否有效，您必須拿檔案的雜湊與簽章資訊相比較。製作檔案的雜湊是一項非常耗用資源的作業 — 必須從磁碟讀取和處理整個檔案以計算雜湊。
若要啟用憑證規則，請瀏覽至 [軟體限制原則] 節點，並選取結果窗格中的 [強制物件]。然後按兩下以開啟它的內容對話方塊，並選取 [強制執行憑證規則] 選項按鈕。
另外一個識別程式碼的常見方法，是使用本機電腦上的程式碼路徑。這是個實際且有效率的方法，但是它有一個缺點 — 您必須小心確保資料夾上的安全性設定正確。
如果您新增特定的路徑規則，且此路徑允許使用者在該處寫入檔案 (譬如，寫到桌面)，他們只要在那個資料夾裡面放置可執行檔，就可以隨心所欲執行任何程式。然而，若是您的使用者不屬於 Administrators 群組的話，他們一般就無法修改 Program Files 或 Windows 目錄中的任何內容。這表示如果您所有的應用程式都位於 Program Files 目錄中，而且您的使用者不是系統管理員的話，那麼您應該採取路徑規則這個方法來取得簡單又有效率的原則。
路徑規則提供其他一些功能，使它比較適合某些環境。它允許萬用字元，而且可讓您使用環境變數，以便在環境內定義可攜規則 — 畢竟，對每名使用者來說，%systemdrive% 並不一定都是 c:\。
就效能與維護方面，這可能是識別程式碼最不麻煩的方法。路徑規則肯定是值得考慮使用，但是您必須注意其他安全性考量。

網路區域規則
軟體限制原則確實有包含一個稱為網路區域規則的規則類型，但是這個規則類型卻遭到非難。原本這些規則的基本概念是要識別和信任特定可執行程式碼的來源，藉此允許程式碼執行。可惜很難辦到，因此也進展的不順利。目前，軟體限制規則進入點上絕大多數的地方都沒有強制執行此規則類型。
如果大部分應用程式都是安裝在 %Program Files% 目錄，但有其他可執行檔安裝在其他地方，並且由特定的憑證簽署，使用不同類型的規則可能就蠻合理的。試試幾個雜湊規則、幾個路徑規則，就不難找到適合您的原則。
只要記住，處理規則是有順序的 (如 [圖 3]) 所示)。憑證規則最為特定，接下來是雜湊規則，再來是路徑規則，最後是內含萬用字元的路徑規則。因此，如果雜湊規則和路徑規則同時識別出一段程式碼，會以雜湊規則的安全性層級為優先。
[圖 3] 規則處理順序
[圖 3] 規則處理順序 (按一下影像可放大檢視)

強制原則
軟體限制原則功能在要保全的系統上提供的涵蓋範圍相當廣泛。整個構想是，能夠執行程式碼的任何位置都應該與軟體限制原則相整合，進而檢查該原則，查看是否允許執行可執行程式碼。
雖然檢查軟體限制原則的地方不可勝數，但最直接了當的進入點當屬 CreateProcess。在 CreateProcess 期間，會檢查原則以判斷是否允許執行表示應用程式的二進位檔。原則檢查是透過 SaferIdentifyLevel API 完成，這有公開記載。一般的程序如 [圖 4] 所示 (我們稍後會詳細討論 SaferIdentifyLevel)。
[圖 4] 使用 SaferIdentifyLevel 來判斷二進位檔是否能夠執行
[圖 4] 使用 SaferIdentifyLevel 來判斷二進位檔是否能夠執行 (按一下影像可放大檢視)
CreateProcess 之後，下一個強制軟體限制原則最常用的 API 是 ShellExecute。這是當使用者在 [開始] 功能表按一下應用程式或在桌面上按兩下時呼叫的 API。
呼叫 ShellExecute 可以使用的檔案格式林林總總。以 .txt 檔案為例，在檔案上呼叫 ShellExecute 實際上並不會執行檔案 — 就技術層面來說，當然是會開啟檔案。有鑑於此，軟體限制原則包含了一份可執行檔類型清單，以便在呼叫 ShellExecute 時控制要檢查的檔案類型。您可以在軟體限制原則 UI 當中自訂這份可執行檔類型清單。
除了 CreateProcess 和 ShellExecute 之外，還有其他兩個重要的整合點：LoadLibrary 與指令碼裝載。LoadLibrary 無疑是檢查可執行程式碼一個重要的地方，但可惜的是 LoadLibrary 有一些特殊的限制。
大多數應用程式都會載入一個可執行檔和數個 DLL。而且系統上通常會執行許多應用程式。也就是說，LoadLibrary 要進行大量的原則檢查作業。視您識別程式碼的原則而定，要強制這個進入點成本可能相當高 — 想像檢查系統上載入的每個 DLL 的雜湊，這包括對二進位檔進行雜湊，然後將它與可能含有上千個雜湊的清單相比較。
這項功能預設會停用，但是可以手動啟用。要啟用的話，瀏覽至 gpedit.msc 中的 [軟體限制原則] 節點，再按兩下 [強制]。之後，再選取 [所有軟體檔案] 選項按鈕。
我們之前有提到，軟體限制原則已與系統當中大部分的指令碼裝載整合。當中包括 cmd、VBScript、Cscript 和 JScript®。這些進入點，還有其他進入點，都是使用主要的軟體限制原則強制 API：SaferIdentifyLevel。
SaferIdentifyLevel API 會查看相關軟體限制原則裡面的識別資訊，藉此判斷是否應該允許執行指定的可執行檔。這是公開記錄的 API。協力廠商指令碼裝載和可執行環境可以也應該使用它，以便與軟體限制原則相整合，如此一來，原則就可以判斷是否應該允許執行某段可執行程式碼。

以標準使用者身分執行
軟體限制原則一個較不為人知的功能，是它可以在特定應用程式啟動時篩選它們的權限。這項功能在 Windows XP 就已引進，但一直到 Windows Vista 才公開於軟體限制原則 UI 中。
在這方面，它可說是 Windows Vista UAC 的先驅，因為您可以使用它以標準使用者的身分來執行應用程式，即使使用者是 Administrators 群組的成員也一樣。當您建立規則，並在其他規則 UI 裡面將安全性層級設定為一般使用者時，就會發生這種情況。
UAC 的權杖篩選功能和軟體限制原則的一般使用者規則，兩者都是利用基本的 API，這個 API 實作的行為與 CreateRestrictedToken API 一樣。不過，整體架構在技術方面相差懸殊。但是 UAC 與軟體限制原則之間有好幾項重大差異。
首先，在有啟用 UAC 的 Windows Vista 中，每個應用程式預設都是使用類似於 Users 群組成員的安全性權杖啟動，即使使用者是系統管理員也是如此。透過軟體限制原則也可以達成，但是無法以使用者實際的系統管理員權杖來啟動應用程式 — 例如，當使用者必須安裝應用程式時。UAC 的主要優點是可以變更預設安全性內容，以及容易存取使用者的完整系統管理員權杖。
第二項差異在於，以可執行檔為例，程式碼本身會公開必要的權限層級以利正常運作。這是很重要的區別，因為獨立軟體廠商 (ISV) 和開發人員了解他們的程式碼有何需求。舉例來說，如果控制台應用程式需要有系統管理員權限才能進行編輯作業，它就可以在資訊清單中指定該項需求。因此，ISV 可以描述應用程式所需的權限，而不是在它上面強施特定的權限層級，卻沒有其他方法可以變更這個層級。
目前來說，除非您了解一般使用者的運作方式，否則最好避免使用它。UAC 是幫助將桌上型電腦使用者移出 Administrators 群組的最佳方法，而且您應該認真考慮在企業環境中保有 UAC。

當今運用的軟體限制原則
使用軟體限制原則時，有好幾個活動組件需要列入考量。但其實它跟您想的不太一樣，事實上，您可能正在使用軟體限制原則而不自知。比方說，假如您在 Windows Vista 系統上執行家長監護，其實就是使用軟體限制原則來控制應用程式的執行。
當 Windows XP 最初引進軟體限制原則時，它可說是一項重要的技術發展。但是應用程式鎖定其實才開始受到 IT 專業人員的注意。
Windows Vista 中的軟體限制原則功能還是有幾處需要琢磨，但很清楚的是，系統管理員希望有更高的掌控能力來控制環境內執行的內容。所幸對我們所有人來說，這項技術將持續精進，更方便 IT 專業人員管理他們的系統，並降低執行 Microsoft Windows 環境的成本。
極簡軟體限制原則
應用軟體限制原則的其中一種方式，就是建立原則將 Windows 鎖定到 Kiosk 模式。Microsoft 實際上推出了可建立此 Kiosk 的工具組，叫做 SteadyState™。然而，如果您只想了解如何鎖定可以執行的應用程式，有更簡單的辦法可以完成。
若要允許登入 Windows Vista 所需的最小數量應用程式組合，可建立原則允許 logonui.exe 和 userinit.exe 從 %windir%\system32 執行。大多數使用者可能也需要允許執行下列的應用程式：
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
如果您想要預設的 Windows 殼層，另外也要加入 %windir%\explorer.exe。
或者，您可以選擇直接開機到應用程式，例如 Internet Explorer®。在這種情況下，就有必要列出 iexplore.exe 而不是 explorer.exe。
這種極簡原則的另一方面是，您的使用者不應該屬於 Administrators 群組。這點很重要，因為如此一來，他們就無法略過原則。不過，因為他們只能執行一組非常基本的應用程式，而且沒有系統管理員的權限，所以使用者無權安裝應用程式或維護系統。
針對這些機器，您必須透過其他方式進行這些作業。如果您打算使用系統管理員帳戶從本機登入來更新和維護這些機器，您應該選取將軟體限制原則套用到除本機系統管理員以外的所有使用者的選項按鈕。原則也應該包括 consent.exe 和 cmd.exe。這會允許系統管理員從系統管理員命令提示啟動任何系統管理選項。
要注意的是，UAC 預設會限制使用者的安全性權杖的權限，藉此使它看起來不像是 Administrators 群組成員的權杖。即使您將上述設定設為不將原則套用到系統管理員，它還是會套用到使用者身上。唯有經過 UAC 提高權限體驗後，系統管理員才會真正獲得完整的系統管理員權限，也才不會套用軟體限制原則。

Chris CorioChris Corio 曾在 Microsoft 服務於 Windows 安全性小組超過五年的時間。他在 Microsoft 主要是負責應用程式安全性技術，以及保護 Windows 安全性的管理技術。您可以透過電子郵件與 Chris 連絡：winsecurity@chriscorio.com。
Durga Prasad Sayana﻿Durga Prasad Sayana 是 Windows 核心安全性小組的軟體設計工程師兼測試人員。他的主要興趣是安全性技術和軟體測試。您可以透過電子郵件與 Durga 連絡：durgas@microsoft.com。


安全性
管理 Windows Vista 防火牆
Jesper M. Johansson
簡介:
  • 規則類型與案例
  • 防火牆設定檔
  • 網域隔離規則
  • 輸出篩選的問題

不久之前我在部落格裡寫了一篇關於 Windows Vista 防火牆的文章。那篇文章僅僅提及一些不錯的功能，關於部署建議倒是著墨不多。
本文我將詳細說明 Windows Vista® 防火牆中專為簡化企業管理而設計的功能，並且針對利用這項功能來簡化工作、以及確保使用者安全這兩點，提供一些建議。
隨著 Windows Vista SP1 的推出，一般預料企業也會跟進部署 Windows Vista (通常企業會等到第一個 Service Pack 發行之後，再移轉到新的作業系統)。如果您是一位為了企業環境而認真考慮 Windows Vista 的 IT 專業人員，那麼就該好好研究一下防火牆。一旦瞭解 Windows Vista 防火牆的功能之後，也許您就會重新協議協力廠商安全性套件的合約，將防火牆從套件中移除。

Windows 防火牆的今與昔
雖然原版 Windows® XP 的防火牆仍有很多有待改進的地方，不過已經足夠應付當時商務主機防火牆的安全性功能需求，所以並未再做任何新增或改革的動作。
但是到了 Windows XP SP2 之後，防火牆已經全然改貌，此時的防火牆完全是針對簡化企業管理而設計。Windows XP SP2 的防火牆具有輕量、有效、反入侵和集中管理等特性，相當引人注目。不過最吸引人的可能還是：Windows XP SP2 防火牆能夠在開機時保護系統。
最後一點可以說是最關鍵的一點。過去我見過許多系統在開機時中毒，即使已經開啟防火牆了還是無法悻免於難。事實上，在爆破手 (Blaster) 瘟疫流行的高峰期，攻擊率高達每四分鐘一次。換言之，如果您沒有做任何保護措施，就讓電腦暴露在網際網路中，它的中毒機率大約是每四分鐘一次。而如果您所信賴的防火牆未能在開機時保護系統，那麼在重新開機時，12 部系統裡面就有一部會中毒。這些數字在在鞭策著 Microsoft 做出可以確保開機時保護系統的 Windows XP SP2 防火牆。
Windows Vista 的防火牆還接受過一次徹底改造。從管理角度來看，最明顯的改變是它把網際網路通訊協定安全性 (IPsec) 和防火牆的管理介面合而為一。這是一項深富邏輯性的改變。IPsec 和防火牆的目的，都是要把不准通關的東西封鎖在外。兩者不同之處在於，防火牆中負責定義哪些東西獲准通關的參數不夠嚴密，而 IPsec 中封鎖或接受大量位址空間的程序卻是相當麻煩。
自從把兩種功能共同放在一個管理介面之後，系統管理員就可以輕鬆使用它們，而不必擔心哪些部分該套用 IPsec 規則，哪些部分該遵守防火牆篩選條件。也就是說，您現在只有一個系統網路攻擊面的檢視，而這一點可以把犯錯的風險降到最低。
Windows Vista 的 SP1 在防火牆功能當中新增了一些可靠性增強功能，同時也新增了可用於 IPsec 的新演算法，其中最值得注意當屬 Suite B 演算法。這是一組與加密有關的演算法，其中包含進階加密系統 (AES)、Elliptic Curve Cryptography (ECC) 以及安全雜湊演算法 (SHA) 256 和 384。
但最重要的是，Service Pack 1 多了網路存取保護 (NAP) 的支援。NAP 是一種原則強制工具，可以在受管理和未遭入侵的用戶端獲准連接網路之前，利用最新的安全性原則、更新和反惡意程式碼定義，確保它們保持最新狀態。雖然 NAP 無法阻止惡意主機連接網路，不過只要所有受管理的主機沒有受到主動侵害，就可以確保它們完全合格。
Windows Vista 防火牆又稱為「具有進階安全性的 Windows 防火牆」，同時它也是 Windows Server® 2008 的防火牆。Windows Vista 防火牆所有的功能都可以從遠端管理，而且可以利用群組原則進行跨網路設定。

規則類型與案例
管理介面結合防火牆和 IPsec 兩種功能之後，規則類型也增為兩種：方向規則和連線規則。方向規則是標準的防火牆規則，負責定義哪一個流量獲准前往適當的方向。而連線規則負責為電腦之間的連線定義保護參數。如果要畫出關係圖的話，方向規則比較類似您所熟悉的舊版防火牆規則，而連線規則比較類似與 Windows XP SP2 防火牆搭配使用的 IPsec 規則。
許多相當有趣的情況，都是因為把防火牆和 IPsec 結合在同一個介面而產生。舉個例說，將網路上的系統彼此隔離，是目前最重要的安全性觀念。Microsoft 稱之為「伺服器和網域隔離」。
伺服器和網域隔離就同時採用了 IPsec 和防火牆兩種功能。新的防火牆管理介面體認到這一點，於是也加入了隔離規則專屬的功能。如果您要根據來源系統或目的地系統的屬性 (例如網域成員資格) 來限制連線，就很適合使用它們。
如 [圖 1] 所示，「新增連線安全性規則精靈」一開始會詢問您要建立哪一種類型的規則。如果您選擇 [隔離]，精靈就會預先設定幾個適合隔離規則使用的設定。
[圖 1] 使用「新增連線安全性規則精靈」來建立隔離規則
[圖 1] 使用「新增連線安全性規則精靈」來建立隔離規則 (按一下影像可放大檢視)
也許您有注意到 [圖 1] 當中的隔離規則提到健康狀況。伺服器和網域隔離所用的規則，其實與您在 NAP 所用的規則一樣。
有些類型的流量是無法強制驗證的。比方說，您可能不希望對 DNS 解析進行驗證，而對於這類流量的端點，您需要的正是豁免驗證規則。豁免驗證規則正如其名 — 可以讓流量免受 IPsec 需求的限制。
而伺服器對伺服器規則就有點名不符實了。這個規則較常用於伺服器，但也可以用於用戶端。伺服器對伺服器規則只要求驗證連線。這與隔離規則不同，隔離規則不只要求驗證，也要求滿足其他額外的條件，例如網域成員資格或健康狀況。
通道規則主要是定義閘道之間的網站間虛擬私人網路 (VPN) 和通道。通道規則鮮少與 Windows Vista 一起使用，因為您不可能把 Windows Vista 用在閘道中。您可以建立完全自訂的規則，這可讓您自訂規則的每一個參數。

規則排序
規則排序乍看之下有點複雜。這是因為要瞭解規則排序，必須先忘記排序。與其說規則排序是在進行排序，不如說它是比對選擇。讓我們拿輸入流量作個例子吧。只要輸入流量不符合任何接受它的規則，這樣的輸入流量在預設情況下就會被封鎖。您可能會認為這是一種「優先考慮允許規則」的排序，但是這種假設是不正確的。如果某特定封包同時發現了允許規則和封鎖規則，獲勝的是封鎖規則。簡單來說，比對作業是指：
  1. 封鎖規則。如果封包或連線符合其中一項，它會被捨棄。
  2. 允許規則。如果封包或連線符合其中一項，它會被接受。
  3. 預設的方向設定檔行為。如果不符合任何一個封鎖規則或允許規則，則會根據指定為該設定檔中該方向流量預設值的行為，而決定如何對待流量。如果所有設定檔都是輸入方向，則封鎖預設設定中的流量。如果是預設的輸出方向，則接受預設設定中的流量。
比對程序是由已驗證的略過 (IPsec) 規則負責規範。使用該類型的規則時，無論已驗證的流量是否符合其他任何規則，只要符合該規則的其他參數，都會受到核准。已驗證的略過規則，是指勾選了 [覆寫封鎖規則] 選項的方向規則，如 [圖 2] 所示。優先考慮它們，是為了讓已驗證的流量一律都能到達系統。這就是容許您輕鬆接受來自已驗證主機的流量，卻封鎖其他人流量的關鍵所在。在排序時，您可以把這個規則視為 0。因此，完整的規則排序清單如下所示：
[圖 2] 勾選 [覆寫封鎖規則] 選項，設定已驗證的略過規則
[圖 2] 勾選 [覆寫封鎖規則] 選項，設定已驗證的略過規則 (按一下影像可放大檢視)

0. 已驗證的略過規則
1. 封鎖規則
2. 允許規則
3. 預設的方向設定檔行為

每一個符合流量模式的類別當中是否含有多個規則，其實沒有多大關係。只要有任何規則找到相符的流量，規則處理就告停止。

公用、私用以及在網域上
網路資源
  • TechNet 資訊安全中心
  • 使用 Netsh Advfirewall 命令列工具
  • Windows Vista 和 Windows Server 2008 中的 Windows 防火牆及 IPsec 連線適用的安全性規則
  • 在 Windows Server 2008 上使用 SCW 進行安全性監控

新的防火牆擁有三個設定檔：公用、私用和網域。而 Windows XP SP2 防火牆則擁有兩個網路設定檔：標準和網域。一旦電腦找到網域控制站，就會自動啟動網域設定檔。若找不到，則在 Windows XP 中則會用標準設定檔。這個方法為安全性系統管理員提供了強大的功能，他可以在電腦漫遊時完全鎖定電腦，但在電腦位處公司網路的同時允許所有必要的遠端管理功能。但是這個方法對於某些使用者來說會產生一些問題，尤其是那些家裡有個人網路的使用者更是。因為如果系統無法連接網域控制站，就一定會使用標準設定檔，因此系統會從使用者家裡鎖定起來。
而 Windows Vista 所包含的新私人設定檔，可以協助您解決這個問題。現在當您將系統連接到新網路時，它會先問您那個網路是公用 (就是舊標準設定檔的新名稱) 還是私用，然後再妥善設定系統。每當系統連接到那個網路時，系統都會根據網路上基礎結構伺服器呈現給它的網路參數而記住它。雖然這並非萬無一失的做法，不過因為它容許更多網路接受更妥善的鎖定，所以多少還是有點幫助。
另外，用來偵測系統是否在網域上的偵測邏輯，也比舊版更好。因此現在轉換作業比以前更快、更可靠，而且當實際位於網域上時，猶豫應該使用公用或私用設定檔的系統數量也沒那麼多了。
您可以將規則連結到某種特定類型的網路，以防止系統自發性的提供太多資訊，並且防止它們連接到不受信任網路上的系統。這就是防火牆和 IPsec 的整合開始有效發揮作用的地方。
您可以使用這些新的規則，提供一些之前不可能實施的限制。比方說，過去多年來入侵者不斷引誘使用者，將 Windows 網路用的伺服器訊息區 (SMB) 連接到不受信任的主機，以強迫驗證序列授予他們挑戰-回應組合來破解密碼。過去他們也會利用這類攻擊，將驗證降級為純文字驗證，或者將使用者的挑戰-回應組合反射回原始電腦。前者的技術早已在多年前破解了，後者的技術則隨著 Windows XP SP2 一起移轉，但是別忘了，自發性的挑戰-回應組合還是有欠周詳。
為了防止這種情況發生，您可以使用 Windows Vista 防火牆的另一種新功能 — 輸出篩選。比方說，系統管理員可以決定封鎖公用設定檔中所有的輸出 SMB 連線 (那些在連接埠 TCP 135、139、445 和 UDP 137、138、445 終止的連線)。這麼一來，就可以防止有心人士在引誘攻擊中，利用您的系統取得挑戰-回應組合，或者存取網際網路上不受信任的 Windows 檔案共用 ─ 至少不會那麼容易。
同樣的，這也不是萬無一失的做法。比方說，如果系統已遭入侵，這個規則就無法阻止系統對外通訊，因為攻擊者只要停用規則，大家就沒轍了。不過它倒是可以保護行為正常但是有曝光可能的系統。
另外您必須注意的是，就像在 Windows XP SP2 一樣，Windows Vista 和 Windows Server 2008 一次也只能有一個作用中的設定檔。如果系統中有兩個即時網際網路介面，其中一個是在網域上，另一個是在公用網路上，那麼兩者都會套用公用防火牆設定檔，這是因為套用的一定是限制最嚴格的設定檔。正如您所猜測，公用設定檔的限制比私用設定檔更多，而私用設定檔的限制又比網域設定檔更多。因此請注意，輸出 SMB 封鎖規則可能會中斷許多 VPN 連線的流量。
當電腦在公用或私用網路上時，若要讓流量透過 VPN 連線傳送，可以建立專門套用到 VPN 介面的方向規則。不過，VPN 介面必須由 Windows 辨識才行。如果不是使用 Microsoft® 路由及遠端存取服務 VPN 伺服器，請先測試這項功能之後，再廣泛部署它。這個問題主要是發生在通往用戶端的輸入流量，以及您所建立的任何自訂輸出規則。

建置防火牆規則
在新防火牆當中建置防火牆規則，遠比在舊防火牆容易。「新增規則精靈」(如 [圖 3] 所示) 可讓您定義所有常用類型的規則，其中包括針對特定服務而預先定義的規則。
[圖 3] 「新增規則精靈」中預先定義的規則。
[圖 3] 「新增規則精靈」中預先定義的規則。 (按一下影像可放大檢視)
預先定義的規則相當重要。伺服器隔離的主要功能是限制服務的使用對象，只供那些需要使用它們的系統使用。雖然效果有限，不過您還是可以在伺服器產品上使用 Windows「資訊安全設定精靈」(SCW)，讓這項工作更加容易 (我曾在 2008 年 3 月號的《TechNet Magazine》討論過 SCW)。
但是用戶端版的 Windows 一直到現在才具有類似的功能。當您使用預先定義的規則類型時，困難的工作部分 (也就是決定服務要使用哪些端點) 多半都交由它幫您完成了。防火牆不只能夠感知應用程式 (因為它知道「iSCSI 服務」代表哪一個程式)；同時也包含描述特定功能的預先定義規則，因此您可以專心注意規則中需要涵蓋哪些電腦。雖然這仍是困難且耗時的工作，但至少是您環境特有的工作。
另外還有一個自訂規則 (被 [圖 3] 所示的下拉式清單遮住了)，可以提供您所有驗證防火牆能夠提供的彈性。比方說，如果您希望規則只接受 IPsec 加密的流量，請在 [圖 2] 所示的精靈的 [活動] 頁選取這個選項，只接受安全連線。
您在選取這個選項的同時，也開啟了加密功能。如果您將選項保留空白，流量便會使用 ESP-NULL (具有 NULL 金鑰的封裝安全承載)。我們建議您以這種方式使用 IPsec 進行驗證。由於流量可以毫無阻礙的周遊網路，因此它也容許大部分的網路管理工具保持運作。如果您想要加密的話，只要勾選這個方塊即可。
在許多情況下，為網路流量加密，還不如拒絕來自惡意主機的流量。因為將網路流量加密，充其量只能封鎖已經取得網路本身存取權的壞蛋，不讓他看到封包內容。而要求驗證則可以防止您傳送封包，進而防止您受到攻擊。當然有時候非得進行網路層級加密不可，但有時候其實只需要驗證就行了。

建置網域隔離規則
通常在大部分的環境中，您都會希望只有數量有限的電腦能夠傳送流量到工作站。至少所有的工作站都應該以網域隔離規則加以設定。這項作業在 Windows XP 是有點複雜，但在 Windows Vista 卻很簡單。
首先，請開啟您所選擇的管理工具，選取 [連線安全性規則] 節點。接著在該節點按一下滑鼠右鍵，選取 [新增規則]，這時候畫面會出現 [圖 1] 所示的對話方塊。請選取 [隔離規則]，然後按 [下一步]。接著您得選擇要不要強制實施這項規則。如果是在工作站，您多半會要求驗證輸入流量。這是為了防止任何未加入網域的電腦傳送流量到工作站。但是，為了向基礎結構服務要求服務，系統必須容許部分輸出流量自由通行。因此最好的做法就是要求驗證輸入連線，以及要求驗證輸出連線。
接下來就是選擇驗證方法。預設選擇就稱為「預設值」 — 這樣的標題實在沒什麼幫助。您可以在每一部電腦的 IPsec 內容，設定預設的驗證方法 (存取方式是在 [具有進階安全性的 Windows 防火牆] 節點按一下滑鼠右鍵，選取內容)。預設的驗證方法一定是 Kerberos，因為這是最簡單也是最安全的方法。但是為了清楚起見，我建議您在建置規則時選擇它。在一般情況下，您只要驗證電腦就行了，不必連同使用者一起驗證。如果兩者都要求驗證，可能無法接受某些類型的管理流量，例如匿名傳輸的 SNMP 流量。
選完驗證方法之後，只要再選擇您希望規則能夠用在哪些設定檔就行了。因為這個規則是套用在加入網域的電腦上，可以呈現 Kerberos 票證，因此無需在私用或公用設定檔開這個洞。接下來只要再儲存規則，就大功告成了。
現在，基本隔離規則不再像以前那麼複雜了。但是為了充分利用 IPsec 的隔離威力，您必須實作伺服器隔離，即使在工作站上也不例外。這麼做是為了不讓工作站接聽其他用戶端，而只讓它們回應適當的管理工作站。想想看光是讓用戶端系統拒絕接聽其他用戶端，就可以減輕多少因為各種惡意程式碼突圍所造成的影響。

以指令碼編寫防火牆
新的防火牆附隨一個相當好用的 API，可讓您以指令碼編寫部署和評量。當然在理想情況下，最好盡量使用群組原則來進行部署，但是群組原則不見得隨時都能使用，因此一定要利用適當的 API-set 來設定防火牆才行。API 是以 INetFWPolicy2 分類成組。雖然軟體開發套件和 MSDN® Library 含有更完整的使用方法詳細資訊，但是只有少數範例可以說明這一點。
其中一個常見範例是需要判斷是否要開啟一組規則。比方說，假設某應用程式或系統管理員需要判斷是否能夠接受來自系統的檔案及印表機共用，他可以透過 INetFWPolicy2::IsRuleGroupCurrentlyEnabled 完成。[圖 4] 所提供的 VBScript 範例，就是在說明這項功能。
Figure 4 使用 INetFWPolicy2::IsRuleGroupCurrentlyEnabled
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
假設現在檔案和印表機共用是在關閉狀態下，而您需要開啟它，那麼首要任務就是確保開啟動作能夠順利完成，而且不會被群組原則覆寫。完成它的就是 INetFWPolicy2::LocalPolicyModifyState API。下面就是可以填上實際程式碼的概略大綱：
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

命令列和介面類型
沒有適當的命令列進行管理，防火牆就不算完整。Netsh 下面還有一個稱為 advfirewall 的子內容。advfirewall 內容可讓您透過命令列存取在圖形化 UI 內所能做的一切。比方說，如果您要在連接埠 445 實作輸出區塊，可以從已提高權限的命令提示字元執行下述命令：
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
接著再執行同一個命令，把 TCP 換成 UDP，完成下述區塊。這樣就完成規則實作了。
防火牆中有一個很酷的功能，就是您能根據網路介面類型來設定規則。記得前面提過嗎？有的規則可能會影響 VPN 連線。但只要 Windows 認出該介面是 VPN 介面，您就可以使用這類型的規則，免除該介面上的流量：
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
您也可以在 GUI 執行這項作業，但是必須等到規則建立之後才行。接著請在規則上面按一下滑鼠右鍵，選取 [內容]，然後按 [進階] 索引標籤。這時候畫面會出現一個 [介面類型] 區段，您只要在這裡選出正確的介面類型就行了。

輸出篩選
Windows XP SP2 防火牆中缺乏輸出篩選，而被視為內建式防火牆不足以保護安全的主要原因。過去不知道有多少篇文章，把 Windows XP SP2 防火牆不安全完全歸咎於缺乏輸出篩選 (其實真正的原因是 Windows XP 上沒有一個防火牆可以安全提供輸出篩選)。
Windows XP 根本沒有一種基本功能，可以將輸出篩選從障礙物 (或者是我之前用過的原則強制工具) 變成有用的安全性功能。但是 Windows Vista 有。因此，新的防火牆當然可以利用這項功能。在預設的情況下，會封鎖大部分的輸入流量，並允許大部分的輸出流量。
根據預設值，新 Windows Vista 防火牆中的輸出篩選，只會封鎖來自服務的非必要流量 。其實這麼做就足以防止提供輸出篩選器的主機遭到入侵，因此在 Windows XP 進行這個動作根本毫無意義。
Windows Vista 中的服務可以利用限制嚴格的權杖執行。基本上，每一項服務都有專屬於它自己的安全性識別元 (SID)。您可以利用這個服務 SID 來限制資源 (例如，網路連接埠) 的存取權。這個與我們之前在研究限制傳送給使用者的流量時所看到的功能一樣。也就是說，即使您以 NetworkService 的身分執行兩個服務 ，也無法管理彼此的處理程序，不過您可以設定防火牆，只容許其中一個向外通訊。如果被封鎖的服務遭到入侵，它也無法劫持已接受的服務，並且使用已接受的連接埠對外通訊，因為這個連接埠會受到服務 SID 的限制。
這是 Windows Vista 另一項很棒的安全性新功能，新的防火牆就是利用它，以輸出防火牆篩選實際提供真正的安全性價值。
事實上，新防火牆預設會在服務 SID 進行防火牆篩選，但是卻沒有 GUI 可以設定它。規則是在 HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices 登錄機碼中預先定義的。不過，您在手動修改機碼時必須非常小心，因為它並沒有受到支援。

防火牆篩選能夠提供多少安全性？
安全性社群一直對安全性存有一個極大的誤解，就是安全性價值是由防火牆篩選提供。到目前為止，我曾經提過兩個經由輸出篩選提供安全性的案例，但是這兩個案例所用的都是 Windows Vista 之前沒有的新功能。儘管如此，一般人仍然認為輸出篩選整體來說相當不錯，因此在決定購買防火牆時，這一點是他們的主要考慮因素。
諷刺的是，許多公司是以輸出篩選功能主導購買決策，但是在實作防火牆之後，輸出篩選卻根本派不上用場。這種誤導徒令資訊安全性小組浪費不少時間和精力。但是有時候採取一些與安全性有關的行動，讓大家得到心理上的安慰，反而比實際分析真正的威脅更能主導人們的決策。決策常常是由人們對於這類型「安全性劇場」(security theater) 的需要所主導，而不是由事實真相主導 (雖然後者才是正確的做法)。
這是相當簡單的輸出篩選真相，但是提倡者卻沒有把這一點考慮進去。主機防火牆廠商最常提出的論點是，如果系統遭到入侵，無論是受到蠕蟲還是互動式惡意使用者的侵害，輸出篩選都會阻止蠕蟲傳染給其他系統，或者阻止入侵者對外通訊。其實不然。
事實上，在其他條件不變的情況下，輸出篩選都會阻止一些過去曾經出現的惡意程式碼。但是如果 Windows XP 已經附有輸出篩選，那麼我們到目前為止所看到的蠕蟲，很可能早就將它關閉或是迴避。
在 Windows XP (和舊版的 Windows) 當中，任何假冒服務身分執行的蠕蟲 (和所有我們提到的常見蠕蟲也都是冒用服務身分執行) 都可能會這麼做。如果它們不這麼做，唯一的理由就是根本沒有使用輸出篩選的環境，因此也不必停用它。在互動式攻擊當中，攻擊者可以隨心所欲的迴避輸出篩選。如果攻擊者有能力執行任意程式碼，也一定很容易迴避輸出篩選。但在必要時，攻擊者也可以引誘使用者迴避輸出篩選器。
迴避輸出主機防火牆篩選器的方法有好幾種，這得視實際攻擊的案例而定。最簡單的方法是「商請」一位權限過大的使用者幫您執行。現在有太多環境的使用者仍以系統管理員的身分執行，因此那些使用者也有權隨心所欲的迴避安全性原則。攻擊者只要提出兩個選項，一是無形和非直接的安全性利益，另一個是使用者認為價值較高的東西 (例如，馬英久娃娃)，然後請使用者擇其一就行了。
使用者因為看多了這類對話方塊，常常不假思索就按下去，根本沒有仔細瞭解上面寫的是什麼。這是輸出篩選的第一個問題。如果它提供的一個奬品是安全性，另一個是當今最夯的流行產物 (像是馬英久娃娃)，勝出的一定是馬英久娃娃，因為大部分要求使用者做出安全性決策的對話方塊，都缺乏任何足以讓使用者做出安全決定的參考資訊。
但是要提供附上充分決策參考資訊的對話方塊，請使用者做出安全性決策，聽來容易做來難，因為安全性產品 (例如，防火牆) 不僅需要瞭解連接埠、通訊協定以及發出要求的應用程式，還要瞭解要求的真正目的，以及要求對使用者的意義。這些資訊很難以程式設計的方式取得。舉個例說，Microsoft Word 想要建立輸出連線，並不比 Word 想要以該連線做什麼來得有趣，。
我們需要做的是減少 (而不是增加) 無意義的對話方塊，但是輸出篩選防火牆沒辦法幫助我們做到這點。為了瞭解現況，提供重要資訊給使用者，我找出一家知名主機防火牆廠商的銷售文件。那些圖文並茂的文件偵查了防火牆的輸出篩選能力和建議能力。建議能力會偵測使用者想要做什麼，然後提供適當的建議 (至少理論上是如此)。宣傳小冊內的文字，還附了一張螢幕擷取畫面，內容寫著：「本程式尚無相關建議。請選擇下面的項目，或者按一下 [其他資訊] 尋求協助」。即使在行銷文宣中，廠商好像也不能產生參考性的對話方塊。
由於使用者沒有足夠的資訊可以做出適當的安全性決策，系統管理員只好義不容辭出面設定所有的輸出篩選，因為使用者也沒辦法這麼做。可是這麼一來，就等於無限制的加重系統管理員的系統管理負擔。
即使在防火牆詢問之後，使用者按了 [否，稍後再提醒我]，惡意程式碼還是有辦法欺近防火牆身邊。只要被惡意程式碼冒充的使用者可以在某個連接埠開啟輸出連線，惡意程式碼就可以使用那個連接埠。因此，任何處理程序都可以藉由現有的處理程序進行。 舊版的作業系統接受這種做法。但是從 Windows Vista 開始，處理程序會受到適當的限制，這也是為什麼在預設情況下受到限制的服務，根據預設是使用輸出篩選加以封鎖的緣故。
無奈的是，大部分的人總認為輸出主機防火牆篩選，會阻止已遭侵害的資產攻擊其他資產。這是不可能的事。在已遭入侵的資產上加諸保護措施，並且要求它不侵害其他資產，這種事根本就是天方夜譚。保護措施是加諸在您要保護的資產上，而不是加諸在您要對抗的資產上。如果等壞蛋都闖進門了，再要求他們不要偷東西，還不如事先把他們擋在門外來得務實。

Jesper M. Johansson 是負責安全性軟體的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有管理資訊系統 (MIS) 的博士學位，研究安全性長達 20 多年，是企業安全性領域的 Microsoft MVP。其最新著述為《Windows Server 2008 Security Resource Kit》。


安全性
使用數位憑證保護電子郵件的安全
Matt Clapham and Blake Hutchinson
簡介:
  • 建立可驗證的身分識別
  • 更新憑證狀態
  • 取得和交換憑證
  • 疑難排解 S/MIME 系統

千年來，人們採用各種不同的方法來隱藏傳輸的資訊、驗證寄件者，以及驗證訊息。隨著文明的演變，開發出了兼顧這三項任務的方法，而且這套方法已逐漸受到廣泛採納。「安全多用途網際網路郵件延伸」
(S/MIME) 是一套使用加密和數位簽章安全地傳送電子郵件的系統。
目前的加密 (隱藏) 技術分成兩大類：對稱 (秘密) 金鑰演算法，諸如資料加密標準 (DES) 或進階加密標準 (AES)，以及非對稱 (公開/私密) 金鑰演算法，例如 RSA 或 Elliptical Curve Cryptography (ECC)。現代的寄件者驗證工具是單向的算術函數，稱做雜湊，它會產生獨特的簽章。訊息摘要演算法 5 (MD5) 和安全雜湊演算法 (SHA) 是兩大常用的雜湊方法。電腦可以使用這些演算法來產生與個別來源文字 (相同的來源文字會雜湊成相同的值) 相對應的唯一雜湊或數字。為了建置公開金鑰基礎結構 (PKI) 系統，運用和結合了這些簡單的工具。

可驗證的身分識別
憑證授權單位資源
  • 針對加密檔案服務使用憑證授權單位
  • 無法重新命名或從網路移除憑證授權單位伺服器
  • 如何從網域中的電腦移除受信任的憑證授權單位
  • 如何解除委任 Windows 企業憑證授權單位，以及如何從 Windows Server 2003 和 Windows 2000 Server 移除所有相關物件
  • HOWTO：如何將憑證授權單位移至網域控制站上執行的新伺服器

PKI 系統裡面的身分識別是使用數位憑證進行管哩，這跟大多數人在國際間攜帶的政府身分識別 — 護照 — 並沒有什麼兩樣。數位憑證世界的護照標準是 X.509 格式，這種格式廣泛用於各種簽署和加密技術，例如 S/MIME、網際網路通訊協定安全性 (IPsec)、安全殼層 (SSH)、無線網路安全性、虛擬私人網路 (VPN)，甚至安全伺服器通訊 (例如 SSL 網站) 也包括在內。
憑證是以非對稱加密和雜湊為基礎建置而成。若要建立憑證，要求者 (需要某些較高授權單位簽署金鑰的實體) 會產生一個私密金鑰。該金鑰會被鎖定起來，以確保它的真實性永遠不會受到質疑。隨同私密金鑰，另外還會產生一個相對應的公開金鑰。顧名思義，金鑰組的公開部分並不是秘密，而且會公開發佈，但在某些程度上還是會確保它的真實性。
這個金鑰組可進行兩項基本的作業。首先，任何人都可以使用公開金鑰來加密只有私密金鑰可以解密的內容，其次，公開金鑰可用來解密以私密金鑰加密的內容。這對於驗證只有私密金鑰才可能建立的簽章是很重要的。
對憑證授權單位提出的要求包括各種詳細資料，例如適用金鑰的人員或電腦的身分識別、演算法類型和強度，以及金鑰組的公開部分。憑證授權單位 (CA) 會使用雜湊演算法接收及驗證要求當中的資訊，並且建立與該項資訊相對應的唯一識別碼。
CA 會使用它的私密金鑰加密資訊的雜湊，並把它組合成標準格式 (例如 X.509)，然後建立與原始要求相對應的憑證。X.509 憑證將包含一份宣告清單，包括憑證 (主體) 的身分識別、有效期限、公開金鑰，以及可使用憑證進行的作業等。憑證接下來會傳回給要求者，它事實上是個權杖，表明：「我，CA，擔保這個公開金鑰，以及與它相對應的私密部分，作為此處所述的全部用途」。
對於根 CA (位於信任鏈結的最高層級)，憑證會自我簽署。大部分可接受的根 CA 都會預先安裝在基本作業系統或應用程式中，但可透過套件或企業設定加以更新或更改。在根 CA 和分葉節點 (通常是指個人或系統) 之間，可以有一或多個中繼 CA。
鏈結包括所有節點及當中內嵌的所有前置憑證，由 CA 在該層級簽署。嘗試驗證憑證的協力廠商可以檢查本機計算的雜湊，並與針對使用該特定 CA 或個體的對應公開金鑰來解密的雜湊進行比較。就是這樣 — 從分葉到根的完整驗證鏈結 — 當然前提是根是受到信任的。

更新憑證狀態
每個良好的 CA 都有管道可以發佈一份不該再信任的憑證清單。這份憑證撤銷清單 (CRL) 會說明哪些發行項目已特別被 CA 取消。為了方便起見，CRL 的位置通常是 CA 憑證的屬性。
CA 會根據兩種情況定期發行 CRL：排程 (也許是每兩個禮拜) 或事件 (某些情況指出發行的憑證不應該再受到信任)。CA 會在發佈 CRL 時簽署它發行的 CRL。當接收系統評估鏈結的有效性時，它通常會嘗試取得鏈結中每個發行 CA 的 CRL (藉由憑證本身內嵌的詳細資料，或是透過一些預先定義的可信任發佈機制)。如果沒有任何 CRL 可用，用戶端可能會改用最近成功快取的複本，只要此複本不超過指定的 CRL 更新期間就行了。若連這樣都辦不到的話，用戶端系統通常會顯示某種錯誤，指明憑證看似有效但無法確認撤銷狀態。
許多應用程式若是無法驗證鏈結或鏈結中每個節點的 CRL，就會花上比較長的時間載入憑證。視憑證所保護的內容而定，使用者不一定要信任它。每個 CA 一定要有定期更新、廣泛可用的 CRL 發佈點，尤其是對那些公開根的 CA 來說更是如此。
根 CA 是憑證鏈結的基礎，而鏈結則是所有憑證階層的基石。大部分用戶端系統或應用程式只會在分葉節點鏈結回信任的根 CA 時，才會將分葉節點憑證視為有效。這可以是企業 CA，由特定公司所擁有或經營的 CA，或是公開根 CA (例如 VeriSign)。
對於公開根 CA，為了確保完整性，必須具備豐富的操作專業知識。企業對於內部營運也當努力達成相同的等級，因為根 CA 的安全性在此環境下也一樣重要。根 CA 實際上應該保持離線，而且僅作為發行憑證和更新 CRL 之用，以獲得最佳的保護。如需有關 CA 操作最佳作法的詳細資訊，請參閱「憑證授權單位資源」資訊看板中所列的文章。
金鑰修復是需要考量的重要層面之一。為了使調查作業更具效率，並確保資料不會被使用者鎖定而無法復原，企業應該將所有使用者發行的金鑰備份起來。而且這些備份複本應該存放在安全的儲存機制中。如此一來，若是使用者的金鑰不見了，譬如說智慧卡被遺留在計程車裡面，還是有辦法存取金鑰所保護的任何內容。
最後，每個良好的密碼編譯系統都包含生命週期管理的概念。隨著電腦的速度越來越快，演算法也變得越來越薄弱。每個良好的加密系統都必須能夠自行更新，並隨著時間轉換到新演算法和金鑰大小。在識別出密碼編譯弱點，以及分階段加入或去除特定功能時，應該適當地更新 CA。

實作 S/MIME
使用 S/MIME 啟動載入、撰寫、傳送和接收已簽署或已加密電子郵件分成好幾個階段。我們會在介紹典型的 S/MIME 案例時，涵蓋相關細節、問題和可能的解決方案，此案例是：兩名使用者從兩個不同的 Active Directory® 樹系和不同的憑證授權單位鏈結 (也就是從個別的操作實體，無論是否位於相同的公司)，使用 Microsoft® Office Outlook® 2007 傳送已簽署和/或已加密的電子郵件給彼此。
我們將假設必要的基礎結構已經就定位，以著手我們即將說明的作業。在我們的案例中，使用的是整合 Active Directory 的企業憑證伺服器。

取得憑證
第一項工作是取得適當的憑證。要這麼做，您開啟 [憑證管理員] MMC (certmgr.msc)，在 [Personal] 資料夾上按一下滑鼠右鍵，在快顯清單上選取 [所有工作]，然後從清單中選取 [要求新憑證]。
這將啟動「憑證註冊」精靈，如 [圖 1] 所示。根據預設，將顯示幾個以企業為中心的選項，但重要的是 [使用者憑證]。稍後會用它來啟用簽署和加密程序。憑證必須能夠用於：
[圖 1] 要求憑證
[圖 1] 要求憑證 (按一下影像可放大檢視)
  • 數位簽章 (使用建立者的驗證封印建立訊息)
  • 金鑰加密 (針對加密檔案系統等技術，使用一個金鑰保護另一個金鑰)
  • 保全郵件 (只能由握有相對應私密金鑰之指定收件者讀取的加密訊息)
傳送 S/MIME 簽署的電子郵件時並不需要金鑰加密屬性。不過在傳送或接收加密郵件時，就需要這個屬性，但不需要簽章屬性。在預設的情況下，Windows® 憑證服務內的範本會啟用這三個屬性。如果不准使用者要求新憑證，則精靈啟動時三個屬性都不會顯示。如果沒有任何企業 CA 可用，會向使用者顯示「註冊錯誤」，指明無法連絡網域或 CA。針對這個逐步說明，我們將假設單一憑證同時允許簽章和加密。

交換憑證
讓兩名使用者開始傳送加密的電子郵件最簡單的方法，就是直接傳送已簽署的郵件給彼此。撰寫好郵件之後，使用者可按一下 [簽章] 按鈕 (這個按鈕在 Outlook 中有時候預設會隱藏起來，除非至少用過一次。依序一下新訊息的 [選項] 設定、[安全性設定] 按鈕，然後在 [安全性內容] 對話方塊上勾選 [新增數位簽章至此郵件] 方塊，就可以找到這個按鈕)。簽章按鈕 (黃色的小信封上有條紅色的緞帶，註明 [簽章]) 會在郵件中加入數位簽章，以建立它的來源真實性。
在按下 [傳送] 按鈕之後，可能會提示使用者提供另外持有的金鑰權杖，例如插入智慧卡或輸入 PIN。這會視組織內所安排的特定金鑰保護方法而定。
收到 S/MIME 簽署郵件的使用者必須檢視並以滑鼠右鍵按一下寄件者的名稱 (在 [寄件者:] 之後)，接著從內容功能表選取 [新增至 Outlook 連絡人]，這會新增新的連絡人項目或更新現有的項目。憑證隨後會與該特定的連絡人項目建立關聯。請注意，在常見的 Active Directory 環境內 (兩名使用者位於相同的樹系或公司裡)，公開使用者憑證發佈是透過使用者的 Active Directory 物件內的屬性自動完成的。
交換憑證的另外一種方法，就是讓每名使用者以附件的形式傳送他們的 S/MIME 憑證。若要這麼做，雙方都必須將他們的憑證匯出成 CER 檔案。使用者必須檢視憑證，並遵循我們即將討論到的匯出程序，小心不要一併匯出私密金鑰，如 [圖 2] 所示。
[圖 2] 交換憑證時， 不要匯出私密金鑰
[圖 2] 交換憑證時， 不要匯出私密金鑰 (按一下影像可放大檢視)
每名收件者接下來會在 Outlook 中手動建立連絡人項目，然後將憑證加入寄件者的項目中。兩名使用者一交換好憑證，就能夠彼此交換加密的電子郵件了。

疑難排解
有時候收件者會無法開啟加密的訊息。我們在這個領域當中看過的三個最可能的問題肇因，分別是根 CA 不受信任、中繼 CA 無法驗證，以及 CRL 無法使用。
不信任的根 CA 通常會在 Outlook 中顯示成與簽章相關聯的錯誤訊息：「簽章發生錯誤。請按一下簽章按鈕，以取得詳細資訊」。若要解決問題，請從 Outlook 內開啟憑證，再按一下快顯對話方塊中的 [檢視憑證授權] 按鈕。在 [憑證內容] 對話方塊的 [一般] 索引標籤上，檢查一下訊息。如果訊息指出 CA 根憑證不受信任，而且需要安裝，請前往 [詳細資料] 索引標籤。按一下 [複製到檔案...] 按鈕，並遵循精靈，接受所有預設值，然後在收到提示時提供檔案名稱和資料夾。
現在以電腦的系統管理員身分開啟一個全新的 Microsoft Management Console (MMC)。前往 [檔案]|[新增/移除嵌入式管理單元] (Ctrl+M)，選取 [憑證]，並為電腦帳戶新增它，在收到提示時選取 [本機電腦]。接下來，在左邊的樹狀目錄中展開 [憑證] 節點，然後對信任的根憑證授權單位進行相同的動作。在快顯功能表上以滑鼠右鍵按一下並選取 [所有工作]|[匯入]。將前述匯出的憑證檔案匯入到信任的根憑證授權單位，再按一下 [完成]。然後讓受影響的使用者重新啟動 Outlook。
這些指示應該只能用於新增您知道可以信任的根 CA。並非所有根 CA 都生而平等。請先審慎考量是誰擁有和操作根 CA，再使用這套方法新增根 CA 到整個系統的存放區。如果您的企業是透過群組原則控制信任的根 CA 清單，那麼設定值將往下推送到用戶端系統。在這種情況下，上述的指示可能就不管用。如果真的不能用，您可能需要另尋他法，例如保全網站或伺服器以交換資料，因為使用電子郵件的體驗既不會順暢也不會受到保護。
上面提出的第二個問題，無法驗證中繼 CA，通常是發生在兩種情況下：嘗試驗證憑證的用戶端無法取得憑證中所定義的授權資訊存取 (AIA) 位置，或是用戶端所擁有的中繼 CA 憑證版本與 CA 所發行的版本不符 (用戶端通常是晚一兩個版本)。這些狀況在 Outlook 使用者介面中看起來十分類似。我們只在非常特定的情形下看過，就是當鏈結中的中層 CA 已過期，並在它發行的其他下層憑證到期之前重新發行的時候。
基本上，這個問題是發生在鏈結裡面有差距的時候。有些父憑證可能缺乏完善的詳細資料，或是沒有適當內嵌在分葉節點內，進而使整個情況更加複雜。
若要解決這個問題，寄件者必須開啟新郵件，並依序按一下新郵件的 [選項]、[安全性設定] 按鈕，以及 [變更設定] 按鈕。現在按一下 [選取] 按鈕選擇簽署憑證，然後在快顯對話方塊上按一下 [檢視憑證] 按鈕。前往 [憑證路徑] 索引標籤，選取分葉節點的發行者 (也就是在鏈結中往上一層)，再按一下 [檢視憑證] 按鈕。依序按一下 [詳細資料] 索引標籤、[複製到檔案...] 按鈕，然後完成匯出精靈，選擇 PKCS #7 (.P7B)。確定已勾選 [包含憑證路徑中的所有憑證] 選項，如 [圖 3] 所示。最後，傳送匯出的鏈結檔案給所需的收件者。
[圖 3] 修補憑證鏈結中的差距
[圖 3] 修補憑證鏈結中的差距 (按一下影像可放大檢視)
取得匯出的憑證鏈結後，收件者必須開啟和匯入憑證鏈結，做法跟我們之前匯入根憑證雷同。其中一項差異是選取的存放資料夾應該是 [中繼憑證授權]。如果郵件開啟，而且憑證在 Outlook 中顯示為有效，那麼一切會正常運作。
至於第三個問題，無法使用 CRL，修正的方法非常簡單。Outlook 的起初回應看起來跟前一個問題非常像。不過，即使根 CA 或中繼簽章 CA 受到信任，還是會顯示錯誤。對於分葉以上的每個憑證鏈層級，請依序開啟憑證的內容、[詳細資料] 索引標籤，再查看稱為 [CRL 發佈點] 的欄位。
對於列出的每個 CRL 發佈點 (尤其是網際網路可以存取的發佈點)，確認 CRL 檔案 URL 可以開啟。隨著每個層級進行驗證時，往鏈結的上一層移動。如果有任何無法取得的 CRL，可能就是問題的根源。若要解決問題，您應該確認區域網路原則並未封鎖您的存取。否則的話，請試著連絡擁有 CA 的公司，或等待 CA 的 CRL 發佈點恢復可運作狀態。

發佈憑證
發佈作業很簡單。基本上，已簽署的郵件是傳輸到郵件伺服器，這部伺服器接著會透過查驗的方法，即 SMTP，將郵件從一個位置傳送到另外一個位置。我們發現傳輸中的已簽署或已加密郵件有一個問題，就是有些郵件系統會拒絕或中斷通過它們的已簽署或已加密郵件。修正方法是與系統的 IT 管理員合作來允許郵件類型。當然，您可能還是必須忍受有些郵件類型就是會被封鎖。接收方可能有正當的理由不在特定的操作環境下允許加密的郵件。

加密回覆
若要建立加密的回覆 (假設上述的啟動載入程序已完成)，寄件者只需要建立郵件，然後在郵件撰寫視窗中按一下 [加密] 按鈕 (黃色小信封上有個藍色鎖，註明 [加密]) 就行了。如果 [加密] 按鈕無法使用，請遵循傳送已簽署郵件的步驟，不過在最後一個步驟中，請改勾選 [加密郵件內容與附件] 核取方塊。
傳送加密郵件給收件者並不需要 S/MIME 簽署，但是搭配使用兩者也無妨，因為簽署可讓讀者驗證寄件者 (加密功能並不會表明寄件者)。加密程序將嘗試使用所有收件者已知的公開金鑰來加密郵件。如果系統找不到某些指定收件者的憑證，會在快顯對話方塊中將它們標示出來，建議不加密來傳送郵件，如 [圖 4] 所示。
[圖 4] 如果您 使用憑證遇到問題，可決定傳送未加密的郵件
[圖 4] 如果您 使用憑證遇到問題，可決定傳送未加密的郵件 (按一下影像可放大檢視)
根據預設，簽署和加密作業應該與其他同等設定的用戶端系統搭配運作，但是如果雜湊或加密演算法不支援下層的話，有時候跨版本加密或簽署的郵件可能會產生問題。我們在將簽署的電子郵件 (使用 SHA-512 的雜湊演算法) 傳送給執行 Windows XP SP2 的使用者時，就碰過這樣的問題。因為接收系統並不支援雜湊，所以使用者無法驗證簽章或是讀取郵件。然而，除非 Outlook 預設值有所變更，否則使用者不太可能在這個階段遇到太多問題。
收到郵件後，假如與公開憑證相關聯的私密金鑰可以使用的話，指定的收件者應該就能夠開啟郵件。再次強調，使用者可能必須提供額外的權杖以證明持有私密金鑰，這要看私密金鑰的部署方式而定。其他已完成類似啟動載入程序的使用者可與寄件者進行類似的簽署和加密通訊。如果使用者在某些情況下 (也許是因為電腦遺失) 變更了他的私密金鑰，他必須要重新要求憑證，然後重新發佈已簽署的郵件或憑證檔案給其他想要交換加密郵件的人。

結論
讓兩種不同目錄或組織內的兩名使用者之間能夠進行簽署和加密的 S/MIME，所牽涉的通常不比我們剛剛討論的情況複雜到哪裡去。簽署在運用得當的時候非常實用，因為它可提高郵件的真實性。對於機密的詳細資料，加密郵件為傳輸中的資料提供另一層保密性。兩者結合可達成來源的真實性和資料的秘密性。而透過我們在本文所說明的程序，大多數的使用者應該都能順利運用這些功能。

Matt Clapham是 CISSP，並在 Microsoft IT 擔任安全性工程師。他白天對 LOB 應用程式進行安全性評量，晚上則涉獵技術、遊戲、電腦音樂，或是安全性。他偶爾會在 Puget Sound IT 安全性社群發表演說。您可以透過電子郵件與他連絡：matt.clapham@microsoft.com。
Blake Hutchinson 在 Microsoft 的商務線上服務小組 (Business Online Services Group，BOSG) 擔任支援分析師。他的職責包括為 BOSG 的企業客戶內部建立的 LOB 工具，提供作業支援和專案評量。Blake 享受攝影、滑雪和電腦遊戲。您可以透過電子郵件與他連絡：blakeh@microsoft.com。


編輯的話 世紀大爭論
Joshua Hoffman

我喜歡看大對決。 別誤會，我指的不是一般常見的路人甲和路人乙，為了一件芝麻小事當街對沖。這多浪費時間哪！真正的對決，是指兩位分持相對觀點的智者，站在一起熱切表達各自的論據 — 這才稱得上強而有力的權威對決。想想啟蒙教學，想想蘇格拉底吧。
本月份我們要呈現給您的是 IT 界的世紀大爭論 — 透過隱匿來實現安全。我很想在此解釋一下這個概念，不過心裡不免有點懷疑，大部分的人會不會不等看完這幾個字，就開始振振有詞發表意見了呢？我敢打睹，大部分的人一定恰好分成下面兩大派：一派解讀為「這種安全性，根本毫無保障嘛」，另一派則解讀為「只要是安全性，多少有點保障吧」。
本月份我們邀請兩位知名的安全性專家 Jesper Johansson 和 Roger Grimes，共同舉辦一場辯論對決，分別代表其中一方的立場。另外也邀請兩位傑出人才 Aaron Margosis 和 Steve Riley，分別為雙方加油，表達支持評論。雖然我對自己發行的每一頁篇幅都引以為傲，卻也不得不承認本篇的確是我長久以來最欣賞的文章之一。無論您是站在哪一邊，我都希望您敞開心胸好好閱讀，相信您一定會樂在其中。
當然嘍，除了我們喻為年度安全性報導的這一篇之外，還有其他值得一看的文章。我們把去年報導的主題重新回鍋再炒。去年最受歡迎的一篇，是由特約編輯 Michael Murgolo 執筆討論一組 Script Elevation Power Toy 的文章，這組 Script Elevation Power Toy 可以連同 Windows Vista 的使用者帳戶控制功能，幫助您在提高權限的內容當中執行 VBScript 或 Windows PowerShell 指令碼。這篇文章獲得許多正面迴響，因此今年特地請他再次出馬，繼原始的程式碼之後，再介紹一組全新的公用程式。這組強大的公用程式，您無論如何都要試試看。
Byron Hynes 也是去年的合作夥伴，他介紹的是 Windows Vista 的 BitLocker 磁碟機加密。今年 Byron 再度以 BitLocker 為主題，討論繼 Windows Vista SP1 和 Windows Server 2008 推出之後，BitLocker 產生了哪些變化。其他還有軟體限制政策、Windows Vista 防火牆管理、S/MIME 疑難排解、第二版的新專欄《SharePoint 內幕》、提倡永續電腦的商業構想... 等等相關文章。好好享受吧！—Joshua Hoffman

感謝下列 Microsoft 技術專家： Troy Funk、Aaron Margosis、Michael Murgolo、Steve Peschka、Steve Riley、Mark Russinovich、Jon Schwartz 和 Jim Truher。


讀者來信 讀者有話直說

Windows 備份
看到您在 2008 年發表的 Windows Server® 2008 相關報導 (2008 年 3 月份的《TechNet Magazine》，technet.microsoft.com/magazine/cc268370) 之後，我非常興奮，於是就到上市發表會買了一套，打算用在家庭網路。安裝過程相當順利，但是到了備份卻把我難住了。
雖然作業系統本身有支援磁帶機，但新的 Windows Server Backup 卻不支援，而 NT 備份又已經移除 (我把個人資料連同 Active Directory® 和 Exchange Server 2007 一起備份到磁帶機當中)。
雖然知道 Microsoft® Data Protection Manager (DPM) 對我的安裝有害，我還是努力根據網路上的提示下載它。但是 DPM 並未安裝在 Windows Server 2008 上，而我又找不到它們的手動安裝指示。到底小型安裝都是怎麼備份的呢？
—Ravi S.

DPM 的確是磁帶備份的解決方案，因為 Windows Server 2008 中的新解決方案，就是針對磁碟儲存體設計的。再過幾個月，DPM 就會正式支援 Windows Server 2008 了。
—Karandeep Anand (Microsoft 資深領導程式經理)

問卷工作流程
我在 2008 年 2 月份＜建置強大的問卷基礎結構＞(technet.microsoft.com/magazine/cc194407) 一文的「單獨使用 WSS」一節當中，看到下面這一句：「您還可以選擇是否在問卷中指定工作流程。」
據我瞭解，Windows® SharePoint® Services 3.0 (WSS) 和 Microsoft Office SharePoint Server 2007 (MOSS) 並不支援與問卷回覆有關的工作流程。我曾試過把工作流程關聯到問卷回覆，雖然 SharePoint Designer 接受這項關聯性，但是工作流程總是會出現「啟動失敗」錯誤。我曾看過一篇知識庫文章 (support.microsoft.com/kb/926370) 清楚寫著，與問卷回覆相關聯的工作流程並不在支援之列。
我知道我可以把事件接收器連結到問卷，然後起始其他流程，但其實這並不是 SharePoint 一般參照的工作流程。難道這句話錯了嗎？還是我漏看了哪一句嗎？
—Matt B.

您所參考的段落是在講述 WSS 如何提供精靈，讓逐步流程建立問卷。當中它也討論了各種選項 (分支邏輯、開放式/封閉式問題等等)。
而指派工作流程的確是精靈提供的選項，所以「您還可以選擇是否在問卷中指定工作流程」這句話並非完全不對。您是可以指派它，只是結果正如您所說的，問卷中的工作流程就是無法運作，即使這個選項因為某些原因而被包含在內也一樣。我這麼解釋吧。
當您把工作流程關聯到問卷，並且啟動它時，您會接到一則「啟動失敗」的錯誤。根據活動的記錄顯示：
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
這個 GUID 代表工作流程執行個體。這個做法是可以確保您觸發正確的工作流程，只是「問卷」清單類型並不支援工作流程屬性。理由很簡單，因為它沒寫進程式中。所以當工作流程努力以 MakeActivation 方法啟動，並且執行下面這個動作時：
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
它會呼叫 SPWorkflowActivationProperties，如下所示：
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
所以如果它認為 GUID 字串是問卷當中的一個屬性 (顯然它應該是一項內建屬性)，但是問卷卻沒有工作流程式 GUID 專屬的屬性時，結果一樣行不通。
其實這個問題是有相對因應措施的，所以您的思考方式也沒有錯。 因應措施的做法是建立一份觸發工作流程的自訂清單，然後利用 ItemEventReceiver，將事件接收器連結到問卷，接著事件接收器會在自訂清單中建立一個項目來觸發工作流程。不過您也沒說錯，這兩者不完全相同。我就長話短說吧 — 沒錯，你說得很對；它其實沒什麼用。
—Pav Cherny (《SharePoint 內幕》和《TechNet Magazine》的專欄作家)


工具箱 適合 IT 專家的新產品
Greg Steen

經由網路進行宣告
NetSupport Notify
www.netsupportnotify.com
以電腦為主的工作環境在辦公室場所中隨處可見。大部分的使用者都是整天坐在電腦螢幕前面，並且連線到您所管理的網路中。除了為共用資源、應用程式和網際網路提供傳輸途徑外，您也可以將公司網路用作為公司策略的一部份，傳達重要訊息給使用者的手段。有個工具可以協助您透過 LAN 和廣域網路 (WAN) 傳遞訊息給使用者，那就是 NetSupport Limited 推出的 NetSupport Notify。
這個輕量型應用程式伺服器為您提供快速可靠的廣播訊息支援。舉例來說，您很容易就能夠警告使用者共用資源有未預期的服務遺失，讓大家知道他們聽到的安全性警示是由意外所觸發，或通知員工大樓緊急事件。
您可能已經使用過某些簡單的廣播訊息工具，但是這些工具只能用於所安裝的 LAN。然而，NetSupport Notify 是以代理程式為基礎，而且透過它的通知閘道元件，可以輕易周遊您的網路拓撲，到達 Windows® 與 Mac 用戶端，無論這些用戶端是直接連接、經由無線連線連接，亦或是透過虛擬私人網路來連接。
通知服務會以 Windows 服務的方式執行，您是經由系統管理通知主控台 (可安裝在相同或不同機器上) 來與服務連線。來自服務的通知會分類成以下三種安全性等級之一：訊息、警示或緊急。當用戶端接收到訊息時，便會建立一個事件記錄項目，伺服器也會收到訊息已傳達的通知。其他訊息選項包括在顯示視窗之外也播放嗶聲、強制通知永遠保持可見，以及在訊息上設定自動逾時以便自我關閉。
您也可以選擇只鎖定特定的通知群組。通知主控台可以連線到多部通知伺服器，因此單一主控台可以成為訊息廣播中心。
除了伺服器與主控台以外，NetSupport Notify 也包含開發工具，可讓您從遠端為使用者部署代理程式，而不用親臨使用者的桌上型電腦。您可以利用 IP 位址範圍或經由 Windows 網路網域及工作群組探索功能來指定目標電腦。
部署主控台也為您提供網路的快速檢視，其中會顯示已安裝的代理程式版本以及重要資訊，例如 DNS 名稱、MAC 位址、IP 位址、平台，還有控制台是否有權存取遠端電腦。若您使用 Active Directory®，您可以透過群組原則來管理設定和部署作業。
為了防範未經授權的廣播 (例如，「大家好，我的辦公室在四點會舉辦一個派對！」)，代理程式與主控台採用類似 Windows Management Instrumentation (WMI) 金鑰字串的安全代碼。此外，您可以經由 Active Directory 原則控制傳送警示的功能。
價格： 75 名使用者授權 $180 美元起。
使用 NetSupport Notify 傳遞宣告給員工
使用 NetSupport Notify 傳遞宣告給員工 (按一下影像可放大檢視)

監視您的網路
NetOptics：Teeny Tap
www.netoptics.com
與良好的監視應用程式搭配使用，被動的網路分流器也可以當作關鍵工具來疑難排解不可靠的網路、修復異常的應用程式，以及減輕基礎架構的潛在威脅。我注意到有一個不錯的 10/100 網路專用分流器，就是 NetOptics 推出的超級可攜式 Teeny Tap。
這個 3.125 英吋乘 1.5 英吋的「迷你」裝置從第 1 層起提供全雙工的流量監控，可讓您輕鬆地抽查或持續監視 10/100 網路上的流量。這個裝置利用兩個監視 RJ45 連接埠來達到全雙工監視功能，讓您深入探勘在這兩個網路連接埠都連線到網路監視器、通訊協定分析者、IDS/IPS 或其他探查工具時流經兩個網路連接埠兩端的流量。
Teeny Tap 不需要 IP 位址。藉由將您與網路隔離，您可以保持隱形，以防有些人觀察您的出現而停止對網路胡來。同時，零延遲 (Zero Delay) 功能可確保交流器斷電時，不會影響經過交流器的傳輸流量 — 這樣應該就不會發生延遲或封包遺失。
交流器可以從 USB 充電或使用內附的電源供應器；或者使用兩者來當作備援，這麼小的裝置有這樣的功能實在很了不起。Teeny Tap 也與 Power over Ethernet 架構服務相容，例如網路相機和 IP 電話。因此，您也可以監視這些流量來確保通訊的安全性。
Teeny Tap 套件包含交流器、通用電源供應器、兩個跳線和兩個直通型 RJ45 纜線，還有一個攜帶盒。如果您的環境需要更多馬力，不妨參考一下 NetOptics 提供的其他網路交流器產品。產品系列涵蓋的範圍完整，從小型辦公室網路到大型企業環境，從 10MB 到 10GB 以及適用於銅絞線與光纖網路的產品都有。
價格： $325 美元 (直接售價)。
使用 Teeny Tap 監視您的網路
使用 Teeny Tap 監視您的網路 (按一下影像可放大檢視)

最佳化電腦
DTweak Pro
www.daoisoft.com
身為 IT 專業人員 (和廣泛的技術迷)，您一定想要改良系統，並盡可能提高日常作業的效能與自訂經驗。市面上有許多工具都能協助最佳化與自訂使用者在執行 Windows Vista® 的電腦上的使用經驗。Daoisoft 推出的 DTweak Pro 是一項低成本的好選擇 (此外也提供 Windows® XP 和 Windows Server® 2003 適用的版本)。
此應用程式提供一些快速存取檢視來查看 Windows Vista 的各種工具和自訂。譬如說，在 [日常工具 (Daily Tools)] 區段中，您可以執行登錄清除工具、檔案清理公用程式、登錄和磁碟重組工具，以及硬碟效能監視器。
藉由 DTweak，您也可以輕易地檢視和訂製啟動項目、取得 CPU 資訊 (包括 CPU ID、匯流排速度和時脈速度)，還可收集電腦資訊，例如廠商、開機狀態、記憶體設定與系統類型。您甚至可以調整 I/O 快取記憶體，以及等待結束損毀程式與無反應服務的時間長度。
GUI 的 [工具 (Tools)] 區段提供內建 Windows Vista 工具的連結，包含 Diskpart 和系統還原，還有便利網路工具的連結，例如 finger、ping、netstat 和 nslookup。其他網路調整包括調整最大傳輸單位、TCP/IP TTL 和 DNS 逾時設定，以及使用 QoS 封包排程器服務來限制頻寬。
價格： $29.95 美元 (直接下載)。
使用 DTweak 調整和最佳化系統
使用 DTweak 調整和最佳化系統 (按一下影像可放大檢視)

書評
Microsoft Exchange Server 2007 Administrator's Companion
www.microsoft.com/mspress
電子郵件可說是一種挑剔的怪獸。舉例來說，您無法真正控制傳入訊息的流量。如果您試圖透過暫停 SMTP 伺服器直到佇列減少的方式來擊退傳入的洪流，寄件者可能會收到「無法傳送訊息」的通知。排水系統的比喻很恰當 — 水不停流，如果您扭曲某一段的管閥，就等於是冒著另一段管閥爆裂的危險。如果您希望整個企業有效營運，就必須有規劃完善、精密微調和具有彈性的電子郵件基礎結構。
顯然，Microsoft Exchange Server® 2007 的設計是為了處理大量郵件，而且它的設計可讓您訂製基礎結構以滿足您的組織需求 — 無論是今日或未來的需求。但是在 Exchange 2007 部署中，可行的選項與決策琳瑯滿目。而且 Exchange 涵蓋的不只是電子郵件，因此您的工作更加複雜。
您實在需要一兩個參考工具來協助您制訂正確的架構與管理決策。其中一個不可或缺的參考工具書就是《Microsoft Exchange Server 2007 Administrator's Companion》。
這本書包含從規劃和部署到維護和安全性的產品部署生命週期。書中也討論到適用於 Exchange 2007 的各種用戶端及用戶端連線能力選項。本書一開始概述了各種版本之間的差異，並介紹 Exchange 2007 的新功能。對於 Exchange Server 2007 的各種架構元件也有全盤的說明。
接下來的章節說明如何擬訂計畫來部署 Exchange，並示範如何計算存放需求、伺服器和處理器需求，以及加入容錯。書中繼續討論實際的安裝和部署過程，顯示如何針對 Exchange 準備伺服器，還有如何安裝不同的軟體元件。您甚至可以讀到深度的參考資料，建立 Exchange 服務叢集來達到更高層級的可用性。
本書接著討論多種管理工具供您使用，例如 Exchange MMC 面版和新的 Windows PowerShell™ 架構 Exchange 管理命令介面。在此您也會學到各式各樣的知識，範圍從建立信箱到建立儲存群組和備份及還原作業。此章節還有不賴的一點，就是它會示範如何使用管理 GUI 和透過 Windows PowerShell 的命令列來執行所有這些作業。
Exchange 2007 有一些整合通訊功能，可讓您同時管理與單一系統間的資料和語音通訊，書中也示範如何設定及使用語音訊息、傳真訊息和語音式收件匣存取，此處只列出幾個例子。
在深入探討維護的部分，這本書涵蓋了基本的疑難排解技巧與工具、損毀和嚴重損壞修復，以及效能微調。安全性顯然應該是所有整合通訊系統的最主要考量 — 這本書針對如何保障部署安全性提供精闢的資訊。您可以學習到安全性原則與指引、防毒和反垃圾郵件功能，以及公開金鑰基礎結構。
最後，書中探討 Exchange 用戶端以及如何支援組織中的其他 POP3 和網際網路訊息存取通訊協定用戶端。總而言之，無論是想要規劃、維護或只是對 Exchange Server 2007 伺服器整合通訊平台有興趣的人，這本書都可以為所有系統管理員提供不錯的一般性參考資料。
價格： $49.99 美元 (定價)。
(按一下影像可放大檢視)

Greg Steen 是一位技術專家和企業家，為人十分熱心。他總是四處探尋新的工具，協助 IT 專家更輕鬆地進行操作、品管及開發。


SQL 問答集 I/O 錯誤、資料庫鏡像及其他主題
Paul S. Randal

問：我在自己管理的資料庫上開始定期執行一致性檢查，甚至還加入一些 SQL 代理程式警示來擷取使用者查詢所遇到的 I/O 錯誤。我不知道我根據檢查和警示實作的邏輯是否可行，因為我所有的資料庫都沒有損毀問題。我該如何在測試資料庫中製造一些損毀，以便確認我設定的一切可以正確運作呢？另外，如果要偵測 I/O 錯誤的話，還需要進行其他什麼動作嗎？
答：在 SQL Server® 2000 中有個建立損毀資料庫以供測試的老把戲，那就是從測試資料庫的 sysindexes 資料表中，手動刪除一個資料列。但是在 SQL Server 2005 中，很難以這種方法損毀系統資料表。自己動手損毀測試資料庫的最佳辦法，是在資料庫關閉的時候，使用十六進位編輯器更改資料檔。方法如下：
  • 關閉資料庫，這樣資料檔就不會處於鎖定狀態了 (不過要小心別中斷資料庫連線，因為如果誤毀了不該損毀的頁面，可能無法重新連接它)。
  • 在檔案中挑選超過 100 頁的位移 (至少 819200 個位元組)，不過它必須符合 8192 位元組的限度 (頁面限度) 才行。這是為了避開重要的中繼資料頁面和配置點陣圖，進而讓您啟動資料庫，並在上面執行 DBCC CHECKDB 的緣故。
  • 在檔案中選定的位移，寫入幾個位元組的零。這種方法幾乎可以保證產生一些頁面標頭損毀錯誤。
儘管如此，建立損毀測試資料庫最快的方法，還是使用別人已經建立好的。您可以在我的部落格上找到損毀的 SQL Server 2000 和 SQL Server 2005 資料庫 (內含說明)，網址是 go.microsoft.com/fwlink/?LinkId=115151。
至於您的第二個問題 (也就是該怎麼做才能偵測到 I/O 錯誤)，答案是啟用頁面總和檢查碼。這項功能是在 SQL Server 2005 引進的，目的在保護整個資料庫頁面免受 I/O 子系統引起的錯誤所干擾。
基本上，當您將頁面寫入磁碟時，SQL Server 最後會計算整個 8KB 頁面的總和檢查碼，然後在頁面加上總和檢查碼的戳記。當您從磁碟讀取頁面時，如果它有頁面總和檢查碼，就會重新計算該總和檢查碼，並與頁面上儲存的版本相比較。如果兩者不一樣，就表示是 SQL Server 外面的東西損毀了頁面，而引起 824 錯誤。錯誤會顯示在導致讀取該頁面的連線，並且記錄到 SQL Server 錯誤記錄檔和 Windows® 應用程式事件記錄中。
在 SQL Server 2005 和 SQL Server 2008 上建立的所有資料庫，預設都會開啟頁面總和檢查碼。但是，如果是從舊版 SQL Server 升級的資料庫，就必須手動啟用。您可以使用這段程式碼來啟用頁面總和檢查碼：
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

提示：變更預設 SQL Server 連接埠
根據預設，SQL Server 執行個體的設定連接埠是 1433。此連接埠一旦被執行個體佔用後，就不能供其他執行個體使用了。因此，如果您要安裝第二個使用 TCP 在網路上接聽的 (具名) 執行個體，就需要另一個連接埠了。而且在某些情況下，為了避免散亂，系統管理員可能會變更連接埠 (不過這種散亂並不重要，而且可以很容易的使用連接埠掃描器加以解決)。所以嘍，接下來就必須設定用戶端，讓它使用不同的連接埠。常用的方法有三種。
首先，假設系統管理員把執行個體的連接埠改為 5555，其中一個方法是在您想要連接的機器名稱內，把執行個體的連接埠號碼指定為使用 MyServername,5555 語法就行了。如果連接埠再度變更，用戶端也必須再次變更它們的 connectionStrings。
另外一個方法是使用 SQL Server 別名，這是在用戶端上設定的。除了指定別名之外，還必須指定伺服器名稱、連接埠名稱和通訊協定。設定好之後，可像使用伺服器名稱一樣，使用別名連接到資料庫執行個體。這個方法的優點是，伺服器設定變更可由網域系統管理員來部署，因為設定是存放在登錄中。
具名執行個體的第三個方法，是使用 SQL Server Browser 服務，這種情況下的使用者只知道執行個體名稱，並且在 connectionStrings 內使用 MachineName\Instance\Name 指定名稱。這在 SQL Server 2000 中已經視為執行服務的一部分實作了。但是在 SQL Server 2005 中，SQL Server Browser 服務是建置成個別的服務。除了為機器進行執行個體探索之外，它還會在連接埠 1434 上，以適合所要求之執行個體的連接埠號碼，應答連入的使用者資料包通訊協定 (UDP) 要求，藉此重新導向用戶端，以及支援透明連線。
─ Microsoft 的資料庫顧問 Jens K. Suessmeyer

問：為了移除我資料庫中所有的片段，我設定了夜間維護計畫，重建實際執行資料庫中所有的索引，而這項作業是在 SQL Server 2005 Enterprise Edition 含 SP2 上執行。我注意到這會使資料庫過度成長，而磁碟上的空間又不多，所以我多加一個步驟來壓縮所有額外的空間。可是重建步驟好像不能正常運作。到底是怎麼回事呢？
答：您碰到的是一般人在設定維護計畫時常見的問題。您被困在壓縮-成長-壓縮-成長的循環中了。
一般重建索引時，會在刪除現有索引之前，先為索引建立一份新複本。而資料庫檔案必須有額外的空間 (通常跟目前索引使用的空間差不多) 來進行這個程序。SQL Server 2000 也必須有額外的空間來排列索引資料列 (大約是索引大小的 20%)，但是 SQL Server 2005 卻為了重建一個簡單的索引，而排除這項需求。
系統管理員有時候會移除在重建索引時所建立的額外空間，因此他們在執行重建步驟之後，在維護計畫加了壓縮作業。但是很多人並不知道，這項壓縮作業會因為其演算法的關係而導致索引分散。也就是說，剛剛重建和重組的索引會馬上散成片段 — 這就與重建它的原意背道而馳了。
由於索引下次重建的時候，資料庫檔案會再度成長，因此最好在資料庫保留額外的空間，並且盡量避免執行壓縮作業 (此外，持續擴大和壓縮資料庫檔案，也會在作業系統層級導致檔案分散 — 這與索引分散一樣會降低效能)。
最後一點，就是考慮降低重建索引的頻率。您甚至可以試試其他方法，例如我為 SQL Server 2000 撰寫的舊版 DBCC INDEXDEFRAG，或是 SQL Server 2005 和 SQL Server 200 中較新的 ALTER INDEX REORGANIZE 語法。
您不妨參考一本有用的白皮書，它除了討論索引分散之外，還告訴您何時該移除分散情形 (網址是 go.microsoft.com/fwlink/?LinkId=115154)。雖然這本白皮書是針對 SQL Server 2000 所寫，但概念是一樣的。

問：我們公司一直在評估嚴重損毀修復策略，而我覺得資料庫鏡像非常適合我們。我要保護的伺服器裡面含有許多不相關的資料庫 (這是之前的伺服器整併專案所造成)，因此我想針對它們全部使用資料庫鏡像。但問題是，我能夠在不折損效能的情況下鏡像多少資料庫？
答：這個問題的答案我常常用到：視情況而定！根據出版的指導方針指出，每一個執行個體鏡像的資料庫最好不要超過 10 個，但是 10 個只是針對大多數使用者所估計的最大值。您必須針對您的硬體設定考慮下列因素：
  • 主體和鏡像執行個體有多少記憶體？(在理想情況下，兩者應該是一樣的)。
  • 主體和鏡像執行個體的處理能力有多強？(應該也是一樣的)。
  • I/O 子系統有多少頻寬可以用在鏡像執行個體？(應該跟主體上的一樣)。
  • 每一個資料庫的工作負載會產生多少交易記錄檔？
  • 主體和鏡像執行個體之間有多少網路頻寬可用？
最後兩個因素最為重要。如果兩個執行個體之間可用的網路頻寬，不足以處理所有要鏡像的資料庫每秒產生的綜合交易記錄檔，就會折損主體資料庫的效能。SQL Server 2008 有助於減輕記錄檔資料流壓縮所產生的一些負荷。
接下來最需要考慮的，是鏡像的記憶體和執行緒需求。每一個鏡像的資料庫都會使用一個執行緒和一些記憶體。低處理能力伺服器在與正常工作負載結合時，如果有大量鏡像的資料庫，可能會對伺服器造成過多負載。
另外，還必須考量執行資料庫鏡像的方式。在同步模式中，主體資料庫上的交易，必須等到所有交易記錄檔記錄全部複製到鏡像資料庫的交易記錄檔之後，才能進行認可。因此，由於網路超載所引起的任何延遲，都可能降低主體上的工作負載效能。
在非同步模式中，交易不用等候就可以在主體上進行認可，但是網路延遲可能會導致等候傳送給鏡像的交易記錄量變大。這可能會導致交易記錄檔大小的問題。更糟的是，一旦事件失敗，就會遺失未傳送的交易記錄檔 — 因此未傳送的交易記錄檔越多，就越可能在修復情況下遺失資料。
每一種案例的差異甚大，而且我在真正的實際執行環境中看過一些有趣的例子。比方說，我就看過一個含有 150 個資料庫的環境，每一個資料庫的活動量都很低，而且不見得都在同時間發生。在這種情況下，即使 150 個資料庫全部鏡像都沒有問題。
相反地，我也看過一個只含三個負載很重的資料庫，卻沒有良好網路連線的設定。在這種情況下，可能連一個資料庫都無法鏡像，因為網路頻寬不足會降低工作負載。
成功的關鍵在於，先計算產生的記錄檔。如果可用的網路頻寬看來足以支援您要鏡像的資料庫數量，應該就不成問題。請在實際執行設定之前先行測試，並且務必包含所有可能產生交易記錄檔的作業 — 尤其是您可能進行的任何資料庫維護作業。

Paul S. Randal 是 SQLskills.com 的常務董事，同時也是 SQL Server MVP。他在 1999 年 2007 年間服務於 Microsoft 的 SQL Server 儲存引擎 (SQL Server Storage Engine) 小組。Paul 曾為 SQL Server 2005 撰寫過 DBCC CHECKDB/repair，並且在 SQL Server 2008 開發期間負責核心儲存引擎。身為嚴重損壞修復、高可用性和資料庫維護方面的專家，Paul 也經常在研討會上發表演說。他的部落格位於 SQLskills.com/blogs/paul。


公用程式焦點 Windows Vista Upgrade Advisor
Lance Whitney

該是 著手將貴公司升級到 Windows Vista® 的時候了。就像進行任何升級作業一樣，您有許多問題要面對。您的網路用戶端符合硬體和軟體需求嗎？您要應付哪些相容性問題呢？Microsoft 提供免費的 Windows Vista Upgrade Advisor，幫助您回答這些 (還有其他) 問題。這個公用程式會掃描電腦上所有安裝的硬體和軟體，判斷升級是否可行。如果可行的話，Advisor 會推薦最佳的 Windows Vista 版本，並且在升級之前先告知您所有的問題。
Upgrade Advisor 通常會花幾分鐘的時間進行掃描。在執行掃描時，畫面會出現一個圖表，列出不同版本的 Windows Vista，並且比較每一種版本的功能。您也可以選取一個特定的版本 (旗鑑版、家用進階版、企業版或家用入門版)，檢視它所列出的幾項出色功能，以及它對這些功能的簡短描述。掃描完畢之後，[報告詳細資料] 畫面會告訴您，您的電腦是否與 Windows Vista 相容，並且建議您安裝其中一個適合的版本。詳細資料包括：
系統需求 它會告訴您，您的硬體配備 (CPU、RAM、視訊記憶體和 CD/DVD 磁碟機) 是否充足。如果不夠充足，詳細資料會告訴您哪一部分還需要升級，例如，還需要增加多少記憶體。
裝置 它會檢查所有的外部裝置和驅動程式，包括數據機、印表機、掃描器、音效卡、監視器和視訊卡。如果其中一個裝置沒有通過相容性測試，報告就會解釋您要採取什麼行動，例如，從製造商的網站下載最新版的驅動程式，並且附上該網站的連結方便您參考。
Upgrade Advisor 會報告已知的相容性問題，並且建議幾種解決方案。
Upgrade Advisor 會報告已知的相容性問題，並且建議幾種解決方案。 (按一下影像可放大檢視)
程式 它會分析安裝的軟體，讓您知道哪些應用程式能夠在 Windows Vista 執行，哪些應用程式不相容，或者哪些程式需要升級才能通過測試。
如果有任何元件無法在功能較強大的 Windows Vista 版本 (例如旗鑑版) 當中通過相容性測試，您可以回到簡介畫面選取另一個版本 (例如企業版)，這時候您就會看到電腦是否符合該版本所有的需求。
最後，[工作清單] 會描述您的電腦硬體設定，並且列舉您在安裝 Windows Vista 前後需要完成的工作。它會摘要列出前幾個畫面的項目，並且另外提供其他建議，如螢幕擷取畫面所示。您可以列印工作清單，也可以將它儲存為 HTML 檔。
Upgrade Advisor 可在 32 位元的 Windows Vista 或 Windows® XP Service Pack 2 執行，並且必須安裝 Microsoft® .NET Framework 2.0 和 MSXML 6.0。如需其他詳細資訊，以及下載該工具，只要瀏覽 microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx 即可。

Lance Whitney 身兼 IT 顧問、培訓講師和技術文件作家。他投入許多時間改良 Windows 工作站與伺服器。記者出身的 Lance 在 15 年前一頭栽進了 IT 產業。


Sharepoint 內幕 分散網站管理
Pav Cherny

下載本文程式碼: SharePoint2008_06.exe (1160KB)

Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 支援富有彈性的系統管理與安全性模型，可讓 IT 組織集中化控制基礎架構元件 (例如網頁伺服器和資料庫伺服器)，同時將裝載的
網站集合和網站控制分散化。集中化 SharePoint® 基礎結構有助於減少維護成本、統合商務邏輯、提供 SharePoint 資源的單一存取點，還可避免無謂的技術投資。
同時，分散化網站系統管理可讓您確保個別部門保有該部門中 SharePoint 網站集合、網站、文件庫、工作流程方案和其他 SharePoint 資源的自主控制。不過，將網站管理委派給個別部門有一個副作用，就是會增加 IT 部門的維護難度。比方說，如果您無法存取環境內的網站集合與網站，您要如何追蹤資源使用狀況、過期的 SharePoint 網站和集中式基礎結構中的過時內容呢？
在本文中，我將討論 WSS 3.0 的安全性模型，包括將 SharePoint 網站的系統管理控制委派給個別部門，同時保持 SharePoint 基礎架構的集中式系統管理控制的作法有什麼好處及影響。我會說明委派的網站系統管理如何運作；網站、清單和項目層級的存取權限與安全性調整如何協助維護既安全又容易使用的工作環境；以及 Web 伺服陣列系統管理員如何在不提高 SharePoint 權限的情況下存取必要的網站統計資料。
如果您要在測試實驗室中參照本文的步驟，請下載本專欄隨附的資料：technetmagazine.com。隨附資料中包括 Windows Server® 2008 架構 Web 伺服陣列的詳細部署指示，這些資料會合理反映一家具有多個部門的公司的生產環境。

SharePoint 基礎架構和網站集合管理
您可以根據單一伺服器部署或 Web 伺服陣列部署來建置 SharePoint 基礎架構。事實上，很多公司兼具上述兩種情況。單一伺服器部署適用於個別部門，它們需要的是直接快速的共同作業解決方案。效能和可靠性需求最低。當部門的 SharePoint 伺服器 (通常部署在工作站硬體上) 無法使用時，使用者比較容易諒解，因為部門本身要負起系統維護責任，而該部門內的使用者畢竟並非 IT 系統管理員。
如果是由 IT 部門維護伺服器資源，情勢便會丕變。效能和可靠性成為關鍵因素，常常需要部署高可用性解決方案以確實遵循服務等級協定 (SLA)。負載平衡的 Web 伺服陣列部署、SQL Server® 容錯移轉叢集以及儲存在存放區域網路 (SAN) 的資料庫都有助於滿足貴公司的效能與高可用性需求。請參閱 [圖 1] 提供的架構圖例。
[圖 1] SharePoint 基礎結構搭配 SQL Server 容錯移轉叢集和 SAN
[圖 1] SharePoint 基礎結構搭配 SQL Server 容錯移轉叢集和 SAN (按一下影像可放大檢視)
如 [圖 1] 所示，在集中式 SharePoint 基礎結構中，多種類型的系統管理員必須相互合作來維護資源，但是這些系統管理員會從不同的角度檢視環境。舉例而言，網站集合管理員不會看到基礎架構中的伺服器。網站集合管理員使用標準 SharePoint 使用者介面進行工作。無論您是在辦公室或資料中心的 Web 伺服陣列中將網站裝載在執行 WSS 3.0 的電腦上，這個介面都不變。
資料庫管理員和 SAN 儲存體工程師也不會看到 SharePoint 基礎架構。對這些系統管理員來說，SharePoint 資料庫與其他 SQL Server 資料庫沒什麼兩樣，而且 SQL Server 容錯移轉叢集的邏輯單位編號 (LUN) 與其他 LUN 也並無不同。Web 伺服陣列管理員是與 SharePoint 基礎架構最直接相關的系統管理員，不過此系統管理員並不能控制網站集合、資料庫或 LUN。
我們可以這麼說，部門網站集合管理員通常都不曉得基礎架構的詳細資料。畢竟，在部門中佈建網站和委派存取權限給小組及群組並不需要知道這些細節。建立新網站和開始協同合作的程序很簡單，而與 SAN 技術相關聯的高儲存成本等問題很少會浮現腦海中。
每個專案與計劃都會碰到出現新小組網站、過期網站滯留、過時內容未刪除，以及 SharePoint 環境飛快的增長，直到範圍大到系統管理員無法再漠視為止的情況。舉例來說，在 2006 年 Microsoft IT 發起簡化計劃之前，Microsoft 內部 SharePoint 環境曾經包含超過 180,000 個網站。
為網站集合管理員灌輸相關知識將有助於控制集中式 SharePoint 基礎結構中的情況。套用網站集合配額和鎖定也很有用，但是這些方法在處理過時的小組網站及浪費寶貴存放空間與備份資源的內容時成效不彰。
過時內容不一定會使得網站集合超過配額。當然，您可以設定 SharePoint 傳送電子郵件通知給網站集合擁有人，並在指定期間後自動刪除未使用的網站集合，方法是使用 SharePoint 3.0 管理中心網站的「網站使用確認與刪除」功能，但是這項功能無法用於個別網站層級。網站集合可能包含當前的網站和過時的網站，但是「網站使用確認與刪除」功能無法依照這種細分程度來運作。
稍後我將示範如何透過檢查文件和清單項目的上次修改日期來識別未使用的網站和過時的內容，即使沒有網站集合的存取權限也無妨。這項報告功能並非直接提供，但還好實作方法並不困難。

SharePoint 網站管理分散化
委派 SharePoint 網站管理權限很單純。藉由使用 SharePoint 3.0 管理中心網站、命令列工具 Stsadm.exe 或自訂佈建工具，您可以在基礎結構中建立 Web 應用程式、管理路徑和網站集合。身為 Web 伺服陣列管理員，您可以在建立網站集合時指定主要和次要網站集合管理員。這些網站集合管理員可以是一般的網域使用者。他們不需要 Web 伺服陣列或其他基礎結構伺服器上的系統管理權限。這些系統管理員使用他們的網頁瀏覽器直接在 SharePoint 使用者介面中執行網站管理工作。
[圖 2] 顯示委派的網站管理，您可以在隨附資料的工作表中找到逐步指示。在此範例中，Web 伺服陣列管理員為人事部門 (http://sharepoint/hr) 和 IT 部門 (http://sharepoint/it) 佈建個別的網站集合。
[圖 2] 委派的 SharePoint 網站管理
[圖 2] 委派的 SharePoint 網站管理 (按一下影像可放大檢視)
接著，人事部與 IT 系統管理員可以使用 SharePoint 使用者介面的 [網站動作] 功能表中提供的「網站與工作區」功能來建立子層網站，而且可以套用上層的權限，或針對子層網站定義新的系統管理與使用者權限。要注意的是，除非明確設定，否則 Web 伺服陣列管理員無法存取任何上層或子層網站，人事部系統管理員無法存取 IT 網站，而 IT 系統管理員無法存取 HR 網站，雖然所有網站都裝載在相同的 SharePoint 環境中。
網站集合與網站層級的設計需視組織需求而定。在 [圖 2] 範例中，我並未在 http://sharepoint/hr 及 http://sharepoint/it 上建立主網站。換句話說，http://sharepoint 路徑中並沒有網站集合。不過您可以輕鬆地在此路徑中或使用其他管理路徑來建立網站集合，例如 http://sharepoint/sites/hr 和 http://sharepoint/sites/it。
您也可以為人事部或 IT 建立個別的 Web 應用程式，以便建置更直覺化的基礎 URL，例如 http://hr 和 http://it，針對部門佈建一般入口網站，然後使用彙總網頁組件來列出這些主網站中的子層網站資訊。個別網站集合可促進獨立自主的系統管理；有助於限制部門資訊的存取；提供主版頁面、頁面配置、範本、網頁組件和巡覽控制的個別自訂功能；而且可用於將機密資料放置在專屬內容資料庫中，藉此與其他網站集合與內容資料庫區隔。

角色、網站權限和安全性調整
網站集合一旦存在，而且也委派了系統管理權限之後，網站集合管理員就可以開啟上層網站，並使用 [網站動作] 功能表下提供的「網站設定」功能來管理網站集合。其中包括新增 (或移除) 其他具有網站集合中所有網站的完整權限的其他網站集合管理員、建立群組、建立這些群組與角色的關聯性，以及新增使用者到這些群組以取得讀取和參與者權限。另外還包含佈建子層群組網站與小組網站的功能。
雖然您可以為個別使用者授予 SharePoint 權限，但最好還是根據特定角色建立 SharePoint 群組。譬如說，SharePoint 包含可用於「訪客」、「參與者」和「擁有人」等角色的三種預設群組。訪客具有唯讀存取權限；參與者可以新增項目到清單和文件庫中，也可以將網頁個人化；至於擁有人則具有完整控制權。
有一項值得一提的功能，就是 SharePoint 會根據使用者角色執行安全性調整，這表示使用者在使用者介面中看到的連結和項目，僅限於他們實際上有權存取的連結和項目。若您不允許使用者存取某項資源，例如清單 (方法是在 [清單設定] 中設定明確權限)，或選取清單項目 (方法是使用項目的內容功能表中的「管理權限」命令)，那麼該使用者就看不到清單或項目。如果使用者在瀏覽器中直接指定項目的 URL，使用者就會看到「錯誤：拒絕存取」頁面。
[圖 3] 顯示安全性調整的運作情況。人事部系統管理員具有完整權限，而且能夠使用 [網站動作] 功能表來執行系統管理工作。另一方面，人事部訪客只有網站集合的唯讀權限，而且看不到這個功能表。
[圖 3] SharePoint 介面中根據使用者角色的安全性調整
[圖 3] SharePoint 介面中根據使用者角色的安全性調整 (按一下影像可放大檢視)
安全性調整很實用，因為它會隱藏無法存取的功能、連結及項目，但這也表示 Web 伺服陣列管理員若缺乏存取權限，就無法使用 SharePoint 使用者介面來列出網站和網站資源。您將無法在網頁或網頁組件中看到這些資源。不僅如此，無法存取的資源也不會顯示在搜尋結果中，因為 SharePoint 企業版搜尋會根據提交查詢的使用者身份來執行安全性調整。

那命令列呢？
如果圖形化使用者介面無法在不提高網站集合層級權限的情況下提供管道存取所需資訊，也許命令列工具 Stsadm.exe 能提供解決方案。例如，您可能認為您可以使用命令
Stsadm -o enumsites -url http://sharepoint
來列出 http://sharepoint Web 應用程式內的所有網站集合與擁有人。接著您應該可以使用下列命令來列出所有子網站：
Stsadm -o enumsubwebs -url <site collection>
但是，在 Web 伺服陣列環境中，Stsadm.exe 的回應往往是錯誤訊息，指出該資料庫存取權限已遺失。即使您是 Web 伺服陣列管理員，而且可以管理 SharePoint 3.0 管理中心，但 Stsadm.exe 還是無法列舉網站集合。如果您在缺乏 SQL Server 存取權限的情況下在 Web 伺服陣列上使用 Stsadm.exe，就會收到下列錯誤訊息：
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="無法開啟登入所要求的資料庫 &quot;WSS_Content&quot;。登入失敗。&#xD;&#xA;使用者 'CONTOSO\SPAdmin' 的登入失敗。">
<Site Error="無法開啟登入所要求的資料庫 &quot;WSS_Content&quot;。登入失敗。&#xD;&#xA;使用者 'CONTOSO\SPAdmin' 的登入失敗。"/>
Web 伺服陣列管理員會收到此錯誤訊息的原因是，Stsadm.exe 是在已登入使用者 (例如 CONTOSO\SPAdmin) 的環境中執行，而 SharePoint 3.0 管理中心網站是在與 SharePoint 管理中心 v3 應用程式集區相關聯的系統帳戶 (CONTOSO\WssConfigAdmin) 的環境中存取 SharePoint 資料庫。雖然授予您的 SQL Server 中的內容資料庫的帳戶 db_owner 權限可讓您執行 Stsadm -o enumsites -url http://sharepoint 命令，但您還是無法列舉網站集合內的子層網站。命令 Stsadm -o enumsubwebs -url <site collection> 傳回「拒絕存取」(HRESULT:0x80070005 (E_ACCESSDENIED) 發生例外狀況)，您又得重新開始。不過，有一個更好更妥當的方法，也無須提高 SQL Server 權限。

內容資料庫中的網站資訊
如果您無法經由標準的 SharePoint 介面與工具取得所需資訊，就必須直接到 SharePoint 內容資料庫。不過先要提醒您 — 這是最後的手段！內容資料庫依靠專屬結構描述和資料庫結構，而 Microsoft 只在 WSS 3.0 SDK 中記錄一部份的專屬結構描述和資料庫結構，其用意是勸阻客戶直接使用資料庫。可能的話，您應該使用 SharePoint 使用者介面、命令列工具、物件模型或 Web 服務來存取想要的資訊。
如果您沒有其他選擇，必須直接使用資料庫，您至少要將解決方案限制為唯讀存取。修改資料庫結構描述或資料庫結構的作法並沒有受到支援，這麼做可能會導致嚴重問題，使得您必須從備份還原網站集合或重新安裝 SharePoint Web 伺服陣列。
實作報告解決方案來直接存取內容資料庫還有一個可能的替代方案，就是將 Web 伺服陣列管理員帳戶指定為網站集合設定中的次要擁有人。Web 伺服陣列管理員可以在 SharePoint 3.0 管理中心網站中執行這個步驟。您可以在 [應用程式管理] 網頁上的 [SharePoint 網站管理] 下，找到對應的「網站集合管理員」連結。
身為次要網站集合管理員，您可以在網頁瀏覽器中開啟網站集合，顯示 [網站設定]，然後按一下 [網站管理] 下的「網站流量報告」連結，前提是您已經在 SharePoint 3.0 管理中心內啟用 [流量分析處理]。如果您要追蹤 SharePoint 伺服器上的記錄檔案中的流量資料，請參考 [作業] 頁面的 [記錄與報告]。「網站流量報告」功能在預設的情況下是停用的。
但是，如果環境中有大量網站集合或嚴格條件，使您無法授予 Web 伺服陣列管理員必要的權限，那麼針對個別網站集合手動建立網站流量報告就不切實際。更務實的方法是實作直接的 ASP.NET 報告應用程式，以便從內容資料庫列出所有網站集合和網站，同時也列出重要的統計資料，例如項目數量、所有項目的大小總計，以及項目的上次修改日期，如 [圖 4] 所示。
[圖 4] 直接從內容資料庫取得網站統計資料
[圖 4] 直接從內容資料庫取得網站統計資料 (按一下影像可放大檢視)
如果您使用 SharePoint 管理中心 v3 應用程式集區帳戶的身份來執行此應用程式，您無須提高 SQL Server 權限就可以存取內容資料庫。如前所述，管理中心帳戶已經包含必要的 SQL Server 權限。
隨附資料包含了對 SQL 伺服器的內容資料庫使用 SELECT 查詢的簡單報告解決方案，還有在網頁伺服器上逐步部署此解決方案的指示。要注意的是，我並未實作任何安全性檢查。此解決方案會以匿名驗證執行。
管理中心帳戶提供必要的安全性內容來存取內容資料庫，因此無須驗證使用者。針對解決方案的網站，我使用自訂連接埠，透過 Windows Server 2008 的 Windows® 防火牆加以封鎖，因此只有本機使用者可以開啟 Web 應用程式。如此可滿足我的測試環境中的安全性需求，但是在生產環境中，您應該進一步加強安全性，例如啟用 Windows 驗證和針對 ASP.NET 應用程式的虛擬目錄設定限制的存取權限。

結論
SharePoint 提供富有彈性的網站集合和網站管理功能，可讓您集中處理 SharePoint 基礎結構，同時根據貴公司的特定需求分散化網站管理。集中式基礎結構對於任何規模的公司都有幫助，因為整合環境能有效降低成本；促進部門內部和跨部門的資訊共用；提供堅實的基礎來套用專業知識，以堅定的目標維護高安全性、可靠性和延伸性的環境；以及為使用者提供公司網路中網站與 SharePoint 資源的單一存取點。
同時，個別部門和業務單位仍然能控制其 SharePoint 資源。Web 伺服陣列管理員可以指定網站集合管理員，此網站集合管理員接著會在責任範圍內執行網站管理工作，而不需要 IT 部門介入。
但是，將控制權移轉給部門的同時，Web 伺服陣列管理員也喪失了使用標準 SharePoint 功能和工具來監視基礎結構中的資源使用情況的能力。對內容資料庫套用配額、傳送電子郵件提醒給網站集合管理員，以及基於報告目的追蹤流量資料，上述這些方法都能協助減緩問題，但是若要有效管理 SharePoint 基礎結構，Web 伺服陣列管理員需要其他工具，才能以唯讀的方式直接從內容資料庫擷取想要的網站中繼資料。
可用的選項包括使用 SQL Server 2005 Reporting Services 或類似的企業層級報告解決方案。就像隨附資料顯示的範例一樣，您也可以使用 SQL Server SELECT 查詢來取得必要資訊。

Pav Cherny 是 IT 專家兼作者，專攻 Microsoft 共同作業與整合通訊技術。他的出版品包括白皮書、產品手冊和探討 IT 營運和系統管理的書籍。同時 Pav 也是專營管理文件與本土化服務之 Biblioso Corporation 的總裁。


Windows PowerShell 美觀大方
Don Jones

希望指令碼產生美觀的輸出是很正常的，因此經常有人問我有什麼好辦法可以產生像是表格這類的東西。要這麼做其實有好幾種方法，第一步是撰寫指令碼以便把資料 ─ 也就是要格式化顯示的任何資料 ─ 放入名為
$data1、$data2 和 $data3 的變數。接下來就可以開始將資料格式化。

文字之道
網路上
您如果想要快速瀏覽本月 Windows PowerShell 專欄中所探討的方法，請前往 technetmagazine.com/video 看看 Don Jones 如何實際操作這些指令程式。

人們處理這項工作最常見的方法，跟他們處理 VBScript、Perl、KiXtart 或其他文字導向的語言一樣。一開始我可能會先寫出螢幕上的一組欄標題：
Write-Host "ColumnA'tColumnB'tColumnC"
請注意，`t 在 Windows PowerShellTM 中是一個插入定位字元的特殊逸出序列。若要寫出表格中的每一行 — 還記得我的資料是在 $data1、$data2 和 $data3 中 — 我有幾項選擇。其中之一是直接寫入變數，仰賴命令介面自行在雙引號內以它們的內容取代變數：
Write-Host "$data1't$data2't$data3"
另外一種稍微比較吸引人的方法，是利用 –f 運算子來達成同樣的目的。這種方法會將格式與資料相區隔，並形成我個人認為既方便閱讀且更容易維護的一行程式碼：
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
不過，這整套方法卻有個明顯的問題。首先，藉由主控台視窗裡面固定的定位點，我讓自己處於一些奇怪格式中。比方說，假設特定的表格列在第一欄中有 24 個字元的值，我會把該列的整個格式弄亂。另外，因為我是使用 Write-Host 輸出此文字，所以等於只能使用主控台顯示。
如果想要把輸出傳送到檔案或使用其他格式並不容易。最重要的是，這種以文字為基礎的作法會完全忽略我原本使用的以物件為基礎的命令介面，而無法充分運用 Windows PowerShell 所提供的各種超棒技術和功能。

Windows PowerShell 之道
Windows PowerShell 是一種物件導向的命令介面。也就是說，在理想的情況下，您所處理的所有一切內容都應該是在物件中，好讓命令介面在必要時把內容轉換成文字顯示。但是您要怎麼為任意資料建立物件呢？
延續我的範例，我開始先建立一個空白的自訂物件，然後把它存放在變數中：
$obj = New-Object PSObject
這為我提供一個全新的空白物件來處理。我接下來以屬性的形式將資料加入物件中。我是直接將物件輸送到 Add-Member 指令程式進行這個動作。我新增一個叫做 NoteProperty 的東西，為屬性命名 (使用欄標題作為屬性名稱是個不錯的主意)，然後將資料插入作為屬性的值：
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
現在我只要將這個物件輸出 — 到管線，而不是到主控台就行了：
Write-Output $obj
我接著可以針對每個需要輸出的表格列重複這些步驟。下面是一個簡短的函式，它會接受一個字串並隨同原始的字串輸出大小寫的版本：
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
我先從字串變數陣列下手，然後一次處理一個字串變數，再把它們傳送到函式。接著函式的輸出會寫入管線中。
您應該曉得，寫這段程式碼有比較簡單的方式，但我選擇這種方法是因為它可清楚的表達我的重點。結果如 [圖 1] 所示，是格式完美的表格。這是因為命令介面早已知道如何格式化表格中的物件。
[圖 1] 顯示在表格中的 Windows PowerShell 輸出
[圖 1] 顯示在表格中的 Windows PowerShell 輸出 (按一下影像可放大檢視)
每當物件有四個以下的屬性時，Windows PowerShell 都會自動選擇表格。所以現在我不用動手就可以擁有一個雅致的表格了。

等等，還不止這些呢！
本月指令程式：Get-Command
我相信您已用過 Get-Command 或是它好記的別名 (gcm) 一兩次來檢閱可用的 Windows PowerShell 指令程式清單。但是您可能不知道 gcm 到底有多靈活。比方說，假如您想要查看 Windows PowerShell 對某服務可以進行的所有動作，就可以執行 gcm -noun service。或者，若是您想要查看所有的 Windows PowerShell 匯出選項，可以試試 gcm -verb export。如果您只是要查看某特定嵌入式管理單元所加入的指令程式，例如 PowerShell Community Extensions，可以試試 gcm -pssnapin pscx (您可以使用任何嵌入式管理單元來取代「pscx」，查看該嵌入式管理單元的指令程式)。
正如您所見，Get-Command 在探索 Windows PowerShell 上可說是扮演著舉足輕重的角色。您甚至不用查閱手冊，它就可以讓您確知哪項功能可用。而且就探索功能來說，gcm 要比使用像是 Help * 等命令更正確的多。Help 功能只會列出可用的說明主題。任何未隨說明檔發行的指令程式並不會顯示在說明清單中 — 即使指令程式在您需要時可供使用也一樣。

這種方法的好處不只是提供表格而已。當您處理物件時，Windows PowerShell 還知道如何處理一大堆事情。想要將資料放在 CSV 檔案中？就用 Export-CSV。偏好使用 HTML 表格嗎？不妨把物件輸送到 ConvertTo-HTML。需要清單格式嗎？把它們輸送到 Format-List 就搞定了。透過使用物件，您可以利用命令介面早知道要怎麼處理的各種事項。以下是一個修改過的範例：
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
這次我把函式修改成接受管線輸入 — 這在處理物件時，向來是比較好的辦法 — 然後輸出到管線。
這個函式現在在 PROCESS 指令碼區塊內有自己的程式碼。這表示函式會接受管線輸入，而且會針對每個從管線送入的物件執行一次 PROCESS 指令碼區塊。
在 PROCESS 指令碼區塊內，特殊的 $_ 變數指的是目前正在處理的管線物件。這個動作產生的實際結果是，我現在可以直接輸入字串陣列：
@("one","two","three") | StringVersions
因為函式將它的輸出放到管線中，所以我得到一個表格。在管線的尾端，命令介面知道要呼叫它的格式化子系統，這個子系統決定使用表格，因為管線內的物件具有少於五個的屬性 (如果有更多屬性，命令介面預設會使用清單)。
但我不用仰賴預設的行為。我只要將這些物件輸送到另一個指令程式，完成其他作業就大功告成了：
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
[圖 2] 顯示第二個範例在網頁瀏覽器中顯示所得的 HTML。只要將我的輸出資料呈現在物件中，而不是以簡單文字呈現，我馬上就能夠完整存取命令介面內建的豐富功能 — 各種格式化配置、HTML 轉換、匯出選項，還可以排序、篩選和群組等。
[圖 2] HTML 格式的 Windows PowerShell 資料輸出
[圖 2] HTML 格式的 Windows PowerShell 資料輸出 (按一下影像可放大檢視)
這項功能威力無窮，事實上，我甚至會建議您所寫的每個指令碼都應該產生物件作為它的輸出，這樣一來，您就可以盡可能透過許多不同的方法來使用該項輸出 — 而且連多寫一行程式碼都不必。

Don Jones 是 Windows 系統管理自動化方面的專家，並且著有《Windows PowerShell:TFM》和《VBScript, WMI, and ADSI Unleashed》等書。您可以透過 ScriptingAnswers.com 上的論壇與他聯絡。


嗨，Scripting Guy！ 不太辛苦的工作照樣也有回報
The Microsoft Scripting Guys

下載本文程式碼: HeyScriptingGuy2008_06.exe (150KB)

數百年來， 人們總是相信辛勤工作本身就是一種回報；經過一日的努力勞動就會獲得真正的滿足：而幸福真諦來自目的地而非過程；還有 — 算了，您能夠意會就好。任勞任怨的幹活 (就像灰姑娘一樣)，那麼總有一天您會獲得回報。
備註：這是真的嗎，辛苦耕耘不但讓您更快樂，而且總有一天會獲得回報嗎？為什麼要問我們這種問題？
當然，灰姑娘很幸運；畢竟，如果您跟邪惡的繼母和兩個壞心眼的姐姐一起住，就不愁沒有辛勤工作的機會了。但是，萬一您不像她這麼幸運呢？萬一您不是跟邪惡的繼母和兩個壞心眼的姐姐一起住怎麼辦？您要如何經歷漫長、精疲力盡又吃力不討好的工作日呢？您該如何尋覓幸福真諦？
如果您下定決心要拼死拼活的工作，那麼 Scripting Guy 建議您試著撰寫指令碼，以精緻、簡潔的表格格式輸出資料，如同 [圖 1] 的輸出所示。
[圖 1] 表格式輸出
[圖 1] 表格式輸出 (按一下影像可放大檢視)
就像我們說過的，灰姑娘實在太幸運了：她必須把房子打掃的一塵不染，工作結束後，還得要坐在充滿灰燼和煤煙的壁爐中。但是一說到要撰寫以表格格式顯示資料的指令碼，即使是灰姑娘也會知難而退。坐在灰燼和煤煙中是一件事；撰寫以表格格式輸出資料的指令碼又是另一回事。
備註：喔，除非您必須坐在壁爐裡撰寫指令碼；若是如此，那就差不多一樣了。
為何這項工作會讓灰姑娘心生膽怯？因為它難斃了。要在 VBScript 中使用表格格式顯示資料只有一個辦法，就是運用下列幾行：
  • 首先是確定每一欄的最大值。比方說，您可能希望服務的顯示名稱最多可填入 52 個字元。
  • 如此一來，您要計算資料片段的字元數。例如，顯示名稱 Adobe LM Service 有 16 個字元。
  • 如果顯示名稱超過 52 個字元的限制，確定必須從字串結尾砍斷的字元數，好讓顯示名稱能放入所分配的空間中。如果顯示名稱少於 52 個字元，確定必須加入字串結尾的空格數，好讓長度剛好等於 52 個字元。
  • 對下一組資料重複執行相同的動作。再下一個也是，然後依此類推。
如果您很熟悉灰姑娘的故事，那麼您應該知道神仙教母可能會突然現身，把老鼠變成系統管理員 (至於這個戲法有多容易，我們就不予置評了)，然後那隻老鼠就會替您撰寫這個指令碼。不過，您大概不應該奢望會發生這種奇蹟。關於這件苦差事，您只能全靠自己了。
不過往好的方面想，您將是全世界最歡喜的人了。因為您同時也將是全世界最辛苦工作的人。至今還沒有其他工作比它更艱困。
當然，有些人可能願意拿一點點快樂來交換不必那麼辛苦工作的機會。若您也是其中之一，您可能會想：「感謝老天，我們有 Scripting Guy；他們會教我如何將老鼠變成系統管理員，然後教我如何讓老鼠將我的輸出格式化成表格」。可惜，恐怕我們要告訴您一個壞消息：Scripting Guy 不曉得如何將老鼠變成系統管理員 (不過我們可以將系統管理員變成老鼠，如果這樣對您有幫助的話)。我們不知道如何讓別人幫您寫指令碼，更別說是撰寫指令碼來使用表格格式顯示輸出資料了。
可是沒關係，只要您是執行 Windows® XP 或 Windows Server® 2003 (很多人都是)，您就不需要老鼠來為您撰寫指令碼 (抱歉了，Windows Vista® 恐怕並不適用)。您可以自己完成這項工作，而且不用多花多少力氣，這都要感謝 Microsoft.CmdLib 物件。請看一下 [圖 2] 中的範例指令碼。
Figure 2 建立表格式顯示
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
稍微解釋一下，Microsoft.CmdLib 是 Windows XP 和 Windows Server 2003 隨附的 COM 物件。這個物件有幾項不同的功能；如需詳細資訊，請在命令提示字元中輸入 cmdlib.wsc /?，並閱讀螢幕上所顯示的指令碼檔案中的命令。不過今天我們只關心 Microsoft.CmdLib 的一項功能：以表格格式顯示資料的能力。
這顯然會產生一個問題：如何以表格格式顯示資料？讓我們看看能不能找到方法。如您所見，我們的範例指令碼一開始會定義名為 arrResultsArray 的動態陣列：
Dim arrResultsArray()
在典型的指令碼中，資料會在一被擷取時就立即傳回螢幕。但是您怎麼能期望 Scripting Guy 採取這麼平凡的作法？在此指令碼中，我們不會在資料被擷取時立即傳回資料。相反地，我們要將所有傳回的資料儲存在陣列中，然後讓 Microsoft.CmdLib 格式化並顯示資料。
換句話說，這也是為什麼一開始要建立動態陣列 (也就是可以在指令碼的執行過程中調整大小的陣列) 的原因。定義陣列之後，我們將名為 i 的計數器變數值設為 0；我們將使用這個值來追蹤目前的陣列大小。
如果您想知道，我們將 i 值設為 0 的原因是，陣列中的第一個項目永遠是指定為索引編號 0。因此，將第一個項目新增到陣列時，所新增的是項目 0 而非項目 1。
接下來我們必須初始化 Microsoft.CmdLib 物件的執行個體；以下兩行程式碼就是負責這項工作：
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
接著就到下面這一小段程式碼區塊：
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
在此我們要設定幾個參數來設定輸出。在第一行中，我們將值指派到名為 arrHeader 的陣列；您大概已經猜到，這些是輸出表格中各欄的標題。在此範例指令碼中，我們要擷取有關電腦上執行的服務資訊，接著顯示各個服務的 DisplayName、State 及 StartMode 屬性值。
不用說，我們為陣列指派了欄名稱 Display Name、State 和 Start Mode (當然我們也可以將欄名稱簡單指定為 A、B 和 C；Larry、Moe 和 Curly；或是任何我們想使用的名稱。欄名稱不一定要跟屬性名稱一樣)。
備註：灰姑娘的故事有好幾個版本，後母生的姐姐也有不同的名字版本。在迪士尼版本的灰姑娘故事中，兩個姐姐的名字是 Drizzella 和 Anastasia，這剛好也是我們的 Scripting Editor 的名字和中間名！
在第二行程式碼中，我們將值指派給另一個名為 arrMaxLength 的陣列。這個陣列將每一欄的大小存放在表格中。在我們的輸出中，我們要配置 52 個字元空間到欄 1 (服務顯示名稱)；接著我們要分別配置 12 個空格到服務狀態和啟動模式中 (Microsoft.CmdLib 會自動在各欄之間插入空格)。如果我們希望欄大小是 52、12，還有 12 個字元空間 (實際上也是如此)，便要使用如下所示的程式碼：
arrMaxLength = Array(52, 12, 12)
第三行指定資料的輸出格式。我們想要將資料顯示成表格；因此將 strFormat (存放輸出類型的變數) 的值設為 Table。假設我們是要將資料顯示成以逗號分隔的值清單。此時，我們要將格式設為 CSV，如下所示：
strFormat = "CSV"
如此一來，會得到類似下面的輸出結果：
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
要注意的是，Microsoft.CmdLib 不僅在每個項目之間插入逗號，而且還將各個值以雙引號括住。這個功能比您一開始想的還棒。畢竟，在手動執行的情況下，您必須使用如下的程式碼：
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
真討厭。
您說什麼？您不喜歡表格，也不喜歡 CSV 格式？如果是這樣的話，不妨試著將格式設為 List，您會得到類似下面的輸出：
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
不過這已經離題了 (我們有時容易離題)。定義輸出格式之後，我們將名為 blnPrintHeader 的變數值設為 True：
blnPrintHeader = True
我們要使用 blnPrintHeader 來告訴 Microsoft.CmdLib 列印欄標題。如果我們不想列印欄標題呢？沒關係；在這種情況下，將 blnPrintHeader 設為 False：
blnPrintHeader = False
最後是以下這行程式碼：
arrBlnHide = Array(False, False, False)
要顯示資料時，Microsoft.CmdLib 可讓您選擇顯示或隱藏欄。若要隱藏欄 (也就是隱藏特定屬性的資料)，請將該屬性值設為 True；若要顯示欄，請將值設為 False。
在我們的輸出中，我們要依序顯示 DisplayName、State 和 StartMode 屬性的值；因此陣列中使用的值分別是 False、False、False。萬一我們要顯示 DisplayName、隱藏 State，並顯示 StartMode 呢？若是這樣，我們要使用下列這行程式碼：
arrBlnHide = Array(False, True, False)
請記住，使用 False 會顯示欄，True 則是隱藏欄。
此時，我們已經準備好輸出一些資料 — 如果真的有資料的話，就會是這樣 (Scripting Guy 可曾撰寫無法輸出資料的指令碼，然後花費過多時間來偵錯該指令碼，結果卻發現一開始根本不必費事擷取任何資料？呃，當然沒有這種事；您怎麼會這麼想？)
知道這一點之後，我們的下一步是繫結到本機電腦上的 Windows Management Instrumentation (WMI) 服務，然後使用 ExecQuery 方法來擷取關於該電腦上安裝的所有服務資訊：
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
我們應該要澄清一點，在此您不止能使用 WMI 資料。也許您已經猜到，Microsoft.CmdLib 適用於任何資料類型。WMI 只是方便我們擷取一堆資料的手段。
收到服務相關資料集合之後，我們要設定 For Each 迴圈，對集合中的所有服務重複執行同樣的動作。不過，在此並非傳回每個服務的屬性值，而是要執行下列程式碼：
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
這個程式碼區塊的功用到底是什麼？在第 1 行中，我們要調整陣列大小，所使用的命令 ReDim Preserve 不僅能調整陣列大小，還可以保留該陣列中現有的資料 (若少了 Preserve 關鍵字，雖然能調整陣列大小，但是該陣列中現存的資料全都會刪除清除)。
我們要將陣列調整成什麼大小？第一次執行迴圈時，我們要讓陣列大小變成 0；換言之，我們要建立包含一個項目的陣列。那麼我們如何確知已經將陣列大小變成 0 了呢？因為我們使用了計數器變數 i，而且該變數等於 0。
因此，如果我們使用變數 i 來代表陣列大小，不就表示我們永遠會將大小設為 0 嗎？的確如此，只不過每執行一次迴圈，我們將會將 i 值加 1；如您所見，我們在程式碼區塊的第 3 行就是這麼做。
現在就剩下一行程式碼要操心了：
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
在此我們只是取得感興趣的屬性值 — DisplayName、State 和 StartMode — 然後將它們新增到陣列 arrResultsArray 中。請注意，我們不會個別新增屬性值；而是以值陣列的方式加入。的確，這有點不尋常：意思是陣列 arrResultsArray 中的每個項目都是另一個陣列；而這正是 Microsoft.CmdLib 運作的方式。
當然，您可能又要擔心了。「陣列的陣列？我到底要怎麼做才能在充滿陣列的陣列中存取所有個別值？」別慌張，其實很簡單：讓 Microsoft.CmdLib 幫您做就行了。
備註：很抱歉，不過存取陣列的陣列中的所有個別值大概是 Microsoft.CmdLib 唯一能為您做的事。可是下一版物件可能會考慮加入打掃壞後母的房間、洗碗，還有幫討厭的姐姐縫衣服等功能。
事實是，我們只要呼叫 ShowResults 方法，然後將之前在指令碼中設定的所有陣列及變數都傳送到此方法，就可以使用簡潔的表格格式輸出資料：
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
然後會產生什麼結果呢？結果就是我們所要的正確格式化輸出，如 [圖 1] 所示。
不賴吧？您現在有了美觀的輸出，而且幾乎不費吹灰之力 (您的下一個指令碼甚至更簡單，因為您只需要對此處的第一個指令碼做一點小更動)。
當然，您不像灰姑娘那樣日夜操勞，才能使用表格顯示指令碼輸出，所以您也無法享受像灰姑娘一樣的滿足感。而且老實說，您大概也不可能嫁給王子；這並非本文的用意。不過，為了從 VBScript 指令碼獲得這麼棒的輸出，付出一點小代價也是值得的，尤其是一想到當今王子的水準。
而且誰曉得：或許您自己也能找到一位王子也說不定。畢竟，就連皇室成員也需要了解他們電腦上安裝的所有服務資訊，不是嗎？

Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
這個每月一次的挑戰不僅測試您的解謎功力，更要測試您的指令碼技巧。

2008 年 6 月PowerShell 途徑
在這些謎題中，從水平、垂直和對角方向連結字母，藉此構成某 Windows PowerShell 指令程式的名稱。每個字母都只能使用一次。例子如下：
在這個謎題中建構的指令程式是 New-Alias。現在換您了。以下還有三個謎題：

ANSWER:
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：PowerShell Pathway，2008 年 6 月

Read-Host

Set-AuthenticodeSignature

The Microsoft Scripting Guys 為 Microsoft 做事，也就是受雇於 Microsoft。他們在不玩、不教或不看棒球 (以及其他各種活動) 的時候，就負責管理 TechNet 指令碼中心。請造訪他們的網站：http://www.microsoft.com/taiwan/technet/scriptcenter/default.mspx。


桌面檔案 安全性和循規
Wes Miller

身為 IT 專家，您可能會面臨應該互補的目標往往反而相互對抗的窘境。安全性與循規就是兩個這樣的組織目標，達到其中一個目標應該能夠補強另一個目標。可惜，實際情況往往不然。本專欄旨在描述
為何保持安全性並不一定代表會與您所需的計劃相符，以及為何保持循規通常不代表安全性，或至少說明如果循規真的等於安全性，為何您沒有獲得應有的安全性。

安全性並非選擇題
SDL 資源
  • Michael Howard 和 Steve Lipner 所著的《The Security Development Lifecycle》(Microsoft Press，2006 年)
  • 安全性開發生命週期部落格
  • 深入探討 Microsoft 的安全性開發生命週期
  • 資訊安全開發人員中心
  • 高可信度電腦運算安全性開發生命週期

循規通常會涉及外部加諸在組織、產業、公司或產品上的需求 (人事、作業程序、基礎結構、技術等等)。有時循規必須遵守產業內部所公布的標準 (譬如付款卡業資料安全性標準，即 PCI-DSS)。在理想的情況下，這些需求與標準會符合組織現已運作的計劃，至少在某種程度上相符。隨著採用標準日益普及，只要您還想讓企業營運，就無法再忽視它；最後您必須毅然投入，然後盡可能達到最佳效益。
另外一種循規往往比較麻煩。我指的是政府所頒佈的計劃，例如美國健康保險流通與責任法案 (HIPAA) 和沙賓法案，這些計劃在執行上和時間上都沒有您選擇的餘地。
有關遵循法規的重點是，它通常都有一套「由上而下」的方法。一般來說，您會看到用來定義計劃的餅乾壓模式範本，您必須審視您的產品和作業程序，然後設法讓產品和作業程序緊扣交付給您的怪異範本。您不僅要了解循規計劃的用意，更重要的是，若不遵循或無法遵循這些計劃，將有什麼法律或財務方面的後果 (若有的話)。
雖然我們都贊同許多循規計劃的主旨，但付諸執行往往很困難，而且可能不符合所要的目標。而且很遺憾地，這些計劃很多都沒有實質作用 (也就是說，計劃失敗時，並沒有直接的法律或財務後果)。
老實說，身為病患，我沒辦法充分說明 HIPAA 對我的好處是什麼。我只能說，HIPAA 害我去看醫生的時候多了好多文件要填。更糟的是，這些計劃可能產生無心之過。您是否曾試圖將重要的醫療資訊從某位醫生或診所轉交到另一位醫生手上？若無書面授權，無論是多緊急的資訊，怎麼也辦不到。
重點是，從很多角度來說，某些循規計劃變成是選擇題計劃。這表示您設計或修改作業程序或產品完全都是為了遵守循規計劃。就像我經常問我的三歲小孩的一個問題：「這麼做好嗎？」
另一方面，安全性是一種由下而上的計劃 — 前提是執行的方法正確。無論您是設計軟體產品或公司新網路的架構，都要謹記評量兩次而非一次這個關鍵概念。舉例來說，當您設計產品架構，一個完善的草創方案必須界定通訊、當地語系化、版本等等，同時它也應該描述打從一開始就建置在應用程式中的安全性項目 (而且在整個開發過程中您也應該繼續調查和調整這些安全性項目)。
若您是沿用舊有應用程式或架構 (相信大部分人都是)，同樣必須執行我在本專欄中一再強調的深度安全性檢查。如果您不了解事情的來龍去脈，怎麼可能確認安不安全？如需 Microsoft® 安全性開發生命週期 (SDL) 的詳細資訊，請參閱資訊看板「SDL 資源」。

顧全大局
我還記得早期被灌輸安全性不只是實作加密、存取控制清單 (ACL) 或 TLS，或公開金鑰基礎結構 (PKI) 而已的觀念。真正的安全性有賴於掌握大局：了解某版本的通訊協定為何被刪除或從來不受支援；為何新的配置能夠阻止攔截式攻擊；您的第二版產品為何比第一版安全得多，雖然第一版執行比較快。而且您也必須知道您的基礎結構的各部組件如何彼此搭配運作。
另一方面，循規表示運用您的技術並確保所建置的基礎結構符合特定條件。有些計劃，例如付款卡業資料安全性標準 (PCI-DSS) 或北美電力可靠度委員會 (North American Electric Reliability Council，NERC)，都是立意良善而且可以促進真正的安全性改革。但是到頭來 — 您必須根據這些「循規計劃」什錦拼盤來調配您自己的特定專案以及有限的可用資源，因而妥協安全性計劃。
安全性向來不受軟體開發青睞。很多人一定曾在公司中碰過安全性問題「晚點再處理」的情況。循規計劃之所以會存在，就是因為這種風氣 — 安全性不用急著處理 — 行不通，而且向來如此。

綽綽有餘
我最近換了個工作。我目前任職於德州奧斯汀的一家新創公司，這家公司專門建置應用程式安全清單技術，這項技術有點類似我們使用 Winternals 的 Protection Manager 產品所建置的技術。我特別喜歡跟客戶討論一件事，就是客戶覺得自己目前的技術有多安全 — 更明確的說，客戶認為他們所採用的技術組合能夠保障多少基礎結構的安全性。雖然這些技術大多很安全而且不會敞開安全性漏洞的大門，但是有一句我常聽到的評論讓我有點愕然，就是系統「已經夠安全了」。
循規計劃很奇妙 — 要就遵守，不然就不遵守。責任完全在您，不遵守計劃的代價通常是罰金、刑罰或從組織中剔除。但通常並不足以確保真的會有什麼改變。
如果是政府明訂的計劃，我常會碰到一種態度：「只要夠應付稽核員就行了」，或是寧願不要將循規架構付諸執行，因為相關法規 (例如 HIPAA) 並未充分援助強制執行 — 也就是說，不投保就上路，以後再面對可能的後果，這麼做的成本低多了。
安全性也常碰到相同的障礙，不過我覺得至少它比較具體。若身為開發人員或執行者的您先主動告知主管：省略規格中的區段 foo 將使得產品遭受攻擊的機率大幅提高，至少在產品出貨或部署完成後，您可以理直氣壯的說：「我早說過了」。我在處理循規計劃的經驗是，計劃的執行往往是急就章，而且預算少得可憐。目標純粹是符合計劃所要求的最低標準 — 因此我想可能只能滿足計劃的表面字義而非內在精神。

決定您的定位
安全性和循規資源
  • 安全性和循規解決方案指引
  • 安全性指引
  • 付款卡業資料安全性標準循規規劃指南
  • 法規遵循和安全性更新
  • 達成循規
  • 人權辦公室 — HIPAA
  • PCI 安全標準委員會
  • 北美電力可靠度委員會

如果我說您應該要盡可能確保產品和組織的安全性，聽起來可能太理想化，但實際上大部分的循規計劃的確是因建構不良或更常見的自以為是而發起的折衷方案。很遺憾地，在我們身處的世界中，「綽綽有餘」就只是綽綽有餘而已。但是在安全性的世界中不吃「綽綽有餘」這一套。身為 IT 專案人員的我們可以將循規計劃牢記在心，試著在精神與實務雙方面滿足這些條件，但同時也必須確保我們建置的基礎結構不僅是盡量安全，而是要務必安全。換句話說，藉由真正的安全性來保持循規，而不是單純應付循規計劃。
最重要的是，退一步想想您所建置的技術，它屬於商業軟體的一部份，還是要整合至大型系統的一組技術。我必須一再強調，了解系統的相扣環節、這些環節的搭配運作方式以及系統面臨的重大威脅，這些都很重要。
根據您所處的產業，不同的循規計劃對您的重要性可能不定。您可能會在日常生活中遇到這些循規計劃，或只有在設計新專案或技術時遇到。或者，這些循規計劃也許只有在處理特別指定的循規檢閱或稽核時出現。這些都無所謂。我並不認為應該忽略循規計劃，但我懷疑您敢不敢挑戰現狀，不只把目標放在應付交付給您負責的循規計劃，而是執行完整的安全性檢閱來徹底了解您的技術，然後在執行循規檢閱的同時建立其模型。

有什麼好損失的？
畢竟，不遵守循規計劃的罰則似乎含糊不清。不循規會讓您面臨風險，而循規計劃正是要防範這種情況。其後果雖然看起來很模糊不清或遙不可及，但卻是真實存在的。它們可能也不會對您 (個人) 產生影響。記得要務實，但做好最壞情況的打算。
如果您從嚴格的安全性角度來看同一件事，威脅應該顯而易見 — 而且更重要的是，您應該能夠立即識別出開放安全性漏洞的潛在成本。
我與很多人討論過此主題，他們都強調循規計劃有時曖昧不明 — 因為循規計劃常會留下許多解讀空間。不過，一旦您進行了安全性檢閱，安全性疏忽的情況就並非如此了。受忽略的安全性所產生的立即威脅，應該非常清楚明白。否則，您可能需要重新考慮安全性檢閱的相關人事；您可能缺乏關鍵的小組成員來協助您確認解決方案中的實際問題。

原地打轉
在去年的安全性專題專欄中，我討論過＜如何不遺失資料＞(technet.microsoft.com/magazine/cc162325)。一年過去了，更多系統遭到侵害，更多遺失的未加密膝上型電腦，還有更多個人資料落入可疑者的手中。很難說我們是否達成任何進展。我們為何還在原地打轉？計劃的執行常受到延遲，並且是在激少的預算和過份耗用的資源下試圖以最短的時間提供最多的功能。
可惜，這種環境會導致極度匱乏的最低限度工作變成基準。而這種方式絕對無法確保解決方案的安全性或循規，而且也並非計劃時程或成本的關鍵。
我個人堅信：
  1. 若您無意保障解決方案的安全性，就不應建置它。
  2. 每次新增功能時，您都必須在開始前先設計其中的安全性。
  3. 如果您的組織不願意在工程流程內建置安全性，您應該質疑公司或組織的整體目標為何。
組織所擁有的客戶或合作夥伴個人資料越來越多，而組織有責任保障這些資料的安全性。可惜的是，在我們所處的世界中，並不將安全性視為應有的預設選項，而且員工也無法大膽質疑組織對安全性所做的努力。
當安全性 (非循規) 無法落實時，隨之而來的反應往往是：「該是時候保障系統安全了」，「身份竊盜保險」就成為標準的責任方案來取悅客戶、學生、病患和員工，而這些人的個人資料還有潛在的財務健全都有洩漏之虞。
我們常在太短的時間內被要求太多，獲得的卻太少。但是我們身為 IT 專業人員有責任質疑安全性為何不是主要重點，為何管理階層總是只從循規計劃或安全性失敗，以及實際或可能的法律威脅 (這可能會讓組織蒙羞或面臨風險) 的層面來思考安全性。

接受我的挑戰
最重要的是，我請求您挑戰現狀。如果您被交代要達成循規目標 — 請盡量確保您在這麼做的時候，並非只把時間浪費在滿足別人的安全性概念上。您應該要確認您的目標是保障系統安全性，在此同時，也要定義足夠的程序或基礎結構來達成循規計劃。如需本主題的詳細資訊，請參閱「安全性和循規資源」資訊看板。
總之，循規往往不是尋求安全性的正途。但是只要能正確的實作和調整安全性，通常就能通往循規之道。

Wes Miller 在位於德州奧斯汀的 CoreTrace (www.CoreTrace.com) 擔任資深技術產品經理。他之前任職於 Winternals Software，並且曾在 Microsoft 擔任專案經理一職。您可以透過電子郵件與 Wes 聯絡：technet@getwired.com。


IT 產業 成為環境領導者的 10 大關鍵因素
Michael Walsh and Eliza Walsh

以現今業界來說，似乎沒有一家公司不在談論他們的環境研究計劃。而 IT 在這些研究計劃當中扮演著舉足輕重的角色 — 它提供您絕佳的改革機會，促使您成為公司和業界的實踐先驅。但是，到底該從何處著手改革呢？下面就是有效成為環境和永續方案先驅者的十大關鍵要素。
熟悉問題
首先您必須廣泛並深入探索有關電腦與環境永續的專業知識。身為一位 IT 專家，您應該先從減少電腦對環境所產生的影響開始著手，例如電源管理、硬體整併，以及環境廢棄物管理等。
而身兼一位環境領導者，您也必須設法借助各種軟體和硬體，來減少非 IT 部門運作所產生的影響。於是這麼一來，就必須與律師、人力資源經理和企業管理者密切合作，共同定義解決公司整體環境影響的原則 — 這些原則也許從商務旅行原則到全球碳足跡規定 (carbon footprint) 皆涵蓋在內。
另一方面，公司內外人員也無不殷切期待您針對環境、公司以及貴公司營運的業界開發專門技術。因此，您必須審核自己對於環境永續、永續電腦，以及貴公司在短期和長期需求方面的瞭解。
如果您是剛剛進入新公司，或是剛剛轉任新職務，勢必背負著無形和有形的壓力，驅策您快速進入情況。如果這家公司過去未曾針對環境尋求定位、而現在卻積極急起直追的話，您的壓力就更大了。
但是，如果因此隨著壓力起舞，很可能會危及您和公司的信譽。從短期角度來看，建議您還是專注解決當務之急，把傳播策略方案暫時擱在一邊，直到您已經準備妥當，或者等到熱身時段過了再說。

客觀審核貴公司
接下來要做的是慎重審核貴公司或商務營運的環境和永續性。怎麼做呢？就是多方接觸重要關係人，以及其他公司內外的有力人士。
您必須建立一個內部和外部聯絡人的網路，定義重要關係人的生態系統。這些人可以幫助您瞭解貴公司在環境永續性的地位。
您可以根據自己的責任而定，找出貴公司目前和未來在環境規定、標準和法律方面的遵循依據。另外還要評估貴公司在競爭者和分析師心目中的預期地位，並且瞭解客戶、合作夥伴、政府機關以及有影響力的客戶倡導者，對於貴公司及其環境研究計劃的看法。同時還得判斷您的方案在目前和未來有哪些技術、財務與環境方面的限制。
您也可以根據貴公司的規模和預算，尋找其他值得考慮的研究。具有建設性的洞察理解，通常來自內部調查、焦點團體以及協力廠商的研究。它可以幫助您正確瞭解員工對於下列三項的滿意度：過去公司所採取的環境行動、貴公司在競爭市場所佔的地位，以及潛在市場商機所在的地方。但是它最大的潛在價值，卻是協力廠商研究在驗證或駁斥重要關係人意見的能力。

展望目標與時機
接下來就該擬定貴公司的長期和短期目標了。一開始您可以將此二者的目標時間分別設定為一年和五年，然後再配合自己的需求來調整時間長度。不過務必切記的是，環境問題絕對不是短期問題，只把環境問題視為短期問題的人，肯定會替公司、重要關係人、客戶和合作夥伴帶來麻煩。
在決定貴公司的一年期和五年期目標時，必須先決定您在目前和未來所要面對的商業景觀。其中包括公司文化、公司的長短期商業目標、目前和未來的預算限制、銷售點的擴展計劃、以及業界不斷變化的法律和法規環境。
舉個例說，您可以在資料中心找到戰略決策與策略定位兩者衝突的來龍去脈。在過去，空間被視為資料中心設計的主要考量。但是過去幾年來，電源逐漸取代空間成為擴展的限制因素，同時也加重了營運成本。資料中心操作員發現逐漸提升的電源重要性將成為未來長期的隱憂，因此他們開始採取行動來減輕能源不足的危機，其中包括資料中心管理的根本轉移，而這一點卻與主流空間驅動決策因素互相矛盾。在某些情況下，減少耗電量所花費的投資，佔了絕大部分的短期成本，相較之下，維護現有原型的成本就少得多了。但是隨著能源價格大幅上漲，幾年前積極改變資料中心管理方針的資料中心操作員，現在已被視為具有真知遠見的人，而他們公司所獲得的回報，也已經超過最初的投資了。

開發願景和策略
接下來就是開發願景和策略了。當然，您必須先瞭解目前企業所達到的程度，以及未來需要達到的目標。在設定願景和策略時，不應該將它們視為永遠不變的東西。貴公司對環境的承諾也許可以長久不墜，但是您的願景和策略可不一定。它會因為某些內部和外部變數的出現 (例如，法規需求的變化、客戶認知的轉移，以及商務需求的發展) 而被迫修正。同時隨著企業環境方案的掘起，公司也必須參考其他大型公司的願景和策略，來調整自己的 IT 願景和策略。
而設定願景，就等於設定公司的商業走向。您必須仔細斟酌措辭，務求謹慎簡潔、條理明晰，但是又不過於繁雜冗長。撰寫願景並非列舉公司希望對環境所做的每一件事，而是提出需要提出的問題，以正確引導公司員工及合作夥伴。使命聲明 (或願景聲明) 的目的通常是表達願景，而願景必須在您上任的前半年就開始傳播。
至於設定策略的目的不只是定義方向，也要建立明確的商業目標和方針，以及為了達到這些目標和方針所做的投資。您可以利用現有的模型，幫助您規劃策略性計劃。其中最適合環境和永續問題的兩個模型是 SWOT (長處、短處、機會與威脅) 和 PESTLE (政治、經濟、社會、科技、法律以及環境) 模型。您可以在文件中定義策略，例如，策略性計劃。
請注意，如果領導者在發表書面聲明之前，先向認知採納者和反對關係人廣泛收集他們對願景和策略的意見，這類領導者就比較容易成功。尢其是在定案計劃中提出反對者意見的領導者，其成功機會更大。

宣導商業責任
宣導不必等到發表願景和策略之後，而是從您擔任新職開始就必須著手進行。不過，一旦發表願景和策略之後，就必須承擔更多公開的責任 (包括內部責任和外部責任)。剛開始，您或代理人需要將願景傳播給有影響力的團體，例如員工、分析師、媒體、合作夥伴、客戶和客戶倡導人。您必須鼓舞並激勵他們相信您的願景和策略，並且提出具有說服力的論點，說明這才是對貴公司和目標觀眾最有利的策略。
同時，您也必須將焦點轉移到策略的個別項目，並且定期向這些目標觀眾更新最新動態，指出代表成功的重大里程碑、傳播策略的改變，以及坦言貴公司或業界所面對的挑戰。
另外也要做好準備，讓每一位觀眾表達不同的興趣與需求。在提及每一位觀眾的專屬需要和興趣時，記得要保持基礎願景和策略的一致性，以便有效取得各種目標觀眾的參與意願。
另外，千萬別為了滿足不同的觀眾，而急於傳播彼此矛盾的「商業需求」。領導者一旦這麼做，就無法在這些問題建立可信度，即使不致如此嚴重，也會限制他們在領導變革的效率，最壞的情況更可能危及整個公司的信譽。[圖 1] 所強調的是七個有效傳播訊息的關鍵因素。
[圖 1] 有效傳播訊息的關鍵因素
[圖 1] 有效傳播訊息的關鍵因素 (按一下影像可放大檢視)

管理您的訊息
您在宣導願景和策略時，請務必考量內部和外部訊息的專業技術與完整性。環境及永續性與企業社會責任的關係，和他們與產品開發、服務、銷售與市場行銷的關係同等重要。即使貴公司已將實質的環境領導權指派給您 (但尚未給予您對環境永續公民權研究計劃的直接擁有權)，您還是要遵守與身為公民權領導者同樣的標準。
千萬不要低估外部觀眾對於環境問題的關切之心，以及他們對環境商業實務的熟悉程度。更重要的是，如果您的傳播內容過度欠缺或過度充斥承諾或完整性，也千萬不要低估他們毀滅傳播的能力。否則，貴公司可能會被貼上「環保騙子」的標籤哦。
因此，您必須制定一個結合檢閱流程的傳播策略，商請內部博學多聞之士在您公開發表之前，先行提供意見。傳播策略必須設定訊息的主要元素範圍，例如，公司環境內容資料表、訊息架構、核准的發言人名單以及話題。傳播策略是構成明確結構與一致性的重要關鍵，必須緊接在願景和策略之後完成。對訊息主要擁有人賦予個人責任，對您只有好處，沒有壞處。

透過測量來進行管理
管理願景和策略範圍內的責任是很重要的任務。無論營運、產品開發還是銷售與行銷，都必須定義那些會影響您達到目標與方針的因素。您必須將這些因素整理成一份簡單的清單，將它們對應到整體的策略計劃，接著設定這些因素在品質和 (或) 數量的底線，並且建立追蹤測量標準，作為未來分析之用。這些測量標準應該積極管理。
另外，您必須明確定義報告這些追蹤測量標準的責任，並且定期開會，邀請所有重要關係人參與會議。重要關係人可以在會議當中，討論這些追蹤測量標準對於策略計劃健全與否的影響，方法是將測量標準對應到這些因素，而將這些因素對應到策略計劃的個別元素。
只不過，許多環境領導者發現他們公司尚未備好支援追蹤測量標準的測量工具。但是您又必須借助這些工具提供必要的品質和數量資料，讓您妥善分析以及報告環境與永續研究計劃。因此，無論是藉由重新設計商業流程、部署合作與測量技術，或是開發自訂的內部工具都可以，總之一定要開發專門的測量工具才行。
不過，如果沒有資深領導階層支援公司投資這些測量工具，您可能還要面對令人頭痛的成本效益決策，決定是否為了採用適當的測量工具，而額外增加員工人數。

分析和報告環境影響
收集品質和數量資料，是為了進行深度分析。如果領導者希望瞭解他們所提出的方案有多麼成功，以及他們對公司或企業營運所採取的行動產生了什麼影響，非得進行這項分析不可。
由於環境的相關法規、標準、法律以及自發性企業報告景觀朝令夕改，對於發表環境足跡詳細資訊的公司來說，其壓力也越發沉重。如果能夠備好必要的工具和程序來支援管理、測量和分析，即可協助您收集所需的資訊，讓您製作規定發表的年度報告、進行必要的歸檔作業，以及製作自發性的公司永續報告。因此，您必須瞭解目前和未來的報告需求之後，才能投資因應商務需求而成長的整合式管理、測量、分析和報告基礎結構。
分析和報告的技術，對於積極成為實踐先驅的公司來說是不可或缺的一環。而軟體在此扮演著舉足輕重的地位 — 尤其是環境管理、流程設計、資料收集、資料操作、遠端感應、共同作業、視覺效果和簡報所用的軟體。
商用軟體有時候必須針對環境空間中特定的應用程式加以自訂。因此，為了達成整合式管理、測量、分析和報告基礎結構，在技術上做大手筆的投資也許有其必要。

身為實踐先驅
實踐先驅是每一位環境領導者嚮往達到的目標。實踐先驅分為許多類型 (請參閱 [圖 2] 的範例)，不過它們都有一個共通點：其專長並非由職銜定義，而是他們針對整合性與開放性採取行動以及引領變革的記錄所定義。
[圖 2] 實踐先驅的類型
[圖 2] 實踐先驅的類型 (按一下影像可放大檢視)
全球環境永續生態系統有賴實踐先驅來主導變革。實踐先驅的脈絡遍布政府、非政府、業界和消費者倡導組織等廣泛的聯絡人網路，他們可以商請有影響力的廠商出面解決需要密切合作的問題。實踐先驅也很熟悉許多攸關全球社區利益的新興環境問題，並且將這些問題呈現在全球觀眾面前。
另外，實踐先驅也會針對尚未受到業界重視的重要議題構思解決方案。開發這些解決方案可能需要發揮影響力，與他人 (包括競爭者在內) 聯手合作，同時也可能需要推動公司投資有待開發的市場，但是實踐先驅最後總是有辦法達成全球性的變革。

保持最新狀態
保持最新狀態，讓知識體系定期接受更新，是一種新興的紀律。若要維持信譽不墜，必須以學術觀點瞭解其他環境領導者所倡導的各種科學、政策、法律、經濟、科技和商業層面。另外相當重要的一點是，您不一定要遵守當今主流的意見，但是一定要根據環境永續和電腦的專業瞭解，倡導獨特的觀點。在環境領導者 (或是自稱實踐先驅的人) 逐漸增加的業界裡，這項整合凸顯了最主要的差異。
一名真正的領導者，在把責任交付屬下 (該屬下對於自己有興趣的主題具備專業知識)，以及在聽從公司內部其他環境政策資深代表的意見時，也必須注意其安全性。與公司前輩定期開會和報告，的確可以充分瞭解公司在環境永續的研究成果，但關鍵是您必須知道自己何時需要代表公司發言。而要知道這一點，就必須確實瞭解您的核心義務，對於內部和外部觀眾所預期的環境，堅持一貫的信念。

Michael Walsh 是 Microsoft 的資深環境產品經理。
Eliza Walsh 是傳播策略顧問，過去曾經擔任 Microsoft 中國地區的傳播專員。


現場筆記 共用分割畫面
Kentaro Toyama

把電腦的存取範圍 儘可能延伸到更多人身上，是 Microsoft Research India 傲人的目標。這個目標已經由 MultiPoint (我們曾在 2008 年 5 月份的《TechNet Magazine》討論過) 程式實現了。MultiPoint 可讓許多使用者使用多個滑鼠，與同一部電腦進行互動。
而分割畫面則是另一種形式的同時共用存取電腦，也是由 Microsoft Research India 構思完成。該程式先設定一部電腦、兩個鍵盤和兩個滑鼠的組合，然後讓終端機服務直接分割監視器。接下來就可以讓兩人共用這個監視器，各自執行不同的 OS 執行個體以及各自選擇的軟體 (﻿research.microsoft.com/users/udaip/splitscreen.htm)。比方說，一個人可以進行文書處理，而另一個人可以使用試算表。
為了啟用分割畫面，我們採用三個在 Windows Server® 2003 (我們正準備升級到 Windows Server 2008) 執行的終端機伺服器執行個體。第一個執行個體是一個容器，負責擷取所有的滑鼠和鍵盤事件，並將它們轉散佈。這一層所用的技倆，與我們在 MultiPoint 所用的一樣，也就是把有的滑鼠和鍵盤事件，連同它們的裝置識別碼一起擷取 (當 USB 裝置一插入時，Windows® 就會自動指派專屬識別碼給它們；這些識別碼並不是專屬於這個硬體裝置，而是專屬於目前的作業執行個體 — 必須了解的是兩次滑鼠點按動作是來自同一個滑鼠，還是來自不同的滑鼠)。另外，該容器也會繪製滑鼠游標。
我們可以在裡面另外開啟兩個終端機伺服器執行個體，各自接收其中一個畫面的相關事件。比方說，在預設模式下，所有由識別碼 x 的滑鼠所發出的滑鼠事件，都在左手邊的分割畫面進行，而所有由識別碼 y 的滑鼠所發出的滑鼠事件，則在右手邊的分割畫面進行。
分割畫面是使用終端機服務，直接分割一個電腦監視器 (按一下影像可放大檢視)
終端機伺服器的容器執行個體是不可缺少的一項，有了它，您才能完全控制讓哪些事件前往哪些地方，並且啟用其他進階的功能。舉個例說，我們可以容許右手邊的游標越界到左手邊的畫面，然後簡單指向畫面某處 (也許是用在教學課程吧)，或甚至與另一個視窗互動。
這時候，右手邊滑鼠事件的某個部分也會饋送到左手邊的畫面。我們曾經考慮過在 Windows 使用虛擬化技術來執行類似的功能；這也不是行不通，只不過所耗費的資源比較多罷了。
研究人員擔心大家可能會因為只能使用半邊畫面而心情不好，於是我們在印度的 Bangalore，與專門教導低收入城市年輕人基本電腦概念的 Hope Foundation 共同策畫一項研究。我們發現學生使用分割畫面的學習效果，似乎與每人使用一部電腦不相上下，至少在有限的 IT 培訓課程當中是如此。我們也查過是否有人體工學方面的問題，不過這些問題並沒有發生，即使是使用 14 吋螢幕也一樣。最重要的是，IT 培訓中心很高興能夠以同數量的電腦容納兩倍之多的學生。
Microsoft Research India 目前正與終端機服務和其他 Microsoft 小組討論，看看分割畫面是不是一項值得上市的技術。如果您覺得分割畫面是您會考慮採用的東西，請告訴我們您希望將它用在哪些案例中。來信請寄 splitscr@microsoft.com。

Kentaro Toyama 是 Microsoft Research India (research.microsoft.com/india) 的助理常務董事，暨新興市場小組 (research.microsoft.com/research/tem) 的首席技術研究員，負責為全球經濟弱勢社區開發技術。


Windows 機密文件 史上最糟的兩款電腦
Raymond Chen

2007 年 3 月， 當《PC World》雜誌評比有史以來最糟糕的前 10 部電腦時，我特別注意到前兩名，因為我們實際上用過這兩款電腦。嗯，「用過」的說法可能有點言過其實。也許我應該說我曾見證過這些電腦的使用情況，因為它們大部分的產能活動都是在 Microsoft 的員工辦公室進行。
Mattel 牌 Barbie PC 名列《PC World》名單的第二名。這款電腦比其他色彩單調的廉價電腦前進了一大步。具體來說，這是一款色彩單調的廉價電腦，但是您可以將粉紅貼紙貼到機殼、顯示器和喇叭上來加以裝飾 — 這麼說您就懂了。電腦中也預先安裝了芭比娃娃主題的軟體。
我們拿了一台來進行測試，受困於這台電腦的可憐測試人員至少還能夠以幽默和嘲弄的態度來投入測試工作，並黏上隨附的所有貼紙與裝飾品以確保安裝的電腦跟「原設計」一模一樣。這台電腦就放在從入口能一覽無遺的桌上，我們歡迎所有經過和看到這台亮粉紅色災難電腦的人試玩看看。
Barbie PC 為我們提供無限的娛樂來源。每當有機器發生問題，而開發人員必須來辦公室偵錯電腦時，他們一知道要處理的是哪一台電腦後，您肯定會看到他們流露出驚喜或驚呼「酷喔！」的反應。我還聽說某年暑假有一個大學實習生為了惡搞，就在 Barbie PC 上安裝了 Windows Server® Datacenter Edition。
無上的榮耀 — 準確來說應該是無下的榮耀 — 非 Packard Bell PC 莫屬。啊，美好的回憶。在此舉出一個例子來說明這款電腦的設計有多棒：現成的設定使得每個擴充槽插得滿滿的。或許他們的想法是：「我們的電腦太完美了，永遠不必升級！」
早在 Windows® 95 專案的時代，有位資深主管買了一台當作家用電腦，基於吃狗食 (dogfooding) 的測試目的，他安裝了最新版的 Windows 95。您可能已經猜到，那台電腦發生各式各樣的問題，而且必須經常送回偵錯。
Windows 95 專案的開發經理很聰明，他毅然而然採取直接的方式來解決問題。譬如說，為了確保推出的 Windows 95 能涵蓋廣泛的應用程式相容性，他開著一台小貨車到當地的電腦商店，店中所有電腦程式各買一份。他接著將軟體放在員工餐廳的桌上，並邀請 Windows 95 產品小組成員來拿走兩件軟體 — 附帶條件是小組成員必須安裝和執行所拿的軟體，而且還要針對所有異常事件 (無論大小) 建立偵錯檔案。作為回報，小組成員可以保有這些軟體。餐廳的盛況就像跳蚤市場一樣，小組成員打量桌上的商品，興奮地與同僚討論「你拿到什麼？」
有感於資深主管將家用電腦帶來偵錯的次數太頻繁，Windows 95 專案的開發經理再次決定採取直接的作法。他到當地的電腦商店購買了一台與資深主管完全一樣的 Packard Bell PC。
世界上有兩台這樣的電腦已經夠糟了；更糟的是，我要負責在第二台電腦上安裝每一個新版的 Windows 95，然後偵錯其中發生的任何問題。如此一來，當資深主管在家用電腦上安裝最新版本時，才不會有任何問題。
當您逐字逐句的讀到這兒，您應該已經注意到這項計劃的困難處。由於 Packard Bell PC 上沒有可用的擴充槽，因此根本無從安裝網路卡。我必須尋求其他迂迴的手段來獲得網路連線能力。我實在恨透了那台電腦。

Raymond Chen的網站「The Old New Thing」以及同名著作均探討 Windows 的歷史和 Win32 程式設計。鏡中的影像比想像中更近。