About ZTA Private Access Enforcement

Secure Access has a single Access policy, which consists of policy rules and settings. There are two types of access rules:

• Private access rules, which controls access to applications hosted from your data center and private clouds.
• Internet access rules, which controls access to resources on the internet from managed devices.

Your private access and internet policy rules and the default policy rules control the access and security of your resources and protect the traffic in your organization. Before you start adding rules to your policy, we recommend that you read through the topics in Manage the Access Policy.

Secure Access supports Zero Trust Access (ZTA) for secure remote access connections to configured private resources. We recommend that you read through the topics in Manage Private Resources and Manage Connections to Private Destinations for a thorough understanding of ZTA private access.

You configure private access rules to control the access and security of your private resources and protect the traffic in your organization. By default, traffic is handled by the first rule in the list that matches the traffic. Rules lower in the list have no effect on traffic that matches a rule higher in the list.

Secure Access provides several enforcement modes which provide a flexible approach to policy evaluation by allowing IT administrators to apply rules based on a broader set of criteria. The following topics describe the enforcement modes for ZTA private access:

• Most specific match enforcement mode — This is the default enforcement mode for ZTA private access.
• Multi-app match enforcement mode — This enforcement mode option 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.
• Multi-app with resolved IP match enforcement mode — This enforcement mode option identifies all the possible private resources that would be matched to resolved IP addresses following DNS resolution, and considers all possible private resources (across both FQDN and resolved IPs) during policy evaluation equally.

Note

For information about changing your organization's enforcement mode, contact Cisco Secure Access Support. For more information, see the contact support section in the Welcome to Secure Access topic.

Tip

Secure Access Packages and Feature Availability

Not all of the features described here are available to all Secure Access packages. Information about your current package is listed on the Admin > Licensing page. For more information, see Determine Your Current Package. If you encounter a feature here that you do not have access to, contact your sales representative for more information about your current package. See also, Cisco Secure Access Packages.

The default enforcement mode for ZTA private access follows a top-down approach to private access rule processing. Each request is evaluated against the defined list of rules in order of priority until it finds a rule that matches its criteria. Once a match is found, the access policy applies the specified action (allow or block).

Note: Traffic to private destinations is blocked by default. You must create rules to allow traffic to private destinations.

For each ZTA private access request, the default mode for policy evaluation functions as follows:

• Prior to policy evaluation, the ZTA proxy selects the one most-specific private resource to move ahead for the request.
• Only this one single resource is considered during policy evaluation, and only rules that include that resource in its destination can possibly be matched to.
• In order for a rule to match a request, along with defined source and destination, endpoint posture profile requirements associated with the rule must also be met.

• In the case of exactly duplicated private resources (identical IP/FQDN, port and protocol), this approach would have multiple equally specific matches, in which case ZTA would pick an arbitrary one of the matching resources.

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.
   1. In the case of IPs, match all resources that have IPs or CIDRs that contain the requested destination IP.
   2. 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:
   1. Evaluation will be done top-down, with rule #1 being checked before rule #2, and so on.
   2. 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.

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).

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.

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.

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. The resulting behavior is:

• 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.

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.

   Note

   DNS resolution for this step would continue to happen at the ZTA proxy as in any other domain-based flow:

   1. 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.
   2. 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. This 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.
   1. 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.
   2. 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).

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.

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.

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.