Halberd Payments: actually reducing PCI scope in a shared VPC estate

The control has to live somewhere the engineer who made the 5432 mistake cannot edit. That is the whole design principle.

Structure:

• Two host projects, not one. A cardholder-data host project and a corporate host project. Shared VPC attachment is a hard boundary: no route exists between them without an explicit, reviewed connection. This is the single change that does the most work.
• Folders mirror the boundary: org / prod / cde and org / prod / corporate, with other environments as sibling folders. Policies attach to folders, so new projects inherit the boundary instead of requiring someone to remember.
• Hierarchical firewall policies at the folder level: a baseline policy on the org node with deny ingress 0.0.0.0/0 and ::/0 at low priority, then explicit allows for the known flows (health checks from the load balancer ranges, monitoring, the interconnect path) at higher priority. goto_next on the CDE folder policy so it composes with the org baseline rather than replacing it.
• Egress controls too: deny 0.0.0.0/0 egress from the CDE subnet except via a controlled egress path with FQDN-based rules. Exfiltration and unpatched outbound calls are the same finding category.
• IAM: remove compute.firewalls.* from project-level roles; give developers roles/compute.networkUser scoped to specific subnets. Firewall authorship moves to the network security team.

Why project-level VPC firewall rules are not the control: they are governed by project IAM, so the same engineer who can create a VM in the project can typically create a firewall rule in it. A control that the subject of the control can edit is a procedure, not a control. Hierarchical firewall policies are attached at the org/folder level with IAM held by a separate group, and project-level rules cannot override a hierarchical deny. That is the property the QSA is actually asking about.

Also add: VPC Flow Logs on the CDE subnets shipped to a CDE-restricted log bucket, and a log-based alert on any firewall rule insertion in the CDE folder. The four-day window is the finding; detection is what closes it.

The QSA's scope rule has two halves: systems that can connect to the CDE, and systems that hold credentials or data for the CDE. You must close both, or the non-CDE projects stay in scope.

Actually reduces scope:

1. Separate host projects with no peering, no shared routes. Removes connectivity, which removes the 35 projects from the network-connected scope.
2. Replace any shared credentials path. If a marketing job holds a service account key that can read a CDE bucket, that project is in scope regardless of network. Audit for it explicitly; this is where scope quietly survives a network fix.
3. Move the analytics data out, rather than grant access to it in place. If non-CDE analysts query a view over a CDE-owned BigQuery dataset, the reader project is arguably in scope. Push de-identified rows on a schedule into a dataset owned by the corporate data project, with the de-identification applied before the copy. Granting a view is the tempting shortcut and it does not work.
4. Move the acquired company's two projects to their own host project and folder, so their engineers' IAM blast radius is two projects and they cannot reach the other seven CDE projects. Keep subnets non-overlapping so you can merge later cheaply.

Cosmetic (do not claim scope credit): renaming projects, adding labels and tags, deploying another vulnerability scanner, creating a separate logging project without changing who can read the logs, and rewriting the 5432 rule as project-level VPC firewall rules.

Reduces risk, does not reduce scope:

• VPC Service Controls perimeter around the CDE projects with the corporate projects outside. Excellent exfiltration control, and it is the thing that would have contained a bad actor - but it does not remove the network reachability the QSA is asking about, and it does not govern the on-premises Oracle path over Interconnect.
• Private Service Connect for the data-team-to-Oracle path, with an explicit consumer accept list, replacing any broad Interconnect route advertisement into the CDE subnets.
• CMEK on CDE buckets and Spanner, plus Access Transparency. Risk reduction, not scope reduction.

Say the quiet part to the CISO: scope reduction here is a re-architecture of two project boundaries plus a data copy job, roughly one quarter of work. Everything else on the list is defense in depth that you should also do, but describing it as scope reduction will fail the next audit.

One host project per trust boundary, shared services consumed as services, not as network reach.

Isolation design:

• The acquired company's two projects go into a third host project in a sibling folder, not into the main CDE host project. Shared VPC permits exactly one host per service project, so this is a structural decision, and it means their engineers' networkAdmin grants reach only their own VPC.
• A hierarchical firewall policy on their folder denies RFC1918 to the other CDE subnets and to the corporate host project, with an explicit allow to the shared-services CIDR only.

Shared services, resolved properly:

1. Logging: do not punch a route to a shared logging collector. Use aggregated sinks at the folder level - log routing is an API operation, not a network flow. Their projects' logs land in a CDE log bucket they cannot read, and they get a separate sink into their own bucket for their own troubleshooting. No connectivity required.
2. Artifact Registry: PSC endpoints with an explicit consumer accept list, or a per-host-project registry mirror. Prefer the mirror: two identical registries are cheap, and it removes a cross-boundary path whose ACL will drift.
3. Oracle over Interconnect: publish the on-premises prefix into each host project separately via a Cloud Router/VPN or Interconnect attachment for that host project. Do not advertise the full on-prem range into all three. The data team's job runs from the CDE host project side, and the acquired company never sees a route to the Oracle host at all.
4. Access Context Manager + VPC Service Controls perimeter around the CDE folder with the acquired company outside it. Their engineers cannot call CDE APIs even with a mis-issued token.

Judgment call to state explicitly: three host projects for 44 projects is more network objects and more router config, and there is a real temptation to use one host project plus firewall denies. Denies are a policy; host-project separation is a structural boundary with a separate IAM surface. For a PCI estate with an acquired company whose engineers you do not manage, take the structure.