ALTR Quickstart - Data Access Control

Prerequisites

What You'll Learn

What You'll Build

Create a sample database

In This Step: We are creating a sample database by copying a small amount of data from Snowflake's shared SNOWFLAKE_SAMPLE_DATA database. We will use this sample database for the rest of this Quickstart.

Create a sample database

-- Use ACCOUNTADMIN role
USE ROLE ACCOUNTADMIN;

-- Create Sample Database
CREATE DATABASE ALTR_GETTING_STARTED_DB;

-- Set DB Context
USE DATABASE ALTR_GETTING_STARTED_DB;

-- Populate sample database from Snowflake's shared sample database. 
-- Usually named: SNOWFLAKE_SAMPLE_DATA
CREATE TABLE SAMPLE_CUSTOMER AS 
    SELECT 
        C_FIRST_NAME,
        C_LAST_NAME,
        C_EMAIL_ADDRESS,
        C_BIRTH_COUNTRY
    FROM SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL.CUSTOMER
    LIMIT 10000;

Note: If you can't access Snowflake's built-in sample data and want to use your own data, go for it! To match this guide we recommend creating a separate database named ALTR_GETTING_STARTED_DB. Populate it with fields from your own dataset — be sure to include columns with PII like email addresses, names, addresses, SSNs, etc.

Setup a new ALTR account

In This Step: We will create an ALTR account and connect it to Snowflake, all from within your browser. ALTR is a SaaS solution that integrates directly with Snowflake — no installation required on your premises. The process starts in Snowflake's Partner Connect portal.

NOTE: If you already have an ALTR account and want to use it instead of creating a new one, skip to Step 4 ALTR Setup for existing accounts

Connect to ALTR via Partner Connect

Set your ALTR Password

Complete the ALTR Setup Wizard

GRANT ROLE ACCOUNTADMIN TO USER "PC_ALTR_USER";

NOTE: After onboarding is complete you can revoke the ACCOUNTADMIN grant from PC_ALTR_USER if desired. Express Configuration is temporary by design.

ALTR Setup for existing accounts

In This Step Only perform this step if you plan to use an ALTR account that existed before running this Quickstart. If you just created a new ALTR account in the previous step, skip to Step 5 Run Data Classification.

Grant ALTR access to the sample database

CALL "PC_ALTR_DB"."PUBLIC"."SETUP_ALTR_SERVICE_ACCOUNT"(TRUE);

NOTE: If the stored procedure returns an error, try calling it again with FALSE:

CALL "PC_ALTR_DB"."PUBLIC"."SETUP_ALTR_SERVICE_ACCOUNT"(FALSE);

Connect ALTR to the Sample Database

NOTE: Free tier ALTR accounts are limited to a single connected database. Disconnect your existing database before connecting this one, or use the database you already have connected (column names may differ from this guide).

Run Data Classification

In This Step ALTR can scan your database and automatically identify columns that contain sensitive data. We call this classification. In this step we will trigger a Google DLP classification scan, which samples your data and sends it to Google's DLP API to detect information types like email addresses, names, and phone numbers.

Start a classification scan

NOTE: ALTR does not send your raw data to Google DLP. Before submission, ALTR scrambles the sample by randomly mixing values across rows and columns, so individual records cannot be reconstructed.

View the classification results

Classification Report Explainer:

• The left panel lists every classifier tag (information type) detected, with a count of how many columns matched.
• Clicking a classifier tag filters the right panel to show the specific Schema, Table, Column, and confidence level for each match.
• Get more information on data classification in ALTR

Connect a Column to ALTR

In This Step Before ALTR can enforce a masking policy on a column, that column must be connected to ALTR. Connecting a column places ALTR in the query stream for any query that references it.

Connect the C_EMAIL_ADDRESS column

Note: To connect a tag instead of an individual column, the process is identical — navigate to the Tags tab and click Add Tag. Tag-based connections allow a single policy to apply to all columns sharing a tag, which is useful for managing large datasets at scale.

Define a Column-Based Access Policy

In This Step We will build a role-based masking policy for the EMAIL_ADDRESS column using ALTR Policies. A single policy can contain multiple rule statements — one per role — so we will define all three masking levels in one place.

Create a Column Policy for EMAIL_ADDRESS

Configure Rule Statements

Policy Explainer

• Any Snowflake role not listed in a rule statement will receive NULL values for this column — ALTR defaults to deny.
• If masking policies conflict across multiple policies on the same column, ALTR applies the most permissive rule.
• Get more information on ALTR Policies

Test Policy in Snowflake

Copy test SQL into a new worksheet

--
-- Grant access to the sample database for our test roles:
--
USE ROLE ACCOUNTADMIN;
USE DATABASE ALTR_GETTING_STARTED_DB;

GRANT SELECT ON TABLE SAMPLE_CUSTOMER TO ROLE ORGADMIN;
GRANT USAGE ON DATABASE ALTR_GETTING_STARTED_DB TO ROLE ORGADMIN;
GRANT USAGE ON SCHEMA PUBLIC TO ROLE ORGADMIN;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE ORGADMIN;

GRANT SELECT ON TABLE SAMPLE_CUSTOMER TO ROLE SYSADMIN;
GRANT USAGE ON DATABASE ALTR_GETTING_STARTED_DB TO ROLE SYSADMIN;
GRANT USAGE ON SCHEMA PUBLIC TO ROLE SYSADMIN;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE SYSADMIN;

GRANT SELECT ON TABLE SAMPLE_CUSTOMER TO ROLE PUBLIC;
GRANT USAGE ON DATABASE ALTR_GETTING_STARTED_DB TO ROLE PUBLIC;
GRANT USAGE ON SCHEMA PUBLIC TO ROLE PUBLIC;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE PUBLIC;

USE WAREHOUSE COMPUTE_WH;

-- *** END OF GRANT ACCESS section ***


--
-- ALTR Policy Tests:
--

-- ORGADMIN sees emails with no masking:
USE ROLE ORGADMIN;
SELECT * FROM SAMPLE_CUSTOMER;

-- SYSADMIN sees the domain only (****@example.com):
USE ROLE SYSADMIN;
SELECT * FROM SAMPLE_CUSTOMER;

-- PUBLIC sees fully masked email values (******):
USE ROLE PUBLIC;
SELECT * FROM SAMPLE_CUSTOMER;

-- Now go into the ALTR portal and edit the policy:
--   - Remove PUBLIC from the Full Mask rule statement
-- Then re-run the query as PUBLIC and observe that policy changes
-- take effect immediately — no Snowflake changes required.

USE ROLE PUBLIC;
SELECT * FROM SAMPLE_CUSTOMER;

-- To see the default deny behavior:
--   - Remove PUBLIC from all rule statements in the policy entirely.
-- Querying as PUBLIC will now return NULL for C_EMAIL_ADDRESS.

USE ROLE PUBLIC;
SELECT * FROM SAMPLE_CUSTOMER;

Run the Grant section

Run the policy tests

Conclusion

What we covered:

Ideas for exploring further:

Getting Help: