Clouding the encryption issue.
Another fun topic to consider when you’re defining cloud governance is the use, support and administration of encryption.
The way I see it, there are two main types of encryption use: let’s call them container encryption and content encryption.
Container encryption is wrapping some data in encryption, usually to move it from place to place, but also if you’re just protecting it as one big blob. Examples are SSL (building a tube just to get data safely from A to B—or, as Spaf puts it, getting it safely from the cardboard box to the park bench), whole disk encryption, flash drive encryption, and media encryption.
Content encryption is used to protect particular data, no matter which form it’s in or where it’s headed. This includes file-level encryption, email message encryption, and anything else where you are protecting it for dedicated use by an intended recipient.
When do you use one versus the other? It depends upon which threats you’re worried about. More to the point, it depends upon whether you trust your provider. If all you use is SSL, you’re clearly not concerned about your web administrator or your system administrator; you just want to make sure your session can’t be hijacked by outsiders. If you’re worried about internal threats as well as external ones, you’ll prefer a separation of duties enforced by having someone else manage the encryption keys on data that cannot be accessed in any other way, at any time, without decrypting it.
Let’s say that you have confidential data that you want to protect “at rest.” (I use the quotes because in my opinion, data isn’t truly at rest unless it’s on a host that is turned off. The rest of the time, even if it’s not actually on stage, it’s in the green room.) In one scenario, you let your cloud provider decide which encryption product to use (as long as the algorithm is approved), you let him install it, and you let him manage the keys on behalf of you and your users (and his other cloud customers). In the other scenario, you do it yourself, and just let the provider run the rest of the layers.
Do you have a provision model where the vendor only administers the operating system and shouldn’t have any need to access the data you’re protecting? If you’re encrypting the entire hard drive on a laptop, you’re going to need to let your PC support person access it in order to diagnose problems, perform upgrades, and—oh yes—issue you a rescue token when you forget your passphrase.
This model makes a difference when you’re talking about encrypting backups. Do you take already encrypted data (to which the administrator has no access) and write it as-is using a regular backup utility? Or do you only encrypt it on its way off to tape, because the only threat you’re worried about is the Iron Mountain guy who leaves the tapes stacked outside the cafeteria entrance while he gets himself coffee on the way to the offsite storage?
Your provider will probably understand your need for SSL over the Internet. He may or may not understand your demand for SSL within the cloud. He’ll assure you that he’s got plenty of measures in place to separate your data from the data of his other customers. But unless he’s very security-savvy, you’re going to have a fight on your hands when you talk about installing and administering your own encryption, because he can’t conceive of you seeing HIM as a potential threat.
UPDATE: Completely missed that Rich Mogull is, as usual, a step ahead of me. And he brings up the idea of data monogamy, which I like.
Posted by shrdlu on Wednesday, May 20, 2009
(0) Comments • Permalink •
