In the past we’ve had Dynamic Data Masking where you could set up a policy such that when a certain user would query a field that may have sensitive information; you could mask the underlying data with some other characters, such as masking a social security number with a string of x’s.
The key to note is with Dynamic Data Masking, the underlying data does not change but with Static Data Masking, it alters or updates the data in your database. The way it works is you’re creating a copy of your database and then applying updates that modify the data in your database, so it’s quite different from Dynamic Data Masking.
Need of Data Masking
Why you should know the details about static and dynamic data masking explained? Well certainly, this is not something you would apply on your live production databases but let’s say you have a team that needs to do some performance monitoring or test performance improvement on the database. To do this they would need a full copy of the live data with all the latest indexes and stats and you often need your full database to do that.
Fields of Data masking on various sectors
Database administrators are responsible for database security and compliance issues. In a normal workflow, we used to have multiple environments for applications such as Production, Staging, UAT, Dev, and Sandbox. It is a regular task for the DBA to refresh the lower (staging, test, UAT etc.) environments with a backup of the production database backup. Sometimes we need to share the database backup with the external vendors as well.
The database may contain critical information such as Personally Identifiable Information (PII data) such as email address, contact information, national id number etc. We might have other sensitive information such as bank account number, credit card number, CVV etc. which we do not want anyone to access. We need to be compliant with GDPR, PCI, and SOX regulatory compliance as well.
If we restore the database to lower environment, all of the data gets transferred to the lower environment which put our critical data at a risk since we do not have security or encryption enabled at that level. It may be a requirement to mask or shuffle the data prior to a database restore.
Consider the below example, where our production database has sensitive credit card information and we have performed a database restore to dev, UAT and sandbox environment.
Dynamic Data masking
In general, dynamic data masking (DDM) is real-time data masking. It is often compared with another method for data masking, called static data masking, which involves setting up a separate shielded database or a “dummy database” including value-less data at load time.
Dynamic data masking provides solutions for the cases where individuals are working close to the production environment, but should not have access to the original data. For example, contractors and staffers may be trying to troubleshoot or update a production database. It is important that they do not have access to sensitive pieces of information such as individual health data, credit card numbers, etc.
Static Data Masking
As the name suggests, data masking is a method enterprise use to hide data. It protects confidential data points from people without permission to view it. The main purpose of masking data is to guard sensitive information in circumstances where it might be observable to someone without clearance to the data.