Getting Started

The how-to guides linked on this page illustrate how to integrate Snowflake with Immuta to secure your data with governance policies, discover what data types and sensitive data should be secured, and observe your users' activity to ensure risky user access is caught and addressed.

Requirement: Snowflake Enterprise Edition

Configure your Snowflake integration

Configuring a Snowflake integration is required for Detect, Discover, and Secure. These guides provide information on the recommended features to enable with Snowflake, or see the Detect use case for a comprehensive guide on the benefits of these features and other recommendations.

  1. Configure your Snowflake integration with the following features enabled:

  2. Select None as your default subscription policy.

These guides provide step-by-step instructions for auditing and detecting your users' activity, or see the Detect use case for a comprehensive guide on the benefits of these features and other recommendations.

These guides provide step-by-step instructions for discovering, classifying, and tagging your data.

  1. Register a subset of your tables to configure and validate SDD.

  2. Configure SDD to discover entities of interest for your policy needs.

  3. Register your remaining tables at the schema level with schema monitoring turned on.

These guides provide step-by-step instructions for configuring and securing your data with governance policies, or see the Secure use cases for a comprehensive guide on creating policies to fit your organization's use case.

  1. Validate the policy. You do not have to validate every policy you create in Immuta; instead, examine a few to validate the behavior you expect to see:

    1. Validate that the Immuta users impacted now have an Immuta role in Snowflake dedicated to them.

    2. Validate that when acting under the Immuta role those users have access to the table(s) in question.

    3. Validate that users without access in Immuta can still access the table with a different Snowflake role that has access.

    4. Validate that a user with SECONDARY ROLES ALL enabled retains access if

      • they were not granted access by Immuta and

      • they have a role that provides them access, even if they are not currently acting under that role.

  2. Validate that a user with a role that can access the table in question (whether it's an Immuta role or not) sees the impact of that data policy.

  3. Once all Immuta policies are in place, remove or alter old roles.

Last updated

Other versions

SaaS2024.32024.1

Copyright © 2014-2024 Immuta Inc. All rights reserved.