Skip to main content
Delphix

Best Practice: Identifiers and Users for Masking (KBA1753)

 

Issue

This document covers the requirements and scope of Identifiers and Users required for the masking process, explaining the challenges and recommendations.

One of the primary requirements is the connectivity between Delphix and the databases.  This document details the permissions required for different masking use case .  While you can use existing ID’s, Delphix recommends creation of new ID’s specific to masking.

Note

Note:

The context of this document is limited to Masking only.

Challenges & Recommendation

Delphix connects to databases for two reasons:

  • Discovering sensitive data
  • Masking sensitive data

Permissions needed to execute the operations are different for each case. Clients may use a single ID that encompasses all required access or different ID’s for each action. 
Delphix recommends a single ID where possible.

Delphix masking recommends that you do not connect to the production databases to reduce load and minimize risk to the production systems.

To ensure consistency of approach and execution, Delphix recommends running a masking project from a centralized Masking Center of Excellence (CoE). 
Additional stakeholders include:

  • DBA Groups(s)
  • System administrators
  • Information Security
  • Infrastructures
  • Project Management Organization

The below sections describe the required access type, the embedded table has more detailed specifications for the IDs.

Use Cases  

 Scenario 1: Data Discovery 

Sensitive data discovery is a non-destructive process and reads metadata and/or data from databases only.

The discovery process has the following 2 or 3 characteristics:

  • Access and read sensitive (production) data.
  • Analyze metadata from selected schema/database
  • May sample unmasked data if doing data level profiling

Hence, the ID used for profiling needs to be able to connect data, read data, and also maintain a full audit trail.

A User Id of this nature may need approval for access to production/sensitive data and may not need exclusive access while the profiling job but will put load on database.
This however is low priority and executed infrequently after masking is successfully configured and executed the first time.

Scenario 2: Data Masking  

Masking operations change data in the database and hence needs an exclusive access on the target database while the masking job is running.

Along with changing data, the masking process sometimes needs to make DDL changes (mostly transient) and may need higher privileges than DML. This ID also needs be fully audit-able since it accesses sensitive data.

Scenario 3: File Masking 

Masking operations also change data in files and hence needs an exclusive access on the file system while the masking job is running.

Masking workflow works in 2 modes:

  • On-The-Fly (Recommended for file masking)
    This mode involves creating 2 directories on the SFTP/FTP location with SOURCE – R or 400 TARGET – RWX or 755
  • In-Place
    Target – R or 400

Recommendation

Below are a few recommendations for creating IDs.  These should be incorporated in the Masking CoE rule book during project setup.

Central Creation 

Wherever possible the User ID(s) should be centrally created per company policy. This makes it easier to copy users to different databases.

Replication across Platforms 

A template for the ID should be created within the company for easy ID provisioning across all platforms (as data masking happens across platforms). A common naming-convention is also highly recommended

It becomes very easy for all groups (mentioned) earlier if a common ID (over a common ID name) is used for the same purpose across company.

Auditable 

The masking IDs will access and change sensitive data. As per company policy it may be needed that every action of these IDs is tracked and an audit trail is maintained. Audit log for ID activity may be maintained for the longest period per company’s Information Security policy.

Note

Note:

 Delphix maintains an audit trail of (each) user activity inside Delphix.

Non-Interactive 

Within the Delphix interface, users cannot see the underlying data. They are only allowed to see the metadata and data characteristics.

It is understood that certain users will need access to data to validate, verify, and oversee the masking operations. It is highly recommended that these users have separate IDs and do not use Delphix IDs designated for masking.

Delphix IDs should remain non-interactive as Delphix only establishes programmatic access to databases and not visual based.

Role Based Access Control (RBAC)

If RBAC for dynamic access is available, the Delphix ID/IDs should be included in a role that has access to the appropriate Databases. A masking role can also be created with the permissions needed.

Firewall Protection 

Since masking operation executes a large number of queries and reads huge amount of sensitive data, the firewall or DLP (data leak prevention) systems in the company should be updated for activity using the Masking IDs. The masking activity is sometimes flagged as inappropriate by older systems and the processes are blocked.

Linkage 

Many customers link the masking user IDs to third-party products designated for User ID management, recommendations for such use cases is below.

Central Authentication 

Many firms use central authentication like LDAP and Kerberos. Delphix supports any JDBC based authentication mechanism. The Delphix engine may need to register with the company domain,  this can be accomplished via Delphix professional services.

 

Note

Note:

 LDAP username / password authentication is natively available to connect to databases, system specific JDBC connection URL shall be used.

Privileged Password Management (PPM)

Many customers use central password repositories for privileged IDs which have access to production data. Delphix does not officially endorse any third party product but many of our clients have integrated with Cyber-ark, Cloak ware, and Powerbroker type of PPM solutions. Users may have to consult the PPM team in order to facilitate integration

Privileges 

The table below highlights the permissions IDs need for most common database types.

Oracle Function Description
Profiling CREATE SESSION Connect to the database.
SELECT Query the table with the SELECT statement.
Masking

