This section contains information about private connectivity options for Databricks integrations.

Overview

The Immuta SaaS platform supports private connectivity to Databricks on AWS and the Azure Databricks Service. This allows customers to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.

Support for AWS PrivateLink is available in most regions across Immuta's Global Segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.

Support for Azure Private Link is available in all Databricks-supported Azure regions.

Configuration Guides

• AWS PrivateLink

• Azure Private Link

This section contains information about private connectivity options for Snowflake integrations.

Overview

The Immuta SaaS platform supports private connectivity to Snowflake accounts hosted in both AWS and Azure. This allows customers to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.

Support for AWS PrivateLink is available in most regions across Immuta's Global Segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.

Support for Azure Private Link is available in all Snowflake-supported Azure regions.

Configuration Guides

• AWS PrivateLink

• Azure Private Link

AWS PrivateLink provides private connectivity from the Immuta SaaS platform to customer-managed Snowflake accounts hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.

This feature is supported in most regions across Immuta's Global Segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.

Requirements

• You have an Immuta SaaS tenant.

• Your Snowflake account is hosted on AWS.

• Your Snowflake account is on the Business Critical Edition.

• You have ACCOUNTADMIN role on your Snowflake account to configure the Private Link connection.

• You have enabled AWS PrivateLink for Snowflake.

Configure Snowflake with AWS PrivateLink

1. In your Snowflake environment, run the following SQL query, which will return a JSON object with the connection information you will need to include in your support ticket:

   Copy

   select SYSTEM$GET_PRIVATELINK_CONFIG()

2. Copy the returned JSON object into a support ticket with Immuta Support to request for the feature to be enabled on your Immuta SaaS tenant.

3. Configure the Snowflake integration.

4. Register your tables as Immuta data sources.

AWS PrivateLink provides private connectivity from the Immuta SaaS platform to customer-managed Starburst (Trino) Clusters hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.

This feature is supported in most regions across Immuta's Global Segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.

Requirements

• You have an Immuta SaaS tenant.

• Your Starburst (Trino) Cluster is hosted on AWS.

• You have set up an AWS PrivateLink Service for your Starburst Cluster endpoints.

  • If you have configured Private DNS Hostnames on your PrivateLink Service, the domain ownership must be verifiable via a public DNS zone. This means that you cannot use a Top-Level Domain (TLD) that is not publicly resolvable, e.g. starburst.mycompany.internal.

  • If you are using TLS, the presented certificate must have the Fully-Qualified Domain Name (FQDN) of your cluster as a Subject Alternative Name (SAN).

  • When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect; all connections will be blocked until the Immuta Service Principal is added).

  • Only TCP connections over IPv4 are supported.

Configure Starburst (Trino) with AWS PrivateLink

1. Open a support ticket with Immuta Support with the following information:

   • AWS Region

   • AWS Subnet Availability Zones IDs (e.g. use1-az3)

   • VPC Endpoint Service ID

   • DNS Hostname

   • Ports Used

2. Authorize the Service Principal provided by your representative so that Immuta can complete the VPC Endpoint configuration.

3. Configure the Starburst (Trino) integration.

4. Register your tables as Immuta data sources.

Azure Private Link provides private connectivity from the Immuta SaaS platform, hosted on AWS, to customer-managed Snowflake Accounts on Azure. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.

Support for Azure Private Link is available in all Snowflake-supported Azure regions.

Requirements

• You have an Immuta SaaS tenant.

• Your Snowflake account is hosted on Azure.

• Your Snowflake account is on the Business Critical Edition.

• You have ACCOUNTADMIN role on your Snowflake account to configure the Private Link connection.

Configure Snowflake with Azure Private Link

1. In your Snowflake environment, run the following SQL query, which will return a JSON object with the connection information you will need to include in your support ticket:

   Copy

   select SYSTEM$GET_PRIVATELINK_CONFIG()

2. Copy the returned JSON object into a support ticket with Immuta Support to request for the feature to be enabled on your Immuta SaaS tenant.

3. Your Immuta representative will work with you to schedule a time in which to accept the connection in your Snowflake account. They will provide you with a SQL query to run using the ACCOUNTADMIN role. The SQL query will be in this format:

   Copy

   SELECT SYSTEM$AUTHORIZE_PRIVATELINK (
   '/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Network/privateEndpoints/abc12345.east-us-2.azure.snowflakecomputing.com-eus2',
     '<ACCESS_TOKEN>'
   );

   The query should return the following response: Private link access authorized.

4. Configure the Snowflake integration.

5. Register your tables as Immuta data sources. Note that the privatelink-account-url from the JSON object in step one will be the Server when registering data sources.

Specify authentication method

When creating a data source in Power BI, specify Microsoft Account as the authentication method, if available. This setting allows you to use your enterprise SSO to connect to your compute platform.

Set up DirectQuery

After connecting to the compute platform and the tables to use for your data source, select DirectQuery to connect to the data source. This setting is required for Immuta to enforce policies.

Publish data

After you publish the datasets to the Power BI service, force users to use their personal credentials to connect to the compute platform by following the steps below.

1. Enable SSO in the tenant admin portal under Settings -> Admin portal -> Integration settings.

2. Find the option to manage Data source credentials under Settings -> Datasets.

3. For most connectors you can enable OAuth2 as the authentication method to the compute platform.

4. Enable the option Report viewers can only access this data source with their own Power BI identities using DirectQuery. This forces end-users to use their personal credentials.

Resources

• Snowflake guides:

  • https://www.snowflake.com/blog/using-sso-between-power-bi-and-snowflake

  • https://docs.snowflake.com/en/user-guide/oauth-powerbi

• Databricks guide: https://learn.microsoft.com/en-us/azure/databricks/partners/bi/power-bi#access-azure-databricks-data-source-using-the-power-bi-service

• Redshift guide: https://aws.amazon.com/blogs/big-data/integrate-amazon-redshift-native-idp-federation-with-microsoft-azure-ad-and-power-bi

This section contains information about application-wide settings and configurations.

How-to guides

• App settings: Control application-wide settings on the Immuta app settings page.

• Configure private networking: Leverage AWS PrivateLink or Azure Private Link for communication between the Immuta SaaS platform and an integration.

  • Amazon Redshift

  • Databricks

    • AWS PrivateLink

    • Azure Private Link

  • Snowflake

    • AWS PrivateLink

    • Azure Private Link

  • Starburst (Trino)

    • AWS PrivateLink

    • Azure Private Link

• BI tools: Configure Immuta to enforce policies on the dashboards of your BI tools.

• IP filtering: Filter the IP addresses users can log in from.

• System status bundle: Export and download a system status bundle to assess and solve issues with the Immuta application.

Reference guides

• Deployment options: This reference guide describes the SaaS and self-managed deployment options, the global segments for deploying Immuta, and the IP addresses to authorize in your network firewall configuration to allow Immuta to connect to databases running in closed networks.

• Data processing: This reference guide describes the types of metadata and sample data Immuta processes.

• Encryption and masking practices: This reference guide describes the processing data Immuta uses to enact policies, generate data source fingerprints, and the encryption practices on that data.

The system status tab allows administrators to export a zip file called the Immuta status bundle. This bundle includes information helpful to assess and solve issues within an Immuta tenant by providing a snapshot of Immuta, associated services, and information about the remote source backing any of the selected data sources.

1. Click the App Settings icon.

2. Select the System Status tab.

3. Select the checkboxes for the information you want to export.

4. Click Generate Status Bundle to download the file.

AWS PrivateLink provides private connectivity from the Immuta SaaS platform to customer-managed Redshift Clusters hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.

This feature is supported in most regions across Immuta's Global Segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.

Requirements

• You have an Immuta SaaS tenant.

