2026.06.11 2026.06.20

【SASE実践・適用設計編】[前段] 通信経路とセキュリティ機能を分けて設計する

buffoon

SD-WANとSSE（Security Service Edge）2つのコンポーネントが絡み合うため、「どこから手をつければいいのかわからない」「設計の全体像が見えにくい」というご意見もあるかと思います。

SASEの設計をスムーズに進めるためのコツは、「通信経路（ネットワーク）」と「セキュリティ機能」を一旦分けて（分離して）考えてみることです。これらを分けて整理するだけで、複雑に見えるSASEの全体像が驚くほどシンプルに見えてきます。

今回は【実践・適用設計編】の前段として、複雑なSASEの設計をシンプルに紐解くための「パーツの分け方」と「通信の2つの方向性」について解説します。

通信の本質を「2つの方向」で整理する

【SASEとは】SASEの仕組み

こちらの記事でも紹介しましたが、SASEの具体的な機能に踏み込む前にまずは企業の通信を「誰がどこにアクセスするか」という本質的な2つの方向に整理すべきです。この2つの経路によって、SD-WANとSSEの主役（どちらの機能を重視すべきか）が入れ替わります。

インターネット向けの通信（外向き）：拠点やリモート環境から、Microsoft 365などのSaaSや一般Webサイトへ抜ける通信。
社内通信（内向き）：拠点間（拠点 ⇄ 本社/DC）、またはリモート環境から社内システム（リモート ⇄ 本社/DC）へアクセスする通信。

この2つの方向性を頭に入れた上で「経路」と「セキュリティ」のパーツを分解していきます。

設計をシンプルにする「3つのパーツ」

適用設計をスムーズに進めるためには、インフラを以下の3つのパーツに分解して定義するのがおすすめのアプローチです。

【パーツ1】SD-WANで制御する機能（拠点エッジ）

主に「内向き通信の最適化」と「外向き通信の交通整理」を担う、ネットワークの足回りのレイヤーです。ここでは高度なセキュリティ検査は行わず、パケットを目的地に応じて「どこに、どう流すか」のルーティング制御に特化させます。

具体的には、拠点エッジデバイス（SD-WANルータ）は主に以下の3つのトラフィック制御を司ります。

① ローカルブレイクアウト（LBO）：Microsoft 365やZoomなど、信頼できる特定のSaaSトラフィックを識別し、データセンターを経由させずに拠点のローカル回線から直接インターネットへ逃がします。
② 拠点間通信（内向き）：本社やデータセンター（DC）、他の拠点にある社内システム宛ての通信を、最適なオーバーレイ経路（VPNや閉域網）を選択して安全に相互接続します。
③ SSEへの転送（外向き・内向きの関所へ）：一般Webサイトや、LBO対象外のSaaS宛ての通信（＝セキュリティ検査が必要なトラフィック）をパーツ2で構築するSSEの接続ポイント（POP）に向けてカプセル化して転送します。

【パーツ2】SSEまで到達する経路（トランスポート・接続性）

ユーザーや拠点から、後述する「セキュリティの関所（SSE）」まで、トラフィックを安全に送り届けるためのアプローチ方法の設計です。実はここが、製品選定やアーキテクチャによって設計が大きく変わるパーツです。

拠点からの接続（拠点 ⇄ SSE）：SD-WANルータ等のエッジデバイスから、SSEの最寄りの接続ポイント（POP）に対してIPsecトンネルやGREトンネルを自動常時接続します。
- このトンネルは通常、インターネット向けの通信（外向き）のセキュリティ検査を通すために使われますが、ソリューション（Prisma Accessなど）によっては、「ZTNAで繋がってきたリモートユーザーが拠点内の社内システムへアクセスするための内向きの経路確保（帰りの通信用トンネル）」として兼用・設計されるケースもあります。
リモート環境からの接続（モバイル ⇄ SSE）：PCやスマートフォンに導入した専用のクライアントエージェントを介して、暗号化された通信をSSEへ直接転送します。

【パーツ3】SSEで実装するセキュリティ機能（クラウドエッジ）

