使用触发器来审计表的DML、DDL操作

最近帮客户排查某问题时,因为怀疑应用对某张配置表有变更,所以需要对这张表的所有操作进行审计。

原本Oracle对某张表的审计是非常方便的,一条命令就可以实现,也不需要费心自定义审计表。

-- 启用对表DEPT的插入、更新和删除操作的审计
AUDIT INSERT, UPDATE, DELETE ON DEPT BY ACCESS;

-- 查看对DEPT表的所有审计记录
SELECT * FROM DBA_AUDIT_TRAIL WHERE OBJ_NAME = 'DEPT';

-- 停用对表DEPT的审计
NOAUDIT INSERT, UPDATE, DELETE ON DEPT;

但不幸的是,因为客户当前环境已经把默认开启的audit_trail给关闭了。(默认开启,默认值是DB,关闭就是NONE)
笔者已经在实验环境验证过:
– 1.audit_trail必须开的情况下,对表进行审计才会有记录;
– 2.audit_trail是静态参数,如果修改,需要重启数据库才可以生效。

尤其注意要检查这个参数的设置情况,因为这里比较坑的一点是,上述审计命令,即便你关了这个参数,开启表审计的命令执行也并不会报错,只是实际上无法记录。

相信大家都知道,生产环境的重启申请流程非常麻烦,因此只能用手工的方式,比如自定义触发器的方式来监控这张表的DML操作。

还好因为这个配置表正常情况下,并不会被频繁修改,所以使用触发器也不会带来什么性能问题。

下面就进入到hands-on环节,我们模拟下这个客户的需求,假设dept这张表:

-- 创建示例表DEPT
CREATE TABLE dept (
    deptno NUMBER(2) PRIMARY KEY,
    dname VARCHAR2(14),
    loc VARCHAR2(13)
);

-- 插入示例数据到DEPT表
INSERT INTO dept VALUES (10, 'ACCOUNTING', 'NEW YORK');
INSERT INTO dept VALUES (20, 'RESEARCH', 'DALLAS');
INSERT INTO dept VALUES (30, 'SALES', 'CHICAGO');
INSERT INTO dept VALUES (40, 'OPERATIONS', 'BOSTON');

commit;

针对dept表建立触发器如下:

-- CREATE TABLE
CREATE TABLE dml_audit(
modiy_time DATE, 
table_name VARCHAR2(30), 
deptno NUMBER(2), 
modiy_type VARCHAR2(14), 
dname VARCHAR2(14), 
loc VARCHAR2(13)
);

CREATE OR REPLACE TRIGGER dept_trg
BEFORE INSERT OR DELETE OR UPDATE ON dept
FOR EACH ROW
BEGIN
  IF inserting THEN 
    INSERT INTO dml_audit (modiy_time, table_name, deptno, modiy_type, dname, loc) 
    VALUES (sysdate, 'dept', :NEW.deptno, 'insert', :NEW.dname, :NEW.loc);
  END IF;

  IF deleting THEN 
    INSERT INTO dml_audit (modiy_time, table_name, deptno, modiy_type, dname, loc) 
    VALUES (sysdate, 'dept', :OLD.deptno, 'delete', :OLD.dname, :OLD.loc);
  END IF;

  IF updating THEN 
    INSERT INTO dml_audit (modiy_time, table_name, deptno, modiy_type, dname, loc) 
    VALUES (sysdate, 'dept', :OLD.deptno, 'update_before', :OLD.dname, :OLD.loc);

    INSERT INTO dml_audit (modiy_time, table_name, deptno, modiy_type, dname, loc) 
    VALUES (sysdate, 'dept', :NEW.deptno, 'update_after', :NEW.dname, :NEW.loc);
  END IF;
END;
/

测试下,确认delete、insert、update都可以监测到:

08:17:58 PRIMARY @DB0913_9DF_IAD -> JINGYU @DEMO2> select * from dml_audit;

no rows selected

Elapsed: 00:00:00.02
08:18:05 PRIMARY @DB0913_9DF_IAD -> JINGYU @DEMO2> delete from dept where deptno=10;

1 row deleted.

