Skip to content

Native Snowflake Access Patterns

Audience: System Administrators, Data Owners, and Data Users

Content Summary: This page describes the Native Dynamic Snowflake access pattern, through which Immuta applies policies directly in Snowflake, allowing you to use the Snowflake Web UI and your existing BI tools and have per-user policies dynamically applied at query time and the Native Snowflake Workspace access pattern, through which Immuta applies policies directly in Snowflake within the context of a project.

Native Dynamic Snowflake

Native Dynamic Snowflake completely eliminates role bloat, as all views are accessible through the PUBLIC role and access controls are applied in the view, allowing customers to leverage Immuta's powerful set of attribute-based policies. Additionally, users can continue using roles to enforce compute-based policies through "warehouse" roles, without needing to grant each of those roles access to the underlying data or create multiple views of the data for each specific business unit.

Native Dynamic Snowflake can be used on its own or together with Native Snowflake Workspaces.

Enable Native Dynamic Snowflake

Native Dynamic Snowflake is enabled the same way that Snowflake workspaces are enabled through the App Settings page.

Snowflake Configuration

Once Snowflake has been enabled on an instance, all future Snowflake data sources will also be created natively within the immuta database of the linked Snowflake instance. In addition to creating views, Immuta will also periodically sync user metadata to a system table within the Snowflake instance.

Sync Views and Data Sources

This access pattern leverages webhooks to keep Snowflake views up-to-date with the corresponding Immuta data sources. Whenever a data source or policy is created, updated, or disabled, a webhook will be called that will create, modify, or delete the native Snowflake view.

The SQL that makes up all views includes a join to the secure view: immuta_system.user_profile. This view is a select from the immuta_system.profile table (which contains all Immuta users and their current groups, attributes, projects, and a list of valid tables they have access to) with a constraint immuta__userid = current_user() to ensure it only contains the profile row for the current user. This secure view is readable by all users and will only display the data that corresponds to the user executing the query.

Note: The immuta_system.profile table is updated through webhooks whenever a user's groups or attributes change, they switch projects, they acknowledge a purpose, or when their data source access is approved or revoked. The profile table can only be read and updated by the Immuta system account.

Secure and Non-Secure Views

When creating a native Snowflake data source, users have the option to use a regular view (traditional database view) or a secure view; however, according to Snowflake's documentation , "the Snowflake query optimizer, when evaluating secure views, bypasses certain optimizations used for regular views. This may result in some impact on query performance for secure views." To use the data source with both Native Dynamic Snowflake and Native Snowflake Workspaces, secure views are necessary. Note: If HIPAA compliance is required, secure views must be used.

Snowflake Native View

Non-Secure View Policy Implications

When using a non-secure view, certain policies may leak sensitive information. In addition to the concerns outlined here, there is also a risk of someone exploiting the query optimizer to discover that a row exists in a table that has been excluded by row-level policies. This attack is mentioned here in the Snowflake documentation.

Policies that will not leak sensitive information

  • masking by making NULL, using a constant, or by rounding (date/numeric)
  • minimization row-level policies
  • date-based row-level policies
  • k-anonymization masking policies (these are generated as a whitelist)

Policies that could leak sensitive information

  • masking using a regex will show the regex being applied. In general this should be safe, but if you have a regex policy that removes a specific selector to redact (e.g., a regex of /123-45-6789/g to specifically remove a single SSN from a column), then someone would be able to identify columns with that value.
  • in conditional masking and custom WHERE clauses including “Right To Be Forgotten,” the custom SQL will be visible, so for a policy like "only show rows where COUNTRY NOT IN(‘UK’, ‘AUS’)," users will know that it’s possible there is data in that table containing those values.

Policies that will leak potentially sensitive information

These policies leak information sensitive to Immuta, but in most cases would require an attacker to reverse the algorithm. In general these policies should be used with secure views:

  • masking using hashing will include the salt used
  • numeric and categorical local differential privacy will include the salt used
  • reversible masking will include both a key and an IV
  • format preserving masking will include a tweak, key, an alphabet range, prefix, pad to length, and checksum id if used

Policy Enforcement

The data sources themselves have all the Data policies included in the SQL through a series of CASE statements that determine which view of the data a user will see. Row-level policies are applied as top-level WHERE clauses, and usage policies (purpose-based or subscription-level) are applied as WHERE clauses against the user_profile JOIN. The access_check function allows Immuta to throw custom errors similar to the Query Engine when a user lacks access to a data source because they are not subscribed to the data source, they are operating under the wrong project, or they cannot view any data because of policies enforced on the data source.

Snowflake Database Structure

By default, all native views are created within the immuta database, which is accessible by the PUBLIC role, so users acting under any Snowflake role can connect. All views within the database have the SELECT permission granted to the PUBLIC role as well, and access is enforced by the access_check function built into the individual views. Consequently, there is no need for users to manage any role-based access to any of the database objects managed by Immuta.

