September 10, 2010, 2:05 PM — Forrester has been putting out really interesting reports on cloud computing lately. I discussed one of them in a recent post entitled "Cloud Computing: Whose Crystal Ball is Correct," which addressed the topic of private clouds. In that post, I examined Forrester's James Staten's point that implementing private cloud computing requires far more than buying vSphere and a few add-on modules-it requires standardization, process re-engineering, and organizational alignment.
This week brought another excellent report from Forrester, "Compliance with Cloud: Caveat Emptor," written by Dr. Chenxi Wang, exploring the challenges raised by the collision between data compliance requirements and cloud computing real-world offerings.
As Dr. Wang notes, most data compliance laws and regulation are written with an assumption that the liable party controls the infrastructure data is stored on as well as the placement decision about where that storage is located. Practically none of the laws and regulations recognize that a service provider may hold the data on behalf of the liable organization. Therefore, most compliance situations assign all of the responsibility to the user of a cloud computing environment despite the manifest fact that much of the control of the data is out of the hands of the user.
Several things about Dr. Wang's analysis stood out to me:
1.It may be easier to learn where an IaaS provider's data centers (and therefore, data storage location) are than for an SaaS provider. Google is identified in the report as not being able to state, definitively, where one's data is hosted or that its location will be restricted to any given region. Obviously, any opaqueness about location causes a real problem for users to ascertain if they are in compliance with applicable laws and regulations.
2.Only one law is identified as specifically recognizing the role of a service provider-HITECH for HIPAA. All other laws and regulations leave all of the responsibility with the user. At HyperStratus, we refer to this situation as asymmetric risk -despite the fact that compliance is a shared responsibility, most or all of the risk falls upon the user.
3.Those who trumpet that cloud providers accept responsibility for legal compliance measures overlook an obvious difficulty-cloud providers often don't know what data is being stored in their infrastructure and can't know what legal conditions apply to the data.
For a company like Amazon, the fact that someone can begin executing a cloud-based application with nothing more than a credit card and an account id means that it has no way to validate (or indeed, even understand) an application's compliance requirement. This is worth repeating-absent a discussion, there is no way for a cloud provider to have any idea what measures should be taken for compliance reasons-so insisting the cloud provider step up and meet compliance requirements may be unrealistic.
4.Cloud-based PCI doesn't really exist. Dr. Wang states that achieving PCI compliance appears to be economically unattractive for cloud providers, so most cloud providers don't bother. The standard recommendation we make is to place the application in a cloud environment and to make PCI-oriented calls out to another service provider that specializes in PCI compliance.
In terms of recommendations, Dr. Wang proposes two types of compliance measures:
1. Assess: One approach is to assess a cloud provider's compliance situation by discussing (and perhaps auditing) their compliance measures. I don't necessarily think this is bad advice, but it may not be practical for all users, since a cloud provider could easily be overwhelmed by customers wanting to sit down and discussing implemented measures. In any case, the interaction-heavy model is a poor fit for many cloud providers who want to provide low-cost, low-touch service. There is an effort afoot to develop a standardized cloud audit description that could be accessed remotely in an automated way. This is a far better match for the direction computing is heading in, and holds the potential that a standardized description could be accessed as part of a provisioning workflow and direct the resource placement decision from a rule-based engine.
