Snowflake敏感数据共享：选择合适控制层级

A practical guide for Snowflake customers and practitioners

Data sharing is rarely a simple yes-or-no decision.

A public reference dataset, an internal operational table, a customer-level record, and a patient-level clinical dataset may all be “data,” but they do not carry the same disclosure risk. Treating them identically creates one of two problems: sensitive data is exposed too broadly, or low-risk data becomes so difficult to access that its value disappears.

The better approach is to treat data sharing controls as a spectrum. As sensitivity and collaboration risk increase, the sharing pattern should move from broad access toward curated views, policy-controlled access, privacy-preserving analytics, and — at the highest end — results that are intentionally protected against re-identification.

Snowflake provides capabilities across that spectrum. The important design question is not “Which Snowflake security feature should we use?” It is “How much of the underlying data should the consumer be allowed to see, and what should they be allowed to do with it?”

A useful spectrum for data sharing

Many organizations use labels such as Public, Internal, Confidential, and Highly Confidential. The exact labels vary, but the principle is consistent: protection requirements should increase with the potential impact of unauthorized disclosure.

For Snowflake practitioners, a five-level model is useful:

• Level 1: Public or low-risk data
• Level 2: Internal or limited-partner data
• Level 3: Confidential business data
• Level 4: Personal or regulated data
• Level 5: Highly sensitive data requiring privacy-preserving analytics

These are not Snowflake-defined classifications. They are an architecture framework for selecting an appropriate sharing pattern.

Quick decision tree: how much access should you grant?

Start with the minimum-access question: what does the consumer actually need to accomplish?

• Is the data intentionally public? → Use marketplace listing with standard RBAC.
• Is the data limited to a partner or internal audience? → Use a private listing with database roles and object grants.
• Does the consumer need only selected rows or columns? → Share (secure) views and/or secure UDFs. Add row access policies and account-specific filters.
• Does the data contain personal or regulated attributes? → Apply masking, tagging, tokenization, and row-level controls before sharing.
• Could repeated queries reveal an individual or a small group? → Use aggregation or projection policies, and — when needed — Differential Privacy. Consider if Data Clean Room with approved query patterns could help.

Choose the more protective pattern first, validate the consumer experience, and relax controls only when the business requirement justifies it.

Level 1: Public or low-risk data

Examples include published statistics, product reference data, public economic indicators, or datasets intentionally offered to a broad audience.

At this level, the primary concern is usually integrity, availability, and clear licensing — not preventing every consumer from seeing the values. A public listing or broadly discoverable data product may be appropriate. Snowflake listings can provide metadata, discovery, and distribution options, while direct shares support read-only access for selected accounts. Snowflake’s collaboration overview describes listings, direct shares, and reader accounts as different ways to distribute data.

The baseline controls still matter:

• Use Snowflake role-based access control to manage who can administer and publish the data product.
• Keep the shared object read-only for consumers.
• Define ownership, usage expectations, and licensing in the listing metadata.
• Monitor usage where listing telemetry is available.
• Confirm that no sensitive columns, metadata, or embedded credentials are included.

Even when the data is intended to be public, classification should happen before publication. A common failure mode is publishing a “mostly public” table that contains one internal column, operational identifier, or quasi-identifier that was not intended for distribution.

Level 2: Internal or limited-partner data

This level covers data that is not secret, but should not be broadly available. Examples include internal operational metrics, partner-specific reference data, non-public performance information, and data shared with a defined group of customers or suppliers.

The appropriate pattern is usually a targeted Secure Data Share or private listing. Snowflake Secure Data Sharing provides read-only access to selected database objects, and the data remains in Snowflake rather than being copied into the consumer account. The Secure Data Sharing documentation explains that sharing uses Snowflake’s services layer and metadata store between accounts.

At this level, use access controls to narrow the audience:

