Thresholds are extensions of Column Access Policies that enable ALTR Administrators to set limits on Snowflake data access, such as limiting the number of values a user can access or limiting the times in which users can run queries against sensitive data. Thresholds can be configured to trigger a variety of actions, from triggering an in-app ALTR notification or completely restricting access to any sensitive data.
Thresholds extend the capabilities of Column Access Policies, so a Column Access Policy must be created first before you can begin using Thresholds.
Thresholds can be created on the Thresholds page, under Data Policy. To create a new threshold, click “Add New”. From here, you can specify:
Once all of those sections are complete, selecting “Create Threshold” will create the threshold and begin enforcing additional governance on your columnar data.
When a threshold is triggered, an “Anomaly” is generated in ALTR. Depending on whether the threshold is configured to block data, this anomaly may not not restrict access to the user who triggered the threshold.
If the Threshold is configured to block access, the user who triggered the threshold will no longer be able to query sensitive data in Snowflake. Any query they run on columns that are connected to ALTR will result in NULL values. This behavior will continue until an ALTR admin resolves the Anomaly.
Is the Threshold is only configured to generate an Anomaly, the user who triggered the threshold will be able to continue querying data in Snowflake.
Once an anomaly is triggered, an admin in ALTR can resolve the Anomaly in the Anomalies page. On this page, an ALTR administrator can easily see which users have triggered thresholds and which threshold they triggered. Closing an open Anomaly is as simple as clicking “Resolve Anomaly” and leaving an optional comment. If the threshold was configured to Block access to data, resolving an anomaly will allow the blocked user to regain access to sensitive data.
ALTR uses a variety of tools and algorithms to enforce thresholds in Snowflake.
When ALTR is invoked by Snowflake’s Dynamic Data Masking Policies for columns that are protected by time-based thresholds, a comparison of the current time to the threshold’s rules determines whether or not the threshold is triggered.
Snowflake’s Dynamic Data Masking Policies invoke ALTR’s governance engine on every query on connected columns, but before result sets are determined. Because of this, ALTR must estimate the result set to make a governance decision for Access-Based thresholds. This process is called “Predictive Thresholding”.
ALTR’s query parsing engine uses a variety of mechanisms to estimate result set engines, such as parsing of limit stations and cacheing of table row sizes. However, this system may not always be able to accurately predict how many values will be returned by a query before the query executes - especially for more complex queries or if new values have been recently inserted to a table. To ensure that access-based thresholds properly trigger, ALTR monitors Snowflake warehouse activity and triggers the threshold after the query executes in hindsight. Because of this, ALTR is able to properly trigger access-based thresholds even if it was unable to properly predict the result set size before the query executed. This hindsight threshold triggering typically resolves within two minutes of the query completing.
Warning: Due to ALTR’s limited ability to predict the result set size of complex queries, there is a small window of time between query execution and when ALTR is able to access the number of rows returned by the query. Because of this, users violating thresholds may be able to access more data than intended, both on the query triggering the threshold as well as any queries made before ALTR is able to access the query results.
Note: Snowflake sends information about columns accessed to ALTR one-by-one. Because of this, if ALTR determines that a query is going to trigger a blocking Threshold, only the triggering column and other connected columns considered after the column triggering the threshold will be NULLed. ALTR has no control or insight in what order columns are sent by Snowflake for governance decisions, so this may appear random. This only applies to columns triggering a Threshold; any connected columns queried by a user after the trigger a blocking Threshold will always be Nulled.