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

投稿日: 2003年8月06日

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

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

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

<Audit Trailについての検証 ~その2~>
ペンネーム ベロ

では、今週から本格的に監査を実行していこと思います。

先週は、audit_trail=dbと設定し、全てのセッション確立をSYS.AUD$に格納する
ように設定してある。
また、LPS(Logon Per Second)を計測してパフォーマンスに与える影響を確認
してみた。

今回は、このセッション監査をもう少し掘り下げていこうと思います。

□■ セキュリティー編 □■□■□■□■□■□■□■□■□■□■□■□■□■

では、セッション監査を行った後、セキュリティーに関して見るべき項目をあげ
てみる。使うディクショナリは先週同様「DBA_AUDIT_SESSION」

(DBA_AUDIT_SESSION内の見るべきポイント)

-------------------------- ------------------------------------------------
TIMESTAMP,LOGOFF_TIME     : ログイン - ログオフの時間が長いセッションが
                            いないか監視することが大事。
-------------------------- ------------------------------------------------
LOGOFF_LREAD,LOGOFF_PREAD : セッション内での論理読込、物理読込の量を監視
                            し、大量の読込であればそのオペレーションの妥
                            当性を確認しなければならない。
-------------------------- ------------------------------------------------
RETURNCODE                : 0以外のものを監視する必要がある。
-------------------------- ------------------------------------------------
SESSION_CPU               : セッション内でのCPU使用時間を監視することに
                            より、ループプロセスなどの発見に繋がる可能性
                            がある。
select os_username                      osuname
        ,username                         dbuname
        ,sessionid                        sesid
        ,(logoff_time-timestamp)*24*60*60 conn_time
        ,logoff_lread                     lread
        ,logoff_pread                     pread
        ,action_name                      act_name
        ,returncode                       retcd
        ,session_cpu                      ses_cpu
     from   dba_audit_session;
OSUNAME DBUNAME SESID CONN_TIME LREAD    PREAD    ACT_NAME RETCD SES_CPU
------- ------- ----- --------- -------- -------- -------- ----- -------
kshin   SYSTEM  32857      4546   221647    12726   LOGOFF     0    2418 <-(1)
       ・・・              ^^^^
oracle  ORABM   32856      2330 12392624        1   LOGOFF     0  230963
select vs.sql_text
           ,du.username
           ,vs.executions     execs
           ,vs.loads          loads
           ,vs.disk_reads     d_reads
           ,vs.buffer_gets    buf_gets
           ,vs.rows_processed row_proc
           ,vs.cpu_time       cpu_t
    from   v$sql vs, dba_users du, dba_audit_session da
    where  da.sessionid      in (32856,32857)
    and    vs.parsing_user_id = du.user_id
    and    du.username        = da.username
    and    vs.last_load_time between to_char(da.timestamp
                                            ,'yyyy-mm-dd/hh24:mi:ss')
                            and to_char(da.logoff_time
                                            ,'yyyy-mm-dd/hh24:mi:ss');
SQL_TEXT           DBUNAME EXECS LOADS D_READS BUF_GETS ROW_PROC CPU_T
------------------ ------- ----- ----- ------- -------- -------- ------
declare a varchar2 ORABM       1     1       1 12392590        0 230961
SELECT * FROM DBA_ SYSTEM      4     1    3955     4016      132    220
SELECT * FROM V$SE SYSTEM      1     1       1       60        1      4
・・・
(省略)

このSQLでは、セッションを特定してSQLを検索することはできない。あくまでも、
SQLのロードされた時間とユーザを指定していることに注意してほしい。

DBA_AUDIT_SESSIONだけの情報では、セッション内で行った操作を追跡すること
はできない。
(ちなみにLAST_LOAD_TIMEは最後にロードされた時間なので、上記SQLでは、取得
できないSQL文もでてくる)

+-------------------------------------------------------------------------+
| 結局、ユーザのアカウンティング(誰が、いつ、どこからログインしたのかを  |
| 監視)以外に、セッション内での操作履歴を見ようとするとセッション監査だ  |
| けでは無理ということ!                                                   |
+-------------------------------------------------------------------------+

アカウンティング以外であれば、監査レベルを上げ、特定オブジェクトに対する
SQLを監査するオブジェクト監査を実施する必要がありそうだ。
ということで、次週からはオブジェクト監査について検証していきます。

□■ パフォーマンス編 □■□■□■□■□■□■□■□■□■□■□■□■□■

前回のLPSでは、ある瞬間にLogonが集中した場合のLogon限界値を示しています。
だから、Logonが集中するという特別な状況以外は役に立たない指標と言えるかも
知れない。

そこで、TPC-Cのベンチマークプログラムにより50セッションでの負荷テストを実
施してみよう。監査有り / 無しそれぞれ、ベンチマークを5回実行して、その平均
TPS(Transaction Per Second)を算出する。

(ちなみに、このTPC-CベンチマークによりOracleサーバは高負荷(特にCPUが100%
で振り切った状態)になる)

では、ベンチマークスタート!!

(1) 監査無しの場合・・・・・・・131 TPS
(2) 監査有りの場合・・・・・・・131 TPS

うーん。計ったように同じ値になってしまった。

+--------------------------------------------------------------------------+
| 普通のOLTP処理においてセッション監査を実行しても、パフォーマンスには影響 |
| を与えないということ!                                                   |
+--------------------------------------------------------------------------+

では、次週からはオブジェクト監査について検証していきます。

やっと、梅雨明けでいきなり夏&夏ばての茅ヶ崎より