Oracle Cloud Infrastructure（以下「OCI」）のAutonomous Database（以下「ADB」）を構築すると、Application Express（以下「APEX」）も自動構成されるため、構築開始からわずか5分でOracle Databaseのローコード開発ツールであるAPEXが利用できます。
Autonomous Database（日本語だと「自立型データベース」）というだけあって、構築だけでなく、運用管理までクラウド・ベンダー（オラクル社）に任せられるため、ユーザーは基盤のことを気にせず、アプリケーションに集中することができます。
今回は、ADBに附属するAPEXを利用した際に、データベース監査がどのように取得できるか試してみたので、その結果を記載してみたいと思います。
1.マニュアル確認
ADBのマニュアルの「Autonomous Databaseの監査について」を確認すると、以下の記載があります。
| Autonomous Databaseは、監査データを保護し、その監査証跡をUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューに書き込みます。 |
| 各Autonomous Databaseインスタンスが自動削除ジョブを1日に1回実行して、14日以上経過したすべての監査レコードを削除します。 14日より長い監査データ保存期間が必要な場合は、Oracle Data Safeを使用して監査データを保存します。 |
|
デフォルトでは、Autonomous Databaseは監査ポリシーを適用して次のデータベース・アクティビティを監査します。
・Oracle Cloud Operationsによるすべてのアクティビティ また、次のいずれかを使用して追加監査ポリシーを適用できます。 |
デフォルト設定では限られた操作しかログが取得されないようです。
必要に応じて、監査ポリシーを構成します。
2.初期状態でのAPEX操作＆監査ログ確認
まずは、なにも考えずにAPEXの操作をしてから、監査ログ（UNIFIED_AUDIT_TRAIL）を確認してみます。
SQL> select * from UNIFIED_AUDIT_TRAIL where to_char(EVENT_TIMESTAMP,'YYYYMMDD')='20220502';
レコードが選択されませんでした。
予想どおり、この状態ではなにもログが取得されていません。
3.監査ポリシーの構成
ADMINユーザーで、APEXで利用しているemp表に対するすべての操作の監査ログを取得するよう、以下の監査ポリシーを作成してみます。
※詳細はデータベースのマニュアルの「監査ポリシーの構成」を参照ください。
SQL> CREATE AUDIT POLICY emp_all ACTIONS all ON ayamakkk.emp;
監査ポリシーが作成されました。
作成した監査ポリシーを有効にします。（必要であれば、この構文で対象ユーザーなども指定できます）
SQL> AUDIT POLICY emp_all;
監査が成功しました。
注：統合監査ポリシーの有効化に関するマニュアルには以下の記載があります。
| 監査ユーザー(またはポリシーに関連付けられたロールを付与されたユーザー)がデータベース・インスタンスにログインするまで、ポリシーは有効となりません。言い方を変えると、監査ユーザーのログイン中にポリシーを作成して有効化すると、ポリシーは監査データを収集できません。監査を開始する前に、ユーザーはログアウトしてから再ログインする必要があります。 |
監査ポリシーは、データベース・セッションをリセットしないと有効にならないため、監査ログを確認するセッションや、監査ログを出力するセッションは再ログインが必要となります。
3.監査ポリシー構成後、APEX操作＆監査ログ確認
監査ポリシー構成後、APEXの操作をしてから、監査ログ（UNIFIED_AUDIT_TRAIL）を確認してみます。
select * from UNIFIED_AUDIT_TRAIL where to_char(EVENT_TIMESTAMP,'YYYYMMDD')='20220502';
今度はレコードが存在するため、確認してみたいデータに絞って検索してみます。
SQL> select
2 EVENT_TIMESTAMP,
3 DBUSERNAME,
4 DBPROXY_USERNAME,
5 CLIENT_PROGRAM_NAME,
6 ACTION_NAME,
7 OBJECT_SCHEMA,
8 OBJECT_NAME,
9 SQL_TEXT,
10 CLIENT_IDENTIFIER,
11 CURRENT_USER
12 from
13 UNIFIED_AUDIT_TRAIL
14 where
15 to_char(EVENT_TIMESTAMP,'YYYYMMDD') = '20220502'
16 order by
17 EVENT_TIMESTAMP;
EVENT_TIMESTAMP
---------------------------------------------------------------------------
DBUSERNAME DBPROXY_USERNAME CLIENT_PROGRAM_NAME
-------------------- -------------------- --------------------
ACTION_NAME OBJECT_SCH OBJECT_NAM
-------------------- ---------- ----------
SQL_TEXT
--------------------------------------------------------------------------------
CLIENT_IDENTIFIER CURRENT_USER
------------------------------ --------------------
22-05-02 09:45:06.279170
ADMIN sqlplus.exe
CREATE AUDIT POLICY SYS EMP_ALL
CREATE AUDIT POLICY emp_all ACTIONS all ON ayamakkk.emp
ADMIN
22-05-02 09:45:26.954526
ADMIN sqlplus.exe
AUDIT SYS EMP_ALL
AUDIT POLICY emp_all
ADMIN
22-05-02 09:46:54.464950
ORDS_PLSQL_GATEWAY ORDS_PUBLIC_USER ORDS_ADBS_Managed
INSERT AYAMAKKK EMP
insert into "EMP"
("EMPNO","ENAME","EMAIL_ADDRESS","OFFICE_ADDRESS","OFFICE_FL
APEXKKK:111876560749511 AYAMAKKK
22-05-02 09:46:55.060495
ORDS_PLSQL_GATEWAY ORDS_PUBLIC_USER ORDS_ADBS_Managed
SELECT AYAMAKKK EMP
select * from(select a.*,row_number() over (order by null) apx$rownum from(selec
APEXKKK:111876560749511 AYAMAKKK
4行が選択されました。
最初の2つのレコードは監査ポリシーを構成した際のログです。
sqlplusからADMINユーザーで操作しているのがわかります。
DBUSERNAME DBPROXY_USERNAME CLIENT_PROGRAM_NAME
-------------------- -------------------- --------------------
ADMIN sqlplus.exe
その次の2つのレコードがAPEXからの操作ログになります。
以下の3点がAPEXからの操作の特徴ですね
DBUSERNAME DBPROXY_USERNAME CLIENT_PROGRAM_NAME
-------------------- -------------------- --------------------
ORDS_PLSQL_GATEWAY ORDS_PUBLIC_USER ORDS_ADBS_Managed
CLIENT_IDENTIFIERにAPEXユーザー名とセッションIDが入っています。
CURRENT_USERがデータベース・ユーザーになりますね
CLIENT_IDENTIFIER CURRENT_USER
------------------------------ --------------------
APEXKKK:111876560749511 AYAMAKKK
ADBの場合、基本的な監査機能は設定済となるため、アプリケーションで必要な監査ポリシーを追加することで、すぐに監査機能が利用できることが確認できました。