Data Protection, Encryption, and Masking
Encryption layers
Snowflake encrypts data at rest with AES-256, using hierarchical key management: account master keys protect table master keys, which protect file keys. Tri-Secret Secure combines a Snowflake-managed key with a customer-managed key (in AWS KMS, Azure Key Vault, or GCP KMS) so that neither party alone can decrypt data. Data in transit uses TLS. Client-side encryption with a customer-supplied passphrase is available for staged files.
Masking and tokenization
Dynamic data masking applies a masking policy at query time based on the session role, leaving stored data unchanged. Policies attach to columns and can use conditional masking (CASE logic on role or other columns). External tokenization replaces sensitive values before load using a tokenization service. Tag-based masking associates a masking policy with a tag so any column carrying that tag is masked automatically.
Other protections
Secure views hide the view definition and underlying data from non-owners. Row access policies filter rows by role or mapping table. Projection and aggregation policies constrain SELECT lists and aggregate queries. Time Travel and fail-safe support recovery but are not a substitute for encryption.
Traps
- Believing masking alters stored data - it does not; it is evaluated at query time.
- Confusing Tri-Secret Secure with client-side encryption.
- Forgetting that a masking policy returns the column's data type and must be compatible.
- Assuming secure views protect data from the view owner - they protect from other roles.
Rule of thumb
Encrypt by default (Snowflake does), then layer access controls: masking for column-level sensitivity, row access policies for row-level, secure views for definition hiding. Use Tri-Secret Secure when regulation requires customer-controlled keys.