Designing a secure Delta Sharing strategy

Delta Sharing lets you securely share live Unity Catalog data (tables, views, volumes, notebooks, AI models) with users inside or outside your organization without copying data or requiring recipients to use Databricks. A secure sharing strategy relies on Unity Catalog's Shares and Recipients objects, combined with access controls, credential management, and activity monitoring to govern who can see what and how they authenticate.

1 · Learn the must-know

• 1A share is a Unity Catalog securable object containing one or more tables, views, volumes, or other assets from a catalog/schema that you grant to one or more recipients.
• 2Recipients can be Databricks-to-Databricks (authenticated via Unity Catalog identity, supporting Azure AD/Entra ID federation and no token management) or open sharing via a bearer-token-based credential file for non-Databricks recipients, which is less secure since tokens can be shared/leaked.
• 3For open sharing, admins should set token expiration, rotate/rotate-and-revoke recipient credentials regularly, and use IP access lists to restrict where the credential file can be used from.
• 4Use CREATE SHARE, GRANT SELECT ON SHARE, and CREATE RECIPIENT with fine-grained object-level grants so recipients only see the specific tables/views/columns/rows intended, leveraging views with row/column filtering for finer control before sharing.
• 5All Delta Sharing grants and activity are governed by Unity Catalog and logged via unity catalog audit logs (system.access.audit), allowing providers to monitor recipient query activity and revoke access at any time by dropping the recipient or share grant.
• 6Sharing across metastores/regions or with external (non-Databricks) parties should default to Databricks-to-Databricks sharing where possible for stronger identity-based security, reserving open sharing only when the recipient has no Databricks account.

2 · Check your understanding