Zscaler Private Access (ZPA) is one of Zscaler’s many products in the Zscaler Zero Trust Exchange. It functions as a NextGen VPN, enabling organizations to give users access to their internal applications and services while maintaining network security. ZPA does so by offering an interconnected private internet connection for tunnels through which it enforces security policies and limiting access to authorized users.
ZScaler Private Access
🍎 NextGen VPN
🍊 Reverse Proxy
Slow. Added latency from extra hops due to ZPA Public Service Edge.
Fastest. Deployed at edge, no additional latency or bandwidth costs
Client-based access is bad for end-user experience.
Provides clientless access for seamless user experience.
The only use for Zscaler Private Access (ZPA) is for companies that do not want to self-host a reverse proxy like Pomerium and for some reason do not want to use Cloudflare. ZPA is a reworked NextGen VPN masquerading as a reverse proxy with Zscaler offering middleman managing services. There is nothing ZPA provides that Pomerium does not do better — and if you absolutely do not want to self-host but have a big budget, we find Cloudflare to be a better solution than ZPA.
Provides a hosted proxy solution for inbound and outbound traffic.
Setting up a software-defined virtual private network for organization.
Limits lateral movement — ZPA reduces attack surfaces by limiting user access to applications and not exposing the network
Access Control — ZPA provides PAM-style access control for cloud applications
Requires Zscaler’s Servers — Once you have a User Client and an App Connector, the connection is brokered by the ZPA Public Service Edge (which would be the Gateway in a VPN architecture). This means that your uptime is determined by Zscaler’s server availability. Zscaler offers Private Service Edge as a self-hosting option, but charges you to manage them.
Repurposed VPN architecture— ZPA is a NextGen VPN built atop their old VPN foundations. If you’re trying to get rid of tunneling problems, ZPA removes none of that.
Slower Speeds — There’s added latency as the data needs to be backhauled through Zscaler’s servers, adding an extra hop or four.
Who watches the watchers? — Zscaler can MITM and intercept all traffic for decryption. This exposes your network and data to Zscaler’s actions.
Evaluators Should Know
Zscaler is distancing themselves from VPNs, but their solution just replaces VPN tunnels with Zscaler tunnels. The fundamental problem — tunneling — has not been solved by Zscaler at all.
Clientless access is a good step towards usability, and Zscaler states that users shouldn’t need to login to a remote access VPN client. We completely agree. So it confuses us when Zscaler replaces the VPN login client with…
We could spend some time talking about how deploying, managing, and updating these clients are a management burden to IT admins. Clients are inherent to tunneling, and we don’t blame Zscaler for having one. It’s a shame that their product cannot put the theory into practice.
Making this usability criteria worse is that Zscaler’s architecture negatively impacts speed.
Zscaler is slower than Pomerium because of their VPN tunneling architecture: Network performance is impacted when data must tunnel extra hops from the origin to the VPN server, then from the VPN server to the user, a process known as data backhauling.
In short, network performance is directly impacted by increasing the amount of hops. ZPA and Zscaler Internet Access (ZIA) hasn’t changed anything:
A Zscaler Tunnel (Z-Tunnel) is a TLS-encrypted, mutually authenticated point-to-point connection between Zscaler Client Connector and a ZPA Public Service Edge managed by Zscaler, or it’s between an App Connector and a ZPA Private Service Edge managed by an organization.
Taking a look at Zscaler’s latency-inducing architecture:
First hop: from Zscaler Client/App Connecter to the ZPA Public/Private Service Edge
Second hop: from Zscaler Public Service Edges (the gateway) back to the user.
At the very minimum, that data is still taking an inefficient route. This matters because these extra hops and intermediary servers do impact latency and affect user experience. The solution is to give users direct connection to the application through a reverse proxy like Pomerium.
Zscaler’s adherence to obsolete VPN architecture does not follow with their explanation for why VPNs are being phased out. This architecture is also a critical point as to why they either cannot implement continuous verification or must Man-in-the-Middle you.
Traditionally, the Perimeter Problem exists because organizations used to set out a network perimeter for their internal apps and services. This was fine until remote access became necessary. Tunnels — like VPNs and Zscaler — are for getting past the network firewalls to grant remote access. Over time, those tunnels then became access points and exposure points themselves.
Again, Zscaler has correctly identified a symptom (poor security) then erroneously forgot to fix the problem (tunneling). Tunneling has other problems, namely being unable to enforce…
Continuous verification and data tenancy
Continuous verification is important to identify and block malicious actions before they happen. It is the idea that malicious or negligent user actions can happen even after user identity is verified when a session starts. This is a critical part of a zero trust solution: checking if every single action and request should be allowed before its execution.
Tunneling and connection-based solutions have the Perimeter Problem because they only care about checking user identity when the session starts. The solution is fundamentally blind to the data transfer and user actions once a connection is established, making it only capable of logging actions instead of preventing them from executing.
Zscaler attempts to address this with their SSL inspection:
The Zscaler service can inspect HTTPS traffic from your organization. The service can scan data transactions and apply policies to it. It functions as a full SSL proxy, or SSL man-in-the-middle (MITM) proxy.
And fully admits that they’re man-in-the-middling your data to inspect it. This is a drastic exposure of private and sensitive data to Zscaler, a third-party service. Using this service would disqualify companies working with sensitive data from making compliance audits.
To sum it up, your options with Zscaler are:
Accept no continuous verification so requests and actions are not inspected for malicious activity, or –
Use Zscaler SSL inspection where Zscaler decrypts all your data and acts as the MITM attack vector
Context-aware access is integrating institutional context into policy for making access control decisions. It is no longer reasonable to make access decisions based on user identity alone. Instead, access control solutions should have access to data that would better inform the context surrounding otherwise legitimate user activity. The authorization policy should integrate that data into access decisions when deciding if an impending user request should be allowed or denied, completing the full circle of all four pillars to your access solution.
Zscaler may implement rudimentary forms of context-aware access on session start, but it is limited to the basic forms of anomalous behavior detection that many other solutions use. Compare this to Pomerium’s full integration model where all information available to the organization can be used to make context-aware access decisions for every single action.
Pomerium’s place as an open-source context-aware reverse proxy helps prevent ransomware attacks on internal services and resources. Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN. The result is:
Easier with clientless access.
Faster by being tunnel-free and deployed where your apps and services are.
Safer because every single action is verified before allowed to execute.
Tailored to your organization’s needs by integrating all data for context-aware access.