Comprehensive Network Security Design

Introduction to Network Security Design

For a Professional Cloud Architect, network security is no longer just about "firewalls at the edge." In a modern cloud environment, security must be multi-layered, identity-centric, and automated. Designing for network security in GCP involves moving from a traditional perimeter-based model to a Defense in Depth and Zero Trust architecture.

This guide covers how to secure your VPCs, protect against external threats, and ensure data remains within authorized boundaries.

Plain-Language Explanation:

比喻 1 — Airport Security Layers (Defense in Depth)

Think of a modern airport. Cloud Armor is the perimeter fence and outer checkpoint that stops obvious threats before they reach the terminal. Identity-Aware Proxy (IAP) is the boarding gate agent that scans your boarding pass and ID for every single flight, even if you already cleared TSA. VPC firewall rules are the locked doors between gates, baggage handling, and the tarmac — different roles need different keys. VPC Service Controls is customs, which inspects what leaves the country (the perimeter), not just who walks through. If any one layer fails, the others still hold.

比喻 2 — A Hotel's Smart Key System (Hierarchical Firewall Policies)

A large hotel chain doesn't let each individual hotel decide how the master key works. Corporate sets chain-wide rules ("no master key opens the safe room") — that's the Organization-level hierarchical firewall policy. Regional managers add their layer ("no key opens the rooftop after 11pm") — that's the Folder-level policy. Finally, each hotel sets per-room locks — that's the project-level VPC firewall rule. A receptionist in one branch cannot override what corporate decided. Same with GCP: a project owner cannot punch a hole through a Folder-level deny rule.

比喻 3 — A Private Phone Line vs Public Switchboard (Private Service Connect)

Imagine you run a hospital and need to call a specific lab for test results. Using the public phone network (the internet) means anyone could potentially listen in or impersonate the lab. Private Service Connect (PSC) is like a private, direct phone line between your office and that one lab — no public switchboard involved. The lab (the "producer") publishes a private endpoint, your office (the "consumer") connects to it using internal IPs only, and the call never leaves Google's private fiber. No VPN, no peering, no public DNS lookup.

The "Defense in Depth" Strategy

Network security should be viewed as a series of concentric circles. If one layer is breached, others must remain to protect the core data.

1. Edge Security: Cloud Armor, Cloud CDN, and Load Balancing (External).
2. Boundary Security: VPC Service Controls (Service Perimeters).
3. Network-Level Security: Cloud Firewall rules, Hierarchical Firewall Policies, and Intrusion Detection (Cloud IDS).
4. Application/Identity Security: Identity-Aware Proxy (IAP), SSL/TLS termination.
5. Compute Security: Shielded VMs, OS Login, and private IPs.

Plain-Language Analogies for Network Security

Analogy 1 — The Medieval Castle (Defense in Depth)

A castle doesn't just have one wall. It has a Moat (External Load Balancer/Cloud Armor) to keep the crowds at bay, a Drawbridge (Identity-Aware Proxy) that only lowers for known allies, Thick Stone Walls (VPC Service Controls) that prevent people from smuggling gold out of the treasury, and Inner Guard Posts (Cloud Firewall) at every hallway to ensure people are only where they are supposed to be.

Analogy 2 — The VIP Nightclub (Identity-Aware Proxy)

In a traditional network, if you have the "key" to the door, you're in. In a Zero Trust model with IAP, the network is like a VIP nightclub. Even if you are standing at the door (the URL), the bouncer (IAP) doesn't care that you're there. They check your ID and your invitation list (IAM roles) before they even let you touch the door handle. No ID, no entry—regardless of where you came from.

Analogy 3 — The Bank Vault's Air Gap (VPC Service Controls)

Imagine a bank where the tellers can see the money but can't take it outside the building. VPC Service Controls is like a specialized security field around the bank. Even if a teller (a compromised service account) tries to "email" the gold (data) to an external account, the security field blocks it because the data is not allowed to leave the "Perimeter" of the bank, even if the teller has valid credentials.

Core Security Components

