Ctrlk
AcademyCustomer Portal
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Data Masking Policies

The article explains masking policies and their importance in safeguarding sensitive data within the OvalEdge application.

Masking Policies

Masking conceals actual data by substituting it with altered content, like characters or numbers. The main goal is to generate a hard-to-identify alternate data version, safeguarding sensitive information from unauthorized access. In the event of a data breach or unauthorized access, masked data adds an additional layer of protection.

Many industries are subject to strict data protection regulations like GDPR or HIPAA. Masking aids in compliance by minimizing the exposure of sensitive data, reducing the risk of breaches and penalties.

This process is particularly crucial for safeguarding sensitive data types like:

  • Personally identifiable information (PII)

  • Protected health information (PHI)

  • Payment card information (PCI-DSS)

  • Intellectual property (ITAR).

Masking Scheme Options

A masking scheme defines how original data is transformed while preserving the data's format and length. When configuring masking for your data, you have a range of choices known as masking schemes. These schemes determine how the original data is transformed to ensure privacy and security. Let's explore these with examples:

  • Mask Alphanumeric Characters: Replace letters and numbers with masking characters while preserving special characters.

    • Original: "JohnDoe@1985"

    • Masked: "xxxxxxx@xxxx"

  • Mask All Characters: Replace all characters, such as "abc@123" turning into "xxxxxxx”.

  • Show Last 4 Characters: Display only the last four characters, for instance.

    • Original: "123-456-789"

    • Masked: "xxx-xxx-789"

  • Show First 4 Characters: Display the initial four characters, like "abc@123" showing as "abc@xxx”.

  • Present Blank Spaces: Replace data with blank spaces.

    • Original: "987-654-321"

    • Masked: " "

  • Default Masking (xxxxxxx): Use a generic masking approach, replacing all characters with "x" for consistency, like "abc@123" transforming to "xxxxxxx”.

    • Original: "SensitiveData"

    • Masked: "xxxxxxx"

  • Number Masking (-1): For numerical data, replace with a default number, such as.

    • Original: "-12345"

    • Masked: "-1"

  • Number Masking (-9999999999): Similar to the previous option, replace numerical data with a predefined default value.

    • Original: "1234567890"

    • Masked: "-9999999999"

Masking Policies Approaches

A Policy is a rule applied to represent data in encrypted form. OvalEdge Supports Masking at the Column level.

The masking policies in OvalEdge can be implemented in two ways: Business Glossary Term Associations and Security Masking.

  • Term Associations

  • Security - Table Column

Business Glossary Term Associations

OvalEdge provides a structured approach to implementing masking techniques through its Business Glossary. This feature empowers organizations to tailor their masking policies, permitting designated or allowed users and roles to access actual data while applying masking to the data for others. Here's a breakdown of how this process works.

  • Masking using Terms: Within OvalEdge's Business Glossary module, users have the capability to link masking policies to particular terms. This functionality enables organizations to implement masking measures on data objects that are linked to terms with associated masking policies.

  • Single Policy per Column Type: OvalEdge enforces a one-to-one relationship between policies and column types when creating these masking policies. This ensures clarity and consistency in the masking process. For instance, a single masking policy can be created for string, timestamp, boolean, date, or default data types.

  • Handling Data Type Mismatch: It's important to note that the masking policy associated with a term must align with the data type of the respective column. For instance, if a masking policy is created for string data types but is applied to a column with an integer data type, the default masking policy (Asterisk masking) takes precedence. This approach ensures that data remains protected to a certain extent regardless of any mismatches.

