こんにちは。ネットワールドSEの藤田です。
弊社は昨年よりZscaler社とディストリビュータ契約を締結しております。
www.networld.co.jp
担当SEとして、よし！Zscalerに関する技術情報を発信していこう！と意気込んだものの、最初の一発目は何にしようかと迷いました。うーむ、なにしろ機能豊富です。ここはやはり皆さん昨今お悩みのリモートアクセスVPN問題から入りましょう！、ということに決めました。
これから何回かに分けてVPNの代替となるZscaler社のZTNAソリューション「Zscaler Private Access」（ZPA）をご紹介したいと思います。このシリーズでは具体的な設定方法ではなく、ZPAを理解することに焦点を当てたいと思います。
皆様の検討の一助となれば幸いです！
【Zscaler】ZPAでVPNを置き換える！#1 ZPAが求められる理由 - ネットワールド らぼ
【Zscaler】ZPAでVPNを置き換える！#2 ユーザの操作感 - ネットワールド らぼ
【Zscaler】ZPAでVPNを置き換える！#3 アプリケーション通信の流れ - ネットワールド らぼ
【Zscaler】ZPAでVPNを置き換える！#4 アプリケーションの定義 - ネットワールド らぼ
免責事項
- 本書は、株式会社ネットワールド（以下 弊社）が作成・管理します。
- 本書の記載内容の一部または全部を弊社に無断で改変・転載することを禁じます。
- 本書の記載内容は、一部または全部が将来予告無く変更されることがあります。
- 本書の利用は、利用者様の責任において行われるものとします。
- 本書の記載内容には、最善の注意を払っておりますが、正確性・完全性を保証するものではありません。従いまして、本書の利用によって生じたあらゆる損害に関して、弊社は一切の責任を負いかねます。
リモートアクセスVPNの現状
まず、独立行政法人情報処理推進機構（IPA）が公開した「情報セキュリティ白書2025」からランサムウェアの感染経路の推移を抜粋します。
感染経路として、VPN機器からの侵入が高い割合を占めたまま推移しております。
2025年は悲惨なランサムウェアの被害が多発した年でした。ランサムウェアの甚大な被害は皆さんニュースでご存じのところかと思います。そのランサムウェアの感染経路の半分以上をVPN機器が占めている現状があります。
なぜこのような事態になっているのでしょうか？
リモートアクセスVPNの性質上、社外にいる社員を社内ネットワークへアクセスさせるため、それを受ける入口が必要になります。また、社外にいる社員の場所をすべて特定するのは困難ですから、不特定の場所からのアクセスを想定しなければなりません。そのような条件の下では、VPNの入口はインターネットへ公開せざるを得ません。
このリモートアクセスVPNの入口が、同様に攻撃者の入口にもなっているという現状があります。この入口がアタックサーフェイスとなってしまいます。アタックサーフェイスとは、攻撃者が不正アクセスや侵害を試みることができるすべてのポイントを指します。
セキュリティも認証もがっちりやってます！という万全な運用を行っても、ゼロデイ攻撃の懸念は拭えません。どれだけVPN機器の運用をしっかり行っても、外部公開と未知の脆弱性という組み合わせにはどうしてもゼロデイ攻撃の懸念がついてまわります。
ちょっと残酷な状況ですよね。ではどうしたらいいの？というお悩みに、Zscaler社のZPAをご紹介したいと思います。
ZPAによるアタックサーフェイスを排除
ZPAはZscaler社によるZTNA（Zero Trust Network Access）を実装したソリューションです。ゼロトラストの原則である「最小権限の原則」を体現したソリューションとなっております。
まず先のアタックサーフェイスにはどのように対応するのでしょうか？
答えは簡単です。アタックサーフェイスを排除 して対応します。
ZPAで構成するリモートアクセスは、VPNのようにグローバルIPアドレスを外部公開して接続を受け付ける方法は取りません。社内へApp Connectorという仮想アプライアンスを配置し、それがインターネット上のZscalerの基盤へ接続します。このトンネル接続は、社内からインターネット方向へのアウトバウンド通信のみが必要です。そのため、これまでのようにグローバルIPアドレスを公開する必要がなくなるのです。
一方、リモートアクセスのクライアント側は、Zscaler Client Connector（ZCC）というソフトウェアを使用します。こちらも端末からZscaler基盤へのアウトバウンド方向の通信のみで、トンネルを確立します。
つまり、Zscalerが通信の中継役になるということです。攻撃者からすると、顧客固有の情報は見えず、ただただZscaler社の基盤がそこにあるだけということになります。
また、社内ネットワークで要となるApp Connectorも、必要なのはアウトバウンド通信のみです。脆弱性は都度修正するのが基本ですが、そのリスクはサービスが公開されているほどに高まります。この点、App Connector自身に脆弱性が発生した場合でも影響が最小限になるように設計されています。
このようにZPAはアタックサーフェイスを排除できます。だから、安全なのです。
ZPAによるアプリケーションベースのアクセス
さらに、ZPAはアプリケーションへの接続の考え方も変わります。
VPNはそのVirtual Private Networkという名前の通り、仮想的にプライベートネットワークを延長する技術です。社外でも社内と同様にプライベートネットワークへアクセスできるよう構成されます。リモートユーザにはVPN用のサブネットが割り当てられ、そのプールからIPアドレスを払い出し、社内ネットワークへアクセスするのが一般的ではないでしょうか。
しかし、ゼロトラストの観点からはネットワークは信頼の条件になりません。VPNに対するアクセス制御は、やはりネットワークベースになるのが一般的でしょう。ネットワークベースのアクセス制御は、送信元IP/宛先IP/ポート番号など、ネットワークパケットの情報を基に動作します。この情報でユーザ単位のアクセス制御を厳密に実装するのは難しいですよね。厳格に実装できなければ、結果的にラテラルムーブメントの余地を残してしまいます。
そもそもZPAは考え方が異なります。
ZPAの設定は アプリケーションを中心 に設計されています。まず、ZPAは公開するアプリケーションを定義するところから始まります。これは、FQDN（IPアドレス）とTCP/UDPのポート番号から構成されます。この定義したアプリケーションに対し、誰がどのような条件でアクセスできるのかを個別に定義していきます。つまり、より実際の利用に即した形で詳細なアクセス制御を実装できるのです。
そもそものアクセスポリシーがアプリケーションを中心とした考え方で設計されています。ネットワークへ接続させるわけではないため、本来アクセスさせたかったアプリケーションのみをユーザへ公開することになり、ラテラルムーブメントの範囲を極小化することができます。
仮にユーザ端末が侵害され、ZPA経由での通信を奪われたとします。ZPAによるアクセスポリシーであれば、どこへアクセスできたのか明白です。ラテラルムーブメントに必要なネットワークアクセスが初めから断たれているためです。そのため、セキュリティインシデント時に影響範囲を素早く特定することができ、調査が必要なポイントを素早く絞り込むことができます。
まとめ
まず概要としてVPNと比較する形で、ZPAがなぜ求められるのかをご紹介しました。これからZPAを技術的な観点からご紹介させて頂くわけですが、キーワードは「最小権限の原則」です。ZPAの各種設定が、なるべくユーザへ最低限の情報しか見せないよう設計されています。ZPAを適切に設計することで、今回ご紹介したようなメリットを享受することができ、セキュリティのリスクを大幅に低減することができます。それでは次回以降、より技術的な内容のご説明をさせて頂ければと思います。ありがとうございました。
