ログマイナー再び！！　その９

＜ログマイナー再び！！　その９＞
ペンネーム：ぽっちゃりメタボン

読者の皆様こんにちは！！

早起きして執筆しているぽっちゃりメタボンです。

「早起きは三文の得」何か良いことがあればいいですねぇ。

では、今週もはりきってはじめましょう。

▼ 前回までのまとめ

前回まで８回に渡ってログマイナーの検証を行ってきました。

ログマイナーの存在を知らなかった人も、知ってはいたけど使い方、または
用途がイメージできないといった人の助けになれたのでは（ほんと？）と感じ
ています。

今回は本シリーズの目的の一つであった「事後監査」を行っていく上でのまと
めを行います。

▼ 事後監査の流れ

以下に、事後監査を行っていく上での流れを書いてみます。

１．傾向分析
２．分析結果の精査
３．監査ポリシーの決定
４．監査の実施

では一つづつ中身を確認していきましょう。

１．傾向分析
ログマイナーを使って対象となるシステムの「傾向」を把握します。
ここで言っている「傾向」ですが以下の２点があると考えられます。

・アクセス傾向

監査対象となるシステムに対してどういった経路でアクセスされているのかを
掴むことが重要です。

切り口としては、「OSユーザ」、「DBユーザ」、「プログラム」などが考えら
れます。

まずは、どういったOSユーザ、DBユーザ、プログラムからのアクセスがあるの
か、またはその組み合わせはどのようなものが現在あるのかを把握します。

ログマイナーで使用可能なv$logmnr_contents表ではその情報が確認可能です。
ただし、その情報が格納されている v$logmnr_contents.session_info は一つ
のカラムに複数の情報が入っているので確認をする際には、項目を切り出すこ
とが必要になります。

[DBユーザ]
substr(substr(session_info,instr(session_info,’login_username’)),1, _
instr(substr(session_info,instr(session_info,’login_username’)),’ ‘)) DB_USER,

[OSユーザ]
substr(substr(session_info,instr(session_info,’OS_username’)),1, _
instr(substr(session_info,instr(session_info,’OS_username’)),’ ‘)) OS_USER,

[プログラム]
substr(substr(session_info,instr(session_info,’OS_program_name’)),1, _
length(session_info)) PROGRAM

上記３つの項目に対する組み合わせを取得するためには以下のSQLを実行しま
す。

select distinct DB_USER, OS_USER , PROGRAM from
(select [DBユーザ],[OSユーザ],[プログラム]) from _
v$logmnr_contents where operation != 'INTERNAL');

また、ここでポイントとなるキーワードが「職務分掌」

・SQL傾向

システム内の表に対してどういった、オペレーションが行われているのかを把
握します。ここで言っているオペレーションとは各種DMLの事を指しています。

上記の情報を取得するためには以下のSQLを実行します。

select distinct seg_name , operation from v$logmnr_contents
where operation in ('UPDATE','INSERT','DELETE');

どうでしょうか、実際に分析してみると「え？なんだこのプログラムは？」
「業務委託会社に割り当てているアカウントからのUPDATEが存在している」
といった意外なアクセス経路、SQLがあるのではないでしょうか。

まずは、現状を把握することが大事です。

２．分析結果の精査

１．で分析したアクセス経路、SQLパターンの結果から現在のシステム利用傾
向を把握することはできました。

これを元にして、これは正規アクセス、これは不正アクセスとといった選別を
行っていきます。

また、ある表に対してのオペレーションはUPDATEが存在せず、INSERTとDELETE
しか存在しないということもわかりました。

こういったプロセスを経なければ、システムに適応した、より効果的な監査ポ
リシーを決定することは非常に難しくなってしまいます。

３．監査ポリシーの決定

ここまで、「分析」、「分析結果の精査」を行いました。
これらに基づいて監査ポリシーの決定を行います。

２．「分析結果の精査」がしっかりと行われていればすんなりと決められると
思います。

また、業務の運用ルールに絡めたポリシーもあるかと思います。
例えば、重要な顧客情報を更新する際には必ず作業申請書の提出を義務付ける
などがありますね。そのような運用をしている場合にはデータが申請通りに
更新されているかどうか、または、申請されていない更新がある場合には違反
とするといったものが考えられます。

４．監査の実施

決定したポリシーに基づいて、監査を実施します。
これはログマイナーを使用して実施することが可能です。

イメージとしてはポリシー毎にWhere句に条件を付加した形で v$logmnr_contents
に対して実行するSQL文を用意しておきます。

監査担当者がそれを実行し、ポリシー違反のアクセス、及びSQLがないかを
チェックしていきます。

また、３.で示した例である作業申請書と突合せた上で、更新が正しく行われ
ていたかなどもチェックします。

ここで違反があった場合にはそれぞれの違反に対して是正、及び指導していく
必要があります。

▼ まとめ

いかがでしたでしょうか。
ログマイナーを有効活用して事後監査を実施していけそうですね。

ただし、監査では継続的にかつ、サイクルとして実行に移していくことが大事
ですので一回で満足せず、継続的に行っていきましょう。

本シリーズも次回で最終回となります。
感慨深いものがありますが、ラストスパートしていきます。

今回はここまで！！

秋の味覚を味わいたい茅ヶ崎より

ログマイナー再び！！ その９