侵入検知・防止システム(IDS/IPS)

1. 概要

A. 定義および登場背景

侵入検知システム(IDS, Intrusion Detection System)とは、ネットワーク・ホストで発生するトラフィックとイベントを収集・分析し、攻撃・不正利用・ポリシー違反の兆候を検知して警報(alert)を発するセキュリティ体系であり、侵入防止システム(IPS, Intrusion Prevention System)はこれに加え、検知した攻撃をリアルタイムに遮断・隔離する能動的対応まで行う体系である。要するにIDSは「見て知らせる」検知者、IPSは「見て止める」遮断者であり、IPSはしばしば「IDSにインライン遮断能力を加えた進化形」と説明される。

IDS/IPSが登場した根本的背景は、「通路を開閉する統制だけでは侵入を防げない」というファイアウォールの限界認識にある。従来のネットワークファイアウォールは、送信元・宛先IPとポートを基準にアクセスを許可または遮断する。しかし、いったん許可されたポート(例:Webサービスの443)を通じて入ってくるトラフィックの中に攻撃ペイロードが隠れていると、ファイアウォールはこれを正常トラフィックと区別できない。すなわちファイアウォールは「誰がどの扉から入るか」は統制するが、「その人が中で何をするか」は見えない。この死角、すなわち許可された通信の内部で行われる悪意ある行為を監視するために、侵入検知という概念が生まれた。

歴史的にIDSは、1980年にドロシー・デニング(Dorothy Denning)が提示した侵入検知モデルに理論的ルーツを持ち、1990年代にSnortのようなオープンソースのシグネチャベースIDSが普及して大衆化した。しかし初期のIDSは攻撃を「検知して警報するだけ」で、遮断は人が事後に行わねばならなかったため、攻撃がすでに成功した後にしか対応できない限界が露わになった。ネットワーク速度が速まり、自動化された攻撃が秒単位で展開されるにつれ、検知と同時に遮断するインライン(in-line)能動的対応の必要性が高まり、これが2000年代のIPS登場につながった。今日ではアプリケーション識別・ユーザー認識・脅威インテリジェンスを結合した次世代IPS(NGIPS)へと発展し、次世代ファイアウォール(NGFW)の中核機能に吸収される流れを見せている。

B. 必要性

現代の侵害事故は、外部境界を突破した後、内部で水平移動(lateral movement)しながら長期間潜伏する様相を帯びる。境界ファイアウォール一つでは、すでに内部へ入った攻撃や内部者の不正利用を検知できないため、トラフィックとホストイベントを常時監視するIDS/IPSが多層防御(Defense in Depth)の必須層となる。規制面でもISMS-P、PCI-DSS、電子金融監督規程などはネットワーク侵入検知・遮断手段の運用とログ保存を要求しており、IDS/IPSの検知ログは事故発生時の原因究明と説明責任の中核的根拠となる。

実際、セキュリティ業界の侵害調査報告書は、攻撃者が内部に侵入してから検知されるまでの滞留時間(dwell time)が数十日に及ぶと繰り返し指摘してきた。境界だけを守る防御では、この長い潜伏期間に内部で行われる偵察・権限昇格・データ持ち出しをまったく捕捉できない。IDS/IPSはまさにこの「境界を通過した後の時間」を監視して滞留時間を短縮し、攻撃の連鎖(kill chain)が完成する前の中間段階で断ち切る機会を提供する点で、単なる警報装置を超えた検知・対応時間短縮の中核手段として位置づけられる。

C. 中核的特徴

IDS/IPSの特徴は三つに集約される。第一はコンテンツ・行動レベルの深層分析であり、パケットヘッダーだけでなくペイロードを再構成し、プロトコル文脈を解釈して攻撃か否かを判断する。第二は検知(IDS)と遮断(IPS)の役割分化であり、検知専用装置は可用性負担なく広く観察し、遮断装置は経路上で即座に対応するが、誤検知時には正常通信まで断つ危険を負う。第三は継続的なルール・モデル更新への依存性であり、新たな攻撃が絶えず登場するため、シグネチャ更新と異常行動のベースライン(baseline)再学習が運用の成否を左右する。この三つの特徴が結合し、IDS/IPSは「設置して終わる装置」ではなく「運用で完成する統制」として機能する。

2. IDS/IPSの全体構造と配置方式

IDS/IPSは単一のアルゴリズムではなく、データ収集(センサー)→分析(エンジン)→対応→管理のパイプラインとして理解すべきである。以下は全体の構成要素とデータフローを示した構造図である。

