How to Use MariaDB Data Masking
Data masking is a security policy used to obfuscate sensitive data (such as client contact information) when your database or any part of it is being accessed. Data masking is helpful when using your database, that includes sensitive data, for training purposes, software testing, or sharing relevant information with various teams.
MariaDB is one such database where you can use data masking to keep personally identifiable information (PII) or otherwise sensitive information secure. But what exactly is data masking, how do you implement it, and why is it important for MariaDB data security?
In this article, you will learn about:
What is MariaDB?
MariaDB is a widely-used relational database management system (or RDBMS). It’s derived from the MySQL platform as a product of a development fork when MySQL was purchased by Oracle in 2009. The original developers wanted to keep their creation open-source and so MariaDB was born.
Since MySQL and MariaDB are sister platforms, the two remain highly compatible, although as time passes, they continue to develop distinct features. Their description as sister platforms is also literal as they’re named for lead developer Michael Widenius’ daughters My and Maria respectively.
MariaDB remains a favorite among database professionals and app developers for its flexibility, storage options, scalability, and wide range of uses including CRM, e-commerce, and inventory and transaction management. In addition, its dedication to a free, open-source model makes it an accessible platform for those who need a cost-effective database option rich with features and community support.
What is Dynamic Data Masking?
Data masking is a data security practice meant to ensure the privacy of sensitive data. When data is shared or accessed by low-privilege users, real data is obscured, jumbled, or hidden behind fake data in order to avoid unnecessary exposure.
Dynamic data masking doesn’t change the real data, instead, it provides an avenue through which data can be shared without revealing sensitive PII.
With that in mind, data masking – like all other security strategies – should be one of a few layers of database protections rather than the only line of defense between your data and bad actors.
Why Should You Mask Data?
As mentioned above, data masking is useful for teams within your organization as a security measure as well as for testing, development, demonstrations, and staff training.
For example, when your teams are trying to test a non-production version of your database, they can see exactly how the database performs but their view of specific data points is obfuscated. In other words, they see how the data is supposed to be laid out but real, sensitive data is still hidden behind the mask, keeping it safe from teams who don’t need to see that data.
Data masking is also useful when sharing database information across different teams. For instance, the sales and marketing teams might need to see the same tables but while one team needs to see sensitive data (like contact information) the other doesn’t. Instead of having to create individual authorizations and privileges, separate tables, or even separate databases, data masking and row-level security allows users from both teams to call the same information but only gives each team the information they are authorized to see.
Benefits of Dynamic Data Masking
Dynamic data masking provides a level of granular control concerning who has access to information. Depending on security rules or specialized data masking plugins, user queries are intercepted and modified based on those rules. The user then only sees the masked query data without the entire database needing to be obscured.
Dynamic data masking doesn’t require a separate database copy and so you can save server space by choosing this option. Depending on how you’ve set up your dynamic masks, you may still need to update query rules as your database evolves. However, there are specialized plugins that can automate that process for you.
One of the biggest benefits of dynamic data masking, however, is not needing to take real data out of the database to create a mask. The mask is made in real-time as it’s needed and continuously updates with changing security considerations, keeping the data safe within the database.
Drawbacks of Dynamic Data Masking
In some technologies, dynamic data masking may require ongoing maintenance. It also may be difficult to scale the dynamic mask across different data stores.
If there are multiple teams working on the data in multiple locations applying the different masks, required for varying levels of access and compliance regulations, is complicated.
Learn more:
Examples of Data Masking in MariaDB
Dynamic masking in MariaDB allows you to establish fine-grained security access controls by assigning authentications and authorizations. You set the accessibility requirements of different users based on their assigned privileges.
Within MariaDB, you can also make use of row-level security. This allows you to secure data on the basis of user-level security at the database level instead of the application level.
Row-level security is used to restrict access to sensitive information and for compliance purposes. It ensures only those employees who should have access to data are given access, and that this access can be assigned as temporary or permanent.
MariaDB has its own audit plugin, Audit trail, which provides detailed information about the users and hosts who have accessed, analyzed, or changed any data. This helps to secure the information and is useful for compliance.
Your database is accessible to all departments of your business but every user queries the database for different reasons. Some teams may need to use the same tables but one team might require access to sensitive data while the other doesn’t.
Dynamic masking rules can catch queries from the less-privileged team, giving them only the data they need to do their job and obscuring the data they don’t need in real-time. Instead of creating separate copies of your database for each team depending on their access, the dynamic masks streamline the process without using up valuable space on your servers.
How to Implement Dynamic Data Masking in MariaDB
Dynamic data masking occurs without making any changes to the original data. The mask occurs on the original database, in real-time, and varies with user permissions.
There are several ways to do so, depending on the amount of complexity you need to solve and your specific requirements.
Using Database Views
Using a database view, you can use IF or CASE WHEN conditional statements, that will return different results for different columns. This is usually done by using the CURRENT_USER() function, to return different values for different users. Once you create the view, you grant users permission to the view instead of the underlying tables.
This method is quite flexible in the transformations you can apply and the conditions, but it comes at a price of being hard to manage and maintain, especially at scale. It is therefore especially useful for solving very specific needs.
Using MaxScale
MariaDB MaxScale is a database proxy that provides enhanced security such as real-time data encryption and dynamic masking of sensitive data for data consumers at scale. After installing and configuring MaxScale, you can create dynamic masking rules in MaxScale, configured per column, in each table of each database.
Using Satori
When using Satori with MariaDB, you can apply dynamic masking policies not only based on specific locations, but also according to data types. You can set a simple data masking policy according to user roles that returns the data accordingly. For example, only accounting will be able to access sensitive financial data, and only HR will be able to view employee PII.
Implementing MariaDB Data Masking with Satori
Satori allows you to apply dynamic masking on data stored in MariaDB, MySQL, and other data platforms from a single pane. You don’t need to add any views or SQL policies, and you can apply a dynamic masking policy based on data types that are continuously updated.
Learn more: