Dynamic Data Masking
by
Janardhan Bandi
Agenda
• Column level security
• Masking policies
• Dynamic data masking
• Creating masking policies
• Applying masking policies
• Altering or Dropping policies
Column Level Security
• Column-level Security in Snowflake allows the application of a masking policy to a column
within a table or view.
• To protect sensitive data like customers PHI, bank balance info etc.
• Column-level Security includes two features:
• Dynamic Data Masking
• External Tokenization
• Dynamic Data Masking is a is the process of hiding data by masking with other
characters. We can create masking policies to hide the data present in columns.
• Tokenization is the process of hiding sensitive data by replacing it with cypher text.
External Tokenization makes use of masking policies with external functions created at
external cloud provider side.
Masking Policies
• Snowflake supports masking policies to protect sensitive data from unauthorized access while
allowing authorized users to access at query runtime.
• Masking policies are schema level objects.
• Masking policies can include conditions and functions to transform the data when those conditions
are met.
• Same masking policy can be applied on multiple columns.
Dynamic data masking
• Sensitive data in Snowflake is not modified in an existing table. But when users execute a query it
will apply the masking dynamically and displays the masked data, hence called dynamic data
masking.
• The data can be masked, partially masked, obfuscated(unclear), or tokenized data.
• Unauthorized users can operate the data as usual but they can't view the data.
• Mostly masking policies applied based on the Roles.
Creating Masking Policies
• Masking policies can be created with CREATE MASKING POLICY command as shown below.
// Based on the role
create masking policy employee_ssn_mask as (val string) returns string ->
case when current_role() in ('PAYROLL') then val else '******’ end;
// Based on some condition
create masking policy email_visibility as
(email varchar, visibility string) returns varchar ->
case
when current_role() = 'ADMIN' then email
when visibility = 'Public' then email
else '***MASKED***'
end;
Applying Masking Policies
• After creating masking policies, we can apply them wherever we have a requirement to
protect the data or hide that data.
• This policy should be applied at column level.
• We can apply same policy on multiple columns from multiple tables and views.
// Setting or applying Masking Policy
ALTER TABLE public.employee MODIFY COLUMN ssn
SET MASKING POLICY employee_ssn_mask;
ALTER TABLE public.employee
MODIFY COLUMN ssn SET MASKING POLICY employee_ssn_mask,
MODIFY COLUMN email SET MASKING POLICY email_visibility USING(email, visibility);
Removing Masking Policies
// Unsetting or removing Masking Policy
ALTER TABLE public.employee
MODIFY COLUMN ssn UNSET MASKING POLICY;
ALTER TABLE public.employee
MODIFY COLUMN ssn UNSET MASKING POLICY,
MODIFY COLUMN email UNSET MASKING POLICY;
Altering and Dropping Policies
// Altering or modifying
ALTER MASKING POLICY policy_name SET BODY -> <Case Statement>;
ALTER MASKING POLICY policy_name RENAME TO new_policy_name;
// Dropping
DROP MASKING POLICY policy_name;
Limitations:
1. Before dropping masking policies, we should unset them.
2. Data type of input and output values must be same.
Thank You
