When you stop and think about it, what makes "the cloud" so appealing from a customer standpoint is the ability...
to consume exactly what you need. Anything below the level of the "application stack" you're using becomes a black box. This includes foundational infrastructure and technical components, support and operational mechanisms, hosting considerations and the like.
Once data enters the cloud, it might traverse many different data centers and geographic regions, be hosted multiple places simultaneously or be dynamically relocated as needed.
The cloud's ubiquity is a powerful concept because it allows customers to focus on other more business-pressing issues rather than all these technical details. However, there can be some unexpected outcomes as well. Because underlying details about a cloud service's implementation aren't always scrutinized, their effects on security can largely go unnoticed. This is often the case when it comes to where data is physically hosted. Customers rarely stop and ask about location when storing data in the cloud, but in some cases it can matter significantly.
Why location matters
While cloud services appear relatively static to customers, behind the scenes it can be anything but. Once data enters the cloud, it might traverse many different data centers and geographic regions, be hosted multiple places simultaneously or be dynamically relocated as needed. There are multiple reasons why this can happen. Cloud services providers may move data as a hedge against downtime (i.e., to mitigate localized outages), to reduce latency (by servicing requests closest to the point of origin) or to reduce costs.
Unless an enterprise specifically asks, it may never know the details of how, when and where different data storage locations are brought to bear in delivering the cloud-based services they consume. While from a service delivery standpoint this might be negligible, from a security and compliance standpoint this can have unexpected ramifications. In addition to possible legal and regulatory issues that can arise when data is stored in a location prohibited by contractual or legal obligations, possible audit and risk issues can arise as well. If, for example, your organization audits and vets a particular data center, what happens when data expands beyond those borders without your knowledge, or if data is relocated to a location with fewer or different security controls?
From a legal and compliance standpoint, consider that security and compliance efforts can become significantly more complex the more locations are involved. Because different jurisdictions have different laws and judicial processes, procedures for gaining access to data (e.g., to support law enforcement activity) might be above and beyond what your organization is comfortable with. Or certain locations might potentially violate regulatory or contractual requirements -- for example in the case of the European Union Data Directive, which limits migration of personal data beyond the borders of certain approved countries.
But it's not just the governing laws that can make this complicated. There can be regional differences between data centers based on cultural factors as well even within the same service provider organization. For example, an Information as a Service (IaaS) provider might decide to certify a specific UK data center according to ISO/IEC 27001:2005 in order to satisfy customer demand for that level of attestation, but where they have reduced demand (for example in the U.S.), the provider might elect not to do so. If customer data is mirrored between locations in the U.K. and the U.S., certain customers' control sets may not be met.
What you can do
Some organizations might decide for any number of reasons that they wish to control the migration of data based on location. For example, they might want to limit geographic region on the basis of governing regulation, due to customer contractual requirements, due to concern about foreign governments or because they have target certifications in mind for data centers. If this is the case, the question becomes how to achieve this outcome in a practical way.
Much of the wisdom given to cloud customers about controlling data location focuses on contract language and pre-engagement vetting: establishing service provider agreements that limit the localities in which data can be stored by a service provider, limiting engagement of services only to those firms that can commit to a fixed location where data will be stored, or evaluating services in depth prior to engagement and observing data processing facilities. This is useful advice and certainly something any organization should have on its pre-engagement checklist; as a practical matter, it's important to recognize that this is merely a starting point.
Specifically, what happens if an organization signs an agreement with a cloud provider, but later deems a data storage location as undesirable? If this sounds unlikely to occur, consider that there are a few ways this can happen: An organization might not have had location on its radar when first engaging with cloud vendors; individuals or business units may have engaged in a relationship without centralized oversight; or usage of a service might evolve over time to encompass other types of data than originally envisioned (what might be OK for public marketing literature might not be OK for the customer registry).
When dealing with an after-the-fact situation, pre-engagement vetting is probably a non-starter. Contractual negotiation likewise has limited utility -- there may be an opportunity to press the issue if the renegotiation cycle is imminent, but a customer in that scenario has already lost much of its leverage. Not surprisingly, procedural remedies might be challenging to effect -- at least in the immediate term.
Given this reality, it's helpful to look at what technical options might be available to bridge the gap. Note, though, the ability to address these issues via technical controls will depend on the type of service you're consuming. For example, many IaaS providers allow a customer to specify the data center locations in which its virtual instances are hosted. If they do not, but the customer does have access to the lower levels of the stack (Platform as a Service, or PaaS, and IaaS), one option is to look to other technical controls to address access at the logical rather than physical level. For example, if an organization is concerned about access to data by foreign governments, judicious use of cryptography might help to alleviate some of these concerns.
Addressing location is most challenging for shadow IT Software as a Service implementations. Options for procedural remedies are limited, and the ability to interact with the underlying layers of the stack to implement technical controls is likewise constrained. An enterprise can certainly pursue negotiation with the vendor in that case (they might, for example, be willing to customize their service given sufficient monetary incentive), but looking for alternative providers might be a cheaper path.
About the author:
Ed Moyle is currently director of emerging business and technology for ISACA. Moyle previously worked as senior security strategist for Savvis Inc. and as senior manager with CTG. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.