In OvalEdge the security for data is managed during the transit as well as at the rest.
Data at Rest
OvalEdge uses a MySQL database for storing application data. The data can be secured through a secure MySQL deployment on request, by enabling Transparent Data Encryption through the Keyring plugin. This encryption can be enabled for:
- File-per-table tablespaces.
- Audit log files
- Backups
https://dev.mysql.com/doc/refman/5.7/en/innodb-data-encryption.html
Data in Transit
Crawling for Metadata
The metadata from source systems is collected by OvalEdge connectors, using secure encrypted connections. The table below lists the encryption protocols used by the connectors.
Source System |
Connector Encryption Protocol |
Remarks |
SQL Server |
SSL / TLS 1.2 |
|
Oracle |
SSL / TLS 1.2 |
|
Postgres |
SSL / TLS 1.2 |
|
MySQL |
SSL / TLS 1.2 |
|
SAP |
SNC |
Viewing Data
Users can view data from source systems in the following ways :
- As sample data in the data catalog
- As a result of queries executed in the query sheet
Security for sensitive or confidential information is enforced through governance policies. This covers :
- Sensitive information, typically of a person that should not be disclosed. For example in a healthcare company, information about a person's health record is sensitive information and the data should be masked.
- Confidential information should always be restricted from access by unauthorized users. The columns themselves should not be visible. For example in a healthcare pharmaceutical company, any column data related to the composition of the drug is classified as confidential.
- PII, referring to personally identifiable information as defined by standards like GDPR, should be masked so that it is not visible to unauthorized users. For example Name, Email, Phone, etc.
Implementing Data Security
Access to data objects like schemas, tables, files, reports, etc can be governed through roles-based access policies that can be defined. This allows policies to enable or disable access to the entities at the role level. Policies applied at a containing object level, automatically cascade the access policies to its child entities.
For example, if a schema ‘CRM’ access has been restricted to a role ‘SALES_GROUP_MANAGERS’, then only users in that role will see the schema, its tables, columns metadata in the data catalog. These objects will not be visible to users not present in the role. This access restriction is applied to all modules in OvalEdge.
In addition, data security is also supported at the column level in OvalEdge. The following types of column-level security are supported:
- Data Masking: When this is enabled on a column or a set of columns, the values in the column are masked to ‘XXXX’ for unauthorized users.
- Data Restricting: When this is enabled on a column or a set of columns, the column is hidden from unauthorized users.
These security types can be enforced at two levels:
- Individual table column level
- Business glossary term level, providing an option to enforce the required security settings for all the columns associated with the terms.
Data Security at Column Level
The steps involved in enforcing data security directly are given below :
- Navigate to Administration -> Security menu option. This will display the security settings for the various objects.
- Enable column security, by selecting the checkboxes, for the tables containing the sensitive, confidential, or PII columns.
- Click on the Table columns tab, which will open the Table columns security view.
- Set the security policy for the columns by selecting ‘Mask Column’ or ‘Restrict Column’. If both are selected, then the restriction policy will take precedence.
- Masking: This is applied to all roles in the system.
- Restriction: This can be configured at the role level, to allow authorized users access to columns. When the Restrict column checkbox is selected, by default the authorized role is set to OE_ADMIN. This can be changed to add or remove additional roles as needed.
Note: If column security has not been enabled for the tables containing the columns, an alert will be displayed to enable the same.
Data Security at Business Glossary Terms Level
The steps involved for enforcing data security at the terms level are given below :
- Navigate to Business Glossary (Master Taxonomy) -> Security menu option. This will display the domains and the related terms already defined.
Note: The glossary and terms should have been set up prior to this step. - Click the term for which data security settings need to be applied.
- Set the security policy for the term by selecting the ‘Mask Column’ or ‘Restrict Column’ checkboxes. If both are selected, then the restriction policy will take precedence.
- Masking: This is applied to all roles in the system.
- Restriction: This can be configured at the role level, to allow authorized users access to columns. When the Restrict column checkbox is selected, by default the authorized role is set to OE_ADMIN. This can be changed to add or remove additional roles as needed.
Data Security While Logging
OvalEdge does not log any data from source systems in its logs at any point in time - while crawling, profiling and querying. Hence masking or restriction of sensitive, confidential or PII information in the logs is not required.
The logs can be extracted from the application installation for audit purposes as needed.
Alternatively, logs from OvalEdge can also be integrated with Splunk. The logs generated can be viewed in Splunk and audited for sensitive, confidential, and PII information using the tools available in Splunk.
For more information on Splunk Integration, please refer to Integration with Splunk for Log aggregation article.
Copyright © 2019, OvalEdge LLC, Peachtree Corners GA USA