7.3 Application Segments, Segment Groups & Discovery

7.3 Application Segments, Segment Groups & Discovery

Core Principle: In traditional networks, access controls are applied to broad IP subnets and VLANs, exposing entire network segments to connected users. In Zscaler Private Access, access is defined strictly at the application level. An Application Segment defines exactly which internal workloads, domain names, IP addresses, and transport ports a user is authorized to reach. By coupling Application Segments with dynamic App Discovery and Synthetic IP interception, ZPA enables organizations to transition from legacy, unsegmented VPN environments to granular, least-privilege Zero Trust architectures.

---

1. Structure of an Application Segment

An Application Segment is the foundational policy object in ZPA that defines a private internal application or a group of related services.

+-----------------------------------------------------------------------------------+
|                    APPLICATION SEGMENT OBJECT STRUCTURE                           |
+-----------------------------------------------------------------------------------+

  ┌───────────────────────────────────────────────────────────────────────────────┐
  │                         APPLICATION SEGMENT DEFINITION                        │
  ├───────────────────────────────────────────────────────────────────────────────┤
  │ 1. Domain / IP Definitions:                                                   │
  │    - Exact FQDNs:     jira.corp.internal, gitlab.dev.local                    │
  │    - Wildcard Domains: *.finance.corp.internal, *.eng.local                   │
  │    - Specific IPs:    10.10.50.25, 172.16.4.100                               │
  │    - IP Subnets:      10.200.0.0/24                                           │
  ├───────────────────────────────────────────────────────────────────────────────┤
  │ 2. Protocols & Port Ranges:                                                   │
  │    - TCP Ports:       80, 443, 8080-8090, 3389                                │
  │    - UDP Ports:       53, 5000-5500                                           │
  ├───────────────────────────────────────────────────────────────────────────────┤
  │ 3. Association Bindings:                                                      │
  │    - Segment Group:   "Production-Engineering-Apps"                          │
  │    - Server Groups:   "AWS-East-Jira-Servers", "Azure-West-Git-Servers"       │
  │    - Connector Groups:"AWS-East-Connector-Group", "Azure-West-Connector-Grp" │
  ├───────────────────────────────────────────────────────────────────────────────┤
  │ 4. Operational Settings:                                                      │
  │    - Health Reporting: Continuous, On-Demand, or None                         │
  │    - Double-Blind / Inspection: Source IP Anchoring, AppProtection Profile   │
  └───────────────────────────────────────────────────────────────────────────────┘

Application Segment Matching Criteria:

1. Exact FQDN Matching: Matches a single explicit domain (e.g., payroll.corp.internal). Provides the highest specificity and security.
2. Wildcard Domain Matching: Matches all hostnames under a domain hierarchy (e.g., *.corp.internal matches app1.corp.internal, sub.dev.corp.internal, and api.corp.internal).
3. IP Subnet / Address Matching: Specifies individual IPv4/IPv6 addresses or CIDR blocks (e.g., 10.50.0.0/16). Typically used for legacy non-DNS applications or administrative IP access.
4. Port & Protocol Granularity: Restricts application access to designated TCP and UDP port lists (e.g., TCP 443, 8443) or port ranges (e.g., TCP 5000-5050), blocking unauthorized ports on the same host.

---

2. Segment Groups: Policy Bundling & Modular Management

A Segment Group is a logical container that bundles multiple Application Segments together.

+-----------------------------------------------------------------------------------+
|                 SEGMENT GROUPS IN ZPA ACCESS POLICY ARCHITECTURE                  |
+-----------------------------------------------------------------------------------+

  ┌───────────────────────────────────────────────────────────────────────────────┐
  │                        SEGMENT GROUP: "Finance-Core-Apps"                     │
  │  ┌─────────────────────────┐ ┌──────────────────────────┐ ┌────────────────┐  │
  │  │ App Segment: Payroll Web│ │ App Segment: Billing DB  │ │ App Segment:   │  │
  │  │ (payroll.corp:443)      │ │ (billing-sql.corp:1433)  │ │ SAP ERP (443)  │  │
  │  └─────────────────────────┘ └──────────────────────────┘ └────────────────┘  │
  └───────────────────────────────────────┬───────────────────────────────────────┘
                                          │ Referenced in
                                          ▼
  ┌───────────────────────────────────────────────────────────────────────────────┐
  │                               ZPA ACCESS POLICY                               │
  │  * Rule 1: IF User IN "Finance-Department" AND DevicePosture = "Compliant"     │
  │            AND Target Segment Group = "Finance-Core-Apps"                     │
  │            THEN Action = ALLOW                                                │
  └───────────────────────────────────────────────────────────────────────────────┘

Operational Advantages of Segment Groups:

• Simplified Access Policy Administration: Instead of authoring individual access policy rules for hundreds of distinct applications, administrators assign the entire Segment Group to a single policy rule.
• Dynamic Policy Inheritance: When a new Application Segment is created and placed into an existing Segment Group, all access rules and posture policies bound to that Segment Group automatically apply to the new application immediately.

---

3. Dynamic App Discovery vs. Defined Application Segments

When migrating from a legacy VPN to ZPA, enterprise IT teams frequently lack an accurate, up-to-date inventory of all internal applications, server hostnames, and required port numbers. ZPA solves this challenge through App Discovery Mode.

+-----------------------------------------------------------------------------------+
|                    BROWNFIELD APP DISCOVERY & ZERO TRUST LIFECYCLE                |
+-----------------------------------------------------------------------------------+

  PHASE 1: BROAD DISCOVERY                PHASE 2: TELEMETRY & LOGGING
  Create Wildcard App Segment             Users generate internal traffic
  [ *.corp.internal : Ports 1-65535 ] ──> [ ZPA Discovers Active Flows ]
                                                    │
                                                    ├──> payroll.corp.internal : 443
                                                    ├──> git.corp.internal : 22, 443
                                                    └──> sql-db.corp.internal : 1433
                                                    │
  PHASE 4: LEAST PRIVILEGE LOCKDOWN       PHASE 3: DEFINE SPECIFIC SEGMENTS
  Retire or restrict wildcard segment     Admin converts discovered apps into
  [ Zero Trust Micro-Segmentation ]   <── [ Defined Application Segments ]

How App Discovery Operates:

1. Configure Discovery Wildcard: The administrator creates an Application Segment with a wildcard domain (e.g., *.corp.internal) and broad port range (e.g., TCP 1-65535) and assigns it to an App Connector Group.
2. User Traffic Triggers Discovery: When an authorized user attempts to access an internal service (e.g., billing.corp.internal:8443), Client Connector intercepts the request, and the App Connector resolves and establishes the connection.
3. Automated Cataloging: ZPA logs the exact FQDN, destination IP, protocol, and port in the Discovered Applications dashboard.
4. Define Application Segment: With a single click in the ZPA Admin Portal, the administrator converts the discovered transaction into an explicit, Defined Application Segment with tight port boundaries.
5. Least-Privilege Enforcement: Once all essential enterprise workloads are defined, the broad wildcard segment is restricted or removed, achieving full Zero Trust isolation.

[!IMPORTANT] Rule Precedence: Defined Application Segments always take precedence over wildcard discovery segments. When a specific application is defined (e.g., payroll.corp.internal), traffic matching that specific FQDN is evaluated against the defined segment's policy rather than the general wildcard segment.

4. Synthetic IP Allocation & Double-Blind Interception

One of the most innovative mechanisms in ZPA is how Zscaler Client Connector (ZCC) intercepts application traffic without modifying the underlying operating system routing table or creating virtual network adapters with routable internal subnets.

+-----------------------------------------------------------------------------------+
|                   SYNTHETIC IP LOCAL INTERCEPTION SEQUENCE                        |
+-----------------------------------------------------------------------------------+

  Endpoint User Space                              Zscaler Client Connector (ZCC) Stack
  ┌───────────────────────────────┐               ┌───────────────────────────────────┐
  │ User Application (Browser)    │               │ Local DNS Proxy / Intercept Engine│
  │ Requests: jira.corp.internal  │               │                                   │
  └──────────────┬────────────────┘               └─────────────────▲─────────────────┘
                 │ (1. Standard OS DNS Query)                       │
                 └──────────────────────────────────────────────────┘
                                                                    │
  ┌─────────────────────────────────────────────────────────────────┴─────────────────┐
  │ 2. ZCC inspects query -> Matches ZPA Application Segment "*.corp.internal"        │
  │ 3. ZCC intercepts query -> Generates Synthetic IP: 100.64.0.45 (from CGNAT pool)  │
  │ 4. ZCC returns DNS 'A' Record (100.64.0.45) directly to Browser                   │
  └─────────────────────────────────────────────────────────────────┬─────────────────┘
                                                                    │
  ┌───────────────────────────────┐                                 │
  │ Browser opens TCP 443 socket  │ <───────────────────────────────┘
  │ Destination: 100.64.0.45:443  │
  └──────────────┬────────────────┘
                 │ (5. Outbound TCP Packet destined to Synthetic IP)
                 ▼
  ┌───────────────────────────────────────────────────────────────────────────────────┐
  │ 6. ZCC Tunnel Driver intercepts packet destined to 100.64.0.45                    │
  │ 7. Encapsulates payload in Z-Tunnel 2.0 (TLS/DTLS) -> Forwards to ZPA Service Edge│
  │ 8. Tunnel header includes metadata: Target = jira.corp.internal:443               │
  └───────────────────────────────────────────────────────────────────────────────────┘

Advantages of Synthetic IP Interception:

1. No IP Subnet Collisions: In traditional VPNs, if a remote worker's home Wi-Fi uses 192.168.1.0/24 and the corporate datacenter uses 192.168.1.0/24, routing breaks due to overlapping subnets. Because ZPA uses synthetic IPs in the Carrier-Grade NAT (CGNAT) block (100.64.0.0/10), local endpoint routing collisions are completely eliminated.
2. Zero Route Injection: ZCC does not inject hundreds of corporate routes into the endpoint operating system kernel routing table, preventing route table bloat and VPN routing flapping.
3. Network Topology Concealment: The endpoint never learns the true internal IP address of the destination server, preserving absolute zero trust network blindness.

---

5. Practical Configuration Scenario: Enterprise Application Migration

Objective: Migrate a corporate engineering toolset (*.dev.corp.internal) from a legacy SSL VPN to ZPA with least-privilege segmentation.

Implementation Workflow:

1. Create Segment Group: In ZPA Admin Portal, navigate to Application Management > Segment Groups and create Engineering-Dev-Tools.
2. Configure Discovery Segment: Under Application Management > Application Segments, create a wildcard segment:
   • Name: Dev-Wildcard-Discovery
   • Domains: *.dev.corp.internal
   • TCP Port Ranges: 1-65535
   • Segment Group: Engineering-Dev-Tools
   • Server Group: Dev-Datacenter-Servers
3. Monitor Discovered Applications: Navigate to Analytics > Diagnostics > Discovered Applications. Review inbound transactions over a 7-day period. The logs reveal active workloads:
   • gitlab.dev.corp.internal on TCP ports 22, 443
   • jenkins.dev.corp.internal on TCP port 8080
   • nexus.dev.corp.internal on TCP port 8443
4. Define Explicit Application Segments: Create discrete Application Segments for GitLab-Service (Ports 22, 443), Jenkins-Service (Port 8080), and Nexus-Service (Port 8443).
5. Apply Access Policies: Restrict GitLab-Service to Developers and Jenkins-Service to DevOps engineers.
6. Decommission Wildcard: Delete or disable the Dev-Wildcard-Discovery segment to enforce strict least-privilege access.

---

6. Exam Tips & High-Frequency Traps

[!TIP] Exam Tip (Wildcard vs. Specific Segment Precedence): When an incoming request matches both a defined FQDN segment (e.g., app.corp.com) and a broad wildcard segment (e.g., *.corp.com), ZPA always matches the most specific Application Segment.

[!WARNING] Exam Trap (Synthetic IP Range): The default Synthetic IP range used by ZPA is 100.64.0.0/10 (RFC 6598 CGNAT space). If an organization uses this range internally, administrators can configure a custom non-conflicting Synthetic IP range in the Client Connector profile.

[!IMPORTANT] Exam Key Point (App Discovery Requirement): App Discovery functions only when wildcard domains are used in an Application Segment. If an Application Segment contains only explicit FQDNs or IP addresses, App Discovery is inactive for that segment.