• You have set up an AWS PrivateLink Service for your Redshift Cluster endpoints.

  • If you have configured Private DNS Hostnames on your PrivateLink Service, the domain ownership must be verifiable via a public DNS zone. This means that you cannot use a Top-Level Domain (TLD) that is not publicly resolvable, e.g. redshift.mycompany.internal.

  • If you are using TLS, the presented certificate must have the Fully-Qualified Domain Name (FQDN) of your cluster as a Subject Alternative Name (SAN).

  • When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect, all connections will be blocked until the Immuta Service Principal is added).

Configure Redshift with AWS PrivateLink

1. Open a support ticket with Immuta Support with the following information:

   • AWS Region

   • AWS Subnet Availability Zones IDs (e.g. use1-az3)

   • VPC Endpoint Service ID

   • DNS Hostname

   • Ports Used

2. Authorize the Service Principal provided by your representative so that Immuta can complete the VPC Endpoint configuration.

3. Configure the Redshift integration.

4. Register your tables as Immuta data sources.

Specify authentication method

When creating the data source in Tableau, specify the authentication method as Sign in using OAuth. This setting will allow you to use your enterprise SSO to connect to your compute platform.

Set up a live connection

After connecting to the compute platform, select the tables you will use for your data source. Then, select Live connection. This setting is required for Immuta to enforce policies.

Credential prompt

To share your dashboard to your organization, publish your data sources. During this process, set the authentication method to Prompt user. This option ensures that dashboard viewers will see the data according to their personal policies.

Resources

• Snowflake guide:

• Databricks guides:

• Redshift guide:

Users with the Cloud group are able to lock down ingress access for a set of IP addresses, adding another layer of security to their instances. This feature can filter the IP addresses from which a user can log in to the service, providing more security than user authentication.

To configure IP Filtering, contact .

Navigate to the App Settings Page

1. Click the App Settings icon in the left sidebar.

2. Click the link in the App Settings panel to navigate to that section.

Use Existing Identity Access Manager

See the identity manager pages for a tutorial to connect an Microsoft Entra ID, Okta, or OneLogin identity manager.

To configure Immuta to use all other existing IAMs,

1. Click the Add IAM button.

2. Complete the Display Name field and select your IAM type from the Identity Provider Type dropdown: LDAP/Active Directory, SAML, or OpenID.

Immuta Accounts

To set the default permissions granted to users when they log in to Immuta, click the Default Permissions dropdown menu, and then select permissions from this list.

Link External Catalogs

See the External Catalogs page.

Enable External Masking

To enable external masking,

1. Navigate to the App Settings page and click External Masking in the left sidebar.

2. Click Add Configuration and specify an external endpoint in the External URI field.

3. Click Configure, and then add at least one tag by selecting from the Search for tags dropdown menu. Note: Tag hierarchies are supported, so tagging a column as Sensitive.Customer would drive the policy if external masking was configured with the tag Sensitive).

4. Select Authentication Method and then complete the authentication fields (when applicable).

5. Click Test Connection and then Save.

Add a Native Workspace

1. Select Add Workspace.

2. Use the dropdown menu to select the Databricks Workspace Type.

   • Before creating a workspace, the cluster must send its configuration to Immuta; to do this, run a simple query on the cluster (i.e., show tables). Otherwise, an error message will occur when users attempt to create a workspace.

   • The Databricks API Token used for native workspace access must be non-expiring. Using a token that expires risks losing access to projects that are created using that configuration.

3. Use the dropdown menu to select the Schema and refer to the corresponding tab below.

Add An Integration

1. Select Add Native Integration.

2. Use the dropdown menu to select the Integration Type. Follow one of the guides below to finish configuring your integration:

   • Azure Synapse Analytics

   • Databricks Spark

   • Databricks Unity Catalog

   • Redshift

   • Snowflake

   • Starburst (Trino)

Initialize Kerberos

To configure Immuta to protect data in a kerberized Hadoop cluster,

1. Upload your Kerberos Configuration File, and then you can add modify the Kerberos configuration in the window pictured below.
2. Upload your Keytab File.