CONNECT, 

RESOURCE,

and DBA

These roles are provided for compatibility with previous versions of Oracle Database. You can determine the privileges encompassed by these roles by querying the DBA_SYS_PRIVS data dictionary view.
CREATE SESSION Connect to the database.
DELETE Remove rows from the table with the DELETE statement.
INSERT Add new rows to the table with the INSERT statement.
SELECT Query the table with the SELECT statement.
UPDATE Change data in the table with the UPDATE statement.

Masking

Power

User

ALTER Change the table definition with the ALTER TABLE statement.
CONNECT, RESOURCE, and DBA These roles are provided for compatibility with previous versions of Oracle Database. You can determine the privileges encompassed by these roles by querying the DBA_SYS_PRIVS data dictionary view.
CREATE SESSION Connect to the database.
CREATE TABLE Create a table in the grantee's schema.
DELETE Remove rows from the table with the DELETE statement.
EXECUTE Operations on job classes, programs, chains, and credentials.
INDEX Create an index on the table with the CREATE INDEX statement.
INSERT Add new rows to the table with the INSERT statement.
SELECT Query the table with the SELECT statement.
UPDATE Change data in the table with the UPDATE statement.

 

 

Sybase

Function

Description

Profiling Profiling Allows the user to connect to the database. See New user creation.
SELECT Allows the user to look at information in a table or a view. This permission can also be granted to individual columns in a table. See GRANT statement.

Masking

 

 

 

CONNECT Allows the user to connect to the database. See New user creation.
DELETE Allows the user to delete rows from a table or view. See GRANT statement.
INSERT Allows the user to insert rows into a table or view. See GRANT statement.
INTEGRATED LOGIN Allows the user to connect to the database using an integrated login. See Windows integrated logins.
KERBEROS LOGIN Allows the user to connect to the database using a Kerberos login. See Kerberos authentication.
SELECT Allows the user to look at information in a table or a view. This permission can also be granted to individual columns in a table. See GRANT statement.
UPDATE Allows the user to update rows in a table or view. This permission can also be granted to individual columns in a table. See GRANT statement.

Masking

Power

User

 

 

 

 

 

 

ALTER Allows the user to alter the structure of a table or create a trigger on a table. Because this permission grants the user the permission to modify the database schema, it should not be granted to most users. See GRANT statement.
CONNECT Allows the user to connect to the database. See New user creation.
CREATE ON Allows a user with RESOURCE authority to create database objects in the specified dbspace. See GRANT statement and RESOURCE authority.
DELETE Allows the user to delete rows from a table or view. See GRANT statement.
EXECUTE Allows the user to execute a procedure or a function. See GRANT statement.
INSERT Allows the user to insert rows into a table or view. See GRANT statement.
INTEGRATED LOGIN Allows the user to connect to the database using an integrated login. See Windows integrated logins.
KERBEROS LOGIN Allows the user to connect to the database using a Kerberos login. See Kerberos authentication.
REFERENCES Allows the user to create indexes on a table and to create foreign keys that reference a table. This permission can also be granted on individual columns in a table. Because this permission grants the user permission to modify the database schema, it should not be assigned to most users.
SELECT Allows the user to look at information in a table or a view. This permission can also be granted to individual columns in a table. See GRANT statement.
UPDATE Allows the user to update rows in a table or view. This permission can also be granted to individual columns in a table. See GRANT statement.

 

SQL Server

Function

Description

Profiling

CONNECT CONTROL SERVER
SELECT SELECT

Masking

 

CONNECT CONTROL SERVER
DELETE DELETE
INSERT INSERT
SELECT SELECT
UPDATE UPDATE

Masking

Power

User

 

ALTER ALTER
CONNECT CONTROL SERVER
CREATE TABLE CONTROL SERVER
DELETE DELETE
EXECUTE EXECUTE
INSERT INSERT
SELECT SELECT
UPDATE UPDATE

 

Applicable Delphix Versions

This article applies to the following versions of the Delphix Engine:

Major Release

Sub Releases

5.3 5.3.0.0
5.2 5.2.2.0, 5.2.2.1, 5.2.3.0, 5.2.4.0, 5.2.5.0, 5.2.5.1, 5.2.6.0, 5.2.6.1

5.1

5.1.0.0, 5.1.1.0, 5.1.2.0, 5.1.3.0, 5.1.4.0, 5.1.5.0, 5.1.5.1, 5.1.6.0, 5.1.7.0, 5.1.8.0, 5.1.8.1, 5.1.9.0, 5.1.10.0

5.0

5.0.1.0, 5.0.1.1, 5.0.2.0, 5.0.2.1, 5.0.2.2, 5.0.2.3, 5.0.3.0, 5.0.3.1, 5.0.4.0, 5.0.4.1 ,5.0.5.0, 5.0.5.1, 5.0.5.2, 5.0.5.3, 5.0.5.4

 

 

Tags recommended by the template: article:reference