Netskope One Private Access のアクセスモデルを整理してみた
Netskope の ZTNA ソリューションである Netskope One Private Access の3つのアクセスモデルの違いについて解説します。
はじめに：VPNからゼロトラストへの移行とNetskope One Private Access
テレワークやハイブリッドワークが当たり前になった今でも、多くの企業は依然として VPN をリモートアクセスの基盤として使い続けています。
一方で、VPN には次のような課題があります。
- 一度接続すると社内ネットワークに「入り放題」になりがち（過大な権限・広すぎる到達範囲）
- トラフィックを一度データセンターに集約するため、遅延・帯域逼迫が起こりやすい
- 利用ユーザー数の増加に応じてゲートウェイ増設・機器更改が必要になり、運用負荷も高止まり
こうした背景から、「ネットワークに入れる」前提の VPN から、「アプリにだけつなぐ」ことを前提にした ゼロトラストリモートアクセス（ZTNA） への移行が進んでいます。
Netskope One Private Access（以下 NPA） は、Netskope の SASE/SSE プラットフォーム上で提供されるゼロトラストリモートアクセス機能です。
本記事では、その中でも特に分かりにくくなりがちな 3つのアクセスモデル：
- Netskope Private Application Access
- Netskope Private Optimized Access
- Netskope Private Unified Access
の違いを整理しながら、「自社にはどれが合いそうか」をイメージできるようになることをゴールに解説していきます。
3つのアクセスモデルの全体像：まずはざっくり比較
最初に、3つのアクセスモデルの役割を一言でまとめると、以下のようなイメージになります。
- Netskope Private Application Access:
クライアント発の通信を前提とした レイヤー7（アプリケーション単位）の ZTNA
- Netskope Private Optimized Access:
Endpoint SD-WAN を活用し、クライアント発・サーバー発を含む双方向通信 を扱えるリモートアクセス
- Netskope Private Unified Access:
上記 Netskope Private Application Access + Netskope Private Optimized Access をまとめて利用可能にした統合アクセスモデル
3つのアクセスモデルに共通しているコンセプトは、
- ネットワーク単位ではなく ユーザー / デバイス / アプリケーション単位 でアクセスを制御する
- Netskope クライアント と Netskope NewEdge（グローバルな PoP）を活用し、ユーザーに近い場所でセキュリティ・アクセス制御を実行する
- 同じ管理コンソール・同じポリシーモデル上で、SaaS・Web・プライベートアプリを一体的に扱える
という点です。
以降のセクションでは、それぞれのアクセスモデルをもう少し具体的に見ていきます。
Netskope Private Application Access
コンセプトと得意領域
Netskope Private Application Access (以降、本記事では「Application」と記載) は、既存 VPN をまずは「アプリケーション単位の ZTNA」に置き換えるためのアクセスモデルです。
- ユーザー端末の Netskope クライアントから、Netskope の PoP へ接続
- PoP から Publisher (ZTNA コネクタ) 経由で社内アプリケーションにアクセス
- 1つ1つのアプリケーションを「Private App」として定義し、ポリシーでアクセスを制御
という形で、「どのユーザーが、どのアプリに、どの条件で」 アクセスできるかを細かく制御できます。
特に以下のような課題を持つ環境に向いています。
- リモートワーク時に、社内アプリだけ安全に公開したい
- 部署や役割ごとにアクセスできるサーバーやシステムを 最小権限化 したい
- VPN 越しに「社内ネットワーク丸ごと」にアクセスできてしまう状況から脱却したい
技術的な特徴 (L7 ZTNA)
Application アクセスモデルが扱うのは基本的に クライアント発の L7（アプリケーション層）通信 です。
- DNS・ホスト名・IP アドレスなどを使って、到達させたいアプリケーションを「Private App」として定義
- そのアプリに対して Publisher (ZTNA コネクタ) を割り当て、Netskope クライアントからの接続を中継
- ユーザー属性、グループ、デバイス状態、接続元ロケーションなどを条件にポリシーを記述
ネットワーク的には「社内へのトンネル」を貼るのではなく、アプリ単位でトンネルを張るイメージ です。
これにより、たとえば「ファイルサーバーと社内 Wiki にはアクセスさせるが、データベースには一切アクセスさせない」といった、きめ細かいマイクロセグメンテーションが容易となります。
代表的なユースケース
- ファイルサーバー（SMB）、社内ポータル、業務 Web アプリなどへの社員リモートアクセス
- クラウド上の管理コンソール（例：IaaS、監視ツール、運用 Web UI）への安全なアクセス
- 協力会社・ベンダー向けに、RDP/SSH/Web 管理画面だけを限定公開するシナリオ
- 送信元 IP 制限のある SaaS/管理サイトに対し、Netskope の固定 IP（GIP）と組み合わせてアクセスさせる構成
Netskope Private Optimized Access
コンセプトと得意領域
Netskope Private Optimized Access (以降、本記事では「Optimized」と記載) は、Netskope の Endpoint SD-WAN 機能を活用して、クライアントと社内ネットワーク間の 双方向通信 を含むトラフィックを扱えるようにしたアクセスモデルです。
Application アクセスモデルの L7 ZTNA だけでは対応が難しい、
- VoIP
- VDI / フルリモートデスクトップ
- リモートサポートツール
- 監視エージェントやサーバー側からの通知
といった、「サーバー側からクライアント方向にもトラフィックが流れる」アプリケーションを、ゼロトラストの枠組みでカバーすることを狙っています。
つまり、「VPN でないと動かせないアプリ」 をどこまで減らせるか、に真正面から取り組むためのアクセスモデルと言えます。
技術的な特徴 (L3 ベース + 双方向)
Optimized では、端末上の Netskope クライアントから Netskope の SASE Gateway へ L3 ベースで直接接続 し、その先にあるプライベートネットワークとルーティングするアーキテクチャを取ります。
- クライアント発・サーバー発の双方のトラフィックを扱える
- ルーティング制御や経路選択に SD-WAN の知見を取り込んでいる
- 同じクライアント・同じコンソール上で SWG / CASB / ZTNA と一体的に運用できる
結果として、
- 「Netskope クライアント + Optimized で、VPN 的なリモートアクセスもカバー」
という構成に寄せていけるのがポイントです。
代表的なユースケース
- コールセンターの VoIP クライアントやソフトフォンをリモートから利用する
- VDI やフルデスクトップ接続（RDP など）をフルリモート環境で使う
- リモートサポートツール・画面共有ツールなど、双方向にトラフィックが流れるアプリ
- 監視・資産管理エージェントなど、サーバーや管理側からクライアントに向けて通信が必要なシステム
Netskope Private Unified Access
コンセプトと全体像
Netskope Private Unified Access (以降、本記事では「Unified」と記載) は、ここまで紹介した Application（L7 ZTNA）と Optimized（Endpoint SD-WAN ベースの L3 アクセス）を包括した上位のアクセスモデル です。
- ユーザー・デバイス・アプリケーションのコンテキストに基づく L7 制御と、
- ネットワーク的な双方向トラフィックを扱う L3 制御
の両方を、1つのクライアント・1つのコンソール で運用できます。
イメージとしては、
「まず Application で ZTNA を始める →
必要なところから Optimized の機能も取り入れる →
最終的には Unified で “VPN 完全リプレース” を目指す」
といった、ロードマップのゴールに位置付けられるアクセスモデルです。
統合のメリット
Unified アクセスモデルを採用すると、次のようなメリットがあります。
接続方式を意識せずに設計・運用できる
- アプリごとに「L7 でいくか / L3 でいくか」を選べる
- どちらも同じクライアント・同じ UI で運用可能
ログ・可視化・トラブルシュートが一元化される
- SaaS / Web / Private App（L7/L3）のイベントを同じ UI で確認
- ユーザー単位の動きが追いやすい
グローバル展開時のスケーラビリティ確保
- NewEdge の PoP と組み合わせて、世界各地のユーザーを同じコントロールプレーンで管理
代表的なユースケース
- グローバルに拠点・ユーザーを抱え、プライベートアプリも多数存在する大規模環境
- 現状は VPN と ZTNA が混在しており、段階的に統合していきたい企業
- SASE / SD-WAN を中長期の基盤として採用し、その上でリモートアクセスも完結させたい企業
3つのアクセスモデルをどう選ぶか？シナリオ別の検討軸
シンプルなリモートアクセスを素早く始めたい場合
「まずは VPN の課題を少しずつ解消したい」 という場合は、
- 既存 VPN と併用しながら
- 重要なアプリケーションから順番に NPA へ切り替えていく
という形で、Application アクセスモデル を入口として導入するパターンが多いです。
このフェーズでは、
- 社内ポータル
- ファイルサーバー
- 管理用 Web コンソール
など、比較的わかりやすい「クライアント発の L7 アプリ」 から対象にするとスムーズです。
VoIP やレガシーアプリを含めて VPN を置き換えたい場合
「VPN を残しているのは、VoIP や VDI、レガシープロトコルがあるから」というケースでは、Optimized アクセスモデル が検討の中心になります。
- 双方向通信が必要なアプリケーションを棚卸し
- どのネットワークセグメントにあるか、どの経路で到達させたいか
- 既存の拠点側ネットワークとの整合性（ルーティング・FW ポリシーなど）
を整理したうえで、Endpoint SD-WAN を活用した経路設計を行います。
中長期で SASE 全体を見据えたロードマップを描きたい場合
ある程度の期間をかけて、
- SWG / CASB によるインターネット向けトラフィックの制御
- ZTNA によるプライベートアプリへのアクセス制御
- SD-WAN による拠点間・クラウド間のトラフィック最適化
を一体で実現したい場合、最終的なゴールとして Unified アクセスモデル を据えると設計がしやすくなります。
ロードマップ例：
フェーズ1：Application で ZTNA を開始し、VPN と並行運用
フェーズ2：Optimized を適用するアプリ・ユーザーを広げ、VPN 経由のトラフィックを段階的に削減
フェーズ3：Unified で運用を統合し、VPN を完全リプレース
検討時に押さえておきたいチェックリスト
アクセスモデル検討時には、少なくとも次の観点を整理しておくことをお勧めします。
- アプリ種別
- Web / 非Web / VoIP / VDI / 管理系ツール など
- 通信方向
- クライアント発通信だけで成立するか
- サーバー発通信（プッシュ通知、エージェント通信など）が必要か
- ユーザーと拠点の分布
- 国内のみか、グローバル展開か
- 在宅・モバイルユーザーの割合
- 将来の SASE / SD-WAN 戦略
- 拠点間ネットワークも含めて Netskope の SD-WAN を活用したいか
- 他のネットワーク製品との棲み分けをどうするか
まとめ：自社にとっての「次の一歩」を決める
最後に、3つのアクセスモデルを改めて整理します。
- Netskope Private Application Access:
クライアント発の L7 通信を対象にした アプリケーション単位の ZTNA の入口
- Netskope Private Optimized Access:
Endpoint SD-WAN を活用し、双方向通信を含むアプリもカバーして VPN フルリプレースを目指すためのアクセスモデル
- Netskope Private Unified Access:
Application + Optimized を包括し、SASE 戦略全体の中でリモートアクセスを統合する最終形のアクセスモデル
どのアクセスモデルが「正解」かは企業ごとに異なりますが、共通して言えるのは、
- まずは自社のアプリケーションを棚卸しし、
- 「クライアント発だけで良いもの」と「双方向通信が必要なもの」を整理したうえで、
- 小さく PoC を始め、段階的に適用範囲を広げていく
という流れが失敗しにくい、ということです。
本記事が、Netskope Private Access の導入検討や、VPN からの移行計画を描く際のヒントになれば幸いです。
この記事の投稿者TYuki
Netskope 製品のプリセールスを担当しています。
過去にはネットワーク製品(ロードバランサーやSD-WAN)の技術担当などをしていました。
この記事をシェア