• Share with specific consumer accounts rather than publishing broadly.
• Use database roles and object grants to limit access to the intended schemas, views, and tables.
• Separate provider administration from data stewardship using distinct roles.
• Use private listings when consumers should discover or request access to a data product without making it public.
• Validate the consumer account and region before granting access.

For many internal use cases, this is enough. The consumer can query live, governed data, but the provider retains control over what objects are included in the share.

Level 3: Confidential business data

Confidential data may include customer-level business records, pricing information, proprietary research, contract-related data, or detailed operational data. The consumer may be trusted, but direct access to the base table is still unnecessary or undesirable.

This is where secure objects become important. Snowflake strongly recommends sharing secure views and/or secure UDFs instead of directly sharing sensitive tables. Secure views can expose only the required columns and rows while protecting the underlying tables and view definitions. Snowflake’s secure-object guidance provides examples of using account-aware filtering (which also be done using Row Access Policies) to show different rows to different consumer accounts.

A practical design is to maintain separate private and public schemas:

• Private schema: base tables, mapping tables, entitlement logic, and sensitive business logic.
• Public schema: secure views or secure UDFs intended for sharing.
• Share: only the public schema objects required by the consumer.

This pattern supports several controls at once:

• Row-level filtering based on the consumer account.
• Column selection and transformation.
• Account-specific entitlements.
• Protection of underlying table names, joins, and business logic.
• Consumer simulation before publishing the share.

The SIMULATED_DATA_SHARING_CONSUMER session parameter can help providers test what a specific consumer account will see before granting access. That validation step is especially important when a single secure view serves multiple customers with different entitlements.

Level 4: Personal or regulated data

Personal and regulated data includes PII, PHI, payment data, identifiers, and other data governed by legal, contractual, or industry requirements. The question is no longer only “Who can query this?” It is also “Which fields should this user see, in what form, and for what purpose?”

Snowflake Dynamic Data Masking applies masking policies at query time, allowing authorized users to see cleartext while other users see fully masked, partially masked, obfuscated, or tokenized values. The Dynamic Data Masking documentation describes this as a column-level security capability that evaluates the query context and role hierarchy at runtime.

For larger estates, tag-based protection can reduce manual policy administration. A masking policy can be associated with a tag, and the policy can then apply automatically to tagged columns across databases, schemas, tables, or views. Snowflake’s tag-based masking guidance explains how tagging and policy inheritance can automatically protect new columns and objects.

Common controls for this level include:

• Sensitive-data classification and tagging
• Tag-based masking for PII and regulated attributes.
• Row access policies for tenant, geography, provider, or consent boundaries.
• External tokenization when the original value should be replaced before or during ingestion.
• Secure views that expose only the minimum necessary fields.
• Access History and policy monitoring for auditability.
• Business Critical or other regulated-account configurations where required by the use case.

Snowflake also supports sharing data protected by masking and row access policies through shared database roles. This lets the provider define policy conditions that recognize an approved shared role in the consumer account. The policy-protected sharing documentation describes this pattern for shared masking and row access policies.

A key design principle is to apply the protection before the data crosses the collaboration boundary. Do not rely on the consumer to mask or filter the data after receiving a broad share.

Level 5: Highly sensitive data and joint analysis

Some datasets are too sensitive for raw-record sharing even when the partner is trusted. Examples include patient-level healthcare data, identity graphs, household-level marketing data, fraud intelligence, and datasets where a small filtered result could reveal an individual.

For these cases, Snowflake Data Clean Rooms provide a more constrained collaboration model. The parties can collaborate on approved analyses without exposing the raw underlying data to one another. Snowflake’s public article What Is a Data Clean Room, and Do You Need One? presents the decision point clearly: Secure Data Sharing is appropriate when partners can access live data within acceptable privacy boundaries, while a clean room is more appropriate when data is sensitive or regulated and collaboration risk is high.

Clean-room designs can combine:

• Secure Data Sharing as the underlying data-access mechanism.
• Row access policies and database roles.
• Stored procedures that generate and validate approved requests.
• Query restrictions and allowlisted templates.
• Aggregation thresholds and suppression of small groups.
• Custom logging and audit events.
• Anonymized or aggregated outputs rather than raw rows.
• Differential Privacy policies

Snowflake’s Data Clean Room Q&A describes this model as “sharing without showing.” It also discusses noise, timestamp constraints, and small-count suppression as protections against triangulation and re-identification.

Differential Privacy Policies

Data Clean Rooms can also turn on/define differential privacy policies when the highest-risk use cases may require stronger privacy guarantees. Data Clean Rooms offer their own differential privacy settings (epsilon, privacy budget) per template. Snowflake Differential Privacy, which uses privacy policies, is a separate feature for direct sharing. Tables protected by privacy policies cannot be linked into a clean room.

Snowflake Differential Privacy dynamically adds noise to query results. The amount of noise increases as a query becomes more sensitive — for example, when it targets a small group or potentially an individual. The consumer can analyze the dataset without seeing row-level data or directly reverse-engineering sensitive information. Privacy policies cannot be combined with masking or aggregation policies on the same table or view, and pairing them with projection policies causes queries to fail. Choose one per object, or apply them at different layers.

Aggregation policies and projection policies provide additional layers. Aggregation policies constrain queries so that results are based on sufficiently large groups, while projection policies can prevent sensitive columns from being directly projected in query results. See Snowflake’s public documentation for aggregation policies and projection policies.

These controls are not interchangeable:

• Masking hides or transforms values.
• Row access policies restrict which records are visible.
• Projection policies restrict whether a column can be returned.
• Aggregation policies require analysis at a group level.
• Differential privacy adds mathematical protection against inference and re-identification.
• Data Clean Rooms govern which parties can run which analyses and what results can leave the environment.

A practical decision sequence

When designing a new sharing use case, work through these questions in order:

1. Is the data intentionally public, or does it contain any internal, personal, or regulated attributes?
2. Does the consumer need raw records, or only a curated subset?
3. Does the consumer need cleartext values, or would masked, tokenized, or transformed values satisfy the use case?
4. Should access vary by consumer account, role, geography, tenant, or consent status?
5. Could repeated queries reveal a person or a small group even if the output is aggregated?
6. Does the consumer need freedom to explore, or should the provider approve a limited set of analyses?
7. What evidence is required to demonstrate who accessed the data, what they queried, and which policies applied?

The answers naturally lead to a control pattern. Low-risk data may need only a listing and standard access controls. Confidential data often benefits from secure views and account-specific filtering. Regulated data typically requires masking, row access, tagging, and auditability. Highly sensitive collaborative analysis may require a clean room, aggregation controls, or differential privacy.

Final takeaway

The strongest Snowflake architectures do not treat security as a single feature. They compose controls according to the sensitivity of the data and the trust model of the collaboration.

Use the least restrictive pattern that satisfies the business requirement — but no less restrictive. Share openly when the data is genuinely public. Curate and govern when the data is confidential. Mask and filter when it contains personal or regulated attributes. When partners need insights but should not see the underlying records, move to clean rooms, aggregation policies, and differential privacy.

That spectrum gives teams a practical way to increase data collaboration without making raw data exposure the default.

Sources

• About Secure Data Sharing — Snowflake Documentation
• Use secure objects to control data access — Snowflake Documentation
• Share data protected by a policy — Snowflake Documentation
• Understanding Dynamic Data Masking — Snowflake Documentation
• Tag-based masking policies — Snowflake Documentation
• What Is a Data Clean Room, and Do You Need One? — Snowflake
• Snowflake Data Clean Room Q&A — Snowflake
• Unlock the Value of Sensitive Data with Differential Privacy — Snowflake
• Aggregation policies — Snowflake Documentation
• Projection policies — Snowflake Documentation

Sharing Sensitive Data on a Spectrum: Choosing the Right Snowflake Control was originally published in Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.