WEFおよびWECによる一元的ログ収集の基本

先週、イベントロギングの要点について説明しました。すべてのシステムが重要なイベントやアクティビティに関するログを書き込んでいることを確認する内容です。今週は、これらのイベントログをWindowsイベントコレクター（WEC）サーバーで一元的に収集し、すべてのログをElastic Securityに転送する要点を説明します。

WEFとWEC

最新のWindowsには、Windowsリモート管理（WinRM）サービスが含まれており、これはWS-Management（WSMan）プロトコルを実装しています。さらに、これらはすべてWindows管理インストルメンテーション（WMI）の一部です。WinRMのコンポーネントの一つにWindowsイベント転送（WEF）サービスがあり、これがWinRMなどを有効にする必要がある理由です。WEFは、Windowsイベントコレクター（WEC）サービスを実行しているWindowsサーバーにWindowsイベントログを転送できます。

転送には2つのモードがあります。

1. ソース開始：WEFサービスがWECサーバーに接続します。
2. コレクター開始：WECサービスがWEFサービスに接続します。

どちらもWSManを使用してログを転送し、WinRMが実行されている必要があります。

WEFとWECのセットアップには、多くの落とし穴や障害が存在します。当社のWECクックブックに従えば、これらを回避できます。しかし、より包括的な視点と豊富な背景情報を提供するために、ここではそれらについて、そしてクックブックで採用されている解決策についても解説します。

「転送されたイベント」イベントログファイル

Windowsイベントログシステムにはチャネルという概念があります。これらのチャネルは、最終的にそのチャネルに書き込まれたすべてのイベントログを格納するイベントログファイルによって支えられています。Windowsシステムにはあらかじめ定義されたチャネルがいくつか用意されており、アプリケーションは新しい「プロバイダー」を登録することで独自のチャネルを追加できます。

つまり、初期状態では、WECサーバーには、通常のWindowsサーバーが独自のログ用に持っているチャネルしかありません。では、WECサーバーに転送されるすべてのログをどこに保存すればよいでしょうか？選択肢は次の3つです。

1. リモートチャネルと一致するローカルチャネルに格納します（つまり、リモートの「セキュリティ」チャネルイベントはWECのローカルの「セキュリティ」チャネルに保存されます）。

落とし穴：

• すべてのリモートログがローカルログと混ざる
• WECサーバーは、独自のイベントログをこのチャネルにループする可能性があります。
• ログの管理とアクセス制御が非常に困難になる

2. すべてのリモートログをローカルの「転送イベント」チャネルに保存します。

落とし穴：

• すべての書き込みが1つのファイルに行われるため書き込みパフォーマンスが悪い
• イベントが個別のファイルに分割されていないため検索/読み取りパフォーマンスが悪い
• ログファイル別で転送されるすべてのイベントが同じように扱われるためデータライフサイクル管理が不十分
• すべての作業が単一のファイルにボトルネック化されるためWECサーバーのリソース使用率が低い
• ファイルを分けるとファイルごとに異なるアクセス制御が可能になるためアクセス管理が不十分
• 上記の問題により、多くの企業は転送されるイベントログを厳しく制限し、可視性にギャップが残るためカバレッジ/可視性が悪い

3. WECサーバー用の新しいチャンネルを作成します。

これは一見すると当たり前のように思えるかもしれないが、実際はそうではなく、ほとんどの人がそれが選択肢の一つであることを知らなくても無理はないでしょう。

多くのWECサーバーは、オプション1または2（上記）で設定されていましたが、Microsoftの社内セキュリティチームが（約15年前に）Windows SDKを使用してオプション3を実装する方法に関するブログ記事を公開しました。以下は、2016年に投稿された同様の改訂版です。

WECイベントの新しいチャネル

