This topic provides an overview of VPC Service Controls and describes its advantagesand capabilities.

Who should use VPC Service Controls

Your organization might own intellectual property in the form of highlysensitive data, or your organization might handle sensitive data that is subjectto additional data protection regulations, such as PCI DSS. Unintended loss ordisclosure of sensitive data can lead to significant negative businessimplications.

If you are migrating from on-premises to the cloud, one of your goals might beto replicate your on-premises network based security architecture as you moveyour data to Google Cloud. To protect your highly sensitive data, you might wantto ensure that your resources can only be accessed from trusted networks. Someorganizations might allow public access to resources as long as the requestoriginates from a trusted network, which can be identified based on the IPaddress of the request.

To mitigate data exfiltration risks, your organization might also want to ensuresecure data exchange across organizational boundaries with fine-grainedcontrols. As an administrator, you might want to ensure the following:

• Clients with privileged access don't also have access to partner resources.
• Clients with access to sensitive data can only read public data sets but notwrite to them.

How VPC Service Controls reduces data exfiltration risks

VPC Service Controls helps protect against accidental or targeted actionby external entities or insider entities, which helps to minimize unwarranteddata exfiltration risks from Google Cloud services such as Cloud Storageand BigQuery. You can use VPC Service Controls to create perimetersthat protect the resources and data of services that you explicitly specify.

VPC Service Controls secures your Google Cloud services by defining thefollowing controls:

• Clients within a perimeter that have private access to resources do nothave access to unauthorized (potentially public) resources outside theperimeter.

• Data cannot be copied to unauthorized resources outside the perimeter usingservice operations such asgcloud storage cporbq mk.

• Data exchange between clients and resources separated by perimetersis secured by usingingress and egress rules.

• Context-aware access to resources is based on client attributes, such asidentity type (service account or user), identity, device data, and networkorigin (IP address or VPC network). The following are examples ofcontext-aware access:

  • Clients outside the perimeter that are on Google Cloud oron-premises are within authorized VPC resources and usePrivate Google Access to access resources within a perimeter.

  • Internet access to resources within a perimeter is restricted to a rangeof IPv4 and IPv6 addresses.

  For more information, seeContext-aware access using ingress rules.

VPC Service Controls provides an extra layer of security defense forGoogle Cloud services that is independent of Identity and Access Management(IAM). While IAM enables granularidentity-basedaccess control, VPC Service Controls enables broadercontext-based perimetersecurity, including controlling data egress across the perimeter. We recommendusing both VPC Service Controls and IAM for defense in depth.

VPC Service Controls lets you monitor resource access patterns across yourservice perimeters using Cloud Audit Logs. For more information, seeVPC Service Controls audit logging.

Security benefits of VPC Service Controls

VPC Service Controls helps mitigate the following security risks without sacrificingthe performance advantages of direct private access to Google Cloudresources:

• Access from unauthorized networks using stolen credentials: Byallowing private access only from authorized VPC networks,VPC Service Controls helps protect against the risk of data exfiltrationpresented by clients using stolen OAuth or service account credentials.

• Data exfiltration by malicious insiders or compromised code:VPC Service Controls complements network egress controls by preventing clientswithin those networks from accessing the resources of Google-managedservices outside the perimeter.

  VPC Service Controls also prevents reading data from or copying data to aresource outside the perimeter. VPC Service Controls preventsservice operations such as agcloud storage cp command copying to a publicCloud Storage bucket or abq mk command copying to a permanentexternal BigQuery table.

  Google Cloud also provides a restricted virtual IP that is integratedwith VPC Service Controls.The restricted VIP also allows requests to bemade toservices supported by VPC Service Controlswithout exposing those requests to the internet.

• Public exposure of private data caused by misconfigured IAMpolicies: VPC Service Controls provides an extra layer of security bydenying access from unauthorized networks, even if the data is exposed bymisconfigured IAM policies.

• Monitoring access to services: Use VPC Service Controls indry runmode to monitor requests toprotected services without preventing access and to understand trafficrequests to your projects. You can also create honeypot perimeters toidentify unexpected or malicious attempts to probe accessible services.

You can use an organization access policy and configure VPC Service Controls foryour entire Google Cloud organization, or usescopedpolicies and configureVPC Service Controls for a folder or project in the organization. You retain theflexibility to process, transform, and copy data within the perimeter.

VPC Service Controls configurations are managed at the organization level bydefault, but scoped access policies for folders or projects can be used todelegate administration of service perimeters further down the resourcehierarchy.

