Policy Management

• 1: Creating Policies
• 2: Adding Data Elements to Policy
• 3: Adding Roles to Policy
• 4: Configuring Policy Permissions
• 4.1: Permission Conflicts
• 4.1.1: Inheriting Permissions
• 5: Deploying Policies

1 - Creating Policies

Creating a Structured Policy

This section describes the steps to create a structured policy.

To create a structured policy:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appears.

2. Click Add New Policy.

   The New Policy screen appears.

3. Select Structured from Type.

4. Type a unique name for the policy in the Name textbox. The maximum length of the policy name is 55 characters.

5. Type the description for the policy in the Description textbox.

6. Under the Permissions tab, select the required permissions.

   For more information about adding permissions, refer to the section Configuring Policy Permissions.

7. Under the Data Elements tab, add the required data elements.

   For more information about adding data elements, refer to the section Data Elements.

8. Under the Roles tab, add the required roles.

   For more information about adding roles, refer to the section Roles.

9. Under the Data Stores tab, add the required Data Stores.

   For more information about adding data stores, refer to the section Data Stores.

10. Click Save.

A message Policy has been created successfully appears.

Creating an Unstructured Policy

This section describes the steps to create an unstructured policy.

To create an unstructured policy:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Click Add New Policy.

   The New Policy screen appears.

3. Select Unstructured from Type.

4. Type a unique name for the policy in the Name textbox.

   The maximum length of the policy name is 55 characters.

5. Type the description for the policy in the Description textbox.

6. Under the Permissions tab, select the required permissions.

   For more information about adding permissions, refer to the section Configuring Policy Permissions.

7. Under the Data Elements tab, add the required data elements.

   For more information about adding data elements, refer to the section Data Elements.

8. Under the Roles tab, add the required roles.

   For more information about adding roles, refer to the section Roles.

9. Under the Data Stores tab, add the required Data Stores.

   For more information about adding data stores, refer to the section Data Stores.

10. Click Save.

A message Policy has been created successfully appears.

2 - Adding Data Elements to Policy

Adding Data Elements for Structured Policies

This section describes the steps to add data elements for structured policies.

To add data elements for structured policies:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Select the policy.

   The screen to edit the policy appears.

3. Click the Data Elements tab.

4. Click Add.

   The list of all the available data elements appears.

5. Select the data elements.

6. Click Add.

A message Selected Data Elements have been added to the policy successfully appears.

Adding Data Elements for Unstructured Policies

This section describes the steps to add data elements for unstructured policies.

To add data elements for unstructured policies:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Select the policy.

   The screen to edit the policy appears.

3. Click the Data Elements tab.

4. Click Add.

   The list of data elements created for unstructured data appears.

5. Select the data elements.

6. Click Add.

A message Selected Data Elements have been added to the policy successfully appears.

3 - Adding Roles to Policy

Adding Roles to Policies

You add roles to a policy to enforce user access to data. The roles can be set up to enable granular access control on sensitive enterprise data. You can add one or more roles to a policy.

To add roles to policies:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Select the policy.

   The screen to edit the policy appears.

3. Click the Roles tab.

4. Click Add.

   The list of roles created appears.

5. Select the roles.

6. Click Add.

A message Selected Roles have been added to the policy successfully appears.

4 - Configuring Policy Permissions

Policy Permissions define how your end users will interact with sensitive data. Permissions specify if the members of a Role have the ability to protect or unprotect a given Data Element. Permissions govern the format of data to return for authorized and unauthorized unprotect operations.

Permissions can be set using the ESA Web UI or the Policy Management API.

Available Permissions vary depending on whether the Policy is Structured or Unstructured.

For Structured Policies, the following Permissions are configurable for each Data Element:

• Unprotect: Allows Role members to unprotect data.
• Protect: Allows Role members to protect data.
• Reprotect: Allows Role members to reprotect data.

Note: From 10.1.0, if you have selected the HMAC-SHA256 data elements, then only the Protect option is enabled. The other options, such as, Reprotect and Unprotect are grayed out.

For Unstructured Policies, the following Permissions are configurable for each Data Element:

• Unprotect Content: Allows Role members to unprotect data.
• Protect Content: Allows Role members to protect data.
• Reprotect Content: Allows Role members to reprotect data.
• Create Object: Allows Role members to create a file or directory.
• Admin Permissions: Allows Role members to add or remove protection.

Access and No-Access Operations

You can control the data output during unprotect operations:

• For authorized unprotect operations, you can decide to return the data in the clear or with an applied Mask.
• For unauthorized unprotect operations, you can decide to return the data in its protected form if it is available, as null, or generate an error.

The following table specifies the behavior during Unprotect operations.

Note: Masks can only be applied during unprotect operations.

For more information about how no-access operations work for users in multiple roles, refer to the section No-Access Operations for Users in Multiple Roles.

You can also set permissions or rules using the Policy Management API.

Setting Default Permissions for a Policy

By default, every new Policy is created with most restrictive permissions, disallowing all operations for Policy members. Changes to Permissions will have to be made on a granular level, by modifying Data Element Permissions or Role Permissions.

