VPC Service Controls Perimeter for BigQuery and Cloud Storage: Minimal Data Perimeter Design

Problem: data can leave BigQuery and Cloud Storage through authorized identities

BigQuery and Cloud Storage are IAM-secured, but a principal with valid IAM can export a table to a public bucket, copy data to another project, or query from an unmanaged network. VPC Service Controls creates a Google-enforced perimeter that blocks those data movement paths even when IAM would allow them.

Requirements for a data perimeter

A minimal perimeter for analytics data should:

• Prevent exfiltration from BigQuery and Cloud Storage to outside the organization.
• Restrict access to authorized GCP projects and corporate networks.
• Maintain auditability of access attempts.
• Allow controlled batch loads from on-premises without public internet exposure.

VPC Service Controls does not replace encryption or IAM. It complements them by enforcing a network and project boundary.

Smallest suitable design

One service perimeter is enough for a first implementation. Keep the surface small and add later.

Perimeter membership

• BigQuery datasets that contain sensitive data.
• Cloud Storage buckets that hold raw or curated data for those datasets.
• A dedicated admin project that owns the perimeter policy. Do not use a production workload project as the admin.

Access level for corporate users

Define a basic access level that requires the request to originate from known corporate CIDR ranges. This is evaluated before IAM.

Perimeter policy

• Ingress: allow from an explicit list of approved projects. Default deny all others.
• Egress: default deny. Allow only to resources inside the perimeter.
• Access level: attach the corporate CIDR access level to ingress.

On-prem connectivity

Use Cloud VPN or Private Service Connect with Private Google Access. Do not allow public internet egress for the perimeter workloads. If batch loads are required from on-prem, route them through the VPN into the perimeter and use a service account with limited roles.

Example perimeter definition sketch

# Run from a terminal with roles/accesscontextmanager.policyAdmin
gcloud access-context-manager perimeters create analytics-perimeter \\
  --policy=POLICY_ID \\
  --title="Analytics Data Perimeter" \\
  --resources=projects/PROJECT_WITH_BQ,projects/PROJECT_WITH_GCS \\
  --restricted-services=bigquery.googleapis.com,storage.googleapis.com

Replace POLICY_ID, PROJECT_WITH_BQ, PROJECT_WITH_GCS with your values. The command creates the perimeter object; membership and policy settings are then edited in the console or via API.

Trust and data boundaries

The perimeter edge is the trust boundary enforced by Google. Inside the perimeter is trusted GCP resources and identities that have been vetted via IAM and project membership. Outside is untrusted.

IAM is still required inside the perimeter. A user with BigQuery Data Viewer inside the perimeter can still read data. VPC Service Controls only blocks movement across the edge.

Data at rest remains encrypted by default. VPC Service Controls does not change encryption. It changes where data can be accessed from and where it can be copied to.

Operational checks

Monitor for denied requests. VPC Service Controls violations appear in Cloud Audit Logs with a specific denied reason. Create a log-based alert for denied export, copy, or cross-perimeter access.

Alert on policy changes. Perimeter membership and access level changes are security-critical. Alert on updates to the access context manager policy.

Validate access levels. Periodically review the CIDR definitions in the access level and test evaluation from an authorized and unauthorized IP. Access levels are evaluated at request time.

Test export attempts. From a project inside the perimeter, attempt a prohibited BigQuery export to a bucket outside the perimeter. Expect a VPC Service Controls violation in audit logs. Do not run this in production without coordination.

Review membership drift. New BigQuery datasets or Cloud Storage buckets created in the projects are not automatically added to the perimeter. Review project resource lists regularly.

Failure modes

Misconfigured access levels block legitimate analysts. If the corporate CIDR is wrong or missing, users receive access denied even with correct IAM.

Default egress deny breaks workloads that need external APIs, package registries, or public egress. Workloads inside the perimeter that call external services will fail unless egress is explicitly allowed or proxied.

Perimeter splits break BigQuery external tables. An external table that references a bucket outside the perimeter will fail to read.

Admin project outage halts policy updates. The admin project must remain available for emergency changes.

Rollback is not instantaneous. Perimeter policy changes propagate with delay. Test changes in a non-production perimeter first.

When to change the design

Consider redesign when:

• Cross-perimeter data sharing is required regularly. Use authorized ingress/egress or a data sharing perimeter instead of a single closed perimeter.
• Multi-cloud or third-party SaaS needs access to data. VPC Service Controls cannot protect data accessed outside GCP.
• Public egress to external APIs is a hard requirement. You may need a perimeter bridge, a separate egress perimeter, or a proxy service.

Limitations to keep in mind

• VPC Service Controls does not prevent insider access by principals with valid IAM inside the perimeter.
• It does not prevent data exfiltration via application logic, e.g., returning data in query results to an allowed client.

Practical verification

• Open VPC Service Controls console and confirm BigQuery datasets and Cloud Storage buckets are listed inside the perimeter.
• Check the access level CIDR definitions match your corporate ranges.
• Review Cloud Audit Logs for VPC Service Controls denied entries over the last 7 days.