Guides
Secure Access Help Center

Multi-App Match Enforcement Mode

This enforcement mode for ZTA private access considers all possible private resources matches (including duplicates) for a given access request during policy evaluation, rather than narrowing down to only one most-specific resource match, 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.
    a. In the case of IPs, match all resources that have IPs or CIDRs that contain the requested destination IP.
    b. In the case of FQDNs, match all resources that have exact domains or wildcards that contain the requested FQDN.
  2. Evaluate for rules that would apply to the requesting user/source and ANY of the identified possible resource matches.
  3. Still prioritize the rule priority/definition order to decide which rule to match to:
    a. Evaluation will be done top-down, with rule #1 being checked before rule #2, and so on.
    b. Each rule is evaluated and moved past if there is no perfect match (including posture requirements), but in case it is a rule match then evaluation stops with that rule as the selection and the proxy moves past the evaluation phase.
  4. In the case of a “tie-breaker” scenario the most-specific match resource will be considered.

Examples

Scenario 1: Multiple matching IP/CIDR destinations in different resources

Resource A -> 10.10.10.10
Resource B -> 10.10.10.10 (same port and protocol as Resource A)
Resource C -> 10.10.10.0/24
Resource D -> 10.0.0.0/8

Access policy rules:

  1. UserGroupA has access to Resource A
  2. UserGroupB has access to Resource B
  3. UserGroupC has access to Resource C
  4. UserGroupD has access to Resource D

Behavior:

  • When a request comes in for “10.10.10.10” as the destination, all resources (A to D) are identified and taken forward for policy evaluation.
  • At policy evaluation, a request for “10.10.10.10” can match to any of rules #1 to #4 from a destination point of view (logical equivalent is that - rule destination should be contained within the set of all possible resource matches that were identified).
  • But, since each rule has an explicitly different source, the rule would only be matched to if the source also aligns (i.e. user from UserGroupA would only ever match to rule #1, and so on).

Scenario 2: Multiple matching FQDN destinations in different resources

Resource A -> “test.acme.com”
Resource B -> “*.acme.com”
Resource C -> “test.acme.com”

Access policy rules:

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

Behavior:

  • Exactly like the IP/CIDR Scenario 1, all resources (A to C) would be identified for a request to “test.acme.com”.
  • Exactly like Scenario 1, while such a request can be matched to any of rules #1 to #3 in terms of destination, matching to a rule also requires matching to the source and so access would be segregated based on user identity; i.e. user from UserGroupA would only ever match to rule #1, and so on.

Scenario 3: Multiple matching rules by source and destination – rule ordering priority in effect

Resource A -> 10.10.10.0/24
Resource B -> 10.10.10.10

Access policy rules:

  1. UserGroupA has access to Resource A
  2. UserGroupA has access to Resource B

Behavior:

  • Like the earlier scenarios, a request to “10.10.10.10” would match to both resources A and B.
  • Unlike earlier scenarios, both rules can now apply to the same user (from UserGroupA) and both rules can provide access but to 2 different resources.
  • But, ZTA top-down rule enforcement based on rule priority is maintained, and because a request from UserGroupA to “10.10.10.10” would match to rule #1, rule #2 would never even be checked; the rule providing access to Resource B would never be hit, even though it is the most specific resource.

Scenario 4: Tie-breaker scenarios for multiple valid resource destinations in matched rule

Resource A -> 10.10.10.10
Resource B -> 10.10.10.10 (same port and protocol as Resource A)
Resource C -> 10.10.10.0/24

Access policy rules:

  1. UserGroupA has access to Resource A OR Resource C
  2. UserGroupB has access to Resource A OR Resource B
    Behavior:
  • Like the earlier scenarios, a request to “10.10.10.10” would match to all resource (A to C).
  • Like the earlier scenarios, a request from user in UserGroupA would match to rule #1, and for UserGroupB would match to rule #2, for the same “10.10.10.10” destination.
  • Unlike earlier scenarios, both rules have multiple destination resources that all map to the “10.10.10.10” destination.
  • For rule #1, since Resource A (10.10.10.10) is more specific than Resource C (10.10.10.0/24), access will be provided to Resource A.
  • For rule #2, since Resource A and B are identical in all sense (10.10.10.10 with same port and protocol), we will arbitrarily pick one to provide access.

Most Specific Match Enforcement Mode < Multi-App Match Enforcement Mode > Multi-App with Resolved IP Match Enforcement Mode

Updated 8 days ago