A few weeks ago I posted on different methods for encrypting IaaS volumes, which tends to be one of the top questions I get about data security in the cloud. Also high on that list is encrypting (or tokenizing) for SaaS and (some) PaaS. I call this the “Salesforce.com Problem”, because more often than not I’m talking to someone on the larger side, specifically about Salesforce.com.

Before I go into options, I need to explain why I’m only talking about some PaaS. PaaS covers a very wide range of technologies – from Database as a Service, to things like Google APIs, to full-on application environments like CloudFoundry and Elastic Beanstalk. For this post I’m mostly restricting myself to SaaS-related PaaS like Force.com. In other words, API interfaces to things you can also run completely via a web interface. I know this is a grey line, and in some future post I’ll go more into detail on encrypting for the rest of PaaS. Just recognize that the core architecture described here works for cases beyond this scope, but some of the issues & details may not apply.

There are only two options for SaaS encryption:

  1. Encrypt it at the SaaS provider.
  2. Encrypt it before you send it.

To review quickly, when analyzing encryption systems we look at the locations of three components: the data, the encryption engine, and key management.

If your SaaS provider handles the encryption on their side, they hold all three components, so this option requires trust in your provider. Yes, there are many subtleties and options that dramatically affect security, but at the core the provider needs the key and the data at some point. The advantage (for you) is simplicity and flexibility.

But if you don’t trust your SaaS provider, you’ll need to encrypt on your side… which means increased cost and complexity.

If you encrypt it before you send it, there are two options:

  1. Encrypt in a client application before uploading the data.
  2. Proxy connections and encrypt at the proxy.

The first option is common for things like backup applications, but as I mentioned that’s more PaaS – the part we aren’t talking about here. Espcially because the vast majority of the apps I am talking about today are web-based.

So most organizations I know which are looking to do this are evaluating proxy-based solutions such as CipherCloud, PerspecSys (maybe – their website sucks and doesn’t mention how they work), and Navajo Systems.

These are application-aware web proxies that intercept browser calls to the SaaS provider and replace sensitive data with encrypted or tokenized values. Instead of connecting directly to the SaaS provider, users go through the proxy. You configure it to encrypt or tokenize sensitive data, although instead of defining every field on every form you should be able to say “account number” and have the product automagically replace it everywhere.

In some future post I’ll delve into this architecture in more depth, but there are three main challenges to this approach:

  1. The product needs to stay totally up to date with any changes with the SaaS provider UI/application. When you are intercepting and rewriting HTML fields on the fly, you really need to know exactly where they are.
  2. Users need to connect back through your enterprise, or a trusted web-based host (e.g., running the proxy at Rackspace). For your internal network, this means you’re back to running VPNs. If you host on the outside, you have another party to trust but can handle it with bookmarks or such. If you use a cloud-based web proxy for URL filtering and content security, you might be able to map it up there.
  3. You might break application functionality/usefulness. This requires a lot of translation, which affects SaaS features that rely on the protected data. This becomes more of an issue as you protect more fields and data types – the more you obfuscate, the less your SaaS app can process. (It can still process the un-tokenized data).

Because of these challenges I tend to regard this proxy approach as a band-aid for SaaS. It’s definitely not ideal, and a heck of a lot of work for the vendor to keep up and running. I believe it makes more sense for PaaS, where you rely more on APIs than HTML interfaces.

In all cases I think the web proxy approach is best used for very discrete and limited data – otherwise there is too much potential loss of core application functionality, at which point you might as well stick to internal systems.

Share: