ハイブリッド SSE の耐障害性：フェイルオーバーと復旧

Security Service Edge レジリエンスとは、コンポーネントや依存関係に障害が発生した場合でも、SSEの適用機能を通じてユーザーとデータを保護し続け、ユーザーが業務を継続できるようにする能力のことです。ハイブリッドSSEでは、オンプレミスに2つ目の適用場所が追加されるため、障害が発生しうる部分と、引き続き稼働しうる部分が変化します。Skyhighのアーキテクチャでは、Webゲートウェイとprivate access はオンプレミスのゲートウェイで適用され、データ保護、分離、AI制御、CASB、およびデータポスチャー管理はSkyhighクラウドで適用されます。

この記事は、「ハイブリッドクラウドのセキュリティ」ガイドの一部です。

なぜ今、SSEのレジリエンスが重要なのか

SSEの耐障害性が重要なのは、クラウド経由で提供されるセキュリティでは、セキュリティ対策が共有インフラに集中しており、そのインフラが一度に全員に対して機能しなくなる可能性があるためです。

クラウド型セキュリティでは、セキュリティ対策の実施がプロバイダーのインフラに集中しています。これにより拡張性が確保されますが、一方で、あるプロバイダーでインシデントが発生した場合、すべての顧客が一斉に影響を受ける可能性もあります。

2025年に発生した2つの事例が、この傾向を如実に示している：

• AWS、2025年10月19日～20日。DynamoDBの自動DNS管理機能に潜んでいた不具合により、us-east-1リージョンでエンドポイントの解決に失敗が発生しました。AWSの事後報告によると、この事象は10月19日午後11時48分（PDT）から10月20日午後2時20分（PDT）にかけて発生し、ロードバランシングや新規インスタンスの起動に連鎖的な影響が及びました。
• Cloudflare、2025年11月18日。データベースの権限設定の変更により、巨大な設定ファイルが生成され、それがCloudflareのネットワーク全体に波及し、トラフィックの配信に広範囲にわたる障害を引き起こした。Cloudflareのインシデントレポートによると、エンジニアたちは当初、大規模なDDoS攻撃を疑っていたという。

どちらの事例も、厳密にはセキュリティベンダーのサービス停止そのものではありませんでしたが、いずれも共有インフラにおける設定ミスが連鎖反応を引き起こす様子を示しています。単一のプロバイダーに依存しているセキュリティサービスやアクセスサービスは、そのプロバイダーのサービス停止に伴い機能しなくなる可能性があります。

ガートナーも、SSE市場において同様の懸念を指摘している。同社の2026年のSSEに関する調査レポートでは、ベンダー各社がオンプレミスでSSEのデータプレーンを拡張する仮想アプライアンスやハードウェアアプライアンスの提供を拡大しており、これによりローカルでのトラフィック処理が可能となり、予期せぬクラウドのダウンタイムに対する耐性が向上すると述べられている。これは、Skyhigh Securityが2026年8月に発表した内容でも引用されている。

想定すべき故障モード

単一の拠点での障害からプラットフォーム全体のクラウド障害に至るまで、7つの障害モードを想定した計画を立ててください。

フェイルオープンとフェイルクローズド

すべてのエンフォースメントポイントには、明確に定義された障害時の挙動が必要であり、適切な選択はトラフィックのクラスによって異なります：

• 失敗（クローズ）：強制実行が利用できない場合、トラフィックはブロックされます。保護は維持され、作業は停止します。
• フェイルオープン：強制機能が利用できない場合、トラフィックは検査をバイパスする。処理は継続されるが、保護機能は失われる。

いずれも、あらゆるケースにおけるデフォルト設定とすべきではありません。一般的なパターンとしては、リスクの高いカテゴリ、規制対象のデータフロー、および特権アクセスについては「フェイルクローズ」とし、リスクの低い一般的なブラウジングについては、期間限定で「フェイルオープン」（ログ記録付き）とするものです。トラフィッククラスごとにこの選択内容を文書化し、ベンダーに確認して、トラフィッククラスごとにどのフェイル動作が設定可能かを確認した上で、フェイルオープン状態が有効になっていることをユーザーおよびセキュリティオペレーションセンターが把握できるようにしてください。

ハイブリッドSSEでは、クラウドが利用できない場合でもローカルトラフィックを引き続き強制できるため、この選択が重要になる頻度が低くなります。

キャッシュされたポリシーとローカルでの決定

地方の法執行機関は、独自に決定を下せる場合にのみ、強靭性を発揮できる。

各ローカルコンポーネントが何をキャッシュしているかを確認します：

• ポリシー：ゲートウェイは、コンソールに接続できない場合でも、最後に認識されたポリシーを引き続き適用し続けますか？
• URLの分類と評価：ローカルデータベースは存在するのか、また、その情報がどれほど古くなっても、ルールの適用精度が低下しないか？
• 認証：IDプロバイダーまたはクラウド認証サービスに接続できない場合、セッションを継続したり、新しいセッションの認証を行ったりすることは可能ですか？
• DLPの分類とフィンガープリント：ここで説明するSkyhighの導入環境では、データ保護はクラウド上で適用されます。クラウドへの接続が利用できない場合、ローカルゲートウェイではデータ保護は継続されません。remote browser isolation 、AIセキュリティ制御、CASB、およびDSPMも同様にクラウド依存要素として扱い、各サービスの動作を検証してください。
• ライセンス：ライセンスの有効性確認に失敗した場合、猶予期間はありますか？
• ログ：イベントはローカルにバッファリングされ、接続が回復した際に転送されますか？

クラウドの依存関係

ローカルコンポーネントからのすべての外部依存関係をリストアップし、担当者と許容可能な停止時間を割り当ててください。

依存関係の完全なチェックリストについては、「プライベートSSEの導入：アーキテクチャとクラウドの依存関係」を参照してください。

フェイルオーバーの設計

耐障害性に優れたハイブリッドSSEは、ローカルクラスタリングと、単一のポリシー下でのローカルとクラウド間のフェイルオーバーを組み合わせています。

ローカルでの高可用性。主要な各拠点に、ロードバランシングとヘルスチェック機能を備えたゲートウェイをクラスタまたはペアで展開します。コンテナ化または仮想アプライアンスを利用することで、容量を迅速に拡張することが容易になります。

ローカルサイト向けのクラウドフェイルオーバー。ローカルゲートウェイクラスターに障害が発生した場合、トラフィックを同じポリシーの下にあるクラウドのPoP（接続拠点）へ迂回させます。これには、ローカルとクラウドの両方の適用処理が1つのポリシーエンジンを共有している必要があります。そうしないと、フェイルオーバーによってユーザーが従うべきルールが変更されてしまいます。

クラウドユーザー向けのローカルフォールバック。通常はクラウド上で検査を受けているユーザーが、クラウドの障害発生時にオンプレミスにいる場合、トラフィックをローカルゲートウェイ経由でルーティングします。これらのユーザーに対しては、ローカルでのWebおよびプライベートアプリケーションのポリシー適用が維持されます。データ保護、ブラウザの分離、AIによる制御、およびCASBはクラウド上で適用され、通信経路が復旧した時点で再び適用が再開されます。

リモートユーザー向けのマルチPoPフェイルオーバー。エージェントおよびトンネルがセカンダリPoPに自動的にフェイルオーバーされること、およびそれがどのリージョンで発生するかを確認してください。特に、居住地ルールによって検査場所が制限されている場合は注意が必要です。

ブランチの継続性。ビジネスの重要度に基づいて、どのブランチでローカルでの適用を行うか、どのブランチで地域またはクラウドでの適用に依存するかを決定します。

復旧テスト

試されていないレジリエンスは単なる仮定に過ぎないため、定期的なテストスケジュールを策定しましょう：

• コンポーネントの障害：ゲートウェイノードを停止させ、ユーザーに影響を与えずにフェイルオーバーを確認する。
• クラウドへの到達不能：あるサイトからのベンダーのクラウドへのアクセスをブロックし、ローカルでの適用状況、キャッシュされたポリシー、およびログ記録の挙動を確認します。
• IDサービスの停止：IDプロバイダーが利用できない状態をシミュレートし、セッションの挙動を確認します。
• フェイルオープンおよびフェイルクローズの動作：各トラフィッククラスが設計どおりに動作することを確認する。
• 復旧：ベンダーに、障害発生時に適用されるログバッファリング容量とオーバーフロー時の動作について確認し、実際にどのようなデータが届くか、また障害発生中に実施されたポリシー変更がその後も反映されることを確認してください。

NISTのSP 800-34は、ビジネスシステムと同様にセキュリティインフラにも適用される緊急時対応計画の枠組みを規定しています。EUの金融機関については、2025年1月17日から施行される「デジタル・オペレーショナル・レジリエンス法」により、デジタル・オペレーショナル・レジリエンスのテストや、重要なプロバイダーに対する代替計画を含むICTのサードパーティ・リスクの管理が義務付けられています。

ベンダーと確認すべき運用上の制限

各SSEベンダーの耐障害性に関する主張を鵜呑みにする前に、その運用制限について各ベンダーに確認してください。

• 各サービスごとに公開されているSLA、および可用性の測定方法
• クラウドに接続できない場合の各ローカルコンポーネントの動作と、その状態がどのくらいの期間続くか
• キャッシュされた分類、脅威インテリジェンス、およびポリシーの有効期限が切れるまでの最長期間
• 各拠点間、およびローカルとクラウド間の適用処理間のフェイルオーバー時間
• フェイルオーバーが可能なリージョン、およびフェイルオーバーがレジデンシーの境界を越えて行えるかどうか
• TLS 検査が有効な場合のアプライアンスごとおよびクラスターごとの容量制限
• 誤った設定がすべての顧客に一斉に及ぶのを防ぐための、更新および変更管理の手法
• インシデント対応プロセスおよび過去のインシデント報告書

SkyhighによるSSEのレジリエンスへの取り組み

Skyhighクラウドパスが利用できない場合、オンプレミスゲートウェイは、検証済みのポリシー、ID、およびライセンスの制限範囲内で、ローカルWebおよびプライベートアプリケーションに対するセキュリティ対策を引き続き実施します。接続およびサービスが復旧するまで、そのパス上では、クラウドで適用されるDLP、RBI、AIセキュリティ制御、CASB、およびDSPMは利用できません。

Skyhigh Hybrid SSE Meshは、必要に応じてSSEデータプレーンをオンプレミスに維持するため、組織独自のゲートウェイ上でローカルWeb検査とローカルZTNAが継続される一方で、クラウドのPoP（接続拠点）がリモートユーザーに対応します。1つのコンソールとポリシーエンジンで両方の経路を管理しますが、利用可能な制御機能は適用場所やリアルタイムの依存関係によって異なります。Skyhighの2026年3月のプラットフォームアップデートでは、コンテナ化されたアプライアンスアーキテクチャと動的トラフィックルーティングが追加されました（Skyhigh Security）が追加され、Skyhighはプラットフォームの稼働率を99.999%と報告しています。

出典

1. AWS. 「北バージニア（US-EAST-1）リージョンにおけるAmazon DynamoDBのサービス障害の概要」（2025年10月）。https://aws.amazon.com/message/101925/
2. Cloudflare. 「2025年11月18日のCloudflareサービス停止について」https://blog.cloudflare.com/18-november-2025-outage/
3. Skyhigh Security. 「Skyhigh Security 、2026年ガートナー『Critical Capabilities forSecurity Service Edge』の『Advanced SSE Use Case』部門で第1位にランクイン」（2026年8月5日）。https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
4. NIST.SP 800-34 Rev. 1: 連邦情報システムのための緊急時対応計画ガイド。 https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
5. 欧州連合。規則（EU）2022/2554（デジタル・オペレーショナル・レジリエンス法）。 https://eur-lex.europa.eu/eli/reg/2022/2554/oj
6. Skyhigh Security. 「Skyhigh Security 、革新的なユニバーサルSSEプラットフォームを強化する新ソリューションを発表」（2026年3月24日）。https://www.skyhighsecurity.com/about/newsroom/newswire/skyhigh-security-announces-new-solutions-to-strengthen-disruptive-universal-sse-platform.html