在 SQL Server 2008 中进行审计
概要：关于SQL Server 审计，SQL Server 2008引入了一项重要的新特性，即为企业级客户提供了一种真实的审计解决方案。虽然SQL跟踪能很好的满足大多数审计需求，SQL Server审计提供了一些具有吸引力的优势，藉此可以帮助DBA更容易的达到像满足合规性需求这样的目标。包括提供了审计日志的集中存储，系统中心集成，以及更加显著的性能。可能最显著的是，SQL Server审计允许粒度审计，据此审计可以对特定的对象采取具有针对性的行动。本文对引入的新特性以及相应的使用说明，进行了全方位的描述，并提供了一些实例。
任何数据安全性策略最重要的一项能力是能追踪谁访问过或者企图访问你的数据。这提供了检测未授权的访问企图或者有必要，能找到内部有恶意的人员误用了他们的合法访问的能力。另外，丰富而强大的跟踪能力能对管理员对敏感配置所做的更改进行监督。
在当今的信息时代，此种考虑更加贴近实际。数据收集、存储、使用以及滥用都在以前所未有的速度增长。世界范围内的政府和私营部门组织，通过建立各种合规制度，以提高对那些持有数据的管理。其中一些广为人知的例子包括：
欧盟数据保护指令，一项严格的对欧盟和全球经济都有影响的数据保护政策。
HIPAA,健康保险携带和责任法案，美国法律的一部分。
萨班斯 - 奥克斯利法案，美国法律管辖企业的一部分。
支付卡行业数据安全标准，主要的信用卡公司授权，在世界各地都有影响。
这些正式的法规对世界各地的所有行业，各种规模的组织都产生了影响。为了确保他们的IT平台和实践相兼容，他们给组织施加了巨大的压力。最终，这些需求被传达给了管理数据的DBA，开发者以及IT专业人士。
提供一种满足这些需求并如此高效的数据管理平台是非常重要的。为了满足这些需求，SQL Server 2008引入了一种丰富而高度集成的审计能力，（这种能力）能对造地微软SQL Server数据库软件提供重大的改进。
本文将重温SQL Server2008最新的审计特性，并将其与过去的版本进行比对，在此过程中将贯穿一些实例。
在SQL Server 2005及早期的版本中，通过使用一组工具组合来实现审计。在服务器级别，登陆成功或失败的记录都记录在Windows操作系统的应用日志和SQL Server的错误日志里。登录触发器，服务器触发器，DDL触发器能对特定类型事件进行自定义审核。详细的活动审计工具的首选却是SQL 跟踪工具。SQL 跟踪工具是一种监测SQL Server数据库引擎所涉及的广泛范围内的内部事件的机制。它被用来侦听死锁，监测应用程序的性能，调试，以及其他一些扩展或管理目的。由于（SQL Trace）能捕捉包括用户ID在内的所执行的单条语句，因此作为一种审计工具非常有用。
但作为审计工具，SQL Trace有它自身的局限性。配置个管理跟踪要求使用单独的工具，那就是SQL Server事件探查器。该工具被多数开发者和管理员所喜爱，但它没有被继承到SQL Server Management Studio中，主要的SQL Server管理界面。而且，它的接口不关注具体任务的创建和管理信息的审计。在Transact-SQL级别，跟踪是通过一组以不可见的数字代码作为参数而不是做诱人的管理API集合的系统存储过程来配置的。
在SQL Server 2005中的跟踪功能以编程的方式通过Server管理对象进行访问。然而，SMO跟踪类依赖于SQL Server事件探测器授权的二进制跟踪定义文件，因此他们并不真正作为一个独立的API，用于管理服务器审计。
最终，由于SQL Trace是一类多用途工具，因此它并不能完全对审计员关注的问题进行解答。当作为一种审计工具使用的时候，SQL Trace捕获报表。但这并不需要对某一用户读取或修改的信息全部暴露。当真正的问题如“谁从该（数据库）表中读取了数据？”出现后，报表可能会涉及到视图，存储过程或用户自定义函数这些案例将会被要求进行深入分析。
以上所有的工具描述在SQL Server2008中依然存在，他们对于各种各样的需求依然有用。但SQL Server2008对于（数据库）表赋予了一种新的，更加专注的，更高度集成的审计能力。
SQL Server 2008企业版通过在数据库引擎中引入本机审核功能，从而增强了服务器的审计能力。新的SQL Server审计特性保留了SQL Server2005审计解决方案的所有能力，并增强了如数据目标审计和细粒度审计的灵活性。
在SQL Server 2008中，SQL Server 审计特性有意替代SQL Trace作为首选的审计解决方案。SQL Server审计的目的在于提供丰富的审计功能与唯一审计功能，不像SQL Trace，还用于性能调试。最终，设计SQL Server审计的主要目标如下：
安全性—审计功能及其对象，必须真实安全。
性能—必修尽量减少对性能的影响。
管理—审计功能必须易于管理。
可发现—以审计为中心的问题，必须易解答。
随后的章节将逐一讨论如何实现上述设计目标。
如前面提到的，SQL Server审计现在对服务器进行本地审核。这得益于新SQL Server审计在性能上的优势与允许审计对象作为第一类数据库对象被创建。作为第一类对象，意味着通过Transact-SQL DDL 语句（如果你喜欢的话，也可以通过SQL Server管理工具）进行审计对象的创建和操作。此外，通过数据库的熟悉的权限模型保证审计对象的安全。
当审计对象被创建时，必须指定审计事件的目标。典型的目标是大多数情况下都适合的文件。然而，在SQL Server 2008中，审计事件同样可以被写入Windows应用程序日志。这有利于在某些情况下，访问审计信息，通过管理应用程序进行整合。另外，学Windows安全日志那样能将审计作为一个目标进行标记（开始于Windows Server® 2003操作系统）的非常安全意识将大受欢迎。这样做的意义在于，Windows安全日志被认为是抗篡改和不可抵赖的。使用安全日志的另一个好处是微软系统中心操作管理器的审计收集服务能被用来从多台机器中安全的收集审计信息并产生综合报告。
最终也是最重要的要提的一点是，在SQL Server 2008中的SQL Server审计是可以指定粒度进行审计。审计活动用户，角色或组数据库对象，能够被限制到表级别以下。这也就是说，你能针对SQL Server审计来追踪指定的活动用户或降到单表级别以下的用户。例如，SQL Server审计允许一条记录由所有的工资表更新以DBO的方式组成。
审计是数据库安全战略的一个重要组成部分，正如SQL Server审计功能自身必须是具有高度的安全性和安全对象。因为它是数据库对象，创建，删除，或修改审计对象的权限，都是通过数据库引擎的权限模型和执法管制来控制的。SQL Server审计功能引入了一种新的服务器级别的被称为权限ALTER ANY SERVER AUDIT的允许主要创建，修改，删除审计或服务器审核规范对象的权限。审计规范能言简意赅的作为一个对象，在审计中捕捉活动的对象进行描述（更详尽的描述参见后文）。
审计日志显然是一个需要保护的资产。必须仔细考虑审计数据发往哪里。理想的情况是，审计信息应当发往一个甚至是系统管理员都不能被修改或篡改的地方。为达到此目的的一个简单的策略是将审计事件发送到一个只有读权限的SQL Server账户的共享的文件中。具有审计师潜力的人很显然想访问这些数据但没人（能真正访问到）。还有，如果是共享在不同电脑上，很可能会受到和Windows管理员（SQL Server所在的电脑）同样的保护，虽然明显有一些性能上的考虑以及网络中断的脆弱性。另一种选择是Windows安全日志。这对于想将SQL Server审计日志本地化存储又想从系统管理员甚至是本地Windows管理员处得到保护的人来说，是一个不错的选择。最后一点—SQL Server不加密或以其他方式保护审计日志。这样附加的保护层得以应用，当然，对于SQL Server可以通过一种外部手段，如文件系统加密。
如果，无论出于何种理由，SQL Server审计时无法将审计事件写入审计目标，你可以配置设计对象来关闭服务器实例。虽然关闭服务器实例看起来似乎很严重，但对于某些场景，如为了确保其处于非活动状态被审计的情况下服务器无法操作这类通用标准的要求还是有必要的。要以这样的表现方式来配置审计，进行CREATE 或 ALTER AUDIT DDL操作时必须另外拥有SERVER SHUTDOWN 服务器权限。如果由于SQL Server审计导致服务器无法启动，那么可以通过 -m 跟踪标志（命令）来启动SQL Server并使服务器启动。SQL Server审计自身不会停止，只有关机行为会被禁止。需要注意的是通过 -m启动SQL Server只在单用户模式下，同时为了允许DBA启动数据库，在需要的时候对SQL Server审计配置进行更改。另外， -f 跟踪标志适用于在最小配置模式下启动SQL Server，这种情况下审计被禁止当审计DDL仍然能使用。在实际应用中， -m 标志命令能满足大多数情况下对SQL Server审计重配置的要求。 如果因写审计事件失败而没有触发关闭SQL Server实例（的事件），审计记录会怎样被处理？答案是，审计事件被缓存在内存中，直到他们能被刷新到新的目标。如果这些记录占满缓存而没有被写入审计日志，服务器将导致新的审计记录无法写入，直到缓存空间被释放或审计失效。不同的内存缓冲区，大小也不相同，但在默认情况下，每个审计缓冲区大约是4M的容量，这样的空间可以容纳至少170个审计事件（准确的数字依赖于每个事件所包含的数据量）。如果在操作系统返回一条错误信息之前问题没有被纠正，如磁盘写失败，审计会话将处于离线状态并将对应的错误写入服务器错误日志；所有的缓存和新的审计事件将被丢弃。问题被纠正后，为了恢复审计，审计对象将重启。如果无法忍受审计记录丢失，审计（功能）应该被配置为关闭而不是继续写入失败。为了确保审计日志的事件捕捉和服务器上活动的事件之间的高度同步，SQL Server审计可以将写审计到日志配置为同步方式，也就是事物将被阻塞直到事件被写到目的地。很明显这将对服务器的性能带来不利的影响。在大多数情况下，推荐以异步的方式进行审计日志的写入。如下所述，写入的时间长度可以配置；从默认的一秒钟增加的时间值可以提高服务器的性能。 最后需要强调的一点是服务器审计对象本身的状态有任何变化都会被记录到审计日志中。这是SQL Trace的短处，但这是一个很重要的功能，因为可能会捕获任何试图规避审计（的行为）。假设审计事件被发送到目标对象，SQL Service账户无法进行修改，该功能对于DBA来说，很好的保护了审计记录。进而，就有可能在实例的范围之内，将SQL Server审计配置成能记录所有定义的审计对象的改变，不仅是眼前的服务器审计对象（该配置可以通过根据服务器审计规范，增加 AUDIT_CHANGE_GROUP来完成；在后续的文档中将会有更清晰的描述）。 SQL Server 2008引入了一种新的，名为SQL Server扩展事件的高性能的事件基础架构。SQL Server审计功能是利用其性能优势建立在扩展事件上层，并且提供同步和异步写功能（默认情况下，SQL Server 审计使用异步事件模型）。需要注意的一点，审计事件是扩展事件的一种保护类型，因此CREATE/ALTER/DROP SESSION EVENT命令不能直接操作SQL Server审计。更多关于扩展事件的信息，参看SQL Server在线书籍。 默认情况下，出于性能方面的考虑，审计事件以异步方式写入到审计目标。当对于写入到审计日志的审计记录有严格的要求，希望对性能退化有些考量的时候，你可以选择同步方式进行写入（准确的数额取决于量和生成的审计记录的类型）。异步或同步方式的选择，由 CREATE AUDIT DDL（后续说明）操作决定；默认情况下，该值（查询延迟的值）为1000，也就是SQL Server审计队列的审计记录 了一秒，然后写入目标。在冗余允许的条件下，你可以将该值设大一些以提高性能；这样做的代价是与实际的数据库活动，活动记录在日志中可能会越来越不同步，如果在服务器上出现致命的错误会导致记录丢失的风险大增。为了确保同步记录SQL Server审计，将 QUEUE_DELAY的值设为了0.
有针对性的审计也有助于减少对其对于性能的影响。显而易见的策略是：限制审计对于精确的操作集不产生太大的兴趣。细粒度审计功能的SQL服务器审核允许审计配置为目标的具体行动、主体和对象(小到单一表的级别)。因此,资源不能被浪费在不必要的审计信息生成上。同SQL跟踪相比,这通常会生成大量的记录并依赖后过滤(post-filtering)来提供有针对性的审计。
因为对于结构化的SQL Serer审计，取得最佳性能的方法通常是使用一个文件作为审计目标。当然，不同审计目标之间的性能差异是高度依赖于审计配置等选项的。
SQL Server 2008的审计功能是完全可控的，它主要管理接口,特别是SQL Server管理工作室,服务器管理对象(SMO),和主题DDL。
在SQL Server Management Studio中，服务器级别的审计配置在用户界面的安全文件夹下。两个相关的子文件夹是审计和服务器审计规范。数据库级别的审计配置在数据库审计规范子文件夹中，在每个数据库的安全文件夹下可供使用。
相比早期版本，审计配置完全可以通过SMO（SQL Server 管理对象）以编程的方式进行管理，使用 Microsoft.SqlServer.Management.SMO命名空间中的对象。最终，与使用系统存储过程来配置SQL Tace相比，SQL Server 审计使用明确的SQL DDL语法来创建，管理和安全审计。
审计数据能被写入二进制文件或者Windows事件日志（应用日志或者安全日志）。当写入文件的时候，审计数据通过内置的表值函数，该函数允许使用常规的SELECT语法来查询审计记录。写入到事件日志中的事件信息可以通过事件查看器或特定的事件日志管理软件进行操作，如微软系统中心操作管理器。访问和分析审计数据的细节将在后续文章中进行讨论。
除了提供一个鲁棒(健壮)的基础结构收集审计资料，SQL Server 2008更容易满足特定的审计需求。审计记录基于对数据库中对象的权限检查而被捕获。这意味着，例如，一个对于表A的Select查询记录，不管实际的SQL语句是否引用了表A，视图，存储过程，或者另一个对象，都不会有变化。
同时，SQL Server 2008允许细粒度审计标准的定义。审计可以从局限于单个表，到特定的DML操作(例如，DELETE删除与SELECT选择)和特定的主体。这种粒度可以降低那些必须满足一组特定需求的审计数据存储和分析的总量。
理解和管理审计在SQL Server 2008中的设置，最好从三个主要对象开始，以此来描述审计。
服务器审计对象对审计数据的目标进行了描述，外加高级别的配置设置。将一个服务器审计对象作为审计片申明或目标。该目标可能是文件，Windows应用程序日志，或者是Windows安全日志。事件写入目标的延迟许可在该对象上也能配置。要注意的是服务器审计对象并不包括被审计的内容—而仅仅是审计数据的去向。可以定义多个服务器审计对象，每个对象的制定和运行相互独立。 服务器审计规范对象描述了审计的含义。正如其名字所示，该对象专注于服务器实例的行为。 以服务器审计规范与服务器审计相关联的方式来定义审计数据所要写入的位置。在服务器审计规范对象与服务器审计对象之间是一对一的关系。数据库审计规范同样描述了审计的含义。但是正如其名所示，该对象专注于发生在特定数据库上的行为。审计数据所要写入的地方是由服务器审计对象相关联的数据库审计规范来定义的。每个数据库审计规范仅与一个服务器审计对象关联。服务器审计，作为它的一部分，仅与每个数据库的数据库审计规范相关联。
下图一描述了定义整个审计制度的对象之间的交互。
图一中所有对象之间的关系是可调配的。当然，没有至少一个服务器审计与一个规范（服务器或数据库），审计就无法生成任何数据。所有这些对象—服务器审计，服务器规范和数据库审计规范—运用DDL能进行完全管理，SQL Server Management Studio administrative的管理界面或SMO。
我们来追溯审计定义的每个细节部分。
图 1: 审计对象的结构
服务器审计通过 CREATE SERVER AUDIT语句创建。除了名字之外，最重要的是创建时指定的服务器审计是审计数据的目标。在SQL Server2008中，可用的目标有二进制文件，Windows应用程序日志，Windows安全日志（需要特定的权限—在后续讨论—以写入到安全日志中的SQL Server服务账户）。对于文件的目标，用户必须至少提供文件路径和可选（项），滚动更新文件的最大尺寸和最大数目。SQL Server名称的审计文件自动运行，依据以下格式：<audit_name>_<audit_guid>_nn_<timestamp_as_bigint>.sqlaudit 当活动的审计文件达到指定的最大大小，它将自动翻转到一个新的文件。此过程继续进行翻转到由MAX_ROLLOVER_FILES参数指定的最大数目。当达到或假设达到最大数目的更新文件，SQL Server就开始从时间最久的开始，删除一些现有的审计文件以创建新文件。请注意如果删除操作由于任何原因而失败，审计会继续进行。
从可选择性上讲，审计可以保留在启动时的最大磁盘空间上。当然，SQL Server服务账户必须有写入目标文件夹的权限。
为了提供安全性能上的权衡控制，在服务器审计上可进行队列延迟的配置。若该值为0，那么审计记录与生成记录的行为是同步的。另外，可以指定毫秒级单位的队列延迟，以减少在负载下对性能的影响。最小的延迟值为1000毫秒（默认值）。
为了满足最严格的安全要求，服务器审计可以有选择地进行配置，以便如果审计失败SQL Server将关闭。例如，如果审计日志中的目标驱动器变得不可用，SQL Server关闭，可以手动重新启动-m命令开关，除非关机的根本原因被纠正。
默认情况下，创建的服务器审计处于禁用状态。这样可以用DDL覆盖以使审计能立即可用。在大多数情况下，管理员却希望在审计可用之前，能对审计进行完全配置。
服务器审计用一个GUID自动标识并且是唯一标识。为了提供分布式方案，如数据库镜像， CREATE SERVER AUDIT语句允许GUID被明确指定。设计被创建后，GUID不能在改变。
下面的DDL例子显示了创建一个名为PCI_Audit的审计，将毫无延迟的写入文件，在写文件事件失败后强制服务器关闭。
Transact-SQL
CREATE SERVER AUDIT PCI_Audit
TO FILE (FILEPATH = ’F:\AuditLogs\’, MAXSIZE = 1GB, MAX_ROLLOVER_FILES = 80)
WITH (QUEUE_DELAY = 0, ON_FAILURE = SHUTDOWN)
该服务器审计初始处于禁用状态。
服务器审计在创建后通过使用ALTER SERVER AUDIT 语句可以进行修改。下面的例子将目标改成Windows应用程序日志，增加了队列延迟的值以及有关失败的设置。
Transact-SQL
ALTER SERVER AUDIT PCI_Audit
TO APPLICATION_LOG
WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE)
ALTER SERVER AUDIT语句也可以用于服务器审计的可用与不可用的状态设置。
Transact-SQL
ALTER SERVER AUDIT PCI_Audit
WITH (STATE = ON)
在活动事物的范围之外，服务器审计只能启用或禁用。
SQL Server Management Studio 的数据库审计的创建和管理都是在审计的目录里面，具体位置是在的server服务->安全 节点里面。
截图2：在 SQL Server Management Studio里面创建数据库审计
权限：在服务上的审计行为(CREATE, ALTER, or DROP)，要求要有ALTER ANY SERVER AUDIT 的授权，该权限可以由 CONTROL SERVER的权限继承。
写入Windows安全日志
写入windows安全日志特别值得一提，因为考虑到有一些额外的考虑因素。因为写入Windows安全日志是特权很高的操作，SQL Server服务账户被授予SeAuditPrivilege （也被称为“生成安全审计”）特权。虽然这也可以通过本地安全策略工具（secpol.msc）完成。只要将服务账户添加到 本地策略/用户权限分配/生成安全审计路径下。
此外，审计策略的粒度在SQL Server项可以被记录之前，对于Windows必须要进行修改。在Windows 2003中，使用安全策略工具修改 本地策略/审计策略/审计对象访问设置；将“成功”与“失败”设为启用。在Windows Vista ®操作系统和Windows Server 2008中，使用auditpol 命令行工具执行布命令 auditpol /set /subcategory：“生成应用程序”/成功:可用 /失败:可用。请注意在某些域环境下，域策略可能会覆盖这些设置，在这种情况下，需要从域管理员处得到协助。在WIndows XP电脑上，安装了SQL Server 2008开发版的用户，将不能将审计信息写入到Windows 安全日志，因为该操作系统不支持该功能。
CREATE SERVER AUDIT SPECIFICATION 语句可以创建服务器审计规范。在服务器审计规范创建之前，服务器审计必须存在，因为DDL需要制定一个审计名称。
服务器审计规范的主要内容是将要审计的行为组列表。可审计的操作以组的形式收集，并覆盖服务器级别的活动，如服务器的配置更改和登录/注销。这些组是硬链接，在SQL Server文档中有详细描述。
下面的语句创建了一个服务器审计规范以跟踪备份/恢复事件，SQL Server服务启动和停止，改变服务器成员的角色。
Transact-SQL
CREATE SERVER AUDIT SPECIFICATION PCI_Server_Mgmt_Spec
FOR SERVER AUDIT PCI_Audit
ADD (BACKUP_RESTORE_GROUP),
ADD (SERVER_STATE_CHANGE_GROUP),
ADD (SERVER_ROLE_MEMBERSHIP_CHANGE_GROUP)
WITH (STATE = OFF)
使用 ALTER SERVER AUDIT SPECIFICATION 语句 创建服务器审计后，服务器审计规范可以被重新分配到不同的服务器审计。该语句也允许更改列表中审计行为组和被标记的启用（ON）与禁用（OFF）之间的状态切换。
下面的例子给之前的语句创建的规范上，增加了一个行为组。
Transact-SQL
ALTER SERVER AUDIT SPECIFICATION PCI_Server_Mgmt_Spec
ADD (SERVER_PRINCIPAL_CHANGE_GROUP)
只能在事物范围之外更改审计的状态（可用或禁用）。同样，如果ALTER SERVER AUDIT语句将状态从ON改为OFF，那么在同一语句中可能不包含任何其他变化。
在SQL Server 管理工具中服务器审计规范的创建和管理都在服务器审计规范文件夹下，该文件夹是服务器级别的”安全性“文件夹。
权限
服务器审计规范（创建，修改或删除）的操作要求具有ALTER ANY SERVER AUDIT 权限，该权限包含在控制服务器里。
数据库审计规范更像服务器审计规范，但也存在某些明显的不同。如名所示，当然，数据库审计规范属于审计数据库级别的行为。如同服务器审计规范，一个预定义的审计行为组列表被用来定义规范的轨迹。
除此之外，还有，数据库审计规范允许更多的特定的审计行为被追踪。数据库中的细粒度行为很容易被当做目标。在探讨该细节之前，先考查以下语句。
Transact-SQL
CREATE DATABASE AUDIT SPECIFICATION PCI_Txn_Database_Spec
FOR SERVER AUDIT PCI_Audit
ADD (DATABASE_OBJECT_PERMISSION_CHANGE_GROUP),
ADD (SELECT ON dbo.Customer BY dbo),
ADD (INSERT ON dbo.Customer BY dbo),
ADD (UPDATE ON dbo.Customer BY dbo),
ADD (DELETE ON dbo.Customer BY dbo),
ADD (EXECUTE ON dbo.usp_SubmitPO BY public)
该规范追踪了所有属于DATABASE_OBJECT_PERMISSION_CHANGE 组的操作，假如有多个管理员在数据库中操作，用它来进行监测非常有用。另外，它也追踪由dbo用户对 Customer表的特定的DML操作，作，任何执行的 usp_SubmitPO存储过程 。 也需注意关键字public的使用，追踪所有用户所做的更改。
在SQL Server 2008中，这种细粒度行为的定义是与他们的服务器级别的数据库审核规范的一个关键区别。定义一个行为被审计的一般形式是：
<action> ON <object> BY <principal>
审计发生时，以任何方式采取行动（都行）。换句话说，对Customer的SELECT操作会被审计，如果用户的操作是一条Customer表上的SELECT语句，一个SELECT查询表视图，查询表的一条存储过程，诸如此类。
注意到在上述格式中的<object>涉及到的对象类似表，视图或者存储过程，又或是整个数据库或模式。对于后者，DATABASE::<db_name>和SCHEMA::<schema_name>这样的格式也被分别使用。
允许审计有局限性的集中，从而使在审计中捕捉的数据量最小是需要首要指定的。为了审计所有主体的行为，可以指定公众的角色。例如，接下来的操作记录了在MyDB数据库中所属MyDBRole角色的任何用户的所有对象上的所有SELECT（行为）。
Transact-SQL
SELECT ON DATABASE::MyDB BY MyDBRole
如服务器级别的规范，数据库审计规范可以在创建或通过ALTER DATABASE SERVER SPECIFICATION语句来启用或禁止。ALTER语句也允许修改设计行为列表和行为组。
在SQL Server Studio中，数据库审计规范在数据库审计规范文件件下进行创建和管理，这是数据库级别的”安全性“文件夹下的数据库中问题。
权限
服务器审计规范（创建，修改或删除）的操作要求具有ALTER ANY SERVER AUDIT 权限，该权限包含在控制服务器里。
在我们进入到审计数据怎样读取和使用之前，一些技术方面的实现变得不值得一提。早些时候，有人认为SQL服务器审计是从本机到服务器。此功能有很多方面与DBMS结合更加紧密，其中最重要的是审计事件被触发的方式。在SQL Server 2008中审计是通过与发生在数据库引擎内部的权限检查相挂钩的方式来实现的，如果相关审计被指定的话，SQL Server审计有机会产生审计记录。也就意味着对一个对象所有形式的访问都会被审计。
SQL Server审计需要注意的第二个方面是它的内部事务行为。关于这点有两方面。第一，审计本身与事务边界的交互如何操作。所有审计有关的DDL语句，包括CREATE SERVER AUDIT语句，在活动的事务内可以执行，除非他们触发了对事务状态的改变。若在一个事务中，创建的审计将限定在事务范围之内—将提交或回滚事务。
另一方面，当可审计的事件发生在事务中如何被记录。简单的说：他们一直被审计。很显然，如果数据可以被读取，这将减少安全隐患，但没有审计记录，因为一个待审计的事务被回滚。因此，记录审计事件的发生而不管事务范围和回滚是否发生。
本节包含关于你能使用和应用由SQL Server审计所产生的数据的方法的信息。
当SQL Server 2008服务器审计的审计目的地被配置为文件选项时，审计数据将被写入到磁盘上的二进制文件中。目标位置可以是本地文件夹或者是网络共享的UNC路径。
尽管服务器审计可以指定审计文件创建的路径，文件名是由SQL Server自动生成。文件名格式如下：<audit_name>_<audit_guid>_nn_<timestamp_as_bigint>.sqlaudit。
在这种模式下，nn是一个连续的以递增方式产生的新的审计文件的分区号，如果审计配置允许翻转到新的文件。
审计文件可能会被写入到由NTFS加密保护的文件中，并提供SQL Server服务账户有适当的权限。还允许写入到采用NTFS压缩的文件夹中。在两种情况下，当然，会有些性能影响。如果审计文件的目标位置是远程文件共享，审计内容在进行网络传输时不会被加密。
如上述提及到的，审计文件是用二进制格式（存储）并不允许用文本编辑器读取。SQL Server提供了一种称为fn_get_audit_file()的用来读取审计数据的表值函数。该函数所使用的参数如表1所示。
参数名 类型 描述
File_pattern
nvarchar
目录或路径和文件名说明了位置和审计文件设置为可读取。一个 星号通配符是允许的。可以是本地或UNC路径。
Initial_file_name
nvarchar
指定路径和从文件集中开始读取的文件的文件名。
Audit_file_offset
bigint
在initial_file_name参数中已知的文件位置。在该字节偏移量开 始阅读下一条记录。
表 1: fn_get_audit_file()函数的参数
下面的语句表示为指定的审计读取所有审计文件。
SELECT * FROM fn_get_audit_file(
'D:\Audits\MyAudit-_C26128D1-F97B-4B82-9E47-B6A296045B05_*.sqlaudit',
default, default)
下面是读取 E:\SqlAudits\ 文件下所有的审计文件的例子。
SELECT * FROM fn_get_audit_file('E:\SqlAudits\*', default, default)
这些示例是为指定的审计在已知偏移量时读取所有审计记录。
SELECT * FROM fn_get_audit_file(
'D:\Audits\MyAudit-_C26128D1-F97B-4B82-9E47-B6A296045B05_*.sqlaudit',
'D:\Audits\MyAudit-_C26128D1-F97B-4B82-9E47-B6A296045B05_0_128439520854140000.sqlaudit',
5120)
顺便提一句， initial_file_name 和audit_file_offset 参数可以通过从fn_get_audit_file()函数最后一次调用的输出中，分别查看initial_file_name 和 audit_file_offset 列来确定。
理所当然的，因为这是一条来自表值函数，一条WHERE 子句，ORDER BY子句，和其它标准的SQL SELECT语法可以用来塑造的结果集的SELECT语句。
因为fn_get_audit_file()函数以参数的形式提供了明确的路径，可以讲不活动的审计文件移动到新的位置并使用该函数进行读取。在这一点上，审计文件只是静态的数据。因此他们不在接受审计事件时，可以随意移动和查询审计文件。这样做的好处是，多个服务器上的审计文件可以合并在一个文件夹并作为一组集合进行查询。以此方式，管理员或审计员可以很容易的通过一个分布式的SQL Servers集合对关键事件进行查找。
fn_get_audit_file()函数返回了一组由SQL 服务器审计捕捉的丰富信息。提供多达二十多列，从如下几个方面：
事件的日期和时间，它是否成功（或权限被就绝）
事件的用户上下文（在服务器和数据库级别的主要ID和名字）
操作类型（如SELECT，EXECUTE，DELETE）
目标对象
连接上下文（服务器和实例，数据库，模式）
审计事件（若是可应用的）触发的真实的Transact-SQL语句
在文件中的审计文件名和审计记录的位置
对于一些特殊事件的其它XML信息，如审计管理事件
很明显，关于每个审计事件，都提供了大量的信息。其中一列，声明，包含了引起审计事件行为的实际文本，尽管语句中的实际数据值如果是参数化的，而可能没有显示。需要注意的是，这可能没有直接命名审计资源。例如，在表1上的SELECT审计事件可能由引用了表1的视图1上的SELECT引起。
声明字段的数据类型为nvarchar，长度为4000字符。在一个超过该声明大小的事件中，SQL Server 2008产生了多条审计记录，通过更多的需要捕捉完整内容的记录来传播声明文本。在审计记录中的序列号字段能使完整语句进行重组。
fn_get_audit_file()是为你的环境实现最佳的审计分析方案的起点。因为它本质上如同表一样呈现了审计数据，它提供了查询，挖掘，归档或以任何必要的方式记录的审计日志的手段。从这个意义上讲，这也许是最灵活的审计数据的三种可能的目标。
SQL Server 2008审计能都交替的配置将日志记录到Windows 应用程序日志或Windows安全日志。这可能是其具有价值的几个原因：
对于一些服务器管理员和审计人员而言，Windows事件日志的位置和格式都很熟悉。
安全日志在写，篡改和查看方面有着固有的限制，在作为审计信息的存储库方面，有一定的吸引力。
有现有的微软和第三方解决方案，旨在Windows事件日志中的整合，监测和报警。例如，微软系统中心有一个称为审计收集服务的组件，可以有选择的整合来自多个服务器的安全事件日志。同时，系统中心操作管理器产品是专门用来对Windows事件日志进行监测，报告和报警。
当服务器审计被配置为TO APPLICATION_LOG或TO SECURITY_LOG 选项时，所有审计事件被写入到相关的日志。事件包含由fn_get_audit()表值函数返回的审计文件的相同的信息。在事件日志里，该信息是以文本格式写入到事件正文中。
对于打算成立监视或警告事件日志条目的用户而言，知道是什么事件日志中的特定属性将被分配给SQL Server审计条目是非常重要的。所有SQL Server审计事件记录下了事件源的SQL Server实例的名称。事件ID为33205。事件的描述是可以发现的事件的唯一特征。因此，为了实现审计事件筛选或报警，事件日志管理工具，将用于需要支持基于描述（如正则表达式搜索）的事件的标识。
使用用户环境中一个典型的OLTP工作负载对SQL Server审计进行性能测试并与SQL Trace尽可能的进行比较。测试结果一致表明相比于SQL Trace，SQL Server审计在性能方面会有11%-45%提高。下面列出了关于使用负载的简要说明，随后的表中显示了每次负载下的各种执行时间。本次比较过程中， SQL Trace运行在C2 Audit Mode，SQL Server审计开启相同事件的审计功能并输出到一个文件。
负载1包括11个数据库，大小从1.94M到1812.5M不等。包括平均有2761行的755张表，以char 、smallint 和decimal类型的列为主。
下面是负载1的活动量汇总（负载%）：
存储过程：
sp_cursorfetch
执行 (38.72%)
语句：
ORDER BY (21.90%)
SELECT FROM (39.51%)
1,219,234条语句被执行。
负载2包括2个数据库，大小从64M到423.88M不等。包括平均49141行35张表，以bit、varbinary、int和nvarchar 类型的列为主。
下面是负载2的活动量汇总（负载%）：
执行(100%)
1,633,557 条语句被执行
负载3包括3个数据库，大小从1.94M到1059.63M不等。包括平均有586行的154张表，以real、numeric和float类型的列为主。
下面是负载3的活动量汇总（负载%）：
存储过程：
sp_execute
sp_prepare
sp_unprepare
执行 (94.25%)
语句：
SELECT FROM（39.87%）
585,400 条语句被执行
负载4包括1个大小3235.75 MB的数据库。具有平均144,245 行的84张表，以int, varchar, 和 datetime类型的列为主。
下面是负载4的活动量汇总（负载%）：
存储过程：
sp_cursorfetch
执行 (95.89%)
语句：
SELECT FROM（39.87%）
3,435,303 条语句被执行
负载5包括一个大小174.94 MB的数据库。平均具有4108行的152张表，以 char和， numeric, int 和 float类型的列为主。
下面是负载5的活动量汇总（负载%）：
存储过程：
sp_cursorclose
sp_cursorfetch
sp_cursoropen
执行 （78.58%)
语句：
SELECT FROM（26.96%）
296,642 条语句被执行
Workload Base Time (min) SQL Trace (min) SQL Server Audit (min) Perf Cost Vs. Base Perf Gain vs. Trace
1
13.30
15.89
14.13
6.24%
11.08%
2
41.30
101.85
55.93
35.42%
45.09 %
3
5.09
6.29
5.57
9.43%
11.45%
4
63.36
76.64
68.13
7.53%
11.10%
5
3.59
4.76
4.00
11.42%
15.97%
表2：SQL Server Audit vs. SQL Trace的性能数字
在表2中， PERF COST VS BASE的计算式： (SQL AUDIT– BASE TIME) / BASE TIME，PERF GAIN VS TRACE的计算式：(SQL TRACE – SQL AUDIT) / SQL TRACE。
SQL 跟踪和SQL Server审计的改善，从 11.08% 到 45.09%不等,负载2 显示两者之间的巨大区别。这很可能是在I/O文件中注重SQL Server审计的高效，从而负载产生了大量的审计事件 的一个结果 。从表中还观察到，SQL Server审计的运行成本从 6.24% 到 35.42%不等。请记住，这些值是大量的审计行为组启用产生的，跟较为温和的审计设置放在一起， 成本较低。因为SQL跟踪缺乏像SQL Server审计这样的细粒度审计能力，在这种情况下，两者之间的性能比较是不可能的。
下面提供一个利用SQL Server审计功能的真实场景。
SQL Server审计的一个相对简单但非常贴切的用法就是监控授权用户访问一张敏感表。利用SQL Server 2008中的审计功能，通过定义适当的数据库审计，可以轻松实现这样的监控。比如，假定这张敏感表为hr.salary,位于数据库hr_db下，我们想检查dbo（甚至sysadmin）在什么时间试图访问该表。在这个例子中，审计信息将被写入到一个位于远程共享目录\\AuditServer\Audit的一个文件中，这个文件在SQL Server实例中只允许写但不能读或修改。
首先，我们需要创建审计和数据库审核规范“对象。
Transact-SQL
USE master
CREATE SERVER AUDIT audit1 TO FILE (FILEPATH='\\AuditServer\Audit')
USE hr_db
CREATE DATABASE AUDIT SPECIFICATION hr_dbspec FOR SERVER AUDIT audit1
ADD(SELECT,UPDATE,INSERT,DELETE ON hr.salary by dbo)
由于创建对象默认情况下禁用，他们需要同时启用。
Transact-SQL
USE master
ALTER SERVER AUDIT audit1 WITH (STATE=ON)
USE hr_db
ALTER DATABASE AUDIT SPECIFICATION hr_dbspec WITH (STATE=ON)
在这一点上，审计被所有的查询反对的hr_db的表由dbo或sysadmin被记录下来，作为任何行动，启用或禁用审计。
要确认已启用，无论是审计和审计规范，系统视图可以进行查询。
Transact-SQL
SELECT is_state_enabled FROM sys.server_file_audits
SELECT is_state_enabled FROM sys.database_audit_specifications
一些遵从性法规要求访问和加密密钥的使用需要审计。SQL Server审计有能力记录所有活动的触摸对称加密密钥或数字证书的私钥或非对称密钥对。简要的说，这些活动在服务器和数据库级别通过DATABASE_OBJECT_CHANGE_GROUP行为组而涵盖。DATABASE_OBJECT_CHANGE_GROUP行为组涵盖了所有的涉及到密钥用法，还有在数据库中CREATE, ALTER, 和DROP对象，不包含在模式之内。除了数据库从最初的初始化期间，CREATE, ALTER, 和DROP事件应当处在低水平，这意味着捕捉该行为组的活动在加密密钥活动的限制之下。例如，审计的创建使用SQL Server Management Studio将被展示出来。为了创建审计对象，在实例下扩大安全树，右击Audits，然后点击 New Audit。将会打开如图3所示的 Create Audit对话框，你可以配置对审计属性进行配置。
图3：Create Audit对话框
如果默认值是可以接受的，唯一有输入要求是File path，假设审计目标是文件。注意到 SQL Server Management Studio基于时间戳创建了默认的审计名称。接下来必须创建服务器和数据库审计规范。可以通过分别在Server Audit Specifications和对象资源管理器中的Database Audit Specifications上点右键来完成（如图4）。
图4：通过 SQL Server Management Studio创建数据库审计规范
对于数据库审计规范，会出现图5所示的创建数据库审计规范（Create Database Audit Specification）对话框。
图5：创建数据库审计规范对话框
上一步所创建的审计对象需要在审计（Audit）下拉列表中被选中。之后从审计动作类型（Audit Action Type）下拉列表中选中DATABASE_OBJECT_CHANGE_GROUP。
创建服务器审计规范的步骤是十分相似的。这里，可以通过在对象浏览器中右键点击开启审计及相关规范。
在审计开始运行后，管理员可以充分利用基于策略管理的能力来管理多服务器上的审计，以查明他们是否已运行，以及配置是否恰当。对于PBM基本的理解在随后的讨论中假定；更多的信息，参看SQL Server联机丛书。
创建策略以确定审计或审计规范是否启用时相当简单的。创建一个策略报告服务器是否有审计被启用，新的条件需要使用审计方面和表达式来创建，以评估@Enabled的值是否为真（如图6）。
图6：PBM创建新的条件对话框
注意名称（Name）一栏中的值是任意的。由于创建了条件，新的策略也应该被建立。在这个例子里，新的策略名为AuditOnPolicy，而检查条件（Check Condition）中的值被设定为已创建的AuditOn条件。（图7）
图7：PBM创建新的策略对话框
点击OK 创建策略，将评估是否在服务器上启用审计对象（或者服务器，如果评估已通过Registered Servers 对话框进行初始化）。策略评估提供了在实例中定义的审计对象清单，并说明他们是否处于活动状态。在图8中显示的评估结果表明审计未启用。
图8：PBM评估策略对话框
要注意的是在该版本SQL Server中，审计对象是只读的。正因如此，点击 Configure 会返回一条错误信息。最后，应建立类似的策略，以确定审计规范是否启用。
当然，知道审计可以启用是很重要的，但验证审计是被恰当配置的同样有趣。虽然无法决定审计规范中是否定义了一个如DATABASE_OBJECT_CHANGE_GROUP这样的行为组，可能不是很明显，但不是不可能。因为审计行为组没有PBM（Policy Based Management 基于策略的管理）的存在，策略可能会被作为T-SQL查询替代，来决定在审计规范中是否包括了一组特定的行为组。这里提供了这样的查询。
Transact-SQL
SELECT 1
FROM sys.server_audits AS a
JOIN sys.database_audit_specifications AS s
ON a.audit_guid = s.audit_guid
JOIN sys.database_audit_specification_details AS d
ON s.database_specification_id = d.database_specification_id
WHERE a.is_state_enabled = 1
AND s.is_state_enabled = 1
AND d.audit_action_name = N'DATABASE_OBJECT_CHANGE_GROUP'
如果活动的审计包括了由DATABASE_OBJECT_CHANGE_GROUP行为组创建的规范，查询将返回1。在PBM中要创建基于该查询的一个制约，像下面这样做：
创建一个新的制约条件和表达式。点击“...”按钮，弹出Advanced Edit对话框。
向下滚动Functions and properties列表，双击 ExecuteSql()。填充“ExecuteSql(string returnType, string sqlQuery)”文本单元格的值。你可以编辑该字符串，替换字符串类型为‘numeric’，与上面的SELECT语句中的字符型的sqlQuery（如图9；注意在查询中的单引号必须避开另一个单引号）。
图9：PBM Advanced Edit窗口
3.点击OK按钮，返回Create New Expression对话框，设置Operator 为= ，值为1以完成表达式。
4.设置Facet 为Database因为你希望查询每个数据库实例的评估。
在评估时，使用该表达式的策略将帮助管理员检测数据库是否被恰当的审计。
在SQL Server 2008中引入的新的SQL Server 审计功能表示了对早起SQL Server版本提供的审计能力的显著改善。其中核心的优势是引入了细粒度审计，据此，事件可以有针对性的特定行为，特别是主要的对象；对象甚至可以被限制在单表级别。性能是另一个诱因，因为SQL Server审计的性能显著优于SQL Trace，在某些情况下，达到45%左右。另外，审计目标不在局限于文件，因为Windows应用程序和安全日志现在是可选的。并考虑像审计实例重新启动和非自愿的变更记录的审计状态之间的状态持久性的好处，新的SQL Server审计功能为企业提供了一个稳健的，全面的审计解决方案。
本文地址：http://www.oschina.net/translate/auditing-in-sql-server-2008
原文地址：http://msdn.microsoft.com/zh-cn/library/dd392015.aspx
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们
概要：关于SQL Server 审计，SQL Server 2008引入了一项重要的新特性，即为企业级客户提供了一种真实的审计解决方案。虽然SQL跟踪能很好的满足大多数审计需求，SQL Server审计提供了一些具有吸引力的优势，藉此可以帮助DBA更容易的达到像满足合规性需求这样的目标。包括提供了审计日志的集中存储，系统中心集成，以及更加显著的性能。可能最显著的是，SQL Server审计允许粒度审计，据此审计可以对特定的对象采取具有针对性的行动。本文对引入的新特性以及相应的使用说明，进行了全方位的描述，并提供了一些实例。
任何数据安全性策略最重要的一项能力是能追踪谁访问过或者企图访问你的数据。这提供了检测未授权的访问企图或者有必要，能找到内部有恶意的人员误用了他们的合法访问的能力。另外，丰富而强大的跟踪能力能对管理员对敏感配置所做的更改进行监督。
在当今的信息时代，此种考虑更加贴近实际。数据收集、存储、使用以及滥用都在以前所未有的速度增长。世界范围内的政府和私营部门组织，通过建立各种合规制度，以提高对那些持有数据的管理。其中一些广为人知的例子包括：
欧盟数据保护指令，一项严格的对欧盟和全球经济都有影响的数据保护政策。
HIPAA,健康保险携带和责任法案，美国法律的一部分。
萨班斯 - 奥克斯利法案，美国法律管辖企业的一部分。
支付卡行业数据安全标准，主要的信用卡公司授权，在世界各地都有影响。
这些正式的法规对世界各地的所有行业，各种规模的组织都产生了影响。为了确保他们的IT平台和实践相兼容，他们给组织施加了巨大的压力。最终，这些需求被传达给了管理数据的DBA，开发者以及IT专业人士。
提供一种满足这些需求并如此高效的数据管理平台是非常重要的。为了满足这些需求，SQL Server 2008引入了一种丰富而高度集成的审计能力，（这种能力）能对造地微软SQL Server数据库软件提供重大的改进。
本文将重温SQL Server2008最新的审计特性，并将其与过去的版本进行比对，在此过程中将贯穿一些实例。
在SQL Server 2005及早期的版本中，通过使用一组工具组合来实现审计。在服务器级别，登陆成功或失败的记录都记录在Windows操作系统的应用日志和SQL Server的错误日志里。登录触发器，服务器触发器，DDL触发器能对特定类型事件进行自定义审核。详细的活动审计工具的首选却是SQL 跟踪工具。SQL 跟踪工具是一种监测SQL Server数据库引擎所涉及的广泛范围内的内部事件的机制。它被用来侦听死锁，监测应用程序的性能，调试，以及其他一些扩展或管理目的。由于（SQL Trace）能捕捉包括用户ID在内的所执行的单条语句，因此作为一种审计工具非常有用。
但作为审计工具，SQL Trace有它自身的局限性。配置个管理跟踪要求使用单独的工具，那就是SQL Server事件探查器。该工具被多数开发者和管理员所喜爱，但它没有被继承到SQL Server Management Studio中，主要的SQL Server管理界面。而且，它的接口不关注具体任务的创建和管理信息的审计。在Transact-SQL级别，跟踪是通过一组以不可见的数字代码作为参数而不是做诱人的管理API集合的系统存储过程来配置的。
在SQL Server 2005中的跟踪功能以编程的方式通过Server管理对象进行访问。然而，SMO跟踪类依赖于SQL Server事件探测器授权的二进制跟踪定义文件，因此他们并不真正作为一个独立的API，用于管理服务器审计。
最终，由于SQL Trace是一类多用途工具，因此它并不能完全对审计员关注的问题进行解答。当作为一种审计工具使用的时候，SQL Trace捕获报表。但这并不需要对某一用户读取或修改的信息全部暴露。当真正的问题如“谁从该（数据库）表中读取了数据？”出现后，报表可能会涉及到视图，存储过程或用户自定义函数这些案例将会被要求进行深入分析。
以上所有的工具描述在SQL Server2008中依然存在，他们对于各种各样的需求依然有用。但SQL Server2008对于（数据库）表赋予了一种新的，更加专注的，更高度集成的审计能力。
SQL Server 2008企业版通过在数据库引擎中引入本机审核功能，从而增强了服务器的审计能力。新的SQL Server审计特性保留了SQL Server2005审计解决方案的所有能力，并增强了如数据目标审计和细粒度审计的灵活性。
在SQL Server 2008中，SQL Server 审计特性有意替代SQL Trace作为首选的审计解决方案。SQL Server审计的目的在于提供丰富的审计功能与唯一审计功能，不像SQL Trace，还用于性能调试。最终，设计SQL Server审计的主要目标如下：
安全性—审计功能及其对象，必须真实安全。
性能—必修尽量减少对性能的影响。
管理—审计功能必须易于管理。
可发现—以审计为中心的问题，必须易解答。
随后的章节将逐一讨论如何实现上述设计目标。
如前面提到的，SQL Server审计现在对服务器进行本地审核。这得益于新SQL Server审计在性能上的优势与允许审计对象作为第一类数据库对象被创建。作为第一类对象，意味着通过Transact-SQL DDL 语句（如果你喜欢的话，也可以通过SQL Server管理工具）进行审计对象的创建和操作。此外，通过数据库的熟悉的权限模型保证审计对象的安全。
当审计对象被创建时，必须指定审计事件的目标。典型的目标是大多数情况下都适合的文件。然而，在SQL Server 2008中，审计事件同样可以被写入Windows应用程序日志。这有利于在某些情况下，访问审计信息，通过管理应用程序进行整合。另外，学Windows安全日志那样能将审计作为一个目标进行标记（开始于Windows Server® 2003操作系统）的非常安全意识将大受欢迎。这样做的意义在于，Windows安全日志被认为是抗篡改和不可抵赖的。使用安全日志的另一个好处是微软系统中心操作管理器的审计收集服务能被用来从多台机器中安全的收集审计信息并产生综合报告。
最终也是最重要的要提的一点是，在SQL Server 2008中的SQL Server审计是可以指定粒度进行审计。审计活动用户，角色或组数据库对象，能够被限制到表级别以下。这也就是说，你能针对SQL Server审计来追踪指定的活动用户或降到单表级别以下的用户。例如，SQL Server审计允许一条记录由所有的工资表更新以DBO的方式组成。
审计是数据库安全战略的一个重要组成部分，正如SQL Server审计功能自身必须是具有高度的安全性和安全对象。因为它是数据库对象，创建，删除，或修改审计对象的权限，都是通过数据库引擎的权限模型和执法管制来控制的。SQL Server审计功能引入了一种新的服务器级别的被称为权限ALTER ANY SERVER AUDIT的允许主要创建，修改，删除审计或服务器审核规范对象的权限。审计规范能言简意赅的作为一个对象，在审计中捕捉活动的对象进行描述（更详尽的描述参见后文）。
审计日志显然是一个需要保护的资产。必须仔细考虑审计数据发往哪里。理想的情况是，审计信息应当发往一个甚至是系统管理员都不能被修改或篡改的地方。为达到此目的的一个简单的策略是将审计事件发送到一个只有读权限的SQL Server账户的共享的文件中。具有审计师潜力的人很显然想访问这些数据但没人（能真正访问到）。还有，如果是共享在不同电脑上，很可能会受到和Windows管理员（SQL Server所在的电脑）同样的保护，虽然明显有一些性能上的考虑以及网络中断的脆弱性。另一种选择是Windows安全日志。这对于想将SQL Server审计日志本地化存储又想从系统管理员甚至是本地Windows管理员处得到保护的人来说，是一个不错的选择。最后一点—SQL Server不加密或以其他方式保护审计日志。这样附加的保护层得以应用，当然，对于SQL Server可以通过一种外部手段，如文件系统加密。
如果，无论出于何种理由，SQL Server审计时无法将审计事件写入审计目标，你可以配置设计对象来关闭服务器实例。虽然关闭服务器实例看起来似乎很严重，但对于某些场景，如为了确保其处于非活动状态被审计的情况下服务器无法操作这类通用标准的要求还是有必要的。要以这样的表现方式来配置审计，进行CREATE 或 ALTER AUDIT DDL操作时必须另外拥有SERVER SHUTDOWN 服务器权限。如果由于SQL Server审计导致服务器无法启动，那么可以通过 -m 跟踪标志（命令）来启动SQL Server并使服务器启动。SQL Server审计自身不会停止，只有关机行为会被禁止。需要注意的是通过 -m启动SQL Server只在单用户模式下，同时为了允许DBA启动数据库，在需要的时候对SQL Server审计配置进行更改。另外， -f 跟踪标志适用于在最小配置模式下启动SQL Server，这种情况下审计被禁止当审计DDL仍然能使用。在实际应用中， -m 标志命令能满足大多数情况下对SQL Server审计重配置的要求。 如果因写审计事件失败而没有触发关闭SQL Server实例（的事件），审计记录会怎样被处理？答案是，审计事件被缓存在内存中，直到他们能被刷新到新的目标。如果这些记录占满缓存而没有被写入审计日志，服务器将导致新的审计记录无法写入，直到缓存空间被释放或审计失效。不同的内存缓冲区，大小也不相同，但在默认情况下，每个审计缓冲区大约是4M的容量，这样的空间可以容纳至少170个审计事件（准确的数字依赖于每个事件所包含的数据量）。如果在操作系统返回一条错误信息之前问题没有被纠正，如磁盘写失败，审计会话将处于离线状态并将对应的错误写入服务器错误日志；所有的缓存和新的审计事件将被丢弃。问题被纠正后，为了恢复审计，审计对象将重启。如果无法忍受审计记录丢失，审计（功能）应该被配置为关闭而不是继续写入失败。为了确保审计日志的事件捕捉和服务器上活动的事件之间的高度同步，SQL Server审计可以将写审计到日志配置为同步方式，也就是事物将被阻塞直到事件被写到目的地。很明显这将对服务器的性能带来不利的影响。在大多数情况下，推荐以异步的方式进行审计日志的写入。如下所述，写入的时间长度可以配置；从默认的一秒钟增加的时间值可以提高服务器的性能。 最后需要强调的一点是服务器审计对象本身的状态有任何变化都会被记录到审计日志中。这是SQL Trace的短处，但这是一个很重要的功能，因为可能会捕获任何试图规避审计（的行为）。假设审计事件被发送到目标对象，SQL Service账户无法进行修改，该功能对于DBA来说，很好的保护了审计记录。进而，就有可能在实例的范围之内，将SQL Server审计配置成能记录所有定义的审计对象的改变，不仅是眼前的服务器审计对象（该配置可以通过根据服务器审计规范，增加 AUDIT_CHANGE_GROUP来完成；在后续的文档中将会有更清晰的描述）。 SQL Server 2008引入了一种新的，名为SQL Server扩展事件的高性能的事件基础架构。SQL Server审计功能是利用其性能优势建立在扩展事件上层，并且提供同步和异步写功能（默认情况下，SQL Server 审计使用异步事件模型）。需要注意的一点，审计事件是扩展事件的一种保护类型，因此CREATE/ALTER/DROP SESSION EVENT命令不能直接操作SQL Server审计。更多关于扩展事件的信息，参看SQL Server在线书籍。 默认情况下，出于性能方面的考虑，审计事件以异步方式写入到审计目标。当对于写入到审计日志的审计记录有严格的要求，希望对性能退化有些考量的时候，你可以选择同步方式进行写入（准确的数额取决于量和生成的审计记录的类型）。异步或同步方式的选择，由 CREATE AUDIT DDL（后续说明）操作决定；默认情况下，该值（查询延迟的值）为1000，也就是SQL Server审计队列的审计记录 了一秒，然后写入目标。在冗余允许的条件下，你可以将该值设大一些以提高性能；这样做的代价是与实际的数据库活动，活动记录在日志中可能会越来越不同步，如果在服务器上出现致命的错误会导致记录丢失的风险大增。为了确保同步记录SQL Server审计，将 QUEUE_DELAY的值设为了0.
有针对性的审计也有助于减少对其对于性能的影响。显而易见的策略是：限制审计对于精确的操作集不产生太大的兴趣。细粒度审计功能的SQL服务器审核允许审计配置为目标的具体行动、主体和对象(小到单一表的级别)。因此,资源不能被浪费在不必要的审计信息生成上。同SQL跟踪相比,这通常会生成大量的记录并依赖后过滤(post-filtering)来提供有针对性的审计。
因为对于结构化的SQL Serer审计，取得最佳性能的方法通常是使用一个文件作为审计目标。当然，不同审计目标之间的性能差异是高度依赖于审计配置等选项的。
SQL Server 2008的审计功能是完全可控的，它主要管理接口,特别是SQL Server管理工作室,服务器管理对象(SMO),和主题DDL。
在SQL Server Management Studio中，服务器级别的审计配置在用户界面的安全文件夹下。两个相关的子文件夹是审计和服务器审计规范。数据库级别的审计配置在数据库审计规范子文件夹中，在每个数据库的安全文件夹下可供使用。
相比早期版本，审计配置完全可以通过SMO（SQL Server 管理对象）以编程的方式进行管理，使用 Microsoft.SqlServer.Management.SMO命名空间中的对象。最终，与使用系统存储过程来配置SQL Tace相比，SQL Server 审计使用明确的SQL DDL语法来创建，管理和安全审计。
审计数据能被写入二进制文件或者Windows事件日志（应用日志或者安全日志）。当写入文件的时候，审计数据通过内置的表值函数，该函数允许使用常规的SELECT语法来查询审计记录。写入到事件日志中的事件信息可以通过事件查看器或特定的事件日志管理软件进行操作，如微软系统中心操作管理器。访问和分析审计数据的细节将在后续文章中进行讨论。
除了提供一个鲁棒(健壮)的基础结构收集审计资料，SQL Server 2008更容易满足特定的审计需求。审计记录基于对数据库中对象的权限检查而被捕获。这意味着，例如，一个对于表A的Select查询记录，不管实际的SQL语句是否引用了表A，视图，存储过程，或者另一个对象，都不会有变化。
同时，SQL Server 2008允许细粒度审计标准的定义。审计可以从局限于单个表，到特定的DML操作(例如，DELETE删除与SELECT选择)和特定的主体。这种粒度可以降低那些必须满足一组特定需求的审计数据存储和分析的总量。
理解和管理审计在SQL Server 2008中的设置，最好从三个主要对象开始，以此来描述审计。
服务器审计对象对审计数据的目标进行了描述，外加高级别的配置设置。将一个服务器审计对象作为审计片申明或目标。该目标可能是文件，Windows应用程序日志，或者是Windows安全日志。事件写入目标的延迟许可在该对象上也能配置。要注意的是服务器审计对象并不包括被审计的内容—而仅仅是审计数据的去向。可以定义多个服务器审计对象，每个对象的制定和运行相互独立。 服务器审计规范对象描述了审计的含义。正如其名字所示，该对象专注于服务器实例的行为。 以服务器审计规范与服务器审计相关联的方式来定义审计数据所要写入的位置。在服务器审计规范对象与服务器审计对象之间是一对一的关系。数据库审计规范同样描述了审计的含义。但是正如其名所示，该对象专注于发生在特定数据库上的行为。审计数据所要写入的地方是由服务器审计对象相关联的数据库审计规范来定义的。每个数据库审计规范仅与一个服务器审计对象关联。服务器审计，作为它的一部分，仅与每个数据库的数据库审计规范相关联。
下图一描述了定义整个审计制度的对象之间的交互。
图一中所有对象之间的关系是可调配的。当然，没有至少一个服务器审计与一个规范（服务器或数据库），审计就无法生成任何数据。所有这些对象—服务器审计，服务器规范和数据库审计规范—运用DDL能进行完全管理，SQL Server Management Studio administrative的管理界面或SMO。
我们来追溯审计定义的每个细节部分。
图 1: 审计对象的结构
服务器审计通过 CREATE SERVER AUDIT语句创建。除了名字之外，最重要的是创建时指定的服务器审计是审计数据的目标。在SQL Server2008中，可用的目标有二进制文件，Windows应用程序日志，Windows安全日志（需要特定的权限—在后续讨论—以写入到安全日志中的SQL Server服务账户）。对于文件的目标，用户必须至少提供文件路径和可选（项），滚动更新文件的最大尺寸和最大数目。SQL Server名称的审计文件自动运行，依据以下格式：<audit_name>_<audit_guid>_nn_<timestamp_as_bigint>.sqlaudit 当活动的审计文件达到指定的最大大小，它将自动翻转到一个新的文件。此过程继续进行翻转到由MAX_ROLLOVER_FILES参数指定的最大数目。当达到或假设达到最大数目的更新文件，SQL Server就开始从时间最久的开始，删除一些现有的审计文件以创建新文件。请注意如果删除操作由于任何原因而失败，审计会继续进行。
从可选择性上讲，审计可以保留在启动时的最大磁盘空间上。当然，SQL Server服务账户必须有写入目标文件夹的权限。
为了提供安全性能上的权衡控制，在服务器审计上可进行队列延迟的配置。若该值为0，那么审计记录与生成记录的行为是同步的。另外，可以指定毫秒级单位的队列延迟，以减少在负载下对性能的影响。最小的延迟值为1000毫秒（默认值）。
为了满足最严格的安全要求，服务器审计可以有选择地进行配置，以便如果审计失败SQL Server将关闭。例如，如果审计日志中的目标驱动器变得不可用，SQL Server关闭，可以手动重新启动-m命令开关，除非关机的根本原因被纠正。
默认情况下，创建的服务器审计处于禁用状态。这样可以用DDL覆盖以使审计能立即可用。在大多数情况下，管理员却希望在审计可用之前，能对审计进行完全配置。
服务器审计用一个GUID自动标识并且是唯一标识。为了提供分布式方案，如数据库镜像， CREATE SERVER AUDIT语句允许GUID被明确指定。设计被创建后，GUID不能在改变。
下面的DDL例子显示了创建一个名为PCI_Audit的审计，将毫无延迟的写入文件，在写文件事件失败后强制服务器关闭。
Transact-SQL
CREATE SERVER AUDIT PCI_Audit
TO FILE (FILEPATH = ’F:\AuditLogs\’, MAXSIZE = 1GB, MAX_ROLLOVER_FILES = 80)
WITH (QUEUE_DELAY = 0, ON_FAILURE = SHUTDOWN)
该服务器审计初始处于禁用状态。
服务器审计在创建后通过使用ALTER SERVER AUDIT 语句可以进行修改。下面的例子将目标改成Windows应用程序日志，增加了队列延迟的值以及有关失败的设置。
Transact-SQL
ALTER SERVER AUDIT PCI_Audit
TO APPLICATION_LOG
WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE)
ALTER SERVER AUDIT语句也可以用于服务器审计的可用与不可用的状态设置。
Transact-SQL
ALTER SERVER AUDIT PCI_Audit
WITH (STATE = ON)
在活动事物的范围之外，服务器审计只能启用或禁用。
SQL Server Management Studio 的数据库审计的创建和管理都是在审计的目录里面，具体位置是在的server服务->安全 节点里面。
截图2：在 SQL Server Management Studio里面创建数据库审计
权限：在服务上的审计行为(CREATE, ALTER, or DROP)，要求要有ALTER ANY SERVER AUDIT 的授权，该权限可以由 CONTROL SERVER的权限继承。
写入Windows安全日志
写入windows安全日志特别值得一提，因为考虑到有一些额外的考虑因素。因为写入Windows安全日志是特权很高的操作，SQL Server服务账户被授予SeAuditPrivilege （也被称为“生成安全审计”）特权。虽然这也可以通过本地安全策略工具（secpol.msc）完成。只要将服务账户添加到 本地策略/用户权限分配/生成安全审计路径下。
此外，审计策略的粒度在SQL Server项可以被记录之前，对于Windows必须要进行修改。在Windows 2003中，使用安全策略工具修改 本地策略/审计策略/审计对象访问设置；将“成功”与“失败”设为启用。在Windows Vista ®操作系统和Windows Server 2008中，使用auditpol 命令行工具执行布命令 auditpol /set /subcategory：“生成应用程序”/成功:可用 /失败:可用。请注意在某些域环境下，域策略可能会覆盖这些设置，在这种情况下，需要从域管理员处得到协助。在WIndows XP电脑上，安装了SQL Server 2008开发版的用户，将不能将审计信息写入到Windows 安全日志，因为该操作系统不支持该功能。
CREATE SERVER AUDIT SPECIFICATION 语句可以创建服务器审计规范。在服务器审计规范创建之前，服务器审计必须存在，因为DDL需要制定一个审计名称。
服务器审计规范的主要内容是将要审计的行为组列表。可审计的操作以组的形式收集，并覆盖服务器级别的活动，如服务器的配置更改和登录/注销。这些组是硬链接，在SQL Server文档中有详细描述。
下面的语句创建了一个服务器审计规范以跟踪备份/恢复事件，SQL Server服务启动和停止，改变服务器成员的角色。
Transact-SQL
CREATE SERVER AUDIT SPECIFICATION PCI_Server_Mgmt_Spec
FOR SERVER AUDIT PCI_Audit
ADD (BACKUP_RESTORE_GROUP),
ADD (SERVER_STATE_CHANGE_GROUP),
ADD (SERVER_ROLE_MEMBERSHIP_CHANGE_GROUP)
WITH (STATE = OFF)
使用 ALTER SERVER AUDIT SPECIFICATION 语句 创建服务器审计后，服务器审计规范可以被重新分配到不同的服务器审计。该语句也允许更改列表中审计行为组和被标记的启用（ON）与禁用（OFF）之间的状态切换。
下面的例子给之前的语句创建的规范上，增加了一个行为组。
Transact-SQL
ALTER SERVER AUDIT SPECIFICATION PCI_Server_Mgmt_Spec
ADD (SERVER_PRINCIPAL_CHANGE_GROUP)
只能在事物范围之外更改审计的状态（可用或禁用）。同样，如果ALTER SERVER AUDIT语句将状态从ON改为OFF，那么在同一语句中可能不包含任何其他变化。
在SQL Server 管理工具中服务器审计规范的创建和管理都在服务器审计规范文件夹下，该文件夹是服务器级别的”安全性“文件夹。
权限
服务器审计规范（创建，修改或删除）的操作要求具有ALTER ANY SERVER AUDIT 权限，该权限包含在控制服务器里。
数据库审计规范更像服务器审计规范，但也存在某些明显的不同。如名所示，当然，数据库审计规范属于审计数据库级别的行为。如同服务器审计规范，一个预定义的审计行为组列表被用来定义规范的轨迹。
除此之外，还有，数据库审计规范允许更多的特定的审计行为被追踪。数据库中的细粒度行为很容易被当做目标。在探讨该细节之前，先考查以下语句。
Transact-SQL
CREATE DATABASE AUDIT SPECIFICATION PCI_Txn_Database_Spec
FOR SERVER AUDIT PCI_Audit
ADD (DATABASE_OBJECT_PERMISSION_CHANGE_GROUP),
ADD (SELECT ON dbo.Customer BY dbo),
ADD (INSERT ON dbo.Customer BY dbo),
ADD (UPDATE ON dbo.Customer BY dbo),
ADD (DELETE ON dbo.Customer BY dbo),
ADD (EXECUTE ON dbo.usp_SubmitPO BY public)
该规范追踪了所有属于DATABASE_OBJECT_PERMISSION_CHANGE 组的操作，假如有多个管理员在数据库中操作，用它来进行监测非常有用。另外，它也追踪由dbo用户对 Customer表的特定的DML操作，作，任何执行的 usp_SubmitPO存储过程 。 也需注意关键字public的使用，追踪所有用户所做的更改。
在SQL Server 2008中，这种细粒度行为的定义是与他们的服务器级别的数据库审核规范的一个关键区别。定义一个行为被审计的一般形式是：
<action> ON <object> BY <principal>
审计发生时，以任何方式采取行动（都行）。换句话说，对Customer的SELECT操作会被审计，如果用户的操作是一条Customer表上的SELECT语句，一个SELECT查询表视图，查询表的一条存储过程，诸如此类。
注意到在上述格式中的<object>涉及到的对象类似表，视图或者存储过程，又或是整个数据库或模式。对于后者，DATABASE::<db_name>和SCHEMA::<schema_name>这样的格式也被分别使用。
允许审计有局限性的集中，从而使在审计中捕捉的数据量最小是需要首要指定的。为了审计所有主体的行为，可以指定公众的角色。例如，接下来的操作记录了在MyDB数据库中所属MyDBRole角色的任何用户的所有对象上的所有SELECT（行为）。
Transact-SQL
SELECT ON DATABASE::MyDB BY MyDBRole
如服务器级别的规范，数据库审计规范可以在创建或通过ALTER DATABASE SERVER SPECIFICATION语句来启用或禁止。ALTER语句也允许修改设计行为列表和行为组。
在SQL Server Studio中，数据库审计规范在数据库审计规范文件件下进行创建和管理，这是数据库级别的”安全性“文件夹下的数据库中问题。
权限
服务器审计规范（创建，修改或删除）的操作要求具有ALTER ANY SERVER AUDIT 权限，该权限包含在控制服务器里。
在我们进入到审计数据怎样读取和使用之前，一些技术方面的实现变得不值得一提。早些时候，有人认为SQL服务器审计是从本机到服务器。此功能有很多方面与DBMS结合更加紧密，其中最重要的是审计事件被触发的方式。在SQL Server 2008中审计是通过与发生在数据库引擎内部的权限检查相挂钩的方式来实现的，如果相关审计被指定的话，SQL Server审计有机会产生审计记录。也就意味着对一个对象所有形式的访问都会被审计。
SQL Server审计需要注意的第二个方面是它的内部事务行为。关于这点有两方面。第一，审计本身与事务边界的交互如何操作。所有审计有关的DDL语句，包括CREATE SERVER AUDIT语句，在活动的事务内可以执行，除非他们触发了对事务状态的改变。若在一个事务中，创建的审计将限定在事务范围之内—将提交或回滚事务。
另一方面，当可审计的事件发生在事务中如何被记录。简单的说：他们一直被审计。很显然，如果数据可以被读取，这将减少安全隐患，但没有审计记录，因为一个待审计的事务被回滚。因此，记录审计事件的发生而不管事务范围和回滚是否发生。
本节包含关于你能使用和应用由SQL Server审计所产生的数据的方法的信息。
当SQL Server 2008服务器审计的审计目的地被配置为文件选项时，审计数据将被写入到磁盘上的二进制文件中。目标位置可以是本地文件夹或者是网络共享的UNC路径。
尽管服务器审计可以指定审计文件创建的路径，文件名是由SQL Server自动生成。文件名格式如下：<audit_name>_<audit_guid>_nn_<timestamp_as_bigint>.sqlaudit。
在这种模式下，nn是一个连续的以递增方式产生的新的审计文件的分区号，如果审计配置允许翻转到新的文件。
审计文件可能会被写入到由NTFS加密保护的文件中，并提供SQL Server服务账户有适当的权限。还允许写入到采用NTFS压缩的文件夹中。在两种情况下，当然，会有些性能影响。如果审计文件的目标位置是远程文件共享，审计内容在进行网络传输时不会被加密。
如上述提及到的，审计文件是用二进制格式（存储）并不允许用文本编辑器读取。SQL Server提供了一种称为fn_get_audit_file()的用来读取审计数据的表值函数。该函数所使用的参数如表1所示。
参数名 类型 描述
File_pattern
nvarchar
目录或路径和文件名说明了位置和审计文件设置为可读取。一个 星号通配符是允许的。可以是本地或UNC路径。
Initial_file_name
nvarchar
指定路径和从文件集中开始读取的文件的文件名。
Audit_file_offset
bigint
在initial_file_name参数中已知的文件位置。在该字节偏移量开 始阅读下一条记录。
表 1: fn_get_audit_file()函数的参数
下面的语句表示为指定的审计读取所有审计文件。
SELECT * FROM fn_get_audit_file(
'D:\Audits\MyAudit-_C26128D1-F97B-4B82-9E47-B6A296045B05_*.sqlaudit',
default, default)
下面是读取 E:\SqlAudits\ 文件下所有的审计文件的例子。
SELECT * FROM fn_get_audit_file('E:\SqlAudits\*', default, default)
这些示例是为指定的审计在已知偏移量时读取所有审计记录。
SELECT * FROM fn_get_audit_file(
'D:\Audits\MyAudit-_C26128D1-F97B-4B82-9E47-B6A296045B05_*.sqlaudit',
'D:\Audits\MyAudit-_C26128D1-F97B-4B82-9E47-B6A296045B05_0_128439520854140000.sqlaudit',
5120)
顺便提一句， initial_file_name 和audit_file_offset 参数可以通过从fn_get_audit_file()函数最后一次调用的输出中，分别查看initial_file_name 和 audit_file_offset 列来确定。
理所当然的，因为这是一条来自表值函数，一条WHERE 子句，ORDER BY子句，和其它标准的SQL SELECT语法可以用来塑造的结果集的SELECT语句。
因为fn_get_audit_file()函数以参数的形式提供了明确的路径，可以讲不活动的审计文件移动到新的位置并使用该函数进行读取。在这一点上，审计文件只是静态的数据。因此他们不在接受审计事件时，可以随意移动和查询审计文件。这样做的好处是，多个服务器上的审计文件可以合并在一个文件夹并作为一组集合进行查询。以此方式，管理员或审计员可以很容易的通过一个分布式的SQL Servers集合对关键事件进行查找。
fn_get_audit_file()函数返回了一组由SQL 服务器审计捕捉的丰富信息。提供多达二十多列，从如下几个方面：
事件的日期和时间，它是否成功（或权限被就绝）
事件的用户上下文（在服务器和数据库级别的主要ID和名字）
操作类型（如SELECT，EXECUTE，DELETE）
目标对象
连接上下文（服务器和实例，数据库，模式）
审计事件（若是可应用的）触发的真实的Transact-SQL语句
在文件中的审计文件名和审计记录的位置
对于一些特殊事件的其它XML信息，如审计管理事件
很明显，关于每个审计事件，都提供了大量的信息。其中一列，声明，包含了引起审计事件行为的实际文本，尽管语句中的实际数据值如果是参数化的，而可能没有显示。需要注意的是，这可能没有直接命名审计资源。例如，在表1上的SELECT审计事件可能由引用了表1的视图1上的SELECT引起。
声明字段的数据类型为nvarchar，长度为4000字符。在一个超过该声明大小的事件中，SQL Server 2008产生了多条审计记录，通过更多的需要捕捉完整内容的记录来传播声明文本。在审计记录中的序列号字段能使完整语句进行重组。
fn_get_audit_file()是为你的环境实现最佳的审计分析方案的起点。因为它本质上如同表一样呈现了审计数据，它提供了查询，挖掘，归档或以任何必要的方式记录的审计日志的手段。从这个意义上讲，这也许是最灵活的审计数据的三种可能的目标。
SQL Server 2008审计能都交替的配置将日志记录到Windows 应用程序日志或Windows安全日志。这可能是其具有价值的几个原因：
对于一些服务器管理员和审计人员而言，Windows事件日志的位置和格式都很熟悉。
安全日志在写，篡改和查看方面有着固有的限制，在作为审计信息的存储库方面，有一定的吸引力。
有现有的微软和第三方解决方案，旨在Windows事件日志中的整合，监测和报警。例如，微软系统中心有一个称为审计收集服务的组件，可以有选择的整合来自多个服务器的安全事件日志。同时，系统中心操作管理器产品是专门用来对Windows事件日志进行监测，报告和报警。
当服务器审计被配置为TO APPLICATION_LOG或TO SECURITY_LOG 选项时，所有审计事件被写入到相关的日志。事件包含由fn_get_audit()表值函数返回的审计文件的相同的信息。在事件日志里，该信息是以文本格式写入到事件正文中。
对于打算成立监视或警告事件日志条目的用户而言，知道是什么事件日志中的特定属性将被分配给SQL Server审计条目是非常重要的。所有SQL Server审计事件记录下了事件源的SQL Server实例的名称。事件ID为33205。事件的描述是可以发现的事件的唯一特征。因此，为了实现审计事件筛选或报警，事件日志管理工具，将用于需要支持基于描述（如正则表达式搜索）的事件的标识。
使用用户环境中一个典型的OLTP工作负载对SQL Server审计进行性能测试并与SQL Trace尽可能的进行比较。测试结果一致表明相比于SQL Trace，SQL Server审计在性能方面会有11%-45%提高。下面列出了关于使用负载的简要说明，随后的表中显示了每次负载下的各种执行时间。本次比较过程中， SQL Trace运行在C2 Audit Mode，SQL Server审计开启相同事件的审计功能并输出到一个文件。
负载1包括11个数据库，大小从1.94M到1812.5M不等。包括平均有2761行的755张表，以char 、smallint 和decimal类型的列为主。
下面是负载1的活动量汇总（负载%）：
存储过程：
sp_cursorfetch
执行 (38.72%)
语句：
ORDER BY (21.90%)
SELECT FROM (39.51%)
1,219,234条语句被执行。
负载2包括2个数据库，大小从64M到423.88M不等。包括平均49141行35张表，以bit、varbinary、int和nvarchar 类型的列为主。
下面是负载2的活动量汇总（负载%）：
执行(100%)
1,633,557 条语句被执行
负载3包括3个数据库，大小从1.94M到1059.63M不等。包括平均有586行的154张表，以real、numeric和float类型的列为主。
下面是负载3的活动量汇总（负载%）：
存储过程：
sp_execute
sp_prepare
sp_unprepare
执行 (94.25%)
语句：
SELECT FROM（39.87%）
585,400 条语句被执行
负载4包括1个大小3235.75 MB的数据库。具有平均144,245 行的84张表，以int, varchar, 和 datetime类型的列为主。
下面是负载4的活动量汇总（负载%）：
存储过程：
sp_cursorfetch
执行 (95.89%)
语句：
SELECT FROM（39.87%）
3,435,303 条语句被执行
负载5包括一个大小174.94 MB的数据库。平均具有4108行的152张表，以 char和， numeric, int 和 float类型的列为主。
下面是负载5的活动量汇总（负载%）：
存储过程：
sp_cursorclose
sp_cursorfetch
sp_cursoropen
执行 （78.58%)
语句：
SELECT FROM（26.96%）
296,642 条语句被执行
Workload Base Time (min) SQL Trace (min) SQL Server Audit (min) Perf Cost Vs. Base Perf Gain vs. Trace
1
13.30
15.89
14.13
6.24%
11.08%
2
41.30
101.85
55.93
35.42%
45.09 %
3
5.09
6.29
5.57
9.43%
11.45%
4
63.36
76.64
68.13
7.53%
11.10%
5
3.59
4.76
4.00
11.42%
15.97%
表2：SQL Server Audit vs. SQL Trace的性能数字
在表2中， PERF COST VS BASE的计算式： (SQL AUDIT– BASE TIME) / BASE TIME，PERF GAIN VS TRACE的计算式：(SQL TRACE – SQL AUDIT) / SQL TRACE。
SQL 跟踪和SQL Server审计的改善，从 11.08% 到 45.09%不等,负载2 显示两者之间的巨大区别。这很可能是在I/O文件中注重SQL Server审计的高效，从而负载产生了大量的审计事件 的一个结果 。从表中还观察到，SQL Server审计的运行成本从 6.24% 到 35.42%不等。请记住，这些值是大量的审计行为组启用产生的，跟较为温和的审计设置放在一起， 成本较低。因为SQL跟踪缺乏像SQL Server审计这样的细粒度审计能力，在这种情况下，两者之间的性能比较是不可能的。
下面提供一个利用SQL Server审计功能的真实场景。
SQL Server审计的一个相对简单但非常贴切的用法就是监控授权用户访问一张敏感表。利用SQL Server 2008中的审计功能，通过定义适当的数据库审计，可以轻松实现这样的监控。比如，假定这张敏感表为hr.salary,位于数据库hr_db下，我们想检查dbo（甚至sysadmin）在什么时间试图访问该表。在这个例子中，审计信息将被写入到一个位于远程共享目录\\AuditServer\Audit的一个文件中，这个文件在SQL Server实例中只允许写但不能读或修改。
首先，我们需要创建审计和数据库审核规范“对象。
Transact-SQL
USE master
CREATE SERVER AUDIT audit1 TO FILE (FILEPATH='\\AuditServer\Audit')
USE hr_db
CREATE DATABASE AUDIT SPECIFICATION hr_dbspec FOR SERVER AUDIT audit1
ADD(SELECT,UPDATE,INSERT,DELETE ON hr.salary by dbo)
由于创建对象默认情况下禁用，他们需要同时启用。
Transact-SQL
USE master
ALTER SERVER AUDIT audit1 WITH (STATE=ON)
USE hr_db
ALTER DATABASE AUDIT SPECIFICATION hr_dbspec WITH (STATE=ON)
在这一点上，审计被所有的查询反对的hr_db的表由dbo或sysadmin被记录下来，作为任何行动，启用或禁用审计。
要确认已启用，无论是审计和审计规范，系统视图可以进行查询。
Transact-SQL
SELECT is_state_enabled FROM sys.server_file_audits
SELECT is_state_enabled FROM sys.database_audit_specifications
一些遵从性法规要求访问和加密密钥的使用需要审计。SQL Server审计有能力记录所有活动的触摸对称加密密钥或数字证书的私钥或非对称密钥对。简要的说，这些活动在服务器和数据库级别通过DATABASE_OBJECT_CHANGE_GROUP行为组而涵盖。DATABASE_OBJECT_CHANGE_GROUP行为组涵盖了所有的涉及到密钥用法，还有在数据库中CREATE, ALTER, 和DROP对象，不包含在模式之内。除了数据库从最初的初始化期间，CREATE, ALTER, 和DROP事件应当处在低水平，这意味着捕捉该行为组的活动在加密密钥活动的限制之下。例如，审计的创建使用SQL Server Management Studio将被展示出来。为了创建审计对象，在实例下扩大安全树，右击Audits，然后点击 New Audit。将会打开如图3所示的 Create Audit对话框，你可以配置对审计属性进行配置。
图3：Create Audit对话框
如果默认值是可以接受的，唯一有输入要求是File path，假设审计目标是文件。注意到 SQL Server Management Studio基于时间戳创建了默认的审计名称。接下来必须创建服务器和数据库审计规范。可以通过分别在Server Audit Specifications和对象资源管理器中的Database Audit Specifications上点右键来完成（如图4）。
图4：通过 SQL Server Management Studio创建数据库审计规范
对于数据库审计规范，会出现图5所示的创建数据库审计规范（Create Database Audit Specification）对话框。
图5：创建数据库审计规范对话框
上一步所创建的审计对象需要在审计（Audit）下拉列表中被选中。之后从审计动作类型（Audit Action Type）下拉列表中选中DATABASE_OBJECT_CHANGE_GROUP。
创建服务器审计规范的步骤是十分相似的。这里，可以通过在对象浏览器中右键点击开启审计及相关规范。
在审计开始运行后，管理员可以充分利用基于策略管理的能力来管理多服务器上的审计，以查明他们是否已运行，以及配置是否恰当。对于PBM基本的理解在随后的讨论中假定；更多的信息，参看SQL Server联机丛书。
创建策略以确定审计或审计规范是否启用时相当简单的。创建一个策略报告服务器是否有审计被启用，新的条件需要使用审计方面和表达式来创建，以评估@Enabled的值是否为真（如图6）。
图6：PBM创建新的条件对话框
注意名称（Name）一栏中的值是任意的。由于创建了条件，新的策略也应该被建立。在这个例子里，新的策略名为AuditOnPolicy，而检查条件（Check Condition）中的值被设定为已创建的AuditOn条件。（图7）
图7：PBM创建新的策略对话框
点击OK 创建策略，将评估是否在服务器上启用审计对象（或者服务器，如果评估已通过Registered Servers 对话框进行初始化）。策略评估提供了在实例中定义的审计对象清单，并说明他们是否处于活动状态。在图8中显示的评估结果表明审计未启用。
图8：PBM评估策略对话框
要注意的是在该版本SQL Server中，审计对象是只读的。正因如此，点击 Configure 会返回一条错误信息。最后，应建立类似的策略，以确定审计规范是否启用。
当然，知道审计可以启用是很重要的，但验证审计是被恰当配置的同样有趣。虽然无法决定审计规范中是否定义了一个如DATABASE_OBJECT_CHANGE_GROUP这样的行为组，可能不是很明显，但不是不可能。因为审计行为组没有PBM（Policy Based Management 基于策略的管理）的存在，策略可能会被作为T-SQL查询替代，来决定在审计规范中是否包括了一组特定的行为组。这里提供了这样的查询。
Transact-SQL
SELECT 1
FROM sys.server_audits AS a
JOIN sys.database_audit_specifications AS s
ON a.audit_guid = s.audit_guid
JOIN sys.database_audit_specification_details AS d
ON s.database_specification_id = d.database_specification_id
WHERE a.is_state_enabled = 1
AND s.is_state_enabled = 1
AND d.audit_action_name = N'DATABASE_OBJECT_CHANGE_GROUP'
如果活动的审计包括了由DATABASE_OBJECT_CHANGE_GROUP行为组创建的规范，查询将返回1。在PBM中要创建基于该查询的一个制约，像下面这样做：
创建一个新的制约条件和表达式。点击“...”按钮，弹出Advanced Edit对话框。
向下滚动Functions and properties列表，双击 ExecuteSql()。填充“ExecuteSql(string returnType, string sqlQuery)”文本单元格的值。你可以编辑该字符串，替换字符串类型为‘numeric’，与上面的SELECT语句中的字符型的sqlQuery（如图9；注意在查询中的单引号必须避开另一个单引号）。
图9：PBM Advanced Edit窗口
3.点击OK按钮，返回Create New Expression对话框，设置Operator 为= ，值为1以完成表达式。
4.设置Facet 为Database因为你希望查询每个数据库实例的评估。
在评估时，使用该表达式的策略将帮助管理员检测数据库是否被恰当的审计。
在SQL Server 2008中引入的新的SQL Server 审计功能表示了对早起SQL Server版本提供的审计能力的显著改善。其中核心的优势是引入了细粒度审计，据此，事件可以有针对性的特定行为，特别是主要的对象；对象甚至可以被限制在单表级别。性能是另一个诱因，因为SQL Server审计的性能显著优于SQL Trace，在某些情况下，达到45%左右。另外，审计目标不在局限于文件，因为Windows应用程序和安全日志现在是可选的。并考虑像审计实例重新启动和非自愿的变更记录的审计状态之间的状态持久性的好处，新的SQL Server审计功能为企业提供了一个稳健的，全面的审计解决方案。
本文地址：http://www.oschina.net/translate/auditing-in-sql-server-2008
原文地址：http://msdn.microsoft.com/zh-cn/library/dd392015.aspx
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们
7055
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
