Snowflake Encryption, Tri-Secret Secure and Cortex AI Access

1.How Snowflake encrypts customer data

Every Snowflake account is encrypted, with no setup needed. All customer data is encrypted by default with AES, and the keys are managed in a hierarchy whose root lives in a cloud provider's hardware security module (HSM). Encryption and key management need no configuration from the customer.

In the hierarchy, each layer of keys encrypts, or "wraps", the layer below it. There are four levels, from the top: the root key, account master keys, table master keys and file keys. Each account has its own key hierarchy, so separate account master keys keep tenants apart as well as the access control model does. Lower levels cover less data: a table master key encrypts one table, and a file key encrypts one file.

On AWS and Azure, Snowflake creates and stores the root key in the HSM. On Google Cloud, it does this through Google Cloud KMS, in multi-tenant HSM partitions.

Sources1

2.Key rotation and periodic rekeying

Keys move through three states: active, retired and destroyed. Snowflake rotates keys in its hierarchy automatically once they are more than 30 days old. The active key is retired and a new random key is created. Only the active key encrypts new data. Retired keys can only decrypt. For example, if a table master key was version 1 in April, version 1 still decrypts April's data in June, while version 3 encrypts June's inserts. Because rotation is automatic, a key older than 30 days needs no action from the administrator.

Rotation moves a key from active to retired. Rekeying moves it from retired to destroyed. With periodic rekeying enabled, once a retired key is more than a year old, Snowflake re-encrypts the data it protects with a new key and destroys the old one. On Enterprise Edition, ACCOUNTADMIN enables this with the PERIODIC_DATA_REKEYING account parameter. Rekeying runs online in the background, without downtime, and does not change Time Travel or Fail-safe retention. The one cost is storage: rekeyed files are charged for 7 days of Fail-safe.

Sources1

3.Tri-Secret Secure and customer-managed keys

Some customers want to hold a key of their own. A customer-managed key (CMK) is a master key kept in the key management service of the cloud that hosts the account. Tri-Secret Secure combines it with a Snowflake-maintained key to form a composite master key. Together with Snowflake's user authentication, that gives three levels of protection.

The composite key acts as the account master key: it wraps the keys below it, and it never encrypts raw data. That design gives the customer control, and also responsibility. If the CMK is revoked, Snowflake can no longer decrypt your data.

You can turn on automatic CMK rotation in your cloud provider without doing anything in Snowflake. Snowflake does not start using the new key version right away. It picks it up the next time it rotates the account master key, which happens every 30 days. Existing files are still decrypted with earlier CMK versions, so never delete old versions or revoke access to them. Replacing the CMK with a different key is a manual change coordinated with Snowflake Support.

Sources21

4.Registering a CMK and activating Tri-Secret Secure

Setting up Tri-Secret Secure is split between you and Support. You register your CMK yourself using system functions, and then Snowflake Support enables Tri-Secret Secure for the account you name. The steps are the same on every cloud, though the function arguments differ; on Azure, for example, SYSTEM$GET_CMK_CONFIG needs your tenant_id.

After activation, SYSTEM$GET_CMK_INFO reports progress. Its output says the key "is being activated" while rekeying is still running and "is activated" when it finishes. To change the CMK later, repeat the same registration steps with the new key. While data is re-encrypted, the function reports that the key "is being rekeyed".

Sources2

5.Enabling Cortex AI functions for users

Cortex AI access is also governed at the account level, with two separate gates. A user needs the USE AI FUNCTIONS account privilege, or a per-function USE AI FUNCTION <name> privilege, and also one of the database roles SNOWFLAKE.CORTEX_USER or SNOWFLAKE.AI_FUNCTIONS_USER.

By default every user passes both gates: USE AI FUNCTIONS and CORTEX_USER are both granted to PUBLIC. To restrict access, ACCOUNTADMIN revokes them from PUBLIC and grants them to chosen roles. AI_FUNCTIONS_USER is not granted to PUBLIC. It allows the scalar AI functions without access to Cortex services such as Cortex Agent, Cortex Analyst or Cortex Search. Neither database role can be granted directly to a user; grant it to a role the user can assume.

The blanket and per-function privileges combine with OR. A role that has USE AI FUNCTIONS can call every function, so revoking a per-function grant from it changes nothing. One exception to know: USE AI FUNCTIONS does not currently apply to AI function queries run inside Snowflake native applications.

USE ROLE ACCOUNTADMIN;

-- Remove blanket access from PUBLIC
REVOKE USE AI FUNCTIONS ON ACCOUNT FROM ROLE PUBLIC;

-- Create a role with access to only AI_COMPLETE
CREATE ROLE ai_complete_user_role;
GRANT USE AI FUNCTION AI_COMPLETE ON ACCOUNT TO ROLE ai_complete_user_role;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE ai_complete_user_role;

GRANT ROLE ai_complete_user_role TO USER example_user;

REVOKE USE AI FUNCTIONS ON ACCOUNT
FROM ROLE  ? ;

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Key rotation destroys the old key and re-encrypts existing data, so an administrator should step in when a key passes 30 days.Why is that wrong?

   Rotation is automatic and only retires the old key. Re-encrypting data and destroying a retired key is periodic rekeying, which acts on keys retired for more than a year and must be enabled on Enterprise Edition.

   Covered in Key rotation and periodic rekeying

2. 2.Under Tri-Secret Secure, the composite master key encrypts the raw data files directly.Why is that wrong?

   The composite key takes the place of the account master key and only wraps lower keys. File keys, derived from table master keys, encrypt the raw data.

   Covered in Tri-Secret Secure and customer-managed keys

3. 3.Granting USE AI FUNCTIONS to a role is enough for its users to call Cortex AI functions.Why is that wrong?

   Users also need the CORTEX_USER or AI_FUNCTIONS_USER database role, granted through a role. If CORTEX_USER has been revoked from PUBLIC, the privilege alone is not enough.

   Covered in Enabling Cortex AI functions for users

Practise it for real

Limit Cortex AI functions to one custom role instead of every user in the account

1. 1.Run USE ROLE ACCOUNTADMIN; then REVOKE USE AI FUNCTIONS ON ACCOUNT FROM ROLE PUBLIC;

   Why: Only ACCOUNTADMIN can manage this privilege, and PUBLIC holds it by default

   You should see: Users who relied on PUBLIC can no longer call most Cortex AI functions

2. 2.Run CREATE ROLE cortex_user_role; then GRANT USE AI FUNCTIONS ON ACCOUNT TO ROLE cortex_user_role;

   Why: This gives the account-level gate to a role you control

   You should see: The new role holds the USE AI FUNCTIONS privilege

3. 3.Run GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE cortex_user_role;

   Why: The privilege also needs a Cortex database role, which must be granted to a role rather than a user

   You should see: The role now passes both gates

4. 4.Run GRANT ROLE cortex_user_role TO USER example_user; then SHOW GRANTS TO ROLE cortex_user_role;

   Why: This assigns the role to the user and confirms what the role holds

   You should see: SHOW GRANTS lists USE AI FUNCTIONS for the role