在信息技術世界里，變更是永恒的。如果您的 IT 組織與大多數其他 組織并無二致，那么了解在您的環境中所發生的變更就會成為您不得不面對的壓力，而且這種壓力與日俱增。IT 環境的復雜性和規模不斷變大，由于管理錯誤和意外數據泄漏所帶來的影響也越來越嚴重。當今的社會要求組織對此類事件負責，因此組織現在擔負著法律責任來保護它們所管理的信息。

　　這樣一來，審核環境中所發生的變更也就變得至關重要。為什么呢?通過審核，可以為了解和管理當今高度分散的大型 IT 環境中的變更提供方法。本文將涵蓋大多數組織所面臨的常見難題、IT 組織中符合性和規定的前景、中的一些基本審核，還將說明如何借助 的功能和 Microsoft System Center Operations Manager 2007 Audit Collection Services (ACS) 來完善全面的審核策略。

　　瞥一眼新聞標題就會發現，現在數據泄漏已逐漸成為一種常見問題。在這些意外事件中，許多都涉及到訴訟、財務損失以及組織要承擔的公共關系問題。能夠解釋所發生的變更或能夠快速確定問題是減小數據泄漏事件影響的關鍵。

　　例如，假定您的組織負責管理給定客戶群體的“個人身份信息”(PII)。盡管有多種方式來保護您所管理的系統中所包含的信息，但仍可能會出現安全問題。通過適當的審核，組織可以準確知道存在安全問題的系統和可能會丟失的數據。如果不進行審核，數據丟失所造成的影響可能會非常大，這主要是因為沒有辦法來估計危害程度。

　　那么為什么還沒有 IT 組織這樣做?原因在于，大多數組織沒有完全了解審核的技術方面問題。而高級管理層通常只了解諸如備份和還原等概念，審核環境中所發生的變更具有內在的復雜性，這是一種很難傳達的消息。因此，有關審核的問題通常只在重大意外事件發生后才會浮現出來。例如，雖然基本審核可能已啟用，但如果因缺少規劃而未將系統配置為審核某個特定變更，則不會收集該信息。

　　此外，在審核的安全事件中還有一些內在的問題需要 IT 專業人員來處理。其中一個難點是當今大型計算環境中系統的分布問題，這會給收集和聚合帶來嚴峻的挑戰，因為變更可能在任意給定時間出現在任何一個或一組系統中。進而還會產生另一個挑戰 — 關聯。有時需要轉換單個系統和多個系統上的事件間的關系，以提供所發生事情的真正涵義。

　　還要注意的另外一個問題是審核通常會超越傳統組織的邊界。不同的組織或團隊結構出于不同的原因而存在，可能不容易將其連接起來。許多組織都有目錄服務團隊、消息傳遞基礎結構團隊和桌面團隊，但可能只有一個安全團隊負責所有這些領域。而且，組織內的專門安全人員可能不會出現在所有位置。例如，分支機構通常依賴單個人或一個小團隊來負責包括安全事件日志管理在內的所有任務。

　　最后，大量的事件也是一個挑戰。審核的安全事件的事件日志記錄數據量要遠遠多于其他類型的事件日志記錄的數據量。收集的事件數使得有效保留和查看日志變得非常困難。而且，目前的規定和擬議的規定都要求保留此信息，因此并無助于減少當今計算基礎結構中的這一負擔。

　　以前，審核訪問信息可能被歸納為希望知道和試圖確保安全。現在，組織以及組織的高級管理人員對信息的泄漏或缺少適當的保護負有法律責任，因此 IT 管理員熟悉可能適用于其環境的各種規定就顯得尤為重要。對于全球性的公司，挑戰會更為嚴峻，因為每個國家都有自己的信息和保護規定。在圖 1 中列出了一些現有的規定符合性法規示例，還列出了 IT 組織的一些期望。

　　2002 年的“薩班-奧西利法案”(SOX)第 404 節承認信息系統的角色并要求上市公司每年對財務報告的內部控制情況進行一次復查。

