> For the complete documentation index, see [llms.txt](https://documentation.immuta.com/SaaS/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.immuta.com/SaaS/configuration/integrations/snowflake/reference-guides/snowflake-overview/protecting-data.md).
# Protecting Data
{% hint style="info" %}
**New connections**
The [new connections flow](/SaaS/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/new-connections-reference-guide.md) documented here is available and released to select tenants.
{% endhint %}
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](/SaaS/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/new-connections-reference-guide.md), 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](/SaaS/configuration/integrations/snowflake/reference-guides/snowflake-overview.md#registering-a-connection) 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](#user-content-fn-1)[^1]. 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](https://docs.snowflake.com/en/user-guide/security-row.html) and [masking policies](https://docs.snowflake.com/en/user-guide/security-column.html) 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](/SaaS/govern/secure-your-data/authoring-policies-in-secure/data-policies/how-to-guides/data-policy-tutorial.md) for guidance on authoring data policies in Immuta and the [supported data policies](/SaaS/govern/secure-your-data/authoring-policies-in-secure/data-policies/reference-guides/data-policies.md#data-policy-support-matrix-integrations) 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)`](https://docs.snowflake.com/en/sql-reference/data-types-text#varchar) types) and precision ([`NUMBER (X,Y)`](https://docs.snowflake.com/en/sql-reference/data-types-numeric) 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` |
{% hint style="info" %}
**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.
{% endhint %}
For more details about Snowflake column length and precision requirements, see the [Snowflake behavior change release](https://docs.snowflake.com/en/release-notes/bcr-bundles/2024_04/bcr-1355) documentation.
#### **Query performance**
When a policy is applied to a column, Immuta uses [Snowflake memoizable functions](https://docs.snowflake.com/en/developer-guide/udf/sql/udf-sql-scalar-functions#memoizable-udfs) 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.
[^1]: If the **require manual subscription** option is selected for the policy, these users will have to manually subscribe to the data.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://documentation.immuta.com/SaaS/configuration/integrations/snowflake/reference-guides/snowflake-overview/protecting-data.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.