Dynamic data masking. Static masking is not enough

You've probably already heard of Dynamic data masking, although if not, it's only a matter of time before you use it.

By masking the data, organizations prevent unauthorized users from viewing sensitive data while protecting information by following the law. Data masking technology provides data security by replacing sensitive information with content that is not confidential, but doing it in such a way that the data copy looks and acts the same as the original.

Data can be masked statically or dynamically. But in this article we want to show why static masking is not enough. For them, first we are going to see some problems that we can find with static masking and in this way we will see more clearly why we need Dynamic data masking.

Some concerns about static masking

With static data masking, most administrators, database developers and testers never touch the production database. All your work is done on the basis of simulated test data. This provides a level of protection and is required for many environments. But nevertheless, not a complete solution, as it does not protect against authorized users to view and extract unauthorized information.

• Static solutions really require extraction of all data before it is masked, namely, the data actually leaves the database without masking. One of the most disturbing facts about static data masking is the ETL standard (extraction, transformation and loading). In other words, the information in the database is extracted as is from the database and only transformed afterwards. You must hope or trust that the masking solution has successfully removed the actual data and that the static masking solution is running on a secure platform that is not compromised..

• The active database is not protected from those who have access permissions to the database. There are always some administrators, QA, developers and others with access to the real live database. These personnel can access the actual data records, that are not masked.

• In many organizations where a test database is not required for other purposes, it is a waste to have a full test database that is a copy of the entire production database, minus the identifying information. We have more cost in hardware and maintenance of the second system.

• Activities must be done twice: once in the test system and then deployed in the live system. There is no guarantee that it will work in the production system and, if it does not work, developers or database administrators will need to debug the system and will need to do it on the test system to bring it back to production o They are given permission to view the actual live data to see what happens.

Dynamic data masking to protect live systems

Dynamic data masking is designed to protect data in real time on production systems and on systems “not alive”. Dynamic data masking masks all sensitive data accessed, and it does it in real time, so that sensitive information never leaves the database. When authorized personnel look at the actual data in the production database, data is masked or unreadable, so the actual data is not disclosed. Thus, in no case is anyone exposed to private data through direct access to the real database.

Using a reverse proxy, the Dynamic data masking investigates each query before it reaches the database server. If the query involves the processing of sensitive data, data is masked on the database server before it reaches the application or person requesting it. This way, data is fully functional for development or testing purposes, but they are not shown to unauthorized users.

Dynamic data masking allows all authorized persons to perform any type of action on the database without seeing the actual data. Of course, the activities that are supposed to show the data show the data, but only to authorized personnel using the correct access. By using advanced data masking rules, it is possible to identify whether a particular field should be shown to a particular person and under what circumstances. For instance, someone can access a hospital record at the same time, but only from a particular terminal, or an IP address, using a specific application and with specific credentials. Accessing that same record using a direct database command would not work or could result in masked data.