8.2 Network Security: Cloud Armor, VPC Service Controls & Firewalls

Network Security: Cloud Armor, VPC Service Controls & Firewalls

Core Principle: Enterprise network security in Google Cloud operates across multiple concentric defense rings: Edge Security (Cloud Armor for DDoS and WAF), Perimeter Security (VPC Service Controls for PaaS exfiltration prevention), and Compute/Network Security (Hierarchical Firewall Policies and Cloud NGFW with Layer 7 IPS). Effective cloud architecture combines these layers to enforce least privilege from external edge ingestion down to internal packet inspection.

---

Hierarchical Firewall Policies & Cloud Next Generation Firewall (NGFW)

Google Cloud provides a hierarchical firewall architecture that enforces organizational compliance rules top-down, ensuring central security teams maintain absolute control over traffic flows regardless of project-level changes.

+-----------------------------------------------------------------------------------+
|                    HIERARCHICAL FIREWALL EVALUATION HIERARCHY                     |
+-----------------------------------------------------------------------------------+
|  1. ORGANIZATION FIREWALL POLICIES                                                |
|     - Applied at Org root; evaluated FIRST (Priority 0 - 2,147,483,647)           |
|     - Actions: ALLOW, DENY, or goto_next (delegates evaluation downward)          |
+-----------------------------------------------------------------------------------+
|  2. FOLDER FIREWALL POLICIES                                                      |
|     - Applied at Folder level; inherits or overrides Org policies via goto_next   |
+-----------------------------------------------------------------------------------+
|  3. GLOBAL / REGIONAL NETWORK FIREWALL POLICIES                                   |
|     - Attached directly to individual VPC networks                                |
+-----------------------------------------------------------------------------------+
|  4. TRADITIONAL VPC FIREWALL RULES                                                |
|     - Evaluated LAST (Priority 0 - 65535; default implied deny ingress / allow eg) |
+-----------------------------------------------------------------------------------+

Hierarchical Policy Mechanics

• Precedence & Non-Overridable Guardrails: Organization-level policies evaluate before any folder or VPC rules. If an organization rule contains a DENY for port 22 (SSH) from 0.0.0.0/0, no project owner or network admin can override this rule in a child VPC.
• The goto_next Action: Allows organization security architects to create inspection rules or permissive baseline rules while explicitly delegating specific traffic decisions to lower-level folder or project firewalls.
• Secure Tags Integration: Policies can target instances using Resource Manager Secure Tags (e.g., environment=prod, compliance=pci), which are cryptographically bound to IAM permissions and cannot be manipulated by local VM owners.

Cloud Next Generation Firewall (NGFW) Tiers

Cloud NGFW Enterprise: Layer 7 Intrusion Prevention Service (IPS)

• Architecture: Integrates Palo Alto Networks threat detection technologies directly into Google Cloud's Andromeda SDN without requiring inline third-party firewall appliances or complex routing hops.
• Threat Signatures: Scans live packet payloads for malware, spyware, command-and-control (C2) communication, and known vulnerabilities (e.g., Log4j, OpenSSL exploits).
• Decoupled Scaling: Scales elastically with network traffic without causing network throughput bottlenecks or single points of failure.

---

VPC Service Controls (VPC-SC): Data Exfiltration Prevention

While Cloud IAM governs identity (who has permission to access a service), IAM alone cannot prevent data exfiltration. An authorized developer with valid credentials could legitimately read sensitive data from a corporate BigQuery dataset and write it to an unauthorized personal Cloud Storage bucket.

+-----------------------------------------------------------------------------------+
|                    THE DATA EXFILTRATION RISK WITHOUT VPC-SC                      |
+-----------------------------------------------------------------------------------+
|  [ Compromised Developer / Insider ]  (Valid Corporate IAM Credentials)            |
|         │                                                                         |
|         ├── (1) Authorized Read ===> [ Corporate BigQuery Dataset (Project A) ]    |
|         │                                                                         |
|         └── (2) Exfiltration Write => [ Personal Attacker Storage (Project X) ]   |
|                 (IAM permits write because attacker owns Project X!)             |
+-----------------------------------------------------------------------------------+

