Encryption and Auditing for MySQL Databases under HIPAA
We get a number of questions every week regarding MySQL databases and HIPAA web site compliance. These range from confusion over auditing of access to stored ePHI to what HIPAA’s data encryption requirements actually are to how HIPAA applies to MySQL databases. Here, we will attempt to address some of these subtle questions for you.
ePHI Access Auditing
Lets start with the “easy” question.
We are often asked about database audit trails for all of the accesses (reads, writes, updates) made to customer databases … as at first glance, it may appear that HIPAA and other forms of compliance are asking for that … “the more and more detailed the logs, the better,” one may think.
However, lets back up a step. HIPAA wants to make sure that you log “who” accessed ePHI, when that happened, etc. The “who” here is the end user of your web site. In the majority of cases, all literal database reads and writes are performed by a single “database user” acting at the bequest of your web site application. So, while it is possible to log all database activity, that does not actually address HIPAA’s requirements at all, as this activity generally will not include any information about “what person” interacted with your web application to cause that activity.
The full detail of your database activity is also known as a “transaction log” and it is very useful if you are replicating your database from one server to another, or if you want to make certain kinds of backups or provide recovery points for certain kinds of 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 of time (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.
But wait … so how does one actually audit access to ePHI in the database?
It turns out that this is the job of your web application. Your 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 your application to record such events with a degree of granularity that you deem appropriate for your compliance needs. E.g.
- Are you going to record access to each individual piece of ePHI, or
- Are you going to record only access to a particular patent’s records? or
- Are you going to separately record views and edits, or treat these as a lump?
It is up to you to determine the appropriate level and granularity of your auditing as a function of what your web application does, how ePHI fits into it, and what your compliance team deems appropriate. It is then up to your 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, there is no database-level panacea that will “take care of this” for you and generate the kinds of auditing information needed for HIPAA … it won’t happen without your web developers building it into your web application.
MySQL Database Encryption
HIPAA does not actually require that your ePHI be encrypted at rest when stored in your MySQL database…. as long as it is isolated so that no unauthorized people can access it. That said, it is generally always better to have your data encrypted at rest, if possible, as that prevents a breach from happening should the data be compromised.
Beyond trusting in the security and integrity of your providers’ servers and solution, you can mitigate your potential risk of breach without at-rest encryption to a significant degree by:
- Hosting your web and database on a dedicated server. In a shared server environment, your potential risk is greater — more customers using your server means possible risk from other customers and from those who would attack those other customers and compromise your data as well. A dedicated server is like a “private room”. Your exposure is much less.
- Hosting your database on a separate dedicated server from your web site. By putting your database on its own server, you isolate it even from your dedicated web server. Should your web server be compromised, your database server is much less likely to be. This is the recommended architecture for anyone very security conscious, independent of their decision for at-rest data encryption.
But still, how can MySQL data be encrypted at rest?
There are essentially 3 ways this can be done.
1. Disk Encryption
The hard drive or partition that MySQL uses to store your data can be encrypted. This is like the “FileVault” built into modern Mac computers or the encrypted hard drives your can buy at the store. This method ensures that if the hardware is lost or stolen, the data is safe. This is very good for laptops and servers in an office environment. It is marginally useful for databases located in world class data centers or in the cloud — as the chance of someone “stealing” or “losing” your hard drive here is very, very low.
The big down side of “Disk Encryption” is that each time the server is “booted up,” some person must be there to enter the password to unlock the drive before its data can be used. E.g. if your server is ever rebooted or restarted without someone authorized to know that special password standing by … your database will be DOWN until such a time as that person can either be physically present at the server’s console and enter the password, or can login remotely and 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 center or in “the cloud” … you are not worried about loss or theft of the drive, you are very much more worried about someone gaining system-level access to the server and accessing your 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 your disk itself, you have a large file or partition that “looks like a disk.” Access to this “disk” is through a special software application ….. which encrypts data to be stored and decrypts data to be read from this “disk.” Data at rest is always encrypted and your application sees this data as normal 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 gotten unauthorized access to your server…. a very good step for HIPAA compliance.
LuxSci can support this solution for dedicated server customers.
3. Cell-Level Encryption
The simplest and cheapest solution is for your application to encrypt ePHI when saving it in your database and decrypt it when it is read from your database. (1) It doesn’t cost any more, (2) it works with any MySQL database, (3) your data is encrypted at rest, and (4) your 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. You provide the key-phrase and MySQL takes care of the encryption and decryption of your data. Keep the key phrase away from your database and you have good protection for your data. You could achieve similar results (albeit with more work) using PGP or openssl, for example.
What is the down side? Well, you can’t use MySQL to search or sort data that is encrypted in this way because, to MySQL, it is all just a big encrypted blob of text. Additionally, it requires your web developers to actively implement encryption and decryption for sensitive data. If this is done from the beginning, it is perhaps not so much work; however, if your application is already written, it could be painful.
What do we recommend?
It depends…like most things:
- 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/or do not wish to implement encryption at the application level, consider a solution such as zNcrypt.