How to mask a table column using a term?

  1. Accessing the Business Glossary Module: Locate the Business Glossary module on the left panel of OvalEdge's interface.

  2. Selecting the Desired Term: Search for and choose the specific term you want to associate with a masking policy.

  3. Manage Associations: Scroll to the "Manage Associations" section at the bottom of the screen.

  4. Enabling Masking: Check the "Masked" checkbox to trigger an "Assign Masking Policy" pop-up window.

    Assigning a Masking Policy allows administrators to associate a masking policy with a Business Glossary term by enabling the Masked option. They can either select an existing masking policy or create a new one by defining the column data type, masking scheme, and the roles and users permitted to view unmasked data. Once saved, the policy is applied to all data objects associated with that term, ensuring sensitive information is protected while allowing authorized access.

  5. Choosing Policy Type: Opt for either "Add New Policy" or "Add Existing Policy.”

    1. Add Existing Policy: To add the masking schemes that are previously configured policies, along with their associated allowed roles and users.

    2. Adding New Policy: To create a new policy by specifying the column data type, masking schemes, allowed roles, and users.

  6. Add New Policy

    1. Define Column Type: Select the relevant column type (string, number, timestamp, date, default) that requires masking.

    2. Policy Name: Give a clear and descriptive name to the masking policy.

    3. Masking Scheme Options: Choose from various masking options, including masking alphanumeric characters, masking all characters, displaying the last 4 characters, showing the first 4 characters, or presenting blank spaces.

    4. Specify Allowed Roles and Users: Utilize dropdown options to specify the roles and users permitted to access unmasked data.

    5. Save Changes: Click the "Save Changes" button to incorporate the newly created masking policy into the list of masking policies for future usage.

Security Masking - Column Level

This approach involves applying masking to table columns through the Administration > Security module. Users with Security and Governance admin privileges on the specific connector can implement masking policies on that connector and associated data objects.

Enabling table-level security is a prerequisite for masking a table column. This setting allows modifications to associated table columns, facilitating the application of masking or other security measures.

Conflicting Data Masking Policies

When Column-level Security Masking and Term-level Masking policies apply to the same data object, the most recently applied masking policy takes precedence.

When a Term-level Masking Policy is applied, the existing Column-level Security Masking on the associated data object is automatically disabled. The following scenarios describe how masking behavior changes based on the status of the associated Business Glossary term.

Scenario
Result

Column-level Masking enabled, Term in Draft or Published state without a Term-level Masking Policy

The Column-level Masking Policy remains in effect.

Column-level Masking enabled, Term in Initial Draft status (newly created term awaiting publication)

The Column-level Masking Policy continues to be applied until the term is published.

Column-level Masking enabled, Term in Published status with a Term-level Masking Policy

The Term-level Masking Policy overrides the Column-level Masking Policy and is applied to the associated data object.

Column-level Masking enabled, Term moved from Published to Draft

The previously applied Term-level Masking Policy remains in effect even after the term is moved back to the Draft state.

Column-level Masking enabled, Term deleted or the Term-level Masking Policy removed

All masking is removed from the data object. The previously disabled Column-level Masking Policy is not restored automatically.

Existing Term replaced with another Term in Draft status

All masking policies are removed from the data object, including any existing Column-level Security Masking.

Below are the supported formats for different column types:

String
Number
Date
Time Stamp
Boolean

char

bit

date

timestamp

boolean

varchar

tinyint

-

datetime

bool

varbinary

smallint

-

datetime2

-

binary

mediumint

-

datetimeoffset

-

tinyblob

int

-

smalldatetime

-

tinytext

integer

-

timestamp_ltz

-

text

bigint

-

time

-

blob

float

-

year

-

mediumtext

double

-

-

-

mediumblob

decimal

-

-

-

longtext

dec

-

-

-

longblob

numeric

-

-

-

enum

real

-

-

-

set

smallserial

-

-

-

character varying

serial

-

-

-

character

bigserial

-

-

-

uuid

money

-

-

-

nchar

smallmoney

-

-

-

nvarchar

currency

-

-

-

ntext

int64

-

-

-

string

float64

-

-

-

longvarchar

double precision

-

-

-

longnvarchar

-

-

-

-

varchar2

-

-

-

-

textarea

-

-

-

-

Copyright © 2026, OvalEdge LLC, Peachtree Corners, GA, USA.

PreviousConfigure ViewsNextUser's List

Last updated

Was this helpful?