任意のイベントチャネルを作成できるようになった今、何を作成すべきでしょうか？WECサーバーをどのように構成し、設計すべきでしょうか？様々な考え方がありますが、WECクックブックでは、エンタープライズ資産をグループ化することで、ログのアクセス制御とデータライフサイクルを適切に管理できるようにしています。

深く掘り下げる前に、別のアプローチを見てみましょう。PalantirのWECアーキテクチャとガイドラインをご覧になった方もいらっしゃるかもしれません。ここでは、Powershell、WMI、DNS、ファイアウォールなどのイベントログタイプごとにチャネルを作成しています。これらのチャネルには、すべての資産タイプ（ドメインコントローラー、ドメインサーバー、ドメインワークステーション）および部門・ビジネスユニット・OUのログが含まれています。また、階層構造にはなっておらず、イベントビューアーでは長いリストとして表示されます。したがって、チャネルにはWECサブスクリプションもあります。Palantirには推奨される監査ポリシーもあります。

私は、Palantirのこのアプローチなど、他のアプローチも紹介したいと思っています。なぜなら、万能な解決策は存在せず、同社のアプローチは、当社のクックブックで紹介されているものよりも、組織に適している可能性があるからです。

Palantirのチャネルリストを見れば、7チャネルごとに「#」の数が増える「WEC#-Something」形式に気づきます。これは、Windowsのイベントログシステムでは、チャネルは「プロバイダー」と呼ばれるものによって定義され、最大8つのチャネルしか定義できないためです。

しかし、Windows SDK開発者ではないセキュリティ担当者全員が使用していた「ecmangen」ツールのバグにより、プロバイダーごとに7つ以上のチャネルを設定することが困難になっていました。

Microsoftは、その中の多くのバグを修正する代わりに、Windows SDKからecmangenを削除したようです。つまり、古いSDKを使用するか、マニフェストXMLファイルを自分で（おそらくお気に入りのXMLエディターで）作成するかのどちらかです

。

他の皆さんと同様に、私も（当初は）ecmangenを使用し、作業を簡略化するために7つのチャネルに限定していました。現在のクックブックは、XMLを生成するPowerShellスクリプトに基づいています。ecmangenはもはや必要ないため、必要に応じて8つのチャネルを使用することも可能ですが、クックブックでは依然として推奨されている7つのチャネルのみを使用しています。

注：プロバイダは8つのチャネルが入った箱のようなものと考えてください。各チャネルは最終的には個別のログファイルになります。

資産別に整理する

プロバイダーをいくつでも作成できるという利点を活かして、資産ごとに整理することができます。おそらく、Active Directory環境では、ドメインメンバーを資産の種類（ドメインサーバー、ドメインコントローラー、ワークステーションなど）や、それらの資産が属する部門（組織単位と言ってもいいでしょう）ごとに既にグループ化しているはずです。

このクックブックでは、部門（ビジネスユニットまたはOU）ごと、資産タイプごと、資産の重要度（ラボ/テスト/本番）ごとなど、ADの組織に合わせてプロバイダーを簡単に作成できます。

資産の種類ごとに分類することで、アクセス制御やログのライフサイクル管理をより効率的に行えるというメリットが得られます。特定の資産タイプのログを確認する必要がある場合でも、その場所がすぐに分かります。

手続きを簡素化するため、すべてのプロバイダーは同じチャネルセット（最大8つ）を取得します。その後、システムは（OUを介して）プロバイダーにマッピングされ、そのシステムのイベントログがそのプロバイダーのチャネルにマッピングされます。

デフォルトでは、WECサーバーをADアーキテクチャに合わせて構成するために使用される「wec_config.ps1」スクリプトには、いくつかのプロバイダーとアセットの割り当てが定義されています。

• ドメインコントローラー：メンバーの割り当てはここでは明確だと思います
• ドメインサーバー：ドメイン内のサーバー
• ドメインクライアント：ユーザーワークステーション（デスクトップ/ノートパソコン）
• ドメイン特権：より高い特権を持つシステム（例：ジャンプホストまたはWECサーバー）
• ドメインメンバー：通常のドメインメンバー全般を指し、他のグループには含まれません。
• ドメインその他：その他、該当しないホスト用

