Multi-Tenant and Cross-Tenant Threats in Google Cloud and Beyond

Principal Access Boundary, a new feature of the Google Cloud Platform, might not have made it to the agendas of CISOs and senior IT managers. But it could help mitigate fundamental cloud workload (and SaaS) security risks: identity and access management (IAM)-enabled data exfiltration paths that bypass all network security mechanisms such as firewalls.

The ongoing cloudification of workloads brings new challenges for IAM beyond the two traditional ones, i.e., enabling employees (and customers and partners) to access company resources while blocking cybercriminals. An organization’s engineers and employees need access to the organization’s cloud resources for their daily work. Roles and rights configurations in the IAM solution define which individual employees, external partners, customers, or users can access which resource (Figure 1, A). The IAM blocks users or intruders without explicitly granted access (Figure 1, B), even if they are in the company perimeter beyond network firewalls or more sophisticated security features such as VPC service controls in GCP or Private Link in Azure.

New Data Exfiltration Paths in the Cloud

However, in the cloud and SaaS worlds, two new data exfiltration paths and paths for smuggling malware into an organization exist: cross-tenant and multi-tenant access.

Related:Azure Data Factory Bugs Expose Cloud Infrastructure

Figure 1: The four cloud access challenges

Assume an employee has a company account and a personal account with a cloud or SaaS provider – quite a typical scenario for engineers working with the Azure cloud and using M365 in the office and at home. Then, the employee can upload sensitive company R&D documents to their personal M365 account or a SharePoint account controlled by foreign agencies. In Azure or Google Cloud, they might access their company’s cloud storage and transfer customer lists and order histories to cloud storage controlled by cybercriminals (Figure 1, C).

Preventing such traffic is often impossible on the network level since many cloud services do not incorporate the tenant information into the URL, as Figure 2 illustrates for GCP cloud storage. Thus, looking at URLs, no firewall or egress proxy understands whether an employee accesses a company or a non-company tenant. So, blocking unwanted traffic at the perimeter is not an option. The only solution: cloud or SaaS providers implement a tenant restriction capability.

Figure 2: Sample configuration for a cloud storage bucket. Neither the name nor the URL indicates which GCP tenant the data belongs to

A Closer Look at Tenant Restrictions

IP filtering is the poor man’s tenant restriction variant. Smaller providers with few customers often implement this pattern. They might restrict access to tenant «Germany-Southwest-43» to requests originating from the IP range 131.246.0.0/16, for example.

Related:Securing AI: What the OWASP LLM Top 10 Gets Right – and What It Misses

IP filtering does not scale and causes operational challenges. For example, IP changes result in blocked access. Thus, larger providers such as Google or Microsoft support a pattern with organizational restriction headers. When a user submits an HTTP request (Figure 3, 1), the customer organization’s egress proxy adds a list of acceptable tenants to the request (2) before forwarding the request to the cloud provider (3). Then, the cloud provider checks whether a user tries to log in to a tenant on the allow list of the organization restriction header (4).

Figure 3: Implementing tenant restriction for Cloud and SaaS services with organization restriction headers

Even with tenant restriction in place, one crucial data exfiltration (or ingress) path in cloud environments remains open: cross-tenant access, i.e., a principal (aka, a personal or technical user) in one (GCP) cloud tenant accesses resources in a (malicious) second (GCP) tenant without involvement of end-user devices like laptops.

In the pre-cloud era, CISOs never worried that someone would grant their engineers access to the Bank for International Settlement’s on-prem databases in Basel. The bank would never do that. In the cloud, however, CISOs need to worry about unsolicited access granting to M365 resources or Google Cloud Storage. It is a new attack path for cybercriminals.

Related:How Insecure Network Devices Can Expose Data Centers to Attack

But before demonizing cross-tenant/organization/subscription interaction features (the wording always differs slightly), even security specialists must understand their benefits. Suppose I run an online shop and have my workload and data in one GCP project. My bank runs its workload on GCP as well. So, why not interact directly within the GCP ecosystem? It is riskier if the bank and the online shop interact via the internet with all the authentication and lost-credential topics (Figure 4, A).

Figure 4: Understanding cross-tenant/organization access security threats

Mitigating Multi-Tenant and Cross-Tenant Threats

After looking at the benefits, let's deep-dive into the security threats. A user named Tom works for an online shop. He has access to a sensitive customer list. Assume that Tom turns criminal or that cybercriminals hack his Google Cloud account. Now, the attackers (or Tom himself) grant Tom’s account access to a cloud storage bucket «bad things only» in a GCP organization used for cybercrime activities (Figure 1, B).Now, using the «Tom» account, cybercriminals can exfiltrate the customer list by transferring it to the storage account «bad things only» (C). Plus, they might upload malware to Tom’s account (D) and install it on all VMs in GCP to which Tom has access. If they also manage to break into Tom’s email inbox, the cybercriminals can spread the malware to all his internal and external contacts (E). No traditional security network protection mechanisms such as firewalls, proxies, or DLP detect the traffic between Tom’s GCP account and the cybercriminals’ storage account «bad things only.»

The new GCP feature, Principal Access Boundary (PAB), mitigates these risks by complementing traditional IAM with explicit whitelisting. At PAB’s heart are Principal Access Boundary Rules, which are collections of Google Cloud resources. Policy Bindings apply these rules to sets of Google Cloud Principals. Afterward, these principals can access resources only if they meet two conditions:

Figure 5 illustrates the concept, which, if consequently applied, prevents Tom from being granted access to resources in the cybercriminal’s GCP organization, thereby effectively blocking this attack path.

Figure 5: Understanding Principal Access Boundary in the Google Cloud Platform

To conclude and emphasize the vital message: Google Cloud’s Principal Access Boundaries concept is not a security hotfix for a specific GCP vulnerability. Instead, it addresses a common security challenge related to cross-tenant access, one of the significant risks emerging from the cloudification of workloads. Along with the better-known tenant restriction topic, it demands the attention of security and risk professionals. They need to evaluate their critical platforms to determine if these risks exist – and whether they exceed their organization’s risk appetite. If so, they need to mitigate them – and this might not be as straightforward for all platforms as it is with GCP. So, use this new GCP feature as a wake-up call.