Limitations

  • Immuta is unable to create a corresponding view in Snowflake for data sources

    • that have a differential privacy policy applied,
    • with an external policy handler, or
    • that are using the Advanced Rules DSL.
  • Certain interpolation functions can also block the creation of a native view, specifically @interpolatedComparison() and @iam.

Native Snowflake Workspaces

Snowflake workspaces allow users to access protected data directly in Snowflake without having to go through the Immuta Query Engine.

Typically, Immuta applies policies by forcing users to query through the Query Engine, which acts like a proxy in front of the database Immuta is protecting. However, Snowflake secure views make this process unnecessary. Instead, Immuta enforces policy logic on data and represents it as secure views in Snowflake. However, since secure views are static, creating a secure view for every unique user in your organization for every table in your organization would result in secure view bloat. Immuta projects address this problem by virtually grouping users and tables and equalizing users to the same level of access, ensuring that all members of the project see the same view of the data. Consequently, all members share one secure view.

While interacting directly with Snowflake secure views in these workspaces, users can create derived data sources and collaborate with other project members at a common access level. Because these derived data sources will inherit all appropriate policies, that data can then be shared outside the project. Additionally, derived data sources use the credentials of the Immuta system Snowflake account, which will allow them to persist after a workspace is disconnected.

Native Snowflake Workspaces can be used independently or with Native Dynamic Snowflake.

Policy Enforcement

Immuta enforces policy logic on data and represents it as secure views in Snowflake. Because projects group users and tables and equalize members to the same level of access, all members will see the same view of the data and, consequently, will only need one secure view. Changes to policies immediately propagate to relevant secure views.

Mapping Projects to Secure Views

Immuta projects are represented as Session Contexts within Snowflake. As they are linked to Snowflake, projects automatically create corresponding

  • roles in Snowflake: IMMUTA_[project name]
  • schemas in the Snowflake IMMUTA database: [project name]
  • secure views in the project schema for any table in the project

If users switch projects, they simply change their Snowflake Session Context to the appropriate Immuta project. If users are not entitled to a data source contained by the project, they will not be able to access the Context in Snowflake until they have access to all tables in the project. If changes are made to a user's attributes, the changes will immediately propagate to the Snowflake context.

Using Immuta with an Existing Snowflake Account

The following steps allow Immuta to be used with existing Snowflake accounts.

  1. Immuta is configured to integrate with the organization’s Snowflake account and (optionally) share a single sign on (such as Okta), allowing users in Immuta to map to the same users in Snowflake. (Alternatively, that mapping can be inferred by using the same usernames in both Snowflake and Immuta.)

  2. CREATE_DATA_SOURCE permissions are granted to specific users to allow them to expose Snowflake table metadata and enforce policies.

  3. If tags are used to drive policies, users can manually add tags when tables are imported, Immuta can automatically tag sensitive data (if Sensitive Data Detection is enabled), or users can pull tags from external catalogs that are mapped to the tables being exposed.

  4. Policies are created and enforced on tables.

  5. The CREATE_PROJECT permission is granted to specific users so they can create their own Immuta projects and create the appropriate Snowflake contexts. These users can drive what projects and hence what Snowflake contexts exist. Note: When users leave a project or a project is deleted, that Snowflake context will be removed from their Snowflake accounts.

  6. The CREATE_DATA_SOURCE_IN_PROJECT permission is given to specific users so they can expose their derived tables in the project; the derived tables will inherit the policies, and then the data can be shared outside the project.

  7. Users access data only through secure views in Snowflake (via Immuta projects), which significantly decreases the amount of role management for administrators in Snowflake. Organizations should also consider having a user in Snowflake who is able to create databases and make GRANTs on those databases and having separate users who are able to read and write from those tables.

Benefits

  • Few roles to manage in Snowflake; that complexity is pushed to Immuta, which is designed to simplify it.
  • A small set of users has direct access to raw tables; most users go through secure views only, but raw database access can be segmented across departments.
  • Policies are built by the individual database administrators within Immuta and are managed in a single location, and changes to policies are automatically propagated across thousands of tables’ secure views.
  • Self-service access to data based on data policies.
  • Users work in various contexts in Snowflake natively, based on their collaborators and their purpose, without fear of leaking data.
  • All policies are enforced natively in Snowflake without performance impact.

    • Security is maintained through Snowflake primitives (roles and secure views).
    • Performance and scalability is maintained (no proxy).
  • Policies can be driven by metadata, allowing massive scale policy enforcement with only a small set of actual policies.

  • Derived tables can be shared back out through Immuta, improving collaboration.
  • User access and removal are immediately reflected in secure views.

Limitations

  • Snowflake workspaces do not support differential privacy policies. Any Snowflake sources with differential privacy policies applied will not be created within the native Snowflake workspace.
  • Native derived data sources can't be query-backed.