イベントログの基礎から実務運用まで：時刻同期・正規化・SIEM活用で守るセキュリティと監査
エバープレイ編集部イベントログとは — 基本定義と重要性
イベントログは、OS・アプリケーション・ネットワーク機器が動作中に発生した事象（イベント）を時系列で記録する仕組みです。システムの健全性確認、障害対応、セキュリティ監査、フォレンジック、法令遵守（コンプライアンス）など、多用途で使われます。ログには「いつ」「どのプロセスやユーザーが」「どのような操作（結果）」を行ったかが残り、問題発生時の原因追及や攻撃の追跡に不可欠です。
イベントログの構成要素
- タイムスタンプ：イベント発生日時（時刻同期が重要）
- ソース／プロバイダー：どのアプリやサービスが発生させたか
- イベントID／コード：事象を分類する識別子（例：Windowsの4624は成功したログオン）
- レベル／重大度：情報（Informational）、警告（Warning）、エラー（Error）、監査（Audit）など
- ユーザー／SID：操作を行ったユーザーやアカウント識別子
- プロセスID、スレッドID、ホスト名、IPアドレス 等：付随するコンテキスト情報
- メッセージ／詳細：人が読める説明文や追加データ
主要プラットフォーム別の特徴
Windows
Windowsでは「Windows Event Log（イベントログ）」が標準で提供され、代表的なログ種別に Application、System、Security、Setup、ForwardedEvents などがあります。ログはバイナリ形式（.evtx）で、既定の保存先は C:\\Windows\\System32\\winevt\\Logs\\ です。閲覧・検索は Event Viewer（eventvwr.msc）や PowerShell の Get-WinEvent、wevtutil コマンドで行います。
重要なセキュリティ監査用イベントIDの例：
- 4624 — アカウントのログオン成功
- 4625 — アカウントのログオン失敗
- 4634 — アカウントのログオフ
- 4688 — 新しいプロセスの作成
- 1102 — 監査ログが消去された（イベントログクリア）
Linux / Unix 系
従来は syslog（rsyslog、syslog-ng 等）が広く使われ、/var/log/ 以下にメッセージをテキストで保存します。近年は systemd を採用するディストリビューションで journal（systemd-journald）が利用され、バイナリ形式で格納されます（/var/log/journal または /run/log/journal）。監査（セキュリティ）処理には auditd（Linux Audit Framework）を利用することが多く、より詳細な syscall レベルの記録が可能です。
ログのフォーマットと標準化
イベントログはベンダーやアプリごとに形式が異なるため、中央集約や相関分析の前に正規化（フィールドを統一）することが重要です。一般的なフォーマットや規格には次のものがあります：
- RFC 5424 — Syslog プロトコルの標準フォーマット
- CEF（Common Event Format）や LEEF — セキュリティ製品向けの共通フォーマット
- JSON / GELF — ログ収集基盤（Elastic, Graylog 等）で扱いやすい構造化フォーマット
ログ収集・中央集約・SIEM
ログの有効活用には中央収集が必須です。エージェント（Filebeat、Winlogbeat、NXLog、Fluentd など）を各ホストに導入してログを転送し、Elastic Stack、Splunk、QRadar 等の SIEM に集約・インデックス化して検索・相関・可視化・アラートを行います。Windows 固有の仕組みとしては Windows Event Forwarding（WEF）を使ったイベント収集もあります。
時刻同期（NTP/Chrony）の重要性
ログの時刻がバラバラでは事象の時系列解析ができません。NTP（または Chrony）で全サーバ・ネットワーク機器の時刻を一貫して保つことは、インシデントレスポンスやフォレンジックの前提条件です。
保存・保持ポリシーとローテーション
ログは無制限に蓄積できないため、保存期間・保存先（オンプレミス、クラウド、WORM ストレージなど）、ローテーション（logrotate、journald の保持設定）、バックアップ、アーカイブ方針を定めます。法令や業界規格によっては一定期間の保持が求められる（例：金融、医療など）。
改ざん防止と整合性
- リモートでの集中保存によりローカルでの改ざんリスクを軽減する
- 書込み禁止（WORM）ストレージやログ署名、ハッシュを用いた整合性検証
- 監査ログへのアクセス制御と監査トレイルの確保
- イベントログ消去（例：Windows のイベント 1102）に対する検知ルールを設定
プライバシーと法的配慮
ログには個人情報（ユーザー名、IP、操作履歴など）が含まれるため、収集・保持・閲覧はプライバシー法（GDPR 等）や内部ルールに準拠して行う必要があります。不要な個人情報はマスキングや最小化の検討を行います。
運用上のベストプラクティス（チェックリスト）
- 重要なログ（セキュリティ、認証、プロセス作成、権限変更、設定変更など）を確実に収集する
- 全ホスト・機器の時刻を NTP/Chrony で同期
- ログを中央集約し、長期保管および検索可能にする（SIEM の導入）
- ログの保持期間とローテーションを定める（法令・業務要件に基づく）
- 可視化とアラートルールを設定し、閾値や異常行動で通知する
- ログの改ざん検知（ハッシュ、署名、WORM）と、ログ削除アクティビティの監視
- 権限管理：ログ閲覧・削除は最小権限で運用
- 定期的にログポリシーと収集の妥当性をレビュー
インシデント対応時のログ活用フロー（概要）
- 検知：SIEM や IDS で異常を検知
- トリアージ：該当ホスト・ユーザーの関連ログを収集（周辺機器、ネットワーク機器、クラウドログ含む）
- タイムライン作成：時系列でイベントを連結して因果関係を把握
- 根本原因分析：プロセス、コマンド、アクセス元、脆弱性を特定
- 証拠保全：該当ログのエクスポート、ハッシュ化、アクセスログの記録（チェーン・オブ・カストディ）
- 対策と復旧：封じ込め、駆除、パッチ適用、再発防止策の実施
- 報告と教訓化：対応レポートを作成し運用に反映
よくある課題と対策
- ログ量が膨大：ログフィルタリング（重要イベントに絞る）、集約・圧縮、コスト効率の良い長期保管を設計
- 異なるフォーマット：正規化レイヤーを用意し、マッピングルールを整備
- 誤検知・ノイズ：ベースライン分析とチューニングでアラート精度を改善
- 暗号化・転送の問題：TLS 等で転送経路を保護し、認証付きで受け渡し
まとめ
イベントログは単なる運用記録ではなく、セキュリティ、監査、障害対応に不可欠な証拠基盤です。適切な収集・時刻同期・中央管理・正規化・保存ポリシー・改ざん防止を設計・運用することで、効率的な監視と信頼性のあるインシデント対応が可能になります。導入にあたっては業務要件と法的要請を踏まえた設計が重要です。
参考文献
- Microsoft Docs — About Event Logs
- Microsoft Docs — Audit Logon Events (4624, 4625 など)
- Microsoft Docs — Windows Event Forwarding
- NIST Special Publication 800-92 — Guide to Computer Security Log Management
- RFC 5424 — The Syslog Protocol
- systemd-journald — documentation
- rsyslog — Documentation
- Elastic — Filebeat / ログ収集の概要
投稿者プロフィール
