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 | Pomerium | |
|---|---|---|
| Similar Solution? | 🍎 NextGen VPN | 🍊 Reverse Proxy |
| Speed | Slow. Added latency from extra hops due to ZPA Public Service Edge. | Fastest. Deployed at edge, no additional latency or bandwidth costs |
| Ease-of-use | Client-based access is bad for end-user experience. | Provides clientless access for seamless user experience. |
| Security | Poor. Has the Perimeter Problem or MITMs your traffic, becoming a single point of failure themselves. | Continuously verifies each requested action before execution. Self-hosted so no risk to your data. |
| Context-Awareness | Identity-aware and some dynamic access only. | Integrates institutional context into policy decisions for context-aware access. |
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.
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.
We agree with Zscaler that VPN tunnels are a problem. Their recent video (now privatized) does a great job of explaining why VPNs are a security and productivity concern.
The problem is replacing VPN tunnels with Zscaler’s tunnels doesn’t fix the problem.
We base our evaluation on a strict four-pillar criteria when evaluating access control solutions:
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.
Source: Zscaler defining their own tunnels
Taking a look at Zscaler’s latency-inducing architecture:
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 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.
Source: Zscaler’s About SSL Inspection
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:
Neither are good options with Zscaler.
And our final pillar: taking institutional context into account when providing access.
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:
Check out our open-source Github Repository or give Pomerium a try today!
Embrace Seamless Resource Access, Robust Zero Trust Integration, and Streamlined Compliance with Our App.
Download Now