特別報導：Windows Server 2008

Windows Server 2008 中的稽核與規範

Rob Campbell 和 Joel Yoker

摘要:

• 提高規範的重要性
• 了解您環境內的變動
• 稽核安全性事件的挑戰
• 稽核的技術層面

在資訊科技的世界裡，變動是一種常態。如果您的 IT 組織跟其他大多數 IT 組織一樣，那麼想必您是面臨著與日俱增的壓力，不得不了解您環境內所發生的變更。隨著 IT 環境的複雜度和規模的擴增，

系統管理方面的失誤和資料不慎暴露所產生的衝擊也跟著加大。當今社會對這類的事件負責的呼聲高漲，因此各公司現在也必須盡法律責任來保衛資訊的安全。

這樣的結果，使得稽核您環境內的變更就變得很重要了。為什麼呢？稽核提供了各種方法來了解和管理當今大型高分散式 IT 環境的變動。在本文中，我們將探討大多數公司所面臨的常見挑戰、IT 當中規範和法規的全貌、在 Windows® 中進行稽核的一些基本原理，以及 Windows Server® 2008 和 Microsoft® System Center Operations Manager 2007 Audit Collection Services (ACS) 的功能如何補充不足，來達成完備的稽核策略。

稽核挑戰

只要稍微瞄一下每天的頭條新聞，就不難發現資料暴露的問題已成為家常便飯。這些當中的許多事件都牽涉到法律行動、財務損失和公司需負責的公關議題。降低資料暴露事件所造成的衝擊，關鍵在於快速釐清發生了什麼變動或是識別問題所在。

舉例來說，讓我們假設貴公司負責管理某特定客戶基底的個人識別資訊 (PII)。要保護包含在您管理的系統上的資訊，雖說方法不計其數，但仍舊免不了遭到侵害。適當的稽核可讓公司對受到侵害的系統，甚或是丟失的資料瞭若指掌。若不進行稽核，資料遺失所帶來的衝擊可能更大，這多半是因為要估計出遭到侵害的範圍根本不可能。

那麼 IT 組織為什麼還遲遲未行？事實上是，大多數的公司對稽核的技術層面並沒有通盤的了解。雖然資深的主管階層一般都了解像是備份和還原的概念，但是稽核環境裡面的變動所牽涉的複雜度實在難以表達。結果，關於稽核的疑問往往只在發生重大的事件後才此起彼落。例如，公司有可能已經施行基本的稽核，但若因缺乏規劃，而未設定系統來稽核特定的變更，也就不會收集該項資訊。

再者，稽核的安全性事件也有一些 IT 專家必須處理的固有問題。其中一個困境就是在現今大型運算環境內系統的分散程度，這在收集和彙總方面呈現了明顯的挑戰，因為變更很可能在任何特定時間發生在任何系統或一組系統上。這就產生了另一項挑戰 — 相關性。為了找出情況發生真正的意義，往往有必要解釋單一和多重系統上的事件之間的關係。

另外還有一個問題，那就是稽核通常超出傳統組織化的界限。不同的組織或小組結構是因不同的理由而存在，因此可能不容易銜接。許多公司都有目錄服務小組、訊息基礎結構小組和桌上型電腦小組，但很可能只有一個安全性小組負責所有這些領域。除此之外，貴公司的專屬安全性人員可能無法現身於所有地點。比如說，分公司辦公室通常只有一名員工或一小組人馬要負責所有的工作，包括安全性事件日誌管理在內。

最後，量大的事件也極富挑戰。稽核的安全性事件數量遠比其他類型的事件日誌還多。收集的事件數目之多，要有效地保留和檢閱記錄檔實在不容易。再者，現行和尚未通過的法規也規定要保留這項資訊，使得現今運算基礎結構的負荷更加沉重。

在過去，稽核資訊的存取可以歸納成是一種求知和想要求得安全的慾望。而現在，因為公司 — 以及負責的資深管理階層 — 必須擔負起因資料遺失或缺乏適當保護措施而引起的法律責任，IT 系統管理員更有必要熟悉適用於其環境的法規。對於全球性的公司來說，這些挑戰更為複雜，因為每個國家對於資訊及其相關保護措施，都有自己的一套規定。**[圖 1]**列出了一些現行的法律規範範例，以及對 IT 組織的相關期望。

