7.3 审计与合规：给数据库装行车记录仪

7.3 审计与合规：给数据库装行车记录仪

本节摘要：审计不阻止任何事，但让一切事可追责——它是威慑，也是合规的证据链。本节讲清内核级审计框架的动作与目标设计、审计策略与常见法规条款的映射方法，以及从"开了"到"有人看"的运营闭环，最后并入一份安全合规设计检查单。审计设计的起点不是"开什么功能"，而是"要回答什么问题"。

审计的起点是问题清单

先想清三个问题再碰配置。要回答什么：谁在非工作时间动过薪酬表？谁导出过整表数据？这个存储过程被谁改过？问题清单决定审计目标。记在哪里：审计日志写文件（落档归查）、写安全日志（与域安全体系联动）、写应用日志（便于集中采集）——选型跟着公司的日志平台走。记多细：全量记录会淹没信号（一天几个 GB 没人看等于没记）， selective 记录才有价值。这三个问题的答案就是审计策略——先有策略，再有配置，顺序反了的审计最后都变成占磁盘的摆设。

SQL Server 的审计框架是内核级的：服务器审计对象定义"记到哪、怎么写"（目标、队列延迟、失败处理）；服务器级与数据库级审计规范定义"记什么"——把审计动作组（如 FAILED_LOGIN_GROUP 失败登录、DATABASE_OBJECT_CHANGE_GROUP 对象结构变更）或具体动作（对某张表的 SELECT、INSERT）绑定到主体。内核级意味着事件在引擎深处生成，绕不过去——应用层的日志可以撒谎，审计日志不会。

-- 建审计与规范的最小骨架
USE master;
CREATE SERVER AUDIT Audit_Security
    TO FILE (FILEPATH = N'Z:\audit\', MAXSIZE = 512 MB, MAX_ROLLOVER_FILES = 100)
    WITH (ON_FAILURE = CONTINUE);        -- 磁盘故障时不拖垮业务，但要告警
ALTER SERVER AUDIT Audit_Security WITH (STATE = ON);

USE 订单库;
CREATE DATABASE AUDIT SPECIFICATION Spec_敏感表
    FOR SERVER AUDIT Audit_Security
    ADD (SELECT, INSERT, UPDATE, DELETE ON dbo.客户 BY public),   -- 敏感表全动作
    ADD (DATABASE_OBJECT_CHANGE_GROUP),                            -- 结构变更
    ADD (FAILED_LOGIN_GROUP) WITH (STATE = ON);                    -- 爆破尝试
-- 查看结果：sys.fn_get_audit_file 读审计文件，对接日志平台做告警
​

从条款到配置：合规映射的方法

合规审查的常见形态是"给证据"：等级保护要"操作可追溯"，行业监管要"敏感数据访问留痕"。映射的方法是把条款翻译成审计动作组。举例的映射表长这样：身份鉴别条款 → FAILED_LOGIN_GROUP 加 FAILED_DATABASE_AUTHENTICATION_GROUP（锁定策略在域侧）；访问控制条款 → 敏感表的增删改查审计加 DENY 的命中记录；安全审计条款 → 审计日志的防篡改（文件目标加签名校验）与保留期（至少与合规要求等长，常见半年到三年）；备份恢复条款 → 备份还原动作审计（BACKUP_RESTORE_GROUP）。映射表本身要作为合规材料存档——审查员要看的不是"你开了审计"，而是"你的审计为什么长这样"。

⚠️ 审计的两类静默失效：一是 ON_FAILURE 配了 CONTINUE 却没配告警——审计盘满了持续丢日志几个月无人知晓；二是审计对象覆盖了 public 角色却没盖住新加的应用账号——语义上没错，覆盖面却随时间缩水。审计覆盖面要随权限矩阵一起年检。

运营闭环：从记录到追责

审计的价值在运营闭环里兑现。四步闭环：采集——审计文件或安全日志汇入集中日志平台，实例本地只留短期缓冲；告警——对高价值事件配实时规则（非工作时段的整表导出、对象结构变更、连续失败登录），审计的威慑力全部来自"会被当场发现"的预期；留存——按合规保留期归档，文件加校验防篡改；复盘——每次安全事件或合规检查后回放审计链，补策略盲区。一次真实复盘案例：某系统审计记录显示每周日凌晨有大批量 SELECT 导出，追查是外包团队在做"数据维护"，从未报备——技术上没越权，流程上无授权。结案不是加权限限制，而是把外包维护纳入工单审批流。审计发现的多数问题最终落在流程上，这是正常且健康的闭环输出。

审计数据的分析姿势

审计文件落了地，还要会读。基础查询用系统函数读取审计文件并按需过滤：按时间窗、按动作类型、按数据库对象聚合，几行语句就能回答"过去一周谁动过这张表"。进阶分析靠三条固定规则跑在日志平台上：失败登录尖峰（一分钟内同账号或同来源连续失败超阈值，爆破尝试）；非时段操作（维护窗口外的结构变更与大导出，命中即通知）；权限使用漂移（某账号首次使用了它从未用过的高危权限，账号被盗的典型行为特征）。规则的价值在"少而准"——十条高噪音规则不如三条人人会点开的告警。
归档策略补一句：审计文件按月滚动归档，保留期以最长的合规要求为准，归档介质加完整性校验。有一类审查会抽验"三年前某天的审计是否可读且未篡改"——能当场调出原始文件并演示校验通过，审查就过了大半。审计体系的最终形态不是功能开关，而是一条随时可调用的证据流水线。

本节要点回顾

• 先有策略再谈配置：要回答什么、记在哪里、记多细，三问不清的审计必然沦为摆设；
• 内核级审计绕不过：服务器审计定去向，审计规范定内容，动作组与具体动作两级粒度；
• 条款翻译成动作组：合规映射表既是配置依据也是审查材料，"为什么长这样"要能讲清；
• 两类静默失效：失败不告警的 CONTINUE、覆盖面随账号增长缩水，都要靠年检兜住；
• 闭环四步：采集、告警、留存、复盘，威慑力来自"会被当场发现"；
• 多数发现落在流程：审计暴露的常常不是技术漏洞而是流程漏洞，这是它的健康输出。

三道门全部砌完：门禁、加密、行车记录仪。下一章回到主线任务——性能监控与持续调优，把分散在前六章的取证工具串成一套日常方法论。