In recent months and years, we have seen the benefit of low-cost object stores offered by cloud service providers (CSPs). In some circles, these are called “Swift” or “S3” stores. However, as often as the topic of object or cloud storage emerges, so does the topic of securing the data within those object stores.

CSPs often promise that their environments are secure and, in some cases, that the data is protected through encryption — but how do you know for sure? Furthermore, CSPs offer extremely high redundancy, but what happens if you cannot access the CSP at all, or if you want to move your data out of that CSP’s environment entirely?

Also, who controls the key? Some CSPs propose strategies such as bring-your-own-key (BYOK). However, these approaches are laughable because you have to give the encryption key to the CSP. In that case, it is not your key — it’s their key. BYOK should be called GUYK (give-up-your-key), GUYKAD (give-up-your-key-and-data) or JTMD (just-take-my-data).

Imagine if you could store your data in object stores of any cloud, encrypted under keys that only you control, and transport it easily across multiple clouds and CSPs, enabling you to move between or out of CSPs at your leisure.

Watch the webinar: Reduce Data Risk in the Cloud with Encryption

What Are Object Stores?

Object stores are systems that store data as objects instead of treating them as files and placing them in a file hierarchy or file system. Some object stores are layered with additional features that allow them to be provided as a desktop service, such as Box or Dropbox. However, the critical value of object stores is that they are inexpensive and highly scalable.

Whether you need a gigabyte or a zettabyte of storage, object stores can provide that storage to you easily and inexpensively. That is the simple part.

Protecting Data in the Cloud

Regardless of the kind of storage you consider, protecting the data therein is necessary in today’s climate. Remember that even when storage is inexpensive, your data is still immensely valuable, you are still are responsible for it and you do not want those assets to become liabilities.

How do we protect this data in the truest sense of the word? The answer is simply to encrypt it. However, if the CSP encrypts the data, you must give it the key. You can consider the thought experiments of BYOK, negotiation, wrapping and other key management practices, but at the end of the day, the CSP still has your key. Is there a way the data can be encrypted and stored in their cloud without the CSP accessing it or preventing you from easily switching to another provider?

Encryption of Cloud Object Store Data You Fully Control

There is only one way to maintain full control over your data when it is stored in a cloud object store: by encrypting the data with keys you own and manage before it actually reaches the cloud object store. But does this mean you have to programmatically encrypt the data before you actually upload it?

Luckily, the answer to that question is no, you do not have to programmatically encrypt the data yourself. The new IBM Multi-Cloud Data Encryption object store agent will transparently and automatically do this for you. In fact, this new capability acts as a proxy between your applications and your cloud object store. It transparently intercepts the data you are uploading to the cloud object store and automatically encrypts it with keys you control. Similarly, it intercepts the data you are retrieving back from the cloud object store and decrypts it using the appropriate keys.

Splitting the Bounty and the Key

We can now extend the concept of the encrypting object stores. There is a well-established practice that has been adopted in cloud data protection called data-splitting, which is combined with the concept of key-splitting, also known as secret-sharing.

The fundamental premise of this practice is based on two specific steps. The first step is to take the data and split it into multiple “chunks.” This is not exactly like taking a $100 bill and ripping into three pieces, but it is similar (we will get to that in a bit).

The second step is to encrypt each chunk of data under its own key. Once you have an encrypted chunk, you can place it in an object store. If you have three chunks, you can store them in three different object stores. However, that is not the whole story.

This approach ensures that no object store (or CSP) has access to the unencrypted data or any single key to decrypt it. Even if an object store CSP had access to the encryption key for the data in its object store, it would still have insufficient information to recover the plaintext — it would need the other chunks and their keys.

But this approach gets even more interesting: In this scenario, a subset of the chunks is required to reassemble the original plaintext. This is sometimes called “M-of-N” because it only requires access to M chunks of all N chunks of the data (M being a subset of N) to recover the data. That means that you can have your N chunks stored in the object stores of N different cloud service providers, but you only need access to a subset (M) of those object stores to recover your data. CSPs have neither access to sufficient information (keys or cipher text) nor a necessary component to recover your object store data, which means that nobody controls your object stores — except you.

Greater Flexibility to Change CSPs

Let’s assume that one day you decide that one of the CSPs no longer meets your criteria. Perhaps it is too expensive, it has been breached, it is in the wrong country, its policies have changed, it supports the wrong team or it just isn’t the awesome piece of chocolate cake you dreamed of.

Now you have greater flexibility to change. Just add a new object store to your N (N+1) and then close your account with the CSP you no longer want to use, and you’re done. The CSP did not have access to your data or keys before, and it can now take back all of that storage that contained those random bits of your encrypted data and sell it to somebody else. This is cryptographic shredding at its finest.

You should anticipate questions concerning the increased cost of storage with this approach, but it is nothing new. Remember that storage is inexpensive, but your data is extremely valuable. As an industry, we have been adopting storage strategies such as Redundant Array of Independent Disks (RAID) for years. The benefits of that kind of redundancy overwhelmingly outweigh the costs of the additional disk drives. Although data-splitting is not exactly the same as RAID, the concepts are very similar, as are the benefits and the return on investment (ROI).

Data- and key-splitting are not new, but their combination in an M-of-N approach to protecting object stores is quickly gaining traction. This is critical to the security, risk reduction and flexibility necessary to accelerate our pursuit of the cloud. We no longer need to trust the CSP or adopt a GUYK, GUYKAD or JTMD strategy.

With M-of-N cryptography, data-splitting and crypto-shredding strategies, you can stay in control of your keys and data and ensure that nobody else controls your object stores except you. This is just the beginning of how we secure the cloud.

Watch the webinar: Reduce Data Risk in the Cloud with Encryption