Prepare and test your skills
Prepare and test your skills
Analyzing data exfiltration risks means deciding when identity controls are not enough and a perimeter boundary is required. VPC Service Controls (VPC-SC) (opens in a new tab) is a context-based perimeter security control that isolates multi-tenant Google Cloud services to mitigate data exfiltration. A service perimeter defines a boundary around projects, VPC networks (opens in a new tab), and restricted services, and API requests to those services cannot cross the boundary unless an ingress or egress rule explicitly allows them. VPC-SC is required when sensitive data, such as intellectual property or data subject to PCI DSS, could be copied or accessed outside trusted networks even by authenticated identities.
Exfiltration vectors are the paths by which data moves from a trusted resource to an unauthorized destination, and a perimeter is required when identity controls alone cannot close those paths. Identity and Access Management (IAM) enforces granular identity-based access, but an identity that is authorized inside the perimeter can still copy data outside it if no boundary exists. VPC-SC adds context-based perimeter security that controls data egress across the boundary, and the two controls together provide defense in depth. The following vectors justify creating a perimeter:
gcloud storage cp command copying to a public Cloud Storage bucket or a bq mk command copying to a permanent external BigQuery table, and VPC-SC blocks the copy to the resource outside the perimeter.How VPC Service Controls blocks movement is by enforcing related controls around explicitly specified restricted services such as Cloud Storage and BigQuery. 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 by service operations, and data exchange between clients and resources separated by perimeters is secured only through ingress and egress rules. Context-aware access evaluates client attributes including identity type, identity, device data, and network origin, so internet access can be restricted to defined IPv4 and IPv6 ranges and on-premises or Google Cloud clients can use Private Google Access from authorized VPC resources.
The perimeter depends on companion network and service controls to close network egress paths. Traffic from VMs inside the perimeter flows to Google APIs through a Private Service Connect (opens in a new tab) endpoint configured with the vpc-sc bundle, Cloud DNS resolves googleapis.com to that endpoint, and VPC firewall rules deny broad egress before selectively allowing TCP port 443 to the endpoint address. Services that are accessible from inside the perimeter are further narrowed by VPC accessible services, which restrict which APIs a VPC network inside the perimeter can call, and by service patterns that permit only specific unsupported API URL patterns. A restricted virtual IP integrated with VPC-SC provides a private path that respects the boundary, and Cloud Audit Logs (opens in a new tab) record access patterns across perimeters for monitoring. A perimeter cannot contain projects from different organizations, so communication between perimeters in different organizations uses perimeter bridges, and a Shared VPC deployment must include the host project in the perimeter along with its service projects.
Exam tip: IAM controls whether an identity can call an API, while VPC Service Controls controls whether restricted-service data can cross the perimeter boundary — use both when an authorized identity must not be able to copy data outside.
Validating perimeters and matching scope means using enforcement modes to test policy and sizing the boundary to where sensitive data lives. A perimeter in enforced mode denies requests that violate the policy, protecting against stolen credentials, misconfigured permissions, and malicious insiders that have access to the projects. A perimeter in dry run mode logs violations as though enforcement were active but does not deny access, which supports previewing a new perimeter, measuring the impact of a change, monitoring unexpected service usage and request origins, and mirroring production boundaries in development before enforcement.
Configure VPC-SC in an ordered sequence where each stage depends on the prior stage:
RESTRICTED-SERVICES alias to align VPC-callable services with restricted services.Choose the perimeter scope that matches the distribution of sensitive data and operational constraints:
| Scope | Protects | Choose when | Avoid when |
|---|---|---|---|
| Broad perimeter | All supported services across the environment | Sensitive data could appear in many projects and consistent developer attributes support ingress policy | Many workloads need public internet or unsupported services that would require excessive exceptions |
| Subset perimeter | Only projects with sensitive data and internal-only workloads | Limited, well-defined projects hold sensitive data, such as BigQuery datasets needing narrow analyst exceptions | Many projects could potentially contain sensitive data |
| No perimeter | No boundary; relies on IAM and network controls | Workloads are internet-facing without sensitive data, use unsupported services, or lack consistent device or IP attributes for ingress rules | Sensitive data exists in the Google Cloud environment |
In production perimeters, restrict all supported services rather than only Cloud Storage and Compute Engine to mitigate the full range of exfiltration paths, and combine the perimeter with strict egress firewall rules and the Restrict Resource Service Usage organization policy.
Implementing granular access policies means adding context-aware exceptions to a deny-by-default perimeter without reopening broad exfiltration paths. VPC Service Controls (VPC-SC) (opens in a new tab) blocks API requests to restricted services such as Cloud Storage and BigQuery from crossing its boundary, while ingress rules, egress rules, and Access Context Manager access levels permit only specific identities, devices, and networks to cross under defined conditions. Effective implementation pairs those policy rules with private network controls and uses dry-run logging and audit logs to diagnose failures.
Context-aware access in VPC Service Controls evaluates client attributes before allowing a request to reach a protected resource inside a perimeter. An access policy collects service perimeters and access levels for an organization, with one access policy allowed at the organization node and additional scoped policies possible for folders and projects. An access level defines conditions on identity type such as service account or user, specific identity, device data such as device trust posture, and network origin such as IP address range or VPC network.
Traffic flows from the external client to the restricted Google Cloud API only when both Identity and Access Management (IAM) permissions and the VPC Service Controls boundary conditions are satisfied. IAM provides identity-based access control for who can act on a resource, while VPC Service Controls provides context-based perimeter security for where and from what context the request originates, including control of data egress. Practical patterns include allowing clients outside the perimeter that reside in authorized VPC resources to use Private Google Access to reach inside, and restricting internet access to resources inside the perimeter to defined ranges of IPv4 and IPv6 addresses.
How ingress and egress rules permit secured exchange is by naming both sides of each allowed flow across the boundary. An ingress rule (opens in a new tab) controls traffic flowing from outside a perimeter to protected resources inside, and an egress rule controls traffic flowing from clients and resources inside a perimeter to destinations outside. Each rule names its source context, its destination project or resource, and the restricted services and methods it applies to, so a request crosses the boundary only when all of its conditions match.
These rules enforce separation scenarios such as preventing clients with privileged access from also reaching partner resources, or allowing clients with access to sensitive data to read public datasets without writing to them. Data operations that would copy data outward, such as gcloud storage cp to a public Cloud Storage bucket or bq mk to a permanent external BigQuery table, remain denied unless an explicit egress rule permits that source, destination, and service combination. For perimeters in different organizations or separate boundaries that must interoperate, perimeter bridges allow defined projects and services to communicate without merging the perimeters.
Limiting service use inside the perimeter prevents a workload inside the boundary from using an unrestricted service as an alternate exfiltration path. VPC accessible services restrict which Google Cloud services can be reached from inside a perimeter, such as from virtual machines in a VPC network (opens in a new tab) hosted inside the perimeter. When enabled, traffic from the VPC network to Google APIs is limited to an allowlist, commonly configured with the alias value RESTRICTED-SERVICES to match the same set defined as restricted services in the perimeter.
For Google services not fully integrated with VPC Service Controls, administrators can use VPC Service Controls service patterns to permit access only to specific unsupported API URL patterns over private paths. This avoids granting overly broad access while still allowing required private-path calls. In production perimeters, restricting only Cloud Storage and Compute Engine leaves other supported APIs unprotected, so the recommended posture is to restrict all supported services and then open narrow, method-level exceptions.
Private network controls make enforcement reliable by moving API traffic off the public internet and denying internet egress paths to Google APIs. Private connectivity moves API traffic from the VPC subnet through Private Service Connect (opens in a new tab) and Cloud DNS rather than the public internet. The subnet enables Private Google Access, a Private Service Connect endpoint and forwarding rule targets the vpc-sc bundle, and a private DNS zone for googleapis.com. maps googleapis.com and *.googleapis.com to the endpoint address such as 10.0.1.1.
Firewall rules then enforce the network boundary around that private path. A low-priority rule such as priority 65534 denies all egress to 0.0.0.0/0, and a higher-priority rule such as priority 1000 allows only tcp:443 to the Private Service Connect address. This combination denies egress to default internet-reachable API domains and implied allowed paths before selectively permitting encrypted API traffic to the endpoint. Google Cloud also provides a restricted virtual IP integrated with VPC Service Controls for this private-access model, and Shared VPC deployments must include the host project in the perimeter alongside service projects or network-based controls will not align with the policy boundary.
Diagnosing perimeter denials and connectivity failures means distinguishing policy denials from network-layer failures and IAM denials. A perimeter in enforced mode denies requests that violate ingress, egress, or accessible-service policy, while a perimeter in dry run mode logs the same violations without denying access. Cloud Audit Logs (opens in a new tab) record access patterns across perimeters and reveal the source network, identity, service, and method of each blocked or would-be-blocked request.
| Mode | Request behavior | Best use |
|---|---|---|
| Enforced mode | Requests that violate the perimeter are denied unless an ingress or egress rule permits them | Production protection against stolen credentials, misconfigured permissions, and malicious insiders |
| Dry run mode | Violations are logged as if enforced but access is not prevented | Previewing new perimeters, testing changes, identifying unexpected service usage, and mirroring production in development |
Common connectivity failures map to specific layers and each names both sides of the dependency. A missing or too-narrow ingress rule blocks an outside identity or network from reaching an inside resource, while a missing egress rule blocks an inside client from copying to a defined outside destination. Overly narrow VPC accessible services block an inside VPC network from reaching a needed Google API even when the perimeter itself would allow it, and incorrect Cloud DNS or firewall configuration blocks the VM from reaching the Private Service Connect endpoint before policy is ever evaluated.
Exam tip: Dry run mode only logs a would-be denial, so use its logs to add the missing access level or ingress and egress rule before switching the same configuration to enforced mode.
Designing secure service perimeters means defining a trust boundary that enforces segmentation without breaking legitimate service use. VPC Service Controls (opens in a new tab) is a context-based perimeter security control that mitigates data exfiltration from Google Cloud services. A service perimeter defines a trust boundary around Google Cloud projects, VPC networks, and protected APIs, so requests that originate outside the perimeter are denied by default even when Identity and Access Management (IAM) permissions would otherwise allow them. Resources inside the same perimeter can communicate freely when IAM and network controls permit, while any access across the boundary requires an explicit access level or ingress or egress rule.
A common unified perimeter is a single large service perimeter that encloses all sensitive projects in an organization. The common unified perimeter provides the most effective protection against data exfiltration compared to multiple segmented perimeters because it eliminates east-west paths between perimeters that must each be explicitly authorized. Management overhead is also lower because administrators focus primarily on north-south access, which is access from the internet to resources inside the perimeter, rather than on east-west traffic between perimeters.
Services and networks inside the common unified perimeter still depend on IAM and VPC firewall controls for granular authorization. Service perimeters do not replace IAM, and the principle of least privilege must still be applied to every identity inside the boundary. Layer the perimeter with additional controls such as blocking direct internet egress from VPC networks so a compromised workload cannot send data out through the network path.
Multiple perimeters are separate service perimeters in one organization that isolate data with different trust, regulatory, or sharing requirements. Multiple perimeters increase management cost because every cross-perimeter flow must be reviewed and every east-west exception must be maintained in addition to north-south access. Choose multiple perimeters only when isolation itself is the security requirement, as in these cases:
Perimeter design principles guide the selection of projects, restricted services, and boundary policies that enforce segmentation without breaking legitimate service functionality. Good perimeter design starts during architecture planning because enabling protection changes how cloud services behave, and the design should be kept as simple as possible. Avoid designs that rely on multiple perimeter bridges, perimeter network projects or demilitarized zone (DMZ) perimeters, and complex access levels.
Enable all protected services in the perimeter to reduce operational complexity and minimize exfiltration vectors. Leaving an API unprotected creates an additional path for data to flow from a protected resource to an unprotected service, so any decision to protect one API and not another requires review and justification. Qualify every new project through a review process and include in the perimeter all projects that pass the qualification conditions.
Ingress and egress rules for cross-perimeter access are granular perimeter exceptions that allow specific API operations to cross the service perimeter boundary. An ingress rule allows traffic to flow from outside the perimeter to a protected resource inside, and an egress rule allows traffic to flow from a protected resource inside to a resource outside. Each rule names both sides of the flow: the source side defines identities and sources such as user, service account, IP address, VPC network, or project, and the destination side defines operations by service name and method plus target resources by project.
If the caller and the target are in the same perimeter, no ingress or egress rule is needed. When they are separated, configure the rule on the perimeter that owns the protected resource. For example, a Compute Engine instance in projects/111 that needs google.storage.objects.get on a Cloud Storage bucket in projects/999 requires an egress rule in the source perimeter where egressFrom allows the workload identity and egressTo names storage.googleapis.com, the google.storage.objects.get method, and projects/999 as the destination resource.
Backup and DR appliance (opens in a new tab) patterns show how the direction follows the protected side:
backupdr.googleapis.com and storage.googleapis.com with the source as the appliance IP address, network, or project, and configure an egress exception in the appliance perimeter for the same two services with the target as the vault project.backupdr.googleapis.com and storage.googleapis.com from the appliance source.backupdr.googleapis.com and storage.googleapis.com to the vault project, optionally combined with the appliance IP address.Audit Manager follows the same principle when the Audit Manager service agent, the Cloud Storage destination bucket, and the audited services are not in the same perimeter. Enrollment and audit operations require Cloud Storage methods such as google.storage.buckets.getIamPolicy, google.storage.buckets.testIamPermissions, google.storage.objects.getIamPolicy, google.storage.buckets.setIamPolicy, google.storage.objects.setIamPolicy, google.storage.objects.create, and google.storage.objects.get to be named explicitly in the ingress rule of the bucket perimeter and the egress rule of the caller perimeter.
Choosing between access levels, rules, and perimeter bridges means matching the control to the source and precision required for controlled communication. Access Context Manager access levels, ingress and egress rules, and perimeter bridges provide three different ways to allow controlled communication without removing the perimeter. An access level grants north-south access from outside based on context such as identity, IP range, or network, so designated IAM principals can reach protected BigQuery or Cloud Storage data while all other outside callers are denied. An ingress or egress rule grants east-west or north-south service access at API and method granularity, so only the named service, method, and project can cross. A perimeter bridge connects projects in two different perimeters so they can exchange data, such as allowing a Requester Pays payer project to sit in a bridge with the bucket project instead of in the same perimeter.
Choose the mechanism by the source and precision required. Choose an access level when the decision is who and from where a human or system may enter, such as allowing the Cloud Storage console page or a signed URL to be reached from an approved public IP range or user account. Choose ingress and egress rules when the decision is which service operation may cross, such as allowing Pub/Sub publishing between two organizations, allowing private VPC access to read a BigQuery dataset, allowing private VPC access to write to a Cloud Storage bucket, or allowing projects in multiple perimeters to share logs in a separate logging perimeter. Reserve bridges for stable project-to-project trust between perimeters and avoid multiplying them, since each bridge widens the effective exfiltration boundary.
Exam tip: For Cloud Storage signed URL operations in an ingress or egress policy, use ANY_IDENTITY as the identity type; ANY_SERVICE_ACCOUNT and ANY_USER_ACCOUNT do not apply to signed URL checks, which are evaluated against the signing credentials and the network origin of the request.
vpc-sc bundle, with Cloud DNS resolving googleapis.com to the endpoint and firewall rules allowing only TCP port 443 to that address.ANY_IDENTITY must be used because ANY_SERVICE_ACCOUNT and ANY_USER_ACCOUNT do not apply to signed URL checks.Identity and Access Management controls whether an identity can call an API, while VPC Service Controls controls whether restricted-service data can cross the perimeter boundary even when Identity and Access Management would allow it. Together they provide defense in depth because an enforced perimeter still denies movement of restricted-service data across the boundary when IAM policies are misconfigured or overly broad.
A perimeter in enforced mode denies requests that violate the policy unless an ingress or egress rule permits them, while a perimeter in dry run mode logs the same violations without denying access. Use dry run mode to preview a new perimeter, measure the impact of a change, monitor unexpected service usage and request origins, and mirror production boundaries in development before enforcement, and use enforced mode for production protection against stolen credentials, misconfigured permissions, and malicious insiders.
A common unified perimeter is a single large service perimeter enclosing all sensitive projects and provides the most effective protection against data exfiltration because it eliminates east-west paths between perimeters while lowering management overhead to focus on north-south access from the internet. Choose multiple perimeters only when isolation itself is the security requirement, such as separating high-trust healthcare data from de-identified shareable data, limiting Payment Card Industry Data Security Standard (PCI DSS) scope, or isolating independent tenants where movement between tenants is considered exfiltration.
A security engineer is configuring and troubleshooting context-aware access controls for administrative access to resources protected inside a VPC Service Controls perimeter.
The engineer has created Access Context Manager access levels that enforce device posture verification and IP origin restrictions. Different access bindings were applied to multiple Google Groups in Cloud Identity to govern various developer tiers. During security validation, the engineer discovers that a user assigned to both the Security-Core group (which enforces a strict managed device posture) and the General-Auditors group (which only requires a corporate network IP) can successfully invoke Google Cloud APIs on perimeter-protected resources from an unapproved personal device.
Why is this access permitted, and how should the security engineer remediate the issue?
Last updated