Snowflake security operating model

Summary

A Snowflake security program needs identity controls, role design, network controls, data-protection policies, audit evidence, and a review process. Map each control to an owner and protected resource. Test the effective access path from the user or service identity to the data returned by a query. Feature availability varies by Snowflake edition and account configuration. Verify every feature in the target account before using this guide as an implementation plan.

Start with account and identity boundaries

Inventory accounts, organizations, regions, identity providers, integrations, service users, and administrative roles. For each identity, record: Separate interactive users from applications and automation. Remove shared credentials from routine workflows. Use approved strong authentication and identity-provider controls for human access. Two identity patterns pay for themselves quickly. Route human users through the identity provider with single sign-on and multi-factor authentication, so that joiner, mover, and leaver events in the provider control Snowflake access. Move service users to key-pair authentication with a rotation schedule, and set the user type so that no service identity can hold a password for interactive login. A service user with a password is the credential that ends up in a notebook.

Human or workload identity
Authentication method
Assigned roles
Owner
Environment
Last use
Expiration or review date
Emergency-access status

Design the role hierarchy around responsibilities

Define roles for job responsibilities and workload functions. Keep object ownership and policy administration separate from routine data use. A review should answer: Avoid granting routine users broad administrative roles. Review direct grants and inherited grants together. A workable pattern uses three layers. Access roles carry privileges on objects, such as read on one schema. Functional roles describe a job, such as finance analyst, and inherit access roles. Users receive functional roles. This pattern makes a review question mechanical: list the access roles under one functional role, and confirm each one belongs to that job. Future grants and managed access schemas decide how the design ages. Future grants apply the pattern to objects that do not exist yet, which prevents each new table from arriving unprotected. Managed access schemas move grant control from object owners to schema or security administrators, which stops a well-meaning table owner from widening access outside the review process.

Which role grants access?
Which parent role inherits it?
Which database, schema, table, view, or warehouse is covered?
Does the role need read, write, operate, or ownership privileges?
Can the role grant access to another role?
Which user or service can assume the role?

Add network and session controls

Define how users, services, partner tools, and private networks connect. Use account-level and narrower policies according to the architecture. Test: Keep a recovery path that does not depend on the control being changed. A network policy that blocks every source, including the administrator's, still needs an operator who can reach the account to repair it. Keep one break-glass identity outside the identity provider, protected by strong authentication, monitored, and tested on a schedule. For live data paths, prefer private connectivity such as AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect over public endpoints with broad allow rules. Session policies that shorten idle timeouts reduce the window in which a stolen session token remains useful.

Approved and blocked source networks
Private connectivity paths
Client and driver versions
Session and authentication policies
Break-glass access
Recovery from a policy error

Classify sensitive data

Create a controlled classification vocabulary and map tags to data-protection rules. The workflow should include: Discover candidate sensitive columns. Review the classification. Apply the approved tag or record. Attach the required policy. Test with authorized and unauthorized roles. Monitor unclassified and unprotected data. Classification output is a review input. The data owner remains responsible for the approved classification and control. Tags make protection follow the data. A tag such as a personal-data class can carry a masking policy, and every column tagged with it receives the same treatment. Tag propagation covers derived objects such as views built on tagged columns, which closes the most common gap between the classified base table and the unclassified view on top of it.

Enforce column and row protection

Snowflake masking policies can transform a column value at query time. Row access policies determine which rows a query returns. Snowflake also documents aggregation, projection, and join policies for specific protection requirements. For each policy, record: Test the policy on the assigned table or view. The existence of a policy object does not show that sensitive data is covered. Two behaviors deserve direct testing. A masking policy decides its result from the role executing the query, so test with every role that can reach the object, including roles that arrive through a share. Policy conditions that read session context can interact with cached or reused query results, so test the unauthorized role with a fresh query rather than assuming the mask applies because it applied in an earlier session.

Policy owner
Protected object
Classification or business rule
Allowed roles and contexts
Expected result
Test identities
Last successful test
Exception process

Protect shared data

Before sharing data, define the provider, consumer, permitted use, objects, policies, refresh behavior, region, duration, and revocation process. Test policy behavior in the consumer context. Snowflake documents specific policy and context-function behavior for sharing and resharing. Review those limits before enabling a downstream path. Keep a register of active shares and listings with owners, consumers, data classes, approvals, and review dates. The register matters because shares outlive the projects that created them. A share with no review date is a permanent data flow with no owner.

Build audit evidence

Use Snowflake account and organization usage records to investigate authentication, queries, grants, object changes, policy references, and data access. The ACCESS_HISTORY view can support questions such as: Define retention, export, alerting, and investigation procedures for the evidence required by the organization. Plan for the latency of these views. ACCESS_HISTORY and related ACCOUNT_USAGE views can lag real time by up to a few hours, which is acceptable for weekly reviews and unacceptable for live alerting. Use the information schema or event tables where the response time matters, and export ACCOUNT_USAGE records before their retention window closes if the organization needs a longer history than Snowflake retains.

Who accessed an object?
When did access occur?
Which columns or base objects were involved?
Which masking or row access policies protected the query path?

Monitor control coverage

Measure coverage and effectiveness separately. Useful measures include: Snowflake Trust Center findings can identify some missing configurations. Snowflake states that certain checks verify the presence of a policy without evaluating whether the correct data is protected. Add resource-level tests. Coverage questions belong in scheduled queries, and effectiveness questions belong in tests. A query can count sensitive columns with no policy. Only a test with a known identity can show that the right value came back masked.

Active users without a recent review
Dormant service users
Administrative-role assignments
Sensitive columns without an assigned policy
Policy objects without protected resources
Active shares past their review date
Failed authentication and unusual access
Security findings without an owner
Break-glass use and closure time

Failure modes in a Snowflake security program

Four failure modes recur. The first is grant sprawl through inheritance. A functional role inherits one access role too many, and every holder gains the extra schema. The three-layer review pattern and a periodic role-graph diff against the approved design catch the drift. The second is the unprotected new object. A team creates a table from a pipeline, and no policy or future grant covers it. Default protection through future grants, plus a daily query for untagged sensitive columns, closes the window. The third is the untested policy change. A masking policy edit intended to widen access for one role widens it for every role. The staged change procedure in the next section exists for this case. The fourth is evidence without retention. An investigation starts ninety days after an event, and the relevant usage records have aged out. Decide the retention requirement before the incident, and export accordingly.

Change controls safely

Apply security changes through reviewed, versioned deployment paths. Test role and policy changes with representative identities. For high-impact changes: Record the intended access result. Identify affected roles and objects. Test in a lower environment or controlled scope. Prepare a recovery path. Deploy with an evidence record. Verify effective access. Monitor for denied or expanded access. Manage roles, policies, tags, and grants as code where the organization already has that practice. A declarative definition of the security model, reviewed in version control, gives the audit trail that manual console changes cannot.

Cost and scale trade-offs

Security controls carry operating cost, and the design should show it. Edition choice is the largest lever, because data-protection policies, private connectivity, and several governance features depend on the edition. Price the edition against the controls the inventory actually requires rather than against a feature list. Compute cost follows the monitoring design. Scheduled ACCOUNT_USAGE scans, classification runs, and test suites consume warehouse credits. Small dedicated warehouses with tight auto-suspend limits keep that cost visible and bounded. Administrative scale follows the role design. An object-by-object grant model grows linearly with tables and consumes reviewer attention on every change. A tag- and role-layer model concentrates effort on a small number of policy objects, and the same small team can govern a much larger estate.

Design for the reviewer who inherits the controls

Design for the reviewer, and the controls survive staff changes. A security model that one expert can explain is a model one expert must maintain. The break-glass path is part of the control set. Organizations that never test emergency access discover its failure during the emergency. Evidence requirements arrive from auditors, regulators, and customers on their own schedule. Export the usage records that matter before anyone asks, because the export cannot recover a period that has already aged out.

Review checklist

Are human and workload identities separated?
Can each role be linked to a responsibility and owner?
Are administrative duties separated?
Are network, authentication, and session policies tested?
Is sensitive data classified and protected at query time?
Are shares and consumers reviewed?
Can the team trace access to base objects and policies?
Do controls have tests and evidence?
Can operators recover from an incorrect security change?