1. Cloud Firewall (and Firewall Plus)

GCP firewalls are stateful and distributed. They are not "appliances" but rather metadata applied to VMs.

• Service Accounts & Tags: Always prefer using Service Accounts or Network Tags over IP ranges for internal rules to ensure scalability.
• Hierarchical Firewall Policies: Applied at the Folder or Org level to enforce security guardrails that project owners cannot override.

2. VPC Service Controls (VPC SC)

This is a critical PCA topic. It creates a security perimeter around Google-managed services (like Cloud Storage, BigQuery, Vertex AI).

• Data Exfiltration Prevention: Prevents copying data from an authorized bucket to an unauthorized one.
• Access Context Manager: Allows access based on attributes like IP, user identity, or device health.

3. Cloud Armor (WAF & DDoS)

Positioned at the Global External HTTP(S) Load Balancer.

• WAF Rules: Protection against SQL injection, Cross-Site Scripting (XSS).
• Adaptive Protection: Uses ML to detect and block L7 DDoS attacks.

4. Identity-Aware Proxy (IAP)

The cornerstone of Google's "BeyondCorp" (Zero Trust) vision.

• Allows access to web applications and VMs (via SSH/RDP) over the public internet without a VPN.
• Verifies user identity and context for every request.

VPC Firewall Rules and Hierarchical Firewall Policies

GCP firewall enforcement happens at the VM virtual NIC, not at a central appliance. Each rule is evaluated independently by the host hypervisor, which means firewall rules scale linearly with your fleet without introducing chokepoints.

Rule precedence and structure

A firewall rule has five key components: priority (0-65535, lower wins), direction (Ingress or Egress), action (allow or deny), target (which VMs it applies to via service account, tag, or "all"), and filter (source/destination range, port, protocol).

Implied rules ship with every VPC:

• Implied allow egress to 0.0.0.0/0 at priority 65535.
• Implied deny ingress from 0.0.0.0/0 at priority 65535.

Hierarchical firewall policies

Hierarchical policies attach to the Organization or Folder and evaluate before project-level VPC firewall rules. They support three actions network admins lower in the tree cannot override: allow, deny, and goto_next. The goto_next action explicitly delegates the decision to the next level down.

gcloud compute firewall-policies create corp-guardrails \
  --organization=123456789012 \
  --short-name=corp-guardrails
gcloud compute firewall-policies rules create 1000 \
  --firewall-policy=corp-guardrails \
  --action=deny --direction=INGRESS \
  --src-ip-ranges=0.0.0.0/0 --layer4-configs=tcp:22 \
  --description="Deny SSH from internet — IAP-only"

Global vs regional network firewall policies

GCP now offers Global Network Firewall Policies and Regional Network Firewall Policies as a unified replacement for legacy per-VPC rules. They support tags (managed via IAM-controlled tag keys), making cross-project rule authorship safer than the old network-tag string matching, which any project owner could spoof.

Cloud Armor Edge Protection

Cloud Armor is the Layer 7 protection plane that sits in front of the Global External Application Load Balancer, the Regional External Application Load Balancer, and (via Cloud Armor for Network Load Balancers) the external Network Load Balancer with rate-limiting and threat intelligence.

Security policy types

• Backend security policies — attached to backend services, filter requests before they reach the origin.
• Edge security policies — attached to Cloud CDN backend buckets/services, evaluate at Google's edge POPs before cache lookup.

Pre-configured WAF rules

Cloud Armor ships with Google Cloud Armor WAF rules based on the OWASP ModSecurity Core Rule Set 3.3. Each rule has a sensitivity tunable from 1 (high specificity, fewer false positives) to 4 (catches more, more false positives):

gcloud compute security-policies rules create 1000 \
  --security-policy=prod-edge \
  --expression="evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 2})" \
  --action=deny-403

Pre-configured rule sets include sqli-v33-stable, xss-v33-stable, lfi-v33-stable, rfi-v33-stable, rce-v33-stable, methodenforcement-v33-stable, and protocolattack-v33-stable.

Adaptive Protection and rate limiting