　　健康保險可攜性與責任法案 (HIPPA)致力于有關健康數據的安全和隱私;“安全規則”涵蓋該數據的管理、物理和技術方面的保護。

　　電子發現 (eDiscovery)定義文檔保留和訪問的標準，包括確定文檔訪問人員的范圍和訪問方式。

　　2002 年的“聯邦信息安全管理法案”(FISMA)聯邦要求為美國政府體系提供全面的“信息安全”(INFOSEC) 框架，與各種法律執行機構進行協調，建立對商業產品和軟件功能的控制和承認機制。第 3544 節涵蓋機構的職責(包括 IT 控制)。

　　聯邦信息處理標準 (FIPS) 發布 200指定聯邦信息和信息系統的最低安全要求，并概述了在 NIST Special Publication (SP) 800-53 中找到的建議用法。在 NIST SP800-53 的第 AU-2 節 (Auditable Events) 中，指定信息系統必須能夠將審核記錄從多個組件編譯到系統范圍內與時間相關的審核追蹤中、能夠由單個組件管理審核的事件，并能夠確保組織定期復查可審核事件。

　　考慮到所有這些法律壓力，IT 專業人員需要做些什么?IT 經理和技術人員需要構建清晰簡練的情節并將其提供給組織內部和外部的人員。這包括制定正確的審核策略(需要事前評估和投資)。此處的關鍵概念在于，審核不能像常見的那樣可以事后進行設計。

　　此類 IT 挑戰通常可通過人員、過程和技術的組合加以解決。對審核而言，它就是過程。因此，第一步應掌握基礎知識，以便能夠響應組織對規定符合性的需要和要求。我們首先介紹 Windows 中有關審核的一些基礎知識，然后再深入研究 Windows Server 2008 和 Windows Vista® 中的變更。

　　所有審核事件都記錄在 Windows 安全事件日志中。這些事件通常都是無法立即對其采取操作的，實際上它們一般都屬于信息性內容。對所發生的每個特定類型的訪問，每個事件都記錄一個簡單的“審核成功”或“審核失敗”。這不同于那些應用程序或系統事件日志，它們可通過彩色編碼來識別問題(提示：可通過查找紅色事件來追蹤問題)。

　　安全事件日志與此完全不同，因為審核的事件通常被其數量所掩蓋，并且如前所述，安全數據的關聯可能會帶來重大的挑戰。即使是單一系統上的簡單數據破壞也會成為問題。此時可能需要對安全事件日志加以分析，以確定哪個帳戶被用來訪問該數據，這就需要管理員回溯查看整個日志以嘗試找到該帳戶。遺憾的是，當今一些較為復雜的攻擊通常是協調、分散的，這使得受害者在進行此類分析時非常困難。

　　也就是說，了解使信息能夠記錄在 Windows 的安全事件日志中的以下關鍵要素非常重要：“審核策略”和“系統訪問控制列表”(SACL)。對于本地計算機而言，“審核策略”是可以通過“組策略”或“本地安全策略”進行配置的設置，可定義特定訪問類型的成功和失敗事件集合。以下主要“審核策略”類別在 Windows 中已存在多年(稍后在 Windows Server 2008 的新“Granular Audit Policy”中還會介紹更多策略)：

　　●審核帳戶登錄事件

　　●審核帳戶管理

　　●審核目錄服務訪問

　　●審核登錄事件

　　●審核對象訪問

　　●審核策略變更

　　●審核權限使用

　　●審核過程跟蹤

　　●審核系統事件

　　通常大多數 IT 組織都非常了解定義“審核策略”的需求以及這些相關的類別，但是“審核策略”只代表其中一部分解決方案。 在實現全面審核計劃方面也扮演著一個重要角色。兩個特定的“審核策略”類別(審核目錄服務訪問和審核對象訪問)完全取決于 SACL 在安全事件日志中返回的信息。那么 SACL 究竟是什么?

