Ensuring Enterprise Data Privacy in Saas Offerings

Ensuring Enterprise Data Privacy in Saas Offerings

Ensuring Enterprise Data Privacy in Saas Offerings

enterprise data privacy in SaaS

Data Privacy is widely regarded as individual liberty or right – which it most certainly is. But the importance of privacy for enterprise data is rarely if ever discussed. Any conversations around this get conflated with security – and there is a pervasive misunderstanding that security equals privacy when it comes to enterprise data.

In this blog post, we will look at why data privacy is important for enterprises and why just securing the data in the cloud (using techniques like encryption) is insufficient. We will also discuss commonly seen key management strategies and their relative pros/cons.

There is a pervasive misunderstanding that security equals privacy when it comes to enterprise data.

“Trust-Me” privacy model

This is unfortunately how the vast majority of the SaaS world still operates. Many SaaS vendors sell the story that data is fully encrypted at rest – which is true. What they fail to say is that they also retain the ability to decrypt customer data if they choose to. Sure, there are legal clauses and confidentiality agreements with employees that act as deterrents and their technical support team is allowed to have “limited access” to your data and only “with your permission” etc. – but the reality all this language masks is that there is no technological barrier that prevents the SaaS vendor or their employees from accessing enterprise data.

What makes matters worse is that SaaS companies are also governed by the laws of the land, and governments across the world are applying more demands on SaaS and cloud vendors to share data in decrypted form – many times without following a due process that involves getting a subpoena or informing the organization about the demand for their data.

Many SaaS vendors sell the story that data is fully encrypted at rest – which is true. What they fail to say is that they also retain the ability to decrypt customer data if they choose to.

BYOK – Segregation of Duties

A common remedy to the “Trust Me” problem is a concept called BYOK (Bring Your Own Key). The idea is that you “segregate” or “separate” duties by having the SaaS vendor only be the “data store”, while allowing the customer to decide who gets access. So, by allowing the customer to control the keys used for encryption, access to the data is controlled by the customer – thus achieving data privacy. The concept is sound, but how it actually manifests itself in practice is questionable.

Most SaaS offerings that allow BYOK do this by simply encrypting data using their own key, and then using the customer-provided key (BYOK) to encrypt the encryption key itself. Any customer accesses to their data requires them to provide the BYOK, which is used to decrypt and gain access to the actual key used for encryption. Unfortunately, many SaaS vendors retain the ability to decrypt data if they wish to because there is no technical barrier that prevents them from using the original encryption key directly.

KMS or HSM

Doing BYOK right requires a strong and trusted Key Management Service (KMS) or a Hardware Security Module (HSM). There are techniques like Double Key Encryption (DKE) espoused by Microsoft or Envelope Encryption, espoused by Google which can achieve strict segregation of duties using an unbiased 3rd party KMS or HSM. The problem however is that most KMS and HSM services are provided by the same cloud vendors that host the SaaS solution which can raise questions of neutrality and separation of duties. Unfortunately, the cross-operability of these services across different clouds is also highly limited. So, for a customer to be able to truly rely on a common service across all their applications requires housing a KMS themselves – which can be expensive and not worth the hassle. And on top of all this, not all SaaS solutions may lend their keys to be managed via KMS’es or HSMs either.

Passphrase-based key

A model that cuts through all this complexity is to simply let the end-user have complete control over the encryption keys. This is typically done by letting the end-user type in a passphrase known only to them – which is used to form their encryption key. The encryption then happens right at the end-user system and only encrypted data travels to the SaaS cloud.

This is a pretty fool-proof method and guarantees privacy – except each end-user has to remember their passphrase and if they forget their passphrase, their data could become inaccessible. Worse, if the end-user leaves the organization, and doesn’t provide anybody the passphrase before their departure, the organization loses access to their data entirely.

Enterprise controlled keys

The best of all worlds would seem to be an enterprise-level key, but a single encryption key used for all the data in an enterprise is a high target vulnerability and a single point of failure. What would be ideal is a per-user key, which is unique and system generated, but with the ability for the enterprise to change at any point in time.

This is not as difficult as it seems once you realize that the enterprise doesn’t really need to preserve, protect or remember the user encryption keys – as long as a reliable software system in their control can do all of that for them. They just need the ability to change the keys at any point of time (or a periodic interval) to protect themselves from possible theft. This can be accomplished by giving the enterprise IT administrator control over one portion of the keys – which when combined with other algorithmically generated variables – forms a unique user key on the fly.

The process will be predictable and repeatable, and has the following advantages:

  1. Per-user keys – so no single point of vulnerability or failure
  2. Users don’t have to remember their keys, passwords, or a passphrase
  3. The IT Administrator has control over one part of the key (call it an IV or Initialization Vector), by changing which all user keys are automatically regenerated
  4. The IT Administrator doesn’t have to remember this IV or commit it to memory – but they can change it at any time. 

The keys never have to be persisted anywhere. 

  1. Only the IV is persisted and in encrypted form.

Most SaaS services do Model 1, some say they do Model 2, but do so sub-optimally. Some consumer-based services provide Model 4.

If you want Model 5, which provides true enterprise-controlled data privacy, check out Parablu’s BluVault Backup As A Service. We have perfected the Enterprise-controlled encryption key model which succeeds in providing the highest level of security without compromising data privacy or convenience.

At Parablu we specialize in building data management solutions like Backup, Archiving, Content Collaboration and File Sharing. We offer solutions that are hosted as well as on-premise. Our unique solutions can also integrate with existing subscriptions you have like Microsoft 365 or Google G-Suite and save you a ton in terms of the storage costs associated with Backup.

Write to us at info@parablu.com to learn more.

Do you have specific requirements or enterprise needs?

Share the Post:
Scroll to Top