Detections
Analytics

3.8 Ensure VPC Service Controls Is Enabled for Supported Google Cloud Services

Information

Ensure that VPC Service Controls are configured to create security perimeters around sensitive Google Cloud resources, preventing unauthorized data exfiltration and limiting access to resources from approved networks and identities. VPC Service Controls provide an additional layer of defense-in-depth by allowing organizations to define trust boundaries around GCP services and control data movement across those boundaries.

VPC Service Controls provide critical protection against data exfiltration attacks by creating security perimeters that restrict data access based on client identity, device state, and network origin. Without VPC Service Controls, an attacker who compromises credentials or exploits misconfigurations can freely move data between projects, organizations, or external systems. VPC Service Controls enforce defense-in-depth by adding network-level access controls that complement IAM policies, preventing both malicious insiders and external attackers from exfiltrating sensitive data even if they obtain valid credentials. This control is essential for organizations handling regulated data or implementing zero-trust security architectures. VPC Service Controls also protect against supply chain attacks by restricting which services and APIs can interact with protected resources, reducing the blast radius of compromised third-party integrations or malicious code execution within the cloud environment.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Note: The following remediation instructions use Cloud Storage (GCS) as an example. Similar steps should be followed for other services supported by VPC Service Controls (BigQuery, Cloud SQL, Bigtable, etc.) by substituting the appropriate service API and project resources.

From Google Cloud CLI

1: Create an Access Context Manager Policy:

# Check if policy exists
gcloud access-context-manager policies list --organization=<ORG_ID>

# If no policy exists, create one
gcloud access-context-manager policies create \\
 --organization=<ORG_ID> \\
 --title="VPC Service Controls Policy"

2. Create a Service Perimeter to protect Cloud Storage buckets:

# Get policy ID
POLICY_ID=$(gcloud access-context-manager policies list \\
 --organization=<ORG_ID> \\
 --format="value(name)")

# Create perimeter in dry-run mode first
gcloud access-context-manager perimeters create <PERIMETER_NAME> \\
 --title="Production Data Perimeter" \\
 --resources=projects/<PROJECT_NUMBER> \\
 --restricted-services=storage.googleapis.com \\
 --policy=${POLICY_ID} \\
 --perimeter-type=regular \\
 --async

3. Add multiple projects and services to the perimeter:

gcloud access-context-manager perimeters update <PERIMETER_NAME> \\
 --add-resources=projects/<PROJECT_NUMBER_1>,projects/<PROJECT_NUMBER_2> \\
 --add-restricted-services=bigquery.googleapis.com,sqladmin.googleapis.com \\
 --policy=${POLICY_ID}

4. Test with dry-run mode before enforcement:

# Create dry-run spec
gcloud access-context-manager perimeters dry-run create <PERIMETER_NAME> \\
 --policy=${POLICY_ID} \\
 --resources=projects/<PROJECT_NUMBER> \\
 --restricted-services=storage.googleapis.com

5. Monitor dry-run logs to identify blocked requests:

# Query VPC Service Controls logs for dry-run violations
gcloud logging read \\
 'protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
 AND protoPayload.metadata.dryRun=true' \\
 --limit=50 \\
 --format=json \\
 --project=<PROJECT_ID>

6: After testing, enforce the perimeter:

gcloud access-context-manager perimeters dry-run enforce <PERIMETER_NAME> \\
 --policy=${POLICY_ID}

7: Create access levels for conditional access (optional but recommended):

gcloud access-context-manager levels create <ACCESS_LEVEL_NAME> \\
 --title="Corporate Network Access" \\
 --basic-level-spec=<ACCESS_LEVEL_SPEC_FILE>.yaml \\
 --policy=${POLICY_ID}

Example access level spec file (access_level.yaml):

combiningFunction: AND
conditions:
 - ipSubnetworks:
 - "203.0.113.0/24" # Corporate IP range
 members:
 - "user:[email protected]"

Then add the access level to the perimeter:

gcloud access-context-manager perimeters update <PERIMETER_NAME> \\
 --add-access-levels=<ACCESS_LEVEL_NAME> \\
 --policy=${POLICY_ID}

Impact:

Implementing VPC Service Controls requires careful planning as it restricts network access to protected resources. Services outside the perimeter will be denied access to resources inside the perimeter by default, which may impact:

 - Application connectivity: Applications must be within the same perimeter or use authorized ingress/egress rules
 - Data pipelines: Cross-project data flows require explicit perimeter bridges or access levels
 - Third-party integrations: External services may be blocked and require perimeter configuration
 - Administrative access: Admin tasks from non-corporate networks may be restricted unless access levels permit

Organizations should use VPC Service Controls dry-run mode to test policies before enforcement to identify and remediate connectivity issues. There is no direct performance impact on services within the perimeter.

See Also

https://workbench.cisecurity.org/benchmarks/22181

Item Details

Category: SECURITY ASSESSMENT AND AUTHORIZATION, CONFIGURATION MANAGEMENT, CONTINGENCY PLANNING, PLANNING, PROGRAM MANAGEMENT, SYSTEM AND SERVICES ACQUISITION, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|CA-7, 800-53|CM-7, 800-53|CP-6, 800-53|CP-7, 800-53|PL-8, 800-53|PM-7, 800-53|SA-8, 800-53|SC-4, 800-53|SC-7

Plugin: GCP

Control ID: 99d4772bfc8df8ce8775389107cd07d6eef6be780396e01dc359bf3f4ed9f588