監査ログをいかに取得し活用するか

監査ログの定義

そもそも監査ログとは、いかなるログの事を示すのでしょうか？皆さんは監査ログの定義をご存じでしょうか？感覚的には通じる単語ですが、前述の「5.」の事もありますので、まずはログから言葉を整理していきたいと考えます。

(1)ログの定義

ログの定義については、「IT用語辞典BINARY」で説明がありますので、引用します。
～IT用語辞典BINARY「ログ」の項目～

ログとは、主にコンピュータの稼働状況や、サーバーのアクセス状況などに関して、履歴を記録することである。または、そのようにして記録されたファイルのことである。
ログを出力する主なシステムとしては、オペレーティングシステム、サーバー、セキュリティソフトなどがある。

ログはテキストファイルとして出力されることも多いが、ログの種類は多種多様で、そのフォーマットもそれぞれ異なっているため、内容を読み取るのは容易ではない。また、多量のアクセスを処理するWebサーバーやメールサーバーなどにおいては、わずかな期間で膨大なデータ量のログファイルが生成されるため、システム管理者がログファイルを直接調べて解析を行うことは非常に困難である。そのため、通常は、ログを解析する専用のソフトウエアが用いられる。
ログを解析することによって、Webサーバーへのアクセスの傾向や、不正アクセスの兆候、Webページの問題点などをはっけんすることができる。

なお、最近では、内部統制の整備が企業に求められる中で、ログそのものの重要性が高まるとともに、ログが改ざんされていないことを証明する必要性も高まっている。

このように、監査ログのニュアンスが含まれる説明になっていますが、歴史的には、コンピュータのバグや不具合につながるエラーを記録するものであったと記憶しています。当時の開発者はエラーと一緒に出力されたダンプファイルなどを基に改修を行っていたのです。つまり、ログとはエラーという異常を検知するための記録と言う事ができます。

(2)監査ログ

続けて、監査ログの意味をご説明しますが、「監査証跡」と同じ意味であるように理解している方も多いようです。そこで、監査ログとの違いについても言及したく、「IT用語辞典BINARY」より「監査証跡」の説明も引用します。
～IT用語辞典BINARY「監査証跡」の項目～

監査証跡とは、情報システムの処理の内容やプロセスを、システム監査人が追跡するために時系列に沿って保存された記録のことである。
監査証跡は、情報システムの信頼性や安全性、効率性、有効性などが確保されていることを実証するために用いられる。OSやデータベース、業務アプリケーションなどの各種システムのログファイルは、有力な監査証跡となる。
なお、監査証跡は、処理された内容と結果の相互の関連を追跡するためのトランザクション証跡と、システム資源へのアクセスに関する因果関係を追跡するためのアクセス証跡に大別される。

こちらの説明も情報システムに限定しているような記述になっているので、監査証跡と監査ログがイコールであるように読み取れます。しかし、監査証跡となる監査証拠は全てがログといったデジタルデータしか採用されないわけではなく、例えば、IT内部統制の現場では情報システム部長による手書きの署名・署名日付・押印がセットになった承認記録を監査人に提出し、コントロールを有効と判断されるケースもあるわけです。

よって、監査ログとは「システムの利用者、開発者、運用者がシステムに対して実行した操作内容を時系列かつ連続的（いつ・誰が・何をした）に記録されたものであり、その記録からシステムの運用が法規制，業界基準、社内規定等の監査基準に準拠しているまたは有効であることを、監査証跡として証明するために使用するログの事」と解釈する事で、それぞれの差異が理解できるのではないでしょうか。簡単に言い換えると、監査証跡として使用するログデータの事を監査ログと理解すれば良いと考えます。また、監査ログはログの一部である事は間違いありませんが、目的が異なるログですので、別物と理解した方が良いと思います。

著者は監査ログの定義が世の中にどの程度明文化されて使われているか検索してみましたが、監査証跡と監査ログが同一のものとして説明されているか、監査ログの定義が無いまま単語が使われ、文脈から大体の意味が読み取れるようになっている記載しか見つけられませんでした。よって、ログと監査証跡と監査ログの違いが分かるよう、説明を長くしました。

ログと監査ログの違いを理解する上でのポイントとして、コンピュータ、サーバー等のシステムでは、デフォルト設定で監査ログとして使用できるログを出力しないようになっています。デフォルト設定で監査ログを取得しないようになっている理由として、監査ログ設定の有効化により、大量のログ出力によるディスク領域の逼迫とパフォーマンス低下が、システム運用上のリスクになるからだと考えています。データベースを例にすると、全てのSELECT文発行処理の「成功」をログとして出力する設定にした場合、「失敗」だけを出力する設定にするのと比較し、大量にログが出力されSystem表領域やディスク容量が逼迫する可能性がありますし、ログ出力というプロセスが発生し続けるため、CPUとディスクI/Oからパフォーマンスが低下するという事がご想像できると思います。

よって、監査ログを出力したい場合には、それは特別な要件として、デフォルト設定から変更する必要があるわけです。

監査ログ取得の必要性

何故、監査ログを取得するべきなのでしょうか？監査ログを取得する必要性は、次のようになると考えられます。

1. コンプライアンス要件
2. 事件・事故発生時の事実確認（証拠収集の観点を含む）
3. 取引先や会員等、ステークホルダーへの説明責任を果たすための「材料」
4. 再発防止策の策定
5. 事件・事故の兆候の収集

これらについて、順番に説明していきます。

（1）コンプライアンス要件

コンプライアンス要件は、前述でもご説明していますが、PCI DSSやIT内部統制などの観点で監査ログの取得が必要となるケースがあり、それらを準拠または遵守する上で必要になります。

PCI DSSバージョン1.2では、要件10に「ネットワークリソースおよび会員データへの全てのアクセスを追跡し、監視する事」とあります。関係する要件を表2に一覧化してみました。

また、内部統制については、財務報告の信頼性を保証する事を求められますので、財務報告にかかわるデータが不正に入力、改ざんされていない事を保証しなければなりません。

著者の経験から一例を挙げると、基幹業務システムの受発注処理では、未承認IDによるトランザクションの有無、トランザクション・データの改ざん防止を求められる事が多いと思いますので、これらを保証する監査ログの取得が有効なコントロールになります。

（2）事件・事故発生時の事実確認（証拠収集の観点を含む）

次に、事件・事故が発生した時の事実確認についてですが、これは、「何が起きたのか」についての正確な事実を把握する事を意味します。もちろん、事実確認に用いるログが正確である事が前提ですが、その場合は監査ログが客観的証拠となりますので、証拠収集の観点でも監査ログ取得は重要と言えます。

例えば、不正アクセスでサーバーに侵入されたとします。ひょっとしたら、データベースに格納された会員など顧客の個人情報が漏えいしたかもしれません。起きては困る事件・事故ですが、監査ログを取得していれば被害の内容が分かりますから、不正アクセスが発生した結果、誰が、誰の、どんな情報を盗んだか、といった情報が取得できます。監査ログがなければ、不正アクセスの場合は誰がどこにアクセスして、何をしたかが分かりません。