Snowflake Secure Data Sharing lets an account share selected database objects with another account. Its access-control model also permits role inheritance. Snowflake data sharing and access control together make the effective grant path the central question for a customer-account assessment.
Quick answer. A Snowflake data sharing assessment should trace which role can create or modify a share, which objects and columns are exposed, which consumers receive access, and how changes are logged. Test with synthetic data and authorized account roles. Stingrai can scope human-led cloud and application testing around the customer-controlled account, integration and connected API.
A role inherited by an operator can give that operator authority to manage a share. Consumer-visible exposure can broaden when the provider changes a grant, adds an object or account, changes a shared view or policy, or changes the data in a directly shared table. Those are separate customer-controlled decisions to test. Snowflake documents both role inheritance and that updates to existing shared objects become available to consumers. Snowflake access control and sharing overview
The buyer's test matrix
Use this matrix to agree expected decisions before testing. Replace generic actors and objects with an approved provider account, share, consumer account, identity, secure view and synthetic dataset. Each row calls for both a configuration observation and, where authorization permits, a consumer-visible result.
Boundary | Expected decision | Safe test | Evidence to keep | Control owner |
|---|---|---|---|---|
Share operator | Only approved active roles can create or modify a named share | Compare a permitted operator with a deliberately restricted role | Active role, inherited path and result | Platform owner |
Object grant | Only approved objects are granted to the share | Compare | Grant list and consumer result | Data owner |
View output | The view definition or masking policy exposes only intended fields and rows | Compare synthetic sensitive fields for approved and denied consumer accounts | View definition, expected policy and redacted result | Analytics owner |
Recipient account | Only named consumer accounts receive the share | Review | Target and imported-account lists, query outcome | Sharing administrator |
Consumer role | Consumer users have only intended read access to the imported database | Compare authorized and restricted roles inside the test consumer account | Consumer grants and role-specific result | Consumer administrator |
Change evidence | The team can identify who changed a share or view | Correlate test change, grant history and consumer observation | Actor, timestamps and telemetry limits | Security operations |
Figure 1: A practical evidence path for this assessment. The stages are an editorial test-planning model based on the cited provider documentation.
Establish the provider and consumer boundary
The provider creates a share and grants selected database objects to it. The consumer creates a read-only imported database from that share and controls which of its own roles may query the imported objects. Snowflake states that Secure Data Sharing does not copy or transfer the shared data as part of the sharing operation. This matters to a buyer because a provider grant and a consumer role grant answer different questions. A provider test establishes what the share exposes to the consumer account. A consumer test establishes which users within that account may read it. Snowflake, About Secure Data Sharing
Make the data contract explicit before testing. Record the approved provider account, consumer account, share name, database, schemas, tables or views, and the fields and rows that should be visible. For a test with more than one consumer, record the intended result for each consumer separately. An approved account receiving a broader row set than its contract permits is a different finding from an unapproved account receiving the share at all. Likewise, a consumer user receiving access through an overly broad local role is a consumer-side control issue, not necessarily a provider-side grant error.
A direct share and a listing are not interchangeable for scoping. Snowflake describes a direct share as a route to another account in the same region, while cross-region delivery uses other sharing mechanisms. If the business request spans regions, the proposal needs to name the actual mechanism and each account involved rather than assume that the same direct-share test covers it. Snowflake, About Secure Data Sharing A BI export, API response or downstream file made from query results is another boundary again. Include it only with authorization from its owner; do not imply that a Snowflake share assessment covers every later use of the data.
Trace authority to the share operation
Snowflake roles can be assigned to other roles, so an operator's active role may inherit authority that is not visible in a screenshot of the operator's direct assignment. Both a session's primary and secondary roles can contribute to some authorization decisions, but Snowflake uses the primary role for CREATE statements. Snowflake, Overview of Access Control The test plan should trace the selected human or service identity to its active role, inherited role chain, and relevant share privilege. Creating a share requires CREATE SHARE; managing an existing share requires the role to hold both share ownership and that global privilege. Snowflake describes the distinction in its provider guide. Snowflake, Create and configure shares
Use a permitted test operator and a role that the owner says must not manage the share. Have each attempt the same safe action against a disposable test share, such as adding a synthetic view or approved consumer. Keep the active role and the observed decision together. If the restricted operator succeeds, the report should identify the inherited grant or ownership path that enabled it. If it fails as expected, record that denial as a passing control rather than silently omitting it. Do not label a powerful administrator role as a vulnerability simply because it can administer shares; compare its authority with the organization's approved delegation.
The provider should also distinguish who can manage the share from who can alter the underlying view. An analytics role that can redefine an already shared view may change consumer-visible fields even without touching the share's object grants. Conversely, an operator with share management rights may add an object without changing the view. Those are separate change paths, owners and retests. Snowflake notes that changes to existing shared objects become available to consumers and that newly added objects become available when granted to the share. Snowflake, About Secure Data Sharing
Compare the approved inventory with effective grants
Snowflake supports adding objects to a share by direct grants or by granting a database role to the share. Use SHOW GRANTS TO SHARE for object privileges. For recipients, SHOW SHARES shows outbound shares and a to column, but that column displays at most three accounts. For the full target list, Snowflake directs providers to SNOWFLAKE.ACCOUNT_USAGE.SHARES.TARGET_ACCOUNTS, which can lag by up to three hours. SHOW GRANTS OF SHARE answers a different question: which accounts have already created a database from the share. It omits accounts that were added but have not imported it. Snowflake, Create and configure shares and SHOW SHARES reference The assessor should reconcile the full target list, actual importers and object grants with the approved data contract. A list of shared databases alone is too broad a description; the same database may contain several schemas, and a share can expose a table, view or other supported object within it.
For each approved object, ask the owner what the consumer should be able to query. Then query a synthetic marker object from an authorized test consumer and attempt a distinct marker object that should remain absent. This positive and negative pair shows whether the grant list corresponds to the actual consumer result. If the provider uses database roles, include the role-to-share path; otherwise the report may miss why an object is reachable. A provider-side grant inventory remains configuration evidence until a consumer query confirms the observed exposure.
Test changes deliberately. Add a synthetic object to the test share, verify that the intended consumer sees it, revoke its grant, and verify that access disappears. The business owner should approve each mutation and a rollback. Snowflake documents that objects added to a share become available to consumers and that access to a share or object can be revoked. Snowflake, About Secure Data Sharing The report must distinguish the expected behavior of the platform from an unexpected grant in the customer's configuration.
Decide whether the shared object matches the data contract
The object choice is itself a security decision. Snowflake says an entire table can be shared without preparation, while filtering data by a condition or consumer account calls for one or more secure views. Snowflake, Create and configure shares Ask the data owner whether the consumer is meant to receive the full approved table, a defined column set, or a subset of rows. A direct table grant should not be accepted as a substitute for the intended filtered view merely because the consumer can run the expected sample query. Conversely, do not call full-table access a flaw if the approved data contract genuinely includes that whole table and the customer has checked applicable policies.
Build a small fixture that makes the distinction observable. Include an allowed row, a row assigned to a different test consumer and a field that the business owner marks as restricted. The test should show the set returned by the actual shared object, not just that a query succeeded. Capture the object's identity and current definition with the result. If a policy protects the base table or view, capture the policy's expected effect too; a secure view label alone is not the decision record. Snowflake, Working with Secure Views For teams that change views through deployment pipelines, ask which approval and regression check runs before a definition change reaches an already shared object. Snowflake says updates to existing objects in a share become available to consumers, making that change path part of the exposure review. Snowflake, About Secure Data Sharing
This produces a useful purchasing question: will the assessor inspect only the share's grant list, or also the definitions and policies that determine what its granted objects return? A grant-list-only review may be enough for a narrow inventory exercise. It cannot support a conclusion about per-consumer row or field limits without the output test. State the difference in the SOW so a data owner receives the answer they actually need.
Test secure-view output, not its label
A secure view can be used to limit shared rows or fields, but the SECURE designation is not a substitute for reviewing its definition and actual output. Snowflake warns that a data owner can inadvertently expose information through a secure view that was not constructed carefully. Snowflake, Working with Secure Views For the test, prepare synthetic rows that are deliberately assigned to different consumer accounts and columns that represent allowed and restricted fields. Record the expected row and field set for each account. Confirm the view definition or masking policy implements that expectation, then observe the result as each approved test consumer.
The context functions are consequential. Snowflake says CURRENT_ROLE and CURRENT_USER return NULL inside a secure view shared to another account. It recommends CURRENT_ACCOUNT for account-specific row authorization. Snowflake, Working with Secure Views A provider-side view that relies on these context functions should therefore be tested against consumer-account context, not an imagined consumer role visible to the provider. Snowflake also offers SIMULATED_DATA_SHARING_CONSUMER for simulating a secure view's output for a consumer account. Use that to catch a view definition mistake before the consumer test, then query from the real authorized test account where available. The simulation and the live consumer result are distinct pieces of evidence. Snowflake, Create and configure shares
There is a separate policy-protected sharing pattern. Snowflake documents sharing a database role with the consumer and using IS_DATABASE_ROLE_IN_SESSION in a masking or row access policy. That can make the consumer's shared database role relevant to the policy result, even though CURRENT_ROLE in a provider secure view is not the consumer's account role. Snowflake, Share data protected by a policy If this design is in use, the SOW should include the policy, shared database role and consumer activation path. The test should prove the intended masked and unmasked result under controlled roles, and report it separately from a simple CURRENT_ACCOUNT row filter. This avoids treating all shared-view access decisions as though they use the same context function.
Inside the consumer account, test its local roles separately. A consumer role may lack access to the imported database even when its account is an approved recipient. Conversely, a consumer administrator may grant local users broader read access than the provider expected. Snowflake documents that the consumer configures access to the imported database using its own role-based access control. Snowflake, About Secure Data Sharing The report should label these results as consumer-account authorization findings. The provider cannot infer the consumer's full role design from a provider share listing.
Avoid live personnel or commercial data in this test. Synthetic rows with deliberately different account markers can establish whether a filter works without displaying actual records in evidence. If the customer cannot provision a consumer test account or a representative view, say that the assessment verified grants and simulated output only. Do not claim a full consumer-side authorization test from a provider configuration screenshot.
Use the right evidence source for each question
The immediate configuration answer comes from the current share and grant state. Snowflake's GRANTS_TO_SHARES Account Usage view can also show historical grants, including revoked privileges, but the documentation notes that it can lag current state. Snowflake, GRANTS_TO_SHARES A buyer should therefore ask for a timestamped current grant capture alongside any historical view, rather than treating a delayed history row as the live truth. Preserve role names and object names where they explain the decision, but redact credentials, sensitive identifiers and query result values.
Ask the security team to distinguish share administration telemetry from consumer query evidence. A consumer query result proves what the test consumer saw. Provider-side sharing configuration shows what was offered. Listing usage views apply to specific listing and data-exchange arrangements, so do not promise that every direct share yields the same consumer-usage telemetry. Snowflake, About Secure Data Sharing If the report relies on account query history, state which account supplied it and any visibility or retention limit. A test with unavailable logs can still prove an authorization outcome, but it cannot claim that operations security would have detected the change.
The evidence package should let a data owner repeat the decision: the approved rule, test identity, active role, share and object, consumer account, sanitized query, observed row and field set, grant path, relevant change event and remediation owner. Keep the positive and negative case together. A denial without the consumer's intended privilege could reflect a broken fixture; a successful query without an approved expectation cannot establish excessive access.
Test recipient removal as a separate control
Object revocation and recipient removal answer different questions. Snowflake documents that a provider can revoke access to an object or share, and that removing a consumer account from a share immediately removes that account's access to the shared data. Snowflake, About Secure Data Sharing If the customer's concern is offboarding a partner, a test that only revokes one table privilege does not establish that the account has lost the rest of its shared access. The SOW should identify which offboarding decision the buyer expects to prove.
Use a disposable share or an approved test recipient. First show that the test account can query the synthetic object under a local role with access to the imported database. Record the provider recipient list and the consumer query result. Then remove the test account from the share under the approved change window and repeat the same query. Preserve the provider change and the consumer denial together. If the test requires restoring access, document that rollback and run the positive case again. This sequence distinguishes a provider-side account change from a consumer-side role change that merely hides the database from one user.
The conclusion must stop at the share boundary. Snowflake's sharing operation does not copy the shared data, but a consumer application may have saved query results elsewhere. Snowflake, About Secure Data Sharing Removing the account should end access through the share; it does not establish that previously exported files, dashboards or downstream databases were erased. Those assets need their own owners and evidence if the buyer wants a complete partner offboarding assessment.
Put measurable boundaries in the statement of work
The SOW should name the provider account and test consumer accounts, test share, included database objects, view definitions or policies available for review, human and service identities, and connected applications that are explicitly in scope. It should identify who may authorize a grant change and who may restore the original configuration. Snowflake's provider documentation identifies separate commands and privileges for creating a share, granting an object and adding an account, so a generic instruction to “test Snowflake” leaves material actions unspecified. Snowflake, Create and configure shares
Specify an allowed change window, maximum synthetic dataset, approved query patterns, monitoring contact and stop condition. If a consumer is controlled by a separate organization, require that organization's authorization for active queries or role changes. A provider's consent to review its own share does not extend to testing the consumer's users, warehouse or applications. Keep the provider-managed service itself and unrelated accounts out of scope unless their owners explicitly approve them.
An acceptance criterion can be written plainly: the authorized consumer sees the named synthetic view and only the approved row and field set; the denied consumer cannot query it; the permitted operator can perform the agreed share change; the restricted operator cannot; after an approved revocation, the consumer no longer reaches the object. Record exceptions and environmental limits before execution. This is more useful to procurement than a promise to run an unspecified scan, because each result maps to a business decision and a control owner.
Remediate the mechanism and retest the consumer result
The fix depends on the mechanism. For an excessive provider object grant, remove or narrow the grant and review other shares that use the same database role. For an overbroad view, revise its definition or policy and test every intended consumer account with synthetic fixtures. For an unintended recipient, revoke the account from the share and verify the resulting denial. For an operator with excessive management authority, change the relevant role inheritance or privilege and repeat the denied management action. These paths follow Snowflake's distinct share, object and role controls. Snowflake, Create and configure shares and Overview of Access Control
A retest should repeat the original actor, object and consumer query after the fix. Retesting only a grant screenshot can miss a view that still exposes the field, while retesting only a view query can miss a different consumer account that still has the share. If a downstream BI tool or API copied the result earlier, its cleanup is a separate workstream with its own owner and authorization. The report should close only the boundary it actually retested and describe any remaining dependent work accurately.
What Stingrai can scope
Stingrai is a CREST-accredited penetration testing company with human-led web, API and cloud testing for regulated and enterprise environments. A quote for this topic should begin with the named customer-owned assets and their authorization boundaries. The testers can compare role or identity behavior, document confirmed findings with proof and remediation guidance, and retest remediated findings. Stingrai's service overview describes the available assessment areas.
A one-time assessment can answer a defined procurement or audit question. For a changing integration or cloud configuration, the buyer may choose a continuous program as well. The SOW should state the coverage and evidence expected in either model. Findings should support the customer's own security and audit program without substituting for the customer's control ownership.
Frequently Asked Questions
What does a Snowflake data sharing security assessment cover?
It covers customer-controlled role hierarchy, share administration, grants, secure views, consumer accounts, service identities and relevant change telemetry for named shares and datasets.
Does a share-grant review replace a consumer-side test?
No. Grant review explains intended configuration; a controlled consumer query shows the data actually visible across the account boundary.
Should production data be copied into a test share?
Use synthetic rows and fields whenever possible. The goal is to prove an access decision and its remediation without placing sensitive business records in screenshots or logs.
What should a buyer require in the SOW?
Require named accounts and shares, roles, approved test consumer, expected object and field access, authorization limits, redacted evidence, owners and retest criteria.
Related reading
Talk to Stingrai
Share the assets, identities and expected access decisions you want tested. Get a Quote or book a free discovery call to define the authorization boundaries and deliverables.
