はじめに
組織内のエンドポイントやサーバーが数百・数千台規模になると、各端末に個別にログインしてイベントログを確認することは不可能です。また、端末がランサムウェアや攻撃者に完全侵害された場合、攻撃の痕跡を隠滅するためにローカルのイベントログが消去（EID 1102）されるリスクが極めて高くなります。
こうした課題を解決するのが、Windows標準機能であるWEF（Windows Event Forwarding：Windows イベント転送）です。サードパーティ製のエージェントを追加インストールすることなく、組織内のログを中央のコレクターサーバーへリアルタイム転送し、SIEMへ連携するセキュアな基盤を構築できます。
前提条件
- 本記事はActive Directoryドメイン環境でのGPO配布を前提としています。ワークグループ環境でも構成可能ですが、証明書ベースの認証設定が別途必要になります。
- コレクターへの転送先指定にはFQDN（完全修飾ドメイン名）を使用してください。IPアドレスでも動作する場合がありますが、WinRMが既定で要求するKerberos認証が正しく機能しなくなります。
Linuxエンジニア向けの例え
WEFは、各ホストのrsyslog/syslog-ngに@@collector.example.local:514のような転送設定を書き、ローカルログを中央のsyslogサーバーへプッシュする構成に相当します。追加のエージェントを入れず、OS標準のログデーモン（Windowsの場合はイベントログサブシステムとWinRM）だけで完結する点も同じ発想です。
攻撃者が侵入後に~/.bash_historyや/var/log/auth.logを消去して痕跡を隠すのと同様に、Windows環境でもEID 1102（セキュリティ ログのクリア）は定番の証拠隠滅手口です。だからこそ、ログが生成された端末に留め置かず、数秒〜数十秒以内に中央のコレクターへ転送し切ってしまうことが重要になります。
1. Windows Event Forwarding (WEF) の基本アーキテクチャ
WEFは、HTTP/HTTPS（WinRM）および標準のWS-Managementプロトコルを利用して動作します。
[ クライアント端末 (Forwarder) ] ──(HTTPS/WinRM: 5986)──▶ [ コレクターサーバー (WEC) ] ──▶ [ SIEM / 分析基盤 ]
[ サーバー端末 (Forwarder) ] ──(Kerberos / 相互認証)─┘ (ForwardedEvents ログ) (Splunk, Sentinel等)
プッシュ型 vs ソース主導型（Source-Initiated）
WEFには2種類の転送方式がありますが、エンタープライズ要塞化におけるデファクトスタンダードは「ソース主導型（Source-Initiated）」です。
- コレクター主導型（プッシュ型）: コレクターが各端末へログを取りに行く方式。端末のIP変更やスリープに弱く、ファイアウォールの内向きポートを開放する必要があるため非推奨。
- ソース主導型（推奨）: 端末側からコレクターへ向けてアウトバウンド通信でログを送り出す方式。GPOでコレクターのURLを通知するだけで、数千台のクライアントPCやノートPCから安全にログを収集可能。
2. WEF導入の3ステップ
ステップ1：コレクターサーバー（WEC）の準備
ログを集約するWindows Serverで、Windows Event Collector（Wecsvc）サービスを有効化します。
# 管理者権限のPowerShellで実行
# コレクターサービスを起動・自動起動に構成
wecutil qc /q
イベント配信の最適化として既定（「標準」）以外の「帯域幅の最小化」「待機時間の最小化」を使う場合は、コレクター側でも別途
winrm quickconfigの実行が必要になる点に注意してください。
ステップ2：全クライアント（転送元）の事前設定（GPO）
各端末がログを転送できるように、WinRM（Windows Remote Management）の自動起動と、コレクターのサブスクリプションマネージャー（送信先URL）をGPOで配布します。
WinRM サービスの自動起動:
パス: コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → システム サービス
「Windows Remote Management (WS-Management)」を「自動」に設定。
転送先コレクターの指定:
パス: コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → イベント転送
ポリシー名: 「ターゲット サブスクリプション マネージャーの構成」を「有効」に設定。
オプションの「表示」にコレクターの接続情報を入力：
Server=http://wec-server.corp.local:5985/wsman/SubscriptionManager/WEC,Refresh=60
（※セキュアな本番環境ではHTTPS / ポート5986と証明書構成を推奨）
転送元端末でのログ読み取り権限の付与:
セキュリティログ（Security）は機密性が高いため、通常のプロセスでは読み取れません。ソース主導型の転送では、各転送元端末上でイベント転送処理そのものがローカルのNETWORK SERVICEアカウントとして動作するため、転送元端末自身のローカル「Event Log Readers」グループにNETWORK SERVICEを追加する必要があります（コレクター側のコンピューターアカウントではない点に注意してください）。
数千台規模の端末に一括適用するには、GPOの「グループ ポリシーの基本設定」→「コントロール パネルの設定」→「ローカル ユーザーとグループ」を使い、対象OU配下の全端末に対して「Event Log Readers」グループへNT AUTHORITY\NETWORK SERVICEを追加する設定を配布します。
3. サブスクリプション（収集ルール）の設計
コレクターサーバー側で「どの端末から、どのイベントIDを収集するか」を定義するサブスクリプション（Subscription）を作成します。
GUIによる作成（イベントビューアー）
- コレクター上で
eventvwr.mscを開き、「サブスクリプション」を右クリック →「サブスクリプションの作成」を選択。 - 送信元コンピューター: 「ソース コンピューター側から開始」を選択し、ドメインのコンピューターグループを指定。
- イベントの選択: 前回（第37回）で収集対象として絞り込んだ重要イベントを指定（例: ログオン 4624/4625、プロセス生成 4688、Kerberoasting検知用の4769、Sysmonログなど）。
XMLによる詳細クエリの指定例
クエリを直接XMLで定義することで、高ノイズな通常イベントを排除し、侵入調査に必要なイベントのみを抽出して転送できます。
<QueryList>
<!-- セキュリティログから認証・プロセス・特権操作のみを収集 -->
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624 or EventID=4625 or EventID=4688 or EventID=4720 or EventID=4728 or EventID=4732 or EventID=4769)]]
</Select>
</Query>
<!-- Sysmonが導入されている場合はSysmonの全アラートも集約 -->
<Query Id="1" Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
</Query>
</QueryList>
4. コレクターからSIEMへのパイプライン
集約されたログは、コレクターサーバーのForwardedEvents.evtx（転送されたイベント）に一括して書き込まれます。
ここからSIEMへの連携は、以下のように一本化されます。
[ 各端末 ] ──(WEF標準転送)──▶ [ コレクター: ForwardedEvents ] ──(単一エージェント)──▶ [ SIEM ]
- クライアントへの負荷ゼロ: エンドポイントPC1台1台に重いサードパーティ製ログ収集エージェントを入れる必要がありません。
- ネットワーク境界の集約: SIEMへの外部通信はコレクターサーバー1台のみに絞られるため、ファイアウォール設計が極めてシンプルになります。
- 改ざん耐性の確保: 攻撃者がエンドポイントのローカルログを消去する前に、イベント発生から数秒以内でコレクターへログが送出されるため、証拠隠滅を防げます。
まとめ
ログは生成させるだけでは意味がなく、「消される前に安全な場所へ退避させ、統合監視できる状態にする」ことで初めてセキュリティ要塞化の防護壁として機能します。
- Windows標準のWEFを採用し、エージェントレスで堅牢な収集基盤を構築する
- ソース主導型（Source-Initiated）で設計し、リモートPCの変動にも柔軟に対応する
- 重要なイベント（4624, 4688, 4769, Sysmon等）に絞り込んで転送し、回線とSIEMライセンスを最適化する
このWEFパイプラインを確立することで、組織全体の脅威検知・初動対応のスピードを一段上のレベルへ引き上げましょう。
今すぐ実行すべき確認コマンド
# 1. コレクターサービスが稼働しているか確認（コレクターサーバー上で実行）
Get-Service Wecsvc
# 2. 転送元端末で、WinRMサービスが自動起動・稼働中か確認
Get-Service WinRM
# 3. 転送元端末で、Network ServiceがEvent Log Readersに所属しているか確認
Get-LocalGroupMember -Group "Event Log Readers" | Where-Object { $_.Name -match "NETWORK SERVICE" }
# 4. コレクターサーバー上で、サブスクリプションの稼働状況を確認
wecutil es
wecutil gr <サブスクリプション名>
# 5. コレクターに実際にログが集約されているか確認
Get-WinEvent -LogName ForwardedEvents -MaxEvents 5