忘れかけのIT備忘録

今まで学んできた知識や小技、なるほど!と思ったことをメモするブログです。

Oracleの監査の検証(従来型監査編)

この記事は、JPOUG Advent Calendar 2022 16日目の記事です。
15日目はNAKASHOU06さんの記事「~クラウド1年生に贈るクラウド利用Tips~ - Qiita」でした。

今回はOracleの監査について検証しました。
監査はシステムのセキュリティ(機密性)を確保する手段の1つで、DBに対する操作を監視(記録)する機能です。
主に「誰が」、「いつ」、「何をしたか」を記録し、DBに対して不正なアクセスや操作がないか監視するのが目的です。

12c以降の場合、監査は2種類(従来型監査・統合監査)使用できますが、今回は従来型監査を検証しました。
今さら従来型監査の検証…という声も聞こえそうですが、統合監査との動きを比較するため、先ず従来型監査の動きを復習しました。
※個人の検証結果に基づく見解のため、正確性に欠ける可能性があります
※20c以降の場合、従来型監査は非推奨となっているため、設計する際はご注意ください (参考) AUDIT (従来型監査)

従来型監査は、必須監査、DBA監査、標準監査(標準データベース監査)、ファイングレイン監査(FGA監査)の監査証跡(監査ログ)をOSファイルやDBに出力します。

必須監査
特権ユーザ(SYSDBA/SYSOPER/SYSASM権限など)の操作を監査します
※必ず実施されるため、無効化できません

【監査対象】
インスタンス起動/停止
・特権ユーザによるインスタンス接続
【出力先】
UNIX
OSファイル(AUDIT_FILE_DEST初期化パラメータで設定したパス/<インスタンス名>_ora_<プロセスID>_<監査日時>.aud)
※DBインスタンス停止中は$ORACLE_HOME/rdbms/audit/<インスタンス名>_ora_<プロセスID>_<監査日時>.audに出力されます
Windows
イベントビューワ(未検証)

DBA監査
特権ユーザ(SYSDBA/SYSOPER権限など)の操作を監査します
必須監査はインスタンス起動/停止や接続を監査しますが、DBA監査は特権ユーザのDB内の操作を監査します
AUDIT_SYS_OPERATIONS初期化パラメータがTRUEの場合、有効になります

【監査対象】
・特権ユーザによるDB内の操作
【出力先】
UNIX
OSファイル(AUDIT_FILE_DEST初期化パラメータで設定したパス/<インスタンス名>_ora_<プロセスID>_<監査日時>.aud)
Windows
イベントビューワ(未検証)

標準監査(標準データベース監査)
一般ユーザのDBの操作を監査します
表に影響を与えるDDL文(CREATE TABLE/DROP TABLE/TRUNCATE TABLEなど)のSQL文や権限(システム権限、オブジェクト権限)の使用を監査します
SQL文の監査は成功(WHENEVER SUCCESSFUL)、失敗(WHENEVER NOT SUCCESSFUL)で監査対象の操作を絞れます

【監査対象】
・一般ユーザによるDBインスタンスへの接続
・一般ユーザによる特定のDDL文(DB構造の変更)の操作 (例)テーブル作成
・一般ユーザによるシステム権限を使用した操作 (例)CREATE ANY TABLE権限の使用
・一般ユーザによるオブジェクト権限を使用した操作 (例)SCOTT.EMP表へのSELECT
【出力先】
AUDIT_TRAIL初期化パラメータの設定値によって出力先が異なります
AUDIT_TRAIL=os、xmlxml,extendedのいずれか
OSファイル(AUDIT_FILE_DEST初期化パラメータで設定したパス/<インスタンス名>_ora_<プロセスID>_<監査日時>.aud)
※AUDIT_TRAIL=xml,extendedの場合、SQL文、バインド変数も出力します
WindowsでAUDIT_TRAIL=osの場合、イベントビューワ(未検証)

AUDIT_TRAIL=db、db,extendedのいずれか
DBA_AUDIT_TRAILビュー(SYS.AUD$表)
※AUDIT_TRAIL=db,extendedの場合、SQL文、バインド変数も出力します

値ベース監査
特権/一般ユーザのDB内の操作のうち、値の変化を監査します
例えばUPDATE文の場合、標準監査でSQL文は監査できますが、変更前後の値は監査できません
必須監査みたいに事前に組み込まれた監査機能ではないため、事前に変更前後の値を書き込むテーブルとUPDATE後に変更前後の値をテーブルに書き込むトリガーの作成が必要です
UPDATE文を実行するたびトリガーも実行される(DBへの負荷も増える)ため、注意が必要です

