Welcome!

Every Cloud Needs a Silver Lining

Gilad Parann-Nissany

Subscribe to Gilad Parann-Nissany: eMailAlertsEmail Alerts
Get Gilad Parann-Nissany via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


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.

Here’s why.

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. Cloud Key Management Cloud Encryption Cloud Database security  risk cubes 300x159 MySQL in the cloud: database encryption options and cloud encryptionFor 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.

  1. 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”.
  2. 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.
  3. 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.

  1. 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.
  2. 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.
  3. 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?).
  4. 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.

More Stories By Gilad Parann-Nissany

Gilad Parann-Nissany, Founder and CEO at Porticor is a pioneer of Cloud Computing. He has built SaaS Clouds for medium and small enterprises at SAP (CTO Small Business); contributing to several SAP products and reaching more than 8 million users. Recently he has created a consumer Cloud at G.ho.st - a cloud operating system that delighted hundreds of thousands of users while providing browser-based and mobile access to data, people and a variety of cloud-based applications. He is now CEO of Porticor, a leader in Virtual Privacy and Cloud Security.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.