7 Quick Ways to Improve your Snowflake Security

Update - January 12th 2021: Following Snowflake’s preview addition of self-service account creation using the ORGADMIN role, which converts this action to a quick-win, I've added a new Snowflake security quick-win, Separate production from staging.   I may be biased, but running an enterprises’ Snowflake cloud data warehouse is a dream job. It’s a position that comes with an extraordinary amount of power—but we know what they say, with great power comes a great need to ensure that you’re keeping your company’s most sensitive assets secure! Snowflake warehouse security differs from one organization to the next, and knowing how to approach it in your organization will involve tons of risk assessments and cross-departmental diplomacy. We’ve already made a not-too-shabby and rather comprehensive snowflake security guide. In this post, we thought we’d offer some quick-win security tips to help you start keeping your organization safe while you integrate the bigger steps!

1. Limit usage of strong roles

Strong roles, especially ACCOUNTADMIN, are used in many Snowflake data warehouses. According to the principle of least privileged data access, this poses a risk and should be avoided whenever possible. We’re better off treating ACCOUNTADMIN like a root account and avoiding its direct use, such as reading data from tables, with the exception of specific administrative tasks (and even those should mostly be done by the other administrative roles). Moreover, avoid configuring it to be the default role for users, even if they have access to this role.

What you can do right now:

• Check administrative role activity in the query_history view:

  SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
  WHERE role_name = 'ACCOUNTADMIN';
  

• You can fine tune the query to your needs and apply to other administrative roles like SYSADMIN and SECURITYADMIN.
• Make sure that your administrators aren’t using administrative roles for non-administrative tasks by providing them with more granular roles for data retrieval use cases.

2. Limit allocation of strong roles

Not only should you limit the usage of strong roles, you should also limit the amount of people granted these roles to the absolute minimum required. It’s simply too much power to put into too many hands. ACCOUNTADMIN should ideally be allocated to a maximum of two users. Remember, giving someone the keys to the kingdom is an important matter—they shouldn’t be automatically handed to “VIPs” by virtue of their executive status. If they give you trouble, send them a link to this blogpost.  

What you can do right now:

• Check who currently has access to administrative roles. Start with ACCOUNTADMIN to prioritize for risk reduction. You can and should also check if they’re actually using those roles.
• You can use the following query or customize it to your needs:

  SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_USERS
  WHERE DELETED_ON IS NULL
  AND ROLE='ACCOUNTADMIN';
  

• Inform users with unnecessary administrative roles that you’re revoking their access and proceed.

3. Enable MFA for your users, especially administrators

Enabling Multi-Factor Authentication for your organization may not be a quick win, but since we have now reduced the amount of users granted administrative roles, adding MFA for those users is a smaller task. At the very least, it will help deal with your riskiest set of users.  

What you can do right now:

• Before requiring MFA of everyone on your account, consider starting with yourself and other admins.

4. Keep failed logins in mind

Don’t forget that failed logins to your system may have important implications (is an ex-employee attempting to login? Is a script trying to execute and isn’t working properly due to changed credentials?). Checking for failed logins should be integrated in other reporting, dashboarding and monitoring, but for a quick look at “what’s going on”, you can start with a query to see the top failed logins.  

What you can do right now:

• Investigate login failures
• Set up login failures to show in a dashboard

5. Revoke access to inactive users

Inactive users are a problem any way you look at them. They have the capability to access data, and perhaps even modify or delete it. They don’t provide any value since they aren’t interacting with the system anyway. Moreover, it’s important to remember that some users may be cancelled application users, ex-employees and other hazards.  

What you can do right now:

• Check which users are inactive, and follow your organization’s process to remove them (i.e. notify them or their managers and remove them).

6. Cancel unused roles

What’s true to unused users is also true to unused roles. Redundant roles can be a messy accident waiting to happen. My advice is to look for such roles and remove them from the system. If no one is using them, they’re just more potential for trouble.  

What you can do right now:

• Go over the unused roles and remove those that are unused.

7. Limit network access to your cloud data warehouse

You can set network policies in Snowflake to be in effect for your entire account or use them per user. Limiting network access will make it harder to abuse Snowflake accounts and reduce risks. If we’re looking for quick wins, I would start with creating network policies for the users with administrative access, as they pose the most risk.  

What you can do right now:

• Start setting network policies, starting with “power users”.
• Detailed instructions about setting network policies are available in our complete snowflake security guide.

8. Separate production from staging

Some organizations are running data experiments and staging from the same databases which are used by their production systems. This can cause a lot of bad outcomes like sensitive information being exposed to developers for no good reason, or even impact on production when someone makes a mistake. It is advised to separate the environments, and to create separate accounts for staging, as well as if applicable development or testing environments. If you are using the self-service accounts creation (using the ORGADMIN role), this can be as simple as a CREATE ACCOUNT statement.

 

Now what?

I hope you find this useful to kickstart your Snowflake security. If you have other quick steps in mind to improve Snowflake account security, I’d love to hear from you!   The next step for a secure Snowflake Data Warehouse is to set up Satori on top of it. Satori provides another layer of protection on your data warehouses that enables you to:

• Analyze your account’s privileges and reduce risks
• Set smart and dynamic access controls and manage access controls with ease, decoupled from your data infrastructure
• Manage workflows and self-service to data
• Get security value out of the box

If you’d like to learn more, please contact us or schedule a demo.