Custom Masking and Extensibility Functions

This page provides information about what Custom Masking and Extensibility Functions are, an explanation of how they function,  how to use them, and example cases.

Customized Extensibility Functions can give you even greater capabilities to secure sensitive data for your business needs.

Prerequisites

To begin creating custom extensibility functions, you must meet the following prerequisites:

• You will need to be able to to write custom code for Snowflake
• You will need at least one connected database

What are Extensibility Functions for Custom Masking?

Snowflake Extension Functions are functions that you can customize and define which ALTR inserts into Snowflake and invokes in our Dynamic Data Masking Policies during column access governance. By default, these functions take in the governance decision from ALTR (such as what mask should be applied to a column for a query) and  return logic to the masking policy.

How do Custom Extensibility Functions Work?

You can build custom logic in your user-defined functions (UDF) to modify the functionality of your masking policies, such as calling encryption functions, building custom masks, or practically anything.

When connecting the first column for a database to ALTR, then ALTR creates a UDF named ALTR_HOOK_POST in the ALTR_DSAAS schema. Whenever masking policies are made for columns, they will reference this ALTR_HOOK_POST function. These UDFs are database-specific; a new function is made for every database.

ALTR_HOOK_POST takes in a variety of parameters, including the schema information of the columns and what's returned by ALTR. By default, this ALTR_HOOK_POST function returns NULL and can manually update this UDF in Snowflake to customize the behavior of the masking policy based on ALTR’s output. This can be used to perform functions like customizing masking policies, invoking other functions such as encryption services, or adding additional custom rules to when to govern.

IMPORTANT TO KNOW: Modifying this function inherently changes the behavior of data governance in Snowflake in an undefined way. ALTR does not manage or have any guarantees about the behavior of custom functions.

When you remove a database from ALTR, we remove ALTR_HOOK_POST along with all of our other client-side objects. Apart from creating the base USD and removed from ALTR when the database is removed, ALTR does not touch or edit ALTR_HOOK_POST.

How to Use the ALTR Post-Hook Function

To use an extension function, you must replace the default NULL UDF and replace it with your own custom code. This must be done in the ALTR_DSAAS schema for the relevant database. If you have more than one database, then you must perform this operation for each database.

Post-Hook Parameters

• SCHEM - The name of the schema that the column is contained in
• TBL - The name of the table that the column is contained in
• COL - The name of the column
• ALTR_DISPOSITION - A signal from ALTR of level of access granted on the column based on the policy set in
• ALTRVAL - The plain-text value in the column

ALTR Dispositions

ALTR uses single-letters, text combinations, or characters to indicate different dispositions. These are the possible values of the ALTR_Disposition parameter.

• A - Allow access to plain text data (Role has "No Mask" in Lock)
• N - Replace the value with NULLs (Role is not in a Lock)
• S - Return a static mask according to ALTR’s static masking behavior (Role has "Constant Mask" in Lock)* -return *s for the length of original value (Role has "Full Mask" in a Lock)
• 4 - Return the last 4 characters of the value and replaces characters before that with *s (Role has "Show Last Four" in a Lock)
• @ - Returns the domain name of an email address but replaces anything before with *s (Role has "Email Mask" in a lock)
• TROLE_LIMIT - Throws an error if the number of available roles to the user is above the amount that ALTR will process
• D - A catch-all used if ALTR does not return any of the above
• DB - The name of the database that the column is contained in

Examples of Post-Hook Functions

We've provided a few examples of post-hook functions that can override masking policies.

Example 1.

When ALTR indicates the ALTR_DISPOSITION is a '4', (which means the default behavior is to mask everything but the last 4 characters of the value), then this behavior of the ALTR_POST_HOOK function will mask everything but the last 6 characters of the value

‍

Example 2.

When ALTR indicates the ALTR_DISPOSITION is a 'A' (which means the default behavior is to show the value in plain text), then this behavior of the ALTR_POST_HOOK function will call an external function to decrypt the values instead. ALTR does not create this DECRYPT external function. This must be managed by you.

‍

Example 3.

This shows a user-defined function that contains masking policy behavior. Next, the ALTR_POST_HOOK function calls that UDF. The purpose of this is so you don't have to define masking policy behavior on every single database. You just have to create a function that contains the masking policy behavior and then call it from the ALTR_POST_HOOK function.

In this masking policy, when ALTR indicates the ALTR_DISPOSITION is a '4', ( which means the default behavior is to mask everything but the last 4 characters of the value), then this behavior of the ALTR_POST_HOOK function will mask everything but the last 6 characters of the value.

Frequently Asked Questions

Each of the FAQs are listed by topics.

CUSTOM CODE MAINTENANCE

Question: Will ALTR maintain all custom masking extensibility functions that I write code for?

Answer: You will have to maintain this for your business.
‍

Question: How can I reset the function so that it will use ALTR's default behavior?

Answer: Here's the code that you can write to do that.

TOKENIZATION

Question: Can custom masking and extensibility functions also be used for tokenization?

Answer: Yes

MULTIPLE DATABASES

Question: If I have more than one database, then do I have to create custom masking and extensibility functions for each one?

Answer: Yes