侵入検知の導入判断 — ホスト側で見張るかネットワーク側で止めるか

侵入検知の設計判断は、「どの製品を選ぶか」よりも「どの層に検知を置き、誰が何を起点に動くか」を先に決めることから始まる。ログを収集しただけでは侵入に気づけない構造は多くの現場に存在しており、ホスト型かネットワーク型かという選択に先立って、資産の重要度・守備範囲の空白・運用体制の限界を整理しなければならない。以下では、検知レイヤーの判断軸、誤検知との折り合いをどこで付けるか、そして設計段階で決めておくべきチェックフレームを順に整理する。

ログは集めたのに侵入されても誰も気づかない構造

ログ収集が「記録」にとどまる構造的問題

多くの構築現場では、SyslogやAuditdの出力をSIEMや集約サーバーへ転送し、「ログ基盤は整備済み」という状態に至ることがある。しかし収集したログにアラートルールが存在しなければ、それは後追い調査のための証拠保全にすぎず、リアルタイムの侵入検知とは根本的に異なる。「ログを遡れば侵入の痕跡が見つかる」状態と、「侵入が発生した時点でアラートが飛ぶ」状態では、インシデント対応の速度に雲泥の差がある。構築を任されたある担当者が「ログは全部転送していたが、通知は一切来なかった」と振り返る事例は、現場では繰り返し聞かれる話だ。

検知の欠如が平常時に可視化されない理由

ログ収集の整備はダッシュボードへの表示や蓄積量として可視化されやすく、関係者に「セキュリティ対策が整っている」という印象を与えやすい。一方、検知ルールの欠如は平常時には何も起きないため問題として浮上しない。インシデントが発生して初めて「リアルタイムの検知が設計されていなかった」と判明する構造になっており、収集基盤が完成した時点で検知設計を後回しにする判断がそのまま固定化されやすい。過去の侵入インシデント事例では、発生から発覚まで数週間から数か月を要したケースが報告されており、その間に被害範囲が静かに拡大している。

収集と検知の役割を設計段階で切り分ける

設計フェーズで「ログを何のために収集するか」を明示しなければ、収集と検知は同一の基盤に混在し、どちらの要件も中途半端になりやすい。収集の目的が「インシデント後の調査」であれば、保存期間・検索性・保存コストがKPIになる。「リアルタイムの異常検知」が目的であれば、ルールエンジン・アラートチャネル・対応フローが設計範囲に入る。両方を同一基盤で賄う場合でも、それぞれの要件を独立して定義し、優先順位を明文化しておくことが後の運用設計の土台になる。目的が曖昧なまま構築を進めると、どちらの機能も十分に機能しない状態に陥る。

検知を入れる資産と収集だけで足りる資産の判断

資産の重要度と攻撃対象領域で優先順位を付ける

すべての資産に同一レベルの検知を適用するのは、コストと運用負荷の観点から現実的ではない。まず資産を「外部から到達可能な公開系」「内部ネットワークの基幹系・データ保管系」「その他の補助的資産」の三層に分類するところから始める。公開系は攻撃の最初の入口として狙われるため、ネットワーク型の検知を優先的に配置する。基幹系は権限昇格や横展開を早期に察知する必要があるため、ホスト型が適する。補助的資産はログ収集と集約のみで対応し、検知のリソースを重要資産に集中させる判断が合理的だ。

収集だけで対応できるシナリオの判断軸

資産がクローズドなネットワークに閉じており外部から直接到達できない、変更頻度が極めて低い読み取り専用システムである、障害時の影響範囲が局所的なバッチ処理サーバーである、という条件が重なる場合は、定期的なログレビューで代替できるケースがある。ただし「クローズドだから安全」という前提は、内部からの不正アクセスや設定変更による経路開通を見落としやすい。クローズド環境でも接続ログと権限変更ログは最低限収集し、月次以上の頻度でレビューする体制は維持することが望ましい。この判断は固定せず、環境の変化に応じて年1回以上の再評価を組み込む設計が現実的だ。

検知レイヤーを追加すべき判断トリガー

以下の条件のいずれかに当てはまる資産は、ログ収集のみでは不十分と判断し、検知レイヤーの設計を優先する。個人情報・認証情報・決済データを保持している資産、管理者権限アカウントが定常的にログインする資産、変更管理プロセスの外で設定変更が発生しうる環境、外部公開APIや管理コンソールへの経路が存在するシステムが主な対象となる。これらの条件は構築時点だけでなく環境の変化とともに再評価が必要であり、資産棚卸しと組み合わせて定期的に見直す体制が現実的だ。

ホスト型(HIDS)/ネットワーク型(IDS/IPS)/エンドポイント製品の選定比較

各方式が守れる範囲と守れない範囲

ホスト型HIDS（Host-based IDS）は個別サーバー上でファイル整合性・プロセス起動・ログの異常を監視し、暗号化通信の内側の処理まで可視化できる強みがある。一方でエージェントをホスト数分だけ展開・管理する必要があり、100台規模の環境では展開計画とバージョン管理だけで相当な工数を要する。ネットワーク型IDS/IPSはインラインまたはミラーポートで通信全体を監視し、ホストに変更を加えずに複数資産をまとめてカバーできる。ただしTLSオフロードが構成されていない環境では、暗号化トラフィックの内容は確認できない。エンドポイント製品（EDR）はプロセス挙動の相関分析に強く、マルウェアの初期侵害検知で優位性があるが、ライセンスコストがエンドポイント数に比例して拡大する点を考慮する必要がある。

方式別の特性を整理する比較表

比較観点	ホスト型（HIDS）	ネットワーク型（IDS/IPS）	エンドポイント製品（EDR）
主な検知対象	ファイル改ざん・プロセス・ログ異常	通信パターン・シグネチャ一致	プロセス挙動・メモリ操作・相関分析
暗号化通信への対応	高（ホスト内処理まで可視）	低（TLSオフロードが必要）	高（プロセス単位で追跡可）
横展開の検知	個別ホスト単位のため限定的	通信ベースで横断的に検知可	相関分析で検知可
展開工数	ホスト台数分のエージェント管理	ミラーポート/インライン配置	全エンドポイントへエージェント展開
主な誤検知要因	除外ルールの設計精度	シグネチャの鮮度とチューニング	行動ベースのため誤検知が出やすい
適した環境	台数が限られた重要サーバー群	広域セグメントの一括監視	Windowsクライアントを含む混在環境

組み合わせる場合の設計判断と留意点

単一方式では守備範囲に必ず空白が生じる。外向き通信の不審なパターンをネットワーク型で検知し、内部重要サーバーのファイル改ざんや権限変更をホスト型で監視するという役割分担が一般的な構成だ。エンドポイント製品はLinuxサーバー中心の環境よりも、Windowsクライアントを含む混在環境で選択肢として浮上しやすい。どの方式を組み合わせるにしても、「この方式では守れない部分を何が補完しているか」を設計書に明記し、担当者が変わっても選定根拠が引き継げる状態を保つことが重要だ。組み合わせの妥当性は構成変更のたびに再確認する習慣を設計に組み込んでおく必要がある。

改ざん検知の対象をどのディレクトリまで広げるか

監視対象パスの選定基準

改ざん検知を設計する際の起点は、「攻撃者に書き換えられた場合に直接被害が発生するパス」だ。Webのドキュメントルート、実行バイナリの格納先、設定ファイルの集約先、認証・認可に関わるファイル群が最低限の監視対象になる。ここに「念のため広く見ておきたい」という発想で /home や /tmp、/var/log を加えると、通常運用でのファイル変更がそのまま誤検知源になる。まず「変更が検知されたら即座に対応が必要なパス」に絞り込み、そこを基点に段階的に拡張していくことが、監視の実効性を維持する基本的な設計判断だ。

広げすぎたときに運用で起きること

/var/log 配下を監視対象に含めた構成では、ログローテーションのたびにアラートが発生し、担当者がアラートを「いつものもの」として読み飛ばすようになったケースが複数報告されている。監視対象を広げることとアラートの信頼性を保つことはトレードオフの関係にあり、対象パスを10個追加するごとに除外ルールの検討コストが比例して増える傾向がある。アラートの信号対雑音比を設計段階から意識し、「追加するパスに対応フローがあるか」を確認してから追加するという手順を定めておくことで、対象の肥大化を抑制できる。

段階的拡張の設計と見直しタイミング

最初の監視対象は「変更が検知されたら即対応が必要なパス」に絞り込み、3か月程度運用して誤検知率が許容範囲に収まってから次の候補パスを追加する段階的拡張が現実的だ。デプロイやパッチ適用などの計画的な変更時には監視を一時緩和し、作業完了後に再有効化する手順をあらかじめ設計しておかないと、メンテナンスのたびに大量のアラートが発生する。変更管理プロセスと検知設定の連携は設計段階で組み込む必要があり、変更チケットと検知設定の変更履歴を紐づける体制が望ましい。

初期チューニングと除外ルールを誰がいつ回すか

チューニング責任者を設計段階で決める

侵入検知を導入した直後は誤検知が多発する。これは製品の品質の問題ではなく、環境固有の「正常パターン」がまだルールに反映されていないためだ。初期チューニングを「導入ベンダーが実施する」という前提のまま本番稼働に進むと、保守フェーズに入った時点で社内に知識が残らない。導入時からチューニング作業を担う担当者を社内で指名し、変更記録をチケット管理ツールで残す体制が必要だ。担当者が1名だけの構成では、異動や退職でノウハウが消失するリスクがあるため、最低2名体制を設計の前提に置くことが望ましい。

除外ルールの肥大化を防ぐ管理設計

除外ルールは「誤検知を止めるための一時的な措置」として追加されたものが恒久化する傾向がある。追加した理由と有効期限を記録せずに積み重ねると、1年後には除外ルールが数十件を超え、誰も削除できない状態になることが多い。除外ルールを追加するたびに「いつまで有効か」「何のために除外するか」「承認者は誰か」を記録し、四半期ごとに棚卸しする運用フローを設計段階で取り決めておくことが長期的な品質維持の鍵になる。棚卸し時に有効期限を過ぎたルールは原則削除し、継続が必要であれば再審査のうえ追加し直す手順が望ましい。

定例レビューの頻度と変更時の対応

初期運用の最初の1か月はアラートが多発するため、週次でのレビューが現実的だ。誤検知率が安定した段階で月次に移行し、インフラの大きな変更（環境移行・構成拡張・OS更新など）が発生するタイミングで都度レビューを差し込む体制にする。特に本番環境への新規サービス追加時は検知ルールが新しいトラフィックパターンに対応していないことが多く、追加から2週間程度は集中的なチューニングをスケジュールに確保しておくと後手に回らない。チューニングの記録は設計書と同じ管理リポジトリで保持すると、変更の経緯が追跡しやすくなる。

検知を欲張って誤検知に埋もれ運用が止まる境界

アラート疲れが引き起こす本当のリスク

誤検知が日常化すると、担当者はアラートを確認する行動そのものをやめてしまう。「アラート疲れ」と呼ばれるこの状態に陥ると、実際の侵入アラートが大量の誤検知に埋もれて見逃されるという最悪のシナリオに直結する。構築段階で「アラートを多く出せば安全」という発想で設定を積み重ねたケースでは、導入から半年後に担当者がSIEMのダッシュボードを開かなくなったという話が現場では繰り返し聞かれる。検知の価値は件数ではなく「担当者が対応可能な量に収まっているか」という視点で評価する必要がある。

対応可能なアラート量の目安を設計に組み込む

明確な業界標準があるわけではないが、現場での経験則として「担当者1名あたり1日30件を超えるアラートが継続すると対応品質が低下し始める」という目安が語られることがある。この数字はスキルや自動トリアージの有無によって変動するが、設計段階で「チューニング前に何件のアラートが発生する見込みか」を試算し、体制と照らし合わせる作業は省略できない。チューニング前の初期段階では安定後の数倍の件数が出ることを前提に、段階的に絞り込む計画を設計書に明記しておくことが重要だ。件数の試算は导入するツールの評価環境で一定期間稼働させて実測するのが最も確実な方法だ。

欲張りすぎの設計を止める判断フレーム

「検知できること」と「検知して対応できること」は異なる。検知ルールの数を増やすよりも、対応フローが確立しているアラートの種類を着実に増やす方が運用の実効性は上がる。アラートに対して「誰が・何時間以内に・何をするか」が決まっていないルールは追加しないという設計方針も有効な選択肢だ。検知範囲を広げる提案が出たときに「そのアラートの対応フローはすでにあるか」を先に確認する習慣が、欲張りすぎの設計を抑止する実践的な手段になる。ルールの追加と対応フローの整備をセットで設計するというシンプルな原則を徹底するだけで、アラート疲れは大幅に予防できる。

侵入検知設計チェックフレーム

侵入検知の設計・導入前に確認すべき判断ポイントを以下にまとめた。全ての項目にYesで答えられない段階では、ツールの選定より前にアーキテクチャと運用体制の見直しを優先することを推奨する。手を動かす手順の詳細は専門書や実地での学習で深めてもらい、ここでは「何を決めておくべきか」の判断軸として参照してほしい。

• 検知対象の資産を「重要度別」「外向き/内向き別」に分類し、文書化済みか
• 各資産に「収集のみ」「収集＋検知」「検知＋自動遮断」のどのレベルを適用するか決定済みか
• ホスト型・ネットワーク型・エンドポイント型の守備範囲の重複と空白を設計図上で確認済みか
• 改ざん検知の対象パスを「変更されたら即対応が必要なパス」に限定し、追加根拠を記録しているか
• 初期チューニングを担う担当者を社内で指名済みか（最低2名体制か）
• 除外ルールの追加に「理由・有効期限・承認者」の記録ルールを設けているか
• 除外ルールの四半期ごとの棚卸しをスケジュール化済みか
• 担当者1名あたりの1日アラート目標件数を設定し、超過時のエスカレーションフローを定めているか
• アラートに「誰が・何時間以内に・何をするか」の対応フローが存在しないルールを除外しているか
• 本番変更・デプロイ時の検知設定一時緩和→再有効化手順が変更管理プロセスに組み込まれているか
• 資産の変化に合わせた年1回以上の検知設計見直しをスケジュールに組み込んでいるか