　　每個對象(文件、注冊表或目錄服務)都有一個“訪問控制列表”(ACL)，其中包含一個或多個被分為以下兩種類型的“訪問控制項”(ACE)：“隨機訪問控制列表”(DACL) 和 SACL(后者定義的設置會記錄試圖對安全對象進行的訪問)。SACL 中的每個 ACE 都指定了應記錄在安全事件日志中的特定托管人的訪問嘗試類型。ACE 用來定義對指定對象的成功和/或失敗的訪問嘗試記錄。圖 1 顯示的是對某個對象使用 SACL 以生成特定訪問類型的事件。

　　了解“審核策略”與 SACL 之間的關系至關重要，因為在涉及環境中的變更時，需要通過配置來捕捉“正確”的審核事件。如前所述，“審核目錄服務訪問”和“審核對象訪問審核策略”只允許在安全事件日志中針對那些特定類別生成審核，如果某個對象在其 SACL 中配置了審核 ACE，則只生成事件。當這些條目準備就緒后，安全事件將由 Windows 本地安全機構 (LSA) 生成并被寫入安全事件日志。

　　事件由兩個截然不同的區域組成：標頭 - 它是靜態的，預先為每個事件標識符(事件 ID)都做了定義;正文 - 它是動態的，不同的事件包含不同的詳細信息。圖 2 顯示了 Windows Server 2008 安全事件示例中的這兩個元素。了解這些事件的組成對任意審核項目的分析階段而言都非常重要，并且對于了解在各種工具(如 ACS)中如何返回信息也具有特殊意義。

　　現在我們已經了解了問題所在，那么 Windows Server 2008 是如何幫助組織應對這些挑戰的呢?Windows Server 2008 是第一個包含新的 Windows Eventing 6.0 事件子系統的服務器版本，它極大地改善了安全事件管理的前景。請注意，雖然我們此處重點討論的是 Windows Server 2008，但 95% 的新功能集也存在于 Windows Vista 中。

　　對于 Windows Eventing 6.0，很多人的第一個關注點都會是全新的用戶界面。新的“事件查看器 Microsoft 管理控制臺”(MMC) 管理單元提供了出色的概述和摘要頁面、靈活的自定義視圖以及功能大大增強的說明文字。這些界面可幫助最終用戶或系統管理員查找事件信息，并可直接從“事件查看器”配置重要的事件日志選項。

　　常常會影響到事件日志中的安全數據的一個關鍵問題是數據的保留。以前，“事件日志”子系統(包括所有日志)會面臨可伸縮性限制。如果超過了這些限制，整個子系統將停止記錄事件。但在 Windows Eventing 6.0 中則不然，組織現在只受可用磁盤空間數量的限制。不過要注意，過大的事件日志分析起來可能會非常麻煩，因為每個單獨的日志條目在過濾時都必須進行評估，因此您可以干脆將日志保持在可管理的大小。

　　當然，這仍允許 IT 管理員為許多系統的事件日志制定存檔計劃。為了在本地服務器級別對此提供幫助，在 Windows Eventing 6.0 中新增了一個功能，即選項“日志滿時存檔日志而不覆蓋事件”。在先前版本的 Windows 中，此選項只能通過修改 AutoBackupLogFiles 注冊表值直接進行設置。盡管這提供了一種在本地存檔日志的機制，但是它并未提供隨時間推移來管理這些文件的解決方案，也未解決跨多系統時出現的聚合問題。“審核收集服務”沒有為此提供完整的解決方案，我們過一會兒將談到這一點。

　　新的界面只是一個開始。Windows Eventing 6.0 真正強大的功能在于新的 Windows Event Log 服務和底層的基于 XML 的引擎。這些組件提供了增強的可伸縮性、可訪問性和各種管理選項。事件現在以靈活的 XML 格式進行存儲，允許用戶自定義解決方案，無縫地植入此信息。

