Snowflake Data Application Security

Everyone, what are you doing with Snowflake? I think it is often used as a DWH to integrate internal data into one place. On the other hand, there are not many companies that are actually practicing use cases that incorporate it as part of their own application functionality.

Therefore, I will be writing about “Data Application Security” which is necessary to embed Snowflake in an app. Snowflake offers various types of applications such as native apps, connector apps, and management apps. In this article, I will explain the details of these apps and also touch upon best practices related to security.

Chapter 1: Deployment and Isolation Patterns

There are three main deployment patterns for Snowflake:

Snowflake Deployment Patterns

1. Managed App

- A managed app is a type of software service application where users only need to connect to the application without worrying about Snowflake running in the background.
- The application provider builds the application and owns and manages the Snowflake account behind it.
- Users can connect to the Snowflake account and run the application.

2. Native App

- A native app is a deployment pattern that transitioned from Snowflake’s private preview to public preview.
- In this pattern, application execution and orchestration occur within the Snowflake ecosystem.
- App providers create the app and offer it through the Snowflake Marketplace or direct sharing.
- Users can acquire this app and run it in their environment.

3. Account per Tenant

- In this deployment pattern, each tenant has its own database and related objects, with data being isolated at the database level.
- Role-Based Access Control (RBAC) provides separation between tenants, and each tenant has its own warehouse.
- Furthermore, network isolation is provided at this level, and users can bring their encryption keys.

Snowflake Isolation Patterns

There are three main isolation patterns for Snowflake:

1. Multi-Tenant Tables

- In this pattern, app consumers or tenants share the same tables.
- Snowflake provides isolation between tenants using views, UDFs, row-level access policies, and column-level security.
- It is also possible to share compute resources among multiple tenants.

2. Object per Tenant

- In this pattern, each tenant has its own database and related objects, with data being isolated at the database level.
- RBAC provides separation between tenants, and each tenant has its own warehouse.
- Network isolation is also provided, with each tenant having its own account.

3. Account per Tenant

- In this pattern, each tenant owns one or more accounts, with accounts being isolated per tenant.
- Network isolation is provided at this level as well, and users can bring their encryption keys.

Choices and Best Practices

The choice of deployment and isolation patterns depends on use cases and business cases, but there are some best practices to consider:

1. Data Selection and Storage:

Select secure objects like tables and views and set access policies and security appropriately.

2. Role-Based Access Control (RBAC):

Define user entities with minimal privileges and grant minimal privileges to the environment.

3. Identity and Access Management:

Define user authentication and authorization methods to enhance account security.

4. Network Security:

Properly configure network security, such as isolation between tenants and public access blocks.

Chapter 2: Network Security and Best Practices

Overview

Snowflake, a cloud-based data platform, provides essential elements for network security to ensure data security and performance. This article focuses on Snowflake’s network security and explains best practices in detail.

Network Connectivity and Security

Connections between Snowflake accounts and applications are typically made over the public internet. There are four main communication channels regarding network connectivity:

1. Connection to Snowflake accounts
2. Connection to OCSP provider hosts
3. Connection to internal stages managed by Snowflake (S3 buckets or Azure Blob)
4. Connection from Snowflake to customer-managed external stages

If your application is hosted on the same cloud provider as the Snowflake account or running on-premises, you can establish a private connection. This utilizes Snowflake’s Private Link service used in critical business scenarios. The Private Link service leverages cloud provider services like AWS Private Link, Azure Private Link, GCP Private Connect.

Network Policy and Security

Network policy is a crucial element for managing the security of Snowflake accounts. Network policies can be applied at the following levels:

1. Account level
2. Integration level (schema integration, OAuth integration)
3. User level

User-level policies take precedence and are the most specific. Network policies manage IP address permissions or denials, which can be a challenging task due to the dynamic nature of IP addresses.

Therefore, Snowflake introduced “Network Rules.” Network Rules allow the use of cloud provider identifiers (VPC ID, Link ID) instead of IP addresses, reducing the overhead of IP-based management and enhancing security.

Advantages of Network Rules

The advantages of Network Rules include:

1. Reducing the overhead of IP-based management
2. Resolving IP address overlap with Private Link connections
3. Simplifying access control to internal stages

Network Rules are referenced and evaluated within network policies, enabling more effective security management.

Best Practices for Network Policies
Best practices for configuring network policies include:

1. Using different network rules for each tenant
2. Applying multiple network rules to network policies
3. Controlling external access using network rules

By properly configuring network policies and network rules, you can secure your Snowflake account and achieve secure communication with applications.

Chapter 3: Data Application Security and Access Control

OVERVIEW

Security and access control for Snowflake data applications is essential to ensure data security and proper access management. Utilize best practices such as SSO authentication, enabling MFA, password policies, session policies, and leverage external OAuth and Snowflake OAuth appropriately to enhance data security. Choose authentication methods wisely. Implement access control effectively using function roles and access roles. Proper configuration and monitoring are crucial for security in connected applications. Make use of these approaches for Snowflake data application security and securely manage data.

User Access and Authentication

1. Use of SSO Authentication

It is recommended to use Single Sign-On (SSO) authentication for access to data applications. SSO authentication is an excellent option from a security and management perspective. However, in certain specific scenarios, local usernames and passwords may be required, such as when administrators need access to Snowflake or when there are issues connecting to the IDP.