+-----------------------------------------------------------------------------------+
|                    VPC SERVICE CONTROLS MITIGATION ARCHITECTURE                   |
+-----------------------------------------------------------------------------------+
|  SERVICE PERIMETER (Projects A, B + Cloud Storage & BigQuery Restricted APIs)     |
|  +-----------------------------------------------------------------------------+  |
|  |  [ Protected BigQuery ] <======> [ Protected GCS Bucket ]                  |  |
|  +-----------------------------------------------------------------------------+  |
|         │                                                                         |
|         └── (BLOCKED) Exfiltration Write to Outside Project X                     |
|             "VPC Service Controls: Request violates perimeter security policy"   |
+-----------------------------------------------------------------------------------+

Core Components of VPC Service Controls

1. Service Perimeter: A logical boundary enclosing one or more Google Cloud projects and specifying a list of Restricted Services (e.g., storage.googleapis.com, bigquery.googleapis.com, pubsub.googleapis.com). All API communication across the perimeter boundary is blocked by default.
2. Access Levels (Access Context Manager): Define contextual conditions for granting ingress access into the perimeter based on:
   • Source IPv4 / IPv6 CIDR blocks (e.g., corporate office or VPN egress IPs).
   • User identity or service account principal.
   • Device posture (Chrome Enterprise, OS version, disk encryption, screen lock).
   • Geographic origin.
3. Ingress and Egress Policy Rules: Granular, directional rules allowing specific cross-perimeter traffic based on API method, identity, caller project, and target resource.
4. Perimeter Bridges: A legacy mechanism used to link two distinct service perimeters bidirectionally. Modern architectures prefer directional Ingress/Egress rules.
5. Dry Run Mode: Enables security architects to test perimeter configurations against live production workloads. Violations are logged to Cloud Logging without blocking requests, preventing accidental application outages.

Ingress vs. Egress Rule Mechanics

{
  "ingressPolicies": [
    {
      "ingressFrom": {
        "identityType": "ANY_IDENTITY",
        "sources": [{"accessLevel": "accessPolicies/123/accessLevels/corp_vpn"}]
      },
      "ingressTo": {
        "resources": ["projects/1122334455"],
        "operations": [{"serviceName": "bigquery.googleapis.com", "methodSelectors": [{"method": "*"}]}]
      }
    }
  ],
  "egressPolicies": [
    {
      "egressFrom": {"identities": ["serviceAccount:pipeline@prod.iam.gserviceaccount.com"]},
      "egressTo": {
        "resources": ["projects/9988776655"],
        "operations": [{"serviceName": "storage.googleapis.com", "methodSelectors": [{"method": "*"}]}]
      }
    }
  ]
}

---

Google Cloud Armor: Edge Defense, WAF & DDoS Protection

Cloud Armor operates at the Google Cloud edge, tightly integrated with External Application Load Balancers (Global and Regional) to defend web applications against volumetric DDoS attacks, application-layer exploits, and malicious bot automation.

+-----------------------------------------------------------------------------------+
|                         CLOUD ARMOR EDGE DEFENSE STACK                            |
+-----------------------------------------------------------------------------------+
|  1. LAYER 3/4 DDOS PROTECTION   |  - Always-On Anycast infrastructure defense      |
|                                 |  - Absorbs multi-terabit SYN/UDP floods at edge |
+---------------------------------+-------------------------------------------------+
|  2. PRECONFIGURED WAF RULES     |  - ModSecurity / OWASP Top 10 Core Rule Set     |
|                                 |  - SQLi, XSS, LFI, RFI, RCE, Scanner Detection  |
+---------------------------------+-------------------------------------------------+
|  3. CUSTOM RULES (CEL ENGINE)   |  - Common Expression Language (IP, Geo, Headers)|
+---------------------------------+-------------------------------------------------+
|  4. ADAPTIVE PROTECTION         |  - Machine Learning anomaly detection           |
|                                 |  - Auto-generates mitigation rules during attack|
+---------------------------------+-------------------------------------------------+
|  5. BOT MANAGEMENT & RATE LIMIT |  - reCAPTCHA Enterprise score evaluation        |
|                                 |  - Rate limiting (e.g., max 100 req/min per IP) |
+-----------------------------------------------------------------------------------+

1. Preconfigured WAF Rules (OWASP Top 10)

Cloud Armor includes out-of-the-box rule sets based on the OWASP Core Rule Set (CRS):

