MySQL Security

Security is in the forefront of everyone’s minds, especially when it comes to data storage and use. Databases are one component of a secure environment which has its own implementation of security.

Using a largely open source RDMS, such as MySQL, provides its own certification challenges. There is a myriad of criteria out there from Best Practices and PHI/PII Compliance, to full blown HIPPA and FISMA Compliance, and everything in between.

Types of Compliance

There are a number of acts that require various types of security for your data implementation, and they apply to specific types of data and organizations. For Best Practices, we at Datavail look at the most rigorous requirements for all of them, and use that as our checklist.

Types of Implementation

For MySQL, prior to an audit, you need to make sure you are using compliant practices.

RDMS Implementation

The version of MySQL you use must be secure, including settings and permissions. It must reside on a secure operating system, and on secure hardware. The host and database permissions should always be locked down as much as possible, while still allowing for proper functioning. For example, don’t allow read/write when only read is required.

Secure Communication

Communication with the RDMS must be via secure methods. Communication with the host (server) must be via secure methods.

Data Storage

Data must be stored securely. This includes “live” data as well as “data at rest.”

Access/Permissions

Permission and access must be closely controlled. This includes using group permissions (e.g. AD/LDAP/PAM) for host (server) access, as well as database access.

Auditing

To be fully compliant, all access must be logged, including activity.

Monitoring

You must monitor your implementation for security breaches and threats.

Compliant MySQL Implementations

When talking about the environment for your database, you must ensure that each part is secure. Typically, a VPN is used which is not directly accessible to the public. Access to this VPN is severely limited, monitored, and audited. In general, to easily achieve compliance with the applicable requirement (FISMA, PHI, etc.), or your business requirements, you have three primary choices for MySQL: MariaDB, Percona MySQL, and Oracle MySQL Enterprise.

These forks of MySQL allow you to enable plugins for PAM (Active Directory) authentication and Auditing. Additionally, they can use encryption plugins to keep live data safe. Replication and MySQL connections should be using SSL. Regardless of the build of MySQL, full disk encryption should be implemented prior to installing MySQL to fulfill the “encryption at rest” component.

All access to the host and MySQL instance, where possible, should be done using roles and accounts established from your centralized user system (e.g. Active Directory)

Our Approach

Design

When we design a MySQL database environment, we take into account the level of security, the auditing required, data retention requirements, as well as performance, growth, extensibility, and cost. Our number one goal is to fulfill your security requirements while at the same time, maximizing performance and usability, as well as ensuring the environment will grow with you.

Existing Environments

When we encounter an existing system that should be compliant to a particular security act, or if the system owners just want to be able to say they are secure, we perform an audit on the database environment. We have an automated audit that will roll through your MySQL database implementation, flagging exceptions, and noting checklist items that pass. Once we have the results of this audit, we review what is lacking, and provide a plan on how to bring the environment more into compliance with the least amount of impact to live systems.

Table 1 – Sample Checklist Results