Snowflake threat scenarios: privileged roles, service credentials, third-party connections

1.Over-privileged roles and users

The most common Snowflake threat scenario is too much privilege. ACCOUNTADMIN sits at the top of the system role hierarchy. It is not a superuser, though: it can only view and manage objects when it, or a role below it in the hierarchy, holds privileges on them. Snowflake's recommendations are clear. Give ACCOUNTADMIN to only a few people, and to at least two so they can reset each other's passwords. Require MFA for all of them. Don't make it anyone's default role. Use a different role for automated scripts.

Grant sprawl is a quieter version of the same problem. Outside managed access schemas, an object owner can grant access to any role, including PUBLIC. That is true under RBAC and under user-based access control (UBAC). Managed access schemas take that ability away from object owners: only the schema owner or a role with MANAGE GRANTS can grant privileges there. For review, the GRANTS_TO_ROLES view in ACCOUNT_USAGE lists grants to roles, users, and applications. Direct grants to users skip the role hierarchy, so this query is a useful check:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
  WHERE granted_to = 'USER';

The Trust Center automates much of this review. It covers finding over-privileged roles and limiting the number of ACCOUNTADMIN and SECURITYADMIN users. It flags tasks that run with those roles' privileges. Its Users with administrator privileges scanner reports new users whose default role is an administrator role, and recent administrator grants to existing users.

Sources12

2.Compromised service account credentials

Service users authenticate without a person present, so a stolen credential can be used silently. Snowflake asks for TYPE = SERVICE on users created for service-to-service applications. Users marked TYPE=LEGACY_SERVICE need to move to stronger authentication. The baseline rule is that every service user must use an authentication method stronger than a password. The authentication methods differ in what an attacker would steal:

The Threat Intelligence scanner package looks for signs of credential compromise. It classifies users as human or service and checks for password sign-in without MFA, inactivity, and abnormal failure rates. It runs once a day by default. The Trust Center's Strong Authentication Hub tracks which service users still need to migrate.

Sources34

3.Third-party connections and packages

Third-party tools usually connect through an integration, a Snowflake object that sits between Snowflake and the outside service. For a custom OAuth client, you create the integration with CREATE SECURITY INTEGRATION and OAUTH_CLIENT = CUSTOM. The main threat-reduction setting is BLOCKED_ROLES_LIST. It lists roles that a user cannot consent to use with that integration, so the vendor application cannot get tokens for those roles.

Client software is a risk too. The Trust Center can raise a detection when drivers or other client versions in use have known vulnerabilities or are end-of-life. Its Users with unusual applications used in sessions scanner flags clients that are new for a given user. For code that runs inside Snowflake and calls out, the external access integration from the egress model limits which hosts the code can reach, whoever wrote it. The provided sources do not describe scanning third-party code packages (such as Python libraries) for vulnerabilities. Treat that as a gap to cover with your own process.

Sources52

4.Implementing and verifying mitigations

Each threat above has a matching control. Use network policies and the precedence rules for entry points. Use egress rules in external access integrations for exit points. Use role hierarchies under SYSADMIN, managed access schemas, and MFA on ACCOUNTADMIN for privilege. Use SERVICE users with secretless authentication or role-scoped tokens for service credentials. Use BLOCKED_ROLES_LIST for OAuth clients. Programmatic access tokens are a good example of controls working together. The AI Security package flags PATs used with Cortex Code CLI that have no role restriction (ALLOWED_ROLES) or no compliant network policy. If either control is missing, a stolen token could give broad access.

The Trust Center connects identifying a threat to confirming that its mitigation worked, and access to it should follow least privilege as well. An ACCOUNTADMIN grants one of two application roles:

USE ROLE ACCOUNTADMIN;

CREATE ROLE trust_center_admin_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_ADMIN TO ROLE trust_center_admin_role;

CREATE ROLE trust_center_viewer_role;
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_VIEWER TO ROLE trust_center_viewer_role;

Violations and detections are mitigated differently. To fix a violation, change the configuration, following the Trust Center's remediation guidance. The finding stays visible until the scanner package runs again, either on schedule or on demand. You can also mark a violation Resolved and record a justification for audit. A detection is a past event and cannot be fixed directly. Investigate it, and if it matters, change controls to prevent similar events.

Sources2

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.ACCOUNTADMIN is a superuser that can see and manage every object in the account.Why is that wrong?

   ACCOUNTADMIN can only view and manage objects when it, or a role below it in its hierarchy, has privileges on them.

   Covered in Over-privileged roles and users

2. 2.A Trust Center detection, such as a login from an unrecognized IP, can be remediated and resolved like a violation.Why is that wrong?

   A detection is a one-time past event. You investigate it and prevent recurrence, and its lifecycle cannot currently be managed.

   Covered in Implementing and verifying mitigations

Practise it for real

Set up least-privilege Trust Center access and check the account for direct user grants

1. 1.As ACCOUNTADMIN, create trust_center_admin_role and grant it the SNOWFLAKE.TRUST_CENTER_ADMIN application role

   Why: Only an admin-level application role can manage scanners and the lifecycle of violations

   You should see: Both statements succeed and the role exists

2. 2.Create trust_center_viewer_role and grant it SNOWFLAKE.TRUST_CENTER_VIEWER, then grant it to an analyst user

   Why: Analysts can review findings without being able to change scanners

   You should see: The analyst can open the Violations and Detections tabs but cannot manage scanners

3. 3.Run SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES WHERE granted_to = 'USER';

   Why: Direct grants to users bypass the role hierarchy and are a common source of over-privilege

   You should see: A list of privileges granted directly to users, to review for over-privilege