Policy Management

• 1: Protegrity Data Security Methodology
• 2: Package Deployment in Protectors
• 3: Initializing the Policy Management
• 4: Components of a Policy
• 4.1: Working With Data Elements
• 4.1.1: Example - Creating Token Data Elements
• 4.1.2: Example - Creating a FPE Data Element
• 4.1.3: Example - Creating Data Elements for Unstructured Data
• 4.2: Working With Alphabets
• 4.2.1: Creating an Alphabet
• 4.3: Working With Masks
• 4.3.1: Creating a Mask
• 4.3.2: Masking Support
• 4.4: Working With Trusted Applications
• 4.4.1: Creating a Trusted Application
• 4.4.2: Linking Data Store to a Trusted Application
• 4.4.3: Deploying a Trusted Application
• 4.5: Creating a Data Store
• 4.5.1: Adding Allowed Servers for the Data Store
• 4.5.2: Adding Policies to the Data Store
• 4.5.3: Adding Trusted Applications to the Data Store
• 4.6: Working With Member Sources
• 4.6.1: Configuring Active Directory Member Source
• 4.6.2: Configuring File Member Source
• 4.6.3: Configuring LDAP Member Source
• 4.6.4: Configuring POSIX Member Source
• 4.6.5: Configuring Azure AD Member Source
• 4.6.6: Configuring Database Member Source
• 4.7: Working with Roles
• 4.7.1: Creating a Role
• 4.7.2: Mode Types for a Role
• 4.7.3: Adding Members to a Role
• 4.7.3.1: Filtering Members from AD and LDAP Member Sources
• 4.7.3.2: Filtering Members from Azure AD Member Source
• 4.7.4: Synchronizing, Listing, or Removing Members in a Role
• 4.7.5: Searching User
• 5: Creating and Deploying Policies
• 5.1: Creating Policies
• 5.2: Adding Data Elements to Policy
• 5.3: Adding Roles to Policy
• 5.4: Adding Permissions to Policy
• 5.4.1: Permission Conflicts and Collision Behavior
• 5.4.1.1: Inheriting Permissions for Users in Multiple Policies and Roles
• 5.5: Deploying Policies
• 5.6: Policy Management using the Policy API
• 6: Deploying Data Stores to Protectors
• 7: Managing Policy Components
• 8: Policy Management Dashboard
• 9: Exporting Package for Resilient Protectors
• 10: Legacy Features

1 - Protegrity Data Security Methodology

The data security policy each organization creates within ESA is based on requirements with relevant regulations. A policy helps you to determine, specify and enforce certain data security rules. These data security rules are as shown in the following figure.

Classification

This section discusses about the classification of Policy Management in ESA.

• What do you want to protect?

  The data that is to be protected needs to be classified. This step determines the type of data that the organization considers sensitive. The compliance or security team will choose to meet certain standard compliance requirements with specific law or regulation. For example, the Payment Card Industry Data Security Standard (PCI DSS) or the Health Information Portability and Accessibility Act (HIPAA).

  In ESA, you classify the sensitive data fields by creating ‘Data Elements’ for each field or type of data.

• Why do you need to protect?

  The fundamental goal of all IT security measures is the protection of sensitive data. The improper disclosure of sensitive data can cause serious harm to the reputation and business of the organization. Hence, the protection of sensitive data by avoiding identity theft and protecting privacy is for everyone’s advantage.

Discovery

This section discusses about the discovery of Policy Management in ESA.

• Where is the data located in the enterprise?

  The data protection systems are the locations in the enterprise to focus on as the data security solution is designed. Any data security solution identifies the systems that contains the sensitive data.

  In ESA, you specify locations by creating a Data Store.

• How you want to protect it?

  Data protection has different scenarios which require different forms of protection. For example, tokenization is preferred over encryption for credit card protection. The technology used must be understood to identify a protection method. For example, if a database is involved, Protegrity identifies a Protector to match up with the technology used to achieve protection of sensitive data.

• Who is authorized to view it in the clear?

  In any organization, the access to unprotected sensitive data must be given only to the authorized stakeholders to accomplish their jobs. A policy defines the authorization criteria for each user. The users are defined in the form of members of roles. A level of authorization is associated with each role which assigns data access privileges to all members in the role.

Protection

This section discusses about protection of Policy Management in ESA.

The Protegrity Data Security Platform delivers the protection through a set of Data Protectors. The Protegrity Protectors meet the governance requirements to protect sensitive data in any kind of environment. ESA delivers the centrally managed data security policies as part of a package and the Protectors locally enforce them. It also collects audit logs of all activity in their systems and sends back to ESA for reporting.

Enforcement

This section discusses about enforcement of Policy Management in ESA.

The policy is created to enforce the data protection rules that fulfils the requirements of the security team. It is deployed to all Protegrity Protectors that are protecting sensitive data at protection points.

Monitoring

This section discusses about monitoring audits related to Policy Management in ESA.

As a policy is enforced, the Protegrity Protectors collects audit logs in their systems and reports back to Insight. Audit logs helps you to capture authorized and unauthorized attempts to access sensitive data at all protection points. It also captures logs on all changes made to policies.

2 - Package Deployment in Protectors

This section describes Package Deployment in protectors.

Protegrity enables you to deploy packages to protectors. A package can be a single policy, a standalone entity such as a CoP ruleset, or a combination of a policy and other entities. For example, a package can include the following entities:

• Data Security Policy - Security policies used to protect, unprotect, and reprotect data.

• CoP Ruleset - Instructions used by the Protegrity Data Security Gateway (DSG) to transform data.

  For more information about the CoP Ruleset, refer to Ruleset reference.

The following image illustrates how the Data Security Policy that is defined in the ESA reaches the protectors as part of a package. A Data Security Policy is created and deployed in the ESA either using the ESA Web UI or the DevOps API. When the protector sends a request to the ESA, the ESA creates a package containing the policy. The protector then pulls the package and the related metadata. If a change is made to any of the policies that are part of the package, the protector pulls the updated package from the ESA. There can be multiple scenarios when any change in policy is made.

Important: The deployment scenario explained in this section applies to 10.0.0 protectors and later.

3 - Initializing the Policy Management

When you install and log in to the ESA Web UI for the first time, you must initialize the Policy Management (PIM). This initialization creates the keys-related data and the policy repository. This section describes the steps to initialize the Policy Management (PIM) to load the Policy Management-specific information on the ESA Web UI. When you try to access any of the Policy Management or Key Management screens on the ESA Web UI, a request to initialize the PIM appears.

Prior to the installation of protectors, ensure that you perform the following steps to initialize the Policy Management.

To initialize the Policy Management:

1. On the ESA Web UI, click Policy Management or Key Management.

2. Click any option available in the Policy Management or Key Management area.

   The following screen to initialize PIM appears.

   

3. Click Initialize PIM.

   A confirmation message box appears.

4. Click Ok.

   The policy management information appears in the Policy Management area.

You can also initialize the PIM using the Policy Management REST API.

4 - Components of a Policy

A policy contains multiple components that work together to enforce protection at the protection endpoints. The role component and policy is tied closely. Any changes made to the organization LDAP, such as a user linked to a role is added or deleted, result in an update to the policy. The automatic deployment of policy is only applicable for automatic roles. When a policy is deployed in ESA, the protectors sends a request to the ESA for retrieving the updated policy. The ESA creates a package containing the updated policy and the protector pulls the package and the related metadata. So, when a change in package is detected due to one of the following reasons, the protector pulls the package:

• Security Role changes.
• Rotation of keys. This is only applicable when either the Signing Key or the Data Element Key for an encryption data element with Key ID is rotated.
• Changes in permissions.
• Addition or deletion of data elements.
• Updating of the individual components of a package, such as, the data security policy or the CoP.

You can also create a resilient package that is immutable or static by exporting the package using the RPS API. For more information about the RPS API, refer to section APIs for Resilient Protectors in the Protegrity APIs, UDFs, Commands Reference Guide.

4.1 - Working With Data Elements

Data elements consist of a set of data protection properties to protect sensitive data. This set consists of different token types, encryption algorithms, and encryption options. The most important of these properties are the methods that you use to protect sensitive data.

For more information about the protection methods, refer to Protection Methods Reference Guide from the Legacy Documents section.

You can create data elements for the following data types:

• Structured Data: Structured Data provides the properties that support column-level database protection, and capabilities to integrate policies into applications, with an API. The Structured Data can also be used by the COP Ruleset to transform the data.

• Unstructured Data: Unstructured Data provides the properties supporting file protection. The file protection capabilities enable the protection of sensitive data as it traverses the enterprise or as it rests within files.

  Important: 10.0.0 Protectors do not support policies with Unstructured data elements.

The following figure shows the New Data Element screen.

The following table provides the description for each data element available on the of the ESA Web UI.

4.1.1 - Example - Creating Token Data Elements

This example shows how to create numeric tokenization data element that is used to tokenize numerical data.

To create a structured data element:

1. On the ESA Web UI, navigate to Policy Management > Data Elements & Masks > Data Elements.

2. Click Add New Data Element.

   The New Data Element screen appears.

3. Select Structured from Type.

4. Type a unique name for the data element in the Name textbox.

   The maximum length of the data element name is 55 characters.

5. Type the description for the data element in the Description textbox.

6. Select the protection method from the Method drop-down. In this example, select Tokenization.

7. Select the tokenization data type from the Data Type drop down. In this example, select Numeric (0-9).

   For more information about the different data types, refer to the Protection Methods Reference Guide.

8. Select the tokenizer from the Tokenizer drop-down.

   For more information about the different token elements, refer to the Protection Methods Reference Guide.

9. If the Tokenizer should leave characters in clear, then set the number of characters from left and from right in the From Left and From Right text boxes.

   For more information on the maximum and minimum input values for these fields, refer to the section Minimum and Maximum Input Length in the Protection Methods Reference Guide.

10. If the token length needs to be equal to the provided input, then select the Preserve length check box.

11. If you select the Preserve length option, then you can also choose the behavior for short data tokenization in the Allow Short Data drop-down.

    If you require short data tokenization with existing data that was previously not protected using short data enabled data element, then you must do the following:

    1. Unprotect the existing data with the old data element.
    2. Create a new data element that is enabled with short data.
    3. Reprotect the unprotected data with the new short data enabled data element. For more information about length preservation and short data tokenization, refer to section Length Preserving and Short Data Tokenization in Protection Methods Reference Guide.

12. Click Save.

A message Data Element has been saved successfully appears.

4.1.2 - Example - Creating a FPE Data Element

This example shows how to create an FPE data element that is used to encrypt Plaintext Alphabet data.

To create a structured FPE data element:

1. On the ESA Web UI, navigate to Policy Management > Data Elements & Masks > Data Elements.

2. Click Add New Data Element.

   The New Data Element screen appears.

3. Select Structured from Type.

4. Enter a unique name for the data element in the Name textbox.

The maximum length of the data element name is 55 characters.

5. Type the description for the data element in the Description textbox.

6. Select FPE NIST 800-38G from the Method drop-down.

7. Select a data type from the Plaintext Alphabet drop-down.

8. Configure the minimum input length from the Minimum Input Length text box.

9. Select the tweak input mode from the Tweak Input Mode drop-down.

   For more information about the tweak input mode, refer to the section Tweak Input in the Protection Methods Reference Guide.

10. Select the short data configuration from the Allow Short Data drop-down.

    Note: FPE does not support data less than 2 bytes, but you can set the minimum message length value accordingly.

    For more information about length preservation and short tokens, refer to section Length Preserving in Protection Methods Reference Guide from the Legacy Documents section.

    If you are create a short data token in a policy and then deploy the policy, the Forensics displays a policy deployment warning indicating that the data element has unsupported settings.

11. Enter the required input characters to be retained in the clear in the From Left and From Right text box.

    For more information about this setting, refer to the section Left and Right Settings in the Protection Methods Reference Guide from the Legacy Documents section.

12. Configure any special numeric data handling request, such as Credit Card Number (CCN), in the Special numeric alphabet handling drop-down.

    For more information about handling special numeric data, refer to the section Handling Special Numeric Data in the Protection Methods Reference Guide from the Legacy Documents section.

13. Click Save.

A message Data Element has been created successfully appears.

4.1.3 - Example - Creating Data Elements for Unstructured Data

This example shows how to create an AES-256 data element that is used to encrypt a file.

To create an unstructured data element:

1. On the ESA Web UI, navigate to Policy Management > Data Elements & Masks > Data Elements.

2. Click Add New Data Element.

   The New Data Element screen appears.

3. Select Unstructured from Type.

4. Type a unique name for the data element in the Name textbox.

Note: Ensure that the length of the data element name does not exceed 55 characters.

5. Type the required description for the data element in the Description textbox.

6. Select AES-256 from the Method drop-down list.

7. If you want to enable multiple instances of keys with the data element, then check the Use Key ID (KID) checkbox.

8. Click Save.

A message Data Element has been saved successfully appears.

4.2 - Working With Alphabets

The Unicode Gen2 token type gives you the liberty to customize what Unicode data to protect and how the protected token value is returned. It allows you to leverage existing internal alphabets or create custom alphabets by defining Unicode code points. This flexibility allows you to create token values in the same Unicode character set as the input data.

For more information about the code points and considerations around creating alphabets, refer to the section Code Points in Unicode Gen2 Token Type in the Protegrity Protection Methods and Reference Guide.

The following figure shows the Alphabet screen.

4.2.1 - Creating an Alphabet

An alphabet can include multiple alphabet templates, for example, an alphabet can be created to generate a token value, which is a mix of Numeric and Cyrillic characters.

To create an alphabet:

1. On the ESA Web UI, navigate to Policy Management > Data Elements & Masks > Alphabets.

2. Click Add New Alphabet.

   The New Alphabet screen appears.

3. Enter a unique name for the alphabet in the Name text box.

4. Under the Alphabet tab, click Add to add existing alphabets or custom code points to the new alphabet.

   The Add Alphabet entry screen appears.

   If you plan to use multiple alphabet entries to create a token alphabet, then click Add again to add other alphabet entries.

   Ensure that code points in the alphabet are supported by the protectors using this alphabet.

   

5. Select an existing alphabet, a custom code point, or a range of custom code points.

   The following options are available for creating an alphabet.

   Important: For the SLT_1_3 tokenizer, you must include a minimum of 10 code points and a maximum of 160 code points.

   Important: For the SLT_X_1 tokenizer, you must include a minimum of 161 code points and a maximum of 100k code points.

   Alphabet option	Description
   Existing Alphabets	Select one of the existing alphabets. The list includes internal and custom alphabets.
   Custom code point in hex (0020-3FFFF)	Add custom code points that will be used to generate the token value.
   Custom code point range in hex (0020-3FFFF)	Add a range of code points that will be used to generate the token value. Note: When creating an alphabet using the code point range option, note that the code points are not validated. For more information about consideration related to defining code point ranges, refer to the section Code Point Range in Unicode Gen2 Token Type in the Protegrity Protection Methods and Reference Guide.

6. Click Add to add the alphabet entry to the alphabet.

7. Click Save to save the alphabet.

   Important: Only the alphabet characters that are supported by the OS fonts are rendered properly on the Web UI.

A message Alphabet has been created successfully appears.

4.3 - Working With Masks

Masks are a pattern of symbols and characters, that when imposed on a data field obscures its actual value to the viewer of that data. For example, you might want to mask out characters from credit cards and Social Security numbers. Masks can obscure data completely or partially. For example, a partial mask might display the last four digits of a credit card on a grocery store receipt.

For more information about the Masks option, refer to the section Masks in the Protegrity Protection Methods and Reference Guide.

The following figure shows the New Mask screen.

The following table provides the description for each element available on the Web UI.

The following table shows the different mask mode templates.

4.3.1 - Creating a Mask

To create a mask:

1. On the ESA Web UI, navigate to Policy Management > Data Elements & Masks > Masks.

2. Click Add New Mask.

   The New Mask screen appears.

3. Enter a unique name for the mask in the Name text box.

4. Enter the description for the mask in the Description textbox.

5. Select CCN 6X4 from the Mask Template drop-down.

6. Select Clear from Mask Mode.

7. Select the masking character from the Character drop-down.

8. Click Save.

A message Mask has been saved successfully appears.

4.3.2 - Masking Support

4.4 - Working With Trusted Applications

The Trusted Applications (TA) is an entity that defines which system users and applications are authorized to run the Application Protector to protect data.

Trusted Application does not support the capability of adding multiple users and applications in a single Trusted Application instance. In a Trusted Application, you can add only one application and its corresponding system user. If you want to add multiple users and applications, then you must create Trusted Application for each application and its corresponding system user.

4.4.1 - Creating a Trusted Application

To make an application trusted:

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

2. Click Add New Trusted Application.

   The New Trusted Application screen appears.

   

3. Type a unique name to the trusted application in the Name textbox.

4. Type the required description to the trusted application in the Description textbox.

5. Type the name of the application in the Application Name textbox.

   The maximum length of an Application Name is up to 64 characters.

   Important: In case of AP Java and AP Go applications, ensure that you specify the complete module or package name.

   In the application name, you can type the asterisk (*) wild card character to represent multiple characters or the question mark (?) wild card character to represent a single character. You can also use multiple wild card characters in the application name.

   For example, if you specify Test_App* as the application name, then you can use applications with names, such as, Test_App1 or Test_App123 to perform security operations.

   Caution: Use wild card characters with discretion, as they can potentially lead to security threats.

6. Type the name of the application user in the Application User textbox.

   In the application user name, you can type the asterisk (*) wild card character to represent multiple characters or the question mark (?) character to represent a single character. You can also use multiple wild card characters in the application user name.

   For example, if you specify User* as the application user name, then you can have users with names, such as, User1 or User123 to perform security operations.

   Caution: Use wild card characters with discretion, as they can potentially lead to security threats.

7. Click Save.

A message Trusted Application has been created successfully appears.

4.4.2 - Linking Data Store to a Trusted Application

To link a trusted application to a data store:

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. Under the Data Stores tab, click Add.

   The screen to add the data stores appears.

4. Select the required data stores.

5. Click Add.

A message Select Data Stores have been added to Trusted Application successfully appears.

4.4.3 - Deploying a Trusted Application

Deploying a trusted application consists of the following two states:

• Making the Trusted Application ready for development
• Deploying the Trusted Application

Making the Trusted Application ready for deployment

The following procedure describes the steps to make a trusted application ready for deployment.

After you link data stores to your trusted application, it is ready to be deployed to the protector nodes.

To make a trusted application ready for deployment:

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.

Deploying the Trusted Application

The following procedure describes the steps to deploy the trusted application.

You deploy the policy to the data store after the trusted application is ready for deployment. If no data stores are linked with the trusted application, then the deployment of the trusted application fails.

To deploy the trusted application:

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.

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

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.

4.5 - Creating a Data Store

