Enterprise Cloud Computing Blog

Cloud Storage

Is Encryption the Solution to Cloud Computing Security and Privacy?

Posted by Guest Blogger Erik Heels on Aug 04, 2011 at 7:30 AM

By Guest Blogger Erik Heels, Partner at Clock Tower Law Group, experts in patent law

Wikipedia defines "cloud computing" as "the logical computational resources (data, software) accessible via a computer network (through WAN or Internet etc.), rather than from a local computer.  Managing local computers is hard: there are security issues, computer lifecycle issues, accessibility issues.  Cloud computing, ideally, is easy: set it and forget it, access your data from anywhere, outsource your IT headaches to your service provider.  To end users, whether individuals or companies, "the cloud" is an abstraction, a computing environment that can expand to suit users' needs.

What's The Problem?

One problem with cloud computing is that both cloud computing providers and law enforcement agencies can access your files, usually more easily than if your stored the files on your own computer.

Also, security breaches, like the much-publicized Dropbox security breach, during which all Dropbox accounts were accessible to all users without any password protection, can occur in the cloud.

For users, it is important to know whether your data is secure, who can access it, and what happens when there is a security breach.

For service providers, it is important to comply with both US and non-US laws including (1) data retention laws, which are ostensibly designed to help law enforcement entities do their job and (2) data disclosure laws, which are ostensibly deigned to help users know when their private information has been compromised.

Is Encryption The Answer?

Most cloud computing providers (1) authenticate (e.g. transfer usernames and password) via secure connections and (2) transfer (e.g. via HTTPS) data securely to/from their servers (so-called "data on the wire"), but, as far as I can tell, none (3) encrypts stored data (so-called "data at rest") automatically.

So if you want your data to be secure in the cloud, then consider encrypting the stored data.  And don't store your encryption keys on the same server!  It is unclear whether a cloud computing provider could be compelled by law enforcement agencies to decrypt data that (1) it has encrypted or that (2) users have encrypted, but if the provider has the keys, decryption is at least possible.

I have used and abandoned both Microsoft's Encrypting File System (EFS) and Apple's FileVault for encrypting data on my desktop computers.  But desktop encryption is painfully slow! Perhaps cloud computing providers can leverage the power of their data centers to make the performance hit of encryption-decryption imperceptible to the user.  That would be cool.  And would make the benefits of cloud computing greatly outweigh the risks.

Here are three security questions you should ask of your cloud computing provider:

  1. Data on the Wire.  Are files transferred to/from cloud servers encrypted by default?
  2. Data at Rest.  Are files stored on cloud servers encrypted by default?
  3. Data Retention.  If files on cloud servers are encrypted and there is a request from law enforcement to decrypt the data, then what do you do?  Bonus question: What if you have the key(s)?

I searched for answers to these questions for four cloud computing providers (sourced in part from TechTarget's list of top cloud computing providers and Wikipedia's list of cloud computing providers) that are popular with small businesses like mine:

Simple Google searches of these providers' websites provided more questions than answers on the topic of encryption:

Cloud service providers need to do a much better job of communicating what is and what is not secure about their offerings.  For example, I would characterize Dropbox's security page as misleading at best:

"Your files are actually safer while stored in your Dropbox than on your computer in some cases. We use the same secure methods as banks and the military.... Like most online services, we have a small number of employees who must be able to access user data for the reasons stated in our privacy policy (e.g., when legally required to do so).  But that’s the rare exception, not the rule."

Just because your files are transferred securely to Dropbox does not mean they are stored in an encrypted format on Dropbox's servers.  And it is the "rare exception" that is, or should be, the concern of users.

For More Information

Summary

As more individuals and companies move their computer files and computer applications from local client computers (over which they have a great deal of control) to remote server computers (over which they have limited control), security becomes a bigger concern - both for users and for service providers.

Erik J. Heels is an MIT engineer; trademark, domain name, and patent lawyer; Red Sox fan; and music lover.  He blogs about technology, law, baseball, and rock 'n' roll at ErikJHeels.com.  His law firm, Clock Tower Law Group, represents cool companies such as CloudSwitch.

File under: , , , ,
1 comment(s) so far...

Moving to the Cloud: Key Considerations for Cloud Storage

Posted by John Considine on Oct 27, 2009 at 8:00 AM

This post is part of a series examining the issues involved when moving applications between internal data centers and public clouds.

