> For the complete documentation index, see [llms.txt](https://documentation.immuta.com/saas/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.immuta.com/saas/configuration/integrations/databricks/databricks-unity-catalog/reference-guides/databricks-unity-catalog-integration-reference-guide/protecting-data.md).
# Protecting Data
{% hint style="info" %}
**New connections**
The [new connections flow](/saas/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/new-connections-reference-guide.md) documented here is available and released to select tenants.
{% endhint %}
In the Databricks Unity Catalog integration, Immuta administers Databricks Unity Catalog privileges on data registered in Immuta. Then, Immuta users who have been granted access to the data sources can query them.
The sequence diagram below outlines the events that occur when an Immuta user who is subscribed to a data source queries it in Databricks Unity Catalog.
## Registering a connection
The Databricks Unity Catalog integration is configured and data is registered through [connections](/saas/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/new-connections-reference-guide.md), an Immuta feature that allows administrators to register data objects in a technology through a single connection to make data registration more scalable for your organization.
Once the Databricks Unity Catalog connection is registered, you can author subscription and data policies in Immuta to enforce access controls.
See the [Databricks Unity Catalog integration reference guide](/saas/configuration/integrations/databricks/databricks-unity-catalog/reference-guides/databricks-unity-catalog-integration-reference-guide.md) for more details about registering a connection.
## Protecting data
### Subscription policies
When a subscription policy is applied to a data source, users who meet the conditions of the policy will be [automatically subscribed to the data source](#user-content-fn-1)[^1]. Immuta creates and manages Databricks Unity Catalog groups for those users (if an appropriate group does not already exist), grants the required Unity Catalog privileges to the group, and adds the entitled users to that group.
Consider the following example that illustrates how Immuta enforces a subscription policy that only allows users in the `analysts` group to access the `yellow-table`. When this policy is authored and applied to the data source, Immuta creates an Immuta-managed Databricks group (if needed), grants the `SELECT` privilege on `yellow-table` to that group, and adds users who are members of the `analysts` group to it.
In the image above, the user in the `analysts` group accesses `yellow-table`, while the user who is a part of the `research` group is denied access.
### **User permissions Immuta revokes**
**On securable objects**
If you enable a Databricks Unity Catalog object in Immuta, Immuta will only manage users' access to that data object after a subscription policy grants them access to the data source. Immuta preserves all preexisting grants in Databricks and only revokes user access when explicitly dictated by an Immuta policy.
Expand the collapsible blocks below to see how Immuta-managed grants and Databricks-managed grants are affected in various scenarios.
Subscription policy applied
Immuta only manages grants for Immuta users once a subscription policy applies to them. Any grants performed on Databricks objects outside Immuta will not be revoked.
The table below illustrates how the following policy enforces access controls for 4 different users, some of whom have Databricks-managed grants:
> Allow users to subscribe to the data source if they are a member of group `HR`
| | Immuta-managed grant | Databricks-managed grant | Access result |
| ------------------------------------------------------------------ | -------------------- | ------------------------ | -------------------- |
|
| `SELECT` | `SELECT` | :white\_check\_mark: |
In this example,
* **User A is granted access** to the table by **Immuta**.
* **User B is granted access** to the table by **Databricks**.
* **User C cannot access** the table because they do not meet the conditions of the Immuta policy and they have been not granted access to the table in Databricks outside of Immuta.
* **User D is granted access** to the table by **Immuta** and **Databricks**. The Immuta-managed `SELECT` grant coexists with their Databricks-managed `SELECT` grant.
Subscription policy edited
If a subscription policy is edited, Immuta only affects the Immuta-managed grants on the data object.
The table below illustrates how editing the following policy enforces access controls for 4 different users, some of whom have Databricks-managed grants:
**Previous policy**
> Allow users to subscribe to the data source if they are a member of group `HR`
**Updated policy**
> Allow users to subscribe if they are a member of group `Engineers`
| | Immuta-managed grant | Databricks-managed grant | Access result |
| ------------------------------------------------------------------ | -------------------- | ------------------------ | -------------------- |
|
| Revoked | Revoked | :x: |
In this example,
* **User A is revoked access** to the table by **Immuta**. Because this user was previously granted access to the data source by Immuta, that Immuta-managed grant is revoked.
* **User B is granted access** to the table by **Databricks** and **Immuta**. The Immuta-managed `SELECT` grant coexists with their Databricks-managed `SELECT` grant.
* **User C cannot access** the table because they do not meet the conditions of the Immuta policy and they have been not granted access to the table in Databricks outside of Immuta.
* **User D is revoked access** to the table by the change to the Immuta policy. The Immuta-managed `SELECT` grant (from the previous policy) and the pre-existing Databricks-managed `SELECT` grant have been revoked because the Immuta policy explicitly dictated that their access should be removed.
Subscription policy deleted
If a subscription policy is deleted, users' Immuta grants are revoked for that policy. Users will retain access to the data source if they have Immuta-granted access through another subscription policy that overlaps or if they have a Databricks-managed grant for that data source.
The table below illustrates how **deleting the following Immuta policy** affects access for 4 different users, some of whom have Databricks-managed grants:
> Allow users to subscribe to the data source if they are a member of group `HR`
| | Immuta-managed grant | Databricks-managed grant | Access result |
| ------------------------------------------------------------------ | -------------------- | ------------------------ | -------------------- |
|
| None | None | :x: |
In this example,
* **User A is revoked access** to the table by **Immuta**. Because this user was [previously granted access](#subscription-policy-applied) to the data source by Immuta, that Immuta-managed grant is revoked when the subscription policy is deleted.
* **User B is granted access** to the table by **Databricks**.
* **User C cannot access** the table because they have not been granted access by an Immuta policy and they have been not granted access to the table in Databricks.
* **User D is revoked access** to the table by **Immuta**. Because this user was [previously granted access](#subscription-policy-applied) to the data source by Immuta, Immuta took over managing this user's grants on the table, and that Immuta-managed grant is revoked when the subscription policy is deleted.
Data source disabled
If a data source is disabled, users' access reverts to what the Databricks-managed access was previously, before the data object was registered in Immuta.
The table below illustrates how **disabling** the data source in Immuta affects access for 4 different users, some of whom have Databricks-managed grants.
| | Immuta-managed grant | Databricks-managed grant | Access result |
| ------------------------------------------------------------------ | -------------------- | ------------------------ | -------------------- |
|
| None | `SELECT` | :white\_check\_mark: |
In this example,
* **User A is revoked access** to the table by **Immuta**. The Immuta-managed grant is revoked when the data source is disabled because the state of the grants on this data object reverts to what it was before the data object was registered in Immuta.
* **User B is granted access** to the table by **Databricks**. The Databricks-managed grant remains because the state of the grants on this data object reverts to what it was before the data object was registered in Immuta.
* **User C cannot access** the table because they had not been granted access to the table in Databricks.
* **User D is granted access** to the table by **Databricks**. The Immuta-managed grant is revoked and the Databricks grant remains when the data source is disabled because the state of the grants on this data object reverts to what it was before the data object was registered in Immuta.
If a user is not registered in Immuta, Immuta will have no effect on that user's access to data in Unity Catalog.
**On schemas and catalogs**
By default, Immuta will revoke Immuta users' `USE CATALOG` and `USE SCHEMA` privileges in Unity Catalog for users that do not have access to any of the underlying securables within that catalog/schema. If users have any Immuta-managed or Databricks-managed grants to a securable, Immuta will not revoke that catalog/schema access.
If you disable this setting, Immuta will only revoke the permissions granted on the securable objects themselves, and users' `USE CATALOG` and `USE SCHEMA` permissions will remain even if the user does not have access to any resource in that catalog/schema.
See the [App settings page for instructions](/saas/configuration/application-configuration/how-to-guides/config-builder-guide.md#databricks-unity-catalog-configuration) on changing this setting.
### Data policies
After Databricks Unity Catalog objects are registered in Immuta, you can author data policies in Immuta to enforce fine-grained access controls.
When a data policy is applied to a Databricks Unity Catalog data source, Immuta enforces that policy natively in Databricks. Depending on the policy type, Immuta applies SQL user-defined functions (UDFs) to enforce row-level security and column masking on registered tables so that queries return policy-enforced results.
As data policies are created, updated, or removed in Immuta, Immuta updates the corresponding SQL UDFs in Databricks to keep enforcement in sync. Users continue querying the Databricks Unity Catalog object directly and see policy-enforced data in Databricks.
See the [Data policies page](/saas/govern/secure-your-data/authoring-policies-in-secure/data-policies/how-to-guides/data-policy-tutorial.md) for guidance on authoring data policies in Immuta and the [supported data policies](/saas/govern/secure-your-data/authoring-policies-in-secure/data-policies/reference-guides/data-policies.md#data-policy-support-matrix-integrations) for the Databricks Unity Catalog integration.
[^1]: If the **require manual subscription** option is selected for the policy, these users will have to manually subscribe to the data.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://documentation.immuta.com/saas/configuration/integrations/databricks/databricks-unity-catalog/reference-guides/databricks-unity-catalog-integration-reference-guide/protecting-data.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.