Skip to content

Column Masking Based on Group Membership

Column masking based on group membership allows organizations to control the visibility of sensitive data (PII) depending on whether a user belongs to specific business groups.
This approach ensures that authorized users can see clear data, while unauthorized users automatically see masked values, without changing application logic or Snowflake roles.

This is commonly used when the same Snowflake role is shared across teams, but data visibility must still vary by user responsibility.

Business Use Case

Consider a customer table that contains sensitive information such as names, email addresses, or government IDs.

  • Compliance or HR teams may require access to the clear data to perform audits or investigations.
  • Analytics or reporting teams should still access the table, but must not see sensitive values.
  • Both teams may be using the same Snowflake role for operational reasons.

Instead of creating multiple roles or duplicating data, Privacera allows you to:

  • Grant clear access only to users who belong to approved groups
  • Automatically mask the same column for all other users

This ensures least-privilege access, improves data security, and simplifies role management.

How It Works (User Perspective)

  • Privacera evaluates group membership at runtime
  • If the user belongs to an allowed group → masking is skipped
  • If the user does not belong to the group → masking is enforced
  • If the user lacks table permission → access is denied

This decision is applied before data is returned to Snowflake, ensuring consistent enforcement.

Implementation Steps

1. Set Group Membership

Ensure users are assigned to appropriate groups in Privacera.
Group membership can be managed in either of the following ways:

  • Synced from an Identity Provider (IdP)
  • Manually assigned within Privacera

Example groups: - Group-1 - Group-2

2. Define Column Masking Policy in Privacera

Create a column masking policy with the following logic:

  • Apply masking to the column (example: member_name)
  • Grant access to the public group
  • Add a condition that excludes users in specific groups

Policy Condition

Text Only
1
!IS_IN_GROUP('Group-1') && !IS_IN_GROUP('Group-2')

How the Policy Logic Works

  • Users NOT in Group-1 AND Group-2
    → Column masking is applied

  • Users who belong to Group-1 OR Group-2
    → Column masking is skipped, and clear data is shown

This logic allows Privacera to dynamically decide whether sensitive data should be masked at query runtime, based on the user’s group membership.

Validate Access

The following scenarios demonstrate how this policy behaves for different types of users.

Scenario 1 – Valid Group Membership

User Context
  • User is a member of Group-1 or Group-2
  • Uses a Snowflake role that has permission to the table (for example, TEST_ROLE1)
Action
SQL
1
SELECT * FROM table_cdo;
Expected Result
  • The column member_name is displayed in clear text
  • No masking is applied
Why This Happens

The user satisfies both required conditions: - Valid group membership - Valid Snowflake table permission

Since the group condition evaluates to false, masking is skipped.

Scenario 2 – Missing Group Membership

User Context
  • User is NOT a member of Group-1 AND Group-2
  • Uses a Snowflake role that has permission to the table (for example, TEST_ROLE1)
Action
SQL
1
SELECT * FROM table_cdo;
Expected Result
  • Rows are returned successfully
  • The column member_name is masked (hashed)
Why This Happens
  • Table access is allowed by the Snowflake role
  • The group condition evaluates to true
  • Privacera enforces column masking before returning data

Scenario 3 – Missing Group Membership + No Table Permission

User Context
  • User is NOT a member of Group-1 AND Group-2
  • Uses a Snowflake role that does not have permission to the table
    (for example, TEST_ROLE2)
Action
SQL
1
SELECT * FROM table_cdo;
Expected Result
  • Access to the table is denied
Why This Happens

Privacera enforces authorization before masking.
Since the user does not have table permission, the query is blocked and no data is returned.

Key Takeaways

  • Group-based masking enables fine-grained control over sensitive data visibility
  • Works even when Snowflake roles are shared across teams
  • Avoids the need to maintain multiple copies of sensitive data
  • Aligns with least-privilege access and compliance best practices