1. 审计与合规治理工程导入
在开始学习 SQL Server 审计的具体技术之前，先要建立一个正确的认知：审计不是“打开一个开关、看几张报表”的孤立动作，而是一项需要长期运营的工程。它涉及数据采集、存储、分析、告警、留存与取证等多个环节，并与组织的合规目标、权限体系、变更管理紧密耦合。本章作为全课程的导入，重点回答四个问题：SQL Server 审计在整体安全体系中处于什么位置？合规治理到底要达成什么目标？必须掌握哪些核心术语？以及整个工程框架由哪些部分组成。
一、SQL Server 审计的定位
SQL Server 的安全能力可以粗略分为四层：身份认证（谁可以登录）、权限授权（登录后能做什么）、数据保护（静态加密、动态数据掩码、行级安全）、行为审计（实际发生了什么）。前三层是“事前控制”，审计是“事后可见”。事前控制再严密，也无法回答“谁在什么时候删除了这张表”“哪个账号在凌晨批量导出了客户数据”这类问题——这正是审计存在的意义。
从合规视角看，审计是多数监管要求中的硬性条款。例如等级保护要求对重要用户行为和重要安全事件进行审计，数据安全法要求对数据处理活动进行记录，SOX 要求对财务相关数据库的访问可追溯。因此，SQL Server 审计的定位可以概括为：它是数据库层的“黑匣子”，为安全事件调查、合规举证、异常行为发现提供不可否认的证据链。
需要特别强调的是，审计与“日志”不是同义词。错误日志、默认跟踪记录的是系统运行状态，而审计记录的是主体对客体执行的操作，并且要求可配置、可筛选、可防篡改、可长期留存。这是审计区别于普通日志的四个关键特征。
二、合规治理目标
合规治理不是“为了通过检查”，而是把外部监管要求转化为内部可执行、可度量的控制目标。对 SQL Server 而言，典型目标包括：
- 可追溯性：任何对敏感数据的访问、修改、删除都能定位到具体登录名、主机、时间、语句。
- 完整性：审计记录不能被普通 DBA 随意修改或删除，需具备防篡改机制。
- 留存性：按监管要求保留足够时长（常见为 6 个月至 3 年，金融行业可能更长）。
- 最小干扰：审计不能显著拖慢业务，需通过筛选和分级控制开销。
- 可举证：在需要时能快速导出、检索并形成符合取证要求的证据材料。
这五个目标之间存在张力。例如留存越久、审计越全，存储和性能开销越大。因此合规治理的本质是在风险、成本与监管要求之间做平衡，而不是追求“全量记录一切”。
三、核心术语
在后续章节中会反复出现以下术语，先建立统一理解：
| 术语 | 含义 |
|---|---|
| 审计（Audit） | SQL Server 中的顶层对象，定义审计输出的目标位置与行为，如写入文件或 Windows 事件日志。 |
| 服务器审计规范 | Server Audit Specification，定义在服务器级别要捕获的动作，如登录失败、权限变更。 |
| 数据库审计规范 | Database Audit Specification，定义在某个数据库内要捕获的动作，如 SELECT、UPDATE、EXECUTE。 |
| 审计动作组 | 预定义的动作集合，如 SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP。 |
| 主体（Principal） | 执行操作的身份，如登录名、数据库用户、角色。 |
| 客体（Securable） | 被操作的对象，如表、视图、存储过程、架构。 |
| 审计日志 | 审计产生的记录集合，通常为 .sqlaudit 文件。 |
理解“审计—审计规范—动作组—主体/客体”这条对象链，是后续配置工作的基础。一个常见的误区是把“审计”和“审计规范”混为一谈：审计决定“写到哪里”，审计规范决定“记录什么”，两者必须同时启用才会产生记录。
四、整体工程框架
把审计当作工程来做，可以划分为五个阶段，它们构成一个闭环，而不是一次性任务：
- 规划：识别敏感资产、明确合规要求、确定审计范围与留存策略。
- 采集：创建审计对象与审计规范，配置输出目标与筛选条件。
- 存储：将审计文件集中收集、归档，防止本地被篡改或磁盘写满。
- 分析：通过查询、报表或 SIEM 关联，发现异常行为并生成告警。
- 运营：定期评审、调整策略、处理告警、支持取证与合规检查。
下面的 SVG 展示了这五个阶段与关键输入输出之间的关系，帮助建立整体视图。
五、从框架到落地：一个最小可行示例
为了把抽象框架落到具体操作，下面给出一个最小可行示例。假设某业务库 SalesDB 中有一张客户表 dbo.Customers，合规要求记录对该表的 SELECT 与 UPDATE 操作，并将审计文件写入 D:\Audit\ 目录。
-- 1. 创建审计对象，指定输出到文件
CREATE SERVER AUDIT SalesAudit
TO FILE (FILEPATH = 'D:\Audit\', MAXSIZE = 200 MB, MAX_ROLLOVER_FILES = 10)
WITH (ON_FAILURE = CONTINUE);
-- 2. 启用审计
ALTER SERVER AUDIT SalesAudit WITH (STATE = ON);
-- 3. 在目标数据库中创建数据库审计规范
USE SalesDB;
CREATE DATABASE AUDIT SPECIFICATION SalesDbSpec
FOR SERVER AUDIT SalesAudit
ADD (SELECT, UPDATE ON dbo.Customers BY public)
WITH (STATE = ON);执行后，任何对 dbo.Customers 的 SELECT 或 UPDATE 都会写入审计文件。可以通过以下查询查看审计记录：
SELECT event_time, action_id, succeeded,
server_principal_name, database_name, object_name, statement
FROM sys.fn_get_audit_file('D:\Audit\*.sqlaudit', DEFAULT, DEFAULT)
ORDER BY event_time DESC;判断是否达成目标的依据是：查询结果中应出现对应时间点的 SELECT/UPDATE 记录，且 server_principal_name 能定位到具体登录名。如果为空，需检查审计与审计规范是否均为 ON 状态、动作组是否匹配、以及执行账号是否有权限写入目标目录。