Zero Copy Data Sharing: Securing Live Shares Across Data Platforms

Zero copy data sharing gives another organisation live, queryable access to your data without exporting a file, which means the share itself has become the security boundary. Nothing leaves in a nightly SFTP job any more: a consumer account, a reader account or a bearer token holder reads the provider's current tables directly, and every change the provider makes is visible at once. That is efficient, and it moves the familiar questions of who has access, for how long and with what evidence into share definitions, recipient credentials and platform audit views. This guide covers share and recipient governance, reader accounts, Delta Sharing tokens, open catalog credential vending, revocation, auditing consumer queries and the contract that should sit behind every share. It is written for data platform owners, security architects and data protection teams. Platforms are listed alphabetically; order is never a ranking.

Key takeaways

• A share is a standing grant to an outside party. Treat every share, listing and recipient as an access path to be owned, justified, reviewed and expired, exactly like a privileged account.
• Share views, not tables. Snowflake strongly recommends sharing secure views or secure UDFs rather than tables, and Delta Sharing recipients can read everything in a share, so the shape of the data must be decided before the grant.
• Recipient credentials are non-human identities. A Delta Sharing credential file holds a bearer token that may never expire if no expiry is set; a reader account has its own administrator. Both need vaulting, rotation and an owner.
• Revocation is instant but not retroactive. Removing an account or dropping a share cuts access immediately, yet anything the consumer has already queried, copied or unloaded stays with them; contracts and minimisation carry that risk.
• Provider visibility is partial. Platform views show which objects and columns consumers touched, with delays of up to two days, not full query text, so logging must be combined with contractual audit rights.

What zero copy sharing is, and where the boundary moves

In a traditional data exchange the provider extracts data, transfers it and loses control at the moment of transfer. In zero copy sharing the provider grants a consumer read access to objects that stay in the provider's storage. Snowflake's documentation states that with Secure Data Sharing no actual data is copied or transferred between accounts; the consumer creates a read-only database from the share and pays only for the compute it uses to query. The Delta Sharing open protocol takes a different technical route to the same outcome: a sharing server authenticates the recipient and returns short-lived pre-signed URLs to individual data files, or temporary cloud storage credentials scoped to a table's directory, so the recipient reads the provider's files in place. Open table formats extend the idea further: the Apache Iceberg REST catalog specification defines an X-Iceberg-Access-Delegation header through which a catalog can vend storage credentials or remotely sign requests for a client.

The same pattern sits behind the terms "federated data model" and "federated data platform": data stays with its owner and is queried where it lives, with a catalog or sharing layer brokering access. Security consequences follow from that design:

• Freshness cuts both ways: Snowflake notes that new objects and updates to shared objects are available to consumers immediately. A column added to a shared table, or a view definition widened by mistake, is exposed the moment it is committed.
• Access is identity based: the consumer's own role model decides who inside the consumer organisation can query the imported database. The provider controls what is shared and with which account, not which of the consumer's users read it.
• Data can still leave: read-only means the consumer cannot change your tables, not that it cannot copy results into its own storage. Snowflake's reader account page notes that unloading with COPY INTO <location> remains possible using connection credentials.
• Different from clean rooms: a clean room restricts which questions may be asked and what output may leave; a share hands over row-level read access. See the Data Clean Rooms Guide when the requirement is joint analysis without raw access.

Sharing models compared

Choosing: where both sides run the same platform, platform-native sharing (Databricks to Databricks, Snowflake direct share or listing) avoids a portable bearer secret and lets the consumer apply its own access control. Use open sharing when the recipient runs different tooling, and prefer OIDC federation over static tokens where the recipient has a capable identity provider. Use reader accounts only for small consumers with no platform of their own, accepting that you now operate their accounts. Smaller providers with a handful of partners can manage this with a register and quarterly review; large providers running listings or marketplaces need automated inventory from SHOW SHARES, recipient APIs and audit tables.

Designing what goes into a share

• Build a dedicated sharing layer: keep shareable objects in their own database or schema, separate from internal analytics. Snowflake's secure views example keeps the base table and access mapping in a private schema and shares only a public schema containing the secure view.
• Use secure views and per-consumer filtering: Snowflake supports only secure views in shares, and a standard view added to a share causes an error. For multi-tenant shares, filter rows with a mapping table joined on CURRENT_ACCOUNT(), and test what each consumer will see with the SIMULATED_DATA_SHARING_CONSUMER session parameter before adding the account.
• Remember that a share is all or nothing for the recipient: the Delta Sharing protocol states that a recipient can access all resources in a share. Split data with different sensitivity or audiences into separate shares rather than relying on recipients to ignore tables.
• Share database roles deliberately: Snowflake lets providers grant database roles to a share, but a shared database role does not support future grants, so each new object needs an explicit decision.
• Minimise columns: share derived, aggregated or pseudonymised columns where the use case allows. Classification tags help here; see the Data Classification Guide.
• Respect platform guard rails: Snowflake documents that sharing sensitive data from Business Critical accounts with non-Business Critical accounts is disabled by default, and that HIPAA accounts cannot share with non-HIPAA accounts. Treat any request to relax these as a risk acceptance with a named approver.
• Do not trust consumer-side filters: the Delta Sharing protocol describes predicate and limit hints as best effort; the server may return files that do not match. Never rely on a recipient's query filter to restrict what it receives.

