Share security and governance in Snowflake - Deep Dive

Overview - Share security and governance

What is it?

Share security and governance in Snowflake means controlling who can access shared data and how they can use it. It involves setting rules and permissions to protect data when it is shared between accounts or organizations. This ensures that only authorized users see or modify the data. It helps keep data safe and compliant with policies.

Why it matters

Without proper share security and governance, sensitive data could be exposed to unauthorized people, causing privacy breaches or financial loss. It also helps organizations follow laws and rules about data use. Good governance builds trust between data owners and users, making data sharing safe and effective.

Where it fits

Before learning share security and governance, you should understand basic Snowflake concepts like accounts, databases, and roles. After this, you can explore advanced data sharing features, compliance frameworks, and monitoring tools to manage data securely at scale.

Mental Model

Core Idea

Share security and governance is about setting clear rules to safely share data while controlling who can see or change it.

Think of it like...

It's like lending a book to a friend but deciding if they can only read it or also write notes inside. You trust them but keep control over what they can do.

┌───────────────────────────────┐
│         Data Owner            │
│  (Sets sharing rules & rights)│
└──────────────┬────────────────┘
               │
               ▼
┌───────────────────────────────┐
│        Shared Data             │
│  (Accessible under rules)      │
└──────────────┬────────────────┘
               │
               ▼
┌───────────────────────────────┐
│       Data Consumer           │
│  (Uses data within permissions)│
└───────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Snowflake Data Sharing Basics

Concept: Learn what data sharing means in Snowflake and how it works at a simple level.

Snowflake allows one account to share data with another without copying it. The data owner creates a share object that points to specific databases or tables. The consumer account can then access this shared data directly. This sharing is secure because the data stays in the owner's account.

Result

You can share live data instantly without moving or duplicating it.

Understanding that Snowflake shares data by reference, not by copying, helps grasp why security controls are crucial.

2

Foundation

Roles and Permissions in Snowflake

Concept: Learn how Snowflake uses roles to control access to data and actions.

Snowflake uses roles to grant permissions. Each role has specific rights like reading or writing data. Users are assigned roles, so they only do what their role allows. This system helps enforce security by limiting access based on job needs.

Result

Users can only access data and perform actions their roles allow.

Knowing roles are the building blocks of access control is key to managing share security.

3

Intermediate

Configuring Secure Shares with Access Controls

🤔Before reading on: do you think shared data can be modified by the consumer by default? Commit to your answer.

Concept: Learn how to set up shares so consumers can only read data, not change it.

When creating a share, the owner grants read-only access to specific objects. Consumers cannot modify shared data because Snowflake enforces read-only permissions on shares. This prevents accidental or malicious changes.

Result

Shared data remains unchanged by consumers, preserving data integrity.

Understanding that shares are read-only by default prevents security risks from unintended data changes.

4

Intermediate

Using Network Policies and MFA for Share Security

🤔Before reading on: do you think Snowflake allows restricting data access by IP address? Commit to your answer.

Concept: Learn how to add extra layers of security like network restrictions and multi-factor authentication.

Snowflake lets you define network policies to restrict which IP addresses can connect. You can also require multi-factor authentication (MFA) for users accessing shared data. These controls reduce the risk of unauthorized access even if credentials are compromised.

Result

Only trusted networks and verified users can access shared data.

Knowing how to combine network policies and MFA strengthens share security beyond basic permissions.

5

Advanced

Governance with Data Masking and Row Access Policies

🤔Before reading on: do you think data masking can be applied to shared data? Commit to your answer.

Concept: Learn how to protect sensitive data within shares by hiding or restricting parts of it.

Snowflake supports data masking policies that hide sensitive fields based on user roles. Row access policies can limit which rows a user sees. Applying these to shared data ensures consumers only see data they are allowed to, even within the same table.

Result

Sensitive data is protected and only visible to authorized users.

Understanding that governance can be fine-grained inside shares helps meet compliance and privacy needs.

6

Expert

Monitoring and Auditing Shared Data Access

🤔Before reading on: do you think Snowflake tracks who accessed shared data and when? Commit to your answer.

Concept: Learn how to track and review shared data usage for security and compliance.

Snowflake logs all access to shared data, including user identity, time, and actions. You can query these logs or use Snowflake's ACCOUNT_USAGE views to audit data sharing activity. This helps detect misuse or unusual patterns.

Result

You have visibility into shared data usage and can respond to security events.

Knowing how to monitor shares is essential for maintaining trust and meeting governance requirements.

Under the Hood

Snowflake implements data sharing by creating a secure pointer from the consumer account to the data in the provider account. The data itself never moves or copies. Access is controlled by roles and permissions defined in the provider account, enforced at query time. Network policies and authentication add layers before access is granted. Audit logs record every access event for governance.

Why designed this way?

This design avoids data duplication, reducing storage costs and synchronization issues. It also centralizes control with the data owner, improving security and compliance. Alternatives like copying data would increase risk and complexity. Snowflake's cloud-native architecture enables this seamless, secure sharing.

┌───────────────┐       ┌───────────────┐
│ Provider     │       │ Consumer      │
│ Account      │       │ Account       │
│ ┌─────────┐ │       │ ┌─────────┐   │
│ │ Data    │ │◄──────│ │ Share   │   │
│ │ Storage │ │       │ │ Object  │   │
│ └─────────┘ │       │ └─────────┘   │
│   ▲         │       │               │
│   │ Roles & │       │               │
│   │ Perms  │       │               │
└───┴────────┘       └───────────────┘
       │
       ▼
  Network & Auth
       │
       ▼
  Access Logs & Audit

Myth Busters - 4 Common Misconceptions

Quick: Can a consumer modify shared data by default? Commit to yes or no.

Common Belief: Consumers can update or delete data in a share if they want.

Reality: Shares are read-only for consumers; they cannot modify shared data.

Why it matters: Believing consumers can change data leads to incorrect trust and potential security gaps.

Quick: Does sharing data copy it to the consumer account? Commit to yes or no.

Common Belief: Data sharing duplicates data into the consumer's account storage.

Reality: Data is not copied; consumers query the provider's data directly.

Why it matters: Thinking data is copied causes confusion about costs, latency, and data freshness.

Quick: Can network policies alone fully secure shared data? Commit to yes or no.

Common Belief: Restricting IP addresses is enough to secure shared data.

Reality: Network policies help but must be combined with roles, MFA, and auditing for full security.

Why it matters: Overreliance on one control can leave gaps exploitable by attackers.

Quick: Can data masking be bypassed by consumers? Commit to yes or no.

Common Belief: Data masking is just cosmetic and can be ignored by savvy users.

Reality: Data masking is enforced by Snowflake and cannot be bypassed by consumers.

Why it matters: Misunderstanding masking risks exposing sensitive data unintentionally.

Expert Zone

1

Shares do not grant roles or permissions to consumers; consumers must have roles in their own account to access shared data.

2

Row access and masking policies apply dynamically at query time, allowing flexible governance without data duplication.

3

Audit logs can be integrated with external SIEM tools for advanced monitoring and alerting on shared data usage.

When NOT to use

Avoid using shares when consumers need to modify data or when data must be isolated for compliance. In such cases, consider data replication or ETL pipelines with strict access controls.

Production Patterns

In production, organizations use shares for cross-department analytics, partner data exchange, and marketplace data distribution. They combine shares with automated role management, network policies, and continuous auditing to maintain security at scale.

Connections

Zero Trust Security Model

Share security in Snowflake builds on zero trust principles by verifying every access request regardless of network location.

Understanding zero trust helps grasp why Snowflake enforces strict role-based access and multi-factor authentication for shares.

Data Privacy Regulations (e.g., GDPR, HIPAA)

Governance controls in shares help organizations comply with data privacy laws by restricting and auditing data access.

Knowing privacy regulations clarifies why fine-grained masking and auditing are essential in shared data environments.

Library Lending Systems

Like a library lending books with rules on who can borrow and how to use them, Snowflake shares data with controlled permissions.

This cross-domain connection shows how managing shared resources safely is a universal challenge.

Common Pitfalls

#1 Granting full access to shared data without restricting roles.

Wrong approach:

CREATE SHARE my_share;
GRANT USAGE ON DATABASE my_db TO SHARE my_share;
GRANT SELECT ON ALL TABLES IN SCHEMA my_db.public TO SHARE my_share;
-- No role or network restrictions set

Correct approach:

CREATE SHARE my_share;
GRANT USAGE ON DATABASE my_db TO SHARE my_share;
GRANT SELECT ON ALL TABLES IN SCHEMA my_db.public TO SHARE my_share;
ALTER SHARE my_share SET NETWORK_POLICY = my_network_policy;
-- Roles and MFA enforced on consumer side

Root cause:

Misunderstanding that shares alone control access without combining with roles and network policies.

#2 Assuming consumers can update shared data.

Wrong approach:

Consumer runs: UPDATE shared_db.table SET column = 'value';

Correct approach:

Consumer can only run: SELECT * FROM shared_db.table;

Root cause:

Not knowing that shares are read-only for consumers.

#3 Not auditing shared data access regularly.

Wrong approach:

-- No queries or alerts on ACCOUNT_USAGE.ACCESS_HISTORY

Correct approach:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY WHERE OBJECT_NAME = 'shared_table';

Root cause:

Ignoring the importance of monitoring for security and compliance.

Key Takeaways

Snowflake shares data securely by allowing read-only access without copying data.

Roles and permissions are essential to control who can see shared data and what they can do.

Additional security layers like network policies and MFA protect shared data from unauthorized access.

Governance features like data masking and row access policies help protect sensitive information within shares.

Monitoring and auditing shared data access is critical to maintain security and compliance.