The Tenant Isolation Problem
Cloud tenants must be isolated from one another. But what if the security boundary is flawed?
In recent years, several cross-tenant vulnerabilities have been discovered in various multi-tenant cloud applications which could have enabled malicious actors to access data belonging to other customers (such as ChaosDB, ExtraReplica, AttachMe and Hell’s Keychain).
This inspired us to create PEACH, a tenant isolation framework for cloud applications, based on the lessons we've learned in our cloud vulnerability research.
What is the PEACH framework?
In a nutshell, it’s a step-by-step framework for modeling and improving SaaS and PaaS tenant isolation, by managing the attack surface exposed by user interfaces.
Whether you’re a cloud customer or a cloud application developer, PEACH provides a clear standard for transparency on tenant isolation assurance.
Step 1: Modeling Tenant Isolation
The first step is conducting an isolation review, by analyzing the risks associated with customer-facing interfaces, determining which security boundaries are in use, and then measuring their strength according to five parameters (P.E.A.C.H.).
Tenants and hosts have minimal permissions in the service environment.
The data belonging to each tenant is encrypted with a unique key, regardless of where the information is stored.
Communications between each tenant and the control plane use authentication with a validated key unique to each tenant.
All inter-host connectivity is blocked by default unless explicitly approved by the tenants involved.
Unnecessary secrets, software and logs scattered throughout the environment are purged, to avoid leaving clues or enabling quick wins for malicious actors.
Step 2: Improving Tenant Isolation
Is there room for improvement in your tenant isolation model?
If you discover potential issues with your current design, you can take the following steps to mitigate the risk of isolation escape, while accounting for operational context and application use cases.
Reducing interface complexity
By applying limitations on what actions a user can perform, the would-be attacker's degree of control will be reduced.
Improving tenant seperation
Tenant separation may be improved by replacing security boundaries or hardening existing ones.
Increasing interface duplication
The impact of vulnerabilities can be limited by duplicating shared components (per-tenant, per-region, etc.).
Promoting Collaboration & Vendor Transparency
The PEACH framework can enable industry-wide collaboration in regard to isolation assurance and promote vendor trust via transparency.
This framework provides a method of abstracting preventative controls into a codified representation of isolation posture, without needlessly revealing sensitive architectural details.
We hope to provide a common language for industry collaboration on solving the shared tenant isolation problem.
We would like to extend our gratitude to the following for providing valuable feedback throughout the development of this framework:
Christophe Parisel, Senior Cloud Security Architect,
Cfir Cohen, Staff Software Engineer,
Kat Traxler, Principal Security Researcher,
Srinath Kuruvadi, Head of Cloud Security,
Joseph Kjar, Senior Cloud Security Engineer,
Mike Kuhn, Managing Principal,
Daniel Pittner, Software Architect,
Adam Callis, Information Security Architect,
We would also like to thank for their review of this document and the valuable constructive feedback they provided. We highly appreciate their interest in helping us identify multi-tenant isolation best practices while improving security transparency for cloud customers.
This framework attempts to build on previous work on tenant isolation by AWS, Azure, IBM, Oracle, and the UK's National Cyber Security Centre (NCSC).
For detailed guidance on secure cloud architecture, see the Security pillar of the AWS Well-Architected Framework, the Security, privacy, and compliance category of Google’s Cloud Architecture Framework, the Secure phase of Microsoft’s Cloud Adoption Framework for Azure, and the Best practices framework for Oracle Cloud Infrastructure.
For further reading on the subject of threat modelling, see PASTA, Microsoft’s STRIDE, Carnegie Melon’s Hybrid Threat Modeling Method, AWS’s “How to approach threat modeling”, OWASP’s Threat Modeling Cheat Sheet and the Threat Modeling Manifesto.