Recipient credentials and reader accounts as non-human identities

Every external share ends in a credential or an account, and these are the identities attackers look for. See the NHI lifecycle automation for the general discipline.

Delta Sharing bearer tokens

• Profile file: the protocol's profile file holds shareCredentialsVersion, endpoint, bearerToken and an optional expirationTime. The specification says that if no expiration is provided the token can be seen as never expiring.
• One-time download: Databricks documents that the recipient can download the credential file only once through the activation link, and that the activation link should travel over a secure channel. If it reaches the wrong person, the documented response is to revoke share access, rotate with an existing token expiry of 0, send the new link securely and re-grant once it is used.
• Lifetime: Databricks caps recipient tokens at one year and takes the default from the metastore's recipient token lifetime setting. Changing the default does not update existing recipients; their tokens must be rotated. Databricks also states that tokens issued before 8 December 2025 with an expiry after 8 December 2026, or with no expiry, expire automatically on 8 December 2026, so providers with older recipients should plan rotations now.
• Rotation: a recipient can hold at most two tokens, active and rotated. Set --existing-token-expire-in-seconds short during routine rotation and to 0 on suspected compromise.
• Network restriction: attach an IP access list to open sharing recipients where the partner has stable egress addresses.
• Recipient side: if you consume shares, store the credential file in a secrets manager, not a notebook or repository. See the Secrets Management Guide.

Snowflake reader accounts

• Creation rights: reader accounts are created with CREATE MANAGED ACCOUNT ... TYPE = READER by ACCOUNTADMIN or a role holding the global CREATE ACCOUNT privilege. Restrict that privilege; anyone holding it can stand up an account that consumes your shares.
• You operate their identities: the provider owns the account, names its administrator and handles its users' support, because reader account users cannot contact Snowflake Support directly. Apply your own MFA, network policy and leaver process to the people in it.
• Cost is an abuse signal: the provider pays all credits and reader warehouses can consume unlimited credits, so Snowflake recommends a resource monitor. Unexpected consumption is also a sign of misuse or credential theft.
• Inventory and retirement: SHOW MANAGED ACCOUNTS lists them (default limit 75) and READER_ACCOUNT_USAGE views show usage. DROP MANAGED ACCOUNT removes access immediately and cannot be undone.

For the account-level controls on each platform, see the Databricks Service Principals and Token Security Guide and the Service Accounts in Snowflake Guide.

Implementing a governed sharing programme

1. Inventory what already exists. On Snowflake run SHOW SHARES, SHOW GRANTS TO SHARE, SHOW GRANTS OF SHARE and SHOW MANAGED ACCOUNTS; on Databricks list shares, recipients and their authentication type and token expiry. Record owner, consumer, purpose and data classification for each.
2. Restrict who can create shares and recipients. Limit Snowflake CREATE SHARE and CREATE ACCOUNT and the Databricks CREATE RECIPIENT privilege to a small platform team. Business owners request shares; they do not create them.
3. Introduce a request and approval workflow. Each request names the consumer legal entity, the objects, the lawful basis or contract, the expiry date and the business owner. Data protection approves personal data shares.
4. Build the sharing layer and test as the consumer. Create secure views or filtered tables in a dedicated schema, test with SIMULATED_DATA_SHARING_CONSUMER or a test recipient, and compare the output with the approved data items.
5. Pilot with one partner. Grant, confirm the consumer sees only what was approved, confirm audit events arrive, then roll the pattern out.
6. Set expiry and review dates at creation. Short token lifetimes for open sharing recipients, quarterly attestation of every share by its owner, and automatic flagging of shares past their agreed end date.
7. Plan the rollback. Prefer removing objects from a share over dropping it: Snowflake notes that dropping a share or removing an account immediately invalidates consumer databases, and re-creating the share does not restore them. Document which action to use for a mistaken grant (remove the object), a compromised recipient (remove the account or revoke and rotate) and contract end (remove the account, then drop the share or reader account).

Revocation and offboarding

Because revocation stops future reads only, the contract must require the consumer to delete retained copies at termination and to certify that it has done so. The ICO's data sharing code lists retention, deletion and termination procedures among the contents of a good data sharing agreement.

Auditing consumer access

• Databricks: with system tables enabled, Delta Sharing activity lands in system.access.audit. Provider events include deltaSharingQueriedTable and deltaSharingQueriedTableChanges for pre-signed URL shares and generateTemporaryTableCredential for cloud token access, with recipient identity in fields such as recipient_name, recipient_id or deltaSharingRecipientId. Failed actions record the error in response.error_message.
• Snowflake: for listings, the LISTING_ACCESS_HISTORY view in the data sharing usage schema shows each consumer query with the consumer account, the shared objects and columns accessed and how columns were used. Data can take up to two days to appear, is retained for 365 days and does not include full SQL text; the query token cannot be correlated with consumer query IDs.
• Change auditing on the provider side: log and alert on CREATE SHARE, ALTER SHARE ... ADD ACCOUNTS, grants to shares, recipient creation and token rotation. A new recipient or account added outside the workflow is the highest value signal.
• Threat context: MITRE ATT&CK describes adversaries moving data to an account they control in the same cloud provider (T1537 Transfer Data to Cloud Account), which an unauthorised share achieves without a single byte crossing your network monitoring. Use of stolen cloud credentials maps to T1078.004 Cloud Accounts.

Contractual and legal controls

• Data sharing agreement: the ICO says an agreement is not mandatory but is good practice, and that it should identify the parties and controllers, the purpose, the data items, the lawful basis, how individuals' rights are handled, security, retention, deletion and review.
• Onward use and copying: state whether the consumer may persist query results, combine them with other data or pass them on, since the platform cannot prevent this once results are read.
• Credential handling: require the consumer to store sharing credentials in a secrets manager, report suspected exposure within a fixed time and accept rotation on request. See the Third-Party Security Contract Clauses Template.
• Audit and notification: agree that the provider may review consumer access logs, and that the consumer notifies incidents affecting shared data. See the Third-Party Incident Notification Clauses Guide.
• Reader account terms: because you operate those users, set acceptable use, joiner and leaver notification and MFA requirements in the agreement.

Framework mapping

In CIS Controls v8.1 the topic sits mainly in Control 3 (Data Protection) and Control 15 (Service Provider Management).

Common failure patterns

• Sharing base tables: a whole table is granted for convenience and later gains a sensitive column that reaches every consumer the moment it is added.
• Never expiring tokens: open sharing credential files issued without expiry and stored in a partner's shared drive or notebook remain valid long after the project ends.
• Forgotten reader accounts: accounts for a pilot partner survive for years with default administrator credentials, no MFA and no owner, while the provider pays for their compute.
• Silent typos: an ALTER SHARE ... ADD ACCOUNTS with a wrong locator succeeds without change, the intended partner chases access and someone grants a broader workaround.
• Dropping instead of trimming: a mistaken object is fixed by dropping the share, breaking every consumer database, which pushes teams to avoid cleanup next time.
• Weak consumer account security: the share is well designed but the consumer's account has no MFA. The 2024 campaign against Snowflake customers showed how infostealer credentials without MFA open data warehouses; see the Snowflake Account Compromise Playbook.

Practitioner checklist

• Reconcile every share, listing, recipient and reader account against a register with owner, consumer entity, purpose, classification and end date.
• Restrict CREATE SHARE, CREATE ACCOUNT and CREATE RECIPIENT to the platform team.
• Share secure views or curated tables from a dedicated schema; never share raw base tables containing personal data.
• Test each consumer's view before granting, using the platform's consumer simulation or a test recipient.
• Set short expiry on open sharing tokens, attach IP access lists where possible and prefer OIDC federation or platform-native sharing.
• Rotate recipient tokens issued without expiry before the platform's own forced expiry dates.
• Apply MFA, network policies and resource monitors to reader accounts, and remove unused ones.
• Collect share audit events and listing access history into your SIEM and alert on new recipients or accounts added outside the workflow.
• Back every external share with a data sharing agreement covering onward use, deletion at termination, credential handling and audit rights.
• Run quarterly owner attestation and remove recipients with no activity in 90 days.

Standards and references

• Delta Lake project: Delta Sharing Protocol
• Apache Iceberg: REST Catalog OpenAPI Specification
• Databricks: Create a recipient object for non-Databricks users using bearer tokens
• Databricks: Audit and monitor data sharing
• Snowflake: About Secure Data Sharing
• Snowflake: Manage reader accounts
• ICO: Data sharing code of practice, data sharing agreements
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Data Clean Rooms Guide · Databricks Security Guide · Snowflake Security Guide · Data Governance and Data Catalogue Security Guide · Third-Party Access Guide