3. Enter the principal Immuta will use to authenticate with your KDC in the Username field. Note: This must match a principal in the Keytab file.

4. Adjust how often (in milliseconds) Immuta needs to re-authenticate with the KDC in the Ticket Refresh Interval field.

5. Click Test Kerberos Initialization.

Generate System API Key

1. Click the Generate Key button.

2. Save this API key in a secure location.

Enable Sensitive Data Discovery

To enable Sensitive Data Discovery and configure its settings, see the Sensitive Data Discovery page.

Audit Settings

Enable Exclude Query Text

By default, query text is included in native query audit events from Snowflake, Databricks, and Starburst (Trino).

When query text is excluded from audit events, Immuta will retain query event metadata such as the columns and tables accessed. However, the query text used to make the query will not be included in the event. This setting is a global control for all configured integrations.

To exclude query text from audit events,

1. Scroll to the Audit section.

2. Check the box to Exclude query text from audit events.

3. Click Save.

Allow Policy Exemptions

Click the Allow Policy Exemptions checkbox to allow users to specify who can bypass all policies on a data source.

Manage the Default Subscription Policy

1. Click the App Settings icon in the navigation menu.

2. Scroll to the Default Subscription Policy section.

3. Select the radio button to define the behavior of subscription policies when new data sources are registered in Immuta:

   • None: When this option is selected, Immuta will not apply any subscription policies to data sources when they are registered. Changing the default subscription policy to none will only apply to newly created data sources. Existing data sources will retain their existing subscription policies.

   • Allow individually selected users: When a data source is created, Immuta will apply a subscription policy to it that requires users to be individually selected to access the underlying table. In most cases, users who were able to query the table before the data source was created will no longer be able to query the table in the remote data platform until they are subscribed to the data source in Immuta.

4. Click Save and confirm your changes.

Default Subscription Merge Options

Immuta merges multiple Global Subscription policies that apply to a single data source; by default, users must meet all the conditions outlined in each policy to get access (i.e., the conditions of the policies are combined with AND). To change the default behavior to allow users to meet the condition of at least one policy that applies (i.e., the conditions of the policies are combined with OR),

1. Click the Default Subscription Merge Options text in the left pane.

2. Select the Default "allow shared policy responsibility" to be checked checkbox.

3. Click Save.

Note: Even with this setting enabled, Governors can opt to have their Global Subscription policies combined with AND during policy creation.

Configure Governor and Admin Settings

These options allow you to restrict the power individual users with the GOVERNANCE and USER_ADMIN permissions have in Immuta. Click the checkboxes to enable or disable these options.

Create Custom Permissions

You can create custom permissions that can then be assigned to users and leveraged when building subscription policies. Note: You cannot configure actions users can take within the console when creating a custom permission, nor can the actions associated with existing permissions in Immuta be altered.

To add a custom permission, click the Add Permission button, and then name the permission in the Enter Permission field.

Create Custom Data Source Access Requests

To create a custom questionnaire that all users must complete when requesting access to a data source, fill in the following fields:

1. Opt for the questionnaire to be required.

2. Key: Any unique value that identifies the question.

3. Header: The text that will display on reports.

4. Label: The text that will display in the questionnaire for the user. They will be prompted to type the answer in a text box.

Create Custom Login Message

To create a custom message for the login page of Immuta, enter text in the Enter Login Message box. Note: The message can be formatted in markdown.

Opt to adjust the Message Text Color and Message Background Color by clicking in these dropdown boxes.

Prevent Automatic Table Statistics

To disable the automatic collection of statistics with a particular tag,

1. Use the Select Tags dropdown to select the tag(s).

2. Click Save.

K-anonymization

When a k-anonymization policy is applied to a data source, the columns targeted by the policy are queried under a fingerprinting process that generates rules enforcing k-anonymity. The results of this query, which may contain data that is subject to regulatory constraints such as GDPR or HIPAA, are stored in Immuta's metadata database.

The location of the metadata database depends on your deployment:

• Self-managed Immuta deployment: The metadata database is located in the server where you have your external metadata database deployed.

• SaaS Immuta deployment: The metadata database is located in the AWS global segment you have chosen to deploy Immuta.

To ensure this process does not violate your organization's data localization regulations, you need to first activate this masking policy type before you can use it in your Immuta tenant.

1. Click Other Settings in the left panel and scroll to the K-Anonymization section.

2. Select the Allow users to create masking policies using K-Anonymization checkbox to enable k-anonymization policies for your organization.

3. Click Save and confirm your changes.

Advanced Settings

Preview Features

If you enable any Preview features, provide feedback on how you would like these features to evolve.

Policy Adjustments

1. Click Advanced Settings in the left panel, and scroll to the Preview Features section.

2. Check the Enable Policy Adjustments checkbox.

3. Click Save.

Complex Data Types

1. Click Advanced Settings in the left panel, and scroll to the Preview Features section.

2. Check the Allow Complex Data Types checkbox.

3. Click Save.

Enhanced Subscription Policy Variables

For instructions on enabling this feature, navigate to the Global Subscription Policies Advanced DSL Tutorial.

Deploy Configuration Changes

When you are ready to finalize your configuration changes, click the Save button at the bottom of the left panel, and then click Confirm to deploy your changes.

AWS PrivateLink provides private connectivity from the Immuta SaaS platform to customer-managed Databricks accounts hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.

This front-end PrivateLink connection allows users to connect to the Databricks web application, REST API, and Databricks Connect API over a VPC interface endpoint. For details about AWS PrivateLink in Databricks and the network flow in a typical implementation, explore the Databricks documentation.

This feature is supported in most regions across Immuta's Global Segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.

Requirements

Databricks

Ensure that your accounts meet the following requirements:

• Your Databricks account is on the E2 version of the platform.

• Your Databricks account is on the Enterprise pricing tier.

• You have your Databricks account ID from the account console.

• You have an Immuta SaaS tenant.

• AWS PrivateLink for Databricks has been enabled.

Databricks workspace

Ensure that your workspace meets the following requirements:

• Your workspace must be in an AWS region that supports the E2 version of the platform. In the us-west-1 region, Databricks does not support PrivateLink even for workspaces on the E2 version of the platform.

• Your Databricks workspace must use Customer-managed VPC to add any PrivateLink connection.

• Your workspaces must be configured with private_access_settings objects.

Enablement

Contact your Databricks representative to enable AWS PrivateLink on your account.

Configure Databricks with AWS PrivateLink

Register the Immuta VPC endpoint for the applicable AWS region with your Databricks workspaces. The Immuta VPC endpoint IDs are listed in the table below.

Identify your private access level (either ACCOUNT or ENDPOINT) and configure your Databricks workspace accordingly.

• If the private_access_level on your private_access_settings object is set to ACCOUNT, no additional configuration is required.

• If the private_access_level on your private_access_settings object is set to ENDPOINT, using the table above, you will need to add it to the allowed_vpc_endpoint_ids list inside your private_access_settings object in Databricks. For example,

  Copy

  "private_access_settings_name": "immuta-access",
  "region": "us-east-1",
  "public_access_enabled": false,
  "private_access_level": "ENDPOINT",
  "allowed_vpc_endpoint_ids": [
          "vpce-0fe5b17a0707d6fa5"
  ]

provides private connectivity from the Immuta SaaS platform, hosted on AWS, to customer-managed Azure Databricks accounts. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.

This front-end Private Link connection allows users to connect to the Databricks web application, REST API, and Databricks Connect API over an Azure Private Endpoint. For details about Azure Private Link for Databricks and the network flow in a typical implementation, explore the .

Support for Azure Private Link is available in .

Requirements

Ensure that your accounts meet the following requirements:

• You have an Immuta SaaS tenant.

Configure Databricks with Azure Private Link

1. Contact your Immuta representative, and provide the following information for each Azure Databricks Workspace you wish to connect to:

   • Azure Region

   • Azure Databricks hostname

   • Azure Databricks Resource ID or Alias

Immuta can enforce policies on data in your dashboards when your BI tools are connected directly to your compute layer.

This page provides recommendations for configuring the interaction between your database, BI tools, and users.

Connect directly to the database instead of extracts or imports

To ensure that Immuta applies access controls to your dashboards, connect your BI tools directly to the compute layer where Immuta enforces policies without using extracts. Different tools may call this feature different names (such as live connections in Tableau or DirectQuery in Power BI).

Connecting your tools directly to the compute layer without using extracts will not impact performance and provides host of other benefits. For details, see Moving from legacy BI extracts to modern data security and engineering.

Use personal credentials to authenticate and query data

Personal credentials need to be used to query data from the BI tool so that Immuta can apply the correct policies for the user accessing the dashboard. Different authentication mechanisms are available, depending on the BI tool, connector, and compute layer. However, Immuta recommends to use one of the following methods:

• Use OAuth single sign (SSO) on when available, as it offers the best user experience.

• Use username and password authentication or personal access tokens as an alternative if OAuth is not supported.

• Use impersonation if you cannot create and authenticate individual users in the compute layer. Native impersonation allows users to natively query data as another Immuta user. For details, see the user impersonation guide.

For configuration guidance, see Power BI configuration example and Tableau configuration example.

Authentication method matrix

Immuta has verified several popular BI tool and compute platform combinations. The table below outlines these combinations and their recommended authentication methods. However, since these combinations depend on tools outside Immuta, consult the platform documentation to confirm these suggestions.

Notes

• AWS Databricks + Power BI Service: The Databricks Power BI Connector does not work with OAuth or personal credentials. Use a Databricks PAT (personal access token) as an alternative.

• Redshift + Tableau: Use username and password authentication or impersonation.

• Starburst + Power BI Service: The Power BI connector for Starburst requires a gateway that shares credentials, so this combination is not supported.

• Starburst + Tableau: Use username and password authentication or impersonation.

• QuickSight: A shared service account is used to query data, so this tool is not supported.

Azure Private Link provides private connectivity from the Immuta SaaS platform, hosted on AWS, to customer-managed Starburst (Trino) clusters on Azure. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.

Support for Azure Private Link is available in .

Prerequisites

• You have an Immuta SaaS tenant.

• Your Starburst (Trino) cluster is hosted on Azure.

Configure Starburst (Trino) with Azure Private Link

1. • Azure Region

   • Azure Private Link Service Resource ID or Alias

   • DNS Hostname

3. Once the Immuta Azure Subscription is authorized, inform your representative so that Immuta can complete Private Link Endpoint configuration.

• SaaS: This deployment option provides data access control through Immuta's integrations with automatic software updates and no infrastructure or maintenance costs.

• Self-Managed: Immuta supports self-managed deployments for users who store their data on-premises or in private clouds, such as VPC. Users can connect to on-premises data sources and cloud data platforms that run on Amazon Web Services, Microsoft Azure, and Google Cloud Platform.

SaaS global segments

Immuta SaaS can deploy in the following global segments. Each global segment is built using multiple regions for disaster recovery.

Connecting to databases running in closed networks

The IP addresses below must be authorized in your network firewall configuration to allow Immuta to connect.

Asia Pacific

• 3.106.147.24

• 13.114.123.176

• 13.238.102.94

• 13.55.39.43

• 13.55.159.66

• 18.176.33.125

• 35.74.60.182

• 35.79.88.51

• 52.63.167.163

• 52.68.224.114

• 54.79.122.121

• 52.196.249.32

Europe

• 3.9.86.222

• 3.72.210.214

• 3.74.143.208

• 3.126.62.66

• 13.41.25.70

• 18.158.34.136

• 18.169.27.181

• 18.169.63.243

• 18.169.76.225

• 18.195.8.208

• 35.158.87.229

• 35.179.66.5

• 52.16.117.91

• 52.211.82.12

• 54.171.9.121

• 63.34.27.228

• 63.34.155.116

• 108.129.45.8

North America

• 34.192.38.214

• 34.223.179.107

• 35.155.223.131

• 35.163.162.139

• 44.205.48.68

• 44.237.62.198

• 52.2.174.14

• 54.68.252.84

• 54.88.42.98

• 54.205.215.251

• 54.225.122.15

• 100.20.168.64

This section contains information about private connectivity options for Starburst (Trino) integrations.

Overview

The Immuta SaaS platform supports private connectivity to Starburst (Trino) clusters hosted in both AWS and Azure. This allows customers to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.

Support for AWS PrivateLink is available in most regions across Immuta's Global Segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.

Support for Azure Private Link is available in all Azure regions.

Configuration Guides

• AWS PrivateLink

• Azure Private Link

Encryption of Data at Rest

Immuta captures metadata and stores it in an internal PostgreSQL database (Metadata Database). Customers can encrypt the volumes backing the database using an external Key Management Service to ensure that data is encrypted at rest.

Encryption of Data in Transit

To encrypt data in transit, Immuta uses TLS protocol, which is configured by the customer.

Encryption Key Management

Immuta encrypts values with data encryption keys, either those that are system-generated or managed using an external key management service (KMS). Immuta recommends a KMS to encrypt or decrypt data keys and supports the AWS Key Management Service; however, if no KMS is configured, Immuta will generate a data encryption key on a user-defined rollover schedule, using the most recent data key to encrypt new values while preserving old data keys to decrypt old values.

Masking

Immuta employs three families of functions in its masking policies:

• One-way Hashing: One-way (irreversible) hashing is performed via a salted SHA256 hash. A consistent salt is used for values throughout the data source, so users can count or track the specific values without revealing the true value. Since hashed values are different across data sources, users are unable to join on hashed values. Note: Joining on masked values can be enabled in Immuta Projects.

• Reversible Masking: For reversible masking, values are encrypted using AES-256 CBC encryption. Encryption is performed using a cell-specific initialization vector. The resulting values can be unmasked by an authorized user. Note that this is dynamic encryption of individual fields as results are streamed to the querying system; Immuta is not modifying records in the data store. See the External Masking documentation to learn how Immuta policies can work with 3rd-party encryption/decryption services to reveal encrypted records under appropriate circumstances.

• Reversible Format Preserving Masking: Format preserving masking maintains the format of the data while masking the value and is achieved by initializing and applying the NIST standard method FF1 at the column level. The resulting values can be unmasked by an authorized user.

To understand how Immuta processes data, it's imperative to understand the purpose of the Immuta components (illustrated in the diagram below) deployed in the Immuta Cloud infrastructure:

• Fingerprint Service: When enabled, additional statistical queries made during the health check are distilled into summary statistics, called fingerprints. During this process, statistical query results and data samples (which may contain PII) are temporarily held in memory by the Fingerprint Service.

• Immuta Accounts Database: Immuta Accounts stores the Immuta tenant's first account as a part of setup. If a customer chooses not to use a third-party identity provider for their user account management, then subsequent Immuta user accounts will be stored here as well. Account information includes name and email address. If desired, a service account may be used to avoid storing personal identifiers.

• Immuta Tenants Metadata Database: The database specific to a customer's instance that contains the instance's metadata that powers the core functionality of Immuta, including policy data and attributes about data sources (tags, audit data, etc.).

• Immuta Web Service: This component includes the Immuta UI and API and is responsible for all web-based user interaction with Immuta, metadata ingest, and the data fingerprinting process.

Data Categories

Data processed by Immuta falls into one of the following categories. For additional details, click a category to navigate to that section.

TCP Connection

Immuta communicates with remote databases over a TCP connection.

Immuta Audit Logs

