I have another question in my journey to getting my head around Zscaller. This post is cynical… prove me wrong.
ZIA = Internet proxy being run in a Zscaller data center instead of yours. This will only protect web based traffic and anything not proxied remains unprotected?
ZPA = VPN, even through the marketing suggests it is to replace VPN solutions it is in fact a full tunnel VPN solution that tunnels all traffic back to a firewall in a ZScaller data centers to process the traffic?
With these solutions, apart from its a product operated by an industry leading name. What stops me replacing ZIA with a well configured proxy architecture of my own? Why should I replace my current VPN solution with ZPA?
These conversations can go back and forth for days and there are those that don’t see the benefits or it might just not adapt to their environment.
Here are my thoughts:
ZIA - Yes, you’re moving the processing to the cloud which in it of itself is a win because you don’t have to worry about scaling hardware for process intensive functions like SSL.
Also, the ability to provide consistent policies to all users regardless of location is a benefit, unless you have a DC footprint that won’t require extensive back hauling of traffic.
Again, these will be benefits for 90% of companies, but won’t work for everyone.
Finally, ZIA does support all ports and protocols not just “web traffic“. Wanted to make sure you weren’t referring to only 80/443.
ZPA - From the many deployments I’ve done, the major benefits I see are these:
Security by obscurity - there’s no VPN concentrator listening for connections on the internet that can be brute forced. Everything is hidden by synthetic IPs, even if you are using ZPA, you can’t find an internal host’s IP.
Granularity of applications and policies - this is dependent on the actual implementation, but if done properly, you can achieve a level of segmentation and elevated security, with less effort than a traditional VPN requires.
Scalability - depending on your footprint, you can easily deploy 50 app connectors to give the user ability to always be closest to the application, and ZPA will take care of picking the best path.
I’m sure there’s more points to add, but these are probably the most important.
Also, I’m not saying Zscaler is the silver bullet in every situation. It has flaws and doesn’t lend itself to every environment.
Because you would need hundreds of POPs with an incredible amount of computing. Also configuring DLP, sandboxing, malware protection, WAF for private apps and more is unfeasible by yourself.
One thing I don’t see mentioned here, is the ease of SSL Inspection.
Traditional proxies don’t normally supply client side software (ZCC) to do Comply-2-Connect or manage certificates. With Zscaler you can just deploy the default configuration per their documentation and have SSL Inspection without any additional configurations etc. SSL inspection is also very intensive, so using the cloud rather then an on-prem device improves user experience.
These are the same thoughts I have. I spent a lot of time on these considerations, and while I am not 100% convinced of the whole ZS marketing, I see following benefits:
offloading security fuctions (IPS, Web-filtering, etc.) to the provider = potential savings on on-prem FW licenses, no issues with scaling up-down, no issues caused by buggy NGFW features resulting in memory leaks (Fortinet’s common problem)
single point where you configure the policies is probably much better than maintaining multiple FW policies
no Internet exposure (only outbound connections from on-prem) = lower pressure on patching and hardening
provider takes care about high-availability - imagine your central location fails for any reason…
ZIA users connect to nearest Zscaler POP, so it should provide better performance vs tunneling all your remote workers through your central on-prem appliance
The #1 reason to use Zscaler ZIA over on-premises proxy is the ability to provide localized proxy security services outside the firewall without the need of a VPN. This is more beneficial for larger road warrior work forces that work over larger regions then maybe a small localized work force. The reason to use ZPA is if you already use ZIA and you want to bundle VPN access with your Zscaler client for ease and single pane of glass management.
As for using it on premises, well that depends on your needs for a firewall/proxy balanced with the costs of such a firewall/proxy versus the added licensing costs of Zscaler. It’s not so cut and dry an argument for using Zscaler as your primary on-premises firewall/proxy.
ZIA cant protect your data from local applications IM. thats a limitation on their DLP, your data can still leak via Viber, Telegram,Messenger, and other locally installed instant messaging App.
You have a lot more options with ZIA beyond a simple proxy. You’re able to leverage threat intel, provide external DNS security, conduct SSL inspection, DLP, etc. Yes, you could build all of that in your own stack but that would be a lot of tech to build and maintain.
In terms of ZPA - your remote clients don’t connect back to your infrastructure via a simple VPN or tunnel. Ideally, you’ve correctly configured relevant app connectors and your remote clients are never actually joining your network, you’re simply connecting to allowed workloads/apps. This greatly reduces the risk of remote, potentially non-managed, endpoints joining your actual enterprise corp network. Great use-cases for remote workers, contractors, M&A, etc.
Happy to geek out on this anytime - just reach out.
So we’re in the US with people all over the country and HQ in the mid-Atlantic region.
That meant our old setup had Hawaii and Alaska users’ traffic going across the country twice. Bonkers latency.
We could build a new datacenter on the west coast, or we could do what we did and subscribe to ZScaler to use the 11 data centers they’ve already got. Suddenly our big California office stopped being a major problem complaining about slow Internet. ZPA takes away the work of racking routers, bringing up VPN tunnels, and then building more tunnels for RBAC. ZTNA lets you have different people getting access to different things, all over one tunnel- it’s way easier to troubleshoot than the AnyConnect tunnel profiles we were using before.
Thanks for taking the time to respond. I think you have some very valid points. With a lot of technologies, it about ensuring you understand the pros and cons of the technology to make an informed decision about its application. Your post has helped me do this; thanks.
Thanks for taking the time to respond. You offer an interesting point. I think it depends on the existing setup, team size etc. If all your users are in one geographic region, then 2 or 3 POPs should suffice. Most traffic will need to go Tier 1 ISP connections that tend to be less geographically diverse in my experience.
Not being able to resolve the hostname is pretty cool.
VPNs don’t “put users” anywhere. It’s a gateway that users can log into to establish a tunnel (usually IPSEC or TLS) to the VPN gateway. Most corporate VPN gateways then have policies about what those users can acces just like ZPA does.
I don’t understand the outbound thing to be honest. If users are interacting with applications, then the app connector is receiving some kind of communications from ZS cloud. What’s special about what ZS is doing here?