Windowsイベントログ取り込み方法をデータソースからログソースに移行する

Windows イベント ログは、システム アクティビティ、アプリケーションの動作、および環境全体のセキュリティ イベントを監視するのに役立ちます。既存の構成の多くは、従来の Windows イベント データ ソースを使用してログを取り込みます。ログ記録の要件が増加するにつれて、データ ソースのプロパティを介してイベント チャネル、フィルタ、およびリソース固有の構成を管理することがますます複雑になる可能性があります。

LogSource ベースの取り込みは、LogicMonitor で Windows イベント ログを収集するための推奨方法です。LogSource は、LogicMonitor ポータルで構成を一元化し、コレクター側のフィルタリングとリソース マッピングをサポートし、リソース プロパティへの依存度を低減し、従来の DataSource ベースの取り込みよりも一般的にシステム リソースの使用量を削減します。

この記事では、従来の Windows イベント データ ソースから Windows イベント ロギング ログ ソースへ Windows イベント ログの取り込みを移行する方法について説明します。このワークフローにより、可視性を維持し、移行リスクを最小限に抑え、移行プロセス全体を通してロールバック オプションを保持しながら、ログ収集を最新化できます。

Windowsイベントログの取り込み方法を移行するには、以下の手順が必要です。

1. 事前に構築されたLM LogSourceを使用するか、必要に応じて新しいLogSourceを作成して互換性を確保してください。
2. 両方の収集方法を並行して実行し、結果を検証する
3. レガシーデータソースを廃止する
4. リソースプロパティを更新する
5. 監査を実行する

Windowsイベントログの取り込みをデータソースからログソースに移行するための要件

Windowsイベントログの取り込みをデータソースからログソースに移行するには、以下のものが必要です。

• LogSourceの取り込みに対応するLogicMonitor Collectorのバージョン。LogSourceをLM Collectorで使用するには、EA Collector 31.200以降が必要です。
• リソースツリーに存在する、現在Windowsイベントログを収集している既存のWindowsリソース。
• 従来のデータソースによって現在収集されているWindowsイベントログチャネルの一覧です。この一覧は、新しいログソース構成を検証するための基準となります。
• コレクターサービスアカウントに対するWindows Management Instrumentation（WMI）アクセス権限、または構成済みのwmi.userおよびwmi.pass資格情報。
• リモートWindowsイベント収集を使用する環境では、Windowsリモート管理（WinRM）が有効になっています。
• セキュリティログの権限など SeSecurityPrivilegeセキュリティイベントログを収集するため。
• 現在Windowsイベントログ収集に使用されている従来のデータソースプロパティに関連するリソースプロパティのインベントリ。これには以下が含まれます。
  • lmaccess.id
  • lmaccess.key
  • lmlogs.winevent.channels
  • lmlogs.winevent.eventtypes
  • lmlogs.winevent.eventids.exclude
  • lmlogs.winevent.message_strings.exclude
  • lmlogs.winevent.detailed_message
• 変更を加える前に、既存のWindowsイベントログデータソース構成と、関連するリソースプロパティのスナップショットをエクスポートしてください。

Windowsイベントログのログソースを作成する

LogSourceを作成することは、ログ取り込みの移行における最初のステップです。これにより、新しい収集方法がログの取り込みを開始できるようになり、同時に従来のDataSourceは検証のためにアクティブな状態を維持できます。

1. LogicMonitorで、次の場所に移動します 設定 > ロジックモジュール.
2. 次のいずれかの操作を行います。
   • 　 ExchangeModule_Logsource_Windows ログソースから マイ モジュール ツールボックス利用できない場合 マイ モジュール ツールボックスインストール先 応募者と.
   • Windowsイベントログテンプレートを使用して、新しいログソースを作成します。
     詳細については、を参照してください。 Windows イベント ログのログソース構成.
     
