Windows PCのイベントログを無料で特定のPCに転送・収集・管理する方法
2018/04/26
本エントリーの目次
イベントログを特定のPCやサーバーに転送・収集して管理したい！
システム管理者の方など、職場で複数のWindows PCを管理している立場の方の中には、Windows PCのイベントログを特定のPCやサーバーに転送・収集して管理したい！
こう考えている方もいらっしゃると思います。
クライアントPCのイベントログを特定のPCやサーバーに転送・収集して一元管理することで、各PCのイベントログを確認する際、ログを収集・保持しているPCやサーバーにログオンすれば、各PCのイベントログを確認できるようになります。
そのためいちいち各PCにローカルまたはリモートログオンしてイベントログを確認する必要がなくなり、管理の手間が軽減されることでしょう。
またISMS(JIS Q 27001)などの認証を取得する場合、ログ取得及び監視が必要になることがあります。
こういった理由からWindows PCのイベントログを特定のPCやサーバーに転送・収集して管理したい場合、少しネットで調べていただければ分かると思いますが、方法はいくつもあります。
たとえば有償のイベントログ収集専用のソフトウェアを使う。
あるいは有償のクライアントPC管理ソフトウェアの機能の一つとして提供されているものを使う、自作のプログラムでログを収集するなどでしょうか。
有償のソフトウェアを使えば簡単にログの収集や転送、管理ができると思いますが、ネックは価格でしょう。
イベントログの転送・収集・管理機能を提供する有償のソフトウェアは、1ライセンスの価格が結構高いことが多いんですよね。
しかも多くのケースでは、イベントログの収集対象(収集される側)であるクライアントPCの台数が多いため、イニシャルコストもランニングコストもそれなりの費用になるはず。
自作のプログラムで対応する場合でも、仕様検討や技術調査、実装、動作検証にはそれなりの工数が必要です。
また、多数のクライアントPCにエージェントプログラム(ログの収集を行うプログラム)を配布する手間もかかります。
だからこちらの方法でも、それなりの費用がかかるんじゃないでしょうか。
そこで今回は、無料で利用でき、手間がほとんどかからないイベントログの転送・収集・管理機能を導入する方法をご紹介します！
はじめに
本エントリーでご紹介しているイベントログの転送・収集・管理機能は、Windows 8.1やWindows 10などのクライアントOS、Windows Server 2012 R2などのサーバーOSの標準機能として搭載されているWindowsの機能を利用しています。※
そのため別途有償のソフトウェアを購入する必要がないことから、無料で利用できると表現しています。
ですがWindows OSやWindows Server OSのライセンスはもちろん必要であり有償となっていますこと、あらかじめご了承ください。
※あまり知られていませんが、実は今時のWindows OSであればイベントログを転送・収集・管理を行う機能が標準で搭載されています。(XPやServer 2003の世代以前のWindows OSでは中核機能であるWinRMが規定ではインストールされていないことがあります。)
本エントリー記載の内容は、Active Directory制御下にあるPC群を使用し、ログを収集・保持するサーバー(コレクター)にWindows Server 2012 R2 Standard Edition、ログの収集対象(収集される側・ソース)であるクライアントPCにWindows 10 Professional 1703を使用して動作確認をしています。
ワークグループ環境でもこの機能の利用は可能ですが、これから紹介する作業手順を行った後に追加の作業が必要となる。
また一部機能に制限がかかるなどの違いがあります。
これについての詳細は、MicrosoftさんのTechNetに記載されているので、本エントリーの内容と併せて参照ください。
また上記Windows OSよりも古いOSを使っている場合、本エントリー記載の手順と一部が異なり、追加プログラムのダウンロードやレジストリの編集が必要になるケースがあります。
WinRMサービス・Wecsvcを利用したイベントサブスクリプションによるイベントログの転送・収集・管理の設定方法
今回ご紹介するイベントログの転送・収集・管理には、WindowsのWinRM(Windows Remote Management ＝ Windows リモート管理)サービス※と、Wecsvc(Windows Event Collector Service ＝ Windows イベント コレクター サービス)を利用したイベントサブスクリプションという機能を使います。
イベントサブスクリプションによるイベントログの転送・収集・管理を行う場合、イベントを収集される側とイベントを収集する側の双方に設定が必要となります。
イベントを収集される側とイベントを収集する側についてはソース/コレクター、クライアント/(ログ)サーバーなどいくつかの呼び方がありますが、本エントリーではMicrosoftさんのTechNetと同様にそれぞれソース、コレクターと表記します。
それではまずはソース側の設定からご紹介しましょう！
※WinRMについての詳細は、Windows リモート管理 (WinRM) の概要にくわしく書かれているので、興味がある方は併せてご覧ください。
ソースコンピューター(イベントを収集される側のPC)の設定
ソースコンピューター(イベントを収集される側のPC)にログオンし、管理者権限でPowerShellを起動して以下のコマンドを実行します。
1 | winrm quickconfig -force |
-forceパラメーターを付与することで、メッセージによる確認をせずに、ファイアウォール例外を有効に設定してくれます。
またquickconfigの部分をqcと書き換えた以下のコマンドを実行しても構いません。
1 | winrm qc -force |
このコマンドを実行することにより、WinRM(Windows Remote Management ＝ Windows リモート管理)サービスが遅延自動開始に設定され、ファイアウォールがWinRMの通信を阻害しないように例外設定されます。
尚、コマンドを実行後に以下のようなメッセージが表示される場合は、すでにWinRMサービスについて適切な構成が行われています。
1 2 | WinRMサービスは、既にこのコンピューターで実行されています。 このコンピューター上でのリモート管理には、WinRMがすでに設定されています。 |
次にソースコンピューターのAdministrators ローカルグループに、コレクターコンピューターのコンピューターアカウントを追加して管理者権限を付与します。
ただし後述するイベントサブスクリプションの詳細設定にて、ユーザーアカウントに『特定のユーザー』を選択し、ドメインのadministratorなどソースコンピューターのAdministrators ローカルグループに属するユーザーを指定する場合は本設定は不要です。
今回はイベントサブスクリプションの詳細設定にて、ユーザーアカウントに『特定のユーザー』を選択し、ドメインのadministratorを指定する例でご紹介するため、本設定は行わなくてOKです！
セキュリティーログを収集する場合について
コレクターコンピューターがソースコンピューターのイベントログのセキュリティーログを収集する場合は、さらに追加の権限設定が必要です。
この場合にはソースコンピューターのEvent Log Readers ローカルグループに、NETWORK SERVICE アカウントを追加し、イベントログを読み取りできるように権限を設定します。
本設定を行った後は、ソースコンピューターを一度再起動してください。
以上でソースコンピューター(イベントを収集される側のPC)の設定は完了です！
ソースコンピューターの設定をGPOで行う方法
ソースコンピューターの設定作業は数台であれば大した手間ではありません。
ですがこれが10台を超える規模になってくると、かなりきつい作業でしょう。
ただ幸いなことに、ソースコンピューターの設定作業はグループポリシーで簡単に設定できる内容であるため、AD環境の場合はこれを利用することをおすすめします。
グループポリシーでソースコンピューターの設定を行う場合は、以下のポリシーを設定したGPOを対象のOUにリンクしてください。
WinRMによるリモートサーバー管理を許可する
設定対象のGPOのグループポリシー管理エディターを起動し、[ コンピューターの構成 ] – [ ポリシー ] – [ 管理用テンプレート ] – [ Windows コンポーネント ] – [ Windows リモート管理(WinRM) ] – [ WinRM サービス ] – [ WinRMによるリモートサーバー管理を許可する ]と選択し、『有効化』に設定。
オプションのIPv4、IPv6フィルターについては、構文の説明書を読んで適切な値を設定してください。
すべてのIPアドレスについて許可する場合は、IPv4、IPv6ともに『*』と入力します。
Windows リモート管理サービスの遅延開始設定
設定対象のGPOのグループポリシー管理エディターを起動し、[ コンピューターの構成 ] – [ 基本設定 ] – [ コントロール パネルの設定 ] – [ サービス ]と選択し、サービスの新規作成を行います。
新しいサービスの設定画面では以下のように設定してください。
- スタートアップ：自動(遅延開始)
- サービス名：Windows Remote Management(WS-Management)/WinRM
- サービス操作：サービスを開始する
- サービスのロック時のタイムアウト待機時間：30秒間
- ログオン：変更なし
ファイアーウォールの受信設定
設定対象のGPOのグループポリシー管理エディターを起動し、[ コンピューターの構成 ] – [ ポリシー ] – [ Windowsの設定 ] – [ セキュリティの設定 ] – [ セキュリティーが強化されたWindowsファイアーウォール ] – [ 受信の規則 ]と選択し、受信の規則の新規作成を行います。
新しい受信規則の設定画面では以下のように設定してください。
- 規則の種類：事前定義 – Windowsリモート管理
- 事前定義された規則：表示された規則の中から対象となるプロファイルの規則にチェックを入れる
- 操作：接続を許可する
Event Log Readers グループの設定
コレクターコンピューターがソースコンピューターのイベントログのセキュリティーログを収集する場合は、この設定も必要となります。
設定対象のGPOのグループポリシー管理エディターを起動し、[ コンピューターの構成 ] – [ ポリシー ] – [ Windowsの設定 ] – [ セキュリティの設定 ] – [ 制限されたグループ ]と選択し、グループの追加を行います。
新しいグループの設定画面では以下のように設定してください。
- グループ：Event Log Readers
- このグループのメンバー：NETWORK SERVICE
コレクターコンピューター(イベントを収集する側のPC)の設定
コレクターコンピューター(イベントを収集する側のPC)にログオンし、管理者権限でPowerShellを起動して以下のコマンドを実行します。
1 | wecutil quick-config |
このコマンドにより、コレクターコンピューターがログを収集する準備が行われます。
コマンド実行時に実行確認が行われるので、yキーを押下して実行に同意してください。
1 2 | サービスのスタートアップモードはDelay-Startに変更されます。続行しますか（Y- はい、またはN- いいえ）？y Windows イベント コレクター サービスの構成は成功しました。 |
こちらもwinrm quickconfigと同様に、以下のように省略されたコマンドでも実行可能です。
1 | wecutil qc |
[帯域幅の最小化]または[潜在期間の最小化]を指定する場合の追加設定について
後述するイベントサブスクリプションの詳細設定で、イベント配信の最適化の設定について、[帯域幅の最小化]または[潜在期間の最小化]を指定する場合は、コレクターコンピューター上でもソースコンピューター(イベントを収集される側のPC)で実行した以下のコマンドを実行してください。
1 | winrm qc -force |
これについてはMicrosoftさんのTechNetにて、以下のように記載されています。
注
[帯域幅の最小化] または [潜在期間の最小化] のイベント配信の最適化を指定する場合は、コレクター コンピューター上でもこのコマンドを実行する必要があります。
さて、ここまでの準備でイベントログの転送・収集・管理のための下準備は完了したので、最後にイベントサブスクリプションの設定を行います。
イベントサブスクリプションの設定
イベントサブスクリプションでは、どういったイベントログを転送・収集・管理するのか定義し、コレクターコンピューターはこれにしたがってソースコンピューターからログを収集します。
イベントサブスクリプションはイベントビューアーで設定を行うため、『Windows』キーを押しながら『R』キーを押下。
表示された入力ボックスで『eventvwr』と入力して『OK』ボタンをクリックし、イベントビューアーを表示します。
そして画面左側のツリーペインにあるサブスクリプションのコンテキストメニューで、『サブスクリプションの作成』をクリックします。
サブスクリプションのプロパティが表示されるので、『サブスクリプション名』と『説明』を入力してください。
今回の例ではそれぞれ『haruru-log』、『クライアントPC群で発生したイベントレベル重大とエラーのログを収集する。』としています。
『宛先ログ』はコレクターコンピューターがソースコンピューターから収集したログを、コレクターコンピューターのどのイベントログに転送・保管するかを設定します。
初期設定は『転送されたイベント』であり、特にこだわりがなければ変更の必要はありません。
『サブスクリプションの種類とソースコンピューター』では、『コレクターによる開始』を選択し、『コンピューターの選択』をクリックします。
するとコンピューターの選択画面が表示されるので、『ドメイン コンピューターの追加』をクリックして、ソースコンピューターを選択します。
ソースコンピューターを選択後、選択画面で『テスト』をクリックすると、選択されているコンピューターに対して接続テストを実行し、成功すれば『接続テストに成功しました』と表示されます。
テストに失敗した場合には、『このURLは無効です』と表示されます。
このコンピューターの選択画面(GUI)によるソースコンピューターの設定は、ソースコンピューターが少なければ簡単お手軽な作業です。
ところがソースコンピューターが100台を超えるようなケースでは、大変面倒で手間がかかる作業でしょう。
そのためソースコンピューターが多い場合は、後ほど紹介するサブスクリプションに指定するソースコンピューターをCUIで追加設定する方法の利用を検討してください。
尚、サブスクリプションを保存するためには、最低1台のソースコンピューターを指定しなければならないため、コマンド(CUI)によるソースコンピューターの指定を行う場合であっても、最低1台はコンピューターの選択画面(GUI)でソースコンピューターを選択しておいてください。
収集するイベントでは、『イベントの選択』ボタンをクリックし、ソースコンピューターから収集するログの条件を指定します。
以下の例ではソースコンピューターで発生したイベントのうち、イベントレベルが重大とエラーの2つのイベントログを収集し、対象のログとして『Application』、『セキュリティ』、『Setup』、『システム』を指定しています。
次にサブスクリプションのプロパティ画面で『詳細設定』をクリックし、『ユーザーアカウント』と『イベント配信の最適化』について設定します。
『ユーザーアカウント』には、ソースコンピューターのログを読み取る権限があるアカウントを指定してください。
先に説明したソースコンピューターの設定にて、コレクターコンピューターのコンピューターアカウントにソースコンピューターの管理者権限を付与している場合は、『コンピューターアカウント』を選択します。
今回は先の説明で、本設定でドメインのadministratorを指定するケースを想定し、コレクターコンピューターのコンピューターアカウントにソースコンピューターの管理者権限を付与していません。
したがって本設定でドメインのadministratorを指定します。
『イベント配信の最適化』では配信モード(プルもしくはプッシュ)や使用するネットワーク帯域幅など、配信動作が異なる『通常』、『帯域幅の最小化』、『潜在時間の最小化』の3つのモードから適切なオプションを選択してください。
それぞれの違いはTechNetに記載されていたので、以下に引用します。
[通常]
このオプションは、イベントの配信が高い信頼性で行われるようにして、帯域幅の節約は試みません。
帯域幅の使用状況を厳しく制御する必要がある場合や、転送されたイベントをできるだけすばやく配信する必要がある場合以外は、これを選択するのが適切です。プル配信モードが使用され、5 つの項目が一度にバッチ処理されます。バッチ タイムアウトは 15 分です。
[帯域幅の最小化]
このオプションは、イベント配信のためのネットワーク帯域幅が厳密に制御されるようにします。
イベントを配信するために作成されるネットワーク接続の頻度を制限する場合に適しています。プッシュ配信モードが使用され、バッチ タイムアウトは 6 時間に設定されます。
また、6 時間のハートビート間隔が使用されます。[潜在期間の最小化]
このオプションは、イベントが最小限の遅れで配信されるようにします。
警告や重要なイベントを収集している場合は、これを選択するのが適切です。プッシュ配信モードが使用され、バッチ タイムアウトは 30 秒間に設定されます。
今回の例ではイベントレベルが重大とエラーの2つのイベントログを収集していることから、『潜在期間の最小化』が適切と考えて良いでしょう。
以上でイベントサブスクリプションの設定は完了となります。
ここまでの設定を行えば、ソースコンピューターから取得したイベントレベルが重大とエラーの2つのイベントログが、コレクターコンピューターの『転送されたイベント』に転送・収集されているはずです。
ログのプロパティ設定について
イベントサブスクリプションを利用して、複数のソースコンピューターのイベントログの転送・収集・管理を行った場合、サブスクリプションの設定内容によっては短時間の間にログが大量に収集されてしまい、古いログがすぐに見れなくなってしまうことがあります。
これを避けるためにイベントサブスクリプションの宛先ログに指定したログの設定を変更し、最大ログサイズを増やす。
またディスクサイズに余裕がある場合は上書きしない設定に変更する、といった対応をしておくと良いでしょう。
これらの設定変更は、宛先ログのプロパティで行います。
以下の例では、ログのサイズを1GB(1024 ✕ 1024 ＝ 1048576KB)と設定しています。
サブスクリプションの動作を確認する方法
一度設定したサブスクリプションは、イベントビューアーのサブスクリプションを選択することで一覧表示されます。
サブスクリプションの動作を確認したい場合は、対象のサブスクリプションを選択して右クリックし、『ランタイムの状態』を選択します。
すると以下のようなソースコンピューターの状態を一覧表示してくれる画面が表示されます。
『状態』が『アクティブ』であれば、そのコンピューターについては正常にログの収集ができています。
それに対して『エラー』と表示されている場合は何らかの理由により、ログの収集が正常に完了していないことを示しています。
この場合には当該コンピューターを選択すると、画面下部にエラーの理由が表示されるため、そのエラーメッセージを手がかりに問題を解決してください。
またコンテキストメニューにある『再試行』をクリックすると、転送を直ちに再試行してくれます。
サブスクリプションに指定するソースコンピューターをCUIで追加設定する方法
サブスクリプションに指定するソースコンピューターの台数が多い場合、コンピューターの選択画面(GUI)による設定は大変手間がかかる作業であるため、おすすめできません。
ソースコンピューターの追加設定はwecutilコマンドを使ったCUI操作でも可能なため、こちらを使うと良いでしょう。
たとえばあらかじめ作成したサブスクリプションの名前が『haruru-log』、コンピューター名が『PC30001』、属しているActiveDirectoryのドメイン名が『haruru29.local』の場合、コレクターコンピューターにログオンし、管理者権限でPowerShellを起動して以下のコマンドを実行します。
1 | wecutil ss haruru-log /esa:PC30001.haruru29.local /aes /ese:true |
複数台のコンピューターをまとめて追加する際は、上記コマンドを参考にExcelで対象のコンピューターを追加するコマンド文字列を作成し、PowerShellでまとめて実行すると楽ちんです。
wecutilコマンドは他にも多くのパラメーターを持っているため、詳細はTechNet(Wecutil)を参照してください。
ちなみにソースコンピューターにコレクターコンピューターを指定することも可能です。
この場合は、コレクターコンピューターのイベントログのうち、サブスクリプションで指定したログを転送先のイベントログに転送します。
1台のコレクターコンピューターが管理できるソースコンピューターの台数について
サブスクリプションに指定するソースコンピューターをCUIで追加設定する方法を使えば、サブスクリプションに多数のソースコンピューターを追加可能です。
そのため1台のコレクターコンピューターが管理できるソースコンピューターの台数は、一体どれくらいなんだろうか…。
と気になる方もいらっしゃると思います。
ですがこれはサブスクリプションで取得設定しているログの種類や最適化の設定、コレクターコンピューターの性能(CPUやディスクのアクセス速度など)、ネットワーク回線の性能に影響を受けることであり、10台までなら大丈夫だよ！と簡単に言えるものではありません。
ただはるるの過去の経験では、Xeon E5系の2CPU(12コア/24論理プロセッサ)、メモリ64GB、NICを4つ搭載、SAS HDDを使ったRAID6構成のサーバー筐体にWindows Server 2012 R2 Standard Editionをインストールし、ADのメンバーサーバー(主な用途はファイルサーバー)としていたものにコレクターコンピューターを担当させ、AD管理下のクライアントPC数百台(ソースコンピューター)のイベントログを管理させていたことがありますが、パフォーマンスに大きな影響は出なかったと記憶しています。(ネットワークはギガビット・イーサネット)
このときのサブスクリプションの設定はたしか潜在期間の最小化、イベントレベルが重大・エラー・警告の3つのイベントログを収集し、対象のログとして『Application』、『セキュリティー』、『Setup』、『システム』を指定していたはずです。
したがって同等の性能のサーバーとサブスクリプションの設定であれば、1台のコレクターコンピューターが数百台のソースコンピューターを管理可能であり、ファイルサーバー機能なども同時に提供可能と思っていただいて大丈夫だと思います。
イベントログをしっかりと管理すれば問題を未然に防げることも！
Windowsのイベントログには、コンピューターやユーザーの行動に関わるさまざまな情報が記録されています。
これをシステム管理者の方などが取得、一定期間保持、監視し、何らかの問題があれば対応する。
といったようにしっかりと管理すれば、情報セキュリティー上のリスクや、コンピューターのハードウェアトラブルやソフトウェアトラブルの兆候を早期に発見し、問題を未然に防ぐことができる可能性が高まります。
また仮に問題が起きてしまったとしても、その原因究明に役立つ資料となることも少なくありません。
そのためぜひこの機会に、イベントサブスクリプションによるイベントログの転送・収集・管理機能の利用を検討してみてはいかがでしょうか。