fail-closed と fail-open — セキュリティ機器の障害時、通信を止めるか通すか

ファイアウォールやIPSなど、回線に直列（インライン）に入るセキュリティ機器を検討すると、必ず突き当たる問いがあります。「この箱が壊れたとき、通信はどうなるのか？」——答えは製品仕様の片隅に fail-closed / fail-open という言葉で書かれていることが多いのですが、これは仕様の細部ではなく、導入判断そのものに関わる設計思想の選択です。この記事で正面から整理します。

なぜ「障害時の挙動」を決めておく必要があるのか

透過型ファイアウォールのようなインライン機器は、すべての通信がその箱を物理的に通過します。つまり箱の障害は、検査機能の停止であると同時に、回線そのものの問題になります。

このとき取れる設計は2つしかありません。通信を止めるか、検査なしで通すか。どちらにも明確なリスクがあり、「障害は起きない前提」で先送りにすると、起きたときに最悪の形で決まってしまいます。

fail-open — 無検査で通すという選択

fail-open は、機器の障害時に通信を素通しにする設計です。回線は生き続けるため、可用性への影響は最小限に抑えられます。

代償は、障害の間じゅう**「無検査の窓」が開くことです。検査も遮断も記録もされないままトラフィックが流れます。さらに注意したいのは、攻撃者の視点ではこれが「セキュリティ機器を止めれば素通りできる」という構造**に見えることです。障害が偶発か誘発かを問わず、防御が外れた状態が静かに続くリスクを受け入れることになります。

fail-closed — 止めるという選択

fail-closed は、機器の障害時に通信を遮断する設計です。「検査できないなら通さない」——無検査の窓を開けない、安全側に倒れる構えです。

代償は可用性です。箱の障害＝その回線の通信停止であり、機器が回線の単一障害点（SPOF）になります。業務影響の大きい回線では、障害時の影響範囲・復旧手順・保守体制とセットで考える必要があります。

どちらが正解か——回線の性格で決まる

fail-closed が常に正解、ということはありません。判断軸は「その回線で守りたいものは、機密性か可用性か」です。

回線の性格	例	傾向
止まることより、漏れることが致命的	機密データを扱うセグメント、AIエージェント専用セグメント	fail-closed が有力
漏れることより、止まることが致命的	工場ライン、決済系、対外サービスの経路	fail-open（または冗長化）が有力
中間	一般オフィスのインターネット回線	業務依存度と保守体制次第

「全社で統一」ではなく、回線ごとに選ぶものだと捉えるのが実務的です。

HWバイパスという折衷

両者の間を取る仕組みとして、ハードウェアバイパスがあります。機器の電源断や障害を検知すると、内部のリレーが物理的に2つのポートを直結し、回線を素通しに切り替える仕組みです。

これは実質的に「fail-open を意図的に・確実に行う」ための部品です。バイパス動作中は無検査になるという fail-open の性質は変わらないため、「可用性を優先すると決めた回線で、その決定を確実に実行する手段」と理解するのが正確です。

導入前に合意しておくべきこと

インライン機器の導入では、障害時の挙動を顧客とベンダーの間で文書で合意しておくことをおすすめします。最低限、次の点です。

• 標準構成の障害時挙動は fail-closed / fail-open のどちらか
• それは選択・変更できるか（バイパスはオプションか標準か）
• fail-closed の場合：障害時の業務影響範囲と、復旧までの手順・目安
• fail-open（バイパス）の場合：無検査になっていることをどう検知・通知するか
• 計画停止（ファームウェア更新など）のときの挙動

「障害時にどうなるかを聞いたら明確な答えが返ってくるか」は、製品とベンダーを見極める良い試金石でもあります。

まとめ

• 直列に入るセキュリティ機器は、障害時に止めるか通すかをあらかじめ決めておく必要がある
• fail-open は可用性に優しいが、障害中は無検査の窓が開く
• fail-closed は安全側に倒れるが、機器が可用性の単一障害点になる
• どちらが正解かは回線の性格（機密性優先か可用性優先か）次第。回線ごとに選ぶ
• HWバイパスは「fail-open を確実に実行する」折衷手段。導入前にベンダーと挙動を文書で合意する

Tate（盾）は標準構成を fail-closed とし、単一障害点になる事実も含めて明示する設計思想を取っています。詳しくは設計思想・信頼性とよくある質問をご覧ください。