Modern Data Access in Snowflake

When I first wrote this blog in June 2021, it was called “Zero to Self-Service Snowflake Data Access Management with Satori.” At the time, I had been speaking to tons of Snowflake teams and hearing the same few problems:

Data engineering teams felt that granting and revoking access to specific databases, schemas, and tables could get very repetitive and time-consuming, sometimes requiring additional iterations with identity teams to update the IdP structure.
The access request process was often so tedious that data users would instead “make do” with less than optimal data.
Some teams gave up on this process and allowed for overly loose data access policies, putting themselves at risk of data exposure and compliance failures.
In many cases, access would be granted but rarely revoked when no longer in use, resulting in over-privilege risks.

Four years after writing that blog, Snowflake is a different beast with its Snowflake Horizon Catalog, automatic classification, and row- and column-level security.

Today, companies have more data stores, more projects, and more users accessing data than before. The challenge has mainly shifted to being about managing data security and compliance beyond Snowflake, in environments with multiple regions, cloud platforms, and numerous production and analytical data stores. Still, Snowflake environments can be notoriously complex, and even with their data security advancements it can be hard for data and security teams to manage access within them.

Luckily, Satori makes it easy to distribute data access and apply approval and self-service workflows, in Snowflake and the rest of your data environment.

Distributing Data Access Management

Satori's native integration with Snowflake uses Satori to enforce security policies directly onto Snowflake, leveraging Snowflake's existing data access capabilities. The first step to streamlining data access is allowing security engineers or data owners to manage access to their data. This is done through the following configurations in Satori:

Datasets - engineers can define a dataset that can be as granular as a single table, cross-Snowflake accounts, or even a combination of data in Snowflake with data stored in other platforms.
Data Access Workflows - either engineers or the data owners themselves can easily define data access workflows. These workflows can be set by defining specific users or user groups with different access levels to the dataset and can also be in an approval or self-service manner.

By defining this information in Satori, you can assign different data stewards to control access to the data directly, without further need for engineering intervention. This process shortens the time it takes to get access to data and frees data and security engineering from this process.

Approval-Based Data Access

An approval-based data access workflow enables defining users or groups of users to apply automatically for data access requests. The process is straightforward:

The data user or admin attempts to access data and is given a link to the data access portal.
In the data portal, the user fills out their business justification for accessing the data.
Once they submit the request, the data owner gets a notification and can approve the request. Multiple approvers can be specified who have the ability to approve the access request.

For example, looking at customer orders is restricted, but specific teams are allowed to request access. Then, access can be granted to them for a specified amount of time, after which it is automatically revoked and needs to be approved again.

Self-Service Data Access

A self-service data access workflow enables defining users or groups of users to obtain data access automatically after specifying a business justification. The process is also very straightforward:

The data consumer attempts to access data and is given a link to the data access portal.
In the data portal, the consumer fills out their business justification for accessing the data.
Once they submit the request, they automatically get access to the data for a limited amount of time, and the business justification is recorded.

An example would be allowing self-service data access to DBAs who need to fix a production issue. Instead of giving constant access for DBAs to all data, this feature enables DBAs to still do their work while having more control over the data they are accessing and the reasoning behind it.

For more information about how data access requests and approvals work in Satori, refer to the documentation: https://satoricyber.com/docs/data-portal/

No More Over-Privileges!

As we all know, over-privilege in data access is a risk that doesn't go away on its own. The risk keeps growing when users have more access than they need, and data access is granted often but rarely revoked.

Managing Snowflake data access automatically through Satori reduces the risk of over-privilege significantly by:

Eliminating the bottlenecks engineers face that cause them to grant more access than is needed just to avoid dealing with additional access requests.
Giving engineers the ability to group users into more logical groups (in terms of data access), providing access only to the users who actually need data for a particular project, not to a larger team.
Access through Satori is automatically provisioned by setting a specific period for which the access will be granted, as well as a particular period for which unused data access will be automatically revoked.

The best way to learn about self-service is to schedule a demo to discuss if Satori can help you with Snowflake data access.