Snowflake Service Account Security, Part 2

In Part 1, we covered the high-level objectives and methods for attacking service accounts. In Part 2 we discuss defense-in-depth mitigations to those methods.

By the end of this blog, you will be able to apply secure-by-default mitigations to threats impacting Snowflake service accounts.

The following table from Part 1 highlights the objectives and methods we want to mitigate:

These secure-by-default mitigations help prevent and constrain credential misuse from theft and guessing attacks:

• Least privilege
• Short-lived strong credential
• Prevention of credential transmission
• Prevention of human access

• Theft
• Misuse 

Modern cybersecurity strategy assumes adversaries are intelligent and breaches are possible. Our priorities are to:

• Make the architecture secure-by-default by reducing the number of possible scenarios
• Apply appropriate defense-in-depth mechanisms to remaining possible scenarios

This means accounts have only the minimum permissions necessary to complete the current operation. (Operations are interactions with the Snowflake database caused by things like API calls, batch processing, and data loading).

Carefully ensure every operation is well-defined and has the minimum necessary permissions. This ensures that when a credential is stolen, the damage is intentionally limited.

Use these best practices to design Snowflake service accounts:

• Separate read and write permissions by creating read-only, and write-only roles.
• Scope data access on read-only and write-only roles to what is needed for a single operation.
• Create separate roles for handling sensitive data.
• Apply network policies that whitelist specific IP addresses to restrict which network locations service accounts can be used from.

Applying these best practices gives us the following guarantees:

• Write-only credentials cannot be used to read out-of-scope data by attackers
• Read-only credentials cannot be used to write out-of-scope by attackers
• Read-only credentials scoped to specific fields cannot be used to read out-of-scope fields by attackers
• Write-only credentials scoped to specific fields cannot be used to modify out-of-scope fields by attackers
• Stolen credentials cannot be used outside of the network perimeter

• Theft
• Guessing

Least privilege restricts the space in which a stolen credential can be used. Now we focus on restricting the time a credential is useful.

The less time a credential is useful, the less value it can provide an attacker. A credential is considered useful whenever it actively contains permissions that allow data access. It is not considered useful when it can only be used to request new, useful credentials. Being forced to acquire the credential repeatedly may also increase the cost of carrying out an attack.

Use these best practices to ensure short-lived credentials are used by Snowflake service accounts:

• Store credentials in a purpose-built secret storage platform such as HashiCorp Vault, KMS, or SSM.
• Ensure password-based authentication schemes leverage strong randomly generated values.
• Prefer single-use credentials. The useful credential lifetime should not exceed the operation lifetime.

Applying these best practices guarantees that stolen credentials can be used for a limited duration, known in advance by defenders.

Snowflake has written a sample plugin for Hashicorp Vault, a secrets management platform, so you can see how these time-bound credentials work with Snowflake specifically. We will explore the use of this more deeply in Part 3 of this blog post series. 

• Theft
• Disclosure

Credentials that are never transmitted over the wire cannot be intercepted by attackers. They are also unlikely to appear in log files. 

Public key authentication schemes such as RSA key pairs never transmit the private key material on the wire. Instead, only a signature is transmitted. Since the private key is not transmitted it will not show up in debug or trace logs that include raw HTTP traffic.

Use these best practices when deploying key pair authentication for Snowflake service accounts:

• Store private keys and key passphrases in a purpose-built secret storage platform such as HashiCorp Vault, KMS, or SSM.
• Encrypt the private key with a passphrase.
• Use automation to limit the validity of public and private keys to hours or minutes, and rotate them without human interaction.

Applying these best practices guarantees that the credential cannot be intercepted over the network.

• Disclosure
• Theft

Testing with a machine service account is convenient, but it creates auditability and security issues. In addition, it is not possible to identify every place a shared credential may exist, or even who is currently using it.

Therefore, make it impossible for insiders to disclose or steal credentials by making it impossible for them to directly access credentials.

Use these best practices when deploying key pair authentication for Snowflake service accounts:

• Eliminate humans from the service account credential management lifecycle with automation
• Restrict human operators to write-only access to service account credentials in purpose-built secret storage platforms

Applying these best practices guarantees that human operators can never see service account credentials.

Snowflake supports the following high-level approaches for service account authentication:

• OAuth
• Key Pair
• Password

Additionally, Snowflake provides network policies to control where accounts can log in from.

The following two tables cover mitigations each approach provides, to what relative degree, and pros and cons for each:

Service accounts will be with us for a long time. As long as you fully understand the risks, you can deal with them securely. Snowflake has given you a full set of features that can help you mitigate risks when you take full advantage of these capabilities. As always, you can contact your Snowflake team to learn more about these features and get help. 

References: 

1: https://developer.mastercard.com/blog/why-mastercard-doesnt-use-oauth-20/

2: https://tools.ietf.org/html/rfc6819#section-4.1

3: https://tools.ietf.org/html/rfc6819#section-4.1.3

4: https://docs.snowflake.com/en/user-guide/odbc-parameters.html#required-connection-parameters

5: https://stackoverflow.com/questions/15093440/change-keystore-password-from-no-password-to-a-non-blank-password

6: https://docs.snowflake.com/en/user-guide/network-policies.html#managing-user-level-network-policies