ご自身のActive Directory環境に合わせて、リストを精査・編集することをお勧めします。

初期設定時のチャネルリストは以下のとおりです。

• アプリケーション：「アプリケーション」および類似のログ
• セキュリティ：「セキュリティ」および類似のログ
• Sysmon：「Microsoft-Windows-Sysmon/Operational」
• システム：「システム」、「ハードウェアイベント」、「DNSクライアント」、「DHCPクライアント」、「セットアップ」などのログ
• スクリプト：「Windows PowerShell」および類似のログ
• サービス：DNSサーバー、DHCPサーバー、その他のサービスログ
• その他：その他の雑多なログ

繰り返しになりますが、これはご自身のニーズに合わせて自由に変更できます。

WECサブスクリプション

WECサブスクリプションには、以下の内容が含まれます。

• イベントログ（XPath）フィルタ。転送するイベントを選択します。
• 受信したイベントをWECサーバー上のどこに格納するかを指定する宛先チャネル。
• タイプ：
  • コレクター主導で、WECはWEFサービスに接続します。
    • ターゲットコンピューター、接続先のコンピューターのリスト
  • ソースが起動すると、WEFはWECサーバーに接続します。
    • コンピューターグループ、その（コンピューター）メンバーがこのサブスクリプションにアクセスできるADグループ
• 帯域幅/遅延および/またはHTTP/HTTPSを制御するためのイベント配信オプション
• フォーマットタイプ：レンダリングされたテキスト、またはイベントXMLのみ

クックブックスクリプト（特に setup_subscriptions.ps1）は、イベント XML フォーマットタイプを設定します。このフォーマットはサイズが小さいため、スループットの向上、格納されるログの増加、負荷の軽減、帯域幅の削減につながります。ただし、欠点に、ソースプロバイダ（リモートシステム上）が WEC サーバーのイベントログシステムにローカルに登録されていない場合、イベントビューアでメッセージのテキスト説明をローカル言語で表示できないことがあります。しかし、レンダリングされたテキストイベントを送信するとリソース消費が非常に大きいため、正当化するのは困難です。

冒頭で述べたように、WEFはWinRMの機能です。このWinRMコンポーネントは、ローカルシステムの「ネットワークサービス」ユーザーとして実行されます。つまり、WEFは実際にはほとんどのシステムログを読み取ることができず、WECサーバーにはイベントID 111という非常に分かりにくいメッセージのみが送信され、他のログは受信されません。そのため、このクックブックでは、ローカルの「イベントログリーダー」グループに「ネットワークサービス」を追加するGPOの作成方法を解説しています。

WinRMはどのようにしてWEFの構成を取得するのでしょうか？前述のGPOと同じGPO内で、そのサーバー上のすべてのWECサブスクリプションを一覧表示するWSman URLも公開しています。実際には、複数のWECサーバーから複数のWSmanサブスクリプションURLを一覧表示することができ、WEFサービスはそれらすべてを取得して実行しようとします。これにより、冗長なWECサーバー構成が可能になります。

すべてのサブスクリプション？ワークステーションからイベントログがドメインコントローラーのログファイルに送信されるのは困ります。サブスクリプションを表すWSmanエントリには、サブスクリプション構成で設定されているとおり、ADグループのアクセス許可が適用されます。つまり、WEFが実行されているコンピューターが、サブスクリプションを読み取る権限を持つADグループのメンバーでない場合、サブスクリプションを取得して実行することはできません。また、注意しないと、コンピューターが複数のWECサブスクリプションADグループのメンバーになっている場合、そのWEFホストからWEC上に同じイベントログが複数回記録されることになります。

