Windows Server 2008 中的审核和符合性

这样一来，审核环境中所发生的变更也就变得至关重要。为什么呢？通过审核，可以为了解和管理当今高度分散的大型 IT 环境中的变更提供方法。本文将涵盖大多数组织所面临的常见难题、IT 组织中符合性和规定的前景、Windows® 中的一些基本审核，还将说明如何借助 Windows Server® 2008 的功能和 Microsoft® System Center Operations Manager 2007 Audit Collection Services (ACS) 来完善全面的审核策略。

瞥一眼新闻标题就会发现，现在数据泄漏已逐渐成为一种常见问题。在这些意外事件中，许多都涉及到诉讼、财务损失以及组织要承担的公共关系问题。能够解释所发生的变更或能够快速确定问题是减小数据泄漏事件影响的关键。

例如，假定您的组织负责管理给定客户群体的“个人身份信息”(PII)。尽管有多种方式来保护您所管理的系统中所包含的信息，但仍可能会出现安全问题。通过适当的审核，组织可以准确知道存在安全问题的系统和可能会丢失的数据。如果不进行审核，数据丢失所造成的影响可能会非常大，这主要是因为没有办法来估计危害程度。

那么为什么还没有 IT 组织这样做？原因在于，大多数组织没有完全了解审核的技术方面问题。而高级管理层通常只了解诸如备份和还原等概念，审核环境中所发生的变更具有内在的复杂性，这是一种很难传达的消息。因此，有关审核的问题通常只在重大意外事件发生后才会浮现出来。例如，虽然基本审核可能已启用，但如果因缺少规划而未将系统配置为审核某个特定变更，则不会收集该信息。

此外，在审核的安全事件中还有一些内在的问题需要 IT 专业人员来处理。其中一个难点是当今大型计算环境中系统的分布问题，这会给收集和聚合带来严峻的挑战，因为变更可能在任意给定时间出现在任何一个或一组系统中。进而还会产生另一个挑战 — 关联。有时需要转换单个系统和多个系统上的事件间的关系，以提供所发生事情的真正涵义。

还要注意的另外一个问题是审核通常会超越传统组织的边界。不同的组织或团队结构出于不同的原因而存在，可能不容易将其连接起来。许多组织都有目录服务团队、消息传递基础结构团队和桌面团队，但可能只有一个安全团队负责所有这些领域。而且，组织内的专门安全人员可能不会出现在所有位置。例如，分支机构通常依赖单个人或一个小团队来负责包括安全事件日志管理在内的所有任务。

最后，大量的事件也是一个挑战。审核的安全事件的事件日志记录数据量要远远多于其他类型的事件日志记录的数据量。收集的事件数使得有效保留和查看日志变得非常困难。而且，目前的规定和拟议的规定都要求保留此信息，因此并无助于减少当今计算基础结构中的这一负担。

以前，审核访问信息可能被归纳为希望知道和试图确保安全。现在，组织以及组织的高级管理人员对信息的泄漏或缺少适当的保护负有法律责任，因此 IT 管理员熟悉可能适用于其环境的各种规定就显得尤为重要。对于全球性的公司，挑战会更为严峻，因为每个国家都有自己的信息和保护规定。在图 1 中列出了一些现有的规定符合性法规示例，还列出了 IT 组织的一些期望。

考虑到所有这些法律压力，IT 专业人员需要做些什么？IT 经理和技术人员需要构建清晰简练的情节并将其提供给组织内部和外部的人员。这包括制定正确的审核策略（需要事前评估和投资）。此处的关键概念在于，审核不能像常见的那样可以事后进行设计。

此类 IT 挑战通常可通过人员、过程和技术的组合加以解决。对审核而言，它就是过程。因此，第一步应掌握基础知识，以便能够响应组织对规定符合性的需要和要求。我们首先介绍 Windows 中有关审核的一些基础知识，然后再深入研究 Windows Server 2008 和 Windows Vista® 中的变更。

所有审核事件都记录在 Windows 安全事件日志中。这些事件通常都是无法立即对其采取操作的，实际上它们一般都属于信息性内容。对所发生的每个特定类型的访问，每个事件都记录一个简单的“审核成功”或“审核失败”。这不同于那些应用程序或系统事件日志，它们可通过彩色编码来识别问题（提示：可通过查找红色事件来追踪问题）。

安全事件日志与此完全不同，因为审核的事件通常被其数量所掩盖，并且如前所述，安全数据的关联可能会带来重大的挑战。即使是单一系统上的简单数据破坏也会成为问题。此时可能需要对安全事件日志加以分析，以确定哪个帐户被用来访问该数据，这就需要管理员回溯查看整个日志以尝试找到该帐户。遗憾的是，当今一些较为复杂的攻击通常是协调、分散的，这使得受害者在进行此类分析时非常困难。

也就是说，了解使信息能够记录在 Windows 的安全事件日志中的以下关键要素非常重要：“审核策略”和“系统访问控制列表”(SACL)。对于本地计算机而言，“审核策略”是可以通过“组策略”或“本地安全策略”进行配置的设置，可定义特定访问类型的成功和失败事件集合。以下主要“审核策略”类别在 Windows 中已存在多年（稍后在 Windows Server 2008 的新“Granular Audit Policy”中还会介绍更多策略）：

通常大多数 IT 组织都非常了解定义“审核策略”的需求以及这些相关的类别，但是“审核策略”只代表其中一部分解决方案。SACL 在实现全面审核计划方面也扮演着一个重要角色。两个特定的“审核策略”类别（审核目录服务访问和审核对象访问）完全取决于 SACL 在安全事件日志中返回的信息。那么 SACL 究竟是什么？

每个对象（文件、注册表或目录服务）都有一个“访问控制列表”(ACL)，其中包含一个或多个被分为以下两种类型的“访问控制项”(ACE)：“随机访问控制列表”(DACL) 和 SACL（后者定义的设置会记录试图对安全对象进行的访问）。SACL 中的每个 ACE 都指定了应记录在安全事件日志中的特定托管人的访问尝试类型。ACE 用来定义对指定对象的成功和/或失败的访问尝试记录。图 2 显示的是对某个对象使用 SACL 以生成特定访问类型的事件。

了解“审核策略”与 SACL 之间的关系至关重要，因为在涉及环境中的变更时，需要通过配置来捕捉“正确”的审核事件。如前所述，“审核目录服务访问”和“审核对象访问审核策略”只允许在安全事件日志中针对那些特定类别生成审核，如果某个对象在其 SACL 中配置了审核 ACE，则只生成事件。当这些条目准备就绪后，安全事件将由 Windows 本地安全机构 (LSA) 生成并被写入安全事件日志。

事件由两个截然不同的区域组成：标头 - 它是静态的，预先为每个事件标识符（事件 ID）都做了定义；正文 - 它是动态的，不同的事件包含不同的详细信息。图 3 显示了 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 子类别，请键入以下内容：

auditpol /list /subcategory:*

auditpol /get /category:*

请注意，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 命令来执行：

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

此功能在尝试跟踪 Active Directory 对象的变更时尤为有用。对于“目录服务变更”，这些变更出现在一对 Event ID 5136 事件中，如图 5 所示。每个事件在事件正文中都有目录服务“对象”、“属性”和“操作”。对于针对包含现有数据的属性的变更，可看到两个操作：“值已删除”和“值已添加”。对于未填充的属性，在将数据写入到该属性时只能看到“值已添加”操作。例如，当针对某个用户对象（如 telephoneNumber）的属性成功执行了修改操作后，Active Directory 会在详细的事件日志条目中记录属性的以前和当前值。

如果创建了一个新对象，则在对象创建时所填充的属性值将被记录下来。如果在域内移动对象，则以前的位置和新位置（以可分辨名称的形式）将被记录下来。在设置了相应的“审核策略”后，默认会启用“old and new”（旧与新）功能。如果您希望将某个属性保持专有，如雇员 ID 号的变更，可通过对架构进行简单的修改来明确排除这些属性。如果在架构中将该属性的 searchFlags 属性改为 0x100（值 256 -NEVER_AUDIT_VALUE），如图 6 所示，则当该属性发生变更时，“目录服务变更”事件不会发生。

最后，Windows Eventing 6.0 中一个非常不错的新功能是“Event Subscriptions”（事件订阅）。正如先前所述，访问和查看事件日志是一项非常重要的系统管理任务。新的“事件订阅”功能提供了一种方法，可在系统之间直接转发事件。“事件订阅”由收集事件的“事件收集器”和被配置为向指定主机转发事件的“事件源”组成。消耗事件的能力由 Windows Event Collector 服务（Windows Eventing 6.0 的新功能）提供，而订阅功能则被内置在 Windows Event Log 服务中。用户可以配置一个收集器，从各种事件源中收集事件，这里所说的事件源可以是 Windows Server 2008 或 Windows Vista 系统。

从事件源收集的所有数据都驻留在离散的名为 Forwarded Events (ForwardedEvents.evtx) 的事件日志中，并由收集器上的 Event Log 服务进行管理。对两个端点（收集器和源）的配置都是必不可少的，此操作可以自动进行（源上为 winrm quickconfig –q；收集器上为 wecutil qc /q）。要特别注意的是，此事件订阅功能不是为企业设计的，也不是要将事件提供给外部数据库的替换系统。

为了说明如何使用此功能，让我们假定有一个小 Web 场。您有一小组与特定网站（包括 Web 服务器和 SQL 服务器）关联的系统。这些系统可使用新的“事件订阅”功能，将其安全事件日志信息合并到单个系统中。环境规模越大，通常需要的事件日志合并工具集也越高级。

考虑到 Windows Server 2008 的所有新功能，长期管理和存档安全事件日志信息的实际解决方案是使用集中数据库来存放审核信息。“审核收集服务”是 System Center Operations Manager 2007 的一项核心功能。ACS 为转发、收集、存储和分析安全事件数据提供了一种机制。安全事件几乎是以实时的方式收集的并随后存储在中央 SQL 存储库中。利用 ACS，组织还可以为访问审核信息提供最低的权限，因为这不需要对实际审核的系统进行物理访问。让我们看一看 ACS 是如何工作的。

ACS 由三个主要组件组成。首先有一个“转发器”，它是“操作管理器”代理的一部分，可将事件日志数据从客户端传递到 ACS 基础结构。转发器将数据传递到第二个组件，即“收集器”，它是服务器端的侦听器。ACS 转发器通过 TCP 端口 51909 进行连接，它们以安全的方式与指定的“收集器”进行通信。在传输之前，事件日志数据通过规范化操作被转为 XML 格式，这意味着多余信息被去除，事件信息基于事件特定的标头和正文信息被汇总到映射字段中。信息到达收集器后，将被发送到第三个也是最后一个组件中，即 ACS 数据库。这将成为长期存储安全事件信息的存储库。在存储完毕后，可通过 SQL 查询直接对信息进行挖掘，也可使用 SQL Server® Reporting Services 以 HTML 报告的形式加以呈现。ACS 提供三个默认视图，如图 7 所示。

从性能角度看，单个 ACS 收集器每秒可处理的峰最大值是 100,000 个事件，每秒可处理的连续最大值是 2,500 个事件。出于计划目的考虑，单个 ACS 收集器最多可支持 150 个域控制器、3000 个成员服务器或 20,000 个基于默认“审核策略”设置的工作站。在一个真实的测试方案中，大约 150 个域控制器每秒显示了最多约 140 个事件，每小时峰值平均值为 500,000 个事件。在仅仅 14 天后（ACS 的默认保留设置），就有超过 150GB 的安全事件数据被存储到了 SQL 服务器数据库中。更具挑战性的“审核策略”和关联的 SACL 配置会明显生成更多的数据（每小时、每天以及全部时段）。

