世の中に溢れる読めないログ
なぜログを取っておくのか、それは言うまでもなく、それを読み、何かを見つけ、必要な対策を取るためです。しかし残念な事に、多くのログは人間がそのまま読める形では記録されておらず、発生したままのログを保管しても多くの場合、あまり役には立ちません。
また現状、ログの分析はできているとする企業でも、特定の担当者のスキルによってカバーされているいわゆる「ログ管理の属人化」が進んでおり、その担当者が居なくなったらログの分析が行えなくなる、という状況も多いと思われます。このような状況を踏まえ、ログ管理を継続して、適切に行っていくためには、下記について強く認識しなければなりません。
- ログはそのままでは読めない、追えない。（ログを人間が読み、追える形で管理する）
- ログに必要十分な情報は記録されていない。（ログに必要な情報を足して管理する）
これを意識して管理を進めなければ、ログは「宝の山」などではなく、「ゴミの山」と化してしまいます。
それでは、人間が正しく読むことができ、追うことができ、必要な情報を記録する「ログ管理」の方法について、ここでは具体的な話をするために、統合ログ管理システムLogstorageを例にご説明します。
ログが追えない
例えば、何らかの問題が発生し、ITシステム上での特定ユーザの行動を追跡する事を考えてみます。前回ご説明した通り、ログはシステム、機器、アプリケーション毎に形式が大きく異なり、下記のように出力されます。
入退室管理システム
1,カード認証OK ,2023/11/29 08:56,000500 鈴木 一郎,ｶｰﾄﾞ操作記録,ｶｰﾄﾞ:施解錠状態,(01011001)(扉1-1),解錠 入室認証システム
2023/11/29 08:58:27,2131,0,suzuki,192.168.0.1,PC01,192.168.111.124,,Windowsにログオンしました。メールシステム
Nov 29 07:15:57 192.168.0.100 qmail: [ID 748625 mail.info] 1239747357.775176 info msg 322844: bytes 15515 from <suzuki@example.com> qp 2924 uid 7791データベース監査システム
"ora104","192.168.0.1",“domain1\suzuki","ROOT","ORACLEDBCOLLECT",28,"localhost.localdomain","",10,29177,"Query",
"2023-11-29 13:04:10","2023-11-29 13:04:10",0,"2023-11-29 13:04:10",1,0,0,2,2,223,486,"select * from user where userid=‘admin' and password="*****“…上記、赤字部分が各ログ上の「suzukiユーザを一意に識別するキー」を表しています。
このように、ユーザIDの記録のされ方はシステムによってバラバラですので、これらログを単に保管するだけでは、ログの追跡を行う事は極めて困難である事がお分かり頂けるかと思います。
この問題への対処方法は幾つかありますが、下記の図が、「統合ログ管理システムLogstorage」による解決方法です。この方法は、IDの違いを吸収するために「共通IDマスタ」を用意し、ログ収集対象毎のIDに対応する「共通ID」をログに付与します。
ここで付与した「共通ID」を利用して、ユーザID「suzuki」で検索する事で、ユーザの行動が追跡できるという仕組みです。
「ログの追跡性」を確保するためには、こうした「必要な情報をログに足す」という発想が必要です。
ログが読めない その１ ～解析しなければいけないログ～
Windowsイベントログを収集・管理されるケースは非常に多くありますが、Windowsイベントログ（特にファイルアクセスログ）は、読めないログの代表的なものです。
下記は、監査設定を有効にした上で、1つの Excel ファイルをオープンした際に出力されるイベントログの例です。実際にはこのようなログが1アクセス毎に、10行以上記録されます。
Security[560]: [58771, 成功の監査, Thu Nov 29 09:03:59, OHASHI2\ohashi, OHASHI2] オブジェクトのオープン:
オブジェクト サーバー: Security オブジェクトの種類: File オブジェクト名: D:\共有フォルダ\顧客リスト.xls
ハンドル ID: 2628 操作 ID: {0,1886682} プロセス ID: 920 イメージ ファイル名: C:\WINDOWS\explorer.exe プライマリ ユーザー名: ohashi
プライマリ ドメイン: OHASHI2 プライマリ ログオン ID: (0x0,0x119CA) クライアント ユーザー名: - クライアント ドメイン:
- クライアント ログオン ID: - アクセス READ_CONTROL SYNCHRONIZE ReadData (または ListDirectory) ReadEA ReadAttributes 特権 - 制限された SID 数: 0
Security[560]: [58772, 成功の監査, Thu Nov 29 09:03:59, OHASHI2\ohashi, OHASHI2] オブジェクトのオープン:
オブジェクト サーバー: Security オブジェクトの種類: File オブジェクト名: D:\共有フォルダ\顧客リスト.xls
ハンドル ID: 2560 操作 ID: {0,1886683} プロセス ID: 920 イメージ ファイル名: C:\WINDOWS\explorer.exe プライマリ ユーザー名: inamura
プライマリ ドメイン: OHASHI2 プライマリ ログオン ID: (0x0,0x119CA) クライアント ユーザー名: - クライアント ドメイン:
- クライアント ログオン ID: - アクセス READ_CONTROL SYNCHRONIZE ReadData (または ListDirectory) ReadEA ReadAttributes 特権 - 制限された SID 数: 0マイクロソフト社より、上記ログをどのように監査すれば良いか、その方法に関するガイド（「サーバ製品のログ監査ガイド」）が公開されていますが、1つの事象を追うために幾つものログをチェックしなければならず、この手順通りに行うのは現実的ではありません。
そのため、現在はこの複雑なイベントログを解析し、「１アクセス＝１ログ」に近い形に翻訳してくれるツールが幾つか販売されています。
https://logstorage.com/elc-analytics/
また、ご興味のある方は、マイクロソフト社の「サーバ製品のログ監査ガイド」をご覧下さい。分かり易くまとめられた内容ではありますが、同時に、セキュリティイベントログの追跡の複雑さがお分かり頂けるかと思います。
https://wp.techtarget.itmedia.co.jp/contents/3058
今回挙げたWindowsサーバのログ以外にも、ストレージのアクセスログなども解析が必要です。基本的なところではありますが、まずは、現在自社で収集しているログの内容が理解できるかどうか、チェックして見て下さい。
ログが読めない その２ ～変換・情報付与しなければいけないログ～
解析が必要なログ以外で、下記に、そのままではログが読めない代表的なケースを挙げます。
| 大分類 | 中分類 | ログの種類 | 主な対象 |
|---|---|---|---|
| 個人デバイス ※PC、携帯電話、スマートフォン | OS | 操作記録、設定変更記録、認証ログ | クライアントPC 用、モバイル、スマートフォン用 |
| アプリケーション | 操作記録、通話・通信記録、チェック記録 | Office、ブラウザー、メーラー、業務用ソフト、アンチウィルスソフト、 パーソナルファイアウォール、URL フィルタリング 他 | |
| サーバ | OS | 認証ログ、操作記録、SYSLOG、エラーログ | サーバOS |
| ミドルウェア | 認証ログ、操作記録、アクセスログ、エラーログ | Web エンジン、メールゲートウェイ、DBMS、アプリケーションサーバ | |
| アプリケーション | 認証ログ、操作記録、アクセスログ、エラーログ | FireWall、Proxy、VPN、IDS/IPS、リモートアクセスサーバ、Web アプリケーション、 ファイルサーバ、ディレクトリ、DHCP、メールボックス、 アンチウィルス（マルウェア対策）、DB、SFA、CRM、会計、人事 | |
| ネットワークデバイス ※ルーター、スイッチ、負荷分散装置、 無線ＬＡＮアクセスポイント | - | 操作記録、通信記録、アクセスログ | 独自ハードウェア、SNMP |
| 物理 ※監視カメラ、入退室、キャビネ閉開、 キーBOX、プリンター、RFID 関連 | - | カメラ映像、入退室記録、印刷ログ、ドア閉開記録他 | 独自管理サーバ |
上記のケースに対して、またログの活用を進める上で必要なのは、現在記録されているログだけで何とかしようとせず、ログに記録される項目と内／外のデータをリンクし、ログの価値を向上させるという発想です。
「統合ログ管理システムLogstorage」は下の図のように、ログを収集する際に様々なデータをログに足し、利用し易い形で保管することができます。
例えば、最近流行している外部のストレージサービスへのアクセス監視を行いたいという話が増加しています。ストレージサービスは海外を中心に乱立している状況ですので、企業のシステム担当者が全てのストレージサービスを調査し、全てのURLをチェックする事は現実的ではありません。そこで、外部のデータベースを利用する事になります。繰り返しになりますが、「必要な情報をログに足す」という考え方を持つことによって、ログの活用の範囲は大きく広がります。
次回、ログをどう見るのか
今回は、正しく読むことができ、追うことができ、必要な情報を記録するためのログ管理の方法についてご説明しました。ただ、今回ご説明した内容を、全てのログに対して行う必要はありません。あくまで、必要なケースでのみ、実施する事になります。
「必要なケース」とは何か、簡単に言えば、「ログをどう見るのか」「ログから何を見つけるのか」を明確にして、「見つけるために必要な情報を足す」という事になります。
次回は、「ログをどう見るのか」「ログから何を見つけるのか」を中心にご説明します。
