ログ管理への取組みの分類
前回からの続きとなりますが、「個人情報保護法」「内部統制」がログ管理ツール導入の契機になったという説明をしましたが、勿論、ログはそれ以外の目的でも多く利用されています。特に、Webアクセスのログ分析などは、以前から多くの企業で実施され、マーケティングに有効に活用されています。
こうした使い方と分けて考えるため、下表にログ管理への取り組み方の分類をまとめます。
| 分類 | ログ管理への取組み内容 | 主な利用目的 |
|---|---|---|
| 規制対応型 | 政府の規制や関係者の要望等を受け、ログ管理を受動的な形で取組を行うもの。 ログはほぼ、溜められているだけである事が多い。 | 内部統制(IT全般統制)等、コンプライアンス対応としてのログ管理。 |
| 事後調査型 | 事故・障害が生じた際、その原因究明や早期復旧を目的としたログ管理の取組みを行うもの。 原因調査に必要なログに対する検索性などは事前に確認されている事が多い。 | システム運用や、情報漏えい対策として事後調査のためのログ管理。 |
| 機会追求型 | ログ分析を行う事を、新たなビジネスへの展開に有効と捉え、積極的に取り組みを行うもの。 分析方法はある程度確立されている。 | Webサイトへのアクセス分析などマーケティング活動への利用。 |
| 持続発展型 | 機会追求型を発展させ、コンプライアンス対応や局所的な活用に留まらず、 ログ分析を事業活動全体に活用する取り組みを行うもの。 | 現状、殆ど例は無い。 今後はビッグデータ分析等が発展し、こうした全社的なログ管理・活用が実現される可能性はある。 |
上記分類は、「企業の環境経営の取組姿勢（環境白書）」から一部使わせて頂いたもので、（エコなどの）「環境対応」と「ログ管理」は、直接的な経営へのプラスのメリットが見えにくく、「規制対応型」が先行するという意味で共通する面が多いかと思います。
基本的には、表の下に行くほどログの活用度が高いという事が言えますが、「[第1回] ログが活用できないワケ ～ログを溜めるだけになっていませんか？～」で説明した通りの理由で、多くの企業が「規制対応型」或いは「予防的対応型」に留まっているのが現状です。また、「規制対応型」「予防的対応型」にしても、実質的に意味のあるログ管理を行えていないケースも多く見られます。形式的な対応で監査をパスしたものの、何らか調査すべき異常・不正が生じた際、その原因調査に全くログが利用できなかった、というようなケースです。
今回、第3回、第4回では、意味のあるログ管理を行うために必要な点について説明していきますが、まずは、ログそのものの説明から進めていきたいと思います。
様々なログの種類
「ログ」という言葉から、思い浮かぶものは何でしょうか。
システムの運用を担当されている方であれば、サーバやネットワーク機器のシステムログなど、セキュリティを担当されている方であれば認証ログやデータベース等の監査ログやファイアウォールやIPS/IDSのログなど、Webマーケティングを担当されている方であれば、自社Webサイトへのアクセスログなどでしょうか。ログはITシステムの動作履歴ですから、業務の大部分をITシステムに依存する現代の企業では、様々な目的でログを収集しています。
下記に、ログの分類の一例を挙げます。
| 大分類 | 中分類 | ログの種類 | 主な対象 |
|---|---|---|---|
| 個人デバイス ※PC、携帯電話、スマートフォン | OS | 操作記録、設定変更記録、認証ログ | クライアントPC 用、モバイル、スマートフォン用 |
| アプリケーション | 操作記録、通話・通信記録、チェック記録 | Office、ブラウザー、メーラー、業務用ソフト、アンチウィルスソフト、 パーソナルファイアウォール、URL フィルタリング 他 | |
| サーバ | OS | 認証ログ、操作記録、SYSLOG、エラーログ | サーバOS |
| ミドルウェア | 認証ログ、操作記録、アクセスログ、エラーログ | Web エンジン、メールゲートウェイ、DBMS、アプリケーションサーバ | |
| アプリケーション | 認証ログ、操作記録、アクセスログ、エラーログ | FireWall、Proxy、VPN、IDS/IPS、リモートアクセスサーバ、Web アプリケーション、 ファイルサーバ、ディレクトリ、DHCP、メールボックス、 アンチウィルス（マルウェア対策）、DB、SFA、CRM、会計、人事 | |
| ネットワークデバイス ※ルーター、スイッチ、負荷分散装置、 無線ＬＡＮアクセスポイント | - | 操作記録、通信記録、アクセスログ | 独自ハードウェア、SNMP |
| 物理 ※監視カメラ、入退室、キャビネ閉開、 キーBOX、プリンター、RFID 関連 | - | カメラ映像、入退室記録、印刷ログ、ドア閉開記録他 | 独自管理サーバ |
ログには、実に様々ものがありますので、「何のためにログを管理するのか」を明確にした上で、何のログを管理するのか、絞り込んでいく必要があります。また、その中から具体的に何を得るのかを設定し、そのための “軸” を持つ事が重要になります。”軸” とは例えば、”閾値” や “範囲” を指します。よく、”コンプライアンス対応” と称するログ分析レポートで、「ログインの失敗履歴」を出力するようなものがあります。そのレポートには、1日に発生したログイン失敗ログのリストや、ユーザ毎のログイン失敗回数が出力されています。
このようなレポートから、どのような分析が出来るでしょうか。記録されているログそのものや、発生している回数だけを見ても、殆ど意味はありません。ここで見るべきポイントの例としては、「通常とは違う場所からアクセスされていないか？」や、「通常は人が居ない時間帯にアクセスされていないか？」「いつもより回数が異常に多くないか？」などです。こうした分析を行うために、「通常のアクセス元」「通常アクセスのある時間帯」「通常のアクセス回数」などの “軸” が必要である事がお分かり頂けるかと思います。そして、決めた “軸” との比較に必要な内容が、ログに記録されているかを確認し、それを管理していく必要があります。
ログの記録内容
それでは、具体的なログの内容を見てみましょう。ログの種類によって違いはありますが、アクセスログに記録される代表的な項目は下記になります。
| 概要 | アクセスログ (Windowsイベントログ) | アクセスログ (データベース) | アクセスログ (Webサーバ) | |
|---|---|---|---|---|
| いつ | そのアクションが発生した日時 | Wed May 26 14:36:24 | 2023-08-11T06:53:36 | 27/May/2023:00:32:47 |
| 誰が | そのアクションを行った人、機器 | YAMADA\yamada | DBS\Administrator | 192.168.0.1 |
| 何を | そのアクションが何に対して行われたのか | C:\WINDOWS\explorer.exe | EMP | www.logkatsu.com/index.html |
| どこで | そのアクションがどこで行われたか | (そのログが発生したサーバ名・IPアドレス) | (そのログが発生したサーバ名・IPアドレス) | (そのログが発生したサーバ名・IPアドレス) |
| どうやって | そのアクションが、どのように行われたか | オブジェクト アクセスの試行 | select * from EMP; | GET /index.html |
| どうなった | そのアクションの結果はどうだったか （成功／失敗／エラーコードなど） | 成功の監査 | 0 (成功) | 200 (成功) |
次に、上記表に対応する、実際の生のログを見てみましょう。
Windowsイベントログ
Security[567]: [53558, 成功の監査, Wed May 26 14:39:18, YAMADA\yamada, YHAMADA] オブジェクト アクセスの試行: オブジェクト サーバー: Security ハンドル ID: 4612 オブジェクトの種類: File プロセス ID: 1820 イメージ ファイル 名: C:\WINDOWS\explorer.exe アクセス マスク: ReadData (または ListDirectory)Webサーバアクセスログ
192.168.0.1 - - [27/May/2023:00:32:47 0900] "GET /index.html HTTP/1.1" 200 60276 "https://logstorage.com/" "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"データベースアクセスログ
4429496729557
2023-08-11T06:53:36.937000Z/DBS\Administrator
DBS\AdministratorWORKGROUP\DBS1432:600
00SYSDBA1278573858 select * from EMP
ログ分析を本職にしていない限り、「いつ」「誰が」「何を」「どこで」「どうやって」「どうなった」といった情報が、ログの中のどの部分に記録されているかは直ぐには分からないと思います。このように、ログの形式はシステムや機器ごとにバラバラで、更に、このようなログがITシステム上のあちこちに点在して保存されています。
ログ管理を簡潔に説明すると、「点在するログを一元的に、必要な情報と共に管理し、各ログの形式を理解した上で、”軸” と比較する」という事になります。 そのために、まずは下記の問題点を認識し、解決していく必要があります。
問題点① ログは点在している
ログが点在している事は、下記の問題があります。
- ログの追跡が困難
ITシステム上での人の動きやデータの流れを追跡するためには、異なる複数のログを繋ぎ合わせて確認する事が必要になります。例えば、あるサーバ上で何らかの異常が生じた際、その原因調査のために、「サーバ自身のアクセスログ」「サーバに接続していた端末のアクセスログ」「サーバが置かれているマシンルームの入退室ログ」など、様々なログを調査する事があります。 そうした際、ログが点在したままでは、追跡調査は極めて困難です。
- ログの保存期間が統一できない
各サーバ・機器上にそのままログを保存する方法では、保存する期間は各サーバ・機器が持つ機能や、ストレージの大きさに依存する事になります。特にネットワーク機器などは、長期間のログを保管する為の領域を持っていない事が多く、短期間でログが捨てられる事もあります。これは、先に説明したログの追跡を更に困難にします。
- ログの改ざんに対して無防備
悪意を持った人物によってITシステム上で何らかの不正が行われた場合、その痕跡を残さない為に、ログが改ざん・削除される事もあります。各サーバ・機器上にそのままログを保管する方法では、このログの改ざん・削除に対しては無防備です。
こうした問題に対し、統合ログ管理ツールを導入して対応する企業が増えています。統合ログ管理ツールは、「ログの一元化」「ログの圧縮による長期保管」「ログの暗号化・改ざん検出」の他、様々なログの分析機能を持っており、ログ管理の負担を大幅に軽減します。
問題点② ログの形式がバラバラ
残念ながら現在、ログの形式に関する共通的なルールはほぼ無いと言って良く、各製品やアプリケーションがそれぞれ独自の形式でログを出力しています。更にそれらのログの中には、ユーザが読むことを意識して出力されていないものも多くあります。そのため、ログを管理する際は下記を意識する必要があります。
- ログの内容が理解出来る形で管理する
- 必要に応じて情報を付加して管理する
「規制対応型」の場合、単に発生したログをそのまま溜め込んでいるというケースも多く見られ、その場合、いざログを活用しようとしても、それは極めて困難であると言えます。
このログ形式の問題に対して、具体的にどう対応すべきかは次回、第3回でご説明します
