InsightTechnology 旧ブログ

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

今週からAudit Trail（監査証跡）について検証していきたいと思います。

最近、セキュリティがらみの監査が注目されていますが、監査といっても幅広
く、まずは監査機能の概要から勉強してみましょう。

■□ Audit Trail概要 ■□■□■□■□■□■□■□■□■□■□■□■□

IT業界では、「個人情報保護法」の成立、施行に伴い、セキュリティ関連分野
が盛り上がりを見せている。特に、多発する情報漏洩事件をきっかけにエンド
ユーザの関心も高まっており、セキュリティを疎かにすることは企業にとって
は社会信用問題に発展する恐れが強まっている。

以前より、Oracleには様々なセキュリティ機能が搭載されている。その中に、
セキュリティ侵害による被害を抑制する仕組みとして、「監査」という機能が
ある。この監査を使用すると、データベースにログオンしたユーザが実行中の
操作を監視し不正な操作があった場合には早期発見することができる。

Oracleの標準監査では、AUDIT文を使用してユーザの操作を監視して、その内
容に応じて監査証跡（ログ）を記録することがでる。AUDIT文による監査には、
大きく分けると次の3種類がある。

1）文監査
2）権限監査
3）オブジェクト監査

1）「文監査」は、特定のSQL文を対象にした監査。
例えば、AUDIT tableでは、CREATE TABLE文やDROP TABLE文などの使用
が監査対象となる。

2）「権限監査」は、特定の権限の使用を対象にした監査。
例えば、AUDIT create any triggerでは、ユーザがCREATE ANY TRIGGER
権限を使用してデータベース・トリガーを作成した場合に監査対象となる。

3）「オブジェクト監査」は、特定のオブジェクトに対する操作を対象に
した監査。例えば、AUDIT select ON ordersでは、ORDERS表に対する
SELECT文の発行が監査対象となる。

ふーん。要は、Oracleは以前からレベルの違う監査オプションを用意していて、
環境やセキュリティポリシーによって使い分ける必要があるのね。何でもかん
でも監査すればよいわけじゃ無いということ。
監査の種類によって、性格は違うし、システムパフォーマンスへの影響も心配だ。

そこで、今回は、監査の本質とパフォーマンスへの影響を見極めるべく、バリ
バリ監査することにします。ちなみに検証での目標は以下の3つ。

・監査の精度とパフォーマンスの関係
– 精度を上げたとき、パフォーマンスへの影響は？

・取得できたAudit情報は何に使えるのか？

・Auditとセキュリティーの関連
– 最近のAPサーバー構成では1Oracleユーザが当たり前？

今回の監査は、ある程度シナリオを作って、（企業のDBAになりきって？）検
証を行っていきます。検証シナリオは以下の通り。

■□ 検証シナリオ ■□■□■□■□■□■□■□■□■□■□■□■□■□

今回の検証では、前提となる監査シナリオにそって、監査を実施します。監査
シナリオは、Level 1 ～ Level 4まで設定してあり、Level 1では、Audit session
等の文監査による包括的な監査手法を検証します。

Level 2では、オブジェクト監査による、詳細な監査手法を検証します。

Level 3、4では、ファイングレイン監査（Oracle9iからの新機能）により、更
に詳細かつアプリケーションディペンドな監査手法を検証してみる。

前提）
ある企業（A社）は、商品の受発注システムを構築している。A社の情報
システム部門はA社内部からの情報漏洩、不正アクセス等により、重要な
顧客データの流出の可能性を懸念している。

そこで、Oracleの持つ監査機能を使用して、内部監査を実施することに
した。しかし監査といっても幅広く、また、監査によるパフォーマンス
劣化も心配される。監査項目（取得できる情報量）および、監査がパフ
ォーマンスに影響する度合いを把握するためいくつかの監査レベルを設
定することにした。

Level 1）
特定のアプリケーションユーザのログインの監査ログを取得し、データ
ベースへの不正アクセスを発見する。

Level 2）
重要度の異なる特定のテーブルに対する操作（SELECT、UPDATE、INSERT、
DELETE等）の監査ログ取得し、不正データ操作を見破る。

Level 3）
特定のテーブル（例えばCustomer表）には、顧客情報が格納されている。
顧客情報の氏名、性別等の一般情報には制限をかけないが、住所、電話
番号など顧客を特定できる機密情報には、情報漏洩を防止するため、ア
クセスされる度に監査ログを取得する。といった、特定テーブルの特定
列に対する監査を実行してみる。

Level 4）
社内の最高機密情報を格納するテーブル（例えばConfidential表）への
アクセスおよびデータ操作は監査ログを取得するともに、不正アクセス
の場合は即対応できるように、担当者にメールで通知するようにする。

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

では、シナリオにそって、Level 1から検証スタート！！

まず、監査を行うには、パラメータファイルに以下の設定を行う。

audit_trail=[ NONE | TRUE | FALSE | DB | OS ]
audit_file_dest=$ORACLE_HOME/rdbms/audit（デフォルト値）

NONE、FALSEは監査証跡を残さない。TRUE、DBと設定すれば、オラクルオブジ
ェクトのSYS.AUD$上にデータを格納する。OSと設定した場合は、audit_file_dest
に指定したディレクトリにファイルとしてデータを格納する。
（NT系の場合はOSに設定するとイベントビューアに書き出す）