Audit data includes metadata (e.g., who subscribes to a data source, when they access data, potentially what SQL queries were run, etc.) that is generated by a variety of actions and processes in Immuta. The most common processes are illustrated in the diagram below.

All audit logs flow from the Web Service to the Metadata Database (local to the customer's region) and are stored for 90 days.

Immuta Identity Management Data

This process is only relevant to customers using an external identity provider service to manage user accounts in Immuta.

1. The initial Immuta user account is created through Immuta Accounts, and this data is stored in the US (AWS us-east-1).

2. A System Administrator configures an external IAM with Immuta.

3. User account information is collected from the external IAM and stored in the instance's Metadata Database.

Data Dictionary and Data Source Metadata

This data is processed to support data source creation, health checks, policy enforcement, and dictionary features.

1. A System Administrator configures the integration in Immuta.

2. A Data Owner registers data sources from their remote data platform with Immuta. Note: Data Owners can see sample data when editing a data source. However, this action requires the database password, and the small sample of data visible is only displayed in the UI and is not stored in Immuta.

3. When a data source is created or updated, the Metadata Database pulls in and stores statistics about the data source, including row count and high cardinality calculations.

4. The data source health check runs daily to ensure existing tables are still valid.

5. If an external catalog is enabled, the daily health check will pull in data source attributes (e.g., tags and definitions) and store them in the Metadata Database.

Policy Decision Data

Policy decision data is transmitted to ensure end users querying data are limited to the appropriate access as defined by the policies in Immuta.

1. A user runs a query against data in their environment.

2. The query is sent to the Immuta Web Service.

3. The Web Service queries the Metadata Database to obtain the policy definition, which includes data source metadata (tags, column names, etc.) and user entitlements (groups and attributes).

4. The policy information is transmitted to the remote data system for native policy enforcement.

5. Query results are displayed based on what policy definition was applied.

Sample Raw Data

Sample data is processed and aggregated or reduced during Immuta's fingerprinting process and specific policy processes. Note: Data Owners can see sample data when editing a data source. However, this action requires the database password, and the small sample of data visible is only displayed in the UI and is not stored in Immuta.

Fingerprinting Process

1. When enabled, statistical queries made during data source registration are distilled into summary statistics, called fingerprints. Fingerprinting allows Immuta to implement advanced privacy enhancing masking and data policies.

2. During this process, statistical query results and data samples (which may contain PII) are temporarily held in memory by the Fingerprint Service only for the amount of time it takes to calculate the statistics needed. For Snowflake, no data sample is needed, and only statistics about the data are returned to Immuta (no PII).

3. The fingerprinting process checks for new tables through schema monitoring (when enabled) and captures summary statistics of changes to data sources, including when policies were applied, external views were created, or sensitive data elements were added.

Policy Processes

1. Sample data is processed when k-anonymization or randomized response policies are applied to data sources.

2. Sample data exists temporarily in memory in the Fingerprint Service during the computation.

   • k-Anonymization Policies: At the time of its application, the columns of a k-anonymization policy are queried under a separate fingerprinting process that generates rules enforcing k-anonymity. The results of this query, which may contain PII, are temporarily held in memory by the Fingerprint Service. The final rules are stored in the Metadata Database as the policy definition for enforcement. Immuta requires that you opt in to use this masking policy type. To enable k-anonymization for your account, contact your Immuta representative.

   • Randomized Response Policies: If the list of substitution values for a categorical column is not part of the policy specification (e.g., when specified via the API), a list is obtained via query and merged into the policy definition in the Metadata Database.

3. Raw data is processed for masking, producing either a distinct set of values or aggregated groups of values.

User Metrics Data

Immuta collects a variety of metrics and details about app usage that is stored in a single US-based region.

1. Data about activity within the instance is aggregated nightly.

2. Aggregates create metrics (the number of policies created, number of users authenticated, number of tags created, etc.).

3. User data (session ID, length, event properties, page views, etc.) is collected using Segment and Heap.

4. All of this data is stored in a single, US-based region (AWS us-east-1).