Secure Data Sharing

1. Secure Data Sharing

In this chapter we move from governing data within Claro's own account to sharing it with the outside world — safely and deliberately. This video covers Snowflake's secure data sharing model: how data gets shared between accounts without ever being copied, who the players are, and how to handle partners who don't have their own Snowflake account.

2. Problem with Traditional Data Sharing

Claro wants to share aggregated credit risk data with a partner bank. The traditional approach: extract the data, transform it, transfer it via SFTP or an API, then have the partner load it into their system. By the time it lands, it's already out of date. It's a copy, copies drift, they need refreshing, reconciliation, and securing at every step. Snowflake's sharing model eliminates all of that.

3. How Snowflake Sharing Works

Snowflake sharing gives a consumer account direct read access to objects in the provider's account — without copying any data. The underlying storage is shared. When the partner bank queries the shared database, they're reading from Claro's data in real time. The moment Claro updates a record, the partner sees the update on their next query. No pipelines, no stale copies and no transfer risk. All data lives in one place.

4. Creating The Share

Creating a share involves three steps. First, create the share object itself. Second, grant the objects you want to expose: USAGE on the database and schema, SELECT on the specific table. The same USAGE hierarchy from Chapter 1 applies. Third, grant the share to the consumer account by specifying their account identifier. From that point, the partner bank can see the share. Claro controls exactly what's in it and can add or remove objects and accounts at any time.

5. Mounting a Share

On the consumer side, setup is a single step: CREATE DATABASE FROM SHARE. The partner bank specifies the share reference and gives it a local database name. From that point, they query it like any other database. The SELECT looks identical to any other query. But nothing has moved. Every query reads from Claro's storage in real time. The consumer can query but cannot write, clone, or re-share the data.

6. Reader Accounts

Not every partner has a Snowflake account — that's where reader accounts come in. Claro creates and manages the reader account on the partner's behalf: a lightweight Snowflake account with one purpose, querying the share. The partner gets credentials and can query the shared data immediately. The trade-off: with a standard consumer account, the consumer pays for their own compute. With a reader account, Claro pays for the compute. Reader accounts are also limited to shared data only.

7. Secure Views in Sharing

By default, Snowflake shares are configured with SECURE_OBJECTS_ONLY set to true, meaning only secure views can be shared. A secure view lets the consumer query results but hides the view definition entirely, so the partner bank cannot inspect the underlying SQL or see which columns were excluded. You can set SECURE_OBJECTS_ONLY to false to allow sharing standard views, but Snowflake strongly recommends against it when the underlying tables contain sensitive data.

8. Let's practice!

Now it's your turn to set up a share and mount it as a consumer. Let's practice.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.