※ SYS.AUD$は放っておくとどんどんデータが蓄積されていく。そこで、定期
的にデータを削除する必要がある。また、SYS.AUD$はSYSTEM表領域に作成
され、TruncateなどDMLが実行することからSYSTEM表領域のフラグメントが
心配される。そこで、SYS.AUD$を他の表領域に移動させることを考える人
もいるだろうが、アップグレードなどに問題が発生する可能性があるとし
て、サポートされていない。そんな時は、audit_trailをOSと設定し、ファ
イルとして蓄積させることが可能。

audit_sys_operations=[ TRUE | FALSE ]

このパラメータは、9iから導入されオラクルのSYSユーザ（すべてのSYSOPE、
SYSDBA含む）の動作を監査対象にするかどうかのオプションである。
ちなみに8i以前では、SYSOPE、SYSDBAユーザを監査対象にすることはできない。

今回はaudit_trail=DB、audit_sys_operations=FALSEに設定して、Oracle再起動。

今回のミッションはセッション情報の監査ログを残し、不正アクセスを防止す
ることなので、早速セッション情報の監査ログを残すよう設定しよう。

audit session;
Audit succeeded.

この監査オプションでは、システム全体に対して、ログイン（デフォルトでは、
ログインの成功、不成功の両方）、ログオフ時間、および OSユーザなど様々
な情報を取得できる。

ここで、ちゃんと監査が設定されたかどうか確認してみる。
今回は文監査なので、DBA_STMT_AUDIT_OPTSをみると…
（AUDIT関連のビューは$ORACLE_HOME/rdbms/admin/cataudit.sqlを実行する必
要があるかもしれません。）

select * from dba_stmt_audit_opts;

USER_NAME PROXY_NAME AUDIT_OPTION        SUCCESS    FAILURE
--------- ---------- ------------------- ---------- ----------
CREATE SESSION      BY ACCESS  BY ACCESS
^^^^^^^^^  ^^^^^^^^^^

※DBA_STMT_AUDIT_SESSION

USERNAME : ユーザ別監査の場合はユーザ名。クライアントのかわりにプ
ロキシが行うアクセスが監視されている場合は、ANY CLIENT。
システム全体の監査の場合はNULL
PROXY_NAME : クライアントに対して操作を実行しているプロキシ・ユーザ名。
クライアントが直接操作を実行している場合はNULL。
AUDIT_OPTION : システム監査オプションの名前
SUCCESS : WHENEVER SUCCESSFUL システム監査のモード
FAILURE : WHENEVER NOT SUCCESSFUL システム監査のモード

**********************************************************************

ちゃんとログインした時（成功、不成功）に監査するオプションが設定された
ようだ。（今回は特定のユーザのログインを監査するのではなく、全てのユー
ザのログインを監査するオプションなので、USER_NAME列はNULLになっている）

※ 特定のユーザの監査を行う場合
audit session by “特定のユーザ名” ;

では、テストとして、正規のユーザSAMPLE_A～SAMPLE_Yまでの25人がデータベー
スにアクセスできるシステムがあるとして、そこに、時々、SAMPLE_Zという存
在しないユーザや、パスワードを間違えてログインしようとする環境を作って
みる。

この時にSYS.AUD$のサブセットである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_USERNAME USERNAME TERMINAL TIMESTAMP ACTION_NAME LOGOFF_TIME RETURNCODE
----------- -------- -------- --------- ----------- ----------- ----------
kshinkub    SAMPLE_A KSHINKUB 13:59:22  LOGOFF      13:59:32             0  <-(1)
・・・
（省略）
・・・
kshinkub    SAMPLE_Y KSHINKUB 14:02:03  LOGOFF      14:02:13             0
oracle      XPRT              14:03:14  LOGON                            0  <-(2)
kshinkub    SAMPLE_Z KSHINKUB 14:03:39  LOGON                         1017
kshinkub    SAMPLE_A KSHINKUB 14:03:45  LOGON                         1017   conn / as sysdba

truncate table aud$;
audit session whenever not successful;
^^^^^^^^^^^^^^^^^^^^^^^
Audit succeeded.

select * from dba_stmt_audit_opts;

USER_NAME PROXY_NAME AUDIT_OPTION        SUCCESS    FAILURE
--------- ---------- ------------------- ---------- ----------
CREATE SESSION      NOT SET    BY ACCESS
^^^^^^^

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_USERNAME USERNAME TERMINAL TIMESTAMP ACTION_NAME LOGOFF_TIME RETURNCODE
----------- -------- -------- --------- ----------- ----------- ----------
kshinkub    SAMPLE_Z KSHINKUB 15:03:39  LOGON                         1017
kshinkub    SAMPLE_A KSHINKUB 15:03:45  LOGON                         1017

↓
ログインに失敗したセッションのみ監査ログに記録される

※ LPS（Logon Per Second）は筆者の造語
※ AUDITを解除する方法
**********************************************************************

noaudit session;
^^^^^^^
Noaudit succeeded.

select * from dba_stmt_audit_opts;

no rows selected

**********************************************************************

次週は、DBA_AUDIT_SESSIONの中のLOGOFF_LREAD（論理読込）、LOGOFF_PREAD
（物理読込）などから、問題になるセッションを見つけ、そのセッションが発
行したSQLの特定などを行ってみたいと思います。

夏真っ盛り、花火満開の茅ヶ崎より