Elapsed: 00:00:00.22
08:18:41 PRIMARY @DB0913_9DF_IAD -> JINGYU @DEMO2> INSERT INTO dept VALUES (10, 'ACCOUNTING', 'NEW YORK');

1 row created.

Elapsed: 00:00:00.00
08:18:56 PRIMARY @DB0913_9DF_IAD -> JINGYU @DEMO2> update dept set LOC='China' where deptno=40;

1 row updated.

Elapsed: 00:00:00.04
08:19:25 PRIMARY @DB0913_9DF_IAD -> JINGYU @DEMO2> select * from dml_audit;

MODIY_TIME     TABLE_NAME                 DEPTNO MODIY_TYPE     DNAME      LOC
------------------ ------------------------------ ---------- -------------- -------------- -------------
07-AUG-24      dept                   10 delete     ACCOUNTING     NEW YORK
07-AUG-24      dept                   10 insert     ACCOUNTING     NEW YORK
07-AUG-24      dept                   40 update_before  OPERATIONS     BOSTON
07-AUG-24      dept                   40 update_after   OPERATIONS     China

Elapsed: 00:00:00.01

是否万事大吉了呢?

其实不是,因为客户问题是怀疑这个表有被改动,而改动其实不仅仅局限于DML操作。

我们假设一种极端场景,如果一个操作是将这张表drop后重建,然后插入一样的数据。

这样的场景,仅靠上面的触发器就无法记录到。因为表被drop时,对应的触发器也会被删除。
因为触发器是依赖于表存在的对象,当表被删除时,触发器也会失去作用的对象。

比如有这样一个init的脚本,功能是直接对配置表进行了drop删除然后重新创建初始化数据:

@init

那要如何做才能监控到这种极端情况呢?
也不难,再建立一个针对DDL的触发器,如果对dept表有ddl操作也记录到指定日志表。

-- 创建审计表
CREATE TABLE ddl_audit (
    event_time  TIMESTAMP,
    username    VARCHAR2(30),
    userhost    VARCHAR2(30),
    object_type VARCHAR2(30),
    object_name VARCHAR2(30),
    action      VARCHAR2(30)
);

-- 创建 DDL 触发器
CREATE OR REPLACE TRIGGER ddl_trigger
AFTER CREATE OR DROP ON SCHEMA
DECLARE
    v_username    VARCHAR2(30);
    v_userhost    VARCHAR2(30);
BEGIN
    SELECT USER, SYS_CONTEXT('USERENV', 'HOST') INTO v_username, v_userhost FROM DUAL;

    IF ORA_DICT_OBJ_NAME = 'DEPT' THEN
        INSERT INTO ddl_audit (
            event_time, username, userhost, object_type, object_name, action
        ) VALUES (
            SYSTIMESTAMP, v_username, v_userhost, ORA_DICT_OBJ_TYPE, ORA_DICT_OBJ_NAME, ORA_SYSEVENT
        );
    END IF;
END;
/

这样,如果真有这种DDL操作,也可以审计到,但需要注意,这个DDL的触发器的影响相对要大些,非必要情况先不要建。定位完问题后,及时删掉。

08:26:49 PRIMARY @DB0913_9DF_IAD -> JINGYU @DEMO2> select * from ddl_audit;

EVENT_TIME             USERNAME        USERHOST        OBJECT_TYPE            OBJECT_NAME     ACTION
------------------------------ --------------- --------------- ------------------------------ --------------- ------------------------------
07-AUG-24 08.25.11.885875 AM   JINGYU          demo        TABLE                  DEPT        DROP
07-AUG-24 08.25.12.167304 AM   JINGYU          demo        TABLE                  DEPT        CREATE
07-AUG-24 08.25.59.989356 AM   JINGYU          demo        TABLE                  DEPT        DROP
07-AUG-24 08.26.00.061629 AM   JINGYU          demo        TABLE                  DEPT        CREATE

Elapsed: 00:00:00.01

可以看到,这样触发器的方式,虽然比审计笨重,但也可以实现对表无论是DDL还是DML的跟踪记录,有了这些操作痕迹,自然就方便客户去进一步排查问题了。

This entry was posted in Oracle故障处理 and tagged , , . Bookmark the permalink.