株式会社インサイトテクノロジー 発行
http://www.insight-tec.com
┏┏┏┏┏━━━━━━━━━━━━━━━━━━━━━━━━…・・ ┏━
┏┏┏┏┛ 2003.07.30 ┏┛┛
┏┏┏┛ ☆おら！オラ！Oracle -どっぷり検証生活-★ ┏┛┛┛
┏┏┛ ┏┛┛┛┛
┏┛・・…━━━━━━━━━━━━━━━━Vol.163━…・・┏┛┛┛┛┛
◇目次◇
■Oracle検証生活・・・Audit Trailについての検証 その１
■お知らせ・・・○ＱＡについて
■編集者より
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 Oracle 検証生活 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜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再起動。
今回のミッションはセッション情報の監査ログを残し、不正アクセスを防止す
ることなので、早速セッション情報の監査ログを残すよう設定しよう。
**********************************************************************
SQL> audit session;
Audit succeeded.
**********************************************************************
この監査オプションでは、システム全体に対して、ログイン（デフォルトでは、
ログインの成功、不成功の両方）、ログオフ時間、および OSユーザなど様々
な情報を取得できる。
ここで、ちゃんと監査が設定されたかどうか確認してみる。
今回は文監査なので、DBA_STMT_AUDIT_OPTSをみると...
（AUDIT関連のビューは$ORACLE_HOME/rdbms/admin/cataudit.sqlを実行する必
要があるかもしれません。）
**********************************************************************
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 <-(3)
^^^^
**********************************************************************
(1)は、13時59分（TIMESTAMP列）にログインし、同時（LOGOFF_TIME列）にロ
グアウトしている。また、最後のアクションはLOGOFFで、正常終了しているこ
とが分かる。
(2)のXPRTユーザは最後のアクションがLOGONが正常終了しているが、LOGOFF_TIME
がNULLであることから、現在ログイン中で、何かしらを実行していると考えられる。
(3)は、(2)と同様だけど、リターンコードがORA-01017であることから、ユーザ
名もしくは、パスワードが不正であることが分かる。ここでは、正規ユーザ
SAMPLE_Aに対して、パスワード不正でログインしようとしている。
ここで問題なのは、(3)。通常のシステムで同一時間帯に(3)が多発する場合は、
内部の人間が不正アクセスを試みた可能性がある。
また、(1)のような正常系のアクセスであっても、USERNAME列を監視しておく
ことが重要。例えば、デフォルトユーザ（通常はロックがかかっているHRやSH
ユーザ）でのログインなどは、デフォルトユーザを踏み台にした不正アクセス
の危険性がある。
今回の検証では、252回のログインを試みている（正常系250回、異常系2回）
このログインテストによって、AUDITを設定した場合は2.5 LPS（Logon Per Second）。
AUDITを設定しない場合は、3.0 LPSであった。
やはり、セッションの監査ログを残すにも、Oracleに負荷をかけていることが
分かる。セッション数が膨大なシステムでは、Oracleへの負荷もさることなが
ら、監査ログの解析も煩雑になることが予想される。
問題なのは、上記の(3)（不正アクセスの痕跡あり）であると割り切って、以下
のように、ログイン成功を監査しないオプションを実行することも一つの方法
だろう。
**********************************************************************
SQL> conn / as sysdba
SQL> truncate table aud$; <- 唯一データ操作が可能なAUD$
SQL> audit session whenever not successful;
^^^^^^^^^^^^^^^^^^^^^^^
Audit succeeded.
SQL> 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を解除する方法
**********************************************************************
SQL> noaudit session;
^^^^^^^
Noaudit succeeded.
SQL> select * from dba_stmt_audit_opts;
no rows selected
**********************************************************************
次週は、DBA_AUDIT_SESSIONの中のLOGOFF_LREAD（論理読込）、LOGOFF_PREAD
（物理読込）などから、問題になるセッションを見つけ、そのセッションが発
行したSQLの特定などを行ってみたいと思います。
夏真っ盛り、花火満開の茅ヶ崎より
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 ＱＡについて 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜皆様からのＱＡを受付けております＞
皆様のＱＡにはできるだけ、お答えしたいと思っています。
すべてのＱＡにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非ＱＡをお寄せください。
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 編集者より 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
先日、結婚した後輩のお祝いをしたんです。やはり最初の質問は「プロポー
ズの言葉は？」だったのですが・・奥さんから「結婚しよう」って言われた
そうなんですっ！！んー。年上の奥さんとは聞いていたのですが、まさかプ
ロポーズまでされていたとは・・。しっかりするんだよぉ。っと心の中で
後輩を応援してしまいましたっ☆ by TI
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
登録・解除は以下のURLで行うことができます。
http://www.insight-tec.com/jp/html/ora3/ora3.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜おら！オラ！Oracle－どっぷり検証生活－＞
発行／編集：株式会社インサイトテクノロジー
http://www.insight-tec.com
マガジンID：0000030093
本メールマガジンに掲載された記事を許可なく転載することを禁じます。
Copyright(c) 1995-2003, Insight Technology, Inc., All Rights Reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
