Explore

VPC Service Controls

Who should use VPC Service Controls?

Your organization might own intellectual property in the form of highly sensitive data, or your organization might handle sensitive data that is subject to additional data protection regulations, such as PCI DSS. Unintended loss or disclosure of sensitive data can lead to significant negative business implications.

If you are migrating from on-premises to the cloud, one of your goals might be to replicate your on-premises network based security architecture as you move your data to Google Cloud. To protect your highly sensitive data, you might want to ensure that your resources can only be accessed from trusted networks. Some organizations might allow public access to resources as long as the request originates from a trusted network, which can be identified based on the IP address of the request.

To mitigate data exfiltration risks, your organization might also want to ensure secure data exchange across organizational boundaries with fine-grained controls. 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 not write to them.

How VPC Service Controls reduces data exfiltration risks?

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

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

Clients within a perimeter that have private access to resources do not have access to unauthorized (potentially public) resources outside the perimeter.

Data cannot be copied to unauthorized resources outside the perimeter using service operations such as

gcloud storage cp⁠

bq mk⁠

Data exchange between clients and resources separated by perimeters is secured by using

ingress and egress rules⁠

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

Clients outside the perimeter that are on Google Cloud or on-premises are within authorized VPC resources and use Private Google Access to access resources within a perimeter.

Internet access to resources within a perimeter is restricted to a range of IPv4 and IPv6 addresses.

For more information, see

Context-aware access using ingress rules⁠

VPC Service Controls provides an extra layer of security defense for Google Cloud services that is independent of Identity and Access Management (IAM). While IAM enables granular identity-based access control, VPC Service Controls enables broader context-based perimeter security, including controlling data egress across the perimeter. We recommend using both VPC Service Controls and IAM for defense in depth.

VPC Service Controls lets you monitor resource access patterns across your service perimeters using Cloud Audit Logs.

Security benefits of VPC Service Controls

VPC Service Controls helps mitigate the following security risks without sacrificing the performance advantages of direct private access to Google Cloud resources:

Access from unauthorized networks using stolen credentials: By allowing private access only from authorized VPC networks, VPC Service Controls helps protect against the risk of data exfiltration presented 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 clients within those networks from accessing the resources of Google-managed services outside the perimeter.

VPC Service Controls also prevents reading data from or copying data to a resource outside the perimeter. VPC Service Controls prevents service operations such as a gcloud storage cp command copying to a public Cloud Storage bucket or a bq mk command copying to a permanent external BigQuery table.

Google Cloud also provides a restricted virtual IP that is integrated with VPC Service Controls. The restricted VIP also allows requests to be made to

services supported by VPC Service Controls⁠

without exposing those requests to the internet.

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

Monitoring access to services: Use VPC Service Controls in

dry run mode⁠

to monitor requests to protected services without preventing access and to understand traffic requests to your projects. You can also create honeypot perimeters to identify unexpected or malicious attempts to probe accessible services.

Use Cases

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

⁠

Isolate Google Cloud resources and VPC networks⁠

into service perimeters

⁠

Extend perimeters to on-premises networks⁠

using authorized VPN or Cloud Interconnect landing zone VPC networks.

⁠

Control access to Google Cloud resources⁠

from the internet

⁠

Protect data exchange across perimeters and organizations⁠

by using ingress and egress rules

⁠

Allow context-aware access to resources⁠

based on client attributes by using ingress rules

Isolate Google Cloud resources into service perimeters

A service perimeter creates a security boundary around Google Cloud resources. A service perimeter allows free communication within the perimeter but, by default, blocks communication to Google Cloud services across the perimeter.

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

⁠

Extend perimeters to an authorized VPN or Cloud Interconnect

You can configure private communication to Google Cloud resources from VPC networks that span hybrid environments with Private Google Access

on-premises extensions⁠

. To privately access Google Cloud resources within a perimeter, the VPC network that contains the landing zone from on-premises must be a part of the perimeter for resources in the on-premises network.

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

⁠

Control access to Google Cloud resources from the internet

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

The following diagram shows a service perimeter that allows access from the internet to 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, see

Restricting 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⁠

, and

IAM conditions⁠

Multi-factor authentication: We recommend using

multi-factor authentication to access your Google Cloud resources⁠

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.

Post-deployment scans: You can consider using the following post-deployment scanning tools to scan for open Cloud Storage buckets:

⁠

Security Command Center⁠

⁠

Cloud Asset Inventory⁠

to search asset metadata history and analyse IAM policy to understand who has access to what.

Third-party tools like Palo Alto Prisma Cloud

De-identification of sensitive data: You can consider using

Sensitive 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.

Ref:

Overview of VPC Service Controls | Google Cloud⁠

⁠

Who should use VPC Service Controls?

How VPC Service Controls reduces data exfiltration risks?

Security benefits of VPC Service Controls

Use Cases

Isolate Google Cloud resources into service perimeters

Extend perimeters to an authorized VPN or Cloud Interconnect

Control access to Google Cloud resources from the internet

Other controls to mitigate data exfiltration risks

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.