To set default permissions for a policy:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Select the required policy.

   The screen to edit the policy appears.

3. Click the Permissions tab.

4. Select the required permissions.

5. Click Save.

The permissions are set for the policy. The default Permissions are inherited by every new Role added to the Policy. Roles added before the Permission change are not modified.

Modifying Data Element Permissions

You can modify Permissions of Roles for each individual Data Element. The new Permissions override the default Permission configuration.

To customize permissions for each data element:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Select the required policy.

   The screen to edit the policy appears.

3. Click the Data Elements tab.

4. Click Edit Permissions.

   The Permissions screen appears.

5. Select the required permissions.

   You can choose the Permissions of each Policy Role on the Data Element you are modifying.

   Note: If you are using masks with any data element, then ensure that masks are created before editing permissions.

6. Click Save.

A message Permissions have been updated successfully appears.

Note: The customized permissions, if any, override the default permissions for any policy.

Modifying Role Permissions

You can modify Permissions over Data Elements for each individual Role. The new Permissions will override the default Permission configuration.

To customize permissions for each role:

1. On the ESA Web UI, navigate to Policy Management> Policies & Trusted Applications> Policies.

   The list of all the policies appear.

2. Select the policy.

   The screen to edit the policy appears.

3. Click the Roles tab.

4. Click Edit Permissions.

   The Permissions screen appears.

5. Select the permissions.

   You can choose the Permissions of each Policy Data Element for the Role you are modifying.

6. Click Save.

A message Permissions have been updated successfully appears.

4.1 - Permission Conflicts

Policy users can be assigned to multiple roles with different Data Element permission settings. This section guides you through conflict resolution applied by the software. As a general rule, the least restrictive permissions are applied. If the conflict is unsolvable, access may be revoked. If multiple policies exist in one data store, then the effective merged policies and merged role permissions are applied when the Data Store is deployed.

Masking Conflicts

In case of Masking conflicts, the general rule of applying least restrictive permission is typically applied, with some exceptions.

Study the following table to understand all possible conflict permutations and their outputs. In this table, User U1 with a policy P is associated with roles R1, R2, and R3. The user is also connected with the data element DE1 containing Left and Right masks, and output formats.

Unprotect Permission Conflicts

Unprotect Permissions may be set to authorized or unauthorized. In the case of authorized access, the data can be returned as masked or in the clear. In the case of unauthorized access, the output may be set to null, exception, or protected string, if available for the specific Data Element.

In case of Authorized and Unauthorized Unprotect Permissions conflicts, the general rule of applying least restrictive permission is always applied. Study the following table to understand all possible conflict permutations and their outputs.

No-Access Operations for Users in Multiple Roles

In case of Unauthorized Unprotect Permissions conflicts, the general rule of applying least restrictive permission is always applied. Study the following below to understand all possible conflict permutations and their outputs.

4.1.1 - Inheriting Permissions

A special case exists when a user is present in multiple roles, this creates a conflict. This section provides information about how the software resolves this conflict. As a general rule, the software applies the most restrictive permissions.

Typically, when a policy user is assigned a role that does not have a specific data element associated with the role, then the user cannot use the data element for performing security operations. If the user tries to use the data element, then an error is generated.

However, consider a policy where you have created a default role that is applicable to all users. You associate a specific data element with this default role. In this case, the policy user, who is included in another role that is not associated with the specific data element, inherits the permissions for this data element from the default role. This scenario is applicable only if the users are a part of the same policy or a part of multiple policies that are applied to the same data store.

Scenario:

Policy 1 contains the role R1, which is assigned to the user U1. The role R1 is associated with a data element DE1, which has the permissions Unprotect, Protect, and Reprotect. The user U1 can unprotect, protect, and reprotect the data using the data element DE1.

Policy 2 contains the role R2, which is assigned to the user U2. The role R2 is associated with a data element DE2. which has the permissions Unprotect, Protect, and Reprotect. The user U2 can unprotect, protect, and reprotect the data using the data element DE2.

Policy P3 contains the role R3, which is applicable to all the users. The role R3 role is associated with two data elements DE1 and DE2. Both the data elements have the Unprotect permissions associated with it.

Note: The ALL USERS denotes a default role which is applicable to all the users. To enable the default role, click the Applicable to all the members toggle button on the ESA web UI. For more information about Applicable to all the members, refer to the section Roles.

Use Case 1

The Use Case 1 table demonstrates that roles R1 and R2 have an indirect relationship with data elements DE1 and DE2. The roles are part of different policies that are deployed to the same data store. As a result, the roles R1 and R2 have inherited the permission of the default role for data elements DE1 and DE2.

Table 1. Use Case 1

The Unprotect permission is highlighted in bold in the Protector side permissions after deploying the policy column. This Unprotect permission indicates that it has been inherited from the role R3, which is applicable to the data elements DE1 and DE2 for all the users.

Use Case 2

