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

（3）取引先や会員等、ステークホルダーへの保障や説明責任を果たすための「材料」

また、事件・事故が発生した時には、何らかの社内調査をして確認できた事実を基に、どのように説明するかについての対応を決めますので、監査ログがない場合には客観性レベルの低い、憶測のような情報を基に事実推定をしてプレスリリースを行う事になります。Webサーバーのログから不正アクセスが確認できたものの、他のログで何が行われたのかについて事実が特定できなかった際にありがちな、プレスリリースの考え方を挙げます。

• ログが無いから何をされたのかという事実が分からない
• つまり、顧客データベースの中身を盗まれたかどうかも分からない
• よって、情報が漏えいした形跡は無いと発表すれば良いだろう（嘘はついていない。また、いたずらにステークホルダーに心配をかけるのも良くないし、事を荒立てたくない）

事実を基に判断をして、プレスリリースを行う事は正しい対応だと考えます。しかし、情報漏えいは起きていないという内容でプレスリリースを出した後に、実際にはクレジットカード番号も含め顧客情報が漏えいしていたという、より悪い事実がマスコミの報道で発覚してしまった場合、ステークホルダーの信用は低下するでしょうし、一般消費者からは問い合わせが殺到してしまう事でしょう。（2）と合わせて、事件・事故対応をするために監査ログが必要となる事がお分かりになると思います。また、監査ログが無ければ、実際に事件・事故が発生していても、それに会社側が気付く事ができないという事も、一つのリスクと言えるのではないでしょうか。

（4）再発防止策の策定

再発防止策を策定する際にも、ログから分かった内容を基に検討をする事により、再発防止策として説明責任に足る施策が何であるかが分かるため、ここでも監査ログの取得が有益だと言えます。

読者の中には、抽象的な説明に聞こえる方がいるかもしれませんので、1つ例示をします。

社内から1,000人分の顧客情報が漏れた際、漏れた情報がもともと社内のどこに保管されていたのかによって、対策をする箇所が変わってきます。データベース・サーバーが不正アクセスを受けていたのであれば、データベースに対するセキュリティ対策（アクセス制御、権限管理、レコードの暗号化など）が役に立ちますが、社内マーケティング部署が社内ファイルサーバーに保管している顧客管理資料（ExcelやAccess形式のファイル）から漏れていた場合には、従業員が使用するクライアントPCに対するセキュリティ対策（持ち出し制御を目的としたツールの導入など）が必要になるでしょう。

この例のポイントは、漏れた顧客情報はデータベース・サーバーの中に格納されているだけでなく、同一または部分的に一致する情報は社内に点在するという事と、漏えいした情報と同じ情報がデータベースのみならずファイル形式で存在していた場合、漏えいした情報の中身を特定しただけでは、情報が保管されていた場所が特定できないという事です。1,000人分程度であれば、Excelファイルから漏れたとしても不思議ではありません。

よって、流出経路・過程といった情報を正しく理解していないと、本当に再発を防止するための対策にならないだけでなく、無関係な対策に手を出す事によるコスト発生も懸念されます。

（5）事件・事故の兆候の収集

事件・事故の兆候は、定期的なログのチェックをする事でつかめる事がありますが、リアルな事件・事故が発生する前に食い止める事ができたとすれば、それに越した事はありません。普遍的な兆候は人間の心理も絡み、明示化する事は難しいのですが、複数のログを突き合わせる事で兆候が見つかる場合も実際にはあるのです。

例えば、1人1台のPCを使用し、それぞれが独立した固有のIDを使用しているとします（つまり、共有PC、共有IDを使用していない環境という事です）。そうすると、ユーザーID「A」は通常、特定のPC「XXX」でのみログインされている事になるわけです。しかし、異なるPC「YYY」にて金曜日の夜中にユーザーID「A」によるログイン記録があり、その時間帯にはユーザーID「A」の使用者は入退館システムのログからは退社済みであったとすると、不正の兆候が見られると言えます。この場合、PC「YYY」は一時的に使用禁止にするか、使用者に事情をヒアリングする事で、水際での防止が成功する可能性があります。

監査ログの取得方法（データベースの例）

監査ログを取得する必要性をご説明しました。次に、監査ログの取得方法をご説明します。設定の方法は機器によって変わりますが、例としてOracleデータベースに対する監査にどのような種類のものがあるか、次に、監査ログ取得の方法についてご説明します。

（1）標準監査

文（特定のSQL）、権限、スキーマオブジェクト（表・ビュー・シーケンス・ストアドプロシージャ・ストアドファンクション・パッケージ）に対する監査を行う機能の事です。

（2）ファイングレイン監査

Oracle9i以降のEnterprise Editionで使用可能なログ取得設定で、標準監査と比較して粒度の細かい監査が可能です。例えば、休日のアクセスのみ、特定の列に対するSELECT文が発行された時のみロギングする事が可能です。

ファイングレイン監査の設定方法は、DBMS_FGA.ADD_POLICYプロシージャを作成します。表3にプロシージャの構成を記載しました。

（3）必須監査

管理者権限でログインしたユーザーの、インスタンスへの接続・インスタンスの起動・インスタンスの停止操作が記録されるもので、Oracleのインストール時にデフォルトでログが取得される設定になっています。

（4）DBA監査

SYS、SYSDBA,SYSOPER権限でログインしたユーザーに対する、すべての操作をOSファイル上にログ取得します。なお、Windows OSの場合においては、DBA監査のログ出力先はイベントログになり、変更は不可能です。

表4に、監査種類ごとの設定手順を一覧化してみました。標準監査のAudit文等の詳細は、別途確認してください。

監査ログの管理方法

監査ログを集めてみたものの、普段または有事の際に使えないのでは本末転倒です。ここでは、「使い物になる」監査ログの管理方法のポイントを次に分けて説明します。

1. 取得対象の選定
2. 保管期間と分析頻度
3. 事件・事故発生を想定した訓練
4. 統合ログツールについて

1. 取得対象の選定

やみくもに監査ログを収集しようとすると、本当に必要なログが取得できていない事や、余計なログまで取得するためにストレージが膨大になる事がありますから、必要な監査ログを必要なだけ取得する事が必要になります。ここで大切な事は、「なぜ監査ログを取らなければならないか」という、目的の明確化です。

兆候をつかみ水際で事件・事故を防止する、または事件・事故発生時の対応検討材料を取得した上で正しい対応を採りたいと考えるリスク（例えば、外部からの不正アクセスや従業員による不正な情報の内部からの持ち出し）に対し、ネットワーク図や個々のシステムに存在するIDなどを眺めれば、事件・事故の想定シナリオも含め見えてくると思います。

ここで注意すべきなのは、単一のシステムから得られるログだけでは事実確認がほとんどできないという事です。例えば、外部からの不正アクセスであれば、ネットワーク上の経路から取得設定をするべきシステムは、次が想定されますが、それぞれのログを時刻やIPアドレスなどで数珠つなぎに重ね合わせなければ、流出経路が特定できません。

• ネットワーク機器（ファイアウォール、ルーター/スイッチ、IDS、RADIUSサーバー等ゲートウェイ）
• Webサーバー
• データベース・サーバー
• OS