How location is crucial to cloud data security

Anyone who has ever dealt in real estate—either buying a house, renting, or just living with someone in the industry—has heard the mantra "location, location, location." As it turns out, location matters in the cloud, too. In particular, if you work for a regional or global company, you’ll find that certain governments, regional political entities (eg. the EU), and industries impose restrictions on where specific types of data can physically reside.

These jurisdictions apply regulations that protect individual and corporate data privacy pertaining to their citizens, public entities, or private sector firms. The most sensitive data of which, Personally Identifiable Information (PII), can be used to identify, locate, or contact specific individuals. Typically, the governance and compliance requirements that they specify require one or more of the following:

  • PII and other data must remain physically resident within the jurisdiction.
  • PII and other data must be protected from viewing or alteration while in transit at all times.
  • PII and other data must similarly be protected while being stored (at rest), at all times.
  • PII and other data must not be physically transmitted outside of the jurisdiction for any reason.

Given these restrictions, you might think that a cloud-based solution—which runs applications and stores corresponding data and documents centrally, reachable by virtually any user from anywhere around the globe—would be out of the question. The good news is, that's not the case!

In the course of assisting our customers globally, Bluewolf has teamed with salesforce.com (and other vendors) to offer solutions that address this "data residency" challenge. Each of the available solutions in the market employs a similar architecture consisting of one or more servers physically located within a jurisdiction that work together to:

  • Intercept data (fields, email addresses, documents, and more) in transit between users and the Salesforce platform.
  • Encrypt (or tokenize) the data, sending only the tokenized versions to the Salesforce platform for storage.
  • Maintain the set of encryption keys (or token dictionaries) required to unscramble the data in a local server.
  • Decrypt (or de-tokenize) the data in the return path to the user, upon request.
  • Store encrypted (or tokenized) documents either internal to salesforce.com, or in an external FTP server or other file store in their own network (or trusted data center).

The “secret sauce” of this approach is that the architecture ensures that PII and other data being protected never leaves the jurisdiction where it is intended to reside. The set of servers that perform encryption/decryption, store the corresponding keys and token dictionaries, and manage the tokenized documents are all physically located within the jurisdiction. Et voilà, we are in compliance!

Of course, there will be tradeoffs. For example, nearly all solutions will have the following limitations:

  • Not all field types are supported. For example, there may be limitations when selecting currency, date, date/time, number, percent, checkbox, or picklist fields for protection.
  • Data within protected fields in object records will be encrypted (or tokenized), so it won’t be readable—users will see the cipher text, not the original field values.
  • Records and reports will have to be "routed" back through the same servers that performed the original encryption (or tokenization), as only those servers have the corresponding keys (token dictionaries) required to unscramble the data.
  • Embedded text that appears within dashboard images may be scrambled (since such images are generated on the server before being sent back).
  • Certain types of program logic need to be carefully considered for the impact of encryption (or tokenization). For example—depending upon the algorithm used, and the vendor—certain formulas, comparisons, text manipulations, etc. may not work because the data within the solution is encrypted (tokenized).

Certain vendors have developed clever algorithms that preserve critical application functionality. For example, they may offer encryption or tokenization schemes that still allow fields to be compared, searched, and sorted lexicographically in their encrypted (tokenized) forms. There are other considerations as well, such as the choice of encryption algorithms, encryption key management, token dictionary management, data type support, web services support, API support, and other differentiators that separate the various offerings. 

The good news is that the best solution for you is out there, and with the rapid pace of innovation, the options are abundant. All the benefits of cloud-based services such as salesforce.com can be realized even without compromising sensitive data in complex, multi-territory, multi-jurisdictional situations. Isn’t that reassuring?

It’s nothing like trying to snag a two-bedroom flat in a prime location at a reasonable rent…now that’s a challenge!

Related Stories

Leave a comment

Alternatively

This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.