Using Secure Access Cloud Access and Activity Policies

Products

• Symantec ZTNA

Issue/Introduction

Using Secure Access Cloud Access (SAC) and Activity policies

Environment

Secure Access Cloud

Resolution

SAC allows you to continuously enforce contextual access and activity policies to control access to resources and restrict users’ actions within the resource based on the context of the user, device and resource (such as the user’s role in the organization, location of the user, MFA status, managed/unmanaged device status etc’).

The article below provides information on how to use the access and activity policies in SAC.

Overview

The Access and Activity policies are designed to implement the organizational access scenarios, for example “Allow sales engineer access from managed devices” access scenario could be implemented as a single access policy for all relevant applications, entities (groups) and conditions (managed device).

In addition, the actions a user can perform within the application can also be restricted, for example in a scenario where the entire sales team is provided with access from both managed and unmanaged devices, the actions the users can perform when accessing from unmanaged devices can be restricted using an activity policy.

Such an activity policy (for example ‘Restrict sales from unmanaged devices’) would include the condition, entities and applications to which it applies (unmanaged devices, Sales group and the applications) and will include the rules restricting the actions themselves (for example file download, specific URI access, etc’).

Each application and entity (such as user, group or an API client) can be assigned to multiple applications in order to support multiple access scenarios.

Definitions

• Access policy – a policy which is used to define allowed access to specific applications. The access policy is defined based on the application type (Web, SSH, RDP or TCP).
• Activity policy – a policy which is used to restrict specific operations within the application, based on its type. For web applications the restrictions may include access to specific URIs, file download events, etc’. For SSH applications the restrictions maybe used to restrict which SSH commands are allowed to be executed.
• Conditions – the conditions are the context of the user or the device performing the request based on which access is granted/denied or based on which a specific action should be restricted. For example, the location of the user performing the request or the state of the device (managed/unmanaged) from which the request is performed could be used to decide whether to grant or deny access to a specific resource and which actions should be restricted. Conditions are used to match the access or activity policies which should apply to the requests.
• Validators – validators are specific actions enforced by SAC to enforce additional validation on the user or the device. An example is an MFA validator which is used as an additional validation of the user’s identity.
• Rules – the explicit actions performed by the end-user (for example file download, or access to a specific URI) and the response to these actions (for example – block action).

Access Policies

Policy Evaluation

The access policy model implements a single-match policy model. This means that for each access request, SAC identifies all applicable policies for the user/application tuple and evaluates these policies against the request context (conditions) to determine whether the request should be allowed or denied.

If no access policy could be matched the access is blocked.

If a policy is matched, the validators in the policy will be applied to the access request (for example – MFA).

If multiple policies are matched a conflict resolution process would be triggered which will prioritize based the following prioritization logic:

1. Policies with validators will apply first.
2. If no policies with validators exist, or all policies have validators defined - policies where the user is explicitly assigned (vs. assigned via a group) will apply second.
3. If all policies are equal – the conflict will be resolved based on the ‘date created’ of the access policy, with older policies applied before newer policies.

Creating an Access Policy

In order to create a new access policy, navigate to the policies tab and create a new access policy.

The access policies are available per application type (e.g. – Web, SSH/SSH Gateway, TCP or RDP). For each access policy type you will be able to assign only applications of that specific type in the policy.

 

 

Access Policy configuration
When defining a policy, the following sections are available for all SSH Access Policies:

1. Applications - the applications to which the policy applies.
2. Entities - users/groups/api-clients to which the policy applies.
3. Context of the request - Filter conditions that specify the context of the user and the device in which the policy will apply. Context includes information about the source IP address, source location and source device. The policy is effective only when *ALL* conditions are satisfied (evaluate to TRUE).
4. Validators - The controls you want to enforce as a prerequisite for granting access to the requested resource. Examples are Multi-factor authentication and Web Verification.

 

In addition, there are SSH and TCP specific sections, available only in the SSH and TCP access policies:

1. SSH Access Policy:
   1. Local Accounts – defines the local accounts defined on the target SSH applications which the assigned entities are allowed to access the SSH application with. For example ‘root’, ‘ec2-user’.
   2. Keys and Agent Forwarding – Authentication – defines the authentication method the entities are allowed to authenticate with. The authentication methods include temporary access token (which is retrieved from the application portal), client certificate (which is a user-specific SSH certificate and can be downloaded from the application portal).
   3. Agent Forwarding – defines whether the SSH certificate used by the user for authentication (if defined in the authentication section) can be forwarded to other resources from the target SSH application.
2. TCP Access Policy:
   1. Keys – Authentication – defines the authentication method the entities are allowed to authenticate with. The authentication methods include temporary access token (which is retrieved from the application portal), client certificate (which is a user-specific SSH certificate and can be downloaded from the application portal).

 