The true challenges in storage and data management in the cloud result from the diverse and often unfamiliar processes and infrastructures offered by the cloud providers, including: new provisioning methods, storage properties, data population and transfer, and systems for data management (snapshots, clones, replication, backup). The cloud providers define the relationship between servers and storage and often impose constraints on everything from allocation size limits to the ways in which storage is managed. These are just some of the things you’ll want to consider as you start to think about integrating cloud computing into your existing IT environments.

I’d like to focus in detail on the complexity and variability of cloud provisioning and storage properties. There are different models for storage in existing compute clouds, with the most common being an “inclusive” storage model. In this model, each server comes with a certain amount of storage attached to it. The storage is a fixed capacity that is provisioned when you create the server from the pre-existing templates.

For example, Rackspace gives you disk space that is proportional to the memory (RAM) size you select.  The smallest memory/disk combination is 256MB of memory with 10GB of disk. With each doubling of memory, the disk space is also doubled until you get to roughly 16GB of memory and 640GB of disk.  With the new Terremark vCloud Express, you get a system disk that is predefined for each “template” server you select.  For a standard Linux distribution, you get a 10GB system disk, for Windows 2K3 you get a 20GB disk and for W2K8, you get a 40GB disk. Terremark’s vCloud Express allows you to add additional storage as new disks, while others (like Rackspace) allow to “resize” your servers and storage to create a new server with a larger disk and copy your data into it. 

Amazon offers several distinct types of storage within EC2. The default storage you get with each server you create in the cloud is called “ephemeral” storage. You then have the option of allocating and attaching Elastic Block Storage (EBS), and there is also an object store system called Simple Storage Service (S3).  Ephemeral and EBS are standard “block storage” devices – meaning they are viewed and used as disks attached to your server (/dev/sdg in Linux, D: in Windows) while S3 requires an API or other tools to integrate with your systems. The good part about the EC2 storage offerings is that you have some powerful options as you build for the cloud; the hard part is mapping the proper resources to your applications and integrating this with your existing processes. Specifically, the base storage is ephemeral, which means that if you power-off the server, or it has a hard fault, all the data on that storage is lost. This means that everything on these drives (boot parameters, application updates, user data, logs, etc.) is subject to loss when you power off the machine. There are several methods of handling this situation: 1) Build your servers every time you start them from a formula or other sources such that you don’t depend on the base storage being persistent; 2) Use Amazon or third party tool sets to periodically “bundle” your servers into S3 (effectively taking a snapshot of the server); or 3) Attach EBS storage to your image and store your important data on persistent storage.

Turning to granularity, we find a wide range in the units or increments of available storage in the various cloud providers. There is the “included” storage mentioned above that is often based on the size of the server and the requested OS type. To add storage, we find cloud providers (such as Amazon) allowing 1GB increments up to 1TB, and others (like Flexiscale) allowing only fixed increments of 50GB/100GB/250GB. For Rackspace, you can resize both the server and storage according to the defined fixed ratios, but these are bound to memory and CPU so there is no independent scaling of storage. The bare-metal cloud provider NewServers allows iSCSI storage to be attached to your servers in 250GB increments. In the cloud these varied increments really matter, because you are paying by the GB/month and if you need just a little more storage, you could end up having to purchase 10x more storage than you need, or having to pay for more memory and compute than you need.

The conclusion we can draw is that there are numerous storage configuration options in the cloud, and these options become linked to the server “flavors” defined by individual cloud providers. Because you don’t have the same control or even mechanisms in the cloud as you do in the local data center, the manner in which you allocate, populate and manage data in the cloud will be different. The work you do to understand and map your applications’ requirements into cloud-based storage requires changing your processes to match those of the cloud, and often this work is cloud-specific. 

Beyond configuration issues, of course, there are many other concerns. For example, with data management, you have to determine how you will get your data into the system, how to grow your systems and how to protect your data. Right now most clouds use template servers that you have to build up from a pre-installed base operating system using update mechanisms and then re-installing the application components. As for protecting your data, there are also many cloud-specific options available – from RAID-protected EBS in Amazon, to data snapshots and cloning, to backup services offered by companies like Rackspace.

The bottom line is that cloud storage can be simultaneously simple and complex – just like cloud computing in general. It’s simple to use if you just want to try something new; complex if you want to integrate cloud storage into your existing processes and infrastructures.

Next: Networking in the Cloud

File under: , , , ,
0 comment(s) so far...