2026.06.12 2026.06.14

【SASE実践】[設計] [セキュリティ] SD-WAN vs SSE：セキュリティ機能はどちらで実装すべきか

buffoon

現在のSD-WANルータ（Cisco Catalyst SD-WANなど）は非常に優秀で、高度なセキュリティ機能を標準搭載しています。一方で、SSE（Zscalerなど）も同様、あるいはそれ以上の強力なセキュリティチェック機構を持っています。

両方に同じような機能がある場合、「どっちでも実装できるから、両方でガチガチにチェックしておこう」とするのは、設計としては下策です。運用が複雑化し、トラブルシューティングが地獄になるからです。

今回は実務の設計で迷わないための「セキュリティチェックの最適な配置」について結論をお伝えします。

【結論】SSEがあるなら、セキュリティチェックは「SSE」に寄せるべし

結論から言うと、SD-WANとSSEを両方導入（併用）する環境であれば、セキュリティチェック機能は原則として「SSE側」に集約すべきです。

SD-WAN側で行うべきなのは、WAN側（インターネット側）からの一次防御（DDoS対策など）に限定し、それ以外の社内から外へ向かう通信のチェックはすべてSSEに任せるのがベストプラクティスです。

なぜ、SD-WANではなくSSEに寄せるべきなのか？理由は明確で「境界の概念が変わったから」です。

理由：拠点とリモートで「一貫したセキュリティポリシー」を担保するため

ユーザーが拠点から通信を発信する場合、パケットは「端末 → SD-WANルータ → SSE → インターネット」という経路をたどります。

しかし、リモートユーザーは拠点のSD-WANルータを通りません。「端末 → SSE → インターネット」と直接SSEへと向かいます。

もし、URLフィルタやIPSの機能を「SD-WANルータ」側で実装してしまうと、拠点で仕事をしている時と自宅でリモートワークをしている時で、セキュリティの強さやルールが変わってしまうという致命的な問題が発生します。

場所を問わず、内（拠点）から外（インターネット）を目指す通信に対して一貫したセキュリティチェックを担保するためには、全員が必ず通過する「SSE」で一元管理するのが最も合理的です。

重要ポイント：TeamsやZoomなどの「LBO通信」はどう考えるべきか？

ここで一歩踏み込んだ設計実務の話をすると、「Microsoft 365やTeams、Zoomといった特定の既知のアプリケーションは、SSEを経由させずに拠点からローカルブレイクアウト（LBO）させる」という経路最適化を行うのが一般的です。

「SSEを通さないなら、そのLBO通信に対してSD-WANルータ側でセキュリティチェック（プロキシ処理やIPSなど）をかけるべきでは？」と思われるかもしれません。

しかし、その必要はありません。

そもそもTeamsやZoomなどの公式通信をLBOさせるのは、「ベンダー側で十分なセキュリティ対策がなされており、悪意ある通信が含まれるリスクが極めて低い（＝安全である）」と企業として判断しているからです。安全だと信頼しているからこそ、遅延を防ぐために直接インターネットへ逃がすわけです。

したがって、これらの既知のLBO通信に対しても、SD-WANルータ側でわざわざ不要なセキュリティチェックを回す必要はありません。ここでもSD-WANルータはチェック処理の負荷から解放され、シンプルに「これはTeamsの通信だからLBO用の回線へ振り分ける」という経路の識別と最適化（Application-Aware Routingなど）に専念させるのが正解です。

拠点間通信（内向き）もSD-WANは「ルーティング」に専念させる

「では、拠点と拠点をつなぐ内向きの通信（拠点間通信）のセキュリティはどうするのか？」という疑問が湧くかもしれません。

ここでも、SD-WAN側に過度なセキュリティチェックを仕込む必要はありません。

なぜなら、SASE環境におけるリモートアクセスや拠点間の一部通信は、ZTNA（Zero Trust Network Access）によって「アプリケーション単位」での通信許可が前提となっているからです。

ZTNAにより、通信はすでに「最小権限」「最小宛先」に絞り込まれてオフィス内に届いている。
危険な通信は、中に入る手前のフェーズ（ZTNA）で排除されている。

したがって、すでに綺麗にフィルタリングされて届いた拠点間通信に対して、SD-WANルータ側でさらに重たいセキュリティチェックを回す必要はありません。

SD-WAN側はセキュリティ処理の負荷から解放される分、本来の主たる任務である「回線品質（遅延やジッター、パケットロス率など）の可視化と、それに基づいたベストパスの決定・パケット伝送」にその強力なリソースを特化させるべきです。これこそが、SD-WANの「動的な経路最適化」という強みを最大限に活かす設計と言えます。

例外：SD-WAN「しか」入れないパターンの設計

ここまで「SSEへの集約」を推奨してきましたが、唯一の例外があります。それは「予算やプロジェクトのフェーズの都合で、SD-WANしか導入しない（SSEは入れない）」というパターンです。

この場合に限っては拠点からインターネットへ直接抜ける通信を無防備にするわけにはいきません。

SSEという盾がいない環境においては、SD-WANルータを「UTM」としてフル活用するのが正解です。

最低限行うべき通信チェック（IPS/IDS、URLフィルタリング、アンチウイルス等）をSD-WANルータ側で動作させる。
拠点の通信の安全性をルータ単体で担保する。

つまり、SD-WANルータのセキュリティ機構は、「SSEがいない場合のためのバックアッププラン」として捉えるのが設計上、非常にスッキリします。

「まとめ：適材適所で「運用のシンプルさ」を勝ち取る」

SD-WANとSSE、どちらも強力なレイヤーだからこそ、役割分担を曖昧にすると「設定の重複」「切り分けの長期化」「ライセンスの無駄遣い」を引き起こします。

今回の設計の要点をまとめます。

原則（SSE併用時）: セキュリティチェックはSSEに一元化。SD-WANは「回線品質に合わせたベストパスの決定」や「信頼できるアプリ（Teams/Zoom等）のLBO識別」に特化させる。
理由: 拠点・リモートを問わず一貫したポリシーを担保し、安全な通信はそのまま流すことで、ルータの処理負荷とネットワーク遅延を最小限に抑えるため。
例外（SD-WAN単体時）: SSEがいない場合のみ、SD-WANルータのUTM機能をフル活用して自衛する。

機能の重複を排除し、それぞれのコンポーネントを「最も得意な領域」に集中させること。これこそが運用フェーズでトラブルに強く、かつパフォーマンスの高いSASEネットワークを作るための鍵となります。