如果创建了一个新对象，则在对象创建时所填充的属性值将被记录下来。如果在域内移动对象，则以前的位置和新位置（以可分辨名称的形式）将被记录下来。在设置了相应的“审核策略”后，默认会启用“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 中检索此信息：

要将此信息添加到报告中，可使用 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 平台的功能。祝您成功。