2026.06.14 2026.06.16

【SASE実践】[設計] [通信経路]拠点間通信 vs ZTNA：すべてをZTNAに任せるべきか

buffoon

はじめに

「SSEやZTNAを導入すればもう高いWAN回線やSD-WANは不要で、全拠点をインターネット＋ZTNAの構成にできるのでは？」というベンダーの提案に悩んでいませんか？

結論から言うと、「前提条件付きで、拠点と拠点をつなぐネットワーク機能（SD-WAN等）は残すべき」です。

すべてをZTNAに任せる「フルZTNA」ではなく、社内と社外で使い分ける「ハイブリッド設計」こそが、日本企業（JTC）の現実的な最適解である理由を解説します。

なぜ「すべてZTNA」ではダメなのか？

①プロトコル挙動や遅延で破綻する「オンプレ資産」の存在

ZTNAは基本的に「クライアント（端末）からWebアプリ（HTTPS等）」への通信を想定して作られています。
※一昔はUDP通信に対応していないソリューションも存在しました。

拠点にあるActive Directory（AD）の認証同期、大容量のファイルサーバー（SMBプロトコル）、オンプレのレガシー業務システムは、ZTNA（コネクタ）を挟むことでプロトコルの挙動が不安定になったり、遅延によって通信が破綻するリスクがあります。これらは従来の拠点間通信（L3/L2レベルのルーティング）に任せる方が圧倒的に安定します。

②ZTNAエージェントが入れられない「サーバー間通信」の壁

ZTNA（ゼロトラスト・ネットワーク・アクセス）の基本思想は、あくまで「PCなどの端末（ユーザー）」から「アプリ」への通信を制御することです。

しかし実際のエンタープライズでは環境が違う（同じLAN内にいない）「サーバーからサーバーへの通信（Server-to-Server）」が頻繁に発生します。ここに大きな壁があります。

エージェントが入れられない： そもそも社内の古いOSのサーバーや、アプライアンス機器にはZTNAのエージェントをインストールできません。
サーバー起点の通信が苦手： ZTNAは「クライアント側からセッションを張る（アウトバウンド）」ことで安全性を担保する仕組みが多いため、サーバー側が起点となって別のサーバーへデータをプッシュするような通信経路の制御は、仕様上サポートしていないか、設定が極めて複雑になります。

補足：サーバー間通信をカバーする「SSEソリューション」の理想と現実

一応、こうしたサーバー起点（Server-to-Server）の通信をフォローするためのSSE/ZTNAソリューションや専用の構成も存在はします。これらを導入すれば非機能要件の観点、例えば「マイクロセグメンテーション（サーバー間の通信を極限まで細かく制御して、万が一のウイルス感染時の横展開を防ぐ）」といった高度なセキュリティ制御が可能になります。

しかし、現場の感覚から言うと、そこまで普及していないのが現実の印象です。

「単に通信を通す（ルーティングする）」という機能要件の面においては、既存のネットワーク（SD-WAN等）で制御する方が圧倒的にシンプルで、コストパフォーマンスも高いからです。運用を複雑にしてまでサーバー間通信をすべてSSEに委ねるメリット（費用対効果）が見出せないケースがほとんどです。

結果として、これらのサーバー間通信を成立させるためにも、拠点間を結ぶネットワークインフラは残さざるを得ないというのが、リアルな結論になります。