3. 適切なリソースを対象とするように、AppliesToロジックを設定します。
4. 以下の手順を実行して、LogSource が従来の DataSource の動作と一致することを確認してください。
   • システム、アプリケーション、セキュリティなど、同じイベントログチャネルを含めてください。
   • DFSレプリケーションやディレクトリサービスなどの他のログを収集する必要がある場合は、追加のログソースを作成してください。
   • LogSourceのインクルードフィルターとエクスクルードフィルターを使用して、従来のDataSourceのフィルタリング動作を再現します。元のコレクションスコープと取り込み量を維持するようにフィルターを設定します。
   • コレクターの権限とアクセス権限が以前の設定と一致していることを確認してください。

ログソースを並列実行して収集を検証する

旧バージョンのデータソースを廃止する前に、両方の収集方法を並行して実行し、新しいログソースの構成を検証してください。

少なくとも24時間から48時間は、両方の方法でログの収集を続けてください。

以下に検証基準を示します。

• 想定されるすべてのWindowsリソースからログが届いています。
• 想定されるイベントログチャネルが表示されます。
• 該当する場合は、セキュリティログが収集されます。
• 想定されるイベントIDが存在します。
• 既存の包含フィルターと除外フィルターは、期待どおりに動作します。
• リソースマッピングは、ログを適切なリソースに関連付けます。
• 予期せぬ除外やデータ収集の欠落は確認されませんでした。
• イベントの総量は、従来のデータソースと同程度です。

LogSource のボリュームを評価するには、次のクエリを使用してください。

* | count by _lm.logsource_name | sort by _count desc

この期間中、データソースとログソースを通じて取り込まれるデータ量に差異があってはなりません。

検証中にログの欠落、リソースマッピングの問題、または予期しない取り込み動作が発生した場合は、廃止作業を進める前に、一般的なトラブルシューティング手順を確認してください。

詳細については、を参照してください。 Windows イベント ログの取り込みに関するトラブルシューティング.

データソースの廃止

検証が成功したら、旧データソースを廃止します。

1. 遺産を開く Windowsイベントログデータソース LogicMonitor ポータルで。
2. 「適用先」フィールド内の既存のロジックをコメントアウトしてください。
   具体的な例を挙げますと、以下の通りです。 /*isWindows() && lmlogs.winevent.channels && lmaccess.id && lmaccess.key*/
   
3. 廃止に関するコメントを追加してください。
   具体的な例を挙げますと、以下の通りです。 /* Deprecated in favor of WindowsEventLogs LogSource as of YYYY-MM-DD */
4. 選択 Save.
   このプロセスが完了した後も、データソースはロールバックまたは監査目的で利用可能です。

リソースプロパティの更新

リソースプロパティを更新することで、従来のログ収集構成への依存関係が解消され、LogSourceベースのアプローチへのスムーズな移行が保証されます。

LogSource の検証が完了し、従来の DataSource が廃止されたら、リソースまたはリソース グループから次のプロパティを削除します。

• lmlogs.winevent.channels
• lmlogs.winevent.eventtypes
• lmlogs.winevent.eventids.exclude
• lmlogs.winevent.message_strings.exclude
• lmlogs.winevent.detailed_message

監査の実施

監査を実施することで、移行が成功し、ログの取り込みが想定どおりに継続されていることを確認できます。

1. LogSourceが24時間から48時間ログを取り込むように設定してください。
2. ログインターフェースで、次のクエリを実行してログ量を評価します。

* | count by _lm.logsource_name | sort by _count desc

3. 従来のデータソースと新しいログソースの間で、関連するすべてのリソースにおけるログの量と分布を比較します。
4. コレクターのパフォーマンスを監視し、予期せぬ問題が発生していないことを確認してください。
5. データソースの設定（XMLまたはJSON形式）をアーカイブして、参照用に保管してください。
6. セキュリティチームやコンプライアンスチームなどの関係者に、移行が完了したことを通知する。

ロールバックが必要な場合は、従来のデータソースでAppliesToロジックを再度有効にし、必要なリソースプロパティを復元してください。

これにより、継続的な可視性と最小限の混乱で、管理された移行が保証されます。