コンピューターグループ？でも、コンピューターが配置されているOUに基づいてマッピングしたいんです！残念ながら、WEF/WEC/WinRM/WSmanはそういう仕組みではありません。しかし、クックブックには、特定のグループのメンバーシップを、指定されたOUの場所と同期させるメカニズムが用意されています。つまり、すべてがOU経由で行われているかのように見せかけることができるのです！

すべてをまとめると

WEFとWECを適切な監視機能やセキュリティのユースケースに合わせて設定するには、多くの複雑な要素を正しく設定する必要があります。

しかし、ご安心ください。クックブックをご用意しており、ほとんどの手順を自動化するPowerShellスクリプトも付属しています。これにより、ミスが発生する可能性が低くなり、操作の再現性が高まるため、ミスの修正も容易になります。

すべてはwec_config.ps1スクリプトから始まります。このスクリプトは自由に編集してください。以降のすべてのスクリプトはこのスクリプトを基に動作します。したがって、例えばwec_config.ps1で転送するイベントログを選択するために使用されるイベントログフィルタを簡単に変更し、setup_subscriptions.ps1を再実行して変更を適用することができます。

スクリプトの機能を見てみましょう（クックブックではその使用方法についてさらに詳しく説明しています）。

• wec_config.ps1 - 他のスクリプトでソースとなるWECサーバーの構成
• gen_manifest.ps1 - これによりWindows SDKのすべてのプロバイダーとそのチャネルを記述するマニフェストXMLが作成されます（ecmangenを使用する必要はもうありません）。
• build_man2dll.ps1 - マニフェストを取得すると、インストールしたシステム（通常はWECサーバー）にすべての新しいプロバイダーとチャンネルを実装するWindowsイベントサブシステムモジュールDLLが構築されます。
• install_channels.ps1 - DLLとマニフェストを取得してローカルシステムにインストールします。configure_channels.ps1 - 新しくインストールしたすべてのチャネルにログパスとログサイズの設定（wec_config.ps1から）を適用します
• setup_subscriptions.ps1 - WECサーバー上のプロバイダー/チャンネルのすべてのサブスクリプションをセットアップ（作成または再構成）します
• map_ou2group.ps1 - ADのOUを使用したいと思うかもしれませんが、WECサブスクリプションはADグループを介してコンピューターを選択します。このスクリプトは、wec_config.ps1の設定を使用して、特定のグループのメンバーシップを指定されたOUの下のコンピューターに同期します。
• gen_winlogbeat_config.ps1 - Winlogbeatに付属の設定では、追加のWECサブスクリプションチャネルがすべてわからないため、その設定を更新します。
• beat_cmd.ps1 - PowerShellでBeatsコマンドを操作するためのヘルパースクリプト

残念ながら、すべての設定はグループポリシーなどのAD側ではまだ手動で行う必要がありますが、クックブックにはスクリーンショット付きのステップバイステップガイドがあります。私もいつかそのためのスクリプトを書くかもしれません。ご期待ください。

最後に、すべてのWECログをElastic Securityに送信するようにWinlogbeatを設定する必要があります。クックブックもこれを教えてくれます。

結論

このブログ記事、そして可能であればクックブック自体をお読みいただいた後、開始前に決定すべき事項について十分な理解が得られ、企業に最適なWECサーバーを構築するために必要なすべてのガイダンスとツールが揃うことを願っています。

適切な監査ポリシーが設定され、WEFが構成され、ADドメインのイベントログをElastic Securityに転送するためのWECサーバーがセットアップされたので、次のブログ記事では、Elastic Securityでこの非常に重要で便利なログデータをどのように活用できるかを見ていきます。

Elastic Securityを初めてご利用になる方は、Elastic Cloud上のElasticsearch Serviceで最新バージョンをお試しいただけます。また、クイックスタートトレーニングをご活用いただくことで、スムーズに導入を進めることができます。

私が執筆した他のクックブックガイドもご覧ください：https://ela.st/tjs-cookbook-lib