In 2016 Oracle added Transparent Data Encryption (TDE) feature to the MySQL server. With this new functionality in hand database administrators can now encrypt Electronic Personal Healthcare Information (ePHI) stored in their MySQL database servers to ensure privacy and prevent data breaches. Moreover, the functionality is available for free in the MySQL Community edition. However, both the Community and the Enterprise edition lack proper key management. Oracle recommends the use of Oracle Key Vault (or any other KMIP compliant key locker to manage the encryption keys) for managing MySQL master encryption keys. The cost of such a solution can run into tens of thousands of dollars – a small fortune for many small to medium sized businesses.
We are offering a key management service to MySQL customers who want to use the TDE functionality but are not ready to take on the arduous task of building and managing an expensive key management system of their own. The service allows customers to offload their key management responsibilities to us. We have a global key management infrastructure that is managed by our security experts on 24x7x365 basis. We ensure that the encryption keys are stored securely and are available to authorized individuals when needed. Our key management procedures are designed to meet or exceed data compliance requirements of various regulations including that of the HIPAA/HITECH Act.
It usually takes less than 30 minutes to install and configure our service. The service is geared towards small to medium sized businesses.
The US Health Insurance Portability and Accountability Act or (HIPAA) requires covered entities to implement technical safeguards to protect ePHI under their control whereas the Health Information Technology for Economic and Clinical Health (HITECH) Act mandates that a successful breach of “unprotected” ePHI must be publicly disclosed. Furthermore, the HIPAA Omnibus Rule holds business associates liable for non-compliance. Hence businesses are looking for answers to the following pivotal questions:
How to preserve brand equity and mitigate risk?
The HIPAA Act requires covered entities to provide public notification upon discovery of a breach of ePHI (unsecured Electronic Patient Health Information) involving more than 500 records. Businesses spend money, time, resources on developing their brand equity. Loss of ePHI can result in significant erosion of their brand equity.
How to lower the compliance cost?
Oracle’s Key Vault can easily cost upwards of fifty thousand dollars and other KMIP compliant key locker are not inexpensive as well. So many businesses are looking into ad-hoc key management solutions that could lead to devastating results down the road. However, keeping the compliance cost in check is also one of the main priorities for many businesses.
How to maintain a secure posture?
Cyber criminals are working hard to come up with new and innovative ways to breach ePHI. Covered entities simply can not evolve their security strategies quickly enough to deal with these emerging threats. This is precisely why many covered entities are looking for data security services instead of a piece of software or hardware that will just encrypt their data.
Where to store the MySQL master encryption key?
The MySQL manual says:
The InnoDB tablespace encryption feature in non-enterprise editions of MySQL uses the keyring_file plugin for encryption key management, which is not intended as a regulatory compliance solution. 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).“
Moreover, the HIPAA sections 164.312 (a)(2)(iv) and 164.312 (e)(2)(i) state that “to avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.”
The two statements above pose a serious technical challenge for businesses that are using the MySQL TDE functionality without a proper key management solution. Additionally, it’s not sufficient to store the encryption keys at a safe place but to also make sure that they are available when needed to authorized key administrators and that every such access to the key vault generates an immutable log entry.
How to protect the MySQL encryption against a malicious ‘root’ user?
The MySQL server requires the encryption key to be available in cleartext when the server is restarted. Unauthorized ‘root’ or privileged insider can access the key during reboots. With the encryption key in hand such malicious users can read ePHI files directly. This technique can be used by untrustworthy ‘root’ user, or by an attacker who has gained the ‘root’ access to the server. It remains a hard problem to solve as most operating systems give unfettered access to the ‘root’ user.
How to protect the redo log, undo log and binary log files?
MySQL TDE provides no protection to ePHI stored in redo log, undo log and binary log files. Once an attacker is able to successfully compromise the server at OS layer they can easily read ePHI stored in these log files.
Server General KMS for MySQL is a key management service for customers who do not want to build or manage a complicated, expensive and time consuming in-house key management system. The service allows customers to offload their MySQL encryption key management to us while they focus on developing their business applications. The service provides an option to customers to store their MySQL master encryption key on-premises in a virtual key locker appliance or within our cloud locker. Moreover, we can help manage the encryption keys of your MySQL server no matter where it is hosted. It usually takes less than 30 minutes to install and configure our service. The service is geared towards small to medium sized businesses who want to cut their data security and regulatory compliance costs.
Server General KMS for MySQL uses the Advanced Encryption Standard (AES) algorithm to encrypt the MySQL master encryption key thereby meeting or exceeding the encryption standard requirement defined as “AES-compatible” by the IETF/IRTF Cipher Catalog and by the National Institute of Standards and Technology (NIST) publication FIPS 140-2.
It is very difficult to restrict “root” user’s access in a manner that does not impede their ability to do their job while disallowing them from accessing the MySQL master encryption key needed to be stored on the server while restarting the MySQL server. A malicious “root” user can easily abuse their powers and gain access to the encryption key and then to ePHI thereby exposing the covered entity to a HIPAA violation. Server General KMS for MySQL protects the MySQL master encryption key by adding an additional layer of control that prevents the “root” user from gaining access to the encryption key in clear text. It should be noted that Server General KMS for MySQL is designed not to interfere with normal access control mechanisms of the MySQL server.
Lastly it is imperative for covered entities to generate an immutable logging trail. Server General KMS for MySQL accomplishes this task through extensive logging of all access grants and their usage. Furthermore, in order to prevent tampering of these log files they are stored at four different locations.
Server General KMS for MySQL enables customers to save money by enabling them to make use of the MySQL TDE functionality available in the Community or the Enterprise edition by lowering their key management cost while making it easy for them to comply with the HIPAA/HITECH Act.