Access Policy Configuration for Zero Trust Approach

Post establishing the trust score parameters and weightage, you can create access policies to implement the policy-based access method in the organization, utilizing the generated user and resource trust scores. These access policies can be tailored to meet the specific needs and requirements of the organization, allowing users to be granted appropriate access privileges to the corresponding resources in a detailed and dynamic manner.

Navigate to 'Admin >> Zero Trust >> Access Policy' to create the new access policies with desired conditions concerning your requirements. Every access policy created for this zero trust approach is to be approved by another administrator of the organization to check for valid access policy conditions towards the users and the resources.

1. Creating an Access Policy

To create an access policy for implementing policy-based access privilege, do the steps that follow:

1. Navigate to 'Admin >> Zero Trust >> Access Policy'.
2. In the page that opens, click Add to create an Access Policy.
3. On the page that opens:
   1. Enter the Policy Name and Description.
   2. Select the approver(s) from the Approval Request Recipient field who will approve this access policy for further implementation.
      

   Note: A minimum of one condition is required to create an access policy.

1.a Creating an Access Policy Condition

To create a condition in an access policy, do the steps that follow:

1. Click New Condition to create a condition.
2. On the page that opens, fill in the necessary fields that follow:
   1. Condition Name - Enter a condition name of your choice.
   2. Description - Enter a detailed description of the condition for future reference.
   3. Use an existing condition as the template - If you have created conditions previously for any access policies, they will be listed in this field. You can use it from the drop-down as a template for this new condition.
      

   Notes:
   i. You can create multiple conditions in an access policy concerning your requirements.
   ii. If there are multiple conditions in an access policy, the user/resource should meet all the configured criteria in the conditions of the access policy to get the respective access privileges.

1.b Defining Criteria and Criteria Expression

Now you have to provide the criteria for this access policy condition that have to be met to get further allowed access privileges via this access policy condition:

1. Password Policy [C1] - In this field, you can choose the strength of the password policy. The password policy is to ensure the password strength of the accounts to which the access privilege is to be given to the users.
   How does it work?
   If you select the lower strength as criteria C1 and the resource to which this access policy is applied has a higher strength, criteria C1 will be accepted. However, if you choose higher strength and the resource to which this access policy is applied has a lower strength of password policy level, the criteria will not be satisfied.
2. Password Access Control [C2] - You can also choose the access control status required for an account or resource to grant access privileges. Access control status for the accounts or resources ensures a controlled level of access by the administrator posts zero trust access policy conditions.
   How does it work?
   If you select Disable, the criteria will be considered valid regardless of the access control configuration at the account or resource level where this access policy is implemented. However, if you select Enable and the accounts or resources covered by this access policy do not have configured access control, then the criteria will not be satisfied.
3. User Trust Score [C3] - Here, you can define the minimum trust score of the user who tries to get access privileges via this access policy. You can either provide a greater-than value or an in-between value as criteria C3.
4. Resource Trust Score [C4] - Similar to the user trust score, here you can define the resource trust score of the resources to which the access privilege is given via this access policy. You can either provide a greater-than value or an in-between value as criteria C4.
5. Criteria Expression - Using this criteria expression option, you can customize your way of criteria' (C1, C2, C3, and C4) importance in the condition of an access policy. Either you can use the AND/OR button to maintain it, or you can use the Edit option to set your criteria importance manually. E.g., [C1 or (C2 and C3) or C4]

1.c Allowed Access If the Criteria Expression is Met

You can enable the access privileges here based on the respective users' requirements to which the condition is to be applied. If the above-defined criteria expression is satisfied, the user associated with this condition is given access privileges that you enabled in this condition.

1. RDP Access - Enabling this checkbox will permit users to take RDP sessions to the resources configured under this access policy when they meet the defined criteria expression.
2. SSH Access - This option will permit users to take SSH sessions to the resources configured under this access policy when they meet the defined criteria expression.

   Note: Users will be restricted to attain all SSH, Telnet, and Legacy SSH connections when they fail to meet the criteria expression configured with enabled SSH access.

3. Remote App - Enabling this access will permit users to connect to the remote applications configured in the target resources when they meet the defined criteria expression.
4. SQL Access - Enabling this checkbox will permit users to take SQL sessions to the SQL resources configured under this access policy when they meet all the defined criteria.
5. Password Reset - This access will grant permission to the users to do remote password reset when the respective user and resource meet the defined criteria expressions.

   Note: If you have any scheduled password reset configured, it will not be affected by the access policy conditions configured via zero trust. Even if the user/resource fails to meet the configured criteria expression, the password reset will be performed through the scheduled password reset.

6. Landing Server Access - Enabling this will allow users to remotely access the IT assets in your data centers configured with a primary landing server if the criteria expression is satisfied.

   Note: To attain the access privilege to a resource configured via the landing server, both the landing server and target resources should meet the defined criteria expression if they are associated with policy-based access privilege conditions.

7. JIT Privilege Elevation - This option provides Just-In-Time privilege elevation access to accounts in PAM360 if all the criteria are satisfied according to the expression added for this condition.
8. Self-Service Privilege Elevation - Linux (If resource configured with Self-Service Privilege Elevation) - Enabling this option will allow users to execute privileged commands with an elevated account privilege without sharing the passwords of the high-privileged user accounts if the provided criteria expression is satisfied. To learn more about configuring Self-Service Privilege Elevation in Linux, click here.

   Notes:
   i. If you are enabling this access privilege in a condition, it is required to enable SSH Access for this access privilege to work for a user.
   ii. If you are allowing users to take remote sessions via external SSH clients such as Remote Connect, PuTTY, etc., for Self-Service Privilege Elevation - Windows/Linux, it is required to neglect the User Trust Score [C3] criteria. The user authentication parameters cannot be validated for such cases.

9. Self-Service Privilege Elevation - Windows (If resource configured with Self-Service Privilege Elevation) - Enabling this option will allow users to run certain types of files/applications (.cmd, .exe, .msc, .msi, and .bat) with elevated account privileges without sharing the password of the higher privilege account if the criteria expression is satisfied. To learn more about configuring Self-Service Privilege Elevation, click here.

   Note: If you are enabling this access privilege in any condition, it is required to enable RDP Access for this access privilege to work for a user.

1.d Actions If the Criteria Expression is Not Met

The operation you select in this section will be performed when the user/resource fails to meet the above-defined criteria expression of a condition.

1. Perform audit and allow access - This option involves conducting an audit of the user's and resource's activity and then granting access to the requested if they fail to meet the criteria expression defined in the access policy condition.
2. Issue a warning message and allow access - If the criteria expression configured in an access policy condition is not satisfied, this option permits users' access to the resource but also sends a warning message to the user to alert them.
3. Request a reason and allow access - Enabling this option involves asking the user to provide a reason for their access request if they fail to meet the configured criteria expression of a condition. If the user provides a reason, the access privilege is permitted with the given reason; otherwise, the access is denied.

   Note: All the above three options are verified during the initial stages before granting the user access to the respective resource. If any of the criteria gets failed post permitted to access, the session will continue without any reason or warning, and this action will be in effect from the impending sessions.

4. Deny/terminate access - This option involves denying access to the resource entirely, and the user is not allowed to access the resource when the criteria expression is not satisfied.
5. Deny/terminate access and send a warning email - If the configured criteria expression of the condition is not met, this option involves denying access to the resource and sending a warning email to the user to alert them.

   Note: The above two operations will be performed during the initial validation and active privileged sessions of the resources. If the configured criteria expression fails during an active privileged session, the respective enabled operation (terminate or warning message with a termination) will be performed.

Applies To: This option allows you to include or exclude users from the condition based on your policy-based access privilege requirements. By associating users with the condition, you can enforce the respective access policy for the users via relevant user groups.

To learn how to create an access policy that involves multiple conditional cases, you can refer to this real-time scenario help document.

2. Mindful While Creating Multiple Conditions in an Access Policy

1. While creating the access policy conditions, you can enforce it to all the users in the organization or a few specific users via user groups. If you want to exclude a few users from the access policy where they have already been included through different user groups, using the same condition template, you can add a new condition with the option 'Exclude User Group'.
2. If there are two below conditions in an access policy applied for the same user:
   1. If the user trust score is greater than 70, allow RDP and SSH access. Else perform an audit and provide access.
   2. If the user trust score is greater than 50, allow RDP access. Else deny/terminate access.
   It works in a way that - RDP access will be allowed for the user trust score greater than 50 or will deny/terminate the session if it is less than 70. SSH access will not be allowed for the user since it is not enabled in one of the conditions.

   Note: If an allow access privilege is not enabled for a user in any of the conditions of an access policy, then it will be considered a disabled privilege for the access policy. In the above cases, we recommend you create unique access policies for RDP and SSH access for the same user with diverse criteria.

3. In an access policy with multiple conditions that have varying criteria and actions for the same user, the privileged access calculation for that access policy will always consider the action from the condition that has the higher precedence action. E.g., Deny/terminate, Exclude User Group.
4. The criteria expression [C1 or C2 and C3 and C4] is always verified from right to left, irrespective of the AND/OR condition. You can use the edit criteria expressions option and use the '()' brackets to define precedence to the criteria validation. E.g., [C1 or (C2 and C3) or C4]
5. For the resource configured with Self-Service Privilege Elevation on Windows or Linux, the trust score of the logged-in user account will be considered for access policy criteria calculation and not the trust of the user account that is used to elevate the privilege.

Related Document