Security risks of multi-tenancy

Security risks of multi-tenancy

Summary: To dispel some of the confusion about security and to help people evaluating whether to go multi-tenant, here is a quick overview of the main risks.


One of the concerns expressed by both users and experts attending Cloud Computing Congress in London this week was the risk of data being exposed to third parties in a multi-tenant environment. There seems to be a lot of confusion on the matter, so I thought it would be useful to blog a quick overview that may be helpful for people evaluating whether to go multi-tenant.

Intuitively, we feel that if our data is physically on the same computer system — or, in a fully multi-tenant stack, actually in the same database — then there has to be a higher risk of data being exposed. Either inadvertently, when for example a software bug or system mulfunction gives access to a user of another system on the same shared infrastructure. Or maliciously, when someone exploits some weakness in the architecture to gain illicit access to data.

In theory, there is some truth in this intuition. But in practice, it depends what level of multi-tenancy we're talking about and how rigorously it has been architected. The theoretical comparison assumes the same security regime in both cases, whereas in real life, the provider of a multi-tenant service is going to put a lot of expertise and resource into making sure its infrastructure is as secure as possible against this kind of data exposure, which would be very bad for its reputation. Most multi-tenant systems are operated to much higher security standards than standalone systems. Look at it this way: in theory, a single house with a fence around it is much more secure than an apartment in a block shared with many other households. In practice, the householders in the apartment block will pool the cost of having a porter on duty 24x7 to control access to the building and monitor security.

There are two main risks to be aware of, depending on what type of infrastructure you're looking at. The first risk applies to a virtualized infrastructure, where a single physical machine hosts many separate virtual machines. There is a theoretical risk that one of the machines in this kind of setup could monitor what its neighbours are doing, burrowing into the underlying infrastructure to bypass security implemented at the software layer. I'm not aware that anyone has shown they've been able to do this in a commercial cloud provider environment, but in theory the risk applies to anything from an infrastructure-as-a-service provider such as Amazon EC2, all the way up to a SaaS provider who is keeping customer data in separate virtual databases.

Some Gartner research that's been publicized this week will fuel the anxieties of those who aren't yet ready to trust multi-tenant clouds, but in fact the detail of the findings bears out what I've said about security measures. Gartner found that 60 percent of virtualized servers will be less secure than the physical servers they replace. But this is not because virtualization is inherently insecure, says Gartner's Neil MacDonald. It's because the people implementing this new, unfamiliar, technology aren't doing it right. "Most virtualized workloads are being deployed insecurely. The latter is a result of the immaturity of tools and processes and the limited training of staff, resellers and consultants," he explains.

Gartner provides a list of six risk factors that it says should be addressed. I'm sure that most cloud providers will already be on the right side of all these risk factors. It is internal enterprise virtualization projects that are neglecting them (some of which, please note, apply to projects that host virtualized servers on cloud infrastructure, but are still about user best practice rather than the provider's infrastructure itself).

Risk number two is the risk that your data will inadvertently get exposed to other users, due to poor implementation of the access management process or some kind of software bug. People are most conscious of this risk in a multi-tenant database, where every customer's data is stored in the same tables, but it also applies where only the application code is shared, since a simple slip could result in redirection to the wrong database. If there's a vulnerability, it could be maliciously exploited, but most of these episodes are cases when a user logs into their system as normal and discovers they're looking at someone else's data. The best known cases of this have been in the online banking world (which hasn't stopped people using online banking, by the way).

The fact that, in theory, there's a greater inherent risk of this happening means that, in practice, providers go to great lengths to ensure that it never does. It is a very simple matter to flag data as belonging to a specific customer and then make sure that flag is always respected when reading data. Providers build and test their software to design out the risk of these data leakages.

It comes down to trust and confidence. Knowing these risks, do you believe your provider will have done what's necessary to prevent them occurring? It's also important to weigh up the risks your data is exposed to if you don't use a cloud provider. How secure is it kept on-premise or in a third-party hosting center under your own control? There's a tendency to distrust multi-tenancy simply because it's new and less well understood (and requires us to trust a third-party provider), but we too readily forget the shortcomings of more familiar environments.

One final consideration to bear in mind is the law. There may be types of regulated data that, because the law was drafted before virtualization became commonplace, forbid the hosting of data on a shared infrastructure. Unfortunately, the only way to get round this — even though the unintended effect of following the law may be, paradoxically, to make the data less secure — is to get the law changed.

Topics: CXO, IT Priorities, Security

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • One more risk

    The biggest risk you have is your own staff, this is something we all agree on, estimated 90% of security risks are insiders. But when you put your data in the cloud the added risk you have added is the cloud providers staff.
    90% of security problems are internal. And this goes for your cloud providers staff as well. You have disgruntled staff at the cloud end and to make their employer (soon to be former employer) look bad they expose their employers customers data to the net.
    This happens at businesses, we see it in the news all the time, and there is no way to know this won't happen in the cloud.
    Now cloud providers will tell you that they vett their stff, do security checks and the like. Don't we all do this? Does it actually decrease the risk of insider attacks?
    Consider this; A company decides to downsize or even just move people around, some employee gets angry, boom, through no fault of yours and with no way to prevent it that employee of your cloud provider dumps all of your data onto the net.
    So if 90% of security threats are this exact problem, how much added risk have you just added to your information by putting it in the cloud?
    Just my opinion, please tell me I am wrong.
    • This is what ISO standards are for

      Access to data about you as a customer is very different than access to the data you keep about your customers.

      Legit SaaS providers with appropriate security certs (ISO 27001, SAS 70 Type II) have blocked their employees from client's data with documented, audited, and approved methodologies. Put simply - their employees, can't, don't, and never will have access to the data their clients keep within their hosted services.

      The majority (if not all) of "disgruntled employee" stories occur at private companies where critical third-party data is not secured to these same standards.
  • Watch Out For Back Doors

    Some 25 years ago, I was working at a company using an accounting system running on *nix. This software was meant for larger companies than mine; and it was capable of either multi-company or multi division reporting.

    Depending on how it was installed on the computer, this implementation could be set up such that each company (or division) had its own set of data files; or be co-mingled. In a co-mingled set up; if the sysadmin DID NOT delete the default login in account; anyone who knew it HAD COMPLETE ACCESS TO ANY AND ALL company (or division) data records. In the event the sysadmin failed to remove the development system, practically any code monkey could create a simple screen that laid bare the data for any record for any company (or division).

    I mentioned this to the VAR that sold us the system, and they discounted it. Seeing was believing, and only after a demonstration, did they realize I was right! I could best characterize the reaction as "OH S---!!!!"