Windowsイベントログのセキュリティ監視｜見るべきイベントID

～ログは「ゴミ箱」ではない。トラストを計算する「燃料」である～

「ログは一応取っています。何かあった時のために」
もしあなたの会社のログ運用が「保存するだけ（Write Only）」になっているなら、それは非常にもったいない、いや、危険な状態です。

多くの企業において、ログは「枯れ葉」のように扱われ、ストレージの肥やしになっています。しかし、ゼロトラスト環境において、ログはアクセスの可否をリアルタイムで判断する「トラストエンジン」を動かすための、重要な「燃料（ガソリン）」の一つなのです。

燃料が足りなければ、どんな高性能なエンジンも十分に働きません。ログを見ていないゼロトラストは、ただの「静的なアクセス制限」に過ぎません。

本稿では、トラストエンジンの仕組みと攻撃分析に基づき、情シスが明日から監視すべき「Windowsイベントログ」と、それを自動化する運用戦略を解説します。

ほかの予防策もまとめて確認したい方は、中小企業のランサムウェア対策チェックリストをご覧ください。

1. ゼロトラストの脳：「トラストエンジン」の仕組み
1. 静的なルールから「動的なスコアリング」へ
2. ログがなければエンジンは「盲目」になる
2. まず何を見るべきか？泥臭い「Windowsイベントログ」監視
3. 「SIEM」は高嶺の花か？ログの一元管理と分析
1. サーバー1台ずつ見て回る時代は終わった
4. 検知したらどうする？「インシデントレスポンス」の初動
1. 人間が寝ている間に「遮断」する
結論：「正常」を知らなければ「異常」はわからない

1. ゼロトラストの脳：「トラストエンジン」の仕組み

静的なルールから「動的なスコアリング」へ

従来のカチカチに固めたセキュリティ（境界防御）では、「営業部のPCならアクセスOK」という静的なルールで運用していました。しかし、ゼロトラストでは「動的な評価」が求められます。

トラストエンジンの実装によっては、アクセス要求が来るたびに「トラストスコア（信頼度）」を計算し、アクセスの可否の判断に使います。

「いつもと同じ場所か？」
「深夜のアクセスではないか？」
「デバイスに不審な挙動はないか？」

スコア方式の場合、このスコアが基準値を下回ると、認証済みのユーザーであってもアクセスを遮断することがあります。

ログがなければエンジンは「盲目」になる

この計算を行うためには、入力データが必要です。その入力データの重要な一つが、デバイスやネットワークから送られてくる「ログ」です。
ログを収集・分析するパイプラインがなければ、トラストエンジンは判断材料が乏しくなり、ゼロトラストの仕組みが十分に働かなくなるおそれがあります。

2. まず何を見るべきか？泥臭い「Windowsイベントログ」監視

AIの前に、まず「生ログ」を知る

「いきなりAIで分析」はハードルが高いでしょう。まずは、Windows標準のイベントログから「攻撃の予兆」を掴むことから始めます（③の4688でコマンドの中身まで記録するには、事前の設定が必要です）。
以下に、情シスが毎朝チェックすべき（あるいはアラート設定すべき）3つのイベントIDを提示します。

① イベントID 4625：ログオン失敗（Logon Failure）

ログオンに失敗するたびに記録されるイベントです。パスワードの打ち間違いでも記録されますが、短時間に大量に続く場合は「総当たり攻撃（ブルートフォース）」の痕跡の可能性があります。
特に、RDP（3389）やSMB（445）に対して、短時間に大量の「4625」が記録されていた場合、攻撃者があなたのサーバーのパスワードをこじ開けようとしているおそれがあります。早急に対象ポートを閉じる、アカウントをロックするなどの対応を検討してください。

② イベントID 7045：サービスのインストール

攻撃者は侵入後、バックドア（遠隔操作ツール）やランサムウェアを「Windowsサービス」として登録し、再起動しても動作するように永続化を図ります。
見覚えのないサービス（例：AnyDeskや不審なPowerShellスクリプト）が登録されたログがあれば、侵入を疑って最優先で調べるべき兆候です。ソフトの導入やアップデートなど正規の操作でも7045は記録されるため、登録された日時とサービスの中身を確かめます。

③ イベントID 4688：プロセスの作成

プロセスが作成されたときに記録されるイベントです。監査ポリシー「Audit Process Creation」（プロセス作成の監査）を有効にし、さらにグループポリシー「Include command line in process creation events」を有効にした場合に、攻撃者が実行したコマンドの中身まで記録されます。既定ではコマンドラインの欄は空です（Microsoft Learn、2026年10月確認）。
設定を有効にしたうえで、vssadmin.exe delete shadows（ボリュームシャドウコピーの削除）や、powershell.exe -enc ...（Base64でエンコード〈難読化〉されたコマンドの実行）など、明らかに業務に関係のないコマンドが実行されていないか監視します。

不正なログインを入口で防ぐ方法は、Vol.04 MFA導入ガイドで解説しています。

3. 「SIEM」は高嶺の花か？ログの一元管理と分析

サーバー1台ずつ見て回る時代は終わった

サーバーが10台、PCが100台ある環境で、それぞれのイベントビューアーを目視確認するのは現実的ではありません。ログは一箇所に集約しなければなりません。

これを実現するのがSIEM（Security Information and Event Management）です。
「SIEMは高価だ」というイメージがあるかもしれませんが、中堅企業でも導入可能な選択肢は増えています。

クラウドのSIEM・ログ集約サービス:
Microsoft Sentinel（旧 Azure Sentinel）はクラウドネイティブのSIEMで、保存したデータ量に応じた従量課金でスモールスタートが可能です。なお、Azureポータルでの提供は2027年3月31日に終わり、以降はMicrosoft Defenderポータルで使う形になります（Microsoft、2026年10月確認）。
Amazon CloudWatch LogsはSIEMではなく、ログの監視・保存・集約のサービスです。こちらも従量課金で、AWSの無料枠から始められます。
EDRの活用:
EDR製品によっては、端末のログをクラウドに収集し、不審な挙動を自動分析する「プチSIEM」的な機能を持っています。

ログを分散させず、「一箇所で見られる」状態を作ることが、監視の第一歩です。