Doing a bit of digging, I figured out why -- one of our competitors has started promoting a solution in this space. Lovely. I dutifully found the source documents, and realized that there was a good deal more to this discussion than white papers and marketing videos I was able to find.
So, without too much competitive rancor, please join me in a quick discussion of secure multi-tenancy, because it shows all signs of being an increasingly popular topic over time.
At first blush, the concepts of "secure" and "multi-tenancy" appear to be polar opposites.
Security is inherently about isolation: keeping your information, applications and resources isolated from others. It's also about clear separation of administration roles as well.
Multi-tenancy, on the other hand, is all about sharing: especially when it comes to sharing physical resources (compute, network, storage), but, ultimately, operational roles as well -- fewer people doing more.
Why Is This Important?
Service providers and cloud operators depend on high degrees of multi-tenancy to make their value propositions work from an economic perspective. You can't be cheaper than traditional IT unless you're aggressively sharing resources and operational roles. That's what any cloud is about.
Most customers, on the other hand, are concerned about security and isolation. They look at these shared resource models, and justifiably have hard questions. Indeed, addressing this fundamental issue -- at something more than a “security-washing” level -- is essential for enterprise-oriented external clouds to be something more than a novelty.
I don't believe the problem is insolvable: for example, secure multi-tenancy has been the norm in data networks for many years. Multiple networking tenants can share the same physical network infrastructure, and there's little concern around security.
But we're not in the same situation when it comes to shared IT infrastructure. I've picked out only three issues among many, simply because they illustrate the real challenge here.
Issue #1 -- Preventing Service Provider Access To Your Information
If you're renting shared resources from a service provider, you want a very clear understanding as to what things the server provider can do, and what things they are prevented from doing.
In a storage centric discussion, this can boil down to a simple question: can the service provider get access to your data without your permission? I'm not talking policy and procedure, I'm talking simple physical access. And we're not just talking protecting primary storage here -- we're talking snaps, backups, archives -- the whole enchilada.
If you've ever been in a hosting facility, you may have seen "locked cages" that prevent physical access to equipment. In a multi-tenancy environment, we need a virtual equivalent to that concept.
The most complete answer, in many people's minds, is strong encryption complemented by tenant-owned key management. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider.
If you think that I'm being too stringent here, keep in mind that in many proposed solutions, data from multiple tenants is freely intermixed on available storage devices. Sure, logical access is mediated, but it's all living on the same rotating physical rust.
Now, if I'm imagining virtually anything, let's imagine a disk appears to be going bad, and needs to be replaced. Your sensitive data may be somewhere on that disk, in plain view. Can you even tell which drives might hold some of your data?
In EMC land, that's one of the reasons we created a Secure Erase function that doesn't allow disk drive removal without erasure, as well as using RSA technology to provide role-specific temporary administrative credentials to arays. Not to mention PowerPath-based encryption for guest images, Avamar-encryption and RSA’s key manager.
Because drives do fail, equipment gets upgraded, and technicians occasionally do have to work on the equipment.
Issue #2 -- Separation Of Church and State
The most secure environment in the world is useless unless there's an administrative model that provides separation of roles and responsibilities. You don't want everyone running around with the "root" or "admin" password, do you? Or granting the “cloud administrators” omnipotent privileges?
Even in classical IT environments, this definition and enforcement of role separation and delegation is a really big deal. Taking that a step further, if we introduce multi-tenancy into the equation, the tenant should have full control of the administrative model for the resources they control.
No back doors, and no access -- unless granted by the tenant. Imagine you had a lockbox down at the local bank. You'd assume that you would be the only one with access, wouldn't you? Same for security in mulit-tenant environments.
Put differently, I believe that this core delegation of roles and responsibilities lies at the heart of making secure multi-tenancy something more than a vague marketing concept.
No matter what you do, it ain't secure unless you can manage it in a secure way.
Issue #3 -- You're Not Secure If You Can't Prove It
Early on, I realized that all the security stuff in the world was relatively useless unless you could prove it to an outside auditor. Secure multi-tenancy is no exception.
If you're an enterprise IT user, and you're using an external service provider, you'll probably have to pass the same sort of audit as you would for any infrastructure you owned.
That means, among other things, you'll have to provide audit and change control logs (including potentially those from your service provider!) showing that controls are in place and are effective. And, of course, it wouldn't do to have the audit logs on the same multi-tenancy infrastructure, would it?
Any viable 'secure multi-tenancy solution" in my book would have to have infrastructure audit logs available to all tenants at a minimum. This level of transparency and accountability isn't the norm in most SP models, but will likely be before too long.
Issues #4, #5, #6 ...
There's more, but I think I've begun to make my point. I haven't even begun to delve into issues like denial of service, or certifying IT infrastructure compliance, or a whole bird's nest of related topics. And that’s just poking at the “secure” part of multi-tenancy. Even within simple multi-tenancy (forget security for a moment), there’s a lot still yet to be said.
Here's the message: if this topic is important to you, there's far more to this secure multi-tenancy thing than integrating a bit of networking technology and emulating a logical array. There's data, for one thing. And administrative models. And being able to credibly pass an audit.
Now, back to our competitor's proposed solution -- a somewhat-secure-but-not-really-all-that-secure approach. Does it solve a useful customer problem for people concerned with security? Perhaps, but I'm incredibly skeptical.
However, this does make me think that EMC should probably get busy and focus a bit more on this topic. Fortunately, we've got a lot of very interesting pieces that could result in a very compelling solution.
Just off the top of my head: guest OS level encryption w/key management, for example. Ability to encrypt snaps, real backups and archive copies. Separation of tenant data on isolated media if needed. External configuration and event auditing with per-tenant reporting. Automated IT compliance management with tenant reporting. Tools that support an administrative model with clear separation of roles and responsibilities. A mechanism for secured temporary administrative credentials. Secure media erasure.
And a few more potential bits as well :-)
Just to be clear, though, there are lots of enterprise use cases for service provider multi-tenancy that don't require high degrees of security. The proposed approach might work there. And, on the other hand, there are environments where the security requirements are so daunting it's hard to imagine them running in a generic multi-tenant environment -- ever!
By the way, this stuff ain't exactly nuclear physics, either. Just take a look at how most large-scale data centers in sensitive industries do their business (e.g. financial services) and you'll see all that I described here, and more.
That being said, we collectively as an industry have to do a bit of legwork to bring this to service providers in a way that doesn't require dedicated, separated physical infrastructure.
We're not there yet, however.