Settings

Global application settings are available under the Settings item of the main navigation menu.

The Settings page has the following sections:

• Git Repository Settings
  • Git Repository Parameters
  • Git Provider Setup
• SMTP Email Settings
  • SMTP Parameters
• SSL Credentials
  • Active SSL Credentials
  • Installing SSL Credentials
• Hostnames
• Instance Secret
• DataMasque AI Engine
• SAML Single Sign-On
• Global Keywords
• Locality
  • Configuring the Locality
  • Locality in the Ruleset Generator
  • Locality Interpolation in Rulesets

Note: Application settings can only be accessed when logged in as a DataMasque admin user.

Git Repository Settings

DataMasque allows you to manage ruleset YAML files by pushing them to and pulling them from a remote Git repository. Configure these settings and upload your SSH private key file to enable these functions.

Note: DataMasque only supports connecting to the remote Git repository over SSH.

Tip: Upload your SSH private key on the My Account page before configuring the repository URL. This allows DataMasque to validate the connection when you save your settings.

You can configure your remote Git repository details by clicking the    button. You will be presented with a form to provide your configuration (see Git Repository Parameters below for details):

Git Repository Parameters

Repository URL	The remote Git SSH URL to push ruleset to or pull ruleset from. See Git provider setup for URL formats.
Branch Name	The target branch name to push ruleset to or pull ruleset from. If left blank, DataMasque will try to auto-detect the default branch.
Directory Path	The directory path to push ruleset to or pull ruleset from. Leave it blank to specify the root directory of the repository.

Git Provider Setup

DataMasque connects to remote Git repositories over SSH. The table below shows the SSH URL format for each supported provider.

Provider	URL Format	Example
GitHub / GitLab / Bitbucket Cloud	git@hostname:org/repo.git	git@github.com:acme/rulesets.git
Azure DevOps	git@ssh.dev.azure.com:v3/org/project/repo	git@ssh.dev.azure.com:v3/acme/MyProject/rulesets
AWS CodeCommit	ssh://SSH-KEY-ID@git-codecommit.REGION.amazonaws.com/v1/repos/REPO	ssh://APKAEIBAERJR2EXAMPLE@git-codecommit.us-east-1.amazonaws.com/v1/repos/rulesets

For all providers, upload your SSH private key on the My Account page.

AWS CodeCommit

CodeCommit requires an IAM SSH key ID embedded in the URL:

1. In the AWS IAM console, navigate to your IAM user. Under Security credentials, scroll to SSH keys for AWS CodeCommit.
2. Click Upload SSH public key and upload the public key that corresponds to the private key you will upload to DataMasque. Note the SSH key ID (e.g. APKAEIBAERJR2EXAMPLE).
3. Use the SSH key ID as the username in your repository URL (see table above).

Important: The SSH key ID must be included in the URL. Without it, the connection will fail because CodeCommit cannot determine the correct IAM identity.

For more information, refer to the AWS CodeCommit SSH connection documentation.

Azure DevOps

Azure DevOps uses a non-standard SCP-style URL without a .git suffix:

1. In Azure DevOps, navigate to your repository and click Clone. Select the SSH tab and copy the URL. It will be in the format git@ssh.dev.azure.com:v3/org/project/repo.
2. Add your SSH public key under User settings > SSH public keys in Azure DevOps.

For more information, refer to the Azure DevOps SSH documentation.

Bitbucket

Bitbucket Cloud uses standard SCP-style SSH URLs (git@bitbucket.org:org/repo.git).

Bitbucket Server (self-hosted) typically uses SSH on a custom port. Use the ssh:// URL format:

ssh://git@bitbucket.example.com:7999/project/repo.git

Replace bitbucket.example.com, 7999, project, and repo with your server's details.

Add your SSH public key under Personal settings > SSH keys in Bitbucket.

SMTP Email Settings

DataMasque can be configured to send emails over SMTP for the purposes of providing 'Forgotten Password' account recovery and critical system notifications. This will also be used to send support and usage information to DataMasque.

Note: Emails will be sent to usage@datamasque.com in addition to registered users. Please ensure the SMTP server is capable of sending emails to registered users, as well as outbound emails to usage@datamasque.com.

You can configure your SMTP server details by clicking the    button. You will be presented with a form to provide your configuration (see SMTP Parameters below for details):

You may opt in to receive a copy of any automated outbound emails that are sent to DataMasque HQ. This can be done by enabling the setting shown below.

SMTP Parameters

Sender	The email address that your DataMasque instance will send emails from*
Host Name	The hostname or IP address of your SMTP server (must be accessible from your DataMasque instance)
Port	The port used by your SMTP server
Security Protocol	The security protocol used by your SMTP server
SMTP Username	The username used to authenticate with your SMTP server (requires SSL or TLS)
SMTP Password	The password used to authenticate with your SMTP server (requires SSL or TLS)

You can test saved SMTP server configurations by clicking the SEND TEST EMAIL button. This will send a test email to the email address associated with your user account to test connectivity to the specified SMTP server from DataMasque.

Note: Most non-relay SMTP servers that require SSL/TLS security protocol and SMTP credentials will rewrite the From header in messages to the corresponding SMTP account to secure the credentials of the sender. In that case, it is recommended to configure the SMTP credentials and DataMasque Sender with the same email address (for consistency).

SSL Credentials

By default, DataMasque is configured with an auto-generated self-signed SSL certificate. The self-signed certificate must be accepted in the browser by a user when accessing DataMasque.

To ensure a secure SSL connection, it is recommended to install a certificate that has been signed by a trusted CA whose root certificate is installed on client machines.

Active SSL Credentials

The SSL Credentials panel contains details of the SSL credentials currently in use by DataMasque, including the certificate and private key files and the SHA-1 fingerprint of the certificate:

Installing SSL Credentials

You are able to install your own SSL credentials using the "SSL Credentials" settings panel.

Note: DataMasque accepts X.509 SSL certificates in PEM format. Other formats are not supported.

Note: When generating an SSL certificate for DataMasque, it is recommended to correctly set the "Common Name" field to match the hostname of the DataMasque instance but also include SAN (Subject Alternative Name) entries that cover the potential IP addresses at which DataMasque may be accessed. In a Cohesity environment, this would include the IP address for each cluster node. This ensures that DataMasque can always be accessed using a secure connection.

New SSL certificate and private key files can be installed by clicking on each file and selecting replacements to upload. Before proceeding, ensure that any critical data stored in DataMasque is backed up. In the event that invalid or incorrect credentials are installed DataMasque may become inaccessible.

Once you are satisfied that you have backed up any important data, click the 'Save' button to update DataMasque with the selected credentials. After successful installation, your page will be refreshed to ensure that your browser is initialised with the new credentials.

If at any point you wish to revert to using the default self-signed SSL certificate, you may do so by clicking the "Reset Default" button.

Hostnames

DataMasque must be configured with the hostnames and IP addresses that will be used to access the application. It is strongly recommended to include the DataMasque instance IP address in this configuration as well as hostname to avoid losing access to the application. Currently, only IPv4 addresses are supported, in the following formats:

• Standard IPv4 address: x.x.x.x, where x ranges from 0 to 255.
• IPv4 with CIDR notation: x.x.x.x/y, where x ranges from 0 to 255 and y ranges from 0 to 32.

Hostnames can be added and deleted using this interface, however deleting the hostname that is currently in use to access DataMasque is disallowed.

Instance Secret

Each DataMasque instance has a randomly generated instance secret to protect against attackers replicating deterministic masking on a different instance (see the deterministic masking guide for details). You can rotate the instance secret from the Settings page by clicking the Rotate Instance Secret button. After rotating the instance secret, subsequent deterministic masking will be based on a new instance secret, and existing rulesets will produce different masking results.

DataMasque AI Engine

The DataMasque AI Engine is an optional service that provides AI-powered entity detection for unstructured masking. When configured, it enables the use of the ai_detect matcher for AI-powered entity detection.

Note: The DataMasque AI Engine is a separate service deployed alongside DataMasque. Contact support@datamasque.com for access.

After connecting DataMasque to the DataMasque AI Engine, the following section will appear in the settings menu. For instructions on connecting to the DataMasque AI Engine, see the Configuration Guide.

For more information on using the ai_detect matcher with the unstructured_text mask, see Unstructured Masking.

SAML Single Sign-On

The SAML Single Sign-On settings panel can be used to configure DataMasque for single sign-on (SSO). See the SAML Single Sign-On user guide for details about how SAML SSO works with DataMasque.

The following parameters can be configured for SAML SSO:

IdP metadata XML	The SAML metadata XML file obtained from your identity provider.
Disable local logins	When SAML SSO is configured, enabling this will disable login of all local users (except DataMasque admin users).

Global Keywords

You can provide DataMasque with Global Custom Data Classification keywords.

Column names are matched to Global Custom Data Classification keywords in addition to the built-in data discovery keywords.

Custom Data Classification keywords can be delimited by any number of spaces .

You can also provide DataMasque with Ignored keywords. Column names that match Ignored keywords are excluded from Sensitive Data Discovery reports.

Keywords can be added and deleted under the Global Keywords section on the Settings Page. You can also add keywords by uploading a CSV file. The system will detect whether the CSV data is row-based or column-based, and import the keywords accordingly. Note that the system does not support CSV files with multiple rows and columns, i.e. a CSV containing either a single row with multiple values, or single column with multiple rows, but not both, should be uploaded.

Example: regex:^street|postal, which matches any column name beginning with street or postal. For more information please refer to our user guide on regular expressions

Patterns such as schema.table.column or schema.table are also supported for Custom Data Classification keywords and Ignored keywords, but are not supported when prefixed by regex as . can also be used in regular expressions.

Wildcards are also supported by using the * character, for example you can discover or ignore all columns in any table by specifying schema_name.table_name.*

Locality

DataMasque can be configured with a locality setting. Built-in localities are available, or a custom locality can be specified.

The locality is used in two ways:

1. Ruleset Generator: Influences the seed files selected when generating rulesets.
2. Ruleset Interpolation: Can be referenced directly in ruleset YAML files using the {{ locality }} placeholder.

Configuring the Locality

Select a locality from the dropdown menu. Built-in options include common locality codes such as US, AU, and GB. If your desired locality is not listed, select Custom to enter your own value.

If no locality is configured, it defaults to US.

Locality in the Ruleset Generator

The locality setting determines the seed files selected for from_file masks in the generated rulesets. These masks and seed files are used for masking data such as first name, last name, addresses, etc.

The selected seed files will be specific to the chosen locality, provided they exist. If your locality is set to AU (for example), DataMasque will look for these seed files in order, stopping when one exists.

• Custom_AU_firstNames_mixed.csv,
• DataMasque_AU_firstNames_mixed.csv,
• DataMasque_firstNames_mixed.csv

Before selecting the Custom option and setting your locality, you should upload seed files with file names in the same format as existing seed files (DataMasque_locality_* or Custom_locality_* replacing locality with the character code). These new seed files will be selected by the ruleset generator when generating a ruleset. The same logic for which seed file is selected, as described above, for the AU option also applies. If any seed files don't exist for the locality the default(s) will be used.

These files require specific columns in order to work as intended, detailed in the table below. Where prefix can be either DataMasque or Custom.

File Name	Required Columns	Default	Used For Sensitive Data Labels
prefix_locality_firstNames_mixed.csv	firstname-mixed	DataMasque_firstNames_mixed.csv	First Name, Middle Name, Name, Email
prefix_locality_lastNames.csv	lastnames	DataMasque_lastNames_v2.csv	Last Name, Name, Email
prefix_locality_fake_email_suffixes.csv	email-suff	DataMasque_fake_email_suffixes.csv	Email
prefix_locality_addresses.csv	state_long, city, postcode, address	DataMasque_US_addresses.csv	State, City, Post Code, Address
prefix_locality_addresses_real.csv	street_address, suburb	DataMasque_US_addresses_real_V2.csv	Street Address, Suburb
prefix_locality_street_types.csv	street_type, abbreviation	DataMasque_street_types.csv	Street Type, Street Type Abbreviation
prefix_locality_occupations.csv	occupation	DataMasque_occupations.csv	Job Position
prefix_locality_companies.csv	company_name	DataMasque_US_companies.csv	Company

The default seed files can be used as a reference for creating your own custom locality seed files.

Note: The ruleset generator applies special formatting for East Asian custom localities that use hierarchical addressing (large-to-small format): JP (Japan), CN (China), and KR (South Korea).

For these localities, the address sensitive data label will be formatted as: Postcode (postcode) → State/Province (state_long) → City (city) → Street/Block (address).

Locality Interpolation in Rulesets

The locality setting can be referenced directly in ruleset YAML files, using the {{ locality }} placeholder. This allows you to create rulesets that dynamically adapt based on the configured locality.

Note: Values containing the {{ locality }} placeholder must be enclosed in quotes (single or double) to ensure they are interpreted as quoted scalars in YAML.

Example

The following ruleset snippet contains a {{ locality }} placeholder, which will be interpolated into the seed_file parameter. Note that the entire seed_file parameter is enclosed in double quotes.

masks:
  - column: first_name
    type: from_file
    seed_file: "DataMasque_{{ locality }}_addresses.csv"
    seed_column: address

After interpolation (with locality set to US):

masks:
  - column: first_name
    type: from_file
    seed_file: "DataMasque_US_addresses.csv"
    seed_column: address

When a masking run executes, {{ locality }} is automatically substituted with the current locality value.