Simplifying Snowflake Roles Management using Satori
A few days ago, I wrote about some of the complexities of managing Snowflake roles at scale. In that post, I concentrated on why it’s difficult to scale roles management, as the process data consumers must go through to solve data problems (such as predictions, analytics, etc.) can be complex.
After publishing the article, I was asked, “So, how does Satori simplify the process?” Therefore, I thought it would be interesting to share some details about how we help solve these problems for Snowflake customers, as well as organizations using other data warehouses and lakes.
Before starting, it’s important to note that one of our company’s core beliefs is that we must be as least intrusive as possible. This means that Satori does not interfere with the role management or access controls you have set up in Snowflake (or other data stores), but rather augments them. There is no need to change the way your data is architectured, migrate roles, or make any other complicated changes.
So, here are several ways in which we help simplify data access and roles management:
Decoupling Access Control from Data Infrastructure
In most organizations, data engineering teams manage data authorization, as they have DBA access level to the Snowflake data warehouse or other data stores. That means they’re eventually running the GRANT/REVOKE commands based on requests streamlined to them by data owners and users. They do not always know the exact nature of the data they’re granting access to. This makes them a bottleneck, and this job is often a side track of actual data engineering, and not their favorite part of their work.
By decoupling access control from the data infrastructure and using Satori, access to the data can be self-serviced or done by data owners and stewards instead, which eliminates a large part of the complexity.
Using IDP Groups for Setting Access Policies
Satori’s Data Access Controllers are enriched with user context information, particularly from Identity Providers (such as Okta). This context allows easy policies to be applied to the data access, which eliminates the need to manage permissions in a certain role perspective. That means that you can set a Satori policy enabling or restricting certain IDP groups from accessing certain datasets. You can even set access permissions in a more holistic manner (such as restricting access to PII, Financial Data, or other types of data).
For example, here’s a simple policy blocking access to any financial data from users who are not part of the “finance” IDP group:
- name: Block access to financial data from anyone outside Finance group action: block identity_tags: - not identity.idp.group::finance data_tags: - c12n.operational::financialdata
In addition to simplifying the process, this feature also reduces your reliance on IT and other departments, thus eliminating delays and frictions.
Simplifying Snowflake Data Masking
Snowflake Dynamic Data Masking is a helpful feature that enables you to return different (masked) data based on users’ roles. This enables configuring policies, which enable granular access control, in which you can only view the data in certain columns if you work in a specific role that has been granted access.
Satori’s Universal Masking makes it even simpler to mask sensitive data. With Satori’s Universal Data Masking, you do not need to configure each column in the table according to a specific masking policy (although you still can if you prefer), and can instead set clearer policies, such as “all analysts can view only hashed sensitive data,” “a certain IDP group can see PII” and more.
In the below example, we’re setting a masking profile concealing all PII, PHI and financial data access, which can be applied according to the organization’s data access policies:
In addition, by using Satori’s Universal Masking, you’re improving performance, as queries are still cached and optimized in Snowflake and are only masked by Satori’s DAC.
Easier Row-Based Security
Setting up Row-Based Security means certain teams will only be able to access data that “belongs” to them. While this is often a necessary task, configuring it is not for the faint of heart, as it requires adding an abstraction layer in Snowflake Secure View, which may be hard to manage at scale (when you need to set up secure views for hundreds of tables).
Setting up Row-Based Security in Satori for Snowflake data warehouses reduces much of the overhead required by mapping the row-level security relations separately from the data and applying them to hundreds or thousands of tables at once.
Having to pre-configure data access whenever you add new datasets, or for different data projects, delays data access. By setting “blanket” policies in Satori (for example, restricting all access to PII from non-authorized data consumers), and self-servicing data access, we eliminate some of the need for pre-configuration. Of course, such specific configurations can be added when needed, but this helps make data access faster and simpler.
Simplifying Maintenance of Roles
As I wrote in my blogpost about managing Snowflake roles, part of the process of granting access to data is also maintaining, auditing, and monitoring that access, as well as revoking it when necessary. Satori offers enriched data access audits, which contain important metadata such as:
The redacted query
Resultset columns, as well as data types (such as sensitive data types)
User context, such as the user’s IDP groups
Tools used, query ID, and more
This simplifies auditing, monitoring and ongoing roles management, as well as generic access management.
To sum it up…
Managing roles using Satori does not detract from the great features Snowflake offers, but rather simplifies roles management and data access management at scale. And Satori does not only simplify roles; it offers a scalable and simple data governance solution that’s actually fun to manage.
If you’d like to learn more about how Satori accomplishes this, I invite you to join a personal 30-minute demo. You can click here to schedule it right away.