【監査対象】
UPDATE文などによる変更前後の値
【出力先】
ユーザが作成した値ベース監査用のテーブル

ファイングレイン監査(FGA監査)
特権/一般ユーザのデータベース内の操作(DML)を監査します
特定のテーブルのレコードの検索条件や監査対象の列、SQL文などの監査条件を指定して、標準監査よりさらに細かく監査します
※Enterprise Editionのみ

【監査対象】
監査ポリシーに合致したデータへの操作(DML)
【出力先】
DBA_FGA_AUDIT_TRAILビュー(SYS.FGA_LOG$表)
※AUDIT_TRAIL=db,extendedの場合、標準監査とファイングレイン監査の監査ログをDBA_COMMON_AUDIT_TRAILビューで参照可能

■検証環境
OS:Oracle Linux 6.5
GI:Oracle Grid Infrastructure 12c Release 1 (12.1.0.2.0) Enterprise Edition
DB:Oracle Database 12c Release 1 (12.1.0.2.0) Enterprise Edition
※2ノードRAC(管理者管理型DB)

■前提
・非CDB
・従来型監査のみ

■設定内容
事前に下記のとおり設定しています

統合監査設定
SQL> select inst_id, parameter, value from gv$option where parameter = 'Unified Auditing';

INST_ID PARAMETER            VALUE
------- -------------------- --------------------
      1 Unified Auditing     FALSE
      2 Unified Auditing     FALSE

【参考】統合監査(混合モード)無効化
1. 有効な監査ポリシー確認
SQL> select * from audit_unified_enabled_policies;

USER_NAME       POLICY_NAME          ENABLED_OPT              SUCCESS   FAILURE
--------------- -------------------- ------------------------ --------- ---------
ALL USERS       ORA_SECURECONFIG     BY                       YES       YES
ALL USERS       ORA_LOGON_FAILURES   BY                       YES       YES

2. 監査ポリシー取り消し
SQL> noaudit policy ORA_SECURECONFIG;

監査取消しが成功しました。

SQL> noaudit policy ORA_LOGON_FAILURES;

監査取消しが成功しました。

3. 有効な監査ポリシー確認
SQL> select * from audit_unified_enabled_policies;

レコードが選択されませんでした。

ASMの監査設定
SQL> --監査ログ(OSファイル)の出力先(デフォルト)
SQL> select inst_id, name, value from gv$parameter where name = 'audit_file_dest';

INST_ID NAME                           VALUE
------- ------------------------------ ----------------------------------------
      1 audit_file_dest                /u01/app/12.1.0/grid/rdbms/audit
      2 audit_file_dest                /u01/app/12.1.0/grid/rdbms/audit

DBの監査設定
SQL> --監査ログ(OSファイル)の出力先(デフォルト)
SQL> select inst_id, name, value from gv$parameter where name = 'audit_file_dest';

INST_ID NAME                           VALUE
------- ------------------------------ ----------------------------------------
      1 audit_file_dest                /u01/app/oracle/admin/orcl/adump
      2 audit_file_dest                /u01/app/oracle/admin/orcl/adump

SQL> --DBA監査設定(デフォルト)
SQL> select inst_id, name, value from gv$parameter where name = 'audit_sys_operations';

INST_ID NAME                           VALUE
------- ------------------------------ ----------------------------------------
      1 audit_sys_operations           TRUE
      2 audit_sys_operations           TRUE

 

■検証パターン
①必須監査
②DBA監査
③標準監査(標準データベース監査)
④値ベース監査
ファイングレイン監査(FGA監査)

■検証
①必須監査
特権ユーザの必須監査対象の操作が監査されるか検証します
検証環境はRACなのでASMとDBの起動/停止、接続を検証します
本検証では
・ASM操作はSYS(SYSASM権限)
・DB操作はSYS(SYSDBA権限)
を使用します

【検証手順】
1. ASMインスタンス停止
2. ASMインスタンス起動
3. ASMインスタンス接続
4. DBインスタンス停止
5. DBインスタンス起動
6. DBインスタンス接続

【想定】
必須監査対象の操作が監査されること

【検証結果】
必須監査対象の操作が監査された

【作業ログ】

1. ASMインスタンス停止
[root@node1 ~]# /u01/app/12.1.0/grid/bin/crsctl stop crs

#監査ログ確認
[root@node1 ~]# cat /u01/app/12.1.0/grid/rdbms/audit/+ASM1_ora_14288_20221124204627247146143795.aud
Thu Nov 24 20:46:30 2022 +09:00
LENGTH : '154'
ACTION :[18] 'SHUTDOWN IMMEDIATE'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSASM'
CLIENT USER:[4] 'grid'
CLIENT TERMINAL:[0] ''
STATUS:[1] '0'
DBID:[0] ''
★SYSASM権限でASMインスタンス停止した監査ログが出力された

2. ASMインスタンス起動
[root@node1 ~]# /u01/app/12.1.0/grid/bin/crsctl start crs -wait

#監査ログ確認
[root@node1 ~]# cat /u01/app/12.1.0/grid/rdbms/audit/+ASM1_ora_19856_20221124204915718819143795.aud
Thu Nov 24 20:49:15 2022 +09:00
LENGTH : '142'
ACTION :[7] 'STARTUP'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSASM'
CLIENT USER:[4] 'grid'
CLIENT TERMINAL:[0] ''
STATUS:[1] '0'
DBID:[0] ''
★SYSASM権限でASMインスタンス起動した監査ログが出力された

3. ASMインスタンス接続
[grid@node1 ~]$ sqlplus / as sysasm

#監査ログ確認
[root@node1 ~]# cat /u01/app/12.1.0/grid/rdbms/audit/+ASM1_ora_22562_20221124205356529751143795.aud
Thu Nov 24 20:53:56 2022 +09:00
LENGTH : '147'
ACTION :[7] 'CONNECT'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSASM'
CLIENT USER:[4] 'grid'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[0] ''
★SYSASM権限でASMインスタンス接続した監査ログが出力された

4. DBインスタンス停止
[oracle@node1 ~]$ srvctl stop database -db orcl

#監査ログ確認
[root@node1 ~]# cat /u01/app/oracle/admin/orcl/adump/orcl1_ora_22996_20221124205518173254143795.aud
Thu Nov 24 20:55:34 2022 +09:00
LENGTH : '156'
ACTION :[18] 'SHUTDOWN IMMEDIATE'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[0] ''
STATUS:[1] '0'
DBID:[0] ''
★SYSDBA権限でDBインスタンス停止した監査ログが出力された

5. DBインスタンス起動
[oracle@node1 ~]$ srvctl start database -db orcl

#監査ログ確認
[root@node1 ~]# cat /u01/app/oracle/admin/orcl/adump/orcl1_ora_24752_20221124205952460023143795.aud
Thu Nov 24 20:59:52 2022 +09:00
LENGTH : '144'
ACTION :[7] 'STARTUP'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[0] ''
STATUS:[1] '0'
DBID:[0] ''
★SYSDBA権限でDBインスタンス起動した監査ログが出力された

【補足】
DBインスタンス起動/停止はクラスタを跨ぐ操作かどうかで監査ログの出力先が変わります
クラスタを跨ぐ場合:全DBサーバに監査ログを出力(※1)
クラスタを跨がない(ノード単位)場合:操作対象のDBサーバに監査ログを出力(※2)
(※1) 例. srvctl start database -db orcl
(※2) 例. srvctl start instance -db orcl -node node1

6. DBインスタンス接続
[oracle@node1 ~]$ sqlplus / as sysdba

#監査ログ確認
[root@node1 ~]# cat /u01/app/oracle/admin/orcl/adump/orcl1_ora_31455_20221124211423662296143795.aud
Thu Nov 24 21:14:23 2022 +09:00
LENGTH : '160'
ACTION :[7] 'CONNECT'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[10] '1646447705'
★SYSDBA権限でDBインスタンス接続した監査ログが出力された

 

②DBA監査
特権ユーザのDBA監査対象の操作が監査されるか検証します
本検証ではSYS(SYSDBA権限)を使用します

【検証手順】
1. データディクショナリ問合せ
2. データ更新

【想定】
DBA監査対象の操作が監査されること

【検証結果】
DBA監査対象の操作が監査された

【作業ログ】

1. データディクショナリ問合せ
SQL> select count(*) from dba_users;

  COUNT(*)
----------
        42

#監査ログ確認
[root@node1 ~]# cat /u01/app/oracle/admin/orcl/adump/orcl1_ora_31987_20221124211615877436143795.aud
Thu Nov 24 21:16:17 2022 +09:00
LENGTH : '184'
ACTION :[30] 'select count(*) from dba_users'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[10] '1646447705'
★SYSDBA権限でデータディクショナリアクセスした監査ログが出力された

2. データ更新
SQL> update scott.emp set SAL = 1000 where EMPNO = 7369;

1行が更新されました。

#監査ログ確認
[root@node1 ~]# cat /u01/app/oracle/admin/orcl/adump/orcl1_ora_32177_20221124211651203243143795.aud
Thu Nov 24 21:18:06 2022 +09:00
LENGTH : '204'
ACTION :[50] 'update scott.emp set SAL = 1000 where EMPNO = 7369'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/0'
STATUS:[1] '0'
DBID:[10] '1646447705'
★SYSDBA権限でデータ更新した監査ログが出力された

 

③標準監査(標準データベース監査)
一般ユーザの標準監査対象の操作が監査されるか検証します
本検証ではSCOTT(サンプルユーザ)を使用します

【検証手順】
1. AUDIT_TRAIL初期化パラメータ設定
2. 監査オプション設定
3. ノード1からSCOTTでDBログイン(間違ったパスワード)
4. ノード2からSCOTTでDBログイン(間違ったパスワード)
5. SCOTTでテーブル作成
6. SCOTTでデータ挿入

【想定】
標準監査対象の操作が監査されること

【検証結果】
標準監査対象の操作が監査された

【作業ログ】

1. AUDIT_TRAIL初期化パラメータ設定
SQL> alter system set audit_trail = db, extended scope=spfile sid='*';

システムが変更されました。

SQL> select inst_id, name, value from gv$parameter where name = 'audit_trail';

INST_ID NAME                           VALUE
------- ------------------------------ ----------------------------------------
      1 audit_trail                    DB, EXTENDED
      2 audit_trail                    DB, EXTENDED
※反映させるため、DB再起動しています

2. 監査オプション設定
SQL> --ログイン失敗検証用
SQL> audit SESSION by SCOTT by access whenever not successful;

監査が成功しました。

SQL> --テーブル作成検証用
SQL> audit TABLE by SCOTT by access;

監査が成功しました。

SQL> --データ操作検証用
SQL> audit INSERT on scott.emp by access;

監査が成功しました。

SQL> select user_name, audit_option, success, failure from dba_stmt_audit_opts order by audit_option;

USER_NAME            AUDIT_OPTION         SUCCESS         FAILURE
-------------------- -------------------- --------------- ---------------
SCOTT                CREATE SESSION       NOT SET         BY ACCESS
SCOTT                TABLE                BY ACCESS       BY ACCESS
★オブジェクト権限の監査オプションは表示されなかった…

3. ノード1からSCOTTでDBログイン(間違ったパスワード)
[oracle@node1 ~]$ sqlplus scott/machigai

SQL*Plus: Release 12.1.0.2.0 Production on 木 11月 24 22:17:58 2022

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

ERROR:
ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。

#監査ログ確認
SQL> select TO_CHAR(TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as TS, USERNAME, USERHOST, OWNER, OBJ_NAME, ACTION_NAME, SQL_TEXT from dba_audit_trail order by TIMESTAMP desc;

TS                   USERNAME        USERHOST             OWNER           OBJ_NAME        ACTION_NAME          SQL_TEXT
-------------------- --------------- -------------------- --------------- --------------- -------------------- --------------------------------------------------------------------------------
2022/11/24 22:17:59  SCOTT           node1.oracle12c.jp                                   LOGON
★ノード1でSCOTTがログイン失敗した監査ログが出力された

4. ノード2からSCOTTでDBログイン(間違ったパスワード)
[oracle@node2 ~]$ sqlplus scott/machigai

SQL*Plus: Release 12.1.0.2.0 Production on 木 11月 24 22:19:29 2022

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

ERROR:
ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。

#監査ログ確認
SQL> select TO_CHAR(TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as TS, USERNAME, USERHOST, OWNER, OBJ_NAME, ACTION_NAME, SQL_TEXT from dba_audit_trail order by TIMESTAMP desc;

TS                   USERNAME        USERHOST             OWNER           OBJ_NAME        ACTION_NAME          SQL_TEXT
-------------------- --------------- -------------------- --------------- --------------- -------------------- --------------------------------------------------------------------------------
2022/11/24 22:19:30  SCOTT           node2.oracle12c.jp                                   LOGON
★ノード2でSCOTTがログイン失敗した監査ログが出力された

5. SCOTTでテーブル作成
SQL> create table test_table(id number, text varchar(10), create_time date);

表が作成されました。

#監査ログ確認
SQL> select TO_CHAR(TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as TS, USERNAME, USERHOST, OWNER, OBJ_NAME, ACTION_NAME, SQL_TEXT from dba_audit_trail order by TIMESTAMP desc;

TS                   USERNAME        USERHOST             OWNER           OBJ_NAME        ACTION_NAME          SQL_TEXT
-------------------- --------------- -------------------- --------------- --------------- -------------------- --------------------------------------------------------------------------------
2022/11/24 22:20:10  SCOTT           node1.oracle12c.jp   SCOTT           TEST_TABLE      CREATE TABLE         create table test_table(id number, text varchar(10), create_time date)
★SCOTTがCREATE TABLE権限を使用した監査ログが出力された

6. SCOTTでデータ挿入
SQL> insert into emp(EMPNO, ENAME, JOB, MGR, HIREDATE, SAL, COMM, DEPTNO) values(9999, 'TEST', 'DBA', 7369, sysdate, 2000, 500, 10);

1行が作成されました。

#監査ログ確認
SQL> select TO_CHAR(TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as TS, USERNAME, USERHOST, OWNER, OBJ_NAME, ACTION_NAME, SQL_TEXT from dba_audit_trail order by TIMESTAMP desc;

TS                   USERNAME        USERHOST             OWNER           OBJ_NAME        ACTION_NAME          SQL_TEXT
-------------------- --------------- -------------------- --------------- --------------- -------------------- --------------------------------------------------------------------------------
2022/11/24 22:24:44  SCOTT           node1.oracle12c.jp   SCOTT           EMP             INSERT               insert into emp(EMPNO, ENAME, JOB, MGR, HIREDATE, SAL, COMM, DEPTNO) values(9999
                                                                                                               , 'TEST', 'DBA', 7369, sysdate, 2000, 500, 10)
★SCOTTがINSERT権限を使用した監査ログが出力された

 

④値ベース監査
ユーザがデータ更新した際、変更前後の値が監査されるか検証します
本検証ではSCOTT(サンプルユーザ)を使用します

【検証手順】
1. 値ベース監査用テーブル作成
2. 値ベース監査用トリガー作成
3. SCOTTでデータ更新

【想定】
変更前後の値が監査されること

【検証結果】
変更前後の値が監査された

【作業ログ】

1. 値ベース監査用テーブル作成
SQL> create table audit_emp_sal(username varchar2(30), create_date date, empno number, new_sal number, old_sal number);

表が作成されました。

2. 値ベース監査用トリガー作成
SQL> create or replace trigger trg_audit_emp_sal after update of sal on scott.emp referencing new as new old as old for each row
  2  begin
  3    if :old.sal != :new.sal then
  4      insert into audit_emp_sal values(sys_context('userenv', 'session_user'), sysdate, :new.empno, :new.sal, :old.sal);
  5    end if;
  6  end;
  7  /

トリガーが作成されました。
★SCOTTのEMP表のSAL列を更新(UPDATE)後、変更前後の値をAUDIT_EMP_SAL表に書き込むように設定

3. SCOTTでデータ更新
SQL> select * from emp where EMPNO = 7369;

     EMPNO ENAME      JOB               MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- ---------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK            7902 80-12-17       1000                    10

SQL> update emp set SAL = 9999 where EMPNO = 7369;

1行が更新されました。

SQL> commit;

コミットが完了しました。

SQL> select * from emp where EMPNO = 7369;

     EMPNO ENAME      JOB               MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- ---------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK            7902 80-12-17       9999                    10

#監査ログ確認
SQL> select USERNAME, TO_CHAR(CREATE_DATE, 'YYYY/MM/DD HH24:MI:SS') as CREATE_DATE, EMPNO, NEW_SAL, OLD_SAL from audit_emp_sal;

USERNAME        CREATE_DATE               EMPNO    NEW_SAL    OLD_SAL
--------------- -------------------- ---------- ---------- ----------
SCOTT           2022/11/24 22:30:38        7369       9999       1000
★SCOTTのUPDATE文による変更前(OLD_SAL)、変更後(NEW_SAL)の値が監査ログに出力された

 

ファイングレイン監査(FGA監査)
ユーザのファイングレイン監査対象の操作が監査されるか検証します
本検証ではSCOTT(サンプルユーザ)を使用します

【検証手順】
1. ファイングレイン監査ポリシー作成
2. 監査ポリシーに該当するパターン1
3. 監査ポリシーに該当するパターン2
4. 監査ポリシーに該当しないパターン1
5. 監査ポリシーに該当しないパターン2

【想定】
ファイングレイン監査対象の操作が監査されること

【検証結果】
ファイングレイン監査対象の操作が監査された

【作業ログ】

1. ファイングレイン監査ポリシー作成
SQL> exec dbms_fga.add_policy(object_schema => 'SCOTT', object_name => 'EMP', policy_name => 'fga_audit_emp_sal', audit_condition => 'DEPTNO=10', audit_column => 'SAL', enable => TRUE, statement_types => 'SELECT');

PL/SQLプロシージャが正常に完了しました。
★DEPTNOが10のレコードのSAL列をSELECTしたら監査するように設定

2. 監査ポリシーに該当するパターン1
SQL> select empno, ename, sal, deptno from emp;

     EMPNO ENAME             SAL     DEPTNO
---------- ---------- ---------- ----------
      7369 SMITH            9999         10
      7499 ALLEN            1600         30
      7521 WARD             1250         30
      7566 JONES            2975         20
      7654 MARTIN           1250         30
      7698 BLAKE            2850         30
      7782 CLARK            2450         10
      7839 KING             5000         10
      7844 TURNER           1500         30
      7900 JAMES             950         30
      7902 FORD             3000         20
      7934 MILLER           1300         10

#監査ログ確認
SQL> select TO_CHAR(TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as TS, DB_USER, USERHOST, OBJECT_NAME, SQL_TEXT, STATEMENT_TYPE from dba_fga_audit_trail order by TS desc;

TS                   DB_USER         USERHOST             OBJECT_NAME     SQL_TEXT                                                                         STATEMENT_TYPE
-------------------- --------------- -------------------- --------------- -------------------------------------------------------------------------------- ---------------
2022/11/24 22:32:35  SCOTT           node1.oracle12c.jp   EMP             select empno, ename, sal, deptno from emp                                        SELECT
★EMPNO7369・7782・7839・7934のレコードのDEPTNOが10で、SAL列をSELECTしているため、監査ログが出力された

3. 監査ポリシーに該当するパターン2
SQL> select empno, ename, sal, deptno from emp where deptno = 10;

     EMPNO ENAME             SAL     DEPTNO
---------- ---------- ---------- ----------
      7369 SMITH            9999         10
      7782 CLARK            2450         10
      7839 KING             5000         10
      7934 MILLER           1300         10

#監査ログ確認
SQL> select TO_CHAR(TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as TS, DB_USER, USERHOST, OBJECT_NAME, SQL_TEXT, STATEMENT_TYPE from dba_fga_audit_trail order by TS desc;

TS                   DB_USER         USERHOST             OBJECT_NAME     SQL_TEXT                                                                         STATEMENT_TYPE
-------------------- --------------- -------------------- --------------- -------------------------------------------------------------------------------- ---------------
2022/11/24 22:32:42  SCOTT           node1.oracle12c.jp   EMP             select empno, ename, sal, deptno from emp where deptno = 10                      SELECT
★DEPTNOを10で絞って、SAL列をSELECTしているため、監査ログが出力された

4. 監査ポリシーに該当しないパターン1
SQL> select empno, ename, sal, deptno from emp where deptno = 20;

     EMPNO ENAME             SAL     DEPTNO
---------- ---------- ---------- ----------
      7566 JONES            2975         20
      7902 FORD             3000         20

#監査ログ確認
★SAL列をSELECTしているがDEPTNOを20で絞っているため、監査ログが出力されない

5. 監査ポリシーに該当しないパターン2
SQL> select empno, ename, job, deptno from emp where deptno = 10;

     EMPNO ENAME      JOB            DEPTNO
---------- ---------- ---------- ----------
      7369 SMITH      CLERK              10
      7782 CLARK      MANAGER            10
      7839 KING       PRESIDENT          10
      7934 MILLER     CLERK              10

#監査ログ確認
★SAL列をSELECTしていないため、監査ログが出力されない

 

■参考資料
AUDIT (従来型監査)
https://www.oracle.com/jp/a/tech/docs/technical-resources/db-audit-100831.pdf

■おわりに
監査ログを自動的に削除する機能はないため、削除運用も設計が必要です。
監査は機密性を確保する手段でしたが、完全性や可用性は同時実行性やバックアップ・リカバリなどで確保します。

次回は従来型監査で監査した項目を統合監査で監査した場合、どのように監査されるのか検証しようと思います。

最後までお読みいただきありがとうございました。
17日目の記事もお楽しみに!