Getting Started with ALTR & Snowflake
Configure ALTR's Snowflake Service User
Connect Snowflake Databases
Connect Columns to ALTR
Creating Policy & Manage Data
Classification
Analytics
Column Access Policies
Thresholds
Row Access Policy
Audit Logs
Settings
Vault Tokenization
Tokenization API
Management API
ALTR Driver JDBC Installation
ALTR Driver ODBC Installation
Configure Tableau to Gain User Level Observability
Integrating ALTR Notifications with AWS S3
TDS Proxy Installation
CDM Installation
Custom Masking and Extensibility Functions
Bring Your Own Key for Vaulted Tokenization
ALTR uses a "Service User" to connect to Snowflake, which is an account to your Snowflake instance used to create and enforce governance policies. This page guides you though how to manage this Service User and ensure it has all of the necessary permissions for policy creation and enforcement.
In order to create and enforce data governance policies, ALTR needs to be able to access your Snowflake account and create schema objects. It does this just like any other Snowflake user - by having a User, Role, and warehouse with which to communicate with Snowflake. We refer to these as the “Service User”, “Service Role”, and “Service Warehouse”.
When signing up for ALTR through Snowflake Partner Connect, Snowflake automatically creates a user, role, and warehouse for ALTR - PC_ALTR_USER, PC_ALTR_ROLE, and PC_ALTR_WAREHOUSE. Although Snowflake automatically grants some permissions to PC_ALTR_ROLE, these are not sufficient to create and enforce governance policies. This document describes what permissions are required by ALTR’s Service User, why it needs them, and how you can permission (and re-permission) PC_ALTR_ROLE.
If you created your ALTR account directly through ALTR’s website, Snowflake did not auto-create a service user, role, and warehouse. Instead, you likely executed ALTR’s stored procedure for creating a service user - or you made your own. If you went through the stored procedure and need to re-permission the Service User (ALTR_SERVICE_USER), you can follow the same instructions as below - though be sure to set the parameter to FALSE instead of TRUE and ensure it’s affecting the correct role.
To quickly and easily configure ALTR’s Service User with all of the permissions required to create and enforce governance rules, we have prepared a Stored Procedure that enables you to automate grants with just a few SQL commands. If you signed up through Snowflake Partner Connect, ALTR automatically created a copy of this stored procedure in PC_ALTR_DB. If you signed up through ALTR’s website, you likely copied and pasted the stored procedure yourself.
Running the Stored Procedure iterates through every database in your Snowflake Account and grants ALTR’s service user particular permissions to create and enforce governance policies. If you’ve created new Snowflake databases since starting with ALTR, or if you have some other permissions issue, re-running the stored procedure will re-configure the Service User to the correct permissions. The stored procedure must be run as ACCOUNTADMIN. Sometimes, ALTR updates the service user to account for new features enabled by Snowflake, such as the ability to create and maintain Row Access Policies. If you are having Service User issues and have not run the stored procedure in awhile, copy the latest version from this page instead of relying on any older version.
The stored procedure grants PC_ALTR_ROLE (Snowflake Partner Connect Signups) or ALTR_SERVICE_USER (altr.com Signups) the following permissions:
CREATE DATABASE: This is used for debugging
APPLY MASKING POLICY: ALTR Uses Snowflake’s Dynamic Data Masking Policies to create and enforce Column Access Policies. When a column is connected to ALTR, ALTR creates a Masking Policy for that column in Snowflake. Once that policy is created, ALTR is invoked by Snowflake to make a governance decision each time that column is queried.
CREATE INTEGRATION: ALTR communicates with Snowflake to make governance decisions through an API integration. This permission enables ALTR’s Service User to create those API integrations for each connected database.
APPLY TAG: ALTR can invoke Snowflake’s Classification tool to generate SEMANTIC_CATEGORY and PRIVACY_CATEGORY tags, which can then be leveraged when defining Tag-Based Column Access Policies. The APPLY TAG permission is required to assign these tags to columns during a Snowflake Classification.
APPLY ROW ACCESS POLICY: This permission is required for ALTR to apply Row Access Policies to tables in Snowflake.
MONITOR ON WAREHOUSE: ALTR monitors warehouse activity to identify when sensitive columns are access by users. This is particularly used for ALTR’s Thresholding and Rate Limiting capabilities, as monitoring warehouse activity enables ALTR to identify exactly how many values of a column were accessed.
USAGE ON DATABASE: This enables ALTR to access databases in Snowflake to create the necessary objects to enforce governance policies
CREATE SCHEMA ON DATABASE: ALTR creates all it’s governance objects in a custom ALTR_DSAAS schema, ensuring that these policies are separated from data-holding schemas.
USAGE ON SCHEMA: This enables ALTR to create necessary schema-level objects to create and enforce governance policies.
SELECT ON TABLES: ALTR does not automatically select or store any raw data (actual values) from client Snowflake Accounts. However, if you opt-in to a Google DLP classification, ALTR uses this permission to randomly sample data from tables for classification. ALTR does not persist these samples.
CREATE TAG ON SCHEMA: ALTR can invoke Snowflake’s Classification tool to generate SEMANTIC_CATEGORY and PRIVACY_CATEGORY tags, which can then be leveraged when defining Tag-Based Column Access Policies. The CREATE TAG permission is required to create these tags during a Snowflake Classification.
CREATE ROW ACCESS POLICY: This permission is required for ALTR to create Row Access Policies in Snowflake.
GRANT IMPORTED PRIVILEGES: If you opt to allow ALTR to access your database’s query history to generate Data Usage Analytics for all queries, ALTR requires this permission to access Snowflake’s Access History Views.
When signing up for ALTR though Snowflake Partner Connect, ALTR automatically loads a stored procedure into PC_ALTR_DB that can be used to configure PC_ALTR_ROLE. During the onboarding process, you have the option to:
Note: ALTR uses ACCOUNTADMIN only to run the stored procedure and configure PC_ALTR_ROLE. Any further actions taken by ALTR’s service user are done using PC_ALTR_ROLE unless you specify otherwise.
After onboarding, there are many reasons why you may need to re-permission your Service User. These include:
In order to re-permission your service user, run the two scripts below as ACCOUNTADMIN in Snowflake. If your ALTR account was created via altr.com instead of Snowflake Partner Connect, run the second command as FALSE instead of TRUE so that it affects ALTR_SERVICE_ROLE instead of PC_ALTR_ROLE. Note: if you have many databases in your Snowflake account, this script may significant time to run.