Audit Trailについての検証 その６
Oracleデータベースの監査機能である、Audit Trail に関する性能検証、機能検証をLevel1-4でまとめた人気コンテンツのeBook版。標準監査機能の基本から応用まで全8回で解説。
Level 1）Audit sessionなどによる文監査
Level 2）オブジェクト監査
Level 3）ファイングレイン監査 Basic
Level 4）ファイングレイン監査 Advanced
*eBook版のダウンロードをご希望の方は、画像をクリック
＜Audit Trailについての検証 ～その６～＞
ペンネーム ベロ
それでは、今回は今時？のWEBシステムについて考えてみたいと思います。
従来のクライアント/サーバでは、各クライアントからデータベースサーバに
セッションを張っていた。しかし、WEBシステムでは、このセッション確立を
APサーバが行っている。しかも、コネクションプーリングを行っていたりして
いるのが当たり前になっている。
このような環境で、データベースのアクティビティを監査することは可能なの
であろうか？
ということで、DBサーバ – APサーバ – クライアントといった3階層の場合の
監査を見ていこうと思います。
まず、3階層の環境は以下の通り：
┌─ DBサーバ ─┐ ┌─ APサーバ ─┐ ┌─ クライアント ─┐ │ │ │ │ │ │ │ │←────┤ │←────│ Windows2000 │ │ Oracle9.2.0 │ │ TOMCAT │ │ ＋ │ │ │ │ ＋ │ │ IE6.0 │ │ ├────→│ JDBC │────→│ │ │ │ │ │ │ │ └───────┘ └───────┘ └─────────┘
APサーバ上に簡単な検証用プログラムを作成する。
検証用プログラムの概要は以下の通り。
(1) コネクションプールを使用せず、CONNECT後、単純なSELECT文を発行後、
DISCONNECTする。この処理を100回行う。
(2) コネクションプールを使用して、(1)同様の処理を100回行う。
(1)、(2)の場合で実際にどのような監査データが取得できるか見てみよう。
まず、(1)を実行。
監査データをDBA_AUDIT_SESSIONから確認する。
select os_username
,username
,terminal
,to_char(timestamp,'hh24:mi:ss') timestamp
,action_name
,to_char(logoff_time,'hh24:mi:ss') logoff_time
,returncode
from dba_audit_session ;
OS_USERNAM USERNAME TERMINAL TIMESTAMP ACTION_NAM LOGOFF_TIME RETURNCODE ---------- -------- -------- --------- ---------- ----------- ---------- SYSTEM ORABM unknown 15:44:43 LOGOFF 15:44:43 0 SYSTEM ORABM unknown 15:44:44 LOGOFF 15:44:44 0 SYSTEM ORABM unknown 15:44:44 LOGOFF 15:44:44 0 SYSTEM ORABM unknown 15:44:44 LOGOFF 15:44:45 0 SYSTEM ORABM unknown 15:44:45 LOGOFF 15:44:45 0 SYSTEM ORABM unknown 15:45:04 LOGOFF 15:45:04 0 ・・・ SYSTEM ORABM unknown 15:45:04 LOGOFF 15:45:04 0 SYSTEM ORABM unknown 15:45:04 LOGOFF 15:45:04 0 SYSTEM ORABM unknown 15:45:05 LOGOFF 15:45:05 0 SYSTEM ORABM unknown 15:45:05 LOGOFF 15:45:05 0 ^^^^^^ ^^^^^^^ 100行が選択されました。
監査データとして取得できるのは、TERMINAL列をみて分かるようにUNKNOWN。
つまり不明なわけである。
実際にはAPサーバがセッションを確立した際の情報が記録されており、クライ
アントの情報を記録することはできない。
ちなみに全く監査とは関係ないが、このときの(1)の処理時間は21.831(s) ・・・。
^^^^^^^^^^^^^^^^^^^
つづいて、(2)のコネクションプールを使用したプログラムを実行して、監査
データを確認してみる。
select os_username
,username
,terminal
,to_char(timestamp,'hh24:mi:ss') timestamp
,action_name
,to_char(logoff_time,'hh24:mi:ss') logoff_time
,returncode
from dba_audit_session ;
OS_USERNAM USERNAME TERMINAL TIMESTAMP ACTION_NAM LOGOFF_TIME RETURNCODE ---------- -------- -------- --------- ---------- ----------- ---------- SYSTEM ORABM unknown 15:44:43 LOGOFF 15:44:43 0 SYSTEM ORABM unknown 15:44:44 LOGOFF 15:44:44 0 SYSTEM ORABM unknown 15:44:44 LOGOFF 15:44:44 0 SYSTEM ORABM unknown 15:44:44 LOGOFF 15:44:45 0 SYSTEM ORABM unknown 15:44:45 LOGOFF 15:44:45 0 SYSTEM ORABM unknown 15:45:04 LOGOFF 15:45:04 0 ・・・ SYSTEM ORABM unknown 15:45:04 LOGOFF 15:45:04 0 SYSTEM ORABM unknown 15:45:04 LOGOFF 15:45:04 0 SYSTEM ORABM unknown 15:45:05 LOGOFF 15:45:05 0 SYSTEM ORABM unknown 15:45:05 LOGOFF 15:45:05 0 SYSTEM ORABM unknown 15:52:06 LOGON 0<-(1) ^^^^^^ ^^^^^^^ ^^^^^ 101行が選択されました。
さすが、コネクションプール100回の実行を1セッションでこなしている。
さらに、ACTION_NAME列を確認してみると、「LOGON」となっており、ログオン
しっぱなしであることも確認できる。
(2)の場合でも、TERMINAL列は当然UNKNOWN。
よって、WEBシステムの場合の監査はAPサーバのアクティビティまでした追跡
できないということか？
来週はさらにこのWEBシステムのデータベース監査について見ていこうと思います。
ちなみに、(2)の処理時間は0.791(s) ・・・。
^^^^^^^^^^^^^^^^^^
コネクションプールってけっこう効果ありなのですね。
まだまだ、残暑厳しい茅ヶ崎より。