Snowflake & Looker DataSecOps with Satori
In this post, we will discuss the DataSecOps advantages that Looker users over Snowflake enjoy by using Satori. If you are searching for a generic overview of how Satori helps organizations streamline their DataSecOps, visit our product page.
Here’s a short video of what we’ll cover:
A typical deployment of Satori with Looker looks like this:
As you can see in the image above, Looker goes through Satori when accessing data stored in Snowflake, and your data engineers and data owners can use Satori to simplify access and enhance security and governance. Satori can also optionally integrate with your IdP to provide additional context to your data access.
Here’s what we’ll discuss:
- Roles and Users Management When Using Looker with Snowflake
- Simplified Access Control to Snowflake Data
- Looker Users in Snowflake Database Audits
- Looker User Directory Groups for Snowflake
- Looker Row-Level Security with Satori for Snowflake
- Looker-Snowflake Continuous Data Classification with Satori
- Looker-Snowflake Policies with Satori
- Learn More
Roles and Users Management When Using Looker with Snowflake
There are two options for integrating Snowflake with Looker. One option is using a “Looker user” which will be used for the data access. Alternatively, you could use OAuth integration in which each user needs to log in with a corresponding Snowflake user using OAuth, and the token is kept in Looker until it expires.
The OAuth integration method is preferred, as it allows each user to be limited by their access, as defined in Snowflake itself. For example, if the user BEN@SATORICYBER.COM logs in through OAuth and has a default role of DATAENG, that user will be able to read data from all objects per the privileges defined in his configuration. In addition, we will be able to see the log entries for the specific user when looking at the Snowflake logs (QUERY_HISTORY and LOGIN_HISTORY) rather than seeing only a generic Looker user.
However, in many cases, this integration process turns into a more complicated project than simply connecting Looker, as these users have to be both created and provisioned, along with defining their corresponding default roles and data access grants. That is why we have simplified this process in Satori.
Simplified Access Control to Snowflake Data
Data owners can manage access to data without the need for data engineering intervention, which streamlines access to data. They can set self-service access to data, or approval workflows. Such data access can be limited in time, or revoked when unused, to reduce security risk.
Data owners can decide, for example, that they wish to grant data access to all data scientists, but only after they provide a required business justification when accessing new data. The access control is then managed with the same security policies applied across all tools, not only in Looker.
Looker Users in Snowflake Database Audits
When using Satori with Looker, with or without an OAuth integration, the configuration links the Looker users and utilizes them in Satori. This way, you can have an audit log based on the Looker user, rather than a generic Looker user, which is very helpful in analytics and, of course, for audits and compliance.
This capability is very useful, for example, if you want reports with users and teams’ access to sensitive data (such as PII or PHI) because it can generate these reports easily.
In the image below, we can see such data access done by a Looker user, in a non-OAuth integration, which is shown as the analyst himself instead of as a generic user:
Looker User Directory Groups for Snowflake
Having the capability to link specific users with their activity is of top importance, but I would say that data engineers using Satori are most excited about the ability to simplify management of data access groups using the Satori User Directory Groups.
Using Satori, you can define custom user groups for access with Looker to your Snowflake data cloud. In this manner, you can limit access to certain datasets or even allow data access only after going through specific data workflow triggers.
These groups can be comprised of a set of:
- IdP groups (such as Okta, OneLogin, or Azure AD)
- Snowflake users
- Snowflake roles
- Other Satori directory groups
This enables extremely robust access control, including both RBAC (role-based access control) and ABAC (attribute-based access control), which can be managed by data engineers but can, more importantly, be distributed to the data owners and data stewards.
Looker Row-Level Security with Satori for Snowflake
When you want to apply row-level security on Snowflake data for users employing Looker, you can do so by using the access_filter parameter for the Looker Explore object, or you can set row-level security using Snowflake. However, by applying row-level security in Satori, you ensure that users will experience the same restrictions across all tools (not just Looker) and all data stores (e.g. across both Snowflake and Postgres).
Setting Row-level security in Satori is straightforward, and can be handled using Satori UI, or by API integration. It also has the ability to apply row-level security on semi-structured data.
Looker-Snowflake Continuous Data Classification with Satori
Whenever data is accessed by Looker users, it is continuously classified by Satori, and, if there is new sensitive data, it is discovered in real time. With Satori, you can apply masking policies to desensitize data without configuring specific data locations so that, even if sensitive data (such as PII) is discovered in a new location, it will be masked when retrieved. This configuration can be limited only to Looker, only to certain datasets, or only to specific users.
Looker-Snowflake Security Policies with Satori
Using Satori, you can apply security policies to protect the data queried by Looker, which is stored in your Snowflake data cloud, in the same manner as data that is retrieved using other tools and data stores. You can then focus on the business goal - for example, you may want to apply security policies that block access to certain types of sensitive data from all users except a selected group, or you may want to mask all sensitive data unless a user is specifically allowed to access it.
Using Satori, you can manage and apply security policies easily across all of your data platforms, as per the screenshot below:
If you would like to learn more about how Satori can help you with streamlining DataSecOps by enabling agile security, governance, and privacy to your Snowflake data cloud using Looker, as well as with other data stores and BI tools, contact us today to set up a demo.
Schedule a Demo
Ready for better data access governance and universal data protection? Schedule a quick, private demo today!
Recent blog posts
- Introducing Data Access Policy as Code With Satori Terraform Provider
- Satori's New DataSecOps Policy Engine Will Streamline and Revolutionize Data Security for Large Enterprises
- Data Classification With Satori
- Data Classification Best Practices - Part 2
- Snowflake & Looker DataSecOps with Satori
- Data Classification Best Practices - Part 1
Posts by Tag
- Access Control
- Data Governance
- Data Protection
- Snowflake Data Warehouse
- data security
- data democratisation
- AWS Redshift
- Data Science
- Sensitive Data
- Data Classification
- Snowflake security
- Data Policy Management
- Policy Management
- self service access control
- Data Masking
- Human Element
- Least Privileges
- Policy Engine
- RSA ISB
- Redshift Security
- Redshift data access
- Row Level Security
- Snowflake Roles
- role hierarchy
- rsa conference
- rsa innovation sandbox
- snowflake stages