That, at least in the abstract, is a description of pretty much every organization using cloud services; if you are an organization consuming cloud, you are sharing infrastructure with other customers.
At times when many different tenants have their workloads running simultaneously in a single physical server, storage array, or network segment, where they all assume that this one is segregated from the other tenants’ data and applications. Only if the underlying isolation has been constructed appropriately will that expectation hold, but getting it wrong is astronomically impactful for a platform and its entire customer base.
This poses a challenge, which is why cloud security for multi-cloud environments focuses on preventing organizations’ data and workloads from falling victim to other tenants within shared infrastructure, without relying on assumptions that may not hold.
The Actual Meaning of Multi-Tenancy in Terms of Security
Multi-tenancy is the architectural basis of many modern cloud computing technologies. The essential premise that makes cloud computing (cost-effective and scalable in the first place) is that instead of dedicating physical hardware for each customer, providers pool resources and dynamically allocate them across many customers. This relative security comes at the cost of trading physical separation for logical separation. Two wholly unrelated organizations could be operating workloads on the exact same underlying hardware, separated solely by software-enforced barriers.
This definitely alters the security dialogue. The part to protect is not if a workload is physically isolated, but whether the virtualization, access control and network segmentation that brings about that isolation are solid. Although the tenants should ideally have nothing to do with one another (indeed they don’t even know each other exists), a bug in any of those layers could arguably allow one tenant’s actions to interfere with, or “cross-contaminate,” another.
The Shared Responsibility Reality
Exactly the division of responsibility between provider and customer is one of the most confusing aspects for many people working with multi-tenant cloud security. They protect the infrastructure that is beneath cloud providers, the physical data centers, the hypervisors, and tenant separation mechanisms. You are trained to be responsible for securing what you put inside your own section of that infrastructure identity and access configuration, application security and data protection.
The problem is that this dichotomy does not necessarily reflect reality and organizations can put their trust in protections that were never included in the provider’s commitments. A misconfigured storage bucket or an overly permissive access policy is seldom the blame of the provider. More often than not, it’s tied directly to choices made on that line between shared and dedicated responsibility, making it critical to understand exactly where that line is drawn in the first place as a step towards securing your multi-tenant deployment.
Isolation Mechanisms Worth Understanding
In most cases tenant isolation works in combinations of multiple layers that work together rather than an individual layer acting on its own. Specific compute resources such as those separated by virtual machine: Hypervisor or container, or orchestration layer boundaries. Network segmentation is a technique that prevents traffic from one tenant’s environment from reaching another tenant’s environment, and this is often achieved through implementing virtual networks and security groups. Identity & access controls dictate who can reach what resources, wherever those resources may be starting from.
International standards bodies have published detailed guidance on exactly this kind of layered protection. ISO’s cloud security controls standard lays out specific controls for protecting and separating a customer’s virtual environment from other tenants, covering everything from virtual machine configuration to monitoring of activity inside the shared environment. Organizations evaluating a cloud provider’s multi-tenant security posture often find it useful to check which of these kinds of controls the provider has actually implemented, rather than taking isolation claims at face value.
Why is Configuration More Important than Architecture
Yet, the multi-tenant security is easy to believe will only be solved in a one-time architectural way by the cloud provider. In practice, many more real-world incidents occur due to misconfiguration on the customer side than are a consequence of any flaws in the underlying isolation architecture itself. The root cause of the problem could also be an access policy that is broader than necessary, a storage resource left in public access or an identity role with more privileges than its function requires, in short anything that removes isolation.
This is part of why public cloud security guidance places so much emphasis on the customer’s own configuration choices rather than just the provider’s infrastructure. NIST’s public cloud security guidelines walk through exactly this point, noting that accountability for security and privacy in a public cloud deployment cannot be delegated to the provider and remains the customer’s obligation to fulfill, regardless of how strong the underlying multi-tenant architecture happens to be.
Practical Considerations for Multi-Tenant Deployments
The ability to treat some questions as perpetual, not just one-off, helps organizations contemplating and operating in multi-tenant cloud environments. Network-level Workloads Separation Is that separation of workloads implemented at the network level and continually tested instead of assumed? Do you periodically review identity and access policies so that privilege creep is nipped in the bud before becoming a liability? Does encryption apply equally to data at rest and in transit, with meaningful protections so that even a compromise of logical isolation wouldn’t expose intelligible plaintext to another tenant?
When it comes to addressing these questions, there is no one-size-fits-all answer: the best way forward will vary based on the provider or service model and regulatory environment at hand. The important part is, that multi-tenant security should be perceived as something that needs continual verification rather than a box that’s checked on the initial deployment and left to gather dust.
The shared aspect of cloud infrastructure is not going away, and it probably shouldn’t for most organizations. But the economics and flexibility it allows are too enticing to overlook. Shared responsibility is always an effective way to set expectations with your compliance teams, however, organizations have the power over how seriously they treat their configuration options on the organization side of that line since it is typically where the real risk in multi-tenant environments means to converge.
Frequently Asked Questions
What is the weakest, most underutilized security risk in unrelated multicore systems?
The reality is that on the customer side, misconfiguration (e.g., overly permissive access policies or exposed storage) accounts for far more real incidents than defects in the provider isolation architecture reliability score.
Multi-cloud deployment: Who owns security?
The underlying infrastructure and isolation mechanisms are secured by the providers, whereas customers still need to secure identity, access, applications, and data in their own environment.
How can you be sure that your tenant isolation is actually working?
Specific to the provider asking, are you able to review the isolation controls a provider implements against popular cloud security standards.
