In a previous blog post Andrew Hindle discussed the difference between Data Access Filtering and Dynamic Data Masking. This blog post investigates the advantages of combining these two approaches. As of version 1.2, the Axiomatics Data Access Filter for Multiple Databases (ADAF MD) introduces masking capabilities. At the core, Data Access Filtering is an application of Attribute Based Access Control (ABAC) based on the expressiveness of the XACML language. The dynamic data masking capabilities in ADAF MD make use of the same XACML-powered authorization engine, which means data masking in this context can be made subject to complex business rules expressed in the XACML language. The expressiveness of this policy language enables the implementation complex business rules that are far more advanced than the relatively simple rules that data masking solutions typically are based on so far.

This post explains how to perform a custom data masking on a column using the Axiomatics Data Access Filter for Multiple Databases.

Data masking implies hiding confidential data such as credit card numbers, emails, social security numbers or other privacy sensitive information, etc.

Data masking can be defined using a <maskValue> element in the configuration of the system. The mask value element principally offers three options:

  • If you leave it undefined, data masking means redacting the actual cell value. Whatever value is found in the database will be left out in the result set and replaced by a NULL value.
  • You can enter a constant value which will be used instead of the cell value in all the records affected by the filter condition. The constant must match the datatype of the table column.
  • You can call any function that would be valid to use inside a SELECT statement of the SQL dialect applicable to your database.

Data masking can thus be done not only by redacting the whole value but also by masking out a portion of the data via a function call. This blog post will use a simple example to show how it can be done. We use a function call to apply data masking to a column that holds email addresses. The part preceding the ‘@’ in the email address will be masked with ‘****’. In this example we are using a simple SQL function to achieve data masking to hide part of the email address.

In the filter configuration we add a protected DB object (column).

<dbObject column="EMAIL" mask="true" schema="SCOTT" table="EMPLOYEE">
<maskValue>CONCAT('****',SUBSTR(EMAIL,INSTR(EMAIL,'@')))</maskValue>
</dbObject>

The function called in the <maskValue> element masks the column ‘EMAIL’ when it is selected from the table ‘EMPLOYEE’. ADAF MD makes sure that only the part after the ‘@’ will be displayed to the end user. This SQL statement sent from a client application to the database is intercepted by ADAF MD:

SELECT
NAME,
EMAIL,
DEPARTMENT
FROM SCOTT.EMPLOYEE

If you execute the SQL statement without masking the result obtained is:

NAME EMAIL DEPARTMENT
Ella ella@broker.com Sales
Julia julia@claimsmng.com Claims
Oliver oliver@broker.com Sales
Hugo hugo@claimsmanager.com Claims
Charlie charlie@claimsmanager.com Claims

ADAF MD alters the SQL statement on the fly to make it retrieve masked email addresses based on an applicable policy condition. When dynamic data masking is applied the returned data set looks like this:

NAME EMAIL DEPARTMENT
Ella ****@broker.com Sales
Julia ****@claimsmng.com Claims
Oliver ****@broker.com Sales
Hugo ****@claimsmanager.com Claims
Charlie ****@claimsmanager.com Claims

An interesting effect of the combination of dynamic data masking and data access filtering is that the masking conditions are controlled via the XACML policies of the data access filter. The policy in our example above is somewhat primitive. It basically states that “if the accessed column includes an email address, mask out the name part”. The authorization decision is made solely on what type of data the result set contains. It is an example of the simplest form of access control rule that only takes properties of the information object into account but disregards the properties of the user, the action being performed on the object, and the context of the access request.

Real-world business rules are typically much more complex. In our example above one could expect a business rule stating that

  1. Users can read and update their own email addresses.
  2. Managers can view the email addresses of staff members in their own departments only. Email addresses of users in other departments must be masked.

With attribute-based access control this can easily be achieved with a quick policy change in ADAF MD. Let’s assume the manager of the Sales department lists the above table after we have done the policy change. This is the result set the sales manager then retrieves:

NAME EMAIL DEPARTMENT
Ella ella@broker.com Sales
Julia ****@claimsmng.com Claims
Oliver hugo@broker.com Sales
Hugo ****@claimsmanager.com Claims
Charlie ****@claimsmanager.com Claims

As we can see, dynamic data masking is now conditionally applied, aligned with underlying XACML authorization policies. Attribute based access control (ABAC) based on the XACML standard delivers far greater flexibility than the more content-oriented and simple authorization rules of earlier generations of dynamic data masking.

In future blogs we will investigate further possibilities, for instance through policy-driven cell-level encryption or other types of advanced function calls in the <maskValue> element. Stay tuned.



Leave a Reply

Your email address will not be published. Required fields are marked *