Enhancing data privacy: a guide to Dynamic Data Masking in Snowflake

Let us start by analyzing the two main components involved: dbt and Snowflake.

dbt (Data Build Tool) is an open-source tool designed for data transformation and modeling within modern data warehouses.

Snowflake is a cloud-based data warehouse platform providing flexible, scalable and completely managed services for storing and analyzing large data volumes.

The data transformation and modeling capabilities of dbt combined with the instant scalability and the cloud-based data warehousing offered by Snowflake make it easier for data teams to build, manage and analyze data pipelines.

dbt_snow_mask is a package designed to work with dbt to automate the application of masking policies in Snowflake by exploiting the meta property in dbt models.

In this way, it is easier to manage and apply data masking consistently across Snowflake data warehouses.

Key features and benefits of dbt_snow_mask

• Automation, consistency and scalability: dbt_snow_mask automates the application of arbitrarily complex Snowflake’s masking policies using definitions within the dbt’s meta configs, reducing manual effort. This ensures consistency, by centrally managing policies in dbt, and scalability, by providing data masking across all relevant data.
  
  
• Customized masking policy: the package supports the creation of custom masking policies that can be tailored to specific data fields and business requirements. Through this flexibility, organizations can define how data should be masked based on their unique security needs and compliance restrictions.
  
  
• Simplified data security management: integrating masking criteria into the dbt workflow using this package simplifies the management and implementation of data security measures. In this way, data are constantly protected, reducing the risk of exposure, and organizations can track and verify who has access to sensitive data and under what circumstances.

How it works & Example usage

This section will present how to apply a masking policy to a model; similar considerations can be made if, instead of a model, one were to consider a source or a snapshot.

1. First of all, the package must be installed:

1.a) Add the dbt_snow_mask package to the packages.yml file in the dbt project:

2. By default, the masking policies are created in the database-schema pair associated with the target specified in the profiles.yml file.

This behaviour can be changed by acting on the parameters passed to the dbt_project.yml file and use a common database or a common schema:

2.a) Use a common database.
By setting the following, optional, parameters the database and schema where the masking polices are created in can be changed:

• use_common_masking_policy_db: flag to enable or not the usage of a common pair database-schema for all masking policies. Valid values are ‘True’ or ‘False’.
• common_masking_policy_db: the database name for creating masking policies.
• common_masking_policy_schema: the schema name for creating masking policies.
• create_masking_policy_schema: flag whose valid values are ‘True’ or ‘False’. When set to ‘False’, helps to avoid creating schema if the dbt role does not have access to create schema. The default value is ‘True’.

Example: vars config in dbt_project.yml file to enable using a common masking policy database, with database name set to “DB_NAME”, schema name set to “SCHEMA_NAME”, avoiding creating schema if the dbt role does not have access to create schema:

2.b) Use a common schema (in the current database).
By setting the following, optional, parameters only the schema that the masking polices are created in can be changed:

• use_common_masking_policy_schema_only: flag to enable the usage or not of a common schema in the current database for all masking policies. Valid values are ‘True’ or ‘False’.
• common_masking_policy_schema: the schema name for creating masking policies.
• create_masking_policy_schema: flag whose valid values are ‘True’ or ‘False’. When set to ‘False’, helps to avoid creating schema if the dbt role does not have access to create schema. The default value is ‘True’.

Example: vars config in dbt_project.yml file to enable using a common masking policy schema, with schema name set to “SCHEMA_NAME”, avoiding creating schema if the dbt role does not have access to create schema: