【Vol.08】「ログは語るが、誰も聞こうとしない」:ゼロトラストの頭脳を動かす監視戦略と、必見のWindowsイベントID

ゼロトラスト実装ガイド

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

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

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

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

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

スポンサーリンク

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

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

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

トラストエンジンは、アクセス要求が来るたびにリアルタイムで「トラストスコア(信頼度)」を計算します。

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

このスコアが基準値を下回った瞬間、認証済みのユーザーであってもアクセスを遮断します。

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

この計算を行うためには、入力データが必要です。その入力データこそが、デバイスやネットワークから送られてくる「ログ」です。
ログを収集・分析するパイプラインがなければ、トラストエンジンは何も判断できず、ゼロトラストは機能しません。

スポンサーリンク

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

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

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

① イベントID 4625:ログオン失敗(Logon Failure)

これは「総当たり攻撃(ブルートフォース)」の痕跡です。
特に、RDP(3389)やSMB(445)に対して、短時間に大量の「4625」が記録されていた場合、攻撃者があなたのサーバーのパスワードをこじ開けようとしています。即座に対象ポートを閉じるか、アカウントをロックする必要があります。

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

攻撃者は侵入後、バックドア(遠隔操作ツール)やランサムウェアを「Windowsサービス」として登録し、再起動しても動作するように永続化を図ります。
見覚えのないサービス(例:AnyDeskや不審なPowerShellスクリプト)が登録されたログがあれば、それは侵入確定のレッドカードです。

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

攻撃者が実行するコマンドの履歴です。
vssadmin.exe delete shadows(バックアップ削除)や、powershell.exe -enc ...(暗号化された不正コード実行)など、明らかに業務に関係のないコマンドが実行されていないか監視します。

スポンサーリンク

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

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

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

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

  • クラウドネイティブSIEM:
    AWS CloudWatch LogsやAzure Sentinelなどは、従量課金でスモールスタートが可能です。
  • EDRの活用:
    多くのEDR製品は、端末のログをクラウドに収集し、不審な挙動を自動分析する「プチSIEM」的な機能を持っています。

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

スポンサーリンク

4. 検知したらどうする? 「インシデントレスポンス」の初動

人間が寝ている間に「遮断」する

ログ監視のゴールは、「攻撃を見つけること」ではありません。「被害を止めること」です。
異常なログ(ID 4625の急増など)を検知した際、人間が起きて対応していては間に合いません。

ここで、Vol.5で構築した「デバイストラスト」が活きてきます。

  1. SIEM/EDRが異常を検知(ログオン失敗の多発)。
  2. トラストスコアを自動的に引き下げる(信頼度低下)。
  3. IdP(認証基盤)がアクセス権を即座に剥奪し、ネットワークから隔離する。

この「検知から遮断までの自動化(SOAR)」こそが、ランサムウェアの拡散速度に勝てる唯一の対抗策です。

スポンサーリンク

結論:「正常」を知らなければ「異常」はわからない

ログ監視において最も重要なことは、ツールの導入ではありません。
「自社の『正常な状態(ベースライン)』を知ること」です。

「普段のログイン回数はどれくらいか?」「深夜にアクセスする社員は誰か?」
平時の姿を知らなければ、ログの中に現れた「異常」に気づくことはできません。

中堅・成長企業の情シス責任者は、まず「イベントID 4625(ログオン失敗)」のアラート設定から始めてください。
静かなログの海に、攻撃者の足音は必ず残っています。それに耳を傾ける体制を作ることが、ゼロトラスト運用の要です。

本記事は、ZTRラボが提唱する全15章の「生存戦略」の一部(各論)です。 ゼロトラストとレジリエンスを統合した実装ロードマップの全体像を知りたい方は、まず以下の「実装バイブル」をご覧ください。

▶ 【完全保存版】ゼロトラスト×レジリエンス 実装バイブル:侵入前提時代を生き抜く「全15章の生存戦略」

タイトルとURLをコピーしました