2026.06.17 2026.06.18

【SASE実践】[障害シナリオ] SSE（PoP）障害による「全社通信停止」とその回避策

buffoon

「SASE/SSEを導入してクラウドもセキュリティも万全！これで社内のレガシーなプロキシやインターネットGWはすべて廃止できるぞ！」

……本当にそうでしょうか？

近年、企業のネットワーク・セキュリティの最適解として定着したSASEやSSE。しかし、すべてのトラフィックをクラウド上の接続拠点（PoP）に集約するアーキテクチャには常に「クラウドシングルポイント（PoP障害）による全滅」という最大のリスクが付きまといます。

もし利用しているSSEサービスが広域で大規模な障害を起こしたら、あなたの会社のビジネスはどうなるでしょうか？

今回は、ネットワークエンジニアの視点から、「SSEのPoPが全損した」という最悪の障害シナリオを想定し、出社している社内ユーザーのインターネットアクセスをいかにして泥臭く救うか、その具体的な回避策と設計のジレンマについて考察します。

恐怖のシナリオ：PoP障害がもたらす「全社通信停止」

SSEを全社導入している環境において、PoPが広域障害で完全にダウンした場合その影響は壊滅的です。今回のシナリオではリモートワーク環境からのアクセスについてはPoPが死んでいるため「全断（接続不可）」と割り切って諦めるものとします。

しかし、「せめて出社している社内ユーザーのインターネットアクセスだけでも救いたい」というのが、現場の共通の願いではないでしょうか。

通常、社内PCはPACファイルやクライアントソフトの制御によってすべてのWebトラフィックをSSEのPoPに転送しています。その宛先が全滅したとき、何の対策も講じていなければ、社内からのブラウジング、SaaS利用、認証トラフィックなど、すべてのインターネット通信が完全にストップしてしまいます。

対策案①：SSE単体でのDRソリューション

まず検討に値するのが、SSEベンダーが提供している単体で完結するDRソリューションです。例えば、主要なSSEでは以下のような仕組みが用意されています。

Private Service Edge（旧PZENなど）の導入 これは、クラウド上にあるPoPの機能を、社内のオンプレミス環境にアプライアンスや仮想マシンとして設置するソリューションです。

メリット

クラウドのPoPが死んでも、社内設置型の筐体が身代わり（DR）として動作するため、通常時と全く同じセキュリティポリシーを維持したまま通信を継続できます。

課題（なぜこれだけではダメなのか？）

最大のネックは「コストと手間の割に、めったに起きない障害への投資」である点です。DRのためだけに高額なライセンスや専用アプライアンスを維持する贅沢は、経営層への費用対効果（ROI）の説得が非常に困難です。また、オンプレ環境に新たな管理対象（運用負荷）が増える点もエンジニアとしては頭の痛い問題です。

対策案②：既存コンポーネント（SD-WAN×社内プロキシ×GPO）を駆使した回避策

高額なDRソリューションに頼れない場合、いま社内にあるリソース（SD-WAN、社内プロキシ、インターネットGW、GPO）をフル活用した「泥臭い回避策」を模索することになります。

目指すべきは「通常時用PAC」から「緊急時用PAC」への切り替えとSD-WANによる柔軟なトラフィックの仕分け（制御）です。

① 発動トリガーと切り替えの仕組み

クラウドPoPのヘルスチェック（死活監視）失敗をトリガー、あるいは管理者からの緊急指示としてActive DirectoryのGPO等を駆使して、社内PCが読み込むPACファイルを「緊急時用」へと瞬時に切り替えます。

② 緊急時PACによるトラフィックの仕分け

すべての通信をひとつの経路に流すのではなく、通信の性質に応じて以下のように仕分けます。

テナント制御・認証通信（機密性：高 / 通信量：小）
- 「社内プロキシ（オンプレ環境）」へ集約
- 社内のインターネットGWから外へ出します。これらの通信は会社の統制やセキュリティ担保が絶対に外せない一方で、セッション数や帯域はそこまで爆発しないため、レガシーな社内プロキシに集めて処理させます。
社内利用が許可されている主要SaaS（M365、Boxなど / 信頼性：高 / 通信量：大）
- PACでSSEを「バイパス」し、SD-WANで「LBO（ローカルブレイクアウト）」
- これらは信頼できる宛先であり、かつトラフィックの大部分を占めるため、緊急時PACでプロキシをバイパスさせ、拠点のSD-WANのLBO機能を使って直接インターネットへ逃がします。

【本音の葛藤】バイパス・LBOが引き起こす「デグレ vs パンク」のジレンマ

理論上は上記の手法で通信を救えそうですが、いざ実設計に落とそうとすると現場のエンジニアは深い「ジレンマ」に陥ることになります。

葛藤①：無造作にバイパス・LBOさせると「セキュリティのデグレ」が起きる M365やBoxをバイパスさせるのは良くても、もし「その他大勢の野良インターネット通信」まで無造作にバイパスさせてしまうと、SSEが提供していたURLフィルタやサンドボックス、ログ監査が一切効かない「ガラ空き」の状態になります。万が一、この緊急時にマルウェア感染や情報漏洩が発生すれば、目も当てられません。
葛藤②：かといって社内プロキシに寄せすぎると「オンプレ環境がパンク」する セキュリティのデグレを恐れて、多くの通信を社内プロキシに集約しようとすると、今度はかつて「脱プロキシ」を進めたはずの細い社内回線や、リソースの縮小されたオンプレプロキシの帯域が確実にパンクします。結局、誰もインターネットに繋がらないという元の木阿弥に戻ってしまいます。

現場のリアルな落としどころ（設計の妥協点）

このジレンマに対する現実的な解は、「緊急時は100点（通常時と同じセキュリティ）を諦め、70点（業務継続＋最低限の統制）で耐える仕様」を事前に定義し、会社として合意しておくことです。

具体的には、宛先IPやURLの範囲が完全にホワイトである「M365」や「Box」といった特定SaaSだけを徹底的に洗い出してLBOで逃がし、それ以外の「どうしても必要なWebブラウジング」は、細々と残してある社内プロキシ経由に限定。さらに緊急時プロキシ側では「最低限のURLフィルタだけをかける（＝重くてもいいから繋がる状態を維持する）」といったトレードオフの設計が泥臭くも現実的なラインになるでしょう。

補足：リモートユーザーを「レガシーVPN」で救うのはアリか？

「社内ユーザーは救えても、リモートユーザーは見捨てるしかないのか？いっそのこと昔使っていたVPN環境を『緊急用』として残しておけばいいのでは？」

そう考える方もいるかもしれません。確かに通常時はポートを閉じておき、有事の際だけVPNゲートウェイを叩き起こしてリモートユーザーを終端させる手法は理論上は「アタックサーフェス（攻撃面）を抑えたBCP対策」に見えます。

しかし現場のリアルな運用を考えると、

平時にテストしていないVPNが、本番障害時に一発で動くのか？（証明書切れやクライアントソフトの未更新）
SSEが死んでいる状態で、VPNのユーザー認証をどう担保するのか？
全員が殺到した瞬間に、細い社内回線とVPN装置がパンクするのではないか？

結局、レガシーVPNの維持は、セキュリティのデグレだけでなく「動くかどうかわからない高コストな保険」を抱え続ける運用負荷を生みます。やはりリモートワーク側は「SSEの信頼性に賭ける（またはPrivate Service Edgeの検討）」と割り切り、影響度を『社内だけは死守する』に限定する方がアーキテクチャとしては健全と言えるでしょう。

まとめ：『クラウド全振り』の時代だからこそ、レガシーが命綱になる

今回の考察から得られる結論は、「SSEでのDR（Private Service Edge）を本線として検討・予算化を試みつつも、それが難しい現実を鑑みるならば、かつて捨て去ろうとした『社内プロキシ』や『インターネットGW』を、薄く細く社内に残しておくことこそが、最強のBCP（事業継続計画）になる」ということです。

「古い技術やオンプレミス環境を完全に撤廃する」ことだけが正義ではありません。ハイブリッドな環境を「保険」としてあえて残し、緊急時にそこへトラフィックを逃がす設計ができるかどうか。それこそがクラウド時代において本当に「自分でコントロールできるネットワーク」を構築するための、エンジニアの知恵なのではないでしょうか。