• Adaptive Protection uses ML to baseline normal traffic per backend service and auto-suggests rules during anomalous spikes. It emits a JSON adaptiveProtection field in Cloud Logging with attack signatures.
• Rate limiting supports throttle (drop excess) and rate_based_ban (ban offending key for a duration). Keys can be IP, HTTP header, XFF IP, region code, or HTTP cookie.

Cloud Armor Managed Protection tiers

Private Service Connect (PSC): Producer and Consumer

Private Service Connect is GCP's mechanism for exposing services through private IPs without VPC peering, Cloud VPN, or public endpoints. It is the recommended pattern for multi-tenant SaaS, cross-VPC service sharing, and accessing Google APIs privately.

The two PSC topologies

1. PSC for Google APIs (consumer-only)

Maps Google managed services (Cloud Storage, BigQuery, Pub/Sub, etc.) to a private IP within your VPC.

gcloud compute addresses create psc-gcp-apis \
  --global --purpose=PRIVATE_SERVICE_CONNECT \
  --addresses=10.10.0.5 --network=prod-vpc
gcloud compute forwarding-rules create psc-gcp-apis-fr \
  --global --network=prod-vpc \
  --address=psc-gcp-apis --target-google-apis-bundle=all-apis

Now storage.googleapis.com resolves to 10.10.0.5 inside prod-vpc — traffic never touches the public internet.

2. PSC for published services (producer + consumer)

The producer runs a service behind an internal load balancer in their VPC and publishes a service attachment. The consumer creates a PSC endpoint (a forwarding rule with a private IP) in their VPC that references the service attachment by URI.

# Producer side
gcloud compute service-attachments create my-saas-attachment \
  --region=us-central1 --producer-forwarding-rule=ilb-fr \
  --connection-preference=ACCEPT_AUTOMATIC \
  --nat-subnets=psc-nat-subnet

# Consumer side
gcloud compute forwarding-rules create my-saas-endpoint \
  --region=us-central1 --network=consumer-vpc \
  --target-service-attachment=projects/producer/regions/us-central1/serviceAttachments/my-saas-attachment

PSC vs VPC Peering vs Shared VPC

• PSC — exposes a single service as an endpoint. No IP overlap concerns, no transitivity issues, fine-grained per-service IAM.
• VPC Peering — connects entire VPCs. Non-transitive, requires CIDR coordination, exposes everything routable.
• Shared VPC — single VPC owned by a host project, used by service projects. Centralized but tightly coupled.

Cloud NAT for Controlled Egress

Cloud NAT provides outbound internet access to VMs that have no external IP, which is the default-secure posture for production workloads. It is a managed, regional, SDN-based service — there is no NAT gateway VM to operate or scale.

How Cloud NAT works

• Attaches to a Cloud Router in a specific region/VPC.
• Allocates external IPs (auto or manual) and dynamically maps internal source ports to external IP:port tuples.
• Supports both primary and alias IP ranges of subnets in the same region.
• Endpoint-Independent Mapping (EIM) can be enabled for protocols requiring consistent NAT mappings (e.g., WebRTC).

gcloud compute routers create nat-router \
  --network=prod-vpc --region=us-central1
gcloud compute routers nats create prod-nat \
  --router=nat-router --region=us-central1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips \
  --enable-logging --log-filter=ERRORS_ONLY

Port allocation pitfalls

By default, each VM is allocated 64 ports per NAT IP. A VM opening many concurrent connections to the same destination (destIP:destPort) will exhaust ports and trigger NAT_ALLOCATION_FAILED errors visible in VPC Flow Logs.

Mitigations:

• Increase --min-ports-per-vm to 1024 or higher.
• Enable Dynamic Port Allocation (--enable-dynamic-port-allocation) so ports scale up to --max-ports-per-vm only when needed.
• Add more external IPs to the NAT (each IP adds ~64,512 usable ports).

Cloud NAT logging

Cloud NAT can emit two log types: TRANSLATIONS_ONLY and ERRORS_ONLY (or both). For exam scenarios involving "audit which external IPs our private VMs talked to," TRANSLATIONS_ONLY is the answer.

