snowflake cloud data platform - Tri-Secret benefits

Question

I am wondering what the functional benefits are of applying Tri-Secret Managed Key security in Snowflake warehouses?

From what I understand:

• the Tri-Secret method let's you define your own key
• revoking that key will make it impossible for Snowflake to decrypt your data

But is the level of encryption in any way more secure? The only difference I see is that a Snowflake key and your own key are combined. Prohibiting access to that key will make it impossible for Snowflake to decrypt, rendering your data useless. And then what? How to recuperate from that?

Also see: https://www.snowflake.com/blog/customer-managed-keys/

This is from Snowflake themselves. What they essentially say, is:

• you have more control, but you must supply Snowflake with that key otherwise they can't do their work
• you can shut out Snowflake from accessing your data if you mistrust them
• if there is a data leak, you can prevent further leakage (but why not shutdown all access in that case, except for reverified trusted parties???)

I am stymied by this functionality. The only response I get from local Snowflake representatives is that the Dutch financial laws/regulations prescribe or at least imply the need for this.

Regards, Richard.

question from:https://stackoverflow.com/questions/65889825/tri-secret-benefits

Answer 1

Let me start by making the most important statement here: Don't use customer managed keys, unless you really need to use them.

Think of the worst case scenario: If you don't have an incredible resilient platform to securely store your own keys, then you risk losing all your data if you ever lose your keys.

Let me quote now some 3rd parties on when customer managed keys should be used:

Google says:

Customer-managed encryption keys are intended for organizations that have sensitive or regulated data that requires them to manage their own encryption key.

Meaning: Customer managed keys are intended for organizations that are required to use them. Don't follow this path, unless you are required too.

Or why would some companies start using their own keys, or stop using them — from CIO.com:

If you’re considering whether bringing your own keys – which also means securing your own keys – is right for your business, the first question to ask is are you ready to become a bank, because you’ll have to run your key infrastructure with the same rigor, down to considering the travel plans of officers of the company. If you have three people authorized to use the smart card that gives access to your key, you don’t ever want to let all three of them on the same plane.

Same article about Microsoft customers on the automotive industry:

“They all start by saying ‘I want to be in control,’ but as they see the responsibility and they understand to what extreme lengths Microsoft taking this responsibility, they say ‘why don’t you just do it.’ They don't want to be the weaker link in a chain.”

And NY financial institutions:

Even some New York financial institutions, who initially wanted BYOK that ran against their own on-premises HSMs decided against that when they considered what could go wrong, says Paul Rich from Microsoft’s Office 365 team. “An HSM could have been powered down, taking out a vast swathe of user base. They quickly got the idea that this is potentially a great denial of service attack that malicious insider or attacker performs on the company. These are our most sophisticated customers who are highly sensitive that this is a big responsibility but also a threat of potential destruction, whether that’s accidental or malicious.”

So you should only use customer managed keys if you already understand why they would be beneficial for your use case - and only if you are ready to incur the cost of securely managing them. Otherwise, just let Snowflake handle all these complexities for you.

On the other hand, benefits of using tri-secrets from the Snowflake announcement post:

Customer-managed keys provide an extra level of security for customers with sensitive data. With this feature, the customer manages the encryption key themselves and makes it accessible to Snowflake. If the customer decides to disable access, data can no longer be decrypted. In addition, all running queries are aborted. This has the following benefits for customers: (a) it makes it technically impossible for Snowflake to comply with requests for access to customer data, (b) the customer can actively mitigate data breaches and limit data exfiltration, and (c) it gives the customer full control over data lifecycle.

On the same blog post you'll notice that Snowflake tri-secret customer keys are managed by AWS's KMS. This gives you the above benefits, without having to deploy your own infrastructure to manage your keys. You still need to carefully consider your responsibility for safeguarding your key.

AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys. AWS KMS is integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs.

The blog post hasn't been updated to reflect that also GCP and Azure can be used to manage the keys, as stated in the docs:

Tri-Secret Secure lets you control access to your data using a master encryption key that you maintain in the key management service for the cloud provider that hosts your Snowflake account: AWS: AWS Key Management Service (KMS); Google Cloud: Cloud Key Management Service (Cloud KMS); Microsoft Azure: Azure Key Vault.

Synonyms for future research you might want to perform: BYOK, CMEK.