なぜ、失敗だけでなく「成功の監査」も必要？
ITシステムの監査における「成功」と「失敗」とは、ユーザーがある操作を行ったときに、それがユーザーの目的を達成した上で終了したか、何らかの理由によって完了できなかったかを表すものと考えるといい。
つまり、システムにおける「失敗の監査」は、「だれかがログオンしようとしたができなかった」「だれかが、あるファイルを開いたり、編集しようとしたりしたけれどもできなかった」ことを記録として残していくものである。この記録は、不正侵入の検知などに有効だ。
一方で、「成功の監査」は、なぜ必要なのだろうか？ いくつかの例を考えてみよう。
例えば「成功の監査」は、ファイルアクセスの稼働率を示すためのひとつの指標とみることもできる。従業員の会社に対する貢献度を明確にするためのデータの一部ととらえることもできるだろう。
また、成功の監査により、会社が休みの日なのにログオン記録があれば、なぜ、この社員は会社が休みの時に出勤しているのだろうという疑問が出てくる。それは例えば、休日を返上して仕事をしているからかもしれない。この社員は平日に仕事が終わらないため、休日になると遅れを取り戻すために仕事をしているかもしれない。この場合は従業員の仕事配分が平準化できていないということになる。つまり、仕事の絶対量が多すぎるのか、仕事の指示がうまくないかのどちらかだ。もし、過労によりミスが頻発するようであれば、会社側の監督責任である。
一方で、もし、休日の誰もいないオフィスで、会社の取引先情報をせっせと自分のPCにコピーしている社員がいるとする。それは将来、自分が独立する時のために顧客名簿を作成しているのかもしれない。もちろん、このケースでは顧客情報の流出となり、やはり会社の監督責任が問われる。
監査記録を元に、該当社員に理由をヒアリングして対策を立てれば、これらの問題は防げるかもしれないのだ。
使いようによっては、「成功の監査」を、いわば業務プロセスの「見える化」のための道具として活用することもできるのである。
書類はファイルサーバに集積
PCでの操作履歴や環境の変更、入出力、エラーの記録のことを一般的に「ログ」と呼ぶ。こうした履歴をすべてログとして記録すると、ログのサイズは大きくなる一方なので、ある程度の取捨選択は必要である。とはいえ、最低でも「ログオン認証の成功失敗」「ファイル作成」「プリンタ出力」「削除」などのログは残しておきたい。
通常、こうしたログは、ローカルのPCに蓄積される。そのため、ログを収集するには各クライアントを調査しなければならない。これは手間のかかる仕事だ。少しでも手間を省くのであれば、社内のファイルはすべてサーバに集めてしまい、そこでログを収集する。これなら、ログの調査はサーバだけで良い。
手間はかかるものの、クライアント側に保存されたログを活用することもできる。クライアントのログは、監査していることが従業員にもわかるように、繁忙期を避けて数カ月ごとに見る。経営陣と従業員が定期的にログを見ながら、ヒアリングする場を作れば、客観的に仕事ぶりを評価できるだろう。それに、クライアントでもログが監査されていると意識させることで、不正の抑止力にもなる。
