This series is intended to be a personal study guide. Information may not be comprehensive or accurate. I am sharing it in case others find it useful. Please feel free to comment if any information is inaccurate.
1.4 Explain the security capabilities associated with each Snowflake edition
(Higher editions inherit all features of lower editions)
-
All Editions
- Site access controlled through network policies
- SCIM to manage user identities and groups
- Key Pair Authentication and Rotation
- Multi-factor authentication
- OAuth for authorized account access without sharing or storing credentials
- Support for user SSO through federated authentication
- Controlled access to all objects in account through hybrid DAC/RBAC model
- Encryption on all ingested data stored in Snowflake tables
- Automatic encryption on all files stored in internal staging
- Soc 1 Type II and Soc 2 Type II compliance
- Standard Time Travel (up to 1 day)
- Disaster recovery for up to 7 days past time travel
-
Enterprise edition
- Configure idle session timeout
- Periodic re-keying of encrypted data
- Extended time travel (up to 90 days)
- Column level security to apply masking policies
- Row access policies to determine which rows are visible in a result
- Object tagging to facilitate tracking sensitive data
- Support for data classification
- ACCESS_HISTORY view for auditing user access
-
Business critical edition
- Private communication between VPC/VNet and Snowflake service
- Private communication to Snowflake internal stages
- Support for encryption with customer-managed keys
- Support for HIPPA compliance
- PCI DSS compliance
- HITRUST CSF compliance
- FedRAMP Moderate compliance
- IRAP Protected compliance
-
Virtual Private Snowflake
- Dedicated metadata store
- Isolated Snowflake environment that doesn't share resources with other accounts
- Overview
- Column-level security feature
- Uses masking policies to selectively mask plain-text data at query time
- Masking policies are schema-level objects
- Snowflake query operators may see the plain-text value, a partially masked value, or a fully masked value
- Benefits
- Ease of use
- Data administration and SoD
- Data authorization and governance
- Data sharing
- Change management
- Limitations
- Tables/views with masking policies can't be shared, and shared tables/views can't have masking policies applied to them
- Masking policies can't be set on tables/views from which materialized views have already been created
- Materialized views only contain columns not protected by a masking policy
- Dropping a table or schema requires the masking policy and its mappings to be self-contained within the database or schema
- Masking policies can't be applied to virtual columns
- An external table can't be referenced as a lookup table to determine if column values should be masked
- A masking policy definition must have the same data type for input and returned data
- Future grants of masking policies are not supported
- Considerations
- Exercise caution when applying masking policies
- Verify queries using columns that have masking policies before making the tables/views available to users
- Determine additional tables/views where the source data may appear, as users may see partially masked or unmasked data
Top comments (0)