Cloud IDS for Intrusion Detection

Cloud IDS is a Google-managed Intrusion Detection System powered by Palo Alto Networks' threat detection engine. It is detection-only (IDS, not IPS) — alerts go to Cloud Logging and Security Command Center, but Cloud IDS does not block traffic.

Architecture

Cloud IDS deploys an IDS endpoint per region, which receives mirrored traffic via a packet mirroring policy you configure. The endpoint inspects:

• Threat signatures (~9,000+ Palo Alto signatures)
• Malware command-and-control traffic
• Known exploits and vulnerabilities
• Anomalous protocol behavior

Setup workflow

# 1. Allocate a /24 from the producer VPC for the IDS endpoint
gcloud compute addresses create cloud-ids-ip-range \
  --global --purpose=VPC_PEERING --prefix-length=24 \
  --network=prod-vpc

# 2. Create the IDS endpoint
gcloud ids endpoints create prod-ids \
  --network=prod-vpc --zone=us-central1-a \
  --severity=INFORMATIONAL

# 3. Forward mirrored traffic to the IDS endpoint
gcloud compute packet-mirrorings create ids-mirror \
  --region=us-central1 \
  --collector-ilb=$(gcloud ids endpoints describe prod-ids \
    --zone=us-central1-a --format='value(endpointForwardingRule)') \
  --mirrored-subnets=prod-subnet-us-central1

Severity levels and alerting

Alerts are tagged INFORMATIONAL, LOW, MEDIUM, HIGH, or CRITICAL. Configure a log-based alert in Cloud Monitoring:

resource.type="ids.googleapis.com/Endpoint"
jsonPayload.alert_severity="CRITICAL"

Cloud IDS vs Cloud Armor vs VPC Service Controls

Packet Mirroring for Deep Inspection

Packet Mirroring clones all ingress and egress traffic from selected VMs and forwards full packet copies (headers + payload) to a collector — typically an Internal Load Balancer fronting either Cloud IDS or a custom IDS/IPS fleet.

Selection criteria

A packet mirroring policy filters which traffic is cloned, layered as an AND of:

• Mirrored source: specific subnets, specific VM instances by name, or VMs matching network tags.
• Filter: by protocol (tcp/udp/icmp), CIDR ranges, and direction (INGRESS, EGRESS, BOTH).

Cost considerations

Mirroring doubles the egress traffic out of the mirrored VMs — every packet generates a clone sent to the collector. For a hot 10 Gbps service, that is another 10 Gbps you pay for in inter-zone or inter-region transit if the collector is not co-located.

Best practice:

• Place the collector ILB in the same region as mirrored sources to avoid inter-region bandwidth charges.
• Use filters aggressively — mirroring only suspicious subnets or only TCP/443 is far cheaper than mirroring all traffic.

gcloud compute packet-mirrorings create web-tier-mirror \
  --region=us-central1 \
  --collector-ilb=ids-collector-ilb \
  --mirrored-tags=pci-scope \
  --filter-protocols=tcp \
  --filter-cidr-ranges=10.0.0.0/8 \
  --filter-direction=BOTH

Where Packet Mirroring fits

