IDS/IPSの設置場所｜ネットワーク型・ホスト型の置き方をFW直下と重要セグメントで解説

「IDS/IPSを導入したのに、攻撃の検知も遮断もできなかった」——これは多くの中小企業の情シス担当者が口にする失敗談です。原因の8割は製品選定ではなく、設置場所の選び方にあります。FW（ファイアウォール）の外側に置くのか内側に置くのか、ホスト型をどのサーバーから入れるのか、SPANポートとTAPのどちらを使うのか。この一つひとつの判断が、誤検知率と検知精度を左右します。

この記事では、IDS/IPSの設置場所について、ネットワーク型とホスト型のそれぞれを、FW直下・重要セグメント間・公開サーバー・管理系サーバーといった具体的な配置パターンで解説します。中小企業向けの最小構成例、SPAN/TAPの設定実例、AWS/Azureでのトラフィックミラーリングのコツまでカバーするので、設置場所に迷っている担当者は最後まで目を通してみてください。なお、IDS/IPSそのものの基礎概念はIDS/IPSとは？侵入検知・防御の仕組みと選び方で解説しているので、必要に応じて先にそちらを参照してください。

IDS/IPSの設置場所が運用成否を決める理由

IDS/IPSの精度は、製品の優劣よりも「どこに置くか」で決まります。理由はシンプルで、観測できないトラフィックは検知も遮断もできないからです。たとえばインターネット境界のFW外側に置けば攻撃の試行回数は大量に見えますが、ブロックされた無害なパケットも全部拾うため誤検知が膨らみます。逆にFWの内側で重要セグメント間に置けば、攻撃成功後の横展開（ラテラルムーブメント）を捉えやすくなります。

設置場所を間違えたときに起きる典型的な症状は3つです。1つ目は「アラートが多すぎて見ない運用」になること。FW外側に置いたNIDSがポートスキャンを毎分検知し、本当に重要なシグナルが埋もれます。2つ目は「内部脅威を見逃す」こと。境界だけ守って内部セグメントが素通しだと、感染端末からのC2通信が検知されません。3つ目は「コンプライアンス要件を満たせない」こと。PCI DSSやISMSの内部監査では、カード情報を扱うセグメント前段でのIDS/IPS設置が事実上必須です。

覚えておきたいのは、「IDS/IPSは1台で全部を見る装置ではない」という前提です。境界・内部・ホスト、それぞれに役割を分担させて、初めて多層防御が機能します。1台で何でもやろうとすると、誤検知の山に埋もれて結局誰も見なくなる、というのが現場でよく起きる失敗パターンです。

ネットワーク型（NIDS/NIPS）の置き方｜FW直下と重要セグメント間

ネットワーク型は、ネットワーク機器のミラーポートやインライン配置で通信を観測する形式です。中小企業の場合、最初に置くべきは「FW直下のDMZ前」一択と考えてください。理由は、FWで明らかな不正パケットがブロックされた後の通信を観測するため、誤検知が大幅に減るからです。

1. FW直下に置くべき5つの根拠

・FWのフィルタ後: ポートスキャンや明らかな不正パケットはFWで落ちるため、IDSが見るトラフィックの質が向上します
・公開サーバー狙いの攻撃を直撃: Webサーバー・メールサーバーへの実際の侵入試行を捉えやすい
・SSL終端後の通信が見える可能性: ロードバランサーをFW直下に置く構成なら、復号後のHTTPを観測できる
・運用負荷が低い: 観測点が1箇所に絞れるため、ルールチューニングも一元化できる
・ログ容量の見積もりが楽: トラフィック量がほぼ固定で、ストレージ計算がしやすい

2. 重要セグメント間に追加するタイミング

FW直下のNIDS/NIPSが安定運用に乗ったら、次は内部セグメント間に2台目を置きます。具体的にはこんなセグメント境界です。

・業務LAN ⇔ サーバーセグメント: 感染端末からの内部スキャンや認証アタックを検知
・社内VLAN ⇔ 経理・人事システム: 個人情報・財務情報セグメントへの不正アクセスを早期発見
・VPN着信 ⇔ 社内LAN: テレワーク端末経由の侵入を境界で止める
・製造ライン（OT）⇔ 情報系LAN: 工場系システムへの攻撃を専用ルールで検知

3. インライン配置とパッシブ配置の選び方

ネットワーク型には2つの設置形態があります。最初は必ずパッシブで運用し、誤検知を3か月ほど見極めてからインラインに切り替える、という段階移行が事故を防ぎます。

ホスト型（HIDS/HIPS）の対象サーバー選定基準

ホスト型は、サーバー1台ごとにエージェントを入れて、ファイル改ざん・プロセス起動・ログイン試行などを監視します。すべてのサーバーに入れるのが理想ですが、現実にはライセンス費用と運用負荷の制約から、優先順位をつける必要があります。

1. ホスト型の優先導入リスト

中小企業で限られたライセンス枠を最も活かすなら、次の順番で導入を進めます。

・優先度1: インターネット公開サーバー全台（Web・メール・DNS・VPN装置）— 攻撃を直接受けるため最優先
・優先度2: 認証基盤（Active Directory・LDAP・RADIUS）— ここを取られると全部取られる
・優先度3: データベースサーバー（顧客DB・販売管理DB）— 情報漏洩の最終標的
・優先度4: ファイルサーバー（共有フォルダ）— ランサムウェアの被害集中ポイント
・優先度5: 管理サーバー（監視・バックアップ・パッチ配信）— 攻撃者の足場になりやすい
・優先度6: 一般業務PC— EDR/XDRで代替を検討

2. ネットワーク型でカバーできない領域を埋める

ホスト型を入れる最大の理由は、ネットワーク型では絶対に見えない領域があるからです。

・暗号化通信の中身: HTTPS/SSH/RDPの内部はNIDSでは復号しない限り見えない
・ローカル操作: コンソールログイン・USB経由の操作はネットワークを流れない
・ファイル改ざん: /etc/passwdの書き換え、Webコンテンツへのバックドア埋め込み
・権限昇格: sudoの不正使用、SUID権限の悪用
・マルウェアの起動: プロセス生成・サービス登録の異常検知

3. HIDS/HIPS製品の代表例とリソース消費

ホスト型は常駐エージェントなので、サーバーのCPU・メモリを消費します。本番サーバーに入れる前に、必ず開発環境で負荷を測定してください。一般的な目安は、CPU 5〜15%増、メモリ 200〜500MB増、ディスクI/O 10〜20%増程度です。

設置位置の決定フロー（パッシブ→インライン段階移行）

設置場所を決めるときは、感覚ではなく決定フローで進めると失敗が減ります。実際に現場で使ってきた手順を共有します。

1. STEP1: 守るべき情報資産の洗い出し

まず「何を守るか」を決めない限り、置き場所は決まりません。情報資産を3段階に分類します。

・機密度A: 個人情報・カード情報・営業秘密 → セグメント分離＋NIDS＋HIDS両方
・機密度B: 業務データ・社内システム → セグメント分離＋NIDSで監視
・機密度C: 公開情報・社外資料 → 境界NIDSで一元監視

2. STEP2: 機密度Aセグメントの境界に観測点を置く

機密度Aを扱うセグメント（例: 経理セグメント、開発系の本番DBセグメント）の入口に、最初のNIDSを置きます。中小企業の場合、ここで初めて「内部にIDS/IPSを置く」ことになるケースが多いはずです。

3. STEP3: 公開サーバーにHIDSを展開

同時並行で、インターネット公開サーバーにHIDS（Wazuhなど）のエージェントを展開します。公開サーバーは攻撃を直接受けるため、ネットワーク型の検知だけでは間に合わないケースが多いからです。

4. STEP4: パッシブで3か月運用→誤検知を潰す

導入直後にインライン（IPS）モードで動かすのは絶対に避けてください。最初の3か月はパッシブ（IDS）で運用し、業務通信の特徴を学習させながらシグネチャの除外設定を入れます。誤検知の典型例は、社内独自プロトコル・グループウェアの定期Pollingリクエスト・バックアップソフトの大量転送などです。

5. STEP5: 重要シグネチャからインライン化

3か月の観測で誤検知が落ち着いたら、リスクの高いシグネチャから順にインライン（遮断）モードに切り替えます。一度に全シグネチャをインライン化すると、業務停止のリスクが跳ね上がります。SQLインジェクション・既知のCVE悪用・C2通信あたりから始めて、3〜6か月かけて段階拡大するのが安全です。

中小企業向け最小構成例（外部接続点1点＋公開サーバー全台）

「ライセンス予算が限られているけど、最低限のIDS/IPS体制を組みたい」という相談をよく受けます。社員30〜100名規模、情シス担当が1〜2名の中小企業を想定した最小構成を紹介します。

1. 推奨される最小構成

・NIDS 1台: 外部接続点（FW直下）にパッシブ配置。OSSのSuricataで開始
・HIDS 公開サーバー全台: Wazuhエージェントを公開Web・メール・VPN装置に導入
・HIDS 認証基盤: Active Directoryまたは社内認証サーバー1台
・SIEM代わりのログ集約: Wazuhのマネージャーが兼ねるため追加コスト不要
・遮断機能: 当面はFWのIP遮断連携で対応、IPS化は半年後に検討

2. 初期コストの目安（OSSベース）

OSSのSuricata + Wazuh構成なら、ライセンス費用はゼロです。初期コストは主にハードウェアと構築工数になります。

なお上記85〜155万円は外部委託前提の初期コスト試算です。ハブ記事の年間ランニング目安（OSSで30〜100万円/年）と合わせて、3年トータルでの投資判断を行ってください。

3. 3年以内に拡張すべき2台目以降

初期構成が安定したら、内部セグメント間に2台目のNIDSを追加します。1台目で外部攻撃を、2台目で内部不正・横展開を見る、という多層配置が完成形です。

設置場所別のミラーポート/SPAN設定実例

ネットワーク型を設置するときに必ず登場するのが、SPANポート（Switched Port Analyzer）とネットワークTAPです。両者の違いと、実際の設定例を見ていきます。

1. SPANポート vs ネットワークTAP

中小企業では、まずSPANポートで開始してパケットロスが問題になったらTAPへ切り替える、という運用がコストパフォーマンスに優れます。

2. Cisco IOSでのSPAN設定例

Cisco Catalystシリーズで、VLAN10とVLAN20のトラフィックをポートGi1/0/24にミラーする設定です。

# 動作確認: Cisco Catalyst 9300 / IOS XE 17.x系（2960系・3850系もコマンド互換）
# 監視セッション1を作成
Switch(config)# monitor session 1 source vlan 10 , 20 rx
Switch(config)# monitor session 1 destination interface Gi1/0/24

# 設定確認
Switch# show monitor session 1
Session 1
---------
Type                   : Local Session
Source VLANs           :
    RX Only            : 10,20
Destination Ports      : Gi1/0/24

# 注意: 双方向観測したい場合は rx を both に変更
# Switch(config)# monitor session 1 source vlan 10 , 20 both

3. YAMAHAルーターでのミラーリング設定例

YAMAHA RTX1300シリーズで、LAN1のトラフィックをLAN3にミラーする例です。中小企業ではYAMAHAユーザーが多いので併記します。

# 動作確認: YAMAHA RTX1300 / Rev.23以降（RTX1210/RTX1220 Rev.14系も同コマンド）
# LAN1の通信をLAN3にミラー
mirroring interface lan3 lan1 in
mirroring interface lan3 lan1 out

# 設定保存
save

# 確認
show config | grep mirroring

4. SuricataのインターフェースとAFパケット設定例

Suricata側でミラー受信用インターフェースを正しく設定しないと、せっかくのトラフィックが取りこぼされます。Linux上でAF_PACKETを使う設定例です。

# 動作確認: Suricata 7.0.x（Linux ens192インターフェース）
# /etc/suricata/suricata.yaml の抜粋
af-packet:
  - interface: ens192
    threads: 4
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes
    use-mmap: yes
    mmap-locked: yes
    tpacket-v3: yes
    ring-size: 200000
    block-size: 32768

# プロミスキャスモードを有効化（受信用インターフェース）
ip link set ens192 promisc on

# Suricata起動
systemctl restart suricata

# パケット取りこぼしの確認
suricata --build-info | grep AF_PACKET
tail -f /var/log/suricata/stats.log | grep capture.kernel_drops

5. SPAN設定でやりがちな失敗3つ

・送信元ポートと送信先ポートのVLAN混在: 同じVLAN内で循環してしまい、ループ警告が出る
・SPAN先ポートで通常通信を流す: ミラー専用ポートで業務通信を流すと、ループや輻輳が発生する
・双方向ミラー忘れ: rx onlyのまま運用して、送信側パケットが見えていない

クラウド環境（AWS/Azure）でのトラフィックミラーリング

クラウドに移行した環境でも、IDS/IPSの設置場所の考え方は基本的に変わりません。ただし、SPANポートに相当する機能はクラウドベンダーが提供する「トラフィックミラーリング」を使う形になります。

1. AWS VPC Traffic Mirroringの設定手順

AWSでは、ENI（Elastic Network Interface）単位でVPC Traffic Mirroringを設定できます。EC2インスタンスのトラフィックをコピーして、別のEC2上のSuricataで受信する流れです。

# 動作確認: AWS CLI v2.15.x / 対象EC2はNitroベース必須（C5/M5/R5/T3以降）
# AWS CLIでのトラフィックミラーリング設定例

# 1. ミラーターゲット（受信先のSuricata ENI）を作成
aws ec2 create-traffic-mirror-target \
    --network-interface-id eni-suricata1234567 \
    --description "Suricata IDS Target"

# 2. ミラーフィルタ（取得するトラフィックの条件）を作成
aws ec2 create-traffic-mirror-filter \
    --description "All inbound and outbound"

# 3. ミラーフィルタにルールを追加（全トラフィック受信）
aws ec2 create-traffic-mirror-filter-rule \
    --traffic-mirror-filter-id tmf-xxxxxxxxxxxxx \
    --traffic-direction ingress \
    --rule-number 100 \
    --rule-action accept \
    --protocol -1 \
    --destination-cidr-block 0.0.0.0/0 \
    --source-cidr-block 0.0.0.0/0

# 4. ミラーセッションを作成（観測対象ENIをひもづけ）
aws ec2 create-traffic-mirror-session \
    --network-interface-id eni-target1234567 \
    --traffic-mirror-target-id tmt-xxxxxxxxxxxxx \
    --traffic-mirror-filter-id tmf-xxxxxxxxxxxxx \
    --session-number 1 \
    --virtual-network-id 12345

2. AWS構成での注意点

・対応インスタンスタイプの確認: Nitroベースのインスタンス（C5/M5/R5/T3以降）のみ対応。旧世代（M4/C4/T2等）は非対応のため、観測対象EC2と受信側Suricata用EC2の両方をNitro系で揃える必要があります。
・VXLANカプセル化: ミラートラフィックはVXLANで包まれるため、Suricata側のデコード設定が必要
・料金: ミラーセッション1つあたりおよそ$0.01/時間、転送データ量にも課金
・マルチAZ構成: アベイラビリティゾーン跨ぎは追加費用がかかるため、IDS用サブネットは観測対象と同じAZに配置

3. Azure Virtual Network TAPの代替策

AzureにはVirtual Network TAPという機能がありますが、提供地域が限定的です。代替策として次の選択肢があります。

・Network Watcherのパケットキャプチャ: 短時間のスポット観測には有効、常時監視には不向き
・NVA（Network Virtual Appliance）方式: PaloAlto・FortiGateなどをインライン配置
・HIDS主体の構成: VM単位でWazuhエージェントを入れ、ネットワーク観測を最小化
・Azure Firewall Premium: IDS/IPSシグネチャ検知機能が組み込み済み

4. クラウドネイティブのIDS/IPSサービス

自前でSuricataを建てずに、クラウドベンダーやサードパーティのマネージドサービスを使う選択肢もあります。中小企業ではこちらの方が運用負荷が低く、現実的なケースが多いです。

運用開始前の設置場所確認10項目

IDS/IPSの本番投入前に確認すべき項目をチェックリストにまとめました。1つでも未確認のものがあれば、本番投入は延期した方が安全です。

・1. 観測点の通信量: 設置箇所のピーク時bps/ppsを実測し、IDS機器の処理性能と比較した
・2. ミラー方式の決定: SPANかTAPか、SPAN先ポートのVLAN分離を確認した
・3. パケットロス監視: capture.kernel_drops相当の指標を監視に組み込んだ
・4. ログストレージ容量: 90日分のフルパケット保管に必要な容量を確保した
・5. アラート通知経路: メール・Slack・Teamsなど、運用担当に届く経路を確認した
・6. 誤検知除外リスト: 社内グループウェアや独自プロトコルの除外を事前登録した
・7. インラインの障害時動作: バイパス機能（フェールオープン）の動作確認をした
・8. パッシブ運用期間の合意: 最低3か月のパッシブ運用について経営層・現場の合意を得た
・9. シグネチャ更新方式: 自動更新か手動更新か、頻度と検証手順を決めた
・10. 緊急停止手順: 業務影響が出たときの緊急停止・バイパス手順を文書化した

誤検知の対処は次のステップ

設置場所が決まったら、次にぶつかる壁が「誤検知の山」です。導入直後のNIDSは1日数千件のアラートを出し、運用担当が疲弊して見なくなる、というのがよくあるパターンです。誤検知の減らし方・チューニングの考え方は別記事「IPSの誤検知を減らすチューニング手順」で詳しく解説しているので、運用フェーズに入ったらそちらも参照してください。

また、「IDSとIPSのどちらを選ぶべきか」「シグネチャ型と異常検知型の違いは何か」といった製品選定の判断軸については、ハブ記事のIDS/IPSとは？侵入検知・防御の仕組みと選び方で整理しています。設置場所を決める前段階で迷っている方は、まずそちらから読み進めると判断材料が揃います。

よくある質問（FAQ）

Q1. NIDSとNIPSは同じ機器で兼用できますか？

多くの商用製品（PaloAlto・Fortinet・Cisco Firepower等）は、設定変更だけでパッシブ（IDS）モードとインライン（IPS）モードを切り替えられます。OSSのSuricataも同様で、af-packetとnfqueueの設定切り替えで両方に対応します。最初はIDSモードで運用を始め、誤検知が落ち着いてからIPSモードに移行するのが定石です。一度に両モードを別ポートで動かすこともできますが、機器負荷が増えるため通信量が多い環境では避けたほうが無難です。

Q2. ホスト型を全サーバーに入れるのは現実的ですか？

ライセンス予算とサーバー台数次第です。サーバー20台以下の中小企業ならOSSのWazuhで全台導入が現実的です。50台を超えると商用EDR/XDRに切り替えた方が運用負荷が下がります。優先順位としては、インターネット公開サーバー → 認証基盤 → DBサーバーの順で、最低限この3カテゴリだけでも入れると体制が大きく変わります。エージェントの常駐負荷を心配する声もよく聞きますが、Wazuhで実測するとCPU 5〜10%増、メモリ300MB程度で、本番運用に耐えるレベルです。

Q3. SPANポートとTAPはどちらを優先すべきですか？

中小企業の1Gbps以下の環境ならSPANポートで十分です。導入コストがゼロで、スイッチの設定変更だけで運用できます。TAPを検討すべきなのは、①10Gbps以上の高速回線、②パケットロスがコンプライアンス上許されない環境、③エラーパケットも含めて観測したいフォレンジック用途、のいずれかに該当する場合です。最初はSPANで開始してパケットロス（capture.kernel_drops）を3か月モニタし、問題が出たらTAPに切り替える運用が現実的です。

Q4. クラウド移行後はIDS/IPSは不要になりますか？

不要にはなりません。AWS GuardDutyやAzure Defenderなどクラウドベンダーが提供する脅威検知サービスは、VPCフローログやAPI操作ログから異常を検知しますが、ペイロードレベルのシグネチャ検知はカバー範囲が限定的です。Webアプリへの攻撃検知は別途WAFが必要ですし、横展開の検知にはVPC Traffic Mirroring + Suricataのような仕組みが有効です。「クラウドだから安全」という思い込みは禁物で、責任共有モデルでユーザー側が守るべき範囲を理解した上で、IDS/IPSの配置を再設計してください。

Q5. パッシブ運用の3か月は長すぎませんか？早めにIPS化したいのですが

気持ちはよく分かります。ただ、現場で2週間でIPS化に踏み切って、業務通信を遮断してしまった事例を何件も見てきました。バックアップソフトの大量転送がDDoS判定された、グループウェアの定期Pollingが偵察行為と検知された、社内独自プロトコルがマルウェア通信と判定された、といった失敗です。3か月という期間は、月次・週次・日次の業務サイクルを一通り観測するために必要な最低期間と考えてください。どうしても急ぐ場合は、SQLインジェクションや既知CVEの悪用など、誤検知が極めて少ないシグネチャだけ先行してIPS化する「部分インライン化」も選択肢です。

Q6. Suricataのインターフェース設定で「cluster-type: cluster_flow」と「cluster-type: cluster_cpu」はどう使い分けますか？

cluster_flowはフローID単位でCPUに分散するため、TCPセッションの完整性を保ったまま並列処理ができ、中小企業の標準推奨です。一方cluster_cpuは単純なCPU負荷分散で、フローの断面でパケットが別CPUに振り分けられるため、TCPセッションをまたぐ深い解析が困難になる場合があります。マルチキューNICやXDPと組み合わせる10Gbps級の高速環境向けで、1Gbps以下の通常環境ではcluster_flow一択と考えてよいです。

本記事のまとめ

IDS/IPSの設置場所は、製品選定よりも運用成否を左右する重要な決定事項です。中小企業の標準解はシンプルで、ネットワーク型はFW直下にパッシブ配置、ホスト型は公開サーバー全台と認証基盤への展開、運用が安定したら重要セグメント間に2台目を追加、という段階拡張です。

設置場所を決める判断軸として、本記事で紹介した「機密度A/B/Cで分類→境界に観測点を置く→3か月パッシブ運用→重要シグネチャからインライン化」のフローを参考にしてみてください。SPANポートとTAPの選択、AWS VPC Traffic Mirroringの設定、運用開始前の10項目チェックリストも、現場で繰り返し使ってきたノウハウです。

IDS/IPSの基礎概念や製品選定の考え方はIDS/IPSとは？侵入検知・防御の仕組みと選び方で、誤検知のチューニング手順はIPSの誤検知を減らすチューニング手順で別途解説しています。導入フェーズ・運用フェーズに合わせて、3記事を行き来しながら活用してみてください。

Linuxサーバーに対するfirewalldやSELinuxの設定は、姉妹サイトLinuxMaster.JPで詳しく解説しています。AWSのIAMやVPC設計の基礎は、CloudMasters.TOKYOを参考にしてみてください。