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.2 Outline security principles
-
Multi-factor Authentication (MFA)
- Integrated Snowflake feature
- Powered by Duo Security, managed by Snowflake
- Enrollment is not automatic, users must enroll themselves
- Can be disabled through the ALTER_USER command with MINS_TO_BYPASS_MFA or DISABLE_MFA
- MFA tokens can be cached to reduce the number of prompts when connecting
-
Data Encryption
- End-to-end encryption
- Secures data at rest or in transit to and from Snowflake
- Consists of a customer network, a staging area, and a secure VPC or Vnet
- Staging areas can be internal (Snowflake provided) or external (customer provided)
- Internal staging is automatically encrypted
- All data at rest in Snowflake is automatically encrypted
- Data is decrypted during transformation and re-encrypted afterward
- Client-side encryption
- User encrypts data before loading it into Snowflake
- Follows specific protocol provided by cloud storage service
- Customer creates a secret master key which is shared with Snowflake
- Client provided by cloud storage service generates a random encryption key with the master key and encrypts the file before uploading
- The file and the key are uploaded and later downloaded
- The client decrypts the key and then decrypts the file using the key
- At no point does the cloud service or any third party see the unencrypted data
- The master key can be stored as a stage object in Snowflake - requires 256-bit Advanced Encryption Standard (AES) key encoded in Base64
- End-to-end encryption
-
Network and Security Policies
- Allow restricted access based on user IP address
- Can create allowed and blocked lists using IP address ranges defined as CIDR blocks
- Current IP address must be in the allowed list and must not be in the blocked list
- A security administrator (or higher) can create multiple policies, but only one can be associated with an account at a time
- Policies can be applied to specific users
-
Access Control
- Overview
- Access control determines who can access specific Snowflake objects
- Combines Discretionary Access Control (each object has an owner) and Role-based Access Control (privileges assigned to roles)
- Securable object = entity to which access can be granted (denied by default unless allowed by a grant)
- Role = entity to which privileges can be granted, in turn assigned to users or other roles (role hierarchy)
- Privilege = defined level of access to an object
- User = identity recognized by Snowflake, whether a person or program
- Considerations
- ACCOUNTADMIN Role
- Account administrators (ACCOUNTADMIN system role) can view and operate on all objects in an account
- Only assign ACCOUNTADMIN to a limited number of users
- Require users with ACCOUNTADMIN to use MFA
- Assign ACCOUNTADMIN to at least two users to avoid having to wait for password recovery procedures
- Avoid using ACCOUNTADMIN to create objects unless they require the highest level of security
- Don't make ACCOUNTADMIN anyone's default role
- Avoid using ACCOUNTADMIN for automated scripts
- Securable database objects require USAGE privilege on both the container database and schema
- Custom roles must be assigned to users or granted to other roles
- Use role hierarchies to align access with business functions
- Use managed access schemas for added object security (removes object owners' ability to make grant decisions)
- Use future grants to define an initial set of privileges applied to new objects of a certain type within a schema
- A user cannot view the results of another user's query
- Privileges granted on source objects are not transferred to cloned objects
- ACCOUNTADMIN Role
- Access Control Privileges
- Configuring Access Control
- Overview
-
Federated Authentication and Single Sign-On (SSO)
- Federated authentication enables SSO
- Logging into and out of Snowflake
- System timeout due to inactivity
- With SSO, users authenticate through an external identity provider (IdP) and can securely initiate Snowflake sessions during their IdP session without logging into Snowflake
- SSO workflows
- Login
- Snowflake-initiated: user goes to Snowflake, chooses IdP, if successful IdP sends SAML response to Snowflake to initiate session
- IdP initiated: user goes to IdP site and inputs credentials, then clicks on Snowflake application in the IdP, then IdP sends SAML response to Snowflake
- Logout
- Standard requires explicit logout of both IdP and Snowflake (supported by all IdPs)
- Global enables logout of all sessions and is IdP-dependent
- Snowflake-initiated: global not supported, each session must be explicitly logged out separately
- IdP initiated: depends on IdP, can be standard and/or global
- Timeout
- Snowflake: web interface is disabled, user must re-authenticate through IdP or cancel the session
- IdP: IdP times out, but open Snowflake sessions remain active
- Login
- Federated authentication enables SSO
Top comments (0)