8 August 2010

Where is my Cloud?

Cloud Computing. A brilliant approach for data handling. Want to process a large data set (like client details) accessible in all of your firm's offices without the messy expense of buying and maintaing a data centre? Host it in "the Cloud".

But what, and crucially where, is "the Cloud"?


As a working definition, I'm going to say that "Cloud computing" refers to the process of using multiple network-connected computers and computer-based resources (including application software and storage media) to address a given information processing task. It's a powerful marketing term used to sell information processing services.

The pitch is simple: why bother buying your own data processing and storage hardware? It's expensive, it's difficult to maintain, and it becomes obsolete quickly. Why not, instead, use our "cloud facility" to process and store your data. You (the customer) can access this from any of your offices around the world securely using encrypted links via the Internet. We (the cloud computing provider) refresh our server and storage technology on a routine basis, and we have multiple facilities that provide massive backup and redundancy opportunities. If any single one of our server facilities becomes temporarily unavailable, you won't even notice because our other server facilities act as real-time backups.

This kind of service is provided to large customers by the traditional "big ticket" IT service providers. New market entrants, especially Google, also make a nice living delivering this type of service.

But none of them (today) likes to answer the question "where is the cloud". Customers who ask this question are often given unhelpful answers like, "the cloud is everywhere and nowhere". People who push harder may be told a real answer, such as "we have server facilities located in Cities A, B, C, D, and E".

So now we get down to the reason I'm writing about cloud computing in this blog. There are times when the geo-location of a data storage device becomes legally important. Law enforcement officials may wish to exercise lawful authority to search the device, but this authority is constrained by physical jurisdiction. Similarly, compliance with certain laws and regulations (especially data protection and banking laws) may limit how certain data is circulated internationally.

In one famous and very public case, a large international financial services organisation found itself in serious difficulty. This was because it complied with a lawful demand for information in Country A in which customer data was stored, but that compliance came at the cost of allegedly violating the law in Country B from which the data had been collected. The organisation's technically-driven desire to mirror its entire data set in multiple global locations eventually caused it to get caught in a "regulatory sheer force": complying with the law of Country A caused it (allegedly) to violate the law of a Country B. Business solution? Segregate the data by geo-location: keep the data collected in Country B only in Country B and do not store it in Country A.

(By the way, even this solution is not perfect. Country A might serve some form of legal notice on staff located in Country A and threaten them with sanctions unless the data is brought from Country B. In that case the solution is generally to split up the business so that they are not under a common system of control.)

Many businesses and government agencies these days increasingly push back on cloud computing service providers with a demand like, "Make sure that OUR data stays in OUR country". Puting the matter differently, they say to the service provider that it's OK to use a clouding computing solution with multiple sites and systems supporting the service - so long as OUR cloud is only in OUR country.

At an information security conference a few years ago, I was told about a Canadian provincial government that made early history in this arena. The provincial government was signing up to a data processing outsourcing arrangement with a US-based cloud service provider. The provincial government demanded that the service provider geo-locate all processed data physically in Canada. The service provider replied that "our system doesn't technically work that way". The Canadian provincial government held firm. Restrict geo-location of processed data to Canada or no deal. The service provider agreed and imposed business and technical measures to assure compliance.

These types of data geo-location restrictions are becoming more common in large cloud computing SLA's. Anecdotally I am aware of a number of such restrictions imposed on service providers in both large and small government contracts here in Britain.


Lesson for cloud computing service providers: if you have not done so already, start designing service protocols that allow you to restrict the geo-location of data storage and data processing activity. Today it's "value add". Sometime in the medium-term future (a few years ago I predicted no later than 2018 - I'll stick to that) it will be impossible to operate in this business space unless you are capable of delivering this type of geo-location restriction.