Design and architect service perimeters

This document describes recommended VPC Service Controls deployment architectures. This document is for network administrators, security architects, and cloud operations professionals who run and operate large, production scale deployments on Google Cloud and who want to mitigate the risk of sensitive data loss.

Because VPC Service Controls protection affects cloud services functionality, we recommend that you plan the enablement of VPC Service Controls in advance, and consider VPC Service Controls during architecture design. It's important to keep VPC Service Controls design as simple as possible. We recommend that you avoid perimeter designs that use multiple bridges, perimeter network projects or a DMZ perimeter, and complex access levels.

Use a common unified perimeter

A single large perimeter, referred to as a common unified perimeter, provides the most effective protection against data exfiltration compared to using multiple, segmented perimeters. A common unified perimeter reduces the number of access levels, which helps to prevent complexity in your allowlist process.

We recommend that you fully enforce your common unified perimeter without internet egress and without access to unsupported services. We further recommend that you avoid defining perimeters based on logical constructs such as lifecycle and divisions. The perimeter blocks data exfiltration, and it isn't meant to define access. Instead, use Identity and Access Management to define access controls. For more information, see Creating a service perimeter.

Use multiple perimeters in one organization

When data sharing is a primary use case for your organization, you can use more than one perimeter. If you produce and share lower-tier data like de-identified patient health data, you can use a separate perimeter to facilitate sharing with outside entities. For more information, see reference patterns for secure data exchange.

If you use your cloud organization to host independent, third-party tenants such as partners or customers, you can define a perimeter for each tenant. If you consider data movement from from one of these tenants to another to be exfiltration, we recommend that you implement a separate perimeter.

Perimeter design

We recommend that you enable all protected services when you create a perimeter, which helps to reduce complexity and exfiltration vectors. There is no reason to protect one API and not all others.

All new projects must go through the review and qualification process that is described in the following sections. Include in the perimeter all the projects that pass the qualification conditions.

Make sure that there isn't a path to the private VIP from any of the VPCs in the perimeter. If you allow a network route to, you negate VPC Service Controls protection from insider data exfiltration. If you must allow access to a non-supported service, try to isolate the use of unsupported services into a separate project, or move the entire workload off the perimeter.

Review and qualify projects

A typical enterprise has many projects that represent workloads and high-level constructs such as control planes, data lakes, business units, and lifecycle stages. In addition to organizing these projects and components into folders, we recommend that you qualify them to be inside or outside of a VPC Service Controls perimeter. To make the qualification, consider the following questions:

  • Is there a component that has a hard dependency on a service that VPC Service Controls doesn't support?

    VPC Service Controls enforcement is unambiguous, so this type of dependency can't function in a perimeter. We recommend that you modify the workload to isolate the requirement for unsupported services into a separate project, or move the workload out of the perimeter altogether.

  • Is there a critical dependency on external access (ingress or egress) of this component?

    We recommend that you minimize outside access. For information about when you can limit access to a specific set of public IP addresses, service account identities, or trusted devices, see Allowlist design.

  • Is there a component that has no sensitive data and doesn't consume sensitive data from other projects?

If any of the preceding are true, we recommend that you don't put the project into a perimeter. You can work around this, as discussed in the Allowlist design topic. However, we recommend that you minimize perimeter complexity.

What's next