フェイルセーフ・フェイルセキュアとは？セキュリティ設計の基本原則と企業システムへの実装ガイド

認証システムが止まったとき、あなたのシステムはどちら側に倒れますか。「全員を通す」のか「全員を遮断する」のか——この設計判断ひとつが、企業のセキュリティを決定的に左右します。

フェイルセーフ（fail-safe）とフェイルセキュア（fail-secure）は、障害発生時の「安全側への倒れ方」を定義するセキュリティ設計の基本概念です。設計段階でこれを決めておかないと、ファイアウォールが落ちた瞬間に全トラフィックが素通りする、認証サービスが停止した途端に誰でもログインできるようになる——という事態が現実に起きます。

この記事では、フェイルセーフとフェイルセキュアの違いから、ファイアウォール・認証・Webアプリケーションへの具体的な実装方法、中小企業の情シスが今すぐ確認すべきチェックポイントまで、現場目線でわかりやすく解説します。

フェイルセーフ・フェイルセキュアとは？概念と違いを整理する

まず2つの用語を整理しましょう。

1. フェイルセーフ（fail-safe）

フェイルセーフとは、システムが故障・障害に陥ったときに「人的・物理的な安全を優先した状態」に移行する設計思想です。

エレベーターの安全装置が代表例です。ワイヤーが切れたときに落下を防ぐブレーキが自動的に作動します。これは「止まる＝安全」という設計です。ビルの非常口ドアも同様で、停電時に自動的に開放されます。人命の安全を最優先にした結果、「開く」という動作を選んでいます。

セキュリティの文脈では、可用性（Availability）を重視した設計に使われることが多く、「障害時でも業務を止めない」方向に倒れます。

2. フェイルセキュア（fail-secure）

フェイルセキュアとは、システムが障害に陥ったときに「セキュリティ的に安全な状態（アクセスを拒否する方向）」に移行する設計思想です。

銀行の金庫扉がわかりやすい例です。停電時、金庫扉は「閉まったまま」になります。開放されるより閉じているほうがセキュリティ的に安全だからです。これがフェイルセキュアです。

ITセキュリティの文脈では、機密性（Confidentiality）と完全性（Integrity）を優先した設計に使われます。

3. 2つの概念の関係と使い分け

重要なのは、「どちらが正しい」という話ではないことです。守るべき対象と優先する価値観によって、どちらを採用するかが変わります。情報セキュリティの現場では、多くの場合「フェイルセキュア」寄りの設計が求められますが、可用性とのバランスが必要です。

攻撃者はなぜ障害・エラーの瞬間を狙うのか

フェイルセーフ・フェイルセキュアの概念が重要な理由の一つは、攻撃者が意図的に「障害状態」を作り出すことがあるからです。

1. エラー誘発による情報窃取

Webアプリケーションに意図的に不正な入力を送り込んでエラーを発生させ、エラーメッセージにサーバーのパス、データベース構造、ソフトウェアバージョンが表示されるのを利用する手法があります。「障害時に詳細情報を出す」設計がフェイルセキュアではなく、攻撃者への情報提供になっていた例です。

2. 認証サービスの意図的な過負荷

DDoS攻撃（分散型サービス拒否攻撃）で認証サービスに過剰な負荷をかけ、認証サーバーがダウンしたあとに「フェイルオープン（fail-open）」——つまり認証をスキップしてアクセスを許可する——設定を狙う攻撃パターンがあります。

3. ネットワーク機器への割り込み

BGPハイジャックやルーター設定の悪用でネットワーク経路を分断し、フェイルオープンに設定されたファイアウォールがバイパスされる事例も報告されています。

これらは設計段階で「障害時にどちら側に倒れるか」を決めていれば防げたケースです。

システム別のフェイルセキュア実装パターン

1. ファイアウォール・ネットワーク機器

ファイアウォールは最も重要なフェイルセキュア設計の対象です。「fail-closed（フェイルクローズド）」と「fail-open（フェイルオープン）」という概念で語られます。

# fail-closed（推奨: フェイルセキュア）
# ファイアウォールプロセスが落ちたとき、全トラフィックを遮断する
# iptables デフォルトポリシーをDROPに設定する例
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# 必要な通信だけを明示的に許可する（ホワイトリスト方式）
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT

デフォルトポリシーを DROP にすることで、ファイアウォールルールが何らかの理由で機能しなくなったとき、通信は「遮断」に倒れます。これがフェイルセキュアな設定です。

逆に、デフォルトポリシーを ACCEPT にすると、ルールの評価に失敗したパケットはすべて通過します。これはフェイルオープンであり、セキュリティリスクになります。

・fail-closed（フェイルクローズド）: デフォルト拒否。ルール未一致＝遮断。セキュリティ優先
・fail-open（フェイルオープン）: デフォルト許可。ルール未一致＝通過。可用性優先

本番環境のインターネット向けファイアウォールは、基本的にfail-closed一択です。

2. 認証・アクセス制御システム

認証サービスが停止したとき、システムはどう動作すべきでしょうか。

「認証サーバーに接続できない→認証をスキップしてログインを許可する」という設計はフェイルオープンです。可用性は保たれますが、認証サーバー停止が攻撃の踏み台にされる可能性があります。

フェイルセキュアな設計では「認証サーバーに接続できない→ログインを拒否する」になります。

# PAM設定でのフェイルセキュアの考え方
# /etc/pam.d/sshd の例

# requiredを使うことで、認証モジュールが失敗した場合に
# 認証全体を失敗させる（フェイルセキュア）
auth    required    pam_unix.so
auth    required    pam_google_authenticator.so

# sufficientを使うと、そのモジュールが成功すれば後続をスキップ
# 設計によってはフェイルオープンな動作になる可能性があるため注意
# auth    sufficient  pam_unix.so

PAMの `required` は、そのモジュールが失敗してもPAMスタックの評価を続け、最終的に認証失敗として処理します。これにより一部の認証モジュールが機能しなくても、認証全体が失敗（＝アクセス拒否）に倒れます。

3. Webアプリケーションのエラーハンドリング

Webアプリケーションでのフェイルセキュアは、エラー発生時に何を表示するかの設計に現れます。

# NGな設計（フェイルオープン・情報漏洩リスクあり）
# エラー時にスタックトレースやシステム情報を返す
try:
    result = db.query(sql)
except Exception as e:
    # 開発時のデバッグコードが本番に残ってしまったケース
    return f"エラーが発生しました: {str(e)}"
    # 例: "エラー: SQLSTATE[42000]: /var/www/html/db/config.php line 45"

# OKな設計（フェイルセキュア）
try:
    result = db.query(sql)
except Exception as e:
    # 内部エラーはログに記録
    logger.error(f"DB error: {str(e)}", exc_info=True)
    # ユーザーには汎用メッセージのみ返す
    return "処理中にエラーが発生しました。しばらくたってからお試しください。"

エラーメッセージにサーバーのファイルパス、データベース種別・バージョン、SQLクエリの断片が含まれると、それが攻撃者に有用な情報を提供します。フェイルセキュアな設計では、内部エラーの詳細はログに記録し、ユーザーには汎用メッセージだけを返します。

4. 暗号化・TLS設定

TLS通信でもフェイルセキュアの考え方が重要です。

・ダウングレード攻撃への対応: クライアントが古いTLSバージョン（TLS 1.0/1.1）を要求してきたとき、「接続を拒否する（フェイルセキュア）」か「古いバージョンで接続する（フェイルオープン）」かを設計で決めます
・証明書検証失敗時: 証明書の検証に失敗したとき、接続を拒否するのがフェイルセキュアです。「警告は出るが接続を継続させる」設計はフェイルオープンです

Webサーバー（nginx/Apache）では `ssl_protocols TLSv1.2 TLSv1.3;` のように許可するバージョンを明示し、それ以外は接続拒否するのが現代のベストプラクティスです。

中小企業でも今日からできること

フェイルセキュアの概念を理解したうえで、現場で実践できる確認手順をまとめます。

1. ファイアウォールのデフォルトポリシー確認

# iptablesのデフォルトポリシー確認
iptables -L | grep "policy"
# 出力例（フェイルセキュア）:
# Chain INPUT (policy DROP)
# Chain FORWARD (policy DROP)
# Chain OUTPUT (policy ACCEPT)

# firewalldの場合
firewall-cmd --get-default-zone
firewall-cmd --zone=public --list-all
# デフォルトゾーンの設定でフィルタリング方針を確認

`policy ACCEPT` になっているチェーンがあれば、対応するルールが機能しなくなったときに全通過するリスクがあります。インターネット向けのINPUT/FORWARDは `policy DROP` にすることを推奨します。

2. Webアプリのエラーページ確認

存在しないURLにアクセスして、表示されるエラーページを確認します。サーバーのソフトウェア名・バージョン・ファイルパスが表示されていないかチェックしてください。

nginxなら `server_tokens off;`、Apacheなら `ServerTokens Prod` と `ServerSignature Off` を設定することで、エラーページからサーバー情報を隠せます。

3. 認証フローの障害時動作テスト

認証に使っているシステム（Active Directory、RADIUS、SSOサービスなど）を意図的に停止させて、その間のアクセス動作を確認します。「認証サーバーが止まっていても全員ログインできた」という状態は即座に是正が必要です。

4. エラーログの出力先とレベルの確認

アプリケーションのエラーが適切にログに記録されているかを確認します。フェイルセキュアな設計では「ユーザーには出さないが、内部には記録する」が原則です。ログが残っていないと、インシデント発生後の調査ができなくなります。

よくある誤解と注意点

【注意】フェイルセキュアは「可用性の敵」ではない

「全部フェイルセキュアにしたら、障害のたびにシステムが止まってしまう」と心配する声があります。確かに可用性とのトレードオフは存在しますが、現代のシステム設計では両立できるアプローチがあります。

・冗長化で可用性を確保: 認証サーバーをプライマリ・セカンダリで冗長化し、フェイルセキュアを維持したまま可用性を高める
・段階的な縮退運転: 全機能を止めるのではなく、セキュリティ要件の低い機能だけを限定的に継続させる設計
・ブレイクグラスアカウント: 緊急時のみ使用できる特別なアカウントを用意し、通常時は封印する

【注意】すべての場面でフェイルセキュアが最善ではない

医療機器や工場の制御システムでは、物理的な安全（人命）を最優先にするため、フェイルセーフ（安全側＝動作継続）が採用されるケースがあります。「セキュリティのためにシステムを止める」ことで人が危険にさらされる場合は、フェイルセーフを選ぶことが正しい設計です。

情報システムにおいても、業務の性質に応じて「どちらに倒れるか」を意識的に設計することが重要です。

【注意】テストせずに本番適用しない

デフォルトポリシーをACCEPTからDROPに変えると、これまで暗黙的に許可されていた通信が遮断されることがあります。変更前に必ずテスト環境で動作確認し、変更後も段階的に適用してください。

セキュリティバイデザインの考え方として、設計段階からフェイルセキュアを組み込む方法については、姉妹記事「セキュリティバイデザインとは？5つの原則と中小企業での実践方法」も参考にしてください。

本記事のまとめ

フェイルセーフとフェイルセキュアは、セキュリティ設計の出発点となる考え方です。ファイアウォールのデフォルトポリシー、認証システムの障害時動作、Webアプリのエラーハンドリング——これらすべてに「障害時にどちらに倒れるか」の設計判断が含まれています。

「何も考えていなかったらフェイルオープンになっていた」という状況が最も危険です。設計段階で意図的に選択することが、現場のセキュリティエンジニアに求められる実力です。