Skip to main content
Delphix

KBA1753 Best Practice: Masking Engine Identifiers and Users

 

Applicable Delphix Versions

  • 5.3
  • 5.2
  • 5.1
  • 5.0

Issue

Introduction

This document covers the requirements and scope of the Identifiers and users required for the masking process.  It explains various challenges and recommendations.

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

A brief summary of privileges is shown in the tables at the end of this document.

Context of this document is limited to masking.

Challenges

Delphix masking recommends not connecting to 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.  Below is a list of additional stakeholders:

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

Delphix connects to Databases for primarily 2 purposes.

  1. Discovering sensitive data
  2. Masking sensitive data

Permissions needed to execute the operations are different for each of these cases. 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.

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

Use cases 

 Use case scenario 1 – Data Discovery

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

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 and read data, it also need to 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 is however, low priority and executed infrequently after masking is successfully configured and executed the first time.

Use case 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 may need to make DDL changes (mostly transient) and may need higher privileges than DML. This ID also needs be fully auditable since it accesses sensitive data.

Use case 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

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

  1. In-Place

        Target – R or 400

Best Practices

Below are a few recommendations for creating IDs.  These should be incorporated in the Masking CoE rulebook 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

Similar to earlier points, a template for the ID should be created within the firm 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 Firm’s Info sec policy.

Note: Delphix maintains an audit trail of all activity of each Delphix user inside Delphix.

Non-Interactive

Within the Delphix UI, 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 & 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

If an RBAC for dynamic access based on role 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 Firm 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, and this can be accomplished via Delphix professional services.

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

Privileged Password Management

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 & 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

Additional Information

Additional Database details will be available soon.

External Links

N/A