Snowflake Access Control and Satori

Snowflake comes with built-in powerful authentication and authorization capabilities. Combined with Satori's authorization capabilities, organizations are able to enforce advanced fine-grained security and privacy policies while greatly reducing the level of effort required to do so. The following section provides a template on how to utilize the capabilities of both systems.

Learn more about the benefits of Satori for Snowflake and Schedule a demo meeting

Access Control in Snowflake

Snowflake implements the role-based access control paradigm to manage permissions to database objects such as tables or views. In RBAC, roles define what level of access are granted to specific database objects, and when a role is assigned to a user, the user is granted with privileges to access the database objects listed in the role.

For more information on Snowflake's access control capabilities, read the documentation.

How Does Satori and Snowflake Work Together?

Satori enforces access to data by intercepting queries before they reach Snowflake. If Satori determines that the user is allowed to execute the query, it sends it to Snowflake and if not, an error is returned. When queries reach Snowflake, they are evaluated using Snowflake's RBAC-based authorization. This means that users need to execute their queries using a Snowflake role that grants them with the required level of access to the objects they are querying.

Unified Access Control Strategy

Many organizations are looking to implement fine-grained access control to data. However, since changes to database privileges require administrative access to Snowflake, data engineering teams often become a bottleneck in the process. In addition, without effective automation or tooling around managing authorization, practicing least privilege access to data is challenging. It's a simple tradeoff between effort and risk - to reduce risk, a large amount of effort needs to be invested.

Following the Pareto principle, we've seen organizations move to a simpler, more practical approach to managing access to data in Snowflake - instead of creating a large number of roles to capture a complex authorization scheme, organizations are separating between common datasets and more restricted ones.

Common Datasets

Common datasets refers to datasets that most users should be able to request access to. Create a COMMON Snowflake role that grants read-only access to all the relevant Snowflake objects such as warehouses, databases, schemas and tables. Then assign these roles to all the users of the Snowflake account. Then, create one or more datasets in Satori to a subset of these tables, define access rules, enable access requests or self-service access as needed.

Because all users are assigned to the COMMON role, Satori can fully control access to the data without forcing data engineers to change permissions settings on Snowflake. In most organizations this approach solves managing access issues for 80% of the data with minimal ongoing effort from data engineering teams.

Restricted Datasets

Restricted datasets refers to datasets that most users should not be able to request access to. For example Financial or Legal data. Create a Snowflake role for each of these types of datasets and a corresponding Satori dataset, then assign the Snowflake roles to users as required. For example, employees who are finance team should be assigned to the FINANCE Snowflake role. Dataset stewards for these datasets will then grant access to data on a need-to basis.

Example

John is a member of the finance team. Following the unified access control strategy, John is assigned to both the COMMON and the FINANCE roles in Snowflake, as depicted by the solid Blue arrows in the diagram below. John requested access to the Customer Demographics and Sales Forecast datasets and was granted access, however he was not granted access to the Order Fulfillment dataset, as shown by the dashed Red arrow.

Cross-dataset queries

Snowflake's RBAC enforces a single role that is assumed by a user when running a query. This means that, unrelated to Satori, users cannot join data between tables from common datasets and restricted datasets. To resolve this, organizations can consider creating another level of roles that inherit from the COMMON role and any required restricted role. So, if John needs to join data between a common dataset and a finance dataset, a COMMON_FINANCE or USER_ROLE_JOHN roles can be created that inherit from both the COMMON and FINANCE roles.