The Use Case 2 table demonstrates that if roles R1 and R2 have a direct relationship with data elements DE1 and DE2, then they will not inherit the permissions of the default role.

Table 2. Use Case 2

Use Case 3

The Use Case 3 table demonstrates that if roles R1 and R2 have a direct relationship with data elements DE1 and DE2, then they will not inherit the permissions of the default role.

Table 3. Use Case 3

Use Case 4

The Use Case 4 table demonstrates that as role R2 has an indirect relationship with data element DE1, it has inherited the permissions of the default role. The role R1 has a direct relationship with data element DE1, and it have not inherited the permissions of the default role.

Table 4. Use Case 4

The Unprotect permission is highlighted in bold in the Protector side permissions after deploying the policy column. This Unprotect permission indicates that it has been inherited from the role R3, which is applicable to the data element DE1 for all the users.

Use Case 5

The Use Case 5 table demonstrates that Role R1 has inherited the permissions of the default role for the data element DE2.

Table 5. Use Case 5

The resultant permissions are highlighted in bold in the Protector side permissions after deploying the policy column. These permissions indicate that they have been inherited from the roles R3 and R4, which are applicable to the data element DE2 for all the users.

Use Case 6

The Use Case 6 table demonstrates that role R1 will inherit the permissions of the default role for the data element DE2.

Table 6. Use Case 6

The resultant permissions are highlighted in bold in the Protector side permissions after deploying the policy column. These permissions indicate the permissions that have been inherited from the role R3, which is applicable to the data element DE2 for all the users.

Use Case 7

In Use Case 7 table, role R1 is related to data element DE1 in policy P1 and and role R3 is related to data element DE1 in policy P3. In this case, roles R1 and R3 will not inherit the permissions of the default role.

Table 7. Use Case 7

5 - Deploying Policies

Policies must be deployed to take effect in the system.

There are two stages of deployment: Ready to Deploy and Deployed. The Ready to Deploy stage signals that the Policy configuration is finalized and the Policy can be deployed. The Deployed stage means that this version of the Policy is actively being made available to the Protectors. If you modify a Policy, then you need to repeat the deployment process.

Note that this behavior only applies to modifying Policies via ESA Web UI. If you are modifying a Policy using the Policy Management API, the deployment happens automatically after every change. For more information about the Policy Management API, please refer to the section Using the Policy Management REST APIs.

Marking the Policy as Ready to Deploy

To mark the Policy as Ready to Deployment:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Select the required policy.

   The screen to edit the policy appears.

3. Click Ready to Deploy.

A message confirming the action appears. The Ready to Deploy is inactive and the Deploy is active. The ESA must be up and running to deploy the package to the protectors.

Deploying a Policy

This section describes how to deploy the policy after it has been marked as Ready to Deploy.

To deploy the policy:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Policies.

   The list of all the policies appear.

2. Select the required policy.

   The screen to edit the policy appears.

3. Click Deploy.

A message Policy has been deployed successfully appears.

Note: An error message appears if the deployment of the Policy is not linked to any Data Store.

If you deploy a policy to a data store, which contains additional policies that have already been deployed, then the policy user inherits the permissions from the multiple policies.

For more information about inherting permissions, refer to Inheriting Permissions.

Deploying Data Stores

You can choose to deploy a Policy to a specific Data Store only. That will allow the nodes associated with the Data Store to get the latest Policy. By deploying a Data Store, you deploy the Trusted Applications associated with it.

To deploy a Data Store:

1. On the ESA Web UI, navigate to Policy Management > Data Stores.

   The list of all the data stores appear.

2. Select the data store.

   The screen to edit the data store appears.

3. Click Deploy.

A message **Data Store has been deployed successfully** appears.

When the Protector pulls the package that contains a policy added to the data store, it connects to ESA to retrieve the necessary policy information. The policy information includes members for each role in the policy, token elements, and so on.

Deploying Trusted Applications

During deployment, the Application Protector validates the Trusted Application. If the validation fails, then the Protector generates an audit entry with the detailed information.

Marking a Trusted Application as Ready to Deploy

To mark a Trusted Application as Ready to Deploy:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Trusted Applications.

   The list of all the trusted applications appear.

2. Select the required trusted application.

   The screen to edit the trusted application appears.

3. Click Ready to Deploy.

A message Trusted Application has been marked ready to deploy appears.

The Deploy action is active.

Deploy the Trusted Application

To deploy the trusted application after it has been marked as Ready to Deploy:

1. On the ESA Web UI, navigate to Policy Management > Policies & Trusted Applications > Trusted Applications.

   The list of all the trusted applications appear.

2. Select the required application that is in the ready to deploy state.

   The screen to edit the trusted application appears.

3. Click Deploy. A message Trusted application has been successfully deployed appears.

Note: An error message appears if the deployment of the Trusted Application is not linked to any Data Store.

You can also deploy the trusted application by deploying the data store. In this case, all the policies and trusted applications that are linked to the data store are prepared to be distributed to the protection points.

For more information about deploying a data store, refer to Deploying Data Stores to Protectors.