ZTNA/SASEを名乗る製品を「攻撃断面」で見分ける — ゲートウェイが自社に残るなら、VPNとの距離は思ったより近い

2026年11月5日 12:36

ZTNAやSASEという名前が付いていても、構造は大きく2種類に分かれます。見分ける軸はひとつです。「インターネット側から到達できる入口が、自社の側に残るか」。なお以下は製品名の優劣ではなく、構造の話として記載します。

【2つの方式】

■ インバウンド（ゲートウェイ公開）型

自社のデータセンターや拠点にあるゲートウェイ機器が、外部からの接続を待ち受けます。ポリシーはアプリ単位に細かくできても、待ち受け口はインターネットに出たままです。

■ インサイドアウト型

社内側のコネクタが、クラウド上のブローカーへ「外向きに」接続します。自社側には待ち受けポートがなく、利用者もクラウドに接続し、ブローカーが両者をつなぎます。

【なぜ攻撃断面が違うのか】

・インバウンド型は、公開IPとポートが存在するため、スキャンで見つかります。認証前に処理される機能（ポータル、SAML、管理画面）に脆弱性が出ると、「パッチを当てるのが先か、悪用されるのが先か」の競争になります

・実例として、2026年初頭には、FortiGateの認証回避系の脆弱性が実際に悪用され、公開されたゲートウェイが足がかりになったと報告されています。これは特定の製品の問題ではなく、公開されたゲートウェイ機器という構造の問題です

・政府共通基盤GSSの事案も同じ構造でした。警察庁によれば、国内のランサムウェアの侵入経路は、VPN機器が約5割を占めます

・インサイドアウト型は、待ち受けがないため、外部のスキャンで入口が見つかりません。認証前の攻撃面が自社側に存在しない点が、本質的な違いです

【VPNと何が変わるか（観点別）】

・入口の有無：VPNは公開 / インバウンド型ZTNAも公開 / インサイドアウト型は自社側に公開なし

・認証前の攻撃面：VPNとインバウンド型は自社側に残る / インサイドアウト型は自社側になし

・脆弱性対応の主体：VPNとインバウンド型は自社が緊急で適用 / インサイドアウト型はクラウド側の更新が中心（コネクタは自社で更新）

・アクセス制御の粒度：ZTNAはどちらもアプリ単位にできる

つまり、粒度が細かくなっても、入口が残るなら、攻撃者から見える面は変わりません。

【公平のために：インサイドアウト型にも限界がある】

・クラウド側基盤の障害や侵害の影響を受ける（集中リスク）

・コネクタの管理が必要。侵害されたときの到達範囲が広すぎると、被害が大きくなる

・サーバー起点の通信や、レガシーなプロトコルの扱いに設計上の工夫が要る

・インバウンド型の製品でも、クラウド提供型の構成を選べる場合がある。製品名ではなく、構成で判断する必要がある

【選定時に確認したい6つの質問】

1. 自社内に、インターネットから到達できる待ち受けIP・ポートが残るか

2. 認証前に処理される機能（ポータル、SAML、管理画面）が、公開面に出ていないか

3. 脆弱性が出たとき、パッチ適用の主体と、許容できる猶予はどうか

4. 管理画面が、インターネット側に出ない構成にできるか

5. コネクタが侵害された場合の到達範囲を、最小権限とセグメントで絞れるか

6. 実際に外部からスキャンして、何が見えるかを検証したか

【現実的な打ち手】

■ すでにインバウンド型を導入している場合

全面置換は現実的ではないので、まず公開面を最小化します。管理画面の非公開、不要機能の無効化、パッチ適用のSLA、MFA、監視を整えます。並行して、重要システムから順にインサイドアウト型へ段階的に移します。

【終わりに】

ZTNAやSASEという名称は、構造を保証しません。見るべきは機能一覧ではなく、「攻撃者から見える入口が残るか」。この一点で、VPNとの本当の距離が測れると考えています。

ピックアップされています