Protecting Data

Learn how Immuta enforces policies on data in your Snowflake environment

In the Snowflake integration, Immuta administers Snowflake privileges on data registered in Immuta. Then, Immuta users who have been granted access to the data sources can query them.

The sequence diagram below outlines the events that occur when an Immuta user who is subscribed to a data source queries it in Snowflake.

Registering a connection

The Snowflake integration is configured and data is registered through connections, an Immuta feature that allows administrators to register data objects in a technology through a single connection to make data registration more scalable for your organization.

Once the Snowflake connection is registered, you can author subscription and data policies in Immuta to enforce access controls.

See the Snowflake integration reference guide for more details about registering a connection.

Protecting data

Subscription policies

When a subscription policy is applied to a data source, users who meet the conditions of the policy will be automatically subscribed to the data source. Immuta creates roles for those users (if an Immuta-generated role for them does not already exist) and grants Snowflake privileges to that role.

Consider the following example that illustrates how Immuta enforces a subscription policy that only allows users in the analysts group to access the yellow-table. When this policy is authored and applied to the data source, Immuta issues a SQL statement in Snowflake that grants the SELECT privilege on yellow-table to Immuta-created roles of users registered in Immuta that are part of the analysts group.

In the image above, the user in the analysts group accesses yellow-table, while the user who is a part of the research group is denied access.

Data policies

After Snowflake objects are registered in Immuta, you can author data policies in Immuta to enforce fine-grained access controls.

When a data policy is applied to a Snowflake data source, Immuta enforces that policy natively in Snowflake. Depending on the policy type, Immuta manages Snowflake row access policies and masking policies on the registered object so that queries return policy-enforced results.

As data policies are created, updated, or removed in Immuta, Immuta updates the corresponding Snowflake policy objects and attachments to keep enforcement in sync. Users continue querying the Snowflake object directly and see policy-enforced data in Snowflake.

See the Data policies page for guidance on authoring data policies in Immuta and the supported data policies for the Snowflake integration.

Comply with column length and precision requirements in a Snowflake masking policy

When a user applies a masking policy to a Snowflake data source, Immuta truncates masked values to align with Snowflake column length (VARCHAR(X) types) and precision (NUMBER (X,Y) types) requirements.

Consider these columns in a data source that have the following masking policies applied.

• Column A (VARCHAR(6)): Mask using hashing for everyone
• Column B (VARCHAR(5)): Mask using a constant REDACTED for everyone
• Column C (VARCHAR(6)): Mask by making null for everyone
• Column D (NUMBER(3, 0)): Mask by rounding to the nearest 10 for everyone

Querying this data source in Snowflake would return the following values:

A	B	C	D
5w4502	REDAC	null	990
6e3611	REDAC	null	750
9s7934	REDAC	null	380

Hashing collisions

Hashing collisions are more likely to occur across or within Snowflake columns restricted to short lengths, since Immuta truncates the hashed value to the limit of the column. (Hashed values truncated to 5 characters have a higher risk of collision than hashed values truncated to 20 characters.) Therefore, avoid applying hashing policies to Snowflake columns with such restrictions.

For more details about Snowflake column length and precision requirements, see the Snowflake behavior change release documentation.

Query performance

When a policy is applied to a column, Immuta uses Snowflake memoizable functions to cache the result of the called function. Then, when a user queries a column that has that policy applied to it, Immuta uses that cached result to dramatically improve query performance.