変更要約: 初版
4.3検査方式とセンサ配置の比較
パケットフィルタリング（ステートレス）・ステートフル検査・ディープパケットインスペクション（DPI）という検査の深さの違いと、インライン対タップ/SPAN（遮断できるか・経路に影響するか）、フルパケットキャプチャ（タップ）対トランザクショナル（NetFlow）（ペイポードを持つか・軽量に長期保持できるか）を、「この目的にはどの方式が適切か」という設計判断として学びます。
監視の設計では「どこまで深く見るか」「経路に割り込んで止めるか、コピーだけ取るか」「全部保存するか、要約だけ残すか」という3つの軸が絡みます。それぞれに可視性と、コスト/遅延/リスクのトレードオフがあり、目的（遮断したいのか観測だけか、ペイロードが要るのか統計で十分か、長期保持したいのか）から方式を選ばないと、性能を無駄に食ったり必要な証跡を取り逃したりします。この節では検査の深さ・センサの置き方・保持データの粒度を、実務の判断として比較します。
4.3.1検査の深さ
- パケットフィルタリング（ステートレス）＝各パケットを個別に5タプル（IP・ポート・プロトコル）とACLで許可/拒否する。接続の状態を持たないため高速・安価だが、「その戻りパケットは確立済みセッションの一部か」を判断できず、戻り通信のために広くポートを開ける等の甘さが出やすい。
- ステートフル検査＝接続状態テーブルを持ち、内側から確立したセッションの戻りトラフィックを自動的に許可する（新規の外→内は既定拒否のまま）。ステートレスより安全で運用も楽だが、状態管理の分だけリソースを使う。L3/L4の状態が中心。
- ディープパケットインスペクション（DPI）＝ペイロードをL7まで検査し、アプリ識別・IPS署名・マルウェア検知など中身に踏み込む。可視性は最も高いが、CPU/メモリを最も消費し遅延も増える。NGFWやIPSがこれを担い、暗号化されると（復号しない限り）中身は見えなくなる点に注意。
4.3.2センサの置き方（インライン対タップ）
- インライン＝センサを通信経路上に直列に置く。トラフィックが必ず通るので遮断や書き換えができる（IPS・ファイアウォールの前提）。反面、遅延を足し、機器故障時に通信が止まる（または素通しになる）リスクがあり、fail-open/fail-closedの設計判断が要る。
- タップ/SPAN＝トラフィックのコピーを経路外で受け取る。遮断はできず検知/記録のみ（IDS・パケットキャプチャの前提）だが、本番経路に割り込まないので遅延も障害リスクも与えない。ハードウェアタップは物理的に全フレームを複製し取りこぼしにくいのに対し、スイッチのSPAN（ミラー）は帯域超過時にフレームを落としうる。
4.3.3保持データの粒度（フルキャプチャ対NetFlow）
- フルパケットキャプチャ（タップ経由）＝ヘッダもペイロードも丸ごと保存する。事後にファイル抽出やコマンド再構成ができる最も詳細な証跡だが、ストレージを激しく消費し長期保持は非現実的。深掘り調査の対象区間に絞って取るのが定石。
- トランザクショナルデータ（NetFlow）＝各フローの5タプル＋バイト/パケット数・時刻の要約だけを残す。ペイロードが無いので軽量で長期保持・広域のベースライン化に向き、ビーコンや異常な通信量の面的検知に強い。中身の確証はできないので、深掘りにはフルキャプチャと組み合わせるのが実務。
「ステートレス＝個別パケット/状態なし・高速」「ステートフル＝接続テーブルで戻りを自動許可」「DPI＝L7ペイロードまで見る/最重量」「インライン＝遮断可・経路に影響/故障リスク」「タップ・SPAN＝コピーで検知のみ・SPANは超過時に落とす」「フルキャプチャ＝ペイロードあり/ストレージ重い」「NetFlow＝統計のみ/軽量・長期保持」の対応が頻出です。目的（遮断か観測か・ペイロードか統計か）から方式を選びましょう。
あなたはデータセンタの監視を再設計しています。要件は「(1) 既知の攻撃をその場で遮断したい、(2) それとは別に、全通信を後から詳しく調べられるようにしたいが、本番トラフィックに遅延や障害リスクは与えたくない、(3) 数か月スパンで通信量の異常（ビーコン/持ち出し）を面で見張りたい」です。まず(1)の「その場で遮断」は、コピーを見るだけのタップでは実現できません——遮断するには経路上に直列で入るインライン配置のIPS（DPIで署名一致を判定）が必要で、ここではfail-closed/openと遅延の許容を設計します。次に(2)の「詳しく後から調べる・ただし本番に影響させない」は、経路に割り込む必要がないのでタップ（またはSPAN）でトラフィックのコピーを取り、それをフルパケットキャプチャに流します。ここでインラインのIPSにフルキャプチャまで兼ねさせようとすると、DPIとフル保存の負荷で遅延が悪化し、(2)の「影響を与えたくない」に反します——遮断（インライン）と詳細記録（タップ）は役割を分けるのが定石です。取りこぼしを避けたいので、SPANではなくハードウェアタップを選ぶ判断も妥当です。最後に(3)の「数か月・面で異常量を見張る」は、フルキャプチャを何か月も貯めるのは非現実的なので、軽量なNetFlow（トランザクショナル）で長期の統計ベースラインを作り、逸脱を検知したらその区間だけフルキャプチャを深掘りする、という二段構えにします。こうして、遮断はインライン＋DPI、詳細はタップ＋フルキャプチャ、長期監視はNetFlow、と目的ごとに方式を割り当てるのが、性能も証跡も両立させる設計判断です。
| 方式 | 見える範囲 | 遮断可否/影響 | 向く目的 |
|---|---|---|---|
| パケットフィルタ（ステートレス） | 個別パケットの5タプル | 許可/拒否可・状態なし | 高速な粗いフィルタ |
| ステートフル検査 | 接続状態（戻りを追跡） | 許可/拒否可・状態管理コスト | セッション単位の安全な制御 |
| DPI | L7ペイロードまで | 遮断可・最も高負荷 | アプリ識別・IPS・マルウェア検知 |
| タップ/SPAN | トラフィックのコピー | 遮断不可・経路に無影響（SPANは落とし得る） | 影響を与えない検知/記録 |
| NetFlow（トランザクショナル） | 5タプル＋統計・ペイロード無し | 遮断せず観測のみ・軽量 | 長期の量的ベースライン |
ひっかけ： 「タップ/SPANでミラーしているのだから攻撃をその場で遮断できる」は誤りです——タップ/SPANはコピーを見るだけで検知/記録のみ、遮断には経路上に直列で入るインライン配置（IPS/FW）が必要です。また「NetFlowを取っているのだからペイロードの証拠も残る」も誤り＝NetFlowは統計のみでペイロードを持たないため、中身の確証にはフルパケットキャプチャが要ります。
4.3.4この節のまとめ
- 検査の深さ：ステートレス（個別パケット・高速）→ステートフル（戻りを追跡）→DPI（L7まで・最重量）。深いほど見えるが高負荷
- 配置：インラインは遮断可だが経路に影響/故障リスク、タップ/SPANはコピーで検知のみ・無影響（SPANは超過時に落とし得る）
- 粒度：フルキャプチャはペイロードありだがストレージ重い、NetFlowは統計のみで軽量・長期保持。役割を分けて組み合わせる
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 要件は「既知攻撃をその場で遮断する」ことである。監視チームは「スイッチのSPANポートでトラフィックをミラーしてIDSに送れば遮断できる」と主張した。この主張の評価として最も適切なものはどれか。
Q2. 数か月スパンで、社内から外部への通信量の異常（ビーコンや大量持ち出し）を面で監視したい。ストレージは限られており、常時のフルパケット保存は非現実的である。この目的に最も適したデータ収集方式はどれか。
Q3. ステートレスのパケットフィルタで「内部から外部への戻り通信を通すために、外部発の高位ポートを広く許可」する運用になっており、外部からの不正接続が入り込む懸念がある。この課題への最も適切な改善はどれか。