7.3 审计与合规

7.3 审计与合规

本节摘要：审计不是抓人，是把"谁在什么时候对什么数据做了什么"变成不可抵赖的基础设施。本节讲统一审计的配置方法、细粒度审计的精准记录，以及审计记录自身防篡改的两道措施，并以一次泄露追查的全过程演示审计记录的实战读法。

一、审计不是为了抓人

7.1 的权限梳理管住了"谁能干什么"，7.2 的加密管住了"带走能不能看"，但还有一类问题悬着：有权的人有没有越权地用？工资表管理员有权查，但上周有人查了全表 3000 行——是正常的吗？没有审计，这个问题永远没有答案；有了审计，它变成一条可以回放的事实链。内控与合规对审计的要求可以归纳成三个"可"：可追溯（每个敏感操作能定位到人、时间、对象、动作）、可告警（异常行为发生时能及时知道，而不是半年后翻账）、可保全（记录本身不被操作者删改）。三"可"齐了，审计才从纸面义务变成能力。

二、统一审计：12c 之后的正解

老式的传统审计（AUDIT 命令加 audit_trail 参数）功能够用但配置散乱：审计策略散在字典各处、开关混在参数里、记录格式不一。12c 起的**统一审计（Unified Auditing）**把一切收进一个管道：审计策略用一段声明式配置表达，全部记录进统一的审计轨迹（默认写入表，可推送到外部审计仓库），管理面从"几十条散装命令"变成"几张策略清单"。

-- 确认统一审计已启用
SELECT value FROM v$option WHERE parameter = 'Unified Auditing';
-- 策略一：敏感表审计——工资表的查询与导出动作全部记录
CREATE AUDIT POLICY payroll_access
  ACTIONS SELECT ON hr.salaries,
          UPDATE ON hr.salaries
  WHEN 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') IS NOT NULL'
  EVALUATE PER SESSION;
AUDIT POLICY payroll_access;
-- 策略二：特权操作审计——任何会话以 SYSDBA 做的管理动作
CREATE AUDIT POLICY privileged_actions
  ACTIONS COMPONENT = DIRECT_PATH LOAD;
AUDIT POLICY privileged_actions BY SYS, SYSTEM;
-- 查询审计记录：最近一小时谁碰过工资表
SELECT dbusername, event_timestamp, action_name,
       object_schema, object_name, sql_text
  FROM unified_audit_trail
 WHERE object_name = 'SALARIES'
   AND event_timestamp > SYSDATE - 1/24
 ORDER BY event_timestamp DESC;
​

配置审计有两条成本纪律。其一，审计有开销：每条被审计的动作多一次写记录的成本，"全库全动作审计"会把交易系统拖出两位数的损耗——审计策略要像权限一样按"敏感对象加特权动作"精准圈定，而不是贪全。其二，审计有容量：统一审计轨迹表会持续膨胀，要配定期归档与清理作业（按合规保留期，通常一到三年），别让审计表自己成为全库最大的对象。

三、细粒度审计与记录保全

**细粒度审计（Fine-Grained Auditing）**解决"审计太粗"的另一半问题：统一审计记录"谁查了工资表"，细粒度审计能记录"查了超过 10 行工资数据的会话"——按条件触发、按列圈定、可配告警处理器（FGA 的策略处理器能在触发时自动发消息）。防内鬼批量拉数的场景，它比统一审计精准得多。

记录保全是审计的命门：审计记录写在库内，而审计要防的恰是有权动库的人——DBA 自己。两道措施构成底线。第一道，权限隔离：审计轨迹的清理权限单独授权、操作留痕，回收 DBA 角色对审计表的操作权（统一审计体系对此有内建保护）。第二道，外送异地：审计记录实时或定时推送出库，交给独立的日志平台或审计仓库，库内被篡改也有异地副本——"记录的生存能力必须高于被审计对象的控制权"，这是审计体系设计的第一原则。

图 7-2：审计记录的流转与保全链路

四、案例：一次批量查询泄露的追查全程

背景。 HR 反馈：猎头似乎掌握了全公司薪酬分布。管理层要求三天内回答：数据是否从库内流出、谁经手、走什么通道。

操作。 追查按证据链三步。第一步，时间窗圈定：猎头侧的薪酬数据特征指向最近两个月，先查这期间工资表的全部访问——统一审计轨迹按对象聚合，命中 41 个会话，其中 38 个是 HR 应用账号（正常业务模式：单行、低频），3 个是个人账号直连。第二步，行为画像：用细粒度审计与 ASH 交叉，3 个直连会话里有 1 个在凌晨 1:40 执行了无条件的全表查询，行数 3200，来源 IP 是办公网段一台笔记本的地址——不是跳板机。第三步，通道确认：该账号是五年前发出去的分析岗位临时账号（7.1 梳理清单里漏掉的漏网之鱼），有 SELECT 权限、无审计外送遮挡。

结果。 48 小时内完成事实链：某分析岗员工用遗留账号从笔记本直连拉取全表。后续动作按流程走：账号立即冻结、按制度上报、全库启动第二轮权限梳理。解读。 这个案子的复盘价值在"为什么能查出来"：审计策略在事发前就配置了敏感表审计——追查靠的是存量记录，不是临时开审计（临时开的审计只能保未来，不能还过去）。变式。 若该库只开了统一审计而没覆盖工资表，追查就只剩操作系统层的连接日志，能定位到"有人连过"却拿不到"查了什么"——敏感对象清单要定期与业务对齐，新上的敏感表同步进审计策略。

⚠️ 常见坑：审计上线后无人看记录。告警才是审计的活性成分——把"非工作时间访问敏感表""单会话行数超阈值""特权账号异常登录"三类事件接到值班告警链路，审计才从"事后取证"升级为"事中拦截"。

五、常见问题

问题一：审计记录里能看到查了哪些值吗？ 统一审计记录的是动作与对象，不含数据值；细粒度审计可配置记录 SQL 全文（含绑定值）。记录 SQL 文本的隐私与存储成本都高，通常只对最高敏对象开启，并让这些记录同样进入外送保全的通道——审计的边界本身也要按最小化原则设计。

问题二：合规检查最常扣分的三处是什么？ 经验排序：审计未覆盖特权账号的变更操作（建用户、授权动作没进审计）、记录保留期不达标（合规要求三年、实际只留三十天）、审计表无保护（DBA 可静默清理）。三处都能用一套配置整改，缺的是把合规条款翻译成检查项的那张对照表。

问题三：告警的阈值怎么定才不狼来了？ 从基线学起：先跑两周只记录不告警，按对象与账号的访问模式统计出正常区间，再在正常区间外设置阈值。直接拍脑袋的阈值要么天天误报被运维静音，要么形同虚设——阈值是学出来的，不是定的。

本节要点回顾

• 三"可"标准：可追溯、可告警、可保全——合规检查表按这三条逐项对，少一条都是纸面审计。
• 统一审计是配置的正解：策略声明式、记录单一管道；策略要精准圈定，贪全会拖垮交易库。
• FGA 管精准打击：按条件与列触发的审计，防批量拉数比统一审计灵敏。
• 保全高于一切：权限隔离加外送异地，记录的生存能力必须高于被审计者的控制权。

第 7 章把安全三问答完。下一章把视野拉高：几十套库怎么收进一个容器、机房怎么搬进云、内核怎么自己值班——多租户、云化与自治演进。