Data Security in MySQL is an evolving compliance and threat landscape

MySQL remains one of the most popular relational databases today. It offers a variety of data security features that can help with compliance, but only for those who purchase and use the enterprise edition. Even then, the data protection capabilities offered in the enterprise edition are meant for the threat landscape of a bygone era.

Today’s security and compliance requirements demand that companies do more to secure MySQL databases and demonstrate proper controls are in place. In this blog we’ll discuss the problems that today’s MySQL users face, how well MySQL’s current data security features address those problems, and what additional measures users should take to fully address those problems.

Control of the Data

One of the biggest changes to the IT landscape is the move to public cloud infrastructure. Whereas databases used to be exclusively run on company-owned and operated data centers, today companies regularly use managed database services in public cloud. They do so to decrease the cost associated with managing database infrastructure and increase their responsiveness of workload scaling. As an open-source database, MySQL was one of the early databases offered as a service by cloud providers. AWS, for example, introduced optimized versions of MySQL for its relational database service (RDS), and it became one of the more widely used databases in cloud infrastructure.

Though MySQL as a whole adapted quickly to run in the cloud, its data security features remained rooted in assumptions of an on-premise deployment model. One of the most salient examples of this assumption is MySQL’s built-in access control mechanism. It was designed assuming that the infrastructure is fully trusted and owned by the user, and as a result, highly privileged operating system users can gain access to the MySQL “root” account with a trivial amount of effort. The “root” account is the super user for the database, meaning that it can easily gain access to all data stored in the database. This security model was reasonable in an on-premise environment where a company had full control over its machines and staff or when the host machine administrator was the same as the database administrator. But, when databases moved to the cloud, a third party (i.e. the cloud provider and its infrastructure administrators) also gained access to data in the database. This means that additional controls are needed to demonstrate that the third parties cannot access the data.

One of the best ways to do this is to encrypt the data that is loaded in the database tables.   Baffle Data Protection for Databases can enable this type of encryption without any code changes by using an inline proxy that encrypts the data on behalf of the application before it reaches the MySQL database. Once in encrypted form, even if an authorized privileged user tries to query the data, they will never see actual data values. If they try to alter the data, it will be instantly recognized as unencrypted or encrypted with the wrong key.  Note that this is different than TDE / FDE as with those techniques, the data is encrypted on disk but unencrypted when it is loaded into tables (sometimes referred to as data-in-use).

Need-to-Know Access to Sensitive Data

New and evolving data privacy regulations specify that sensitive data must be controlled such that it is accessed on a need-to-know basis. GDPR, for example, uses this language to describe the requirement:

“The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller.”

Similar language can be found in PCI-DSS pertaining to credit card numbers:

“[O]nly personnel with a legitimate business need can see more than the first six/last four digits of the PAN.”

In short, privileged database users are no longer allowed to retain unchecked access to sensitive data in favor of operational efficiency. Security mechanisms must be put in place to require specific authorization to access data, and not just audit any unauthorized data access. Since MySQL’s security features like Transparent Data Encryption (TDE) and Enterprise Data Masking were designed and built around MySQL’s existing access control system, these security mechanisms do not provide the need-to-know controls that current compliance regulations need.

For example, TDE automatically decrypts data for any user with SELECT privileges on the data. This effectively gives privileged database users such as the DBA or backup administrator access to sensitive data even if it is encrypted. Likewise, MySQL Enterprise Data Masking is readily bypassed by privileged users since it simulates dynamic masking capabilities through the use of views with the provided masking functions, so any privileged user with access to the base table can see sensitive data values.

Baffle Protection for Databases can ensure that data in MySQL is only visible to a set of explicitly defined users by enforcing access control of data independently from the MySQL access controls. This means that database administrators or other privileged database users cannot deliberately or inadvertently access sensitive data values without an explicit grant of access through the data protection policies. Furthermore, Baffle supports enabling or denying access based on application user identities rather than database identities. This granularity of control further ensures that it’s possible to define a security policy that grants data access to the smallest possible set of users.

Multi-Tenant Data Sets

Today’s software and software components commonly use a microservices or service oriented architecture. This means that the data layer is often exposed to application components as independent services where the data sets from multiple service users or tenants are comingled. From a security and compliance perspective, each of these tenant’s data should be isolated and independently controlled.

Unfortunately, MySQL’s security mechanisms were not designed with multi-tenancy in mind, where onecan grant access to individual databases independently through MySQL built-in access controls nor support row-level access to a table that has the data of multiple tenants.

Once again, the administrators and privileged users of the MySQL server can trivially bypass these grants. Furthermore, when TDE is used to encrypt the data, the data of different tenants are all encrypted with the same key encryption key, and all tenants data is stored together in the same data, backup, and log files. This means that if any tenant wants to permanently disable access to its data, there’s not a way to do so.

Baffle Data Protection is designed to support multi-tenant data sets in MySQL databases, both for logical databses as well as row-level for data sets in a table. Baffle supports both Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK) for encryption such that each tenant’s data is encrypted with its own keys, and each tenant can easily disable access to its data set stored in a shared MySQL database just be removing access to the encryption keys.

Use Baffle to Meet Today’s Compliance and Security Requirements

While MySQL does have many security features that can improve the security posture of the database, its native security features are no longer sufficient to address current compliance requirements or security threats on their own. Baffle Data Protection for Databases provides the missing data security capabilities to ensure that MySQL can be used in compliance with data privacy regulations. Best of all, Baffle has a no-code deployment model and built-in key management integration that makes it easy to secure MySQL databases.