• sqli-v33-stable: Detects SQL Injection attempts.
• xss-v33-stable: Detects Cross-Site Scripting payloads.
• lfi-v33-stable / rfi-v33-stable: Local/Remote File Inclusion.
• rce-v33-stable: Remote Code Execution exploits (e.g., Apache Struts, Spring4Shell).
• scannerdetection-v33-stable: Blocks vulnerability scanners (Nmap, Nessus, Nikto).
• protocolattack-v33-stable: HTTP Request Smuggling, header injection.

2. Custom Rule Expressions (Common Expression Language - CEL)

Architects write expressive custom security rules evaluated by priority (0 to 2,147,483,647):

• Geographic Filtering: origin.region_code == 'RU' || origin.region_code == 'KP'
• IP Subnet Filtering: inIpRange(origin.ip, '198.51.100.0/24')
• Header & Path Inspection: request.headers['user-agent'].contains('sqlmap') || request.path.matches('/admin/.*')
• reCAPTCHA Score Assessment: token.recaptcha_session.score < 0.4

3. Adaptive Protection & Rate Limiting

• Adaptive Protection: Employs ML models that learn baseline traffic patterns for backend services. When an application-layer (Layer 7) volumetric attack occurs, Adaptive Protection alerts security operations within minutes, identifies the offending traffic signature, and provides a one-click suggested rule to mitigate the attack.
• Advanced Rate Limiting: Enforces request quotas per client IP or session cookie (e.g., allow up to 100 requests per 60 seconds; ban or return HTTP 429 / redirect to reCAPTCHA if threshold exceeded).

---

Network Security Capabilities Matrix

---

Concrete Architectural Scenario: Secure Multi-Tier E-Commerce & Analytics Architecture

Scenario Profile

• Client: High-volume online retailer processing $500M in annual transactions.
• Requirements: Mitigate OWASP Top 10 web exploits and Layer 7 DDoS attacks; prevent marketing analysts from copying raw customer BigQuery records to external personal cloud projects; block all external SSH across all enterprise VPCs; inspect outbound VM traffic for malware command-and-control communication.

[ Internet Traffic ] ===> [ Cloud Armor Security Policy (WAF + DDoS + Rate Limit) ]
                                     │
                          [ External HTTPS Load Balancer ]
                                     │
                          [ Frontend GKE Cluster ]
                                     │
  +──────────────────────────────────┴──────────────────────────────────+
  │  ORGANIZATION FIREWALL POLICY: Deny Ingress Port 22 from 0.0.0.0/0    │
  │  CLOUD NGFW ENTERPRISE: Outbound Layer 7 IPS (Blocks C2 / Malware)   │
  +──────────────────────────────────┬──────────────────────────────────+
                                     │
  +──────────────────────────────────┴──────────────────────────────────+
  │  VPC SERVICE CONTROLS PERIMETER                                     │
  │  - Encloses Analytics Project + BigQuery + Cloud Storage APIs        │
  │  - Access Level: Corporate VPN Subnet (192.0.2.0/24)                │
  │  - Egress Blocked: Prevents writing data to any external GCP project│
  +─────────────────────────────────────────────────────────────────────+

Architecture Blueprint

1. Edge Defense: Cloud Armor attached to the External Application Load Balancer with preconfigured WAF rules (sqli-v33-stable, xss-v33-stable), Adaptive Protection enabled, and rate limiting set to 200 req/min per IP.
2. Exfiltration Perimeter: VPC Service Controls enclosing the Analytics Project with BigQuery and Cloud Storage in the restricted services list. An Access Level permits queries only from the Corporate VPN IP range, blocking all data egress to unlisted GCP projects.
3. Hierarchical Guardrails: An Organization Firewall Policy configured with priority 100 to DENY ingress TCP port 22/3389 from 0.0.0.0/0 across all projects.
4. Intrusion Prevention: Cloud NGFW Enterprise enabled on the VPC to perform Layer 7 deep packet inspection and FQDN filtering on outbound egress traffic to block command-and-control beaconing.

---

[!IMPORTANT] Exam Watch: When a scenario involves protecting Google PaaS APIs (like BigQuery or Cloud Storage) from data exfiltration or stolen IAM credentials, the answer is VPC Service Controls. When defending public web applications against SQL injection, XSS, or DDoS, the answer is Cloud Armor. When enforcing mandatory non-overridable network rules across all projects in an enterprise, the answer is Hierarchical Firewall Policies.