遮断する前に観測する — would-block ログで始めるファイアウォール段階導入

「金曜の夜にファイアウォールのポリシーを有効化したら、月曜の朝に基幹システムの連携が止まっていた」——ファイアウォール導入の失敗談として、形を変えて何度も語られるパターンです。原因はポリシーの出来ではなく、いきなり遮断を有効化したことにあります。この記事では、業務を壊さずにポリシーを効かせるための段階導入の進め方を整理します。

なぜ「いきなり遮断」は失敗するのか

ネットワークには、設計書に載っていない通信が必ず流れています。誰かが手で設定した連携、忘れられたバッチ処理、機器のファームウェア更新、SaaSのバックグラウンド通信——。机上で作ったポリシーは、こうした「知らなかった正当な通信」を高い確率で巻き込みます。

しかも遮断による障害は厄介です。アプリ側にはタイムアウトとしてしか見えず、原因がファイアウォールだと特定されるまで時間がかかります。ポリシーの精度の問題ではなく、確認の工程を飛ばしたことの問題です。

段階導入の3ステップ

実務で広く知られているのは、遮断の手前に2つの段階を置く進め方です。

段階	やること	通信への影響
① 観測	何が流れているかをまず見る	なし
② would-block 運用	ポリシーを当てるが遮断しない	なし
③ 強制	確認済みのポリシーで実際に遮断	あり

ステップ① 観測 — 許可リストの素案づくり

ポリシーを書く前に、いまの通信の実態を見ます。どのホストが、どの宛先（ドメイン）へ、どのプロトコルでつないでいるか。この観測結果がそのまま許可リストの素案になります。設計書から書き起こすより、実際に流れている通信から起こすほうが、漏れがはるかに少なくなります。

ステップ② would-block 運用 — 「もし強制したら何が止まるか」を見る

素案のポリシーを適用しますが、遮断はしません。代わりに「このポリシーを強制していたら、この通信は遮断されていた」という記録（would-block ログ）を残します。

would-block ログに上がってくるのは、次のどちらかです。

• 正当な業務通信の拾い漏れ → 許可リストに追加する（ポリシーのチューニング）
• 本当に止めたい通信 → そのまま遮断対象として確認する

この振り分けを繰り返してログが落ち着いてくれば、「強制しても業務は止まらない」という確証が積み上がります。遮断する前に遮断の影響をレビューできることが、この工程の価値です。

ステップ③ 強制への切替

would-block ログのレビューで未処理の項目がなくなった（または説明がつく状態になった）ことを確認してから、遮断を有効化します。切替直後は問い合わせに即応できる体制（業務時間内の切替、関係部署への周知、切り戻し手順の用意）を整えておくのが定石です。

would-block レビューの実務

• 誰が見るか — ネットワーク担当だけで判断できないログが必ず出ます。「この宛先は業務で使っているか」を答えられる業務部門・システム担当に確認できる経路を、最初から用意しておきます
• 何を見るか — would-block に上がった宛先を「許可に追加 / 遮断のまま / 要調査」に振り分けます。件数を眺めるのではなく、1件ずつ判断を付けて消し込むのがポイントです
• どれくらいの期間か — 環境によりますが、目安としては観測に数日〜数週間、would-block 運用にも数週間程度のレンジを見込むことが多いようです。月次バッチのような低頻度の通信を拾いたい場合は、その周期をまたぐ長さが必要になります。接続先が少なく安定した環境（AIエージェント専用セグメントなど）なら、より短い期間で収束します

強制後の運用 — 切り替えて終わりではない

強制への切替はゴールではなく、運用の始まりです。

• 遮断ログのレビュー — 強制後の遮断ログには、見逃していた正当な通信と、実際の攻撃・ポリシー違反の両方が混ざります。切替直後は高頻度で、安定後も定期的に確認します
• 初見の宛先のレビュー — 「この環境から初めて接続する宛先」は、新しい業務通信か、異常の兆候かのどちらかです。要調査イベントとして拾う運用にすると、ポリシーの鮮度が保てます
• 監査証跡としての価値 — 観測 → would-block → 強制の各段階のログは、「いつ・何を根拠に・どう絞ったか」の記録そのものです。インシデント対応でも監査対応でも、この証跡が効きます

正直な注意点

• would-block 運用の期間中は、当然ながらまだ何も遮断されていません。リスクの高い環境では、明白に危険な宛先だけ先行して遮断する、観測期間を圧縮するなどの調整が必要です
• ログが「落ち着いた」ことの判断は最終的に人の判断です。低頻度の正当な通信を拾い切れない可能性は残るため、切り戻し手順とセットで切り替えます

まとめ

• いきなり遮断を有効化すると、設計書にない正当な通信を巻き込んで業務が止まりやすい
• 段階導入は 観測 → would-block 運用 → 強制 の3ステップ
• would-block は「もし強制したら何が止まるか」を、止める前にレビューできる工程
• レビューは業務部門に確認できる体制で、1件ずつ消し込む。期間は環境によるが数週間単位のレンジを見込む
• 強制後も遮断ログ・初見の宛先のレビューを続ける。各段階のログは監査証跡になる

Tate（盾）は、この段階導入をそのまま運用モード（observe / monitor / enforce）として備えています。導入の流れは 導入ページ、可視化の仕組みは 可視化・AI解析 をご覧ください。