Data Security (PII - Role Based Restrictions)
AE RPA complies with the requirement of masking of data (Data is masked as per the masking pattern) and anonymization (one-way data encryption) of the Personal Identifiable Information (PII) data in custom business reports.
This has been extended to Process Input defined in Automation Studio to be included as PII data in existing OOB Reports as well. PII can be defined as any personal information about any person with which the person can be identified.
Mainly, the PII data includes:
· First name or last name
· Country, State, City, Pin code
· Credit card
· SSN and so on.
A data masking is a process which hides the confidential part of data. Data protection feature ensures that sensitive data is protected in the RPA work environment.
NOTE: |
By default, OOB Dashboard in Reporting will show data for all the profiles. However, you can restrict the data appearing in OOB Dashboards by mapping the particular profiles in the User Mapping section of the Administrator Module. To achieve this, you are required to perform configuration in elastic search config.yml. For more information about TxnStore configuration, see Role and User Based Authorization section in AE-RPA-Engage-Installation Guide.
|
Prerequisites
· In order to use masking pattern in production, enure that you have also imported KibanaReportsMasked.json while AE RPA installation.
· User role should have access to OOB Dashboards and Visualization Tab to create reports and view in the dashboards.
· Ensure that required masking pattern/Anonymization has been applied for an argument through Data Protection in Automation Studio. For more information about masking, see data protection section in AE-RPA-Engage-Automation Studio Guide.
§ Data can be masked or anonymized for Operational reports as well as Business reports.
Configuration Required for Data Protection
To achieve data security for business report, you are required to do changes only in Elastic Search config .yml. For operational reports, you are required to perform mainly two types of configuration changes in Kibana.yml and Elastic Search config.yml. Additionally, you will have to perform changes in KibanaReports.json and KibanaReportsMasked.json files as well.
1. Before starting with changes, ensure that reporting is in stopped state.
2. You are required to configure Kibana.yml.
a. Navigate to build path folder- $\generic\kibana\kibana-6.7.2-windows-x86_64\config\kibana.yml.
b. Configure the Ids and title in the allowedDashboards for the role whose data protection needs to be changed.
§ For instance, if masking is required, you should provide ids of KibanaReportsMaskedJson.
§ For non masking (plain text needs to be shown) you should provide ids of KibanaReport Json.
For more information about configuring the ids and title, see Role_Based_Access_Control_to_Reporting_Tabs_and_Dashboards.
3. Then, you are required to configure Elastic Search config.yml.
a. Navigate to build path folder - $\generic\elasticsearch\elasticsearch-6.7.2\config\AssistEdgeAnA\config.yml.
By default except super_admin role, all other roles process input data is masked. If you want to change the default setting or add a masking pattern for a new role or existing role, then you are required to configure the role accordingly.
NOTE: |
In case process input argument does not match with data masking pattern criteria, then the default masking pattern is applied to process input argument. For more details about fall back mechanism, see Data Protection FallBack Mechanism section under Infrastructure Health Monitoring in the AE-RPA-Administrator Guide. |
Following is the field level description:
Fields |
Description |
roles |
Specify the role for which you want to allow the access. <Super_Admin>: By default, <super_admin> user can view the process inputs and data for this role will not appear as masked. But the anonymize data will be encrypted. For Other Roles: If masking pattern is applied, then for all other roles, the data will appear as masked. New Role: For any new role added to AE RPA, then <super_admin> user should configure the masking pattern for new role. Else, masking pattern will not be applied and the role will have privileges of super admin. |
exclude - MaskedArguments |
If you configure any role with exclude-MaskedArguments, then that role can view the business input data in plain text. |
exclude -MaskedSearchInputs |
If you configure any role with exclude: MaskedSearchInputs, then that role can view the process input data in plain text. |
exclude -Searchinput |
If you configure any role with exclude: SearchInputs, then that role can view the process input data as masked. |
exclude-Arguments |
If you configure any role with exclude-Arguments, then that role can view the business input data as masked. |
b. In the datareport*, configuration changes will affect the business reports.
c. In the rpa-trans-*, configuration changes will affect the operational reports and dashboards.
NOTE: |
For a particular role, user will not be able to see any data for Operational reports in following scenarios: a. Id of Dashboard is used from KibanaReportsMasked.Json in kibana.yml and maskedsearchinput arguments are excluded in config.yml. b. Id of Dashboard is used from KibanaReports.Json in kibana.yml and searchinput argument is excluded in config.yml. |
4. Navigate to build path folder - $\RPA_18.1\scripts and restart the following components:
a. TXNSTORE (if changes are done in config.yml)
b. REPORTING (If changes are done in kibana.yml)
5. Based on the configuration done, the process inputs will appear as masked in the Reports and Dashboard for the relevant roles.
NOTE: |
In case data is anonymized from Automation Studio, then it will appear anonymized, irrespective of the roles and changes done in Elastic search config.yml. |
On This Page Hide
Related Topics