重要的一点是要认识到，面对如此数量的数据，没有人能够在典型的大型企业环境中查看每个事件。但是，组织不应对此处出现如此多的数据感到恐惧。了解在环境中所发生的变更是以分析大量数据为代价的。

这就是 ACS 的优势所在。通过 SQL Server Reporting Services 和 ACS，您可以将通常隐藏在安全事件日志背后的问题转换为一些易于识别的问题，就像应用程序事件日志中通过彩色编码来识别事件一样。ACS 包括一组默认报告，根据环境的特定需求来扩展这些报告是一件非常简单的事情。

以下面的方案为例：由于在环境中对外部信任问题非常敏感，因此管理层要求制定一份报告，详细说明 Active Directory Trusts 的创建过程。在进行了一些研究后，我们了解到 trustedDomain 对象是在创建信任时，在 cn=System 容器中创建的，而此容器位于 Active Directory 的特定域命名上下文中。在此容器中编辑 SACL 以审核成功创建的任何 Trusted Domain 对象后，我们即可在每次创建此类型的对象后捕获安全事件。在执行信任创建的 DC 上，它将显示在安全事件日志的 566 事件中。我们然后可以编写一个简单的 SQL 查询，从 ACS 中检索此信息：

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

要将此信息添加到报告中，可使用 SQL Server 2005 Reporting Services 中所包括的 Visual Studio® 2005 版，它是专为制定报告提供的。完成向导后，您很容易就可以创建出与图 8 中的报告非常类似的报告。而且，可能出现在安全事件日志中的任何环境变更都可以被汇总到类似的全面报告中。

现在我们已经了解了在审核时所面临的挑战和在法律和技术方面的问题，那么 IT 管理员该如何开始为其组织制定“审核计划”呢？与大多数事情一样，制定全面的审核策略是一个多步骤过程。第一步是确定要审核的内容。这包括对环境进行分析并确定哪些类型的事件和变更需要生成审核。这可以包括一些简单的项目（如帐户锁定、敏感组变更、信任创建等），也可以包括复杂的变更（如修改所在环境中的应用程序内的配置元素）。此处的关键在于管理层必须参与确定审核计划中都需要有“什么”。此练习需要书面完成并应定期重复，而不是在发生重大意外事件以后再执行。

第二步是确定涉及特定变更的审核信息如何以安全事件的形式返回。审核信息有时比较难懂并且易读性较差。在实施之前，必须在安全事件和各种操作之间建立关联，以了解安全事件的真正涵义。不能在意外事件发生后再来确定事件与操作的关系。

第三步是指当这一切准备就绪时，即当您实施“审核策略”和 SACL 时。正如前面所讨论的，您需要在目录、文件系统和注册表中定义“审核策略”设置（以允许生成安全事件）和 SACL（为关联的操作生成审核追踪），以获得在这些领域中对变更的完整描述。

接下来是第四步，也是最后一步，即收集、触发和分析。根据组织规模和需求的不同，这些可能会涵盖在 Windows Server 2008 的固有功能中，也可能涵盖在一些高级解决方案中，如 System Center Operations Manager 的“审核收集服务”功能。大多数组织所犯的一个常见错误是只设置“审核策略”而不定义 SACL。最后一步是实施技术解决方案，向组织中的负责人报告和共享数据。如前所述，大多数组织已建立了负责安全的实体，因此需要围绕有待提高效率的现有组织元素来构建审核计划。这最后一步的关键是要以有意义的方式收集信息并将其提供给那些负责了解环境中所发生变更的所有实体。

大多数 IT 组织现在已不只是仅考虑一个全面的审计计划，而是实际需要这样的计划。与先前的平台相比，Windows Server 2008 为收集和分析安全事件数据提供了增强的机制。先进的收集和报告技术（如 ACS）使过去因事件数量和分布原因而晦涩难懂的问题变得明朗起来，使这些变更立刻变得一目了然。

与大多数 IT 问题一样，过程是主要的挑战。必须通过更多的配置和分析才能捕捉到 IT 经理的预期目标，因此要想从容应对这些挑战，必须深入了解环境的要求和 Windows 平台的功能。祝您成功。