How to Monitor Access to Sensitive Data In Snowflake with Satori
Being optimally focused is the key that helps you spend your resources better. When your organization has a lot of data that you put in your Snowflake Data Cloud, it is important to prioritize your focus on the things that matter most, and part of that is monitoring the sensitive data you have within your tables and managing who accesses it.
Types of sensitive data to monitor
There are several main types of sensitive data that you should monitor access to, which are listed below. Please keep in mind that the complete list depends on your organization and the type of data it has.
PII (Personal Identifiable Information): This includes things such as names, phone numbers, email addresses, login IP addresses, addresses, and other information that can identify data subjects.
PHI (Protected Health Information): This equates to data such as medical information and identifying information like EMPI (Enterprise Master Patient Index) or health plan beneficiary numbers.
Operational Data: This type of data consists of passwords, IP addresses, API keys, etc. whose exposure may cause a security risk.
Financial Data: Financial information or other business information that may contain commercial secrets and should not be shared broadly.
Why is it important to monitor access to sensitive data?
It is vital to monitor access to sensitive information in your organization in terms of compliance, regulations, and risk-reduction frameworks used by your business. It is also incorporated for privacy reasons, such as making sure you’re meeting privacy regulations and are not exposing private information beyond what’s permitted. Furthermore, personal data leakage may be a catalyst to severe security risks.
Monitoring sensitive data access also helps your organization gain more confidence in Snowflake, and enhance your use of Snowflake to store and analyze data, thus increasing the overall strategic value of your data.
Steps of Monitoring Sensitive Data in Snowflake
There are two steps in monitoring sensitive data in Snowflake:
The first is the inventory of your data. To monitor sensitive data, you need to know where it is and have an inventory of the location of sensitive data in your Snowflake data cloud.
The second is having the ability to monitor access to those locations, and being able to answer questions about what type of sensitive data was accessed, when, and by who (users, groups, and roles).
Let’s dig a bit deeper into those steps, check the alternatives, and discuss why using Satori over Snowflake is the best solution to meet your objectives.:
Step 1: Data Inventory
Mapping your sensitive data can be done in several ways. For instance, you can use methods like sending questionnaires to data owners. Regardless, you would want to map the data you have that is being accessed and know what types of data it contains. This is either done manually for a relatively small dataset, or in an automated fashion.
When leveraging automation, it can either be done as an ad-hoc project of mapping sensitive data in your data repositories or done continuously. When you use Satori for Snowflake, it is automatically being updated to find out where sensitive data is inside your Snowflake data cloud. You can read more about the different ways to create a data inventory over Snowflake here.
We believe continuous discovery is better than ad-hoc mapping due to the following reasons:
Data in a data warehouse is constantly updated and changed, and a mapping project quickly becomes stale.
By performing the data inventory without scanning your Snowflake data cloud, we guarantee zero impact to activities, which also means that you do not need to coordinate such efforts across the organization. Thus, saving you immense time, resources, and money.
This is a sample of the continuously updated data inventory in Satori, where you can also override the autonomously discovered tags manually:
You can easily create views in Satori with newly discovered sensitive data so that you can take action specifically about new instances of sensitive data (such as apply masking or other types of access controls).
You can read more about Satori’s autonomous data inventory here.
Step 2: Monitoring Access to Sensitive Data
There are several ways you can monitor access to the mapped sensitive data. One of them is by analyzing the access logs in Snowflake (under snowflake.account_usage.query_history). However, you will need to crunch some data and process the raw data to make sure you correlate between the columns that were pulled, and those containing sensitive data. You will also need to analyze the data some more to know if some of this data was masked by Snowflake’s dynamic masking (and therefore is not sensitive).
In Satori’s analytics dashboard, you can monitor access to sensitive data as well as create saved views with the monitored data during a certain time window for specific locations or groups. Here is an example of what that looks like:
In addition, the enriched audit we provide contains contextual data, including the exact types of sensitive data that were accessed in each query, as well as the specific locations in which they were extracted. Here is a demonstration of that:
In conjunction with this, you can filter and analyze the audit to monitor exactly what is required for your organization. An example would be creating a view of the data access to sensitive data in the last day or week. More information on Satori's universal audit, can be found here.
Monitor Sensitive data access in Snowflake now!
If you’d like to see our demo and understand how Satori can painlessly enable you to monitor your sensitive data and do much more around the governance, security, and compliance of your Snowflake data, you can schedule a demo here.
Recent blog posts
Posts by Tag
- Data Governance
- Access Control
- Data Protection
- Snowflake Data Warehouse
- AWS Redshift
- data security
- Data Science
- Sensitive Data
- data democratisation
- Snowflake security
- self service access control
- Data Masking
- Human Element
- Least Privileges
- Policy Engine
- RSA ISB
- Row Level Security
- Snowflake Roles
- role hierarchy
- rsa conference
- rsa innovation sandbox
- snowflake stages