在信息技术世界里，变更是永恒的。如果您的 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 组织的一些期望。
#p#
Figure1法规以及它们对 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 在安全事件日志中返回的信息。那么 SACL 究竟是什么?每个对象(文件、注册表或目录服务)都有一个“访问控制列表”(ACL)，其中包含一个或多个被分为以下两种类型的“访问控制项”(ACE)：“随机访问控制列表”(DACL) 和 SACL(后者定义的设置会记录试图对安全对象进行的访问)。SACL 中的每个 ACE 都指定了应记录在安全事件日志中的特定托管人的访问尝试类型。ACE 用来定义对指定对象的成功和/或失败的访问尝试记录。图 2 显示的是对某个对象使用 SACL 以生成特定访问类型的事件。
图 2对某个对象使用 SACL
了解“审核策略”与 SACL 之间的关系至关重要，因为在涉及环境中的变更时，需要通过配置来捕捉“正确”的审核事件。如前所述，“审核目录服务访问”和“审核对象访问审核策略”只允许在安全事件日志中针对那些特定类别生成审核，如果某个对象在其 SACL 中配置了审核 ACE，则只生成事件。当这些条目准备就绪后，安全事件将由 Windows 本地安全机构 (LSA) 生成并被写入安全事件日志。
事件由两个截然不同的区域组成：标头 - 它是静态的，预先为每个事件标识符(事件 ID)都做了定义;正文 - 它是动态的，不同的事件包含不同的详细信息。图 3 显示了 Windows Server 2008 安全事件示例中的这两个元素。了解这些事件的组成对任意审核项目的分析阶段而言都非常重要，并且对于了解在各种工具(如 ACS)中如何返回信息也具有特殊意义。
【编辑推荐】
