ALTR Detokenization Policy for Snowflake Columns

If you want to add an extra layer of security before you enable certain roles to access your tokenized data, then applying an ALTR Detokenization Policy would be a beneficial part of 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 converting the columns back to its original state where there are no token identifiers. When you use ALTR to apply a Detokenization Policy for a Snowflake column, then the original column data 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, you will need to:

• Have a Snowflake column of data that has previously been tokenized
• Have a data source that's connected to ALTR
• Have the right permission level to set policy to detokenize the column
• Manually label (in the ALTR UI) OR API which column(s) are tokenized
• Be an Enterprise Plus tier plan subscriber

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, as described earlier, detokenization is the reverse process. The objective of using ALTR to apply a Detokenization Policy is for you to control who can access the raw 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 will only have access to tokenized columns through ALTR; however, if you choose to apply a 'No Mask' policy option, then you can select which roles can access the raw detokenized values. A 'Masked' policy option will enable you to select which roles 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 your data is tokens and is labeled in ALTR
• Be very careful to assign this policy to the right user role
• If you've failed to label the column as tokens (and only selected the 'no masking' option), then you'll only see the token values

Recommendation

We recommend that you apply policy against one column at a time for easier manageability.

Configure Columns to Detokenize Them

To begin this procedure, first the columns must already be tokenized through our API or another provider. In addition, you must have the appropriate permission (role) that has granted you the 'unmask option' to detokenize and read the raw value of the original data. Once both of these prerequisites are met, then you can proceed with the steps below.

1. Tell ALTR which columns has tokens in it. ALTR has no way to identify which of your columns has tokens in Snowflake unless you've labeled the columns as 'tokenized'. See figure 2.
2. Next, create a 'No Mask' policy on the tokenized column. The combination of a column being labeled as 'Tokenized', and with a 'no mask' governance policy is sufficient to enable detokenization on Snowflake columns.

‍

Frequently Asked Questions

Ease of Use

Question: Is the policy complex to apply or remove?

Answer: Setting a 'No Mask' option on any column is easy as long as the column is connected to ALTR. In addition, if the data has already been tokenized then be sure to label the column as tokenized.

Considerations to Keep in Mind

Question: Are there security or compliance risks to consider before applying this policy?

Answer: There are only security and compliance risks if the policy is applied incorrectly. Be careful about which roles you assign this policy to.

Policy Availability Once its Applied

Question: How long does it take for the policy to go into effect after I've applied it? Does it happen immediately?

Answer: It's an asynchronous process and could take up to a few minutes for the policy to take effect.

Question: How will I know that the policy has been applied successfully?

Answer: A confirmation message will display.

‍