Guides
Secure Access Help Center

Multi-App with Resolved IP Match Enforcement Mode

This enforcement mode for ZTA private access combines the multi-app enforcement mode with additional identification of all possible private resources that would match to the resolved IP addresses of any domain-based resources found during the initial multi-app identification:

  • For each domain-based private resource that is identified, DNS resolution is performed at the ZTA proxy and all possible resolved IP addresses for the requested FQDN, ZTA enforcement will additionally identify all the possible private resources that would be matched to the resolved IP addresses.
  • ZTA enforcement next considers all possible private resources (across both FQDN and resolved IPs) during policy evaluation equally, while still matching to rules based on the top-down rule priority ordering.

The ZTA private access enforcement evaluation functions as follows:

  1. Identify all possible private resources that apply to the access request destination.
  2. For FQDN-based resources only, complete DNS resolution for all destinations even before it is known whether we will proceed with this resource at the end of policy evaluation.
    a. Note: DNS resolution for this step would continue to happen at the ZTA proxy as in any other domain-based flow:
    i. In the case of a resource behind an IPSec tunnel, the “internal DNS server” specified in the private resource definition would have to be accessible behind the same IPSec tunnel. The proxy would reach out to the DNS server for resolution in the same way as it would reach out to the destination resource itself.
    ii. In the case of a resource behind an Resource Connector Gateway (RCG), the resource DNS server would also be hosted behind the RCG. The proxy would reach out to the RCG for DNS resolution, and the RCG would complete DNS resolution and return the results to ZTA.
  3. Use the resolved IPs from DNS to re-identify all possible resources that apply to the entire subset of DNS-resolved IPs.
  4. Evaluate for rules that would apply to the requesting user/source and ANY of the identified possible resource matches.
    a. Includes both initially found FQDN-based resources, and IP-based resources that were identified after DNS resolution.
  5. Still prioritize the rule priority/definition order to decide which rule to match to.
  6. In case of a “tie-breaker” scenario (access requests matches to rule with multiple destinations that are all “valid” in multi-match approach), the most-specific match resource will be considered, with respect to the original requested destination.
    a. So, if the original request was to an FQDN, we would select the destination in the matched rule that corresponds to the most-specific FQDN over IP-based resources, if available.
    b. If there are no FQDN destinations in the matched rule for a FQDN-based request, we would match to the most specific IP-based resource (based on the DNS resolved IP).

Examples

Note – multi-app matching scenarios would also be applicable here.

Scenario 1: FQDN resource-based rule at higher priority than IP resource-based rule

Resource A -> defined with destination “acme.com”, which resolves to 10.10.10.10
Resource B -> defined with destination “10.10.10.0/24”

Access policy rules:

  1. UserGroupA has access to Resource A
  2. UserGroupA has access to Resource B
  3. UserGroupB has access to Resource A
  4. UserGroupB has access to Resource B

Behavior:

  • When a user in either group A or B accesses the “acme.com” destination, they would be matched to both Resource A and B; however, due to rule priority ordering, they would match to rules #1 and #3 respectively for all accesses. They would never match to the resolved-IP based resource.
  • When a user in either group A or B accesses an IP within the “10.10.10.0/24” CIDR, they would be matched to only Resource B. As a result, they would only ever match to rules #2 and #4 respectively for all accesses.

Scenario 2: IP resource-based rule at higher priority than FQDN resource-based rule

Resource A -> defined with destination “acme.com”, which resolves to 10.10.10.10
Resource B -> defined with destination “10.10.10.0/24”

Access policy rules:

  1. UserGroupA has access to Resource B
  2. UserGroupA has access to Resource A
  3. UserGroupB has access to Resource B
  4. UserGroupB has access to Resource A

Behavior:

  • When a user in either group A or B accesses “acme.com” destination, they would be matched to both Resource A and B. But due to rule priority ordering, they would match to rules #1 and #3 respectively for all accesses. They would never match to the original FQDN-based resource.
  • When a user in either group A or B accesses an IP within the “10.10.10.0/24” CIDR, they would be matched to only Resource B. As a result, they would only ever match to rules #2 and #4 respectively for all accesses.

Scenario 3: Tie-breaker scenario for FQDN-IP overlap within the same rule

Resource A -> defined with destination “acme.com”, which resolves to 10.10.10.10
Resource B -> defined with destination “10.10.10.0/24”

Access policy rules:

  1. UserGroupA has access to Resource A OR Resource B

Behavior:

  • Like earlier scenarios, a request to “acme.com” would match to both resource A and B.
  • But unlike earlier Scenarios, a request from a user in UserGroupA would match to rule #1 that has two valid destinations.
  • In this case, because the original request was to FQDN (“acme.com”), Resource A is the most specific match to the access request, and so access will be provided to Resource A.

Multi-App Match Enforcement Mode < Multi-App with Resolved IP Match Enforcement Mode > About Endpoint Requirements in Access Rules

Updated 8 days ago