Let’s start with good news - if you are using Snowflake and want a simple way to manage data access workflows, Satori can help you do just that. I will now explain this simple process which may save you a lot of data engineering resources and, more importantly, allow your organization to consume data faster while maintaining security and compliance.
Before I start explaining how you can do this, I wanted to share that we have been speaking with a lot of Snowflakers before and during our work on developing this capability, and, overall, here are the main problems they experienced which we wanted to address:
- Data engineering teams feel that granting and revoking access to specific databases, schemas, and tables can get very repetitive and time consuming. Sometimes, these processes require additional iterations with Identity teams to update the IdP structure, which adds more complexity.
- Some data engineering teams or organizations give up on this process and allow for data access policies that are too loose, putting themselves at risk of data exposure and, in many cases, breaking compliance.
- Data consumers sometimes give up on data access requests because they know the process will be tedious and instead “make do” with less than optimal data. Doesn’t that defeat the purpose of why we wanted data democratization in the first place?
- In many cases, access is granted but is rarely revoked when no longer in use, resulting in over-privilege risks.
Enabling self-service data access and automated approval processes to data in Snowflake using Satori is easy, and today we’re going to show you how to do just that. I will demonstrate how to distribute data access from data engineering to its business owners and apply approval and self-service workflows.
So let’s go from zero to self-service Snowflake data access using Satori.
Distributing Data Access Management
In order to help data engineering teams administrating Snowflake to streamline data access and prevent a bottleneck effect, a first step is to allow the data owners (or data stewards) to manage access to their data. This is done through the following configurations in Satori:
- Datasets - the data engineers can define a dataset that can be as granular as a single table, or even cross-Snowflake accounts, or even a combination of data in Snowflake with data stored in other platforms.
- Data Access Workflows - either data engineers or the data owners themselves can easily define the 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 (which causes no changes in your Snowflake accounts), you can assign different data stewards to control access to the data directly, without further need for data engineering. This process shortens the time it takes to get access to data and frees data engineering and IT 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 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, the data owner gets a notification and can approve the 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 limited amount of time.
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 teams like data scientists. Instead of always opening access for data scientists to all data, this feature enables data scientists to still do their work while having more control over the data they are accessing and the reasoning behind it.
Here is a short demo of both approval and self-service workflows in action:
No More Over-Privileges!
As we all know, over-privilege in data access is often a continuously growing risk for organizations. This risk is growing because users have more access than they need, thus creating additional risk with no added value. The main reason for over-privilege is that 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 bottleneck which data engineers face that often causes them to grant more access than is needed, so they will not need to deal with additional access requests.
- Giving data engineers the ability to group users into more logical groups (in terms of data access), thus 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.
Conclusion
The best way to learn about self-service is to schedule a demo to discuss how self-service Snowflake data access can work for your company. You can also read more about our self-service data access here or read the product documentation here.
