The Patchwork Cloud - Cross-border sovereignty issues in the cloud

  One thing I've recently been made painfully aware of is sovereignty issues when it comes to cloud computing.  I'm specifically referring to a situation where a consumer organization - let's say for the sake of argument that we're talking about a Canadian company - has restrictions on where it's data and services can physically be in terms of geographical locality.  In simple terms, a company here in Canada, depending on the regulations its under, likely has restrictions on whether it can have services or data hosted from a US-based cloud service.  This means any component of their cloud service cannot be outside the Canadian physical border.  This makes for an interesting exercise in technology and service mapping when it comes to cloud computing and utility.

 

  Imagine you're the ACME Corp. trying to find a public cloud service to host your retail application ...except due to regulatory and compliance restrictions Canadian citizen's data cannot be hosted outside the Canadian physical borders.  How would you, the consumer, go about making sure this is true during the procurement of such services?

 

  The fact is, that CIOs are challenged now more than ever to ensure the agility, security, resiliency, performance, and cost-effectiveness (among other things) of their IT services and this can create a challenging situation when it comes to cloud computing.  Being sure your data and services are within your sovereign borders is one thing when you're dealing with a single provider - but let's look at it from a cloud perspective.  More and more often services such as Software as a Service (SaaS) are being delivered "stacked on" one, two or many other services the customer may never be aware of.

 

  If you're purchasing a Software as a Service (SaaS) cloud service you load your data into your SaaS provider confident that their entire operation is within your country's sovereign borders.  Unfortunately, your SaaS provider uses multiple Platform as a Service (PaaS) service providers to deliver things like resiliency and performance so they're reasonably sure the services they utilize all reside within the same borders.  Where this gets complicated and out of control is when those multiple PaaS providers start to utilize various IaaS providers and Storage as a Service providers.  Odds are the storage provider never even knows they're doing business with ACME Corp. ...only that their downstream customer is buying services from them to build yet another service.  On the other side of that coin, there is a chance that your SaaS provider is unaware that your IaaS provider gets their storage from a company which has their service physically located in Canada, Switzerland, and California ...those last two don't meet your regulatory and compliance requirements.

 

  Since cloud computing is a paradigm of computing as a utility (or service) it's not uncommon to have these deeply nested relationships which aren't aware of each other several layers up or down, and if requirements aren't laid out clearly and investigated thoroughly it's entirely possible that regulations and compliance needs can be broken even with a reasonable amount of due diligence.  So how do you proceed forward if you've got these types of requirements and needs?  Do you simply stay away from cloud computing providers and build out your private cloud?  The answer is not mutually exclusive.

 

  While the question of public cloud cannot be dismissed simply because it requires complex relationships, thorough investigation and attestation, and complete situational awareness of services being delivered and consumed - there are some use-cases which make public cloud an unlikely and unfit option.  It's entirely OK to come to the conclusion that private clouds (entirely within your premise or sovereignty) are the only option.  There seems to be this prevailing conventional wisdom that cloud computing is right for all business models and use-cases ...this is simply not true.  I've had several conversations with CIOs and CISOs where the conclusion after a thorough discourse is to simply build a private cloud because public clouds were too high of a risk.  You can't always chase the "because it's cheaper we need to..." model of public cloud.  And heck, it's even a fallacy to say that public cloud is somehow always cheaper (but that's a story for another time).

 

  From the consumer viewpoint my advice to you is if you're facing these types of issues, is to simply take a deep breath and ask lots of questions.  Be thorough in your investigation and don't allow vendors to give you the "trust us, we're the experts" line because you're the consumer of these cloud services and you have the right to know ...and often the legal requirement to be fully aware of the environments you employ for your compute services.

 

  From the provider perspective, the advice isn't much different.  Be aware of what kind of service you're building.  Know the benefits as well as the limitations of your service.  Understand that it may not be right for everyone, and that sometimes compliance regulations dictate a no-go situation.  Most importantly make sure you're able to provide your consumers with as much information as legally allowable, and don't just do the typical vendor brush-off.  You should know where the physical and logical services you're potentially using as building blocks for your service are coming from, and who's managing them.  This is your responsibility.

 

  In the end, it's all about due care, process, and not rushing into a cloud computing migration because you heard it's the big buzz-word from your peers or from a trade magazine.  Take a rational approach and first understand the parameters from which you need to operate and the requirements you have.  Then enforce, with prejudice, those requirements on your vendors and know the potentially deep relationships that exist in the way cloud computing is delivered.  Let's measure twice, go in with our eyes wide open and aware, and then make the cut.

Comments
John Lawren James(anon) | ‎02-09-2012 08:58 AM

I can accept there is the risk that my data is going to potentially reside in another country, so long as I can identify what country that is, I'll store my data there as long as the risk is minimal.

 

What happens if I'm in Canada, the data is stored in UK.    Privacy-wise and data security-wise, both countries have similar data protection policies.   My concern is the route that my data is going to travel to get to me.  What happens if someone is port spanning and capturing my data as it passes through Romaina, or Russia, or perhaps China?   Routing issues like these have occured before

 

That is my concern.  My data is going on a holiday to a nation that does not meet my risk level, and I'm not even aware of it.

Omar Herrera Reyna(anon) | ‎02-09-2012 06:38 PM

Security decisions should not depend on perception but on sound risk assessment. Geolocation by itself does no cause problems, it is the environment that creates problems and many of the threats that we identify in a certain environment do not respect borders.

 

Take for example the case of firewalls and the network perimeter. There is no clear perimeter anymore (it almost got to the data itself) Where do you put the firewall? Even with the good intentions, trying to establish a perimeter at the borders of a country won't be effective. It may cause more damage than good in the end.

 

Also, from a risk perspective, foreign governments are not necessarily a threat (or even interested) in many businesses. If you are a manufacturer of defense equipment, it seems reasonable to consider foreign governments as potential threats. But what if we are a consulting firm offering consulting services for taxpayers in your country? It may be that the main threats (in terms of governments and competitors) are not located in foreign countries, but in our own.

 

Anyway, a chain is only as strong as its weakest link, and data security should be equally effective, no matter where it is used. When hiring external services (no matter if they are provided on or off premises, or within or outside our own country) we may share part of the responsibility for protecting sensitive data, but not accountability. Being accountable means that we still must ensure that good security measures in place. And good security should be reasonably effective, independently of the location.

 

We may not be able to change the mind of lawmakers other than by example, showing them that good security baselines do work and apply everywhere. Just complying with the different laws may help us avoid fines, but we are not really solving the problem, and eventually someone will find out that internal security should be strengthened (with yet more laws). Then we will get too much

bureaucracy that businesses will be hurt, then lawmakers will introduce simplify regulations to allow businesses to remain competitive, and then the cycle will start over again.

David WoelfleCTO (anon) | ‎02-12-2012 12:50 PM

Data Sovereignty is a real challenge.  For many organizations, both in public sector and regulated industries, ensuring that national or provincial legislation and regulation is met is a real requirement.  In Canada we are seeing this as a real barrier to cloud adoption.  The network issue (where did my data flow) is also real and requires additional measures.  In the ned it requires you to assure the following:

 

1)  The data stayed in Canada

2)  The support team is all in Canada

3)  The tools are all in Canada and controlled in Canada (including proxies, directories, server management, ....)

4) The network stays in Canada

 

Constraining the network may be impossible (Internet traffic can go anywhere after all).  Then encryption and other protections have to be invoked.

 

This problem isn't about potential risks and overstating an issue; It is about meeting our legal obligations to our clients and customers as IT providers.

DavidWoelfleCTO | ‎02-12-2012 12:59 PM

So the comments about this not solving the problem are very misleading.  The fact is non-compliance can cause much more than fines - you can find your company banned for multiple years from any government work, as well as facing all the costs of remediations, resolutions or clean-up from the exposure.  Not to mention the impact on your companies reputation.  The facts are that approaching this problem properly can help meet both your regulatory obligations, and improve your security.

 

Think about what it means in the end for a Canadian service provider (which is where I operate today):

 

1) I have to keep the data in country

2) I have to use only Canadian support staff for any tasks that COULD allow them to touch the data

3) I have to keep my tools, directories and controls all in Canada under the control of only Canadian staff.

4) I have to keep the network in Canada, or protect the data in transit (over the internet for example) with appropriate security (encryption anyone?) measures.

 

Further I should be addressing the overall security requirements for any environment that faces public or shared networks.  Start with simple measures:

 

- Encrypt data whenever it isn't public

- Control access to only those with a need for access

- Enforce separation of duties for secure roles

- Ensure appropriate logging and auditing are in place

- Provide for 3rd party audits

 

There is, of course, much more to establishing a full, comprehensive security posture, that also meets the requirements of data sovereignty.  However, a coordinated approach will help you address both challenges.  Failure to address either one could be disaster for you and your organization.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation