「社内ネットワークに不正なアクセスがあったらしいが、いつ、どこから侵入されたのかまったくわからない」。こうした状況は、侵入検知の仕組みがないネットワークでは珍しくありません。ファイアウォールだけでは防ぎきれない攻撃が増えている今、ネットワーク内部の異常をリアルタイムに検知・遮断できる体制が求められています。
この記事では、IDS(Intrusion Detection System: 侵入検知システム)とIPS(Intrusion Prevention System: 侵入防御システム)について、仕組みの違いから具体的な導入手順まで、現場で使えるレベルで解説します。「IDSとIPSはどう違うのか」「うちの規模でも導入できるのか」という疑問を持つ方に向けて、実践的な情報をまとめました。

IDS・IPSとは?なぜ今必要なのか
IDS(侵入検知システム)は、ネットワーク上の通信やサーバー上の動作を監視し、不正アクセスや攻撃の兆候を検知して管理者に通知するシステムです。一方、IPS(侵入防御システム)は、検知に加えて不正な通信を自動的に遮断する機能を持っています。
はじめに混同しやすい点を整理しておきます。IDS/IPSの「IP」はネットワークアドレスの「IPアドレス(Internet Protocol Address)」ではなく「Intrusion Prevention(侵入防御)」の略です。同じくIDSの「ID」も「Identifier」ではなく「Intrusion Detection(侵入検知)」を指します。検索で迷ったらまずこの語源を押さえてください。
ファイアウォールが「門番」として許可された通信だけを通すのに対し、IDSは「監視カメラ」、IPSは「警備員付きの監視カメラ」のような役割を果たします。ファイアウォールをすり抜けた攻撃や、内部からの不正アクセスを検知できるのがIDSとIPSの強みです。
近年、標的型攻撃やゼロデイ攻撃のように、ファイアウォールだけでは防げない脅威が増えています。特に中小企業では「ファイアウォールがあるから大丈夫」と考えがちですが、実際にはファイアウォールを通過した後のネットワーク内部を監視する仕組みがなければ、侵入に気づけないまま被害が拡大するリスクがあります。
IDSとIPSの違いを理解する
IDSとIPSは混同されやすいですが、役割が明確に異なります。
| 項目 | IDS(侵入検知) | IPS(侵入防御) |
|---|---|---|
| 主な役割 | 不正通信の検知・通知 | 不正通信の検知・遮断 |
| 通信への影響 | 通信をコピーして分析(パッシブ) | 通信経路上で分析・遮断(インライン) |
| 誤検知時の影響 | 誤アラートが増える(業務影響は小さい) | 正常な通信まで遮断される可能性がある |
| 導入の難易度 | 比較的低い(既存構成を変えにくい) | ネットワーク構成の変更が必要な場合がある |
| 適した場面 | まず監視体制を整えたい段階 | 自動遮断まで含めた防御を実現したい段階 |
ポイントは、IDSは「検知して知らせる」、IPSは「検知して止める」という違いです。IPSのほうが防御力は高いですが、誤検知(正常な通信を攻撃と判断してしまうこと)が発生すると業務に直接影響するため、まずIDSで監視を始め、運用に慣れてからIPSに移行するのが現場では一般的です。

IDS・IPSの検知方式
IDS・IPSが不正な通信を見つける方法には、大きく2つの方式があります。
1. シグネチャベース検知(不正検知型)
あらかじめ登録された攻撃パターン(シグネチャ)と通信を照合し、一致したものを不正として検知する方式です。ウイルス対策ソフトのパターンマッチングに近い考え方で、既知の攻撃に対しては高い精度で検知できます。
・メリット: 既知の攻撃に対する検知精度が高い。誤検知が比較的少ない
・デメリット: シグネチャにない未知の攻撃は検知できない。定期的なシグネチャ更新が必要
2. アノマリベース検知(異常検知型)
正常な通信パターンをあらかじめ学習し、そこから逸脱した通信を異常として検知する方式です。未知の攻撃やゼロデイ攻撃にも対応できる可能性がありますが、正常な通信を攻撃と誤認識するケースも発生しやすくなります。
・メリット: 未知の攻撃パターンも検知できる可能性がある
・デメリット: 誤検知(フォルスポジティブ)が多くなりやすい。チューニングに手間がかかる
実際の製品では、この2つの方式を組み合わせたハイブリッド検知が主流です。シグネチャベースで既知の攻撃を確実に捕捉しつつ、アノマリベースで未知の脅威もカバーする構成が現場では多く採用されています。
| 比較項目 | シグネチャ型 | アノマリ型 |
|---|---|---|
| 検知対象 | 既知の攻撃パターン(マルウェア・既知CVE悪用通信) | 通常時から逸脱した振る舞い(通信量・接続先・時間帯) |
| 誤検知率 | 低い(パターン一致のみ) | 高め(学習データと運用環境の差異で発生) |
| 未知攻撃の検知 | 苦手(シグネチャ未提供のゼロデイは見逃す) | 得意(振る舞いベースで未知も拾える) |
| 運用負荷 | 低~中(ルール更新が中心) | 中~高(学習・チューニング・トリアージが必須) |
| 代表的な製品・OSS | Snort、Suricata(ルールベース動作時) | Zeek(旧Bro)、Suricata(異常検知設定時)、商用UTM |
中小企業ではまずシグネチャ型で運用を始めて、慣れてきたらアノマリ型を併用する流れが現実的です。最初からアノマリ型に振り切ると、誤検知の山に埋もれて運用が止まります。
ネットワーク型とホスト型の違い
IDS・IPSは設置場所によって、ネットワーク型(NIDS/NIPS)とホスト型(HIDS/HIPS)に分類されます。
ネットワーク型(NIDS/NIPS)
ネットワークの通信経路上に設置し、流れるパケットを監視します。1台でネットワーク全体を監視できるため、効率的に広い範囲をカバーできます。
・設置場所: ルーターやスイッチの近く、ファイアウォールの内側など
・監視対象: ネットワークを流れるパケット全体
・利点: ネットワーク全体を少ない台数で監視できる
・注意点: 暗号化された通信(HTTPS等)の中身は直接分析できない
ホスト型(HIDS/HIPS)
個々のサーバーやPCにエージェントをインストールし、そのホスト上の動作を監視します。ファイルの改ざんやログの異常、不審なプロセスの起動などを検知できます。
・設置場所: 監視対象のサーバーやPCにインストール
・監視対象: ファイルシステム、プロセス、ログ、レジストリなど
・利点: 暗号化通信の復号後の内容も監視できる。内部不正にも対応
・注意点: 監視対象ごとにインストールが必要。サーバー負荷が増加する
| 比較項目 | ネットワーク型 | ホスト型 |
|---|---|---|
| 監視範囲 | ネットワーク全体 | 個別のホスト |
| 暗号化通信 | 分析困難 | 復号後に分析可能 |
| 導入コスト | 少台数で広範囲をカバー | 台数分の導入・管理が必要 |
| 内部不正の検知 | ネットワーク経由のみ | ローカル操作も検知可能 |
中小企業で始める場合は、まずネットワーク型のIDSを1台導入してネットワーク全体の可視化を優先し、重要なサーバーにはホスト型を追加で導入するのがコストと効果のバランスに優れた構成です。
オープンソースIDS・IPSの導入手順
予算が限られた環境でも、オープンソースのIDS・IPSを活用すれば侵入検知の仕組みを構築できます。ここでは代表的なツールと、Suricataを例にした導入手順を紹介します。
代表的なオープンソースIDS・IPS
・Snort: IDS/IPSの先駆け的存在。Cisco傘下で開発が続いている。豊富なシグネチャ(ルールセット)が利用可能
・Suricata: マルチスレッド対応で高速処理が可能。Snortのルールとの互換性もある。近年はこちらが主流になりつつある
・OSSEC: ホスト型IDSの定番。ファイル整合性チェックやログ解析が得意
Suricataの導入例(CentOS/AlmaLinux)
# EPELリポジトリを有効化 sudo dnf install epel-release -y # Suricataをインストール sudo dnf install suricata -y # バージョン確認 suricata --build-info | head -5
基本的な設定ファイルの編集
Suricataの設定ファイルは /etc/suricata/suricata.yaml です。最低限、以下の項目を自社環境に合わせて変更します。
# /etc/suricata/suricata.yaml の主要設定箇所 # 監視対象の内部ネットワークを指定(デフォルト: [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]) vars: address-groups: HOME_NET: "[192.168.1.0/24]" # 自社ネットワークに変更 # 監視するネットワークインターフェースを指定(デフォルト: eth0) af-packet: - interface: ens192 # 実際のインターフェース名に変更 # ログの出力先(デフォルト: /var/log/suricata/) default-log-dir: /var/log/suricata/
ルール(シグネチャ)の更新と有効化
# suricata-updateでルールを取得・更新 sudo suricata-update # Suricataを起動 sudo systemctl enable --now suricata # ログを確認(アラートが記録される) sudo tail -f /var/log/suricata/fast.log
この状態ではIDSモード(検知・通知のみ)で動作します。運用に慣れてきたら、設定ファイルでIPSモード(通信遮断あり)に切り替えることも可能です。
中小企業でも今日からできること
「IDS・IPSの導入はハードルが高い」と感じるかもしれませんが、段階的に進めれば情シス1人体制でも十分に実現できます。
ステップ1: まずはログの可視化から
いきなりIDS・IPSを導入する前に、既存のファイアウォールやルーターのログをきちんと確認する習慣をつけましょう。多くの機器はデフォルトでログを出力していますが、誰も見ていないケースがほとんどです。
ステップ2: OSSのIDSを検証環境で試す
本番環境にいきなり入れるのではなく、まずは検証用のサーバーにSuricataやSnortを導入して動作を確認します。自社ネットワークの「普段の通信パターン」を把握することが、誤検知の低減につながります。
ステップ3: 本番環境にIDSモードで導入
検証で問題なければ、本番ネットワークにIDSモード(検知のみ・遮断なし)で導入します。2〜4週間ほど運用して、アラートの内容と頻度を確認しながらルールをチューニングしていきます。
ステップ4: 必要に応じてIPSモードへ移行
誤検知が十分に減ったら、重要なセグメントからIPSモード(自動遮断あり)に切り替えます。すべてを一度にIPSにする必要はなく、段階的に進めるのが安全です。
よくある誤解と注意点
【誤解1】ファイアウォールがあればIDS・IPSは不要
ファイアウォールはポート番号やIPアドレスで通信を制御しますが、許可されたポートを通る攻撃(例: HTTP/443経由のSQLインジェクション)は検知できません。IDS・IPSはパケットの中身を分析するため、ファイアウォールとは異なるレイヤーで防御を担います。両者は補完関係にあり、どちらか一方で十分ということはありません。
【誤解2】IDS・IPSを入れれば攻撃を完全に防げる
IDS・IPSはあくまで多層防御の一つです。シグネチャに含まれない新しい攻撃手法や、巧妙に正常通信に偽装した攻撃はすり抜ける可能性があります。ファイアウォール、IDS・IPS、ログ監視、エンドポイント保護を組み合わせた多層防御の考え方が重要です。
【注意】誤検知への対応を怠らない
IDS・IPSの運用で最も手間がかかるのが、誤検知(フォルスポジティブ)への対応です。導入直後はアラートが大量に発生することがあります。1件ずつ確認してルールの除外設定やチューニングを行うことが、実用的な監視体制を作る上で欠かせません。アラートが多すぎて無視するようになってしまう「アラート疲れ」は、IDS・IPS運用で最も避けるべき事態です。

本記事のまとめ
| 項目 | ポイント |
|---|---|
| IDSとIPSの違い | IDSは検知・通知、IPSは検知・遮断。まずIDSから始めるのが安全 |
| 検知方式 | シグネチャベース(既知の攻撃)とアノマリベース(未知の攻撃)の2種類 |
| 設置タイプ | ネットワーク型は全体監視、ホスト型はサーバー個別監視 |
| 導入の進め方 | ログ確認→OSSで検証→IDSモードで本番導入→段階的にIPSへ |
| 運用の要 | 誤検知のチューニングを継続し、アラート疲れを防ぐこと |
IDS・IPSは、ファイアウォールだけではカバーしきれないネットワーク内部の脅威を検知するために欠かせない仕組みです。オープンソースのツールを活用すれば、コストを抑えながらも実効性のある侵入検知体制を構築できます。まずはIDSモードで「ネットワークで何が起きているか」を可視化するところから始めてみてください。
ネットワークセキュリティの基盤となるファイアウォールの設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。
「セキュリティ基礎」の記事を読む
このテーマに関連する解説記事を一覧でまとめています。あわせてご覧ください。
IDSとIPSのどちらを選ぶか|判断フローチャート
「検知だけで十分なのか、自動でブロックまで踏み込むべきか」は導入時に必ずぶつかる論点です。判断軸は4つで、ビジネス影響度・誤検知許容度・運用人員・SLA要件を順に見ていけば結論が出ます。
| 判断軸 | IDS(検知のみ)が向くケース | IPS(自動遮断)が向くケース |
|---|---|---|
| ビジネス影響度 | 停止が許容される社内系・検証環境 | EC・予約・決済など停止=売上損失の本番系 |
| 誤検知許容度 | 誤遮断が業務停止に直結する基幹系 | 多少の誤遮断より侵害拡大を防ぎたい外向きDMZ |
| 運用人員 | アラート対応1~2名で平日日中のみ | 24時間監視またはMSSP委託済み |
| SLA要件 | 稼働率99.9%程度の社内システム | 稼働率99.99%以上かつ侵害時の二次被害が大きい |
迷ったら最初はIDSモード(検知のみ)で1~2か月運用し、誤検知率と対応コストを実測してからIPSへ切り替えるのが安全です。Suricataのように同一プロダクトで切替可能なものを選ぶと移行が楽になります。
IDS/IPS設置場所の決め方
IDS/IPSは「どこに置くか」で見える攻撃も防げる攻撃も大きく変わります。原則は2つだけ覚えてください。ネットワーク型は通信の通り道に置く、ホスト型は守りたい資産そのものに入れる、です。
ネットワーク型(NIDS/NIPS)の置き場所は、ファイアウォール直下のDMZ境界、社内セグメント間(Office系LAN ⇔ サーバーLAN)、リモートアクセスVPN集約点の3か所が定番です。スイッチのSPANポートやネットワークTAPでミラーリングしたトラフィックをIDSに流し込む構成が中小企業でも導入しやすい形です。
ホスト型(HIDS/HIPS)は、公開Webサーバー、認証サーバー(Active Directory・LDAP)、重要DBサーバー、踏み台サーバーといった「侵入されたら被害が大きい資産」に優先して入れます。全サーバーに一律で入れると運用が破綻するため、資産の重要度ランクで絞るのが現実解です。
設置場所別の具体的なネットワーク図、SPAN/ミラーポート設定例、AWS/Azureクラウド環境でのVPCトラフィックミラーリング手順については、姉妹記事『IDS/IPSの設置場所|ネットワーク型・ホスト型の置き方』で詳しく解説しています。
IPS誤検知を減らす実務フロー
IPSを本番投入したあと、最初の1か月で必ずぶつかるのが誤検知(False Positive)の処理です。野放しにすると正常通信を遮断して業務が止まり、現場から「IPS外してくれ」と言われます。回避策は手順化された運用フローを最初から決めておくことです。
基本サイクルは4ステップで回します。
・ステップ1: トリアージ — アラートを「真の攻撃/誤検知/要調査」の3分類に振り分けます。発生頻度と影響範囲で優先度を付けるのがポイントです。
・ステップ2: ホワイトリスト登録 — 業務上正当な通信(社内ツール・既知のスキャナ・脆弱性診断ベンダー)を送信元IP・宛先・ポート単位で除外設定します。
・ステップ3: シグネチャチューニング — 過剰反応するルールをdisable、または閾値を調整します。Suricataならsuricata.yamlのthreshold.configで頻度制限をかけられます。
・ステップ4: 再評価 — チューニング後2週間運用して誤検知率と検知漏れを再測定し、必要なら再調整します。
ホワイトリスト雛形、Suricataのthreshold.config記述例、商用IPS(Palo Alto・FortiGate)でのチューニング画面手順については、姉妹記事『IPS誤検知の減らし方|ホワイトリスト・シグネチャ調整・運用フロー実例』にまとめています。
IDS/IPSと組み合わせるセキュリティ機構(SIEM/EDR/WAF)
IDS/IPS単体ではカバーできない領域があります。ネットワーク層の通信は見えても、エンドポイント内部の挙動やWebアプリ層の攻撃文脈までは追いきれません。実運用では他の機構と組み合わせて多層防御を組みます。
役割分担は次のように整理できます。
・SIEM(Security Information and Event Management): IDS/IPS・FW・サーバー・認証基盤のログを集約し、相関分析で「単体では見抜けない攻撃ストーリー」を浮かび上がらせます。Splunk・Elastic SIEM・Microsoft Sentinelなどが代表例です。
・EDR(Endpoint Detection and Response): 端末側で動く脅威(マルウェア実行・ファイル改ざん・LSASS不正アクセス)を検知してプロセスを停止します。ネットワーク型IDS/IPSが見られない暗号化済みエンドポイント挙動を補完します。
・WAF(Web Application Firewall): HTTP/HTTPSのアプリケーション層に特化し、SQLインジェクション・XSS・パストラバーサルなどIDS/IPSでは判別が難しい文脈依存の攻撃を防ぎます。
中小企業で全部一気に導入するのは現実的ではありません。優先順位は「IDS/IPS(ネットワーク可視化)→ EDR(エンドポイント保護)→ SIEM(相関分析)→ WAF(公開Webがあれば追加)」の順が無難です。なお全体の防御思想としてはゼロトラストの考え方が背景にありますが、その詳細は別記事に譲ります。
中小企業がIDS/IPSを導入する場合のコスト目安
「うちみたいな規模で、結局いくらかかるの?」という質問を現場でよく受けます。従業員50~300名規模の中小企業を想定した年間コストの目安を整理します。あくまで2026年時点のレンジ感で、構成次第で上下します。
| 項目 | OSS(Suricata/Snort/Zeek) | 商用UTM・専用IPS |
|---|---|---|
| ライセンス費 | 0円(OSS無償) | 年30~150万円(拠点数・スループットで変動) |
| ハードウェア | 初期10~30万円(汎用サーバー or NUC級) | アプライアンス込みでライセンスに包含が多い |
| 初期構築・チューニング | 20~50万円(外部委託する場合) | 20~80万円(ベンダーSE費用) |
| 年間運用(ルール更新・アラート対応) | 10~50万円(自社運用前提) | 30~150万円(保守・MSSP費用込み) |
| 合計(年間ならし) | 30~100万円 | 80~300万円 |
OSSは「ライセンス0円」の見出しに惹かれがちですが、運用人件費を抜くと費用比較を見誤ります。情シス1人体制で兼任できるのは年100台規模までが目安で、それを超えるならMSSP(Managed Security Service Provider)への委託も選択肢に入れてください。
よくある質問(FAQ)
Q1. IDSとIPSはどちらを先に導入すべきですか?
運用経験がない場合はIDSから始めることを推奨します。検知のみで1~2か月走らせて誤検知率を把握してから、IPSモードに切り替える流れが安全です。Suricataのように1製品でモード切替できるものなら段階移行が楽になります。
Q2. IPSの誤検知で社内システムが止まったときの対処は?
まず該当ルールを即座にdisableして業務影響を止め、次に該当通信のパケットキャプチャとIPSログを保全します。後追いで「正当通信なのか・チューニング不足なのか」を切り分け、ホワイトリスト登録または閾値調整で再発を防ぎます。原因特定前のIPS全停止は侵害リスクを上げるため避けてください。
Q3. ホスト型IDSとネットワーク型IDSの設置場所はどう決めますか?
ネットワーク型はFW直下・セグメント境界・VPN集約点に置き、ホスト型は公開サーバー・認証基盤・重要DBなど「侵害時の被害が大きい資産」に絞って入れます。全台導入は運用が破綻するため、資産重要度ランクで対象を絞り込んでください。
Q4. SnortとSuricataはどう違い、どちらを選ぶべきですか?
Snortは歴史が長くドキュメントも豊富ですが、設計がシングルスレッド寄りです。Suricataはマルチスレッド対応でスループットが出やすく、ルール記法はSnort互換に近い設計です。新規導入ならSuricataが第一選択で問題ありません。
Q5. シグネチャ型とアノマリ型はどう使い分けますか?
既知攻撃の遮断はシグネチャ型、未知の振る舞い検知はアノマリ型と役割が分かれます。実運用ではシグネチャ型をベースに、重要セグメントだけアノマリ型を追加する併用構成が定番です。アノマリ単独運用は誤検知が多く、初動には向きません。
Q6. WAFやEDRはIDS/IPSと併用すべきですか?
併用が前提です。IDS/IPSはネットワーク層、WAFはアプリ層、EDRはエンドポイントと守備範囲が異なります。中小企業で予算が限られる場合は「IDS/IPS → EDR → WAF」の優先順で順次導入してください。
Q7. 中小企業の年間コスト目安はどれくらいですか?
OSS構成(Suricata等)で年30~100万円、商用UTM・専用IPSで年80~300万円が目安です。ライセンスより運用人件費(チューニング・アラート対応)が支配的になるため、自社対応かMSSP委託かを早めに決めることをおすすめします。
Q8. IDS/IPSのアラート対応は何人体制で回せますか?
平日日中のみのIDS運用なら1~2名で対応可能です。24時間365日のIPS自動遮断運用を内製で回すなら最低3~4名が必要で、現実的にはMSSP委託でカバーしている中小企業がほとんどです。アラート対応の体制設計は導入前に必ず詰めてください。