統合監査の使用方法について

2023年5月12日 Oracle Database 管理

1 はじめに
2 統合監査とは
3 統合監査の検証
4 まとめ

はじめに

こんにちは。
2019年に新卒で入社した、技術チームの「たくみ」です。

今回はOracleDatabaseの監査についてご紹介させて頂きます。

そもそも監査とは誰が、いつ、どのような処理を実施したか等を記録し、後から追えるようにするための記録です。
これらの情報を記録しておくことで、後から不正なアクセスや処理が実施されていないかを確認することができます。

本記事ではこの監査のひとつである統合監査について、実機での検証を交えてご紹介させて頂きます。それでははじめていきましょう！

統合監査とは

まずはじめに統合監査について簡単にご紹介します。

統合監査とは12cより使用できるようになった監査です。
それまでは個別で管理されていた様々な種類の監査を文字通り1つに統合し、管理がより容易になっています。
取得可能な監査の内容が変わる訳ではありません。

従来のDBA監査(初期化パラメータによる設定)や標準監査(AUDITコマンドによる設定)等を統合監査(ポリシーによる設定)という1つの手法で設定出来るようになったものとなります。

統合監査の主な特徴を以下にまとめます。

監査データはデフォルトで「SYSAUX」表領域の　「AUDSYS」スキーマの読取り専用の表に格納されます。
すべての監査レコードは、同一の形式で統合監査証跡に書き込まれ「UNIFIED_AUDIT_TRAIL」ビューから参照できます。そのため参照が容易になりました。
また1つの場所に1つの形式で書き込まれるため、管理やセキュリティが改善されました。
従来の監査は、AUDIT_TRAIL（監査の出力形式を指定）やAUDIT_FILE_DEST（監査の出力先を指定）などの初期化パラメータの値に依存していましたが、統合監査では依存しません。
監査のパフォーマンスが大幅に向上しました。
データベースへのログインやSQLの操作だけではなく、Oracle Data PumpやOracle Recovery Managerなどの操作も監査できます。

また監査管理の職務分離も可能とするため、「AUDIT_ADMIN」と「AUDIT_VIEWER」ロールが存在します。
「AUDIT_ADMIN」を付与されたユーザーは監査対象の定義や監査レコードの参照等の管理業務が可能となり、「AUDIT_VIEWER」を付与されたユーザーは監査レコードの参照のみが可能となります。

統合監査の検証

それでは実機で検証していきましょう！
今回は統合監査の有効化から実際に監査レコードが取得されるまでを検証してみます。
なお、本検証環境は下記を用いております。

OS	Red Hat Enterprise Linux
データベース	Oracle Database 19c
DBインストールユーザー	oracle

統合監査の有効化

統合監査の有効化と書いていますが、12cよりデフォルトで統合監査は使用することができます。
デフォルトでは統合監査以外にも従来の監査を使用することができます。
これを混合モードと言います。

この混合モードから完全な統合監査モード（統合監査のみ使用可能）に変更することを
統合監査の有効化と表現しています。

今回は従来の監査は使用しませんので、統合監査を有効化してしまいましょう！

まずDBサーバが混合モードか完全な統合監査モードかはV$OPTIONで確認できます。

SQL> SELECT PARAMETER,VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

PARAMETER            VALUE
-------------------- --------
Unified Auditing     FALSE

パラメータの「Unified Auditing」が「FALSE」の場合は混合モードになります。
これが「TRUE」となれば完全な統合監査モードになります。

それではやっていきましょう！
※本検証で使用しているOSはLinuxサーバになります。Windowsサーバでは少し手順が違いますので、ご注意ください。

①対象のデータベースに接続し、下記コマンドでデータベースを停止します。

SQL> SHUTDOWN IMMEDIATE

<実行例>

SQL> SHUTDOWN IMMEDIATE
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL>

②SQLの操作を終了し、今度はOSコマンドでリスナーを停止します。
※Oracle RACおよびOracle Grid Infrastructureリスナーでは、リスナーを停止する必要はありません。

$ lsnrctl stop <リスナー名>

<実行例>

[oracle@ORA19-DG ~]$ lsnrctl stop listener

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 26-1月 -2023 16:45:26
Copyright (c) 1991, 2020, Oracle. All rights reserved.
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ORA19-DG)(PORT=1521)))に接続中
コマンドは正常に終了しました。
[oracle@ORA19-DG ~]$

③<ORACLE_HOME>/rdbms/libにカレントディレクトリを移動します。

$ cd $ORACLE_HOME/rdbms/lib

④oracleユーザーで下記コマンドを実行して、完全な統合監査モードに移行します。

$ make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME

<実行例>

[oracle@ORA19-DG lib]$ make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME
/usr/bin/ar d /apps/oracle/product/19.3.0/dbhome_1/rdbms/lib/libknlopt.a kzanang.o
/usr/bin/ar cr /apps/oracle/product/19.3.0/dbhome_1/rdbms/lib/libknlopt.a /apps/oracle/product/19.3.0/dbhome_1/rdbms/lib/kzaiang.o
chmod 755 /apps/oracle/product/19.3.0/dbhome_1/bin
・
・
＜中略＞
・
・
    if [ -f "$getcrshome" ]; then \
        crshome="`$getcrshome`"; \
        if [ -n "$crshome" ]; then \
            if [ $crshome != /apps/oracle/product/19.3.0/dbhome_1 ]; then \
                oracle="/apps/oracle/product/19.3.0/dbhome_1/bin/oracle"; \
                $crshome/bin/setasmgidwrap oracle_binary_path=$oracle; \
            fi \
        fi \
    fi \
fi\
);
[oracle@ORA19-DG lib]$

⑤リスナーを起動します。

$ lsnrctl start <リスナー名>

<実行例>

[oracle@ORA19-DG lib]$ lsnrctl start listener

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 26-1月 -2023 17:01:33
Copyright (c) 1991, 2020, Oracle.  All rights reserved.
/apps/oracle/product/19.3.0/dbhome_1/bin/tnslsnrを起動しています。お待ちください...
・
・
＜中略＞
・
・
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ORA19-DG)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
リスナーはサービスをサポートしていません。
コマンドは正常に終了しました。
[oracle@ORA19-DG lib]$

⑥データベースに接続し、データベースを起動します。

SQL> STARTUP

<実行例>

SQL> STARTUP
ORACLEインスタンスが起動しました。

Total System Global Area 1241513488 bytes
Fixed Size                  8896016 bytes
Variable Size             436207616 bytes
Database Buffers          788529152 bytes
Redo Buffers                7880704 bytes
データベースがマウントされました。
データベースがオープンされました。
SQL>

以上が有効化手順になります。

改めてV$OPTIONを確認してみると・・・

SQL> SELECT PARAMETER,VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

PARAMETER            VALUE
-------------------- --------
Unified Auditing     TRUE

「Unified Auditing」が「TRUE」になっていますね！
無事に完全な統合監査モードに移行することができました！

監査ポリシーの作成

先述しましたが、監査とは誰が、いつ、どのような処理を実施したかを記録するためのものです。
この「どんなこと」をしたら監査を記録するかをデータベースに定義する必要があります。
それが監査ポリシーになります。

この監査ポリシーですが「データの更新（update操作）」の監査を記録するなどの設定以外にも、
「select any table」権限を使用したら監査を記録するというように様々の条件のポリシーを作成できます。
詳細はマニュアルをご参照ください。
2023年3月時点での最新マニュアルは下記となります。
Oracle Database 21c／セキュリティ・ガイド／26 監査ポリシーの構成

今回は分かりやすくする為、SQL文(DELETE)に対する監査を検証してみましょう！

準備として検証に用いるユーザーとそのユーザーが所有するテーブルを作成しています。

検証用ユーザー：audit_test
検証用テーブル：audit_test_table

統合監査を使用する為に、統合監査ポリシーを作成します。
作成するには「create audit policy」文を使用します。
SQL文に対する監査のポリシーを作成する場合のコマンドは下記です。

create audit policy <統合監査ポリシー名> actions <監査対象操作> on <監査対象オブジェクト>;

今回は「audit_test_table」テーブルに対して「delete」操作を実施した際に監査されるポリシーを作成します。名前は「audit_test_policy」にしています。

SQL> create audit policy audit_test_policy actions delete on audit_test.audit_test_table;

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

SQL>

作成された監査ポリシーは「audit_unified_policies」で確認することができます。

SQL> select policy_name,audit_option,audit_option_type,object_schema,object_name,object_type
  2  from audit_unified_policies where policy_name='AUDIT_TEST_POLICY';

POLICY_NAME           AUDIT_OPTION         AUDIT_OPTION_TYPE  OBJECT_SCHEMA        OBJECT_NAME          OBJECT_TYPE
-------------------- -------------------- ------------------ -------------------- -------------------- -----------------------
AUDIT_TEST_POLICY     DELETE               OBJECT ACTION      AUDIT_TEST           AUDIT_TEST_TABLE     TABLE

SQL>

無事に作成できていることを確認できました！
「audit_option」に対象操作である「DELETE」、
「object_name」に対象オブジェクトである「AUDIT_TEST_TABLE」が表示されていますね。

監査ポリシーのユーザー付与

この作成した統合監査ポリシーですが、このままでは使用できません。
「誰」がこのポリシーで定義された操作を実施したら監査に記録するかを定義する必要があります。
これは「audit policy」文を使用して定義します。

audit policy <統合監査ポリシー名> by <監査対象ユーザー名1>,<監査対象ユーザー名2>.....[whenever [not] successful]

「by」句で監査ポリシーを付与するユーザーを指定します。
指定されたユーザーが、監査ポリシーで指定された操作を実施すると監査が記録されます。
なお、監査対象からユーザーを除外する場合は「by」句の代わりに「except」句を使用します。

「whenever [not] successful」句を指定した場合、指定しない場合、それぞれ下記のような動作になります。

whenever successful：ユーザーの操作が成功した場合のみ監査します。
whenever not successful：ユーザーの操作が失敗した場合のみ監査します。
省略：ユーザーの操作が成功した場合と失敗した場合を監査します。
※例えばSQLの構文エラーがあった場合や、権限が不足した状態で操作をした場合に監査が記録されます。

この句は省略する(指定しない)ことも可能で、省略した場合はユーザーの操作が成功、失敗に関わらず監査されることになります。
今回の検証では下記のようにコマンドを実行しています。

SQL> audit policy audit_test_policy by audit_test whenever successful;

監査が成功しました。

SQL>

このコマンドで検証用ユーザー「audit_test」が「audit_test_policy」で定義した操作（audit_test_tableに対するdelete操作）を実行し、かつ成功した場合に監査されるようにしています。

監査の記録の確認

それでは早速、delete操作を実行してみましょう！

まずは「audit_test」ユーザーでデータベースにログインし、「audit_test_table」にデータを挿入します。

SQL> conn audit_test/<パスワード>

SQL> insert into audit_test_table (empno,empname,gender_f) values (10,'tanaka',1);

1行が作成されました。

SQL> commit;

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

SQL>select * from audit_test_table;

EMPNO       EMPNAME  GENDER_F
---------- -------- ----------
10          tanaka   1

SQL>

無事に挿入ができました。
それではデータを削除します。

SQL> delete from audit_test_table;

1行が削除されました。

SQL> commit;

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

SQL> select * from audit_test_table;

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

SQL>

削除も無事にできました。
それでは「UNIFIED_AUDIT_TRAIL」を確認してみましょう！

SQL> select event_timestamp,dbusername,action_name,object_schema,object_name 
  2  from unified_audit_trail where dbusername='AUDIT_TEST' order by 1;

EVENT_TIMESTAMP           DBUSERNAME           ACTION_NAME          OBJECT_SCHEMA   OBJECT_NAME
------------------------- -------------------- -------------------- --------------- -----------------
23-03-20 13:19:14.678921  AUDIT_TEST           DELETE               AUDIT_TEST      AUDIT_TEST_TABLE

SQL>

上記の赤文字の箇所をご覧ください！
「dbusername」列に操作を実施したユーザー、
「action_name」列に実施された操作、
「object_name」列に操作対象オブジェクトが表示されています。
「audit_test」ユーザーが「audit_test_table」に対して、
「delete」操作を実施したことが記録されていますね！！
また、ポリシーを設定していない「insert」操作は監査が記録されていないこともわかりますね。