This is the plumbing layer that feeds Cloud IDS or a third-party security appliance. PCA questions often phrase this as "compliance team needs to retain full packet captures for 90 days" — that is mirroring traffic to a third-party VM collector that writes pcaps to Cloud Storage, not Cloud IDS (which doesn't store raw pcaps).

Service Directory for Secure Service Discovery

Service Directory is a managed service registry that provides a single source of truth for service names, IPs, ports, and metadata across GCP, hybrid, and multi-cloud. It eliminates the brittleness of hard-coded IPs or self-hosted Consul/etcd clusters.

Core concepts

• Namespace — top-level scope (e.g., prod, staging).
• Service — logical name within a namespace (e.g., payments-api).
• Endpoint — concrete address:port registered under a service, with optional metadata key/value pairs (version, region, weight).

gcloud service-directory namespaces create prod --location=us-central1
gcloud service-directory services create payments-api \
  --namespace=prod --location=us-central1
gcloud service-directory endpoints create v1-instance-1 \
  --service=payments-api --namespace=prod --location=us-central1 \
  --address=10.20.30.40 --port=8443 \
  --metadata=version=1.4.2,region=us-central1

Service Directory zones for DNS

Service Directory integrates with Cloud DNS via a "Service Directory zone." Create a private DNS zone backed by a Service Directory namespace, and every service automatically becomes resolvable as service.namespace.cloud.dns.suffix.

Security benefits

• IAM-gated reads — only callers with servicedirectory.endpoints.resolve can discover endpoints. Compare to public DNS where any internet client can probe dig.
• Audit logs — every resolve is logged in Cloud Audit Logs, providing a forensic trail of which service talked to which.
• No hardcoded IPs — when an IP rotates (e.g., autoscaler replaces a VM), the registry updates atomically without rolling restarts.

Cloud DNS and DNSSEC

Cloud DNS is Google's authoritative DNS, available in public zones, private zones, forwarding zones, and peering zones. For security architecture, two features matter most: DNSSEC for record integrity, and DNS policies for egress control.

DNSSEC for public zones

DNSSEC signs every DNS response so resolvers can verify records were not tampered with in transit. Enable it on a managed zone:

gcloud dns managed-zones create example-com \
  --dns-name=example.com. --visibility=public \
  --dnssec-state=on \
  --denial-of-existence=nsec3

After enabling, retrieve the DS record and publish it at your domain registrar — without that DS link, resolvers cannot complete the chain of trust.

gcloud dns dns-keys list --zone=example-com \
  --format='value(ds_record_data)'

Private zones, forwarding, and split-horizon DNS

• Private zones — resolve internal records only inside specified VPCs.
• Forwarding zones — forward queries to an on-prem DNS server (e.g., for corp.internal).
• Peering zones — let one VPC resolve another VPC's private zones (common in hub-and-spoke).

DNS policies for inbound/outbound control

A DNS policy can enable inbound DNS forwarding (lets on-prem clients query Cloud DNS via a regional reserved IP) or enforce outbound forwarding for specific zones.

Network Connectivity Center: Hub and Spoke at Scale

Network Connectivity Center (NCC) is GCP's managed hub-and-spoke connectivity fabric. Instead of building point-to-point peerings between every VPC and every on-prem site, NCC provides a logical hub that connects spokes of multiple types.

Spoke types

• VPC spokes — VPCs attached directly to the hub (replaces full-mesh VPC peering).
• Hybrid spokes — HA VPN tunnels and Cloud Interconnect VLAN attachments.
• Router appliance spokes — third-party SD-WAN/NGFW VMs (e.g., Cisco, Palo Alto).

Modes

• Mesh mode — every spoke talks to every other spoke (transitive).
• Star mode — spokes only reach the hub (e.g., for a centralized inspection VPC).

gcloud network-connectivity hubs create global-hub \
  --description="Corp hub-and-spoke"
gcloud network-connectivity spokes linked-vpc-network create prod-vpc-spoke \
  --hub=global-hub --vpc-network=prod-vpc \
  --global
gcloud network-connectivity spokes linked-interconnect-attachments create dc-interconnect \
  --hub=global-hub --region=us-central1 \
  --interconnect-attachments=projects/host/regions/us-central1/interconnectAttachments/vlan-1

Why NCC for security architecture

• Centralized inspection — star mode forces all spoke-to-spoke traffic through a hub VPC running a third-party NGFW or Cloud IDS, giving you a single chokepoint for east-west inspection.
• Operational simplicity — N spokes need N attachments to the hub, not N×(N-1)/2 peerings.
• Cross-region — VPC spokes communicate globally without needing custom routes between regions.

Network Intelligence Center: Observability and Verification

Network Intelligence Center (NIC) is the diagnostic and verification toolkit for GCP networking. It is not a runtime data-plane component — it is the control-plane observatory every architect should know exists before an outage forces them to discover it.

Five modules

1. Network Topology — auto-generated graph of VPCs, subnets, VMs, load balancers, and their traffic volumes. Useful for "where is unexpected egress coming from?" investigations.

2. Connectivity Tests — synthetic reachability checks. You specify a source (VM, IP, GKE pod) and destination, and NIC simulates the packet path through firewalls, routes, and NAT, returning a verdict (REACHABLE, UNREACHABLE with a specific reason like "blocked by firewall rule deny-ssh-from-internet").

gcloud network-management connectivity-tests create web-to-db \
  --source-instance=projects/p/zones/us-central1-a/instances/web-1 \
  --destination-instance=projects/p/zones/us-central1-a/instances/db-1 \
  --destination-port=5432 --protocol=TCP

3. Performance Dashboard — packet loss and latency between regions and zones, sourced from Google's internal probes. Useful for confirming "is it the network or the app?"

4. Firewall Insights — flags unused, shadowed, or overly permissive firewall rules with recommendations. Example output: "Rule allow-all-ssh has not matched a packet in 60 days — consider removing."

5. Network Analyzer — proactive scanning that surfaces config issues (e.g., "subnet exhaustion in 5 days," "VPN tunnel mismatched MTU"). Findings appear automatically — no manual run needed.

When to reach for each

• "Why can't VM A reach VM B?" → Connectivity Tests
• "Which firewall rules can we safely delete?" → Firewall Insights
• "Are we about to run out of IPs?" → Network Analyzer
• "Show me actual traffic patterns" → Network Topology

For PCA scenarios about troubleshooting connectivity in a complex shared-VPC environment, Connectivity Tests is almost always the right tool — it evaluates the actual rule set at simulation time, not a stale documented design.

Implementation Patterns: The "Secure Hub and Spoke"

A common architectural pattern for large enterprises is the Hub and Spoke using Shared VPC.

• The Hub: Contains centralized security appliances (if using 3rd party), Cloud IDS, and centralized logging.
• The Spokes: Isolated projects for different business units.
• Security Benefit: Centralizes the management of network exit points and simplifies the application of Org-level policies.

Architect's Choice: For the PCA exam, if you need to provide secure access to an internal application for remote employees without the overhead of a VPN, the answer is almost always Identity-Aware Proxy (IAP). ::

FAQ — Network Security Design

Q1. What is the difference between a Firewall Rule and VPC Service Controls?

Firewall rules control Network Traffic (IPs, Ports, Protocols) between VMs. VPC Service Controls control Data Movement between Google Services (API calls), specifically preventing data from being exfiltrated to unauthorized projects.

Q2. Can I use Cloud Armor with a Network Load Balancer?

Cloud Armor for Network Load Balancers exists but only supports a limited rule set (rate limiting, threat intelligence, named IP lists). For full WAF protection — including OWASP pre-configured rules — you must use a proxy-type load balancer (Application Load Balancer).

Q3. Is Shared VPC more secure than VPC Peering?

Shared VPC is generally preferred for security governance because it allows a central "Network Admin" to control all networking, while "Service Project Admins" only manage their apps. VPC Peering is a decentralized "handshake" between two networks, which can be harder to audit at scale.

Q4. How do I protect against "Zero Day" web attacks?

Enable Cloud Armor Adaptive Protection. It uses machine learning to establish a baseline of normal traffic and automatically generates rules to block anomalous spikes that look like attacks.

Q5. What is the "Hidden Cost" of VPC Service Controls?

The primary "cost" is operational complexity. Once enabled, it can break legitimate integrations (like a 3rd party tool accessing your BigQuery). You must carefully configure Ingress and Egress rules within the perimeter.

Final Architect Tip

On the PCA exam, look for keywords like "Compliance," "Data Exfiltration," or "Regulatory Requirements." If you see these, your design must include VPC Service Controls. If the focus is on "Public facing web app" and "Attacks," think Cloud Armor. Always design for Least Privilege—don't open port 22 or 3389 to the world; use IAP TCP Forwarding instead.