Windowsイベントログは、管理者が潜在的なシステムの問題を調査および診断するために不可欠なツールですが、実際の価値を獲得し、ノイズの多い重要でないアクティビティから有用なログエントリを分離することも困難な作業になる可能性があります。 役立つログのレベルに応じて、Windowsイベントは、システムの問題、アプリケーション固有の問題にまたがり、不正アクセス、ログインの失敗、異常な動作に関するセキュリティタイプの問題に飛び込む可能性があります。 管理者は、チャネル、ログレベル、およびデータを表示するためのレンズの概念を理解して、このデータを日常のトラブルシューティングや根本原因分析に役立てる必要があります。
今日の議論では、Windowsシステム管理者のレンズを使用して適用します Windowsイベントログ システム障害、パフォーマンスの問題、停止につながる構成の問題、またはサービスの中断の根本原因を特定するため。
ノイズ対価値
ノイズ対値の主題に関して私が最もよく耳にするコメントは、ログの99％が検索または使用されないということです。 これはほとんど真実だと思いますが、人々が通常ログを使用する方法のために強化されています。これは、問題や停止が発生し、ログが必要悪になるまでログを回避します。 ほとんどのロギングベンダーは取り込みに基づいて請求するため、ログコンシューマーは、繰り返しの監査成功イベントを除外したり、すべての情報レベルのログを削除して警告、重大、およびエラーのログのみを保持したりするために多大な労力を費やします。 これらはすべて、取り込みとコストを削減するだけでなく、構成変更のダークスポットの可視性も低下させます。 構成の変更は、今日のITのすべての停止の40％に関連しており、ほとんどの場合、さまざまなログソースに情報レベルとして書き込まれています。 Windowsも例外ではなく、これらの「ノイズの多い」イベントの多くが情報チャネルに書き込まれます（チャネルについては今後さらに詳しく説明します）。
AI、機械学習、そして 異常検出 問題が発生するまで検索されないログの99％の値を増やすことができます。 異常検出を使用して構成変更ログまたは情報レベルのログをスキャンすると、対処または認識できる新しい動作に関する実際の洞察を示すことができます。 これは、そもそも停止を回避し、サービスが中断した場合に問題をより迅速に解決するのに役立ちます。 エラー、警告、およびクリティカルレベルのログのみを取り込んで保持している場合は、99％から取得できるプロアクティブな値を見逃しています。
一元化して集約
Windowsイベント管理戦略の最初のステップは、環境全体からこれらのログを一元化してXNUMXつの場所に集約することです。 保持時間はユースケースによって異なりますが、それらを中央で検索可能にすることが成功の鍵です。
Windowsイベントは、各Windowsサーバーにローカルに配置されます。つまり、適切なサーバーを適切なタイミングで取得するためだけに、かなりの付加価値のないエンジニアリング時間が必要になる可能性があります。 付加価値のないエンジニアリング時間とは、技術者または管理者がシステムへの接続、ログファイルのダウンロード、検索、または分析とトリアージを実行する前に必要なタスクの解析に費やす時間です。 統合するにはさまざまな手段がありますが、ここでは、ログの取り込み手段が整っており、会話をノイズ対値、および消費するログの種類に移すことができると想定します。
イベントチャネルとは何ですか？
チャネルは基本的に、イベントタイプを分類するバケットです。 それらをカテゴリに分類すると、収集、検索、および表示が容易になります。 多くのWindowsベースのアプリケーションは、Microsoftの事前定義されたチャネルのXNUMXつにログインするように構成されていますが、アプリケーションが独自のチャネルを作成していることもわかります。 システム管理者の目を通してWindowsイベントログを監視し、トラブルシューティングを行うためのベストプラクティスのアプローチは、アプリケーション、システム、およびセキュリティチャネルからログを取り込むことです。 ただし、システムにインストールされている機能やその他のアプリケーションに基づいて、多くの追加チャネルが存在する可能性があります。 管理者のPowerShellプロンプトからのクイックPowerShellコマンドを使用すると、問題のシステムで使用可能なチャネルのクイックリストを表示できます。
PowerShellに次のコマンドを入力します。
# to see channels listed in the standard order
Get-WinEvent -ListLog *
# to sort more active channels to the top of the list
Get-WinEvent -ListLog * | sort RecordCount -Descending
# to see channels present on a remote computer
Get-WinEvent -ListLog * -ComputerName <hostname>出力には、チャネルのリストと、それらのチャネルに現在含まれているイベントレコードの数が含まれます。
LogMode MaximumSizeInBytes RecordCount LogName
------- ------------------ ----------- -------
Circular 20971520 59847 Application
Circular 20000000 29339 Microsoft-Windows-Store/Operational
Circular 20971520 21903 Security
Circular 4194304 10098 Microsoft-Windows-GroupPolicy/Operational
Circular 5242880 9568 Microsoft-Windows-StateRepository/Operational
Circular 15728640 7066 Windows PowerShell
Circular 5242880 4644 Microsoft-Windows-AppXDeploymentServer/Operational
Circular 8388608 4114 Microsoft-Windows-SmbClient/Connectivity
Circular 1052672 2843 Microsoft-Windows-EapHost/Operational
Circular 1052672 2496 Microsoft-Client-Licensing-Platform/Admin
イベントの種類
チャネルを定義したので、Microsoftによって事前設定されたイベントタイプについて説明し、それらを各チャネルに適用します。 マイクロソフトは、イベントタイプを情報、エラー、警告、重大、セキュリティ監査の成功、およびセキュリティ監査の失敗に分類しています。 ここで最初に注意することは、イベントタイプのセキュリティ監査の成功とセキュリティ監査の失敗はセキュリティチャネルにのみ適用され、セキュリティチャネルにのみ存在することです。 注意すべきもうXNUMXつの重要な項目は、すべてのセキュリティイベントがセキュリティチャネルに書き込まれるわけではないということです。 セキュリティ関連のイベントは、システムまたはアプリケーションチャネル、あるいはシステム上に存在する可能性のあるその他の機能固有のチャネルに書き込むこともできます。
OpsとSIEMのWindowsイベント
従来、SIEMは、デバッグレベルのログを除いて、すべてのログとログタイプを要求します。 これは、コストが法外な要因ではない完璧な世界で機能する可能性がありますが、ほとんどの企業は無制限の資金を持っておらず、除外しています。 上記のように、セキュリティタイプのイベントはチャネル間で書き込むことができます。 SIEMは通常、これらすべてのチャネルからログを取得する必要がありますが、多くの場合、コスト削減方法として情報レベルのアラートを除外します。
運用の観点からの典型的なスタンスは、セキュリティチャネルが取り込みから除外されることが多いというものです。 上で述べたように、情報レベルのアラートは、特に異常検出のアイデアが適用される場合、運用スタッフにとって非常に価値があります。
ベストプラクティス
上で概説した通常のアプローチは価値を提供しますが、LogicMonitorのベストプラクティスアプローチは、これらのログから追加の価値を取得する上でもう少し進んでいます。 任意のチャネルを取得することをお勧めしますが、運用チームであっても、アプリケーション、システム、およびセキュリティチャネルから始めることをお勧めします。 ここでの重要なチャネルはセキュリティチャネルです。 取り込むイベントタイプを定義することが不可欠であり、推奨されるアプローチは、任意のチャネルで情報レベル以上のログイベントを受け入れることです。 これは、セキュリティチャネルを含むすべてのチャネルの情報、警告、エラー、および重大なイベントのイベントタイプを取り込むことを意味します。 運用チームのセキュリティイベントを取得する理由と、監査成功ノイズの一部を調整する方法についてもう少し詳しく見ていきましょう。
セキュリティチャネルは、最大のイベント量と最大の話者を引き継いでいます。 さらに調査すると、それがセキュリティ監査の成功イベントタイプであることが圧倒的にわかります。 セキュリティ監査の成功は非常におしゃべりであり、基本的に、誰がどこで/いつログインしたか、何にアクセスしたか、予想される動作の記録を提供します。 このレベルのログは、セキュリティ分析の調査に役立つ場合がありますが、故障/修正タイプのトリアージで役立つことや使用されることはめったにありません。 これは、セキュリティ監査の失敗とコインの裏側につながります。 セキュリティ監査の失敗は、アクセスの失敗またはログインの失敗を示し、攻撃またはハッカーの活動の最初の指標となる可能性のある疑わしい活動を示している可能性があります。 上記のいずれかまたはすべてが、運用チームとセキュリティチームの両方に影響を与えるより大きな問題につながる可能性があります。
ここでイベントタイプとベストプラクティスをまとめるためのもうXNUMXつの考えは、デバッグレベルのログです。 デバッグレベルのログは、特定のユースケースが発生し、一時的にオンにして詳細なトリアージを支援する場合に役立ちます。 これらのアドホックな場合にのみ使用する必要があります。
LMログで反応するよりも積極的になる
LogicMonitorの LMログ 機能とベストプラクティスアプローチを組み合わせることで、Windowsイベントログを単一の検索可能なガラス板に迅速かつ効率的に集約するための、優れた賢明なアプローチがお客様に提供されます。 適切なレベルのログを収集して、Windows管理者がより良いMTTRを実現できるようにし、問題のトリアージ中に根本原因分析を使用し、異常検出を使用してログのプロアクティブな使用を促進し、より大きな問題につながる可能性のある異常な動作や変更をキャッチします。道。 これらは、Windowsイベントログの課題のいくつかに対処するLMログのほんの一部の機能です。
- 既存のLogicMonitor監視インフラストラクチャと既に配置されているコレクターを使用して、WMIを介してLMログを簡単に取り込むことができます。
- ログをサーバーメトリックと組み合わせて、XNUMXつのガラス枠でより詳細なビューを表示します。
- 毎日、毎週、または毎月の異常レビューセッションは、異常な動作に関する貴重な洞察を得るのに役立ちます。
- LM Logs DataSourceを使用してチャネルを定義し、個々のサーバーまたはサーバーグループレベルでプロパティを適用するための直感的でシンプルな手段。
- キーワード、eventID、または正規表現を使用して特定の条件でアラートをトリガーします。
- データソースプロパティを使用して、EventID、イベントタイプ、またはメッセージ文字列で繰り返しイベントをすばやく除外します。
オンデマンドウェビナーをご覧ください LMログが、チームがトラブルシューティングを減らし、ITワークフローを合理化し、制御を強化してリスクを軽減するのにどのように役立つかについて詳しく学びます。