ログから何を見つけるのか?
取り合えずログを集めておいて後から使い方を考える、というアプローチも無い訳ではありません。本特集の第2回でご説明した「規制対応型」の対応を、外部からの要請のために至急行わなければいけない、というケースも実態として多いのも事実です。
しかし、前回までお話してきたように、ログを無目的に、何の考慮もせず溜めているやり方では、「後から」ログを使おうにも、様々なデータの不足や、ログの内容に関する解釈の問題（理解できないログ）に突き当たり、有効に活用する事は困難です。
ログを溜める目的、それは、そこから何かを見つけ出す為です。ログから何を見つけるのか、ログ管理を始める時、このポイントが明確になっているか否かで、今後のログ活用の成否が決まると言っても過言ではありません。今回は、「ログの見方」についてご説明します。
ログ「だけ」見ることの限界
ログを見る事とは、一言で言えば「比較する」という事です。
まずは簡単な例ですが、ITシステムにエラーが発生しているか否かをログから調べるとしましょう。見方は、”エラーメッセージがログに記録されているかどうか” です。これは、”エラーメッセージがログに記録されていない” という「基準」がある為、発見する事が出来ます。
次に、「不正アクセス」を例に、ログイン失敗ログを見ることを考えてみましょう。調査の結果、1日の会社全体のログイン失敗回数は100回だったとしましょう。この数字から不正が行われている可能性を判断できるでしょうか。この数字だけでは、恐らく誰にも判断できません。「基準」が無いからです。
では、同じログイン失敗ログの見方でも、下記ならどうでしょうか。
- 前月の平均値と比較するとログイン失敗回数が2倍以上多くなっている
- ログイン失敗ログに記録されているアクセス元のIPアドレスが、いつもの端末のものと違う
- 作業申請が出ていないサーバで、ログイン失敗ログが記録されている
こうした「比較」によるログの分析が、単なる回数のカウントをより遥かに有効である事はお分かり頂けるかと思います。上記は、”前月のデータ”、”いつもの端末”、”作業申請” など、「基準」と、実際の行為の結果であるログを比較し、「基準」から外れたものを見つけ出す、というものです。この「基準」はいずれも、ログには直接的には含まれていない情報です。
ここで言いたい事は、ログ「だけ」を見て、そこから何かを見つけ出そうとする事には限界があるという事です。繰り返しになりますが、ログを見る事とは「比較」するという事ですから、比較対象となる、「基準」を作る必要があります。
ログを見る際の基準
それでは、「基準」となるものを幾つか挙げてみましょう。
| 基準 | 概要 | 例 |
|---|---|---|
| 企業内のルール／手続き | 社内規定やセキュリティポリシーなど。 | 作業申請情報／勤務表／最新パッチの適用ルール／サーバアクセスの際の管理端末 |
| 管理台帳・マスタ | IT資産上のデータの棚卸しをする際に、正とするもの。 | IDカード管理台帳／アカウント一覧／ファイアウォールのポリシー一覧 |
| 過去の実績値 | 自社の昨日／先月／去年などの実績値。 | 先月の平均ログイン失敗回数／キャンペーン実施前のWebアクセス回数 |
| 既知のパターン | 「ログにこの内容が出ていたら疑いがある」といったパターン。 | システムエラーが生じた際に記録されるログのパターン／マルウェアが外部サイトと通信する際に記録されるログパターン |
| 期待値・目標値 | 施策実施後の期待値 | 設備増設後の性能向上値／セキュリティ教育後のポリシー違反率 |
上記のような「基準」と「ログ」を突合せる分析の仕方は「ログの突合（とつごう）」と呼ばれ、最近ようやく実践され始めてきました。それでは下記で、幾つか具体的なログの突合の例をご覧頂きましょう。
ログの突合例
例1．作業申請書と実作業ログの突合
下記は、作業申請書と実作業ログの突合の図です。
サーバや機器、アプリケーションに対してメンテナンスを行う際など、作業申請を出し、承認を受けた後に作業を行う、というフローを持っている企業が多いかと思いますが、この例は、その「作業申請」と「実作業ログ」を突合せ、申請通りに正しく作業が行われているかどうかを判定するレポートです。
申請の出ていない作業が行われていたり、申請されているにも関わらず作業が行われていない（特に退職者アカウントの消し忘れなどは後にセキュリティ事件・事故につながりやすい）などを正確に把握することが出来ます。 単にログデータを眺める事と比較し、遥かに確実で効率的である事がお分かり頂けるかと思います。
例2．勤務表と入退室ログの突合
下記は、勤務表と入退室ログの突合の図です。
勤務表上では「定時退社」となっていながら、実は定時後も作業をし続けているような、所謂サービス残業の有無を把握するレポートで、労働基準法対応として用いられるケースが増えています。このレポートでは、勤務表と入退室システムのログを突合せ、勤務表上の退社時間より10分以上後(タイムカードへの打刻後、実際に建物を出るまでにタイムラグがあるため）に入退室システムに当該ユーザのログが記録された場合、これを報告します。入退室ログには、実際の人の出入りというごまかせない「事実」が記録されますので、正確な勤務状況の把握が可能になります。
例3. ICカード管理台帳と入退室ログの突合
下記は、ICカード管理台帳と入退室ログの突合の図です。
ICカードの管理台帳と、例えば過去半年分の入退室ログを突合せて未使用のICカードを抽出したり、また逆に、管理台帳上は存在しないICカードの使用実態（未返却のICカードの使用など）も把握する事が出来ます。
こうした棚卸し的な使い方は他でも応用でき、例えばファイアウォールのポリシー情報です。ファイアウォールのポリシー情報は長年の運用の中で蓄積されたものが登録されていますが、運用状況の変化・変更の中で既に有効ではないポリシーも設定として多く残り、それがファイアウォールの性能に影響を与えているようなケースもあります。ポリシーの一覧と実際のファイアウォールの通信ログを突合せ、使用されていないポリシーを抽出し、その妥当性を判断するような使い方も出来ます。
上記のようにログを活用できる製品として、統合ログ管理システムLogstorageをご紹介します。
Logstorageは、定期的にレポートを自動生成できる機能や、さまざまな軸でログの統計情報をグラフ化できる機能などを備えており、ログの分析作業を効率的に行うことが可能です。Logstorageの詳細については、以下ページをご覧ください。
>>Logstorage製品ページはこちらログ管理について一番多い質問
「何のログを取ったら良いか」、これがログ管理システムの構築を検討されている方から一番多く寄せられるご質問です。
これは単に「サーバアクセスログなのか?」「端末操作ログなのか?」「Webアクセスログなのか?」という事だけでなく、そのログを取る根拠となる、「基準」の設定も含めたご質問である事が多いと感じています。
個人情報保護、内部統制報告制度を背景としてログ管理のニーズが高まった数年前は、基準の設定から、ログ・データの収集管理までの一貫したコンサルティングを提供できる人材が少なかった事が、ログを溜めているだけ、という状況が蔓延してしまった一因でもあります。
しかし現在では、様々な事例を通してログ管理のノウハウを蓄積し、サービス提供する事業者も増えてきていますので、ログ管理を改めて考え直す環境は整ってきています。
