Improving Tenant Isolation
Following an isolation review, vendors have three preventive "levers" at their disposal to manage the risk of isolation escape: reducing interface complexity, improving separation between tenants, and increasing interface duplication. Let's dive deeper into each method.
Interface complexity and the risks associated with it can be reduced (to a point) by right-sizing the type of interface to the type of expected input, and by improving API security according to industry best practices . Each of these can serve to lower complexity by applying limitations on what actions a user can perform, thus reducing a would-be attacker’s degree of control.
Existing security boundaries can be strengthened (by adding PEACH hardening factors), replaced with stronger types, or augmented by additional boundaries of different types. Each of these serves to lower the impact of exploitation by impeding lateral movement.
A well-hardened IaaS-based security boundary (such as virtualization) is suitable for ensuring tenant isolation regardless of interface complexity. Likewise, an application-level security boundary (such as containerization) is usually adequate for isolating simple interfaces, but not good enough on its own for isolating more complex interfaces.
While security boundaries serve to hinder a malicious tenant’s attempts at lateral movement, we can further limit the impact of interface vulnerabilities by shifting shared functionality outside the vendor’s trust boundary and duplicating it according to a certain organizing principle (per-tenant, per-region, etc.).
It is ultimately up to the vendor to decide how best to finetune their architecture, depending on important additional context such as external constraints (e.g., budget and compliance requirements) and expected use-case characteristics (e.g., data sensitivity). It is important to balance tenant isolation against these other factors. “Over-isolation” can be avoided by prioritizing the duplication of complex components over simpler ones and limiting degree of separation to the minimum necessary.
The process of evaluating tenant isolation should be performed on a regular basis, starting at the initial design phase, and repeated prior to every major version release. This is meant to prevent isolation drift, caused by unintended differences between design and implementation, as well as the addition of new functionality. Additionally, automatic testing should be in place to challenge design assumptions and empirically verify correct implementation.