Chapter 7: Introducing ZTNA with Zscaler Private Access (ZPA)
In the very first chapter, we discussed two main issues faced by modern enterprises: the first being the need for a secure web access experience, and the second being the need to connect enterprise applications to their end users in a very flexible, secure way.
The first issue was addressed by the Zscaler Internet Access (ZIA) offering from Zscaler. This chapter discusses in detail the second offering from Zscaler, which is Zscaler Private Access (ZPA). We will look at the need for a Zero Trust Network Access (ZTNA) solution that is satisfied by ZPA. We will also look at how ZPA is architected, along with its related components.
You will learn about the need for ZTNA in today's enterprise environment, which drastically rethinks the security access model. You will also understand the building blocks of the ZPA architecture, and the role played by each component. We will also explore some clientless ZPA solutions where it is not possible to use the Zscaler Client Connector (ZCC) app.
In this chapter, we are going to cover the following topics:
- What is ZTNA and how does ZPA fit in to this?
- Delving into the ZPA architecture
- Exploring clientless ZPA solutions
What is ZTNA and how does ZPA fit in to this?
ZTNA is defined by Gartner (https://www.gartner.com/en/information-technology/glossary/zero-trust-network-access-ztna-) as "a product or service that creates an identity- and context-based, logical access boundary around an application or set of applications. The applications are hidden from discovery, and access is restricted via a trust broker to a set of named entities. The broker verifies the identity, context and policy adherence of the specified participants before allowing access and prohibits lateral movement elsewhere in the network. This removes application assets from public visibility and significantly reduces the surface area for attack."
This definition by Gartner is certainly a mouthful and is very generic in nature. Let's adapt this definition to the one given by Zscaler, as it applies to its ZPA solution. Zscaler defines this as follows (see https://www.zscaler.com/resources/security-terms-glossary/what-is-zero-trust-network-access for more details):
The ZTNA definition by Zscaler is a little bit easier to understand for anyone who is familiar with the security terms used in that definition. A traditional firewall, Virtual Private Network (VPN), or a proxy generally creates network segments—such as trusted segments and untrusted segments, but the ZTNA framework takes a totally different approach.
ZTNA core principles
Zscaler breaks this down into the following four core principles (taken from the same URL as previously):
- ZTNA completely isolates the act of providing application access from network access. This isolation reduces risks to the network, such as infection by compromised devices, and only grants application access to authorized users.
As mentioned previously, application access no longer means access to the underlying network that the application resides on. This means that lateral movement by a compromised device is no longer possible because all the compromised device sees is the application and not the network.
- ZTNA makes outbound-only connections, ensuring both network and application infrastructure is made invisible to unauthorized users. Internet Protocol (IP) addresses are never exposed to the internet, creating a darknet that makes the network impossible to find.
When end users request access to an application, both the end users and the applications have fake IP addresses that are never exposed to the internet. This means that whoever is scanning for the IP addresses on the public internet can never find these IP addresses, so there is nothing to attack.
- ZTNA's native app segmentation ensures that once users are authorized, application access is granted on a one-to-one basis. Authorized users have access only to specific applications, rather than full access to the network.
Although this principle looks very similar to the first one mentioned previously, this principle combines the least-privilege-access concept so that end users have just enough access to perform their work and cannot expand their access scope to beyond what is already provisioned.
- ZTNA takes a user-to-application approach to security, rather than a network-centric approach. The network becomes deemphasized and the internet becomes the new corporate network, leveraging end-to-end encrypted Transport Layer Security (TLS) micro-tunnels instead of Multiprotocol Label Switching (MPLS).
As explained earlier in the first principle, an end user is granted access just to an application, not the underlying network. This connection between the end user and the application occurs via encrypted TLS micro-tunnels that are established through the public internet; so, each end user-to-application session is an encrypted TLS micro-tunnel of its own.
Now that we have defined what ZTNA is and its four core principles, let's explore the need for ZTNA in today's enterprise security solutions.
Why is ZTNA needed?
Let's explore why enterprises today are looking toward adopting ZTNA. Here are some reasons for this:
- Alternative to traditional VPNs—VPNs have become slow and difficult to administer and manage, and offer limited security. Gartner predicts the following: "By 2023, 60% of the enterprises will phase out most of their remote access VPNs in favor of ZTNA."
- Secure access to multiple clouds—As many enterprises are adopting the cloud and migrating to multiple cloud providers for redundancy and portability, ZTNA is becoming increasingly popular.
- Least-privilege access—Third-party vendors and users often receive over-privileged access, creating security risks and gaps for an enterprise. ZTNA significantly reduces this risk by making sure that external users only gain access to authorized applications instead of gaining access to the network hosting those applications.
- Faster integration—When an enterprise acquires one or more businesses through mergers and acquisitions, network integration between the enterprise and the new companies can take years, with overlapping IP addresses. ZTNA simplifies and reduces the time and management needed for this effort, and yields quick business value.
Now that we have understood what ZTNA means and the need for it, let's examine how the ZPA product offering satisfies these ZTNA conditions.
ZPA security principles
The ZPA product offering was created with the four ZTNA core principles explained earlier. These are outlined again here:
Principle 1: Provide end users with access to the applications, not to the underlying network. ZPA only provides end users access to a specific application based on policy rules, without placing the end user onto the private network.
Access to applications should not be dependent on network access, such as access control lists (ACLs) based on IP addresses. If network access is not provided to end users, there is no risk of lateral movement (in case of any compromised devices) throughout the network, which may consist of hundreds of other resources. This minimizes the attack surface, providing a better level of security.
Principle 2: Applications are never exposed to the end users. ZPA does not advertise application availability in general to everyone. Applications are only visible to authenticated and legitimate end users.
By restricting the discovery of internal enterprise applications only to authenticated users, unauthenticated users who form a majority are unable to view those applications, thereby preventing any possible attack or exploitation. Not using inbound connections or public IP addresses creates an enterprise darknet, whereby applications are not exposed to the internet.
Principle 3: Don't segment the network—segment your applications. ZPA segments applications based on who the users are, what their access entitlement is, and the security-posture status of their end device.
When mapping is performed from a specific end user to a specific application using a per-session TLS micro-tunnel (thereby moving to a user-to-application model from a network-to-network model), this removes any lateral movement on that secure connection.
Principle 4: Use the internet for remote access, and not a VPN. ZPA leverages the internet by using secure TLS micro-tunnels to access private enterprise applications, without opening network-level access. ZPA also allows for optional double encryption of data transfer between the end-user device and the application, for complete security and privacy.
There is no need for a VPN in a ZPA solution. Both the end user and the application endpoints establish dynamic outbound TLS tunnels to the Zscaler cloud, and the Zscaler cloud will then broker the secure end-to-end connection between the end user and the application. Data is already encrypted end to end, and—optionally—enterprises can use their own client and server certificates for double encryption.
Now that we have looked at the four core security principles of ZPA, let's explore the architecture of ZPA.
Delving into the ZPA architecture
ZPA only supports communications in the client-to-server direction. Any other models (such as server-to-client, client-to-client, and so on) are not supported by ZPA. Important components of the ZPA architecture are the ZPA Central Authority (CA); ZPA Public Service Edge (PSE); ZCC application; App Connectors; ZPA Tunnels (Z-Tunnels); Microtunnels (M-Tunnels); the logging and analytics cluster; and the Log Streaming Service (LSS).
Let's look at each of the components in detail, beginning with the ZPA CA.
ZPA CA
We already looked at the CA when we learned about the ZIA architecture in Chapter 2, Understanding the Zscaler Modular Architecture. Similarities between both the ZIA and ZPA are that both are multi-tenant, redundant, globally distributed policy engines. However, the main difference is that the central purpose of the ZPA CA is to enable connection requests, in addition to enforcing provisioning policies.
Just as with the ZIA CA, the ZPA CA contains the configuration and policy that has been put in place by the enterprise administrator, based on the business needs. The CA also offers detailed visibility into end-user activity and application access. Where the ZPA CA differs is that it supports the App Connectors with their configurations.
To support end-user and administrator authentication, one or more Security Assertion Markup Language (SAML) identity providers (IdPs) must be configured on the ZPA CA, and—if necessary—customer-signed enrollment certificates may also be loaded onto the ZPA CA. The ZPA CA also lists applications that were discovered and can be configured to apply policies for specific applications defined by hostname or IP address and port range.
Manual or dynamic discovery of the servers hosting the applications is supported, although the dynamic option is recommended to reduce manual overhead. The ZPA CA also monitors the reachability and health of these applications so that end users are always connected to the best possible instance of the application. Granular policies can also be configured to control exactly which applications can be accessed by which end users.
Let's explore the next component of the ZPA architecture: the ZPA PSEs.
ZPA PSEs
ZPA PSEs are globally available nodes that broker the connection between end users and connectors, for specific application access. Again, note that ZPA PSEs are separate from ZIA PSEs because they serve completely different functions. Also, ZPA PSEs are a combination of Zscaler in-house data centers, Amazon Web Services (AWS), and Azure resources, to provide global optimum coverage.
End users approach the ZPA PSEs, looking to connect to the applications they are authorized for. The destination applications are already discovered by the App Connectors, and the App Connectors have already approached the ZPA PSEs, effectively announcing that they are ready and available for the end users. The ZPA PSEs then broker the end-to-end connections between these end users and the application connectors.
In addition to brokering these connections, the ZPA PSEs also provide authentication, end-user policy enforcement, and secure data forwarding through single encrypted and—optionally—double-encrypted TLS tunnels.
Let's now look at the next component of the ZPA infrastructure: the ZCC application.
ZCC application
We already spent a lot of time and effort to understanding the flexibility of this application for ZIA access. The ZCC application forms the central component for end users to access applications using ZPA. When the end-user device is connecting to ZPA applications, the browser or agent on the end-user device thinks it is talking directly to the destination application using a synthetic, fake IP address assigned to the application by the ZCC app.
When Z tunnels are established to the nearest ZPA PSE and microtunnels are eventually established between the end-user device and the destination application, the ZCC app serves as the origin for both tunnels. Posture profiles can be defined and associated with the end-user device so that access to the application is only allowed when the end-user host device complies with the specified posture requirements.
Upon successful enrollment with the ZPA PSE, the ZCC application is issued an identity certificate that is signed by the subordinate CA. The keys and certificates are securely stored within the ZCC app itself, and they are renewed every time the end user re-enrolls into the app. In the case of any indication of compromise, the enterprise administrator can disable ZPA access for that end device, and the certificates are automatically revoked.
When the ZCC app enrolls with the ZPA PSE, a hardware fingerprint is also captured with unique data from the end device, to prevent the possibility of cloning the ZCC app and its certificates by unauthorized parties. This unique data consists of the Central Processing Unit (CPU) ID, the unique battery ID, and so on (among other items). This fingerprint is validated every time the app checks in with the ZPA PSE. The ZPA CA then notifies the ZCC app of the available private enterprise applications and the applications that require double encryption.
ZPA web application access can also be achieved using a standard browser, with a Browser Access (BA) configuration option. The ZCC app allows additional features such as an end-user-device posture check and validation using a trusted network configuration and provides multi-protocol access to destination private applications. The BA option is only limited to web applications and will be covered later in this chapter.
When the end user requests access to an application by using the IP address or the Fully Qualified Domain Name (FQDN), the ZCC app will handle that request and establish a local synthetic IP address for the outbound connection. These IP addresses are from the Request for Comments (RFC) 6598 carrier grade range of 100.64.0.0/10, with a ZCC app using a modified subnet mask of /16. The client simply sends all requests to this allocated synthetic IP address.
This request is then sent by the ZCC app to the ZPA PSE, to validate the requested application and the TCP/UDP port (where UDP stands for User Data Protocol) being requested and provide SAML assertion for the user. The ZPA PSE then queries the ZPA CA to verify if this access is allowed per the defined policies of the enterprise, and checks if the application is still available before selecting the best possible connector.
Let's now explore the next component of the ZPA architecture: the App Connectors.
App Connectors
App Connectors are usually the Remote Package Manager (RPM) or Virtual Machines (VMs) installed on the destination network (typically on the same subnet as the applications) hosting the applications. On bootup, these VMs establish an outbound encrypted TLS connection to the nearest and healthy ZPA PSE. This connection is the control plane through which the ZPA PSE controls the configuration of the connector and announces the availability of the discovered application to the ZPA CA when needed.
Connectors do not need—or even support—any inbound connections. They serve as the origin point for the application Z tunnels to the Zscaler cloud and as the destination for the end-to-end microtunnels described previously.
Connectors must be able to resolve the applications via the Domain Name System (DNS) so that they can both connect to those applications and then can be made available over ZPA. In turn, the applications believe that they are simply talking to the connector and are unaware of the tunneling that will be used to connect with the end user's device.
A suitable ZPA subsidiary CA usually signs a provisioning key, which is then needed to enroll a connector. After this enrollment, the connector receives its configuration and certificates from the ZPA CA. These connectors are then controlled from the ZPA CA and can be updated or restarted as needed. Also, a device fingerprint is captured with unique data from the host device, to prevent any cloning of the connector and its certificates by unauthorized parties.
Each connector has throughput support of up to 500 megabits per second (Mbps). If additional capacity is needed by the enterprise, the connectors need to be scaled horizontally by adding more connectors. No special load balancers or clusters are needed. The ZPA intelligently and automatically distributes the originating user sessions across the available connectors to ensure the best user experience.
To avoid a complete outage in case a particular connector is being updated or restarted, it is recommended that connectors be deployed in pairs for redundancy and high availability. The connectors usually undergo weekly software updates.
Let's move on to the next component of the ZPA infrastructure: the Z tunnels.
Z tunnels
Z tunnels are fully encrypted TLS tunnels on port 443 that are both established outbound initially between the end-user ZCC App and the ZPA PSE (initiated by the end-user ZCC App) and then between the app connectors and the ZPA PSE (initiated by the connectors). These tunnels are double-pinned and mutually validated, providing immunity against Man-in-The-Middle (MiTM) attacks.
Z tunnels from the ZCC app to the ZPA PSE use Multi-Factor Authentication (MFA). They use SAML assertion, a user identity certificate, and a hardware fingerprint for this authentication. Similarly, Z tunnels from the connectors to the ZPA PSE use an identity certificate and a hardware fingerprint for validation. These tunnels are established using TLS version 1.2 and use the strongest encryption cipher that is mutually supported by the ZCC app, connector hosts, and the ZPA PSEs.
Let's examine the next component of the ZPA architecture: the microtunnels.
Microtunnels
Microtunnels are end-to-end data-byte stream connections, established between the end user and the destination application, originating from the end-user device, traversing through the ZPA PSE and the App Connector, and finally terminating on the destination application. Microtunnels are created on a per-user to per-application basis and cannot be shared with another user or application.
In an MPLS network, the carriers create unique IDs for the various interfaces on devices. This allows the devices to use those ID numbers when exchanging data packets between themselves. When a data packet eventually leaves the MPLS network, the last device on the path removes all the MPLS IDs before sending the data packet to its destination, which is not MPLS-aware.
Similarly, unique IDs are dynamically allocated by the ZCC app and the App Connectors, and those IDs are used to establish the session. The ZPA PSE is aware of these IDs and simply swaps the IDs, switching the traffic as needed between the ZCC app and the App Connectors. The end-user device and the applications are both unaware of this ID mechanism.
There is an additional option of double encryption. A second tunnel can be established within the microtunnel, using the strongest encryption cipher mutually supported by the ZCC app and the App Connectors. If customer keys are used for encryption, then even the ZPA PSE cannot intercept—or even read—the data within that second tunnel. This results in the data being double-encrypted between the ZCC app and the App Connector, providing an enterprise a greater level of security if there is such a business need.
Let's look at the next component of the ZPA infrastructure: the logging and analytics cluster.
Logging and analytics cluster
As with the logging options that we saw with ZIA, ZPA also offers real-time visibility into logs generated by various operations, such as the following logs:
- Primary tunnel logs—These logs capture authentication events between the App Connectors and the ZCC app on the end-user devices.
- Microtunnel logs—These logs capture user-data transactions.
As with ZIA logs, ZPA logs do not contain any end-user personally identifiable information (PII). The logs are not stored on any persistent hardware media until they arrive at the log cluster. The end-user information can also be obfuscated based on the needs of the enterprise.
The data that is stored at rest at the log cluster has abstracted IDs and does not make sense on its own. This information can be decoded only when combined with additional information stored somewhere else.
Let's look at the final component of the ZPA architecture: the Log Streaming Service (LSS).
LSS
LSS is very similar to the Nanolog Streaming Service (NSS) that we discussed in ZIA. LSS allows an enterprise to stream data—such as user activity, user and connector authentication, and BA logs—to the enterprise Security Information and Event Management (SIEM) for analysis and correlation, and to integrate it with a chosen ticketing platform. LSS needs a connector adjacent to the SIEM. LSS streams the logs through a ZPA PSE, which forwards it to a log receiver (SIEM) through a suitable connector.
In summary, we have seen that both the ZIA and ZPA PSEs are co-located within the same Zscaler data centers but serve very different purposes. We also saw the role and importance of each of the ZPA components and how they work together to provide end users secure access to enterprise private applications without ever exposing either to the internet.
Exploring clientless ZPA solutions
We looked at the ZPA architecture featuring the ZCC app. In certain environments, situations, and platforms, the ZCC app cannot be supported or installed. Let's look at two such clientless ZPA solutions.
Understanding the Zscaler Cloud Connector ZPA solution
Zscaler Cloud Connector aligns with the zero-trust access philosophy. It is a cloud-native service that allows for fast, secure connectivity between apps, and between an app and the internet.
Cloud connector
The cloud connector itself is a software instance that is in front of a VPC in AWS or a virtual network (VNET) in Microsoft Azure. Just as with the App Connector establishing outbound Datagram Transport Layer Security (DTLS) connections to the ZPA cloud, these cloud connectors establish outbound DTLS connections to a connection broker in the Zero Trust Exchange (ZTE).
ZTE
The ZTE is a large security cloud with a global footprint of more than 150 Zscaler data centers. This is like the Zscaler ZIA and ZPA cloud, and delivers a single control plane for secure traffic forwarding between end users and the internet, and between applications themselves.
Delving into the BA ZPA solution
A second—and more popular—clientless option is the BA (Browser Access) clientless ZPA solution. This solution is designed for ZPA applications that can be accessed by end users using a standard web browser. Both end-user authentication and eventual application access is all done using the web browser, without the need to install the ZCC app on end-user devices. There is also no need for a browser extension or a plugin, and not even a Java client on the end-user device.
This solution is designed for third-party vendors and users such as contractors who are unable to install the ZCC app on their end devices. This solution can also be used for platforms such as Google Chromebooks or Linux devices, as the ZCC app is not yet supported for those platforms.
BA components
The BA architecture consists of four components—namely, BA Exporter, BA Certificate, BA DNS CNAME Record, and the BA Crypto Store. Let's understand their role in detail.
BA Exporter
The BA Exporter is a secure web proxy that is located just before the ZPA PSE, and its primary purpose is to listen for incoming BA application requests. Upon receiving such a request, the BA Exporter responds with the needed BA Certificate and establishes a Z-tunnel to the local ZPA PSE upon successful end-user authentication.
BA Certificate
The BA Certificate is a web server certificate for one or multiple BA applications. It can also be a wildcard certificate.
BA DNS CNAME Record
The BA DNS CNAME Record is a CNAME alias for a BA application that is usually resolved to the best BA Exporter.
BA Crypto Store
The BA crypto store is a key store for the BA that contains the BA Certificate private keys and is in the Amazon Key Management Service (KMS).
BA workflow
Once the applications have been identified for migration to ZPA, a BA certificate for each such application must be provisioned in the ZPA cloud. To facilitate the DNS resolution of the application FQDN to the ZPA infrastructure, a CNAME record must be defined for each application on the DNS, typically on the external public DNS servers.
Once these steps have been completed, the end user requests access to the ZPA application by entering the FQDN as a URL in the address bar of the web browser. The DNS server will find a matching A record and will resolve it to an IP address. The user's device then receives the IP address for the best possible BA Exporter that the end user can use to then access the requested application.
The user's browser session connects to this BA Exporter resolved by DNS and then receives the BA certificate (already uploaded to the ZPA cloud) for that application. If the user device already has the proper root CA certificate, this connection to the BA Exporter is then trusted and allowed to proceed.
A TLS connection is then established between the end-user browser and the BA Exporter, and end-user authentication using SAML and the configured IdP is initiated. The user proceeds to authenticate at this point using their credentials, and receives a SAML assertion upon successful authentication. This is no different from the ZPA authentication process using the ZCC app.
The access policy is then checked and, if allowed, the user is granted access to the requested application. The ZPA cloud then provides a combination of the best possible ZPA PSE and the best possible App Connector to access the application. The second leg of the connection is established between the BA Exporter and the App Connector, all the way to the ZPA application.
The final step is the creation of the end-to-end microtunnel, providing an encrypted data path from the user's browser to the application. HyperText Transfer Protocol Secure (HTTPS) is used to encrypt the session between the browser and the BA Exporter, and Z tunnels are used for the rest of the connection path. This microtunnel is created in a unique per-user and per-application combination. It cannot be used by another user or for accessing another application.
BA certificate creation
Let's walk through the process of creating a BA certificate (typically a web certificate from a private CA owned by the enterprise). The first step is to log in to the ZPA Admin Portal. Click on Administration -> Certificate Management -> Browser Access Certificates. Then, click on the Browser Access Certificates tab at the top of the page. Click on the Create CSR option in the top right-hand corner of the page to start a new certificate signing request (CSR). On the Create CSR popup that appears, fill in the following options:
- Name—A name for this CSR.
- Description—A free-flowing text field that can be used to describe the purpose of this CSR.
- Subject—This field needs to conform to the X.520 syntax for the Relative Distinguished Name (RDN), with the following notation: C (Country), ST (State), O (Organization), CN (Common Name), and so on.
- Subject Alternate Name—If necessary, fill in this field; it should match the CN field used in the previous Subject field.
Click Create to create this CSR. The next step is to download the CSR file and get it signed by the enterprise private CA. Follow these steps:
Click on the pencil icon against the CSR just created, to edit the CSR. You can either click on the Download CSR option or select the text for the CSR into a text editor.
The next step is to log in to the enterprise root CA and select the option to request a certificate. You should choose the right format when submitting this certificate request (such as Base 64-encoded). Choose the CSR contents saved previously and generate a web-server type of certificate. Download the generated certificate using Base-64 encoding and save it to the computer from where you are logged in to the ZPA Admin Portal.
Back on the ZPA admin portal, you should have the Create CSR popup window still open, or you can navigate to it as instructed previously. Under the Certificate section, click the Select File button and upload the certificate file that was saved to the computer just now. This completes the process of creating a BA certificate.
Creating a BA CNAME record
After generating the BA certificate, let's walk through the process to create the CNAME record for BA. The administrator needs to log in to the ZPA admin portal and click on Administration -> Application Management -> Application Segments. Under the Application Segments tab on the page, select the chosen application segment (by clicking on the blue pencil icon against it) to enable that application for BA.
On the resulting Edit Application Segment pop-up window, navigate to the Applications section and click the checkbox that says Browser Access. You will see additional options underneath the selection. Select the BA certificate name that was created in the previous section, and then select HTTPS under Protocol so that the BA Exporter can use HTTPS when connecting to the destination ZPA private application. You may change the port number (optionally) if it deviates from the default, and check the box that says Use Untrusted Certificates if the application server certificate cannot be validated by the BA Exporter. Click Save to apply your changes.
As soon as you enable BA for an application, it appears under the Browser Access tab at the top of the page. Navigate to that tab and click on the chevron (>) sign to the left of your application name to view the details. Copy the CNAME, and then add it to your DNS server. This completes the CNAME configuration for BA.
Testing BA
Once we are done with the BA certificate creation and the CNAME update process, it is time to test BA from the end user's computer. Have the end user log in to their computer and make sure the ZCC app is not running. If it is running, have the user log out of the ZCC app and close the app completely.
Have the end user launch a browser window and navigate to the web application that we configured for BA earlier. The user should be prompted to authenticate using the IdP configured by the ZPA administrator. Once the user authenticates using their credentials, the browser should immediately load the web application using BA. To verify the certificate presented by the ZPA cloud, have the user click on the lock icon to the left of the URL. Click on View Details, and it should show that this certificate has been verified by the enterprise private CA and can be fully trusted.
Summary
In this chapter, we learned about the necessity for ZTNA and its core principles. We also saw how ZPA aligns with the core principles of ZTNA and provides end-user access to enterprise private applications.
In the next chapter, we will review the various types of system-provided dashboards offered by the ZPA Admin Portal. We will also explore the most common basic configuration options that need to be performed by any ZPA enterprise administrator.
Questions
As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:
- ZPA aligns with the core principles of ZTNA.
a. Yes
b. No
- Enterprise end users access applications over ZPA using a publicly routed IP address.
a. Yes
b. No
- ZPA can only be supported by the ZCC agent.
a. True
b. False
- ZIA and ZPA use the same components and infrastructure components.
a. True
b. False