Providers — Sharing Databases¶
This topic describes the tasks associated with data providers creating and configuring shares, sharing them with other accounts so that they can be consumed, and performing ongoing maintenance of the shares.
In this Topic:
- Data Sharing and ESD (Enterprise for Sensitive Data) Accounts
- General Data Sharing Usage Notes
- Preparing to Share Data
- Creating a Share
- Determining Whether Consumers Have Created Databases From Shares
- Maintaining Shares
You must use the ACCOUNTADMIN role to perform all these tasks, except preparing your database and objects to share, which can be performed using any role.
Data Sharing and ESD (Enterprise for Sensitive Data) Accounts¶
Restrictions for HIPAA ESD Accounts¶
To ensure compliance with HIPAA requirements:
- Snowflake does not allow HIPAA accounts to share data with non-HIPAA accounts, even if the account is an ESD account.
- Both HIPAA accounts (i.e. provider and consumer) must have a signed BAA in place with Snowflake (required for HIPAA compliance); however, they should also have a signed BAA with each other.
Snowflake is not responsible for ensuring that HIPAA accounts who engage in sharing data have a signed BAA with each other; this is at the discretion of the accounts who are sharing data. However, failure to have a signed BAA with each other many impact the HIPAA compliance of both accounts, particularly the provider account.
Important Considerations for Non-HIPAA ESD Accounts¶
Snowflake does not directly enforce any restrictions on non-HIPAA ESD accounts sharing data; however, to maintain the expected level of data protection provided by ESD, Snowflake strongly recommends the following:
- Do not share sensitive data with non-ESD accounts.
- Consider creating a second, non-ESD account where you store less sensitive data and share this data with both your ESD account and other consumer accounts.
In addition, if you are using Tri-Secret Secure with your ESD account and you share data with other accounts, Snowflake treats the data access from these accounts as if the access occurred from within your own account. Specifically, the data access by the consumer account may require Snowflake to access your AWS KMS.
These are only recommendations and are not enforced by Snowflake. The decision to share data is always at the discretion of the data provider and Snowflake does not assume any responsibility for data that is improperly shared.
General Data Sharing Usage Notes¶
Note the following important usage details for creating and maintaining shares:
Currently, consumer accounts must be in the same Snowflake Region as your account; i.e. you can only share with other accounts in your Snowflake Region.
Each share contains a single database, and all other objects included in the share must be from this same database. This is particularly important to note for views, which are defined by referencing one or more tables; the view and the referenced tables must all be in the same database.
If any referenced objects (i.e. tables) are in a different database, the referencing object (i.e. view) will fail when a user in a consumer account attempts to query it.
For data security and privacy reasons, only secure views are supported in shares at this time. If a standard view is added to a share, Snowflake returns an error.
Adding accounts to a share immediately makes the share available to consume by the accounts.
New and modified rows in tables in a share (or in tables referenced by a view in a share) are available immediately to all consumers who have created a database from the share. Keep this in mind when updating these tables.
A new object created in a database in a share is not automatically available to consumers.
To make the object available to consumers, you must use the GRANT privilege command to explicitly add the object to the share.
This also applies to objects that have been dropped from a database and then recreated with the same name in the database; the recreated object is treated as a new object and is, therefore, not accessible until the object has been explicitly granted the necessary privileges in the share.