Selecting entities and applications

After defining the policy name you’ll need to select the applications and entities to which this policy applies.

 

When the policy evaluation begins (upon the initial access request by the user) the evaluation starts by matching ‘potentially applicable’ policies based on the tuple of user and application.

 

The user’s entire group membership is evaluated in order to match policies in which groups, the user is a member of (either directly or recursively) is a member of.

 

Selecting conditions

Once selecting the applications and entities you can define conditions under which the access policy will be applied. Conditions include location, source IP address of the user/device performing the request, device state.

 

You can define multiple conditions which will be applied in the access policy. These conditions are evaluated using an AND statement, which means the user/device need to satisfy *ALL* conditions in order to be allowed access to the application.

 

SSH Access Policy Example

In order to create a new SSH access policy navigate to the policies tab and create a new SSH access policy.

 

1. Create the new access policy and defined the application to which the access policy applies and the entities (users and groups) which are allowed to access the specified application:
2. Define the local accounts which the assigned entities are allowed to ‘access as’ to the target applications. In this example the accounts are shared across all SSH applications. In the case of personal SSH accounts (for example when the target SSH applications are defined with personal account per user) you can leverage the ‘Local account per user’ option, where the prefix of the user principal name will be used as the local account (for example for [email protected] UPN, the local account used will be ‘michael’).
   
3. Define the authentication and agent forwarding options to apply to the assigned entities and applications.
4. Optional – define the conditions and the validators to apply for the access attempts made by the assigned entities to the assigned applications.

Activity Policies

Activity policies are used to define rules which restrict specific operations within the application, based on its type. For web applications the restrictions may include access to specific URIs, file download events, etc’. For SSH applications the restrictions are used to restrict which SSH commands are allowed or not allowed to be executed.

Activity Policy Evaluation

The activity policy model implements a multi-match model.

This means that for each activity performed by the end-user, SAC identifies all applicable policies for the user/application and the context (conditions) with which the user ‘arrives’ to the application and applies the restrictions rules defined in *ALL* of the matched policies.

If no activity policy could be matched, then no restrictions will apply to the user.

Creating an Activity Policy

In order to create a new access policy, navigate to the policies tab, click on the ‘New’ button and select the type of applications to which you want to create the new activity policy for .

The activity policies are available per application type (Web and SSH/SSH Gateway).

For each activity policy type you will be able to assign only applications of that specific type in the policy and define rules which apply on actions based on the specific protocol (HTTP or SSH).

Activity Policy configuration

When defining a policy, the following sections are available for all SSH Access Policies:

1. Applications - the applications to which the policy applies.
2. Entities - users/groups/api-clients to which the policy applies.
3. Conditions – define the context of the request. The conditions are used to filter which activity policies should be applied given the context of the user/device. Context includes information about the source IP address, source location and others. The policy is effective only when *ALL* conditions are satisfied (evaluate to TRUE).
4. Rules - The specific operations which should be restricted or allowed (for example ‘URI access’ or ‘HTTP Command’ for Web activities or ‘SSH command’ for SSH activities) .

Activity policy conditions:

The conditions specify the context under which the activity policy will apply. For example, creating a location condition means the policy will apply ONLY when a user is accessing the specified resource from the location specified in the condition.

Activity policy rules:

The rules specify the constraints on the action that the user wants to perform. For example, URI deny list for web applications or file download restrictions.

Each rule contains the trigger (the action performed by the user which triggers the rule) and the action, which determines how the SAC should react when the trigger occurs, for example – you can define an action of ‘block action’ in case of an attempt to access a specific URI (for example the ‘/admin’ URI).

Using Activity Rules

1. In the ‘Rules’ section click on the ‘Add Rule’ to view the available rules which could be used to apply restrictions, then choose if the allow/deny rule is going to be applied.
2. Selecting a specific rule will create a new rule definition, in which a specific parameter (if required) should be provided as well as the ‘response’ action. In the example below of a ‘URI accessed’ trigger the parameter includes the list of URIs which should be restricted, and the possible response may be selected as one of the follows: Block action, Block user, Disconnect user.
   
3. In order to specify the parameter, click on the parameter list (empty line) which will open a modal dialog where you could provide the specific URIs which you would want to restrict:
4. Once the parameter and actions are specified the rule will apply on all applicable requests based on the user, application and conditions defined in the activity policy: 
5. In order to block specific action applied for the defined URI, click on "Add Condition" button under URI access rule:
    
   and select the "File Download"
   
    
6. In order to allow the specific list of action only, choose the "Allow rules" option, then click on the request activity to be allowed. When saved, the listed activities only will be allowed when accessing to the applications that appear in the policy.
   In the example below, for the applications listed in the policy, GET HTTP command only will be allowed.