Detections
Analytics

1.17 Ensure Snowflake stored procedures do not run with ACCOUNTADMIN or SECURITYADMIN role privileges

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

The ACCOUNTADMIN system role is the most powerful role in a Snowflake account; it is intended for performing initial setup and managing account-level objects. Users and stored procedures with the SECURITYADMIN role can escalate their privileges to ACCOUNTADMIN

Snowflake stored procedures should not run with the ACCOUNTADMIN or SECURITYADMIN roles. Instead, stored procedures should be run using a custom role containing only those privileges that are necessary for successful execution of the stored procedure.

The principle of least privilege requires that every identity, including service identities, is only given privileges that are necessary to complete its job.

If a threat actor finds a way to influence or hijack the stored procedure execution flow, they may be able to exploit privileges given to the stored procedure. In the case of an ACCOUNTADMIN or SECURITYADMIN roles, that may lead to a full account takeover. Additionally, a mistake in the stored procedure implementation coupled with excessive privileges may lead to a reliability incident, e.g. accidentally dropping database objects.

Solution

Programmatically:

In a Snowsight worksheet or using the SnowSQL CLI:

 -

For each stored procedure <procedure_name> that runs with ACCOUNTADMIN or SECURITYADMIN privileges, create a new role <procedure_specific_role> and assign it to the stored procedure:

CREATE ROLE <procedure_specific_role>;GRANT OWNERSHIP ON PROCEDURE <procedure_name> TO ROLE <procedure_specific_role>;
 -

After creating a new role and granting privileges to each stored procedure, ensure all privileges on the stored procedure <procedure_name> are revoked from the ACCOUNTADMIN and SECURITYADMIN roles:

REVOKE ALL PRIVILEGES ON PROCEDURE <procedure_name> FROM ROLE ACCOUNTADMIN;REVOKE ALL PRIVILEGES ON PROCEDURE <procedure_name> FROM ROLE SECURITYADMIN;

Impact:

Existing stored procedures that are owned by the ACCOUNTADMIN or SECURITYADMIN roles and run with their privileges will need to be updated to use a stored procedure specific custom role. If that role does not have all the privileges required by the stored procedure, the stored procedure execution may fail.

See Also

https://workbench.cisecurity.org/benchmarks/14781

Item Details

References: CSCv7|4.3

Plugin: Snowflake

Control ID: 253f3c0a0ec3461567b98a63ec53e4f98c8d7685f3588bee198b401b91aaac5e