Audit Trailについての検証　その３

Oracleデータベースの監査機能である、Audit Trail に関する性能検証、機能検証をLevel1-4でまとめた人気コンテンツのeBook版。標準監査機能の基本から応用まで全8回で解説。

Level 1）Audit sessionなどによる文監査
Level 2）オブジェクト監査
Level 3）ファイングレイン監査 Basic
Level 4）ファイングレイン監査 Advanced

*eBook版のダウンロードをご希望の方は、画像をクリック

＜Audit Trailについての検証　～その３～＞
ペンネーム　ベロ

先週のお盆休みを皆さんいかがお過ごしでしたか？
社会復帰できない方もレッツAUDIT！ということで今週はオブジェクト監査に
ついて検証していきます。

オブジェクト監査とは、特定オブジェクトに対してSELECT、INSERT、UPDATEと
いったアクションを追跡できる機能を提供しています。構文は以下の通り。

AUDIT アクション名 ON スキーマ名.オブジェクト名 [ BY SESSION|ACCESS ]

今回はORABMユーザの持つ6つのテーブル全てにSELECT、INSERT、UPDATE、DELETE
のアクションを追跡するように設定してみた。ちなみにBY SESSION|ACCESSは、
AUD$表に書き込む単位をセッション単位かACCESS単位にするかという意味。
BY SESSIONであれば、1セッション内で何度オブジェクトにアクセスしても1レコ
ードしか作成しない。一方BY ACCESSではオブジェクトのアクセス毎にレコード
が作成される。

と言うわけで、設定したところでまず、オブジェクト監査で最も気になるレスポ
ンスへの影響を確認することにする。
そこで、レスポンスを前回のTPCベンチマークを利用して見てみよう。
（前回同様50セッション*5回の平均値）

□■ レスポンスへの影響 □■□■□■□■□■□■□■□■□■□■□■□■□■

1. AUDIT無し            ・・・     TPS : 131
2. AUDIT BY SESSION     ・・・     TPS : 108
3. AUDIT BY ACCESS      ・・・     TPS : 93

□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■

SESSION毎に監査を行った場合、NOAUDITからのレスポンスダウン率が17.6%、
ACTION毎に監査を行った場合は、NOAUDITからのレスポンスダウン率が29%と
予想以上に大きなレスポンスダウンとなった。

オブジェクト監査は大きなレスポンスダウンをもたらすことから、ターゲット
となるオブジェクトを見極めて監査を実施する必要がありそうだ。

では、オブジェクト監査を実施する上での考慮すべき点を探っていこう。

まず、オブジェクト監査でどのような情報が取得できるのだろうか？

select os_username          os_usrnm
      ,terminal
      ,owner||'.'||obj_name obj
      ,ses_actions
      ,count(*)             cnt
from   dba_audit_object
group by owner||'.'||obj_name, ses_actions
order by obj,cnt

OS_USRNM TERMINAL OBJ                      SES_ACTIONS                CNT
-------- -------- ------------------------ --------------------- --------
ORACLE    pts/0   ORABM.CUSTOMER           ---------SS-----             1 <-(1)
ORACLE    pts/0   ORABM.CUSTOMER           ---------S------             4
ORACLE    pts/0   ORABM.DISTRICT           ---------SS-----             5
ORACLE    pts/0   ORABM.HISTORY            ------F---------             1 <-(2)
ORACLE    pts/0   ORABM.NEW_ORDER          ---S-----S------             1
ORACLE    pts/0   ORABM.ORDER_LINE         ---------S------             5
ORACLE    pts/0   ORABM.WAREHOUSE          ---------SS-----             2
ORACLE    pts/0   ORABM.WAREHOUSE          ---------S------             3

SES_ACTIONS列にはそのセッションが実行したアクティビティの成功/失敗と
いった情報が蓄積されていく。SES_ACTIONS列の’-‘はプレイスホルダと呼ばれ
以下のアクションに対応している。

1. ALTER
2. AUDIT
3. COMMENT
4. DELETE
5. GRANT
6. INDEX
7. INSERT
8. LOCK
9. RENAME
10. SELECT
11. UPDATE
12. REFERENCE
13. EXECUTE
14. 将来のために予約
15. 同上
16. 同上

つまり、(1)では、左から10、11番目に’S’のフラグが立っている。よって
CUSTOMER表へのSELECTおよびUPDATEが成功していることを意味している。
また、(2)では左から7番目に’F’のフラグが立っていることから、HISTORY表
へのINSERTが失敗したことを示している。
（ちなみに同一セッション内で成功/失敗両方のアクティビティがある時は、
‘B’で表示される）

しかしながら（と言うかやっぱり）実行したSQLの内容の詳細を知ることはできない。

オブジェクト監査も（AUDIT自体）後追いの監査であることから、監査を実施する場合
は、アプリケーション、オブジェクトの性格を把握しおくことが大事。

例えば、参照、更新の激しいホットオブジェクトに監査を実施すれば監査レコードを
大量に生成することになり、レスポンスダウンは免れない。

一方、参照系のオブジェクトに対してDELETEやUPDATEによるデータ破壊を監視すること
はそれほどレスポンスダウンは発生しないと考えられる。

つまり、監査を実施する場合は、オブジェクトの正確を見極め、最小限の監査レコード
で最大限の監査ができるように設定していくことが大事というわけ。

来週は、この最小限の監査レコードで最大限の監査を実現すべくファイングレイン監査
なるものを見ていきたいと思います。

夏だというのに肌寒い茅ヶ崎より。

Audit Trailについての検証 その３