Skip to main content

Tokenization Access Policies

ALTR's tokenization access policies enable you to use ALTR's access control engine to dictate which users are able to detokenize sensitive data.

Adding an extra layer of security before enabling certain roles to access your tokenized data and then applying an ALTR detokenization policy is beneficial to your data governance strategy. While tokenization is the process of converting your sensitive data with "substitutes" that are "tokens" the human eye can’t read or figure out, detokenization is the opposite process. Detokenization functions by removing non-sensitive token identifiers for your Snowflake columns and object tags and converting the them back to the original value where there are no token identifiers. When you use ALTR to apply a detokenization policy for a Snowflake column or object tag, the original value is returned to authorized users.

For example, an application can require a person's date of birth to generate monthly patient invoices for recurring medical services (such as ongoing treatments to treat an illness) that their medical provider has rendered. Detokenized sensitive data must be read under strict security controls.

Prerequisites

To apply an ALTR detokenization policy for your Snowflake column or object tag, ensure you have

  • An ALTR account with access to tokenization.

  • A Snowflake column of data that has been tokenized or a  tag  associated with tokenized data.

  • A data source that's connected to ALTR.

  • Manually labeled (in the ALTR UI or the API) the columns or object tags that contain tokens.

Detokenization Policy Objective and Key Benefits

While tokenization replaces sensitive data with a substitute (that is, a token) to provide an extra layer of protection, detokenization is the reverse process. The objective of using ALTR to apply a detokenization policy is for you to control who can access the original values of your sensitive data versus the tokenized ones.

If your data has already been tokenized via an ETL process through Matillion, then by default, you only have access to tokenized columns and tags through ALTR; however, if you choose to apply a masking policy option, then you can select which roles can access the original detokenized values. A "Masked" policy option enables you to select the roles that can access masked detokenized values.

In short, by applying our detokenization policy you can

  • Leverage your secure tokenized data in Snowflake by setting a policy of specific roles that can see the underlying values.

  • Elevate your security strategy to mitigate data breaches and other risks.

What to Consider Before Applying the Policy

Before you apply a detokenization policy, keep the following considerations in mind:

  • Make sure the Tokenized check box is selected on the tokenized column/tag.

  • Be very careful to assign this policy to the role(s) that should be able to access the original value.

  • If you've failed to label the column/tag as containing tokens (and only selected the "No Mask" option), then you'll only see the token values.

Note

ALTR recommends that you apply separate policies for tokenized and non-tokenized data.

Considerations Specifically for Tag-Based Detokenizations

The following considerations are specifically for tag-based detokenization:

  • Only columns that are VARCHAR and minimum length of 71 characters are supported.

  • Ensure tags that are labeled as "tokenized" actually contain tokens.

Example

Let's say an admin logs into ALTR and performs the following actions on tags where only the email tag value contains tokens:

  • connects a tag (indicated as tokenized) name PII with the values email, name, address

  • puts a lock/policy with no mask on the email tag value (only admin can view detokenized no-mask values)

  • puts a lock/policy with no mask on the name tag value 

This scenario introduces a few risks:

  • If a non-admin user without proper privileges tries to query email, they will see tokens.

  • If a non-admin user without proper privileges tries to query name, they will see the original value (as opposed to NULLs in a governed tag that is not indicated as tokenized))

Likewise, if there's an active alert for user X and user X tries to

  • query email, they will see tokens.

  • query name, they will see the original value (as opposed to NULLs in a governed tag).

Configure Columns or Tags for Role-Based Detokenization

To control access to detokenized data using ALTR, the columns or tags must be previously tokenized through our API or third-party integration.

To configure columns or tags for role-based detokenization:

  1. Connect a column/tag to ALTR and select the "Tokenized" check box. Refer to Connecting Columns / Connecting Tags for more information.

  2. Run the following commands to grant access to the request and response translator functions in Snowflake to the PUBLIC role. Optionally, update the commands to grant access only the roles that will query the data. These functions are called when the queries are run against policies.

    1. Tags:

      • GRANT USAGE ON FUNCTION "ALTR_DSAAS_DB"."ALTR_DSAAS_<org_id_capitalized_and_underscores>"."ALTR_DETOKENIZE_TAG_REQUEST_TRANSLATOR"(OBJECT) TO ROLE PUBLIC;

      • GRANT USAGE ON FUNCTION "ALTR_DSAAS_DB"."ALTR_DSAAS_<org_id_capitalized_and_underscores>"."ALTR_DETOKENIZE_TAG_RESPONSE_TRANSLATOR"(OBJECT) TO ROLE PUBLIC;

      Note

      To obtain the schema for tags, run SHOW SCHEMAS IN DATABASE ALTR_DSAAS_DB.

      If you have only one ALTR tenant, there is one schema called ALTR_DSAAS_{orgid}.

      If you have multiple ALTR tenants, use the schema that corresponds to the org ID for the organization you used to tokenize the data.

    2. Columns:

      • GRANT USAGE ON FUNCTION "<database>"."ALTR_DSAAS".ALTR_DETOKENIZE_RESPONSE_TRANSLATOR(OBJECT) TO ROLE PUBLIC;

      • GRANT USAGE ON FUNCTION "<databse>"."ALTR_DSAAS".ALTR_DETOKENIZE_REQUEST_TRANSLATOR(OBJECT) TO ROLE PUBLIC;

  3. Apply access policies to the tokenized column/tag. By default, queries against policies only return tokens. Creating policies with the "No Mask" option returns the original value for the specified roles. Creating policies with masking options returns masked detokenized data for the specified roles.

In this section: