If you’re here, that probably means you’re about to acquire some sensitive data to take care of. Or that you’ve already acquired it and are protecting it, and you want to see how MySQL Enterprise Data Masking and De-Identification features can help you do it in an easier, better and more efficient manner. It also doesn’t hurt to just add another item to your “bag of tricks”.

Whatever the reason, with recent legislature pushing (can I hear GDPR?) and continuous industry focus on data security, data masking is slowly becoming more and more indispensable part of our daily routine. In this article we show what is currently possible with MySQL Enterprise Data Masking and De-Identification (let’s call it data masking, for short). If you’re interested in data masking in general, the all-mighty Wikipedia provides a nice, lean-and-mean intro material.

First step

Customers who’ve had an early look at this new data masking have responded very positively, and remarked on how useful this set of functions will be for them. We initially focused on the most common requirements by releasing this suite of simple to install functions. They can be enabled extremely easy within your running MySQL server, both on 5.7.24 and 8.0.13 releases. We’ve already gotten new requests from customers for enhancements, and we plan to add them going forward.

Ofcourse, there are many reasons to be rocking our latest-and-greatest (8.0 series) and you should really, really, look into it 🙂

Specialized or generic – what’s your flavour?

Often we have to do with typical formats of sensitive data, such as credit card numbers (also known as PAN, Personal Account Number), social security numbers etc. For such purposes, we’ve created appropriate, fixed-function style solutions.

As you can see, these functions perform partial masking on a well known format using predefined, industry standard masking definitions. Partial masking exposes part(s) of the original data which are deemed safe enough to be used, e.g. for identification purposes.

We imagine you’ll probably think of more places where partial masking could get used (and when you do, we’d like to know more about it, so ping us). In the mean time, if provided fixed-format functions do not apply to your particular problem, maybe our generic partial masking will do the trick:

The usage is intended to be rather self-explanatory, but you can always take a look at our data masking reference for all the details.

What about my data?

“Hang on”, you say, “but I have sensitive data stored in tables, how does this help me?” We’re only getting warmed up here, so stay tuned. For the purposes of this blog entry, we decide to (ab)use a part of our data masking facilities responsible for random data generation.

The original use case for our random data generators was masking of sensitive data which is not to be seen at all, not even partially. In many cases, we needed to mimic the look-and-feel of the original data, so that many applications relying on data format would continue to function properly. Turns out, random data generation, if used properly, can also have an alter-ego (as many heroes do), the “Data Fabricator”. We trust you to use this power for good purpose. Here’s what your data may look like after random generating data:

Notice: although gen_rnd_pan() function will create a proper (Luhn check compliant) credit card number, we have “edited” generated numbers for the purpose of publication, and replaced them with sequence of digits. There is no actual guarantee that some of the generated numbers are not belonging to a real person account.

Dictionaries

One of the interesting features we used “under the hood” in this example is a data masking dictionary. When data is generated randomly, you typically can choose a range, and can expect an output within that whole range. Data masking dictionaries enable us to select a random value from a set of predefined values we can “load” into the masking engine. In order for previous example to be possible, we had to add our dictionaries beforehand in a way similar to this:

SELECT gen_dictionary_load("/dict/path/file.txt", "DictionaryName");

At this point, dictionaries support only string values, and dictionary files are essentially newline delimited rows of distinct values. Sometimes the simple solution works best, and we tried to ease it up, for starters. The dictionary shall be available for usage until we shut down MySQL server, or we issue the following command:

SELECT gen_dictionary_drop("DictionaryName");

For the purposes of generating data, we’ve created short dictionaries for columns name, surname, city and title. We have also created another dictionary with german city names, which is going to be used for following examples.

Masking the data

At this point, we believe hope that “fabricated” data bears some resemblance to your actual production data, give or take a column or two. It’s obvious that most of the columns fall into sensitive data territory. Now we’ll use combined forces of partial and random data masking to create a masked view of our data.

Voila – you have yourself a masked version of your sensitive data:

Our first and last names got cosily switched to initials, and emails are all from example.com domain (not that they weren’t before, but your actual e-mail addresses are probably not from this domain).

New US phone numbers got applied, and special C-level employee got slightly demoted. Not to mention that the whole team transferred to EU.

Finally, salaries are “compressed” a bit, social security numbers are partially masked, and no one will get to use your employee’s credit card numbers in an online store.

Conclusion

Security is of utmost importance in today’s world, MySQL will continue to focus on security features and for sure data masking and de-identification. We look for customer feedback to guide our roadmap to meet your top challenges first. Tell us what you want. And as always thanks for using MySQL.