2. SQL Server审计体系总览

SQL Server 的审计能力并不是单一机制，而是由多个层次、多个引擎、多个用途的组件叠加而成。很多团队在合规项目中走弯路，往往不是不会用某个工具，而是一开始就选错了审计载体：把本该用服务器级审计记录的对象权限变更，交给了 SQL Trace；把本该用扩展事件做的高频语句采样，硬塞进数据库审计；或者把 C2 审计误当成通用合规审计来用。要避免这些问题，必须先建立一张清晰的“审计体系地图”，理解每种机制在作用范围、记录粒度、性能开销、输出形态、合规适用性上的边界。

下面这张图把六类机制放在同一张体系视图中，按“作用层级”和“典型用途”两个维度定位，便于在方案设计时快速判断该用哪一种。

服务器级审计：合规审计的“总开关”

服务器级审计是 SQL Server 2008 之后引入的正式审计框架，也是等保、ISO 27001、SOX 等合规场景中最常被要求的机制。它的核心对象是 SERVER AUDIT，负责定义“审计记录写到哪里、以什么格式写、写满后怎么办”。它本身不决定记录什么事件，只决定输出通道。

CREATE SERVER AUDIT [Audit_Compliance]
TO FILE (
    FILEPATH = 'D:\SQLAudit\',
    MAXSIZE = 512 MB,
    MAX_ROLLOVER_FILES = 20,
    RESERVE_DISK_SPACE = OFF
)
WITH (
    QUEUE_DELAY = 1000,
    ON_FAILURE = CONTINUE
);
ALTER SERVER AUDIT [Audit_Compliance] WITH (STATE = ON);

关键参数需要结合合规要求来定：QUEUE_DELAY 控制写入延迟，1000 毫秒是常见折中值，设为 0 会强制同步写入、显著增加开销；ON_FAILURE 决定审计目标不可写时是继续运行还是关闭实例，合规严格场景通常设为 SHUTDOWN，但生产环境需谨慎评估；MAX_ROLLOVER_FILES 决定滚动文件数量，直接影响可追溯的时间窗口。服务器级审计的适用边界很明确：需要不可篡改、可集中收集、满足合规检查的审计记录时使用，但它本身不记录具体语句，必须配合审计规范。

数据库级审计：把“记录什么”落到具体库

数据库级审计通过 CREATE DATABASE AUDIT SPECIFICATION 定义，必须绑定到一个已启用的服务器级审计。它决定在某个数据库内记录哪些操作，例如对敏感表的增删改查、权限授予、架构变更等。

USE [SalesDB];
CREATE DATABASE AUDIT SPECIFICATION [AuditSpec_Sales]
FOR SERVER AUDIT [Audit_Compliance]
ADD (SELECT, INSERT, UPDATE, DELETE ON dbo.Customer BY public),
ADD (DATABASE_PERMISSION_CHANGE_GROUP),
ADD (SCHEMA_OBJECT_CHANGE_GROUP)
WITH (STATE = ON);

这里 BY public 表示对所有用户生效，实际项目中更推荐按角色或具体用户限定，避免审计量失控。DATABASE_PERMISSION_CHANGE_GROUP 和 SCHEMA_OBJECT_CHANGE_GROUP 是合规检查中最常被点名的两个组。数据库级审计的边界是：只覆盖当前数据库内的对象与权限事件，不覆盖登录、实例配置、备份还原等实例级行为。因此它通常与服务器级审计配合使用，形成“实例 + 库”双层覆盖。

扩展事件：诊断与轻量审计的主力

扩展事件（Extended Events，简称 XE）是 SQL Server 2008 引入、2012 之后逐步取代 SQL Trace 的诊断引擎。它的优势是开销低、可定制、支持实时消费与文件目标，非常适合做语句级采样、死锁捕获、长时间运行查询监控等。

CREATE EVENT SESSION [Track_LongQuery] ON SERVER
ADD EVENT sqlserver.sql_statement_completed (
    ACTION (sqlserver.sql_text, sqlserver.database_name, sqlserver.username)
    WHERE duration > 5000000
)
ADD TARGET package0.event_file (
    SET filename = N'D:\XELogs\LongQuery.xel',
        max_file_size = 100,
        max_rollover_files = 10
)
WITH (MAX_DISPATCH_LATENCY = 5 SECONDS);
ALTER EVENT SESSION [Track_LongQuery] ON SERVER STATE = START;

上面示例中 duration > 5000000 的单位是微秒，即只记录超过 5 秒的语句。扩展事件的边界在于：它擅长“行为观察”，但不天然具备合规审计所需的防篡改、集中收集和标准化输出。如果合规明确要求审计记录不可被普通 DBA 修改，扩展事件文件目标通常不满足，需要额外做权限隔离或转发。

SQL Trace：已弃用的兼容机制

SQL Trace 与 Profiler 是 SQL Server 2000 时代的跟踪机制，从 SQL Server 2012 起被标记为弃用。它通过 sp_trace_create、sp_trace_setevent 等存储过程配置，输出 .trc 文件。虽然部分遗留监控脚本仍在用，但新项目不应再选择它：开销高、事件模型陈旧、与扩展事件功能重叠。只有在必须兼容旧工具链或旧脚本时，才保留其使用。

C2 审计：高开销的“全量记录”模式

C2 审计是 SQL Server 提供的一种实例级全量审计模式，通过 sp_configure 'c2 audit mode', 1 开启。它会记录几乎所有语句和登录活动，输出到实例数据目录下的 .trc 文件。C2 审计的定位非常特殊：它面向的是政府或特定合规标准中“必须记录全部活动”的极端要求，而不是通用企业审计。开启后性能下降明显，磁盘增长快，且文件管理不便。除非合规条款明确点名 C2，否则不建议启用。

自定义审计：补齐业务语义的最后一层

原生审计机制记录的是“谁在什么时候对哪个对象做了什么”，但往往缺少业务上下文，例如“这次修改对应哪个订单、哪个审批单”。这时就需要自定义审计：用 DML 触发器把变更前后的关键字段写入审计表，或用变更数据捕获（CDC）、变更跟踪（Change Tracking）做增量记录，或在应用层记录业务操作日志。

CREATE TABLE dbo.Audit_Customer (
    AuditID     BIGINT IDENTITY PRIMARY KEY,
    Operation   VARCHAR(10),
    CustomerID  INT,
    OldValue    NVARCHAR(200),
    NewValue    NVARCHAR(200),
    ChangedBy   SYSNAME DEFAULT SUSER_SNAME(),
    ChangedAt   DATETIME2 DEFAULT SYSDATETIME()
);

自定义审计的边界是：它灵活但不可信程度最高，因为审计表本身可能被有权限的用户修改，触发器也会带来额外开销。它适合作为补充，而不适合作为合规审计的唯一依据。

把这六类机制放在一起看，审计体系的设计逻辑就清晰了：服务器级审计提供合规底座，数据库级审计把记录范围落到具体库，扩展事件承担日常诊断，SQL Trace 和 C2 审计只在特定条件下保留，自定义审计补齐业务上下文。真正专业的做法不是“全都开”，而是根据合规条款、性能预算和业务需求，明确每一层该开什么、不该开什么，并让它们之间形成互补而不是重复。