One of the most common questions about cloud security is around privacy and regulatory compliance. Questions around government mandates and industry requirements abound from IT managers considering a shift to the cloud—most of which relate to multi-tenancy.
Since there’s been so much discussion about multi-tenancy in the cloud lately, I thought I’d explain what it means for both cloud providers and cloud customers.
But first, a tangent:
I live in an apartment. I have a small apartment that has everything I need. I enjoy living in an apartment because I don’t have to maintain the plumbing or electrical. I don’t have to rake the yard or clean the gutters. I don’t have to clean the pool or fix broken equipment in the gym. I don’t have to worry about security; it’s provided as part of my rent. I only have to worry about my belongings in my apartment. As a result, I get to enjoy the cost savings of a shared environment, and the robust amenities of my building. My apartment building has lots of other residents. Some work different jobs, some work at different companies. But we all share the same building, with the same resources and amenities.
My apartment building is a multi-tenant cloud. More on that later.
Cloud providers (landlords) love multi-tenancy clouds (apartment buildings) because they rent the same resources to a large number of renters, and the renters get to enjoy all the financial savings of those shared resources. The cost savings is good news to all parties involved. The cloud, as you know, can provide amazing cost savings, fantastic up-times and someone else to blame or sue when there is a mistake, when there has been an accident or if problems go unfixed.
Today we’ll talk about security, reliability, auditability, quality of service and regulatory compliance in multi-tenant solutions vs. single-tenant solutions.
In my apartment building, there is a bank of washers and dryers. Everyone can use them—10 washers and 10 dryers for 300 families. But if the power goes out in the laundry room, we’re all wearing dirty underwear. This is a multi-tenant problem.
In the cloud, when a multi-tenant app goes down, it takes everyone with it. Take WordPress. They went down a few months back. One app down, everyone went with it. Imagine other Web apps out there. What if Salesforce went down? What if Gmail went down? One App. Life stops. Now what if that’s an industry specific app everyone is using. You see where this is going.
The upside? One application upgrade, one application maintenance: one application across the board saves time and money for the customer.
But what about single tenancy?
Let’s talk again about washing machines. If we go single tenant on a washing machine, then each apartment that wants to pay for a washing machine can have one. It’s their washing machine, they don’t share it. It’s a single tenant solution. If their washing machine goes down, it doesn’t affect the other washing machines in the building. In this case, the cost savings obviously isn’t as pronounced as in a multi-tenant setting. Because in a building of 300 families, if even half of them want their own washer/dryer, we’re looking at 150 washers and 150 dryers, all of which need to be maintained, all of which can fail, all of which need to be supported individually and all of which carry their own price tag.
How about security in a multi-tenant vs. single-tenant situation?
Securing a building is one thing, but what about securing each apartment from other tenants? That also needs to be considered. Firewalls at the front of the network keep external threats out, much like a doorman. But what’s to stop your neighbor from breaking into your apartment? There’s no doorman to stop someone on the inside.
So, because of shared resources, security needs to be handled at a much lower level: segmentation of resources. You have to segment your apartment from your neighbor’s apartment. On the network side that would be segmenting those shared resources using Mac Address Control address pools, VLAN tagging (Virtual Local Area Networks) with more advanced security controls such as tag zoned segments, private VLANS and ACLs (access control lists) to define a secure environment, enforce the policies of the secure environment and maintain that secure environment.
For storing your business data, your critical data and your customer data, you’ll want to make sure that the architecture users LUN (Logical Unit Number) masking, at rest encryption, zoning and VSANs (Virtual Storage Area Networks) to keep cloud insiders and cloud outsiders out. Ultimately, there needs to be as much security between you and your neighbor as there is from an outsider trying to break into the building.
If you enter the lobby of my apartment building, the doorman will either allow you in, or he’ll turn you away. In other buildings, you need to authenticate yourself by using a key fob for entry. And make no mistake: there is always an audit trail:
“Dimitri McKay entered the building at 3:05am”
“Ms. Jameson came to visit Dimitri McKay at 4:15am”
If your business is governed by industry mandates or government regulatory compliance, you need to make sure you have data such as raw logs to keep your auditors (and upper management) happy. Local or in the cloud, it’s your responsibility to practice due diligence. There are providers that offer security and accountability. You can have your Kate and Edith too.
Quality of Service
My neighbor complains constantly about noise from my apartment. And he should. My subwoofer at volume level 10 shakes the apartment, his apartment, the people upstairs, the mail room, the garage and three blocks away at the local watering hole. I tend to use it at 3am when I have insomnia. You don’t want your cloud to have the “Dimitri McKay subwoofer” problem. In other words, I’m a tenant who is affecting the processes of another tenant—in this case, their sleep. By putting some quality of service in place, that segregation of work keeps my noise from impacting his sleep. It’s the same situation in the cloud: your workload shouldn’t be affected by your annoying neighbor.
The cloud is a shared environment, much like my apartment building. Where I’ve used a simple example of multi tenancy would be an apartment building. In an apartment building you have a “shared environment” where multiple “renters” share a common infrastructure (the plumbing, the electrical grid, hallways, etc.) but still have segregated areas where the users keep their stuff (host their applications and/or data).
Multi-tenancy is highly desirable to cloud providers because they can provide a platform or service (applications, infrastructure, etc.) and rent it to a large number of customers without having to make massive customizations, tons of labor-intensive upgrades, troubleshooting sessions and associated costs. Single tenancy has merit in situations where sharing the same app among a broad scope isn’t a viable option.
On a large scale such as the infrastructure side, the cloud provider will always opt for multi-tenant, but the customers themselves will likely seek single tenant in the following situations: custom apps, customers who are bound by specific regulatory compliance mandates, or those who care more about security than price.
One example of this is anyone who needs to have raw log data from all of their IT infrastructure, OS and apps in one place. They could have a single tenant log management tool in the cloud that only collects data from their specific cloud network devices, cloud applications and server operating systems. In this situation, segregation makes more dollars and sense.
Just as is the case with public, private and hybrid clouds, there’s no be-all, end-all situation when it comes to choosing between single- and multi-tenant deployments. It depends on what your goals are, as well as your budget.