主に「外向き通信の安全確保」と、「内向き通信のゼロトラスト化」の核心となるレイヤーです。すべての通信をクラウド上の「一元化されたポリシー」で検査します。

DNSセキュリティ：すべての通信の起点となる「DNSリクエスト」の段階で脅威をブロックする防御の第一層です。DNSパケット（クエリ）の内容をリアルタイムに検査し、接続先がフィッシングサイトやC2サーバー（悪意ある司令塔）でないか、不正なAレコード（IPアドレス）が返ってきていないかをチェックします。実装としては、端末や拠点のDNSフォワーダの参照先を「SSEが提供する安全なDNSのIPアドレス」に変更・強制適用する設計が一般的です。
SWG（Secure Web Gateway）：不正なWebサイトへのアクセスブロック、URLフィルタリング、SSL/TLS復号による通信内部のウイルス・マルウェア検知。
CASB（Cloud Access Security Broker）：会社が許可していないSaaS（シャドーIT）の利用制限や、許可されたSaaSからの機密情報漏洩（DLP）を防止。
FWaaS（Firewall as a Service）：Web（HTTP/HTTPS）以外のプロトコルも含め、すべてのポートの通信をクラウド上で制御・ログ取得。
ZTNA（Zero Trust Network Access）：【内向き通信】において、従来の「VPNで一度繋がれば社内はフリーパス」という概念を捨て、「誰が、どのデバイスから、どの社内アプリにのみアクセスしてよいか」を最小特権で制御。
- 注意点：Zscaler（ZPA）などのアーキテクチャを採用する場合、リモートユーザーからのZTNA通信を社内システムに届けるために、ローカル環境（データセンターや拠点）側に専用の接続ポイント（App Connector等）を配置し、SD-WANや既存の社内ネットワークとどう紐付けるかという「接続ポイントの設計」が不可欠になります。「クラウドを入れれば終わり」ではなく、オンプレミス側との境界線をどうデザインするかが重要です。

分けて考えると、なぜ設計・運用が楽になるのか？

これらを混ぜて設計してしまうと、「拠点のルータでどこまでセキュリティをかけるか？」「このSaaSを許可するとき、ルータとクラウドの両方の設定を変えなければいけないのか？」といった設計・運用のジレンマに陥り、管理の複雑化を招きがちです。

役割ごとにパーツを切り離して捉えることで、次のような運用のメリットが見えてきます。

トラブルシューティングが格段に早くなる 「通信が遅い・繋がらない」ときはパーツ1・2（ネットワーク側）を疑い、「特定のサイトが開けない・制限される」ときはパーツ3（セキュリティ側）を確認する、といったように原因の切り分けが非常にスムーズになります。
変化に対して柔軟に対応できる（ポリシーの一元管理） 基本的には、クラウド上のSSE（パーツ3）のポリシーを1箇所書き換えるだけで、全拠点・全リモートユーザーに即座に安全な共通ポリシーを適用できるようになります。

注意点：LBO設計における「パーツ間の連動」

「概念として分ける」ことはおすすめですが、実運用では「SD-WAN側でアプリ判定を行うLBO」を組むと、パーツ間が連動して設定変更が必要になるという落とし穴があります。

新しいSaaS追加時の運用負荷 「新しいSaaSをLBOしたい」場合、SSEだけでなくSD-WAN側（パーツ1）でもアプリ識別のポリシー変更やシグネチャ更新が発生します。実装次第でネットワーク側の運用負荷が跳ね上がります。
DNS（名前解決）の経路の複雑化 LBOを成立させるには正しい名前解決が必須です。「DNS通信だけをパーツ3（SSE）に投げるのか、LBO経路にそのまま流すのか」というDNSの経路設計（パーツ2）とセキュリティ（パーツ3）の連動を整理しておかないと、「LBOした通信だけが繋がらない」といった複雑なトラブルを招きます。

「概念を分けて整理する」のは大前提として、実運用ではLBOやDNSをトリガーに各パーツがどう連動するかまで見据えて適用設計を作り込むことが、破綻しない運用の隠れた肝になります。