Enhance Data Protection in Dataverse with Secured Masking Rules

Have you heard of column level security in Dataverse? This feature has been around for a long time, and it allows makers to control access down to the column. Imagine you’re building an app in Dataverse. BUT, you’ve got a handful of columns with super-sensitive data, these could be social security numbers, salaries, or other private details. Most likely you don’t want any user to have access to the sensitive data in those fields. This is where column-level security works really well. The problem here is that the access levels with column level security is for ALL the data in the column. For example if there is a security number stored in a column with column-level security there are only 3 access levels available: read, update and create. With read access users can either read ALL the data that is stored in that column, or they can’t read it. For example maybe you need users to see the last 4 digits of a social security number, so they can confirm it is the right person they are speaking to, this is not something that is attainable with the legacy column security. Knowing all of this, wouldn’t it be great to have data masking rules that are a bit more flexible? I’m here to tell you that this feature is now in preview and I’ll explain all about how these new rules work so you can try them out immediately!

How does it work?

I would recommend to only try this out in a non-production environment, as stated above, this is a preview feature, meaning it is not meant for production. Trying preview features before they are generally available helps you get ready, plus you can provide Microsoft with feedback on the feature(s). Let me first explain how data masking rules work, once enabled. Once a maker has created one (or multiple) masking rules, they can apply these to one or multiple Dataverse columns. (I will go through all the steps on how to do this later in this article.) Keep in mind that unlike the legacy column-level security, masking rules can only be applied to number, single-line and multi-line text columns. Just like with the legacy column level security, the permissions for who can read what is in the column that has the masking rule is managed in the column-level security profile. Admins can configure in the masking rule which character replaces the text/number they want to hide. For example they can use * or # or any other character. Users who don’t have access to read a column that has a masking rule, will see the character the admin selected in the masking rule to hide the data in the column. This is all configured per individual masking rule. If a person does have access to a column with a masking rule, they will see an icon shaped like an eye next to the ‘masked’ column.

Create a new masking rule

The system already has a few masking rules available out of the box, which you can start using immediately. You can review them by opening the default solution and searching for ‘Securing Masking Rule’ under ‘objects’ in the solution. For this example I am going to create a masking rule for email addresses, where I want to hide the characters in the email address that appear before the @ sign. If there is other data in the column, I want to show it. So for example if someone enters ‘Here is the the email address: dian@gmail.com‘, users that have read access to the column (not to the masking) will see ‘Here is the email address: ****@gmail.com’. I like to use solutions when creating new objects in Dataverse, so I create a new solution before doing anything. You can do this by navigating to make.powerapps.com and making sure you’re in the right environment. Click on ‘Solutions’ on the left and click the ‘+New’ button on the command bar. I called my solution ‘Masking Rules’ and clicked ‘Save’ after selecting a publisher. To create a new masking rule, click on ‘+New’ and select ‘Security’ > ‘Secured masking rule’. This will open the secure masking rule form in a new tab. For the name field I enter ‘rsm_email_address_masking’. In the display field I enter ‘Masking Email Address’. In the description I explain how this rule works. I used ChatGPT to help generate a regular expression, which I entered in the regular expression field:

[A-Za-z0-9._%+-](?=[A-Za-z0-9._%+-]*@[A-Za-z0-9.-]+\.[A-Za-z]{2,})

This expression part of the email address before the @-sign. In the masked character field I enter ‘*’. This is the character the users will see. On the right side of the screen I enter test data, which in this case is a random email address. I do the same in the ‘Enter Rich Text Test Data’ field. The two fields below show how the data will look once the masking rule has been applied. You will need to save the masking rule in order to see data being populated in those fields.

Adding a masking rule to a column

Masking rules can only be added to columns that have column security enabled. To do this, you’ll need to select the table for which column you want to add the masking rule to. In this example I am going to add this to the contact table so from within the solution I click on the ‘Add existing’ button and click ‘Table’ and search for the ‘contact’ table’. I then click on ‘Edit Objects’. Since I want the system to mask any email address that is entered in the ‘Description’ column, I select this column and click ‘Add’. Once the column has been added to the solution, I click on the column to open it and select ‘Advanced Options’ on the side pane that opens. Under ‘General’ I click the checkbox that reads ‘Enable column security’ and select the previously created masking rule in the column below the checkbox, then I click ‘Save’. Don’t forget to publish your changes!

Configure permissions

Since we want certain users to have access to the data that is being masked by the rule we created earlier, we have to create a (or edit an existing) column security profile. For this example I will create a new column security profile. From within my solution I click on ‘+New’ > Security > Column Security Profile. I call it ‘Email Masked Profile’ and click ‘Save’ to save the profile. Under ‘column permissions’ you’ll see a list of fields that are enabled for column security. I see the ‘Description’ column of the contact table that I just enabled for column security. I select the column and click ‘Edit’ on the command bar. The permissions pane opens on the right side of the screen. This part is very important! You’ll notice that there are permissions we can set for ‘Read’, ‘Read Unmasked’, Update and Create. If you are familiar with column security profiles, then you should know what read, update and create means. The ‘Read’ permission allows users to read the data in the column. However, if there is a data masking rule active on the column and the ‘Read unmasked’ is set to ‘Not allowed’, they will not be able to read any masked data. In this example, I had a masking rule that would only mask the part of the email address that is on the left side of the @ sign, any other data in the field will be visible IF the user has ‘Read’ rights for the column. If they don’t have ‘Read’ rights on the column, they will not be able to see any data in the field and if they have ‘Read’ rights and ‘Read Unmasked’ rights, they will be able to click on the ‘eye’ icon next to the column to unmask the data. Below is the example of what the user will see with the assigned privileges. NOTE: At the time that this article was published, the read icon (shown on the image below on the right) is only visible to users with the System Administrator role! Microsoft is working on enabling this for non-admin users in a future release.

When you configure the ‘Read Unmasked’ privilege, you have the option to set it to ‘Read Unmasked – One record’ or to set it to ‘Read Unmasked – All records’. Microsoft states on the learn site that ‘this setting is highly privileged. Read unmasked should only be allowed for backend services that require unmasked values for backend processing.’ I tried to test this functionality by seeing if I was able to view the description field for multiple contact records in a list, but there is no button to unmask the data for multiple records, so it doesn’t seem to work that way.

Auditing

One thing I really like is that the audit tables honor these masking settings as well! So if someone changes the value in a column and someone without masking viewing privileges views the audit history for that column, they will see the masked values. On top of that, if someone views masked data (removing the mask by clicking on the eye icon) that action is also tracked in the auditing data!

The only issue that I found when I was testing this, is that if you access the audit history from within a form (in my case the contact form) the masking is not honored. When I navigate to ‘related’ on the contact form and select ‘Audit’, I was able to view all the data in the ‘Description’ column, even though my user account did not have a column security profile with read access for masked data. Keep in mind this is still a preview feature which is why we still see some things that are not working the way they should (yet). I did let Microsoft know about this in the hope this will be fixed. Once all the bugs are worked out, I think this feature has a lot of potential helping secure data even better! I hope you enjoyed this article! Be sure to check in again next week or subscribe here to never miss another post!