Implementing pg_columnmask in an end-to-end workflow - Amazon Aurora
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Implementing pg_columnmask in an end-to-end workflow

This section demonstrates a complete implementation of pg_columnmask using a sample employee table with sensitive data. You'll learn how to create custom masking functions, define multiple masking policies with different weight levels for various roles (intern, support, analyst), and observe how users with single or multiple role memberships see different levels of masked data. The examples also cover masking behavior in DML statements with RETURNING clauses, triggers on tables versus views, and policy management operations including renaming, altering weights, and cleanup.

  1. Create a sample table with some sensitive data:

    CREATE SCHEMA hr; CREATE TABLE hr.employees ( id INT PRIMARY KEY, name TEXT NOT NULL, email TEXT, ssn TEXT, salary NUMERIC(10,2) ); INSERT INTO hr.employees VALUES (1, 'John Doe', 'john.doe@example.com', '123-45-6789', 50000.00), (2, 'Jane Smith', 'jane.smith@example.com', '987-65-4321', 60000.00);
  2. Create custom masking functions:

    CREATE OR REPLACE FUNCTION public.mask_ssn(ssn TEXT) RETURNS TEXT AS $$ BEGIN RETURN 'XXX-XX-' || RIGHT(ssn, 4); END; $$ LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION public.mask_salary(salary NUMERIC, multiplier NUMERIC DEFAULT 0.0) RETURNS NUMERIC AS $$ BEGIN RETURN salary * multiplier; END; $$ LANGUAGE plpgsql;
  3. Create multiple policies with different masking levels based on user roles:

    -- Create different roles CREATE ROLE analyst_role; CREATE ROLE support_role; CREATE ROLE intern_role; GRANT USAGE ON SCHEMA hr TO analyst_role, support_role, intern_role; GRANT SELECT ON hr.employees TO analyst_role, support_role, intern_role; ---------------------------------------------------------------------- -- Low-Weight Policy (Intern) CALL pgcolumnmask.create_masking_policy( 'employee_mask_strict', 'hr.employees', JSON_BUILD_OBJECT('name', 'pgcolumnmask.mask_text(name, ''*'')', 'email', 'pgcolumnmask.mask_email(email)', 'ssn', 'pgcolumnmask.mask_text(ssn, ''*'')', 'salary', 'public.mask_salary(salary)')::JSONB, ARRAY['intern_role'], 10 -- Lowest weight ); ---------------------------------------------------------------------- -- Medium-Weight Policy (Support) CALL pgcolumnmask.create_masking_policy( 'employee_mask_moderate', 'hr.employees', JSON_BUILD_OBJECT('email', 'pgcolumnmask.mask_email(email, ''#'')', 'ssn', 'public.mask_ssn(ssn)', 'salary', 'public.mask_salary(salary)')::JSONB, ARRAY['support_role'], 50 -- Medium weight ); ---------------------------------------------------------------------- -- High-Weight Policy (Analyst) CALL pgcolumnmask.create_masking_policy( 'employee_mask_light', 'hr.employees', JSON_BUILD_OBJECT('ssn', 'public.mask_ssn(ssn)', 'salary', 'public.mask_salary(salary, 0.9)')::JSONB, ARRAY['analyst_role'], 100 -- Highest weight );
  4. The following examples demonstrate how different users see data based on their role membership and policy weights.

    -- Create users CREATE USER sarah_intern; GRANT intern_role TO sarah_intern; CREATE USER lisa_support; GRANT support_role TO lisa_support; CREATE USER mike_analyst; GRANT analyst_role TO mike_analyst; CREATE USER ethan_support_intern; GRANT support_role, intern_role TO ethan_support_intern; CREATE USER john_analyst_intern; GRANT analyst_role, intern_role TO john_analyst_intern;

    As an intern (strictest masking):

    SET ROLE sarah_intern; SELECT * FROM hr.employees; id | name | email | ssn | salary ----+------------+------------------------+-------------+-------- 1 | ******** | XXXXXXXX@XXXXXXX.com | *********** | 0.00 2 | ********** | XXXXXXXXXX@XXXXXXX.com | *********** | 0.00

    As a support user (moderate masking):

    SET ROLE lisa_support; SELECT * FROM hr.employees; id | name | email | ssn | salary ----+------------+------------------------+-------------+-------- 1 | John Doe | ########@#######.com | XXX-XX-6789 | 0.00 2 | Jane Smith | ##########@#######.com | XXX-XX-4321 | 0.00

    As an analyst (lightest masking):

    SET ROLE mike_analyst; SELECT * FROM hr.employees; id | name | email | ssn | salary ----+------------+------------------------+-------------+---------- 1 | John Doe | john.doe@example.com | XXX-XX-6789 | 45000.00 2 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00

    As ethan_support_intern user which is both intern and support user:

    SET ROLE ethan_support_intern; -- masking policies appliable to this user: employee_mask_strict and employee_mask_moderate -- id : unmasked because no masking policy appliable on ethan_support_intern -- masks these columns -- name : masked because of employee_mask_strict policy -- email, ssn, salary : both employee_mask_strict and employee_mask_moderate mask these columns -- but employee_mask_moderate will be use because of higher weight SELECT * FROM hr.employees; id | name | email | ssn | salary ----+------------+------------------------+-------------+-------- 1 | ******** | ########@#######.com | XXX-XX-6789 | 0.00 2 | ********** | ##########@#######.com | XXX-XX-4321 | 0.00

    As a john_analyst_intern which is both intern and analyst:

    SET ROLE john_analyst_intern; -- masking policies appliable to this user: employee_mask_strict and employee_mask_light -- id : unmasked because no masking policy appliable on john_analyst_intern -- masks these columns -- name, email : masked because of employee_mask_strict -- ssn, salary : both employee_mask_strict and employee_mask_light mask these columns -- but employee_mask_light will be use because of higher weight SELECT * FROM hr.employees; id | name | email | ssn | salary ----+------------+------------------------+-------------+---------- 1 | ******** | XXXXXXXX@XXXXXXX.com | XXX-XX-6789 | 45000.00 2 | ********** | XXXXXXXXXX@XXXXXXX.com | XXX-XX-4321 | 54000.00