Automate DSPM Data Masking in Snowflake - Netskope Technical Documentation

Overview

As organizations increasingly rely on cloud data platforms for business intelligence, protecting sensitive data across the entire stack—including Snowflake—is imperative. When you query data from a Snowflake worksheet or any other platform, any data field tagged as PII during the discovery process can be dynamically masked without creating copies or views.

The following example illustrates the enforcement of Social Security Numbers (SSN) masking via Netskope DSPM workflows, after Snowflake has been connected to DSPM using the recommended onboarding steps.

Prerequisites

Before you can automate masking in Snowflake using Netskope DSPM, ensure the following requirements are met:

Snowflake is connected to DSPM using the latest onboarding steps.
Your Snowflake account must be connected using the current onboarding flow. This flow ensures the system:
- Detects Snowflake database types (Standard, Imported/Shared, Application, Personal).Applies conditional privilege grants based on database type.Skips personal databases that cannot be granted to roles.Handles special cases such as the SNOWFLAKE system database using GRANT IMPORTED PRIVILEGES.
For step‑by‑step connection instructions, see the Connect Snowflake to DSPM article.
Service account and roles are configured as recommended.
The examples in this article assume:
- A dedicated Snowflake service account has been created for DSPM.
- The service account role has the privileges granted by the onboarding script, based on the detected database types.
- Snowflake masking policies are managed in accordance with your internal Snowflake security standards.

Protecting Sensitive Information

Netskope DSPM offers a solution for sensitive data discovery that automates detecting and classifying sensitive data across Snowflake and your cloud data ecosystem. By registering data sources, you can standardize the classification of sensitive identifiers, enabling you to create dynamic and scalable policies.

The masking workflows described in this article apply only to databases and schemas where the DSPM service account role has the appropriate privileges. Databases that are intentionally skipped during onboarding (for example, personal databases that cannot be granted to roles) will not be scanned or governed by Netskope DSPM and therefore will not be affected by masking workflows.

To learn more about configuring Netskope DSPM to classify your Snowflake data, please visit our Connect Snowflake to DSPM article.

Orchestrating Snowflake Masking Policies

Using the Netskope DSPM policy engine, you can create Classification-type policies and define conditions to target the fields you want to mask. Such policies can drive the assignment of appropriate dynamic masking policies within Snowflake, for all databases and tables that were made accessible to DSPM during the onboarding process.

For more details on creating policies, visit ourPolicy Management article.

Trigger Snowflake Policies

Netskope DSPM policies can trigger external workflows to automatically remediate critical issues. In this case, DSPM triggers a Netskope-provided AWS Lambda function that automatically enforces Snowflake’s dynamic masking policies to keep individual sensitive data safe.

These workflows operate only on Snowflake objects that were successfully granted privileges during onboarding (based on database type detection and conditional privilege grants). If a database was skipped or could not be granted privileges—for example, certain shared or personal databases—Netskope DSPM will not be able to enforce masking policies on that database.

Review Outcomes Within Snowflake

To confirm the masking is active, query the data in Snowflake using different user roles.

Privileged Access (Unmasked): When logged in as a user with the ACCOUNTADMIN role (or a specific role defined in your exception policy), the data remains visible in clear text.
Standard Access (Masked): When queried within any other context besides the privileged role, the sensitive data is dynamically masked.

The exact behavior depends on the Snowflake roles and privileges configured during the onboarding process; the examples in this article assume the recommended service account and role configuration from the Connect Snowflake to DSPM guide.