Posted on by mike

You’re not storing sensitive data in your database. Seriously?


At technology events, I often ask attendees if they’re storing sensitive data in MySQL. Only a few hands go up. Then, I rephrase and ask, “how many of you would be comfortable if your database tables were exposed on the Internet?” Imagine how it would be perceived by your customers, your manager, your employees or your board of directors. Once again, “how many of you are storing sensitive data in MySQL?” Everyone.

TWO MAXIMS:

1.) You are storing sensitive data.

Even if it’s truly meaningless data, you can’t afford for your company to be perceived as loose with data security. If you look closely at your data; however, you’ll likely realize that it could be exploited. Does it include any employee info, server IP addresses or internal routing information?

A recent article by Lisa Vaas from Naked Security highlights a spate of data leaks from poorly configured MongoDB instances.

What’s striking is that these leaks didn’t include credit cards, social security numbers or so-called sensitive data. Nevertheless, companies are vulnerable to ransomware and diminished customer trust.

2). Your data will be misplaced, eventually.

Employees quit, servers get decommissioned; but database tables persist. Your tables are passed among developers, DBA’s and support engineers. They are moved between bare metal, VM’s and public cloud providers. Given enough time, your data will end up in a place it shouldn’t be.

Often people don’t realize that their binary data is easily exposed. Take any binary data, for example, and run the Linux strings function against it. On a Linux command line, just type “strings filename”. You’ll see your data scroll across the screen in readable text.

ENCRYPT MYSQL DATA

Two years ago, MySQL developers had to change their application to encrypt data. Now, transparent data encryption in MySQL 5.7 and 8.0 require no application changes. With Oracle’s version of MySQL, there’s little performance overhead after the data is encrypted.

Below are a few simple steps to encrypt your data in MySQL 8.0. This process relies on a keyring file. This won’t meet compliance requirements (see KEY MANAGEMENT SYSTEMS below), but it’s a good first step.

  1. Check your version of MySQL. It should be MySQL 5.7 or 8.0.
  2. Pre-load the plugin in your my.cnf: early-plugin-load = keyring_file.so
  3. Execute the following queries:
  • INSTALL PLUGIN keyring_udf SONAME ‘keyring_udf.so’;
  • CREATE FUNCTION keyring_key_generate RETURNS INTEGER SONAME ‘keyring_udf.so’;
  • SELECT keyring_key_generate(‘alongpassword’, ‘DSA’, 256);
  • ALTER TABLE titles ENCRYPTION = ‘Y’;

Per documentation warning: The keyring_file and keyring_encrypted file plugins are not intended as regulatory compliance solutions. Security standards such as PCI, FIPS, and others require use of key management systems to secure, manage, and protect encryption keys in key vaults or hardware security modules (HSMs).

KEY MANAGEMENT SYSTEMS (KMS)

Credit card and data privacy regulations require that keys are restricted and rotated. If your company collects payment information, it’s likely that your organization already has one a key management system (KMS). These systems are usually software or hardware appliances used strictly for managing your corporate encryption keys. The MySQL Enterprise Edition includes a plugin for communicating directly with the KMS. MySQL is compatible with Oracle Key Vault, SafeNet KeySecure, Thales Vormetric Key Management and Fornetix Key Orchestration.

In summary, reconsider if you believe that you’re not storing sensitive data. If using MySQL, capabilities in the latest releases make it possible to encrypt data without changing your application. At the very least, encrypt your data with the key file method (above). Ideally, however; investigate a key management system to also meet regulatory requirements.


via Planet MySQL
You’re not storing sensitive data in your database. Seriously?