2. Enabling Multi-Factor Authentication (MFA)

To enhance security, enable Multi-Factor Authentication (MFA). Require MFA even for privileged users to improve security. It is possible to use MFA provided by the IDP or the native MFA provided by Snowflake. Set up at least two account administrators to handle password resets and issue resolution.

3. Application of Password Policies

Snowflake supports password policies that allow you to set requirements for passwords. You can specify complexity, use of special characters, retry counts, lockout periods, etc. Configure it according to the requirements of the information security team. Using appropriate password policies can lead to improved security.

4. Setting Session Policies

By using session policies, you can control timeouts for UI sessions and driver sessions. The default session timeout is 240 minutes, but you can adjust the session policy as needed to set the lifespan of sessions. Session policies can be applied at the account level and user level, with user policies overriding account policies.

5. Control of Authentication Policies

If you want to restrict access to the web interface for specific user groups, you can use authentication policies. Authentication policies control based on authentication methods and client types. This allows you to apply different authentication policies to specific users. This feature is also useful when implementing MFA enforcement based on authentication methods or client types.

Authentication Methods and External OAuth

1. Utilizing External OAuth

When using external OAuth authentication, it is suitable when the authentication server belongs to an external IDP (e.g., OKTA, Active Directory, custom IDP). External OAuth supports various flows and provides many features such as code grant flow or client credentials. When using external OAuth, be mindful of the availability of the IDP.

2. Leveraging Snowflake OAuth

Snowflake OAuth functions with Snowflake itself acting as the authentication server providing tokens to clients. This can be beneficial when not having external OAuth. Snowflake OAuth helps save effort in ensuring high availability. Since the authentication process is integrated into Snowflake, it is independent of the availability of the IDP.

Access Control and Roles

1. Function Roles and Access Roles

Access control in Snowflake data applications is done using the concepts of function roles and access roles. Access roles have read and write access to database objects. On the other hand, function roles are mapped to user functions, and access control is achieved by assigning access roles to function roles. This allows for granular access management and application of the principle of least privilege.

2. Configuration of Access Roles

Access roles are usually set up using SQL and are often not managed by the IDP. Conversely, function roles are typically managed in IDP groups and automatically provisioned along with users. Access roles represent access rights to database objects, enhancing security and access control.

3. Security of Connected Applications

Connected applications require advanced configurations from a security standpoint as they are accessed by two different entities within the same Snowflake account. The application consumer, who is the owner of the account, needs to allow application providers access to the account. To enable application providers to manipulate data within the account, set up account-level objects (databases, roles, warehouses). However, for security and cost management, delegating access rights at the schema level to application providers is crucial. Additionally, create tags and policies and apply them as part of data governance.

Chapter 4: Latest Information on Data Sharing and Security

OVERVIEW

By understanding the latest information on Snowflake data sharing and security, you can achieve secure data sharing and access management. Features that help achieve security, such as database-level roles, data masking policies, data encryption, auditing, and monitoring, are provided. When deploying data applications, ensure proper access control and security measures are in place.

Data Sharing and Permissions

1. Past of Data Sharing

In the past, when sharing data, there was a single privilege called “imported privilege” that granted access to all objects within the data share. However, this approach was overly comprehensive and made it difficult to control access to individual objects within the data share.

2. Database-Level Roles

With the latest update, database-level roles have been introduced. This allows for more detailed control over access to objects within the data share for data providers (data application providers) and data consumers (data application consumers).

3. Application of Data Masking Policies

Data providers can create data masking policies using database-level roles. This enables the propagation of data masking policies from data providers to data consumers, controlling access to the data. By leveraging the new context function “is database role in session,” data providers can set data masking policies and data consumers can apply them. This mechanism ensures real-time application of policy changes by data providers to all data shares.

Optimization of Access Control

1. Best Practices for Access Control

In data sharing, it is important for data providers to minimize data access rights by applying role hierarchies and least privilege access. Data providers should manage access control and configure data objects.

2. Management Based on Deployment Patterns

When managing data applications, the roles of data providers and data consumers differ. In management applications, data providers should manage access control. On the other hand, in connected applications, data consumers can manage and delegate schema-level access to data providers.

Data Encryption and Security

1. Importance of Data Encryption

Data encryption is essential for data security. Snowflake provides data encryption using AES 256 to ensure data security. A feature called “Tri-Secret Secure” has been introduced for data encryption, allowing data providers to encrypt data using their own keys.

2. Key Management per Account

For data sharing across accounts or enriching data, it is important to use different keys for each account. Considering database roles allows setting different encryption keys for different tenants. Using database roles enables more effective key management.

3. Deletion of Confidential Data

When suspending application use and deleting data, you can invalidate or delete data encryption keys. This helps comply with regulations like GDPR.

Audit and Monitoring

1. Audit of Data Access

Auditing and monitoring data access is crucial. Snowflake allows tracking data reads and writes, policy enforcement, tag application, DML and DDL operations through the use of “access history.” Data relationships and login histories are also audited.

2. Audit Options

When selecting audit tools, you have two options: Option A and Option B. Option A uses a tool that connects to all Snowflake accounts, while Option B allows each account to create its own audit and monitoring data securely shared via data sharing.