2026.06.15 2026.06.19

【SASE実践】[前段] ネットワーク制御型SSEとZTNA機能分離型SSE

buffoon

SASEやSSEを検討する際、「どれも同じクラウドセキュリティ製品」に見えていませんか？

実は主要なSSE製品はその「出自（ルーツ）」によって大きく2つのタイプに分類することができます。1つはファイアウォール（FW）アプライアンスから進化した「ネットワーク制御型」。もう1つはプロキシから進化した「ZTNA機能分離型」です。

この2つの違いを理解していないと、「導入したけれどネットワーク経路が複雑になりすぎた」「社内と社外での切り替え運用が煩雑でユーザーから不満が出た」といった失敗に繋がりかねません。

今回は、SASE提案・設計の現場目線から、この2つの型の特徴とメリット・デメリットを徹底解説します。

ファイアウォールから昇華した「ネットワーク制御型SSE」

技術のベースと通信の仕組み

このタイプは、Prisma AccessやFortiSASEなどが代表例です。オンプレミスの次世代FWやUTMアプライアンスの機能をそのままクラウドへシフトさせたモデルと言えます。

通信の集約方式：インターネット向け、リモートワークからの通信、さらには拠点からの通信もすべて同じトンネル（主にIPsecベース）で一度クラウド（SSE）に集約し、そこで一括して通信制御を行います。
最大の強み（拠点間通信）：FWがベースであるため、リモート→拠点、リモート→インターネット、拠点→インターネットだけでなく、拠点→拠点（拠点間通信）も可能です。
シングルベンダーSASEとの親和性：同一ベンダーの機器を使えば、SSE上でSD-WANをシームレスに動作させることも可能です。ネットワークとセキュリティを一つのエコシステムで完結させたい場合に強力な選択肢となります。

プロキシとVPN代替を組み合わせた「ZTNA機能分離型SSE」

技術のベースと通信の仕組み

こちらは、Zscalerが代表例です。オンプレミスのプロキシサーバーをクラウドプロキシ（SWG）へと昇華させ、そこにVPNに代わるソリューションとして「ZTNA」を足し算で組み合わせたモデルです。

通信の集約方式：元々がプロキシベースの技術であるため、主にインターネット（SaaSやWebサイト）向けの通信をSSEに集約してセキュリティチェックを行います。クライアントソフト（エージェント）がなくても、Webブラウザベースの通信であれば成り立たせやすいのが歴史的な特徴です。
社内リソースへのアクセス（ZTNA）：これだけでは社内システム（業務通信）にアクセスできないため、リモートユーザー向けに「ZTNA機能」を独立したトンネルとして作り込んでいます。社内リソースの前段に「コネクタ」と呼ばれる中継ポイントを設置し、そこを経由して安全にアクセスさせます。
特徴：SWG（インターネット用）とZTNA（社内用）で2つのトンネルが明確に分かれているため、拠点→拠点のシームレスな通信には不向きです。
Zscalerに加えて、Netskope、Akamai、Trellix等もSWGの機能にZTNAを加えた型に属します。

両者のメリット・デメリット（比較表）

それぞれの機能には一長一短があります。設計・運用面でのリアルな違いを比較します。

比較項目	ネットワーク制御型SSE	ZTNA機能分離型SSE
主なルーツ	次世代FW、UTM	クラウドプロキシ（SWG）
トンネル構成	シングル（IPsec等で集約）	マルチ（SWG用とZTNA用で分離）
拠点間通信	得意（SD-WAN領域と重複・連携）	不向き（拠点網は別途考慮が必要）
クラウド障害時の影響	全通信が影響を受けるリスクあり	片方の障害が他方に影響しにくい
社内持ち込み時の挙動	社内/社外でエージェントの制御（ON/OFF）の切り替え設計が重要	ZTNAのみ落とし、SWGは常時ONで同じセキュリティポリシーを維持しやすい
ネットワークの複雑さ	シンプルで分かりやすい	ZTNAコネクタと既存網（JTC等のSD-WAN）の相互接続ポイントの設計が複雑になりがち

運用・設計面での「落とし穴」

ネットワーク制御型の場合：社内にPCを持ち込んだ際、明確に「社内/社外」を検知してエージェントの通信を切り替えないと、社内サーバーへの通信なのに一度クラウド（SSE）を迂回して戻ってくるという非効率な経路が発生します。エージェントをOFFにする場合は、今度はオフィスからのインターネット通信を担保するために、オフィスのルータ等からSSEへ別途IPsecを張るような設計が必要になります。
ZTNA機能分離型の場合：2つのトンネルを使うため一見複雑ですが、オフィスにPCを持ち込んだ際は「最低限ZTNA用のトンネルだけ落とす」という制御にすれば、SWG（インターネット用）のトンネルは生かしたまま、社内でも社外でも全く同じWebセキュリティポリシーを適用できるという運用面の美しさがあります。ただし、従来のJTC（伝統的な日本企業）の閉域網のようなネットワークにZTNAを組み込む場合、コネクタと社内網（SD-WAN等）の相互接続ポイントの経路設計がパズル化しやすいというデメリットがあります。

もう一つの系譜：「DNSセキュリティ起点型」

ここまで「ネットワーク制御型」と「ZTNA機能分離型」の2軸で解説しましたが、Cisco（Cisco Secure Connect / 旧Umbrella）などは、また少し異なる「DNSセキュリティ起点」というアプローチをとっています。

もともとCiscoのSASEのベースにあるUmbrellaは、世界最大級のDNSサーバー群であるOpenDNSの技術がルーツです。そのため、以下のような強烈な「ネットワークベンダーらしさ」を持っています。

暗号化される前に止める： Web通信がSSL/TLSで暗号化されて中身が見えなくなる「前」の段階、つまり一番最初の「DNSの名前解決（FQDN）」の時点で、不正なサイトへのアクセスを遮断します。
圧倒的に軽くてシンプル： 全通信をクラウドプロキシに迂回させて重いセキュリティチェックをかける前に、DNSのクエリとリプライをコントロールするだけで完結するため、ネットワークへの負荷が極めて低いです。

実際の製品の設定画面を見ても、URLフィルタリングのような重い処理の手前にまず「DNSの処理によるFQDNベースの通信遮断」が配置されていることが多く、その思想が色濃く残っています。

分類としては「ネットワーク制御型」に非常に近いですが、「まずはDNSというネットワークの基本プロトコルで軽量に守り、必要に応じてSWGやZTNAの重厚な機能を足していく」という、引き算・足し算の美学があるモデルです。

まとめ：垣根は少なくなっているが「思想」は残る

現在、どちらの型のベンダーも弱点を補い合うように進化しています。ネットワーク制御型がクラウドプロキシとしての動作を強化したり、分離型が拠点間通信をサポートするソリューションを発表したりと、機能面での垣根は低くなりつつあります。

しかし、製品の根本にある「思想（ネットワーク起点か、プロキシ起点か）」は、今でも設計の難易度や運用の現場に色濃く影響を与えます。

ネットワーク制御型が向いている企業：「拠点間通信も含めて、ネットワーク全体を一元管理・シンプルにしたい」
ZTNA機能分離型が向いている企業：「社内システムはすでにクラウドシフト（SaaS/IaaS）が進んでおり、リモートワークのセキュリティとWeb検閲をスマートに分離・最適化したい」

自社のネットワークの現状（レガシーな閉域網か、クラウドシフトしているか）と、今後の目指す姿に合わせて、正しい「型」を選択していきましょう。