Section 1.2 - SnowPro Core Certification Study Guide

#cloud #cloudskills #snowflake #examprep

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.

Return to Exam Guide

1.2 Outline security principles

Summary of Security Features

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
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
- Access Control Privileges
- Configuring Access Control
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