With the revelations of Edward Snowden, and almost daily reminders of how wide the surveillance net spanned, it should come as no surprise that customer confidence in the cloud would be shaken, and major cloud vendors would be under more pressure than ever to more effectively secure their customers' data.
Google's announcement that it would encrypt all data stored on the Google Cloud is definitely a step forward. But customers should read the fine print to understand how the change really impacts their security posture and what risks remain.
Effective August 15, Google announced all newly-added customer data would be encrypted on-disk. Existing data storage will be encrypted over coming months.
Google customers already benefit from network-based encryption, which protects data in transit between the cloud and the customer site. The real improvement here is Google now better protects physical data once it lands within their data centers.
This closes a major gap in Google's data storage model. The benefits of this change are:
- Customers have an additional level of data protection in cases where the physical disks which house their data could be compromised. For example, if someone sneaks a disk, out of one of Google's cloud data centers and tries to read the disk, they won't be able to read the encrypted contents of the disk drive.
- Under Google's scheme, each data “owner” has its own encryption key, so if one data owner's keys were compromised, the exposure would in theory be limited to only that company's data. But there is a catch, noted below.
- Customers who are required to comply with certain regulatory mandates (e.g. HIPAA) that require encryption of personal data “at rest” will be covered.
The obvious problem with this model is Google, as host to the “master” key, can encrypt all customer data. This makes the customer dependent on the human, or procedural controls, Google exercises over customer data.
Edward Snowden was a “rogue employee.” Will people someday see a headline where a rogue Google employee with access to these keys has sold a customer's data to one of the customer's competitors?
Google has tried to allay these concerns, and a spokesperson was quoted as saying:
"Of course, if you prefer to manage your own keys then you can still encrypt data yourself prior to writing it to Cloud Storage."
But customers who had already encrypted their data with their own keys before it was sent to the Google cloud would see no new benefit from Google's announcement.
If Google can design an encryption system that allows it to have a “master” key for all customer data, why not let customers create their own master keys offsite, so that even a rogue Google employee cannot get at their data?
A number of cloud vendors allow customers to create and maintain their own offline keys for online storage, and some make this a fairly painless process. This option would offer the best level of protection against compromise from within the data center.
Also, perhaps more importantly, Google should publish an overview of the procedural and technical controls it exercises over all employee access to customer data, not just the encryption keys. This would allow customers to assess the risks for themselves.
An example of a good set of procedural controls over access to customer data might look something like this:
A Google employee must formally request access and gain approval to a customer storage area before they can access the data. An ideal access control model process would include a formal access request process:
- The request should be electronically documented by the employee.
- The request should include the requested access time window and, if known, the specific data to be accessed.
- The request should be sent to the customer and a separate, supervisory Google employee for approval before access can occur.
- If both approve, then access can be granted.
- Any access to customer data by an employee should be logged and reported to the customer in detail.
- The customer should receive notification when the access time window has expired.