　　Windows Eventing 6.0 還提供將管理操作與特定事件相關聯的能力。這是通過將 Windows Event Collector 服務與 Task Scheduler 相集成，從而提供基于任務的事件記錄功能來實現的。這是 Task Scheduler 的一個新范例，以前它只能基于時間來觸發事件。“Attach Task to this Event”(將任務附加到此事件)向導(位于 Windows Server 2008 Event Viewer 中，可在任意事件的上下文菜單中找到)為啟動程序、發送電子郵件或顯示在任意時刻記錄的特定事件的消息提供了一種簡便的方法。當嘗試確定在環境中發生的獨立于特定安全事件的特定操作時，此功能可能會非常有用。例如，如果要審核在域控制器上對“Schema Update Allowed”注冊表項所做的變更，您可以創建一個任務，當此注冊表項被修改時向指定的安全管理員發送一封電子郵件來通知他們。

　　除了收集和存儲大量事件條目這一新功能外，您現在還可以更加靈活地控制要在事件日志中記錄的事件。這是通過一個名為 Granular Audit Policy (GAP) 的新功能完成的。在以前版本的 Windows 中，九個主要審核類別常常會導致事件超載。這些頂級類別現在可通過 50 個精細子類別加以控制，每個都代表事件的一個相關子集。

　　這樣就可以從事件日志中過濾出非關鍵信息，而不會在類別級損失可視性。例如，如果在特定系統上只想監視對注冊表而不是對文件系統的變更，以前只能選擇只報告“對象訪問”類別中成功或失敗的項目。利用 GAP，您現在可以過濾出各種子類別(如“文件系統”、“認證服務”以及“文件共享”)，并且可以只報告在“注冊表”子類別上發生的事件。要了解 Windows Server 2008 系統中 GAP 子類別的內容，必須從提升的命令提示符下運行 Auditpol 命令。要列出可用的 GAP 子類別，請鍵入以下內容：

　　要獲得您的系統中已配置的 GAP 子類別的列表，請鍵入：

　　請注意，GAP 不能通過標準的“組策略”用戶界面進行配置，必須通過 auditpol.exe 進行管理。在 support.microsoft.com/kb/921469 上的知識庫文章中，介紹了在 Windows Server 2008 和 Windows Vista 系統中如何通過“組策略”來部署設置的指導原則。

　　Windows Server 2008 還可以在安全事件日志中捕捉特定類型的新值和舊值。在以前版本的 Windows 中，審核子系統只記錄變更過的 Active Directory® 對象屬性名稱或注冊表值，而不記錄屬性的以前和當前值。此新功能適用于 Active Directory Domain Services、Active Directory Lightweight Directory Services 和 Windows 注冊表。通過在“注冊表”或“目錄服務變更”子類別上啟用“審核成功”或“審核失敗”并設置關聯的 SACL，詳細事件將出現在這些對象的操作事件日志中。這可以使用以下 auditpol 命令來執行：

　　對于注冊表變更，這些將顯示為 Event ID 4657 事件。

　　此功能在嘗試跟蹤 對象的變更時尤為有用。對于“目錄服務變更”，這些變更出現在一對 Event ID 5136 事件中，如圖 4 所示。每個事件在事件正文中都有目錄服務“對象”、“屬性”和“操作”。對于針對包含現有數據的屬性的變更，可看到兩個操作：“值已刪除”和“值已添加”。對于未填充的屬性，在將數據寫入到該屬性時只能看到“值已添加”操作。例如，當針對某個用戶對象(如 telephoneNumber)的屬性成功執行了修改操作后，Active Directory 會在詳細的事件日志條目中記錄屬性的以前和當前值。

　　如果創建了一個新對象，則在對象創建時所填充的屬性值將被記錄下來。如果在域內移動對象，則以前的位置和新位置(以可分辨名稱的形式)將被記錄下來。在設置了相應的“審核策略”后，默認會啟用“old and new”(舊與新)功能。如果您希望將某個屬性保持專有，如雇員 ID 號的變更，可通過對架構進行簡單的修改來明確排除這些屬性。如果在架構中將該屬性的 searchFlags 屬性改為 0x100(值 256 -NEVER_AUDIT_VALUE)，如圖 5 所示，則當該屬性發生變更時，“目錄服務變更”事件不會發生。

　　　　最后，Windows Eventing 6.0 中一個非常不錯的新功能是“Event Subscriptions”(事件訂閱)。正如先前所述，訪問和查看事件日志是一項非常重要的系統管理任務。新的“事件訂閱”功能提供了一種方法，可在系統之間直接轉發事件。“事件訂閱”由收集事件的“事件收集器”和被配置為向指定主機轉發事件的“事件源”組成。消耗事件的能力由 Windows Event Collector 服務(Windows Eventing 6.0 的新功能)提供，而訂閱功能則被內置在 Windows Event Log 服務中。用戶可以配置一個收集器，從各種事件源中收集事件，這里所說的事件源可以是 Windows Server 2008 或 Windows 系統。

　　從事件源收集的所有數據都駐留在離散的名為 Forwarded Events (ForwardedEvents.evtx) 的事件日志中，并由收集器上的 Event Log 服務進行管理。對兩個端點(收集器和源)的配置都是必不可少的，此操作可以自動進行(源上為 winrm quickconfig –q;收集器上為 wecutil qc /q)。要特別注意的是，此事件訂閱功能不是為企業設計的，也不是要將事件提供給外部數據庫的替換系統。

　　為了說明如何使用此功能，讓我們假定有一個小 Web 場。您有一小組與特定網站(包括 Web 服務器和 SQL 服務器)關聯的系統。這些系統可使用新的“事件訂閱”功能，將其安全事件日志信息合并到單個系統中。環境規模越大，通常需要的事件日志合并工具集也越高級。

　　現在我們已經了解了在審核時所面臨的挑戰和在法律和技術方面的問題，那么 IT 管理員該如何開始為其組織制定“審核計劃”呢?與大多數事情一樣，制定全面的審核策略是一個多步驟過程。第一步是確定要審核的內容。這包括對環境進行分析并確定哪些類型的事件和變更需要生成審核。這可以包括一些簡單的項目(如帳戶鎖定、敏感組變更、信任創建等)，也可以包括復雜的變更(如修改所在環境中的應用程序內的配置元素)。此處的關鍵在于管理層必須參與確定審核計劃中都需要有“什么”。此練習需要書面完成并應定期重復，而不是在發生重大意外事件以后再執行。

　　第二步是確定涉及特定變更的審核信息如何以安全事件的形式返回。審核信息有時比較難懂并且易讀性較差。在實施之前，必須在安全事件和各種操作之間建立關聯，以了解安全事件的真正涵義。不能在意外事件發生后再來確定事件與操作的關系。

　　第三步是指當這一切準備就緒時，即當您實施“審核策略”和 SACL 時。正如前面所討論的，您需要在目錄、文件系統和注冊表中定義“審核策略”設置(以允許生成安全事件)和 SACL(為關聯的操作生成審核追蹤)，以獲得在這些領域中對變更的完整描述。

　　接下來是第四步，也是最后一步，即收集、觸發和分析。根據組織規模和需求的不同，這些可能會涵蓋在 Windows Server 2008 的固有功能中，也可能涵蓋在一些高級解決方案中，如 System Center Operations Manager 的“審核收集服務”功能。大多數組織所犯的一個常見錯誤是只設置“審核策略”而不定義 SACL。最后一步是實施技術解決方案，向組織中的負責人報告和共享數據。如前所述，大多數組織已建立了負責安全的實體，因此需要圍繞有待提高效率的現有組織元素來構建審核計劃。這最后一步的關鍵是要以有意義的方式收集信息并將其提供給那些負責了解環境中所發生變更的所有實體。

　　大多數 IT 組織現在已不只是僅考慮一個全面的審計計劃，而是實際需要這樣的計劃。與先前的平臺相比，Windows Server 2008 為收集和分析安全事件數據提供了增強的機制。先進的收集和報告技術(如 ACS)使過去因事件數量和分布原因而晦澀難懂的問題變得明朗起來，使這些變更立刻變得一目了然。

　　與大多數 IT 問題一樣，過程是主要的挑戰。必須通過更多的配置和分析才能捕捉到 IT 經理的預期目標，因此要想從容應對這些挑戰，必須深入了解環境的要求和 Windows 平臺的功能。祝您成功。

關鍵字：Server 2008、審核策略、數據