In the wake of the 2024 data breaches related to the Snowflake platform (TicketMaster) (Santander) (165 Affected Customers), I thought it would make sense to talk a little bit about Snowflake Security best practices. Snowflake recommends all of these approaches (among others), but these are critical to protecting your account (and your data).

Network Policies

Network rules and policies establish a virtual perimeter around your Snowflake data. This limits access to Snowflake from approved networks by IP ranges or network IDs (if using PrivateLink). I think this is one of the best ways to prevent unauthorized access to your Snowflake resources. See the Snowflake Documentation on Network Policies.

Single-Sign-On & MFA

Snowflake strongly encouraged all customers to enable federated authentication/single-sign-on with MFA in their Snowflake accounts in the wake of the data breaches. This makes sense, because Mandiant identified that many of the stolen credentials were contractor accounts which should have been deactivated.

Configuring federated authentication on Snowflake can be complicated, but if you have a large userbase, it is very helpful to also look at the SAML provisioning to create the users. See the Snowflake Federated Authentication Overview. Keep in mind that there's no automation solution out of the box for deactivating users in Snowflake.

My major criticism with Snowflake's recommendation is that most service accounts used by automation cannot use MFA. Securing the user accounts of your employee and contractors does a lot to reduce your attack surface area, but there have been plenty of breaches historically from service account secrets getting committed to GitHub. SSO and MFA are not panaceas to prevent password compromise.

Password Policies

If you don't choose SSO, you should strongly consider some kind of password policy. I'm not a fan of 90-day rotation policies: most users will just start dropping dates in them or writing them down. However, six-month or twelve-month rotation policies might make sense depending on your user turnover. You are trying to balance the likelihood that one of your users has compromised their password (or has left) and those credentials are still valid.

The default Snowflake password policy requires 8 characters, 1 capital letter and 1 number. It doesn't require special characters and it doesn't have a minimum age. It defaults to a minimum age of 0 and a maximum age of 90 days. Different values might make sense for you, so you should read the Snowflake password policy docs.

Password Rotation

These security breaches all used old compromised user credentials. If you are routinely rotating user and service account passwords then lost credentials can't be exploited by adversaries.

In my opinion, service accounts are a bigger problem, on an individual basis, because they tend to have a lot of access (to manage infrastructure, perform ETL, etc.) and may need to be accessible to a large number of people to facilitate support. That means there are a lot of people who could potentially leak these credentials which have a larger-than-usual blast radius.

You can force rotation of user passwords with a password policy, but for service accounts, you need to have a plan for rotation. Rotating service account credentials can be trivial if you are using a secrets vault like AWS Secrets Manager to store the secrets, because many of these services have hooks built in for password rotation.