Configuring Zscaler Private Access (ZPA) to replace traditional VPN with zero trust network access by deploying App Connectors, defining application segments, configuring access policies based on user identity and device posture, and integrating with IdPs.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Configuring Zscaler Private Access (ZPA) to replace traditional VPN with zero trust network access by deploying App Connectors, defining application segments, configuring access policies based on user identity and device posture, and integrating with IdPs.
When replacing traditional VPN concentrators with application-level zero trust access
When providing remote users secure access to internal applications without network-level connectivity
When implementing least-privilege access where users only see authorized applications
When needing to make internal applications invisible to unauthorized users and the internet
When integrating ZTNA with existing SASE architecture using Zscaler Internet Access (ZIA)
Do not use for applications requiring raw UDP access (ZPA primarily supports TCP), for providing full network-level access equivalent to site-to-site VPN (use ZPA AppProtection or branch connector instead), or when the organization requires on-premises-only access control without cloud dependency.
Prerequisites
Zscaler Private Access subscription (Business or Transformation edition)
Identity provider configured: Okta, Microsoft Entra ID, Ping Identity, or SAML 2.0 IdP
App Connector VM requirements: Linux VM (CentOS 7/8, RHEL 7/8, Ubuntu 18.04+, Amazon Linux 2) with 2 vCPU, 4GB RAM minimum
Outbound connectivity from App Connector to ZPA cloud on port 443 (no inbound ports required)
DNS resolution from App Connector to internal application FQDNs
Zscaler Client Connector deployed on user endpoints
Workflow
Step 1: Deploy App Connectors in Application Network
App Connectors establish outbound-only tunnels to the ZPA cloud, providing access to internal applications.
# Download and install App Connector on Linux VM# Obtain provisioning key from ZPA Admin Portal > Administration > App Connectors# For RHEL/CentOSsudo yum install -y https://yum.private.zscaler.com/yum/el7/zpa-connector-latest.rpm
# For Ubuntu/Debian
curl -sS https://dist.private.zscaler.com/apt/pubkey.gpg | sudo apt-key add -
echo"deb https://dist.private.zscaler.com/apt stable main" | sudotee /etc/apt/sources.list.d/zpa.list
sudo apt update && sudo apt install -y zpa-connector
# Configure the connector with provisioning keysudo /opt/zscaler/bin/zpa-connector configure \
--provision-key
systemctl zpa-connector
systemctl start zpa-connector
systemctl status zpa-connector
/opt/zscaler/bin/zpa-connector status
"PROVISIONING_KEY_FROM_PORTAL"
# Start the connector service
sudo
enable
sudo
# Verify connector status
sudo
sudo
# Deploy second connector for HA (minimum 2 per site)
# Repeat on second VM with same App Connector Group provisioning key
Step 2: Define Server Groups and Application Segments
Map internal applications to server groups and create application segments.
ZPA Admin Portal Configuration:
1. Server Groups:
Navigate to: Administration > App Connectors > Server Groups
- Name: "DC-East-Servers"
- App Connector Group: "DC-East-Connectors"
- Servers:
- hr-portal.internal.corp (10.1.1.50, TCP 443)
- finance-app.internal.corp (10.1.1.51, TCP 443)
- git.internal.corp (10.1.2.10, TCP 22, 443)
2. Application Segments:
Navigate to: Resources > Application Segments > Add Application Segment
- Name: "HR Applications"
- Domain/URL: hr-portal.internal.corp
- TCP Ports: 443
- Server Group: DC-East-Servers
- Health Reporting: Continuous
- Bypass Type: Never (force all traffic through ZPA)
- Name: "Engineering Tools"
- Domain/URL: git.internal.corp, ci.internal.corp, wiki.internal.corp
- TCP Ports: 22, 80, 443
- Server Group: DC-East-Servers
- Segment Group: "Engineering Segment Group"
Step 3: Configure Access Policies
Define who can access which application segments based on identity and device posture.
Lightweight Linux service that creates outbound-only encrypted tunnels from internal networks to ZPA cloud, providing access to applications without inbound ports
Application Segment
Logical grouping of internal applications defined by FQDN/IP and ports, mapped to server groups for access policy enforcement
Server Group
Collection of application servers associated with App Connector groups that can serve requests for application segments
Access Policy
Rules defining which users/groups can access which application segments under what conditions (device posture, time, location)
Zscaler Client Connector
Endpoint agent installed on user devices that routes traffic to ZPA cloud for policy enforcement and application access
Browser Access
Clientless ZTNA option allowing application access through a web browser without requiring Zscaler Client Connector installation
Scenario: Migrating 500-User Organization from Cisco AnyConnect VPN to ZPA
Context: A financial services firm with 500 employees uses Cisco AnyConnect for remote access. VPN split-tunnel configuration creates security gaps, and full-tunnel mode causes performance issues. The firm needs application-level access control for SOX compliance.
Approach:
Deploy 4 App Connectors (2 per data center) with HA configuration
Define application segments for 20 internal applications grouped by business function
Configure access policies mapping AD groups to application segments with device posture requirements
Integrate CrowdStrike ZTA scores as device posture input (minimum score 60 for standard, 80 for financial apps)
Enable Browser Access for contractors accessing the vendor portal
Configure LSS to stream access logs to Splunk for SOX audit trail
Run parallel operation for 3 weeks: VPN and ZPA side by side
Phase out VPN connections after validating all application access through ZPA
Pitfalls: App Connector DNS must resolve all internal FQDNs used in application segments. Wildcard domain segments can cause performance issues if too broad. Browser Access does not support all web application frameworks (WebSocket-heavy apps may require Client Connector). CrowdStrike ZTA integration requires Falcon sensor deployment on all endpoints before enforcing posture policies.
