3.3 Encryption, Key Management & Tri-Secret Secure
Key Takeaways
- Snowflake encrypts all data at rest with AES-256 using a hierarchical key model rooted in a cloud-provider HSM: root key, account master keys, table master keys, and file keys.
- Tri-Secret Secure (Business Critical Edition or higher) combines a Snowflake-maintained key with a customer-managed key in the cloud provider's key management service to create a composite master key.
- If Snowflake loses access to the customer-managed key, it can no longer decrypt the account's data, which gives the customer a cryptographic way to cut off access.
- Snowflake-managed keys are rotated automatically when they are more than 30 days old (retired keys only decrypt); periodic rekeying (Enterprise Edition, PERIODIC_DATA_REKEYING = TRUE) re-encrypts data whose retired keys are older than one year.
- Periodic rekeying is opt-in and not free: after rekeying, data encrypted with the old key is kept in Fail-safe for the standard period, which adds storage charges.
3.3 Encryption, Key Management & Tri-Secret Secure
Security in the Snowflake architecture operates as a defense-in-depth model spanning cryptographic storage protection, customer-controlled key governance, and network controls. For the SnowPro Advanced: Architect, mastering how Snowflake's hierarchical encryption model works and how it integrates with external cloud Key Management Services (KMS) is critical for designing compliant architectures. Network policies, network rules, and private connectivity are covered in Section 3.5.
Hierarchical Key Management in Snowflake
All customer data stored in Snowflake is encrypted by default at rest using AES-256 GCM (Galois/Counter Mode). Snowflake implements a hierarchical key model built upon the concept of envelope encryption, where higher-level keys encrypt lower-level keys.
┌──────────────────────────────────────────────┐
│ Tier 1: Snowflake Root Key │
│ (Hardware Security Module / Cloud Cloud-HSM) │
└──────────────────────┬───────────────────────┘
│ Encrypts
▼
┌──────────────────────────────────────────────┐
│ Tier 2: Account Master Key (AMK) │
│ (Unique per Snowflake Customer Account) │
└──────────────────────┬───────────────────────┘
│ Encrypts
▼
┌──────────────────────────────────────────────┐
│ Tier 3: Table Master Key (TMK) │
│ (Unique per Table / Data Object) │
└──────────────────────┬───────────────────────┘
│ Encrypts
▼
┌──────────────────────────────────────────────┐
│ Tier 4: File Keys │
│ (Unique per Micro-Partition File) │
└──────────────────────────────────────────────┘
The Four-Tier Encryption Hierarchy
- Root Key (Tier 1): Stored in a cloud-managed Hardware Security Module (HSM). It wraps and protects the Account Master Keys.
- Account Master Key / AMK (Tier 2): Unique to each Snowflake account. Protects all Table Master Keys within that specific customer account.
- Table Master Key / TMK (Tier 3): Unique to each table or database object. Protects the File Keys for all micro-partitions belonging to that table.
- File Key (Tier 4): Unique to each individual micro-partition file written to cloud storage (Amazon S3, Azure Blob, or Google Cloud Storage). Every single micro-partition file receives its own distinct cryptographic key.
Encryption in Transit
All network communication with Snowflake is encrypted in transit using TLS 1.2 or higher with modern, forward-secret cipher suites. This applies to:
- Client-to-Snowflake connections (SnowSQL, Snowsight, JDBC/ODBC, Python Connector, REST SQL API).
- Internal communication between Virtual Warehouse compute nodes.
- Data movement between virtual warehouse compute nodes and underlying cloud object storage.
Tri-Secret Secure (Customer-Managed Keys)
In standard Snowflake accounts, all keys in the hierarchy are fully managed by Snowflake. For highly regulated industries (banking, healthcare, defense), Snowflake offers Tri-Secret Secure, which introduces a composite key model for the Account Master Key (AMK).
Composite Key Architecture
The name reflects three secrets that together protect access to data:
- Snowflake-maintained key: managed inside Snowflake's key hierarchy.
- Customer-managed key (CMK): held in the customer's key management service in the same cloud platform that hosts the account:
- AWS KMS
- Azure Key Vault
- Google Cloud KMS
- User credentials: Snowflake authentication still controls who can query the data.
Snowflake combines the Snowflake-managed key and the customer-managed key using cryptographic key derivation to produce the composite Account Master Key (AMK).
Customer Cloud KMS Key Snowflake-Managed Key
(AWS KMS / Azure KV / GCP KMS) (Snowflake Security Enclave)
│ │
└────────────────────┬────────────────────┘
│
▼
Composite Account Master Key (AMK)
│
▼
Table Master Keys (TMK)
│
▼
Micro-Partition File Keys
The Cryptographic Kill Switch
Because the customer-managed key lives in the customer's own key management service:
- Key Revocation: If the customer disables the key or revokes Snowflake's permission to use it, Snowflake can no longer derive the composite master key, so the account's data can no longer be decrypted — including by Snowflake personnel.
- Operations that need the data fail while the key is unavailable.
- When access to the key is restored, operations can resume; the data itself was never deleted.
- Architect caution: losing the customer-managed key permanently means losing access to the data, so key lifecycle and backup procedures in the cloud KMS become part of your recovery design.
Edition Prerequisite
Exam Fact: Tri-Secret Secure is strictly available only on Business Critical Edition or higher (including Virtual Private Snowflake). It is not available on Standard or Enterprise Editions.
Key Rotation vs Automated Annual Data Rekeying
A critical distinction on the ARA-C01 exam is the difference between rotating keys and rekeying data:
| Process | Frequency | Mechanics | Performance & Storage Impact |
|---|---|---|---|
| Key Rotation | Automatic, when a Snowflake-managed key is more than 30 days old | The active key is retired and a new key is created. New data is encrypted with the new key; the retired key is used only to decrypt data it protected. | No data rewrite. Applies in every edition. |
| Periodic Rekeying | Opt-in; data whose retired key is older than one year | Snowflake creates a new key and re-encrypts the data protected by the old retired key, then destroys the old key. | Enterprise Edition or higher. Enabled by ACCOUNTADMIN with ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = TRUE; (default FALSE). Old-key data is kept in Fail-safe, which adds storage charges. |
-- Enable periodic rekeying for the account (Enterprise Edition or higher)
USE ROLE ACCOUNTADMIN;
ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = TRUE;
Client-Side Encryption for Internal Stages
Files uploaded with PUT to internal stages are encrypted on the client before they leave the machine (Snowflake-managed client-side encryption), and remain encrypted at rest. External stages can use the cloud provider's server-side encryption (for example AWS_SSE_KMS) or client-side encryption with a master key you supply in the stage definition.
Next: Network policies, network rules, external network access, and private connectivity are covered in Section 3.5.
A financial institution wants a cryptographic control that lets it cut off Snowflake's ability to decrypt its data during a security incident, independent of Snowflake user permissions. Which edition and feature provide this?
A regulated company wants every Snowflake-encrypted table file to be re-encrypted with a fresh key once its retired key is more than a year old. Which configuration meets this requirement?
Which description of Snowflake's hierarchical key model is accurate?