|By Gilad Parann-Nissany||
|May 2, 2012 05:15 AM EDT||
MySQL is probably the most popular open source database. While there is a wealth of discussion online for MySQL database encryption,doing it right in a cloud computing environment is tricky.
The discussion here is quite long, and contains a lot of interesting details. So if you want a spoiler: it is possible to achieve true confidentiality for your MySQL database today; using the industry best practice which is split-key encryption.
Cloud encryption for MySQL – Setting your goals
Before talking tech, it’s actually essential to understand what your goals are, and then how they relate to the technical solution for your MySQL database. Sometimes it is hard to get transparency when it comes to what goals are achievable with different techniques.
The classic goals of any information security solution are “CIA”, meaning
- Confidentiality: your data cannot be read by anyone unauthorized to do so
- Integrity: your data cannot be changed or falsified without your knowledge
- Availability: you can get your data whenever you need it, without compromising the “C” and “I” goals above
Looks old school, right? Here is a subtle point, specific to Cloud Computing: people tend to confuse the Confidentiality goal with
No Data Remanence: confidential data does not remain on a disk (in the cloud) after the disk is used
No Data Remanence is a great goal to have, but it is a subset of confidentiality; it’s easier to implement in the cloud, which is why it is perhaps oversold, but it gets you much less.
On the pro side, No Data Remanence does mean that if a cloud provider employee innocently loses your disk during maintenance, no harm is done. On the con side, it does not mean protection from hackers or malicious insiders trying to access your live data storage. For an independent view on this important issue, see “How to Tell If Your Cloud Provider Can Read Your Data”.
The bottom line: the majority of people considering a MySQL encryption solution in the cloud need full confidentiality, not just a data remanence solution. Only full confidentiality will make you compliant with HIPAA, PCI, SOX, SOC2, EU Data Protection Directives and other standards. Only full confidentiality will protect business and personal data. This point will become clearer as we discuss the techniques for cloud encryption and cloud key management available today.
MySQL and Cloud Encryption
There are several ways to encrypt MySQL databases in the cloud. We’ll discuss three; the first two target the storage “underneath” the MySQL database, while the third relies on the capabilities of the MySQL database itself.
- Full Disk Encryption: unsurprisingly, this means that the entire disk used by MySQL for storing the database is encrypted. Some advantages of this approach: it is simple, transparent and less error prone. The likelihood of forgetting some important bit of data unencrypted is small, since you encrypt everything in a sweeping way. Transparency means it works with your application, without changes to application code. A disadvantage is that full disk encryption may be less configurable, since it is “all or nothing”.
- Encrypting specific files (which represent tables): this approach takes advantage of the fact that MySQL can be configured so that each DB table gets saved into a separate file. The idea is to encrypt only the files that are considered most sensitive. Some folks label this “Transparent Data Encryption”, in analogy to the Oracle TDE and the Microsoft SQL Server TDE.
- Encrypting specific rows, fields or columns in MySQL: the SQL language, as implemented in MySQL, allows your developers to code – quite easily – encryption for specific rows or specific fields. This is obviously the most granular approach. It does require an ability and willingness to write application-level code.
How to compare these techniques? All of them allow you to use standard, well tested encryption techniques, such as AES. They differ as follows.
- Configurability: the latter option (#3) is obviously the most configurable, followed by file-level encryption (#2). For example, if each MySQL row represents a user, you could encrypt each user’s personal data with a different encryption key, for maximum security. The other side of configurability is complexity, requiring either developers to write code or sys-admins to configure options.
- Performance: on MySQL, full disk encryption is usually the best for performance. Of course it depends on which encryption engine you use, so let’s take a concrete comparison of open source encryption engines. For Linux, a well-known file-level encryption engine is ecryptfs; while a well-known engine for full disk encryption is cryptsetup/dmcrypt. Third party comparisons are available on the web, for example here. Based on such objective data, it seems we have a perhaps counter-intuitive result: encrypting “only some files” on MySQL may cause a significant hit on performance compared with full disk encryption. Of course, mileage will vary depending on your specific circumstance.
- Simplicity of Security: simplicity really depends on what you need. If you need to separate e.g. each user’s specific line item with a different encryption key, you should go for encrypting specific rows. If you are satisfied with a more sweeping approach, full disk encryption does have the advantage of simplicity (it’s hard to forget something important when you encrypt everything), while with file-level encryption you have to be sure of what you are doing (did you encrypt just the table, or also its related indices, journals and the configuration files?).
- Finely granular authorization and access: both full disk and file-level encryption allow you to use your operating system’s authorization and access, so they are similar in this respect. On Linux, you can manage ownership of database tables whether you are using the full-disk or file-level approach. On the other hand, row-level and field-level encryption allow you to be much more fine granular, depending on your user-management techniques and what your developers can code.
MySQL and Cloud Key Management
The entire industry accepts that Cloud Key Management is critical to the quality of security and encryption in the cloud. The question becomes “who do I trust?” Who can a cloud customer trust with the encryption keys?
One option is to store the keys in the cloud, either on the same cloud infrastructure you use for your data, or with a dedicated key management vendor. As noted by independent security analysts, you trust that the chosen vendor would keep your keys safe and won’t read your data. But recent security incidents highlight the obvious – security providers are themselves exposed to attacks. Recent examples include the VeriSign hack, and the RSA hack.
This discussion really goes to the heart of the Confidentiality issue we raised above. If you are satisfied with No Data Remanence, you can trust cloud providers or security providers. If you need confidentiality or compliance, you simply cannot. Bottom line: never trust anyone with your encryption keys!
An alternative to trusting a provider with your encryption keys is to store the keys back at the enterprise. That approach is tough for many MySQL users; the open source community thrives on its flexibility. Many users of MySQL in the cloud want a pure cloud model, without being tied down to a specific hardware configuration. A physical server deployment – back in the data center – results in an expensive solution in terms of software licenses, operational overhead, and the loss of important cloud advantages (such as scalability and elasticity).
Ideally, you need a solution that works 100% in the cloud, works with the major Cloud Encryption approaches noted above (an API is essential for supporting #3), has low management overhead, and yet leaves control in your hands.
Best practice is split-key encryption. The technique works in the cloud, yet gives you a “master key” which provides true control (that master key is your half of the “split” key). The result is – you trust no one. As noted by independent cloud experts, by protecting the keys to the kingdom using split-key encryption you can effectively eliminate the concern that keys cannot be secured adequately.
You should also make sure to use an implementation of split-key encryption that enables all the major Cloud Encryption approaches. The implementation you choose should
- Have a cloud-ready API (application programming interface)
- Be integrated out-of-the-box with some of the approaches
- Be future-compatible in the sense that it works not just with MySQL, but also with other necessary pieces of your environment. For example, encrypting file systems and file servers is often also needed in a solution using MySQL
Achieving confidentiality for MySQL implementations in the cloud is possible today.
- Database Security in the Cloud
- Disruptive Innovations and the 'Internet of Things' | @ThingsExpo [#IoT]
- Securing Cloud Data from Cybercrime, Intrusion and Surveillance
- Cloud Computing Security Issues and Challenges By @GiladPN | @CloudExpo [#Cloud]
- MySQL in the Cloud
- Cloud Security – Implementing a Secure Cloud Backup Case Study
- Four Great Tips: Cloud Security for Big Data
- Answering Common Cloud Security Questions from CIOs
- Securing Your ‘Data at Rest’ in the Cloud
- Encrypted Cloud Storage – The Missing Piece