Transcript
In this series of short videos, we're taking a look at the baseline recommendations for the configuration of ZScaler Private Access. This is part one, the value of ZPA. Before we start talking about how ZPA works, it's useful to understand how application access has traditionally worked in the past. For 30 years, enterprises have relied on network-centric methods to connect users to the network and, by extension, to the applications running on it. This approach has a number of common issues. First, it places the users on the network, which increases risk. If a user or device is compromised, since they're on network, that access can be used to move laterally across the network. Secondly, it provides a poor end-user experience, since traffic has to be routed through the internal network and security stacks hosted in your corporate HQ. This causes issues such as users becoming frustrated with their VPN performance. This approach also requires appliances, ACLs, and firewall policies. This means setting up, configuring, and managing your network is a complicated, complex, and difficult task that requires much time and much money. This approach also means that there's no ability to provide application segmentation, there's a lack of visibility into app-related activity, and since your applications are exposed to the internet to allow for inbound connections, there's the opportunity for attackers to leverage this to perform DDoS attacks against your network infrastructure. Additionally, the way users work has changed, and with applications moving to the cloud, the perimeter is extended to the internet. This has rendered network-centric solutions like remote access VPNs mostly obsolete. With that in mind, here's how ZPA works. First, let's define the components that are involved in making ZPA work. Primarily, these are the ZPA service edge, which brokers connections between the application and the user and enforces access policies, ZSkiller client connector, which sits on the user's endpoint and is responsible for forwarding traffic to the zero-trust exchange, and the app connectors, which sit near applications and connect authorized users to applications they are authorized to access only. As an example, here's the typical flow for a user accessing an application that they're authorized to access. First, the user authenticates with their IDP. Secondly, the user attempts to access their application. The ZPA service edge then enforces policy. If the user is not authorized to access its application, the connection is refused. Otherwise, the ZPA service edge sends a dispatch to the connector group. The application connector closest to the application responds, then sends an outbound TLS 1.2 tunnel to the service edge. Finally, the service edge closest to the user creates a second outbound TLS microtunnel between the service edge and the user and then stitches these two tunnels together. The end result is that connection happens only from the application towards the user. This entire model means that application access has been redefined. Applications are visible to authorized users only. Users are connected to specific applications only from the application outward. Internet is used as the transport medium. Users don't require a VPN and don't have network access. This makes lateral movement impossible within the network. This notion of attack surface and attack surface reduction is especially important. As an example, let's compare the attack surface between a traditional castle and moat security setup and ZPA. Here on the left, we have a perimeter security model, the castle and moat model. Since applications reside in private or public clouds or data centers, users have to be able to access them over the internet. This results in those applications being exposed to the internet. Malicious actors can discover these, exploit them, or perform DDoS attacks. Every internet-facing firewall is an attack surface. By contrast, with ZPA, these applications are no longer exposed to the internet. Since all connections transit through the Zero Trust Exchange and connections to applications are from the application to the user, this means your apps are no longer exposed to the internet. And since you can't attack what you can't see, your attack surface is drastically reduced. The end result is that ZPA allows you to implement a least-privileged access to your applications, performing user-to-app segmentation without requiring you to set up network microsegmentation. Authenticated users are connected to authorized applications with business policies that use user and application group information. All connections are inside-out. Third parties can be given secure remote access to your internal applications. Contractors can securely connect with their own devices without network access. B2B customers and suppliers have fast, seamless access, also without network access. And vendors can access utilities. Private service edges can also be hosted on-premise for user-to-app access from inside corporate locations, if required. That's it for this video. Thank you for watching.
