sql2008中安全审计详细介绍
在 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名称的审计文件自动运行，依据以下格式：__nn_.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中，这种细粒度行为的定义是与他们的服务器级别的数据库审核规范的一个关键区别。定义一个行为被审计的一般形式是：
ON
概要：关于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名称的审计文件自动运行，依据以下格式：
从可选择性上讲，审计可以保留在启动时的最大磁盘空间上。当然，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中，这种细粒度行为的定义是与他们的服务器级别的数据库审核规范的一个关键区别。定义一个行为被审计的一般形式是：