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
Views
Thresholds
Row Access Policy
Audit Logs
Settings
Tokenization
Tag-Based Data Masking
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 Tokenization
Open-Source Integrations
This Quick Start Guide is written for Data Scientists, System Administrators, Data Engineers, and other individuals in Data Governance roles.
It is written to provide step-by-step instructions to help you get started with using ALTR. The objective of this guide is to get you up and running quickly to help you begin protecting your sensitive Snowflake data.
In order for ALTR to connect to Snowflake, two prerequisites must be met. These include:
ALTR participates in Snowflake’s Partner Connect Ecosystem, enabling users to get up and running as easily as possible. Snowflake Partner Connect can be accessed by ACCOUNTADMIN users in Snowflake through Snowflake’s Classic Console and the new Snowsight UI.
When you sign up for ALTR through Snowflake Partner Connect, Snowflake will auto-generate a Snowflake Warehouse and Service User for ALTR. ALTR uses these to communicate with your Snowflake account. Snowflake also asks you to select the databases you want to grant USAGE to for ALTR. You can ignore this step. We help you configure these permissions when onboarding onto ALTR.
After clicking Connect, ALTR will send you an email to create your ALTR account, set your ALTR password, and start onboarding. ALTR uses the email address associated with your Snowflake account as your username and as the default method for two-factor authentication when logging into our platform.
Once you set your password, you will be greeted by ALTR’s onboarding wizard. The rest of this document will cover how to finalize configuration of your ALTR account, connect your Snowflake databases, and start governing data.
This section explains the process for you to log into ALTR and other details to guide you with the log in process.
Currently, all users are required to log into ALTR with a:
The username and organization ID listed above are the two newly-established tenant-based login requirements for our security control measures.
The reason for this new 'tenant-based' login change is to enable us to align with the System for Cross-Identity Management (SCIM) standard and also integrate Single Sign-On (SSO) to authenticate each of our users.
As stated above, you currently need to provide your email address (as the username), password, and a six-digit two-factor (2FA) authentication code to log into ALTR. However, soon a 'username' will be required as a login instead of an email address.
All usernames must be unique within each organization and is how ALTR identifies users.
NOTES ABOUT USERNAMES:
If you have forgotten your user name (or Organization ID which is explained below) then ALTR will prompt you for your email address. If the email address exists in that ALTR environment, then ALTR will send an email that includes the organization ID and username for every account associated with that email address.
NOTE: Usernames can not be changed in ALTR. To update your email address, you will need to email ALTR support.
PASSWORDS
All passwords should be strong and meet the following requirements:
If you need to update it, this can be done on the ALTR Login or in Settings page shown in the screenshot below.
All existing multi-organization admins will be given separate logins for every organization that you have access to.
The Forgot Organization/ Username flow will email Organization and Username information for every single account associated to an admin. So, if your email address is associated with more than one account in ALTR, then this email will include the organization ID and username for each one.
TWO-FACTOR AUTHENTICATION (2FA)
2FA codes are available via email, SMS, or an Authentication App. 2FA settings can be managed within the Settings pages in ALTR. See the screenshot below.
Note: Although our Time-based One-Time Password (TOTP) might work with other apps, it has been tested for Google Authenticator, Microsoft Authentication App, Okta, and Authy.
About Organization IDs
An 'Organization' is a unique tenant (or account) in ALTR. An 'Organization ID' is a Universally Unique Identifier (UUID) that refers to an organization. Each organization will have its own specific subdomain to ALTR that will be based on your organization ID.
Example of how your Organization ID subdomain will appear: {orgid}.live.altrnet.com/login
If you already have an organization-specific login page for ALTR then you will not need to re-enter your organization information; however, if you do not and navigate to our 'default' ALTR Login page at live.altrnet.com/login, then you will be prompted to enter your organization ID as shown in the screenshot above. Once that occurs, then you will be redirected to the Login page for your specific organization.
If you have forgotten your organization ID or user name, then ALTR will prompt you for your email address. If the email address exists in that ALTR environment, then ALTR will send an email that includes the organization ID and username for every account associated with that email address. See the screenshots below.
NOTE: You can bookmark your organization-specific ALTR subdomain in your browser to avoid having to manually enter your organization ID each time that you log in to ALTR.
Single Sign-On is an authentication service that will enable you to access ALTR with one set of login credentials. For details about configuring SSO for OKTA and Azure Active Directory, read the guides that will walk you through the steps.
Configuring SSO for Okta
See the steps to configure SSO for Okta.
Configuring SSO for Azure AD
See the steps to configure SSO for Azure
SCIM is an open specification to manage identities across a wide number of software applications by easily creating, editing and managing accounts through a single IdP such as Okta. Our first release of SCIM is tested to work with Okta. We will support Azure Active Directory (AD) in the future. For details about enabling SCIM for Okta, read the guide that will walk you through the steps.
If you have completed all activity and are ready to log out, then click on the Logout icon located in the top right corner of the screen.
NOTE: If no activity is detected after 15 minutes, then the system will automatically log you out.
The first step during onboarding is to grant ALTR’s service user access to create and enforce governance policies. Two options are available: an express configuration where you execute one line of code and ALTR permissions itself, and a manual configuration where you create an execute a Stored Procedure to grant specific permissions to ALTR.
In 'Express Configuration”' you grant ALTR’s service user ACCOUNTADMIN permissions and ALTR uses ACCOUNTADMIN to grant itself all of the permissions it requires to create and enforce governance policies. ALTR only uses ACCOUNTADMIN to permission PC_ALTR_ROLE during this step of onboarding; all other actions are performed as PC_ALTR_ROLE. If you are uncomfortable granting ALTR ACCOUNTADMIN permissions to your Snowflake account, then use the Manual Configuration option.
In Manual Configuration, you manually execute grants to PC_ALTR_ROLE required for ALTR to create and enforce governance policies across all of your databases in Snowflake. To make the process easy, ALTR provides a Stored Procedure that automates these permissions. For a list of these permissions and what ALTR uses them for, read the details.
If you prefer to limit ALTR’s access to particular databases or have questions about particular permissions, then reach out to support@altr.com and we are happy to help you configure your service user.
Not comfortable connecting your Snowflake account right away? Click Request access to a sample Snowflake account and we’ll work with you to get a sandbox Snowflake Account spun up and connected.
After competing either service user setup, ALTR will reach out to Snowflake and run a test to ensure that PC_ALTR_ROLE has the correct permissions.
After you successfully configure your service user, then our Free Tier offering will allow you to connect ONE database to ALTR. Connecting a database is as simple as selecting it from the dropdown and clicking Add Databases.
After you've done this, then ALTR will reach out to Snowflake and make the necessary connections to create and enforce data governance. For more information on what exactly ALTR creates when connecting to Snowflake databases, read the details. Once your database is connected, then you can continue to connect columns to ALTR for governance and create governance policies on those columns.
Before creating governance policies, you need to connect columns to ALTR. ALTR uses Snowflake’s Dynamic Data Masking Policies to govern data in Snowflake, and connecting columns to ALTR creates those Dynamic Data Masking Policies.
Columns can be connected on the 'Data Management' page. To connect a column, click Add New.
This opens the form where you can specify a column to connect, as well as a 'Column Name' which is the label ALTR will use for that column in our UI. Complete this process for each column you want to include in governance policies.
Don’t want to create governance policies per column? ALTR enables creation of Column Access Policies in bulk through the use of Data Tags, which is an Enterprise feature. Upgrade to Enterprise, or reach out to support@altr.com, to learn more.
Once columns are connected to ALTR, they will become available when creating Column Access Policies. Connecting columns in ALTR will also enable all queries against that column to be monitored in ALTR’s Query Log.
Column Access Policies enable users to control which Snowflake roles can access which columns. Column access policies can be configured to completely block access to non-permissioned roles, where a column will be NULLed, as well with Masking Policies, where the column values are partially or fully replaced with substitute values. More information on masking policies can be found here.
To create Column Access Policies, navigate to the Column Access Policies Tab under the 'Locks' page. From here, you can define how particular Snowflake roles can access particular columns. There are four aspects to each Column Access Policy:
If a User Group is not included in a Column Access Policy, any attempt to query that column will result in NULL values for the affected columns. If you create conflicting Column Access Policies - where there are multiple different masks defined for a particular role, ALTR will resolve the conflict by enforcing the most permissive policy.
Once Column Access Policies are defined your data is governed. Feel free to explore querying the affected columns in Snowflake with various roles. Now that you’re onboarded to ALTR, check out our other features such as Data Usage Analytics, Data Classification, and the Query Log.
If you’d like to access any of our Enterprise level governance and security tools, such as Tag-Based Column Access Policies, Row-Access Policies, or Tokenization, reach out to support@altr.com.