Oracleの監査の検証（統合監査編）

前回の従来型監査で検証した項目を統合監査で検証した場合、実際の動きにどのような違いがあるのか検証しました。

統合監査についてざっくり復習します。

概要
12cから登場した新しい監査機能で、従来型監査(必須監査、DBA監査、標準監査(標準データベース監査)、ファイングレイン監査(FGA監査))の監査証跡(監査ログ)をDBの1つのビューに集約して管理します

メリット
・監査ログを1つのビューにしたことで監査ログを探さなくて済む
　→従来型監査は監査によって監査ログをOSファイルに出力したり、DBに出力したり管理が複雑になりやすいという管理上のデメリットがありました
・監査対象のDB操作に「OSユーザが○○だったら～」、「ホスト名が○○だったら～」など細かい条件を指定可能
　→例えば従来型監査はログインを監査するという設定はできますが、「OSユーザがoracleだったらログインを監査する」という設定はできませんでした
　　統合監査は「OSユーザがoracleだったらログインを監査する」という設定ができます
・Data PumpやRMANなどのツールも監査可能
・キュー書込み方式によるディスクI/O軽減(12.1)
　→従来型監査は監査が発生するたび、監査ログを実表に書き込んでいたため、その都度ディスクI/Oが発生していました
　　キュー書込み方式は監査ログをSGAに溜めておき、一定のタイミングで実表へ書き込むため、ディスクI/Oが減りパフォーマンス向上が期待できます
　　※ただし、インスタンス(メモリ)障害等で情報が欠落する可能性があるという理由で12.2で非推奨になりました (参考) 監査証跡の管理
・監査管理用ロール登場
　　→監査設定や参照は管理者権限(SYSDBA権限やDBAロール)が必要でしたが、監査管理用ロール(AUDIT_ADMIN、AUDIT_VIEWER)が登場したことで管理者じゃなくても監査設定や参照ができます
　　　AUDIT_ADMIN：監査ポリシー参照/作成/変更/削除/監査ログ参照など
　　　AUDIT_VIEWER：監査ログ参照

デメリット
・キュー書込み方式の場合、インスタンス(メモリ)障害等で情報が欠落する可能性がある
・DB破損してバックアップがない場合、監査ログを復旧できない可能性がある

【監査対象】
従来型監査の監査項目に加え、Data PumpやRMANなどのツールの操作(※1)
(※1) 監査の概要
【出力先】
UNIFIED_AUDIT_TRAILビュー(AUDSYS.CLI_SWP$xxx表)

■検証環境
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 TRUE
2 Unified Auditing TRUE

【参考】統合監査有効化
1. 統合監査設定確認
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

2. DB停止
[oracle@node1 ~]$ srvctl stop database -db orcl

3. 統合監査実行可能ファイル有効化
[oracle@node1 ~]$ cd $ORACLE_HOME/rdbms/lib
[oracle@node1 lib]$ pwd
/u01/app/oracle/product/12.1.0/dbhome_1/rdbms/lib
[oracle@node1 lib]$ ls -l libknlopt.a
-rw-r--r-- 1 oracle oinstall 1771642 11月 18 18:24 2022 libknlopt.a
[oracle@node1 lib]$ make -f ins_rdbms.mk uniaud_on ioracle
-rw-r--r-- 1 oracle oinstall 1771858 11月 26 14:03 2022 libknlopt.a
※RACの場合、全ノードでmakeが必要です(Doc ID 2371837.1)

4. DB起動
[oracle@node1 lib]$ srvctl start database -db orcl

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

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

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

SQL> --標準監査設定(前回の従来型監査検証の設定値)
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

※統合監査が有効の場合、audit_file_dest、audit_sys_operations、audit_trail初期化パラメータは無効です
　DBインスタンス停止中の監査ログ(OSファイル)は「/u01/app/oracle/admin/orcl/adump」ではなく、「/u01/app/oracle/audit/<インスタンス名>」配下に出力されます

■検証パターン
①必須監査
②DBA監査
③標準監査(標準データベース監査)
④ファイングレイン監査(FGA監査)
※従来型監査で検証した値ベース監査は事前に定義された機能ではなく、統合監査との動きを比較できないため検証は割愛

■検証
①必須監査
特権ユーザの必須監査対象の操作が監査されるか検証します
検証手順は従来型監査の検証と同じです

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

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

【検証結果】
・必須監査対象の操作のうち、下記は監査された
- ASMインスタンス起動/停止、接続の監査ログはOSファイルに出力された(ビューには出力されなかった)
- DBインスタンス起動/停止の監査ログはビューに出力された
・必須監査対象の操作のうち、下記は監査されなかった
- DBインスタンス接続の監査ログはOSファイル、ビューどちらにも出力されなかった(※1)

(※1)
(DBインスタンス起動/停止以外の)SYSDBA権限の操作は監査されないとのことでした(Doc ID 2024280.1)
全操作を監査する監査ポリシー作成後、SYSDBA権限を持つ特権ユーザ(特権アカウント)に監査ポリシーを適用して対応します

【作業ログ】

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_667_20221126152211413052143795.aud
Sat Nov 26 15:22:14 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_6003_20221126152518149265143795.aud
Sat Nov 26 15:25:18 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_9982_20221126153242132738143795.aud
Sat Nov 26 15:32:42 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 ~]# ls -ltr /u01/app/oracle/audit/orcl1
-rw-r----- 1 oracle asmadmin 1536 11月 26 15:37 2022 ora_audit_1138.bin
-rw-r----- 1 oracle asmadmin 1536 11月 26 15:37 2022 ora_audit_0138.bin
★中身は見れないがSYSDBA権限でDBインスタンス停止と同時刻の監査ログが出力された

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

#監査ログ確認(OSファイル)
[root@node1 ~]# ls -ltr /u01/app/oracle/audit/orcl1
-rw-r----- 1 oracle asmadmin 2560 11月 26 15:42 2022 ora_audit_00.bin
-rw-r----- 1 oracle asmadmin 10752 11月 26 15:42 2022 ora_audit_1355.bin
-rw-r----- 1 oracle asmadmin 1536 11月 26 15:42 2022 ora_audit_116.bin
★中身は見れないがSYSDBA権限でDBインスタンス起動と同時刻の監査ログが出力された

#監査ログ確認(ビュー)
SQL> select TO_CHAR(EVENT_TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as EVT_TS,AUDIT_TYPE,USERHOST,DBUSERNAME,ACTION_NAME,OBJECT_SCHEMA,OBJECT_NAME,SQL_TEXT from UNIFIED_AUDIT_TRAIL order by EVENT_TIMESTAMP desc;

EVT_TS AUDIT_TYPE USERHOST DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME SQL_TEXT
-------------------- -------------------- -------------------- --------------- --------------- --------------- --------------- --------------------------------------------------------------------------------
2022/11/26 15:42:21 Standard Not Available SYS STARTUP STARTUP
2022/11/26 15:42:21 Standard Not Available SYS STARTUP STARTUP
2022/11/26 15:38:11 Standard node2.oracle12c.jp SYS SHUTDOWN SHUTDOWN IMMEDIATE
2022/11/26 15:37:49 Standard node1.oracle12c.jp SYS SHUTDOWN SHUTDOWN IMMEDIATE
★「4. DBインスタンス停止」、「5. DBインスタンス起動」の監査ログが出力された

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

#監査ログ確認
★監査ログはOSファイル、ビューどちらにも出力されなかった
理由は上記「【検証結果】」で書いた通りです

【参考】全操作を監査する監査ポリシー作成後、SYS(SYSDBA権限)に監査ポリシー適用
1. 全操作を監査する監査ポリシー作成
SQL> CREATE AUDIT POLICY POL_ALL_ACTIONS
2 ACTIONS ALL
3 WHEN 'SYS_CONTEXT(''USERENV'', ''OS_USER'') = ''oracle'' AND (SYS_CONTEXT(''USERENV'', ''HOST'') = ''node1.oracle12c.jp'' OR SYS_CONTEXT(''USERENV'', ''HOST'') = ''node2.oracle12c.jp'')'
4 EVALUATE PER STATEMENT;

監査ポリシーが作成されました。

★WHEN句で監査ポリシーに対する監査条件を指定できます
　本検証では「OSユーザがoracle」で「ホスト名がnode1.oracle12c.jpかnode2.oracle12c.jp」の場合、全操作を監査するという条件を指定しています

SQL> select POLICY_NAME,AUDIT_CONDITION,AUDIT_OPTION,OBJECT_SCHEMA,OBJECT_NAME from audit_unified_policies where POLICY_NAME like 'POL%' order by POLICY_NAME,AUDIT_OPTION,OBJECT_SCHEMA,OBJECT_NAME;

POLICY_NAME AUDIT_CONDITION AUDIT_OPTION OBJECT_SCHEMA OBJECT_NAME
-------------------- ----------------------------------------------------------------- --------------- --------------- ---------------
POL_ALL_ACTIONS SYS_CONTEXT('USERENV', 'OS_USER') = 'oracle' AND (SYS_CONTEXT('US ALL NONE NONE
ERENV', 'HOST') = 'node1.oracle12c.jp' OR SYS_CONTEXT('USERENV',
'HOST') = 'node2.oracle12c.jp')

2. 全操作を監査する監査ポリシー適用
SQL> audit policy POL_ALL_ACTIONS by sys;

監査が成功しました。

SQL> select * from audit_unified_enabled_policies;

USER_NAME POLICY_NAME ENABLED_OPT SUCCESS FAILURE
--------------- -------------------- ------------------------ --------- ---------
SYS POL_ALL_ACTIONS BY YES YES

★全操作を監査する監査ポリシー適用後、SYS(SYSDBA権限)でDBインスタンス接続したら監査ログが出力された

SQL> select TO_CHAR(EVENT_TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as EVT_TS,AUDIT_TYPE,USERHOST,DBUSERNAME,ACTION_NAME,OBJECT_SCHEMA,OBJECT_NAME,SQL_TEXT from UNIFIED_AUDIT_TRAIL order by EVENT_TIMESTAMP desc;

②DBA監査
特権ユーザのDBA監査対象の操作が監査されるか検証します
検証手順は従来型監査の検証と同じです

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

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

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

【作業ログ】

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

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

#監査ログ確認
SQL> select TO_CHAR(EVENT_TIMESTAMP, 'YYYY/MM/DD HH24:MI:SS') as EVT_TS,AUDIT_TYPE,USERHOST,DBUSERNAME,ACTION_NAME,OBJECT_SCHEMA,OBJECT_NAME,SQL_TEXT from UNIFIED_AUDIT_TRAIL order by EVENT_TIMESTAMP desc;

EVT_TS AUDIT_TYPE USERHOST DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME SQL_TEXT
-------------------- -------------------- -------------------- --------------- --------------- --------------- -------------------- --------------------------------------------------------------------------------
2022/11/26 16:09:15 Standard node1.oracle12c.jp SYS SELECT SYS from$_subquery$_004 select count(*) from dba_users
★SYSDBA権限でデータディクショナリアクセスした監査ログが出力された

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

1行が更新されました。

EVT_TS AUDIT_TYPE USERHOST DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME SQL_TEXT
-------------------- -------------------- -------------------- --------------- --------------- --------------- --------------- --------------------------------------------------------------------------------
2022/11/26 16:10:43 Standard node1.oracle12c.jp SYS UPDATE SCOTT EMP update scott.emp set SAL = 800 where EMPNO = 7369
★SYSDBA権限でデータ更新した監査ログが出力された

③標準監査(標準データベース監査)
一般ユーザの標準監査対象の操作が監査されるか検証します
検証手順は従来型監査の検証と同じです

【検証手順】
1. 監査ポリシー作成
2. 監査ポリシー適用
3. ノード1からSCOTTでDBログイン(間違ったパスワード)
4. ノード2からSCOTTでDBログイン(間違ったパスワード)
5. SCOTTでテーブル作成
6. SCOTTでテーブルにデータ挿入

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

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

【作業ログ】

1. 監査ポリシー作成
SQL> --ログイン失敗検証用
SQL> CREATE AUDIT POLICY POL_LOGON_FAIL
2 ACTIONS LOGON
3 WHEN 'SYS_CONTEXT(''USERENV'', ''OS_USER'') = ''oracle'' AND (SYS_CONTEXT(''USERENV'', ''HOST'') = ''node1.oracle12c.jp'' OR SYS_CONTEXT(''USERENV'', ''HOST'') = ''node2.oracle12c.jp'')'
4 EVALUATE PER STATEMENT;

監査ポリシーが作成されました。

SQL> --テーブル作成検証用
SQL> CREATE AUDIT POLICY POL_CRE_TBL
2 ACTIONS CREATE TABLE
3 WHEN 'SYS_CONTEXT(''USERENV'', ''OS_USER'') = ''oracle'' AND (SYS_CONTEXT(''USERENV'', ''HOST'') = ''node1.oracle12c.jp'' OR SYS_CONTEXT(''USERENV'', ''HOST'') = ''node2.oracle12c.jp'')'
4 EVALUATE PER STATEMENT;

監査ポリシーが作成されました。

SQL> --データ操作検証用
SQL> CREATE AUDIT POLICY POL_OPERATION
2 ACTIONS INSERT on scott.emp
3 WHEN 'SYS_CONTEXT(''USERENV'', ''OS_USER'') = ''oracle'' AND (SYS_CONTEXT(''USERENV'', ''HOST'') = ''node1.oracle12c.jp'' OR SYS_CONTEXT(''USERENV'', ''HOST'') = ''node2.oracle12c.jp'')'
4 EVALUATE PER STATEMENT;

監査ポリシーが作成されました。

SQL> select POLICY_NAME,AUDIT_CONDITION,AUDIT_OPTION,OBJECT_SCHEMA,OBJECT_NAME from audit_unified_policies where POLICY_NAME like 'POL%' order by POLICY_NAME,AUDIT_OPTION,OBJECT_SCHEMA,OBJECT_NAME;

POL_CRE_TBL SYS_CONTEXT('USERENV', 'OS_USER') = 'oracle' AND (SYS_CONTEXT('US CREATE TABLE NONE NONE
ERENV', 'HOST') = 'node1.oracle12c.jp' OR SYS_CONTEXT('USERENV',
'HOST') = 'node2.oracle12c.jp')

POL_LOGON_FAIL SYS_CONTEXT('USERENV', 'OS_USER') = 'oracle' AND (SYS_CONTEXT('US LOGON NONE NONE
ERENV', 'HOST') = 'node1.oracle12c.jp' OR SYS_CONTEXT('USERENV',
'HOST') = 'node2.oracle12c.jp')

POL_OPERATION SYS_CONTEXT('USERENV', 'OS_USER') = 'oracle' AND (SYS_CONTEXT('US INSERT SCOTT EMP
ERENV', 'HOST') = 'node1.oracle12c.jp' OR SYS_CONTEXT('USERENV',
'HOST') = 'node2.oracle12c.jp')

2. 監査ポリシー適用
SQL> --ログイン失敗検証用
SQL> audit policy POL_LOGON_FAIL by scott whenever not successful;

監査が成功しました。

SQL> --テーブル作成検証用
SQL> audit policy POL_CRE_TBL by scott;

監査が成功しました。

SQL> --データ操作検証用
SQL> audit policy POL_OPERATION;

監査が成功しました。

SQL> select * from audit_unified_enabled_policies;

USER_NAME POLICY_NAME ENABLED_OPT SUCCESS FAILURE
--------------- -------------------- ------------------------ --------- ---------
SYS POL_ALL_ACTIONS BY YES YES
SCOTT POL_LOGON_FAIL BY NO YES
SCOTT POL_CRE_TBL BY YES YES
ALL USERS POL_OPERATION BY YES YES

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

SQL*Plus: Release 12.1.0.2.0 Production on 土 11月 26 16:17:57 2022

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

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

SQL*Plus: Release 12.1.0.2.0 Production on 土 11月 26 16:20:39 2022

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

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

表が作成されました。

EVT_TS AUDIT_TYPE USERHOST DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME SQL_TEXT
-------------------- -------------------- -------------------- --------------- --------------- --------------- --------------- --------------------------------------------------------------------------------
2022/11/26 16:23:14 Standard node1.oracle12c.jp SCOTT CREATE TABLE SCOTT TEST_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行が作成されました。

EVT_TS AUDIT_TYPE USERHOST DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME SQL_TEXT
-------------------- -------------------- -------------------- --------------- --------------- --------------- --------------- --------------------------------------------------------------------------------
2022/11/26 16:24:36 Standard node1.oracle12c.jp SCOTT INSERT SCOTT EMP insert into emp(EMPNO, ENAME, JOB, MGR, HIREDATE, SAL, COMM, DEPTNO) values(99
★SCOTTがINSERT権限を使用した監査ログが出力された

④ファイングレイン監査(FGA監査)
ユーザのファイングレイン監査対象の操作が監査されるか検証します
検証手順は従来型監査の検証と同じです

【検証手順】
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

EVT_TS AUDIT_TYPE USERHOST DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME SQL_TEXT
-------------------- -------------------- -------------------- --------------- --------------- --------------- --------------- --------------------------------------------------------------------------------
2022/11/26 16:32:37 FineGrainedAudit node1.oracle12c.jp SCOTT SELECT SCOTT EMP select empno, ename, sal, deptno from emp
★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

EVT_TS AUDIT_TYPE USERHOST DBUSERNAME ACTION_NAME OBJECT_SCHEMA OBJECT_NAME SQL_TEXT
-------------------- -------------------- -------------------- --------------- --------------- --------------- --------------- --------------------------------------------------------------------------------
2022/11/26 16:33:42 FineGrainedAudit node1.oracle12c.jp SCOTT SELECT SCOTT EMP select empno, ename, sal, deptno from emp where deptno = 10
★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していないため、監査ログが出力されない

■参考資料
https://www.oracle.com/webfolder/technetwork/jp/ondemand/ddd2013/F-2.pdf
CREATE AUDIT POLICY (統合監査)
AUDIT (統合監査)
SYS_CONTEXT

■おわりに
ざっくり整理するとこんな感じでしょうか

従来型監査は監査によって監査ログの出力先が違っていましたが、統合監査は1つのビューで全監査ログを確認できるため、便利だと思います。
インスタンス起動/停止以外のSYSDBA権限の操作が監査されないのは焦りましたが…