Skip to content

Getting Started with Immuta Detect

Immuta Detect provides value from the moment the dashboards are visible, which can be enabled for organizations with Snowflake, Databricks Spark, and Databricks Unity Catalog integrations. Currently, organizations with Snowflake integrations can get even more value with data sensitivity. To determine and surface the sensitivity of your data access, enable and tune classification.

Completing all the steps below will fully onboard you with Detect:

  1. View Detect dashboards
  2. Show data sensitivity
  3. Adjust and accept data sensitivity
  4. Get historical audit information

Requirements

  • Immuta SaaS instance

Before you begin

Prerequisites:

The onboarding process assumes that these prerequisites have already been set up, but here are the Immuta features and configuration required to enable Detect. Each integration can be used alone or a Snowflake integration can be used with either Databricks Spark or Databricks Unity Catalog. Databricks Spark and Databricks Unity Catalog are not supported together with Detect:

For Snowflake integrations:

  • A Snowflake integration:

    • With governance features: This integration type is enabled by default for all new Snowflake integrations and is required for the audit information needed for Detect.
    • Native query audit enabled: This feature can be enabled when first configuring the integration or when editing the integration.
    • (Recommended) Table grants enabled: While not required, it is recommended to enable this feature to properly audit unauthorized query events. Without it, unauthorized events will still show as successful. Project workspaces cannot be used with table grants, so if your organization relies on them, leave this feature disabled.
    Benefits and limitations of enabling table grants

    With table grants enabled:

    • Unauthorized query events will be audited and present in the Detect dashboards.
    • Table grants will manage the privileges in Snowflake for Immuta tables, making it more efficient than without.

    Without table grants:

    • Unauthorized events are unavailable because users will have successful queries of zero rows, even if they do not have access to the table.
    • You can use project workspaces. Table grants is not compatible with project workspaces. If your organization depends on that capability, table grants is not recommended.

  • Snowflake tables and users registered in Immuta: Detect only audits events by users registered in Immuta on tables registered in Immuta. If you do not register the tables and users, their actions will not appear in the audit records or on the Detect dashboards.

For Databricks Spark integrations:

For Databricks Unity Catalog integrations:

Recommended:

This setting is not required for Detect, but can be used for better functionality:

  • No subscription policy by default: This feature sets the subscription policy of all new data sources to none when they are registered. Using this feature, allows for organizations to register all Snowflake tables in Immuta. Their audit information will appear in the Detect dashboards, but users' access to them will not be impacted by Immuta until a subscription policy is set.

View Detect dashboards

Requirements:

Immuta permission: USER_ADMIN

Actions:

  1. Grant users the AUDIT permission to see the Detect dashboards.
  2. Navigate through Immuta Detect and explore the dashboards that visualize user and query audit information for your data environment.

These actions will result in users seeing the Detect dashboards containing information on the audit events in your data environment. These dashboards will not contain any information on the sensitivity of your data.

To see sensitivity information using a Snowflake integration, proceed with the steps below.

Show data sensitivity

Only available with Snowflake integrations.

There are two options to tag data and activate classification frameworks to determine the sensitivity of your data:

  1. (Recommended) Use Immuta sensitive data discovery (SDD) to automatically categorize and tag your data: This option is the smoothest onboarding experience because it is the most automated process. You will not need to manually tag your data, and the framework to determine sensitivity is already set to use the SDD tags.
  2. Use your organization's external tags: This option requires more manual configuration, but is best for organizations that have already configured tags for their tables. Please contact your Immuta representative for guidance.

After completing either of the tutorials above, data sources are tagged with entity tags and classification tags. Once users start querying data, and after the data latency with Snowflake, the Detect dashboards will show audit information with sensitivity information.

If you notice some sensitivity types are not appearing as you expect, proceed with the step below.

Adjust and accept data sensitivity

Only available with Snowflake integrations.

Requirements:

Immuta permission: AUDIT and GOVERNOR

Actions:

After Immuta Detect has run SDD and the Immuta DSF, it may be necessary to adjust the resulting tags based on your organization's data, security, and compliance needs. Your Immuta representative will work with you during the preview to customize SDD and Immuta DSF to output the desired tags and classification of data sources.

  1. Configure rules for SDD
  2. Create a new global framework for SDD
  3. Adjust and accept classification tags

After completing the tutorials above, all data appears as the appropriate sensitivity type on the Detect dashboards.

Get historical audit information

Only available with Snowflake integrations.

Requirements:

Immuta permission: APPLICATION_ADMIN

Action:

Consult your Immuta representative to enable historical audit from Snowflake. Enabling historical audit populates your Immuta Detect with up to one year of data platform activity history for all data sources, but can be customized to less time. It will use the tags applied at the time it is enabled, so ensure the tags represent what you want before completing this step: Enable historical audit