Figure 1 法規與它們對 IT 專家的含意

IT 專家要怎麼應付這些法律壓力呢？IT 經理和技術人員必須發展出簡明扼要的藍圖，呈現給公司內外的人員。這包括開發適當的稽核策略，這種策略需要採取主動的手段和投資。此處的關鍵概念是，稽核不當無法在設計事後再添補，而當前的稽核卻往往事後補救。

這類的 IT 挑戰一般透過人員、程序和技術的結合便能獲得解決。稽核時，程序是最重要的一環。因此，第一步應該是掌握基本原則，如此一來您就能回應公司的需要，以及遵守法規方面的需求。我們會先討論在 Windows 內進行稽核的基礎，接下來將深入探討 Windows Server 2008 和 Windows Vista® 中的變更。

稽核安全性事件

所有稽核的事件都會記錄在 Windows 安全性事件日誌中。這些事件通常不能立即採取行動，而且在本質上往往只是提供參考資訊之用。每個事件都會針對所發生的特定存取類型，記錄簡單的「稽核成功」或「稽核失敗」。這不像應用程式或系統事件日誌，可以透過色彩編碼 (提示：尋找紅色事件以找出問題所在) 辨識出問題。

安全性事件日誌之所以不同，是因為稽核的事件往往因為量大而不容易發現，而且之前提過，安全性資料的相關性可能會呈現相當大的挑戰。即便是單一系統上一個簡單的資料漏洞，也是問題連連。要識別存取資料使用的是哪個帳戶，必須分析安全性事件日誌，而系統管理員得追蹤整個記錄檔，才找得到那個帳戶。不幸的是，當今複雜的攻擊行為常常是經過協調而且目標分散，使得受害者難以進行這類的分析。

因此，務必要了解讓資訊記錄在 Windows 的安全性事件日誌中的關鍵要素：稽核原則和系統存取控制清單 (SACL)。稽核原則是本機電腦中可透過群組原則或本機安全性原則進行設定的設定，它定義著收集特定存取類型的成功和失敗事件的作業。下列主要的稽核原則類別在 Windows 中已行之多年 (稍後會詳細說明 Windows Server 2008 中的細微稽核原則)：

• 稽核帳戶登入事件
• 稽核帳戶管理
• 稽核目錄服務存取
• 稽核登入事件
• 稽核物件存取
• 稽核原則變更
• 稽核權限使用
• 稽核處理序追蹤
• 稽核系統事件

大部分 IT 組織都知道定義稽核原則和這些相關類別是不可少的，但是稽核原則不過是整個解決方案的一小部分。SACL 在實作整體稽核計畫時也扮演著重要的角色。有兩個特定的稽核原則類別 — 稽核目錄服務存取和稽核物件存取 — 完全仰賴 SACL 以便在安全性事件日誌中傳回資訊。那麼，SACL 到底是什麼？

每個物件 — 檔案、登錄或目錄服務 — 都有一份存取控制清單 (ACL) 和一或多個分成兩種類型的存取控制項目 (ACE)：判別存取控制清單 (DACL) 和 SACL (後者定義著記錄嘗試存取安全物件的設定)。SACL 中的每個 ACE 都會指定應該記錄在安全性事件日誌中的特定信任者所嘗試的存取類型。ACE 會定義嘗試存取指定物件的成功和/或失敗記錄。[圖 2] 說明使用物件上的 SACL 來產生特定存取類型的事件。

[圖 2]** 使用物件上的 SACL **(按影像可放大)

了解稽核原則和 SACL 之間的關係至關重要，因為要擷取「正確」的稽核事件，設定是不可少的，它與環境內的變更息息相關。如前所述，稽核目錄服務存取和稽核物件存取稽核兩種原則，只會針對該些特定的類別在安全性事件日誌中產生稽核，但是只有當物件在它的 SACL 中有設定稽核 ACE 時才會產生事件。一旦一切就定位，Windows 本機安全性授權單位 (LSA) 就會產生安全性事件，並寫入安全性事件日誌中。

事件包括兩大不同的區域：標頭和本文，前者是靜態的，而且會針對每個事件識別元 (Event ID，事件識別碼) 預先定義；後者則是動態的，並且依不同的事件包含不同的詳細資料。[圖 3] 以簡單的 Windows Server 2008 安全性事件說明這兩個要素。了解這些事件元件對於任何稽核專案的分析階段來說很重要，尤其是關於資訊如何在像是 ACS 的工具內回傳這方面。

[圖 3]** 稽核事件的標頭和本文 **(按影像可放大)

Windows Eventing 6.0

了解問題所在之後，Windows Server 2008 要如何協助公司面對這些挑戰呢？Windows Server 2008 是第一個包含全新 Windows Eventing 6.0 事件子系統的伺服器版本，這個子系統可大幅改進安全性事件管理的情況。要注意的是，雖然我們此處的重點是放在 Windows Server 2008，但 95% 的新功能組仍存在於 Windows Vista 中。

對於 Windows Eventing 6.0，許多人會先注意到的是全新的使用者介面。全新的事件檢視器 Microsoft Management Console (MMC) 嵌入式管理單元提供了絕佳的 [概觀] 和 [摘要] 頁、富彈性的自訂檢視，以及大幅改進的解說文字。這些介面可以幫助使用者或系統管理員直接從事件檢視器本身尋找事件資訊，以及設定重要的事件日誌選項。

資料保留是經常影響事件日誌中的安全性資料的一大問題。在過去，事件日誌子系統 (包括所有記錄檔) 都面臨著延展性的限制。如果超過這些限制，整個子系統便會停止記錄事件。這在 Windows Eventing 6.0 中倒不成問題，公司現在唯一面臨的限制是可用的磁碟空間大小。不過也別輕忽，非常大型的事件日誌分析起來可能困難重重，因為每個個別的日誌項目在篩選時都必須經過評估，因此您應當將記錄檔保持在可管理的大小限度裡面。

不用說，這還是有待 IT 系統管理員針對許多系統開發出一套事件日誌的封存計畫。Windows Eventing 6.0 中現在有個功能在本機伺服器層級上可以幫得上忙，那就是 [當記錄檔已滿時進行封存，不要覆寫事件] 選項。在舊版的 Windows 中，這個選項只能透過修改 AutoBackupLogFiles 登錄值直接設定。這雖然提供了一種機制來封存本機的記錄檔，但它並沒有為長期管理這些檔案提供解決方案，也沒有解決發生在多個系統上的彙總問題。稽核收集服務在這方面倒是提供一套完整的解決方案，我們一會兒就會討論到。

全新的介面只是開頭，好康的還在後面。Windows Eventing 6.0 的真正威力其實是全新的 Windows 事件日誌服務和其下的 XML 架構引擎。這些元件正是提供高延展性、可存取性和管理選項背後的推手。事件現在是以富彈性的 XML 格式儲存，透過這種格式，便可建立自訂解決方案從自身獲取這項資訊。

Windows Eventing 6.0 也提供將系統管理動作與特定事件建立關聯的功能。它採用的方法是將 Windows 事件收集器服務與工作排程器相整合，以供進行工作式事件記錄。這是工作排程器的新運作模型，它過去只限根據時間來觸發事件。「附加工作到此事件」精靈 (可從 Windows Server 2008 事件檢視器中任何事件的快顯功能表存取) 提供一種簡單的方法，在每次記錄特定事件的時候啟動程式、傳送電子郵件，或是顯示訊息。這在嘗試識別環境內所發生的特定動作以隔離成特定的安全性事件時相當有用。比方說，如果您要稽核網域控制站上對「允許的架構更新」登錄機碼所做的變更，您可以建立一項工作來傳送電子郵件給特定的安全性系統管理員，以便在此登錄機碼遭到修改時通知他們。

除了收集和存放大量事件項目的新功能外，您現在還能進一步控制事件日誌中要記錄哪些事件。這是透過一項稱為細微稽核原則 (GAP) 的新功能達成。在舊版的 Windows 中，九大稽核類別往往使事件超載。這些上層類別現在可以透過 50 個細微的子類別來控制，它們各自代表一個相關的事件子集。

這讓您能夠從事件日誌中篩選出非關鍵的資訊，同時不致失去類別層級的可見性。例如，若是在特定系統上您只想監視登錄的變更，而不想監視檔案系統的變更，在過去您只能選擇在「物件存取」類別上報告成功或失敗。但是現在透過 GAP，便可以篩選出像是「檔案系統」、「憑證服務」和「檔案共用」等子類別，而只報告「登錄」子類別上的事件。若要探索 Windows Server 2008 系統上的 GAP 子類別，您必須從較高權限的命令提示執行 Auditpol 命令。若要列出可用的 GAP 子類別，請輸入下列命令：

auditpol /list /subcategory:*

若要取得您系統上所設定的 GAP 子類別清單，請輸入：

auditpol /get /category:*

請注意，GAP 並不能透過標準群組原則使用者介面設定，它必須透過 auditpol.exe 管理。知識庫文件 (support.microsoft.com/kb/921469) 有如何針對 Windows Server 2008 和 Windows Vista 系統透過群組原則部署 GAP 設定的相關指引。

Windows Server 2008 也可以同時擷取安全性事件日誌中特定類型的新舊值。在舊版的 Windows 中，稽核子系統只會記錄有經過變更的 Active Directory® 物件屬性或登錄值的名稱 — 它並不會記錄該屬性之前的值和現在的值。這項新功能適用於 Active Directory 網域服務、Active Directory 輕量型目錄服務和 Windows 登錄。透過啟用「登錄」或「目錄服務變更」子類別的 [稽核成功] 或 [稽核失敗]，然後設定相關聯的 SACL，事件日誌中便會引發詳細的事件對這些物件採取行動。這可以使用下列的 auditpol 命令來執行：

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

對於登錄變更，這些會顯示成「事件識別碼 4657」事件，如 [圖 4]。

[圖 4]** 登錄變更前後 **(按影像可放大)

在嘗試追蹤 Active Directory 物件上的變更時，這項功能特別有用。對於目錄服務變更，這些變更會以一組「事件識別碼 5136」事件顯示，如 [圖 5] 所示。每個事件在事件的本文中都有目錄服務物件、屬性和作業。對含現有資料的屬性所做的變更，我們會看到兩項作業：「刪除的值」和「新增的值」。對於未填入的屬性，我們在資料寫入該屬性時只會看到「新增的值」作業。例如，當對使用者物件的屬性 (例如 telephoneNumber) 執行成功的修改作業時，Active Directory 會將該屬性之前的值和現在的值記錄在詳細的事件日誌項目中。

[圖 5]** 目錄服務變更事件前後 **(按影像可放大)

在新物件建立時，便會記錄在建立物件當時填入的屬性值。如果將物件移入網域中，就會記錄之前的位置和新的位置 (命名為截然不同的名稱)。當設有適當的稽核原則設定時，預設便會啟用「新舊」功能。如果您想要將屬性保持為私用，例如員工識別碼號碼變更，只要進行簡單的修改，就可以特別排除那些屬性。如果在架構中將屬性的 searchFlags 屬性修改成 0x100 (值 256 -NEVER_AUDIT_VALUE)，如 [圖 6] 所示，那麼當屬性發生變更時就不會引發「目錄服務變更」事件。

[圖 6]** 將屬性從目錄服務變更中排除 **(按影像可放大)

最後，Windows Eventing 6.0 其中一項最棒的新功能是事件訂閱。之前有提到，存取和檢閱事件日誌是重要的系統管理工作。全新的事件訂閱功能提供方法直接在系統間轉送事件。事件訂閱包含一個事件收集器和事件來源，前者會收集事件，而您以可設定後者將事件轉送到指定主機。Windows 事件收集器服務 (Windows Eventing 6.0 的新功能) 提供取用事件的功能，而訂閱者功能則已內建至 Windows 事件日誌服務中。您可以設定收集器收集許多事件來源的事件，包括 Windows Server 2008 或 Windows Vista 系統。

所有從事件來源收集到的資料都放在不同的事件日誌中，名為轉送的事件 (ForwardedEvents.evtx)，並且是由收集器上的事件日誌服務來管理。兩端 (收集器和來源) 都必須進行設定，而且設定可以自動化 (在來源上使用 winrm quickconfig –q；在收集器上使用 wecutil qc /q)。有一點要注意的是，事件訂閱這項功能並不是針對企業而設計的，更不是要取代傳送事件到外部資料庫的系統。

其中一個可以運用此功能的範例，就是小型 Web 伺服陣列。假設您有一小組與特定網站相關聯的系統 (包括網頁伺服器和 SQL 伺服器)。這些系統便可以使用新的事件訂閱功能，將它們的安全性事件日誌資訊合併在單一的系統上。較大規模的環境一般都需要較為進階的事件日誌合併工具組。

稽核收集服務

Windows Server 2008 雖然具備所有這些新功能，但長期管理和封存安全性事件日誌資訊的真正解決之道，其實在於稽核資訊的中央資料庫。稽核收集服務是 System Center Operations Manager 2007 的核心功能。ACS 提供了一種機制供轉送、收集、存放和分析安全性事件資料。安全性事件是幾近即時收集而成，而且是存放在中央 SQL 儲存機制中。因為不用實際存取真正要稽核的系統，ACS 也讓各公司有途徑可以提供對稽核資訊的最低權限存取。現在就來看看 ACS 的運作方式。

ACS 有三大元件：第一元件是轉寄站，在這個部分中，Operations Manager 代理程式會將用戶端的事件日誌資料傳輸到 ACS 基礎結構。轉寄站會將資料傳輸到第二個元件，即收集器，這是伺服器端的接聽程式。ACS 轉寄站會透過 TCP 連接埠 51909 連線，安全地與它們指定的收集器通訊。在傳輸之前，事件日誌資料會先正規化成 XML，表示多餘的資訊會移除掉，而事件資訊會根據事件特定的標頭和本文資訊歸納成對應的欄位。資訊一抵達收集器，就會將它傳送到第三也是最後一個元件 — ACS 資料庫。這遂變成長期存放安全事件資訊的儲存機制。一經存放後，資訊就可以直接透過 SQL 查詢來採礦，或使用 HTML 報告 (採用 SQL Server® Reporting Services) 來轉譯。ACS 提供三種預設的檢視，如 [圖 7] 所示。

Figure 7 ACS 檢視

從效能的觀點看來，單一 ACS 收集器在尖峰時段每秒最多可處理 100,000 個事件，而且每秒最多可連續處理 2,500 個事件。若要進行規劃，根據預設稽核原則設定而定，單一 ACS 收集器可支援多達 150 個網域控制站，3000 部成員伺服器，或 20,000 台工作站。在經過測試、實際執行的案例下，約有 150 個網域控制站顯示出每秒最多可處理大約 140 個事件，而在尖峰時段每小時平均可處理 500,000 個事件。14 天下來 (ACS 的預設保留設定)，SQL Server 資料庫中便儲存了超過 150GB 的安全性事件資料。比較積極的稽核原則和相關聯的 SACL 設定很明顯地會產生甚至更多的資料 (每個小時、每天及整體下來)。

在這裡有一點要特別注意的是，資料量這麼大，根本沒有人有辦法可以檢閱典型大型企業環境中的每個事件。反過來說，公司也不用對此處所呈現的數字感到懼怕。要了解您環境內所發生的變更，其實關鍵在於分析大量資料。

這正是 ACS 發揮功效的地方。透過 SQL Server Reporting Services 和 ACS，您可以將一般深埋在安全性事件日誌的問題，轉化成像是在應用程式事件日誌中容易辨別的色彩編碼事件。雖然 ACS 包含一組預設報告，但要針對環境的特定需要來擴充這些報告其實很簡單。

以下面這個案例來說：由於環境內部對外部信任相當敏感，因此管理階層要求我們開發出一份報告，詳述建立 Active Directory 信任的程序。進行過一些研究調查之後，我們知道當建立信任時，Active Directory 內特定的網域命名內容中的 cn=System 容器內會建立一個 trustedDomain 物件。只要在編輯此容器上的 SACL 以稽核順利建成的任何受信任網域之後，接下來便能夠在每次建立此類型的物件時，擷取安全性事件。這在執行信任建立的 DC 上的安全性事件日誌當中，是解譯在 566 事件中。之後我們便可以寫入簡單的 SQL 查詢，從 ACS 擷取這項資訊：

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

若要把它製作成報告，請使用隨附在 SQL Server 2005 Reporting Services 的 Visual Studio® 2005 版本，因為它是專門針對開發報告而提供的。完成精靈之後，很容易就可以建立非常類似 [圖 8] 中的報告。除此之外，可以顯示在安全性事件日誌中的任何環境內變更，也會歸納成類似的專業外觀報告。

[圖 8]** ACS 報告範例 **(按影像可放大)

開發稽核計畫

現在我們對稽核的挑戰，還有法律和技術層面已有所了解，那麼 IT 系統管理員該如何為公司開發「稽核計畫」呢？就跟很多事情一樣，開發完備的稽核原則也牽涉多個步驟。第一個步驟是判定應該要稽核的項目。這包括分析您的環境，並決定哪種類型的事件和變更應該產生稽核。這可包括簡單的項目 (像是帳戶鎖定、敏感的群組變更、建立信任)，或是複雜的變更 (例如在您環境內修改應用程式當中的設定項目)。此處的關鍵是管理階層必須一併參與決定稽核計畫裡面的「內容」。這項作業必須在書面上完成，而且應該定期重複操練 — 而不是只在重大事件發生後才進行。

第二步包括識別攸關特定變更的稽核資訊要如何以安全性事件的形式回傳。稽核資訊有時候相當隱密，而且不容易閱讀。在實作之前，必須在安全性事件和不同動作之間建立相關性，以便了解安全性事件的真正意涵。事件發生後才花時間了解事件與動作的關係就太遲了。

第三步是試車，也就是實作您的稽核原則和 SACL 的時候。先前有討論過，您必須定義目錄、檔案系統和登錄中的稽核原則設定 (以便產生安全性事件) 和 SACL (以針對相關聯的動作產生稽核追蹤)，才能對這些區域中的變更有概全的了解。

這就把我們帶到第四個也是最後一個步驟 — 收集、觸發和分析。視貴公司的規模大小和需要而定，這可涵蓋在原始的 Windows Server 2008 功能中，或是涵蓋在進階的解決方案中，例如 System Center Operations Manager 的稽核收集服務功能。大多數公司最常犯的錯誤是，只設定稽核原則，而沒有定義 SACL。最後一個步驟主要是實作技術解決方案，以便向公司內部的共同工作人員報告和分享資料。之前有提到，大部分公司都有既定的實體負責安全性，而稽核計畫必須針對現有的組織要素來建構才能發揮功效。最後這個步驟的關鍵是，以有意義的方式收集資訊，並將之呈現給所有那些負責了解環境變更的人。

絕大多數 IT 組織都有考慮訂定完備的稽核計畫，但卻都等到發生重大事件之後才了解到它的必要性。跟舊版的平台比起來，Windows Server 2008 提供更加強化的機制來收集和分析安全性事件資料。進階的收集和報告技術，例如 ACS，可暴露過去因大量事件和分散情況而受到隱蔽的問題，進而讓這些變更立即可見。

就跟大部分的 IT 問題一樣，程序也是主要的挑戰。達到 IT 經理的期望向來需要進行額外的設定，因此深入了解您的環境需求，以及 Windows 平台的功能，將可讓您因應這些迎面而來的挑戰。祝您涉獵順利。

Rob Campbell 和 Joel Yoker Rob Campbell 是 Microsoft Federal 小組的資深技術專家，而 Joel Yoker 則是該組的資深顧問。Robl 和 Joel 專門負責為美國聯邦政府客戶開發及部署安全性解決方案。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.