Unknown's avatar Pete 9:02 pm on April 19, 2025  

Hardening Snowflake Access

While Snowflake provides strong default security capabilities, enterprises must take additional steps to lock down the identity and access layer to prevent unauthorized data access. In this article, we focus on front-end hardening, including authentication mechanisms, federated identity controls, network access constraints, and token lifecycle management. The goal is to ensure that only the right identities, coming from the right paths, under the right conditions, ever reach Snowflake.

Snowflake supports SAML 2.0 and OAuth 2.0-based SSO. You should disable native Snowflake usernames/passwords entirely for production accounts.

SAML (Okta, Azure AD, Ping)

  • Create an enterprise application in your IdP.
  • Configure SAML assertions to pass custom attributes like role, email, department.
  • Use SCIM provisioning to sync Snowflake users/roles/groups from the IdP.
  • Set the session timeout in your IdP lower than Snowflake’s to avoid dangling sessions.

Avoid provisioning ACCOUNTADMIN via SAML. Manage this break-glass account separately.

Use EXTERNAL_OAUTH instead of SAML for modern applications or service integrations.

Lock Down OAuth Access

Snowflake supports OAuth for both interactive and non-interactive use. You must restrict token scope, audience, and expiration windows to reduce risk.

Key Hardening Strategies:

  • Use short-lived tokens (preferably < 15 minutes) for all automation.
  • Configure audience (aud) and scopes strictly. Avoid issuing tokens with SESSION:ALL unless required.
  • Rotate client secrets for OAuth apps regularly.
  • For client credentials flow, ensure the client cannot impersonate high-privileged roles.
  • Deny ACCOUNTADMIN access through any OAuth app.

Supported Scopes Examples:

ScopeDescription
session:role:<role_name>Restrict token to one role only
session:warehouse:<wh>Bind session to specific warehouse

Snowflake OAuth Token Validation (under the hood)

sqlCopyEditSELECT SYSTEM$EXTRACT_OAUTH_TOKEN_CLAIM('aud', '<access_token>');

Restrict Native Auth with Network Policies

Even if federated auth is enforced, native logins can still exist and be exploited. Use Snowflake Network Policies to harden this path.

Strategy:

  • Create two network policies:
    • admin_policy: Only allows break-glass IP ranges
    • default_policy: Allows enterprise proxy or VPN egress IPs only
  • Apply the default to the account:
sqlCopyEditALTER ACCOUNT SET NETWORK_POLICY = default_policy;
  • Apply admin_policy only to named break-glass users.

Consider a Cloudflare or Zscaler front-door to enforce geo/IP conditions dynamically.

Implement Role Hierarchy Discipline

Identity hardening isn’t complete without strict RBAC practices. Prevent role escalation and sprawl.

Best Practices:

  • Disallow use of SET ROLE = ANY unless strictly required.
  • Disable PUBLIC role from having any privileges:
sqlCopyEditREVOKE ALL PRIVILEGES ON DATABASE <db> FROM ROLE PUBLIC;
  • Ensure OAuth apps assume dedicated roles, not shared ones.
  • Create role chains with the principle of least privilege — don’t nest high-priv roles into commonly used ones.

Enable MFA Everywhere You Can

Snowflake itself doesn’t natively enforce MFA — this must be handled at the IdP or via authentication proxy.

Solutions:

  • Require MFA on all interactive IdP logins (Okta, Azure, Ping).
  • Use conditional access policies to block access if MFA isn’t passed.
  • For break-glass accounts: Use hardware token MFA or a privileged access broker like CyberArk.

Monitor and Rotate OAuth Secrets & Certificates

Snowflake OAuth integrations (especially EXTERNAL_OAUTH) rely on JWT signing keys.

Operational Controls:

  • Rotate JWT signing certs every 90 days.
  • Monitor for expired or invalid tokens using:
sqlCopyEditSHOW INTEGRATIONS;
  • Alert on integration usage via LOGIN_HISTORY or EVENT_HISTORY.

Harden Service Account Behavior

Service identities are often the weakest link. Use automation to provision/deprovision service roles and tokenize all secrets via a secrets manager like Vault.

Key Points:

  • Never let a service identity own SECURITYADMIN or ACCOUNTADMIN.
  • Tag tokens via session:user_agent, session:client_ip and audit the usage patterns.
  • For zero trust, bind each service to its own network segment and OAuth flow.

Monitor Everything at the Edge

Don’t trust Snowflake alone for auditing — bring data into your SIEM.

Ingest from:

  • LOGIN_HISTORY
  • QUERY_HISTORY
  • ACCESS_HISTORY
  • EVENT_HISTORY

Pipe into Splunk, Snowflake, or S3 via Snowpipe and monitor:

  • Role switching anomalies
  • Login attempts outside normal hours
  • OAuth token usage per integration