TechLeague

    Palo Alto

    GlobalProtect vs Prisma Access ZTNA: 2026年への移行に関する設計図

    TechLeague Editorial··14 分で読了

    従来のGlobalProtectの「オンプレミスゲートウェイ」モデルとPrisma Access ZTNAの間の議論は、もはや機能の同等性に関するものではなく、静的な境界のアーキテクチャ上の終焉と、ハードウェアに依存するPAN-OSでは2026年には対応できないアイデンティティ認識型プロキシベースのセキュリティ態勢への移行に関わるものである。

    アーキテクチャ上の行き詰まり：PAシリーズにおけるGlobalProtectの限界

    この10年間、「黄金の標準」はシンプルだった。地域オフィスにPA-440またはPA-1400を導入し、SSL/IPsecゲートウェイを設定し、 dataplane でGlobalProtectトンネルを直接終端する方法である。これは、ユーザー数が全従業員の10%だった時代には機能した。しかし、ハイブリッドな世界では、このモデルは根本的に破綻している。PA-400シリーズで500のGlobalProtectトンネルを終端すると、暗号化/復号化のために大量のDP（Data Plane）CPUを消費し、Layer 7コンテンツインスペクションやWildFire分析のためのオーバーヘッドがほとんど残らない。

    2026年の現実として、GlobalProtectはVPNであり、Prisma Accessはファブリックである。オンプレミスでGPを実行する場合、ヘッドエンドのISP帯域幅とバックホールの物理的なレイテンシに拘束される。ロンドンのユーザーがニューヨークのゲートウェイに接続してSaaSアプリケーションにアクセスする場合、120msの不要なレイテンシが発生する。Prisma Accessは、「オンランプ」を最寄りのAWS/GCPエッジ（世界中に100以上のPoP）に移動させ、一貫して10ms未満のファーストホップレイテンシを提供する。

    ZTNA 2.0：「接続してから検査」から「アイデンティティファースト」へ

    標準のGlobalProtectは「Connect then Inspect」モデルに従う。ユーザーが認証されてトンネルが確立されると、内部ネットワーク上でIPアドレスを持つ。厳格なセキュリティポリシーが適用されていても、ユーザーのデバイスは技術的にネットワーク上に「存在」する。Prisma Access ZTNA（バージョン2.0）は、ZTNA Connectorを利用し、このロジックを逆転させる。

    ZTNA ConnectorはVPCまたはデータセンター内に設置され、Prisma Accessクラウドへのアウトバウンドトンネルを確立する。ファイアウォールにはインバウンドポート（443/VPNリスナー）が開いていない。これにより、アプリケーションインフラストラクチャはパブリックインターネットから効果的に隠され、最近レガシーSSL-VPNベンダーを悩ませているVPNサービス自体に対するゼロデイエクスプロイトの可能性を排除する。

    
# 従来のGPゲートウェイ (検出に対して脆弱)
set network interface ethernet1/1 layer3 ip 203.0.113.10/24
set network profiles global-protect-gateway GP-GW-External
set deviceconfig setting global-protect-gateway enable yes

