Database Subsetting, Masking, Security

Data masking concepts


There are two types of data masking approaches generally termed "Static" and "Dynamic" data masking.  We have solutions for both since they each have their own place in your data masking toolbox.


Static data masking requires you to clone the production database and then address it with a series of rules which will change the data, usually with an update statement, replacing it with like-for-like data content.  This seems quite simple and surely anyone can do this with an update statement?

The answer is "No" because it's seldom the case that this is all you need to do.  More often than not you have to look at the impact of these changes within the row, within the table and between tables.  It doesn't stop there.....

You may also need to synchronise these changes between databases/schemas and, indeed, between instances.  Using framework tools like Data Masker lets you evolve the data masking approach in such a way that data is changed and synchronised in a structured manner.

Dynamic data masking is an approach where calls to the database are intercepted and the columns being queried are compared with a matrix based upon the user and the column(s) being requested.  A "mask" is then overlaid upon the query result, transparent to the presentation layer, so that the user only sees the mask definition - for instance a credit card may look like '5940-1234-5678-****'.  

Intercepting database calls means that you can also audit all database requests and, indeed, block any action against the database.  This helps ensure that only authorised users perform specific management tasks as well as protecting agianst SQL injections.