Encryption and Auditing for MySQL Databases under HIPAA

We get many questions regarding MySQL databases and HIPAA website compliance. These range from confusion over the auditing of access to stored ePHI to what HIPAA’s data encryption requirements actually are to how HIPAA applies to MySQL databases. Next, we will attempt to address some of these subtle questions.

ePHI Access Auditing

Let’s start with the “easy” question.

We are often asked about database audit trails for all accesses (reads, writes, updates) made to customer databases. At first glance, it may appear that HIPAA and other forms of compliance are asking for that. Many might think “the more detailed the logs, the better.”

However, let’s backup a step. HIPAA wants to ensure that logs of who accessed ePHI, when that happened, etc., are kept. The “who” here is the end-user of your website. In most cases, all literal database reads and writes are performed by a single “database user” acting at the bequest of the website application. While it is possible to log all database activity, that does not address HIPAA’s requirements. This activity generally will not include any information about “what person” interacted with the web application.

The full detail of the database activity is also known as a “transaction log,” and it is beneficial if replicating a database from one server to another. It’s also helpful to make certain kinds of backups or provide recovery points for some server failures. However, these logs can and will get VERY large. In practice, when they are kept, they are kept only for a relatively short period (on the order of hours or days, far short of the “years” timeline inherent in HIPAA). LuxSci can enable these types of logs for customers with dedicated servers who wish to also pay for all of the disk space required to keep them; however, this is generally discouraged in favor of other methods for backup and recovery.

How to audit ePHI access in the database

It turns out that this is the job of the web application. The application knows “who” is logged in and accessing it, and it “knows” what that person is doing, and it should know if that person is reading, saving, or altering content that is or could be ePHI. Therefore, it is up to the application to record such events with a degree of granularity deemed appropriate for the organization’s compliance needs. The organization must decide if they will record:

• Access to each individual piece of ePHI, 
• Access to a particular patent’s records, or
• Separately record views and edits, or treat these as a lump?

It is up to each organization to determine the appropriate level and granularity of auditing as a function of what the web application does, how ePHI fits into it, and what the compliance team deems appropriate. It is then up to web application developers to implement this auditing (saving the history of these ePHI interactions to that database or a different one and providing the means for your compliance team to access and generate reports on that information).

Unfortunately, no database-level panacea will generate the kinds of auditing information needed for HIPAA. It won’t happen without web developers building it into the web application.

MySQL Database Encryption

HIPAA does not require that ePHI is encrypted at rest when stored in a MySQL database, as long as it is isolated so that no unauthorized people can access it. That said, it is always better to have data encrypted at rest, if possible, as that prevents a breach from happening if the data is compromised.

Beyond trusting the security and integrity of the providers’ servers, some ways to mitigate the potential risk of a breach without at-rest encryption by:

1. Hosting the web and database on a dedicated server. In a shared server environment, the potential risk is more significant. More customers using the server means possible risk from other customers and those who would attack those other customers and compromise data. A dedicated server is like a “private room.” The exposure is much less.
2. Hosting the database on a separate dedicated server from the website. By putting a database on its own server, it is isolated from dedicated web servers. The database server is much less likely to be impacted if the web server is compromised. This is the recommended architecture for anyone very security conscious, independent of their decision for at-rest data encryption.

How can MySQL data be encrypted at rest?

There are essentially three ways this can be done:

1. Disk Encryption

The hard drive or partition that MySQL uses to store data can be encrypted. This is like the “FileVault” built into modern Mac computers or encrypted hard drives that can be purchased. This method ensures that the data is safe if the hardware is lost or stolen. This is very good for laptops and servers in an office environment. It is marginally helpful for databases located in world-class data centers or the cloud. The chance of someone “stealing” or “losing” the hard drive here is very low.

The big downside of “Disk Encryption” is that each time the server is “booted up,” someone must be there to enter the password to unlock the drive before its data can be used. Suppose the server is rebooted or restarted without an authorized user standing by. In that case, the database will be DOWN until that person can enter the password to enable the drive (depending on how it is set up). This is very bad for reliability and uptime.

For drives in world-class data centers or the cloud, the more considerable risk is someone gaining system-level access to the server and accessing database files while the machine is running. Disk encryption does not protect against this at all.

For these reasons, disk encryption is not generally used on live servers at LuxSci and most other providers. We use it for off-site backup servers, corporate servers, and the like.

2. Real-Time Virtual Partition Encryption

Imagine that instead of encrypting the disk itself, there is a large file or partition that “looks like a disk.” Access to this “disk” is through a particular software application, which encrypts data to be stored and decrypts data to be read from this “disk.” Data at rest is always encrypted, and the application sees this data as standard unencrypted data. So far, this is just like disk encryption. Next, let’s assume that this special software allows only authorized programs/processes to access this data. This is better than disk encryption because it ensures that the encrypted files are opaque even to a hacker who has unauthorized access to the server. This is an excellent step for HIPAA compliance.

LuxSci can support this solution for dedicated server customers.

3. Cell-Level Encryption

The simplest and cheapest solution is for the application to encrypt ePHI when saving it in a database and decrypt it when it is read from the database. (1) It doesn’t cost any more, (2) it works with any MySQL database, (3) the data is encrypted at rest, and (4) the data is protected from hackers who may have broken into the server.

How do you do it? The simplest way is to use MySQL’s built-in commands AES_ENCRYPT and AES_DECRYPT. The developer provides the key phrase, and MySQL takes care of the data encryption and decryption. Keep the key phrase away from the database and protect the data. Similar results could be achieved (albeit with more work) using PGP or OpenSSL, for example.

What is the downside? MySQL cannot be used to search or sort encrypted data in this way. To MySQL, it is all just a big encrypted blob of text. Additionally, web developers must actively implement encryption and decryption for sensitive data. If this is done from the beginning, it may not be much work. If the application is already written, it could be painful.

What do we recommend?

Like most things, it depends:

• If you are writing your application from scratch or have no tolerance for downtime, consider cell-level encryption.
• If you can tolerate some downtime in the case of a server reboot and do not wish to implement encryption at the application level, consider a solution such as zNcrypt.