flowchart LR
  SRC["トラフィック・ホストイベント"] --> SEN["センサー:収集・正規化"]
  subgraph ENG["分析エンジン"]
    MIS["不正利用検知:シグネチャ"]
    ANO["異常検知:行動・統計"]
  end
  SEN --> ENG
  ENG --> DEC["判定:正常・攻撃・疑わしい"]
  DEC -->|IDS| AL["警報・ロギング"]
  DEC -->|IPS| BLK["遮断・セッション終了・隔離"]
  AL --> MGR["管理コンソール・SIEM連携"]
  BLK --> MGR
  MGR --> TI["脅威インテリジェンス・ルール更新"]
  TI --> ENG

この構造の出発点はセンサー(Sensor)である。センサーはネットワーク区間のパケットをスニッフィングするか、ホストのログ・システムコールを収集し、分析に先立って断片化されたパケットを再構成(reassembly)し、プロトコル単位で正規化する。攻撃者はパケットを細かく分割したりTTLを操作したりして検知を回避しようとするため、センサーの再構成・正規化の品質が、その上のすべての検知精度を左右する隠れた土台となる。続いて分析エンジンが不正利用検知と異常検知を併行して判定し、IDSは警報・ロギングで、IPSはセッション遮断・リセット・隔離で対応し、すべての結果は管理コンソールとSIEMへ収束して相関分析とルール更新に活用される。

A. ネットワークベース(NIDS/NIPS)とホストベース(HIDS/HIPS)

IDS/IPSを貫く第一の設計軸は「どこで観察するか」である。ネットワークベース(NIDS/NIPS)はネットワークセグメントにセンサーを置き、通過するパケット全体を監視する。一台で多数のホストを包括でき、可視性が広くホスト性能に影響を与えないが、暗号化されたトラフィックの内部は復号なしには見えず、スイッチング環境ではミラーポート(SPAN)やネットワークTAPを通じてトラフィックの複製を受け取らねばならない。大規模トラフィック区間ではセンサーの処理性能がボトルネックとなり一部のパケットを取りこぼすドロップ(drop)が発生しうるため、回線速度に合わせた性能設計が重要である。

ホストベース(HIDS/HIPS)は個々のサーバー・端末にエージェントを設置し、ファイル完全性の変化、レジストリ・システムコール、ログイン履歴、プロセス行動を監視する。暗号化が解かれた終端で実際の実行を見るため、ネットワークが見られない内部不正利用・権限昇格を正確に検知するが、ホストごとにエージェントを配布・管理せねばならず、ホスト資源を消費し、攻撃者がホストを掌握するとエージェント自体が無力化されうる。代表的にはファイル完全性検査ツールOSSEC・Wazuh、Windowsイベントベースの検知がHIDSの範疇に入る。

実務では両者を相互補完的に結合する。例えばDMZ区間と内部コアスイッチにはNIDS/NIPSでトラフィックを広く監視し、決済・認証サーバーのように重要度が高いホストにはHIDSを追加してネットワークが見られない内部改ざんを精密に補強する、という具合である。近年ではホストベースの検知がEDR(Endpoint Detection and Response)へ、ネットワークベースの検知がNDR(Network Detection and Response)へそれぞれ発展し、この二つを統合するXDRへ収束している。

B. パッシブ(IDS)配置とインライン(IPS)配置

第二の軸は「トラフィック経路に割り込むか」である。パッシブ(Passive)配置は、センサーがトラフィック経路の外でミラーリングされた複製のみを受け取って検知・警報する。元のトラフィックに遅延を与えず、装置障害がサービス中断に直結しないため可用性負担がないが、攻撃を「発見」するだけで「遮断」できず、検知と対応の間に時間的隔たりが生じる。典型的なIDSがこの方式である。

インライン(In-line)配置は、センサーがトラフィック経路上に置かれすべてのパケットが装置を通過するため、攻撃と判定されたセッションを即座に破棄(drop)するか、TCPリセットで断つことができる。IPSがこの方式を採る。その代わり装置がそのまま単一障害点(SPOF)かつ遅延要因となり、誤検知が発生すると正常通信まで遮断されサービス障害に波及する。このためインライン装置は障害時にトラフィックを通すか(fail-open)遮断するか(fail-close)をサービス特性に合わせてあらかじめ決定し、二重化・バイパススイッチとともに設計せねばならない。可用性が最優先の公共ポータルはfail-openを、金融・機密網はfail-closeを選ぶ、という形で組織の優先順位が反映される。

C. 検知・対応の処理フロー

以下は一つの疑わしいトラフィックがセンサーから判定・対応まで至るプロセス詳細図である。

sequenceDiagram
  participant N as 攻撃者・内部者
  participant S as センサー NIPS
  participant E as 分析エンジン
  participant T as 対象サーバー
  participant M as SIEM・管理者
  N->>S: パケット流入セッション
  S->>S: 再構成・正規化
  S->>E: 正規化ストリーム転送
  E->>E: シグネチャマッチング + 異常スコア算定
  alt 攻撃と判定 - インライン
    E-->>N: セッション遮断・TCP Reset
    E->>M: 警報・ログ - ルールID・ペイロード
  else 正常
    S->>T: トラフィック転送
  end
  M->>E: 相関分析後にルール・閾値を更新

3. 検知手法 — 不正利用検知と異常検知

IDS/IPSの心臓は「何を根拠に攻撃と判断するか」であり、これは大きく二つの系統に分かれる。

A. 不正利用検知(Misuse / Signature-based Detection)

不正利用検知は「既知の悪いものを防ぐ」という接近であり、すでに分析された攻撃の特徴(シグネチャ・パターン・ルール)をデータベースに登録しておき、トラフィックがこれと一致すれば攻撃と判定する。例えばSnortルールはalert tcp any any -> 192.168.0.0/24 80 (content:"/etc/passwd"; ...)のように、特定の文字列・ポート・方向を条件として記述する。この方式は既知の攻撃に対する検知精度が高く誤検知が少なく、判定根拠が明確であるという長所があり、現場のIDS/IPSの一次防衛線として広く使われる。

しかし不正利用検知は本質的に「過去に見た攻撃」しか検知できず、シグネチャにない新種・変種・ゼロデイ攻撃を取りこぼす見逃し(false negative)が構造的限界である。攻撃者はペイロードをエンコードしたり順序を変えたりする小さな変種だけでシグネチャを回避し、これを防ぐにはシグネチャを絶えず追加せねばならずルールセットが肥大化して性能が低下する。2017年にWannaCryランサムウェアが急速に拡散した際、当該SMB脆弱性(EternalBlue)のシグネチャが配布される前の短い空白期に被害が集中したことは、不正利用検知の時差の限界を示す代表的事例である。

B. 異常検知(Anomaly-based Detection)

異常検知は正反対に「正常の基準線を立て、そこから外れるものを疑う」という接近である。平常時のトラフィック量・プロトコル分布・接続時間帯・ユーザー行動などを学習して正常プロファイル(baseline)を作り、統計的に有意に逸脱する行動に異常スコアを付ける。この方式の最大の価値は、シグネチャのない新種・ゼロデイ攻撃と内部者の異常行動まで検知できる点である。例えば普段は業務時間にのみ少量接続していたアカウントが深夜に大量のデータを外部へ送信すれば、シグネチャには掛からなくても異常検知はこれを捕捉する。

異常検知の弱点は誤検知(false positive)が多いことである。正常トラフィックが急変する状況(プロモーションによる接続急増、新規サービス配備)を攻撃と誤認しやすく、基準線の学習データにすでに攻撃が混ざっていれば攻撃を正常と学習する誤りも発生する。したがって異常検知は導入初期の一定期間、遮断なしに観察する学習モードで運用して基準線を精緻化し、閾値を保守的に調整するチューニングが必須である。近年では機械学習・深層学習を適用して多次元の特徴から微妙な異常を捕捉するUEBA(User and Entity Behavior Analytics)へ高度化しているが、判断根拠を説明しにくいブラックボックス問題と説明可能性(XAI)の確保という課題も併せて抱えている。

C. 二つの手法・IDS/IPS類型の比較

現場のIDS/IPSは二つの手法を併行し、既知の脅威は不正利用検知で速く正確に防ぎ、未知の脅威は異常検知で補完する。以下の表は中核の軸を比較整理したものだが、差が生じる理由を併せて理解せねばならない。

区分	不正利用検知(シグネチャ)	異常検知(行動)
判断根拠	既知の攻撃パターン一致	正常基準線からの逸脱
新種・ゼロデイ	検知不可(見逃し)	検知可能
誤検知率	低い	高い
根拠説明	明確(ルールID)	困難(統計・モデル)
運用負担	ルールの継続更新	基準線の学習・チューニング

比較軸	IDS	IPS
主機能	検知・警報	検知・遮断
配置	パッシブ(ミラー・TAP)	インライン
遅延・SPOF	なし	あり
誤検知の影響	警報過多	正常通信の遮断
代表製品	Snort(IDSモード)、Zeek	Suricata、NGIPS、Snort(インライン)

IPSがIDSより常に優れているわけではない。遮断能力は強力だが誤検知一件がそのままサービス障害に直結するため、検知信頼度が十分に検証される前には遮断せず検知のみを行うIDSモードで運用するのが安全である。すなわちIDSとIPSは世代交代の関係ではなく、同じエンジンを可用性・セキュリティの優先順位に応じて異なるモードで運用する選択肢と見るのが正確である。

D. 検知性能指標 — 誤検知・見逃しの数値的理解

IDS/IPSの運用の成否は結局「検知精度をどう測定・管理するか」に帰着するため、混同行列(confusion matrix)に基づく指標を定量的に理解せねばならない。攻撃を攻撃と当てれば真陽性(TP)、正常を攻撃と誤認すれば偽陽性(FP, 誤検知)、攻撃を取りこぼせば偽陰性(FN, 見逃し)である。中核の指標は実際の攻撃をどれだけ取りこぼさないかを見る検知率(再現率, Recall=TP/(TP+FN))と、警報のうち実際の攻撃の比率である精度(Precision=TP/(TP+FP))であり、両者を調和平均したF1が均衡の尺度として使われる。

例えば一日100万件のセッションのうち実際の攻撃が1,000件の環境で、検知率99%・誤検知率(FP rate)0.1%のIPSを仮定しよう。攻撃990件を捕らえる(TP=990)が、正常99万9,000件の0.1%である約999件を誤検知する(FP≈999)。このとき精度は990/(990+999)≈49.7%で、「警報の半分が空振り」となる。これがセキュリティで悪名高い基底率の誤謬(base-rate fallacy)である。正常トラフィックが攻撃より圧倒的に多いため、いくら誤検知率が低く見えても絶対的な誤検知件数が攻撃件数を圧倒し、運用チームを「警報疲労(alert fatigue)」に陥れる。したがってIPSチューニングの目標は単に検知率を上げることではなく、リスクに基づいて警報に優先順位を付け、SIEM相関分析で精度を引き上げ、実際に対応すべき警報のみを残すことでなければならない。

4. 深化 — NGIPS・回避手法・実務適用

従来のIPSはポート・プロトコル・シグネチャに依存し、非標準ポートで回避したりアプリケーション層で変種化する攻撃に脆弱だった。これを克服するために登場した次世代IPS(NGIPS)は、①ポートと無関係に実際のアプリケーションを識別するアプリケーション認識(App-ID)、②IPではなくユーザー単位でポリシーを適用するユーザー認識、③外部の評判・IoC(侵害指標)をリアルタイムに反映する脅威インテリジェンス連携、④悪性が疑われるファイルを隔離環境で実行してみるサンドボックスを統合した。今日のNGIPSは独立装置よりも次世代ファイアウォール(NGFW)の統合モジュールとして提供される場合が多く、ファイアウォール・IPS・アプリケーション制御が一台の装置に収束する流れにある。

一方、攻撃者は検知を避けるために多様な回避(evasion)手法を駆使する。パケットを細かく分割して再構成を妨げるフラグメント攻撃、TTLを操作してセンサーと対象サーバーの再構成結果を異ならせる手法、ペイロードを多重エンコード・難読化する手法、そしてトラフィックを暗号化してそもそもセンサーが内容を見られなくする方法が代表的である。特に今日のトラフィックの大半がTLSで暗号化されるにつれ、IPSが内容を見るにはSSL/TLS復号(可視性の確保)が必要だが、これは性能負担とともに復号地点に平文の機密情報が露出する新たな危険を生む。復号範囲・鍵管理・プライバシー影響評価を併せて設計せねばならない理由である。

オープンエコシステムの面でもIDS/IPSは成熟している。事実上の業界標準となったSnortはルール文法とコミュニティルールセットで新規脅威に素早く対応できるようにし、マルチスレッドアーキテクチャで高速回線を処理するSuricataは同じルール文法を共有しつつプロトコル自動識別・ファイル抽出・TLSメタデータロギングを加え、Zeek(旧Bro)はシグネチャではなくネットワーク行動ログ中心の分析で脅威ハンティングに広く使われる。このように商用・オープンソースが混在する環境では、ルールセットをコードのようにバージョン管理・テスト・配備するルール管理体系(Policy as Code)が運用品質を左右する。

実務適用事例として、金融圏はインターネット区間と内部網境界にNIPSをインラインで置いて外部攻撃を遮断し、内部の重要サーバーにはHIPSを載せて権限昇格・ファイル改ざんを検知し、すべての警報をSIEMに集めてSOARプレイブックで自動対応(IP遮断・セッション隔離)する多層体系を運用する。予想される出題方向としては、▲不正利用検知と異常検知のトレードオフと状況別の選択を論じよ、▲IDSとIPSの配置・運用上の違いを述べよ、▲暗号化トラフィックの増加がIPSに与える影響と対応を提示せよ、▲IPS・WAF・EDR・ファイアウォールを比較し多層防御の設計を提示せよ、などが有力である。

5. 考慮事項および示唆点(技術士の観点)

IDS/IPSを成功裏に定着させるには、「装置の導入」ではなく「運用能力とプロセス」の観点から接近せねばならない。技術士の答案では以下のトレードオフと戦略を併せて論じるべきである。

誤検知・見逃しの均衡(セキュリティ-可用性のトレードオフ):遮断を強く掛けるほど見逃しは減るが、誤検知で正常通信が断たれサービス障害と運用チームの「警報疲労(alert fatigue)」を招く。新規ルールは必ずIDS(検知専用)モードで十分に観察して誤検知をチューニングした後にIPS(遮断)モードへ段階的に転換し、IDS/IPSは「設置して終わり」ではなく継続的チューニングを前提とした運用型統制であることを認識せねばならない。
暗号化トラフィックと可視性の確保:トラフィックの大半が暗号化された今日、復号なしにはIPSがペイロードを検査できない。全面復号は性能・プライバシー負担を生むため、重要度の高い区間のみ選別的に復号し鍵をHSMで保護し、復号しない区間はJA3フィンガープリント・メタデータベースの暗号トラフィック分析(ETA)で補完する設計が必要である。
性能・拡張性とSPOF対応:インラインIPSは回線速度に合わせて無停止で処理せねばならないため、処理性能超過時にパケットドロップ・遅延が発生する。二重化・オートスケーリング・ハードウェアバイパスとfail-open/fail-closeポリシーをサービス特性に合わせて明確に定義せねばならず、これは可用性とセキュリティのいずれを優先するかという経営的判断である。
SIEM・SOAR連携と対応自動化:IDS/IPSの警報はそれ自体で完結せず、SIEMで収集・相関分析しSOARプレイブックで遮断・隔離・チケット発行を自動化してこそ検知から対応までの時間(MTTR)を縮められる。MITRE ATT&CKフレームワークに警報をマッピングすれば、攻撃段階別の検知空白を体系的に識別・補強できる。
連携技術・展望:IDS/IPSはファイアウォール・WAF・EDR・NDRと役割を分担して多層防御をなし、ホスト・ネットワーク検知を統合するXDRとML基盤のUEBAへ進化している。ただし生成AIを活用した攻撃の自動変種が増えるにつれ、防御側も適応型検知を強化せねばならず、AI基盤検知のブラックボックス問題に対応する説明可能性(XAI)の確保が今後の課題として残る。また、ゼロトラストアーキテクチャでは境界中心のIPSを超え、内部の東西(East-West)トラフィックまで監視するマイクロセグメンテーションとの結合が重要になる。

参考資料

NIST SP 800-94, "Guide to Intrusion Detection and Prevention Systems (IDPS)", https://csrc.nist.gov/pubs/sp/800/94/final
Snort, "Snort Rules and Documentation", https://www.snort.org/documents
Suricata, "Suricata Open Source IDS/IPS", https://suricata.io/
MITRE, "ATT&CK Framework", https://attack.mitre.org/
OWASP, "Intrusion Detection", https://owasp.org/www-community/controls/Intrusion_Detection

一言まとめ: IDS/IPSはファイアウォールが見られない許可トラフィック内部の攻撃を、センサー→分析(不正利用・異常検知)→対応のパイプラインで監視する多層防御層であり、IDSはパッシブ検知・警報、IPSはインライン遮断を担い、NGIPS・XDR・UEBAへ進化するが、誤検知・見逃しの均衡、暗号化の可視性、SPOF、SIEM/SOAR連携が運用の中核課題である。