VPC Service Controls and metadata

VPC Service Controls is not designed to enforce comprehensive controls onmetadata movement.

In this context,data is defined as content stored ina Google Cloud resource. For example, the contents of aCloud Storage object.Metadata is defined as the attributes of theresource or its parent. For example, Cloud Storage bucket names.

The primary goal of VPC Service Controls is to control the movement of data,rather than metadata, across a service perimeter through supported services.VPC Service Controls also manages access to metadata, but there might be scenariosin which metadata can be copied and accessed without VPC Service Controls policy checks.

We recommend that you rely on IAM, including the use ofcustom roles,to ensure appropriate control over access to metadata.

Capabilities

VPC Service Controls lets you define security policies that prevent accessto Google-managed services outside of a trusted perimeter, block access to datafrom untrusted locations, and mitigate data exfiltration risks.

You can use VPC Service Controls for the following use cases:

• Isolate Google Cloud resources and VPC networksinto service perimeters

• Extend perimeters to on-premises networks using authorizedVPN or Cloud Interconnect landing zone VPC networks.

• Control access to Google Cloud resources from the internet

• Protect data exchange across perimeters and organizationsby using ingress and egress rules

• Allow context-aware access to resources based onclient attributes by using ingress rules

Isolate Google Cloud resources into service perimeters

Aservice perimeter creates a security boundary around Google Cloudresources. A service perimeter allows free communication within the perimeterbut, by default, blocks communication to Google Cloud services across theperimeter.

The perimeter works specifically with Google Cloud managed services. Theperimeter doesn't block access to any third-party APIs or services on theinternet.

You can configure a perimeter to control the following types of communications:

• From public internet to customer resources within managed services
• From virtual machines (VMs) to a Google Cloud service (API)
• Between Google Cloud services

VPC Service Controls doesn't require you to have a Virtual Private Cloud(VPC) network. To useVPC Service Controls without having any resources on a VPCnetwork, you can allow traffic from external IP ranges or certainIAM principals. For more information, seeCreate and manage access levels.

Here are some examples of VPC Service Controls creating a security boundary:

• A VM within aVPC networkthat is part of a service perimeter can read from or write to a Cloud Storagebucket in the same perimeter. However, VPC Service Controls doesn't allowVMs within VPC networks that are outside the perimeter toaccess Cloud Storage buckets that are inside the perimeter. You mustspecify an ingress policy to allow VMs within VPC networks that are outside theperimeter to access Cloud Storage buckets that are inside the perimeter.

• A host project that contains multiple VPC networks has a different perimeterpolicy for each VPC network in the host project.

• A copy operation between two Cloud Storage buckets succeeds if bothbuckets are in the same service perimeter, but if one of thebuckets is outside the perimeter, the copy operation fails.

• VPC Service Controls doesn't allow a VM within a VPC network that is inside aservice perimeter to access Cloud Storage buckets thatare outside the perimeter.

The following diagram shows a service perimeter that allows communication between aVPC project and Cloud Storage bucket inside the perimeter but blocksall communication across the perimeter:

Extend perimeters to an authorized VPN or Cloud Interconnect

You can configure private communication to Google Cloud resources fromVPC networks that span hybrid environments withPrivate Google Accesson-premises extensions. To privately accessGoogle Cloud resources within a perimeter, the VPC networkthat contains the landing zone from on-premises must be a part of the perimeterfor resources in the on-premises network.

VMs with private IP addresses in a VPC network secured by aservice perimeter cannot access managed resources outside the service perimeter.If necessary, you can continue to enable inspected and audited access to allGoogle APIs (for example, Gmail) over the internet.

The following diagram shows a service perimeter that extends to hybrid environmentswith Private Google Access:

Control access to Google Cloud resources from the internet

Access from the internet to managed resources within a service perimeter isdenied by default. Optionally, you can enable access based on the context of therequest. To do so, you can create ingress rules or access levels to permitaccess based on various attributes, such as the source IP address, identity, orsource Google Cloud project. If requests made from the internet don't meetthe criteria defined in the ingress rule or access level, the requests aredenied.

To use the Google Cloud console to access resources within a perimeter,you must configure an access level that allows access from one or more IPv4and IPv6 ranges, or to specific user accounts.

The following diagram shows a service perimeter that allows access from the internetto protected resources based on the configured access levels, such as IP address or device policy:

Other controls to mitigate data exfiltration risks