# ZTNAコネクタのロジック (アウトバウンドのみ)
# インバウンドNATは不要。コネクタはPrisma Cloudへダイヤルアウトする。
cloud-connector {
  target-fragment "Prisma-Backbone";
  redundancy-group 'Prod-West';
  egress-interface ethernet1/1;
}

    2026年の移行トリガー：GlobalProtectはいつ廃止されるか？

    以下の3つの技術的トリガーに該当する場合、Prisma Access ZTNAへの移行を検討すべきである。

    • 帯域幅のボトルネック：リモートユーザーの総トラフィックが、ヘッドエンドの復号化されたスループット容量の50%を超過する場合（show running resource-monitorで確認）。
    • SaaSの普及：トラフィックの70%がO365、Salesforce、またはGitHubに向かっている場合、PA-3410にトラフィックをバックホールしてインターネットに再度送信するのは、高価なリソースの無駄である。
    • 「アプリケーション固有」の要件：ビジネスが、サードパーティの契約者が特定のJiraインスタンスのみにアクセスし、フルIPスタックトンネルを必要としないことを要求する場合。

    インフラストラクチャの適切なサイジングについては、2025-2026年のPAN-OSハードウェアサイジングに関する詳細ガイドを参照のこと。

    ポリシーの均質性：Panorama vs. Prisma Access Console

    移行における最大の課題の1つは、ポリシーの粒度を失うことへの懸念である。2026年には、Palo Alto Networksはほぼ完全な均質性を達成した。NGFW上のGlobalProtect Gatewayを使用する場合でも、Prisma Access Cloud Managementを使用する場合でも、ポリシー構造は同じである：User-ID、App-ID、Device-ID。しかし、Prisma AccessはPrisma SaaS Securityと統合されたDynamic User Groups (DUG)を導入しており、APIを介して監視されるユーザーの行動が認証情報の盗難を示唆する場合、ZTNAトンネルからユーザーを自動的に排除できる。

    Prisma Access ZTNA Connector vs. Service Connections

    以前のイテレーションでは、内部アプリケーションにアクセスするために「Service Connections」（FWからPrismaへのIPsecトンネル）を使用していた。2026年には、ZTNA Connectorがプライベートアプリケーションアクセス用の推奨される方法となる。これは、アプリケーションプロキシとして機能する軽量なVM（ESXi、KVM、またはCloud Native）である。これにより、ネットワークレベルのアクセスコントロールではなく、アプリケーションレベルのアクセスコントロールが可能になる。ユーザーにサブネットへのアクセスを与えるのではなく、https://internal-app.corp.localへのアクセスを与えるのである。

    ユーザーエクスペリエンス：「常時接続」の神話と現実

    GlobalProtectユーザーは、「トンネルフリップ」、つまりWi-FiからLTEに切り替える際の3〜5秒の切断についてしばしば不満を述べる。Prisma Accessは、モバイルセグメント終端を使用することでこれを解決する。ユーザーは大規模なクラウドバックボーンに接続しているため、セッションの状態は単一の物理DPハードウェアインスタンスではなく、クラウドプロバイダのSDN（Software Defined Network）で維持される。これにより、ZoomやTeamsの通話中にユーザーが気づかないシームレスな移行が実現する。

    コスト方程式：ハードウェア刷新 vs. OpExクラウド

    数字を見てみよう。2,000人のGlobalProtectユーザーに対応し、完全なSSLインスペクションが可能なPA-3410は、MSRPで約35,000ドル、年間7,000ドルのサポートとサブスクリプションが必要である。5年間でのTCOは約70,000ドルとなる。同じ2,000ユーザーの場合、Prisma Access ZTNA（OkyoまたはBusinessエディション）は年間OpExベースでは高くなる可能性があるが、冗長なマルチホームISPリンク、ラックスペース、および毎月PAN-OSの脆弱性をパッチするのに必要な人的資本が不要となる。

    多くの場合、5つ以上の地域ハブを持つ組織では、セキュリティスタックをPrisma Accessに統合することで、各ブランチでのバックホールMPLSや高帯域幅DIA (Dedicated Internet Access) 回線の「隠れた」コストを考慮すると、TCOが20%削減されることがわかっている。

    移行の実装：段階的アプローチ

    スイッチを切り替えるだけで10,000人のユーザーをZTNAに移行できるわけではない。2026年の移行パスは以下の設計図に従う。

    1. フェーズ1：ハイブリッドクラウド。PAシリーズGPゲートウェイは、シッククライアントIP接続を必要とする「レガシー」アプリケーション（例：レガシーOracle DB）のために維持する。
    2. フェーズ2：「インターネットオフロード」にPrisma Accessを使用。すべてのSaaS/Webトラフィックについて、GlobalProtectクライアントがPrismaに接続し、高速バックボーンを利用する。
    3. フェーズ3：ZTNAコネクタの展開。主要なDCにZTNAコネクタを展開し、Webベースの内部アプリケーションを一つずつ移行する。
    4. フェーズ4：ハードウェアの廃止。ローカルゲートウェイにヒットするトラフィックが10%程度になったら、ハードウェアを小規模なもの（PA-400シリーズなど）にダウンサイジングし、ローカルのサイト間接続のみに利用する。

    レガシールーティングを伴う複雑な移行シナリオについては、Prisma AccessとのAdvanced BGP Peeringに関するガイドを参照のこと。

    まとめ：評決

    VPNトンネルを終端するためだけに大規模で高スループットのファイアウォールを購入し続けている場合、技術的な負債の爆弾を築いていることになる。2026年までには、物理ハードウェアでのグローバルなIPsec/SSL VPN終端の管理の複雑さが、クラウドネイティブZTNAのコストを上回るだろう。Prisma Accessはセキュリティだけでなく、ネットワークパフォーマンス、そしてユーザーが実際に活動する場所であるブラウザとアイデンティティプロバイダにセキュリティ境界を移動させることである。

    エッジをモダナイズし、VPNの煩わしさから解放される準備はできているか？弊社のCCIEおよびPCNSEチームは、レガシーGlobalProtectから完全なZTNA 2.0フレームワークへの移行を設計できる。弊社の階層型コンサルティングおよびデプロイメントパッケージについては、techleague.ioをご覧いただきたい。

    よくある質問

    Prisma Accessとオンプレミスゲートウェイの両方で同じGlobalProtectエージェントを使用できますか？+

    はい、GlobalProtect App（v6.x以降）は両方で同じクライアントです。移行を容易にするために、ポータルアドレスを変更するか、アプリ設定で「複数ポータル」構成を使用するだけです。

    Prisma Access ZTNAはリモートユーザーのレイテンシを本当に改善しますか？+

    Prisma Accessは、AWSとGCPの高速バックボーンを使用します。ユーザーに最も近い「エッジ」PoPでユーザーセッションを終端することで、中央データセンターのファイアウォールへのトラフィックのバックホールによるレイテンシを排除します。

    ZTNAに移行する場合、内部サーバーのアドレスを再設定する必要がありますか？+

    通常は不要です。Prisma Accessは通常、「Service Connections」または「ZTNA Connectors」を使用して、安全なトンネル経由で内部リソースにアクセスします。コネクタVMから内部サブネットにルーティングできる限り、内部IPスキーマを再設計する必要はありません。

    Prisma Accessの「ZTNA 2.0」は、標準のZTNAと何が違うのですか？+

    ZTNA 2.0は継続的な信頼性検証を提供します。デバイスが非準拠になった場合（例：AVがオフになった場合）や、セッション中にユーザーの行動が変化した場合、Prisma Accessはトンネルがアクティブなままでも、特定のアプリケーションフローを即座に終了させることができます。

    NGFWでGlobalProtectを維持すべきシナリオはありますか？+

    ZTNAは90%のユースケースで優れています。しかし、固定の送信元IPアドレスを必要とするレガシーアプリケーションや、特定の古い産業用プロトコルのように容易にプロキシできない非標準プロトコルの場合は、従来のGlobalProtectトンネルが依然として必要となる可能性があります。