Presented with 🤍 by
Modeling Tenant Isolation
This first step includes 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.
Map External Interfaces
The starting point of an isolation review is mapping customer-facing interfaces and determining the complexity of each interface (as a predictor of vulnerability) and whether it’s shared among multiple tenants or duplicated per tenant (logically, virtually, or physically).
For example, a database client should be considered a complex interface, while a data entry form should be considered relatively simple.
Determine Security Boundaries
The next step is to determine what types of security boundaries are in place for each duplicated interface.
Hardware Separation
Instances belonging to different tenants run on separate physical machines (IaaS such as bare-metal servers or dedicated physical datacenters).
Data Segmentation
Data belonging to different tenants is stored and/or processed on a shared storage component (virtual or physical), but unique keys are used to encrypt and/or authorize access to each tenant’s data.
Hardware Virtualization
Instances belonging to different tenants run in separate virtual machines running on shared hardware
Network Segmentation
Instances belonging to different tenants run on separate machines (virtual or physical) in the same network, which is segmented into single tenant VPNs.
Containerization
Instances belonging to different tenants run in separate containers running on shared hardware (or nested within a shared virtual machine) via operating-system-level virtualization
Identity Segmentation
Roles are assigned to different tenants (whether or not customers can access them directly under normal circumstances) which are limited by deny-by-default policies, such that each tenant cannot perform any actions affecting resources belonging to any other tenant.
Measure Hardening Factors
The strength of a security boundary is limited by the weakest link in its design or implementation. We can measure the strength of a security boundary according to 5 hardening factors (P.E.A.C.H.):
Privilege Hardening
-
Tenants and hosts generally have minimal permissions in the service environment, thereby adhering to the principle of least privilege.
-
In particular, each tenant is not authorized to read or write to other tenants’ data unless explicitly approved by the tenants involved, and each host does not have read or write access to other hosts.
-
Privileges are verified prior to execution of operations.
Encryption Hardening
-
Data owned by and related to each tenant – at-rest and in-transit – is encrypted with a key unique to that tenant, regardless of architecture.
-
Logs pertaining to each tenant’s activity are encrypted by a secret shared only between the tenant and the control plane.
Authentication Hardening
-
Communications between each tenant and the control plane (in both directions) use authentication with a key or certificate unique to each tenant.
-
Authentication keys are validated, and self-signed keys are blocked.
Connectivity Hardening
-
All inter-host connectivity is blocked by default unless explicitly approved by the tenants involved (so as to facilitate database replication, for example); hosts cannot connect to other hosts in the service environment, except those used by the control plane (i.e., a hub-and-spoke configuration).
-
Hosts do not accept incoming connection requests from other hosts unless explicitly approved by the tenants involved, except those used by the control plane (in anticipation of scenarios in which an attacker manages to overcome connectivity limitations on their own compromised host).
-
Tenants cannot arbitrarily access any external resource (both within the service environment and on the Internet) and are limited to communicating with only pre-approved resources or those explicitly approved by the tenant.
Hygiene
-
Secrets – The interface and datastore (and underlying host, in the case of virtualization or containerization) do not contain any keys or credentials that would allow authentication to other tenants’ environments or decryption of other tenants’ backend communications or logs.
-
Software – The instance and datastore (and underlying host) do not contain any built-in software or source code that could enable reconnaissance or lateral movement.
-
Logs – Each tenant’s logs are hidden from and inaccessible by other tenants; logs accessible to each tenant do not contain any information pertaining to other tenants’ activity.
Summarize Findings
The final step in the modeling process is to summarize our review findings in an isolation design diagram and accompanying implementation table. The diagram allows us to represent the interface architecture in an abstract way, while the table holds the implementation details and serves as a checklist for assessing each of the 5 hardening factors.
For example, this is how we would represent a highly isolated database client in a managed SQL database cloud service: