従来の監査から飛躍的に改善され使いやすくなったUnified Audit：ユーザー目線でチェック！ Oracle Database 12cの知りたいところ（4）（4/4 ページ）
DB運用で避けては通れない、ログ監査。12cではどれくらいDBAが楽になる？ 監査とセキュリティの問題を解消する目玉機能がUnified Auditだ。
Unified AuditingとSQL*Loader ダイレクトパスロード
SQL*Loaderのダイレクトパスロードの実行についても、従来の監査機能では実行状況が明確に記録されませんでした。Unified Auditingでは、以下のようにdirect_loadをコンポーネントに指定したポリシーを作成し有効とすることでSQL*Loaderのダイレクトパスロードに関して監査ログが記録され、実行状況が確認できるようになりました。
SQL*Loader向けの監査設定用のコマンド
SQL> CREATE AUDIT POLICY sqlldr_dp ACTIONS COMPONENT=direct_load load; SQL> AUDIT POLICY all_pump;
実行したSQL*Loaderコマンド
sqlldr USERID=scott/tiger@pdb1 CONTROL=load1.ctl DIRECT=TRUE
SQL*Loader制御ファイル（load1.ctl）
LOAD DATA INFILE 'data.dat' INSERT INTO TABLE emp FIELDS TERMINATED BY "|" (EMPNO,ENAME,JOB,MGR,HIREDATE DATE 'YYYYMMDD',SAL,COMM,DEPTNO)
SQL*Loaderデータファイル（data.dat）
7369|SMITH|CLERK|7902|10-12-17|800||20 7499|ALLEN|SALESMAN|7698|11-02-20|1600|300|30
SQL*Loaderの監査証跡を確認した例
SELECT event_timestamp, audit_type, dbusername, action_name
, object_schema, object_name, sql_text, direct_path_num_COLumns_loade
FROM UNIFIED_AUDIT_TRAIL WHERE audit_type='Direct path API';
event_timestamp audit_type DBUSERNAME ACTION_NAME
------------------------ -------------------- ------------ ------------
13-07-16 16:36:16.961928 Direct path API SCOTT LOAD
OBJECT_SCH OBJEC SQL_TEXT
---------- ----- ----------------------------------------
SCOTT EMP INSERT /*+ SYS_DL_CURSOR */ INTO "SCOTT"
."EMP" ("EMPNO","ENAME","JOB","MGR","HIR
EDATE","SAL","COMM","DEPTNO") VALUES (NU
LL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)
DIRECT_PATH_NUM_COLUMNS_LOADED
------------------------------
8
こちらもログから実行した操作が明確に確認できるので、SQL*Loaderによる操作履歴を確認する用途において非常に便利です。
Unified Auditingログの保存と削除
Unified Auditingでも監査ログのデータ量は増加し続けるため、従来の監査機能と同様に定期的な監査ログのメンテナンスが必要です。
ただし、従来の監査機能では監査ログの格納先が複数存在し、それぞれメンテナンスが必要でした。Unified Auditingでは全ての監査ログがUNIFIED_AUDIT_TRAILビューに格納されるため、このビューの監査ログのみをメンテナンスすればよくなります。
UNIFIED_AUDIT_TRAILビューの情報を保管するための簡単な方法は、監査ログを一時的に格納する表を用意しておき、その表にinsert文によってUNIFIED_AUDIT_TRAILビューから監査ログの行をコピーしておき、expdpでエクスポートすることです。
また、UNIFIED_AUDIT_TRAILビューの監査ログは、従来のバージョンでも提供されているDBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILプロシージャにより削除できます。例えば以下を実行すると、Unified Auditingの監査ログ全てが削除可能でした。
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILによるログの削除
exec DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL( audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, use_last_arch_timestamp =>FALSE);
上記DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILプロシージャを実行すると、UNIFIED_AUDIT_TRAILビューの情報が削除され、$ORACLE_BASE/audit/$ORACLE_SID 以下のログファイル（バイナリ）も削除されました。
Unified Auditingログの書き込み処理の改善
従来の監査ログの書き込み方式は同期書き込みであったため、パフォーマンスへの影響が懸念されました。
同期書き込みでは、ディスクへの監査ログの保存が完了するまで、次の処理が待たされます。Unified Auditingでは、この問題への対策としてSGAキューによる非同期書き込みが実装されました。この非同期書き込みでは、監査ログはまずメモリ上のSGAキューに出力され、後で非同期に保存される動作となるため、ディスクへの監査ログの保存完了を待たずに次の処理を行うことが可能となります。このため、待ちが発生しないことでレスポンスは高まり、データベース全体のパフォーマンスが同期書き込みに比べ向上します。
まとめ（お伝えしたいこと）
データベースに関するセキュリティ維持の重要性は最近の10年間において特に認識されてきており、監査ログの記録に対するニーズは今日において益々高まってきていると思います。しかしながら、データベース内の全てのアクションに関して全ての監査ログを記録することは、大量に出力されるログによるパフォーマンスへの影響や、disk容量の圧迫、煩雑な監査設定などの問題があり、実現は困難でした。そのため、多くのシステムでは全ての監査ログを記録するのではなく、重要な情報は何なのか、監査ログを記録し保管しなければならないアクションなのは何であるのかを見極め、慎重に設計し、必要最小限の監査ログの取得設定が実施されてきたものと認識しています。
しかし、ストレージ技術はSSDの一般化など日進月歩の技術革新を遂げており、大量のログであっても記録するためのリソースは整いつつあります。また、今回お伝えしたように、データベースの監査ログ取得に関して設定を容易とし、監査情報の一元化が図られ、ユーティリティのログも記録できるように改善されました。また、SGAキューによる非同期書き込みが実装され、瞬間的なI/O負荷増大についても軽減が図られました。これらの機能改善が図られたことにより、より多くのシステムですべて操作の監査ログを取得できるようになっています。Oracle Database 12c R1ご利用の際は、新しい監査機能を使用し、監査ログを取得することを改めて検討する機会を設けていただければと存じます。
Copyright © ITmedia, Inc. All Rights Reserved.