# Getting Started

The how-to guides linked on this page illustrate how to integrate Snowflake with Immuta.

**Requirement**: Snowflake Enterprise Edition

## Configure your Snowflake integration

These guides provide information on the recommended features to enable with Snowflake, or see the [Detect use case](https://documentation.immuta.com/2024.3/detect-your-activity/getting-started) for a comprehensive guide on the benefits of these features and other recommendations.

1. [Configure your Snowflake integration](https://documentation.immuta.com/2024.3/integrations/snowflake/how-to-guides/enterprise) with the following features enabled:
   * [Snowflake table grants](https://documentation.immuta.com/2024.3/integrations/snowflake/reference-guides/table-grants-overview) *(enabled by default)*
   * [Snowflake low row access policy mode](https://documentation.immuta.com/2024.3/integrations/snowflake/reference-guides/low-row-access-overview) *(enabled by default)*
   * [Snowflake query audit](https://documentation.immuta.com/2024.3/detect-your-activity/audit/reference-guides/query-audit-logs/snowflake) *(enabled by default)*
2. Select **None** as your [default subscription policy](https://documentation.immuta.com/2024.3/application-settings/how-to-guides/config-builder-guide#manage-the-default-subscription-policy).
3. [Integrate an IAM with Immuta](https://documentation.immuta.com/2024.3/people/getting-started).
4. [Map external user IDs from Snowflake to Immuta](https://documentation.immuta.com/2024.3/people/immuta-users/how-to-guides/external-user-mapping).

## Register metadata

These guides provide instructions for organizing your Snowflake data to align with your governance structure.

1. [Register Snowflake data in Immuta as data sources.](https://documentation.immuta.com/2024.3/data-and-integrations/registering-metadata/register-data-sources/query-backed-tutorial)
2. [Recommended: Organize your data sources into domains and assign domain permissions to accountable teams.](https://documentation.immuta.com/2024.3/data-and-integrations/domains/configure-domains)

## [Detect your user activity](https://documentation.immuta.com/2024.3/detect-your-activity/detect-introduction)

These guides provide step-by-step instructions for auditing and detecting your users' activity, or see the [Detect use case](https://documentation.immuta.com/2024.3/detect-your-activity/getting-started) for a comprehensive guide on the benefits of these features and other recommendations.

1. [Set up audit export to S3](https://documentation.immuta.com/2024.3/detect-your-activity/audit/how-to-guides/enable-uam) or [ADLS Gen2](https://documentation.immuta.com/2024.3/detect-your-activity/audit/how-to-guides/export-adls) for your [Snowflake audit logs](https://documentation.immuta.com/2024.3/detect-your-activity/audit/reference-guides/query-audit-logs/snowflake).
2. [View the Detect dashboards to see the activity of your registered users on registered tables](https://documentation.immuta.com/2024.3/detect-your-activity/detection/use-dashboards).

## [Discover your data](https://documentation.immuta.com/2024.3/discover-your-data/discover-introduction)

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

1. [Enable sensitive data discovery (SDD)](https://documentation.immuta.com/2024.3/discover-your-data/data-discovery/how-to-guides/global-sdd).
2. [Register a subset of your tables](https://documentation.immuta.com/2024.3/data-and-integrations/registering-metadata/register-data-sources/query-backed-tutorial) to configure and validate SDD.
3. [Configure SDD](https://documentation.immuta.com/2024.3/discover-your-data/getting-started#configure-sdd-for-your-data) to discover entities of interest for your policy needs.
4. [Validate that the SDD tags are applied correctly](https://documentation.immuta.com/2024.3/discover-your-data/data-discovery/how-to-guides/manage-sdd-tags#verify-discovered-tags).
5. Register your remaining tables at the [schema level](https://documentation.immuta.com/2024.3/data-and-integrations/registering-metadata/register-data-sources/query-backed-tutorial#select-virtual-population) with [schema monitoring turned on](https://documentation.immuta.com/2024.3/data-and-integrations/registering-metadata/register-data-sources/query-backed-tutorial#enable-or-disable-schema-monitoring).
6. [Implement classification to categorize and tag sensitive data](https://documentation.immuta.com/2024.3/discover-your-data/getting-started#implement-classification).

## [Secure your data](https://documentation.immuta.com/2024.3/secure-your-data/secure-introduction)

These guides provide instructions for configuring and securing your data with governance policies, or see the [Secure use cases](https://documentation.immuta.com/2024.3/secure-your-data/getting-started-with-secure) for a comprehensive guide on creating policies to fit your organization's use case.

1. [Create a global subscription policy](https://documentation.immuta.com/2024.3/secure-your-data/authoring-policies-in-secure/section-contents/how-to-guides/subscription-policy-tutorial).
2. 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 [<mark style="color:blue;">`SECONDARY ROLES ALL`</mark>](https://docs.snowflake.com/en/sql-reference/sql/use-secondary-roles) 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.
3. [Create a global data policy](https://documentation.immuta.com/2024.3/secure-your-data/authoring-policies-in-secure/data-policies/how-to-guides/data-policy-tutorial).
4. 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.
5. Once all Immuta policies are in place, remove or alter old roles.