• Domain restricted sharing: You can consider setting up an organizational policy to limit resource sharing to identities that belong to a particular organization resource. For more information, seeRestricting identities by domain.
• Uniform bucket-level access: To uniformly control access to your Cloud Storage buckets, consider setting up bucket-level IAM permissions. Using uniform bucket-level access lets you use other Google Cloud security features such as domain restricted sharing,Workforce Identity Federation, andIAM conditions.
• Multi-factor authentication: We recommend usingmulti-factor authentication to access your Google Cloud resources.
• Post-deployment scans: You can consider using the following post-deployment scanning tools to scan for open Cloud Storage buckets:
  1. Security Command Center
  2. Cloud Asset Inventory to search asset metadata history and analyse IAM policy to understand who has access to what.
  3. Third-party tools like Palo Alto PrismaCloud
• De-identification of sensitive data: You can consider usingSensitive Data Protection to discover, classify, and de-identify sensitive data inside and outside Google Cloud. De-identification of sensitive data can be done by redaction, tokenization, or encryption.
• Automation using infrastructure-as-code tools: We recommend that you deploy Cloud Storage buckets using an automation tool to control access to the buckets. Pass the infrastructure-as-code through human or automated reviews before deployment.

Unsupported Services

For more information on products and services that are supported by VPC Service Controls, refer to theSupported products page.

Unsupported services may not function at all when enabled in a project protected by VPC Service Controls, especially when low-level storage services like Cloud Storage or Pub/Sub are restricted. We recommend deploying unsupported services in projects outside perimeters. To allow these services to access data in resources within a perimeter,create an access level that includes the service account for that service andapply it to perimeters as needed.

Attempting to restrict an unsupported service using thegcloud command-line tool or the Access Context Manager API will result in an error.

Cross-project access to data of supported services will be blocked by VPC Service Controls. Additionally, the restricted VIP can be used to block the ability of workloads to call unsupported services.

Known limitations

There are some known limitations with certain Google Cloud services,products, and interfaces when you use VPC Service Controls. For example,VPC Service Controls doesn't support all Google Cloud services.Therefore, don't enable unsupported Google Cloud services in theperimeter. For more information, see theVPC Service Controls supported products list.If you need to use a service that VPC Service Controls doesn't support,enable the service in a project that is outside the perimeter.

We recommend that you review known limitations before you includeGoogle Cloud services in the perimeter. For more information, see theVPC Service Controls service limitations.

Glossary

In this topic, you have learned about several new concepts introduced byVPC Service Controls:

VPC Service Controls

Technology that enables you to define a service perimeteraround resources of Google-managed services to control communication to andbetween those services.

service perimeter

A service perimeter around Google-managed resources. Allows freecommunication within the perimeter but, by default, blocks all communicationacross the perimeter.

ingress rule

A rule that allows an API client that is outside the perimeter to accessresources within a perimeter. For more information, seeIngress and egress rules.

egress rule

A rule that allows an API client or resource that is inside the perimeter toaccess Google Cloud resources outside the perimeter. The perimeterdoes not block access to any third-party API or services on the internet.

service perimeter bridge

A perimeter bridge allows projects in different service perimeters tocommunicate. Perimeter bridges are bidirectional, allowing projects fromeach service perimeter equal access within the scope of the bridge.

Note: Instead of using a perimeter bridge, we recommend using ingress and egress rules that provide more granular controls.

Access Context Manager

A context-aware request classification service that can map a request toan access level based on specified attributes of the client, such as thesource IP address. For more information, seeOverview of Access Context Manager.

access level

A classification of requests over the internet based on several attributes,such as source IP range, client device, geolocation, and others. Just likean ingress rule, you can use an access level to configure a serviceperimeter to grant access from the internet based on the access levelassociated with a request. You cancreate an access level using Access Context Manager.

access policy

A Google Cloud resource object that defines service perimeters. Youcan create access policies that are scoped to specific folders or projectsalongside an access policy that can apply to the entire organization. Anorganization can have only one organization-level access policy.

scoped policy

A scoped policy is an access policy that is scoped to specific folders orprojects alongside an access policy that applies to the entire organization.For more information, seeOverview of scoped policies.

restricted VIP

The restricted VIP provides a private network route for products and APIssupported by VPC Service Controls in order to make data and resources used bythose products inaccessible from the internet.restricted.googleapis.comresolves to199.36.153.4/30.This IP address range is not announced to the internet.

What's next

• Learn aboutservice perimeter configuration.
• Understand how to manageVPC networks in service perimeters
• Review theknown service limitations.