Prisma Access
Security Policy for Apps Enabled with ZTNA Connector
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
5.2 Preferred and Innovation
- 5.2 Preferred and Innovation
- 5.1 Preferred and Innovation
- 5.0 Preferred and Innovation
- 4.2 Preferred
- 4.1 Preferred
- 4.0 Preferred
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
-
-
-
-
- Allocate Licenses for Prisma Access (Managed by Strata Cloud Manager)
- Plan Service Connections for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Add Additional Locations for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Enable Available Add-ons for Prisma Access (Managed by Strata Cloud Manager)
- Search for Subscription Details
- Share a License for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Increase Subscription Allocation Quantity
-
- Activate a License for Prisma Access (Managed by Strata Cloud Manager) and Prisma SD-WAN Bundle
- Activate and Edit a License for SASE 5G Through Common Services
-
- General Onboarding Instructions for Prisma Access
-
4.0 & Later
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
- Prisma Access China
-
- Set Up Prisma Access
- Configure the Prisma Access Service Infrastructure
- Remote Networks: IPSec Termination Nodes and Service IP Addresses
- Remote Networks: IP Address Changes Related To Bandwidth Allocation
- Remote Networks: Service IP Address and Egress IP Address Allocation
- API Examples for Retrieving Prisma Access IP Addresses
- Get Notifications When Prisma Access IP Addresses Change
- Prisma Access Zones
- DNS for Prisma Access
- High Availability for Prisma Access
-
- Enable ZTNA Connector
- Delete Connector IP Blocks
- Set Up Auto Discovery of Applications Using Cloud Identity Engine
- Private Application Target Discovery
- Security Policy for Apps Enabled with ZTNA Connector
- Monitor ZTNA Connector
- View ZTNA Connector Logs
- Preserve User-ID Mapping for ZTNA Connector Connections with Source NAT
-
- Enable Dynamic Privilege Access for Prisma Access Through Common Services
- Authorize User Group Mapping in Cloud Identity Engine for Dynamic Privilege Access
- Enable the Access Agent
- Set Up the Agent Infrastructure for Dynamic Privilege Access
- Create a Snippet
- Create a Project
- Traffic Steering for Dynamic Privilege Access
- Push the Prisma Access Agent Configuration
- Download the Dynamic Privilege Access Enabled Prisma Access Agent Package
-
- Install the Prisma Access Agent
- Log in to the Dynamic Privilege Access Enabled Prisma Access Agent
- Change Preferences for the Dynamic Privilege Access Enabled Prisma Access Agent
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Location
- Switch to a Different Project
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Server
- Disable the Dynamic Privilege Access Enabled Prisma Access Agent
- Switch Between the Prisma Access Agent and GlobalProtect App
- View and Monitor Dynamic Privilege Access Users
- View and Monitor Dynamic Privilege Access Projects
- Manage Prisma SASE 5G
- App Acceleration in Prisma Access
-
-
- Planning Checklist for GlobalProtect on Prisma Access
- Set Up GlobalProtect Mobile Users
- GlobalProtect — Customize Tunnel Settings
- GlobalProtect — Customize App Settings
- Ticket Request to Disable GlobalProtect
- GlobalProtect Pre-Logon
- GlobalProtect — Clientless VPN
- Monitor GlobalProtect Mobile Users
- How the GlobalProtect App Selects Prisma Access Locations for Mobile Users
- Allow Listing GlobalProtect Mobile Users
-
- Explicit Proxy Configuration Guidelines
- GlobalProtect in Proxy Mode
- GlobalProtect in Tunnel and Proxy Mode
- Private IP Address Visibility and Enforcement for Agent Based Proxy Traffic
- SAML Authentication for Explicit Proxy
- Set Up Explicit Proxy
- Cloud Identity Engine Authentication for Explicit Proxy Deployments
- Proxy Mode on Remote Networks
- How Explicit Proxy Identifies Users
- Explicit Proxy Forwarding Profiles
- PAC File Guidelines
- Explicit Proxy Best Practices
- Monitor and Troubleshoot Explicit Proxy
- Block Settings for Explicit Proxy
- Use Special Objects to Restrict Explicit Proxy Internet Traffic to Specific IP Addresses
- Access Your Data Center Using Explicit Proxy
- App-Based Office 365 Integration with Explicit Proxy
- Chromebook with Prisma Access Explicit Proxy
- Configure Proxy Chaining with Blue Coat Proxy
- Configure Proxy Chaining on Prisma Access Explicit Proxy
- IP Address Optimization for Explicit Proxy Users- Proxy Deployments
- DNS Resolution for Mobile Users—Explicit Proxy Deployments
- View User to IP Address or User Groups Mappings
- Report Mobile User Site Access Issues
- Enable Mobile Users to Access Corporate Resources
-
-
- Planning Checklist for Remote Networks
- Allocate Remote Network Bandwidth
- Onboard a Remote Network
- Connect a Remote Network Site to Prisma Access
- Enable Routing for Your Remote Network
- Onboard Multiple Remote Networks
- Configure Remote Network and Service Connection Connected with a WAN Link
- Remote Networks—High Performance
- Integrate a Shared Desktop VDI with Prisma Access Using Terminal Server
-
- Multitenancy Configuration Overview
- Plan Your Multitenant Deployment
- Create an All-New Multitenant Deployment
- Enable Multitenancy and Migrate the First Tenant
- Add Tenants to Prisma Access
- Delete a Tenant
- Create a Tenant-Level Administrative User
- Sort Logs by Device Group ID in a Multitenant Deployment
-
- Add a New Compute Location for a Deployed Prisma Access Location
- How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote Network Connections
- Proxy Support for Prisma Access and Strata Logging Service
- Block Incoming Connections from Specific Countries
- Prisma Access for No Default Route Networks
-
-
- Default Routes With Prisma Access Traffic Steering
- Traffic Steering in Prisma Access
- Traffic Steering Requirements
- Default Routes with Traffic Steering Example
- Default Routes with Traffic Steering Direct to Internet Example
- Default Routes with Traffic Steering and Dedicated Service Connection Example
- Prisma Access Traffic Steering Rule Guidelines
- Configure Zone Mapping and Security Policies for Traffic Steering Dedicated Connections
- Configure Traffic Steering in Prisma Access
- Preserve User-ID and Device-ID Mapping for Service Connections with Source NAT
-
- Prisma Access Internal Gateway
-
- Configure Privileged Remote Access Settings
- Set Up the Privileged Remote Access Portal
- Configure Applications for Privileged Remote Access
- Set Up Privileged Remote Access Profiles
- Define Permissions for Accessing Privileged Remote Access Apps
- Configure Split Tunneling for Privileged Remote Access Traffic
- Manage Privileged Remote Access Connections
- Use Privileged Remote Access
-
- Integrate Prisma Access With Other Palo Alto Networks Apps
- Integrate Third-Party Enterprise Browser with Explicit Proxy
- Integrate Third-Party NDRs with Prisma Access
- Juniper Mist Integration for SASE Health
-
-
- Connect your Mobile Users in Mainland China to Prisma Access Overview
- Configure Prisma Access for Mobile Users in China
- Configure Real-Name Registration and Create the VPCs in Alibaba Cloud
- Attach the CEN and Specify the Bandwidth
- Create Linux Instances in the Alibaba Cloud VPCs
- Configure the Router Instances
- Onboard the GlobalProtect Gateway and Configure the Prisma Access Portal
-
-
-
- INC_CIE_AGENT_DISCONNECT
- INC_CIE_DIRECTORY_DISCONNECT
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_MU_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_MU_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_DNS_SERVER_UNREACHABLE_ PER_PA_LOCATION
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_RN_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_DNS_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_ECMP_TUNNEL_RTT_EXCEEDED_ BASELINE
- INC_RN_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SECONDARY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SITE_CAPACITY_PREDICTION
- INC_SC_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SITE_CAPACITY_PREDICTION
-
- INC_CERTIFICATE_EXPIRY
- INC_GP_CLIENT_VERSION_UNSUPPORTED
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_CAPACITY
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_THRESHOLD
- INC_PA_INFRA_DEGRADATION
- INC_PA_SERVICE_DEGRADATION_PA_LOCATION
- INC_PA_SERVICE_DEGRADATION_RN_ SITE_CONNECTIVITY
- INC_PA_SERVICE_DEGRADATION_SC_ CONNECTIVITY
- INC_RN_ECMP_BGP_DOWN
- INC_RN_ECMP_BGP_FLAP
- INC_RN_ECMP_PROXY_TUNNEL_DOWN
- INC_RN_ECMP_PROXY_TUNNEL_FLAP
- INC_RN_ECMP_TUNNEL_DOWN
- INC_RN_ECMP_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_BGP_FLAP
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_BGP_DOWN
- INC_RN_SECONDARY_WAN_BGP_FLAP
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_FLAP
- INC_RN_SITE_DOWN
- INC_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_RN_SPN_LONG_DURATION_CAPACITY_EXCEEDED _THRESHOLD
- INC_RN_SPN_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_SC_PRIMARY_WAN_BGP_DOWN
- INC_SC_PRIMARY_WAN_BGP_FLAP
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_PRIMARY_WAN_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_BGP_DOWN
- INC_SC_SECONDARY_WAN_BGP_FLAP
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_TUNNEL_FLAP
- INC_SC_SITE_DOWN
- INC_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_SC_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- INC_ZTNA_CONNECTOR_CPU_HIGH
- INC_ZTNA_CONNECTOR_MEMORY_HIGH
- INC_ZTNA_CONNECTOR_TUNNEL_DOWN
-
- AL_CIE_AGENT_DISCONNECT
- AL_CIE_DIRECTORY_DISCONNECT
- AL_MU_IP_POOL_CAPACITY
- AL_MU_IP_POOL_USAGE
- AL_RN_ECMP_BGP_DOWN
- AL_RN_ECMP_BGP_FLAP
- AL_RN_PRIMARY_WAN_BGP_DOWN
- AL_RN_PRIMARY_WAN_BGP_FLAP
- AL_RN_PRIMARY_WAN_TUNNEL_DOWN
- AL_RN_PRIMARY_WAN_TUNNEL_FLAP
- AL_RN_SECONDARY_WAN_BGP_DOWN
- AL_RN_SECONDARY_WAN_BGP_FLAP
- AL_RN_SECONDARY_WAN_TUNNEL_DOWN
- AL_RN_SECONDARY_WAN_TUNNEL_FLAP
- AL_RN_SITE_DOWN
- AL_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- AL_RN_SPN_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_PRIMARY_WAN_BGP_DOWN
- AL_SC_PRIMARY_WAN_BGP_FLAP
- AL_SC_PRIMARY_WAN_TUNNEL_DOWN
- AL_SC_PRIMARY_WAN_TUNNEL_FLAP
- AL_SC_SECONDARY_WAN_BGP_DOWN
- AL_SC_SECONDARY_WAN_BGP_FLAP
- AL_SC_SECONDARY_WAN_TUNNEL_DOWN
- AL_SC_SECONDARY_WAN_TUNNEL_FLAP
- AL_SC_SITE_DOWN
- AL_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_SITE_LONG_DURATION_EXCEEDED_CAPACITY
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- AL_ZTNA_CONNECTOR_CPU_HIGH
- AL_ZTNA_CONNECTOR_MEMORY_HIGH
- AL_ZTNA_CONNECTOR_TUNNEL_DOWN
- New Features in Incidents and Alerts
- Known Issues
Security Policy for Apps Enabled with ZTNA Connector
ZTNA Connector seamlessly extends your existing Prisma Access security policy to the
applications it enables for Prisma Access.
Where Can I Use This? | What Do I Need? |
---|---|
|
|
ZTNA Connector does not enforce policy; it seamlessly extends your existing Prisma
Access security policy to the applications it enables for Prisma Access. This means
you can use a common policy across all your applications and data centers, and you
don't need to author your security policy separately for apps onboarded to ZTNA
Connector.
However, as part of setting up ZTNA Connector, you do need to make sure that your
security policy:
Allows traffic between Prisma Access and ZTNA Connector
For this, follow the ZTNA Connector Requirements and Guidelines to make sure that ZTNA Connector can
connect to Prisma Access.
Users can access the applications behind the ZTNA Connector
To ensure your users can access ZTNA Connector apps, follow the steps here for the
interface you're using to manage Prisma Access.
Security Policy for Apps Enabled with ZTNA Connector (Strata Cloud Manager)
Set up a Security policy rule that enables users to access apps behind ZTNA Connector
for Cloud Managed Prisma Access deployments and Strata Cloud Manager.
After you onboard apps to ZTNA Connector, you should set up policy rules to allow and
control access for those apps. The procedure to create and apply policy differs on
whether your apps are defined by
wildcards
, IP Subnets
, or FQDNs
. Security Policy for Wildcard-Based Apps
Wilcard-based apps ( (SettingsZTNA ConnectorApplication TargetsWildcard Targets) require that you create a custom URL category; however, that
type of category only enforces policy for HTTP and HTTPS traffic, and other
traffic (such as SSH) isn't allowed. For this reason, you need to temporarily
allow access to all apps by allowing traffic to the ZTNA Connector Application
IP blocks.
After ZTNA Connector learns the FQDNs that are based on the wildcards, you can
disable the policy that allows Application IP Block traffic and apply policy
enforcement based on the learned FQDNs.
- Create a Custom URL category and add the wildcard URLs to the category.
- Go toManageConfigurationNGFW and Prisma AccessSecurity ServicesURL Access Management.
- Under Custom URL categories, Add Category.
- Give a descriptive Name for the custom URL category and select a Type of URL List.
- Add the wildcard URLs you created in ZTNA Connector to the Items.
- Save your changes.
- Create a URL access Management Profile and add the custom URL category you created to it.
- While still in the URL Access Management area, select URL Access Management Profiles.
- Select an existing profile to modify or Add Profile.
- Add the Custom URL category you created to the profile.
- Select the following parameters:
- Site Access: Allow
- User Credential Submission: Allow
- Save your changes.
- Create a profile group and attach the URL Access Management Profile to the group.
- Go to ConfigurationNGFW and Prisma AccessSecurity ServicesProfile Groups.
- Add a profile group, specifying the URL Access Management Profile you created.
- Create a policy to allow the profile group and the IP addresses for the ZTNA Connector Application IP Blocks.
- Go to WorkflowsPrisma Access SetupPrisma AccessPrisma Access Setup and make a note of the Application IP Blocks under ZTNA Connector IPs.
- Go to ManageConfigurationNGFW and Prisma AccessObjectsAddressAddresses and Add address objects based on the IP addresses you retrieved.If you have IP Subnet-based apps, create address objects for those subnets as well.
- Go to ManageConfigurationNGFW and Prisma AccessObjectsAddressAddress Groups and Add the address objects you created to an address group.
- Go to ManageConfigurationNGFW and Prisma AccessSecurity ServicesSecurity PolicyPre Rules and Add a Security policy to allow access to all application IP address blocks, specifying the Address Group and Profile Group you created in an earlier step.Adding this Security policy allows all traffic from wildcard-based app traffic to be passed while ZTNA Connector discovers the apps based on wildcards. Without the rule to allow the Application IP Blocks, users can't access wildcard-based apps.You can leave this policy in place until ZTNA Connector discovers the wildcard-based apps. Then, you can choose to disable this policy and add Security policy rules for each of the discovered apps.
- After ZTNA Connector has discovered the apps based on wildcards, configure a Security policy for the apps that you added using FQDNs.
- Go to WorkflowsZTNA ConnectorApplication TargetsFQDN Targets and make a note of the FQDNs used by the apps.
- Create an Address object for the FQDN (ManageConfigurationNGFW and Prisma AccessObjectsAddressAddresses).Select the Prisma Access configuration scope.
- Add an address object with the Type of FQDN: Domain Name and enter the FQDN of the discovered application.Enter the FQDNs for the FQDN targets.
- Go to ManageConfigurationNGFW and Prisma AccessSecurity ServicesSecurity PolicyPre Rules and Add a Security policy to allow access to the discovered apps.
- Push Config to save and push your configuration changes.
- (Optional) After you have created the Security policy based on FQDNs, remove the policy based on the IP application blocks.
Security Policy for IP Subnet-Based Apps
- Go to WorkflowsZTNA ConnectorApplication TargetsIP Subnets and make a note of the IP subnets used by the apps.
- Create a policy to allow the IP addresses for the IP subnets used for the apps.
- Go to ManageConfigurationNGFW and Prisma AccessObjectsAddressAddresses and Add address objects based on the IP addresses you retrieved.
- Go to ManageConfigurationNGFW and Prisma AccessObjectsAddressAddress Groups and Add the addresses you created to the address groups.
- Go to ManageConfigurationNGFW and Prisma AccessSecurity ServicesSecurity PolicyPre Rules and Add a Security policy to allow access to the IP subnets for the apps, specifying the Addresses you created in an earlier step.
- Push Config to save and push your configuration changes.
Security Policy for FQDN-Based Apps
- Configure a Security policy for the apps that you added using FQDNs.
- Go to WorkflowsZTNA ConnectorApplication TargetsFQDN Targets and make a note of the FQDNs used by the apps.
- Create an Address object for the FQDN (ManageConfigurationNGFW and Prisma AccessObjectsAddressAddresses).Select the Prisma Access configuration scope.
- Add an address object with the Type of FQDN: Domain Name and enter the FQDN of the discovered application.Enter the FQDNs for all discovered apps.
- Optional Go to ManageConfigurationNGFW and Prisma AccessSecurity ServicesSecurity PolicyPre Rules and Add a Security policy to allow access to the discovered apps.
- Push Config to save and push your configuration changes.
Security Policy for Apps Enabled with ZTNA Connector (Panorama)
Set up a Security policy rule that enables users to access apps behind ZTNA Connector
for Panorama Managed Prisma Access deployments.
After you onboard apps to ZTNA Connector, you should set up policy rules to allow and
control access for those apps. The procedure to create and apply policy differs on
whether your apps are defined by
wildcards
, IP Subnets
, or FQDNs
.
Security Policy for Wildcard-Based Apps
Wilcard-based apps ( (SettingsZTNA ConnectorApplication TargetsWildcard Targets) require that you create a custom URL category; however, that
type of category only enforces policy for HTTP and HTTPS traffic, and other
traffic (such as SSH) isn't allowed. For this reason, you need to temporarily
allow access to all apps by allowing traffic to the ZTNA Connector Application
IP blocks.
After ZTNA Connector learns the FQDNs that are based on the wildcards, you can
disable the policy that allows Application IP Block traffic and apply policy
enforcement based on the learned FQDNs.
- Create a policy to allow the IP addresses for the ZTNA Connector Application IP Blocks.
- From the ZTNA Connector UI, go to WorkflowsPrisma Access SetupPrisma AccessPrisma Access Setup and make a note of the Application IP Blocks under ZTNA Connector IPs.
- Go to ObjectsAddresses and Add address objects based on the IP addresses you retrieved.
- Go To ObjectsAddress Groups and Add the address objects you created to an address group.
- Go to PoliciesSecurity Pre Rules and Add a Security policy to allow access to all application IP address blocks, specifying the Address Group you created in an earlier step.Adding this Security policy allows all traffic from wildcard-based app traffic to be passed while ZTNA Connector discovers the apps based on wildcards. Without the rule to allow the Application IP Blocks, users can't access wildcard-based apps.You can leave this policy in place until ZTNA Connector discovers the wildcard-based apps. Then, you can choose to disable this policy and add Security policy rules for each of the discovered apps.
- After ZTNA Connector has discovered the apps based on wildcards, configure a Security policy for the apps that you added using FQDNs.
- Go to WorkflowsZTNA ConnectorApplication TargetsFQDN Targets and make a note of the FQDNs used by the apps.
- Create an Address object for the FQDN (ObjectsAddresses).Select either the Mobile_User_Device_Group or the Remote_Network_Device_Group, depending on whether mobile users or users at branch sites will be accessing the private apps behind ZTNA Connector.
- Add an address object with the Type of FQDN and enter the FQDN of the discovered application.Enter the FQDNs for the FQDN targets.
- Go to PoliciesSecurityPre Rules and Add a Security policy to allow access to the discovered apps.
- Commit and Push your changes.
- (Optional) After you have created the Security policy based on FQDNs, remove the policy based on the IP application blocks.
Security Policy for IP Subnet-Based Apps
- Go to WorkflowsZTNA ConnectorApplication TargetsIP Subnets and make a note of the IP subnets used by the apps.
- Create a policy to allow the IP addresses for the IP subnets used for the apps.
- Go to ManageConfigurationNGFW and Prisma AccessObjectsAddressAddresses and Add address objects based on the IP addresses you retrieved.
- Go To ObjectsAddress Groups and Add the addresses you created to the address groups.
- Go to PoliciesSecurityPre Rules and Add a Security policy to allow access to the IP subnets for the apps, specifying the Addresses you created in an earlier step.
- Push Config to save and push your configuration changes.
Security Policy for FQDN-Based Apps
- Configure a Security policy for the apps that you added using FQDNs.
- Go to WorkflowsZTNA ConnectorApplication TargetsFQDN Targets and make a note of the FQDNs used by the apps.
- Create an Address object for the FQDN (ObjectsAddresses).Select either the Mobile_User_Device_Group or the Remote_Network_Device_Group, depending on whether mobile users or users at branch sites will be accessing the private apps behind ZTNA Connector.
- Add an address object with the Type of FQDN and enter the FQDN of the discovered application.Enter the FQDNs for all discovered apps.
- Optional Go to ManageConfigurationNGFW and Prisma AccessSecurity ServicesSecurity PolicyPre Rules and Add a Security policy to allow access to the discovered apps.
- Push Config to save and push your configuration changes.