Testing Tenant Isolation on a Data Platform

A cloud infrastructure provider runs a secure data platform where each customer project works in its own isolated environment. It needed independent assurance that users could not reach another project’s data or escalate to platform level. Falx tested the platform from four trust levels, from an anonymous internet user to a user working inside a project environment. No path to another tenant’s resources or to platform-level privileges was found. Of 15 findings, 0 were critical and 2 were high. Both high risks were fixed and verified in a retest, reducing the overall risk rating from medium to low.

At a glance

The challenge

The platform gives each customer project its own environment of virtual machines and tools, reached through a web portal and browser-based remote access. Different projects share the same underlying infrastructure, including identity services, networking and storage.

The client had two questions. Could someone on the internet, without an account, get into the portal or the infrastructure behind it? And could a legitimate user step outside their own project, whether by bypassing the portal’s permissions, moving into another project’s environment or gaining platform-level privileges?

Testing had to take place within a fixed window agreed with the client, using proof-of-concept exploitation only, with no disruption to service and no changes to data.

What we did

1. Threat workshops and architecture walkthroughs

Falx ran pre-test workshops with the client’s engineers to walk through the architecture, access flows and the controls each part of the platform relied on. This produced a focused test plan built around the attack paths most likely to break isolation.

2. Testing from four trust levels

We tested as four different attackers:

• An unauthenticated internet user, probing the external perimeter, exposed services and the login flow
• An authenticated standard user, trying to exceed their permissions in the portal and API
• A project administrator, trying to escalate to platform-level control
• A user inside a project’s virtual machine, trying to reach other projects, shared infrastructure services and the management plane

Using two separately provisioned project environments, we attempted to move between projects, abuse remote access sessions and misuse temporary storage credentials to reach data outside the intended transfer.

3. Identity and access lifecycle testing

We tested what happens when access changes: onboarding, revocation, logout and deprovisioning. These tests checked whether the platform’s records of who has access matched what users could actually do.

Testing followed the OWASP Web Security Testing Guide, OWASP ASVS and MITRE ATT&CK.

Results

Isolation held. No tested scenario gave a user access to another tenant’s resources or to platform-level privileges. Remote access sessions were isolated between tenants, storage transfer credentials were strictly bound to their intended transfer, and network segmentation between tenant workloads held.

15 findings: 0 critical, 2 high, 6 medium, 7 low. The two high-risk issues were:

• A real-time (WebSocket) feature accepted connections without authentication. It did not expose another tenant’s data, but it widened the attack surface unnecessarily.
• Revoking a user’s access did not end their active remote session. A user whose access had been removed could keep working in an environment until their session ended.

Both high risks were fixed and verified in a retest. The real-time feature now rejects unauthorised clients, and revoking access immediately ends any active remote session. This reduced the platform’s overall risk rating from medium to low.

The medium and low findings fell into three themes, each with a staged plan of immediate, 1–3 month, 4–6 month and longer-term actions:

• Network segmentation: tenant workloads could reach some shared infrastructure services, such as identity and proxy services, more broadly than they needed to.
• Identity lifecycle: local administrator accounts without multi-factor authentication, provisioning credentials left on systems, and incomplete clean-up when users were removed.
• Unintended access paths: some management interfaces and the remote access service could be reached directly rather than only through the portal.

What happened next

This was the client’s second engagement with Falx, following an earlier assessment of its managed Kubernetes service and platform cluster.

Advice for similar organisations

• Revoking access must end live sessions. Removing a permission in the portal is not enough if existing remote sessions, tokens and cached credentials carry on working. Test revocation while a session is open.
• Test real-time features separately. WebSocket and streaming endpoints often bypass the authentication checks applied to normal web pages and APIs, so they need their own authentication, origin checks and per-subscription authorisation.
• Deny by default between tenants and shared services. Tenant workloads should reach only the specific identity, proxy and storage services they need, on the specific ports they need.
• Protect break-glass accounts. Local administrator accounts that sit outside single sign-on still need multi-factor authentication, and should not be reachable from the internet.

Facing something similar?

If you run a multi-tenant platform and need independent assurance that your customers are isolated from each other, book a call with Falx.