You create data stores to specify the protectors in your enterprise to which you want to deploy policies and trusted applications. The protectors are identified by their IP address which must be unique across the enterprise. Using the data store, you can define the list of protector nodes that can pull the packages. A data store consists of information on policies and trusted applications. You can create a default data store that deploys polices to the protectors that are not a part of the allowed servers list of any data store. Thus, when a new protector is added that is not a part of any data store, the protector inherits the policy information pertaining to the default data store.

You cannot create data stores with the same names in the data store name. You can create only one default data store for a single instance of ESA.

To create a data store:

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

   The list of all the data stores appear.

2. Click Add New Data Store.

   The New Data Store screen appears.

3. Enter a unique name identifying the data store in the Name textbox.

   The maximum length of the data store name is 55 characters.

4. Enter the description describing the data store in the Description textbox.

5. Click the Select as Default Data Store option.

   If a default data store already exists and you are updating another data store as the default data store, then the following message appears.

   A default Data Store already exists, Please confirm to make this the new default Data Store.

6. Click Ok.

7. Click Save.

A message Data Store has been created successfully appears.

The following tabs are visible after the data store has been saved, as per the type of data store:

• The Policies and Trusted Applications tabs are visible in case of a default data store.
• The Allowed Servers, Policies, and Trusted Applications tabs are visible in case of a non-default data store.

You can also create a Data Store using the Policy Management REST API.

4.5.1 - Adding Allowed Servers for the Data Store

Specifying Allowed Servers for the Data Store

This section describes the steps to specify allowed servers for a data store.

To specify allowed servers for a data store:

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

   The list of all the data stores appear.

2. From the Allowed Servers tab for the data store, click Add.

   The Add Allowed Servers screen appears.

3. If you want to add a single server, then select Single Server and specify the server IP address.

4. If you want to add a range of servers, then Multiple Servers. Enter the range in the From and To text boxes.

5. Click Add.

The servers are added to the list

4.5.2 - Adding Policies to the Data Store

To add policy to 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 the Policies tab.

4. Click Add.

   The list of policies created appear.

5. Select the policies.

6. Click Add.

A message Selected Polices have been added to the Data Store successfully appears.

For more information on creating policies, refer to section Creating and Deploying Policies.

4.5.3 - Adding Trusted Applications to the Data Store

To add trusted application to 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 the Trusted Applications tab.

4. Click Add.

   The list of trusted applications created appear.

5. Select the trusted applications.

6. Click Add.

A message Selected Trusted Applications have been added to the Data Store successfully appears.

4.6 - Working With Member Sources

The users can come from the following types of sources:

• User directory, such as:
  • LDAP
  • Posix LDAP
  • Active Directory
  • Azure AD
• Database
  • Teradata
  • Oracle
  • SQL Server
  • DB2
  • PostgreSQL
• File

Using these source types, you configure the connection to a directory to retrieve information on the users and the user groups available.

When you configure the connection to any member source, you can verify the following values:

• The connection parameters that you have specified are correct.
• The users and groups can be retrieved from the member source. Click Test adjacent to the member source entry from the list or from the respective member source screen. The Test Member Source Connection dialog box displays the status with the following parameters:
• connection
• authentication
• groups
• users

Note: The password length of a member source on some platforms may have a limitation.

4.6.1 - Configuring Active Directory Member Source

To create an Active Directory member source:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Member Sources.

2. Click Add New Member Source.

   The New Member Source screen appears.

3. Enter a unique name of the file member source in the Name textbox.

4. Type the description in the Description textbox.

5. Select Active Directory from the Source Type drop-down list.

   The Active Directory Member Source screen appears.

   

6. Enter the information in the directory fields.

   The following table describes the directory fields for Active Directory member sources.

   Field Name	Description
   Host	The Fully Qualified Domain Name (FQDN), or IP of the directory server.
   Port	The network port on the directory server where the service is listening.
   TLS Options	- The Use TLS option can be enabled to create secure communication to the directory server. - The Use LDAPS option can be enabled to create secure communication to the directory server. LDAPS uses TLS/SSL as a transmission protocol. Note: Selection of the LDAPS option is dependent on selecting the TLS option. If the TLS option is not selected, then the LDAPS option is not available for selection.
   Recursive Search	The recursive search can be enabled to search the user groups in the active directory recursively. For example, consider a user group U1 with members User1, User2, and Group1, and Group1 with members User3 and User4. If you list the group members in user group U1 with recursive search enabled, then the search result displays User1, User2, User3, and User4.
   Base DN	The base distinguished name where users can be found in the directory.
   Username	The username of the Active Directory server.
   Password/Secret	The password of the user binding to the directory server.

7. Click Save.

A message Member Source has been created successfully appears.

4.6.2 - Configuring File Member Source

In Policy Management, the exampleusers.txt and examplegroups.txt are sample member source files that contain a list of users or groups respectively. These files are available on the ESA Web UI. You can edit them to add multiple user name or user groups. You can also create a File Member source by adding a custom file.

The examplegroups.txt has the following format.

[Examplegroups]
<groupusername1>
<groupusername2>
<groupusername3>

Note: Ensure that the file has read permission set for Others.

Important: The exampleusers.txt or examplegroups.txt files do not support the Unicode characters, which are characters with the \U prefix.

Viewing the List of Users and Groups in the Sample Files

This sections describes the steps to view the list of users and groups in the sample files.

To view list of users and groups in the sample files:

1. On the ESA Web UI, navigate to Settings > Systems > Files.

2. Click View, corresponding to exampleusers.txt or examplegroups.txt under Policy Management-Member Source Service User Files and Policy Management-Member Source Service Group Files respectively.

The list of users in the exampleuser.txt file or examplegroups.txt file appear.

Creating File Member Source

This section describes the procedure on how to create a file member source.

To create file member source:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Member Sources.

2. Click Add New Member Source.

   The New Member Source screen appears.

3. Enter a unique name of the file member source in the Name textbox.

4. Type the description in the Description textbox.

5. Select File from the Source Type drop-down list.

6. Select Upload file from the User File drop-down list.

7. Click the Browse.. icon to open the file browser.

8. Select the user file.

9. Click Upload File icon.

   A message User File has been uploaded successfully appears.

10. Select Upload file from the Group File drop-down list.

11. Click the Browse.. icon to open the file browser.

12. Select the group file.

13. Click Upload File icon.

    A message Group File has been uploaded successfully appears.

14. Click Save.

A message Member Source has been created successfully appears.

4.6.3 - Configuring LDAP Member Source

To create an LDAP member source:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Member Sources.

2. Click Add New Member Source.

   The New Member Source screen appears.

3. Enter a unique name of the file member source in the Name textbox.

4. Type the description in the Description textbox.

5. Select LDAP from the Source Type drop-down list.

   The LDAP Member Source screen appears

   

6. Enter the information in the LDAP member source fields.

   The following table describes the directory fields for LDAP member sources.

   Field Name	Description
   Host	The Fully Qualified Domain Name (FQDN), or IP of the directory server.
   Port	The network port on the directory server where the service is listening.
   Use TLS	The TLS is enabled to create a secure communication to the directory server. LDAPS, which is deprecated, is no longer the supported protocol. TLS is the only supported protocol.
   User Base DN	The base distinguished name where users can be found in the directory. The user Base DN is used as the user search criterion in the directory.
   Group Base DN	The base distinguished name where groups can be found in the directory. The group base dn is used as a group search criterion in the directory.
   User Attribute	The Relative Distinguished Name (RDN) attribute of the user distinguished name.
   Group Attribute	The RDN attribute of the group distinguished name.
   User Object Class	The object class of entries where user objects are stored. Results from a directory search of users are filtered using user object class.
   Group Object Class	The object class of entries where group objects are stored. Results from a directory search of groups are filtered using group object class.
   User Login Attribute	The attribute intended for authentication or login.
   Group Members Attribute	The attribute that enumerates members of the group.
   Group Member is DN	The members may be listed using their fully qualified name, for example, their distinguished name or as in the case with the Posix user attribute (cn) value.
   Timeout	The timeout value when waiting for a response from the directory server.
   Bind DN	The DN of a user that has read access, rights to query the directory.
   Password/Secret	The password of the user binding to the directory server

   Parsing users from a DN instead of querying the LDAP server: By default, a user is not resolved by querying the external LDAP server. Instead, the user is resolved by parsing the User Login Attribute from the Distinguished Name that has been initially retrieved by the Member Source Service. This option is applicable only if the Group Member is DN option is enabled while configuring the Member Source. In this case, the members must be listed using their fully qualified name, such as their Distinguished Name. If the ESA is unable to parse the DN or the DN is not available in the specified format, the user is resolved by querying the external LDAP server.

7. Click Save.

A message Member Source has been created successfully appears.

4.6.4 - Configuring POSIX Member Source

You can retrieve users and user groups from any external LDAP and Posix LDAP. The internal LDAP available on ESA, uses the Posix schema. Thus, when using ESA, it is recommended to use Posix LDAP to configure the connection with the internal ESA LDAP.

To create a Posix LDAP member source:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Member Sources.

2. Click Add New Member Source.

   The New Member Source screen appears.

3. Enter a unique name of the file member source in the Name textbox.

4. Type the description in the Description textbox.

5. Select Posix LDAP from the Source Type drop-down list.

   The Posix LDAP Member Source screen appears.

   

6. Enter the information in the directory fields.

   The following table describes the directory fields for Posix LDAP member source.

   Field Name	Description
   Host	The Fully Qualified Domain Name (FQDN), or IP of the directory server.
   Port	The network port on the directory server where the service is listening.
   Use TLS	The TLS can be enabled to create a secure communication to the directory server.
   Base DN	The base distinguished name where users can be found in the directory.
   Username	The username of the Posix LDAP server.
   Password/Secret	The password of the user binding to the directory server.

7. Click Save.

A message Member Source has been created successfully appears.

4.6.5 - Configuring Azure AD Member Source

To create an Azure AD member source:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Sources > Member Sources.

2. Click Add New Member Source.

   The New Member Source screen appears.

3. Enter a unique name of the Azure AD member source in the Name textbox.

4. Type the description in the Description textbox.

5. Select Azure AD from the Source Type drop-down list.

   The Azure AD Member Source screen appears.

   

6. Enter the information in the directory fields.

   The following table describes the directory fields for the Azure Active Directory member sources.

   Field Name	Description
   Recursive Search	The recursive search can be enabled to search the user groups in the Azure AD recursively.
   Tenant ID	The unique identifier of the Azure AD instance
   Client ID	The unique identifier of an application created in Azure AD
   User Attribute	The Relative Distinguished Name (RDN) attribute of the user distinguished name. The following user attributes are available: - displayName - The name displayed in the address book for the user. - userPrincipalName - The user principal name (UPN) of the user. - givenName - The given name (first name) of the user. - employeeId - The employee identifier assigned to the user by the organization. - id - The unique identifier for the user. - mail - The SMTP address for the user. - onPremisesDistinguishedName - Contains the on-premises Active Directory distinguished name (DN). - onPremisesDomainName - Contains the on-premises domainFQDN, also called dnsDomainName, synchronized from the on-premises directory. - onPremisesSamAccountName - Contains the on-premises samAccountName synchronized from the on-premises directory. - onPremisesSecurityIdentifier - Contains the on-premises security identifier (SID) for the user that was synchronized from the on-premises setup to the cloud. -onPremisesUserPrincipalName - Contains the on-premises userPrincipalName synchronized from the on-premises directory. - securityIdentifier - Security identifier (SID) of the user, used in Windows scenarios.
   Group Attribute	The RDN attribute of the group distinguished name. The following group attributes are available: - displayName - The display name for the group. - id - The unique identifier for the group. - mail - The SMTP address for the group. - onPremisesSamAccountName - Contains the on-premises SAM account name synchronized from the on-premises directory. - onPremisesSecurityIdentifier - Contains the on-premises security identifier (SID) for the group that was synchronized from the on-premises setup to the cloud. - securityIdentifier - Security identifier of the group, used in Windows scenarios.
   Group Members Attribute	The attribute that enumerates members of the group. Note: Ensure to select the same Group Members Attribute as the User Attribute. The following group members attributes are available: - displayName - The name displayed in the address book for the user. - userPrincipalName - The user principal name (UPN) of the user. - givenName - The given name (first name) of the user. - employeeId - The employee identifier assigned to the user by the organization. - id - The unique identifier for the user. - mail - The SMTP address for the user. - onPremisesDistinguishedName - Contains the on-premises Active Directory distinguished name (DN). - onPremisesDomainName - Contains the on-premises domainFQDN, also called dnsDomainName, synchronized from the on-premises directory. - onPremisesSamAccountName - Contains the on-premises samAccountName synchronized from the on-premises directory. - onPremisesSecurityIdentifier - Contains the on-premises security identifier (SID) for the user that was synchronized from the on-premises setup to the cloud. - onPremisesUserPrincipalName - Contains the on-premises userPrincipalName synchronized from the on-premises directory. - securityIdentifier - Security identifier (SID) of the user, used in Windows scenarios.
   Password/Secret	The client secret is the password/secret of the Azure AD application.

7. Click Save.

A message Member Source has been created successfully appears.

4.6.6 - Configuring Database Member Source

You use the Database type to obtain users from database, such as, SQL Server, Teradata, DB2, PostgreSQL, or Oracle. An ODBC connection to the database must be setup to retrieve user information.

The following table describes the connection variable settings for the databases supported in Policy Management.

Creating Database Member Source

This section describes the procedure on how to create a database member source.

To create a Database Member Source:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Member Sources.

2. Click Add New Member Source.

   The New Member Source screen appears.

3. Enter a unique name for the file member source in the Name text box.

4. Type the description in the Description text box.

5. Select Database from the Source Type drop-down list.

6. Select one of the following database from the Source drop-down list.

   • Teradata
   • Oracle
   • SQL Server
   • DB2
   • PostgreSQL

7. To enable the usage of a custom data source name, switch the Use Custom DSN toggle.

   1. Enter the custom data source name in the DSN text box.
   2. Ensure that the specified DSN is present in the odbc.ini configuration file located in the /opt/protegrity/mbs/conf/ directory.

8. If you are selecting the Oracle database as the source database, then enter the service name in the Service Name text box.

   Note: This step is applicable for the Oracle database only.

9. If you are not using Custom DSN, then the following steps are applicable.

   1. Enter the database name in the Database text box.

   2. Enter the host name in the Host text box.

   3. Enter the port to connect to the database in the Port text box.

10. Enter the username in the Username text box.

11. Enter the password in the Password text box.

12. Click Save.

The message Member Source has been created successfully appears.

4.7 - Working with Roles

The authorization criteria for each user is defined in form of members of roles. Roles determine and define the unique data access privileges for each member. Each role is associated with a level of authorization granted to all its members, including specific data access privileges.

The following figure shows the New Role screen.

The following table provides the description for each element available on the of the Web UI.

4.7.1 - Creating a Role

To create a role:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Roles.

2. Click Add New Role.

   The New Role screen appears.

3. Enter a unique name for the role in the Name textbox.

   Note: Ensure that the length of the role name does not exceed 55 characters.

4. Enter the required description for the role in the Description textbox.

5. In the Mode drop-down, select a refresh mode.

   For more information about about mode types for a role, refer to section Mode Types for a Role.

6. If you want to apply this role to all members in all the member sources, click Applicable to all members. If enabled, the role is applied to all members in users or groups that do not belong to any other role.

7. Click Save.

4.7.2 - Mode Types for a Role

The modes that are available are Automatic, Semi-automatic, and Manual.

The synchronization of members can be described as follows:

• Synchronization between Hub Controller and Member Source: The Member Source component is responsible for synchronization of the latest changes made in the external sources, such as LDAP, AD, file, or database. In the ESA, the HubController synchronizes with the Member Source to update the policy with any changes detected in roles once in an hour.

Automatic Mode

In automatic mode, groups from the member sources are synchronized periodically without user intervention. The synchronization happens every one hour. The updated policy is deployed automatically after the synchronization.

Semi-Automatic Mode

Semi-Automatic mode is similar to the automatic mode with the exception that you must synchronize the groups manually. The updated policy is deployed automatically after the manual synchronization.

For a new member added to a group, you can manually synchronize the changes by setting the mode to semi-automatic. Then, you can use the Synchronize Members button from the Members tab of a Role screen.

Manual Mode

The roles with mode type as Manual can accept both groups and users. You must manually synchronize the groups. After manual synchronization of members, you must set the policy as Ready to Deploy followed by deploying the policy manually.

For a new member added to a group, you can manually synchronize the changes by clicking the Synchronize Members button from the Members tab of a Role screen.

Note: If a user having the same name but with different letter case appears in multiple roles within a policy, then it can cause permission issues when the policy is deployed. This can happen if the user has different permissions in each role.
To avoid this issue, when the members are automatically synchronized, and users having the same name but different letter case appear in roles, an error is generated. This error appears in the Notifications section of the ESA dashboard to inform you that such conflicting users have been found. The error specifies the correlation ID of the HubController audit log that has been generated. To identify the conflicting users, navigate to the Discover page in the Audit Store Dashboards and search for the specified correlation ID.

4.7.3 - Adding Members to a Role

This section describes the steps to add members to a role.

To add members to a role:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Roles.

2. Click on the role name link to which you want to add members.

   The selected role screen appears.

3. In the Members tab, click Add.

   The Add Members screen appears.

   

4. In the Choose Member Source drop-down, select the Member Source.

5. In the Display Member Type drop-down, select the member type.

   For Automatic or Semi-Automatic mode, it causes the removal of members of type Users from the role. The Display Member Type drop-down is disabled in this case with default Group member type.

6. Enter the filter parameter in the Filter Members text box.

   It accepts characters such as ‘*’ to display all results or word search to search with a word.

   For more information about filtering members from AD and LDAP member sources, refer to the sections Filtering Members from AD and LDAP Member Sources and Filtering Members from Azure AD Member Source.

7. Select the number of display results in the Display Number of Results spin box.

8. Click Next.

   The step 2 of Add Members dialog box appears.

   

   Note: The ID column displays the unique identifier for the Azure AD, Posix LDAP and Active Directory member sources.

9. Select the check box next to each member you want to add.

10. Click Add.

    The selected members are added to the role.

    

    Note: The ID column displays the unique identifier for the Azure AD, Posix LDAP and Active Directory member sources.

11. Click Save to save the role.

    In addition to the Members tab, you can find:

    • Policies: It displays all the policies that are linked to this role.
    • Data Stores: It displays all the data stores that are linked to this role.

4.7.3.1 - Filtering Members from AD and LDAP Member Sources

The following table lists some examples using different AD and LDAP search criteria to filter the members.

If the input in the search filter includes special characters, then you must use the escape sequence in place of the special character to make it a valid input in the search filters.

The following table lists the escape sequence for each of the special characters.

The following table lists some examples of search filters with the usage of escape sequences to include special characters in the search input.

4.7.3.2 - Filtering Members from Azure AD Member Source

The following table lists an example for the Azure AD search criteria to filter the members.

4.7.4 - Synchronizing, Listing, or Removing Members in a Role

The following figure explains the steps to synchronize, list or remove members in a role.

Note: The ID column displays the unique identifier for the Azure AD, Posix LDAP and Active Directory member sources.

The following table provides the description for each element available on the of the Web UI.

Callout	Task Name	Steps
1	Synchronize Members	1. Select the role you want to update by clicking on it in the ESA Web UI, under Policy Management > Roles & Member Sources > Roles. 2. Click the Synchronize Members icon. A status message appears.
2	List Group Members	1. Select the role you want to update by clicking on it in the ESA Web UI, under Policy Management > Roles & Member Sources > Roles. 2. Click the List Group Members . The dialog box appears with the list of all members in the group.
3	Remove Members	1. Select the role you want to update by clicking on it in the ESA Web UI, under Policy Management > Roles & Member Sources > Roles. 2. Click Remove. A confirmation dialog box appears. 3. Click Ok.

4.7.5 - Searching User

The Search Member screen from the Roles & Member Sources screen provides a way to search the users with the associated roles. It also provides additional details like user added time, role and member source to which it belongs to.

For example, if you want to check the role of a user with its member source, then the search results can provide you a way to troubleshoot or check the user-role mapping.

To search a member:

1. On the ESA Web UI, navigate to Policy Management > Roles & Member Source > Search Member.

2. Enter the search criteria in the Member Name textbox.

   For more on valid search criteria, refer to Search Criteria.

   

3. Click Search .

The search results appear.

Search Criteria

Consider the following scenario:

1. You have created a file member source named MemberSource1 which includes:
   • Group File named examplegroups with users examplegroupuser1 and examplegroupuser2
   • User File named exampleusers with users exampleuser1 and exampleuser2
2. You have created a role named Role1.
3. You have added all users from MemberSource1 to Role1.

For the given example, the following table lists the search results with different search criteria.

Table: Search Criteria

Search Criteria	Description	Output
Wild card	Search with ‘*’	It displays all the members.
Character search	Character search Search with ‘1’	It displays examplegroupuser1 and exampleuser1.
Word search	Search with ‘group’	It displays examplegroupuser1 and examplegroupuser2.

You can perform additional actions on the search results such as:

• Clicking on the Role or Source column values redirects you to the Roles or Member Sources page respectively.
• Members can be sorted based on Name, Added Time, Role or Source columns.
• Search results also can be filtered with another search option, which is provided in the search results.

5 - Creating and Deploying Policies

The following figure displays a sample policy.

You can add data elements, roles, link the policy to a data store, and deploy the policy to the protector nodes. You also set different permissions for the content restrictions for a policy.

You can create two types of policies:

• Structured Policy - Policy that supports column-level database protection and integrates policies into applications using an API. This policy type contains only structured data elements.
• Unstructured Policy - Policy that provides support for file protection. This policy type contains only unstructured data elements. It is only supported for File Protectors. The unstructured policy is not applicable for 10.0.0 protectors.

A policy is in one of the following states:

• Ready to Deploy – The policy is created with the required information and ready for deployment.
• Deployed – The policy is ready to be distributed to the protectors.

You can modify a policy at any point in time. If a policy that is deployed is modified, then the policy returns to the Ready to Deploy state.

The Deploy Status is only applicable for 9.x.x.x protectors and earlier. It is not applicable for 10.0.0 protectors and later.

For 10.0.0 protectors and later, you can access this information from the Protegrity Dashboard.

The Policy Management Web UI is primarily used to create policies and related metadata.

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

   Note: 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 Adding Permissions to Policy.

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

   For more information about adding data elements, refer to Working with Data Elements.

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

   For more information about adding roles, refer to Working with Roles.

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

   For more information about adding data stores, refer to Working with 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 Adding Permissions to Policy.

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

   For more information about adding data elements, refer to Working with Data Elements.

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

   For more information about adding roles, refer to Working with Roles.

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

   For more information about adding data stores, refer to Working with Data Stores.

10. Click Save.

A message Policy has been created successfully appears.

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

5.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 the 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.

5.4 - Adding Permissions to Policy

Using the policy permissions, the system can determine what is returned to a user who wants to view protected data. If the user has the appropriate permissions, then the data gets decrypted or detokenized. If permission is denied, then a NULL value is returned by default. Depending on your data element and policy settings, the system can instead return a no-access value (such as Exception or Protected value). The permissions are always defined in the context of a roles and a data element.

You can set a no-access value, such as Exception or Protected value, through editing the permission settings for a role or a data element.

For more information about editing the permission settings of a role or data element, refer to the Customizing Permissions for Data Element in a Policy or Customizing Permissions for Role in a Policy.

The following table describes the different permissions that you can set for structured data.

The following table describes the permissions that you can set for an unstructured data. These permissions are only applicable for File Protector.

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

Setting Default Permissions for a Policy

This section describes the steps to set the default permissions for a policy.

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.

   The following screen appears.

   

4. Select the required permissions.

   For more information about the permissions, refer to the tables Permissions for Structured Data and Permissions for Unstructured Data.

5. Click Save.

The permissions are set for the policy.

Customizing Permissions for Data Elements in a Policy

You can edit the permissions for an individual data element. When you edit the permissions for a data element, then you change the permissions for the roles associated with the data element.

To customize permissions for data element in 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 Data Elements tab.

4. Click Edit Permissions.

   The screen to update the permissions for the role appears.

5. Select the required permissions.

   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.

Customizing Permissions for Roles in a Policy

You can edit the permissions for individual roles. When you edit the permissions for a role, then you change the permissions for the data elements associated with the role.

To customize permissions for role in 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 policy.

   The screen to edit the policy appears.

3. Click the Roles tab.

4. Click Edit Permissions.

   The screen to update the permissions for the role appears.

5. Select the 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.

5.4.1 - Permission Conflicts and Collision Behavior

Masking Rules for Users in Multiple Roles

If the mask settings, which are applied along with the permission settings, for users in multiple roles result in a conflict, then the resultant output differs.

Consider a scenario, where user U1 with a policy P1, associated with roles R1, R2, and R3 and connected with the data element DE1 containing different masks (Left, Right) and output formats, then the resultant output is applicable as per the following table.

A data element-role connection with disabled permission for unprotect operation results in a NULL value, by default, and can be set to other no-access values, such as Exception or Protected value.

The following table explains how no-access values work with different output formats for users in multiple roles.

No Access Permissions

If the Unprotect access permission is not assigned to a user, then either the NULL value or noaccess permission, such as, Protected or Exception value is returned. The returned value is based on the permission settings for a role or a data element. If a user is assigned to multiple roles with different permission settings for the data element, then the following no-access permission on the protector is applicable.

5.4.1.1 - Inheriting Permissions for Users in Multiple Policies and Roles

If 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 the 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.

Example:

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 Working with 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 that is they are part of different policies but they are deployed to the same data store, they have inherited the permission of the default role for data elements DE1 and DE2.

Table 1. Use Case 1

As shown in the table, in the case of old behaviour, no permissions have been inherited from the role R3 that is applicable to the data elements DE1 and DE2 for all the users.

The Unprotect permissions highlighted in bold in the table for the new behavior column indicate the permission, that have been inherited from the role R3, that 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. In this case, protector side permissions after deploying the policy are the same as shown in the old behavior and new behaviour columns.

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. In this case, protector side permissions after deploying the policy are same as shown in the old behavior and new behaviour columns.

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

As shown in the table, in the case of old behaviour, no permissions have been inherited from the role R3 that is applicable to the data element DE1 for all the users.

The Unprotect permission highlighted in bold in the table for the new behavior column indicate the permissions that has been inherited from the role R3, that 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

As shown in the table, in the case of old behaviour, no permissions have been inherited from the roles R3 and R4 that is applicable to the data element DE2 for all the users.

The resultant permissions highlighted in bold in the table for the new behavior column indicate the permissions that have been inherited from the roles R3 and R4, that is 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

As shown in the table, in the case of old behaviour, no permissions have been inherited from the role R3 that is applicable to the data element DE2 for all the users.

The resultant permissions highlighted in bold in the table for new behavior column indicate the permissions that have been inherited from the role R3 that is applicable to the data element DE2 for all the users.

Use Case 7

The Use Case 7 table demonstrates that if role R1 is related to data element DE1 in policy P1 and and role R3 is related to data element DE1 in policy P3, then roles R1 and R3 will not inherit the permissions of the default role. In this case, protector side permissions after deploying the policy are same as shown in the old behavior and new behaviour columns.

Table 7. Use Case 7

5.5 - Deploying Policies

Following are the steps to deploy the policy:

• The policy should be made ready for deployment.
• Deploy the policy.

Preparing the Policy for Deployment

This section describes the steps to prepare the policy ready for deployment.

If all the parameters are valid, then the policy is set to the Ready to Deploy state.

To make the policy ready for 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 deployment 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.

Note:

• When the ESA is offline and the Protector, Resilient Package Proxy (RPP), or the Resilient Package Agent (RPA) is switched off and then switched on: The Protector, RPP, or RPA fail to download the package from the ESA after it is turned on. This download activity continues until the Protector, RPP, or RPA successfully downloads the package.
• When the Protector, RPP, or RPA is running and then the ESA goes offline: The Protector, RPP, or RPA will continue to ping back the ESA, once every minute, to get the latest package. If there is no response from the ESA, then the Protector, RPP, or RPA sends a log to inform that it failed to download or check for any possible updates to the package. The package is kept published and the protect operation continues. If the RPP is not installed on the ESA, then the RPP provides the cached package to the Protector. Similarly, the RPA provides the downloaded package from the shared memory to the Protector.

Deploying the Policy

This section describes the steps how to deploy the policy after it has been prepared for deployment.

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: Redeploy the policy only when there are changes to an existing policy.

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 for Users in Multiple Policies and Roles.

5.6 - Policy Management using the Policy API

The Policy Management REST APIs are used to create or manage the policies. The policy management functions performed from the ESA Web UI can also be performed using the REST APIs. In addition, the read-only information about the appliance is also available using the REST API. The REST API does not support unstructured data elements and policies.

For more information about the Policy Management APIs, refer to the section Using the DevOps REST APIs in the Protegrity APIs, UDFs, Commands Reference Guide from the Legacy Documents section.

6 - Deploying Data Stores to Protectors

After you create a data store with the all the required components, you deploy the policy to the nodes:

For more information about Data Stores, refer to section Working with Data Stores.

To deploy the 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 such as members for each role in the policy, token elements, and so on.

7 - Managing Policy Components

You can edit or delete the following policy components from Policy Management:

• Data Elements
• Masks
• Alphabets
• Member Sources
• Data Stores
• Trusted Applications
• Policies
• Roles

The following table describes the editable fields for each policy component.

When you click the link for name of policy component, you can edit the fields from the component edit panel. You click the Delete ( ) icon to delete the policy component.

If the policy components are already added to a policy, then you cannot delete it.

8 - Policy Management Dashboard

The following figure shows the Dashboard screen for Policy Management.

The Policy Management dashboard consists of the following three areas:

• Summary
• Keys
• Statuses - The Statuses area is a legacy feature that is not applicable for 10.0.0 protectors and later.

Summary

This section provides information about the Summary area in the Policy Management dashboard.

The Summary area displays an overview of the number of policy components created using the Policy Management Web UI. The following policy components appear under the Summary area:

• Roles
• Data Elements
• Member Sources

You can navigate to the respective policy components by clicking the corresponding number.

For example, you click 2 corresponding to Data Elements, to view the list of data elements.

Keys

This section provides information about the Keys area in the Policy Management dashboard.

The Keys tab displays an overview on the number of keys managed and created using the Key Management Web UI. The following key components appear under the Keys area:

• Keys Managed: Total number of keys present in the Policy Management system. This includes the Master Keys, Repository Keys, Signing Keys, Data Store Keys, and Data Element Keys. This number also includes all the rotated keys.
• Data Element Keys Managed: Total number of Data Element Keys currently present in the Policy Management system. Each key is connected to an existing Data Element. This number also includes the rotated Data Element Keys. It is important to note that a maximum number of 8191 keys can be present in the system.
• Data Element Keys Created: Total number of Data Element keys that have been ever created in the Policy Management system. This number also includes the keys that you have created earlier but have subsequently removed after deleting a data element. It is important to note that you can create a maximum number of 8191 keys.

The following figure shows the Keys area.

9 - Exporting Package for Resilient Protectors

The following table provides information about each component that must be used or configured to export the package from the ESA.

10 - Legacy Features

The following Policy Management features are not applicable for 10.0.0 protectors and later:

• Policy Management > Nodes
• Policy Management > Dashboard > Statuses

For more information about these Legacy features for your supported Protectors earlier than 10.0.0, refer to a corresponding version of the Policy Management Guide from the My.Protegrity website.

For 10.0.0 protectors and later, you can access the information about the protector nodes and statuses from the Protegrity Dashboard.