How to Configure Google Cloud VPC Service Controls (VPC SC) to Prevent Data Exfiltration

In traditional network engineering, preventing data exfiltration was straightforward: you installed a firewall at the edge of the corporate network and blocked outbound traffic. In the cloud, this paradigm completely collapses.

Google Cloud services like Cloud Storage (GCS), BigQuery, and Pub/Sub are global, managed APIs. They do not live inside your VPC. If an attacker compromises a virtual machine in your project, or if a malicious insider gains access to a service account key, they can simply use the gsutil CLI to copy terabytes of your sensitive corporate data directly into their own personal, external Google Cloud Storage bucket. Because both your bucket and the attacker’s bucket use the same public Google API endpoint (storage.googleapis.com), standard VPC firewalls cannot block this exfiltration.

Google solved this with VPC Service Controls (VPC SC). VPC SC allows you to draw an invisible, logical security perimeter around your Google Cloud projects and the managed services they consume. It explicitly dictates that services inside the perimeter can only communicate with other services inside the perimeter, neutralizing data exfiltration at the API layer.

This guide explains how to architect and deploy a VPC Service Controls perimeter in Google Cloud.

Understanding the VPC SC Architecture

VPC SC does not use IP addresses or traditional firewall rules. It operates at the Google Cloud API gateway level.

1. The Perimeter: You define a perimeter at the Google Cloud Organization level and place your sensitive Projects inside it.
2. Restricted Services: You define which APIs the perimeter protects (e.g., BigQuery, Cloud Storage).
3. The Enforcement: If a VM inside the perimeter attempts to read data from a BigQuery dataset outside the perimeter, the Google API gateway instantly blocks the request. Conversely, if a laptop outside the perimeter attempts to download an object from a Cloud Storage bucket inside the perimeter, the request is blocked, even if the user has perfect IAM permissions.

Step 1: Planning and the Dry Run Phase

Warning: Do not deploy an enforced VPC SC perimeter without testing. It will instantly break your production applications if they rely on external API calls.

Google provides a Dry Run mode. This allows you to build the perimeter, log all the API calls that would be blocked, analyze the logs, and fix the architecture before actually enforcing the block.

To create a Dry Run perimeter using the gcloud CLI:

gcloud access-context-manager perimeters create my_secure_perimeter \
    --title="Secure Finance Perimeter" \
    --resources="projects/1234567890" \
    --restricted-services="bigquery.googleapis.com,storage.googleapis.com" \
    --policy=my_access_policy_id \
    --type=regular \
    --dry-run

(Note: You must have an Access Context Manager policy instantiated at the Organization level to create a perimeter).

Step 2: Analyzing the Dry Run Logs

Once the Dry Run perimeter is active, allow your applications to run normally for several days. VPC SC will evaluate every API call.

Navigate to Cloud Logging (Log Explorer) and run the following query to find API calls that violated the perimeter:

logName="projects/1234567890/logs/cloudaudit.googleapis.com%2Fpolicy"
jsonPayload.vpcServiceControlsAuditEvent.dryRun="true"

You will likely find legitimate traffic being flagged. For example, your on-premises data center might be trying to push logs to Cloud Storage, or a developer working from home might be querying BigQuery. Because they are physically outside the VPC SC perimeter, the API gateway flags them for blocking.

Step 3: Creating Ingress and Egress Rules (Exceptions)

To fix the legitimate traffic flagged in the Dry Run logs, you must poke explicit, highly-restricted holes through the perimeter using Ingress and Egress rules.

Ingress Rules: Allow traffic from outside the perimeter to access resources inside.
For example, to allow developers to access BigQuery from home, you would integrate VPC SC with Access Context Manager (ACM). You create an ACM Access Level that requires a corporate device and a US IP address. You then create an Ingress Rule on the perimeter that says: “Allow Ingress to BigQuery only if the request meets the ACM Access Level.”

Egress Rules: Allow resources inside the perimeter to access specific resources outside.
For example, if your VM needs to write telemetry to a third-party vendor’s Pub/Sub topic, you create an Egress rule: “Allow Egress only from this specific Service Account, only to the Pub/Sub API, and only to the vendor’s specific Project ID.”

Step 4: Enforcing the Perimeter

Once you have analyzed the Dry Run logs and built the necessary Ingress/Egress exception rules, you are ready to flip the switch and enforce the perimeter.

Use the CLI to commit the Dry Run configuration to the enforced state:

gcloud access-context-manager perimeters dry-run commit my_secure_perimeter \
    --policy=my_access_policy_id

Instantly, the Google Cloud API gateway begins enforcing the rules. If a malicious insider attempts to copy a BigQuery table to their personal Gmail-associated GCP project (which is outside the perimeter), the API responds with a 403 Forbidden (VPC Service Controls) error. The data cannot leave the logical boundary.

Conclusion

Identity and Access Management (IAM) controls who has access to data, but it cannot control where that data goes. VPC Service Controls provides the missing network-level enforcement for managed cloud APIs. By implementing strict API perimeters and context-aware ingress rules, cloud security architects can definitively neutralize insider threats and mathematically prevent data exfiltration in Google Cloud.